From ecrit-bounces@ietf.org Tue Apr 03 15:49:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYp0C-0002z3-PR; Tue, 03 Apr 2007 15:49:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYp0B-0002ys-UW for ecrit@ietf.org; Tue, 03 Apr 2007 15:49:11 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYp0A-0003Kr-HW for ecrit@ietf.org; Tue, 03 Apr 2007 15:49:11 -0400 Received: (qmail invoked by alias); 03 Apr 2007 19:49:09 -0000 Received: from p54984833.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.72.51] by mail.gmx.net (mp038) with SMTP; 03 Apr 2007 21:49:09 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+kDscn2E6kNv6h8tjWcGFgHe1In7YIsIBnFDbcQ8 XITjmiWHeAnfv7 Message-ID: <4612AFB3.6090407@gmx.net> Date: Tue, 03 Apr 2007 21:49:07 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) 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-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Bernard Aboba Subject: [Ecrit] Review of IEEE 802.11k: Urgent! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, based on the IETF ECRIT / IEEE information sharing event at IETF#68 it was indicated that a review of IEEE documents would be useful. Bernard Aboba has provided me with information about the documents that should be reviewed. Thank you, Bernard. We should start with IEEE 802.11k (with a focus on the location information format specific sections). Unfortunately, the document is already in sponsor ballot and a review needs to be provided very soon. Who would be willing to review the document? I will send the username/passwd to fetch the latest document version to the reviewers. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 03 17:22:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYqRp-0008JS-RF; Tue, 03 Apr 2007 17:21:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYqRo-0008Ii-Nj for ecrit@ietf.org; Tue, 03 Apr 2007 17:21:48 -0400 Received: from an-out-0708.google.com ([209.85.132.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYqRn-0002uY-D2 for ecrit@ietf.org; Tue, 03 Apr 2007 17:21:48 -0400 Received: by an-out-0708.google.com with SMTP id d30so1901166and for ; Tue, 03 Apr 2007 14:21:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=jP0YlWFFZXmA+DnXiZBDZ4yD39xKPjmRYSCfAoCCNIIwmtNis7sY/+j8Qg0Z4Jf79wdczxGES1lnyH0AlK2lUiG14Fn7aXC1pBsH9G1HF1WjuKBIwQyhr5rzds1aWOJgJbfLh/lU/2KsaB7kXFBRNjHGO2/1hiIy5tNb+IMCrLU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=gdnKPK3U4TCCJzr8tIsmFfTeU7aEKIqprkEh9XUW0X5SfyxovS4BHLbF9wUtuI5q1niBO/s7zilM9AblFzXJ08vuaFqkMG82Gi8JOvu/oyLk7U16O2m1adArz8nb4c+aAEzIMzI8sE0/pg28IhFIK+QlOaDYGpEgOc7qGo1uQv4= Received: by 10.100.112.19 with SMTP id k19mr4822006anc.1175635306772; Tue, 03 Apr 2007 14:21:46 -0700 (PDT) Received: by 10.100.34.6 with HTTP; Tue, 3 Apr 2007 14:21:46 -0700 (PDT) Message-ID: <5bfe7a820704031421o6121026seaad271706b764f3@mail.gmail.com> Date: Tue, 3 Apr 2007 14:21:46 -0700 From: "Dorothy Stanley" To: "Hannes Tschofenig" Subject: Re: [Ecrit] Review of IEEE 802.11k: Urgent! In-Reply-To: <4612AFB3.6090407@gmx.net> MIME-Version: 1.0 References: <4612AFB3.6090407@gmx.net> X-Spam-Score: 1.0 (+) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: GEOPRIV , Bernard Aboba , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1717684245==" Errors-To: ecrit-bounces@ietf.org --===============1717684245== Content-Type: multipart/alternative; boundary="----=_Part_15063_24840104.1175635306693" ------=_Part_15063_24840104.1175635306693 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hannes, Please note that the username/password information may, per agreement by the IEEE 802.11 chair, be given to individuals in the IETF for review of IEEE 802.11 documents. However, the username/password information may not be shared on e-mail lists, posted on websites, or in any similar way be distributed. Thank you, and please contact me if there are further questions. Dorothy Stanley Liaison IEEE 802.11 to IETF On 4/3/07, Hannes Tschofenig wrote: > > Hi all, > > based on the IETF ECRIT / IEEE information sharing event at IETF#68 it > was indicated that a review of IEEE documents would be useful. Bernard > Aboba has provided me with information about the documents that should > be reviewed. Thank you, Bernard. > > We should start with IEEE 802.11k (with a focus on the location > information format specific sections). Unfortunately, the document is > already in sponsor ballot and a review needs to be provided very soon. > Who would be willing to review the document? I will send the > username/passwd to fetch the latest document version to the reviewers. > > Ciao > Hannes > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > ------=_Part_15063_24840104.1175635306693 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hannes,

Please note that the username/password information may, per agreement
by the IEEE 802.11 chair, be given to individuals in the IETF for review of
IEEE 802.11 documents. However, the username/password information
may not be shared on e-mail lists, posted on websites, or in any similar
way be distributed.

Thank you, and please contact me if there are further questions.

Dorothy Stanley
Liaison IEEE 802.11 to IETF

On 4/3/07, Hannes Tschofenig <Hannes.Tschofenig@gmx.net> wrote:
Hi all,

based on the IETF ECRIT / IEEE information sharing event at IETF#68 it
was indicated that a review of IEEE documents would be useful. Bernard
Aboba has provided me with information about the documents that should
be reviewed. Thank you, Bernard.

We should start with IEEE 802.11k (with a focus on the location
information format specific sections). Unfortunately, the document is
already in sponsor ballot and a review needs to be provided very soon.
Who would be willing to review the document? I will send the
username/passwd to fetch the latest document version to the reviewers.

Ciao
Hannes


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

------=_Part_15063_24840104.1175635306693-- --===============1717684245== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1717684245==-- From ecrit-bounces@ietf.org Tue Apr 03 17:52:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYqvm-0004eX-PP; Tue, 03 Apr 2007 17:52:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYqvl-0004eI-S5 for ecrit@ietf.org; Tue, 03 Apr 2007 17:52:45 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HYqvk-0005Tk-EA for ecrit@ietf.org; Tue, 03 Apr 2007 17:52:45 -0400 Received: (qmail invoked by alias); 03 Apr 2007 21:52:43 -0000 Received: from p54984833.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.72.51] by mail.gmx.net (mp030) with SMTP; 03 Apr 2007 23:52:43 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18bmPt5xnAbcFSAk5VhKQlajPwEcaf9zR4t6SiabU JEa61iJ0LV97WM Message-ID: <4612CCAA.7070206@gmx.net> Date: Tue, 03 Apr 2007 23:52:42 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Dorothy Stanley Subject: Re: [Ecrit] Review of IEEE 802.11k: Urgent! References: <4612AFB3.6090407@gmx.net> <5bfe7a820704031421o6121026seaad271706b764f3@mail.gmail.com> In-Reply-To: <5bfe7a820704031421o6121026seaad271706b764f3@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: GEOPRIV , Bernard Aboba , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Thanks for adding this info. This was the reason why I have not distributed the username/password. Dorothy Stanley wrote: > Hannes, > > Please note that the username/password information may, per agreement > by the IEEE 802.11 chair, be given to individuals in the IETF for > review of > IEEE 802.11 documents. However, the username/password information > may not be shared on e-mail lists, posted on websites, or in any similar > way be distributed. > > Thank you, and please contact me if there are further questions. > > Dorothy Stanley > Liaison IEEE 802.11 to IETF > > On 4/3/07, Hannes Tschofenig wrote: >> >> Hi all, >> >> based on the IETF ECRIT / IEEE information sharing event at IETF#68 it >> was indicated that a review of IEEE documents would be useful. Bernard >> Aboba has provided me with information about the documents that should >> be reviewed. Thank you, Bernard. >> >> We should start with IEEE 802.11k (with a focus on the location >> information format specific sections). Unfortunately, the document is >> already in sponsor ballot and a review needs to be provided very soon. >> Who would be willing to review the document? I will send the >> username/passwd to fetch the latest document version to the reviewers. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 05 10:54:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZTMH-0002h1-FB; Thu, 05 Apr 2007 10:54:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZTMG-0002gt-1m for ecrit@ietf.org; Thu, 05 Apr 2007 10:54:40 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZTMD-0002zB-PJ for ecrit@ietf.org; Thu, 05 Apr 2007 10:54:40 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JG100FLV5F0N6@usaga01-in.huawei.com> for ecrit@ietf.org; Thu, 05 Apr 2007 07:54:37 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JG1004YM5EZB1@usaga01-in.huawei.com> for ecrit@ietf.org; Thu, 05 Apr 2007 07:54:36 -0700 (PDT) Date: Thu, 05 Apr 2007 09:53:24 -0500 From: Spencer Dawkins Subject: Re: [Ecrit] SDO Emergency Services Workshop 2007 To: ECRIT Message-id: <1e8401c77792$296f0260$6401a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; reply-type=response; charset=Windows-1252; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: <45F1DC03.9030609@gmx.net> X-Spam-Score: 0.5 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi, Hannes, Is there any opportunity for remote participation in this meeting? Thanks, Spencer > Hi all, > > we would like to inform you about the progress of the preparation o= f the=20 > 2nd SDO Emergency Services Workshop hosted by the U.S. Department o= f=20 > Transportation (DOT). The workshop will be held April 10, 11 & 12, = 2007,=20 > from 8:30 am =96 6:00 pm., in the Jefferson Building of the Library= of=20 > Congress, located at 101 Independence Avenue SE in Washington, D.C. > > Please find updated information at this webpage: > http://www.emergency-services-coordination.info/2007/ > > Best regards, > > Jenny Hansen > Marc Linsner > Stephen McCann > Christian Militeau > Atle Monrad > Henning Schulzrinne > Hannes Tschofenig > Harry Worstell > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 05 21:54:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZdel-0005dm-8j; Thu, 05 Apr 2007 21:54:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZdek-0005de-Gt for ecrit@ietf.org; Thu, 05 Apr 2007 21:54:26 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZdej-0001We-A0 for ecrit@ietf.org; Thu, 05 Apr 2007 21:54:26 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l361sL7S018781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 5 Apr 2007 21:54:22 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <44E539DD-6E89-4C43-A0F9-824AA8E59B83@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ECRIT From: Henning Schulzrinne Date: Thu, 5 Apr 2007 21:54:16 -0400 X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Subject: [Ecrit] "An S O S for 911 Systems in Age of High-Tech" (NYT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org http://www.nytimes.com/2007/04/06/us/06phone.html?hp _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 09 07:31:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Has5h-0004a4-7d; Mon, 09 Apr 2007 07:31:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Has5g-0004Zy-9i for ecrit@ietf.org; Mon, 09 Apr 2007 07:31:20 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Has5e-0001j2-S2 for ecrit@ietf.org; Mon, 09 Apr 2007 07:31:20 -0400 Received: (qmail invoked by alias); 09 Apr 2007 11:31:18 -0000 Received: from ip-90-187-134-255.web.vodafone.de (EHLO [90.187.134.255]) [90.187.134.255] by mail.gmx.net (mp028) with SMTP; 09 Apr 2007 13:31:18 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/iMPgrHQjiAK+T1sAw1xQ7BcP7rHv5WFq0EVtr+9 aVpVYqItG+YuK+ Message-ID: <461A2403.1080502@gmx.net> Date: Mon, 09 Apr 2007 13:31:15 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Spencer Dawkins Subject: Re: [Ecrit] SDO Emergency Services Workshop 2007 References: <45F1DC03.9030609@gmx.net> <1e8401c77792$296f0260$6401a8c0@china.huawei.com> In-Reply-To: <1e8401c77792$296f0260$6401a8c0@china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.5 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Yes. I will update the webpage to distribute information about the different ways to participate remotely. http://www.emergency-services-coordination.info/2007/ > -----Ursprüngliche Nachricht----- > Von: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > Gesendet: Donnerstag, 5. April 2007 16:53 > An: ECRIT > Betreff: Re: [Ecrit] SDO Emergency Services Workshop 2007 > > Hi, Hannes, > > Is there any opportunity for remote participation in this meeting? > > Thanks, > > Spencer > > > > Hi all, > > > > we would like to inform you about the progress of the > preparation of the > > 2nd SDO Emergency Services Workshop hosted by the U.S. > Department of > > Transportation (DOT). The workshop will be held April 10, > 11 & 12, 2007, > > from 8:30 am – 6:00 pm., in the Jefferson Building of the > Library of > > Congress, located at 101 Independence Avenue SE in Washington, D.C. > > > > Please find updated information at this webpage: > > http://www.emergency-services-coordination.info/2007/ > > > > Best regards, > > > > Jenny Hansen > > Marc Linsner > > Stephen McCann > > Christian Militeau > > Atle Monrad > > Henning Schulzrinne > > Hannes Tschofenig > > Harry Worstell > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 09 10:39:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hav1q-0007Ku-CY; Mon, 09 Apr 2007 10:39:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hav1p-0007Kp-LW for ecrit@ietf.org; Mon, 09 Apr 2007 10:39:33 -0400 Received: from smtp01out.dot.gov ([199.79.179.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hav1m-0002vw-9I for ecrit@ietf.org; Mon, 09 Apr 2007 10:39:33 -0400 Received: from dotfaawms005.ad.dot.gov ([152.119.86.161]) by smtp01out.dot.gov with ESMTP; 09 Apr 2007 10:39:25 -0400 X-IronPort-AV: i="4.14,388,1170651600"; d="scan'208,217"; a="73394366:sNHT68421012" Received: from OSTMAIL03VS3.ad.dot.gov ([152.119.86.69]) by DOTFAAWMS005.ad.dot.gov with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Apr 2007 10:39:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Apr 2007 10:39:23 -0400 Message-ID: <0A0D0FBCB8154043B909C961D02A7A4403F393D6@OSTMAIL03VS3.ad.dot.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SDO Coordination Workshop (Washington, D.C.): Remote participation information (dial-up/conference call #) Thread-Index: Acd6tN2nOgGny5wnTDe4PfFDXlUdvg== From: To: X-OriginalArrivalTime: 09 Apr 2007 14:39:24.0310 (UTC) FILETIME=[DE264360:01C77AB4] X-Spam-Score: 0.4 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Subject: [Ecrit] SDO Coordination Workshop (Washington, D.C.): Remote participation information (dial-up/conference call #) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1476786583==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1476786583== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77AB4.DDDFC485" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77AB4.DDDFC485 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The USDOT, via ITS America, has the following Call-In number for the duration of the workshop:=20 =20 Call: 1-888-409-0010=20 Participant Code: 1984# =20 =20 We will have information about video/Pod Cast availability later this evening as we firm up the details.=20 =20 Thanks everyone! =20 Jenny Hansen, Contractor Project Coordinator NG9-1-1 USDOT/NHTSA (202) 366-5598 http://www.its.dot.gov/ng911=20 =20 =20 ------_=_NextPart_001_01C77AB4.DDDFC485 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The USDOT, via ITS America, has the following = Call-In number for the duration of the workshop:

 

Call:  1-888-409-0010 =

Participant Code: 1984# =  

 

We will have information about video/Pod Cast = availability later this evening as we firm up the details.

 

Thanks everyone!

 

Jenny Hansen, Contractor

Project Coordinator = NG9-1-1

USDOT/NHTSA

(202) 366-5598

http://www.its.dot.gov/ng911

 

 

------_=_NextPart_001_01C77AB4.DDDFC485-- --===============1476786583== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1476786583==-- From ecrit-bounces@ietf.org Tue Apr 10 09:03:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbG0P-0002BP-Bx; Tue, 10 Apr 2007 09:03:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbG0N-0002BC-Tb; Tue, 10 Apr 2007 09:03:27 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbG0L-0004OT-DZ; Tue, 10 Apr 2007 09:03:27 -0400 Received: from unknown (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51]) by co300216-co-outbound.avaya.com with ESMTP; 10 Apr 2007 09:03:24 -0400 X-IronPort-AV: i="4.14,390,1170651600"; d="scan'208,217"; a="1792671:sNHT13317072" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Review of IEEE 802.11k: Urgent! Date: Tue, 10 Apr 2007 16:02:42 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Review of IEEE 802.11k: Urgent! Thread-Index: Acd2NkO+jqhA4T9AQtuWe6cUI4tCGQFOf8pA References: <4612AFB3.6090407@gmx.net> <5bfe7a820704031421o6121026seaad271706b764f3@mail.gmail.com> From: "Romascanu, Dan \(Dan\)" To: "Dorothy Stanley" , "Hannes Tschofenig" X-Spam-Score: 0.1 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: GEOPRIV , Bernard Aboba , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0876130095==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0876130095== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C77B70.86924DE8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C77B70.86924DE8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hannes, Dorothy, =20 I would be interested in reviewing IEEE 802.11k. Can you send me on private mail the user name and password? What is the deadline for submitting comments?=20 =20 Dan =20 =20 =20 =20 _____ =20 From: Dorothy Stanley [mailto:dstanley1389@gmail.com]=20 Sent: Wednesday, April 04, 2007 12:22 AM To: Hannes Tschofenig Cc: GEOPRIV; Bernard Aboba; ECRIT Subject: Re: [Ecrit] Review of IEEE 802.11k: Urgent! =09 =09 Hannes, =09 Please note that the username/password information may, per agreement by the IEEE 802.11 chair, be given to individuals in the IETF for review of=20 IEEE 802.11 documents. However, the username/password information may not be shared on e-mail lists, posted on websites, or in any similar way be distributed. =09 Thank you, and please contact me if there are further questions. =09 Dorothy Stanley Liaison IEEE 802.11 to IETF =09 =09 On 4/3/07, Hannes Tschofenig wrote:=20 Hi all, =09 based on the IETF ECRIT / IEEE information sharing event at IETF#68 it was indicated that a review of IEEE documents would be useful. Bernard=20 Aboba has provided me with information about the documents that should be reviewed. Thank you, Bernard. =09 We should start with IEEE 802.11k (with a focus on the location information format specific sections). Unfortunately, the document is=20 already in sponsor ballot and a review needs to be provided very soon. Who would be willing to review the document? I will send the username/passwd to fetch the latest document version to the reviewers. =09 Ciao=20 Hannes =09 =09 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit=20 =09 ------_=_NextPart_001_01C77B70.86924DE8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hannes, Dorothy,
 
I would be interested in reviewing IEEE 802.11k. = Can you send=20 me on private mail the user name and password? What is the deadline for=20 submitting comments?
 
Dan
 
 
 
 

From: Dorothy Stanley=20 [mailto:dstanley1389@gmail.com]
Sent: Wednesday, April 04, = 2007=20 12:22 AM
To: Hannes Tschofenig
Cc: GEOPRIV; = Bernard Aboba;=20 ECRIT
Subject: Re: [Ecrit] Review of IEEE 802.11k:=20 Urgent!

Hannes,

Please note that the username/password = information=20 may, per agreement
by the IEEE 802.11 chair, be given to = individuals in the=20 IETF for review of
IEEE 802.11 documents. However, the = username/password=20 information
may not be shared on e-mail lists, posted on websites, = or in=20 any similar
way be distributed.

Thank you, and please = contact me if=20 there are further questions.

Dorothy Stanley
Liaison IEEE = 802.11 to=20 IETF

On 4/3/07, Hannes=20 Tschofenig <Hannes.Tschofenig@gmx.net&g= t;=20 wrote:=20
Hi=20 all,

based on the IETF ECRIT / IEEE information sharing event = at=20 IETF#68 it
was indicated that a review of IEEE documents would be = useful.=20 Bernard
Aboba has provided me with information about the = documents that=20 should
be reviewed. Thank you, Bernard.

We should start = with IEEE=20 802.11k (with a focus on the location
information format specific = sections). Unfortunately, the document is
already in sponsor = ballot and=20 a review needs to be provided very soon.
Who would be willing to = review=20 the document? I will send the
username/passwd to fetch the latest = document version to the reviewers.

Ciao=20 =
Hannes


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

------_=_NextPart_001_01C77B70.86924DE8-- --===============0876130095== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0876130095==-- From ecrit-bounces@ietf.org Tue Apr 10 15:37:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbM9M-0007yO-Vw; Tue, 10 Apr 2007 15:37:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbM9K-0007yE-VX for ecrit@ietf.org; Tue, 10 Apr 2007 15:37:06 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbM9E-0004tB-RO for ecrit@ietf.org; Tue, 10 Apr 2007 15:37:06 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGA00330RTN7B@usaga01-in.huawei.com> for ecrit@ietf.org; Tue, 10 Apr 2007 12:37:00 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGA00GW3RTKMN@usaga01-in.huawei.com> for ecrit@ietf.org; Tue, 10 Apr 2007 12:36:59 -0700 (PDT) Date: Tue, 10 Apr 2007 14:35:42 -0500 From: Spencer Dawkins Subject: Re: [Ecrit] SDO Coordination Workshop (Washington,D.C.): Remote participation information (dial-up/conference call #) To: ecrit@ietf.org Message-id: <31d801c77ba7$6e7f2650$6401a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-Priority: 3 X-MSMail-priority: Normal References: <0A0D0FBCB8154043B909C961D02A7A4403F393D6@OSTMAIL03VS3.ad.dot.gov> X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: Jenny.Hansen@dot.gov X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1125624465==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1125624465== Content-type: multipart/alternative; boundary="Boundary_(ID_xQyjXQhptS58MWCFvQT2bg)" This is a multi-part message in MIME format. --Boundary_(ID_xQyjXQhptS58MWCFvQT2bg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Not sure quite who to tell, but the audio feed has just gone very quiet... remote participants can hear each other, but not the conference. Spencer ----- Original Message ----- From: Jenny.Hansen@dot.gov To: ecrit@ietf.org Sent: Monday, April 09, 2007 9:39 AM Subject: [Ecrit] SDO Coordination Workshop (Washington,D.C.): Remote participation information (dial-up/conference call #) The USDOT, via ITS America, has the following Call-In number for the duration of the workshop: Call: 1-888-409-0010 Participant Code: 1984# We will have information about video/Pod Cast availability later this evening as we firm up the details. Thanks everyone! Jenny Hansen, Contractor Project Coordinator NG9-1-1 USDOT/NHTSA (202) 366-5598 http://www.its.dot.gov/ng911 ------------------------------------------------------------------------------ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --Boundary_(ID_xQyjXQhptS58MWCFvQT2bg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Not sure quite who to tell, but the audio feed has just gone very quiet... remote participants can hear each other, but not the conference.
 
Spencer
----- Original Message -----
Sent: Monday, April 09, 2007 9:39 AM
Subject: [Ecrit] SDO Coordination Workshop (Washington,D.C.): Remote participation information (dial-up/conference call #)

The USDOT, via ITS America, has the following Call-In number for the duration of the workshop:

 

Call:  1-888-409-0010

Participant Code: 1984#  

 

We will have information about video/Pod Cast availability later this evening as we firm up the details.

 

Thanks everyone!

 

Jenny Hansen, Contractor

Project Coordinator NG9-1-1

USDOT/NHTSA

(202) 366-5598

http://www.its.dot.gov/ng911

 

 

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit
--Boundary_(ID_xQyjXQhptS58MWCFvQT2bg)-- --===============1125624465== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1125624465==-- From ecrit-bounces@ietf.org Tue Apr 10 16:05:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbMb5-0001wD-Vq; Tue, 10 Apr 2007 16:05:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbMb5-0001vs-3s for ecrit@ietf.org; Tue, 10 Apr 2007 16:05:47 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbMb2-0005KK-8U for ecrit@ietf.org; Tue, 10 Apr 2007 16:05:47 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3AK5fuK026066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 10 Apr 2007 16:05:44 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <2148EBA7-F442-43CE-BB62-5AD0B18BCFE9@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Henning Schulzrinne Date: Tue, 10 Apr 2007 16:06:41 -0400 X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Ecrit] LoST civic caching issue X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org During our implementation of caching in LoST, one of my students came up with the following interesting issue: Suppose that a system has cached a mapping for city=New York, state=NY and somebody moves the client to a place within that region that has its own mapping, e.g., a college campus. (Similar issues arise for places where a county has one mapping, with some part, e.g., the incorporated area, having a more specific mapping.) In those cases, a client would notice that the address has changed, but it still matches the old mapping, so it will not re-query. A related problem occurs if, during a failure, a default response has been returned. For geo coordinates, 'donuts' and other ways to express 'all but this area' conditions, which would trigger re-querying. This doesn't work for civic coordinates, obviously. There seem to be several possibilities: (1) Don't do that. In other words, if an area knows that there are more specific mappings, it has to be split up in some way, e.g., by enumerating all such areas explicitly. For example, for the unincorporated areas, the community name is part of the mapping, even though they all share the same county-wide mapping. This probably works for most cases, but fails for the campus example, since the surrounding city doesn't really know about these. (2) Mark such cases as non-cacheable. Since civic coordinates are only used for stationary and nomadic devices, the additional query load is rather modest. This is the safe approach. (3) As a compromise between (1) and (2), mark mappings that are known to be leaf nodes. For example, a campus could mark its mapping as such since it can be pretty sure that there's nothing below that level. That way, laptops moving within a building don't have to requery. These could simply be marked as cacheable, so that no additional XML tags are needed. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 11 08:27:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbbv6-0004IJ-2m; Wed, 11 Apr 2007 08:27:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbbv5-0004IB-Be for ecrit@ietf.org; Wed, 11 Apr 2007 08:27:27 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbbv0-0006GA-0X for ecrit@ietf.org; Wed, 11 Apr 2007 08:27:27 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGC003RC22MPV@usaga01-in.huawei.com> for ecrit@ietf.org; Wed, 11 Apr 2007 05:15:58 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGC002RE22J5C@usaga01-in.huawei.com> for ecrit@ietf.org; Wed, 11 Apr 2007 05:15:58 -0700 (PDT) Date: Wed, 11 Apr 2007 07:14:36 -0500 From: Spencer Dawkins Subject: Re: [Ecrit] SDO Emergency Services Workshop 2007 To: ECRIT Message-id: <345401c77c32$f943af00$6401a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; reply-type=original; charset=iso-8859-1; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: <8F6CBC7005099442AECDB784C9E9D7E7019EBF9B@MCHP7R6A.ww002.siemens.net> X-Spam-Score: 0.5 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi, Hannes, Is it possible for someone to monitor the jabber room from the worksh= op=20 site? I'm only seeing one other participant yesterday, and they were = also=20 remote. We had a couple of questions, like "who is speaking?" and "what slide= are=20 they on?", that we didn't want to interrupt the speaker for, but woul= dn't=20 mind knowing answers to. (and if anyone knows who spoke after 3GPP2 update, that would be one = of MY=20 questions!) Thanks, Spencer ----- Original Message -----=20 =46rom: "Tschofenig, Hannes" To: "Spencer Dawkins" ; "ECRIT" Sent: Monday, April 09, 2007 6:03 AM Subject: AW: [Ecrit] SDO Emergency Services Workshop 2007 Yes. I will update the webpage to distribute information about the di= fferent=20 ways to participate remotely. http://www.emergency-services-coordination.info/2007/ > -----Urspr=FCngliche Nachricht----- > Von: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > Gesendet: Donnerstag, 5. April 2007 16:53 > An: ECRIT > Betreff: Re: [Ecrit] SDO Emergency Services Workshop 2007 > > Hi, Hannes, > > Is there any opportunity for remote participation in this meeting? > > Thanks, > > Spencer > > > > Hi all, > > > > we would like to inform you about the progress of the > preparation of the > > 2nd SDO Emergency Services Workshop hosted by the U.S. > Department of > > Transportation (DOT). The workshop will be held April 10, > 11 & 12, 2007, > > from 8:30 am - 6:00 pm., in the Jefferson Building of the > Library of > > Congress, located at 101 Independence Avenue SE in Washington, D.= C. > > > > Please find updated information at this webpage: > > http://www.emergency-services-coordination.info/2007/ > > > > Best regards, > > > > Jenny Hansen > > Marc Linsner > > Stephen McCann > > Christian Militeau > > Atle Monrad > > Henning Schulzrinne > > Hannes Tschofenig > > Harry Worstell > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 11 09:12:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbccC-0001uM-V5; Wed, 11 Apr 2007 09:12:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbccB-0001ot-Nk for ecrit@ietf.org; Wed, 11 Apr 2007 09:11:59 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbcc9-0008V8-LD for ecrit@ietf.org; Wed, 11 Apr 2007 09:11:59 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 11 Apr 2007 06:11:57 -0700 X-IronPort-AV: i="4.14,395,1170662400"; d="scan'208"; a="134473386:sNHT51047910" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l3BDBvBF001132; Wed, 11 Apr 2007 06:11:57 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l3BDBuEi023583; Wed, 11 Apr 2007 13:11:56 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 06:11:56 -0700 Received: from mlinsnerwxp ([10.21.144.80]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 06:11:54 -0700 From: "Marc Linsner" To: "'Spencer Dawkins'" , "'ECRIT'" Subject: RE: [Ecrit] SDO Emergency Services Workshop 2007 Date: Wed, 11 Apr 2007 09:11:49 -0400 Message-ID: <000601c77c3a$f9e8f610$5090150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <345401c77c32$f943af00$6401a8c0@china.huawei.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd8NN4duIXZPBfHSnWp//LclmxlDwABU8MQ X-OriginalArrivalTime: 11 Apr 2007 13:11:55.0582 (UTC) FILETIME=[FA7D6DE0:01C77C3A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3074; t=1176297117; x=1177161117; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20SDO=20Emergency=20Services=20Workshop=20200 7 |Sender:=20; bh=9cledN+EN2FYkhL9uo7PemMrLPbHI1aBBUHYl/Baths=; b=G2LElAYIKd+Eu6KRGvkpC2ON/jbIlPo/8Hm0pU8Learmsyhzk193eNpdTfutqmS+q2NBBBBq 9+YjC0W6WDg/4MlSctZssAhjMjPwG/kOiGktmpxZpkjEkB1WNdi21g5k; Authentication-Results: sj-dkim-3; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Spencer, Unfortunately, we don't have Internet access from the meeting venue. Various individuals are using evdo on adhoc basis, so jabber isn't = possible from my point of view. Sorry, -Marc-=20 > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 > Sent: Wednesday, April 11, 2007 8:15 AM > To: ECRIT > Subject: Re: [Ecrit] SDO Emergency Services Workshop 2007 >=20 > Hi, Hannes, >=20 > Is it possible for someone to monitor the jabber room from=20 > the workshop site? I'm only seeing one other participant=20 > yesterday, and they were also remote. >=20 > We had a couple of questions, like "who is speaking?" and=20 > "what slide are they on?", that we didn't want to interrupt=20 > the speaker for, but wouldn't mind knowing answers to. >=20 > (and if anyone knows who spoke after 3GPP2 update, that would=20 > be one of MY > questions!) >=20 > Thanks, >=20 > Spencer >=20 > ----- Original Message ----- > From: "Tschofenig, Hannes" > To: "Spencer Dawkins" ; "ECRIT"=20 > > Sent: Monday, April 09, 2007 6:03 AM > Subject: AW: [Ecrit] SDO Emergency Services Workshop 2007 >=20 >=20 > Yes. I will update the webpage to distribute information=20 > about the different=20 > ways to participate remotely. > http://www.emergency-services-coordination.info/2007/ >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > > Gesendet: Donnerstag, 5. April 2007 16:53 > > An: ECRIT > > Betreff: Re: [Ecrit] SDO Emergency Services Workshop 2007 > > > > Hi, Hannes, > > > > Is there any opportunity for remote participation in this meeting? > > > > Thanks, > > > > Spencer > > > > > > > Hi all, > > > > > > we would like to inform you about the progress of the > > preparation of the > > > 2nd SDO Emergency Services Workshop hosted by the U.S. > > Department of > > > Transportation (DOT). The workshop will be held April 10, > > 11 & 12, 2007, > > > from 8:30 am - 6:00 pm., in the Jefferson Building of the > > Library of > > > Congress, located at 101 Independence Avenue SE in=20 > Washington, D.C. > > > > > > Please find updated information at this webpage: > > > http://www.emergency-services-coordination.info/2007/ > > > > > > Best regards, > > > > > > Jenny Hansen > > > Marc Linsner > > > Stephen McCann > > > Christian Militeau > > > Atle Monrad > > > Henning Schulzrinne > > > Hannes Tschofenig > > > Harry Worstell > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > >=20 >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 11 09:38:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbd1k-0006oO-NP; Wed, 11 Apr 2007 09:38:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbd1j-0006o3-D1 for ecrit@ietf.org; Wed, 11 Apr 2007 09:38:23 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbd1a-0007bE-Bg for ecrit@ietf.org; Wed, 11 Apr 2007 09:38:23 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGC006545VPUW@usaga01-in.huawei.com> for ecrit@ietf.org; Wed, 11 Apr 2007 06:38:14 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGC00AX05VMG5@usaga01-in.huawei.com> for ecrit@ietf.org; Wed, 11 Apr 2007 06:38:12 -0700 (PDT) Date: Wed, 11 Apr 2007 08:36:51 -0500 From: Spencer Dawkins Subject: Re: [Ecrit] SDO Emergency Services Workshop 2007 To: 'ECRIT' Message-id: <348601c77c3e$76928980$6401a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; reply-type=original; charset=iso-8859-1; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: <000601c77c3a$f9e8f610$5090150a@amer.cisco.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi, Marc, That's fine - could you ask the speakers to be a bit more careful abo= ut=20 identifying themselves and their presentations? I'm STILL trying to f= igure=20 out who the speaker talking about Qualcomm fleet management is... Thanks, Spencer ----- Original Message -----=20 =46rom: "Marc Linsner" To: "'Spencer Dawkins'" ; "'ECRIT'" Sent: Wednesday, April 11, 2007 8:11 AM Subject: RE: [Ecrit] SDO Emergency Services Workshop 2007 Spencer, Unfortunately, we don't have Internet access from the meeting venue. Various individuals are using evdo on adhoc basis, so jabber isn't po= ssible =66rom my point of view. Sorry, -Marc- > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > Sent: Wednesday, April 11, 2007 8:15 AM > To: ECRIT > Subject: Re: [Ecrit] SDO Emergency Services Workshop 2007 > > Hi, Hannes, > > Is it possible for someone to monitor the jabber room from > the workshop site? I'm only seeing one other participant > yesterday, and they were also remote. > > We had a couple of questions, like "who is speaking?" and > "what slide are they on?", that we didn't want to interrupt > the speaker for, but wouldn't mind knowing answers to. > > (and if anyone knows who spoke after 3GPP2 update, that would > be one of MY > questions!) > > Thanks, > > Spencer > > ----- Original Message ----- > From: "Tschofenig, Hannes" > To: "Spencer Dawkins" ; "ECRIT" > > Sent: Monday, April 09, 2007 6:03 AM > Subject: AW: [Ecrit] SDO Emergency Services Workshop 2007 > > > Yes. I will update the webpage to distribute information > about the different > ways to participate remotely. > http://www.emergency-services-coordination.info/2007/ > > > > -----Urspr=FCngliche Nachricht----- > > Von: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > > Gesendet: Donnerstag, 5. April 2007 16:53 > > An: ECRIT > > Betreff: Re: [Ecrit] SDO Emergency Services Workshop 2007 > > > > Hi, Hannes, > > > > Is there any opportunity for remote participation in this meeting= ? > > > > Thanks, > > > > Spencer > > > > > > > Hi all, > > > > > > we would like to inform you about the progress of the > > preparation of the > > > 2nd SDO Emergency Services Workshop hosted by the U.S. > > Department of > > > Transportation (DOT). The workshop will be held April 10, > > 11 & 12, 2007, > > > from 8:30 am - 6:00 pm., in the Jefferson Building of the > > Library of > > > Congress, located at 101 Independence Avenue SE in > Washington, D.C. > > > > > > Please find updated information at this webpage: > > > http://www.emergency-services-coordination.info/2007/ > > > > > > Best regards, > > > > > > Jenny Hansen > > > Marc Linsner > > > Stephen McCann > > > Christian Militeau > > > Atle Monrad > > > Henning Schulzrinne > > > Hannes Tschofenig > > > Harry Worstell > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 11 12:10:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbfOs-0001tp-NZ; Wed, 11 Apr 2007 12:10:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbfOq-0001sh-VB; Wed, 11 Apr 2007 12:10:24 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbfOd-0005Ja-7N; Wed, 11 Apr 2007 12:10:23 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id C1B20201C9; Wed, 11 Apr 2007 12:10:08 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28865-01-6; Wed, 11 Apr 2007 12:10:08 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id B928520821; Wed, 11 Apr 2007 11:11:18 -0400 (EDT) To: "ECRIT" , "Geopriv" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Wed, 11 Apr 2007 11:11:16 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 04/11/2007 11:11:17 AM, Serialize complete at 04/11/2007 11:11:17 AM X-Spam-Score: 0.2 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Joanne McMillen Subject: [Ecrit] TIA TR41.4 comments to NENA, re LLDP-MED and NENA requirements (action from ECRIT/IEEE joint meeting) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0665835046==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============0665835046== Content-Type: multipart/alternative; boundary="=_alternative 00536E17852572BA_=" This is a multipart message in MIME format. --=_alternative 00536E17852572BA_= Content-Type: text/plain; charset="US-ASCII" Hi all, During the IETF-68 ECRIT/IEEE joint meeting, I was asked to pass along the TIA TR41.4 comments to NENA, regarding NENA location-related requirements and how LLDP-MED meets them. These are summarized in the formal liaison sent from TR41.4 to NENA, which can now be accessed via the link below (it was not completed at the time of the meeting). In summary, LLDP-MED meets virtually all applicable NENA requirements well. Some others cannot be realistically met by any method. See NENA response at: http://ftp.tiaonline.org/tr-41/tr41.4/Public/2007-03-Teleconference/TR41.4-07-03-006-M-NENA-LiaisonResponse.pdf Original NENA request at: http://ftp.tiaonline.org/tr-41/tr41.4/Public/2006-08-Montreal/TR41.4-06-08-014-M-NENA-Liaison.doc Please note, I posted this to both ECRIT and Geopriv, on the unlikely chance there are some that lurk on one list but not the other. If there are any comments, please reply to ECRIT only, to keep the noise down. Cheers, Peter Blatherwick --=_alternative 00536E17852572BA_= Content-Type: text/html; charset="US-ASCII"
Hi all,  

During the IETF-68 ECRIT/IEEE joint meeting, I was asked to pass along the TIA TR41.4 comments to NENA, regarding NENA location-related requirements and how LLDP-MED meets them.  These are summarized in the formal liaison sent from TR41.4 to NENA, which can now be accessed via the link below (it was not completed at the time of the meeting).  In summary, LLDP-MED meets virtually all applicable NENA requirements well.  Some others cannot be realistically met by any method.  

See NENA response at:  
    http://ftp.tiaonline.org/tr-41/tr41.4/Public/2007-03-Teleconference/TR41.4-07-03-006-M-NENA-LiaisonResponse.pdf
Original NENA request at:
    http://ftp.tiaonline.org/tr-41/tr41.4/Public/2006-08-Montreal/TR41.4-06-08-014-M-NENA-Liaison.doc

Please note, I posted this to both ECRIT and Geopriv, on the unlikely chance there are some that lurk on one list but not the other.  If there are any comments, please reply to ECRIT only, to keep the noise down.  

Cheers,
Peter Blatherwick
--=_alternative 00536E17852572BA_=-- --===============0665835046== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0665835046==-- From ecrit-bounces@ietf.org Wed Apr 11 20:55:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbnbE-0006pi-4d; Wed, 11 Apr 2007 20:55:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbnbD-0006pd-3a for ecrit@ietf.org; Wed, 11 Apr 2007 20:55:43 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbnbB-0004K2-RN for ecrit@ietf.org; Wed, 11 Apr 2007 20:55:43 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 11 Apr 2007 20:55:41 -0400 id 01588036.461D838D.00007A30 In-Reply-To: <2148EBA7-F442-43CE-BB62-5AD0B18BCFE9@cs.columbia.edu> References: <2148EBA7-F442-43CE-BB62-5AD0B18BCFE9@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7F35FE57-033B-44EB-A89E-5BB74F68A9DE@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] LoST civic caching issue Date: Wed, 11 Apr 2007 20:55:40 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org What about option 4? 4) Any time the civic location changes, including when it becomes more specific or less specific, re-query. Also, I don't know if option 2 holds based on your description. There might be valid reasons to get civic location information on a wireless, that is wifi, link. Or do you count wifi in the nomadic category? -andy On Apr 10, 2007, at 4:06 PM, Henning Schulzrinne wrote: > During our implementation of caching in LoST, one of my students > came up with the following interesting issue: > > Suppose that a system has cached a mapping for city=New York, > state=NY and somebody moves the client to a place within that > region that has its own mapping, e.g., a college campus. (Similar > issues arise for places where a county has one mapping, with some > part, e.g., the incorporated area, having a more specific mapping.) > In those cases, a client would notice that the address has changed, > but it still matches the old mapping, so it will not re-query. > > A related problem occurs if, during a failure, a default response > has been returned. > > For geo coordinates, 'donuts' and other ways to express 'all but > this area' conditions, which would trigger re-querying. This > doesn't work for civic coordinates, obviously. > > There seem to be several possibilities: > > (1) Don't do that. In other words, if an area knows that there are > more specific mappings, it has to be split up in some way, e.g., by > enumerating all such areas explicitly. For example, for the > unincorporated areas, the community name is part of the mapping, > even though they all share the same county-wide mapping. > > This probably works for most cases, but fails for the campus > example, since the surrounding city doesn't really know about these. > > (2) Mark such cases as non-cacheable. Since civic coordinates are > only used for stationary and nomadic devices, the additional query > load is rather modest. This is the safe approach. > > (3) As a compromise between (1) and (2), mark mappings that are > known to be leaf nodes. For example, a campus could mark its > mapping as such since it can be pretty sure that there's nothing > below that level. That way, laptops moving within a building don't > have to requery. These could simply be marked as cacheable, so that > no additional XML tags are needed. > > Henning > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 11 22:45:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbpJP-0006S8-3a; Wed, 11 Apr 2007 22:45:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbpJO-0006RN-5l for ecrit@ietf.org; Wed, 11 Apr 2007 22:45:26 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbpJM-0001Z8-VX for ecrit@ietf.org; Wed, 11 Apr 2007 22:45:26 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3C2jGjD022809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 11 Apr 2007 22:45:19 -0400 (EDT) In-Reply-To: <7F35FE57-033B-44EB-A89E-5BB74F68A9DE@hxr.us> References: <2148EBA7-F442-43CE-BB62-5AD0B18BCFE9@cs.columbia.edu> <7F35FE57-033B-44EB-A89E-5BB74F68A9DE@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <27AA0B42-0F74-42FE-943F-120355EA2229@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST civic caching issue Date: Wed, 11 Apr 2007 22:45:17 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 11, 2007, at 8:55 PM, Andrew Newton wrote: > What about option 4? > 4) Any time the civic location changes, including when it becomes > more specific or less specific, re-query. There are two somewhat separate caching issues: resolver and client caching. In the statement above, which one are you referring to? (Depending on the rules, for resolver caching, you could either run into the same problems I mentioned or never cache at the resolver.) > > Also, I don't know if option 2 holds based on your description. > There might be valid reasons to get civic location information on a > wireless, that is wifi, link. Or do you count wifi in the nomadic > category? > Borderline case. Usually, it's nomadic in that it's of the "open- laptop", "close laptop", "change location" variety characteristic of nomadic activity. I don't think this much matters for the problem at hand. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 12 09:12:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbz6I-0002K8-Ev; Thu, 12 Apr 2007 09:12:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbz6G-0002Jo-Pq for ecrit@ietf.org; Thu, 12 Apr 2007 09:12:32 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbz6C-0002OG-W2 for ecrit@ietf.org; Thu, 12 Apr 2007 09:12:32 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JGD009MQZCSHA@usaga01-in.huawei.com> for ecrit@ietf.org; Thu, 12 Apr 2007 06:12:28 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JGD00KARZCMUG@usaga01-in.huawei.com> for ecrit@ietf.org; Thu, 12 Apr 2007 06:12:28 -0700 (PDT) Date: Thu, 12 Apr 2007 08:10:56 -0500 From: Spencer Dawkins To: ecrit@ietf.org Message-id: <375c01c77d04$033e8a80$6401a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.5 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ecrit] Slides for ESW07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The website at http://www.emergency-services-coordination.info/2007/ does have some slidesets available, but there are still a lot missing, including all the slidesets for the panelists. Is there a chance of seeing the presentations soon? Thanks, Spencer _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 07:18:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcJnV-00031a-0i; Fri, 13 Apr 2007 07:18:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcJnT-00031P-HG; Fri, 13 Apr 2007 07:18:31 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HcJnT-0001WA-8P; Fri, 13 Apr 2007 07:18:31 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns4.neustar.com (Postfix) with ESMTP id 323B12ACA3; Fri, 13 Apr 2007 11:18:01 +0000 (GMT) Received: from stntexch12.cis.neustar.com ([10.31.13.31]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 07:18:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Apr 2007 07:18:00 -0400 Message-ID: <886DD03D15173C43BCE98EA662A0101A01EB70D2@stntexch12.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Not-so-grand compromise on how to do endpoint centric LCP without giving away the store Thread-Index: Acd9eBCfZxIYRVO7QJu63bsxYVEIfw== From: "Rosen, Brian" To: X-OriginalArrivalTime: 13 Apr 2007 11:18:01.0059 (UTC) FILETIME=[659F7B30:01C77DBD] X-Spam-Score: -2.8 (--) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ecrit@ietf.org Subject: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCP without giving away the store X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org In the Emergency Services SDO Coordination workshop, a familiar discussion took place: how does location get provided for emergency calls? The real issue is revenue. Access networks have location. They may be willing to (or may be regulated to be required to) provide location for emergency calls. However, they are not willing to give it away for free for other uses. The issue with that is how we support calling networks that don't have relationships with access networks, i.e. the Skype situation. How is location provided such that a Skype emergency call can be placed, but the access network can restrict what else may be done with the location it provides? We have been wrapped around the axle on this for, dare I say, years. So, I think Barbara Stark first described this, and it needs some work, but suppose that, as an option, an access network could supply: 1. A reference to location 2. The results of a LoST query on the location value (viz, PSAP URI and local dialstring) With this, an endpoint could recognize an emergency call and start routing it to the right PSAP. The LIS would agree to dereference for PSAPs, but could restrict other uses of location. Hannes points out that we need one more thing: the calling network has to be able to validate that the PSAP URI really is a PSAP URI so that charging (emergency calls generally are free) is protected. We need a mechanism for them to do that. =20 Perhaps we include in the LoST return a country code for a query with a geo. We add a new operation to LoST that takes a service, a country code and a PSAP URI and returns yes/no validation ("Yes, that URI is a valid URI for that service in that country"). What would we need to do to make this happen? We need extensions to LCPs or some new protocol that returns an LbyR and the LoST results. I wonder if this is just more HELD work. We need the PSAP URI validation. Again, this is optional. The access network may well give up an LbyV. It may give up an LbyR that it will dereference for the endpoint. The access network may have a relationship with the calling network such that the endpoint need not be involved. The PSAP URI validation is actually useful without this idea, especially when location is an LbyR. Instead of having to have the calling network dereference, and then do a LoST query to validate, it can just do this PSAP URI validation. Would this solve our problem? Would access carriers concerned about revenue issues with "giving away" location to it's subscribers be willing to provide LbyR dereferenceable by PSAPs (again remembering that the access network are local to the PSAPs) as well as LoST query services to their endpoints? Would this address the concerns raised by Deutsche Telecom on this issue? Let me be very clear that I think this is an ugly solution. I think that everyone will be much better off if endpoints knew where they were, and apps could take advantage of that. I think we'll get there. I think tying location configuration with the LoST query is a bad idea. I think using LbyR for emergency calls is a bad idea. But I can live with it. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 10:21:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcMee-000487-O0; Fri, 13 Apr 2007 10:21:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcMed-000480-LB for ecrit@ietf.org; Fri, 13 Apr 2007 10:21:35 -0400 Received: from s-utl01-atpop.stsn.net ([72.254.128.201]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HcMeb-0007lL-Ap for ecrit@ietf.org; Fri, 13 Apr 2007 10:21:35 -0400 Received: from s-utl01-atpop.stsn.net ([127.0.0.1]) by s-utl01-atpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007041310213012201 ; Fri, 13 Apr 2007 10:21:30 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,BAYES_00: -1.665,INFO_TLD: 1.686 X-Spam-Level: Received: from [10.0.76.98] ([10.0.76.98]) by s-utl01-atpop.stsn.net; Fri, 13 Apr 2007 10:21:29 -0400 Message-ID: <461F91DE.4020900@gmx.net> Date: Fri, 13 Apr 2007 16:21:18 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Spencer Dawkins Subject: Re: [Ecrit] Slides for ESW07 References: <375c01c77d04$033e8a80$6401a8c0@china.huawei.com> In-Reply-To: <375c01c77d04$033e8a80$6401a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I will upload all slides as soon as possible. Spencer Dawkins wrote: > The website at http://www.emergency-services-coordination.info/2007/ > does have some slidesets available, but there are still a lot missing, > including all the slidesets for the panelists. Is there a chance of > seeing the presentations soon? > > Thanks, > > Spencer > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 10:43:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcMzq-0001z7-Eo; Fri, 13 Apr 2007 10:43:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcMzo-0001yr-U2; Fri, 13 Apr 2007 10:43:28 -0400 Received: from s-utl01-atpop.stsn.net ([72.254.128.201]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HcMzo-0005OX-Is; Fri, 13 Apr 2007 10:43:28 -0400 Received: from s-utl01-atpop.stsn.net ([127.0.0.1]) by s-utl01-atpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007041310432712283 ; Fri, 13 Apr 2007 10:43:27 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.843,BAYES_00: -1.665 X-Spam-Level: Received: from [10.0.76.98] ([10.0.76.98]) by s-utl01-atpop.stsn.net; Fri, 13 Apr 2007 10:43:26 -0400 Message-ID: <461F9703.6040801@gmx.net> Date: Fri, 13 Apr 2007 16:43:15 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Rosen, Brian" Subject: Re: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCP without giving away the store References: <886DD03D15173C43BCE98EA662A0101A01EB70D2@stntexch12.cis.neustar.com> In-Reply-To: <886DD03D15173C43BCE98EA662A0101A01EB70D2@stntexch12.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian, thanks for posting this message. When the end host is provided with LbyV and triggers the LoST lookup and routes the call via its VSP then the VSP (in some circumstances*) might want to verify that the PSAP URI in the message indeed corresponds to a PSAP. The idea that was mentioned a long time ago already was to let the VSP to use the location information for LoST and to compare the result with the content of the message. The main goal here is that the VSP does not need to have a "business" contract to the ASP/ISP. Since there is only a location reference that neither the end host nor the VSP can dereference it is necessary to enhance the existing procedures a bit (as Brian mentioned). I see two ways todo so: a) Enhance LoST b) Enhance the dereferencing protocol In both cases you want to have the LbyR as input and the PSAP URI (and potentially the service number) as output. For (a) you would have to address the LoST query to the LoST server in the ASP/ISP network and the result would be a nomal LoST response. For (b) you would have todo a dereferencing step with an additional parameter for "verify only". The response would be similar to the lookup by the end host -- just the identity that is being used for the lookup would be different. Both approaches are possible and since the VSP has to support both protocols it does not make a big difference which one to use. In both cases you would have to compare the result of the lookup with the content of the message. Ciao Hannes *: It is only necessary when the VSP charges for individual calls or for specific calls (with the given call falling into this category). Rosen, Brian wrote: > In the Emergency Services SDO Coordination workshop, a familiar > discussion took place: how does location get provided for emergency > calls? The real issue is revenue. Access networks have location. They > may be willing to (or may be regulated to be required to) provide > location for emergency calls. However, they are not willing to give it > away for free for other uses. The issue with that is how we support > calling networks that don't have relationships with access networks, > i.e. the Skype situation. How is location provided such that a Skype > emergency call can be placed, but the access network can restrict what > else may be done with the location it provides? > > We have been wrapped around the axle on this for, dare I say, years. > > So, I think Barbara Stark first described this, and it needs some work, > but suppose that, as an option, an access network could supply: > > 1. A reference to location > > 2. The results of a LoST query on the location value (viz, PSAP URI and > local dialstring) > > With this, an endpoint could recognize an emergency call and start > routing it to the right PSAP. The LIS would agree to dereference for > PSAPs, but could restrict other uses of location. > > Hannes points out that we need one more thing: the calling network has > to be able to validate that the PSAP URI really is a PSAP URI so that > charging (emergency calls generally are free) is protected. We need a > mechanism for them to do that. > > Perhaps we include in the LoST return a country code for a query with a > geo. We add a new operation to LoST that takes a service, a country > code and a PSAP URI and returns yes/no validation ("Yes, that URI is a > valid URI for that service in that country"). > > What would we need to do to make this happen? > > We need extensions to LCPs or some new protocol that returns an LbyR and > the LoST results. I wonder if this is just more HELD work. > > We need the PSAP URI validation. > > Again, this is optional. The access network may well give up an LbyV. > It may give up an LbyR that it will dereference for the endpoint. The > access network may have a relationship with the calling network such > that the endpoint need not be involved. > > The PSAP URI validation is actually useful without this idea, especially > when location is an LbyR. Instead of having to have the calling network > dereference, and then do a LoST query to validate, it can just do this > PSAP URI validation. > > Would this solve our problem? Would access carriers concerned about > revenue issues with "giving away" location to it's subscribers be > willing to provide LbyR dereferenceable by PSAPs (again remembering that > the access network are local to the PSAPs) as well as LoST query > services to their endpoints? Would this address the concerns raised by > Deutsche Telecom on this issue? > > Let me be very clear that I think this is an ugly solution. I think > that everyone will be much better off if endpoints knew where they were, > and apps could take advantage of that. I think we'll get there. I > think tying location configuration with the LoST query is a bad idea. I > think using LbyR for emergency calls is a bad idea. > > But I can live with it. > > Brian > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 10:45:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcN25-0002mP-A2; Fri, 13 Apr 2007 10:45:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcN23-0002lE-Ra; Fri, 13 Apr 2007 10:45:47 -0400 Received: from s-utl01-atpop.stsn.net ([72.254.128.201]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HcN23-0005sy-J4; Fri, 13 Apr 2007 10:45:47 -0400 Received: from s-utl01-atpop.stsn.net ([127.0.0.1]) by s-utl01-atpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007041310454212292 ; Fri, 13 Apr 2007 10:45:42 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.421,BAYES_00: -1.665 X-Spam-Level: Received: from [10.0.76.98] ([10.0.76.98]) by s-utl01-atpop.stsn.net; Fri, 13 Apr 2007 10:45:41 -0400 Message-ID: <461F978B.5090102@gmx.net> Date: Fri, 13 Apr 2007 16:45:31 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Alexander Mayrhofer References: <8BC845943058D844ABFC73D2220D4665064BCBD0@nics-mail.sbg.nic.at> In-Reply-To: <8BC845943058D844ABFC73D2220D4665064BCBD0@nics-mail.sbg.nic.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: geopriv@ietf.org, "Rosen, Brian" , ecrit@ietf.org Subject: [Ecrit] Re: [Geopriv] Not-so-grand compromise on how to do endpoint centric LCPwithout giving away the store X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Alex, That's certainly an option. However, since many folks argued that they need location-by-reference anyway I wonder whether we can avoid signing & encrypting of location information. (You need signing as well to have the other security properties we are looking at.) In some sense an encrypted message is very similar to a location-by-reference to the end host -- it is opaque. There is, however, the problem of provisioning the keys to the PSAPs. When we also consider the case of location based applications that are also in scope of GEOPRIV then this approach will obviously not work. So, the main question therefore is: Do we see a problem with the dereferencing step to resolve the reference to location information? So far, I haven't had the impression. This mechanism would only be justified in cases if there is a network connectivity problem between the Location Recipient and the LIS but not between the Target and the Location Recipient. Ciao Hannes Alexander Mayrhofer wrote: >> So, I think Barbara Stark first described this, and it needs >> some work, >> but suppose that, as an option, an access network could supply: >> >> 1. A reference to location >> >> 2. The results of a LoST query on the location value (viz, >> PSAP URI and >> local dialstring) >> > > Hi, > > Without wanting to stir anything up (and, granted, without having > followed the discussion very closely), a third option comes to my mind: > > Location-by-value, encrypted by the access network with a public key > corresponding to the desired application of the location data? > > eg. for emergency services: > > - PSAPs supply a public key for location encryption within their > coverage area (would need to be one key per area, though) > - Access providers serving a certain area would encrypt location > information with that key > - Location information could be decrypted only by the PSAPs which the > corresponding private key > > (hence, would be useless for Joe's Pizza Delivery Services, or favourite name here>'s location advertisement service) > > I would definitely like to avoid any overengineering here, though - that > is just a very rough idea i would like to share. Especially for > emergency services though, i am a little scared about information not > readable in case of catastrophic situations (imagining the frustration > of a PSAP agent looking at an encrypted location while handling the > call...) > > any comments appreciated (including flames :). > > Alex > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 10:52:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcN84-0006z1-8A; Fri, 13 Apr 2007 10:52:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcN83-0006yo-0v; Fri, 13 Apr 2007 10:51:59 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcN82-0007Ax-Jv; Fri, 13 Apr 2007 10:51:59 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns1.neustar.com (Postfix) with ESMTP id 72B9526E39; Fri, 13 Apr 2007 14:51:58 +0000 (GMT) Received: from stntexch12.cis.neustar.com ([10.31.13.31]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 10:51:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCP without giving away the store Date: Fri, 13 Apr 2007 10:51:56 -0400 Message-ID: <886DD03D15173C43BCE98EA662A0101A01EB7175@stntexch12.cis.neustar.com> In-Reply-To: <461F9703.6040801@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCP without giving away the store Thread-Index: Acd92hnIXxuxOuurRO+eaZhfNXK0pwAAFaBQ From: "Rosen, Brian" To: "Hannes Tschofenig" X-OriginalArrivalTime: 13 Apr 2007 14:51:58.0418 (UTC) FILETIME=[49490320:01C77DDB] X-Spam-Score: -2.8 (--) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes I am confused by your message. The problem you describe, where a VSP is trying to validate that the Request URI in what is claimed to be an emergency call is a bona fide PSAP URI seems to be a valid concern. My message described one way to do this validation when what the VSP received (in a SIP Geolocation header) is an LbyR. Are you now wondering how you validate when you have an LbyV? I would think you do the same thing: send the country code (or the whole location) and the PSAP URI to LoST and ask if the PSAP URI is valid. This does not require any query by the VSP to the ASP/ISP. The VSP should be able to query its local LoST server and be referred to the authoritative server for the location it proffers. I'd rather not have to have the VSP try to dereference an LbyR, and if you have an LbyV then you don't even know, necessarily, who the ASP/ISP is. Is there something else I'm missing here? Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Friday, April 13, 2007 10:43 AM > To: Rosen, Brian > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: Re: [Ecrit] Not-so-grand compromise on how to do endpoint centric > LCP without giving away the store >=20 > Hi Brian, >=20 > thanks for posting this message. >=20 > When the end host is provided with LbyV and triggers the LoST lookup and > routes the call via its VSP then the VSP (in some circumstances*) might > want to verify that the PSAP URI in the message indeed corresponds to a > PSAP. The idea that was mentioned a long time ago already was to let the > VSP to use the location information for LoST and to compare the result > with the content of the message. >=20 > The main goal here is that the VSP does not need to have a "business" > contract to the ASP/ISP. >=20 > Since there is only a location reference that neither the end host nor > the VSP can dereference it is necessary to enhance the existing > procedures a bit (as Brian mentioned). >=20 > I see two ways todo so: >=20 > a) Enhance LoST > b) Enhance the dereferencing protocol >=20 > In both cases you want to have the LbyR as input and the PSAP URI (and > potentially the service number) as output. >=20 > For (a) you would have to address the LoST query to the LoST server in > the ASP/ISP network and the result would be a nomal LoST response. > For (b) you would have todo a dereferencing step with an additional > parameter for "verify only". The response would be similar to the lookup > by the end host -- just the identity that is being used for the lookup > would be different. >=20 > Both approaches are possible and since the VSP has to support both > protocols it does not make a big difference which one to use. >=20 > In both cases you would have to compare the result of the lookup with > the content of the message. >=20 > Ciao > Hannes >=20 > *: It is only necessary when the VSP charges for individual calls or for > specific calls (with the given call falling into this category). >=20 > Rosen, Brian wrote: > > In the Emergency Services SDO Coordination workshop, a familiar > > discussion took place: how does location get provided for emergency > > calls? The real issue is revenue. Access networks have location. They > > may be willing to (or may be regulated to be required to) provide > > location for emergency calls. However, they are not willing to give it > > away for free for other uses. The issue with that is how we support > > calling networks that don't have relationships with access networks, > > i.e. the Skype situation. How is location provided such that a Skype > > emergency call can be placed, but the access network can restrict what > > else may be done with the location it provides? > > > > We have been wrapped around the axle on this for, dare I say, years. > > > > So, I think Barbara Stark first described this, and it needs some work, > > but suppose that, as an option, an access network could supply: > > > > 1. A reference to location > > > > 2. The results of a LoST query on the location value (viz, PSAP URI and > > local dialstring) > > > > With this, an endpoint could recognize an emergency call and start > > routing it to the right PSAP. The LIS would agree to dereference for > > PSAPs, but could restrict other uses of location. > > > > Hannes points out that we need one more thing: the calling network has > > to be able to validate that the PSAP URI really is a PSAP URI so that > > charging (emergency calls generally are free) is protected. We need a > > mechanism for them to do that. > > > > Perhaps we include in the LoST return a country code for a query with a > > geo. We add a new operation to LoST that takes a service, a country > > code and a PSAP URI and returns yes/no validation ("Yes, that URI is a > > valid URI for that service in that country"). > > > > What would we need to do to make this happen? > > > > We need extensions to LCPs or some new protocol that returns an LbyR and > > the LoST results. I wonder if this is just more HELD work. > > > > We need the PSAP URI validation. > > > > Again, this is optional. The access network may well give up an LbyV. > > It may give up an LbyR that it will dereference for the endpoint. The > > access network may have a relationship with the calling network such > > that the endpoint need not be involved. > > > > The PSAP URI validation is actually useful without this idea, especially > > when location is an LbyR. Instead of having to have the calling network > > dereference, and then do a LoST query to validate, it can just do this > > PSAP URI validation. > > > > Would this solve our problem? Would access carriers concerned about > > revenue issues with "giving away" location to it's subscribers be > > willing to provide LbyR dereferenceable by PSAPs (again remembering that > > the access network are local to the PSAPs) as well as LoST query > > services to their endpoints? Would this address the concerns raised by > > Deutsche Telecom on this issue? > > > > Let me be very clear that I think this is an ugly solution. I think > > that everyone will be much better off if endpoints knew where they were, > > and apps could take advantage of that. I think we'll get there. I > > think tying location configuration with the LoST query is a bad idea. I > > think using LbyR for emergency calls is a bad idea. > > > > But I can live with it. > > > > Brian > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 11:25:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcNet-0004Sw-JW; Fri, 13 Apr 2007 11:25:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcNer-0004S8-Kq; Fri, 13 Apr 2007 11:25:53 -0400 Received: from s-utl02-atpop.stsn.net ([72.254.128.202]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HcNer-0004lT-85; Fri, 13 Apr 2007 11:25:53 -0400 Received: from s-utl02-atpop.stsn.net ([127.0.0.1]) by s-utl02-atpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007041311255110590 ; Fri, 13 Apr 2007 11:25:51 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.843,BAYES_00: -1.665 X-Spam-Level: Received: from [10.0.76.98] ([10.0.76.98]) by s-utl02-atpop.stsn.net; Fri, 13 Apr 2007 11:25:50 -0400 Message-ID: <461FA0F3.6070509@gmx.net> Date: Fri, 13 Apr 2007 17:25:39 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Rosen, Brian" Subject: Re: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCP without giving away the store References: <886DD03D15173C43BCE98EA662A0101A01EB7175@stntexch12.cis.neustar.com> In-Reply-To: <886DD03D15173C43BCE98EA662A0101A01EB7175@stntexch12.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian, I only described a different way of doing the verification without returning a country code. I also focus on LbyR only rather than LbyV. Ciao Hannes Rosen, Brian wrote: > Hannes > > I am confused by your message. > > The problem you describe, where a VSP is trying to validate that the > Request URI in what is claimed to be an emergency call is a bona fide > PSAP URI seems to be a valid concern. My message described one way to > do this validation when what the VSP received (in a SIP Geolocation > header) is an LbyR. > > Are you now wondering how you validate when you have an LbyV? I would > think you do the same thing: send the country code (or the whole > location) and the PSAP URI to LoST and ask if the PSAP URI is valid. > This does not require any query by the VSP to the ASP/ISP. The VSP > should be able to query its local LoST server and be referred to the > authoritative server for the location it proffers. > > I'd rather not have to have the VSP try to dereference an LbyR, and if > you have an LbyV then you don't even know, necessarily, who the ASP/ISP > is. > > Is there something else I'm missing here? > > Brian > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Friday, April 13, 2007 10:43 AM >> To: Rosen, Brian >> Cc: geopriv@ietf.org; ecrit@ietf.org >> Subject: Re: [Ecrit] Not-so-grand compromise on how to do endpoint >> > centric > >> LCP without giving away the store >> >> Hi Brian, >> >> thanks for posting this message. >> >> When the end host is provided with LbyV and triggers the LoST lookup >> > and > >> routes the call via its VSP then the VSP (in some circumstances*) >> > might > >> want to verify that the PSAP URI in the message indeed corresponds to >> > a > >> PSAP. The idea that was mentioned a long time ago already was to let >> > the > >> VSP to use the location information for LoST and to compare the result >> with the content of the message. >> >> The main goal here is that the VSP does not need to have a "business" >> contract to the ASP/ISP. >> >> Since there is only a location reference that neither the end host nor >> the VSP can dereference it is necessary to enhance the existing >> procedures a bit (as Brian mentioned). >> >> I see two ways todo so: >> >> a) Enhance LoST >> b) Enhance the dereferencing protocol >> >> In both cases you want to have the LbyR as input and the PSAP URI (and >> potentially the service number) as output. >> >> For (a) you would have to address the LoST query to the LoST server in >> the ASP/ISP network and the result would be a nomal LoST response. >> For (b) you would have todo a dereferencing step with an additional >> parameter for "verify only". The response would be similar to the >> > lookup > >> by the end host -- just the identity that is being used for the lookup >> would be different. >> >> Both approaches are possible and since the VSP has to support both >> protocols it does not make a big difference which one to use. >> >> In both cases you would have to compare the result of the lookup with >> the content of the message. >> >> Ciao >> Hannes >> >> *: It is only necessary when the VSP charges for individual calls or >> > for > >> specific calls (with the given call falling into this category). >> >> Rosen, Brian wrote: >> >>> In the Emergency Services SDO Coordination workshop, a familiar >>> discussion took place: how does location get provided for emergency >>> calls? The real issue is revenue. Access networks have location. >>> > They > >>> may be willing to (or may be regulated to be required to) provide >>> location for emergency calls. However, they are not willing to give >>> > it > >>> away for free for other uses. The issue with that is how we support >>> calling networks that don't have relationships with access networks, >>> i.e. the Skype situation. How is location provided such that a >>> > Skype > >>> emergency call can be placed, but the access network can restrict >>> > what > >>> else may be done with the location it provides? >>> >>> We have been wrapped around the axle on this for, dare I say, years. >>> >>> So, I think Barbara Stark first described this, and it needs some >>> > work, > >>> but suppose that, as an option, an access network could supply: >>> >>> 1. A reference to location >>> >>> 2. The results of a LoST query on the location value (viz, PSAP URI >>> > and > >>> local dialstring) >>> >>> With this, an endpoint could recognize an emergency call and start >>> routing it to the right PSAP. The LIS would agree to dereference >>> > for > >>> PSAPs, but could restrict other uses of location. >>> >>> Hannes points out that we need one more thing: the calling network >>> > has > >>> to be able to validate that the PSAP URI really is a PSAP URI so >>> > that > >>> charging (emergency calls generally are free) is protected. We need >>> > a > >>> mechanism for them to do that. >>> >>> Perhaps we include in the LoST return a country code for a query >>> > with a > >>> geo. We add a new operation to LoST that takes a service, a country >>> code and a PSAP URI and returns yes/no validation ("Yes, that URI is >>> > a > >>> valid URI for that service in that country"). >>> >>> What would we need to do to make this happen? >>> >>> We need extensions to LCPs or some new protocol that returns an LbyR >>> > and > >>> the LoST results. I wonder if this is just more HELD work. >>> >>> We need the PSAP URI validation. >>> >>> Again, this is optional. The access network may well give up an >>> > LbyV. > >>> It may give up an LbyR that it will dereference for the endpoint. >>> > The > >>> access network may have a relationship with the calling network such >>> that the endpoint need not be involved. >>> >>> The PSAP URI validation is actually useful without this idea, >>> > especially > >>> when location is an LbyR. Instead of having to have the calling >>> > network > >>> dereference, and then do a LoST query to validate, it can just do >>> > this > >>> PSAP URI validation. >>> >>> Would this solve our problem? Would access carriers concerned about >>> revenue issues with "giving away" location to it's subscribers be >>> willing to provide LbyR dereferenceable by PSAPs (again remembering >>> > that > >>> the access network are local to the PSAPs) as well as LoST query >>> services to their endpoints? Would this address the concerns raised >>> > by > >>> Deutsche Telecom on this issue? >>> >>> Let me be very clear that I think this is an ugly solution. I think >>> that everyone will be much better off if endpoints knew where they >>> > were, > >>> and apps could take advantage of that. I think we'll get there. I >>> think tying location configuration with the LoST query is a bad >>> > idea. I > >>> think using LbyR for emergency calls is a bad idea. >>> >>> But I can live with it. >>> >>> Brian >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 12:04:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOGB-0003cC-Nc; Fri, 13 Apr 2007 12:04:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOGB-0003c3-3z; Fri, 13 Apr 2007 12:04:27 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcOGA-0005Sv-F2; Fri, 13 Apr 2007 12:04:27 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HcODe-0003ZM-8V; Fri, 13 Apr 2007 11:01:51 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "Rosen, Brian" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCP without giving away the store Date: Fri, 13 Apr 2007 12:04:19 -0400 Message-ID: <02f401c77de5$678e4bb0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd9363GJ+vjNF8iQ5+wyWbUAZ4LVAAA1AfQ In-Reply-To: <461FA0F3.6070509@gmx.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Huh, I didn't get that. I'd like to eliminate the country code thing, because otherwise we need a way to carry it in the SIP Geolocation. However, I don't really want the VSP having to ask the ASP/ISP for a dereference of any sort, and I'd like to minimize the work of the ASP/ISP. The notion that the ASP/ISP has to help the VSP determine if what it has is a valid PSAP URI strikes me as a problem. Now, you may remember WAAAY WAAY back, I strongly suggested that the geo form of location always include a country code. I suggested this for disputed areas. The access network is in a very good position to tell you how best to interpret which country actually is the on-the-ground administrator of the location. If you are connected to an Israeli access network, and you ask LoST for a PSAP URI, you probably want an Israeli fire brigade. If you are on a Palestinian access network, then you probably want a different answer. So, having country code in a PIDF with an otherwise geo location is actually helpful. The current answer for this is some kind of manual configuration of the LoST servers so you get the answer you want. While that can work, I think something more automatic might work better, and it fixes the problem. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Friday, April 13, 2007 11:26 AM > To: Rosen, Brian > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do > endpoint centric LCP without giving away the store > > Hi Brian, > > I only described a different way of doing the verification without > returning a country code. > I also focus on LbyR only rather than LbyV. > > Ciao > Hannes > > Rosen, Brian wrote: > > Hannes > > > > I am confused by your message. > > > > The problem you describe, where a VSP is trying to validate that the > > Request URI in what is claimed to be an emergency call is a bona fide > > PSAP URI seems to be a valid concern. My message described one way to > > do this validation when what the VSP received (in a SIP Geolocation > > header) is an LbyR. > > > > Are you now wondering how you validate when you have an LbyV? I would > > think you do the same thing: send the country code (or the whole > > location) and the PSAP URI to LoST and ask if the PSAP URI is valid. > > This does not require any query by the VSP to the ASP/ISP. The VSP > > should be able to query its local LoST server and be referred to the > > authoritative server for the location it proffers. > > > > I'd rather not have to have the VSP try to dereference an LbyR, and if > > you have an LbyV then you don't even know, necessarily, who the ASP/ISP > > is. > > > > Is there something else I'm missing here? > > > > Brian > > > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: Friday, April 13, 2007 10:43 AM > >> To: Rosen, Brian > >> Cc: geopriv@ietf.org; ecrit@ietf.org > >> Subject: Re: [Ecrit] Not-so-grand compromise on how to do endpoint > >> > > centric > > > >> LCP without giving away the store > >> > >> Hi Brian, > >> > >> thanks for posting this message. > >> > >> When the end host is provided with LbyV and triggers the LoST lookup > >> > > and > > > >> routes the call via its VSP then the VSP (in some circumstances*) > >> > > might > > > >> want to verify that the PSAP URI in the message indeed corresponds to > >> > > a > > > >> PSAP. The idea that was mentioned a long time ago already was to let > >> > > the > > > >> VSP to use the location information for LoST and to compare the result > >> with the content of the message. > >> > >> The main goal here is that the VSP does not need to have a "business" > >> contract to the ASP/ISP. > >> > >> Since there is only a location reference that neither the end host nor > >> the VSP can dereference it is necessary to enhance the existing > >> procedures a bit (as Brian mentioned). > >> > >> I see two ways todo so: > >> > >> a) Enhance LoST > >> b) Enhance the dereferencing protocol > >> > >> In both cases you want to have the LbyR as input and the PSAP URI (and > >> potentially the service number) as output. > >> > >> For (a) you would have to address the LoST query to the LoST server in > >> the ASP/ISP network and the result would be a nomal LoST response. > >> For (b) you would have todo a dereferencing step with an additional > >> parameter for "verify only". The response would be similar to the > >> > > lookup > > > >> by the end host -- just the identity that is being used for the lookup > >> would be different. > >> > >> Both approaches are possible and since the VSP has to support both > >> protocols it does not make a big difference which one to use. > >> > >> In both cases you would have to compare the result of the lookup with > >> the content of the message. > >> > >> Ciao > >> Hannes > >> > >> *: It is only necessary when the VSP charges for individual calls or > >> > > for > > > >> specific calls (with the given call falling into this category). > >> > >> Rosen, Brian wrote: > >> > >>> In the Emergency Services SDO Coordination workshop, a familiar > >>> discussion took place: how does location get provided for emergency > >>> calls? The real issue is revenue. Access networks have location. > >>> > > They > > > >>> may be willing to (or may be regulated to be required to) provide > >>> location for emergency calls. However, they are not willing to give > >>> > > it > > > >>> away for free for other uses. The issue with that is how we support > >>> calling networks that don't have relationships with access networks, > >>> i.e. the Skype situation. How is location provided such that a > >>> > > Skype > > > >>> emergency call can be placed, but the access network can restrict > >>> > > what > > > >>> else may be done with the location it provides? > >>> > >>> We have been wrapped around the axle on this for, dare I say, years. > >>> > >>> So, I think Barbara Stark first described this, and it needs some > >>> > > work, > > > >>> but suppose that, as an option, an access network could supply: > >>> > >>> 1. A reference to location > >>> > >>> 2. The results of a LoST query on the location value (viz, PSAP URI > >>> > > and > > > >>> local dialstring) > >>> > >>> With this, an endpoint could recognize an emergency call and start > >>> routing it to the right PSAP. The LIS would agree to dereference > >>> > > for > > > >>> PSAPs, but could restrict other uses of location. > >>> > >>> Hannes points out that we need one more thing: the calling network > >>> > > has > > > >>> to be able to validate that the PSAP URI really is a PSAP URI so > >>> > > that > > > >>> charging (emergency calls generally are free) is protected. We need > >>> > > a > > > >>> mechanism for them to do that. > >>> > >>> Perhaps we include in the LoST return a country code for a query > >>> > > with a > > > >>> geo. We add a new operation to LoST that takes a service, a country > >>> code and a PSAP URI and returns yes/no validation ("Yes, that URI is > >>> > > a > > > >>> valid URI for that service in that country"). > >>> > >>> What would we need to do to make this happen? > >>> > >>> We need extensions to LCPs or some new protocol that returns an LbyR > >>> > > and > > > >>> the LoST results. I wonder if this is just more HELD work. > >>> > >>> We need the PSAP URI validation. > >>> > >>> Again, this is optional. The access network may well give up an > >>> > > LbyV. > > > >>> It may give up an LbyR that it will dereference for the endpoint. > >>> > > The > > > >>> access network may have a relationship with the calling network such > >>> that the endpoint need not be involved. > >>> > >>> The PSAP URI validation is actually useful without this idea, > >>> > > especially > > > >>> when location is an LbyR. Instead of having to have the calling > >>> > > network > > > >>> dereference, and then do a LoST query to validate, it can just do > >>> > > this > > > >>> PSAP URI validation. > >>> > >>> Would this solve our problem? Would access carriers concerned about > >>> revenue issues with "giving away" location to it's subscribers be > >>> willing to provide LbyR dereferenceable by PSAPs (again remembering > >>> > > that > > > >>> the access network are local to the PSAPs) as well as LoST query > >>> services to their endpoints? Would this address the concerns raised > >>> > > by > > > >>> Deutsche Telecom on this issue? > >>> > >>> Let me be very clear that I think this is an ugly solution. I think > >>> that everyone will be much better off if endpoints knew where they > >>> > > were, > > > >>> and apps could take advantage of that. I think we'll get there. I > >>> think tying location configuration with the LoST query is a bad > >>> > > idea. I > > > >>> think using LbyR for emergency calls is a bad idea. > >>> > >>> But I can live with it. > >>> > >>> Brian > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/ecrit > >>> > >>> > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 12:44:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOtK-0007fr-Tm; Fri, 13 Apr 2007 12:44:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOtJ-0007d2-JK; Fri, 13 Apr 2007 12:44:53 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcOtJ-0002af-67; Fri, 13 Apr 2007 12:44:53 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HcOtI-0006Qh-4V; Fri, 13 Apr 2007 12:44:52 -0400 Received: from [127.0.0.1] (ros-dhcp233-050-233.bbn.com [192.233.50.233]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l3DGipw04800; Fri, 13 Apr 2007 12:44:51 -0400 (EDT) Message-ID: <461FB382.1010908@bbn.com> Date: Fri, 13 Apr 2007 12:44:50 -0400 From: Richard Barnes User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Rosen, Brian" Subject: Re: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCP without giving away the store References: <886DD03D15173C43BCE98EA662A0101A01EB70D2@stntexch12.cis.neustar.com> In-Reply-To: <886DD03D15173C43BCE98EA662A0101A01EB70D2@stntexch12.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, I think that you're right that provision of location by reference is a use case we need to support. URI validation will be useful in either case (LbyR or LbyV), and it seems like a natural extension to make to LoST: Validating that a given URI is a PSAP URI is like a reverse DNS lookup. Normal DNS queries map names->addresses (A+ records); reverse DNS queries map addresses to names (*PTR records). Likewise, LoST queries map locations (+service URNs) to URIs; a "reverse LoST" query could map a URI to a service area and a service URN. There's probably even simpler approaches, maybe via some form of NAPTR or ENUM lookup. As far as getting the endpoint the results of a LoST query based on an LbyR: Your suggestion is good, but it has the problem that the access network doesn't really know what to fill in for the element of the LoST query. It could request all of the services available, but that would require a second LoST request. I would suggest that a more elegant solution (and one that deals better with the "unknown " problem) would be to extend LoST to handle location by reference. It wouldn't be a complicated change to LoST, just another location profile. Realizing that this has been discussed in the past, I scanned through the archive and found two main arguments against LoST doing LbyR: 1. Dereference access control In order to do the LoST lookup, a LoST server would have to be allowed to dereference the location reference. Given that most of the LoST infrastructure (e.g. the trees) is pretty static, it doesn't seem difficult to provide authentication credentials for LoST servers and require that they be able to dereference (just like PSAPs). 2. Extra time/complication It's correct that it would not be feasible for every LoST server involved in an LbyR-based query to dereference the location reference. However, this can be avoided if the resolver doing the recursive queries is allowed to do a dereference, since it can then just include the location by value in subsequent queries. This may cover most cases, e.g., if a local LoST resolver is provided by the access network (as is often the case with DNS). There's a lot of overlap between LoST/LbyR and what you propose. If the access network provides a resolver, then the two are essentially the same, except that if LoST/LbyR is used, then the client sends an extra query. However, extending LoST seems to maintain a better separation of the location configuration and mapping functions. Humbly submitted, --Richard Rosen, Brian wrote: > In the Emergency Services SDO Coordination workshop, a familiar > discussion took place: how does location get provided for emergency > calls? The real issue is revenue. Access networks have location. They > may be willing to (or may be regulated to be required to) provide > location for emergency calls. However, they are not willing to give it > away for free for other uses. The issue with that is how we support > calling networks that don't have relationships with access networks, > i.e. the Skype situation. How is location provided such that a Skype > emergency call can be placed, but the access network can restrict what > else may be done with the location it provides? > > We have been wrapped around the axle on this for, dare I say, years. > > So, I think Barbara Stark first described this, and it needs some work, > but suppose that, as an option, an access network could supply: > > 1. A reference to location > > 2. The results of a LoST query on the location value (viz, PSAP URI and > local dialstring) > > With this, an endpoint could recognize an emergency call and start > routing it to the right PSAP. The LIS would agree to dereference for > PSAPs, but could restrict other uses of location. > > Hannes points out that we need one more thing: the calling network has > to be able to validate that the PSAP URI really is a PSAP URI so that > charging (emergency calls generally are free) is protected. We need a > mechanism for them to do that. > > Perhaps we include in the LoST return a country code for a query with a > geo. We add a new operation to LoST that takes a service, a country > code and a PSAP URI and returns yes/no validation ("Yes, that URI is a > valid URI for that service in that country"). > > What would we need to do to make this happen? > > We need extensions to LCPs or some new protocol that returns an LbyR and > the LoST results. I wonder if this is just more HELD work. > > We need the PSAP URI validation. > > Again, this is optional. The access network may well give up an LbyV. > It may give up an LbyR that it will dereference for the endpoint. The > access network may have a relationship with the calling network such > that the endpoint need not be involved. > > The PSAP URI validation is actually useful without this idea, especially > when location is an LbyR. Instead of having to have the calling network > dereference, and then do a LoST query to validate, it can just do this > PSAP URI validation. > > Would this solve our problem? Would access carriers concerned about > revenue issues with "giving away" location to it's subscribers be > willing to provide LbyR dereferenceable by PSAPs (again remembering that > the access network are local to the PSAPs) as well as LoST query > services to their endpoints? Would this address the concerns raised by > Deutsche Telecom on this issue? > > Let me be very clear that I think this is an ugly solution. I think > that everyone will be much better off if endpoints knew where they were, > and apps could take advantage of that. I think we'll get there. I > think tying location configuration with the LoST query is a bad idea. I > think using LbyR for emergency calls is a bad idea. > > But I can live with it. > > Brian > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 12:48:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOxF-0001oa-1i; Fri, 13 Apr 2007 12:48:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOxD-0001o8-0h; Fri, 13 Apr 2007 12:48:55 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcOxB-0004Pl-LZ; Fri, 13 Apr 2007 12:48:54 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Fri, 13 Apr 2007 18:48:51 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 18:48:50 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCPwithout giving away the store Date: Fri, 13 Apr 2007 18:48:48 +0200 Message-Id: <182C63BFBAF131428EA0C16F7FD2191B013584AB@S4DE8PSAAGM.mitte.t-com.de> In-reply-to: <886DD03D15173C43BCE98EA662A0101A01EB70D2@stntexch12.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCPwithout giving away the store Thread-Index: Acd9eBCfZxIYRVO7QJu63bsxYVEIfwAa+3KA From: "Liess, Laura" To: , X-OriginalArrivalTime: 13 Apr 2007 16:48:50.0638 (UTC) FILETIME=[9CE4DEE0:01C77DEB] X-Spam-Score: 0.5 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, Hannes, thank you for bringing up this issue.=20 In principle, I like the option for the access network to supply the = PSAP URI. A similar option could be for the AN to provide an ESRP URI. = The ESRP URI is for the AN a trusted party, so it has the necessary = credentials to fetch the Location Info from the LIS.=20 I figured out how such a scenario could work Configuration VSP's LoST Alice Servers SIP proxy ESRP Servers = PSAP ***Alice gets IP-connectivity**** =20 [M1] DHCP (with LbyR, country code and ESRP URI) <--------- ***Some time later, Alice dials/initiates emergency call*** [M2] INVITE (sos URN or 911/112, contains LbyR, country code and = ESRP URI) -------------------------------> [M3] LoST Query (contains country code = and ESRP URI) ---------------------------> [M4] LoST Response (contains a mark if = ESRP URI is valid) <---------------------------- [M5] INVITE (sos URN or 911/112, = contains LbyR) -------------> [M6] HTTPS(contains LbyR) <---------------------------------- [M7] HTTPS(contains Location) ---------------------------------> [M8] LoST Query = (contains Location) = ---------------------> [M9] LoST Response (contains PSAP = URI)=20 = <---------------------- [M10] INVITE (contains = Location) = -----------------------------------> 200 OK = <------------------------------------------------------------------------= ------- ACK = -------------------------------------------------------------------------= ------> I think if there is a local ESRP between the VSP's SIP Proxy and the = PSAP we are more flexible to comply to country-specific regulations.=20 The ESRP could choose the PSAP based on a local LoST server which knows = the capabilities of the local PSAPs. E.g. during a transition period we = may have the old PSTN PSAPs and very few IP PSAPs with additional = capabilities, e. g. emergency call takers speaking foreign languages or = emergency call takers for deaf people. The local LoST server would be = able to choose the right PSAP (this is just an idea, I don't know = whether or not it's realistic).=20 Thanks Laura =20 =20 =20 > -----Urspr=FCngliche Nachricht----- > Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 > Gesendet: Freitag, 13. April 2007 13:18 > An: geopriv@ietf.org > Cc: ecrit@ietf.org > Betreff: [Ecrit] Not-so-grand compromise on how to do=20 > endpoint centric LCPwithout giving away the store >=20 >=20 > In the Emergency Services SDO Coordination workshop, a=20 > familiar discussion took place: how does location get=20 > provided for emergency calls? The real issue is revenue. =20 > Access networks have location. They may be willing to (or=20 > may be regulated to be required to) provide location for=20 > emergency calls. However, they are not willing to give it=20 > away for free for other uses. The issue with that is how we=20 > support calling networks that don't have relationships with=20 > access networks, i.e. the Skype situation. How is location=20 > provided such that a Skype emergency call can be placed, but=20 > the access network can restrict what else may be done with=20 > the location it provides? >=20 > We have been wrapped around the axle on this for, dare I say, years. >=20 > So, I think Barbara Stark first described this, and it needs=20 > some work, but suppose that, as an option, an access network=20 > could supply: >=20 > 1. A reference to location >=20 > 2. The results of a LoST query on the location value (viz,=20 > PSAP URI and local dialstring) >=20 > With this, an endpoint could recognize an emergency call and=20 > start routing it to the right PSAP. The LIS would agree to=20 > dereference for PSAPs, but could restrict other uses of location. >=20 > Hannes points out that we need one more thing: the calling=20 > network has to be able to validate that the PSAP URI really=20 > is a PSAP URI so that charging (emergency calls generally are=20 > free) is protected. We need a mechanism for them to do that. =20 >=20 > Perhaps we include in the LoST return a country code for a=20 > query with a geo. We add a new operation to LoST that takes=20 > a service, a country code and a PSAP URI and returns yes/no=20 > validation ("Yes, that URI is a valid URI for that service in=20 > that country"). >=20 > What would we need to do to make this happen? >=20 > We need extensions to LCPs or some new protocol that returns=20 > an LbyR and the LoST results. I wonder if this is just more=20 > HELD work. >=20 > We need the PSAP URI validation. >=20 > Again, this is optional. The access network may well give up=20 > an LbyV. It may give up an LbyR that it will dereference for=20 > the endpoint. The access network may have a relationship=20 > with the calling network such that the endpoint need not be involved. >=20 > The PSAP URI validation is actually useful without this idea,=20 > especially when location is an LbyR. Instead of having to=20 > have the calling network dereference, and then do a LoST=20 > query to validate, it can just do this PSAP URI validation. >=20 > Would this solve our problem? Would access carriers=20 > concerned about revenue issues with "giving away" location to=20 > it's subscribers be willing to provide LbyR dereferenceable=20 > by PSAPs (again remembering that the access network are local=20 > to the PSAPs) as well as LoST query services to their=20 > endpoints? Would this address the concerns raised by=20 > Deutsche Telecom on this issue? >=20 > Let me be very clear that I think this is an ugly solution. =20 > I think that everyone will be much better off if endpoints=20 > knew where they were, and apps could take advantage of that. =20 > I think we'll get there. I think tying location=20 > configuration with the LoST query is a bad idea. I think=20 > using LbyR for emergency calls is a bad idea. >=20 > But I can live with it. >=20 > Brian >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 13:22:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPUA-0006kQ-Pt; Fri, 13 Apr 2007 13:22:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPU9-0006kI-TN; Fri, 13 Apr 2007 13:22:57 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcPU9-00039z-IC; Fri, 13 Apr 2007 13:22:57 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Apr 2007 13:22:57 -0400 X-IronPort-AV: i="4.14,408,1170651600"; d="scan'208"; a="118476945:sNHT53215264" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3DHMvCh016543; Fri, 13 Apr 2007 13:22:57 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3DHMmlW022472; Fri, 13 Apr 2007 17:22:57 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 13:22:55 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 13:22:54 -0400 From: "Marc Linsner" To: "'Rosen, Brian'" , Subject: RE: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCPwithout giving away the store Date: Fri, 13 Apr 2007 13:22:52 -0400 Message-ID: <000001c77df0$5f1a9870$42aa520a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acd9eBCfZxIYRVO7QJu63bsxYVEIfwAd6vQw In-Reply-To: <886DD03D15173C43BCE98EA662A0101A01EB70D2@stntexch12.cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 13 Apr 2007 17:22:54.0612 (UTC) FILETIME=[5F328D40:01C77DF0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4005; t=1176484977; x=1177348977; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20Not-so-grand=20compromise=20on=20how=20to=2 0do=20endpoint=20centric=20LCPwithout=20giving=20away=20the=20store |Sender:=20 |To:=20=22'Rosen, =20Brian'=22=20, =20; bh=7crV3yq6CrI/2HVmi7slOyhzbarsq0Kw78MeLI0+bYs=; b=gEiTjQnKuVavSnoxgFglr2u8N/Aaw9ISwE/VSnsXxL6Sn7DYOlEXIOMZB9VieExuUcKgKof4 BofXmrOPoxLqOoiWiOesx/GfMpIie007ccChKVcy1tZlITqAsgrY9CPo; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Who is responsible for PSAP mis-routes? I would think this transfers liability for routing to the access-provider, are they willing to step up to that? -Marc- > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Friday, April 13, 2007 7:18 AM > To: geopriv@ietf.org > Cc: ecrit@ietf.org > Subject: [Ecrit] Not-so-grand compromise on how to do > endpoint centric LCPwithout giving away the store > > In the Emergency Services SDO Coordination workshop, a > familiar discussion took place: how does location get > provided for emergency calls? The real issue is revenue. > Access networks have location. They may be willing to (or > may be regulated to be required to) provide location for > emergency calls. However, they are not willing to give it > away for free for other uses. The issue with that is how we > support calling networks that don't have relationships with > access networks, i.e. the Skype situation. How is location > provided such that a Skype emergency call can be placed, but > the access network can restrict what else may be done with > the location it provides? > > We have been wrapped around the axle on this for, dare I say, years. > > So, I think Barbara Stark first described this, and it needs > some work, but suppose that, as an option, an access network > could supply: > > 1. A reference to location > > 2. The results of a LoST query on the location value (viz, > PSAP URI and local dialstring) > > With this, an endpoint could recognize an emergency call and > start routing it to the right PSAP. The LIS would agree to > dereference for PSAPs, but could restrict other uses of location. > > Hannes points out that we need one more thing: the calling > network has to be able to validate that the PSAP URI really > is a PSAP URI so that charging (emergency calls generally are > free) is protected. We need a mechanism for them to do that. > > Perhaps we include in the LoST return a country code for a > query with a geo. We add a new operation to LoST that takes > a service, a country code and a PSAP URI and returns yes/no > validation ("Yes, that URI is a valid URI for that service in > that country"). > > What would we need to do to make this happen? > > We need extensions to LCPs or some new protocol that returns > an LbyR and the LoST results. I wonder if this is just more > HELD work. > > We need the PSAP URI validation. > > Again, this is optional. The access network may well give up an LbyV. > It may give up an LbyR that it will dereference for the > endpoint. The access network may have a relationship with > the calling network such that the endpoint need not be involved. > > The PSAP URI validation is actually useful without this idea, > especially when location is an LbyR. Instead of having to > have the calling network dereference, and then do a LoST > query to validate, it can just do this PSAP URI validation. > > Would this solve our problem? Would access carriers > concerned about revenue issues with "giving away" location to > it's subscribers be willing to provide LbyR dereferenceable > by PSAPs (again remembering that the access network are local > to the PSAPs) as well as LoST query services to their > endpoints? Would this address the concerns raised by > Deutsche Telecom on this issue? > > Let me be very clear that I think this is an ugly solution. > I think that everyone will be much better off if endpoints > knew where they were, and apps could take advantage of that. > I think we'll get there. I think tying location > configuration with the LoST query is a bad idea. I think > using LbyR for emergency calls is a bad idea. > > But I can live with it. > > Brian > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 14:02:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcQ6a-0007fo-Ao; Fri, 13 Apr 2007 14:02:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcQ6Z-0007ff-M6; Fri, 13 Apr 2007 14:02:39 -0400 Received: from [206.173.41.176] (helo=sea-mimesweep-1.telecomsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcQ6Y-0001KL-VC; Fri, 13 Apr 2007 14:02:39 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Fri, 13 Apr 2007 11:02:37 -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 Subject: RE: [Ecrit] Not-so-grand compromise on how to do endpoint centricLCP without giving away the store Date: Fri, 13 Apr 2007 10:58:17 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657507358133@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <461FB382.1010908@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Not-so-grand compromise on how to do endpoint centricLCP without giving away the store Thread-Index: Acd96xIxXNwnNW5eQ0WPFPugVIhi4wABpCgg References: <886DD03D15173C43BCE98EA662A0101A01EB70D2@stntexch12.cis.neustar.com> <461FB382.1010908@bbn.com> From: "Roger Marshall" To: "Richard Barnes" , "Rosen, Brian" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org 3GPP approaches this in a different way - one which (I think) we could parallel, as shown in the following diagrams: Proposal:=20 - Define a new function which handles location dereferencing and supports lost queries (this seems to me to be somewhat similar to an LRF in 3GPP, since an LRF goes and gets loc + routing). - LoST doesn't need to change, (except maybe in the validation bits - which I still don't understand). - run by the Access Network (therefore Access Network has controls) +------+ +------+ | LS | | LoST | | | | | | | | | +------+ +------+ \ / \ LCP (n/c) / LoST Protocol (n/c) \ / +------+=20 | ULS | New, URI-Loc-Server - logically in Access Network | | | | +------+ / =20 / =20 / =20 +------+ +------+ | UA | | P1 | | |-----------| | | | | | +------+ +------+ 1. Endpoint accessed model +------+ +------+ | LS | | LoST | | | | | | | | | +------+ +------+ \ / \ LCP (n/c) / LoST Protocol (n/c) \ / +------+=20 | ULS | New, URI-Loc-Server - logically in Access Network | | | | +------+ \ \ \ +------+ +------+ | UA | | P1 | | |-----------| | | | | | +------+ +------+ 2. Proxy accessed model Summary: Neither of these scenarios preclude LbyV direct UA or Proxy interaction, if desirable, and (in my mind) don't impact (much) existing protocols. -roger marshall. >-----Original Message----- >From: Richard Barnes [mailto:rbarnes@bbn.com]=20 >Sent: Friday, April 13, 2007 9:45 AM >To: Rosen, Brian >Cc: geopriv@ietf.org; ecrit@ietf.org >Subject: Re: [Ecrit] Not-so-grand compromise on how to do=20 >endpoint centricLCP without giving away the store > >Brian, > >I think that you're right that provision of location by=20 >reference is a use case we need to support. > >URI validation will be useful in either case (LbyR or LbyV),=20 >and it seems like a natural extension to make to LoST: =20 >Validating that a given URI is a PSAP URI is like a reverse=20 >DNS lookup. Normal DNS queries map=20 >names->addresses (A+ records); reverse DNS queries map addresses to >names (*PTR records). Likewise, LoST queries map locations (+service >URNs) to URIs; a "reverse LoST" query could map a URI to a=20 >service area and a service URN. There's probably even simpler=20 >approaches, maybe via some form of NAPTR or ENUM lookup. > >As far as getting the endpoint the results of a LoST query based on an >LbyR: Your suggestion is good, but it has the problem that=20 >the access network doesn't really know what to fill in for the=20 > element of the LoST query. It could request all of=20 >the services available, but that would require a second LoST request. > >I would suggest that a more elegant solution (and one that=20 >deals better with the "unknown " problem) would be=20 >to extend LoST to handle location by reference. It wouldn't=20 >be a complicated change to LoST, just another location=20 >profile. Realizing that this has been discussed in the past,=20 >I scanned through the archive and found two main arguments=20 >against LoST doing LbyR: > >1. Dereference access control >In order to do the LoST lookup, a LoST server would have to be=20 >allowed to dereference the location reference. Given that=20 >most of the LoST infrastructure (e.g. the trees) is pretty=20 >static, it doesn't seem difficult to provide authentication=20 >credentials for LoST servers and require that they be able to=20 >dereference (just like PSAPs). > >2. Extra time/complication >It's correct that it would not be feasible for every LoST=20 >server involved in an LbyR-based query to dereference the=20 >location reference.=20 >However, this can be avoided if the resolver doing the=20 >recursive queries is allowed to do a dereference, since it can=20 >then just include the location by value in subsequent queries.=20 > This may cover most cases, e.g., if a local LoST resolver is=20 >provided by the access network (as is often the case with DNS). > >There's a lot of overlap between LoST/LbyR and what you=20 >propose. If the access network provides a resolver, then the=20 >two are essentially the same, except that if LoST/LbyR is=20 >used, then the client sends an extra query. However,=20 >extending LoST seems to maintain a better separation of the=20 >location configuration and mapping functions. > >Humbly submitted, >--Richard > > > >Rosen, Brian wrote: >> In the Emergency Services SDO Coordination workshop, a familiar=20 >> discussion took place: how does location get provided for emergency=20 >> calls? The real issue is revenue. Access networks have location. =20 >> They may be willing to (or may be regulated to be required=20 >to) provide=20 >> location for emergency calls. However, they are not willing to give=20 >> it away for free for other uses. The issue with that is how we=20 >> support calling networks that don't have relationships with access=20 >> networks, i.e. the Skype situation. How is location provided such=20 >> that a Skype emergency call can be placed, but the access=20 >network can=20 >> restrict what else may be done with the location it provides? >>=20 >> We have been wrapped around the axle on this for, dare I say, years. >>=20 >> So, I think Barbara Stark first described this, and it needs some=20 >> work, but suppose that, as an option, an access network could supply: >>=20 >> 1. A reference to location >>=20 >> 2. The results of a LoST query on the location value (viz, PSAP URI=20 >> and local dialstring) >>=20 >> With this, an endpoint could recognize an emergency call and start=20 >> routing it to the right PSAP. The LIS would agree to=20 >dereference for=20 >> PSAPs, but could restrict other uses of location. >>=20 >> Hannes points out that we need one more thing: the calling=20 >network has=20 >> to be able to validate that the PSAP URI really is a PSAP=20 >URI so that=20 >> charging (emergency calls generally are free) is protected. =20 >We need a=20 >> mechanism for them to do that. >>=20 >> Perhaps we include in the LoST return a country code for a=20 >query with=20 >> a geo. We add a new operation to LoST that takes a service,=20 >a country=20 >> code and a PSAP URI and returns yes/no validation ("Yes,=20 >that URI is a=20 >> valid URI for that service in that country"). >>=20 >> What would we need to do to make this happen? >>=20 >> We need extensions to LCPs or some new protocol that returns an LbyR=20 >> and the LoST results. I wonder if this is just more HELD work. >>=20 >> We need the PSAP URI validation. >>=20 >> Again, this is optional. The access network may well give=20 >up an LbyV. >> It may give up an LbyR that it will dereference for the=20 >endpoint. The=20 >> access network may have a relationship with the calling network such=20 >> that the endpoint need not be involved. >>=20 >> The PSAP URI validation is actually useful without this idea,=20 >> especially when location is an LbyR. Instead of having to have the=20 >> calling network dereference, and then do a LoST query to=20 >validate, it=20 >> can just do this PSAP URI validation. >>=20 >> Would this solve our problem? Would access carriers concerned about=20 >> revenue issues with "giving away" location to it's subscribers be=20 >> willing to provide LbyR dereferenceable by PSAPs (again remembering=20 >> that the access network are local to the PSAPs) as well as=20 >LoST query=20 >> services to their endpoints? Would this address the concerns raised=20 >> by Deutsche Telecom on this issue? >>=20 >> Let me be very clear that I think this is an ugly solution. I think=20 >> that everyone will be much better off if endpoints knew where they=20 >> were, and apps could take advantage of that. I think we'll=20 >get there. =20 >> I think tying location configuration with the LoST query is a bad=20 >> idea. I think using LbyR for emergency calls is a bad idea. >>=20 >> But I can live with it. >>=20 >> Brian >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > The information contained in this message may be privileged and/or confiden= tial. If you are not the intended recipient, or responsible for delivering = this message to the intended recipient, any review, forwarding, disseminati= on, distribution or copying of this communication or any attachment(s) is s= trictly prohibited. If you have received this message in error, please so n= otify the sender immediately, and delete it and all attachments from your c= omputer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 14:33:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcQaZ-0000qp-Ep; Fri, 13 Apr 2007 14:33:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcQaX-0000qP-Sh; Fri, 13 Apr 2007 14:33:37 -0400 Received: from s-utl01-atpop.stsn.net ([72.254.128.201]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HcQaX-0001a4-Da; Fri, 13 Apr 2007 14:33:37 -0400 Received: from s-utl01-atpop.stsn.net ([127.0.0.1]) by s-utl01-atpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007041314332612871 ; Fri, 13 Apr 2007 14:33:26 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.520,BAYES_00: -1.665 X-Spam-Level: Received: from [10.0.76.98] ([10.0.76.98]) by s-utl01-atpop.stsn.net; Fri, 13 Apr 2007 14:33:23 -0400 Message-ID: <461FCCE8.8080001@gmx.net> Date: Fri, 13 Apr 2007 20:33:12 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do endpoint centricLCP without giving away the store References: <886DD03D15173C43BCE98EA662A0101A01EB70D2@stntexch12.cis.neustar.com> <461FB382.1010908@bbn.com> <8C837214C95C864C9F34F3635C2A657507358133@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A657507358133@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Cc: geopriv@ietf.org, ecrit@ietf.org, "Rosen, Brian" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org How would the message exchange look like? Roger Marshall wrote: > 3GPP approaches this in a different way - one which (I think) we could > parallel, as shown in the following diagrams: > > Proposal: > > - Define a new function which handles location dereferencing and > supports lost queries (this seems to me to be somewhat similar to an LRF > in 3GPP, since an LRF goes and gets loc + routing). > - LoST doesn't need to change, (except maybe in the validation bits - > which I still don't understand). > - run by the Access Network (therefore Access Network has controls) > > > +------+ +------+ > | LS | | LoST | > | | | | > | | | | > +------+ +------+ > \ / > \ LCP (n/c) / LoST Protocol (n/c) > \ / > +------+ > | ULS | New, URI-Loc-Server - logically in Access > Network > | | > | | > +------+ > / > / > / > +------+ +------+ > | UA | | P1 | > | |-----------| | > | | | | > +------+ +------+ > > 1. Endpoint accessed model > > > +------+ +------+ > | LS | | LoST | > | | | | > | | | | > +------+ +------+ > \ / > \ LCP (n/c) / LoST Protocol (n/c) > \ / > +------+ > | ULS | New, URI-Loc-Server - logically in Access > Network > | | > | | > +------+ > \ > \ > \ > +------+ +------+ > | UA | | P1 | > | |-----------| | > | | | | > +------+ +------+ > > 2. Proxy accessed model > > Summary: > Neither of these scenarios preclude LbyV direct UA or Proxy interaction, > if desirable, and (in my mind) don't impact (much) existing protocols. > > -roger marshall. > > > > >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Friday, April 13, 2007 9:45 AM >> To: Rosen, Brian >> Cc: geopriv@ietf.org; ecrit@ietf.org >> Subject: Re: [Ecrit] Not-so-grand compromise on how to do >> endpoint centricLCP without giving away the store >> >> Brian, >> >> I think that you're right that provision of location by >> reference is a use case we need to support. >> >> URI validation will be useful in either case (LbyR or LbyV), >> and it seems like a natural extension to make to LoST: >> Validating that a given URI is a PSAP URI is like a reverse >> DNS lookup. Normal DNS queries map >> names->addresses (A+ records); reverse DNS queries map addresses to >> names (*PTR records). Likewise, LoST queries map locations (+service >> URNs) to URIs; a "reverse LoST" query could map a URI to a >> service area and a service URN. There's probably even simpler >> approaches, maybe via some form of NAPTR or ENUM lookup. >> >> As far as getting the endpoint the results of a LoST query based on an >> LbyR: Your suggestion is good, but it has the problem that >> the access network doesn't really know what to fill in for the >> element of the LoST query. It could request all of >> the services available, but that would require a second LoST request. >> >> I would suggest that a more elegant solution (and one that >> deals better with the "unknown " problem) would be >> to extend LoST to handle location by reference. It wouldn't >> be a complicated change to LoST, just another location >> profile. Realizing that this has been discussed in the past, >> I scanned through the archive and found two main arguments >> against LoST doing LbyR: >> >> 1. Dereference access control >> In order to do the LoST lookup, a LoST server would have to be >> allowed to dereference the location reference. Given that >> most of the LoST infrastructure (e.g. the trees) is pretty >> static, it doesn't seem difficult to provide authentication >> credentials for LoST servers and require that they be able to >> dereference (just like PSAPs). >> >> 2. Extra time/complication >> It's correct that it would not be feasible for every LoST >> server involved in an LbyR-based query to dereference the >> location reference. >> However, this can be avoided if the resolver doing the >> recursive queries is allowed to do a dereference, since it can >> then just include the location by value in subsequent queries. >> This may cover most cases, e.g., if a local LoST resolver is >> provided by the access network (as is often the case with DNS). >> >> There's a lot of overlap between LoST/LbyR and what you >> propose. If the access network provides a resolver, then the >> two are essentially the same, except that if LoST/LbyR is >> used, then the client sends an extra query. However, >> extending LoST seems to maintain a better separation of the >> location configuration and mapping functions. >> >> Humbly submitted, >> --Richard >> >> >> >> Rosen, Brian wrote: >> >>> In the Emergency Services SDO Coordination workshop, a familiar >>> discussion took place: how does location get provided for emergency >>> calls? The real issue is revenue. Access networks have location. >>> They may be willing to (or may be regulated to be required >>> >> to) provide >> >>> location for emergency calls. However, they are not willing to give >>> it away for free for other uses. The issue with that is how we >>> support calling networks that don't have relationships with access >>> networks, i.e. the Skype situation. How is location provided such >>> that a Skype emergency call can be placed, but the access >>> >> network can >> >>> restrict what else may be done with the location it provides? >>> >>> We have been wrapped around the axle on this for, dare I say, years. >>> >>> So, I think Barbara Stark first described this, and it needs some >>> work, but suppose that, as an option, an access network could supply: >>> >>> 1. A reference to location >>> >>> 2. The results of a LoST query on the location value (viz, PSAP URI >>> and local dialstring) >>> >>> With this, an endpoint could recognize an emergency call and start >>> routing it to the right PSAP. The LIS would agree to >>> >> dereference for >> >>> PSAPs, but could restrict other uses of location. >>> >>> Hannes points out that we need one more thing: the calling >>> >> network has >> >>> to be able to validate that the PSAP URI really is a PSAP >>> >> URI so that >> >>> charging (emergency calls generally are free) is protected. >>> >> We need a >> >>> mechanism for them to do that. >>> >>> Perhaps we include in the LoST return a country code for a >>> >> query with >> >>> a geo. We add a new operation to LoST that takes a service, >>> >> a country >> >>> code and a PSAP URI and returns yes/no validation ("Yes, >>> >> that URI is a >> >>> valid URI for that service in that country"). >>> >>> What would we need to do to make this happen? >>> >>> We need extensions to LCPs or some new protocol that returns an LbyR >>> and the LoST results. I wonder if this is just more HELD work. >>> >>> We need the PSAP URI validation. >>> >>> Again, this is optional. The access network may well give >>> >> up an LbyV. >> >>> It may give up an LbyR that it will dereference for the >>> >> endpoint. The >> >>> access network may have a relationship with the calling network such >>> that the endpoint need not be involved. >>> >>> The PSAP URI validation is actually useful without this idea, >>> especially when location is an LbyR. Instead of having to have the >>> calling network dereference, and then do a LoST query to >>> >> validate, it >> >>> can just do this PSAP URI validation. >>> >>> Would this solve our problem? Would access carriers concerned about >>> revenue issues with "giving away" location to it's subscribers be >>> willing to provide LbyR dereferenceable by PSAPs (again remembering >>> that the access network are local to the PSAPs) as well as >>> >> LoST query >> >>> services to their endpoints? Would this address the concerns raised >>> by Deutsche Telecom on this issue? >>> >>> Let me be very clear that I think this is an ugly solution. I think >>> that everyone will be much better off if endpoints knew where they >>> were, and apps could take advantage of that. I think we'll >>> >> get there. >> >>> I think tying location configuration with the LoST query is a bad >>> idea. I think using LbyR for emergency calls is a bad idea. >>> >>> But I can live with it. >>> >>> Brian >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> > > > The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network. > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 14:34:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcQbf-0001hL-3J; Fri, 13 Apr 2007 14:34:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcQbe-0001gT-8A; Fri, 13 Apr 2007 14:34:46 -0400 Received: from s-utl01-atpop.stsn.net ([72.254.128.201]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HcQbd-0001uk-SE; Fri, 13 Apr 2007 14:34:46 -0400 Received: from s-utl01-atpop.stsn.net ([127.0.0.1]) by s-utl01-atpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007041314344112873 ; Fri, 13 Apr 2007 14:34:41 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: -0.771,BAYES_00: -1.665, BIZ_TLD: 2.434 X-Spam-Level: Received: from [10.0.76.98] ([10.0.76.98]) by s-utl01-atpop.stsn.net; Fri, 13 Apr 2007 14:34:40 -0400 Message-ID: <461FCD35.4080403@gmx.net> Date: Fri, 13 Apr 2007 20:34:29 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Liess, Laura" Subject: Re: AW: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCPwithout giving away the store References: <182C63BFBAF131428EA0C16F7FD2191B013584AB@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <182C63BFBAF131428EA0C16F7FD2191B013584AB@S4DE8PSAAGM.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: geopriv@ietf.org, Brian.Rosen@neustar.biz, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Laura, in some sense your proposal is similar to use a SIP proxy in the access network (or someone that is closely related to it). Couldn't we just use the DHCP discovery technique for SIP proxies for that purpose? Ciao Hannes Liess, Laura wrote: > Brian, Hannes, > thank you for bringing up this issue. > In principle, I like the option for the access network to supply the PSAP URI. A similar option could be for the AN to provide an ESRP URI. The ESRP URI is for the AN a trusted party, so it has the necessary credentials to fetch the Location Info from the LIS. > > I figured out how such a scenario could work > > > > Configuration VSP's LoST > Alice Servers SIP proxy ESRP Servers PSAP > > ***Alice gets IP-connectivity**** > [M1] DHCP (with LbyR, country code and ESRP URI) > <--------- > > ***Some time later, Alice dials/initiates emergency call*** > [M2] INVITE (sos URN or 911/112, contains LbyR, country code and ESRP URI) > -------------------------------> > [M3] LoST Query (contains country code and ESRP URI) > ---------------------------> > [M4] LoST Response (contains a mark if ESRP URI is valid) > <---------------------------- > [M5] INVITE (sos URN or 911/112, contains LbyR) > -------------> > [M6] HTTPS(contains LbyR) > <---------------------------------- > [M7] HTTPS(contains Location) > ---------------------------------> > [M8] LoST Query (contains Location) > ---------------------> > [M9] LoST Response (contains PSAP URI) > <---------------------- > [M10] INVITE (contains Location) > -----------------------------------> > 200 OK > <------------------------------------------------------------------------------- > ACK > -------------------------------------------------------------------------------> > > > I think if there is a local ESRP between the VSP's SIP Proxy and the PSAP we are more flexible to comply to country-specific regulations. > The ESRP could choose the PSAP based on a local LoST server which knows the capabilities of the local PSAPs. E.g. during a transition period we may have the old PSTN PSAPs and very few IP PSAPs with additional capabilities, e. g. emergency call takers speaking foreign languages or emergency call takers for deaf people. The local LoST server would be able to choose the right PSAP (this is just an idea, I don't know whether or not it's realistic). > > > Thanks > Laura > > > > > > > > >> -----Ursprüngliche Nachricht----- >> Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Gesendet: Freitag, 13. April 2007 13:18 >> An: geopriv@ietf.org >> Cc: ecrit@ietf.org >> Betreff: [Ecrit] Not-so-grand compromise on how to do >> endpoint centric LCPwithout giving away the store >> >> >> In the Emergency Services SDO Coordination workshop, a >> familiar discussion took place: how does location get >> provided for emergency calls? The real issue is revenue. >> Access networks have location. They may be willing to (or >> may be regulated to be required to) provide location for >> emergency calls. However, they are not willing to give it >> away for free for other uses. The issue with that is how we >> support calling networks that don't have relationships with >> access networks, i.e. the Skype situation. How is location >> provided such that a Skype emergency call can be placed, but >> the access network can restrict what else may be done with >> the location it provides? >> >> We have been wrapped around the axle on this for, dare I say, years. >> >> So, I think Barbara Stark first described this, and it needs >> some work, but suppose that, as an option, an access network >> could supply: >> >> 1. A reference to location >> >> 2. The results of a LoST query on the location value (viz, >> PSAP URI and local dialstring) >> >> With this, an endpoint could recognize an emergency call and >> start routing it to the right PSAP. The LIS would agree to >> dereference for PSAPs, but could restrict other uses of location. >> >> Hannes points out that we need one more thing: the calling >> network has to be able to validate that the PSAP URI really >> is a PSAP URI so that charging (emergency calls generally are >> free) is protected. We need a mechanism for them to do that. >> >> Perhaps we include in the LoST return a country code for a >> query with a geo. We add a new operation to LoST that takes >> a service, a country code and a PSAP URI and returns yes/no >> validation ("Yes, that URI is a valid URI for that service in >> that country"). >> >> What would we need to do to make this happen? >> >> We need extensions to LCPs or some new protocol that returns >> an LbyR and the LoST results. I wonder if this is just more >> HELD work. >> >> We need the PSAP URI validation. >> >> Again, this is optional. The access network may well give up >> an LbyV. It may give up an LbyR that it will dereference for >> the endpoint. The access network may have a relationship >> with the calling network such that the endpoint need not be involved. >> >> The PSAP URI validation is actually useful without this idea, >> especially when location is an LbyR. Instead of having to >> have the calling network dereference, and then do a LoST >> query to validate, it can just do this PSAP URI validation. >> >> Would this solve our problem? Would access carriers >> concerned about revenue issues with "giving away" location to >> it's subscribers be willing to provide LbyR dereferenceable >> by PSAPs (again remembering that the access network are local >> to the PSAPs) as well as LoST query services to their >> endpoints? Would this address the concerns raised by >> Deutsche Telecom on this issue? >> >> Let me be very clear that I think this is an ugly solution. >> I think that everyone will be much better off if endpoints >> knew where they were, and apps could take advantage of that. >> I think we'll get there. I think tying location >> configuration with the LoST query is a bad idea. I think >> using LbyR for emergency calls is a bad idea. >> >> But I can live with it. >> >> Brian >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 14:46:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcQmf-0000s7-Ex; Fri, 13 Apr 2007 14:46:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcQme-0000rj-9v; Fri, 13 Apr 2007 14:46:08 -0400 Received: from s-utl02-atpop.stsn.net ([72.254.128.202]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HcQmd-0006Mn-QK; Fri, 13 Apr 2007 14:46:08 -0400 Received: from s-utl02-atpop.stsn.net ([127.0.0.1]) by s-utl02-atpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007041314460411000 ; Fri, 13 Apr 2007 14:46:04 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: 0.281,BAYES_00: -1.665 X-Spam-Level: Received: from [10.0.76.98] ([10.0.76.98]) by s-utl02-atpop.stsn.net; Fri, 13 Apr 2007 14:46:02 -0400 Message-ID: <461FCFE0.10407@gmx.net> Date: Fri, 13 Apr 2007 20:45:52 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCP without giving away the store References: <02f401c77de5$678e4bb0$640fa8c0@cis.neustar.com> In-Reply-To: <02f401c77de5$678e4bb0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 58b614506802734014829a093beb6879 Cc: geopriv@ietf.org, "Rosen, Brian" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian, sorry that I confused everything. Maybe I am still suffering from a post-SDO Emergency Service Workshop syndrome: Let me describe the procedure in a message sequence: Target => LIS: Request LbyR Target<= LIS: LbyR, PSAP URI, Service Number Target=> VSP-Proxy: SIP message including LbyR, PSAP URI VSP-Proxy=> LIS: Check PSAP URI at LbyR VSP-Proxy<= LIS: OK or NOT OK (LIS checks whether the location information behind the LbyR translates to the PSAP URI presented by the VSP-Proxy) DONE Note that yo can replace LIS with LoST server in this example. Does this make sense to you? Ciao Hannes Brian Rosen wrote: > Huh, I didn't get that. > > I'd like to eliminate the country code thing, because otherwise we need a > way to carry it in the SIP Geolocation. However, I don't really want the > VSP having to ask the ASP/ISP for a dereference of any sort, and I'd like to > minimize the work of the ASP/ISP. The notion that the ASP/ISP has to help > the VSP determine if what it has is a valid PSAP URI strikes me as a > problem. > > Now, you may remember WAAAY WAAY back, I strongly suggested that the geo > form of location always include a country code. I suggested this for > disputed areas. The access network is in a very good position to tell you > how best to interpret which country actually is the on-the-ground > administrator of the location. If you are connected to an Israeli access > network, and you ask LoST for a PSAP URI, you probably want an Israeli fire > brigade. If you are on a Palestinian access network, then you probably want > a different answer. So, having country code in a PIDF with an otherwise geo > location is actually helpful. > > The current answer for this is some kind of manual configuration of the LoST > servers so you get the answer you want. While that can work, I think > something more automatic might work better, and it fixes the problem. > > Brian > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Friday, April 13, 2007 11:26 AM >> To: Rosen, Brian >> Cc: geopriv@ietf.org; ecrit@ietf.org >> Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do >> endpoint centric LCP without giving away the store >> >> Hi Brian, >> >> I only described a different way of doing the verification without >> returning a country code. >> I also focus on LbyR only rather than LbyV. >> >> Ciao >> Hannes >> >> Rosen, Brian wrote: >> >>> Hannes >>> >>> I am confused by your message. >>> >>> The problem you describe, where a VSP is trying to validate that the >>> Request URI in what is claimed to be an emergency call is a bona fide >>> PSAP URI seems to be a valid concern. My message described one way to >>> do this validation when what the VSP received (in a SIP Geolocation >>> header) is an LbyR. >>> >>> Are you now wondering how you validate when you have an LbyV? I would >>> think you do the same thing: send the country code (or the whole >>> location) and the PSAP URI to LoST and ask if the PSAP URI is valid. >>> This does not require any query by the VSP to the ASP/ISP. The VSP >>> should be able to query its local LoST server and be referred to the >>> authoritative server for the location it proffers. >>> >>> I'd rather not have to have the VSP try to dereference an LbyR, and if >>> you have an LbyV then you don't even know, necessarily, who the ASP/ISP >>> is. >>> >>> Is there something else I'm missing here? >>> >>> Brian >>> >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Friday, April 13, 2007 10:43 AM >>>> To: Rosen, Brian >>>> Cc: geopriv@ietf.org; ecrit@ietf.org >>>> Subject: Re: [Ecrit] Not-so-grand compromise on how to do endpoint >>>> >>>> >>> centric >>> >>> >>>> LCP without giving away the store >>>> >>>> Hi Brian, >>>> >>>> thanks for posting this message. >>>> >>>> When the end host is provided with LbyV and triggers the LoST lookup >>>> >>>> >>> and >>> >>> >>>> routes the call via its VSP then the VSP (in some circumstances*) >>>> >>>> >>> might >>> >>> >>>> want to verify that the PSAP URI in the message indeed corresponds to >>>> >>>> >>> a >>> >>> >>>> PSAP. The idea that was mentioned a long time ago already was to let >>>> >>>> >>> the >>> >>> >>>> VSP to use the location information for LoST and to compare the result >>>> with the content of the message. >>>> >>>> The main goal here is that the VSP does not need to have a "business" >>>> contract to the ASP/ISP. >>>> >>>> Since there is only a location reference that neither the end host nor >>>> the VSP can dereference it is necessary to enhance the existing >>>> procedures a bit (as Brian mentioned). >>>> >>>> I see two ways todo so: >>>> >>>> a) Enhance LoST >>>> b) Enhance the dereferencing protocol >>>> >>>> In both cases you want to have the LbyR as input and the PSAP URI (and >>>> potentially the service number) as output. >>>> >>>> For (a) you would have to address the LoST query to the LoST server in >>>> the ASP/ISP network and the result would be a nomal LoST response. >>>> For (b) you would have todo a dereferencing step with an additional >>>> parameter for "verify only". The response would be similar to the >>>> >>>> >>> lookup >>> >>> >>>> by the end host -- just the identity that is being used for the lookup >>>> would be different. >>>> >>>> Both approaches are possible and since the VSP has to support both >>>> protocols it does not make a big difference which one to use. >>>> >>>> In both cases you would have to compare the result of the lookup with >>>> the content of the message. >>>> >>>> Ciao >>>> Hannes >>>> >>>> *: It is only necessary when the VSP charges for individual calls or >>>> >>>> >>> for >>> >>> >>>> specific calls (with the given call falling into this category). >>>> >>>> Rosen, Brian wrote: >>>> >>>> >>>>> In the Emergency Services SDO Coordination workshop, a familiar >>>>> discussion took place: how does location get provided for emergency >>>>> calls? The real issue is revenue. Access networks have location. >>>>> >>>>> >>> They >>> >>> >>>>> may be willing to (or may be regulated to be required to) provide >>>>> location for emergency calls. However, they are not willing to give >>>>> >>>>> >>> it >>> >>> >>>>> away for free for other uses. The issue with that is how we support >>>>> calling networks that don't have relationships with access networks, >>>>> i.e. the Skype situation. How is location provided such that a >>>>> >>>>> >>> Skype >>> >>> >>>>> emergency call can be placed, but the access network can restrict >>>>> >>>>> >>> what >>> >>> >>>>> else may be done with the location it provides? >>>>> >>>>> We have been wrapped around the axle on this for, dare I say, years. >>>>> >>>>> So, I think Barbara Stark first described this, and it needs some >>>>> >>>>> >>> work, >>> >>> >>>>> but suppose that, as an option, an access network could supply: >>>>> >>>>> 1. A reference to location >>>>> >>>>> 2. The results of a LoST query on the location value (viz, PSAP URI >>>>> >>>>> >>> and >>> >>> >>>>> local dialstring) >>>>> >>>>> With this, an endpoint could recognize an emergency call and start >>>>> routing it to the right PSAP. The LIS would agree to dereference >>>>> >>>>> >>> for >>> >>> >>>>> PSAPs, but could restrict other uses of location. >>>>> >>>>> Hannes points out that we need one more thing: the calling network >>>>> >>>>> >>> has >>> >>> >>>>> to be able to validate that the PSAP URI really is a PSAP URI so >>>>> >>>>> >>> that >>> >>> >>>>> charging (emergency calls generally are free) is protected. We need >>>>> >>>>> >>> a >>> >>> >>>>> mechanism for them to do that. >>>>> >>>>> Perhaps we include in the LoST return a country code for a query >>>>> >>>>> >>> with a >>> >>> >>>>> geo. We add a new operation to LoST that takes a service, a country >>>>> code and a PSAP URI and returns yes/no validation ("Yes, that URI is >>>>> >>>>> >>> a >>> >>> >>>>> valid URI for that service in that country"). >>>>> >>>>> What would we need to do to make this happen? >>>>> >>>>> We need extensions to LCPs or some new protocol that returns an LbyR >>>>> >>>>> >>> and >>> >>> >>>>> the LoST results. I wonder if this is just more HELD work. >>>>> >>>>> We need the PSAP URI validation. >>>>> >>>>> Again, this is optional. The access network may well give up an >>>>> >>>>> >>> LbyV. >>> >>> >>>>> It may give up an LbyR that it will dereference for the endpoint. >>>>> >>>>> >>> The >>> >>> >>>>> access network may have a relationship with the calling network such >>>>> that the endpoint need not be involved. >>>>> >>>>> The PSAP URI validation is actually useful without this idea, >>>>> >>>>> >>> especially >>> >>> >>>>> when location is an LbyR. Instead of having to have the calling >>>>> >>>>> >>> network >>> >>> >>>>> dereference, and then do a LoST query to validate, it can just do >>>>> >>>>> >>> this >>> >>> >>>>> PSAP URI validation. >>>>> >>>>> Would this solve our problem? Would access carriers concerned about >>>>> revenue issues with "giving away" location to it's subscribers be >>>>> willing to provide LbyR dereferenceable by PSAPs (again remembering >>>>> >>>>> >>> that >>> >>> >>>>> the access network are local to the PSAPs) as well as LoST query >>>>> services to their endpoints? Would this address the concerns raised >>>>> >>>>> >>> by >>> >>> >>>>> Deutsche Telecom on this issue? >>>>> >>>>> Let me be very clear that I think this is an ugly solution. I think >>>>> that everyone will be much better off if endpoints knew where they >>>>> >>>>> >>> were, >>> >>> >>>>> and apps could take advantage of that. I think we'll get there. I >>>>> think tying location configuration with the LoST query is a bad >>>>> >>>>> >>> idea. I >>> >>> >>>>> think using LbyR for emergency calls is a bad idea. >>>>> >>>>> But I can live with it. >>>>> >>>>> Brian >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> >>>>> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 14:55:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcQvO-0005rD-QF; Fri, 13 Apr 2007 14:55:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcQvN-0005r3-Vc; Fri, 13 Apr 2007 14:55:09 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcQvL-0000ni-Cl; Fri, 13 Apr 2007 14:55:09 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HcQvI-00084E-5H; Fri, 13 Apr 2007 14:55:04 -0400 Received: from [127.0.0.1] (ros-dhcp233-050-233.bbn.com [192.233.50.233]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l3DIt3w29198; Fri, 13 Apr 2007 14:55:03 -0400 (EDT) Message-ID: <461FD207.5010801@bbn.com> Date: Fri, 13 Apr 2007 14:55:03 -0400 From: Richard Barnes User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] Not-so-grand compromise on how to do endpoint centricLCP without giving away the store References: <886DD03D15173C43BCE98EA662A0101A01EB70D2@stntexch12.cis.neustar.com> <461FB382.1010908@bbn.com> <8C837214C95C864C9F34F3635C2A657507358133@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A657507358133@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Cc: geopriv@ietf.org, "Rosen, Brian" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org What's the protocol between the UA/P1 and the ULS? It needs to (1) carry LbyR to the ULS and a service URN to the ULS, and (2) return a LoST response to the UA/P1. LoST would be the natural candidate for this, if it could carry LbyR. That said, I don't think that this model has any different requirements in terms of protocols, it just shifts the whole show off the endpoint into the ULS. And I thought the whole point of Brian/Barbara's suggestion was to allow for access-controlled location while keeping positioning local to the endpoint. --Richard Roger Marshall wrote: > 3GPP approaches this in a different way - one which (I think) we could > parallel, as shown in the following diagrams: > > Proposal: > > - Define a new function which handles location dereferencing and > supports lost queries (this seems to me to be somewhat similar to an LRF > in 3GPP, since an LRF goes and gets loc + routing). > - LoST doesn't need to change, (except maybe in the validation bits - > which I still don't understand). > - run by the Access Network (therefore Access Network has controls) > > > +------+ +------+ > | LS | | LoST | > | | | | > | | | | > +------+ +------+ > \ / > \ LCP (n/c) / LoST Protocol (n/c) > \ / > +------+ > | ULS | New, URI-Loc-Server - logically in Access > Network > | | > | | > +------+ > / > / > / > +------+ +------+ > | UA | | P1 | > | |-----------| | > | | | | > +------+ +------+ > > 1. Endpoint accessed model > > > +------+ +------+ > | LS | | LoST | > | | | | > | | | | > +------+ +------+ > \ / > \ LCP (n/c) / LoST Protocol (n/c) > \ / > +------+ > | ULS | New, URI-Loc-Server - logically in Access > Network > | | > | | > +------+ > \ > \ > \ > +------+ +------+ > | UA | | P1 | > | |-----------| | > | | | | > +------+ +------+ > > 2. Proxy accessed model > > Summary: > Neither of these scenarios preclude LbyV direct UA or Proxy interaction, > if desirable, and (in my mind) don't impact (much) existing protocols. > > -roger marshall. > > > >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Friday, April 13, 2007 9:45 AM >> To: Rosen, Brian >> Cc: geopriv@ietf.org; ecrit@ietf.org >> Subject: Re: [Ecrit] Not-so-grand compromise on how to do >> endpoint centricLCP without giving away the store >> >> Brian, >> >> I think that you're right that provision of location by >> reference is a use case we need to support. >> >> URI validation will be useful in either case (LbyR or LbyV), >> and it seems like a natural extension to make to LoST: >> Validating that a given URI is a PSAP URI is like a reverse >> DNS lookup. Normal DNS queries map >> names->addresses (A+ records); reverse DNS queries map addresses to >> names (*PTR records). Likewise, LoST queries map locations (+service >> URNs) to URIs; a "reverse LoST" query could map a URI to a >> service area and a service URN. There's probably even simpler >> approaches, maybe via some form of NAPTR or ENUM lookup. >> >> As far as getting the endpoint the results of a LoST query based on an >> LbyR: Your suggestion is good, but it has the problem that >> the access network doesn't really know what to fill in for the >> element of the LoST query. It could request all of >> the services available, but that would require a second LoST request. >> >> I would suggest that a more elegant solution (and one that >> deals better with the "unknown " problem) would be >> to extend LoST to handle location by reference. It wouldn't >> be a complicated change to LoST, just another location >> profile. Realizing that this has been discussed in the past, >> I scanned through the archive and found two main arguments >> against LoST doing LbyR: >> >> 1. Dereference access control >> In order to do the LoST lookup, a LoST server would have to be >> allowed to dereference the location reference. Given that >> most of the LoST infrastructure (e.g. the trees) is pretty >> static, it doesn't seem difficult to provide authentication >> credentials for LoST servers and require that they be able to >> dereference (just like PSAPs). >> >> 2. Extra time/complication >> It's correct that it would not be feasible for every LoST >> server involved in an LbyR-based query to dereference the >> location reference. >> However, this can be avoided if the resolver doing the >> recursive queries is allowed to do a dereference, since it can >> then just include the location by value in subsequent queries. >> This may cover most cases, e.g., if a local LoST resolver is >> provided by the access network (as is often the case with DNS). >> >> There's a lot of overlap between LoST/LbyR and what you >> propose. If the access network provides a resolver, then the >> two are essentially the same, except that if LoST/LbyR is >> used, then the client sends an extra query. However, >> extending LoST seems to maintain a better separation of the >> location configuration and mapping functions. >> >> Humbly submitted, >> --Richard >> >> >> >> Rosen, Brian wrote: >>> In the Emergency Services SDO Coordination workshop, a familiar >>> discussion took place: how does location get provided for emergency >>> calls? The real issue is revenue. Access networks have location. >>> They may be willing to (or may be regulated to be required >> to) provide >>> location for emergency calls. However, they are not willing to give >>> it away for free for other uses. The issue with that is how we >>> support calling networks that don't have relationships with access >>> networks, i.e. the Skype situation. How is location provided such >>> that a Skype emergency call can be placed, but the access >> network can >>> restrict what else may be done with the location it provides? >>> >>> We have been wrapped around the axle on this for, dare I say, years. >>> >>> So, I think Barbara Stark first described this, and it needs some >>> work, but suppose that, as an option, an access network could supply: >>> >>> 1. A reference to location >>> >>> 2. The results of a LoST query on the location value (viz, PSAP URI >>> and local dialstring) >>> >>> With this, an endpoint could recognize an emergency call and start >>> routing it to the right PSAP. The LIS would agree to >> dereference for >>> PSAPs, but could restrict other uses of location. >>> >>> Hannes points out that we need one more thing: the calling >> network has >>> to be able to validate that the PSAP URI really is a PSAP >> URI so that >>> charging (emergency calls generally are free) is protected. >> We need a >>> mechanism for them to do that. >>> >>> Perhaps we include in the LoST return a country code for a >> query with >>> a geo. We add a new operation to LoST that takes a service, >> a country >>> code and a PSAP URI and returns yes/no validation ("Yes, >> that URI is a >>> valid URI for that service in that country"). >>> >>> What would we need to do to make this happen? >>> >>> We need extensions to LCPs or some new protocol that returns an LbyR >>> and the LoST results. I wonder if this is just more HELD work. >>> >>> We need the PSAP URI validation. >>> >>> Again, this is optional. The access network may well give >> up an LbyV. >>> It may give up an LbyR that it will dereference for the >> endpoint. The >>> access network may have a relationship with the calling network such >>> that the endpoint need not be involved. >>> >>> The PSAP URI validation is actually useful without this idea, >>> especially when location is an LbyR. Instead of having to have the >>> calling network dereference, and then do a LoST query to >> validate, it >>> can just do this PSAP URI validation. >>> >>> Would this solve our problem? Would access carriers concerned about >>> revenue issues with "giving away" location to it's subscribers be >>> willing to provide LbyR dereferenceable by PSAPs (again remembering >>> that the access network are local to the PSAPs) as well as >> LoST query >>> services to their endpoints? Would this address the concerns raised >>> by Deutsche Telecom on this issue? >>> >>> Let me be very clear that I think this is an ugly solution. I think >>> that everyone will be much better off if endpoints knew where they >>> were, and apps could take advantage of that. I think we'll >> get there. >>> I think tying location configuration with the LoST query is a bad >>> idea. I think using LbyR for emergency calls is a bad idea. >>> >>> But I can live with it. >>> >>> Brian >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> > > > The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network. > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 15:11:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcRB1-0008V4-6x; Fri, 13 Apr 2007 15:11:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcRB0-0008Uv-9q; Fri, 13 Apr 2007 15:11:18 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcRAx-0005tz-SE; Fri, 13 Apr 2007 15:11:18 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HcR8P-00071A-3b; Fri, 13 Apr 2007 14:08:37 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , "Rosen, Brian" , Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCPwithout giving away the store Date: Fri, 13 Apr 2007 15:11:09 -0400 Message-ID: <035a01c77dff$80b9c820$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd9eBCfZxIYRVO7QJu63bsxYVEIfwAd6vQwAAPV6GA= In-Reply-To: <000001c77df0$5f1a9870$42aa520a@amer.cisco.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think that is part of the tradeoff an access network makes. If its restricting access to location, and location is needed to route, then it has to assume the liability for misroute, since it's providing the route in lieu of providing location for the VSP to route. If it doesn't want to assume that liability, then it has to give location to someone who does the route, and we're back around that axle again. So, I think it's reasonable that the access network deal with misroutes in this case. Brian > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Friday, April 13, 2007 1:23 PM > To: 'Rosen, Brian'; geopriv@ietf.org > Cc: ecrit@ietf.org > Subject: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do > endpointcentric LCPwithout giving away the store > > Who is responsible for PSAP mis-routes? I would think this transfers > liability for routing to the access-provider, are they willing to step up > to > that? > > -Marc- > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > Sent: Friday, April 13, 2007 7:18 AM > > To: geopriv@ietf.org > > Cc: ecrit@ietf.org > > Subject: [Ecrit] Not-so-grand compromise on how to do > > endpoint centric LCPwithout giving away the store > > > > In the Emergency Services SDO Coordination workshop, a > > familiar discussion took place: how does location get > > provided for emergency calls? The real issue is revenue. > > Access networks have location. They may be willing to (or > > may be regulated to be required to) provide location for > > emergency calls. However, they are not willing to give it > > away for free for other uses. The issue with that is how we > > support calling networks that don't have relationships with > > access networks, i.e. the Skype situation. How is location > > provided such that a Skype emergency call can be placed, but > > the access network can restrict what else may be done with > > the location it provides? > > > > We have been wrapped around the axle on this for, dare I say, years. > > > > So, I think Barbara Stark first described this, and it needs > > some work, but suppose that, as an option, an access network > > could supply: > > > > 1. A reference to location > > > > 2. The results of a LoST query on the location value (viz, > > PSAP URI and local dialstring) > > > > With this, an endpoint could recognize an emergency call and > > start routing it to the right PSAP. The LIS would agree to > > dereference for PSAPs, but could restrict other uses of location. > > > > Hannes points out that we need one more thing: the calling > > network has to be able to validate that the PSAP URI really > > is a PSAP URI so that charging (emergency calls generally are > > free) is protected. We need a mechanism for them to do that. > > > > Perhaps we include in the LoST return a country code for a > > query with a geo. We add a new operation to LoST that takes > > a service, a country code and a PSAP URI and returns yes/no > > validation ("Yes, that URI is a valid URI for that service in > > that country"). > > > > What would we need to do to make this happen? > > > > We need extensions to LCPs or some new protocol that returns > > an LbyR and the LoST results. I wonder if this is just more > > HELD work. > > > > We need the PSAP URI validation. > > > > Again, this is optional. The access network may well give up an LbyV. > > It may give up an LbyR that it will dereference for the > > endpoint. The access network may have a relationship with > > the calling network such that the endpoint need not be involved. > > > > The PSAP URI validation is actually useful without this idea, > > especially when location is an LbyR. Instead of having to > > have the calling network dereference, and then do a LoST > > query to validate, it can just do this PSAP URI validation. > > > > Would this solve our problem? Would access carriers > > concerned about revenue issues with "giving away" location to > > it's subscribers be willing to provide LbyR dereferenceable > > by PSAPs (again remembering that the access network are local > > to the PSAPs) as well as LoST query services to their > > endpoints? Would this address the concerns raised by > > Deutsche Telecom on this issue? > > > > Let me be very clear that I think this is an ugly solution. > > I think that everyone will be much better off if endpoints > > knew where they were, and apps could take advantage of that. > > I think we'll get there. I think tying location > > configuration with the LoST query is a bad idea. I think > > using LbyR for emergency calls is a bad idea. > > > > But I can live with it. > > > > Brian > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 15:15:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcREm-0001rX-J5; Fri, 13 Apr 2007 15:15:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcREl-0001rF-2S; Fri, 13 Apr 2007 15:15:11 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcREk-0007ul-Fl; Fri, 13 Apr 2007 15:15:11 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HcRCD-0000oS-RK; Fri, 13 Apr 2007 14:12:34 -0500 From: "Brian Rosen" To: "'Roger Marshall'" , "'Richard Barnes'" , "Rosen, Brian" Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do endpoint centricLCP without giving away the store Date: Fri, 13 Apr 2007 15:15:06 -0400 Message-ID: <035b01c77e00$0dde4a00$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd96xIxXNwnNW5eQ0WPFPugVIhi4wABpCggAAN4AZA= In-Reply-To: <8C837214C95C864C9F34F3635C2A657507358133@SEA-EXCHVS-2.telecomsys.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'm not sure there is a whole lot of difference to extending the LCP to supply the route data (or, if you like Richard's proposal, to allow the route protocol to do the dereference) and inventing a new protocol to do both. I don't really care all that much, since the message sequences would look the same (you send your identifiers in, like you would with an LCP, and you get back the LbyR and the LoST result). If you don't understand the validation bits (which allow a VSP, who cannot dereference) to make sure that the PSAP URI which the endpoint is routing towards, really is a PSAP URI, ask a question :) Brian > -----Original Message----- > From: Roger Marshall [mailto:RMarshall@telecomsys.com] > Sent: Friday, April 13, 2007 1:58 PM > To: Richard Barnes; Rosen, Brian > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do > endpoint centricLCP without giving away the store > > 3GPP approaches this in a different way - one which (I think) we could > parallel, as shown in the following diagrams: > > Proposal: > > - Define a new function which handles location dereferencing and > supports lost queries (this seems to me to be somewhat similar to an LRF > in 3GPP, since an LRF goes and gets loc + routing). > - LoST doesn't need to change, (except maybe in the validation bits - > which I still don't understand). > - run by the Access Network (therefore Access Network has controls) > > > +------+ +------+ > | LS | | LoST | > | | | | > | | | | > +------+ +------+ > \ / > \ LCP (n/c) / LoST Protocol (n/c) > \ / > +------+ > | ULS | New, URI-Loc-Server - logically in Access > Network > | | > | | > +------+ > / > / > / > +------+ +------+ > | UA | | P1 | > | |-----------| | > | | | | > +------+ +------+ > > 1. Endpoint accessed model > > > +------+ +------+ > | LS | | LoST | > | | | | > | | | | > +------+ +------+ > \ / > \ LCP (n/c) / LoST Protocol (n/c) > \ / > +------+ > | ULS | New, URI-Loc-Server - logically in Access > Network > | | > | | > +------+ > \ > \ > \ > +------+ +------+ > | UA | | P1 | > | |-----------| | > | | | | > +------+ +------+ > > 2. Proxy accessed model > > Summary: > Neither of these scenarios preclude LbyV direct UA or Proxy interaction, > if desirable, and (in my mind) don't impact (much) existing protocols. > > -roger marshall. > > > > >-----Original Message----- > >From: Richard Barnes [mailto:rbarnes@bbn.com] > >Sent: Friday, April 13, 2007 9:45 AM > >To: Rosen, Brian > >Cc: geopriv@ietf.org; ecrit@ietf.org > >Subject: Re: [Ecrit] Not-so-grand compromise on how to do > >endpoint centricLCP without giving away the store > > > >Brian, > > > >I think that you're right that provision of location by > >reference is a use case we need to support. > > > >URI validation will be useful in either case (LbyR or LbyV), > >and it seems like a natural extension to make to LoST: > >Validating that a given URI is a PSAP URI is like a reverse > >DNS lookup. Normal DNS queries map > >names->addresses (A+ records); reverse DNS queries map addresses to > >names (*PTR records). Likewise, LoST queries map locations (+service > >URNs) to URIs; a "reverse LoST" query could map a URI to a > >service area and a service URN. There's probably even simpler > >approaches, maybe via some form of NAPTR or ENUM lookup. > > > >As far as getting the endpoint the results of a LoST query based on an > >LbyR: Your suggestion is good, but it has the problem that > >the access network doesn't really know what to fill in for the > > element of the LoST query. It could request all of > >the services available, but that would require a second LoST request. > > > >I would suggest that a more elegant solution (and one that > >deals better with the "unknown " problem) would be > >to extend LoST to handle location by reference. It wouldn't > >be a complicated change to LoST, just another location > >profile. Realizing that this has been discussed in the past, > >I scanned through the archive and found two main arguments > >against LoST doing LbyR: > > > >1. Dereference access control > >In order to do the LoST lookup, a LoST server would have to be > >allowed to dereference the location reference. Given that > >most of the LoST infrastructure (e.g. the trees) is pretty > >static, it doesn't seem difficult to provide authentication > >credentials for LoST servers and require that they be able to > >dereference (just like PSAPs). > > > >2. Extra time/complication > >It's correct that it would not be feasible for every LoST > >server involved in an LbyR-based query to dereference the > >location reference. > >However, this can be avoided if the resolver doing the > >recursive queries is allowed to do a dereference, since it can > >then just include the location by value in subsequent queries. > > This may cover most cases, e.g., if a local LoST resolver is > >provided by the access network (as is often the case with DNS). > > > >There's a lot of overlap between LoST/LbyR and what you > >propose. If the access network provides a resolver, then the > >two are essentially the same, except that if LoST/LbyR is > >used, then the client sends an extra query. However, > >extending LoST seems to maintain a better separation of the > >location configuration and mapping functions. > > > >Humbly submitted, > >--Richard > > > > > > > >Rosen, Brian wrote: > >> In the Emergency Services SDO Coordination workshop, a familiar > >> discussion took place: how does location get provided for emergency > >> calls? The real issue is revenue. Access networks have location. > >> They may be willing to (or may be regulated to be required > >to) provide > >> location for emergency calls. However, they are not willing to give > >> it away for free for other uses. The issue with that is how we > >> support calling networks that don't have relationships with access > >> networks, i.e. the Skype situation. How is location provided such > >> that a Skype emergency call can be placed, but the access > >network can > >> restrict what else may be done with the location it provides? > >> > >> We have been wrapped around the axle on this for, dare I say, years. > >> > >> So, I think Barbara Stark first described this, and it needs some > >> work, but suppose that, as an option, an access network could supply: > >> > >> 1. A reference to location > >> > >> 2. The results of a LoST query on the location value (viz, PSAP URI > >> and local dialstring) > >> > >> With this, an endpoint could recognize an emergency call and start > >> routing it to the right PSAP. The LIS would agree to > >dereference for > >> PSAPs, but could restrict other uses of location. > >> > >> Hannes points out that we need one more thing: the calling > >network has > >> to be able to validate that the PSAP URI really is a PSAP > >URI so that > >> charging (emergency calls generally are free) is protected. > >We need a > >> mechanism for them to do that. > >> > >> Perhaps we include in the LoST return a country code for a > >query with > >> a geo. We add a new operation to LoST that takes a service, > >a country > >> code and a PSAP URI and returns yes/no validation ("Yes, > >that URI is a > >> valid URI for that service in that country"). > >> > >> What would we need to do to make this happen? > >> > >> We need extensions to LCPs or some new protocol that returns an LbyR > >> and the LoST results. I wonder if this is just more HELD work. > >> > >> We need the PSAP URI validation. > >> > >> Again, this is optional. The access network may well give > >up an LbyV. > >> It may give up an LbyR that it will dereference for the > >endpoint. The > >> access network may have a relationship with the calling network such > >> that the endpoint need not be involved. > >> > >> The PSAP URI validation is actually useful without this idea, > >> especially when location is an LbyR. Instead of having to have the > >> calling network dereference, and then do a LoST query to > >validate, it > >> can just do this PSAP URI validation. > >> > >> Would this solve our problem? Would access carriers concerned about > >> revenue issues with "giving away" location to it's subscribers be > >> willing to provide LbyR dereferenceable by PSAPs (again remembering > >> that the access network are local to the PSAPs) as well as > >LoST query > >> services to their endpoints? Would this address the concerns raised > >> by Deutsche Telecom on this issue? > >> > >> Let me be very clear that I think this is an ugly solution. I think > >> that everyone will be much better off if endpoints knew where they > >> were, and apps could take advantage of that. I think we'll > >get there. > >> I think tying location configuration with the LoST query is a bad > >> idea. I think using LbyR for emergency calls is a bad idea. > >> > >> But I can live with it. > >> > >> Brian > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > >> > >> > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit > > > > > The information contained in this message may be privileged and/or > confidential. If you are not the intended recipient, or responsible for > delivering this message to the intended recipient, any review, forwarding, > dissemination, distribution or copying of this communication or any > attachment(s) is strictly prohibited. If you have received this message in > error, please so notify the sender immediately, and delete it and all > attachments from your computer and network. > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 15:15:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcREm-0001rh-Nq; Fri, 13 Apr 2007 15:15:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcREl-0001rK-44; Fri, 13 Apr 2007 15:15:11 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcREk-0007um-Hq; Fri, 13 Apr 2007 15:15:11 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HcREj-0001lF-5X; Fri, 13 Apr 2007 15:15:09 -0400 Received: from [127.0.0.1] (ros-dhcp233-050-233.bbn.com [192.233.50.233]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l3DJF9w02930; Fri, 13 Apr 2007 15:15:09 -0400 (EDT) Message-ID: <461FD6BC.6050704@bbn.com> Date: Fri, 13 Apr 2007 15:15:08 -0400 From: Richard Barnes User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCP without giving away the store References: <02f401c77de5$678e4bb0$640fa8c0@cis.neustar.com> <461FCFE0.10407@gmx.net> In-Reply-To: <461FCFE0.10407@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fbe0995f04cc21309ef8614a2838e306 Cc: geopriv@ietf.org, "Rosen, Brian" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes, I think you're trying to enable the PSAP to answer the wrong question. There are two questions that one can ask about a call: (1) Is this a valid PSAP URI for this Location (byR)? (2) If this URI a valid PSAP URI? It seems like answering question (2) provides enough information to make charging decisions, and it doesn't require dereferencing a location. Which is nice for several reasons, including that there's no interaction needed between the VSP and the ASP/ISP. Also, note that for mobile targets, question (1) can become false while the call is being routed if the target crosses a PSAP boundary. --Richard Hannes Tschofenig wrote: > Hi Brian, > > > sorry that I confused everything. Maybe I am still suffering from a > post-SDO Emergency Service Workshop syndrome: > > Let me describe the procedure in a message sequence: > > Target => LIS: Request LbyR > > Target<= LIS: LbyR, PSAP URI, Service Number > > Target=> VSP-Proxy: SIP message including LbyR, PSAP URI > > VSP-Proxy=> LIS: Check PSAP URI at LbyR > > VSP-Proxy<= LIS: OK or NOT OK (LIS checks whether the location > information behind the LbyR translates to the PSAP URI presented by the > VSP-Proxy) > > DONE > > Note that yo can replace LIS with LoST server in this example. > > Does this make sense to you? > > Ciao > Hannes > > > Brian Rosen wrote: >> Huh, I didn't get that. >> >> I'd like to eliminate the country code thing, because otherwise we need a >> way to carry it in the SIP Geolocation. However, I don't really want the >> VSP having to ask the ASP/ISP for a dereference of any sort, and I'd >> like to >> minimize the work of the ASP/ISP. The notion that the ASP/ISP has to >> help >> the VSP determine if what it has is a valid PSAP URI strikes me as a >> problem. >> >> Now, you may remember WAAAY WAAY back, I strongly suggested that the geo >> form of location always include a country code. I suggested this for >> disputed areas. The access network is in a very good position to tell >> you >> how best to interpret which country actually is the on-the-ground >> administrator of the location. If you are connected to an Israeli access >> network, and you ask LoST for a PSAP URI, you probably want an Israeli >> fire >> brigade. If you are on a Palestinian access network, then you >> probably want >> a different answer. So, having country code in a PIDF with an >> otherwise geo >> location is actually helpful. >> >> The current answer for this is some kind of manual configuration of >> the LoST >> servers so you get the answer you want. While that can work, I think >> something more automatic might work better, and it fixes the problem. >> >> Brian >> >> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: Friday, April 13, 2007 11:26 AM >>> To: Rosen, Brian >>> Cc: geopriv@ietf.org; ecrit@ietf.org >>> Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do >>> endpoint centric LCP without giving away the store >>> >>> Hi Brian, >>> >>> I only described a different way of doing the verification without >>> returning a country code. >>> I also focus on LbyR only rather than LbyV. >>> >>> Ciao >>> Hannes >>> >>> Rosen, Brian wrote: >>> >>>> Hannes >>>> >>>> I am confused by your message. >>>> >>>> The problem you describe, where a VSP is trying to validate that the >>>> Request URI in what is claimed to be an emergency call is a bona fide >>>> PSAP URI seems to be a valid concern. My message described one way to >>>> do this validation when what the VSP received (in a SIP Geolocation >>>> header) is an LbyR. >>>> >>>> Are you now wondering how you validate when you have an LbyV? I would >>>> think you do the same thing: send the country code (or the whole >>>> location) and the PSAP URI to LoST and ask if the PSAP URI is valid. >>>> This does not require any query by the VSP to the ASP/ISP. The VSP >>>> should be able to query its local LoST server and be referred to the >>>> authoritative server for the location it proffers. >>>> >>>> I'd rather not have to have the VSP try to dereference an LbyR, and if >>>> you have an LbyV then you don't even know, necessarily, who the ASP/ISP >>>> is. >>>> >>>> Is there something else I'm missing here? >>>> >>>> Brian >>>> >>>> >>>>> -----Original Message----- >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> Sent: Friday, April 13, 2007 10:43 AM >>>>> To: Rosen, Brian >>>>> Cc: geopriv@ietf.org; ecrit@ietf.org >>>>> Subject: Re: [Ecrit] Not-so-grand compromise on how to do endpoint >>>>> >>>>> >>>> centric >>>> >>>> >>>>> LCP without giving away the store >>>>> >>>>> Hi Brian, >>>>> >>>>> thanks for posting this message. >>>>> >>>>> When the end host is provided with LbyV and triggers the LoST lookup >>>>> >>>>> >>>> and >>>> >>>> >>>>> routes the call via its VSP then the VSP (in some circumstances*) >>>>> >>>>> >>>> might >>>> >>>> >>>>> want to verify that the PSAP URI in the message indeed corresponds to >>>>> >>>>> >>>> a >>>> >>>> >>>>> PSAP. The idea that was mentioned a long time ago already was to let >>>>> >>>>> >>>> the >>>> >>>> >>>>> VSP to use the location information for LoST and to compare the result >>>>> with the content of the message. >>>>> >>>>> The main goal here is that the VSP does not need to have a "business" >>>>> contract to the ASP/ISP. >>>>> >>>>> Since there is only a location reference that neither the end host nor >>>>> the VSP can dereference it is necessary to enhance the existing >>>>> procedures a bit (as Brian mentioned). >>>>> >>>>> I see two ways todo so: >>>>> >>>>> a) Enhance LoST >>>>> b) Enhance the dereferencing protocol >>>>> >>>>> In both cases you want to have the LbyR as input and the PSAP URI (and >>>>> potentially the service number) as output. >>>>> >>>>> For (a) you would have to address the LoST query to the LoST server in >>>>> the ASP/ISP network and the result would be a nomal LoST response. >>>>> For (b) you would have todo a dereferencing step with an additional >>>>> parameter for "verify only". The response would be similar to the >>>>> >>>>> >>>> lookup >>>> >>>> >>>>> by the end host -- just the identity that is being used for the lookup >>>>> would be different. >>>>> >>>>> Both approaches are possible and since the VSP has to support both >>>>> protocols it does not make a big difference which one to use. >>>>> >>>>> In both cases you would have to compare the result of the lookup with >>>>> the content of the message. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> *: It is only necessary when the VSP charges for individual calls or >>>>> >>>>> >>>> for >>>> >>>> >>>>> specific calls (with the given call falling into this category). >>>>> >>>>> Rosen, Brian wrote: >>>>> >>>>> >>>>>> In the Emergency Services SDO Coordination workshop, a familiar >>>>>> discussion took place: how does location get provided for emergency >>>>>> calls? The real issue is revenue. Access networks have location. >>>>>> >>>>>> >>>> They >>>> >>>> >>>>>> may be willing to (or may be regulated to be required to) provide >>>>>> location for emergency calls. However, they are not willing to give >>>>>> >>>>>> >>>> it >>>> >>>> >>>>>> away for free for other uses. The issue with that is how we support >>>>>> calling networks that don't have relationships with access networks, >>>>>> i.e. the Skype situation. How is location provided such that a >>>>>> >>>>>> >>>> Skype >>>> >>>> >>>>>> emergency call can be placed, but the access network can restrict >>>>>> >>>>>> >>>> what >>>> >>>> >>>>>> else may be done with the location it provides? >>>>>> >>>>>> We have been wrapped around the axle on this for, dare I say, years. >>>>>> >>>>>> So, I think Barbara Stark first described this, and it needs some >>>>>> >>>>>> >>>> work, >>>> >>>> >>>>>> but suppose that, as an option, an access network could supply: >>>>>> >>>>>> 1. A reference to location >>>>>> >>>>>> 2. The results of a LoST query on the location value (viz, PSAP URI >>>>>> >>>>>> >>>> and >>>> >>>> >>>>>> local dialstring) >>>>>> >>>>>> With this, an endpoint could recognize an emergency call and start >>>>>> routing it to the right PSAP. The LIS would agree to dereference >>>>>> >>>>>> >>>> for >>>> >>>> >>>>>> PSAPs, but could restrict other uses of location. >>>>>> >>>>>> Hannes points out that we need one more thing: the calling network >>>>>> >>>>>> >>>> has >>>> >>>> >>>>>> to be able to validate that the PSAP URI really is a PSAP URI so >>>>>> >>>>>> >>>> that >>>> >>>> >>>>>> charging (emergency calls generally are free) is protected. We need >>>>>> >>>>>> >>>> a >>>> >>>> >>>>>> mechanism for them to do that. >>>>>> >>>>>> Perhaps we include in the LoST return a country code for a query >>>>>> >>>>>> >>>> with a >>>> >>>> >>>>>> geo. We add a new operation to LoST that takes a service, a country >>>>>> code and a PSAP URI and returns yes/no validation ("Yes, that URI is >>>>>> >>>>>> >>>> a >>>> >>>> >>>>>> valid URI for that service in that country"). >>>>>> >>>>>> What would we need to do to make this happen? >>>>>> >>>>>> We need extensions to LCPs or some new protocol that returns an LbyR >>>>>> >>>>>> >>>> and >>>> >>>> >>>>>> the LoST results. I wonder if this is just more HELD work. >>>>>> >>>>>> We need the PSAP URI validation. >>>>>> >>>>>> Again, this is optional. The access network may well give up an >>>>>> >>>>>> >>>> LbyV. >>>> >>>> >>>>>> It may give up an LbyR that it will dereference for the endpoint. >>>>>> >>>>>> >>>> The >>>> >>>> >>>>>> access network may have a relationship with the calling network such >>>>>> that the endpoint need not be involved. >>>>>> >>>>>> The PSAP URI validation is actually useful without this idea, >>>>>> >>>>>> >>>> especially >>>> >>>> >>>>>> when location is an LbyR. Instead of having to have the calling >>>>>> >>>>>> >>>> network >>>> >>>> >>>>>> dereference, and then do a LoST query to validate, it can just do >>>>>> >>>>>> >>>> this >>>> >>>> >>>>>> PSAP URI validation. >>>>>> >>>>>> Would this solve our problem? Would access carriers concerned about >>>>>> revenue issues with "giving away" location to it's subscribers be >>>>>> willing to provide LbyR dereferenceable by PSAPs (again remembering >>>>>> >>>>>> >>>> that >>>> >>>> >>>>>> the access network are local to the PSAPs) as well as LoST query >>>>>> services to their endpoints? Would this address the concerns raised >>>>>> >>>>>> >>>> by >>>> >>>> >>>>>> Deutsche Telecom on this issue? >>>>>> >>>>>> Let me be very clear that I think this is an ugly solution. I think >>>>>> that everyone will be much better off if endpoints knew where they >>>>>> >>>>>> >>>> were, >>>> >>>> >>>>>> and apps could take advantage of that. I think we'll get there. I >>>>>> think tying location configuration with the LoST query is a bad >>>>>> >>>>>> >>>> idea. I >>>> >>>> >>>>>> think using LbyR for emergency calls is a bad idea. >>>>>> >>>>>> But I can live with it. >>>>>> >>>>>> Brian >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> >>>>>> >>> >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www1.ietf.org/mailman/listinfo/geopriv >>> > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 15:15:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcRF6-00026d-IC; Fri, 13 Apr 2007 15:15:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcRF4-00025X-Lx; Fri, 13 Apr 2007 15:15:30 -0400 Received: from s-utl01-atpop.stsn.net ([72.254.128.201]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HcRF4-00081i-Ao; Fri, 13 Apr 2007 15:15:30 -0400 Received: from s-utl01-atpop.stsn.net ([127.0.0.1]) by s-utl01-atpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2007041315152512984 ; Fri, 13 Apr 2007 15:15:25 -0400 X-Spam-Status: No, hits=0.0 required=9.9 tests=ALL_TRUSTED: -2.867,AWL: -0.675,BAYES_00: -1.665, BIZ_TLD: 2.434 X-Spam-Level: Received: from [10.0.76.98] ([10.0.76.98]) by s-utl01-atpop.stsn.net; Fri, 13 Apr 2007 15:15:25 -0400 Message-ID: <461FD6C1.5080600@gmx.net> Date: Fri, 13 Apr 2007 21:15:13 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCPwithout giving away the store References: <035a01c77dff$80b9c820$640fa8c0@cis.neustar.com> In-Reply-To: <035a01c77dff$80b9c820$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: geopriv@ietf.org, "Rosen, Brian" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I also believe that this is reasonable assumption with regard to the split of responsibilities in this particular case. Brian Rosen wrote: > I think that is part of the tradeoff an access network makes. If its > restricting access to location, and location is needed to route, then it has > to assume the liability for misroute, since it's providing the route in lieu > of providing location for the VSP to route. > > If it doesn't want to assume that liability, then it has to give location to > someone who does the route, and we're back around that axle again. > > So, I think it's reasonable that the access network deal with misroutes in > this case. > > Brian > > >> -----Original Message----- >> From: Marc Linsner [mailto:mlinsner@cisco.com] >> Sent: Friday, April 13, 2007 1:23 PM >> To: 'Rosen, Brian'; geopriv@ietf.org >> Cc: ecrit@ietf.org >> Subject: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do >> endpointcentric LCPwithout giving away the store >> >> Who is responsible for PSAP mis-routes? I would think this transfers >> liability for routing to the access-provider, are they willing to step up >> to >> that? >> >> -Marc- >> >> >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Friday, April 13, 2007 7:18 AM >>> To: geopriv@ietf.org >>> Cc: ecrit@ietf.org >>> Subject: [Ecrit] Not-so-grand compromise on how to do >>> endpoint centric LCPwithout giving away the store >>> >>> In the Emergency Services SDO Coordination workshop, a >>> familiar discussion took place: how does location get >>> provided for emergency calls? The real issue is revenue. >>> Access networks have location. They may be willing to (or >>> may be regulated to be required to) provide location for >>> emergency calls. However, they are not willing to give it >>> away for free for other uses. The issue with that is how we >>> support calling networks that don't have relationships with >>> access networks, i.e. the Skype situation. How is location >>> provided such that a Skype emergency call can be placed, but >>> the access network can restrict what else may be done with >>> the location it provides? >>> >>> We have been wrapped around the axle on this for, dare I say, years. >>> >>> So, I think Barbara Stark first described this, and it needs >>> some work, but suppose that, as an option, an access network >>> could supply: >>> >>> 1. A reference to location >>> >>> 2. The results of a LoST query on the location value (viz, >>> PSAP URI and local dialstring) >>> >>> With this, an endpoint could recognize an emergency call and >>> start routing it to the right PSAP. The LIS would agree to >>> dereference for PSAPs, but could restrict other uses of location. >>> >>> Hannes points out that we need one more thing: the calling >>> network has to be able to validate that the PSAP URI really >>> is a PSAP URI so that charging (emergency calls generally are >>> free) is protected. We need a mechanism for them to do that. >>> >>> Perhaps we include in the LoST return a country code for a >>> query with a geo. We add a new operation to LoST that takes >>> a service, a country code and a PSAP URI and returns yes/no >>> validation ("Yes, that URI is a valid URI for that service in >>> that country"). >>> >>> What would we need to do to make this happen? >>> >>> We need extensions to LCPs or some new protocol that returns >>> an LbyR and the LoST results. I wonder if this is just more >>> HELD work. >>> >>> We need the PSAP URI validation. >>> >>> Again, this is optional. The access network may well give up an LbyV. >>> It may give up an LbyR that it will dereference for the >>> endpoint. The access network may have a relationship with >>> the calling network such that the endpoint need not be involved. >>> >>> The PSAP URI validation is actually useful without this idea, >>> especially when location is an LbyR. Instead of having to >>> have the calling network dereference, and then do a LoST >>> query to validate, it can just do this PSAP URI validation. >>> >>> Would this solve our problem? Would access carriers >>> concerned about revenue issues with "giving away" location to >>> it's subscribers be willing to provide LbyR dereferenceable >>> by PSAPs (again remembering that the access network are local >>> to the PSAPs) as well as LoST query services to their >>> endpoints? Would this address the concerns raised by >>> Deutsche Telecom on this issue? >>> >>> Let me be very clear that I think this is an ugly solution. >>> I think that everyone will be much better off if endpoints >>> knew where they were, and apps could take advantage of that. >>> I think we'll get there. I think tying location >>> configuration with the LoST query is a bad idea. I think >>> using LbyR for emergency calls is a bad idea. >>> >>> But I can live with it. >>> >>> Brian >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 15:21:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcRL3-0004K7-S9; Fri, 13 Apr 2007 15:21:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcRL2-0004Jw-Rp; Fri, 13 Apr 2007 15:21:40 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcRL2-0002So-Bh; Fri, 13 Apr 2007 15:21:40 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HcRIV-0001BN-07; Fri, 13 Apr 2007 14:19:03 -0500 From: "Brian Rosen" To: "'Liess, Laura'" , "Rosen, Brian" , Subject: RE: [Ecrit] Not-so-grand compromise on how to do endpoint centricLCPwithout giving away the store Date: Fri, 13 Apr 2007 15:21:36 -0400 Message-ID: <035e01c77e00$f5edca50$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd9eBCfZxIYRVO7QJu63bsxYVEIfwAa+3KAAAcFV5A= In-Reply-To: <182C63BFBAF131428EA0C16F7FD2191B013584AB@S4DE8PSAAGM.mitte.t-com.de> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org ESRPs URIs are just PSAP URIs as far as anyone outside the Emergency Services IP Network is concerned. What you get out of LoST is an ESRP = URI or a PSAP URI, and which you get depends on the local emergency = authority's wishes. We don't need to know, and we don't do anything different. Within the ESInet, the ESRP may well use LoST to do further routing. In North America, we imagine a common arrangement would be that a regular = user query to LoST would yield an ESRP URI that was roughly operated at the = state level -- all calls from Virginia go to a (replicated, load balanced) = ESRP. The ESRP may do a further LoST dip, and take into account local = conditions, like congestion and PSAP state, and time of day, and decide which PSAP = will actually get the call. This is invisible to the endpoint, the access network and the VSP. It's = all in what LoST returns. So I don't think we need to specify how ESRPs work. I think the = important part for you is that the access network would trust the ESRP for a dereference the same as it would trust a PSAP. In North America, they = would probably have similar credentials. Brian > -----Original Message----- > From: Liess, Laura [mailto:Laura.Liess@t-systems.com] > Sent: Friday, April 13, 2007 12:49 PM > To: Brian.Rosen@neustar.biz; Hannes.Tschofenig@gmx.net > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: AW: [Ecrit] Not-so-grand compromise on how to do endpoint > centricLCPwithout giving away the store >=20 >=20 > Brian, Hannes, > thank you for bringing up this issue. > In principle, I like the option for the access network to supply the = PSAP > URI. A similar option could be for the AN to provide an ESRP URI. The > ESRP URI is for the AN a trusted party, so it has the necessary > credentials to fetch the Location Info from the LIS. >=20 > I figured out how such a scenario could work >=20 >=20 >=20 > Configuration VSP's LoST > Alice Servers SIP proxy ESRP Servers > PSAP >=20 > ***Alice gets IP-connectivity**** > [M1] DHCP (with LbyR, country code and ESRP URI) > <--------- >=20 > ***Some time later, Alice dials/initiates emergency call*** > [M2] INVITE (sos URN or 911/112, contains LbyR, country code and > ESRP URI) > -------------------------------> > [M3] LoST Query (contains country code = and > ESRP URI) > ---------------------------> > [M4] LoST Response (contains a mark if = ESRP > URI is valid) > <---------------------------- > [M5] INVITE (sos URN or = 911/112, > contains LbyR) > -------------> > [M6] HTTPS(contains LbyR) > <---------------------------------- > [M7] HTTPS(contains Location) > ---------------------------------> > [M8] LoST Query > (contains Location) > = ---------------------> > [M9] LoST Response (contains > PSAP URI) > = <---------------------- > [M10] INVITE = (contains > Location) > = ----------------------- > ------------> > 200 OK > = <---------------------------------------------------------------- > --------------- > ACK > = ----------------------------------------------------------------- > --------------> >=20 >=20 > I think if there is a local ESRP between the VSP's SIP Proxy and the = PSAP > we are more flexible to comply to country-specific regulations. > The ESRP could choose the PSAP based on a local LoST server which = knows > the capabilities of the local PSAPs. E.g. during a transition period = we > may have the old PSTN PSAPs and very few IP PSAPs with additional > capabilities, e. g. emergency call takers speaking foreign languages = or > emergency call takers for deaf people. The local LoST server would be = able > to choose the right PSAP (this is just an idea, I don't know whether = or > not it's realistic). >=20 >=20 > Thanks > Laura >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > Gesendet: Freitag, 13. April 2007 13:18 > > An: geopriv@ietf.org > > Cc: ecrit@ietf.org > > Betreff: [Ecrit] Not-so-grand compromise on how to do > > endpoint centric LCPwithout giving away the store > > > > > > In the Emergency Services SDO Coordination workshop, a > > familiar discussion took place: how does location get > > provided for emergency calls? The real issue is revenue. > > Access networks have location. They may be willing to (or > > may be regulated to be required to) provide location for > > emergency calls. However, they are not willing to give it > > away for free for other uses. The issue with that is how we > > support calling networks that don't have relationships with > > access networks, i.e. the Skype situation. How is location > > provided such that a Skype emergency call can be placed, but > > the access network can restrict what else may be done with > > the location it provides? > > > > We have been wrapped around the axle on this for, dare I say, years. > > > > So, I think Barbara Stark first described this, and it needs > > some work, but suppose that, as an option, an access network > > could supply: > > > > 1. A reference to location > > > > 2. The results of a LoST query on the location value (viz, > > PSAP URI and local dialstring) > > > > With this, an endpoint could recognize an emergency call and > > start routing it to the right PSAP. The LIS would agree to > > dereference for PSAPs, but could restrict other uses of location. > > > > Hannes points out that we need one more thing: the calling > > network has to be able to validate that the PSAP URI really > > is a PSAP URI so that charging (emergency calls generally are > > free) is protected. We need a mechanism for them to do that. > > > > Perhaps we include in the LoST return a country code for a > > query with a geo. We add a new operation to LoST that takes > > a service, a country code and a PSAP URI and returns yes/no > > validation ("Yes, that URI is a valid URI for that service in > > that country"). > > > > What would we need to do to make this happen? > > > > We need extensions to LCPs or some new protocol that returns > > an LbyR and the LoST results. I wonder if this is just more > > HELD work. > > > > We need the PSAP URI validation. > > > > Again, this is optional. The access network may well give up > > an LbyV. It may give up an LbyR that it will dereference for > > the endpoint. The access network may have a relationship > > with the calling network such that the endpoint need not be = involved. > > > > The PSAP URI validation is actually useful without this idea, > > especially when location is an LbyR. Instead of having to > > have the calling network dereference, and then do a LoST > > query to validate, it can just do this PSAP URI validation. > > > > Would this solve our problem? Would access carriers > > concerned about revenue issues with "giving away" location to > > it's subscribers be willing to provide LbyR dereferenceable > > by PSAPs (again remembering that the access network are local > > to the PSAPs) as well as LoST query services to their > > endpoints? Would this address the concerns raised by > > Deutsche Telecom on this issue? > > > > Let me be very clear that I think this is an ugly solution. > > I think that everyone will be much better off if endpoints > > knew where they were, and apps could take advantage of that. > > I think we'll get there. I think tying location > > configuration with the LoST query is a bad idea. I think > > using LbyR for emergency calls is a bad idea. > > > > But I can live with it. > > > > Brian > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 15:25:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcROE-0006Xk-4C; Fri, 13 Apr 2007 15:24:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcROC-0006XZ-UX; Fri, 13 Apr 2007 15:24:56 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcROC-0003rx-I1; Fri, 13 Apr 2007 15:24:56 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HcROC-0001xI-41; Fri, 13 Apr 2007 15:24:56 -0400 Received: from [127.0.0.1] (ros-dhcp233-050-233.bbn.com [192.233.50.233]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l3DJOtw05275; Fri, 13 Apr 2007 15:24:55 -0400 (EDT) Message-ID: <461FD906.3040905@bbn.com> Date: Fri, 13 Apr 2007 15:24:54 -0400 From: Richard Barnes User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCPwithout giving away the store References: <035a01c77dff$80b9c820$640fa8c0@cis.neustar.com> In-Reply-To: <035a01c77dff$80b9c820$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: geopriv@ietf.org, "Rosen, Brian" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I would state things more generally: If you're going to restrict access to location information, then you bear liability for failures resulting from that restriction. That way, if the AN provides routing, then it's responsible for routing working correctly. If the AN wants to out-source mapping , then it's responsible for mapping failures caused by the mapping function not having access to location -- but NOT other mapping failures, like a bad cached mapping. --Richard Brian Rosen wrote: > I think that is part of the tradeoff an access network makes. If its > restricting access to location, and location is needed to route, then it has > to assume the liability for misroute, since it's providing the route in lieu > of providing location for the VSP to route. > > If it doesn't want to assume that liability, then it has to give location to > someone who does the route, and we're back around that axle again. > > So, I think it's reasonable that the access network deal with misroutes in > this case. > > Brian > >> -----Original Message----- >> From: Marc Linsner [mailto:mlinsner@cisco.com] >> Sent: Friday, April 13, 2007 1:23 PM >> To: 'Rosen, Brian'; geopriv@ietf.org >> Cc: ecrit@ietf.org >> Subject: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do >> endpointcentric LCPwithout giving away the store >> >> Who is responsible for PSAP mis-routes? I would think this transfers >> liability for routing to the access-provider, are they willing to step up >> to >> that? >> >> -Marc- >> >>> -----Original Message----- >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Friday, April 13, 2007 7:18 AM >>> To: geopriv@ietf.org >>> Cc: ecrit@ietf.org >>> Subject: [Ecrit] Not-so-grand compromise on how to do >>> endpoint centric LCPwithout giving away the store >>> >>> In the Emergency Services SDO Coordination workshop, a >>> familiar discussion took place: how does location get >>> provided for emergency calls? The real issue is revenue. >>> Access networks have location. They may be willing to (or >>> may be regulated to be required to) provide location for >>> emergency calls. However, they are not willing to give it >>> away for free for other uses. The issue with that is how we >>> support calling networks that don't have relationships with >>> access networks, i.e. the Skype situation. How is location >>> provided such that a Skype emergency call can be placed, but >>> the access network can restrict what else may be done with >>> the location it provides? >>> >>> We have been wrapped around the axle on this for, dare I say, years. >>> >>> So, I think Barbara Stark first described this, and it needs >>> some work, but suppose that, as an option, an access network >>> could supply: >>> >>> 1. A reference to location >>> >>> 2. The results of a LoST query on the location value (viz, >>> PSAP URI and local dialstring) >>> >>> With this, an endpoint could recognize an emergency call and >>> start routing it to the right PSAP. The LIS would agree to >>> dereference for PSAPs, but could restrict other uses of location. >>> >>> Hannes points out that we need one more thing: the calling >>> network has to be able to validate that the PSAP URI really >>> is a PSAP URI so that charging (emergency calls generally are >>> free) is protected. We need a mechanism for them to do that. >>> >>> Perhaps we include in the LoST return a country code for a >>> query with a geo. We add a new operation to LoST that takes >>> a service, a country code and a PSAP URI and returns yes/no >>> validation ("Yes, that URI is a valid URI for that service in >>> that country"). >>> >>> What would we need to do to make this happen? >>> >>> We need extensions to LCPs or some new protocol that returns >>> an LbyR and the LoST results. I wonder if this is just more >>> HELD work. >>> >>> We need the PSAP URI validation. >>> >>> Again, this is optional. The access network may well give up an LbyV. >>> It may give up an LbyR that it will dereference for the >>> endpoint. The access network may have a relationship with >>> the calling network such that the endpoint need not be involved. >>> >>> The PSAP URI validation is actually useful without this idea, >>> especially when location is an LbyR. Instead of having to >>> have the calling network dereference, and then do a LoST >>> query to validate, it can just do this PSAP URI validation. >>> >>> Would this solve our problem? Would access carriers >>> concerned about revenue issues with "giving away" location to >>> it's subscribers be willing to provide LbyR dereferenceable >>> by PSAPs (again remembering that the access network are local >>> to the PSAPs) as well as LoST query services to their >>> endpoints? Would this address the concerns raised by >>> Deutsche Telecom on this issue? >>> >>> Let me be very clear that I think this is an ugly solution. >>> I think that everyone will be much better off if endpoints >>> knew where they were, and apps could take advantage of that. >>> I think we'll get there. I think tying location >>> configuration with the LoST query is a bad idea. I think >>> using LbyR for emergency calls is a bad idea. >>> >>> But I can live with it. >>> >>> Brian >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 15:35:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcRYe-0005Ck-7U; Fri, 13 Apr 2007 15:35:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcRYc-0005Cb-W9; Fri, 13 Apr 2007 15:35:42 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcRYc-0007IJ-LK; Fri, 13 Apr 2007 15:35:42 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns0.neustar.com (Postfix) with ESMTP id 99EB8329D6; Fri, 13 Apr 2007 19:35:42 +0000 (GMT) Received: from stntexch12.cis.neustar.com ([10.31.13.31]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 15:35:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCPwithout giving away the store Date: Fri, 13 Apr 2007 15:35:42 -0400 Message-ID: <886DD03D15173C43BCE98EA662A0101A01EB72C1@stntexch12.cis.neustar.com> In-Reply-To: <0AB57A5DEF898646A069F23604A263536F4AC1@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCPwithout giving away the store Thread-Index: Acd9eBCfZxIYRVO7QJu63bsxYVEIfwAZ38qQAAGc92A= From: "Rosen, Brian" To: "Barclay, Deborah L (Deb)" , X-OriginalArrivalTime: 13 Apr 2007 19:35:42.0501 (UTC) FILETIME=[EC6DED50:01C77E02] X-Spam-Score: -2.3 (--) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Deb There is a tradeoff here between providing some kind of location when, for whatever reason, you can't get current location at the time of the call, and the cost of engaging the location determination mechanism. Once at boot and periodically thereafter is not going to be a problem for measurement systems that provide constant high quality measurements. It's much more of a problem for the current crop of mobile networks that can only provide a coarse location quick, and take much more time (and expend more resources) to get an accurate location. In such networks, what you get from the boot and periodically thereafter queerly is the coarse location, which is by definition fast, and usually low resource consumption. Of course, it also could be a location reference, which doesn't typically change, but even if it did (as it might when changing visited networks), and it would be available instantly, with no resource expenditure. The visited network could quite easily cache the LoST route for the coarse location, so that wouldn't be much work either. Brian > -----Original Message----- > From: Barclay, Deborah L (Deb) [mailto:dlbarclay@alcatel-lucent.com] > Sent: Friday, April 13, 2007 12:08 PM > To: Rosen, Brian; geopriv@ietf.org > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Not-so-grand compromise on how to do endpoint centric > LCPwithout giving away the store >=20 > Hi Brian, >=20 > The ecrit bcp recommends obtaining location on power-up/registration and > then refresh often/occasionally. >=20 > That means endpoints may obtain location frequently but never use it for > an emergency call. >=20 > I thought business models often worked on a pay per dip basis. >=20 > For cellular endpoints, network based and network assisted position > determination are very complex and resource intensive - requiring > auxiliary equipment for position determination. >=20 > Due to the impact on network resources, I'm not sure obtaining position > whenever requested and never being charged will be a viable model for > some technologies. >=20 > Deb >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Friday, April 13, 2007 6:18 AM > To: geopriv@ietf.org > Cc: ecrit@ietf.org > Subject: [Ecrit] Not-so-grand compromise on how to do endpoint centric > LCPwithout giving away the store >=20 > In the Emergency Services SDO Coordination workshop, a familiar > discussion took place: how does location get provided for emergency > calls? The real issue is revenue. Access networks have location. They > may be willing to (or may be regulated to be required to) provide > location for emergency calls. However, they are not willing to give it > away for free for other uses. The issue with that is how we support > calling networks that don't have relationships with access networks, > i.e. the Skype situation. How is location provided such that a Skype > emergency call can be placed, but the access network can restrict what > else may be done with the location it provides? >=20 > We have been wrapped around the axle on this for, dare I say, years. >=20 > So, I think Barbara Stark first described this, and it needs some work, > but suppose that, as an option, an access network could supply: >=20 > 1. A reference to location >=20 > 2. The results of a LoST query on the location value (viz, PSAP URI and > local dialstring) >=20 > With this, an endpoint could recognize an emergency call and start > routing it to the right PSAP. The LIS would agree to dereference for > PSAPs, but could restrict other uses of location. >=20 > Hannes points out that we need one more thing: the calling network has > to be able to validate that the PSAP URI really is a PSAP URI so that > charging (emergency calls generally are free) is protected. We need a > mechanism for them to do that. >=20 > Perhaps we include in the LoST return a country code for a query with a > geo. We add a new operation to LoST that takes a service, a country > code and a PSAP URI and returns yes/no validation ("Yes, that URI is a > valid URI for that service in that country"). >=20 > What would we need to do to make this happen? >=20 > We need extensions to LCPs or some new protocol that returns an LbyR and > the LoST results. I wonder if this is just more HELD work. >=20 > We need the PSAP URI validation. >=20 > Again, this is optional. The access network may well give up an LbyV. > It may give up an LbyR that it will dereference for the endpoint. The > access network may have a relationship with the calling network such > that the endpoint need not be involved. >=20 > The PSAP URI validation is actually useful without this idea, especially > when location is an LbyR. Instead of having to have the calling network > dereference, and then do a LoST query to validate, it can just do this > PSAP URI validation. >=20 > Would this solve our problem? Would access carriers concerned about > revenue issues with "giving away" location to it's subscribers be > willing to provide LbyR dereferenceable by PSAPs (again remembering that > the access network are local to the PSAPs) as well as LoST query > services to their endpoints? Would this address the concerns raised by > Deutsche Telecom on this issue? >=20 > Let me be very clear that I think this is an ugly solution. I think > that everyone will be much better off if endpoints knew where they were, > and apps could take advantage of that. I think we'll get there. I > think tying location configuration with the LoST query is a bad idea. I > think using LbyR for emergency calls is a bad idea. >=20 > But I can live with it. >=20 > Brian >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 17:17:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcT8n-0005Cw-NJ; Fri, 13 Apr 2007 17:17:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcT8n-0005Co-5k; Fri, 13 Apr 2007 17:17:09 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcT8l-0004Zk-Hl; Fri, 13 Apr 2007 17:17:09 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Fri, 13 Apr 2007 23:17:04 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 23:17:03 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: AW: [Ecrit] Not-so-grand compromise on how to do endpoint centricLCPwithout giving away the store Date: Fri, 13 Apr 2007 23:17:03 +0200 Message-Id: <182C63BFBAF131428EA0C16F7FD2191B013584AC@S4DE8PSAAGM.mitte.t-com.de> In-reply-to: <461FCD35.4080403@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Ecrit] Not-so-grand compromise on how to do endpoint centricLCPwithout giving away the store Thread-Index: Acd9+m92ydUvJHorT7WwyThU2PITLAAEk3og From: "Liess, Laura" To: X-OriginalArrivalTime: 13 Apr 2007 21:17:03.0880 (UTC) FILETIME=[1536B880:01C77E11] X-Spam-Score: 0.5 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: geopriv@ietf.org, Brian.Rosen@neustar.biz, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes, I didn't mean the ERSP being in the access network, but rather what = Brian describes in his answer, ESRPs operated at country or state level. = Depending on the granularity of ESRPs, they could be configured into the = access network data (e.g. if they are operated at country level)or the = access network can do LoST queries.=20 ("Local ESRP" was probably quite misleading.)=20 Laura -----Urspr=FCngliche Nachricht----- > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Gesendet: Freitag, 13. April 2007 20:34 > An: Liess, Laura > Cc: geopriv@ietf.org; Brian.Rosen@neustar.biz; ecrit@ietf.org > Betreff: Re: AW: [Ecrit] Not-so-grand compromise on how to do=20 > endpoint centricLCPwithout giving away the store >=20 >=20 > Hi Laura, >=20 > in some sense your proposal is similar to use a SIP proxy in=20 > the access=20 > network (or someone that is closely related to it). Couldn't=20 > we just use=20 > the DHCP discovery technique for SIP proxies for that purpose? >=20 > Ciao > Hannes >=20 > Liess, Laura wrote: > > Brian, Hannes, > > thank you for bringing up this issue. > > In principle, I like the option for the access network to=20 > supply the PSAP URI. A similar option could be for the AN to=20 > provide an ESRP URI. The ESRP URI is for the AN a trusted=20 > party, so it has the necessary credentials to fetch the=20 > Location Info from the LIS.=20 > > > > I figured out how such a scenario could work > > > > > > > > Configuration VSP's =09 > LoST > > Alice Servers SIP proxy =20 > ESRP Servers PSAP > > > > ***Alice gets IP-connectivity**** =20 > > [M1] DHCP (with LbyR, country code and ESRP URI) > > <--------- > > > > ***Some time later, Alice dials/initiates emergency call*** > > [M2] INVITE (sos URN or 911/112, contains LbyR,=20 > country code and ESRP URI) > > -------------------------------> > > [M3] LoST Query (contains=20 > country code and ESRP URI) > > =20 > ---------------------------> > > [M4] LoST Response (contains=20 > a mark if ESRP URI is valid) > > =20 > <---------------------------- > > [M5] INVITE (sos=20 > URN or 911/112, contains LbyR) > > -------------> > > [M6] HTTPS(contains LbyR) > > <---------------------------------- > > [M7] HTTPS(contains Location) > > ---------------------------------> > > [M8] LoST=20 > Query (contains Location) > > =20 > ---------------------> > > [M9] LoST=20 > Response (contains PSAP URI)=20 > > =20 > <---------------------- > > [M10]=20 > INVITE (contains Location) > > =20 > -----------------------------------> > > 200 OK > > =20 > <------------------------------------------------------------- > ------------------ > > ACK > > =20 > >=20 > ---------------------------------------------------------------------- > > ---------> > > > > > > I think if there is a local ESRP between the VSP's SIP=20 > Proxy and the=20 > > PSAP we are more flexible to comply to country-specific regulations. > > The ESRP could choose the PSAP based on a local LoST server=20 > which knows the capabilities of the local PSAPs. E.g. during=20 > a transition period we may have the old PSTN PSAPs and very=20 > few IP PSAPs with additional capabilities, e. g. emergency=20 > call takers speaking foreign languages or emergency call=20 > takers for deaf people. The local LoST server would be able=20 > to choose the right PSAP (this is just an idea, I don't know=20 > whether or not it's realistic).=20 > > > > > > Thanks > > Laura > > > > =20 > > =20 > > > > =20 > > > > > > =20 > >> -----Urspr=FCngliche Nachricht----- > >> Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > >> Gesendet: Freitag, 13. April 2007 13:18 > >> An: geopriv@ietf.org > >> Cc: ecrit@ietf.org > >> Betreff: [Ecrit] Not-so-grand compromise on how to do=20 > >> endpoint centric LCPwithout giving away the store > >> > >> > >> In the Emergency Services SDO Coordination workshop, a > >> familiar discussion took place: how does location get=20 > >> provided for emergency calls? The real issue is revenue. =20 > >> Access networks have location. They may be willing to (or=20 > >> may be regulated to be required to) provide location for=20 > >> emergency calls. However, they are not willing to give it=20 > >> away for free for other uses. The issue with that is how we=20 > >> support calling networks that don't have relationships with=20 > >> access networks, i.e. the Skype situation. How is location=20 > >> provided such that a Skype emergency call can be placed, but=20 > >> the access network can restrict what else may be done with=20 > >> the location it provides? > >> > >> We have been wrapped around the axle on this for, dare I=20 > say, years. > >> > >> So, I think Barbara Stark first described this, and it needs > >> some work, but suppose that, as an option, an access network=20 > >> could supply: > >> > >> 1. A reference to location > >> > >> 2. The results of a LoST query on the location value (viz, > >> PSAP URI and local dialstring) > >> > >> With this, an endpoint could recognize an emergency call and > >> start routing it to the right PSAP. The LIS would agree to=20 > >> dereference for PSAPs, but could restrict other uses of location. > >> > >> Hannes points out that we need one more thing: the calling > >> network has to be able to validate that the PSAP URI really=20 > >> is a PSAP URI so that charging (emergency calls generally are=20 > >> free) is protected. We need a mechanism for them to do that. =20 > >> > >> Perhaps we include in the LoST return a country code for a > >> query with a geo. We add a new operation to LoST that takes=20 > >> a service, a country code and a PSAP URI and returns yes/no=20 > >> validation ("Yes, that URI is a valid URI for that service in=20 > >> that country"). > >> > >> What would we need to do to make this happen? > >> > >> We need extensions to LCPs or some new protocol that returns > >> an LbyR and the LoST results. I wonder if this is just more=20 > >> HELD work. > >> > >> We need the PSAP URI validation. > >> > >> Again, this is optional. The access network may well give up > >> an LbyV. It may give up an LbyR that it will dereference for=20 > >> the endpoint. The access network may have a relationship=20 > >> with the calling network such that the endpoint need not=20 > be involved. > >> > >> The PSAP URI validation is actually useful without this idea, > >> especially when location is an LbyR. Instead of having to=20 > >> have the calling network dereference, and then do a LoST=20 > >> query to validate, it can just do this PSAP URI validation. > >> > >> Would this solve our problem? Would access carriers > >> concerned about revenue issues with "giving away" location to=20 > >> it's subscribers be willing to provide LbyR dereferenceable=20 > >> by PSAPs (again remembering that the access network are local=20 > >> to the PSAPs) as well as LoST query services to their=20 > >> endpoints? Would this address the concerns raised by=20 > >> Deutsche Telecom on this issue? > >> > >> Let me be very clear that I think this is an ugly solution. > >> I think that everyone will be much better off if endpoints=20 > >> knew where they were, and apps could take advantage of that. =20 > >> I think we'll get there. I think tying location=20 > >> configuration with the LoST query is a bad idea. I think=20 > >> using LbyR for emergency calls is a bad idea. > >> > >> But I can live with it. > >> > >> Brian > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > >> > >> =20 >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 13 18:04:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcTsK-00030M-PW; Fri, 13 Apr 2007 18:04:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcTsJ-000308-Vf; Fri, 13 Apr 2007 18:04:11 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcTsJ-0005by-0l; Fri, 13 Apr 2007 18:04:11 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Sat, 14 Apr 2007 00:04:10 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Apr 2007 00:04:09 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [Ecrit] Not-so-grand compromise on how to do endpointcentricLCPwithout giving away the store Date: Sat, 14 Apr 2007 00:04:08 +0200 Message-Id: <182C63BFBAF131428EA0C16F7FD2191B013584AD@S4DE8PSAAGM.mitte.t-com.de> In-reply-to: <035e01c77e00$f5edca50$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Not-so-grand compromise on how to do endpointcentricLCPwithout giving away the store Thread-Index: Acd9eBCfZxIYRVO7QJu63bsxYVEIfwAa+3KAAAcFV5AABKTqMA== From: "Liess, Laura" To: , , X-OriginalArrivalTime: 13 Apr 2007 22:04:09.0658 (UTC) FILETIME=[A98239A0:01C77E17] X-Spam-Score: 0.5 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, I agreee with you. And I think this is a model that almost everyone can = live with. We just need a way to convey the PSAP/ESRP URI from the = access network to the client.=20 Something like draft-polk-dhc-uri-03.txt? But the document is currently = expired. =20 Laura > -----Urspr=FCngliche Nachricht----- > Von: Brian Rosen [mailto:br@brianrosen.net]=20 > Gesendet: Freitag, 13. April 2007 21:22 > An: Liess, Laura; Rosen, Brian; Hannes.Tschofenig@gmx.net > Cc: geopriv@ietf.org; ecrit@ietf.org > Betreff: RE: [Ecrit] Not-so-grand compromise on how to do=20 > endpointcentricLCPwithout giving away the store >=20 >=20 > ESRPs URIs are just PSAP URIs as far as anyone outside the=20 > Emergency Services IP Network is concerned. What you get out=20 > of LoST is an ESRP URI or a PSAP URI, and which you get=20 > depends on the local emergency authority's > wishes. We don't need to know, and we don't do anything different. >=20 > Within the ESInet, the ESRP may well use LoST to do further=20 > routing. In North America, we imagine a common arrangement=20 > would be that a regular user query to LoST would yield an=20 > ESRP URI that was roughly operated at the state level -- all=20 > calls from Virginia go to a (replicated, load balanced) ESRP.=20 > The ESRP may do a further LoST dip, and take into account=20 > local conditions, like congestion and PSAP state, and time of=20 > day, and decide which PSAP will actually get the call. >=20 > This is invisible to the endpoint, the access network and the=20 > VSP. It's all in what LoST returns. >=20 > So I don't think we need to specify how ESRPs work. I think=20 > the important part for you is that the access network would=20 > trust the ESRP for a dereference the same as it would trust a=20 > PSAP. In North America, they would probably have similar credentials. >=20 > Brian >=20 > > -----Original Message----- > > From: Liess, Laura [mailto:Laura.Liess@t-systems.com] > > Sent: Friday, April 13, 2007 12:49 PM > > To: Brian.Rosen@neustar.biz; Hannes.Tschofenig@gmx.net > > Cc: geopriv@ietf.org; ecrit@ietf.org > > Subject: AW: [Ecrit] Not-so-grand compromise on how to do endpoint=20 > > centricLCPwithout giving away the store > >=20 > >=20 > > Brian, Hannes, > > thank you for bringing up this issue. > > In principle, I like the option for the access network to=20 > supply the=20 > > PSAP URI. A similar option could be for the AN to provide=20 > an ESRP URI. =20 > > The ESRP URI is for the AN a trusted party, so it has the necessary=20 > > credentials to fetch the Location Info from the LIS. > >=20 > > I figured out how such a scenario could work > >=20 > >=20 > >=20 > > Configuration VSP's =09 > LoST > > Alice Servers SIP proxy ESRP > Servers > > PSAP > >=20 > > ***Alice gets IP-connectivity**** > > [M1] DHCP (with LbyR, country code and ESRP URI) > > <--------- > >=20 > > ***Some time later, Alice dials/initiates emergency call*** > > [M2] INVITE (sos URN or 911/112, contains LbyR,=20 > country code and=20 > > ESRP URI) > > -------------------------------> > > [M3] LoST Query (contains=20 > country code=20 > > and ESRP URI) > > =20 > ---------------------------> > > [M4] LoST Response (contains=20 > a mark if=20 > > ESRP URI is valid) > > =20 > <---------------------------- > > [M5] INVITE (sos URN or=20 > > 911/112, contains LbyR) > > -------------> > > [M6] HTTPS(contains LbyR) > > <---------------------------------- > > [M7] HTTPS(contains Location) > > ---------------------------------> > > [M8] LoST Query=20 > > (contains Location) > > =20 > ---------------------> > > [M9] LoST Response > (contains > > PSAP URI) > > =20 > <---------------------- > > [M10] INVITE=20 > > (contains > > Location) > > =20 > ----------------------- > > ------------> > > 200 OK > > =20 > > <---------------------------------------------------------------- > > --------------- > > ACK > > =20 > ----------------------------------------------------------------- > > --------------> > >=20 > >=20 > > I think if there is a local ESRP between the VSP's SIP=20 > Proxy and the=20 > > PSAP we are more flexible to comply to country-specific=20 > regulations.=20 > > The ESRP could choose the PSAP based on a local LoST server which=20 > > knows the capabilities of the local PSAPs. E.g. during a transition=20 > > period we may have the old PSTN PSAPs and very few IP PSAPs with=20 > > additional capabilities, e. g. emergency call takers=20 > speaking foreign=20 > > languages or emergency call takers for deaf people. The local LoST=20 > > server would be able to choose the right PSAP (this is just=20 > an idea, I=20 > > don't know whether or not it's realistic). > >=20 > >=20 > > Thanks > > Laura > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > Gesendet: Freitag, 13. April 2007 13:18 > > > An: geopriv@ietf.org > > > Cc: ecrit@ietf.org > > > Betreff: [Ecrit] Not-so-grand compromise on how to do endpoint=20 > > > centric LCPwithout giving away the store > > > > > > > > > In the Emergency Services SDO Coordination workshop, a familiar=20 > > > discussion took place: how does location get provided for=20 > emergency=20 > > > calls? The real issue is revenue. Access networks have=20 > location. =20 > > > They may be willing to (or may be regulated to be required to)=20 > > > provide location for emergency calls. However, they are=20 > not willing=20 > > > to give it away for free for other uses. The issue with=20 > that is how=20 > > > we support calling networks that don't have relationships with > > > access networks, i.e. the Skype situation. How is location > > > provided such that a Skype emergency call can be placed, but > > > the access network can restrict what else may be done with > > > the location it provides? > > > > > > We have been wrapped around the axle on this for, dare I=20 > say, years. > > > > > > So, I think Barbara Stark first described this, and it needs some=20 > > > work, but suppose that, as an option, an access network could=20 > > > supply: > > > > > > 1. A reference to location > > > > > > 2. The results of a LoST query on the location value=20 > (viz, PSAP URI=20 > > > and local dialstring) > > > > > > With this, an endpoint could recognize an emergency call=20 > and start=20 > > > routing it to the right PSAP. The LIS would agree to dereference=20 > > > for PSAPs, but could restrict other uses of location. > > > > > > Hannes points out that we need one more thing: the=20 > calling network=20 > > > has to be able to validate that the PSAP URI really is a=20 > PSAP URI so=20 > > > that charging (emergency calls generally are > > > free) is protected. We need a mechanism for them to do that. > > > > > > Perhaps we include in the LoST return a country code for a query=20 > > > with a geo. We add a new operation to LoST that takes a=20 > service, a=20 > > > country code and a PSAP URI and returns yes/no validation ("Yes,=20 > > > that URI is a valid URI for that service in that country"). > > > > > > What would we need to do to make this happen? > > > > > > We need extensions to LCPs or some new protocol that=20 > returns an LbyR=20 > > > and the LoST results. I wonder if this is just more HELD work. > > > > > > We need the PSAP URI validation. > > > > > > Again, this is optional. The access network may well give up an=20 > > > LbyV. It may give up an LbyR that it will dereference for the=20 > > > endpoint. The access network may have a relationship with the=20 > > > calling network such that the endpoint need not be involved. > > > > > > The PSAP URI validation is actually useful without this idea,=20 > > > especially when location is an LbyR. Instead of having=20 > to have the=20 > > > calling network dereference, and then do a LoST query to=20 > validate,=20 > > > it can just do this PSAP URI validation. > > > > > > Would this solve our problem? Would access carriers=20 > concerned about=20 > > > revenue issues with "giving away" location to it's subscribers be=20 > > > willing to provide LbyR dereferenceable by PSAPs (again=20 > remembering=20 > > > that the access network are local to the PSAPs) as well as LoST=20 > > > query services to their endpoints? Would this address=20 > the concerns=20 > > > raised by Deutsche Telecom on this issue? > > > > > > Let me be very clear that I think this is an ugly=20 > solution. I think=20 > > > that everyone will be much better off if endpoints knew=20 > where they=20 > > > were, and apps could take advantage of that. I think we'll get=20 > > > there. I think tying location configuration with the=20 > LoST query is=20 > > > a bad idea. I think using LbyR for emergency calls is a bad idea. > > > > > > But I can live with it. > > > > > > Brian > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 14 12:02:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hckhe-0007Ng-ST; Sat, 14 Apr 2007 12:02:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hckhe-0007NV-1D for ecrit@ietf.org; Sat, 14 Apr 2007 12:02:18 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hckhc-0003X1-Ko for ecrit@ietf.org; Sat, 14 Apr 2007 12:02:18 -0400 Received: (qmail invoked by alias); 14 Apr 2007 16:02:13 -0000 Received: from ip-90-187-241-23.web.vodafone.de (EHLO [90.187.241.23]) [90.187.241.23] by mail.gmx.net (mp037) with SMTP; 14 Apr 2007 18:02:13 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18eOkY2aE4eho+N/FR6cBpyALxaJ52FZzbDJmz3yR OJe85LUNv5F7ax Message-ID: <4620FAF8.2020201@gmx.net> Date: Sat, 14 Apr 2007 18:02:00 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Rosen, Brian" Subject: Re: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCP without giving away the store References: <886DD03D15173C43BCE98EA662A0101A01EB70D2@stntexch12.cis.neustar.com> In-Reply-To: <886DD03D15173C43BCE98EA662A0101A01EB70D2@stntexch12.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian, ~snip~ > Perhaps we include in the LoST return a country code for a query with a > geo. We add a new operation to LoST that takes a service, a country > code and a PSAP URI and returns yes/no validation ("Yes, that URI is a > valid URI for that service in that country"). > Please describe when the country code is returned and to whom. Who triggers the validation step? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 14 12:41:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HclK2-0002ip-UQ; Sat, 14 Apr 2007 12:41:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HclK1-0002id-Qp for ecrit@ietf.org; Sat, 14 Apr 2007 12:41:57 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HclK0-0006Bo-BT for ecrit@ietf.org; Sat, 14 Apr 2007 12:41:57 -0400 Received: (qmail invoked by alias); 14 Apr 2007 16:41:53 -0000 Received: from ip-90-186-255-89.web.vodafone.de (EHLO [90.186.255.89]) [90.186.255.89] by mail.gmx.net (mp034) with SMTP; 14 Apr 2007 18:41:53 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18UB1UwJLEUFwGUcfqODA7KnvPD/kAeDnZ1UqD/PL wUJzQEwJ2YOKBw Message-ID: <46210449.3020709@gmx.net> Date: Sat, 14 Apr 2007 18:41:45 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] LoST civic caching issue References: <2148EBA7-F442-43CE-BB62-5AD0B18BCFE9@cs.columbia.edu> In-Reply-To: <2148EBA7-F442-43CE-BB62-5AD0B18BCFE9@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Henning, thanks for raising this issue and it is in fact a difficult problem. I see two aspects with the "the donut problem", i.e., there is a larger service boundary with another service area within (the hole in the donut). There are two cases: * The entity responsible for the larger service area knows that there is a donut problem. In this case it would be reasonable to assume that this entity could mark the response as "non cachable". For geo one would want to express the service area as a donut -- currently we don't have a description how to describe such a shape. I now believe that we should add something to the PIDF-LO profile draft. * The entity responsible for the larger service area does NOT know about a potential donut problem. This case is actually not related to civic since it can appear in geo as well. I don't have an easy and nice answer for this case. Ciao Hannes Henning Schulzrinne wrote: > During our implementation of caching in LoST, one of my students came > up with the following interesting issue: > > Suppose that a system has cached a mapping for city=New York, state=NY > and somebody moves the client to a place within that region that has > its own mapping, e.g., a college campus. (Similar issues arise for > places where a county has one mapping, with some part, e.g., the > incorporated area, having a more specific mapping.) In those cases, a > client would notice that the address has changed, but it still matches > the old mapping, so it will not re-query. > > A related problem occurs if, during a failure, a default response has > been returned. > > For geo coordinates, 'donuts' and other ways to express 'all but this > area' conditions, which would trigger re-querying. This doesn't work > for civic coordinates, obviously. > > There seem to be several possibilities: > > (1) Don't do that. In other words, if an area knows that there are > more specific mappings, it has to be split up in some way, e.g., by > enumerating all such areas explicitly. For example, for the > unincorporated areas, the community name is part of the mapping, even > though they all share the same county-wide mapping. > > This probably works for most cases, but fails for the campus example, > since the surrounding city doesn't really know about these. > > (2) Mark such cases as non-cacheable. Since civic coordinates are only > used for stationary and nomadic devices, the additional query load is > rather modest. This is the safe approach. > > (3) As a compromise between (1) and (2), mark mappings that are known > to be leaf nodes. For example, a campus could mark its mapping as such > since it can be pretty sure that there's nothing below that level. > That way, laptops moving within a building don't have to requery. > These could simply be marked as cacheable, so that no additional XML > tags are needed. > > Henning > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 14 13:14:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hclp1-0000xD-Tu; Sat, 14 Apr 2007 13:13:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hclp0-0000wz-UP for ecrit@ietf.org; Sat, 14 Apr 2007 13:13:58 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcloy-0005Gr-UJ for ecrit@ietf.org; Sat, 14 Apr 2007 13:13:58 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 088C320421; Sat, 14 Apr 2007 19:13:54 +0200 (CEST) X-AuditID: c1b4fb3c-a84eabb0000073d5-eb-46210bd1ed8b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DFF6B2000C; Sat, 14 Apr 2007 19:13:53 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Apr 2007 19:13:53 +0200 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 Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpoint centric LCP without giving away the store Date: Sat, 14 Apr 2007 19:13:53 +0200 Message-ID: <0074F19FF6F8534E8F74C56BB84397BBD3583B@esealmw118.eemea.ericsson.se> In-Reply-To: <02f401c77de5$678e4bb0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpoint centric LCP without giving away the store Thread-Index: Acd9363GJ+vjNF8iQ5+wyWbUAZ4LVAAA1AfQADQoz6A= From: "Raymond Forbes \(CV/ETL\)" To: "Brian Rosen" , "Hannes Tschofenig" , "Rosen, Brian" X-OriginalArrivalTime: 14 Apr 2007 17:13:53.0778 (UTC) FILETIME=[473F9520:01C77EB8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org In many areas, especially Mobile Networks Country codes are not reliable. Geneva is a good case. Most calls originated by Non-Swiss mobiles in Geneva are actually made on the French networks and so will get the Country Code +33 of the base station on the surrounding Mountains, the French authorities have no jurisdiction to enter Switzerland even in the case of Emergencies. True because of Cross-boarder agreement on this friendly boarder region the French PSAPs will forward the calls to Switz PSAPs.=20 I am sure that what Brian says may be reasonable from fixed access, but not from Radio Access, radio has no respect for artificial political boundaries. Regards,=20 Ray Forbes BU Networks (CV/ETL/BBC/D) Telephone: +44 (0) 24 7656 3106=20 Mobile: +44 (0) 771 851 1361 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: 13 April 2007 17:04 To: 'Hannes Tschofenig'; Rosen, Brian Cc: geopriv@ietf.org; ecrit@ietf.org Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpoint centric LCP without giving away the store Huh, I didn't get that. I'd like to eliminate the country code thing, because otherwise we need a way to carry it in the SIP Geolocation. However, I don't really want the VSP having to ask the ASP/ISP for a dereference of any sort, and I'd like to minimize the work of the ASP/ISP. The notion that the ASP/ISP has to help the VSP determine if what it has is a valid PSAP URI strikes me as a problem. Now, you may remember WAAAY WAAY back, I strongly suggested that the geo form of location always include a country code. I suggested this for disputed areas. The access network is in a very good position to tell you how best to interpret which country actually is the on-the-ground administrator of the location. If you are connected to an Israeli access network, and you ask LoST for a PSAP URI, you probably want an Israeli fire brigade. If you are on a Palestinian access network, then you probably want a different answer. So, having country code in a PIDF with an otherwise geo location is actually helpful. The current answer for this is some kind of manual configuration of the LoST servers so you get the answer you want. While that can work, I think something more automatic might work better, and it fixes the problem. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Friday, April 13, 2007 11:26 AM > To: Rosen, Brian > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do=20 > endpoint centric LCP without giving away the store >=20 > Hi Brian, >=20 > I only described a different way of doing the verification without=20 > returning a country code. > I also focus on LbyR only rather than LbyV. >=20 > Ciao > Hannes >=20 > Rosen, Brian wrote: > > Hannes > > > > I am confused by your message. > > > > The problem you describe, where a VSP is trying to validate that the > > Request URI in what is claimed to be an emergency call is a bona=20 > > fide PSAP URI seems to be a valid concern. My message described one > > way to do this validation when what the VSP received (in a SIP=20 > > Geolocation > > header) is an LbyR. > > > > Are you now wondering how you validate when you have an LbyV? I=20 > > would think you do the same thing: send the country code (or the=20 > > whole > > location) and the PSAP URI to LoST and ask if the PSAP URI is valid. > > This does not require any query by the VSP to the ASP/ISP. The VSP=20 > > should be able to query its local LoST server and be referred to the > > authoritative server for the location it proffers. > > > > I'd rather not have to have the VSP try to dereference an LbyR, and=20 > > if you have an LbyV then you don't even know, necessarily, who the=20 > > ASP/ISP is. > > > > Is there something else I'm missing here? > > > > Brian > > > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: Friday, April 13, 2007 10:43 AM > >> To: Rosen, Brian > >> Cc: geopriv@ietf.org; ecrit@ietf.org > >> Subject: Re: [Ecrit] Not-so-grand compromise on how to do endpoint > >> > > centric > > > >> LCP without giving away the store > >> > >> Hi Brian, > >> > >> thanks for posting this message. > >> > >> When the end host is provided with LbyV and triggers the LoST=20 > >> lookup > >> > > and > > > >> routes the call via its VSP then the VSP (in some circumstances*) > >> > > might > > > >> want to verify that the PSAP URI in the message indeed corresponds=20 > >> to > >> > > a > > > >> PSAP. The idea that was mentioned a long time ago already was to=20 > >> let > >> > > the > > > >> VSP to use the location information for LoST and to compare the=20 > >> result with the content of the message. > >> > >> The main goal here is that the VSP does not need to have a "business" > >> contract to the ASP/ISP. > >> > >> Since there is only a location reference that neither the end host=20 > >> nor the VSP can dereference it is necessary to enhance the existing > >> procedures a bit (as Brian mentioned). > >> > >> I see two ways todo so: > >> > >> a) Enhance LoST > >> b) Enhance the dereferencing protocol > >> > >> In both cases you want to have the LbyR as input and the PSAP URI=20 > >> (and potentially the service number) as output. > >> > >> For (a) you would have to address the LoST query to the LoST server > >> in the ASP/ISP network and the result would be a nomal LoST response. > >> For (b) you would have todo a dereferencing step with an additional > >> parameter for "verify only". The response would be similar to the > >> > > lookup > > > >> by the end host -- just the identity that is being used for the=20 > >> lookup would be different. > >> > >> Both approaches are possible and since the VSP has to support both=20 > >> protocols it does not make a big difference which one to use. > >> > >> In both cases you would have to compare the result of the lookup=20 > >> with the content of the message. > >> > >> Ciao > >> Hannes > >> > >> *: It is only necessary when the VSP charges for individual calls=20 > >> or > >> > > for > > > >> specific calls (with the given call falling into this category). > >> > >> Rosen, Brian wrote: > >> > >>> In the Emergency Services SDO Coordination workshop, a familiar=20 > >>> discussion took place: how does location get provided for=20 > >>> emergency calls? The real issue is revenue. Access networks have location. > >>> > > They > > > >>> may be willing to (or may be regulated to be required to) provide=20 > >>> location for emergency calls. However, they are not willing to=20 > >>> give > >>> > > it > > > >>> away for free for other uses. The issue with that is how we=20 > >>> support calling networks that don't have relationships with access > >>> networks, i.e. the Skype situation. How is location provided such > >>> that a > >>> > > Skype > > > >>> emergency call can be placed, but the access network can restrict > >>> > > what > > > >>> else may be done with the location it provides? > >>> > >>> We have been wrapped around the axle on this for, dare I say, years. > >>> > >>> So, I think Barbara Stark first described this, and it needs some > >>> > > work, > > > >>> but suppose that, as an option, an access network could supply: > >>> > >>> 1. A reference to location > >>> > >>> 2. The results of a LoST query on the location value (viz, PSAP=20 > >>> URI > >>> > > and > > > >>> local dialstring) > >>> > >>> With this, an endpoint could recognize an emergency call and start > >>> routing it to the right PSAP. The LIS would agree to dereference > >>> > > for > > > >>> PSAPs, but could restrict other uses of location. > >>> > >>> Hannes points out that we need one more thing: the calling network > >>> > > has > > > >>> to be able to validate that the PSAP URI really is a PSAP URI so > >>> > > that > > > >>> charging (emergency calls generally are free) is protected. We=20 > >>> need > >>> > > a > > > >>> mechanism for them to do that. > >>> > >>> Perhaps we include in the LoST return a country code for a query > >>> > > with a > > > >>> geo. We add a new operation to LoST that takes a service, a=20 > >>> country code and a PSAP URI and returns yes/no validation ("Yes,=20 > >>> that URI is > >>> > > a > > > >>> valid URI for that service in that country"). > >>> > >>> What would we need to do to make this happen? > >>> > >>> We need extensions to LCPs or some new protocol that returns an=20 > >>> LbyR > >>> > > and > > > >>> the LoST results. I wonder if this is just more HELD work. > >>> > >>> We need the PSAP URI validation. > >>> > >>> Again, this is optional. The access network may well give up an > >>> > > LbyV. > > > >>> It may give up an LbyR that it will dereference for the endpoint. > >>> > > The > > > >>> access network may have a relationship with the calling network=20 > >>> such that the endpoint need not be involved. > >>> > >>> The PSAP URI validation is actually useful without this idea, > >>> > > especially > > > >>> when location is an LbyR. Instead of having to have the calling > >>> > > network > > > >>> dereference, and then do a LoST query to validate, it can just do > >>> > > this > > > >>> PSAP URI validation. > >>> > >>> Would this solve our problem? Would access carriers concerned=20 > >>> about revenue issues with "giving away" location to it's=20 > >>> subscribers be willing to provide LbyR dereferenceable by PSAPs=20 > >>> (again remembering > >>> > > that > > > >>> the access network are local to the PSAPs) as well as LoST query=20 > >>> services to their endpoints? Would this address the concerns=20 > >>> raised > >>> > > by > > > >>> Deutsche Telecom on this issue? > >>> > >>> Let me be very clear that I think this is an ugly solution. I=20 > >>> think that everyone will be much better off if endpoints knew=20 > >>> where they > >>> > > were, > > > >>> and apps could take advantage of that. I think we'll get there. =20 > >>> I think tying location configuration with the LoST query is a bad > >>> > > idea. I > > > >>> think using LbyR for emergency calls is a bad idea. > >>> > >>> But I can live with it. > >>> > >>> Brian > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/ecrit > >>> > >>> >=20 >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 14 16:38:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcp0W-00006y-4l; Sat, 14 Apr 2007 16:38:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcp0U-00005v-U6; Sat, 14 Apr 2007 16:38:02 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcp0T-0002sv-Fv; Sat, 14 Apr 2007 16:38:02 -0400 Received: from [192.168.0.48] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3EKbJDf012693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 14 Apr 2007 16:38:00 -0400 (EDT) In-Reply-To: <886DD03D15173C43BCE98EA662A0101A01EB70D2@stntexch12.cis.neustar.com> References: <886DD03D15173C43BCE98EA662A0101A01EB70D2@stntexch12.cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2675E720-4D47-4297-AFC7-9D92DAB6A615@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCP without giving away the store Date: Sat, 14 Apr 2007 10:58:25 -0400 To: "Rosen, Brian" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The editorial out the way, I'll start by listing some requirements, some of which have been mentioned already: - Hiding location should not make the PSAP behavior more costly and complicated or less reliable; in other words, just because an access provider choses, for business reasons, to withhold location information from customers should not impose a burden on tax payers. - Hiding location information by one provider should not impose a burden on those access providers that offer location information to their customers. I think the framework document needs to clearly spell out the reliability and security considerations of such a choice. If nothing else, this will prove valuable to the trial lawyer that gets called when the first person gets hurt when location information is erroneously withheld from a PSAP. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 14 16:38:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcp0c-0000LR-Ao; Sat, 14 Apr 2007 16:38:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcp0a-0000GW-9P; Sat, 14 Apr 2007 16:38:08 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcp0Z-0002xN-Tw; Sat, 14 Apr 2007 16:38:08 -0400 Received: from [192.168.0.48] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3EKbJDi012693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 14 Apr 2007 16:38:05 -0400 (EDT) In-Reply-To: <461F978B.5090102@gmx.net> References: <8BC845943058D844ABFC73D2220D4665064BCBD0@nics-mail.sbg.nic.at> <461F978B.5090102@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Sat, 14 Apr 2007 13:55:37 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Alexander Mayrhofer , geopriv@ietf.org, ecrit@ietf.org, "Rosen, Brian" Subject: [Ecrit] Re: [Geopriv] Not-so-grand compromise on how to do endpoint centric LCPwithout giving away the store X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Given that location information will have to be handed around to back- up PSAPs and first responders, I don't think a public key mechanism works well. After all, with a public key, all possible legitimate recipients would have to share a single private key. This goes against all standard recommendations for designing secure systems. (Since location information may need to reach federal authorities, for example, you may end up with essentially one nationwide private key. Not good.) I suspect that the desire to hide location information will primarily afflict a few very large incumbent service providers. I don't see why a hotel or enterprise would want to hide the location from their visitors or employees, say, as the likelihood of monetizing this information is zero. Thus, a simple shared secret between PSAP and the restrictive access provider will probably be sufficient. This still has all kinds of failure possibilities, e.g., if there are backup PSAPs somewhere across the country during a major disaster, but maybe these carriers can check their money making desires during KatrinaBis and turn off the access controls, as there likely won't be too many pizza parlors willing to pay for location information during such times any way. Henning On Apr 13, 2007, at 10:45 AM, Hannes Tschofenig wrote: > Hi Alex, > > In some sense an encrypted message is very similar to a location-by- > reference to the end host -- it is opaque. There is, however, the > problem of provisioning the keys to the PSAPs. When we also > consider the case of location based applications that are also in > scope of GEOPRIV then this approach will obviously not work. > > So, the main question therefore is: Do we see a problem with the > dereferencing step to resolve the reference to location information? > So far, I haven't had the impression. This mechanism would only be > justified in cases if there is a network connectivity problem > between the Location Recipient and the LIS but not between the > Target and the Location Recipient. > > Ciao > Hannes > > Alexander Mayrhofer wrote: >>> So, I think Barbara Stark first described this, and it needs some >>> work, >>> but suppose that, as an option, an access network could supply: >>> >>> 1. A reference to location >>> >>> 2. The results of a LoST query on the location value (viz, PSAP >>> URI and >>> local dialstring) >>> >> >> Hi, >> >> Without wanting to stir anything up (and, granted, without having >> followed the discussion very closely), a third option comes to my >> mind: >> >> Location-by-value, encrypted by the access network with a public key >> corresponding to the desired application of the location data? >> >> eg. for emergency services: >> >> - PSAPs supply a public key for location encryption within their >> coverage area (would need to be one key per area, though) >> - Access providers serving a certain area would encrypt location >> information with that key >> - Location information could be decrypted only by the PSAPs which the >> corresponding private key >> >> (hence, would be useless for Joe's Pizza Delivery Services, or >> > favourite name here>'s location advertisement service) >> >> I would definitely like to avoid any overengineering here, though >> - that >> is just a very rough idea i would like to share. Especially for >> emergency services though, i am a little scared about information not >> readable in case of catastrophic situations (imagining the >> frustration >> of a PSAP agent looking at an encrypted location while handling the >> call...) >> >> any comments appreciated (including flames :). >> >> Alex >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 14 16:38:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcp0V-000069-Hc; Sat, 14 Apr 2007 16:38:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcp0U-00005J-0L; Sat, 14 Apr 2007 16:38:02 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcp0T-0002su-Fv; Sat, 14 Apr 2007 16:38:01 -0400 Received: from [192.168.0.48] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3EKbJDe012693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 14 Apr 2007 16:37:54 -0400 (EDT) In-Reply-To: <886DD03D15173C43BCE98EA662A0101A01EB70D2@stntexch12.cis.neustar.com> References: <886DD03D15173C43BCE98EA662A0101A01EB70D2@stntexch12.cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <16417411-43E1-4EAC-8558-0A7A25307917@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCP without giving away the store Date: Sat, 14 Apr 2007 10:51:51 -0400 To: "Rosen, Brian" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org [This is partially an editorial, but I'll get to solutions in the next message...] My prediction is that the dream of untold riches to be mined from location information is largely just that. In particular, I believe that the value of non-emergency location information for stationary devices in a residential setting is pretty close to zero. After all, users already know their home address and for pizza delivery and similar tasks, it doesn't much matter whether the address validates. Users will fix their address after the first cold pizza arrives. As a practical matter, monetizing this information is going to be very difficult, particularly in European Union countries with strong privacy laws. A VSP is very unlikely to pay for location information, as it has no direct need for it. The local pizza parlor might find the information to be of interest, but the logistics are pretty daunting. Since you can't easily do per-use approval, as you can do with end system location, the pizza parlor would have to contact the various access providers and negotiate an arrangement. In addition, and most onerously, the pizza parlor would probably need to get individual approval from each potential customer to release this information to them. As a customer, why would I agree to release location information to every business, known and unknown, for purposes unknown? This can be fixed by uploading GEOPRIV policy to the access provider, but this requires heavy-duty machinery, as customers have to figure out which domains to include in that list. The likelihood that users will remember to add the pizza parlor's domain name to that list before calling for delivery is pretty slim. For a second delivery, the restaurant already has the correct and verified address, so it has limited additional value. Let's assume for a moment that stationary-device location is indeed tremendously valuable. If so, we'll very quickly get a budding entrepreneur that will get the location from the access provider and then sell it, once, to the customer, for free use henceforth until the customer changes ISPs. Heck, depending on pricing, the customer might do it himself. I'd look forward to the having the access provider sue this enterprise for handing a customer their own street address. ("Yes, your honor, we don't allow this company to tell our customer where they live.") Maybe Domino's will advertise "Get your free serving of location with our extra large pepperoni pizza!". Thus, this whole hide-location-from-customer thing has the distinct feeling of cutting off your nose to spite your face or, more to the topic, of "I can't make VoIP pay for me, so I'm going to make it difficult for everybody else to offer services, too". Location information is obviously valuable for mobile users, but I suspect that the consequence of making it difficult to get will simply increase the use of (unassisted) GPS and SkyHook, or BlueTooth on in-car navigation devices. (As navigation functionality gets integrated into mobile phones, this has to work even when there is no cell coverage.) While I doubt that this argument will suddenly convince the brilliant strategists in telecom companies, at least I'll have a convenient place to point to for an "I told you so" five years from now, or maybe a good place to be proven wrong while others cash in their stock options. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 14 16:38:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcp0V-00006O-R8; Sat, 14 Apr 2007 16:38:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcp0U-00005R-6z; Sat, 14 Apr 2007 16:38:02 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcp0T-0002t9-Ur; Sat, 14 Apr 2007 16:38:02 -0400 Received: from [192.168.0.48] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3EKbJDg012693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 14 Apr 2007 16:38:01 -0400 (EDT) In-Reply-To: <886DD03D15173C43BCE98EA662A0101A01EB70D2@stntexch12.cis.neustar.com> References: <886DD03D15173C43BCE98EA662A0101A01EB70D2@stntexch12.cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Not-so-grand compromise [solutions] Date: Sat, 14 Apr 2007 12:18:35 -0400 To: "Rosen, Brian" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'll try to summarize some solutions and pick apart the problem. There seem to be two basic approaches: (1) Provide only location information that is sufficient for call routing or possibly for obtaining the service number, but not for dispatch. The latter is included by a PSAP-only LbyR. This would remove a large part of the value of the address to pizza parlors, but would not interfere with our standard architecture. It would provide the user with some ability to verify his own address, albeit only partially. (This is one of the reliability drawbacks of the withhold- location-information approaches, which is going to be a major cause of dispatch problems, I suspect.) The biggest problem is determining this minimal address information, but this isn't too hard, given the availability of LoST service region information. (2) Provide only the PSAP URL and LbyR resolvable by the PSAP. Only (2) requires additional work. From what I can tell, the following solutions have been proposed: (a) Include in configuration protocols, such as DHCP. (b) Include in location configuration protocols, such as L7 LCP. (c) Include in a special LoST response, e.g., if the client provides no location information. All of these have problems: - DHCP: Since this is configuration information, adding a lot of extra material to DHCP seems ill-advised, particularly since the likelihood that this information actually reaches residential users is slim. After all, this motivated the whole L7-LCP discussion. This also has problems if the URL needs to be changed since the INFORM request expiration doesn't seem to be tied to the IP address expiration. The number of URLs could be substantial, given that we need more than one emergency service URL and that we may need service testing URLs. - L7 LCP: This subverts a location determination protocol into a general configuration protocol. - LoST: This seems closest to our existing notion of returning a 'default' PSAP if no other resolution is possible. Nothing prevents an ISP-provided LoST client from using whatever information it has available, such as client IP addresses, to make this information better than a national call center. If we go down this route, I think a better solution is to use the on- going work for SIP configuration mechanisms. One of the sources of configuration information is the local access network, so it has all the right properties. After all, emergency calling URLs are not fundamentally different from other configuration information for special servers. Plus, the configuration protocol will likely have mechanism of dealing with conflicting information. The more protocols you add, the higher the likelihood that a device will get conflicting information, with no deterministic way to resolve it. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 14 16:38:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcp0Y-00008T-OV; Sat, 14 Apr 2007 16:38:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcp0X-00007y-UE for ecrit@ietf.org; Sat, 14 Apr 2007 16:38:05 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcp0W-0002va-SP for ecrit@ietf.org; Sat, 14 Apr 2007 16:38:05 -0400 Received: from [192.168.0.48] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3EKbJDh012693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sat, 14 Apr 2007 16:38:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <886DD03D15173C43BCE98EA662A0101A01EB70D2@stntexch12.cis.neustar.com> References: <886DD03D15173C43BCE98EA662A0101A01EB70D2@stntexch12.cis.neustar.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Not-so-grand compromise - PSAP URL verification Date: Sat, 14 Apr 2007 13:46:38 -0400 To: ECRIT X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > I think this is a separable topic, so I've changed the subject line and removed the GEOPRIV cc. Also, this matters only if IP-to-IP calls are being charged for, which seems to be unusual for landline services at this point, to put it mildly. (If there's a PSTN gateway, it is presumably easy to keep a record of PSAP phone numbers, as such databases will need to be kept for other purposes.) Thus, this may only be required for mobile calls using per-minute charging (as opposed to mobile calls using a data service charging model). I'd also argue that this problem would likely best be solved by law enforcement, rather than through protocols. This is clear fraud, with a clearly-identified perpetrator, so it would seem highly unlikely that somebody would want to risk a criminal record to save a few cents on a phone call. (This is obviously not true for unauthenticated calls.) That said, I think brute force is the best solution here. I'd hate to create an elaborate infrastructure for something that may not be all that important in the future. Another important requirement is that the list of valid URLs needs to be automatically synchronized with the LoST records. We really want to avoid the case of having to maintain separate databases for the inverse mapping, simply because they'll invariably get out of sync, with possibly catastrophic consequences. If we assume a country-level mechanism, the number of PSAP URLs is modest. The largest number would likely be the US, with roughly 6000. Figure about 50 bytes for the URL, so we're talking a total data volume of 300,000 bytes. The change frequency in that URL list is likely to be modest, with maybe a few changes each day. Thus, a flooding mechanism seems sufficient, using the synchronization tools that draft-schulzrinne-ecrit-lost-sync offers (with probably one additional flag if a server is only interested in the URLs, without the service region). Since the synchronization mechanism supports push, new URLs can propagate rapidly to resolvers. You'd For higher efficiency and lower risk of inadvertent refusal, one might consider keeping partial URLs in the list, so that an entry of "emergency.nj.us" would match "sip:police@trenton.emergency.nj.us" or any other URL with that suffix. However, that makes indexed searches very difficult and seems more hassle than it's worth, given the trivial data volume. It also makes it harder to automatically derive this information within an authoritative LoST server. Henning > Hannes points out that we need one more thing: the calling network has > to be able to validate that the PSAP URI really is a PSAP URI so that > charging (emergency calls generally are free) is protected. We need a > mechanism for them to do that. > > Perhaps we include in the LoST return a country code for a query > with a > geo. We add a new operation to LoST that takes a service, a country > code and a PSAP URI and returns yes/no validation ("Yes, that URI is a > valid URI for that service in that country"). _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 14 16:56:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcpHz-0001ec-FI; Sat, 14 Apr 2007 16:56:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcpHz-0001eU-2o; Sat, 14 Apr 2007 16:56:07 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcpHy-00016q-Rk; Sat, 14 Apr 2007 16:56:07 -0400 Received: from [192.168.0.48] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3EKtvdo014686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 14 Apr 2007 16:55:58 -0400 (EDT) In-Reply-To: <461FB382.1010908@bbn.com> References: <886DD03D15173C43BCE98EA662A0101A01EB70D2@stntexch12.cis.neustar.com> <461FB382.1010908@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5BE4B2CF-09E5-4585-B98C-9C1C7C8B9D9F@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCP without giving away the store Date: Sat, 14 Apr 2007 16:55:57 -0400 To: Richard Barnes X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: geopriv@ietf.org, "Rosen, Brian" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > 1. Dereference access control > In order to do the LoST lookup, a LoST server would have to be > allowed to dereference the location reference. Given that most of > the LoST infrastructure (e.g. the trees) is pretty static, it > doesn't seem difficult to provide authentication credentials for > LoST servers and require that they be able to dereference (just > like PSAPs). > Unfortunately, every resolver and forest guide would have to dereference. Resolvers and forest guides will be operated by numerous entities, including companies. There is no trust relationship between the Columbia LoST resolver (VSP, in my case) and the access provider. If any resolver can get the location information, you might as well hand it out to the client to begin with. Saves you the extra effort. Thus, this is a non-starter. > 2. Extra time/complication > It's correct that it would not be feasible for every LoST server > involved in an LbyR-based query to dereference the location > reference. However, this can be avoided if the resolver doing the > recursive queries is allowed to do a dereference, since it can then > just include the location by value in subsequent queries. This may > cover most cases, e.g., if a local LoST resolver is provided by the > access network (as is often the case with DNS). In many cases, the LoST resolver will be provided by the VSP, including non-traditional VSPs. Are you suggesting we restrict the LoST architecture to cater to this particular need? I thought we agreed that the business practices of some ISPs should not burden the rest of the infrastructure? > > There's a lot of overlap between LoST/LbyR and what you propose. > If the access network provides a resolver, then the two are > essentially the same, except that if LoST/LbyR is used, then the > client sends an extra query. However, extending LoST seems to > maintain a better separation of the location configuration and > mapping functions. > > Humbly submitted, > --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 14 17:01:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcpNW-0004Y6-Hl; Sat, 14 Apr 2007 17:01:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcpNV-0004Y1-SN for ecrit@ietf.org; Sat, 14 Apr 2007 17:01:49 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HcpNV-000402-Du for ecrit@ietf.org; Sat, 14 Apr 2007 17:01:49 -0400 Received: (qmail invoked by alias); 14 Apr 2007 21:01:46 -0000 Received: from ip-90-186-41-131.web.vodafone.de (EHLO [90.186.41.131]) [90.186.41.131] by mail.gmx.net (mp045) with SMTP; 14 Apr 2007 23:01:46 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+/wU0u4d2/gSyvqAfmR4cUzcPzZUqtJTHibQd4r8 BRIOR3B1tPgJVA Message-ID: <46214134.2010505@gmx.net> Date: Sat, 14 Apr 2007 23:01:40 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) 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-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Ecrit] Unauthenticated Network Access X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, at the SDO Emergency Services workshop we had a chat about unauthenticated network access. We concluded that we don't have good terminology and some of us did not like the concept. Nevertheless, I believe we need to provide a story for it. Here are some thoughts. I believe that there are at least two flavors of "unauthenticated" that need to be considered here: a) The end host does not have credentials for network access. b) The end host does not have credentials for VoIP access. In case of (a) you need to differentiate between public hotspots and networks that are access controlled (for whatever reason, including monetary). With public hotspots that offer free-for-all service there are no problems since you don't perform an authentication procedure anyway. In case the network is access controlled the network administrator/network operator needs to ensure that an entity that claims to do an emergency call indeed does so (since otherwise there is a big security hole that opens doors for fraud). Hence, the access network (or an associated entity) needs some application layer knowledge. In case of (b) the access network provider (or an associated entity) needs to offer SIP proxy functionality since the end host per-definition does not have a "home" network. In a summary there are the following cases: Case A: No credentials for network access authentication BUT credentials for VoIP access Case B: Credentials for network access authentication BUT NO credentials for VoIP access In these two cases it is necessary to deploy a SIP proxy in the access network (or to make use of a SIP proxy that has a relationship to the access network; one could call it outsourcing model). So, the important question now is: How do we discover this proxy in the access / proxy related to the access network? 1) Can we make use of RFC3319 / RFC3361 (Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers"? OR 2) Do we need a new document that describes this functionality? I believe that we could go for (1), i.e., no new functionality needed. Ciao Hannes PS: Note that Case A potentially requires additional treatment described in a separate mail. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 14 19:16:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcrTN-0005II-4O; Sat, 14 Apr 2007 19:16:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcrTM-0005IA-DC for ecrit@ietf.org; Sat, 14 Apr 2007 19:16:00 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HcrTL-0007aO-0c for ecrit@ietf.org; Sat, 14 Apr 2007 19:16:00 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3ENFs1N028833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 14 Apr 2007 19:15:55 -0400 (EDT) In-Reply-To: <46214134.2010505@gmx.net> References: <46214134.2010505@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <072B79F7-B0F2-46A8-8CB1-E461C5ED72C4@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Unauthenticated Network Access Date: Sat, 14 Apr 2007 19:15:55 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes, see my other note on location-less PSAP discovery. Finding an 'emergency proxy' is just another item of UA configuration, again based on the local access network. Doing configuration in half a dozen different ways, with unclear precedence and relationships, is just a recipe for complexity and interoperability problems. Either we believe that the SIP configuration work addresses our configuration needs, or we should stop that work and do something that does. Henning On Apr 14, 2007, at 5:01 PM, Hannes Tschofenig wrote: > Hi all, > > at the SDO Emergency Services workshop we had a chat about > unauthenticated network access. We concluded that we don't have > good terminology and some of us did not like the concept. > Nevertheless, I believe we need to provide a story for it. > > Here are some thoughts. I believe that there are at least two > flavors of "unauthenticated" that need to be considered here: > > a) The end host does not have credentials for network access. > b) The end host does not have credentials for VoIP access. > > In case of (a) you need to differentiate between public hotspots > and networks that are access controlled (for whatever reason, > including monetary). With public hotspots that offer free-for-all > service there are no problems since you don't perform an > authentication procedure anyway. In case the network is access > controlled the network administrator/network operator needs to > ensure that an entity that claims to do an emergency call indeed > does so (since otherwise there is a big security hole that opens > doors for fraud). Hence, the access network (or an associated > entity) needs some application layer knowledge. > > In case of (b) the access network provider (or an associated > entity) needs to offer SIP proxy functionality since the end host > per-definition does not have a "home" network. > > In a summary there are the following cases: > > Case A: No credentials for network access authentication BUT > credentials for VoIP access > > Case B: Credentials for network access authentication BUT NO > credentials for VoIP access > > In these two cases it is necessary to deploy a SIP proxy in the > access network (or to make use of a SIP proxy that has a > relationship to the access network; one could call it outsourcing > model). > > So, the important question now is: > > How do we discover this proxy in the access / proxy related to the > access network? > > 1) Can we make use of RFC3319 / RFC3361 (Dynamic Host Configuration > Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) > Servers"? > > OR > > 2) Do we need a new document that describes this functionality? > > I believe that we could go for (1), i.e., no new functionality needed. > > Ciao > Hannes > > PS: Note that Case A potentially requires additional treatment > described in a separate mail. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 14 19:32:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcrjD-0005hw-GN; Sat, 14 Apr 2007 19:32:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcrjB-0005hh-Bd for ecrit@ietf.org; Sat, 14 Apr 2007 19:32:21 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hcrj6-0007tv-O5 for ecrit@ietf.org; Sat, 14 Apr 2007 19:32:21 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3ENWEAk000569 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 14 Apr 2007 19:32:14 -0400 (EDT) In-Reply-To: <46210449.3020709@gmx.net> References: <2148EBA7-F442-43CE-BB62-5AD0B18BCFE9@cs.columbia.edu> <46210449.3020709@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <635EDC7F-A2F3-4D13-B7DE-27E4EC709CC5@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST civic caching issue Date: Sat, 14 Apr 2007 19:32:16 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 14, 2007, at 12:41 PM, Hannes Tschofenig wrote: > Hi Henning, > > thanks for raising this issue and it is in fact a difficult problem. > > I see two aspects with the "the donut problem", i.e., there is a > larger service boundary with another service area within (the hole > in the donut). There are two cases: > > * The entity responsible for the larger service area knows that > there is a donut problem. In this case it would be reasonable to > assume that this entity could mark the response as "non cachable". > For geo one would want to express the service area as a donut -- > currently we don't have a description how to describe such a shape. > I now believe that we should add something to the PIDF-LO profile > draft. Polygons can be used to describe structures with holes - you just have to have the polygon 'wrap around' the hole and overlap in the middle. It gets tedious for multiple holes. Also, it appears that common SQL databases with geo extensions, such as the popular PostGIS, do not support such complicated shapes. Thus, it may be a better idea to compose this, as a set of coverage polygons [we got that] and a set of exceptions. > > * The entity responsible for the larger service area does NOT know > about a potential donut problem. This case is actually not related > to civic since it can appear in geo as well. I don't have an easy > and nice answer for this case. That is indeed the hard case. However, I believe it is properly the responsibility of the exception case to notify the surrounding entity that it wants to be considered a 'hole'. My perception is that institutions, such as university campuses, with their own police force or ambulance corps coordinate with the local civic authorities, rather than just freelance. I don't know the politics or legalities of whether, say, the NYPD would allow the Columbia police force to be declared officially in charge. If all else fails, the local LoST resolver would have to implement local policy. This is similar to what happens today: If you dial 911 on a cell phone while on the Columbia campus, you'll be connected to the NYPD, not campus police. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 14 20:00:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcsAZ-0000n1-KB; Sat, 14 Apr 2007 20:00:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcsAY-0000km-UX; Sat, 14 Apr 2007 20:00:38 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcsAY-0008L9-KX; Sat, 14 Apr 2007 20:00:38 -0400 X-SEF-Processed: 5_0_0_910__2007_04_14_19_07_11 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sat, 14 Apr 2007 19:07:11 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Apr 2007 19:00:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 14 Apr 2007 19:00:37 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Not-so-grand compromise on how to do endpointcentricLCPwithout giving away the store Thread-Index: Acd9eBCfZxIYRVO7QJu63bsxYVEIfwAR25+AAABL4PAATAlG8A== From: "Winterbottom, James" To: "Marc Berryman" , "Alexander Mayrhofer" , "Rosen, Brian" , X-OriginalArrivalTime: 15 Apr 2007 00:00:38.0198 (UTC) FILETIME=[196A8D60:01C77EF1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ecrit@ietf.org Subject: [Ecrit] RE: [Geopriv] Not-so-grand compromise on how to do endpointcentricLCPwithout giving away the store X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org It is also not clear to me exactly who would do the encryption in this=0D=0A= case=3F=0D=0AWould it be the ISP=3F=0D=0AWould it be the ASP=3F=0D=0A=0D=0A= If it is the ISP, who is potentially national, that would be about 6000=0D=0A= keys just for the USA.=0D=0A=0D=0AI like this solution less than Brian/Barb= ara's and I think it is=0D=0Aprobably more problematic.=0D=0A=0D=0ACheers=0D= =0AJames=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Marc Berryman= [mailto:MBerryman@911.org]=0D=0A> Sent: Friday, 13 April 2007 9:42 PM=0D=0A= > To: Alexander Mayrhofer; Rosen, Brian; geopriv@ietf.org=0D=0A> Cc: ecrit@= ietf.org=0D=0A> Subject: RE: [Geopriv] Not-so-grand compromise on how to do=0D= =0A> endpointcentricLCPwithout giving away the store=0D=0A>=20=0D=0A> Locat= ion-by-value with public encryption key=0D=0A> You would also have to consi= der when the calls are re-routed to a=0D=0A> different location and, oops, = someone forgot to update or include the=0D=0A> key.=0D=0A>=20=0D=0A> Marc B=0D= =0A>=20=0D=0A> Marc B=0D=0A>=20=0D=0A>=20=0D=0A> -----Original Message-----=0D= =0A> From: Alexander Mayrhofer [mailto:alexander.mayrhofer@nic.at]=0D=0A> S= ent: Friday, April 13, 2007 6:34 AM=0D=0A> To: Rosen, Brian; geopriv@ietf.o= rg=0D=0A> Cc: ecrit@ietf.org=0D=0A> Subject: RE: [Geopriv] Not-so-grand com= promise on how to do endpoint=0D=0A> centricLCPwithout giving away the stor= e=0D=0A>=20=0D=0A> > So, I think Barbara Stark first described this, and it= needs=0D=0A> > some work,=0D=0A> > but suppose that, as an option, an acce= ss network could supply:=0D=0A> >=0D=0A> > 1. A reference to location=0D=0A= > >=0D=0A> > 2. The results of a LoST query on the location value (viz,=0D=0A= > > PSAP URI and=0D=0A> > local dialstring)=0D=0A>=20=0D=0A> Hi,=0D=0A>=20=0D= =0A> Without wanting to stir anything up (and, granted, without having=0D=0A= > followed the discussion very closely), a third option comes to my=0D=0Ami= nd:=0D=0A>=20=0D=0A> Location-by-value, encrypted by the access network wit= h a public key=0D=0A> corresponding to the desired application of the locat= ion data=3F=0D=0A>=20=0D=0A> eg. for emergency services:=0D=0A>=20=0D=0A> -= PSAPs supply a public key for location encryption within their=0D=0A> cove= rage area (would need to be one key per area, though)=0D=0A> - Access provi= ders serving a certain area would encrypt location=0D=0A> information with = that key=0D=0A> - Location information could be decrypted only by the PSAPs= which the=0D=0A> corresponding private key=0D=0A>=20=0D=0A> (hence, would = be useless for Joe's Pizza Delivery Services, or favourite n= ame here>'s location advertisement service)=0D=0A>=20=0D=0A> I would defini= tely like to avoid any overengineering here, though -=0D=0Athat=0D=0A> is j= ust a very rough idea i would like to share. Especially for=0D=0A> emergenc= y services though, i am a little scared about information not=0D=0A> readab= le in case of catastrophic situations (imagining the frustration=0D=0A> of = a PSAP agent looking at an encrypted location while handling the=0D=0A> cal= l...)=0D=0A>=20=0D=0A> any comments appreciated (including flames :).=0D=0A= >=20=0D=0A> Alex=0D=0A>=20=0D=0A> _________________________________________= ______=0D=0A> Geopriv mailing list=0D=0A> Geopriv@ietf.org=0D=0A> https://w= ww1.ietf.org/mailman/listinfo/geopriv=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> = _______________________________________________=0D=0A> Geopriv mailing list=0D= =0A> Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/geopriv=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 14 20:01:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcsBR-0001Oe-KB; Sat, 14 Apr 2007 20:01:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcsBQ-0001Ky-6D for ecrit@ietf.org; Sat, 14 Apr 2007 20:01:32 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcsBN-000080-TV for ecrit@ietf.org; Sat, 14 Apr 2007 20:01:32 -0400 X-SEF-Processed: 5_0_0_910__2007_04_14_19_08_02 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sat, 14 Apr 2007 19:08:02 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Apr 2007 19:01:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Slides for ESW07 Date: Sat, 14 Apr 2007 19:01:29 -0500 Message-ID: In-Reply-To: <461F91DE.4020900@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Slides for ESW07 Thread-Index: Acd91w4ZI41WheAKQ3OHRnntdtvETABGhNDQ From: "Winterbottom, James" To: "Hannes Tschofenig" , "Spencer Dawkins" X-OriginalArrivalTime: 15 Apr 2007 00:01:29.0605 (UTC) FILETIME=[380EA350:01C77EF1] X-Spam-Score: 0.5 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes,=0D=0A=0D=0AI also noticed that a lot of people took very detailed n= otes.=0D=0APerhaps some of these people may be prepared to have their notes=0D= =0Apublished to the website also=3F=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D= =0A> -----Original Message-----=0D=0A> From: Hannes Tschofenig [mailto:Hann= es.Tschofenig@gmx.net]=0D=0A> Sent: Saturday, 14 April 2007 12:21 AM=0D=0A>= To: Spencer Dawkins=0D=0A> Cc: ecrit@ietf.org=0D=0A> Subject: Re: [Ecrit] = Slides for ESW07=0D=0A>=20=0D=0A> I will upload all slides as soon as possi= ble.=0D=0A>=20=0D=0A>=20=0D=0A> Spencer Dawkins wrote:=0D=0A> > The website= at http://www.emergency-services-coordination.info/2007/=0D=0A> > does hav= e some slidesets available, but there are still a lot=0D=0Amissing,=0D=0A> = > including all the slidesets for the panelists. Is there a chance of=0D=0A= > > seeing the presentations soon=3F=0D=0A> >=0D=0A> > Thanks,=0D=0A> >=0D=0A= > > Spencer=0D=0A> >=0D=0A> >=0D=0A> > ____________________________________= ___________=0D=0A> > Ecrit mailing list=0D=0A> > Ecrit@ietf.org=0D=0A> > ht= tps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D= =0A> _______________________________________________=0D=0A> Ecrit mailing l= ist=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/ecr= it=0D=0A=0D=0A-------------------------------------------------------------= -----------------------------------=0D=0AThis message is for the designated= recipient only and may=0D=0Acontain privileged, proprietary, or otherwise = private information. =20=0D=0AIf you have received it in error, please noti= fy the sender=0D=0Aimmediately and delete the original. Any unauthorized u= se of=0D=0Athis email is prohibited.=0D=0A---------------------------------= ---------------------------------------------------------------=0D=0A[mf2]=0D= =0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 14 20:03:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcsDf-0002wj-5K; Sat, 14 Apr 2007 20:03:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcsDd-0002r3-G7; Sat, 14 Apr 2007 20:03:49 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcsDd-0000Zn-3X; Sat, 14 Apr 2007 20:03:49 -0400 X-SEF-Processed: 5_0_0_910__2007_04_14_19_10_21 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sat, 14 Apr 2007 19:10:21 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Apr 2007 19:03:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Not-so-grand compromise on how to do endpoint centricLCP without giving away the store Date: Sat, 14 Apr 2007 19:03:47 -0500 Message-ID: In-Reply-To: <461F9703.6040801@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Not-so-grand compromise on how to do endpoint centricLCP without giving away the store Thread-Index: Acd92hx+pZ0n7wo+TlGcqRLUYvI2JABF0MeA From: "Winterbottom, James" To: "Hannes Tschofenig" , "Rosen, Brian" X-OriginalArrivalTime: 15 Apr 2007 00:03:48.0894 (UTC) FILETIME=[8B1473E0:01C77EF1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org There is potentially one other thing that springs to mind, and that is a=0D= =0Aspecific sos domain. If that were done, then the resulting URI itself=0D= =0Awould be explicit that it was for emergency services.=0D=0A=0D=0AJust a = thought.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A> -----Original Message---= --=0D=0A> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A>= Sent: Saturday, 14 April 2007 12:43 AM=0D=0A> To: Rosen, Brian=0D=0A> Cc: = geopriv@ietf.org; ecrit@ietf.org=0D=0A> Subject: Re: [Ecrit] Not-so-grand c= ompromise on how to do endpoint=0D=0A> centricLCP without giving away the s= tore=0D=0A>=20=0D=0A> Hi Brian,=0D=0A>=20=0D=0A> thanks for posting this me= ssage.=0D=0A>=20=0D=0A> When the end host is provided with LbyV and trigger= s the LoST lookup=0D=0Aand=0D=0A> routes the call via its VSP then the VSP = (in some circumstances*)=0D=0Amight=0D=0A> want to verify that the PSAP URI= in the message indeed corresponds to=0D=0Aa=0D=0A> PSAP. The idea that was= mentioned a long time ago already was to let=0D=0Athe=0D=0A> VSP to use th= e location information for LoST and to compare the result=0D=0A> with the c= ontent of the message.=0D=0A>=20=0D=0A> The main goal here is that the VSP = does not need to have a "business"=0D=0A> contract to the ASP/ISP.=0D=0A> =0D= =0A> Since there is only a location reference that neither the end host nor=0D= =0A> the VSP can dereference it is necessary to enhance the existing=0D=0A>= procedures a bit (as Brian mentioned).=0D=0A>=20=0D=0A> I see two ways tod= o so:=0D=0A>=20=0D=0A> a) Enhance LoST=0D=0A> b) Enhance the dereferencing = protocol=0D=0A>=20=0D=0A> In both cases you want to have the LbyR as input = and the PSAP URI (and=0D=0A> potentially the service number) as output.=0D=0A= >=20=0D=0A> For (a) you would have to address the LoST query to the LoST se= rver in=0D=0A> the ASP/ISP network and the result would be a nomal LoST res= ponse.=0D=0A> For (b) you would have todo a dereferencing step with an addi= tional=0D=0A> parameter for "verify only". The response would be similar to= the=0D=0Alookup=0D=0A> by the end host -- just the identity that is being = used for the lookup=0D=0A> would be different.=0D=0A>=20=0D=0A> Both approa= ches are possible and since the VSP has to support both=0D=0A> protocols it= does not make a big difference which one to use.=0D=0A>=20=0D=0A> In both = cases you would have to compare the result of the lookup with=0D=0A> the co= ntent of the message.=0D=0A>=20=0D=0A> Ciao=0D=0A> Hannes=0D=0A>=20=0D=0A> = *: It is only necessary when the VSP charges for individual calls or=0D=0Af= or=0D=0A> specific calls (with the given call falling into this category).=0D= =0A>=20=0D=0A> Rosen, Brian wrote:=0D=0A> > In the Emergency Services SDO C= oordination workshop, a familiar=0D=0A> > discussion took place: how does l= ocation get provided for emergency=0D=0A> > calls=3F The real issue is rev= enue. Access networks have location.=0D=0AThey=0D=0A> > may be willing to = (or may be regulated to be required to) provide=0D=0A> > location for emerg= ency calls. However, they are not willing to give=0D=0Ait=0D=0A> > away fo= r free for other uses. The issue with that is how we support=0D=0A> > call= ing networks that don't have relationships with access networks,=0D=0A> > i= =2Ee. the Skype situation. How is location provided such that a=0D=0ASkype=0D= =0A> > emergency call can be placed, but the access network can restrict=0D= =0Awhat=0D=0A> > else may be done with the location it provides=3F=0D=0A> >=0D= =0A> > We have been wrapped around the axle on this for, dare I say, years.=0D= =0A> >=0D=0A> > So, I think Barbara Stark first described this, and it need= s some=0D=0Awork,=0D=0A> > but suppose that, as an option, an access networ= k could supply:=0D=0A> >=0D=0A> > 1. A reference to location=0D=0A> >=0D=0A= > > 2. The results of a LoST query on the location value (viz, PSAP URI=0D=0A= and=0D=0A> > local dialstring)=0D=0A> >=0D=0A> > With this, an endpoint cou= ld recognize an emergency call and start=0D=0A> > routing it to the right P= SAP. The LIS would agree to dereference=0D=0Afor=0D=0A> > PSAPs, but could= restrict other uses of location.=0D=0A> >=0D=0A> > Hannes points out that = we need one more thing: the calling network=0D=0Ahas=0D=0A> > to be able to= validate that the PSAP URI really is a PSAP URI so=0D=0Athat=0D=0A> > char= ging (emergency calls generally are free) is protected. We need=0D=0Aa=0D=0A= > > mechanism for them to do that.=0D=0A> >=0D=0A> > Perhaps we include in = the LoST return a country code for a query=0D=0Awith a=0D=0A> > geo. We ad= d a new operation to LoST that takes a service, a country=0D=0A> > code and= a PSAP URI and returns yes/no validation ("Yes, that URI is=0D=0Aa=0D=0A> = > valid URI for that service in that country").=0D=0A> >=0D=0A> > What woul= d we need to do to make this happen=3F=0D=0A> >=0D=0A> > We need extensions= to LCPs or some new protocol that returns an LbyR=0D=0Aand=0D=0A> > the Lo= ST results. I wonder if this is just more HELD work.=0D=0A> >=0D=0A> > We = need the PSAP URI validation.=0D=0A> >=0D=0A> > Again, this is optional. T= he access network may well give up an=0D=0ALbyV.=0D=0A> > It may give up an= LbyR that it will dereference for the endpoint.=0D=0AThe=0D=0A> > access n= etwork may have a relationship with the calling network such=0D=0A> > that = the endpoint need not be involved.=0D=0A> >=0D=0A> > The PSAP URI validatio= n is actually useful without this idea,=0D=0Aespecially=0D=0A> > when locat= ion is an LbyR. Instead of having to have the calling=0D=0Anetwork=0D=0A> = > dereference, and then do a LoST query to validate, it can just do=0D=0Ath= is=0D=0A> > PSAP URI validation.=0D=0A> >=0D=0A> > Would this solve our pro= blem=3F Would access carriers concerned about=0D=0A> > revenue issues with= "giving away" location to it's subscribers be=0D=0A> > willing to provide = LbyR dereferenceable by PSAPs (again remembering=0D=0Athat=0D=0A> > the acc= ess network are local to the PSAPs) as well as LoST query=0D=0A> > services= to their endpoints=3F Would this address the concerns raised=0D=0Aby=0D=0A= > > Deutsche Telecom on this issue=3F=0D=0A> >=0D=0A> > Let me be very clea= r that I think this is an ugly solution. I think=0D=0A> > that everyone wi= ll be much better off if endpoints knew where they=0D=0Awere,=0D=0A> > and = apps could take advantage of that. I think we'll get there. I=0D=0A> > th= ink tying location configuration with the LoST query is a bad=0D=0Aidea. I=0D= =0A> > think using LbyR for emergency calls is a bad idea.=0D=0A> >=0D=0A> = > But I can live with it.=0D=0A> >=0D=0A> > Brian=0D=0A> >=0D=0A> > _______= ________________________________________=0D=0A> > Ecrit mailing list=0D=0A>= > Ecrit@ietf.org=0D=0A> > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A= > >=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> __________________________________= _____________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https:= //www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A-------------------------= -----------------------------------------------------------------------=0D=0A= This message is for the designated recipient only and may=0D=0Acontain priv= ileged, proprietary, or otherwise private information. =20=0D=0AIf you have= received it in error, please notify the sender=0D=0Aimmediately and delete= the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 14 20:14:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcsNp-0000GY-J1; Sat, 14 Apr 2007 20:14:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcsNo-0000GL-OV; Sat, 14 Apr 2007 20:14:20 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcsNo-0002j9-CI; Sat, 14 Apr 2007 20:14:20 -0400 X-SEF-Processed: 5_0_0_910__2007_04_14_19_20_48 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sat, 14 Apr 2007 19:20:48 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Apr 2007 19:14:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Date: Sat, 14 Apr 2007 19:14:14 -0500 Message-ID: In-Reply-To: <035a01c77dff$80b9c820$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Thread-Index: Acd9eBCfZxIYRVO7QJu63bsxYVEIfwAd6vQwAAPV6GAAPPTEsA== From: "Winterbottom, James" To: "Brian Rosen" , "Marc Linsner" , "Rosen, Brian" , X-OriginalArrivalTime: 15 Apr 2007 00:14:15.0504 (UTC) FILETIME=[00918D00:01C77EF3] X-Spam-Score: 0.5 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I agree.=0D=0A=0D=0AIndirectly the access network is already assuming this = responsibility=0D=0Asince it is providing location to the end-point in any = case, either=0D=0Adirectly or indirectly.=0D=0A=0D=0A> -----Original Messag= e-----=0D=0A> From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> Sent: Sat= urday, 14 April 2007 5:11 AM=0D=0A> To: 'Marc Linsner'; Rosen, Brian; geopr= iv@ietf.org=0D=0A> Cc: ecrit@ietf.org=0D=0A> Subject: RE: [Geopriv] RE: [Ec= rit] Not-so-grand compromise on how to=0D=0A> doendpointcentric LCPwithout = giving away the store=0D=0A>=20=0D=0A> I think that is part of the tradeoff= an access network makes. If its=0D=0A> restricting access to location, an= d location is needed to route, then=0D=0Ait=0D=0A> has=0D=0A> to assume the= liability for misroute, since it's providing the route=0D=0Ain=0D=0A> lieu=0D= =0A> of providing location for the VSP to route.=0D=0A>=20=0D=0A> If it doe= sn't want to assume that liability, then it has to give=0D=0Alocation=0D=0A= > to=0D=0A> someone who does the route, and we're back around that axle aga= in.=0D=0A>=20=0D=0A> So, I think it's reasonable that the access network de= al with=0D=0Amisroutes in=0D=0A> this case.=0D=0A>=20=0D=0A> Brian=0D=0A> =0D= =0A> > -----Original Message-----=0D=0A> > From: Marc Linsner [mailto:mlins= ner@cisco.com]=0D=0A> > Sent: Friday, April 13, 2007 1:23 PM=0D=0A> > To: '= Rosen, Brian'; geopriv@ietf.org=0D=0A> > Cc: ecrit@ietf.org=0D=0A> > Subjec= t: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do=0D=0A> > endp= ointcentric LCPwithout giving away the store=0D=0A> >=0D=0A> > Who is respo= nsible for PSAP mis-routes=3F I would think this=0D=0Atransfers=0D=0A> > l= iability for routing to the access-provider, are they willing to=0D=0Astep=0D= =0A> up=0D=0A> > to=0D=0A> > that=3F=0D=0A> >=0D=0A> > -Marc-=0D=0A> >=0D=0A= > > > -----Original Message-----=0D=0A> > > From: Rosen, Brian [mailto:Bria= n.Rosen@neustar.biz]=0D=0A> > > Sent: Friday, April 13, 2007 7:18 AM=0D=0A>= > > To: geopriv@ietf.org=0D=0A> > > Cc: ecrit@ietf.org=0D=0A> > > Subject:= [Ecrit] Not-so-grand compromise on how to do=0D=0A> > > endpoint centric L= CPwithout giving away the store=0D=0A> > >=0D=0A> > > In the Emergency Serv= ices SDO Coordination workshop, a=0D=0A> > > familiar discussion took place= : how does location get=0D=0A> > > provided for emergency calls=3F The rea= l issue is revenue.=0D=0A> > > Access networks have location. They may be = willing to (or=0D=0A> > > may be regulated to be required to) provide locat= ion for=0D=0A> > > emergency calls. However, they are not willing to give = it=0D=0A> > > away for free for other uses. The issue with that is how we=0D= =0A> > > support calling networks that don't have relationships with=0D=0A>= > > access networks, i.e. the Skype situation. How is location=0D=0A> > >= provided such that a Skype emergency call can be placed, but=0D=0A> > > th= e access network can restrict what else may be done with=0D=0A> > > the loc= ation it provides=3F=0D=0A> > >=0D=0A> > > We have been wrapped around the = axle on this for, dare I say,=0D=0Ayears.=0D=0A> > >=0D=0A> > > So, I think= Barbara Stark first described this, and it needs=0D=0A> > > some work, but= suppose that, as an option, an access network=0D=0A> > > could supply:=0D=0A= > > >=0D=0A> > > 1. A reference to location=0D=0A> > >=0D=0A> > > 2. The re= sults of a LoST query on the location value (viz,=0D=0A> > > PSAP URI and l= ocal dialstring)=0D=0A> > >=0D=0A> > > With this, an endpoint could recogni= ze an emergency call and=0D=0A> > > start routing it to the right PSAP. Th= e LIS would agree to=0D=0A> > > dereference for PSAPs, but could restrict o= ther uses of location.=0D=0A> > >=0D=0A> > > Hannes points out that we need= one more thing: the calling=0D=0A> > > network has to be able to validate = that the PSAP URI really=0D=0A> > > is a PSAP URI so that charging (emergen= cy calls generally are=0D=0A> > > free) is protected. We need a mechanism = for them to do that.=0D=0A> > >=0D=0A> > > Perhaps we include in the LoST r= eturn a country code for a=0D=0A> > > query with a geo. We add a new opera= tion to LoST that takes=0D=0A> > > a service, a country code and a PSAP URI= and returns yes/no=0D=0A> > > validation ("Yes, that URI is a valid URI fo= r that service in=0D=0A> > > that country").=0D=0A> > >=0D=0A> > > What wou= ld we need to do to make this happen=3F=0D=0A> > >=0D=0A> > > We need exten= sions to LCPs or some new protocol that returns=0D=0A> > > an LbyR and the = LoST results. I wonder if this is just more=0D=0A> > > HELD work.=0D=0A> >= >=0D=0A> > > We need the PSAP URI validation.=0D=0A> > >=0D=0A> > > Again,= this is optional. The access network may well give up an=0D=0ALbyV.=0D=0A= > > > It may give up an LbyR that it will dereference for the=0D=0A> > > en= dpoint. The access network may have a relationship with=0D=0A> > > the cal= ling network such that the endpoint need not be involved.=0D=0A> > >=0D=0A>= > > The PSAP URI validation is actually useful without this idea,=0D=0A> >= > especially when location is an LbyR. Instead of having to=0D=0A> > > ha= ve the calling network dereference, and then do a LoST=0D=0A> > > query to = validate, it can just do this PSAP URI validation.=0D=0A> > >=0D=0A> > > Wo= uld this solve our problem=3F Would access carriers=0D=0A> > > concerned a= bout revenue issues with "giving away" location to=0D=0A> > > it's subscrib= ers be willing to provide LbyR dereferenceable=0D=0A> > > by PSAPs (again r= emembering that the access network are local=0D=0A> > > to the PSAPs) as we= ll as LoST query services to their=0D=0A> > > endpoints=3F Would this addr= ess the concerns raised by=0D=0A> > > Deutsche Telecom on this issue=3F=0D=0A= > > >=0D=0A> > > Let me be very clear that I think this is an ugly solution= =2E=0D=0A> > > I think that everyone will be much better off if endpoints=0D= =0A> > > knew where they were, and apps could take advantage of that.=0D=0A= > > > I think we'll get there. I think tying location=0D=0A> > > configura= tion with the LoST query is a bad idea. I think=0D=0A> > > using LbyR for = emergency calls is a bad idea.=0D=0A> > >=0D=0A> > > But I can live with it= =2E=0D=0A> > >=0D=0A> > > Brian=0D=0A> > >=0D=0A> > > _____________________= __________________________=0D=0A> > > Ecrit mailing list=0D=0A> > > Ecrit@i= etf.org=0D=0A> > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> >=0D= =0A> > _______________________________________________=0D=0A> > Geopriv mai= ling list=0D=0A> > Geopriv@ietf.org=0D=0A> > https://www1.ietf.org/mailman/= listinfo/geopriv=0D=0A>=20=0D=0A>=20=0D=0A> _______________________________= ________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> htt= ps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A----------------------= --------------------------------------------------------------------------=0D= =0AThis message is for the designated recipient only and may=0D=0Acontain p= rivileged, proprietary, or otherwise private information. =20=0D=0AIf you h= ave received it in error, please notify the sender=0D=0Aimmediately and del= ete the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 14 20:21:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcsUp-0002rT-6w; Sat, 14 Apr 2007 20:21:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcsUo-0002rL-1c; Sat, 14 Apr 2007 20:21:34 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcsUl-0003cb-RB; Sat, 14 Apr 2007 20:21:34 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3F0LL0L018584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 14 Apr 2007 20:21:24 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <54EAA193-1F7C-446E-A6A9-159E8196195D@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Not-so-grand compromise on how to do endpoint centricLCP without giving away the store Date: Sat, 14 Apr 2007 20:21:26 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Who would administer such a domain? At least in the US, there is no national authority for PSAPs. Given the PSAP-like semi-private emergency call centers on many corporate and university campuses, there is unlikely to be one. (Yes, this particular solution was discussed, and dismissed, a few years ago. It might even have appeared in one of the early emergency I-Ds.) Henning On Apr 14, 2007, at 8:03 PM, Winterbottom, James wrote: > There is potentially one other thing that springs to mind, and that > is a > specific sos domain. If that were done, then the resulting URI itself > would be explicit that it was for emergency services. > > Just a thought. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 14 20:23:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcsWb-0003BH-L0; Sat, 14 Apr 2007 20:23:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcsWZ-0003A7-VL; Sat, 14 Apr 2007 20:23:23 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcsWY-0003oM-NZ; Sat, 14 Apr 2007 20:23:23 -0400 X-SEF-Processed: 5_0_0_910__2007_04_14_19_29_55 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sat, 14 Apr 2007 19:29:55 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Apr 2007 19:23:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Not-so-grand compromise on how to do endpoint centricLCP without giving away the store Date: Sat, 14 Apr 2007 19:23:21 -0500 Message-ID: In-Reply-To: <54EAA193-1F7C-446E-A6A9-159E8196195D@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Not-so-grand compromise on how to do endpoint centricLCP without giving away the store Thread-Index: Acd+9AS7duGoZ8e4RIGHbLOzdtI8tQAADUTA From: "Winterbottom, James" To: "Henning Schulzrinne" X-OriginalArrivalTime: 15 Apr 2007 00:23:22.0504 (UTC) FILETIME=[469B2080:01C77EF4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I am fine with that, it was just a pie-in-the-sky.. ;)=0D=0A=0D=0A=0D=0A> -= ----Original Message-----=0D=0A> From: Henning Schulzrinne [mailto:hgs@cs.c= olumbia.edu]=0D=0A> Sent: Sunday, 15 April 2007 10:21 AM=0D=0A> To: Winterb= ottom, James=0D=0A> Cc: GEOPRIV; ECRIT=0D=0A> Subject: Re: [Ecrit] Not-so-g= rand compromise on how to do endpoint=0D=0A> centricLCP without giving away= the store=0D=0A>=20=0D=0A> Who would administer such a domain=3F At least = in the US, there is no=0D=0A> national authority for PSAPs. Given the PSAP-= like semi-private=0D=0A> emergency call centers on many corporate and unive= rsity campuses,=0D=0A> there is unlikely to be one.=0D=0A>=20=0D=0A> (Yes, = this particular solution was discussed, and dismissed, a few=0D=0A> years a= go. It might even have appeared in one of the early emergency=0D=0A> I-Ds.)=0D= =0A>=20=0D=0A> Henning=0D=0A>=20=0D=0A> On Apr 14, 2007, at 8:03 PM, Winter= bottom, James wrote:=0D=0A>=20=0D=0A> > There is potentially one other thin= g that springs to mind, and that=0D=0A> > is a=0D=0A> > specific sos domain= =2E If that were done, then the resulting URI=0D=0Aitself=0D=0A> > would be= explicit that it was for emergency services.=0D=0A> >=0D=0A> > Just a thou= ght.=0D=0A>=20=0D=0A=0D=0A-------------------------------------------------= -----------------------------------------------=0D=0AThis message is for th= e designated recipient only and may=0D=0Acontain privileged, proprietary, o= r otherwise private information. =20=0D=0AIf you have received it in error,= please notify the sender=0D=0Aimmediately and delete the original. Any un= authorized use of=0D=0Athis email is prohibited.=0D=0A---------------------= ---------------------------------------------------------------------------=0D= =0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 14 23:32:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcvTV-0004FB-1g; Sat, 14 Apr 2007 23:32:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcvTT-0004E6-Dd for ecrit@ietf.org; Sat, 14 Apr 2007 23:32:23 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcvTS-0000pu-W3 for ecrit@ietf.org; Sat, 14 Apr 2007 23:32:23 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 14 Apr 2007 23:32:21 -0400 X-IronPort-AV: i="4.14,411,1170651600"; d="scan'208"; a="118553221:sNHT57808276" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3F3WKWq001853; Sat, 14 Apr 2007 23:32:20 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3F3WKlG005319; Sun, 15 Apr 2007 03:32:20 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Apr 2007 23:32:19 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Apr 2007 23:32:19 -0400 From: "Marc Linsner" To: "'Brian Rosen'" Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCPwithout giving away the store Date: Sat, 14 Apr 2007 23:32:18 -0400 Message-ID: <005b01c77f0e$abe6d550$42aa520a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-reply-to: <035a01c77dff$80b9c820$640fa8c0@cis.neustar.com> Thread-Index: Acd9eBCfZxIYRVO7QJu63bsxYVEIfwAd6vQwAAPV6GAAQ9X98A== X-OriginalArrivalTime: 15 Apr 2007 03:32:19.0479 (UTC) FILETIME=[ABF83A70:01C77F0E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5981; t=1176607940; x=1177471940; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20RE=3A=20[Ecrit]=20Not-so-grand=20compromi se=20on=20how=20to=20do=20endpointcentric=20LCPwithout=20giving=20away=20t he=20store |Sender:=20 |To:=20=22'Brian=20Rosen'=22=20; bh=ikYqdF7p/dtd5a/QR/IX4tHiN32qIVE0O9bFNGIAKpk=; b=Ij4QSCDHxF/GvSUM/55TUNXJoarM8DqgB0CphIvU/HZmRSTi/wYkVcZW/ndvUh/0RESmqHS0 nQWHhSDqtTK51Ffbj9izt0Lr93oYXbsq/OcBeugLIbiFvz3mDGVTBAND; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, You also realize that an emergency call is going to be routed using 'stale' data. We've always stated that routing at call time is optimal. You are prepared to give that up? -Marc- > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, April 13, 2007 3:11 PM > To: 'Marc Linsner'; Rosen, Brian; geopriv@ietf.org > Cc: ecrit@ietf.org > Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on > how to do endpointcentric LCPwithout giving away the store > > I think that is part of the tradeoff an access network makes. > If its restricting access to location, and location is > needed to route, then it has to assume the liability for > misroute, since it's providing the route in lieu of providing > location for the VSP to route. > > If it doesn't want to assume that liability, then it has to > give location to someone who does the route, and we're back > around that axle again. > > So, I think it's reasonable that the access network deal with > misroutes in this case. > > Brian > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Friday, April 13, 2007 1:23 PM > > To: 'Rosen, Brian'; geopriv@ietf.org > > Cc: ecrit@ietf.org > > Subject: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do > > endpointcentric LCPwithout giving away the store > > > > Who is responsible for PSAP mis-routes? I would think this > transfers > > liability for routing to the access-provider, are they > willing to step > > up to that? > > > > -Marc- > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > Sent: Friday, April 13, 2007 7:18 AM > > > To: geopriv@ietf.org > > > Cc: ecrit@ietf.org > > > Subject: [Ecrit] Not-so-grand compromise on how to do endpoint > > > centric LCPwithout giving away the store > > > > > > In the Emergency Services SDO Coordination workshop, a familiar > > > discussion took place: how does location get provided for > emergency > > > calls? The real issue is revenue. > > > Access networks have location. They may be willing to (or may be > > > regulated to be required to) provide location for > emergency calls. > > > However, they are not willing to give it away for free for other > > > uses. The issue with that is how we support calling > networks that > > > don't have relationships with access networks, i.e. the Skype > > > situation. How is location provided such that a Skype emergency > > > call can be placed, but the access network can restrict what else > > > may be done with the location it provides? > > > > > > We have been wrapped around the axle on this for, dare I > say, years. > > > > > > So, I think Barbara Stark first described this, and it needs some > > > work, but suppose that, as an option, an access network could > > > supply: > > > > > > 1. A reference to location > > > > > > 2. The results of a LoST query on the location value > (viz, PSAP URI > > > and local dialstring) > > > > > > With this, an endpoint could recognize an emergency call > and start > > > routing it to the right PSAP. The LIS would agree to dereference > > > for PSAPs, but could restrict other uses of location. > > > > > > Hannes points out that we need one more thing: the > calling network > > > has to be able to validate that the PSAP URI really is a > PSAP URI so > > > that charging (emergency calls generally are > > > free) is protected. We need a mechanism for them to do that. > > > > > > Perhaps we include in the LoST return a country code for a query > > > with a geo. We add a new operation to LoST that takes a > service, a > > > country code and a PSAP URI and returns yes/no validation ("Yes, > > > that URI is a valid URI for that service in that country"). > > > > > > What would we need to do to make this happen? > > > > > > We need extensions to LCPs or some new protocol that > returns an LbyR > > > and the LoST results. I wonder if this is just more HELD work. > > > > > > We need the PSAP URI validation. > > > > > > Again, this is optional. The access network may well > give up an LbyV. > > > It may give up an LbyR that it will dereference for the > endpoint. > > > The access network may have a relationship with the > calling network > > > such that the endpoint need not be involved. > > > > > > The PSAP URI validation is actually useful without this idea, > > > especially when location is an LbyR. Instead of having > to have the > > > calling network dereference, and then do a LoST query to > validate, > > > it can just do this PSAP URI validation. > > > > > > Would this solve our problem? Would access carriers > concerned about > > > revenue issues with "giving away" location to it's subscribers be > > > willing to provide LbyR dereferenceable by PSAPs (again > remembering > > > that the access network are local to the PSAPs) as well as LoST > > > query services to their endpoints? Would this address > the concerns > > > raised by Deutsche Telecom on this issue? > > > > > > Let me be very clear that I think this is an ugly solution. > > > I think that everyone will be much better off if endpoints knew > > > where they were, and apps could take advantage of that. > > > I think we'll get there. I think tying location > configuration with > > > the LoST query is a bad idea. I think using LbyR for emergency > > > calls is a bad idea. > > > > > > But I can live with it. > > > > > > Brian > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Apr 15 00:27:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcwKS-0003Bt-Qt; Sun, 15 Apr 2007 00:27:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcwKR-0003Bo-FI for ecrit@ietf.org; Sun, 15 Apr 2007 00:27:07 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcwKR-00089V-1V for ecrit@ietf.org; Sun, 15 Apr 2007 00:27:07 -0400 X-SEF-Processed: 5_0_0_910__2007_04_14_23_33_39 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sat, 14 Apr 2007 23:33:39 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Apr 2007 23:27:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Date: Sat, 14 Apr 2007 23:27:05 -0500 Message-ID: In-Reply-To: <005b01c77f0e$abe6d550$42aa520a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Thread-Index: Acd9eBCfZxIYRVO7QJu63bsxYVEIfwAd6vQwAAPV6GAAQ9X98AABrTpg From: "Winterbottom, James" To: "Marc Linsner" , "Brian Rosen" X-OriginalArrivalTime: 15 Apr 2007 04:27:06.0656 (UTC) FILETIME=[5347A200:01C77F16] X-Spam-Score: 0.5 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I am not so sure that this anymore the case than it would be with a=0D=0Alo= cation value is it=3F=0D=0A=0D=0AIf the device is fixed, then the likelihoo= d of change in low, but the=0D=0APSAP route could be tagged with an expiry = the same as a literal location=0D=0Acan. So I think this is the same proble= m.=0D=0A=0D=0AIf the device is mobile then yes this does require an extra d= ip prior to=0D=0Athe mobile sending the initial invite, but the proxy doesn= 't have to the=0D=0ALoST dip on the way, so the net result may be neutral d= epending on how=0D=0Athe proxy does URI checking etc.=0D=0A=0D=0AI am not s= uggesting that this solution is optimal either, but like Brian=0D=0Aand I c= an live with it.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A> -----Original Me= ssage-----=0D=0A> From: Marc Linsner [mailto:mlinsner@cisco.com]=0D=0A> Sen= t: Sunday, 15 April 2007 1:32 PM=0D=0A> To: 'Brian Rosen'=0D=0A> Cc: ecrit@= ietf.org=0D=0A> Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise = on how to=0D=0A> doendpointcentric LCPwithout giving away the store=0D=0A> =0D= =0A> Brian,=0D=0A>=20=0D=0A> You also realize that an emergency call is goi= ng to be routed using=0D=0A> 'stale'=0D=0A> data. We've always stated that= routing at call time is optimal. You=0D=0Aare=0D=0A> prepared to give tha= t up=3F=0D=0A>=20=0D=0A> -Marc-=0D=0A>=20=0D=0A> > -----Original Message---= --=0D=0A> > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > Sent: Fri= day, April 13, 2007 3:11 PM=0D=0A> > To: 'Marc Linsner'; Rosen, Brian; geop= riv@ietf.org=0D=0A> > Cc: ecrit@ietf.org=0D=0A> > Subject: RE: [Geopriv] RE= : [Ecrit] Not-so-grand compromise on=0D=0A> > how to do endpointcentric LCP= without giving away the store=0D=0A> >=0D=0A> > I think that is part of the= tradeoff an access network makes.=0D=0A> > If its restricting access to l= ocation, and location is=0D=0A> > needed to route, then it has to assume th= e liability for=0D=0A> > misroute, since it's providing the route in lieu o= f providing=0D=0A> > location for the VSP to route.=0D=0A> >=0D=0A> > If it= doesn't want to assume that liability, then it has to=0D=0A> > give locati= on to someone who does the route, and we're back=0D=0A> > around that axle = again.=0D=0A> >=0D=0A> > So, I think it's reasonable that the access networ= k deal with=0D=0A> > misroutes in this case.=0D=0A> >=0D=0A> > Brian=0D=0A>= >=0D=0A> > > -----Original Message-----=0D=0A> > > From: Marc Linsner [mai= lto:mlinsner@cisco.com]=0D=0A> > > Sent: Friday, April 13, 2007 1:23 PM=0D=0A= > > > To: 'Rosen, Brian'; geopriv@ietf.org=0D=0A> > > Cc: ecrit@ietf.org=0D= =0A> > > Subject: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to=0D= =0Ado=0D=0A> > > endpointcentric LCPwithout giving away the store=0D=0A> > = >=0D=0A> > > Who is responsible for PSAP mis-routes=3F I would think this=0D= =0A> > transfers=0D=0A> > > liability for routing to the access-provider, a= re they=0D=0A> > willing to step=0D=0A> > > up to that=3F=0D=0A> > >=0D=0A>= > > -Marc-=0D=0A> > >=0D=0A> > > > -----Original Message-----=0D=0A> > > >= From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=0D=0A> > > > Sent: Fri= day, April 13, 2007 7:18 AM=0D=0A> > > > To: geopriv@ietf.org=0D=0A> > > > = Cc: ecrit@ietf.org=0D=0A> > > > Subject: [Ecrit] Not-so-grand compromise on= how to do endpoint=0D=0A> > > > centric LCPwithout giving away the store=0D= =0A> > > >=0D=0A> > > > In the Emergency Services SDO Coordination workshop= , a familiar=0D=0A> > > > discussion took place: how does location get prov= ided for=0D=0A> > emergency=0D=0A> > > > calls=3F The real issue is revenu= e.=0D=0A> > > > Access networks have location. They may be willing to (or = may=0D=0Abe=0D=0A> > > > regulated to be required to) provide location for=0D= =0A> > emergency calls.=0D=0A> > > > However, they are not willing to give = it away for free for other=0D=0A> > > > uses. The issue with that is how w= e support calling=0D=0A> > networks that=0D=0A> > > > don't have relationsh= ips with access networks, i.e. the Skype=0D=0A> > > > situation. How is lo= cation provided such that a Skype emergency=0D=0A> > > > call can be placed= , but the access network can restrict what=0D=0Aelse=0D=0A> > > > may be do= ne with the location it provides=3F=0D=0A> > > >=0D=0A> > > > We have been = wrapped around the axle on this for, dare I=0D=0A> > say, years.=0D=0A> > >= >=0D=0A> > > > So, I think Barbara Stark first described this, and it need= s=0D=0Asome=0D=0A> > > > work, but suppose that, as an option, an access ne= twork could=0D=0A> > > > supply:=0D=0A> > > >=0D=0A> > > > 1. A reference t= o location=0D=0A> > > >=0D=0A> > > > 2. The results of a LoST query on the = location value=0D=0A> > (viz, PSAP URI=0D=0A> > > > and local dialstring)=0D= =0A> > > >=0D=0A> > > > With this, an endpoint could recognize an emergency= call=0D=0A> > and start=0D=0A> > > > routing it to the right PSAP. The LI= S would agree to=0D=0Adereference=0D=0A> > > > for PSAPs, but could restric= t other uses of location.=0D=0A> > > >=0D=0A> > > > Hannes points out that = we need one more thing: the=0D=0A> > calling network=0D=0A> > > > has to be= able to validate that the PSAP URI really is a=0D=0A> > PSAP URI so=0D=0A>= > > > that charging (emergency calls generally are=0D=0A> > > > free) is p= rotected. We need a mechanism for them to do that.=0D=0A> > > >=0D=0A> > >= > Perhaps we include in the LoST return a country code for a query=0D=0A> = > > > with a geo. We add a new operation to LoST that takes a=0D=0A> > ser= vice, a=0D=0A> > > > country code and a PSAP URI and returns yes/no validat= ion ("Yes,=0D=0A> > > > that URI is a valid URI for that service in that co= untry").=0D=0A> > > >=0D=0A> > > > What would we need to do to make this ha= ppen=3F=0D=0A> > > >=0D=0A> > > > We need extensions to LCPs or some new pr= otocol that=0D=0A> > returns an LbyR=0D=0A> > > > and the LoST results. I = wonder if this is just more HELD work.=0D=0A> > > >=0D=0A> > > > We need th= e PSAP URI validation.=0D=0A> > > >=0D=0A> > > > Again, this is optional. = The access network may well=0D=0A> > give up an LbyV.=0D=0A> > > > It may g= ive up an LbyR that it will dereference for the=0D=0A> > endpoint.=0D=0A> >= > > The access network may have a relationship with the=0D=0A> > calling n= etwork=0D=0A> > > > such that the endpoint need not be involved.=0D=0A> > >= >=0D=0A> > > > The PSAP URI validation is actually useful without this ide= a,=0D=0A> > > > especially when location is an LbyR. Instead of having=0D=0A= > > to have the=0D=0A> > > > calling network dereference, and then do a LoS= T query to=0D=0A> > validate,=0D=0A> > > > it can just do this PSAP URI val= idation.=0D=0A> > > >=0D=0A> > > > Would this solve our problem=3F Would a= ccess carriers=0D=0A> > concerned about=0D=0A> > > > revenue issues with "g= iving away" location to it's subscribers=0D=0Abe=0D=0A> > > > willing to pr= ovide LbyR dereferenceable by PSAPs (again=0D=0A> > remembering=0D=0A> > > = > that the access network are local to the PSAPs) as well as LoST=0D=0A> > = > > query services to their endpoints=3F Would this address=0D=0A> > the c= oncerns=0D=0A> > > > raised by Deutsche Telecom on this issue=3F=0D=0A> > >= >=0D=0A> > > > Let me be very clear that I think this is an ugly solution.=0D= =0A> > > > I think that everyone will be much better off if endpoints knew=0D= =0A> > > > where they were, and apps could take advantage of that.=0D=0A> >= > > I think we'll get there. I think tying location=0D=0A> > configuratio= n with=0D=0A> > > > the LoST query is a bad idea. I think using LbyR for e= mergency=0D=0A> > > > calls is a bad idea.=0D=0A> > > >=0D=0A> > > > But I = can live with it.=0D=0A> > > >=0D=0A> > > > Brian=0D=0A> > > >=0D=0A> > > >= _______________________________________________=0D=0A> > > > Ecrit mailing= list=0D=0A> > > > Ecrit@ietf.org=0D=0A> > > > https://www1.ietf.org/mailma= n/listinfo/ecrit=0D=0A> > >=0D=0A> > > ____________________________________= ___________=0D=0A> > > Geopriv mailing list=0D=0A> > > Geopriv@ietf.org=0D=0A= > > > https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A>=20=0D=0A> _____= __________________________________________=0D=0A> Ecrit mailing list=0D=0A>= Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0AThis message is for the designated recipient = only and may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Apr 15 15:58:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdAro-0007cT-7I; Sun, 15 Apr 2007 15:58:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdArm-0007cL-LT for ecrit@ietf.org; Sun, 15 Apr 2007 15:58:30 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdArm-0004kc-5c for ecrit@ietf.org; Sun, 15 Apr 2007 15:58:30 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 15 Apr 2007 15:58:30 -0400 X-IronPort-AV: i="4.14,413,1170651600"; d="scan'208"; a="118576725:sNHT63835036" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3FJwTcp020916; Sun, 15 Apr 2007 15:58:29 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3FJwRlG009719; Sun, 15 Apr 2007 19:58:27 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Apr 2007 15:58:27 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Apr 2007 15:58:25 -0400 From: "Marc Linsner" To: "'Winterbottom, James'" Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Date: Sun, 15 Apr 2007 15:58:25 -0400 Message-ID: <002d01c77f98$6e7052c0$2d0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Acd9eBCfZxIYRVO7QJu63bsxYVEIfwAd6vQwAAPV6GAAQ9X98AABrTpgACBby4A= X-OriginalArrivalTime: 15 Apr 2007 19:58:26.0889 (UTC) FILETIME=[6E7E8390:01C77F98] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8997; t=1176667109; x=1177531109; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20RE=3A=20[Ecrit]=20Not-so-grand=20compromi se=20on=20how=20to=20doendpointcentric=20LCPwithout=20giving=20away=20the= 20store |Sender:=20 |To:=20=22'Winterbottom,=20James'=22=20; bh=s4tpYLMGA3iGkqUyj8C4Vkj7Z7wTu7iMT7VtvY/ooIA=; b=mFX8kdRBoUDTTjiWE4x2qjbl/P/8CZsA5q20LEe5id9pPPWphUEuZv6Cw/4tJdz2f8TQR+5m geCs7lRN+qRCP8BPO3wBTI3WN7q1gDWH5c1953qp++r7AEFNZ30WJHbb; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org James, > > I am not so sure that this anymore the case than it would be > with a location value is it? No, if the client has LbyV, the client can do the LoST lookup at call time. > > If the device is fixed, then the likelihood of change in low, > but the PSAP route could be tagged with an expiry the same as > a literal location can. So I think this is the same problem. You are suggesting the host go back to the access network when setting up an emergency call? I wonder if a course location (enough to route properly) with LbyR embedded in the LbyV would be better. The access provider can take the fine grain location, perform a LoST lookup, give the client only the tuples that LoST returned in the service boundary. The client can then perform a LoST lookup anytime with that set of tuples. If the client is fixed no need to contact the access network at emergency call time. I worry about too many dependencies at call time. -Marc- > > If the device is mobile then yes this does require an extra > dip prior to the mobile sending the initial invite, but the > proxy doesn't have to the LoST dip on the way, so the net > result may be neutral depending on how the proxy does URI > checking etc. > > I am not suggesting that this solution is optimal either, but > like Brian and I can live with it. > > Cheers > James > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Sunday, 15 April 2007 1:32 PM > > To: 'Brian Rosen' > > Cc: ecrit@ietf.org > > Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise > on how to > > doendpointcentric LCPwithout giving away the store > > > > Brian, > > > > You also realize that an emergency call is going to be routed using > > 'stale' > > data. We've always stated that routing at call time is > optimal. You > are > > prepared to give that up? > > > > -Marc- > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Friday, April 13, 2007 3:11 PM > > > To: 'Marc Linsner'; Rosen, Brian; geopriv@ietf.org > > > Cc: ecrit@ietf.org > > > Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand > compromise on how to > > > do endpointcentric LCPwithout giving away the store > > > > > > I think that is part of the tradeoff an access network makes. > > > If its restricting access to location, and location is needed to > > > route, then it has to assume the liability for misroute, > since it's > > > providing the route in lieu of providing location for the VSP to > > > route. > > > > > > If it doesn't want to assume that liability, then it has to give > > > location to someone who does the route, and we're back > around that > > > axle again. > > > > > > So, I think it's reasonable that the access network deal with > > > misroutes in this case. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > > > Sent: Friday, April 13, 2007 1:23 PM > > > > To: 'Rosen, Brian'; geopriv@ietf.org > > > > Cc: ecrit@ietf.org > > > > Subject: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to > do > > > > endpointcentric LCPwithout giving away the store > > > > > > > > Who is responsible for PSAP mis-routes? I would think this > > > transfers > > > > liability for routing to the access-provider, are they > > > willing to step > > > > up to that? > > > > > > > > -Marc- > > > > > > > > > -----Original Message----- > > > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > > > Sent: Friday, April 13, 2007 7:18 AM > > > > > To: geopriv@ietf.org > > > > > Cc: ecrit@ietf.org > > > > > Subject: [Ecrit] Not-so-grand compromise on how to do > endpoint > > > > > centric LCPwithout giving away the store > > > > > > > > > > In the Emergency Services SDO Coordination workshop, > a familiar > > > > > discussion took place: how does location get provided for > > > emergency > > > > > calls? The real issue is revenue. > > > > > Access networks have location. They may be willing to (or may > be > > > > > regulated to be required to) provide location for > > > emergency calls. > > > > > However, they are not willing to give it away for > free for other > > > > > uses. The issue with that is how we support calling > > > networks that > > > > > don't have relationships with access networks, i.e. the Skype > > > > > situation. How is location provided such that a > Skype emergency > > > > > call can be placed, but the access network can restrict what > else > > > > > may be done with the location it provides? > > > > > > > > > > We have been wrapped around the axle on this for, dare I > > > say, years. > > > > > > > > > > So, I think Barbara Stark first described this, and it needs > some > > > > > work, but suppose that, as an option, an access network could > > > > > supply: > > > > > > > > > > 1. A reference to location > > > > > > > > > > 2. The results of a LoST query on the location value > > > (viz, PSAP URI > > > > > and local dialstring) > > > > > > > > > > With this, an endpoint could recognize an emergency call > > > and start > > > > > routing it to the right PSAP. The LIS would agree to > dereference > > > > > for PSAPs, but could restrict other uses of location. > > > > > > > > > > Hannes points out that we need one more thing: the > > > calling network > > > > > has to be able to validate that the PSAP URI really is a > > > PSAP URI so > > > > > that charging (emergency calls generally are > > > > > free) is protected. We need a mechanism for them to do that. > > > > > > > > > > Perhaps we include in the LoST return a country code > for a query > > > > > with a geo. We add a new operation to LoST that takes a > > > service, a > > > > > country code and a PSAP URI and returns yes/no > validation ("Yes, > > > > > that URI is a valid URI for that service in that country"). > > > > > > > > > > What would we need to do to make this happen? > > > > > > > > > > We need extensions to LCPs or some new protocol that > > > returns an LbyR > > > > > and the LoST results. I wonder if this is just more > HELD work. > > > > > > > > > > We need the PSAP URI validation. > > > > > > > > > > Again, this is optional. The access network may well > > > give up an LbyV. > > > > > It may give up an LbyR that it will dereference for the > > > endpoint. > > > > > The access network may have a relationship with the > > > calling network > > > > > such that the endpoint need not be involved. > > > > > > > > > > The PSAP URI validation is actually useful without this idea, > > > > > especially when location is an LbyR. Instead of having > > > to have the > > > > > calling network dereference, and then do a LoST query to > > > validate, > > > > > it can just do this PSAP URI validation. > > > > > > > > > > Would this solve our problem? Would access carriers > > > concerned about > > > > > revenue issues with "giving away" location to it's subscribers > be > > > > > willing to provide LbyR dereferenceable by PSAPs (again > > > remembering > > > > > that the access network are local to the PSAPs) as > well as LoST > > > > > query services to their endpoints? Would this address > > > the concerns > > > > > raised by Deutsche Telecom on this issue? > > > > > > > > > > Let me be very clear that I think this is an ugly solution. > > > > > I think that everyone will be much better off if > endpoints knew > > > > > where they were, and apps could take advantage of that. > > > > > I think we'll get there. I think tying location > > > configuration with > > > > > the LoST query is a bad idea. I think using LbyR for > emergency > > > > > calls is a bad idea. > > > > > > > > > > But I can live with it. > > > > > > > > > > Brian > > > > > > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Apr 15 18:29:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdDE6-0005pl-01; Sun, 15 Apr 2007 18:29:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdDE5-0005pd-90 for ecrit@ietf.org; Sun, 15 Apr 2007 18:29:41 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdDE4-0004E1-NC for ecrit@ietf.org; Sun, 15 Apr 2007 18:29:41 -0400 X-SEF-Processed: 5_0_0_910__2007_04_15_17_36_12 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 15 Apr 2007 17:36:12 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Apr 2007 17:29:37 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 15 Apr 2007 17:29:36 -0500 Message-ID: In-Reply-To: <002d01c77f98$6e7052c0$2d0d0d0a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Thread-Index: Acd9eBCfZxIYRVO7QJu63bsxYVEIfwAd6vQwAAPV6GAAQ9X98AABrTpgACBby4AABWu0sA== From: "Winterbottom, James" To: "Marc Linsner" X-OriginalArrivalTime: 15 Apr 2007 22:29:37.0846 (UTC) FILETIME=[8D34B560:01C77FAD] X-Spam-Score: 0.5 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Marc,=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Marc Linsner [ma= ilto:mlinsner@cisco.com]=0D=0A> Sent: Monday, 16 April 2007 5:58 AM=0D=0A> = To: Winterbottom, James=0D=0A> Cc: ecrit@ietf.org=0D=0A> Subject: RE: [Geop= riv] RE: [Ecrit] Not-so-grand compromise on how to=0D=0A> doendpointcentric= LCPwithout giving away the store=0D=0A>=20=0D=0A> James,=0D=0A>=20=0D=0A> = >=0D=0A> > I am not so sure that this anymore the case than it would be=0D=0A= > > with a location value is it=3F=0D=0A>=20=0D=0A> No, if the client has L= byV, the client can do the LoST lookup at call=0D=0A> time.=0D=0A>=20=0D=0A= [AJW] This presupposes that the location has not changed. If the=0D=0Alocat= ion has changed then this doesn't help unless the client also=0D=0Arequests= a new location at call time. In this case I put to you that=0D=0Athere is = no difference in the number of queries performed.=0D=0A=0D=0A> >=0D=0A> > I= f the device is fixed, then the likelihood of change in low,=0D=0A> > but t= he PSAP route could be tagged with an expiry the same as=0D=0A> > a literal= location can. So I think this is the same problem.=0D=0A>=20=0D=0A> You ar= e suggesting the host go back to the access network when setting=0D=0Aup=0D= =0A> an=0D=0A> emergency call=3F=0D=0A=0D=0A[AJW] Local network hit is like= ly to be faster than a wide-area network=0D=0Ahit.=0D=0A=0D=0A>=20=0D=0A> I= wonder if a course location (enough to route properly) with LbyR=0D=0A> em= bedded=0D=0A> in the LbyV would be better.=0D=0A>=0D=0A=0D=0A[AJW] Hmmm, ma= ybe. I would need to think about this one a bit more as I=0D=0Aam not sure = that we can easily arrive at a solution to how coarse is too=0D=0Acoarse, o= r too fine.=0D=0A=0D=0A=20=0D=0A> The access provider can take the fine gra= in location, perform a LoST=0D=0A> lookup,=0D=0A> give the client only the = tuples that LoST returned in the service=0D=0A> boundary.=0D=0A> The client= can then perform a LoST lookup anytime with that set of=0D=0Atuples.=0D=0A= > If the client is fixed no need to contact the access network at=0D=0Aemer= gency=0D=0A> call time.=0D=0A>=20=0D=0A> I worry about too many dependencie= s at call time.=0D=0A=0D=0A[AJW] Agreed, but we need to allow people to dep= loy it also. Like most=0D=0Athings some ground in the middle will need to b= e found.=0D=0A=0D=0A>=20=0D=0A> -Marc-=0D=0A>=20=0D=0A> >=0D=0A> > If the d= evice is mobile then yes this does require an extra=0D=0A> > dip prior to t= he mobile sending the initial invite, but the=0D=0A> > proxy doesn't have t= o the LoST dip on the way, so the net=0D=0A> > result may be neutral depend= ing on how the proxy does URI=0D=0A> > checking etc.=0D=0A> >=0D=0A> > I am= not suggesting that this solution is optimal either, but=0D=0A> > like Bri= an and I can live with it.=0D=0A> >=0D=0A> > Cheers=0D=0A> > James=0D=0A> >=0D= =0A> > > -----Original Message-----=0D=0A> > > From: Marc Linsner [mailto:m= linsner@cisco.com]=0D=0A> > > Sent: Sunday, 15 April 2007 1:32 PM=0D=0A> > = > To: 'Brian Rosen'=0D=0A> > > Cc: ecrit@ietf.org=0D=0A> > > Subject: RE: [= Geopriv] RE: [Ecrit] Not-so-grand compromise=0D=0A> > on how to=0D=0A> > > = doendpointcentric LCPwithout giving away the store=0D=0A> > >=0D=0A> > > Br= ian,=0D=0A> > >=0D=0A> > > You also realize that an emergency call is going= to be routed=0D=0Ausing=0D=0A> > > 'stale'=0D=0A> > > data. We've always = stated that routing at call time is=0D=0A> > optimal. You=0D=0A> > are=0D=0A= > > > prepared to give that up=3F=0D=0A> > >=0D=0A> > > -Marc-=0D=0A> > >=0D= =0A> > > > -----Original Message-----=0D=0A> > > > From: Brian Rosen [mailt= o:br@brianrosen.net]=0D=0A> > > > Sent: Friday, April 13, 2007 3:11 PM=0D=0A= > > > > To: 'Marc Linsner'; Rosen, Brian; geopriv@ietf.org=0D=0A> > > > Cc:= ecrit@ietf.org=0D=0A> > > > Subject: RE: [Geopriv] RE: [Ecrit] Not-so-gran= d=0D=0A> > compromise on how to=0D=0A> > > > do endpointcentric LCPwithout = giving away the store=0D=0A> > > >=0D=0A> > > > I think that is part of the= tradeoff an access network makes.=0D=0A> > > > If its restricting access = to location, and location is needed=0D=0Ato=0D=0A> > > > route, then it has= to assume the liability for misroute,=0D=0A> > since it's=0D=0A> > > > pro= viding the route in lieu of providing location for the VSP to=0D=0A> > > > = route.=0D=0A> > > >=0D=0A> > > > If it doesn't want to assume that liabilit= y, then it has to give=0D=0A> > > > location to someone who does the route,= and we're back=0D=0A> > around that=0D=0A> > > > axle again.=0D=0A> > > >=0D= =0A> > > > So, I think it's reasonable that the access network deal with=0D= =0A> > > > misroutes in this case.=0D=0A> > > >=0D=0A> > > > Brian=0D=0A> >= > >=0D=0A> > > > > -----Original Message-----=0D=0A> > > > > From: Marc Li= nsner [mailto:mlinsner@cisco.com]=0D=0A> > > > > Sent: Friday, April 13, 20= 07 1:23 PM=0D=0A> > > > > To: 'Rosen, Brian'; geopriv@ietf.org=0D=0A> > > >= > Cc: ecrit@ietf.org=0D=0A> > > > > Subject: [Geopriv] RE: [Ecrit] Not-so-= grand compromise on how=0D=0Ato=0D=0A> > do=0D=0A> > > > > endpointcentric = LCPwithout giving away the store=0D=0A> > > > >=0D=0A> > > > > Who is respo= nsible for PSAP mis-routes=3F I would think this=0D=0A> > > > transfers=0D= =0A> > > > > liability for routing to the access-provider, are they=0D=0A> = > > > willing to step=0D=0A> > > > > up to that=3F=0D=0A> > > > >=0D=0A> > = > > > -Marc-=0D=0A> > > > >=0D=0A> > > > > > -----Original Message-----=0D=0A= > > > > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=0D=0A> > > = > > > Sent: Friday, April 13, 2007 7:18 AM=0D=0A> > > > > > To: geopriv@iet= f.org=0D=0A> > > > > > Cc: ecrit@ietf.org=0D=0A> > > > > > Subject: [Ecrit]= Not-so-grand compromise on how to do=0D=0A> > endpoint=0D=0A> > > > > > ce= ntric LCPwithout giving away the store=0D=0A> > > > > >=0D=0A> > > > > > In= the Emergency Services SDO Coordination workshop,=0D=0A> > a familiar=0D=0A= > > > > > > discussion took place: how does location get provided for=0D=0A= > > > > emergency=0D=0A> > > > > > calls=3F The real issue is revenue.=0D=0A= > > > > > > Access networks have location. They may be willing to (or=0D=0A= may=0D=0A> > be=0D=0A> > > > > > regulated to be required to) provide locat= ion for=0D=0A> > > > emergency calls.=0D=0A> > > > > > However, they are no= t willing to give it away for=0D=0A> > free for other=0D=0A> > > > > > uses= =2E The issue with that is how we support calling=0D=0A> > > > networks th= at=0D=0A> > > > > > don't have relationships with access networks, i.e. the=0D= =0ASkype=0D=0A> > > > > > situation. How is location provided such that a=0D= =0A> > Skype emergency=0D=0A> > > > > > call can be placed, but the access = network can restrict what=0D=0A> > else=0D=0A> > > > > > may be done with t= he location it provides=3F=0D=0A> > > > > >=0D=0A> > > > > > We have been w= rapped around the axle on this for, dare I=0D=0A> > > > say, years.=0D=0A> = > > > > >=0D=0A> > > > > > So, I think Barbara Stark first described this, = and it needs=0D=0A> > some=0D=0A> > > > > > work, but suppose that, as an o= ption, an access network=0D=0Acould=0D=0A> > > > > > supply:=0D=0A> > > > >= >=0D=0A> > > > > > 1. A reference to location=0D=0A> > > > > >=0D=0A> > > = > > > 2. The results of a LoST query on the location value=0D=0A> > > > (vi= z, PSAP URI=0D=0A> > > > > > and local dialstring)=0D=0A> > > > > >=0D=0A> = > > > > > With this, an endpoint could recognize an emergency call=0D=0A> >= > > and start=0D=0A> > > > > > routing it to the right PSAP. The LIS woul= d agree to=0D=0A> > dereference=0D=0A> > > > > > for PSAPs, but could restr= ict other uses of location.=0D=0A> > > > > >=0D=0A> > > > > > Hannes points= out that we need one more thing: the=0D=0A> > > > calling network=0D=0A> >= > > > > has to be able to validate that the PSAP URI really is a=0D=0A> > = > > PSAP URI so=0D=0A> > > > > > that charging (emergency calls generally a= re=0D=0A> > > > > > free) is protected. We need a mechanism for them to do=0D= =0Athat.=0D=0A> > > > > >=0D=0A> > > > > > Perhaps we include in the LoST r= eturn a country code=0D=0A> > for a query=0D=0A> > > > > > with a geo. We = add a new operation to LoST that takes a=0D=0A> > > > service, a=0D=0A> > >= > > > country code and a PSAP URI and returns yes/no=0D=0A> > validation (= "Yes,=0D=0A> > > > > > that URI is a valid URI for that service in that cou= ntry").=0D=0A> > > > > >=0D=0A> > > > > > What would we need to do to make = this happen=3F=0D=0A> > > > > >=0D=0A> > > > > > We need extensions to LCPs= or some new protocol that=0D=0A> > > > returns an LbyR=0D=0A> > > > > > an= d the LoST results. I wonder if this is just more=0D=0A> > HELD work.=0D=0A= > > > > > >=0D=0A> > > > > > We need the PSAP URI validation.=0D=0A> > > > = > >=0D=0A> > > > > > Again, this is optional. The access network may well=0D= =0A> > > > give up an LbyV.=0D=0A> > > > > > It may give up an LbyR that it= will dereference for the=0D=0A> > > > endpoint.=0D=0A> > > > > > The acces= s network may have a relationship with the=0D=0A> > > > calling network=0D=0A= > > > > > > such that the endpoint need not be involved.=0D=0A> > > > > >=0D= =0A> > > > > > The PSAP URI validation is actually useful without this=0D=0A= idea,=0D=0A> > > > > > especially when location is an LbyR. Instead of hav= ing=0D=0A> > > > to have the=0D=0A> > > > > > calling network dereference, = and then do a LoST query to=0D=0A> > > > validate,=0D=0A> > > > > > it can = just do this PSAP URI validation.=0D=0A> > > > > >=0D=0A> > > > > > Would t= his solve our problem=3F Would access carriers=0D=0A> > > > concerned abou= t=0D=0A> > > > > > revenue issues with "giving away" location to it's=0D=0A= subscribers=0D=0A> > be=0D=0A> > > > > > willing to provide LbyR dereferenc= eable by PSAPs (again=0D=0A> > > > remembering=0D=0A> > > > > > that the ac= cess network are local to the PSAPs) as=0D=0A> > well as LoST=0D=0A> > > > = > > query services to their endpoints=3F Would this address=0D=0A> > > > t= he concerns=0D=0A> > > > > > raised by Deutsche Telecom on this issue=3F=0D= =0A> > > > > >=0D=0A> > > > > > Let me be very clear that I think this is a= n ugly solution.=0D=0A> > > > > > I think that everyone will be much better= off if=0D=0A> > endpoints knew=0D=0A> > > > > > where they were, and apps = could take advantage of that.=0D=0A> > > > > > I think we'll get there. I = think tying location=0D=0A> > > > configuration with=0D=0A> > > > > > the L= oST query is a bad idea. I think using LbyR for=0D=0A> > emergency=0D=0A> = > > > > > calls is a bad idea.=0D=0A> > > > > >=0D=0A> > > > > > But I can = live with it.=0D=0A> > > > > >=0D=0A> > > > > > Brian=0D=0A> > > > > >=0D=0A= > > > > > > _______________________________________________=0D=0A> > > > > = > Ecrit mailing list=0D=0A> > > > > > Ecrit@ietf.org=0D=0A> > > > > > https= ://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > > > >=0D=0A> > > > > _____= __________________________________________=0D=0A> > > > > Geopriv mailing l= ist=0D=0A> > > > > Geopriv@ietf.org=0D=0A> > > > > https://www1.ietf.org/ma= ilman/listinfo/geopriv=0D=0A> > >=0D=0A> > > ______________________________= _________________=0D=0A> > > Ecrit mailing list=0D=0A> > > Ecrit@ietf.org=0D= =0A> > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> >=0D=0A> > ---= -----------------------------------------------------------=0D=0A> > ------= ----------------------------=0D=0A> > This message is for the designated re= cipient only and may=0D=0A> > contain privileged, proprietary, or otherwise= private information.=0D=0A> > If you have received it in error, please not= ify the sender=0D=0A> > immediately and delete the original. Any unauthori= zed use of=0D=0A> > this email is prohibited.=0D=0A> > --------------------= ------------------------------------------=0D=0A> > -----------------------= -----------=0D=0A> > [mf2]=0D=0A> >=0D=0A=0D=0A----------------------------= --------------------------------------------------------------------=0D=0AT= his message is for the designated recipient only and may=0D=0Acontain privi= leged, proprietary, or otherwise private information. =20=0D=0AIf you have = received it in error, please notify the sender=0D=0Aimmediately and delete = the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Apr 15 20:10:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdEnw-0008H5-KX; Sun, 15 Apr 2007 20:10:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdEnv-0008Gl-KB for ecrit@ietf.org; Sun, 15 Apr 2007 20:10:47 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdEnv-0006GZ-9c for ecrit@ietf.org; Sun, 15 Apr 2007 20:10:47 -0400 X-SEF-Processed: 5_0_0_910__2007_04_15_19_17_21 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 15 Apr 2007 19:17:20 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Apr 2007 19:10:46 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] LoST civic caching issue X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 15 Apr 2007 19:10:45 -0500 Message-ID: In-Reply-To: <635EDC7F-A2F3-4D13-B7DE-27E4EC709CC5@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST civic caching issue Thread-Index: Acd+7SmXtRpzcK4XRGWcLc4I+T8qPwAzIxKA From: "Thomson, Martin" To: "Henning Schulzrinne" , "Hannes Tschofenig" X-OriginalArrivalTime: 16 Apr 2007 00:10:46.0837 (UTC) FILETIME=[AE9B3E50:01C77FBB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0054366851==" Errors-To: ecrit-bounces@ietf.org --===============0054366851== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSdtIG9wcG9zZWQgdG8gdGhlIGlkZWEgb2YgdXNpbmcgcG9seWdvbiB3cmFwcGluZyB0byBkZWFs IHdpdGggaG9sZXMuICBJdCBpcyBvdmVybHkgY29tcGxpY2F0ZWQsIHBhcnRpY3VsYXJseSB3aGVu IGhvbGVzIGNhbiBlYXNpbHkgYmUgaW5jbHVkZWQgaW4gdGhlIGRhdGEgYnkgbGlua2luZyBhIDAu Lm4gaG9sZXMgd2l0aCBlYWNoIGFyZWEuICBEYXRhYmFzZSBzY2hlbWEgbWlnaHQgYmVjb21lIG1v cmUgY29tcGxpY2F0ZWQsIGJ1dCBub3QgdW5tYW5hZ2VhYmx5IHNvOyBhbmQgYmV0dGVyIHRoYXQg dGhhbiBwdXNoIHRoZSBwcm9ibGVtIG9uIHRob3NlIHdobyBwb3B1bGF0ZSB0aGUgZGF0YWJhc2Uu DQoNCkkgYWdyZWUgdGhhdCBob2xlcyBjYW4gb25seSByZWFsbHkgYmUgcHJvcGVybHkgYWRkcmVz c2VkIGJ5IHNvbWUgZm9ybSBvZiBjb29yZGluYXRpb24uICBBdCB0aGUgdmVyeSBsZWFzdCwgd2Ug Y2FuIGV4cGVjdCB0aGF0IHRoZSBjYW1wdXMgYXV0aG9yaXR5IHRvIHRhbGsgd2l0aCB0aGUgY2l0 eSBhdXRob3JpdHkuDQoNCkZvbGxvd2luZyB0aGF0IHByaW5jaXBsZSwgdGhlIGRlc2NyaXB0aW9u IG9mIGNvdmVyYWdlIGFyZWFzIGlzIHNpbWlsYXIgZm9yIGJvdGggZ2VvZGV0aWMgYW5kIGNpdmlj IGRhdGEuICBHZW9kZXRpYyBpbmNsdWRlcyBhIHBvbHlnb24gKGV4dGVyaW9yKSB3aXRoIDAuLm4g aG9sZXMgKGludGVyaW9yKS4gIENpdmljIGluY2x1ZGVzIGEgY292ZXJhZ2UgYXJlYSAoYSBjaXZp YyBhZGRyZXNzLCBzcGVjaWZpZWQgZG93biB0byBhIHNwZWNpZmljIGxldmVsKSB3aXRoIDAuLm4g aG9sZXMgKHNwZWNpZmljIGNpdmljIGFkZHJlc3NlcyB0aGF0IHNoYXJlIGVsZW1lbnRzIHdpdGgg dGhlIGhpZ2hlciBsZXZlbCBhZGRyZXNzLCBidXQgYXJlIG5vdCBjb3ZlcmVkKS4NCg0KU3VjaCBh IHNvbHV0aW9uIGlzIGVhc2lseSBnZW5lcmFsaXplZCB3aXRob3V0IHNpZ25pZmljYW50bHkgYWZm ZWN0aW5nIHRoZSBMb1NUIHNlcnZlci4gIFRoZSBob3BlIGlzIHRoYXQgaG9sZXMgYXJlIG5vdCBz byBwcmV2YWxlbnQgdGhhdCBlaXRoZXIgZGF0YSBzdHJ1Y3R1cmUgYmVjb21lcyBsYXJnZSBhbmQg b25lcm91cy4NCg0KQ2hlZXJzLA0KTWFydGluDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogSGVubmluZyBTY2h1bHpyaW5uZSBbbWFpbHRvOmhnc0Bjcy5jb2x1bWJpYS5l ZHVdDQo+IFNlbnQ6IFN1bmRheSwgMTUgQXByaWwgMjAwNyA5OjMyIEFNDQo+IFRvOiBIYW5uZXMg VHNjaG9mZW5pZw0KPiBDYzogRUNSSVQNCj4gU3ViamVjdDogUmU6IFtFY3JpdF0gTG9TVCBjaXZp YyBjYWNoaW5nIGlzc3VlDQo+IA0KPiANCj4gT24gQXByIDE0LCAyMDA3LCBhdCAxMjo0MSBQTSwg SGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+IA0KPiA+IEhpIEhlbm5pbmcsDQo+ID4NCj4gPiB0 aGFua3MgZm9yIHJhaXNpbmcgdGhpcyBpc3N1ZSBhbmQgaXQgaXMgaW4gZmFjdCBhIGRpZmZpY3Vs dCBwcm9ibGVtLg0KPiA+DQo+ID4gSSBzZWUgdHdvIGFzcGVjdHMgd2l0aCB0aGUgInRoZSBkb251 dCBwcm9ibGVtIiwgIGkuZS4sIHRoZXJlIGlzIGENCj4gPiBsYXJnZXIgc2VydmljZSBib3VuZGFy eSB3aXRoIGFub3RoZXIgc2VydmljZSBhcmVhIHdpdGhpbiAodGhlIGhvbGUNCj4gPiBpbiB0aGUg ZG9udXQpLiBUaGVyZSBhcmUgdHdvIGNhc2VzOg0KPiA+DQo+ID4gKiBUaGUgZW50aXR5IHJlc3Bv bnNpYmxlIGZvciB0aGUgbGFyZ2VyIHNlcnZpY2UgYXJlYSBrbm93cyB0aGF0DQo+ID4gdGhlcmUg aXMgYSBkb251dCBwcm9ibGVtLiBJbiB0aGlzIGNhc2UgaXQgd291bGQgYmUgcmVhc29uYWJsZSB0 bw0KPiA+IGFzc3VtZSB0aGF0IHRoaXMgZW50aXR5IGNvdWxkIG1hcmsgdGhlIHJlc3BvbnNlIGFz ICJub24gY2FjaGFibGUiLg0KPiA+IEZvciBnZW8gb25lIHdvdWxkIHdhbnQgdG8gZXhwcmVzcyB0 aGUgc2VydmljZSBhcmVhIGFzIGEgZG9udXQgLS0NCj4gPiBjdXJyZW50bHkgd2UgZG9uJ3QgaGF2 ZSBhIGRlc2NyaXB0aW9uIGhvdyB0byBkZXNjcmliZSBzdWNoIGEgc2hhcGUuDQo+ID4gSSAgbm93 IGJlbGlldmUgdGhhdCB3ZSBzaG91bGQgYWRkIHNvbWV0aGluZyB0byB0aGUgUElERi1MTyBwcm9m aWxlDQo+ID4gZHJhZnQuDQo+IA0KPiBQb2x5Z29ucyBjYW4gYmUgdXNlZCB0byBkZXNjcmliZSBz dHJ1Y3R1cmVzIHdpdGggaG9sZXMgLSB5b3UganVzdA0KPiBoYXZlIHRvIGhhdmUgdGhlIHBvbHln b24gJ3dyYXAgYXJvdW5kJyB0aGUgaG9sZSBhbmQgb3ZlcmxhcCBpbiB0aGUNCj4gbWlkZGxlLiBJ dCBnZXRzIHRlZGlvdXMgZm9yIG11bHRpcGxlIGhvbGVzLg0KPiANCj4gQWxzbywgaXQgYXBwZWFy cyB0aGF0IGNvbW1vbiBTUUwgZGF0YWJhc2VzIHdpdGggZ2VvIGV4dGVuc2lvbnMsIHN1Y2gNCj4g YXMgdGhlIHBvcHVsYXIgUG9zdEdJUywgZG8gbm90IHN1cHBvcnQgc3VjaCBjb21wbGljYXRlZCBz aGFwZXMuIFRodXMsDQo+IGl0IG1heSBiZSBhIGJldHRlciBpZGVhIHRvIGNvbXBvc2UgdGhpcywg YXMgYSBzZXQgb2YgY292ZXJhZ2UNCj4gcG9seWdvbnMgW3dlIGdvdCB0aGF0XSBhbmQgYSBzZXQg b2YgZXhjZXB0aW9ucy4NCj4gDQo+IA0KPiANCj4gPg0KPiA+ICogVGhlIGVudGl0eSByZXNwb25z aWJsZSBmb3IgdGhlIGxhcmdlciBzZXJ2aWNlIGFyZWEgZG9lcyBOT1Qga25vdw0KPiA+IGFib3V0 IGEgcG90ZW50aWFsIGRvbnV0IHByb2JsZW0uIFRoaXMgY2FzZSBpcyBhY3R1YWxseSBub3QgcmVs YXRlZA0KPiA+IHRvIGNpdmljIHNpbmNlIGl0IGNhbiBhcHBlYXIgaW4gZ2VvIGFzIHdlbGwuIEkg ZG9uJ3QgaGF2ZSBhbiBlYXN5DQo+ID4gYW5kIG5pY2UgYW5zd2VyIGZvciB0aGlzIGNhc2UuDQo+ IA0KPiBUaGF0IGlzIGluZGVlZCB0aGUgaGFyZCBjYXNlLiBIb3dldmVyLCBJIGJlbGlldmUgaXQg aXMgcHJvcGVybHkgdGhlDQo+IHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBleGNlcHRpb24gY2FzZSB0 byBub3RpZnkgdGhlIHN1cnJvdW5kaW5nIGVudGl0eQ0KPiB0aGF0IGl0IHdhbnRzIHRvIGJlIGNv bnNpZGVyZWQgYSAnaG9sZScuIE15IHBlcmNlcHRpb24gaXMgdGhhdA0KPiBpbnN0aXR1dGlvbnMs IHN1Y2ggYXMgdW5pdmVyc2l0eSBjYW1wdXNlcywgd2l0aCB0aGVpciBvd24gcG9saWNlDQo+IGZv cmNlIG9yIGFtYnVsYW5jZSBjb3JwcyBjb29yZGluYXRlIHdpdGggdGhlIGxvY2FsIGNpdmljIGF1 dGhvcml0aWVzLA0KPiByYXRoZXIgdGhhbiBqdXN0IGZyZWVsYW5jZS4gSSBkb24ndCBrbm93IHRo ZSBwb2xpdGljcyBvciBsZWdhbGl0aWVzDQo+IG9mIHdoZXRoZXIsIHNheSwgdGhlIE5ZUEQgd291 bGQgYWxsb3cgdGhlIENvbHVtYmlhIHBvbGljZSBmb3JjZSB0byBiZQ0KPiBkZWNsYXJlZCBvZmZp Y2lhbGx5IGluIGNoYXJnZS4gSWYgYWxsIGVsc2UgZmFpbHMsIHRoZSBsb2NhbCBMb1NUDQo+IHJl c29sdmVyIHdvdWxkIGhhdmUgdG8gaW1wbGVtZW50IGxvY2FsIHBvbGljeS4gVGhpcyBpcyBzaW1p bGFyIHRvDQo+IHdoYXQgaGFwcGVucyB0b2RheTogSWYgeW91IGRpYWwgOTExIG9uIGEgY2VsbCBw aG9uZSB3aGlsZSBvbiB0aGUNCj4gQ29sdW1iaWEgY2FtcHVzLCB5b3UnbGwgYmUgY29ubmVjdGVk IHRvIHRoZSBOWVBELCBub3QgY2FtcHVzIHBvbGljZS4NCj4gDQo+IEhlbm5pbmcNCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEVjcml0IG1h aWxpbmcgbGlzdA0KPiBFY3JpdEBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9lY3JpdA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkg YW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHBy aXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdp bmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0NCg== --===============0054366851== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0054366851==-- From ecrit-bounces@ietf.org Sun Apr 15 21:32:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdG5B-00039r-6o; Sun, 15 Apr 2007 21:32:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdG5A-00039j-27 for ecrit@ietf.org; Sun, 15 Apr 2007 21:32:40 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdG58-00067x-PD for ecrit@ietf.org; Sun, 15 Apr 2007 21:32:40 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3G1WT4l011387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sun, 15 Apr 2007 21:32:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <75BE6CD6-A8A2-416F-9BC4-627341225C1B@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Henning Schulzrinne Date: Sun, 15 Apr 2007 21:32:30 -0400 X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Ecrit] Hiding (partial) locations X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org After the discussion, I think the simplest approach is the partial response solution: The ISP returns partial location information that is sufficiently accurate to return the correct PSAP. This would typically be the county or city. This reveals (almost) no additional information to the client beyond the PSAP URL. After all, the PSAP boundaries are public or easily guessable, so it would be easy for an external entity to construct a mapping that maps PSAP URLs back to rough locations, thus defeating the efforts by the ISP to hide the location information from their customers. This level of location information is also more or less what you can get for free already from services such as http://www.ip2location.com/free.asp or MaxMind. There are two mechanisms for doing that: (1) combined LbyV and LbyR: rough information by value, precise information by (protected) reference; (2) just LbyR, but the reference is roughly resolvable by possession, precise resolution requires a shared secret (held by the PSAP). This approach has three advantages: (1) If all else fails (such as attempts to resolve the reference), the PSAP at least has some location information to work with, rather than a completely useless reference. This is particularly important if the call arrives at an overflow or backup PSAP, since it will assume that the call is from its service area and it may not be able to resolve the reference due to lack of an established trust relationship. (2) The client can verify the information, reducing errors. (3) Nothing changes in terms of processing compared to providing full location information. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Apr 15 21:39:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdGCA-0006QP-6b; Sun, 15 Apr 2007 21:39:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdGC9-0006Om-04 for ecrit@ietf.org; Sun, 15 Apr 2007 21:39:53 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdGC7-00009v-Ie for ecrit@ietf.org; Sun, 15 Apr 2007 21:39:52 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3G1dg42025205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 15 Apr 2007 21:39:42 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST civic caching issue Date: Sun, 15 Apr 2007 21:39:42 -0400 To: "Thomson, Martin" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 15, 2007, at 8:10 PM, Thomson, Martin wrote: > I'm opposed to the idea of using polygon wrapping to deal with > holes. It is overly complicated, particularly when holes can > easily be included in the data by linking a 0..n holes with each > area. Database schema might become more complicated, but not > unmanageably so; and better that than push the problem on those who > populate the database. I'm no friend of wrapping, either, but the problem is not the schema. As far as I can tell, existing open source geo databases just don't support these, so you have to write a custom database. Not a good idea. > > I agree that holes can only really be properly addressed by some > form of coordination. At the very least, we can expect that the > campus authority to talk with the city authority. > > Following that principle, the description of coverage areas is > similar for both geodetic and civic data. Geodetic includes a > polygon (exterior) with 0..n holes (interior). Civic includes a > coverage area (a civic address, specified down to a specific level) > with 0..n holes (specific civic addresses that share elements with > the higher level address, but are not covered). > > Such a solution is easily generalized without significantly > affecting the LoST server. The hope is that holes are not so > prevalent that either data structure becomes large and onerous. > I'm proposing that the holes are separate entities from the enclosing polygon or civic coverage area, as in [enclosing polygon/civic without hole] [exception 1 (geo or civic)] [exception 2 (geo or civic)] ... Obviously, no mixing of geo and civic is allowed. I'm not sure if that's the same thing you're proposing. This has the advantage that you can search efficiently. For polygons, you'll get two matches: the hole, which refers to the exception record, and the enclosing polygon. > Cheers, > Martin _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Apr 15 21:49:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdGLf-0001lo-Fz; Sun, 15 Apr 2007 21:49:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdGLd-0001kS-7N for ecrit@ietf.org; Sun, 15 Apr 2007 21:49:41 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdGIJ-0004PG-OW for ecrit@ietf.org; Sun, 15 Apr 2007 21:46:15 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3G1k9SX025924 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 15 Apr 2007 21:46:13 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <72A60240-B654-40FC-8153-17F184EB4C9B@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Date: Sun, 15 Apr 2007 21:46:09 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'll just add that you have to provide the client with rough location information ahead of time. Otherwise, it has no clue when to re-query LoST for an updated mapping. Rough location is better than no location - at least the call gets to the right PSAP. Having a location lookup fail completely at call time would likely cause the call to be routed to the wrong PSAP or, worst case, to some generic backup call center. We have long had agreement that we want pre-call lookup to have at least some rough location and PSAP data. Why are we re-opening this debate? Again, this reveals very little additional information to the client, as the client can already determine the tower ID today. On Apr 15, 2007, at 6:29 PM, Winterbottom, James wrote: > Marc, > >> -----Original Message----- >> From: Marc Linsner [mailto:mlinsner@cisco.com] >> Sent: Monday, 16 April 2007 5:58 AM >> To: Winterbottom, James >> Cc: ecrit@ietf.org >> Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to >> doendpointcentric LCPwithout giving away the store >> >> James, >> >>> >>> I am not so sure that this anymore the case than it would be >>> with a location value is it? >> >> No, if the client has LbyV, the client can do the LoST lookup at call >> time. >> > [AJW] This presupposes that the location has not changed. If the > location has changed then this doesn't help unless the client also > requests a new location at call time. In this case I put to you that > there is no difference in the number of queries performed. > >>> >>> If the device is fixed, then the likelihood of change in low, >>> but the PSAP route could be tagged with an expiry the same as >>> a literal location can. So I think this is the same problem. >> >> You are suggesting the host go back to the access network when >> setting > up >> an >> emergency call? > > [AJW] Local network hit is likely to be faster than a wide-area > network > hit. > >> >> I wonder if a course location (enough to route properly) with LbyR >> embedded >> in the LbyV would be better. >> > > [AJW] Hmmm, maybe. I would need to think about this one a bit more > as I > am not sure that we can easily arrive at a solution to how coarse > is too > coarse, or too fine. > > >> The access provider can take the fine grain location, perform a LoST >> lookup, >> give the client only the tuples that LoST returned in the service >> boundary. >> The client can then perform a LoST lookup anytime with that set of > tuples. >> If the client is fixed no need to contact the access network at > emergency >> call time. >> >> I worry about too many dependencies at call time. > > [AJW] Agreed, but we need to allow people to deploy it also. Like most > things some ground in the middle will need to be found. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Apr 15 22:02:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdGXc-0005HI-5W; Sun, 15 Apr 2007 22:02:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdGXa-0005H7-Cq for ecrit@ietf.org; Sun, 15 Apr 2007 22:02:02 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdGXa-0003Ft-1T for ecrit@ietf.org; Sun, 15 Apr 2007 22:02:02 -0400 X-SEF-Processed: 5_0_0_910__2007_04_15_21_08_35 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 15 Apr 2007 21:08:35 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Apr 2007 21:02:01 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] LoST civic caching issue X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 15 Apr 2007 21:01:59 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST civic caching issue Thread-Index: Acd/yB/ZwVF1EnogQAy5IBR7mlBHJAAADFbg From: "Thomson, Martin" To: "Henning Schulzrinne" X-OriginalArrivalTime: 16 Apr 2007 02:02:01.0667 (UTC) FILETIME=[391D7930:01C77FCB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0191201566==" Errors-To: ecrit-bounces@ietf.org --===============0191201566== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBIZW5uaW5nIFNjaHVsenJpbm5l IFttYWlsdG86aGdzQGNzLmNvbHVtYmlhLmVkdV0NCj4gU2VudDogTW9uZGF5LCAxNiBBcHJpbCAy MDA3IDExOjQwIEFNDQo+IFRvOiBUaG9tc29uLCBNYXJ0aW4NCj4gQ2M6IEhhbm5lcyBUc2Nob2Zl bmlnOyBFQ1JJVA0KPiBTdWJqZWN0OiBSZTogW0Vjcml0XSBMb1NUIGNpdmljIGNhY2hpbmcgaXNz dWUNCj4gDQo+IA0KPiBPbiBBcHIgMTUsIDIwMDcsIGF0IDg6MTAgUE0sIFRob21zb24sIE1hcnRp biB3cm90ZToNCj4gDQo+ID4gSSdtIG9wcG9zZWQgdG8gdGhlIGlkZWEgb2YgdXNpbmcgcG9seWdv biB3cmFwcGluZyB0byBkZWFsIHdpdGgNCj4gPiBob2xlcy4gIEl0IGlzIG92ZXJseSBjb21wbGlj YXRlZCwgcGFydGljdWxhcmx5IHdoZW4gaG9sZXMgY2FuDQo+ID4gZWFzaWx5IGJlIGluY2x1ZGVk IGluIHRoZSBkYXRhIGJ5IGxpbmtpbmcgYSAwLi5uIGhvbGVzIHdpdGggZWFjaA0KPiA+IGFyZWEu ICBEYXRhYmFzZSBzY2hlbWEgbWlnaHQgYmVjb21lIG1vcmUgY29tcGxpY2F0ZWQsIGJ1dCBub3QN Cj4gPiB1bm1hbmFnZWFibHkgc287IGFuZCBiZXR0ZXIgdGhhdCB0aGFuIHB1c2ggdGhlIHByb2Js ZW0gb24gdGhvc2Ugd2hvDQo+ID4gcG9wdWxhdGUgdGhlIGRhdGFiYXNlLg0KPiANCj4gSSdtIG5v IGZyaWVuZCBvZiB3cmFwcGluZywgZWl0aGVyLCBidXQgdGhlIHByb2JsZW0gaXMgbm90IHRoZSBz Y2hlbWEuDQo+IEFzIGZhciBhcyBJIGNhbiB0ZWxsLCBleGlzdGluZyBvcGVuIHNvdXJjZSBnZW8g ZGF0YWJhc2VzIGp1c3QgZG9uJ3QNCj4gc3VwcG9ydCB0aGVzZSwgc28geW91IGhhdmUgdG8gd3Jp dGUgYSBjdXN0b20gZGF0YWJhc2UuIE5vdCBhIGdvb2QgaWRlYS4NCg0KSSdtIG5vdCBzdXJlIHdo YXQgeW91IG1lYW4gYnkgInN1cHBvcnQiIHRoZW4uICBIb2xlcyBhcyBleGNlcHRpb25zLCBhcyB5 b3Ugc2hvdyBiZWxvdywgYXJlIGVhc3kuICBCdXQgc2VtYW50aWNhbGx5LCBQb2x5Z29ucyB3aXRo IDxleHRlcmlvcj4vPGludGVyaW9yPiogYXJlIG5vIGRpZmZlcmVudC4NCg0KPiANCj4gPg0KPiA+ IEkgYWdyZWUgdGhhdCBob2xlcyBjYW4gb25seSByZWFsbHkgYmUgcHJvcGVybHkgYWRkcmVzc2Vk IGJ5IHNvbWUNCj4gPiBmb3JtIG9mIGNvb3JkaW5hdGlvbi4gIEF0IHRoZSB2ZXJ5IGxlYXN0LCB3 ZSBjYW4gZXhwZWN0IHRoYXQgdGhlDQo+ID4gY2FtcHVzIGF1dGhvcml0eSB0byB0YWxrIHdpdGgg dGhlIGNpdHkgYXV0aG9yaXR5Lg0KPiA+DQo+ID4gRm9sbG93aW5nIHRoYXQgcHJpbmNpcGxlLCB0 aGUgZGVzY3JpcHRpb24gb2YgY292ZXJhZ2UgYXJlYXMgaXMNCj4gPiBzaW1pbGFyIGZvciBib3Ro IGdlb2RldGljIGFuZCBjaXZpYyBkYXRhLiAgR2VvZGV0aWMgaW5jbHVkZXMgYQ0KPiA+IHBvbHln b24gKGV4dGVyaW9yKSB3aXRoIDAuLm4gaG9sZXMgKGludGVyaW9yKS4gIENpdmljIGluY2x1ZGVz IGENCj4gPiBjb3ZlcmFnZSBhcmVhIChhIGNpdmljIGFkZHJlc3MsIHNwZWNpZmllZCBkb3duIHRv IGEgc3BlY2lmaWMgbGV2ZWwpDQo+ID4gd2l0aCAwLi5uIGhvbGVzIChzcGVjaWZpYyBjaXZpYyBh ZGRyZXNzZXMgdGhhdCBzaGFyZSBlbGVtZW50cyB3aXRoDQo+ID4gdGhlIGhpZ2hlciBsZXZlbCBh ZGRyZXNzLCBidXQgYXJlIG5vdCBjb3ZlcmVkKS4NCj4gPg0KPiA+IFN1Y2ggYSBzb2x1dGlvbiBp cyBlYXNpbHkgZ2VuZXJhbGl6ZWQgd2l0aG91dCBzaWduaWZpY2FudGx5DQo+ID4gYWZmZWN0aW5n IHRoZSBMb1NUIHNlcnZlci4gIFRoZSBob3BlIGlzIHRoYXQgaG9sZXMgYXJlIG5vdCBzbw0KPiA+ IHByZXZhbGVudCB0aGF0IGVpdGhlciBkYXRhIHN0cnVjdHVyZSBiZWNvbWVzIGxhcmdlIGFuZCBv bmVyb3VzLg0KPiA+DQo+IA0KPiBJJ20gcHJvcG9zaW5nIHRoYXQgdGhlIGhvbGVzIGFyZSBzZXBh cmF0ZSBlbnRpdGllcyBmcm9tIHRoZSBlbmNsb3NpbmcNCj4gcG9seWdvbiBvciBjaXZpYyBjb3Zl cmFnZSBhcmVhLCBhcyBpbg0KPiANCj4gW2VuY2xvc2luZyBwb2x5Z29uL2NpdmljIHdpdGhvdXQg aG9sZV0NCj4gPGV4Y2VwdD4NCj4gICBbZXhjZXB0aW9uIDEgKGdlbyBvciBjaXZpYyldDQo+IDwv ZXhjZXB0Pg0KPiA8ZXhjZXB0Pg0KPiAgIFtleGNlcHRpb24gMiAoZ2VvIG9yIGNpdmljKV0NCj4g PC9leGNlcHQ+DQo+IC4uLg0KPiANCj4gT2J2aW91c2x5LCBubyBtaXhpbmcgb2YgZ2VvIGFuZCBj aXZpYyBpcyBhbGxvd2VkLg0KDQpUaGF0IHdvcmtzLiAgSXQgaGFzIHRoZSBhZHZhbnRhZ2Ugb2Yg YmVpbmcgdGhlIHNhbWUgZm9yIGdlb2RldGljIGFuZCBjaXZpYy4gIEl0IGFsc28gbWVhbnMgdGhh dCB0aGUgZ2VvZGV0aWMgcHJvZmlsZSByZW1haW5zIHNpbXBsZS4NCg0KPiBJJ20gbm90IHN1cmUg aWYgdGhhdCdzIHRoZSBzYW1lIHRoaW5nIHlvdSdyZSBwcm9wb3NpbmcuDQoNCkNsb3NlIGVub3Vn aCAtIEkgd2Fzbid0IHRoaW5raW5nIG9mIGFueSBzcGVjaWZpYyBlbmNvZGluZywgYnV0IHRoZSBn ZW5lcmFsaXphdGlvbiBpcyBhIGdvb2QgZml0Lg0KDQo+IFRoaXMgaGFzIHRoZSBhZHZhbnRhZ2Ug dGhhdCB5b3UgY2FuIHNlYXJjaCBlZmZpY2llbnRseS4gRm9yIHBvbHlnb25zLA0KPiB5b3UnbGwg Z2V0IHR3byBtYXRjaGVzOiB0aGUgaG9sZSwgd2hpY2ggcmVmZXJzIHRvIHRoZSBleGNlcHRpb24N Cj4gcmVjb3JkLCBhbmQgdGhlIGVuY2xvc2luZyBwb2x5Z29uLg0KDQpJIGNhbiBzZWUgc2V2ZXJh bCBvcHRpb25zIGZvciBkYXRhYmFzZSBkZXNpZ24uICBEZXRlcm1pbmluZyB0aGF0IHRoaXMgaXNu J3QgaW1wb3NzaWJsZSAob3IgYXQgbGVhc3QgaXQgaXNuJ3QgcmVhbGx5IGhhcmQpIHNob3VsZCBi ZSBlbm91Z2ggZm9yIHNwZWNpZmljYXRpb24gcHVycG9zZXMuDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQg cmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwg b3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVk IGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBk ZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwg aXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K W21mMl0NCg== --===============0191201566== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0191201566==-- From ecrit-bounces@ietf.org Sun Apr 15 23:04:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdHVk-0002ZK-Im; Sun, 15 Apr 2007 23:04:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdHVj-0002ZE-IC for ecrit@ietf.org; Sun, 15 Apr 2007 23:04:11 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdHVj-0001E8-8g for ecrit@ietf.org; Sun, 15 Apr 2007 23:04:11 -0400 X-SEF-Processed: 5_0_0_910__2007_04_15_22_10_45 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 15 Apr 2007 22:10:45 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Apr 2007 22:04:10 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 15 Apr 2007 22:04:09 -0500 Message-ID: In-Reply-To: <72A60240-B654-40FC-8153-17F184EB4C9B@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Thread-Index: Acd/yQUOO56WzXwyTTGjMa1lAqaB7wACnGLQ From: "Winterbottom, James" To: "Henning Schulzrinne" X-OriginalArrivalTime: 16 Apr 2007 03:04:10.0759 (UTC) FILETIME=[E7D3C170:01C77FD3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Sorry Henning perhaps I wasn't being to clear as I was leveraging off=0D=0A= Brian's previous statement about changing the L7 LCP response type.=0D=0A=0D= =0AI would therefore return an expiry time for the created context that=0D=0A= applied equally to the LoST URI. That is the LIS would choose the=0D=0Ashor= test of the two and provide that as the expiry time the end-point,=0D=0Aso = when the end-point updates the context, it gets the new PSAP URI.=0D=0ADoes= that make sense=3F=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=20=0D=0A=0D=0A> ----= -Original Message-----=0D=0A> From: Henning Schulzrinne [mailto:hgs@cs.colu= mbia.edu]=0D=0A> Sent: Monday, 16 April 2007 11:46 AM=0D=0A> To: Winterbott= om, James=0D=0A> Cc: Marc Linsner; ecrit@ietf.org=0D=0A> Subject: Re: [Geop= riv] RE: [Ecrit] Not-so-grand compromise on how to=0D=0A> doendpointcentric= LCPwithout giving away the store=0D=0A>=20=0D=0A> I'll just add that you h= ave to provide the client with rough location=0D=0A> information ahead of t= ime. Otherwise, it has no clue when to re-query=0D=0A> LoST for an updated = mapping. Rough location is better than no=0D=0A> location - at least the ca= ll gets to the right PSAP. Having a=0D=0A> location lookup fail completely = at call time would likely cause the=0D=0A> call to be routed to the wrong P= SAP or, worst case, to some generic=0D=0A> backup call center.=0D=0A>=20=0D= =0A> We have long had agreement that we want pre-call lookup to have at=0D=0A= > least some rough location and PSAP data. Why are we re-opening this=0D=0A= > debate=3F=0D=0A>=20=0D=0A> Again, this reveals very little additional inf= ormation to the client,=0D=0A> as the client can already determine the towe= r ID today.=0D=0A>=20=0D=0A> On Apr 15, 2007, at 6:29 PM, Winterbottom, Jam= es wrote:=0D=0A>=20=0D=0A> > Marc,=0D=0A> >=0D=0A> >> -----Original Message= -----=0D=0A> >> From: Marc Linsner [mailto:mlinsner@cisco.com]=0D=0A> >> Se= nt: Monday, 16 April 2007 5:58 AM=0D=0A> >> To: Winterbottom, James=0D=0A> = >> Cc: ecrit@ietf.org=0D=0A> >> Subject: RE: [Geopriv] RE: [Ecrit] Not-so-g= rand compromise on how=0D=0Ato=0D=0A> >> doendpointcentric LCPwithout givin= g away the store=0D=0A> >>=0D=0A> >> James,=0D=0A> >>=0D=0A> >>>=0D=0A> >>>= I am not so sure that this anymore the case than it would be=0D=0A> >>> wi= th a location value is it=3F=0D=0A> >>=0D=0A> >> No, if the client has LbyV= , the client can do the LoST lookup at=0D=0Acall=0D=0A> >> time.=0D=0A> >>=0D= =0A> > [AJW] This presupposes that the location has not changed. If the=0D=0A= > > location has changed then this doesn't help unless the client also=0D=0A= > > requests a new location at call time. In this case I put to you that=0D= =0A> > there is no difference in the number of queries performed.=0D=0A> >=0D= =0A> >>>=0D=0A> >>> If the device is fixed, then the likelihood of change i= n low,=0D=0A> >>> but the PSAP route could be tagged with an expiry the sam= e as=0D=0A> >>> a literal location can. So I think this is the same problem= =2E=0D=0A> >>=0D=0A> >> You are suggesting the host go back to the access n= etwork when=0D=0A> >> setting=0D=0A> > up=0D=0A> >> an=0D=0A> >> emergency = call=3F=0D=0A> >=0D=0A> > [AJW] Local network hit is likely to be faster th= an a wide-area=0D=0A> > network=0D=0A> > hit.=0D=0A> >=0D=0A> >>=0D=0A> >> = I wonder if a course location (enough to route properly) with LbyR=0D=0A> >= > embedded=0D=0A> >> in the LbyV would be better.=0D=0A> >>=0D=0A> >=0D=0A>= > [AJW] Hmmm, maybe. I would need to think about this one a bit more=0D=0A= > > as I=0D=0A> > am not sure that we can easily arrive at a solution to ho= w coarse=0D=0A> > is too=0D=0A> > coarse, or too fine.=0D=0A> >=0D=0A> >=0D= =0A> >> The access provider can take the fine grain location, perform a=0D=0A= LoST=0D=0A> >> lookup,=0D=0A> >> give the client only the tuples that LoST = returned in the service=0D=0A> >> boundary.=0D=0A> >> The client can then p= erform a LoST lookup anytime with that set of=0D=0A> > tuples.=0D=0A> >> If= the client is fixed no need to contact the access network at=0D=0A> > emer= gency=0D=0A> >> call time.=0D=0A> >>=0D=0A> >> I worry about too many depen= dencies at call time.=0D=0A> >=0D=0A> > [AJW] Agreed, but we need to allow = people to deploy it also. Like=0D=0Amost=0D=0A> > things some ground in the= middle will need to be found.=0D=0A> >=0D=0A>=20=0D=0A=0D=0A--------------= ---------------------------------------------------------------------------= -------=0D=0AThis message is for the designated recipient only and may=0D=0A= contain privileged, proprietary, or otherwise private information. =20=0D=0A= If you have received it in error, please notify the sender=0D=0Aimmediately= and delete the original. Any unauthorized use of=0D=0Athis email is prohi= bited.=0D=0A---------------------------------------------------------------= ---------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Apr 15 23:11:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdHci-0005gM-Dp; Sun, 15 Apr 2007 23:11:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdHcg-0005gG-EE for ecrit@ietf.org; Sun, 15 Apr 2007 23:11:22 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdHce-0002qF-5T for ecrit@ietf.org; Sun, 15 Apr 2007 23:11:22 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3G3B2dp023403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 15 Apr 2007 23:11:07 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8948400A-5AC6-4FA9-B4D7-2FC5239DC36F@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Date: Sun, 15 Apr 2007 23:11:05 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The whole idea of LoST caching is that is both time-based (typically, measured in days or months) and location-based. Thus, I don't see how your mechanism can work. Since there's no way to predict how fast somebody moves, you'd have to have very short expiration times, thus dramatically increasing the LoST query load. In our neighborhood, the PSAP coverage area is roughly a few miles, so at highway speed, so everybody would have to expire bindings every minute or two, even for the vast majority of vehicles that re-visit the same area again and again or stay within the same area. This seems to exactly violate the stipulated "don't make others pay for your business plan" requirement. On Apr 15, 2007, at 11:04 PM, Winterbottom, James wrote: > Sorry Henning perhaps I wasn't being to clear as I was leveraging off > Brian's previous statement about changing the L7 LCP response type. > > I would therefore return an expiry time for the created context that > applied equally to the LoST URI. That is the LIS would choose the > shortest of the two and provide that as the expiry time the end-point, > so when the end-point updates the context, it gets the new PSAP URI. > Does that make sense? > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Apr 15 23:23:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdHoI-00087e-MG; Sun, 15 Apr 2007 23:23:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdHoH-00087Z-PZ for ecrit@ietf.org; Sun, 15 Apr 2007 23:23:21 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdHoH-0005tU-H6 for ecrit@ietf.org; Sun, 15 Apr 2007 23:23:21 -0400 X-SEF-Processed: 5_0_0_910__2007_04_15_22_29_55 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 15 Apr 2007 22:29:55 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Apr 2007 22:23:21 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 15 Apr 2007 22:23:20 -0500 Message-ID: In-Reply-To: <8948400A-5AC6-4FA9-B4D7-2FC5239DC36F@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Thread-Index: Acd/1OdOQNrGRKyYT1qVdAW1MkaZywAANn8g From: "Winterbottom, James" To: "Henning Schulzrinne" X-OriginalArrivalTime: 16 Apr 2007 03:23:21.0179 (UTC) FILETIME=[9587EAB0:01C77FD6] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Please, this is not my business plan and never has been. I am only=0D=0Atry= ing to help move things forward. I must admit though that I don't=0D=0Aunde= rstand how this is any different to providing a location by value in=0D=0At= he same circumstance.=0D=0A=0D=0AYour argument seems to be, you are moving = super fast so the data that=0D=0Ayou have is not right to make a call, go a= nd get new data at call time.=0D=0AIt is not clear to me that there is a re= al difference between:=0D=0A=0D=0Aa) End-point going to the LIS getting upd= ated data then end-point doing=0D=0ALoST lookup and routing call and=0D=0A=0D= =0Ab) End-point asking LIS for location, LIS doing LoST lookup and=0D=0Aret= urning PSAP URI to the end-point.=0D=0A=0D=0AIf the end-point is static, th= en both mechanisms are roughly equivalent=0D=0Aalso.=0D=0A=0D=0AI have no r= eason to hide location from the end-point, but the reality is=0D=0Athat som= e people want to do this. The number of lookup dips is the same=0D=0Ain bot= h circumstances as best as I can tell.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D= =0A=0D=0A> -----Original Message-----=0D=0A> From: Henning Schulzrinne [mai= lto:hgs@cs.columbia.edu]=0D=0A> Sent: Monday, 16 April 2007 1:11 PM=0D=0A> = To: Winterbottom, James=0D=0A> Cc: Marc Linsner; ecrit@ietf.org=0D=0A> Subj= ect: Re: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to=0D=0A> doe= ndpointcentric LCPwithout giving away the store=0D=0A>=20=0D=0A> The whole = idea of LoST caching is that is both time-based (typically,=0D=0A> measured= in days or months) and location-based. Thus, I don't see how=0D=0A> your m= echanism can work. Since there's no way to predict how fast=0D=0A> somebody= moves, you'd have to have very short expiration times, thus=0D=0A> dramati= cally increasing the LoST query load. In our neighborhood, the=0D=0A> PSAP = coverage area is roughly a few miles, so at highway speed, so=0D=0A> everyb= ody would have to expire bindings every minute or two, even for=0D=0A> the = vast majority of vehicles that re-visit the same area again and=0D=0A> agai= n or stay within the same area.=0D=0A>=20=0D=0A> This seems to exactly viol= ate the stipulated "don't make others pay=0D=0A> for your business plan" re= quirement.=0D=0A>=20=0D=0A> On Apr 15, 2007, at 11:04 PM, Winterbottom, Jam= es wrote:=0D=0A>=20=0D=0A> > Sorry Henning perhaps I wasn't being to clear = as I was leveraging=0D=0Aoff=0D=0A> > Brian's previous statement about chan= ging the L7 LCP response type.=0D=0A> >=0D=0A> > I would therefore return a= n expiry time for the created context that=0D=0A> > applied equally to the = LoST URI. That is the LIS would choose the=0D=0A> > shortest of the two and= provide that as the expiry time the=0D=0Aend-point,=0D=0A> > so when the e= nd-point updates the context, it gets the new PSAP URI.=0D=0A> > Does that = make sense=3F=0D=0A> >=0D=0A>=20=0D=0A=0D=0A-------------------------------= -----------------------------------------------------------------=0D=0AThis= message is for the designated recipient only and may=0D=0Acontain privileg= ed, proprietary, or otherwise private information. =20=0D=0AIf you have rec= eived it in error, please notify the sender=0D=0Aimmediately and delete the= original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A---= ---------------------------------------------------------------------------= ------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Apr 15 23:28:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdHtT-00027D-AA; Sun, 15 Apr 2007 23:28:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdHtR-000278-RJ for ecrit@ietf.org; Sun, 15 Apr 2007 23:28:41 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdHtQ-00076n-JH for ecrit@ietf.org; Sun, 15 Apr 2007 23:28:41 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3G3SZ9o008296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 15 Apr 2007 23:28:36 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Date: Sun, 15 Apr 2007 23:28:38 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org No, my note refers to the ability to cache data ahead of the call, as discussed as a requirement. The number of call-associated queries is much, much smaller than the pre-call queries, particularly if caching is "dumbed down" as you seem to suggest. Henning On Apr 15, 2007, at 11:23 PM, Winterbottom, James wrote: > Please, this is not my business plan and never has been. I am only > trying to help move things forward. I must admit though that I don't > understand how this is any different to providing a location by > value in > the same circumstance. > > Your argument seems to be, you are moving super fast so the data that > you have is not right to make a call, go and get new data at call > time. > It is not clear to me that there is a real difference between: > > a) End-point going to the LIS getting updated data then end-point > doing > LoST lookup and routing call and > > b) End-point asking LIS for location, LIS doing LoST lookup and > returning PSAP URI to the end-point. > > If the end-point is static, then both mechanisms are roughly > equivalent > also. > > I have no reason to hide location from the end-point, but the > reality is > that some people want to do this. The number of lookup dips is the > same > in both circumstances as best as I can tell. > > Cheers > James _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Apr 15 23:30:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdHvC-0003HS-Q3; Sun, 15 Apr 2007 23:30:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdHvB-0003HL-7I for ecrit@ietf.org; Sun, 15 Apr 2007 23:30:29 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdHvA-0007bC-Vb for ecrit@ietf.org; Sun, 15 Apr 2007 23:30:29 -0400 X-SEF-Processed: 5_0_0_910__2007_04_15_22_37_03 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 15 Apr 2007 22:37:02 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Apr 2007 22:30:28 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 15 Apr 2007 22:30:27 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Thread-Index: Acd/11OoKZO1uZs1Qy20tcpia8a0SgAADdeg From: "Winterbottom, James" To: "Henning Schulzrinne" X-OriginalArrivalTime: 16 Apr 2007 03:30:28.0593 (UTC) FILETIME=[944A1E10:01C77FD7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org So that being the case, what is the objection=3F=0D=0A=0D=0A=0D=0A> -----Or= iginal Message-----=0D=0A> From: Henning Schulzrinne [mailto:hgs@cs.columbi= a.edu]=0D=0A> Sent: Monday, 16 April 2007 1:29 PM=0D=0A> To: Winterbottom, = James=0D=0A> Cc: Marc Linsner; ecrit@ietf.org=0D=0A> Subject: Re: [Geopriv]= RE: [Ecrit] Not-so-grand compromise on how to=0D=0A> doendpointcentric LCP= without giving away the store=0D=0A>=20=0D=0A> No, my note refers to the ab= ility to cache data ahead of the call, as=0D=0A> discussed as a requirement= =2E The number of call-associated queries is=0D=0A> much, much smaller than= the pre-call queries, particularly if caching=0D=0A> is "dumbed down" as y= ou seem to suggest.=0D=0A>=20=0D=0A> Henning=0D=0A>=20=0D=0A> On Apr 15, 20= 07, at 11:23 PM, Winterbottom, James wrote:=0D=0A>=20=0D=0A> > Please, this= is not my business plan and never has been. I am only=0D=0A> > trying to h= elp move things forward. I must admit though that I don't=0D=0A> > understa= nd how this is any different to providing a location by=0D=0A> > value in=0D= =0A> > the same circumstance.=0D=0A> >=0D=0A> > Your argument seems to be, = you are moving super fast so the data=0D=0Athat=0D=0A> > you have is not ri= ght to make a call, go and get new data at call=0D=0A> > time.=0D=0A> > It = is not clear to me that there is a real difference between:=0D=0A> >=0D=0A>= > a) End-point going to the LIS getting updated data then end-point=0D=0A>= > doing=0D=0A> > LoST lookup and routing call and=0D=0A> >=0D=0A> > b) End= -point asking LIS for location, LIS doing LoST lookup and=0D=0A> > returnin= g PSAP URI to the end-point.=0D=0A> >=0D=0A> > If the end-point is static, = then both mechanisms are roughly=0D=0A> > equivalent=0D=0A> > also.=0D=0A> = >=0D=0A> > I have no reason to hide location from the end-point, but the=0D= =0A> > reality is=0D=0A> > that some people want to do this. The number of = lookup dips is the=0D=0A> > same=0D=0A> > in both circumstances as best as = I can tell.=0D=0A> >=0D=0A> > Cheers=0D=0A> > James=0D=0A>=20=0D=0A=0D=0A--= ---------------------------------------------------------------------------= -------------------=0D=0AThis message is for the designated recipient only = and may=0D=0Acontain privileged, proprietary, or otherwise private informat= ion. =20=0D=0AIf you have received it in error, please notify the sender=0D= =0Aimmediately and delete the original. Any unauthorized use of=0D=0Athis = email is prohibited.=0D=0A-------------------------------------------------= -----------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 05:27:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdNUq-0006Tw-Eg; Mon, 16 Apr 2007 05:27:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdNUp-0006TB-C9 for ecrit@ietf.org; Mon, 16 Apr 2007 05:27:39 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdNUm-00030v-VD for ecrit@ietf.org; Mon, 16 Apr 2007 05:27:39 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTPś id l3G9QPxx019231Mon, 16 Apr 2007 09:26:25 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1HdNQn-000EFU-00; Mon, 16 Apr 2007 10:23:29 +0100 Date: Mon, 16 Apr 2007 10:23:29 +0100 From: "Clive D.W. Feather" To: Henning Schulzrinne Subject: Re: [Ecrit] Hiding (partial) locations Message-ID: <20070416092329.GE49101@finch-staff-1.thus.net> References: <75BE6CD6-A8A2-416F-9BC4-627341225C1B@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75BE6CD6-A8A2-416F-9BC4-627341225C1B@cs.columbia.edu> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning Schulzrinne said: > This level of location information > is also more or less what you can get for free already from services > such as http://www.ip2location.com/free.asp or MaxMind. I hope not. I tried both of these with my home system and my office system. Both are within blocks assigned by RIPE and with the correct civic location in the RIPE database. IP2location: returned a location in the wrong country! [Actually, returned an offshore location approximately 100m from low water mark and 300m from high water mark, but still the wrong country.] MaxMind got the right conurbation for my office, though I suspect it went for some kind of geographic centre for that conurbation, since it's out by several kilometres. For my home it was wrong by about 120km. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 05:43:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdNjl-0002YH-Fy; Mon, 16 Apr 2007 05:43:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdNjk-0002Vx-3o for ecrit@ietf.org; Mon, 16 Apr 2007 05:43:04 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdNjX-0007tc-5b for ecrit@ietf.org; Mon, 16 Apr 2007 05:43:04 -0400 Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id l3G9flIO022288; Mon, 16 Apr 2007 11:41:47 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id l3G9flgk003686; Mon, 16 Apr 2007 11:41:47 +0200 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 11:41:47 +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 Subject: AW: [Ecrit] Hiding (partial) locations Date: Mon, 16 Apr 2007 11:41:46 +0200 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E701A289BC@MCHP7R6A.ww002.siemens.net> In-Reply-To: <20070416092329.GE49101@finch-staff-1.thus.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Hiding (partial) locations Thread-Index: AceACYKw7M5CXe0BQP+DMS/7IPC6UQAAcW6Q From: "Tschofenig, Hannes" To: "Clive D.W. Feather" , "Henning Schulzrinne" X-OriginalArrivalTime: 16 Apr 2007 09:41:47.0187 (UTC) FILETIME=[735DC830:01C7800B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Clive,=20 Are you saying that you think that the idea of providing enough = information for routing by the ISP is good or do you think that the ISP = will not even want to provide this information?=20 Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: Clive D.W. Feather [mailto:clive@demon.net]=20 > Gesendet: Montag, 16. April 2007 11:23 > An: Henning Schulzrinne > Cc: ECRIT > Betreff: Re: [Ecrit] Hiding (partial) locations >=20 > Henning Schulzrinne said: > > This level of location information =20 > > is also more or less what you can get for free already from=20 > services =20 > > such as http://www.ip2location.com/free.asp or MaxMind. >=20 > I hope not. >=20 > I tried both of these with my home system and my office=20 > system. Both are > within blocks assigned by RIPE and with the correct civic=20 > location in the > RIPE database. >=20 > IP2location: returned a location in the wrong country!=20 > [Actually, returned > an offshore location approximately 100m from low water mark=20 > and 300m from > high water mark, but still the wrong country.] >=20 > MaxMind got the right conurbation for my office, though I=20 > suspect it went > for some kind of geographic centre for that conurbation,=20 > since it's out by > several kilometres. For my home it was wrong by about 120km. >=20 > --=20 > Clive D.W. Feather | Work: | Tel: =20 > +44 20 8495 6138 > Internet Expert | Home: | Fax: =20 > +44 870 051 9937 > Demon Internet | WWW: http://www.davros.org | Mobile:=20 > +44 7973 377646 > THUS plc | | >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 08:19:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdQAj-0004Ga-IQ; Mon, 16 Apr 2007 08:19:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdQAi-0004GV-VF for ecrit@ietf.org; Mon, 16 Apr 2007 08:19:04 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdQAh-0007eO-Kz for ecrit@ietf.org; Mon, 16 Apr 2007 08:19:04 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 16 Apr 2007 05:19:02 -0700 X-IronPort-AV: i="4.14,415,1170662400"; d="scan'208"; a="411828188:sNHT47885734" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l3GCJ29Y008293; Mon, 16 Apr 2007 05:19:02 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l3GCIpx1015898; Mon, 16 Apr 2007 12:19:02 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 08:19:01 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 08:19:00 -0400 From: "Marc Linsner" To: "'Winterbottom, James'" Subject: RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Date: Mon, 16 Apr 2007 08:19:00 -0400 Message-ID: <002c01c78021$6a36c980$2d0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Acd9eBCfZxIYRVO7QJu63bsxYVEIfwAd6vQwAAPV6GAAQ9X98AABrTpgACBby4AABWu0sAAc+hVw X-OriginalArrivalTime: 16 Apr 2007 12:19:00.0956 (UTC) FILETIME=[6A54B1C0:01C78021] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1846; t=1176725942; x=1177589942; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20=20RE=3A=20[Ecrit]=20Not-so-grand=20compromise=20on=20how=20t o=20doendpointcentric=20LCPwithout=20giving=20away=20the=20store |Sender:=20; bh=/arwsAH5NiENf4NEzHjft0UNE4LjYMOY/RcK6ZMfwaY=; b=RMtrESV2qxJ2CN6FMuVneZ/7k8J+aoksOAJRCOa6mcK38EkgIRdC0NlyDRuRRsmE7rvmFwdX yknMAnyiaBbkpA4atYwMCW4Oe4yg3fm2Ee2tTRhWWNtIPkLAdrwwR00f; Authentication-Results: sj-dkim-8; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org James, > > > > > > I am not so sure that this anymore the case than it would > be with a > > > location value is it? > > > > No, if the client has LbyV, the client can do the LoST > lookup at call > > time. > > > [AJW] This presupposes that the location has not changed. If > the location has changed then this doesn't help unless the > client also requests a new location at call time. In this > case I put to you that there is no difference in the number > of queries performed. I think we understand mobile clients. Wrt: Fixed clients: The long-standing requirement that a host perform a LoST query at emergency call time gets uglier when that client has to go back to the access provider, who performs the query for the client. Too many messages/round trips. Giving the fixed client a rough location is better. > > > > You are suggesting the host go back to the access network > when setting > up > > an > > emergency call? > > [AJW] Local network hit is likely to be faster than a > wide-area network hit. No hit to the local network is faster. > > > > > I wonder if a course location (enough to route properly) with LbyR > > embedded in the LbyV would be better. > > > > [AJW] Hmmm, maybe. I would need to think about this one a bit > more as I > am not sure that we can easily arrive at a solution to how > coarse is too > coarse, or too fine. If the access provider performs a LoST query with the *real* location, they will know which elements of the location object to pass to the client. > > > > I worry about too many dependencies at call time. > > [AJW] Agreed, but we need to allow people to deploy it also. Like most > things some ground in the middle will need to be found. As long as the middle ground is deployable and works. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 08:22:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdQEF-0005Bw-4R; Mon, 16 Apr 2007 08:22:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdQEE-00059d-BW for ecrit@ietf.org; Mon, 16 Apr 2007 08:22:42 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdQEE-0007vc-3B for ecrit@ietf.org; Mon, 16 Apr 2007 08:22:42 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3GCMWeL014187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Apr 2007 08:22:33 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <711762FF-CB1D-406A-9079-5973736EEE46@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Date: Mon, 16 Apr 2007 08:22:27 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think there's a distinct danger of talking past each other after the third level of >>>, so maybe it's time to review and see where we diverge. Assumption: Devices are mobile. Requirement: Devices need to obtain PSAP URLs well ahead of a call, as part of normal configuration, even if there will be a LoST re- query at call time. (With the non-hiding model, this isn't really necessary as the mobile will have requeried if it has left the PSAP coverage area, so that it will always have correct and up-to-date PSAP information. Re-querying at call time only addresses the highly unlikely scenario that the LoST information itself has changed before the cache expiration time. This distinction seems to have gotten lost in the discussion.) Model: #1 (location) Devices only obtain a (constant) location reference and "trade" this with a LoST server for a PSAP URL. #2 (URL) Devices query for a PSAP URL. In both #1 and #2, the mobile device has no idea when it leaves the coverage area of the PSAP, so either the configuration mechanism has to push a new PSAP URL to the mobile or the mobile has to re-query at high frequency, as it has no idea when it has left one PSAP coverage area and entered another. Thus, this dramatically increases the load on the LoST server (and the power consumption in the mobile). Henning On Apr 15, 2007, at 11:30 PM, Winterbottom, James wrote: > So that being the case, what is the objection? > > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Monday, 16 April 2007 1:29 PM >> To: Winterbottom, James >> Cc: Marc Linsner; ecrit@ietf.org >> Subject: Re: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to >> doendpointcentric LCPwithout giving away the store >> >> No, my note refers to the ability to cache data ahead of the call, as >> discussed as a requirement. The number of call-associated queries is >> much, much smaller than the pre-call queries, particularly if caching >> is "dumbed down" as you seem to suggest. >> >> Henning >> >> On Apr 15, 2007, at 11:23 PM, Winterbottom, James wrote: >> >>> Please, this is not my business plan and never has been. I am only >>> trying to help move things forward. I must admit though that I don't >>> understand how this is any different to providing a location by >>> value in >>> the same circumstance. >>> >>> Your argument seems to be, you are moving super fast so the data > that >>> you have is not right to make a call, go and get new data at call >>> time. >>> It is not clear to me that there is a real difference between: >>> >>> a) End-point going to the LIS getting updated data then end-point >>> doing >>> LoST lookup and routing call and >>> >>> b) End-point asking LIS for location, LIS doing LoST lookup and >>> returning PSAP URI to the end-point. >>> >>> If the end-point is static, then both mechanisms are roughly >>> equivalent >>> also. >>> >>> I have no reason to hide location from the end-point, but the >>> reality is >>> that some people want to do this. The number of lookup dips is the >>> same >>> in both circumstances as best as I can tell. >>> >>> Cheers >>> James >> > > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2] > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 08:37:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdQSR-0002WH-4w; Mon, 16 Apr 2007 08:37:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdQSP-0002W8-LG for ecrit@ietf.org; Mon, 16 Apr 2007 08:37:21 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdQSP-0002c2-9J for ecrit@ietf.org; Mon, 16 Apr 2007 08:37:21 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 16 Apr 2007 08:37:17 -0400 X-IronPort-AV: i="4.14,415,1170651600"; d="scan'208"; a="118616306:sNHT48945308" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3GCbHuW021801; Mon, 16 Apr 2007 08:37:17 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3GCb3lQ018025; Mon, 16 Apr 2007 12:37:17 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 08:37:15 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 08:37:14 -0400 From: "Marc Linsner" To: "'Henning Schulzrinne'" , "'ECRIT'" Subject: RE: [Ecrit] Hiding (partial) locations Date: Mon, 16 Apr 2007 08:37:13 -0400 Message-ID: <003001c78023$f6230790$2d0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <75BE6CD6-A8A2-416F-9BC4-627341225C1B@cs.columbia.edu> Thread-Index: Acd/xyRxc9mKTG94Sy+AhoOlEy4bZQAWk0DA X-OriginalArrivalTime: 16 Apr 2007 12:37:14.0620 (UTC) FILETIME=[F63493C0:01C78023] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2581; t=1176727037; x=1177591037; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20Hiding=20(partial)=20locations |Sender:=20 |To:=20=22'Henning=20Schulzrinne'=22=20, =20=22'ECRIT '=22=20; bh=jWbeE6XRuyaxJqALlCchfnaMXeqUAb4I5qlCbMhuw3k=; b=R6jD0j+994N07rk8plSj1VJ/E6traOazh/QjIgK8hSWNPmeZrQ/qknG6PHB6XSNYMv3WV/5o OyJXpGI/PK+X6zRw1fJKSv6cluAaTQVpFc1T8iCTnhymv01icwaZw+3h; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning, The partial location would need to be accurate enough such that tandem LoST queries don't have to dereference real-time. The only deference should happen at the PSAP for dispatch. If the ESInet deploys a state level proxy which performs a second LoST query to find the county level PSAP, enough data in the LbyV should be there to do so. This is doable today, protocol-wise. The only work may be an additional tag in the LO for the LbyR (if isn't the choice). This also supports the location 'integrity' desires. Prior to expending high-cost resources with a dispatch, the PSAP knows the location provider via the TLS setup during dereference to find the precise location of the caller. -Marc- > > The ISP returns partial location information that is > sufficiently accurate to return the correct PSAP. This would > typically be the county or city. This reveals (almost) no > additional information to the client beyond the PSAP URL. > After all, the PSAP boundaries are public or easily > guessable, so it would be easy for an external entity to > construct a mapping that maps PSAP URLs back to rough > locations, thus defeating the efforts by the ISP to hide the > location information from their customers. This level of > location information is also more or less what you can get > for free already from services such as > http://www.ip2location.com/free.asp or MaxMind. > > There are two mechanisms for doing that: > > (1) combined LbyV and LbyR: rough information by value, > precise information by (protected) reference; > > (2) just LbyR, but the reference is roughly resolvable by > possession, precise resolution requires a shared secret (held > by the PSAP). > > This approach has three advantages: > > (1) If all else fails (such as attempts to resolve the > reference), the PSAP at least has some location information > to work with, rather than a completely useless reference. > This is particularly important if the call arrives at an > overflow or backup PSAP, since it will assume that the call > is from its service area and it may not be able to resolve > the reference due to lack of an established trust relationship. > > (2) The client can verify the information, reducing errors. > > (3) Nothing changes in terms of processing compared to > providing full location information. > > Henning > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 08:46:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdQaq-0004VQ-6Y; Mon, 16 Apr 2007 08:46:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdQao-0004VL-R2 for ecrit@ietf.org; Mon, 16 Apr 2007 08:46:02 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdQao-0005Jd-GU for ecrit@ietf.org; Mon, 16 Apr 2007 08:46:02 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3GCk0k7008617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Apr 2007 08:46:01 -0400 (EDT) In-Reply-To: <003001c78023$f6230790$2d0d0d0a@amer.cisco.com> References: <003001c78023$f6230790$2d0d0d0a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Hiding (partial) locations Date: Mon, 16 Apr 2007 08:45:55 -0400 To: "Marc Linsner" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Marc, I generally agree; I was indeed assuming PSAP-level accuracy, i.e., in the US, a community or county. At least in the US, for wireline, the PSAP boundaries often correspond to rate center boundaries, so all lines on a DSLAM will have the same PSAP. (I will note that in the US, the same location information is also roughly available from the phone book, since the three digits after the area code often correspond to the community or rate center. For example, my phone number is 201 592 xxxx, and all 592's are in Leonia, NJ. As far as I know, the phone company hasn't tried to hide my phone number from me, although they'll force me to pay if I want to hide it from others...) Henning On Apr 16, 2007, at 8:37 AM, Marc Linsner wrote: > Henning, > > The partial location would need to be accurate enough such that > tandem LoST > queries don't have to dereference real-time. The only deference > should > happen at the PSAP for dispatch. If the ESInet deploys a state > level proxy > which performs a second LoST query to find the county level PSAP, > enough > data in the LbyV should be there to do so. > > This is doable today, protocol-wise. The only work may be an > additional tag > in the LO for the LbyR (if isn't the choice). > > This also supports the location 'integrity' desires. Prior to > expending > high-cost resources with a dispatch, the PSAP knows the location > provider > via the TLS setup during dereference to find the precise location > of the > caller. > > -Marc- > > > >> >> The ISP returns partial location information that is >> sufficiently accurate to return the correct PSAP. This would >> typically be the county or city. This reveals (almost) no >> additional information to the client beyond the PSAP URL. >> After all, the PSAP boundaries are public or easily >> guessable, so it would be easy for an external entity to >> construct a mapping that maps PSAP URLs back to rough >> locations, thus defeating the efforts by the ISP to hide the >> location information from their customers. This level of >> location information is also more or less what you can get >> for free already from services such as >> http://www.ip2location.com/free.asp or MaxMind. >> >> There are two mechanisms for doing that: >> >> (1) combined LbyV and LbyR: rough information by value, >> precise information by (protected) reference; >> >> (2) just LbyR, but the reference is roughly resolvable by >> possession, precise resolution requires a shared secret (held >> by the PSAP). >> >> This approach has three advantages: >> >> (1) If all else fails (such as attempts to resolve the >> reference), the PSAP at least has some location information >> to work with, rather than a completely useless reference. >> This is particularly important if the call arrives at an >> overflow or backup PSAP, since it will assume that the call >> is from its service area and it may not be able to resolve >> the reference due to lack of an established trust relationship. >> >> (2) The client can verify the information, reducing errors. >> >> (3) Nothing changes in terms of processing compared to >> providing full location information. >> >> Henning >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 09:41:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdRSr-0007QQ-NP; Mon, 16 Apr 2007 09:41:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdRSq-0007Pe-Eg; Mon, 16 Apr 2007 09:41:52 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdRSp-0007YQ-4t; Mon, 16 Apr 2007 09:41:52 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HdRSC-0006Au-0z; Mon, 16 Apr 2007 08:41:12 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "Rosen, Brian" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCP without giving away the store Date: Mon, 16 Apr 2007 09:41:46 -0400 Message-ID: <07f401c7802c$fc202570$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd+rkT6cMsL92fRQRmFRvi4b5UHqABeCxPA In-Reply-To: <4620FAF8.2020201@gmx.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Back from a weekend of no Internet access and lots of email to process: The country code is returned from the L7 LCP query when an LbyR is returned. The validation is done by the VSP when an emergency call is placed. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Saturday, April 14, 2007 12:02 PM > To: Rosen, Brian > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do > endpoint centric LCP without giving away the store > > Hi Brian, > > ~snip~ > > Perhaps we include in the LoST return a country code for a query with a > > geo. We add a new operation to LoST that takes a service, a country > > code and a PSAP URI and returns yes/no validation ("Yes, that URI is a > > valid URI for that service in that country"). > > > > Please describe when the country code is returned and to whom. > Who triggers the validation step? > > Ciao > Hannes > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 09:52:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdRcq-0003Cc-FB; Mon, 16 Apr 2007 09:52:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdRcp-0003CX-0A for ecrit@ietf.org; Mon, 16 Apr 2007 09:52:11 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdRcn-00015O-Bl for ecrit@ietf.org; Mon, 16 Apr 2007 09:52:10 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HdRcA-0000Xw-6N; Mon, 16 Apr 2007 08:51:30 -0500 From: "Brian Rosen" To: "'Raymond Forbes \(CV/ETL\)'" , "'Hannes Tschofenig'" , "Rosen, Brian" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpoint centric LCP without giving away the store Date: Mon, 16 Apr 2007 09:52:05 -0400 Message-ID: <07f501c7802e$6cb06920$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd9363GJ+vjNF8iQ5+wyWbUAZ4LVAAA1AfQADQoz6AAXLVwUA== In-Reply-To: <0074F19FF6F8534E8F74C56BB84397BBD3583B@esealmw118.eemea.ericsson.se> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: e9d8c60d9288f2c774f26bab15869505 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Thank you for this reminder. I don't think we have a real problem. The call is going to be routed based on the country of the location you have when you place the call. That is going to match the country code that we are using for the validation. The PSAP that gets the call may transfer it when the actual fine grained location is determined, but that is after the call is routed. This is all about routing. The entity returning the LbyR, the country code and the PSAP URI is the access network. It can keep the information consistent. Even if the location were to change between the time the endpoint got the data from its access network, and the time the VSP validated, the VSP isn't getting updated location. It's just validating that the PSAP URI it's routing for is valid within the country that it's routing to. If a bad guy could seed bad information in the worldwide LoST database, then he could put his URI in there, and get calls. I think we have to accept this kind of problem. We don't actually need the country code, and in fact perhaps we should consider it a hint. If there is a URI in the database that matches the proffered URI, it's valid. The country code just gives us a hint of where to look. We might want to recommend that the URIs belong to the country where the URI is routed towards (eg psap.london.uk). However, it works with any URI. Brian > -----Original Message----- > From: Raymond Forbes (CV/ETL) [mailto:raymond.forbes@ericsson.com] > Sent: Saturday, April 14, 2007 1:14 PM > To: Brian Rosen; Hannes Tschofenig; Rosen, Brian > Cc: ecrit@ietf.org > Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > doendpoint centric LCP without giving away the store > > > In many areas, especially Mobile Networks Country codes are not > reliable. > > Geneva is a good case. Most calls originated by Non-Swiss mobiles in > Geneva are actually made on the French networks and so will get the > Country Code +33 of the base station on the surrounding Mountains, the > French authorities have no jurisdiction to enter Switzerland even in the > case of Emergencies. > > True because of Cross-boarder agreement on this friendly boarder region > the French PSAPs will forward the calls to Switz PSAPs. > > I am sure that what Brian says may be reasonable from fixed access, but > not from Radio Access, radio has no respect for artificial political > boundaries. > > Regards, > > Ray Forbes > > BU Networks (CV/ETL/BBC/D) > Telephone: +44 (0) 24 7656 3106 > Mobile: +44 (0) 771 851 1361 > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: 13 April 2007 17:04 > To: 'Hannes Tschofenig'; Rosen, Brian > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > doendpoint centric LCP without giving away the store > > Huh, I didn't get that. > > I'd like to eliminate the country code thing, because otherwise we need > a way to carry it in the SIP Geolocation. However, I don't really want > the VSP having to ask the ASP/ISP for a dereference of any sort, and I'd > like to minimize the work of the ASP/ISP. The notion that the ASP/ISP > has to help the VSP determine if what it has is a valid PSAP URI strikes > me as a problem. > > Now, you may remember WAAAY WAAY back, I strongly suggested that the geo > form of location always include a country code. I suggested this for > disputed areas. The access network is in a very good position to tell > you how best to interpret which country actually is the on-the-ground > administrator of the location. If you are connected to an Israeli > access network, and you ask LoST for a PSAP URI, you probably want an > Israeli fire brigade. If you are on a Palestinian access network, then > you probably want a different answer. So, having country code in a PIDF > with an otherwise geo location is actually helpful. > > The current answer for this is some kind of manual configuration of the > LoST servers so you get the answer you want. While that can work, I > think something more automatic might work better, and it fixes the > problem. > > Brian > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Friday, April 13, 2007 11:26 AM > > To: Rosen, Brian > > Cc: geopriv@ietf.org; ecrit@ietf.org > > Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do > > endpoint centric LCP without giving away the store > > > > Hi Brian, > > > > I only described a different way of doing the verification without > > returning a country code. > > I also focus on LbyR only rather than LbyV. > > > > Ciao > > Hannes > > > > Rosen, Brian wrote: > > > Hannes > > > > > > I am confused by your message. > > > > > > The problem you describe, where a VSP is trying to validate that the > > > > Request URI in what is claimed to be an emergency call is a bona > > > fide PSAP URI seems to be a valid concern. My message described one > > > > way to do this validation when what the VSP received (in a SIP > > > Geolocation > > > header) is an LbyR. > > > > > > Are you now wondering how you validate when you have an LbyV? I > > > would think you do the same thing: send the country code (or the > > > whole > > > location) and the PSAP URI to LoST and ask if the PSAP URI is valid. > > > This does not require any query by the VSP to the ASP/ISP. The VSP > > > should be able to query its local LoST server and be referred to the > > > > authoritative server for the location it proffers. > > > > > > I'd rather not have to have the VSP try to dereference an LbyR, and > > > if you have an LbyV then you don't even know, necessarily, who the > > > ASP/ISP is. > > > > > > Is there something else I'm missing here? > > > > > > Brian > > > > > >> -----Original Message----- > > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > >> Sent: Friday, April 13, 2007 10:43 AM > > >> To: Rosen, Brian > > >> Cc: geopriv@ietf.org; ecrit@ietf.org > > >> Subject: Re: [Ecrit] Not-so-grand compromise on how to do endpoint > > >> > > > centric > > > > > >> LCP without giving away the store > > >> > > >> Hi Brian, > > >> > > >> thanks for posting this message. > > >> > > >> When the end host is provided with LbyV and triggers the LoST > > >> lookup > > >> > > > and > > > > > >> routes the call via its VSP then the VSP (in some circumstances*) > > >> > > > might > > > > > >> want to verify that the PSAP URI in the message indeed corresponds > > >> to > > >> > > > a > > > > > >> PSAP. The idea that was mentioned a long time ago already was to > > >> let > > >> > > > the > > > > > >> VSP to use the location information for LoST and to compare the > > >> result with the content of the message. > > >> > > >> The main goal here is that the VSP does not need to have a > "business" > > >> contract to the ASP/ISP. > > >> > > >> Since there is only a location reference that neither the end host > > >> nor the VSP can dereference it is necessary to enhance the existing > > > >> procedures a bit (as Brian mentioned). > > >> > > >> I see two ways todo so: > > >> > > >> a) Enhance LoST > > >> b) Enhance the dereferencing protocol > > >> > > >> In both cases you want to have the LbyR as input and the PSAP URI > > >> (and potentially the service number) as output. > > >> > > >> For (a) you would have to address the LoST query to the LoST server > > > >> in the ASP/ISP network and the result would be a nomal LoST > response. > > >> For (b) you would have todo a dereferencing step with an additional > > > >> parameter for "verify only". The response would be similar to the > > >> > > > lookup > > > > > >> by the end host -- just the identity that is being used for the > > >> lookup would be different. > > >> > > >> Both approaches are possible and since the VSP has to support both > > >> protocols it does not make a big difference which one to use. > > >> > > >> In both cases you would have to compare the result of the lookup > > >> with the content of the message. > > >> > > >> Ciao > > >> Hannes > > >> > > >> *: It is only necessary when the VSP charges for individual calls > > >> or > > >> > > > for > > > > > >> specific calls (with the given call falling into this category). > > >> > > >> Rosen, Brian wrote: > > >> > > >>> In the Emergency Services SDO Coordination workshop, a familiar > > >>> discussion took place: how does location get provided for > > >>> emergency calls? The real issue is revenue. Access networks have > location. > > >>> > > > They > > > > > >>> may be willing to (or may be regulated to be required to) provide > > >>> location for emergency calls. However, they are not willing to > > >>> give > > >>> > > > it > > > > > >>> away for free for other uses. The issue with that is how we > > >>> support calling networks that don't have relationships with access > > > >>> networks, i.e. the Skype situation. How is location provided such > > > >>> that a > > >>> > > > Skype > > > > > >>> emergency call can be placed, but the access network can restrict > > >>> > > > what > > > > > >>> else may be done with the location it provides? > > >>> > > >>> We have been wrapped around the axle on this for, dare I say, > years. > > >>> > > >>> So, I think Barbara Stark first described this, and it needs some > > >>> > > > work, > > > > > >>> but suppose that, as an option, an access network could supply: > > >>> > > >>> 1. A reference to location > > >>> > > >>> 2. The results of a LoST query on the location value (viz, PSAP > > >>> URI > > >>> > > > and > > > > > >>> local dialstring) > > >>> > > >>> With this, an endpoint could recognize an emergency call and start > > > >>> routing it to the right PSAP. The LIS would agree to dereference > > >>> > > > for > > > > > >>> PSAPs, but could restrict other uses of location. > > >>> > > >>> Hannes points out that we need one more thing: the calling network > > >>> > > > has > > > > > >>> to be able to validate that the PSAP URI really is a PSAP URI so > > >>> > > > that > > > > > >>> charging (emergency calls generally are free) is protected. We > > >>> need > > >>> > > > a > > > > > >>> mechanism for them to do that. > > >>> > > >>> Perhaps we include in the LoST return a country code for a query > > >>> > > > with a > > > > > >>> geo. We add a new operation to LoST that takes a service, a > > >>> country code and a PSAP URI and returns yes/no validation ("Yes, > > >>> that URI is > > >>> > > > a > > > > > >>> valid URI for that service in that country"). > > >>> > > >>> What would we need to do to make this happen? > > >>> > > >>> We need extensions to LCPs or some new protocol that returns an > > >>> LbyR > > >>> > > > and > > > > > >>> the LoST results. I wonder if this is just more HELD work. > > >>> > > >>> We need the PSAP URI validation. > > >>> > > >>> Again, this is optional. The access network may well give up an > > >>> > > > LbyV. > > > > > >>> It may give up an LbyR that it will dereference for the endpoint. > > >>> > > > The > > > > > >>> access network may have a relationship with the calling network > > >>> such that the endpoint need not be involved. > > >>> > > >>> The PSAP URI validation is actually useful without this idea, > > >>> > > > especially > > > > > >>> when location is an LbyR. Instead of having to have the calling > > >>> > > > network > > > > > >>> dereference, and then do a LoST query to validate, it can just do > > >>> > > > this > > > > > >>> PSAP URI validation. > > >>> > > >>> Would this solve our problem? Would access carriers concerned > > >>> about revenue issues with "giving away" location to it's > > >>> subscribers be willing to provide LbyR dereferenceable by PSAPs > > >>> (again remembering > > >>> > > > that > > > > > >>> the access network are local to the PSAPs) as well as LoST query > > >>> services to their endpoints? Would this address the concerns > > >>> raised > > >>> > > > by > > > > > >>> Deutsche Telecom on this issue? > > >>> > > >>> Let me be very clear that I think this is an ugly solution. I > > >>> think that everyone will be much better off if endpoints knew > > >>> where they > > >>> > > > were, > > > > > >>> and apps could take advantage of that. I think we'll get there. > > >>> I think tying location configuration with the LoST query is a bad > > >>> > > > idea. I > > > > > >>> think using LbyR for emergency calls is a bad idea. > > >>> > > >>> But I can live with it. > > >>> > > >>> Brian > > >>> > > >>> _______________________________________________ > > >>> Ecrit mailing list > > >>> Ecrit@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/ecrit > > >>> > > >>> > > > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 09:54:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdRfA-00044F-Do; Mon, 16 Apr 2007 09:54:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdRf9-000447-2n; Mon, 16 Apr 2007 09:54:35 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdRf6-0001dj-NL; Mon, 16 Apr 2007 09:54:35 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HdReT-0000fs-Oy; Mon, 16 Apr 2007 08:53:54 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "Rosen, Brian" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCP without giving away the store Date: Mon, 16 Apr 2007 09:54:28 -0400 Message-ID: <07f601c7802e$c23d80d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd+1MjHuik7RcADSn6DMIg5PMOZXQBUd5SQ In-Reply-To: <2675E720-4D47-4297-AFC7-9D92DAB6A615@cs.columbia.edu> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I will make sure that we have a discussion of this in -framework. I do intend to note that LbyR is more fragile for emergency calls because the dereference may not work in a disaster. The VSP who wishes to validate takes on responsibility for failure to progress a valid call that fails validation for whatever reason. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Saturday, April 14, 2007 10:58 AM > To: Rosen, Brian > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do > endpointcentric LCP without giving away the store > > The editorial out the way, I'll start by listing some requirements, > some of which have been mentioned already: > > - Hiding location should not make the PSAP behavior more costly and > complicated or less reliable; in other words, just because an access > provider choses, for business reasons, to withhold location > information from customers should not impose a burden on tax payers. > > - Hiding location information by one provider should not impose a > burden on those access providers that offer location information to > their customers. > > I think the framework document needs to clearly spell out the > reliability and security considerations of such a choice. If nothing > else, this will prove valuable to the trial lawyer that gets called > when the first person gets hurt when location information is > erroneously withheld from a PSAP. > > Henning > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 10:04:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdRoz-0006zG-Po; Mon, 16 Apr 2007 10:04:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdRoy-0006yr-Gr for ecrit@ietf.org; Mon, 16 Apr 2007 10:04:44 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdRow-00067z-99 for ecrit@ietf.org; Mon, 16 Apr 2007 10:04:44 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 16 Apr 2007 10:04:42 -0400 X-IronPort-AV: i="4.14,415,1170651600"; d="scan'208"; a="57750745:sNHT42438636" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3GE4geM005545; Mon, 16 Apr 2007 10:04:42 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3GE4iGf013490; Mon, 16 Apr 2007 14:04:44 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 10:04:40 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 10:04:40 -0400 From: "Marc Linsner" To: "'Rosen, Brian'" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCP without giving away the store Date: Mon, 16 Apr 2007 10:04:40 -0400 Message-ID: <004801c78030$2da370e0$2d0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <07f601c7802e$c23d80d0$640fa8c0@cis.neustar.com> Thread-Index: Acd+1MjHuik7RcADSn6DMIg5PMOZXQBUd5SQAAJTQiA= X-OriginalArrivalTime: 16 Apr 2007 14:04:40.0415 (UTC) FILETIME=[2CF15EF0:01C78030] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=354; t=1176732282; x=1177596282; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20Re=3A=20[Ecrit]=20Not-so-grand=20compromi se=20on=20how=20to=20doendpointcentric=20LCP=20without=20giving=20away=20t he=20store |Sender:=20 |To:=20=22'Rosen,=20Brian'=22=20; bh=K9g5rLP6Jl9nKn17K4lt+y44vZA8YZIeFBREwDX7k/Q=; b=oY53G0i622XzdtBfL+wLLkvCJ1MmIPiEiopfa5jNChDjgmdrDpTRMpjWa13QJNA3ajLlMOA5 PzGErZzlFPSJsUMzX18mshPB80aTkQkb3GJ4XXEuXCufW/4luoSOyC10; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, > > I will make sure that we have a discussion of this in > -framework. I do intend to note that LbyR is more fragile > for emergency calls because the dereference may not work in a > disaster. Actually, it is possible that the dereference may not work in 'normal' conditions. Lots of machinery with that mechanism. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 10:09:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdRtg-0000zs-F5; Mon, 16 Apr 2007 10:09:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdRtf-0000zi-8n; Mon, 16 Apr 2007 10:09:35 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdRte-0007AD-1g; Mon, 16 Apr 2007 10:09:35 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3GE8wdG006807 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Apr 2007 10:09:01 -0400 (EDT) In-Reply-To: <07f601c7802e$c23d80d0$640fa8c0@cis.neustar.com> References: <07f601c7802e$c23d80d0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <46DC6EC8-09BE-42D4-BEA3-F1642BEFB829@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCP without giving away the store Date: Mon, 16 Apr 2007 10:09:40 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: geopriv@ietf.org, "Rosen, Brian" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 16, 2007, at 9:54 AM, Brian Rosen wrote: > I will make sure that we have a discussion of this in -framework. > I do > intend to note that LbyR is more fragile for emergency calls > because the > dereference may not work in a disaster. > > The VSP who wishes to validate takes on responsibility for failure to > progress a valid call that fails validation for whatever reason. > Wouldn't that typically be the ISP doing the authorization? (I don't want to use the term validation, since we seem to use that for a different operation.) Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 10:27:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSBD-0007OJ-J9; Mon, 16 Apr 2007 10:27:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSBB-0007NF-M6; Mon, 16 Apr 2007 10:27:41 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HdSBA-0004Yl-An; Mon, 16 Apr 2007 10:27:41 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 16 Apr 2007 10:27:39 -0400 id 015880DB.462387DB.00001091 In-Reply-To: References: <8BC845943058D844ABFC73D2220D4665064BCBD0@nics-mail.sbg.nic.at> <461F978B.5090102@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5458E518-412E-4F0F-9BD4-19670E77EC27@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Mon, 16 Apr 2007 10:27:04 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: geopriv@ietf.org, "Rosen, Brian" , ecrit@ietf.org Subject: [Ecrit] Re: [Geopriv] Not-so-grand compromise on how to do endpoint centric LCPwithout giving away the store X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 14, 2007, at 1:55 PM, Henning Schulzrinne wrote: > I suspect that the desire to hide location information will > primarily afflict a few very large incumbent service providers. I > don't see why a hotel or enterprise would want to hide the location > from their visitors or employees, say, as the likelihood of > monetizing this information is zero. There is a non-technical solution to this problem. The access network could easily populate the note well section of the PIDF-LO with a copyright notice granting free use only for emergency call routing and dispatch purposes and requiring permission for all other uses. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 10:32:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSFk-0000tA-E9; Mon, 16 Apr 2007 10:32:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSFj-0000t1-2r; Mon, 16 Apr 2007 10:32:23 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdSFd-0008Me-JB; Mon, 16 Apr 2007 10:32:23 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HdSEy-0001ls-UN; Mon, 16 Apr 2007 09:31:38 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "Rosen, Brian" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise [solutions] Date: Mon, 16 Apr 2007 10:32:12 -0400 Message-ID: <080a01c78034$084b5d40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd+1MjHwk3fpxw6TTGk0HsWvJvyTABVwaJA In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Saturday, April 14, 2007 12:19 PM > To: Rosen, Brian > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise [solutions] > > I'll try to summarize some solutions and pick apart the problem. > > There seem to be two basic approaches: > > (1) Provide only location information that is sufficient for call > routing or possibly for obtaining the service number, but not for > dispatch. The latter is included by a PSAP-only LbyR. This would > remove a large part of the value of the address to pizza parlors, but > would not interfere with our standard architecture. It would provide > the user with some ability to verify his own address, albeit only > partially. (This is one of the reliability drawbacks of the withhold- > location-information approaches, which is going to be a major cause > of dispatch problems, I suspect.) > > The biggest problem is determining this minimal address information, > but this isn't too hard, given the availability of LoST service > region information. I think this is impossible for the U.S., where PSAP boundaries can be one side of the street or another. It works in many countries that don't have many PSAPs. > > (2) Provide only the PSAP URL and LbyR resolvable by the PSAP. > > Only (2) requires additional work. From what I can tell, the > following solutions have been proposed: > > (a) Include in configuration protocols, such as DHCP. > > (b) Include in location configuration protocols, such as L7 LCP. > > (c) Include in a special LoST response, e.g., if the client provides > no location information. > > All of these have problems: > > - DHCP: Since this is configuration information, adding a lot of > extra material to DHCP seems ill-advised, particularly since the > likelihood that this information actually reaches residential users > is slim. After all, this motivated the whole L7-LCP discussion. This > also has problems if the URL needs to be changed since the INFORM > request expiration doesn't seem to be tied to the IP address > expiration. The number of URLs could be substantial, given that we > need more than one emergency service URL and that we may need service > testing URLs. I think we all believe DHCP is only viable in fixed environments, but I use the extreme example of a wired phone connected to a router with a wireless access installed in an RV traveling down the highway as a counterexample. Such situations exist, therefore it has to work, but they are unusual, so it can be less than optimal. In this case, we need DHCP responses that return LbyV and country code and probably another that returns the LoST data. I fail to see that as a major deviation from what DHCP does. The expiration is a red herring. It won't change much, and you do get it again at call time. The number of URIs is an issue, and we may need to do something clever about that. However, I do suspect that the access network that does this will use the L7 LCP, and I don't think leaving DHCP out of this is a problem. > > - L7 LCP: This subverts a location determination protocol into a > general configuration protocol. No it gives you information related to location (the PSAP URI associated with this location. > > - LoST: This seems closest to our existing notion of returning a > 'default' PSAP if no other resolution is possible. Nothing prevents > an ISP-provided LoST client from using whatever information it has > available, such as client IP addresses, to make this information > better than a national call center. I think this is a poor choice because it has too many restrictions on who operates the LoST server. You would either require that the LoST server operator be permitted to dereference, or the access network itself operates the LoST server. While that may be the case, it may not be and I don't see why we should tie these together. > > If we go down this route, I think a better solution is to use the on- > going work for SIP configuration mechanisms. One of the sources of > configuration information is the local access network, so it has all > the right properties. After all, emergency calling URLs are not > fundamentally different from other configuration information for > special servers. Plus, the configuration protocol will likely have > mechanism of dealing with conflicting information. The more protocols > you add, the higher the likelihood that a device will get conflicting > information, with no deterministic way to resolve it. Where did you make the leap that the Vonage configuration server knows anything about the Comcast access network? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 10:37:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSL2-0002vz-Kl; Mon, 16 Apr 2007 10:37:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSL1-0002vt-Vi for ecrit@ietf.org; Mon, 16 Apr 2007 10:37:51 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdSKz-00036p-GM for ecrit@ietf.org; Mon, 16 Apr 2007 10:37:51 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HdSKM-00024w-Ix; Mon, 16 Apr 2007 09:37:10 -0500 From: "Brian Rosen" To: "'Marc Linsner'" Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCPwithout giving away the store Date: Mon, 16 Apr 2007 10:37:46 -0400 Message-ID: <080b01c78034$ce4806b0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd9eBCfZxIYRVO7QJu63bsxYVEIfwAd6vQwAAPV6GAAQ9X98ABHfjIw In-Reply-To: <005b01c77f0e$abe6d550$42aa520a@amer.cisco.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Maybe this has already been answered, but: You update the data at call time. You only use stale data if that doesn't work. Brian > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Saturday, April 14, 2007 11:32 PM > To: 'Brian Rosen' > Cc: ecrit@ietf.org > Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do > endpointcentric LCPwithout giving away the store > > Brian, > > You also realize that an emergency call is going to be routed using > 'stale' > data. We've always stated that routing at call time is optimal. You are > prepared to give that up? > > -Marc- > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, April 13, 2007 3:11 PM > > To: 'Marc Linsner'; Rosen, Brian; geopriv@ietf.org > > Cc: ecrit@ietf.org > > Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on > > how to do endpointcentric LCPwithout giving away the store > > > > I think that is part of the tradeoff an access network makes. > > If its restricting access to location, and location is > > needed to route, then it has to assume the liability for > > misroute, since it's providing the route in lieu of providing > > location for the VSP to route. > > > > If it doesn't want to assume that liability, then it has to > > give location to someone who does the route, and we're back > > around that axle again. > > > > So, I think it's reasonable that the access network deal with > > misroutes in this case. > > > > Brian > > > > > -----Original Message----- > > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > > Sent: Friday, April 13, 2007 1:23 PM > > > To: 'Rosen, Brian'; geopriv@ietf.org > > > Cc: ecrit@ietf.org > > > Subject: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do > > > endpointcentric LCPwithout giving away the store > > > > > > Who is responsible for PSAP mis-routes? I would think this > > transfers > > > liability for routing to the access-provider, are they > > willing to step > > > up to that? > > > > > > -Marc- > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > > > > Sent: Friday, April 13, 2007 7:18 AM > > > > To: geopriv@ietf.org > > > > Cc: ecrit@ietf.org > > > > Subject: [Ecrit] Not-so-grand compromise on how to do endpoint > > > > centric LCPwithout giving away the store > > > > > > > > In the Emergency Services SDO Coordination workshop, a familiar > > > > discussion took place: how does location get provided for > > emergency > > > > calls? The real issue is revenue. > > > > Access networks have location. They may be willing to (or may be > > > > regulated to be required to) provide location for > > emergency calls. > > > > However, they are not willing to give it away for free for other > > > > uses. The issue with that is how we support calling > > networks that > > > > don't have relationships with access networks, i.e. the Skype > > > > situation. How is location provided such that a Skype emergency > > > > call can be placed, but the access network can restrict what else > > > > may be done with the location it provides? > > > > > > > > We have been wrapped around the axle on this for, dare I > > say, years. > > > > > > > > So, I think Barbara Stark first described this, and it needs some > > > > work, but suppose that, as an option, an access network could > > > > supply: > > > > > > > > 1. A reference to location > > > > > > > > 2. The results of a LoST query on the location value > > (viz, PSAP URI > > > > and local dialstring) > > > > > > > > With this, an endpoint could recognize an emergency call > > and start > > > > routing it to the right PSAP. The LIS would agree to dereference > > > > for PSAPs, but could restrict other uses of location. > > > > > > > > Hannes points out that we need one more thing: the > > calling network > > > > has to be able to validate that the PSAP URI really is a > > PSAP URI so > > > > that charging (emergency calls generally are > > > > free) is protected. We need a mechanism for them to do that. > > > > > > > > Perhaps we include in the LoST return a country code for a query > > > > with a geo. We add a new operation to LoST that takes a > > service, a > > > > country code and a PSAP URI and returns yes/no validation ("Yes, > > > > that URI is a valid URI for that service in that country"). > > > > > > > > What would we need to do to make this happen? > > > > > > > > We need extensions to LCPs or some new protocol that > > returns an LbyR > > > > and the LoST results. I wonder if this is just more HELD work. > > > > > > > > We need the PSAP URI validation. > > > > > > > > Again, this is optional. The access network may well > > give up an LbyV. > > > > It may give up an LbyR that it will dereference for the > > endpoint. > > > > The access network may have a relationship with the > > calling network > > > > such that the endpoint need not be involved. > > > > > > > > The PSAP URI validation is actually useful without this idea, > > > > especially when location is an LbyR. Instead of having > > to have the > > > > calling network dereference, and then do a LoST query to > > validate, > > > > it can just do this PSAP URI validation. > > > > > > > > Would this solve our problem? Would access carriers > > concerned about > > > > revenue issues with "giving away" location to it's subscribers be > > > > willing to provide LbyR dereferenceable by PSAPs (again > > remembering > > > > that the access network are local to the PSAPs) as well as LoST > > > > query services to their endpoints? Would this address > > the concerns > > > > raised by Deutsche Telecom on this issue? > > > > > > > > Let me be very clear that I think this is an ugly solution. > > > > I think that everyone will be much better off if endpoints knew > > > > where they were, and apps could take advantage of that. > > > > I think we'll get there. I think tying location > > configuration with > > > > the LoST query is a bad idea. I think using LbyR for emergency > > > > calls is a bad idea. > > > > > > > > But I can live with it. > > > > > > > > Brian > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 10:42:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSPE-0005Ld-Gj; Mon, 16 Apr 2007 10:42:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSPD-0005LY-8R for ecrit@ietf.org; Mon, 16 Apr 2007 10:42:11 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdSPB-0004Rd-0u for ecrit@ietf.org; Mon, 16 Apr 2007 10:42:11 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 16 Apr 2007 10:42:10 -0400 X-IronPort-AV: i="4.14,415,1170651600"; d="scan'208"; a="57755208:sNHT41649756" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3GEg8dI016452; Mon, 16 Apr 2007 10:42:08 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3GEg1Gd024993; Mon, 16 Apr 2007 14:42:01 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 10:41:58 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 10:41:57 -0400 From: "Marc Linsner" To: "'Brian Rosen'" Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCPwithout giving away the store Date: Mon, 16 Apr 2007 10:41:58 -0400 Message-ID: <004f01c78035$638a0480$2d0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <080b01c78034$ce4806b0$640fa8c0@cis.neustar.com> Thread-Index: Acd9eBCfZxIYRVO7QJu63bsxYVEIfwAd6vQwAAPV6GAAQ9X98ABHfjIwAAIvQEA= X-OriginalArrivalTime: 16 Apr 2007 14:41:57.0390 (UTC) FILETIME=[6248AAE0:01C78035] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=197; t=1176734528; x=1177598528; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20RE=3A=20[Ecrit]=20Not-so-grand=20compromi se=20on=20how=20to=20do=20endpointcentric=20LCPwithout=20giving=20away=20t he=20store |Sender:=20 |To:=20=22'Brian=20Rosen'=22=20; bh=UXPkfXw+f3CllMHoLarWTx+H9IVeC4IYxH/O8o6GVBw=; b=as8TzzrYH09nj6IfiidcNZd1SSbEgdVZvzu0o7LhD1N4S3UoY9Elb9w1G4h7Vqaftg2ZILu0 gvRXVgjohHqMGM3hpXfTLU3MpvD6gipYbgOgi1fdN4b+E+9a6DhJb57e; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, > > You update the data at call time. You only use stale data if > that doesn't work. Remind us of the goal for 'send button to ringback' timing, please? 2 seconds? -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 10:54:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSbA-0000tp-0r; Mon, 16 Apr 2007 10:54:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSb8-0000tO-3j; Mon, 16 Apr 2007 10:54:30 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdSb5-00087X-S1; Mon, 16 Apr 2007 10:54:30 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HdSaS-0006sM-GS; Mon, 16 Apr 2007 09:53:48 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCP without giving away the store Date: Mon, 16 Apr 2007 10:54:23 -0400 Message-ID: <081901c78037$213d71a0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceAMMSv+D2eFbEqRUW0joM7oRxMjgABPx8w In-Reply-To: <46DC6EC8-09BE-42D4-BEA3-F1642BEFB829@cs.columbia.edu> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: geopriv@ietf.org, "Rosen, Brian" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org No, this was Hannes' problem. The VSP wants to make sure that the PSAP URI is valid. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, April 16, 2007 10:10 AM > To: Brian Rosen > Cc: Rosen, Brian; geopriv@ietf.org; ecrit@ietf.org > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do > endpointcentric LCP without giving away the store > > > On Apr 16, 2007, at 9:54 AM, Brian Rosen wrote: > > > I will make sure that we have a discussion of this in -framework. > > I do > > intend to note that LbyR is more fragile for emergency calls > > because the > > dereference may not work in a disaster. > > > > The VSP who wishes to validate takes on responsibility for failure to > > progress a valid call that fails validation for whatever reason. > > > > Wouldn't that typically be the ISP doing the authorization? (I don't > want to use the term validation, since we seem to use that for a > different operation.) > > Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 11:00:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSgm-0002ZX-Le; Mon, 16 Apr 2007 11:00:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSgl-0002ZN-Fc; Mon, 16 Apr 2007 11:00:19 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdSgk-0001a8-6F; Mon, 16 Apr 2007 11:00:19 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3GF07Na013138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Apr 2007 11:00:08 -0400 (EDT) In-Reply-To: <0AB57A5DEF898646A069F23604A263536F4AC1@ILEXC2U01.ndc.lucent.com> References: <886DD03D15173C43BCE98EA662A0101A01EB70D2@stntexch12.cis.neustar.com> <0AB57A5DEF898646A069F23604A263536F4AC1@ILEXC2U01.ndc.lucent.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D6F4F83-798A-4A66-ADA1-AEA767BB9F3E@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCPwithout giving away the store Date: Mon, 16 Apr 2007 11:01:20 -0400 To: "Barclay, Deborah L \(Deb\)" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: geopriv@ietf.org, "Rosen, Brian" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I thought we were talking primarily about residential wireline? I don't think anybody is proposing that a wireless device continuously query for its own location. In many cases of interest, this is unnecessary since handsets have GPS built in. (As a side note, since navigation will become standard functionality on handsets, I have a hard time imagining how per-dip systems are going to compete.) A much better solution for systems where location needs to be conveyed to the end system is to have location triggers, namely the ability of the handset to tell the network "notify me if I'm leaving this polygon". We have the necessary tools to do this, via SIP presence. Henning On Apr 13, 2007, at 12:07 PM, Barclay, Deborah L ((Deb)) wrote: > Hi Brian, > > The ecrit bcp recommends obtaining location on power-up/ > registration and > then refresh often/occasionally. > > That means endpoints may obtain location frequently but never use > it for > an emergency call. > > I thought business models often worked on a pay per dip basis. > > For cellular endpoints, network based and network assisted position > determination are very complex and resource intensive - requiring > auxiliary equipment for position determination. > > Due to the impact on network resources, I'm not sure obtaining > position > whenever requested and never being charged will be a viable model for > some technologies. > > Deb > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 11:01:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdShg-0002v5-IZ; Mon, 16 Apr 2007 11:01:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdShf-0002uw-PY; Mon, 16 Apr 2007 11:01:15 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdShf-0001xK-BO; Mon, 16 Apr 2007 11:01:15 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HdSh1-0000Oe-3d; Mon, 16 Apr 2007 10:00:35 -0500 From: "Brian Rosen" To: "'Barclay, Deborah L \(Deb\)'" , "Rosen, Brian" , Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCPwithout giving away the store Date: Mon, 16 Apr 2007 11:01:10 -0400 Message-ID: <081a01c78038$13a801d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd9eBCfZxIYRVO7QJu63bsxYVEIfwAZ38qQAJXqkWA= In-Reply-To: <0AB57A5DEF898646A069F23604A263536F4AC1@ILEXC2U01.ndc.lucent.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.5 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Okay, this is a "have your cake and eat it too" situation. If you want to restrict location, you have to take on the burden of providing the PSAP URI (the route) for an emergency call. This would change only when the user changed something like cell site. You need to make sure the endpoint has this when it changes. You can either keep the update frequency high, or force it when cell site changes (the endpoints know this). The IMS solution, because it couples the access network with the calling network can avoid this because it uses proxy adding of location. However, the general packet interfaces have to support emergency calling too, and here the L7 LCP would have to support the PSAP URI. Brian > -----Original Message----- > From: Barclay, Deborah L (Deb) [mailto:dlbarclay@alcatel-lucent.com] > Sent: Friday, April 13, 2007 12:08 PM > To: Rosen, Brian; geopriv@ietf.org > Cc: ecrit@ietf.org > Subject: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do > endpointcentric LCPwithout giving away the store > > Hi Brian, > > The ecrit bcp recommends obtaining location on power-up/registration and > then refresh often/occasionally. > > That means endpoints may obtain location frequently but never use it for > an emergency call. > > I thought business models often worked on a pay per dip basis. > > For cellular endpoints, network based and network assisted position > determination are very complex and resource intensive - requiring > auxiliary equipment for position determination. > > Due to the impact on network resources, I'm not sure obtaining position > whenever requested and never being charged will be a viable model for > some technologies. > > Deb > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Friday, April 13, 2007 6:18 AM > To: geopriv@ietf.org > Cc: ecrit@ietf.org > Subject: [Ecrit] Not-so-grand compromise on how to do endpoint centric > LCPwithout giving away the store > > In the Emergency Services SDO Coordination workshop, a familiar > discussion took place: how does location get provided for emergency > calls? The real issue is revenue. Access networks have location. They > may be willing to (or may be regulated to be required to) provide > location for emergency calls. However, they are not willing to give it > away for free for other uses. The issue with that is how we support > calling networks that don't have relationships with access networks, > i.e. the Skype situation. How is location provided such that a Skype > emergency call can be placed, but the access network can restrict what > else may be done with the location it provides? > > We have been wrapped around the axle on this for, dare I say, years. > > So, I think Barbara Stark first described this, and it needs some work, > but suppose that, as an option, an access network could supply: > > 1. A reference to location > > 2. The results of a LoST query on the location value (viz, PSAP URI and > local dialstring) > > With this, an endpoint could recognize an emergency call and start > routing it to the right PSAP. The LIS would agree to dereference for > PSAPs, but could restrict other uses of location. > > Hannes points out that we need one more thing: the calling network has > to be able to validate that the PSAP URI really is a PSAP URI so that > charging (emergency calls generally are free) is protected. We need a > mechanism for them to do that. > > Perhaps we include in the LoST return a country code for a query with a > geo. We add a new operation to LoST that takes a service, a country > code and a PSAP URI and returns yes/no validation ("Yes, that URI is a > valid URI for that service in that country"). > > What would we need to do to make this happen? > > We need extensions to LCPs or some new protocol that returns an LbyR and > the LoST results. I wonder if this is just more HELD work. > > We need the PSAP URI validation. > > Again, this is optional. The access network may well give up an LbyV. > It may give up an LbyR that it will dereference for the endpoint. The > access network may have a relationship with the calling network such > that the endpoint need not be involved. > > The PSAP URI validation is actually useful without this idea, especially > when location is an LbyR. Instead of having to have the calling network > dereference, and then do a LoST query to validate, it can just do this > PSAP URI validation. > > Would this solve our problem? Would access carriers concerned about > revenue issues with "giving away" location to it's subscribers be > willing to provide LbyR dereferenceable by PSAPs (again remembering that > the access network are local to the PSAPs) as well as LoST query > services to their endpoints? Would this address the concerns raised by > Deutsche Telecom on this issue? > > Let me be very clear that I think this is an ugly solution. I think > that everyone will be much better off if endpoints knew where they were, > and apps could take advantage of that. I think we'll get there. I > think tying location configuration with the LoST query is a bad idea. I > think using LbyR for emergency calls is a bad idea. > > But I can live with it. > > Brian > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 11:03:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSjW-00043b-MW; Mon, 16 Apr 2007 11:03:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSjV-00043M-B0; Mon, 16 Apr 2007 11:03:09 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdSjU-0002rT-20; Mon, 16 Apr 2007 11:03:09 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HdSip-0000UL-SO; Mon, 16 Apr 2007 10:02:28 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Henning Schulzrinne'" Date: Mon, 16 Apr 2007 11:03:03 -0400 Message-ID: <081b01c78038$56dbae70$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceAM0+Rho/vIh9oSQmWwOJ91URkxAABNCNQ In-Reply-To: <5458E518-412E-4F0F-9BD4-19670E77EC27@hxr.us> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: geopriv@ietf.org, "Rosen, Brian" , ecrit@ietf.org Subject: [Ecrit] RE: [Geopriv] Not-so-grand compromise on how to do endpoint centricLCPwithout giving away the store X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Agree. Barbara Stark and I discussed this a while ago. Limiting use by contract is quite useful. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Monday, April 16, 2007 10:27 AM > To: Henning Schulzrinne > Cc: geopriv@ietf.org; Rosen, Brian; ecrit@ietf.org > Subject: Re: [Geopriv] Not-so-grand compromise on how to do endpoint > centricLCPwithout giving away the store > > > On Apr 14, 2007, at 1:55 PM, Henning Schulzrinne wrote: > > > I suspect that the desire to hide location information will > > primarily afflict a few very large incumbent service providers. I > > don't see why a hotel or enterprise would want to hide the location > > from their visitors or employees, say, as the likelihood of > > monetizing this information is zero. > > There is a non-technical solution to this problem. The access > network could easily populate the note well section of the PIDF-LO > with a copyright notice granting free use only for emergency call > routing and dispatch purposes and requiring permission for all other > uses. > > -andy > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 11:10:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSqB-0007CL-RG; Mon, 16 Apr 2007 11:10:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSqA-0007CF-Rb for ecrit@ietf.org; Mon, 16 Apr 2007 11:10:02 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdSq9-0005fu-Kl for ecrit@ietf.org; Mon, 16 Apr 2007 11:10:02 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HdSpW-0000qA-BJ; Mon, 16 Apr 2007 10:09:22 -0500 From: "Brian Rosen" To: "'Marc Linsner'" Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCPwithout giving away the store Date: Mon, 16 Apr 2007 11:09:58 -0400 Message-ID: <081c01c78039$4de4f410$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd9eBCfZxIYRVO7QJu63bsxYVEIfwAd6vQwAAPV6GAAQ9X98ABHfjIwAAIvQEAAANhcQA== In-Reply-To: <004f01c78035$638a0480$2d0d0d0a@amer.cisco.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Right, 2 seconds. You query LCP (that is local). Someone (endpoint or access network) queries LoST (that is not real local, but not very far). You route. The VSP validates (normally local, but may need a referral which could be to anywhere, that may take time). Then it rings. The dereference happens after the ring starts. Brian > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Monday, April 16, 2007 10:42 AM > To: 'Brian Rosen' > Cc: ecrit@ietf.org > Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do > endpointcentric LCPwithout giving away the store > > Brian, > > > > > You update the data at call time. You only use stale data if > > that doesn't work. > > Remind us of the goal for 'send button to ringback' timing, please? 2 > seconds? > > -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 11:19:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSyy-0001ze-J2; Mon, 16 Apr 2007 11:19:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSyx-0001wP-Dl for ecrit@ietf.org; Mon, 16 Apr 2007 11:19:07 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdSyx-0001mb-3E for ecrit@ietf.org; Mon, 16 Apr 2007 11:19:07 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HdSyJ-0003b5-PV; Mon, 16 Apr 2007 10:18:27 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'ECRIT'" Subject: RE: [Ecrit] Hiding (partial) locations Date: Mon, 16 Apr 2007 11:19:03 -0400 Message-ID: <081d01c7803a$930fe760$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd/xw+VhV2q1o75T6eJd4wJqF7LPAAczrOQ In-Reply-To: <75BE6CD6-A8A2-416F-9BC4-627341225C1B@cs.columbia.edu> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This doesn't work in areas that don't have simple PSAP boundaries. Even in a case where the PSAP serves a city, the boundary of the city is very often not exactly that of the municipal boundary. It definitely doesn't work in the U.S. where there are PSAP boundaries that are one side or the other of the street (even and odd addresses), or between two house numbers on a street. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, April 15, 2007 9:33 PM > To: ECRIT > Subject: [Ecrit] Hiding (partial) locations > > After the discussion, I think the simplest approach is the partial > response solution: > > The ISP returns partial location information that is sufficiently > accurate to return the correct PSAP. This would typically be the > county or city. This reveals (almost) no additional information to > the client beyond the PSAP URL. After all, the PSAP boundaries are > public or easily guessable, so it would be easy for an external > entity to construct a mapping that maps PSAP URLs back to rough > locations, thus defeating the efforts by the ISP to hide the location > information from their customers. This level of location information > is also more or less what you can get for free already from services > such as http://www.ip2location.com/free.asp or MaxMind. > > There are two mechanisms for doing that: > > (1) combined LbyV and LbyR: rough information by value, precise > information by (protected) reference; > > (2) just LbyR, but the reference is roughly resolvable by possession, > precise resolution requires a shared secret (held by the PSAP). > > This approach has three advantages: > > (1) If all else fails (such as attempts to resolve the reference), > the PSAP at least has some location information to work with, rather > than a completely useless reference. This is particularly important > if the call arrives at an overflow or backup PSAP, since it will > assume that the call is from its service area and it may not be able > to resolve the reference due to lack of an established trust > relationship. > > (2) The client can verify the information, reducing errors. > > (3) Nothing changes in terms of processing compared to providing full > location information. > > Henning > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 12:10:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTmS-0006Eu-61; Mon, 16 Apr 2007 12:10:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTmQ-0006ER-Nc for ecrit@ietf.org; Mon, 16 Apr 2007 12:10:14 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdTmP-0007PM-GQ for ecrit@ietf.org; Mon, 16 Apr 2007 12:10:14 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 16 Apr 2007 12:10:13 -0400 X-IronPort-AV: i="4.14,415,1170651600"; d="scan'208"; a="57766259:sNHT42622232" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3GGADd2009207; Mon, 16 Apr 2007 12:10:13 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3GG9nle020015; Mon, 16 Apr 2007 16:10:13 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 12:10:09 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 12:10:08 -0400 From: "Marc Linsner" To: "'Brian Rosen'" Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCPwithout giving away the store Date: Mon, 16 Apr 2007 12:10:05 -0400 Message-ID: <006901c78041$b266ce60$2d0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <081c01c78039$4de4f410$640fa8c0@cis.neustar.com> Thread-Index: Acd9eBCfZxIYRVO7QJu63bsxYVEIfwAd6vQwAAPV6GAAQ9X98ABHfjIwAAIvQEAAANhcQAACQwgA X-OriginalArrivalTime: 16 Apr 2007 16:10:08.0773 (UTC) FILETIME=[B431A350:01C78041] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=416; t=1176739813; x=1177603813; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20RE=3A=20[Ecrit]=20Not-so-grand=20compromi se=20on=20how=20to=20do=20endpointcentric=20LCPwithout=20giving=20away=20t he=20store |Sender:=20 |To:=20=22'Brian=20Rosen'=22=20; bh=av7PvFGVGnK9Rg3nqVJZxDbj8HuC9jMVdNYse2eY97g=; b=rDFF6kKNGApFaR7v6xopogdTg4ieQvbGdLxHtRh+5CBGu2sNRDdoXyBGjEaUp3vpDSlSpqez d+OtOg6xDn/LRO22b+MlHcr/CAi08OwZ0j5wI0fZB3WrSoiSkRygic8x; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, > > You query LCP (that is local). Someone (endpoint or access > network) queries LoST (that is not real local, but not very > far). You route. The VSP validates (normally local, but may > need a referral which could be to anywhere, that may take time). > > Then it rings. > > The dereference happens after the ring starts. Please explain 'local'. What are you inferring? -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 12:15:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTr3-000878-AX; Mon, 16 Apr 2007 12:15:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTr1-00086n-4Z; Mon, 16 Apr 2007 12:14:59 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HdTqz-0005rq-NW; Mon, 16 Apr 2007 12:14:59 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns3.neustar.com (Postfix) with ESMTP id 94EEE17613; Mon, 16 Apr 2007 16:14:27 +0000 (GMT) Received: from stntexch12.cis.neustar.com ([10.31.13.31]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 12:14:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCP without giving away the store Date: Mon, 16 Apr 2007 12:14:26 -0400 Message-ID: <886DD03D15173C43BCE98EA662A0101A01EB753E@stntexch12.cis.neustar.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCP without giving away the store Thread-Index: Acd+1NMtfeRXTd/iQnC3HreRyTN7rgBaydXAAACAgVA= From: "Rosen, Brian" To: "Dawson, Martin" , "Henning Schulzrinne" X-OriginalArrivalTime: 16 Apr 2007 16:14:27.0452 (UTC) FILETIME=[4E60EBC0:01C78042] X-Spam-Score: -2.8 (--) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Right. Good summary. However, because at least some networks have to get through Pay to Play, we need to provide mechanisms that work. =20 The proposal (access networks that want pay to play must provide LbyR, PSAP URI and dialstrings seems a workable solution to those networks. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Monday, April 16, 2007 12:10 PM > To: Henning Schulzrinne; Rosen, Brian > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do > endpointcentric LCP without giving away the store >=20 > All very true I think. Providing location, in my view, is likely to go > through the usual stages: >=20 > * Pay to play > * Free as a competitive differentiator > * Lowest common denominator and assumed as part of the access >=20 > I think the first phase is likely to prove quite short, to non-existent, > because of the cost of putting the billing overlay in. >=20 > Telephone companies didn't go into business to provide connectivity to > emergency services but, eventually, they did it because it's a social > service and society enforced the obligation - emergency calling, > including location, became an assumed part of the bundle. >=20 > Similarly, the physics of the situation dictates it's the providers of > broadband Internet access who can work out location (it's not like it's > a business conspiracy) and, eventually, this will become an assumed part > of the access bundle. >=20 > In cellular networks, the location request associated with initiating an > emergency call is called a "network initiated" request because the > mobile switching center makes the request to the location server. > However, most networks also support a form of request called > "mobile-originated". It's quite likely that any suitably capable handset > can request location, unhindered, from those mobile networks. That's > control plane - but SUPL permits SET-initated requests as well. >=20 > Providing location in cellular networks is probably the most network > resource intensive form of this service. The precedent is in, really, > that users will be able to get their location for free. >=20 > The business strategists that you refer to still need to go through > their own processes and come to their own conclusions but I don't think > you'll be suffering stock option envy on this count Henning. >=20 > Cheers, > Martin >=20 >=20 > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, 15 April 2007 12:52 AM > To: Rosen, Brian > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do > endpointcentric LCP without giving away the store >=20 > [This is partially an editorial, but I'll get to solutions in the > next message...] >=20 > My prediction is that the dream of untold riches to be mined from > location information is largely just that. >=20 > In particular, I believe that the value of non-emergency location > information for stationary devices in a residential setting is pretty > close to zero. After all, users already know their home address and > for pizza delivery and similar tasks, it doesn't much matter whether > the address validates. Users will fix their address after the first > cold pizza arrives. >=20 > As a practical matter, monetizing this information is going to be > very difficult, particularly in European Union countries with strong > privacy laws. A VSP is very unlikely to pay for location information, > as it has no direct need for it. The local pizza parlor might find > the information to be of interest, but the logistics are pretty > daunting. Since you can't easily do per-use approval, as you can do > with end system location, the pizza parlor would have to contact the > various access providers and negotiate an arrangement. In addition, > and most onerously, the pizza parlor would probably need to get > individual approval from each potential customer to release this > information to them. As a customer, why would I agree to release > location information to every business, known and unknown, for > purposes unknown? This can be fixed by uploading GEOPRIV policy to > the access provider, but this requires heavy-duty machinery, as > customers have to figure out which domains to include in that list. > The likelihood that users will remember to add the pizza parlor's > domain name to that list before calling for delivery is pretty slim. > For a second delivery, the restaurant already has the correct and > verified address, so it has limited additional value. >=20 > Let's assume for a moment that stationary-device location is indeed > tremendously valuable. If so, we'll very quickly get a budding > entrepreneur that will get the location from the access provider and > then sell it, once, to the customer, for free use henceforth until > the customer changes ISPs. Heck, depending on pricing, the customer > might do it himself. I'd look forward to the having the access > provider sue this enterprise for handing a customer their own street > address. ("Yes, your honor, we don't allow this company to tell our > customer where they live.") >=20 > Maybe Domino's will advertise "Get your free serving of location with > our extra large pepperoni pizza!". >=20 > Thus, this whole hide-location-from-customer thing has the distinct > feeling of cutting off your nose to spite your face or, more to the > topic, of "I can't make VoIP pay for me, so I'm going to make it > difficult for everybody else to offer services, too". >=20 > Location information is obviously valuable for mobile users, but I > suspect that the consequence of making it difficult to get will > simply increase the use of (unassisted) GPS and SkyHook, or BlueTooth > on in-car navigation devices. (As navigation functionality gets > integrated into mobile phones, this has to work even when there is no > cell coverage.) >=20 > While I doubt that this argument will suddenly convince the brilliant > strategists in telecom companies, at least I'll have a convenient > place to point to for an "I told you so" five years from now, or > maybe a good place to be proven wrong while others cash in their > stock options. >=20 > Henning >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 > ------------------------------------------------------------------------ -- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 12:22:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTy9-0000eB-Iy; Mon, 16 Apr 2007 12:22:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTy7-0000a5-Rb for ecrit@ietf.org; Mon, 16 Apr 2007 12:22:19 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdTy6-0003VP-KF for ecrit@ietf.org; Mon, 16 Apr 2007 12:22:19 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HdTxQ-0003i7-88; Mon, 16 Apr 2007 11:21:38 -0500 From: "Brian Rosen" To: "'Marc Linsner'" Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCPwithout giving away the store Date: Mon, 16 Apr 2007 12:22:12 -0400 Message-ID: <083b01c78043$66c5ed40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acd9eBCfZxIYRVO7QJu63bsxYVEIfwAd6vQwAAPV6GAAQ9X98ABHfjIwAAIvQEAAANhcQAACQwgAAAA5wqA= In-Reply-To: <006901c78041$b266ce60$2d0d0d0a@amer.cisco.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The endpoint has a direct connection to the access network; very low latency. The LoST server may be local (because the access network has a replica), or it may be a pretty direct connection (access network + 1-2 hops). In most networks, it won't even get outside the local Internet exchange point (although some backhaul is inevitable). A look at the Pittsburgh exchange point for example shows all the big cable and LEC carriers have presence. The VSP is querying a local-to-him LoST server. That may not have the actual answer to the query, and may have to refer. Brian > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Monday, April 16, 2007 12:10 PM > To: 'Brian Rosen' > Cc: ecrit@ietf.org > Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do > endpointcentric LCPwithout giving away the store > > Brian, > > > > > You query LCP (that is local). Someone (endpoint or access > > network) queries LoST (that is not real local, but not very > > far). You route. The VSP validates (normally local, but may > > need a referral which could be to anywhere, that may take time). > > > > Then it rings. > > > > The dereference happens after the ring starts. > > Please explain 'local'. What are you inferring? > > -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 12:46:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdULA-00025t-4L; Mon, 16 Apr 2007 12:46:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUL8-00021i-50; Mon, 16 Apr 2007 12:46:06 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUL5-00046p-BE; Mon, 16 Apr 2007 12:46:06 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 16 Apr 2007 12:46:03 -0400 id 015880CA.4623A84B.0000330A In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <413C3E2A-6A05-4CC3-9FA4-6BC4C7F18D70@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCP without giving away the store Date: Mon, 16 Apr 2007 12:46:01 -0400 To: GEOPRIV WG X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Using Martin's nice email to perhaps bring this thread back around to GEOPRIV and to quit dancing around the issue, has anyone actually asked us as part of requirements to hide location from the target? If so, who? If not, why are we considering it? -andy On Apr 16, 2007, at 12:09 PM, Dawson, Martin wrote: > All very true I think. Providing location, in my view, is likely to go > through the usual stages: > > * Pay to play > * Free as a competitive differentiator > * Lowest common denominator and assumed as part of the access > > I think the first phase is likely to prove quite short, to non- > existent, > because of the cost of putting the billing overlay in. > > Telephone companies didn't go into business to provide connectivity to > emergency services but, eventually, they did it because it's a social > service and society enforced the obligation - emergency calling, > including location, became an assumed part of the bundle. > > Similarly, the physics of the situation dictates it's the providers of > broadband Internet access who can work out location (it's not like > it's > a business conspiracy) and, eventually, this will become an assumed > part > of the access bundle. > > In cellular networks, the location request associated with > initiating an > emergency call is called a "network initiated" request because the > mobile switching center makes the request to the location server. > However, most networks also support a form of request called > "mobile-originated". It's quite likely that any suitably capable > handset > can request location, unhindered, from those mobile networks. That's > control plane - but SUPL permits SET-initated requests as well. > > Providing location in cellular networks is probably the most network > resource intensive form of this service. The precedent is in, really, > that users will be able to get their location for free. > > The business strategists that you refer to still need to go through > their own processes and come to their own conclusions but I don't > think > you'll be suffering stock option envy on this count Henning. > > Cheers, > Martin > > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, 15 April 2007 12:52 AM > To: Rosen, Brian > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do > endpointcentric LCP without giving away the store > > [This is partially an editorial, but I'll get to solutions in the > next message...] > > My prediction is that the dream of untold riches to be mined from > location information is largely just that. > > In particular, I believe that the value of non-emergency location > information for stationary devices in a residential setting is pretty > close to zero. After all, users already know their home address and > for pizza delivery and similar tasks, it doesn't much matter whether > the address validates. Users will fix their address after the first > cold pizza arrives. > > As a practical matter, monetizing this information is going to be > very difficult, particularly in European Union countries with strong > privacy laws. A VSP is very unlikely to pay for location information, > as it has no direct need for it. The local pizza parlor might find > the information to be of interest, but the logistics are pretty > daunting. Since you can't easily do per-use approval, as you can do > with end system location, the pizza parlor would have to contact the > various access providers and negotiate an arrangement. In addition, > and most onerously, the pizza parlor would probably need to get > individual approval from each potential customer to release this > information to them. As a customer, why would I agree to release > location information to every business, known and unknown, for > purposes unknown? This can be fixed by uploading GEOPRIV policy to > the access provider, but this requires heavy-duty machinery, as > customers have to figure out which domains to include in that list. > The likelihood that users will remember to add the pizza parlor's > domain name to that list before calling for delivery is pretty slim. > For a second delivery, the restaurant already has the correct and > verified address, so it has limited additional value. > > Let's assume for a moment that stationary-device location is indeed > tremendously valuable. If so, we'll very quickly get a budding > entrepreneur that will get the location from the access provider and > then sell it, once, to the customer, for free use henceforth until > the customer changes ISPs. Heck, depending on pricing, the customer > might do it himself. I'd look forward to the having the access > provider sue this enterprise for handing a customer their own street > address. ("Yes, your honor, we don't allow this company to tell our > customer where they live.") > > Maybe Domino's will advertise "Get your free serving of location with > our extra large pepperoni pizza!". > > Thus, this whole hide-location-from-customer thing has the distinct > feeling of cutting off your nose to spite your face or, more to the > topic, of "I can't make VoIP pay for me, so I'm going to make it > difficult for everybody else to offer services, too". > > Location information is obviously valuable for mobile users, but I > suspect that the consequence of making it difficult to get will > simply increase the use of (unassisted) GPS and SkyHook, or BlueTooth > on in-car navigation devices. (As navigation functionality gets > integrated into mobile phones, this has to work even when there is no > cell coverage.) > > While I doubt that this argument will suddenly convince the brilliant > strategists in telecom companies, at least I'll have a convenient > place to point to for an "I told you so" five years from now, or > maybe a good place to be proven wrong while others cash in their > stock options. > > Henning > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2] > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 12:49:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUOc-000371-JE; Mon, 16 Apr 2007 12:49:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUOb-00036v-92 for ecrit@ietf.org; Mon, 16 Apr 2007 12:49:41 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUOa-0006R3-2k for ecrit@ietf.org; Mon, 16 Apr 2007 12:49:41 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3GGnMtF007658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Apr 2007 12:49:22 -0400 (EDT) In-Reply-To: <083b01c78043$66c5ed40$640fa8c0@cis.neustar.com> References: <083b01c78043$66c5ed40$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8FBAEDC3-94F7-4CA7-92D6-8D1468501DD0@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCPwithout giving away the store Date: Mon, 16 Apr 2007 12:50:24 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The problem is that there are (and should be) many LoST resolvers, including those operated by a third party, neither the VSP nor ISP. Relying on some specific deployment combination seems unwise. I agree that the LoST server will often be local. On Apr 16, 2007, at 12:22 PM, Brian Rosen wrote: > The endpoint has a direct connection to the access network; very low > latency. > > The LoST server may be local (because the access network has a > replica), or > it may be a pretty direct connection (access network + 1-2 hops). > In most > networks, it won't even get outside the local Internet exchange point > (although some backhaul is inevitable). A look at the Pittsburgh > exchange > point for example shows all the big cable and LEC carriers have > presence. > > The VSP is querying a local-to-him LoST server. That may not have the > actual answer to the query, and may have to refer. > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 13:08:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUgQ-00013f-5a; Mon, 16 Apr 2007 13:08:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUgN-00010Z-L2; Mon, 16 Apr 2007 13:08:03 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUT1-0001FL-4J; Mon, 16 Apr 2007 12:54:15 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HdUSM-0002ZF-Bs; Mon, 16 Apr 2007 11:53:34 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'GEOPRIV WG'" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCP without giving away the store Date: Mon, 16 Apr 2007 12:54:11 -0400 Message-ID: <084801c78047$dd176600$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceARqUj9wwI+76yTy6JdReh4IMSAgAASPag In-Reply-To: <413C3E2A-6A05-4CC3-9FA4-6BC4C7F18D70@hxr.us> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Well, there was the note from DT, for example. It raised this very issue. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Monday, April 16, 2007 12:46 PM > To: GEOPRIV WG > Cc: ECRIT > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > doendpointcentric LCP without giving away the store > > Using Martin's nice email to perhaps bring this thread back around to > GEOPRIV and to quit dancing around the issue, has anyone actually > asked us as part of requirements to hide location from the target? > If so, who? If not, why are we considering it? > > -andy > > > On Apr 16, 2007, at 12:09 PM, Dawson, Martin wrote: > > > All very true I think. Providing location, in my view, is likely to go > > through the usual stages: > > > > * Pay to play > > * Free as a competitive differentiator > > * Lowest common denominator and assumed as part of the access > > > > I think the first phase is likely to prove quite short, to non- > > existent, > > because of the cost of putting the billing overlay in. > > > > Telephone companies didn't go into business to provide connectivity to > > emergency services but, eventually, they did it because it's a social > > service and society enforced the obligation - emergency calling, > > including location, became an assumed part of the bundle. > > > > Similarly, the physics of the situation dictates it's the providers of > > broadband Internet access who can work out location (it's not like > > it's > > a business conspiracy) and, eventually, this will become an assumed > > part > > of the access bundle. > > > > In cellular networks, the location request associated with > > initiating an > > emergency call is called a "network initiated" request because the > > mobile switching center makes the request to the location server. > > However, most networks also support a form of request called > > "mobile-originated". It's quite likely that any suitably capable > > handset > > can request location, unhindered, from those mobile networks. That's > > control plane - but SUPL permits SET-initated requests as well. > > > > Providing location in cellular networks is probably the most network > > resource intensive form of this service. The precedent is in, really, > > that users will be able to get their location for free. > > > > The business strategists that you refer to still need to go through > > their own processes and come to their own conclusions but I don't > > think > > you'll be suffering stock option envy on this count Henning. > > > > Cheers, > > Martin > > > > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Sunday, 15 April 2007 12:52 AM > > To: Rosen, Brian > > Cc: geopriv@ietf.org; ecrit@ietf.org > > Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do > > endpointcentric LCP without giving away the store > > > > [This is partially an editorial, but I'll get to solutions in the > > next message...] > > > > My prediction is that the dream of untold riches to be mined from > > location information is largely just that. > > > > In particular, I believe that the value of non-emergency location > > information for stationary devices in a residential setting is pretty > > close to zero. After all, users already know their home address and > > for pizza delivery and similar tasks, it doesn't much matter whether > > the address validates. Users will fix their address after the first > > cold pizza arrives. > > > > As a practical matter, monetizing this information is going to be > > very difficult, particularly in European Union countries with strong > > privacy laws. A VSP is very unlikely to pay for location information, > > as it has no direct need for it. The local pizza parlor might find > > the information to be of interest, but the logistics are pretty > > daunting. Since you can't easily do per-use approval, as you can do > > with end system location, the pizza parlor would have to contact the > > various access providers and negotiate an arrangement. In addition, > > and most onerously, the pizza parlor would probably need to get > > individual approval from each potential customer to release this > > information to them. As a customer, why would I agree to release > > location information to every business, known and unknown, for > > purposes unknown? This can be fixed by uploading GEOPRIV policy to > > the access provider, but this requires heavy-duty machinery, as > > customers have to figure out which domains to include in that list. > > The likelihood that users will remember to add the pizza parlor's > > domain name to that list before calling for delivery is pretty slim. > > For a second delivery, the restaurant already has the correct and > > verified address, so it has limited additional value. > > > > Let's assume for a moment that stationary-device location is indeed > > tremendously valuable. If so, we'll very quickly get a budding > > entrepreneur that will get the location from the access provider and > > then sell it, once, to the customer, for free use henceforth until > > the customer changes ISPs. Heck, depending on pricing, the customer > > might do it himself. I'd look forward to the having the access > > provider sue this enterprise for handing a customer their own street > > address. ("Yes, your honor, we don't allow this company to tell our > > customer where they live.") > > > > Maybe Domino's will advertise "Get your free serving of location with > > our extra large pepperoni pizza!". > > > > Thus, this whole hide-location-from-customer thing has the distinct > > feeling of cutting off your nose to spite your face or, more to the > > topic, of "I can't make VoIP pay for me, so I'm going to make it > > difficult for everybody else to offer services, too". > > > > Location information is obviously valuable for mobile users, but I > > suspect that the consequence of making it difficult to get will > > simply increase the use of (unassisted) GPS and SkyHook, or BlueTooth > > on in-car navigation devices. (As navigation functionality gets > > integrated into mobile phones, this has to work even when there is no > > cell coverage.) > > > > While I doubt that this argument will suddenly convince the brilliant > > strategists in telecom companies, at least I'll have a convenient > > place to point to for an "I told you so" five years from now, or > > maybe a good place to be proven wrong while others cash in their > > stock options. > > > > Henning > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > ---------------------------------------------------------------------- > > -------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > ---------------------------------------------------------------------- > > -------------------------- > > [mf2] > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 13:08:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUgS-00019s-6R; Mon, 16 Apr 2007 13:08:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUgP-00010Z-45; Mon, 16 Apr 2007 13:08:05 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdURd-0000N4-R0; Mon, 16 Apr 2007 12:52:51 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3GGqfds008577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Apr 2007 12:52:44 -0400 (EDT) In-Reply-To: <886DD03D15173C43BCE98EA662A0101A01EB753E@stntexch12.cis.neustar.com> References: <886DD03D15173C43BCE98EA662A0101A01EB753E@stntexch12.cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <82FC4705-1E65-4033-94E9-A19A4A210C65@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCP without giving away the store Date: Mon, 16 Apr 2007 12:53:46 -0400 To: "Rosen, Brian" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: geopriv@ietf.org, "Dawson, Martin" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 16, 2007, at 12:14 PM, Rosen, Brian wrote: > Right. Good summary. > > However, because at least some networks have to get through Pay to > Play, > we need to provide mechanisms that work. > > The proposal (access networks that want pay to play must provide LbyR, > PSAP URI and dialstrings seems a workable solution to those networks. This only works for stationary devices, barely, unless there's an event notification mechanism that updates that information, particularly the PSAP URL. Otherwise, you have to rely on call-time queries, which significantly degrade reliability and performance. In that case, you're not providing a service that is equivalent and the customer pays for the provider's pay-to-play dreams with their life and property. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 13:13:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUlc-0002vB-Hc; Mon, 16 Apr 2007 13:13:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUlb-0002uo-Ju; Mon, 16 Apr 2007 13:13:27 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUla-0000Ea-E0; Mon, 16 Apr 2007 13:13:27 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 16 Apr 2007 13:13:25 -0400 id 015880CA.4623AEB5.00003A68 In-Reply-To: <084801c78047$dd176600$640fa8c0@cis.neustar.com> References: <084801c78047$dd176600$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <551B1465-0345-4B66-8FA1-B4B665AB6DB5@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCP without giving away the store Date: Mon, 16 Apr 2007 13:13:24 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: 'GEOPRIV WG' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 16, 2007, at 12:54 PM, Brian Rosen wrote: > Well, there was the note from DT, for example. Refresh my caffeine-starved brain. DT? > It raised this very issue. I'm getting the sense from this email thread that people do not believe it is a reasonable requirement for various reasons. We are not obliged to accept everything thrown at us. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 13:14:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUmJ-0003bF-Qz; Mon, 16 Apr 2007 13:14:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUmI-0003b9-OR for ecrit@ietf.org; Mon, 16 Apr 2007 13:14:10 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUmH-0000nH-I3 for ecrit@ietf.org; Mon, 16 Apr 2007 13:14:10 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3GHE6Cw014154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Apr 2007 13:14:06 -0400 (EDT) In-Reply-To: <081d01c7803a$930fe760$640fa8c0@cis.neustar.com> References: <081d01c7803a$930fe760$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Hiding (partial) locations Date: Mon, 16 Apr 2007 13:15:19 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 16, 2007, at 11:19 AM, Brian Rosen wrote: > This doesn't work in areas that don't have simple PSAP boundaries. Agreed; it would require more precise location in those jurisdictions. Those do seem to be the exception, however. > > Even in a case where the PSAP serves a city, the boundary of the > city is > very often not exactly that of the municipal boundary. Again, this would only force an ISP to provide more precise location information to those relative handful of exception cases. This seems like a fair trade-off. > > It definitely doesn't work in the U.S. where there are PSAP > boundaries that > are one side or the other of the street (even and odd addresses), > or between > two house numbers on a street. My perception is that PSAP boundaries that don't correspond to community or county names occur, but only affect a tiny fraction of the population. (Street don't matter. Broad Avenue, for example, traverses a half dozen communities in northern Bergen County, but each town has its own PSAP, whose responsibility is defined by the community, not the street.) > > Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 13:19:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUrN-0006GJ-8P; Mon, 16 Apr 2007 13:19:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUrM-0006Ex-Mw; Mon, 16 Apr 2007 13:19:24 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUrL-0002Py-Qu; Mon, 16 Apr 2007 13:19:24 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns1.neustar.com (Postfix) with ESMTP id 9F37626EA0; Mon, 16 Apr 2007 17:19:23 +0000 (GMT) Received: from stntexch12.cis.neustar.com ([10.31.13.31]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 13:19:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCP without giving away the store Date: Mon, 16 Apr 2007 13:19:22 -0400 Message-ID: <886DD03D15173C43BCE98EA662A0101A01EB7570@stntexch12.cis.neustar.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCP without giving away the store Thread-Index: Acd+1NMtfeRXTd/iQnC3HreRyTN7rgBaydXAAACAgVAAAJGIkAABUw3g From: "Rosen, Brian" To: "Dawson, Martin" , "Henning Schulzrinne" X-OriginalArrivalTime: 16 Apr 2007 17:19:23.0338 (UTC) FILETIME=[6081F2A0:01C7804B] X-Spam-Score: -2.3 (--) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org If the LCP guys don't want to include a location URI and dialstring in a response, then I think we need a new protocol to combine the LCP + LoST response in a single query to the access network. I don't have a problem with that, although it's just one more thing the endpoint has to implement. I don't want to revisit LoST dereference of LbyR. As we said, the LoST server may be operated by lots of different entities and I don't want to have to tie them into an authorization mechanism for dereferencing. In fact, I really want to make sure that operationally, whether it's the endpoint, the access network or the VSP that is doing the LoST dip, I want it to work everywhere. =20 I do think having country code visible is a good thing. I have two reasons (validation and disputed territory). You add a third. I think we need to make sure country code is visible. That is a change. It's true that the access network has more of a responsibility to support emergency calling in next generation networks. The VSP (or its equivalent, for example, an IM service provider), has to have a very low level of responsibility, namely, routing a call to the PSAP. We want that to be true primarily because of the difficulty in regulating services providers across the Internet. Access networks, after all, are always local. IM service providers and VSPs are not necessarily local, but we want them to support emergency calling anyway. We need to make it as lightweight on them. I recall asking a founder of Skype if the access network supplied location, the route database was publically available on the Internet, and the PSAP accepted SIP calls from the Internet if free Skype service would support emergency calling. His answer was very illustrative: "why not?" Not just "probably yes", not even just "yes" but "why not?". That's the reaction we want. I think most access networks will provide location for emergency calling for the reason listed. They really do think it is part of their responsibility as a common carrier. Local networks will support the local emergency services. That is as it should be. The problem is that we need ALL access networks to support local emergency calling. The "ALL" inevitably implies regulation. In the IETF, we don't have to deal with those issues, but our architecture is dependent on ALL. Brian=20 > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Monday, April 16, 2007 1:01 PM > To: Rosen, Brian; Henning Schulzrinne > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do > endpointcentric LCP without giving away the store >=20 > Absolutely - agreed. Now I've finally reached the top of the thread. > Here's my perspective: >=20 > * Devices and VSPs should be assumed to have *no* knowledge of the > emergency jurisdiction or the access networks - that includes their > preferred form of location presentation, whether signing is required, > and what rights/rules exist if dereferencing is to occur. >=20 > * The access network should be assumed to know what the local > jurisdiction expects, is able to do, and of course what the access > provider wants to do viz restricting availability of the location > information. >=20 > The corollary is that most of the responsibility for ensuring > interoperability of emergency services at the local level lies with the > access provider and the local emergency services provider(s). The device > needs to know how to find the LIS, ask for location suitable for > emergency use, get it to the LoST server and initiate the call with the > location information included. >=20 > While the LoST server could be part of the access, it certainly doesn't > have to be. There's nothing in LoST that makes the access provider the > most suitable entity to administer the server. I also agree that > conflating the emergency routing service with the location service is > unnecessary and would only reduce flexibility for different > jurisdictions. So let's try to avoid turning HELD into anything more > than a location protocol. (Somebody mentioned that adding configuration > information to a location protocol would be counter-productive. I > heartily agree, and think the converse applies. Sorry - I couldn't > resist that). >=20 > Implied in what I said above is the need for the LCP to support an > explicit request for the "emergency form" of location. HELD does have > that currently but in discussions with Martin T and James W, we think > this needs beefing up due to the "richness of the permutations" that can > be expected in different jurisdictions. >=20 > There are two other things that I would really appreciate being > considered and discussed: >=20 > * Re-evaluating the support of LbyR in the LoST query (since the device > cannot assume the form in which the access will provide location). >=20 > * Defining a method (BCP or otherwise) by which a VSP can determine at a > high level of granularity (I'd be happy with country code) what > jurisdiction the call is coming from. This is purely to support i2 type > architectures where it is the VSP responsibility to identify the correct > VPC. Without some kind of jurisdiction-indication, particularly when > location is provided as a reference, it will be difficult to support > global roaming for subscribers. As above, a VSP cannot be assumed to > have the right to do a dereference - the LIS may be in a completely > different country. For example, can a BCP for reference construction > include this consideration? >=20 > Cheers, > Martin >=20 >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Tuesday, 17 April 2007 2:14 AM > To: Dawson, Martin; Henning Schulzrinne > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do > endpointcentric LCP without giving away the store >=20 > Right. Good summary. >=20 > However, because at least some networks have to get through Pay to Play, > we need to provide mechanisms that work. >=20 > The proposal (access networks that want pay to play must provide LbyR, > PSAP URI and dialstrings seems a workable solution to those networks. >=20 > Brian >=20 > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: Monday, April 16, 2007 12:10 PM > > To: Henning Schulzrinne; Rosen, Brian > > Cc: geopriv@ietf.org; ecrit@ietf.org > > Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > do > > endpointcentric LCP without giving away the store > > > > All very true I think. Providing location, in my view, is likely to go > > through the usual stages: > > > > * Pay to play > > * Free as a competitive differentiator > > * Lowest common denominator and assumed as part of the access > > > > I think the first phase is likely to prove quite short, to > non-existent, > > because of the cost of putting the billing overlay in. > > > > Telephone companies didn't go into business to provide connectivity to > > emergency services but, eventually, they did it because it's a social > > service and society enforced the obligation - emergency calling, > > including location, became an assumed part of the bundle. > > > > Similarly, the physics of the situation dictates it's the providers of > > broadband Internet access who can work out location (it's not like > it's > > a business conspiracy) and, eventually, this will become an assumed > part > > of the access bundle. > > > > In cellular networks, the location request associated with initiating > an > > emergency call is called a "network initiated" request because the > > mobile switching center makes the request to the location server. > > However, most networks also support a form of request called > > "mobile-originated". It's quite likely that any suitably capable > handset > > can request location, unhindered, from those mobile networks. That's > > control plane - but SUPL permits SET-initated requests as well. > > > > Providing location in cellular networks is probably the most network > > resource intensive form of this service. The precedent is in, really, > > that users will be able to get their location for free. > > > > The business strategists that you refer to still need to go through > > their own processes and come to their own conclusions but I don't > think > > you'll be suffering stock option envy on this count Henning. > > > > Cheers, > > Martin > > > > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Sunday, 15 April 2007 12:52 AM > > To: Rosen, Brian > > Cc: geopriv@ietf.org; ecrit@ietf.org > > Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do > > endpointcentric LCP without giving away the store > > > > [This is partially an editorial, but I'll get to solutions in the > > next message...] > > > > My prediction is that the dream of untold riches to be mined from > > location information is largely just that. > > > > In particular, I believe that the value of non-emergency location > > information for stationary devices in a residential setting is pretty > > close to zero. After all, users already know their home address and > > for pizza delivery and similar tasks, it doesn't much matter whether > > the address validates. Users will fix their address after the first > > cold pizza arrives. > > > > As a practical matter, monetizing this information is going to be > > very difficult, particularly in European Union countries with strong > > privacy laws. A VSP is very unlikely to pay for location information, > > as it has no direct need for it. The local pizza parlor might find > > the information to be of interest, but the logistics are pretty > > daunting. Since you can't easily do per-use approval, as you can do > > with end system location, the pizza parlor would have to contact the > > various access providers and negotiate an arrangement. In addition, > > and most onerously, the pizza parlor would probably need to get > > individual approval from each potential customer to release this > > information to them. As a customer, why would I agree to release > > location information to every business, known and unknown, for > > purposes unknown? This can be fixed by uploading GEOPRIV policy to > > the access provider, but this requires heavy-duty machinery, as > > customers have to figure out which domains to include in that list. > > The likelihood that users will remember to add the pizza parlor's > > domain name to that list before calling for delivery is pretty slim. > > For a second delivery, the restaurant already has the correct and > > verified address, so it has limited additional value. > > > > Let's assume for a moment that stationary-device location is indeed > > tremendously valuable. If so, we'll very quickly get a budding > > entrepreneur that will get the location from the access provider and > > then sell it, once, to the customer, for free use henceforth until > > the customer changes ISPs. Heck, depending on pricing, the customer > > might do it himself. I'd look forward to the having the access > > provider sue this enterprise for handing a customer their own street > > address. ("Yes, your honor, we don't allow this company to tell our > > customer where they live.") > > > > Maybe Domino's will advertise "Get your free serving of location with > > our extra large pepperoni pizza!". > > > > Thus, this whole hide-location-from-customer thing has the distinct > > feeling of cutting off your nose to spite your face or, more to the > > topic, of "I can't make VoIP pay for me, so I'm going to make it > > difficult for everybody else to offer services, too". > > > > Location information is obviously valuable for mobile users, but I > > suspect that the consequence of making it difficult to get will > > simply increase the use of (unassisted) GPS and SkyHook, or BlueTooth > > on in-car navigation devices. (As navigation functionality gets > > integrated into mobile phones, this has to work even when there is no > > cell coverage.) > > > > While I doubt that this argument will suddenly convince the brilliant > > strategists in telecom companies, at least I'll have a convenient > > place to point to for an "I told you so" five years from now, or > > maybe a good place to be proven wrong while others cash in their > > stock options. > > > > Henning > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] >=20 >=20 > ------------------------------------------------------------------------ -- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 13:25:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUx1-0000nn-Dm; Mon, 16 Apr 2007 13:25:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUx0-0000nf-4r; Mon, 16 Apr 2007 13:25:14 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUwy-0003kJ-S0; Mon, 16 Apr 2007 13:25:14 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HdUwK-0001j3-0F; Mon, 16 Apr 2007 12:24:32 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCP without giving away the store Date: Mon, 16 Apr 2007 13:25:09 -0400 Message-ID: <086101c7804c$3084fc40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceASnV29pglvIz7Q1WQ7Ew3LblE3gAAbZPA In-Reply-To: <551B1465-0345-4B66-8FA1-B4B665AB6DB5@hxr.us> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: 'GEOPRIV WG' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org http://www1.ietf.org/mail-archive/web/ecrit/current/msg03352.html > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Monday, April 16, 2007 1:13 PM > To: Brian Rosen > Cc: 'GEOPRIV WG'; 'ECRIT' > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > doendpointcentric LCP without giving away the store > > > On Apr 16, 2007, at 12:54 PM, Brian Rosen wrote: > > > Well, there was the note from DT, for example. > > Refresh my caffeine-starved brain. DT? > > > It raised this very issue. > > I'm getting the sense from this email thread that people do not > believe it is a reasonable requirement for various reasons. We are > not obliged to accept everything thrown at us. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 13:32:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdV3q-0002lT-5D; Mon, 16 Apr 2007 13:32:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdV3o-0002lL-Ou; Mon, 16 Apr 2007 13:32:16 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdV3n-0005ne-Hm; Mon, 16 Apr 2007 13:32:16 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 16 Apr 2007 13:32:15 -0400 X-IronPort-AV: i="4.14,415,1170651600"; d="scan'208"; a="118649281:sNHT45129520" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3GHWFlf016545; Mon, 16 Apr 2007 13:32:15 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3GHVnlS013656; Mon, 16 Apr 2007 17:32:15 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 13:32:06 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 13:32:04 -0400 From: "Marc Linsner" To: "'Brian Rosen'" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how todoendpointcentric LCP without giving away the store Date: Mon, 16 Apr 2007 13:32:03 -0400 Message-ID: <00a301c7804d$2711bee0$2d0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <084801c78047$dd176600$640fa8c0@cis.neustar.com> Thread-Index: AceARqUj9wwI+76yTy6JdReh4IMSAgAASPagAAFQ5aA= X-OriginalArrivalTime: 16 Apr 2007 17:32:06.0087 (UTC) FILETIME=[27243570:01C7804D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=144; t=1176744735; x=1177608735; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20Re=3A=20[Ecrit]=20Not-so-grand=20compromi se=20on=20how=20todoendpointcentric=20LCP=20without=20giving=20away=20the= 20store |Sender:=20 |To:=20=22'Brian=20Rosen'=22=20; bh=DXCWlKHOLov1HY1Fu6J/V/Emik1XqZLGaAEu1sPmPks=; b=JC/OwP647jn59H1XVkO/FmMwzQ+cyB84IWw2IT9QHaewgu3w57uC1fZdPHo3czvbvti6NDIb qKH82Td4GDZzchIAKmCHVrM8xBwPpZefturAr9G1y0Wq66NmVcXSE7+z; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: 'GEOPRIV WG' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > Well, there was the note from DT, for example. > > It raised this very issue. And they stated they have a solution. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 13:34:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdV5V-0003rF-FX; Mon, 16 Apr 2007 13:34:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdV5U-0003qz-ET; Mon, 16 Apr 2007 13:34:00 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdV5U-00066U-4g; Mon, 16 Apr 2007 13:34:00 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3GHXq73024629 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Apr 2007 13:33:57 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCP without giving away the store Date: Mon, 16 Apr 2007 13:35:05 -0400 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: geopriv@ietf.org, "Rosen, Brian" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Location determination is not likely to be the major delaying factor, although it can be under the wrong circumstances. If there's even modest packet loss, any TCP connection establishment can be delayed significantly, due to the exponential backoff retry. We'd have to do 2 such lookups (L7 and LoST), plus DNS to resolve the LoST-returned URL. Thus, we're talking roughly 10 round trip times (2 handshakes for TCP, 2 query/response for LoST and L7, plus one round trip for DNS). The initial TCP timeout is 500 ms, if I recall correctly and so is the DNS timeout, both with exponential backoff.) I'm particularly concerned with mass casualty events, where the infrastructure is under duress. Most of the time, none of this will be problem; however, even with modest packet loss rates, there will be a significant fraction of calls experiencing delays of one or more seconds, which are indeed significant based on the performance requirements we were given by the PSAP community. The critical timing is determining rough location and the URL lookup; this can all be done ahead of the call with no loss of accuracy. Thus, delaying PSAP URI determination until call time will indeed degrade the timeliness of emergency calls. Henning On Apr 16, 2007, at 1:08 PM, Dawson, Martin wrote: > I really can't buy into the "significantly degrades > performance/reliability" argument. > > Actually, I think that not doing it at call-initiation may cause the > more significant degradation. > > It can't be assumed that the device "knows" that it's not mobile. As > Brian mentioned, using Ethernet on a mobile platform (camper, train, > plane...) make mobility invisible to the device. > > I can't imagine any sensibly implemented wireline access location > technology that would impose anything more significant than sub-second > response for maximal accuracy. For mobile networks, it may take > longer - > but it's exactly for mobile networks that it's preferable to determine > location as close as possible to call origination time (just as is > done > in cellular today). > > I suppose that BCP could state that, in the absence of an updated > location at the time of the call within the time required, the device > may use the last-known location. That is an optimization and not a > fundamental principle. A well defined fallback procedure should always > be in place. > > Cheers, > Martin > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, 17 April 2007 2:54 AM > To: Rosen, Brian > Cc: Dawson, Martin; geopriv@ietf.org; ecrit@ietf.org > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how > to do > endpointcentric LCP without giving away the store > > > On Apr 16, 2007, at 12:14 PM, Rosen, Brian wrote: > >> Right. Good summary. >> >> However, because at least some networks have to get through Pay to >> Play, >> we need to provide mechanisms that work. >> >> The proposal (access networks that want pay to play must provide >> LbyR, >> PSAP URI and dialstrings seems a workable solution to those networks. > > This only works for stationary devices, barely, unless there's an > event notification mechanism that updates that information, > particularly the PSAP URL. > > Otherwise, you have to rely on call-time queries, which significantly > degrade reliability and performance. In that case, you're not > providing a service that is equivalent and the customer pays for the > provider's pay-to-play dreams with their life and property. > > Henning > > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2] > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 13:35:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdV7J-0004lG-Tf; Mon, 16 Apr 2007 13:35:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdV7I-0004iv-6J; Mon, 16 Apr 2007 13:35:52 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdV7G-0007AS-9s; Mon, 16 Apr 2007 13:35:52 -0400 Received: from ([139.76.131.31]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.20253126; Mon, 16 Apr 2007 13:35:29 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 16 Apr 2007 13:35:28 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 16 Apr 2007 13:35:28 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCP without giving away the store Date: Mon, 16 Apr 2007 13:35:27 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA03938DAB@crexc41p> In-Reply-To: <413C3E2A-6A05-4CC3-9FA4-6BC4C7F18D70@hxr.us> X-MS-Has-Attach: Importance: normal Priority: normal X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCP without giving away the store Thread-Index: AceARswv8VnaWowSQSOQuyD0Wr5oOgABg80w References: <413C3E2A-6A05-4CC3-9FA4-6BC4C7F18D70@hxr.us> From: "Stark, Barbara" To: "Andrew Newton" , "GEOPRIV WG" X-OriginalArrivalTime: 16 Apr 2007 17:35:28.0504 (UTC) FILETIME=[9FCA9780:01C7804D] X-Spam-Score: 0.1 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I asked for it. I believe Otmar asked for it, also. I don't think I can get my company to support this architecture if hiding location from endpoints isn't an option. Barbara -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Monday, April 16, 2007 12:46 PM To: GEOPRIV WG Cc: ECRIT Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCP without giving away the store Using Martin's nice email to perhaps bring this thread back around to GEOPRIV and to quit dancing around the issue, has anyone actually =20 asked us as part of requirements to hide location from the target? =20 If so, who? If not, why are we considering it? -andy On Apr 16, 2007, at 12:09 PM, Dawson, Martin wrote: > All very true I think. Providing location, in my view, is likely to go > through the usual stages: > > * Pay to play > * Free as a competitive differentiator > * Lowest common denominator and assumed as part of the access > > I think the first phase is likely to prove quite short, to non-=20 > existent, because of the cost of putting the billing overlay in. > > Telephone companies didn't go into business to provide connectivity to > emergency services but, eventually, they did it because it's a social=20 > service and society enforced the obligation - emergency calling,=20 > including location, became an assumed part of the bundle. > > Similarly, the physics of the situation dictates it's the providers of > broadband Internet access who can work out location (it's not like=20 > it's a business conspiracy) and, eventually, this will become an=20 > assumed part of the access bundle. > > In cellular networks, the location request associated with initiating=20 > an emergency call is called a "network initiated" request because the=20 > mobile switching center makes the request to the location server. > However, most networks also support a form of request called=20 > "mobile-originated". It's quite likely that any suitably capable=20 > handset can request location, unhindered, from those mobile networks.=20 > That's control plane - but SUPL permits SET-initated requests as well. > > Providing location in cellular networks is probably the most network=20 > resource intensive form of this service. The precedent is in, really,=20 > that users will be able to get their location for free. > > The business strategists that you refer to still need to go through=20 > their own processes and come to their own conclusions but I don't=20 > think you'll be suffering stock option envy on this count Henning. > > Cheers, > Martin > > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, 15 April 2007 12:52 AM > To: Rosen, Brian > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do=20 > endpointcentric LCP without giving away the store > > [This is partially an editorial, but I'll get to solutions in the next > message...] > > My prediction is that the dream of untold riches to be mined from=20 > location information is largely just that. > > In particular, I believe that the value of non-emergency location=20 > information for stationary devices in a residential setting is pretty=20 > close to zero. After all, users already know their home address and=20 > for pizza delivery and similar tasks, it doesn't much matter whether=20 > the address validates. Users will fix their address after the first=20 > cold pizza arrives. > > As a practical matter, monetizing this information is going to be very > difficult, particularly in European Union countries with strong=20 > privacy laws. A VSP is very unlikely to pay for location information,=20 > as it has no direct need for it. The local pizza parlor might find the > information to be of interest, but the logistics are pretty daunting.=20 > Since you can't easily do per-use approval, as you can do with end=20 > system location, the pizza parlor would have to contact the various=20 > access providers and negotiate an arrangement. In addition, and most=20 > onerously, the pizza parlor would probably need to get individual=20 > approval from each potential customer to release this information to=20 > them. As a customer, why would I agree to release location information > to every business, known and unknown, for purposes unknown? This can=20 > be fixed by uploading GEOPRIV policy to the access provider, but this=20 > requires heavy-duty machinery, as customers have to figure out which=20 > domains to include in that list. > The likelihood that users will remember to add the pizza parlor's=20 > domain name to that list before calling for delivery is pretty slim. > For a second delivery, the restaurant already has the correct and=20 > verified address, so it has limited additional value. > > Let's assume for a moment that stationary-device location is indeed=20 > tremendously valuable. If so, we'll very quickly get a budding=20 > entrepreneur that will get the location from the access provider and=20 > then sell it, once, to the customer, for free use henceforth until the > customer changes ISPs. Heck, depending on pricing, the customer might=20 > do it himself. I'd look forward to the having the access provider sue=20 > this enterprise for handing a customer their own street address.=20 > ("Yes, your honor, we don't allow this company to tell our customer=20 > where they live.") > > Maybe Domino's will advertise "Get your free serving of location with=20 > our extra large pepperoni pizza!". > > Thus, this whole hide-location-from-customer thing has the distinct=20 > feeling of cutting off your nose to spite your face or, more to the=20 > topic, of "I can't make VoIP pay for me, so I'm going to make it=20 > difficult for everybody else to offer services, too". > > Location information is obviously valuable for mobile users, but I=20 > suspect that the consequence of making it difficult to get will simply > increase the use of (unassisted) GPS and SkyHook, or BlueTooth on=20 > in-car navigation devices. (As navigation functionality gets=20 > integrated into mobile phones, this has to work even when there is no=20 > cell coverage.) > > While I doubt that this argument will suddenly convince the brilliant=20 > strategists in telecom companies, at least I'll have a convenient=20 > place to point to for an "I told you so" five years from now, or maybe > a good place to be proven wrong while others cash in their stock=20 > options. > > Henning > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may contain=20 > privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender immediately > and delete the original. Any unauthorized use of this email is=20 > prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2] > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA625 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 13:36:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdV7V-0005A3-S1; Mon, 16 Apr 2007 13:36:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdV7U-00059q-2K; Mon, 16 Apr 2007 13:36:04 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdV7T-0007DJ-9G; Mon, 16 Apr 2007 13:36:04 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HdV6n-00046v-UV; Mon, 16 Apr 2007 12:35:22 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "Rosen, Brian" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCP without giving away the store Date: Mon, 16 Apr 2007 13:35:59 -0400 Message-ID: <086201c7804d$b40d34f0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceASbiEZRLwAFJNTMapAQu8k4vgJQAAexMg In-Reply-To: <82FC4705-1E65-4033-94E9-A19A4A210C65@cs.columbia.edu> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: geopriv@ietf.org, "'Dawson, Martin'" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Okay, let's look at this. For fixed devices, the PSAP URI doesn't change often, the cached value is very likely to be good. However, it MIGHT change on short notice. The call time query fixes this, if it works. For mobile devices, the endpoint may get a reference. The REFERENCE doesn't change. It's good for a long time (probably as long as the carrier - subscriber relationship holds). If it gets a value, then it wants an update when it moves beyond the PSAP boundary. With a value, it queries LoST and gets the boundary, then passes that to its location determination mechanism and asks for a notification when it moves beyond that. The above, of course, is fairly far from what IMS currently talks about, but that is what the IETF ecrit/presence architecture would say. If the access network plays cozy with the location, so it passes a reference and a PSAP URI, then it needs a way to TELL the device when the PSAP URI is no longer valid. Perhaps we could define a SIP event package for this purpose, so a LIS could notify an endpoint of a new PSAP URI when its current location warranted that. I suppose this is a presence thing, and maybe we could tie this more strongly into the existing presence system. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, April 16, 2007 12:54 PM > To: Rosen, Brian > Cc: geopriv@ietf.org; Dawson, Martin; ecrit@ietf.org > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > doendpointcentric LCP without giving away the store > > > On Apr 16, 2007, at 12:14 PM, Rosen, Brian wrote: > > > Right. Good summary. > > > > However, because at least some networks have to get through Pay to > > Play, > > we need to provide mechanisms that work. > > > > The proposal (access networks that want pay to play must provide LbyR, > > PSAP URI and dialstrings seems a workable solution to those networks. > > This only works for stationary devices, barely, unless there's an > event notification mechanism that updates that information, > particularly the PSAP URL. > > Otherwise, you have to rely on call-time queries, which significantly > degrade reliability and performance. In that case, you're not > providing a service that is equivalent and the customer pays for the > provider's pay-to-play dreams with their life and property. > > Henning > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 13:42:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdVDZ-0007ED-0y; Mon, 16 Apr 2007 13:42:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdVDX-0007E4-6O for ecrit@ietf.org; Mon, 16 Apr 2007 13:42:19 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdVDW-0000YJ-O2 for ecrit@ietf.org; Mon, 16 Apr 2007 13:42:19 -0400 Received: from ([139.76.131.91]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.20254037; Mon, 16 Apr 2007 13:42:00 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 16 Apr 2007 13:42:00 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 16 Apr 2007 13:42:00 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Date: Mon, 16 Apr 2007 13:41:59 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA03938DB4@crexc41p> In-Reply-To: <081c01c78039$4de4f410$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Thread-Index: Acd9eBCfZxIYRVO7QJu63bsxYVEIfwAd6vQwAAPV6GAAQ9X98ABHfjIwAAIvQEAAANhcQAAFTFSg References: <004f01c78035$638a0480$2d0d0d0a@amer.cisco.com> <081c01c78039$4de4f410$640fa8c0@cis.neustar.com> From: "Stark, Barbara" Importance: normal Priority: normal To: "Brian Rosen" , "Marc Linsner" X-OriginalArrivalTime: 16 Apr 2007 17:42:00.0022 (UTC) FILETIME=[89277F60:01C7804E] X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org If I were a VSP concerned with this problem, I wouldn't make the validation sequential in the process. I would go ahead and route the call and do the validation simultaneously. If it's really invalid, then I charge for it, or maybe shut down the call. That depends on how big of a problem this is. I would also probably cache valid emergency URIs, so I can do the validation locally. But that's just me. Barbara =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Monday, April 16, 2007 11:10 AM To: 'Marc Linsner' Cc: ecrit@ietf.org Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Right, 2 seconds. You query LCP (that is local). Someone (endpoint or access network) queries LoST (that is not real local, but not very far). You route. The VSP validates (normally local, but may need a referral which could be to anywhere, that may take time). Then it rings. =20 The dereference happens after the ring starts. Brian > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Monday, April 16, 2007 10:42 AM > To: 'Brian Rosen' > Cc: ecrit@ietf.org > Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to=20 > do endpointcentric LCPwithout giving away the store >=20 > Brian, >=20 > > > > You update the data at call time. You only use stale data if that=20 > > doesn't work. >=20 > Remind us of the goal for 'send button to ringback' timing, please? 2 > seconds? >=20 > -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA624 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 13:47:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdVIn-0007ei-Ld; Mon, 16 Apr 2007 13:47:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdVIn-0007ea-0v; Mon, 16 Apr 2007 13:47:45 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdVIl-0002AD-Ng; Mon, 16 Apr 2007 13:47:45 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3GHlYeT009024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Apr 2007 13:47:38 -0400 (EDT) In-Reply-To: <086201c7804d$b40d34f0$640fa8c0@cis.neustar.com> References: <086201c7804d$b40d34f0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCP without giving away the store Date: Mon, 16 Apr 2007 13:48:47 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org We have such a mechanism, in progress at least: The SIP configuration framework (see http://tools.ietf.org/html/draft-ietf-sipping-config- framework-11). It supports SIP-based event notifications for configuration updates. As I said in an earlier message, re-inventing a subset of the configuration framework just for this purpose seems counterproductive. On Apr 16, 2007, at 1:35 PM, Brian Rosen wrote: > Okay, let's look at this. > > For fixed devices, the PSAP URI doesn't change often, the cached > value is > very likely to be good. However, it MIGHT change on short notice. > The call > time query fixes this, if it works. > > For mobile devices, the endpoint may get a reference. The > REFERENCE doesn't > change. It's good for a long time (probably as long as the carrier - > subscriber relationship holds). If it gets a value, then it wants > an update > when it moves beyond the PSAP boundary. With a value, it queries > LoST and > gets the boundary, then passes that to its location determination > mechanism > and asks for a notification when it moves beyond that. > > The above, of course, is fairly far from what IMS currently talks > about, but > that is what the IETF ecrit/presence architecture would say. > > If the access network plays cozy with the location, so it passes a > reference > and a PSAP URI, then it needs a way to TELL the device when the > PSAP URI is > no longer valid. Perhaps we could define a SIP event package for this > purpose, so a LIS could notify an endpoint of a new PSAP URI when its > current location warranted that. I suppose this is a presence > thing, and > maybe we could tie this more strongly into the existing presence > system. > > Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 14:21:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdVps-0003yw-QK; Mon, 16 Apr 2007 14:21:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdVpr-0003y6-Mu for ecrit@ietf.org; Mon, 16 Apr 2007 14:21:55 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdVpr-00018D-2q for ecrit@ietf.org; Mon, 16 Apr 2007 14:21:55 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3GILdbE000182 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Apr 2007 14:21:43 -0400 (EDT) In-Reply-To: <07f501c7802e$6cb06920$640fa8c0@cis.neustar.com> References: <07f501c7802e$6cb06920$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Re: [Ecrit] URL verification Date: Mon, 16 Apr 2007 14:22:52 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: de672dd48bf7248e70d446cd2da63266 Cc: ecrit@ietf.org, "Rosen, Brian" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org [I think it would be helpful to align the subject with the topic at hand, as this is confusing enough already...] While it is certainly a good idea to provide country information to the user, as that will also allow retrieval of the dial string using LoST and possibly a default if-all-else-fails "PSAP", I don't see this as necessary for checking whether a URL is a PSAP or not. As I mentioned before, the number of such URLs and the total data volume is so small that flooding this to all resolvers isn't a big problem. If we don't want to flood, there are other mechanisms that can be used to efficiently determine where in the server hierarchy a URL might be. In particular, Bloom filters are a good way to do this. Henning On Apr 16, 2007, at 9:52 AM, Brian Rosen wrote: > Thank you for this reminder. > > I don't think we have a real problem. The call is going to be > routed based > on the country of the location you have when you place the call. > That is > going to match the country code that we are using for the > validation. The > PSAP that gets the call may transfer it when the actual fine grained > location is determined, but that is after the call is routed. This > is all > about routing. The entity returning the LbyR, the country code and > the PSAP > URI is the access network. It can keep the information consistent. > > Even if the location were to change between the time the endpoint > got the > data from its access network, and the time the VSP validated, the > VSP isn't > getting updated location. It's just validating that the PSAP URI it's > routing for is valid within the country that it's routing to. > > If a bad guy could seed bad information in the worldwide LoST > database, then > he could put his URI in there, and get calls. I think we have to > accept > this kind of problem. > > We don't actually need the country code, and in fact perhaps we should > consider it a hint. If there is a URI in the database that matches > the > proffered URI, it's valid. The country code just gives us a hint > of where > to look. We might want to recommend that the URIs belong to the > country > where the URI is routed towards (eg psap.london.uk). However, it > works with > any URI. > > Brian > >> -----Original Message----- >> From: Raymond Forbes (CV/ETL) [mailto:raymond.forbes@ericsson.com] >> Sent: Saturday, April 14, 2007 1:14 PM >> To: Brian Rosen; Hannes Tschofenig; Rosen, Brian >> Cc: ecrit@ietf.org >> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to >> doendpoint centric LCP without giving away the store >> >> >> In many areas, especially Mobile Networks Country codes are not >> reliable. >> >> Geneva is a good case. Most calls originated by Non-Swiss mobiles in >> Geneva are actually made on the French networks and so will get the >> Country Code +33 of the base station on the surrounding Mountains, >> the >> French authorities have no jurisdiction to enter Switzerland even >> in the >> case of Emergencies. >> >> True because of Cross-boarder agreement on this friendly boarder >> region >> the French PSAPs will forward the calls to Switz PSAPs. >> >> I am sure that what Brian says may be reasonable from fixed >> access, but >> not from Radio Access, radio has no respect for artificial political >> boundaries. >> >> Regards, >> >> Ray Forbes >> >> BU Networks (CV/ETL/BBC/D) >> Telephone: +44 (0) 24 7656 3106 >> Mobile: +44 (0) 771 851 1361 >> >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: 13 April 2007 17:04 >> To: 'Hannes Tschofenig'; Rosen, Brian >> Cc: geopriv@ietf.org; ecrit@ietf.org >> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to >> doendpoint centric LCP without giving away the store >> >> Huh, I didn't get that. >> >> I'd like to eliminate the country code thing, because otherwise we >> need >> a way to carry it in the SIP Geolocation. However, I don't really >> want >> the VSP having to ask the ASP/ISP for a dereference of any sort, >> and I'd >> like to minimize the work of the ASP/ISP. The notion that the ASP/ >> ISP >> has to help the VSP determine if what it has is a valid PSAP URI >> strikes >> me as a problem. >> >> Now, you may remember WAAAY WAAY back, I strongly suggested that >> the geo >> form of location always include a country code. I suggested this for >> disputed areas. The access network is in a very good position to >> tell >> you how best to interpret which country actually is the on-the-ground >> administrator of the location. If you are connected to an Israeli >> access network, and you ask LoST for a PSAP URI, you probably want an >> Israeli fire brigade. If you are on a Palestinian access network, >> then >> you probably want a different answer. So, having country code in >> a PIDF >> with an otherwise geo location is actually helpful. >> >> The current answer for this is some kind of manual configuration >> of the >> LoST servers so you get the answer you want. While that can work, I >> think something more automatic might work better, and it fixes the >> problem. >> >> Brian >> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: Friday, April 13, 2007 11:26 AM >>> To: Rosen, Brian >>> Cc: geopriv@ietf.org; ecrit@ietf.org >>> Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do >>> endpoint centric LCP without giving away the store >>> >>> Hi Brian, >>> >>> I only described a different way of doing the verification without >>> returning a country code. >>> I also focus on LbyR only rather than LbyV. >>> >>> Ciao >>> Hannes >>> >>> Rosen, Brian wrote: >>>> Hannes >>>> >>>> I am confused by your message. >>>> >>>> The problem you describe, where a VSP is trying to validate that >>>> the >> >>>> Request URI in what is claimed to be an emergency call is a bona >>>> fide PSAP URI seems to be a valid concern. My message described >>>> one >> >>>> way to do this validation when what the VSP received (in a SIP >>>> Geolocation >>>> header) is an LbyR. >>>> >>>> Are you now wondering how you validate when you have an LbyV? I >>>> would think you do the same thing: send the country code (or the >>>> whole >>>> location) and the PSAP URI to LoST and ask if the PSAP URI is >>>> valid. >>>> This does not require any query by the VSP to the ASP/ISP. The VSP >>>> should be able to query its local LoST server and be referred to >>>> the >> >>>> authoritative server for the location it proffers. >>>> >>>> I'd rather not have to have the VSP try to dereference an LbyR, and >>>> if you have an LbyV then you don't even know, necessarily, who the >>>> ASP/ISP is. >>>> >>>> Is there something else I'm missing here? >>>> >>>> Brian >>>> >>>>> -----Original Message----- >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> Sent: Friday, April 13, 2007 10:43 AM >>>>> To: Rosen, Brian >>>>> Cc: geopriv@ietf.org; ecrit@ietf.org >>>>> Subject: Re: [Ecrit] Not-so-grand compromise on how to do endpoint >>>>> >>>> centric >>>> >>>>> LCP without giving away the store >>>>> >>>>> Hi Brian, >>>>> >>>>> thanks for posting this message. >>>>> >>>>> When the end host is provided with LbyV and triggers the LoST >>>>> lookup >>>>> >>>> and >>>> >>>>> routes the call via its VSP then the VSP (in some circumstances*) >>>>> >>>> might >>>> >>>>> want to verify that the PSAP URI in the message indeed corresponds >>>>> to >>>>> >>>> a >>>> >>>>> PSAP. The idea that was mentioned a long time ago already was to >>>>> let >>>>> >>>> the >>>> >>>>> VSP to use the location information for LoST and to compare the >>>>> result with the content of the message. >>>>> >>>>> The main goal here is that the VSP does not need to have a >> "business" >>>>> contract to the ASP/ISP. >>>>> >>>>> Since there is only a location reference that neither the end host >>>>> nor the VSP can dereference it is necessary to enhance the >>>>> existing >> >>>>> procedures a bit (as Brian mentioned). >>>>> >>>>> I see two ways todo so: >>>>> >>>>> a) Enhance LoST >>>>> b) Enhance the dereferencing protocol >>>>> >>>>> In both cases you want to have the LbyR as input and the PSAP URI >>>>> (and potentially the service number) as output. >>>>> >>>>> For (a) you would have to address the LoST query to the LoST >>>>> server >> >>>>> in the ASP/ISP network and the result would be a nomal LoST >> response. >>>>> For (b) you would have todo a dereferencing step with an >>>>> additional >> >>>>> parameter for "verify only". The response would be similar to the >>>>> >>>> lookup >>>> >>>>> by the end host -- just the identity that is being used for the >>>>> lookup would be different. >>>>> >>>>> Both approaches are possible and since the VSP has to support both >>>>> protocols it does not make a big difference which one to use. >>>>> >>>>> In both cases you would have to compare the result of the lookup >>>>> with the content of the message. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> *: It is only necessary when the VSP charges for individual calls >>>>> or >>>>> >>>> for >>>> >>>>> specific calls (with the given call falling into this category). >>>>> >>>>> Rosen, Brian wrote: >>>>> >>>>>> In the Emergency Services SDO Coordination workshop, a familiar >>>>>> discussion took place: how does location get provided for >>>>>> emergency calls? The real issue is revenue. Access networks >>>>>> have >> location. >>>>>> >>>> They >>>> >>>>>> may be willing to (or may be regulated to be required to) provide >>>>>> location for emergency calls. However, they are not willing to >>>>>> give >>>>>> >>>> it >>>> >>>>>> away for free for other uses. The issue with that is how we >>>>>> support calling networks that don't have relationships with >>>>>> access >> >>>>>> networks, i.e. the Skype situation. How is location provided >>>>>> such >> >>>>>> that a >>>>>> >>>> Skype >>>> >>>>>> emergency call can be placed, but the access network can restrict >>>>>> >>>> what >>>> >>>>>> else may be done with the location it provides? >>>>>> >>>>>> We have been wrapped around the axle on this for, dare I say, >> years. >>>>>> >>>>>> So, I think Barbara Stark first described this, and it needs some >>>>>> >>>> work, >>>> >>>>>> but suppose that, as an option, an access network could supply: >>>>>> >>>>>> 1. A reference to location >>>>>> >>>>>> 2. The results of a LoST query on the location value (viz, PSAP >>>>>> URI >>>>>> >>>> and >>>> >>>>>> local dialstring) >>>>>> >>>>>> With this, an endpoint could recognize an emergency call and >>>>>> start >> >>>>>> routing it to the right PSAP. The LIS would agree to dereference >>>>>> >>>> for >>>> >>>>>> PSAPs, but could restrict other uses of location. >>>>>> >>>>>> Hannes points out that we need one more thing: the calling >>>>>> network >>>>>> >>>> has >>>> >>>>>> to be able to validate that the PSAP URI really is a PSAP URI so >>>>>> >>>> that >>>> >>>>>> charging (emergency calls generally are free) is protected. We >>>>>> need >>>>>> >>>> a >>>> >>>>>> mechanism for them to do that. >>>>>> >>>>>> Perhaps we include in the LoST return a country code for a query >>>>>> >>>> with a >>>> >>>>>> geo. We add a new operation to LoST that takes a service, a >>>>>> country code and a PSAP URI and returns yes/no validation ("Yes, >>>>>> that URI is >>>>>> >>>> a >>>> >>>>>> valid URI for that service in that country"). >>>>>> >>>>>> What would we need to do to make this happen? >>>>>> >>>>>> We need extensions to LCPs or some new protocol that returns an >>>>>> LbyR >>>>>> >>>> and >>>> >>>>>> the LoST results. I wonder if this is just more HELD work. >>>>>> >>>>>> We need the PSAP URI validation. >>>>>> >>>>>> Again, this is optional. The access network may well give up an >>>>>> >>>> LbyV. >>>> >>>>>> It may give up an LbyR that it will dereference for the endpoint. >>>>>> >>>> The >>>> >>>>>> access network may have a relationship with the calling network >>>>>> such that the endpoint need not be involved. >>>>>> >>>>>> The PSAP URI validation is actually useful without this idea, >>>>>> >>>> especially >>>> >>>>>> when location is an LbyR. Instead of having to have the calling >>>>>> >>>> network >>>> >>>>>> dereference, and then do a LoST query to validate, it can just do >>>>>> >>>> this >>>> >>>>>> PSAP URI validation. >>>>>> >>>>>> Would this solve our problem? Would access carriers concerned >>>>>> about revenue issues with "giving away" location to it's >>>>>> subscribers be willing to provide LbyR dereferenceable by PSAPs >>>>>> (again remembering >>>>>> >>>> that >>>> >>>>>> the access network are local to the PSAPs) as well as LoST query >>>>>> services to their endpoints? Would this address the concerns >>>>>> raised >>>>>> >>>> by >>>> >>>>>> Deutsche Telecom on this issue? >>>>>> >>>>>> Let me be very clear that I think this is an ugly solution. I >>>>>> think that everyone will be much better off if endpoints knew >>>>>> where they >>>>>> >>>> were, >>>> >>>>>> and apps could take advantage of that. I think we'll get there. >>>>>> I think tying location configuration with the LoST query is a bad >>>>>> >>>> idea. I >>>> >>>>>> think using LbyR for emergency calls is a bad idea. >>>>>> >>>>>> But I can live with it. >>>>>> >>>>>> Brian >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> >>> >>> >>> >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www1.ietf.org/mailman/listinfo/geopriv >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 14:57:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdWNy-0002AT-IB; Mon, 16 Apr 2007 14:57:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdWNy-0002AO-00 for ecrit@ietf.org; Mon, 16 Apr 2007 14:57:10 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdWNv-0004gf-Te for ecrit@ietf.org; Mon, 16 Apr 2007 14:57:09 -0400 Received: from dynamic-acs-24-154-127-115.zoominternet.net ([24.154.127.115] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HdWNG-00054T-6T; Mon, 16 Apr 2007 13:56:26 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] Hiding (partial) locations Date: Mon, 16 Apr 2007 14:57:04 -0400 Message-ID: <087301c78059$07dce430$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceASo1Ou6M2GJGKRyGqiUv78Abk0AADVlMg In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I don't understand this. If, in order to make a route decision, you need street name and house number, but the access network wishes to hide location from non emergency use cases, how the heck do we supply "coarse" location that is any different from full LbyV? You can't restrict the access network from hiding location ONLY IF the PSAP boundary is truly coarse. I'm also not so sure the access networks would be willing to give out coarse location down to, say, city. So, I guess I disagree this is a fair trade-off. In fact, I think it's a non-starter. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, April 16, 2007 1:15 PM > To: Brian Rosen > Cc: 'ECRIT' > Subject: Re: [Ecrit] Hiding (partial) locations > > > On Apr 16, 2007, at 11:19 AM, Brian Rosen wrote: > > > This doesn't work in areas that don't have simple PSAP boundaries. > > Agreed; it would require more precise location in those > jurisdictions. Those do seem to be the exception, however. > > > > > Even in a case where the PSAP serves a city, the boundary of the > > city is > > very often not exactly that of the municipal boundary. > > Again, this would only force an ISP to provide more precise location > information to those relative handful of exception cases. This seems > like a fair trade-off. > > > > > It definitely doesn't work in the U.S. where there are PSAP > > boundaries that > > are one side or the other of the street (even and odd addresses), > > or between > > two house numbers on a street. > > My perception is that PSAP boundaries that don't correspond to > community or county names occur, but only affect a tiny fraction of > the population. > > (Street don't matter. Broad Avenue, for example, traverses a half > dozen communities in northern Bergen County, but each town has its > own PSAP, whose responsibility is defined by the community, not the > street.) > > > > > > Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 15:07:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdWYN-00067J-Ai; Mon, 16 Apr 2007 15:07:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdWYM-000676-7G; Mon, 16 Apr 2007 15:07:54 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdWYL-000886-19; Mon, 16 Apr 2007 15:07:54 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 16 Apr 2007 15:07:52 -0400 id 01588015.4623C988.00005880 In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA03938DAB@crexc41p> References: <413C3E2A-6A05-4CC3-9FA4-6BC4C7F18D70@hxr.us> <7582BC68E4994F4ABF0BD4723975C3FA03938DAB@crexc41p> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8D7DED03-36E4-4632-871B-B49D15C8658E@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCP without giving away the store Date: Mon, 16 Apr 2007 15:07:51 -0400 To: "Stark, Barbara" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: GEOPRIV WG , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 16, 2007, at 1:35 PM, Stark, Barbara wrote: > I asked for it. I believe Otmar asked for it, also. I don't think I > can > get my company to support this architecture if hiding location from > endpoints isn't an option. Barbara, Can we get a clarification? Is there a technical reason not to support this architecture? If so, can we be informed as to what it is? Also, by "this architecture", you are talking about an ECRIT architecture, not a GEOPRIV architecture, correct? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 15:30:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdWty-0006K9-Tx; Mon, 16 Apr 2007 15:30:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdWtx-0006Jr-PU for ecrit@ietf.org; Mon, 16 Apr 2007 15:30:13 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdWtv-0000gP-Ho for ecrit@ietf.org; Mon, 16 Apr 2007 15:30:13 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3GJTw7M004672 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Apr 2007 15:29:58 -0400 (EDT) In-Reply-To: <087301c78059$07dce430$640fa8c0@cis.neustar.com> References: <087301c78059$07dce430$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <95E00DEE-4C3B-4C1A-87C8-9DEB2B189C82@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Hiding (partial) locations Date: Mon, 16 Apr 2007 15:31:12 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 16, 2007, at 2:57 PM, Brian Rosen wrote: > I don't understand this. > > If, in order to make a route decision, you need street name and house > number, but the access network wishes to hide location from non > emergency > use cases, how the heck do we supply "coarse" location that is any > different > from full LbyV? I'm saying that in those exceptional cases, ISPs should indeed give out more information. This does not significantly devalue their precious location information since only a few "lucky" customers receive it, but it makes the system more robust. That seems like a fair trade-off to me. > > You can't restrict the access network from hiding location ONLY IF > the PSAP > boundary is truly coarse. I'm also not so sure the access networks > would be > willing to give out coarse location down to, say, city. > They do today - via the area code and exchange in phone numbers, which are, as far as I know, disclosed to customers. Indeed, DT uses phone numbers as the user identity for their DSL customers, if I remember correctly. (In Germany, each city has its own area code, more or less, so this fits your description of coarse location down to a city pretty well; see http://www.deutschland-adressen.de/ vorwahlen-02.php for an example) I haven't heard that this has caused major revenue loss or heart burn to phone companies. > So, I guess I disagree this is a fair trade-off. In fact, I think > it's a > non-starter. Are you representing carriers? > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 15:59:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdXMb-0000H6-0j; Mon, 16 Apr 2007 15:59:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdXMZ-0000Gw-ID for ecrit@ietf.org; Mon, 16 Apr 2007 15:59:47 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdXMY-0001WX-96 for ecrit@ietf.org; Mon, 16 Apr 2007 15:59:47 -0400 Received: from dynamic-acs-24-154-127-115.zoominternet.net ([24.154.127.115] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HdXLr-0003hn-TQ; Mon, 16 Apr 2007 14:59:04 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] Hiding (partial) locations Date: Mon, 16 Apr 2007 15:59:38 -0400 Message-ID: <091101c78061$c5a73080$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceAXYqp8xQgAsf9TkSgXSDJI5G12gAAOCwg In-Reply-To: <95E00DEE-4C3B-4C1A-87C8-9DEB2B189C82@cs.columbia.edu> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I am not a carrier, and I don't play one on TV. I'll let the carriers speak for themselves. I don't think, based on my understanding, they will agree with you, I'll let them say it direct. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, April 16, 2007 3:31 PM > To: Brian Rosen > Cc: 'ECRIT' > Subject: Re: [Ecrit] Hiding (partial) locations > > > On Apr 16, 2007, at 2:57 PM, Brian Rosen wrote: > > > I don't understand this. > > > > If, in order to make a route decision, you need street name and house > > number, but the access network wishes to hide location from non > > emergency > > use cases, how the heck do we supply "coarse" location that is any > > different > > from full LbyV? > > I'm saying that in those exceptional cases, ISPs should indeed give > out more information. This does not significantly devalue their > precious location information since only a few "lucky" customers > receive it, but it makes the system more robust. That seems like a > fair trade-off to me. > > > > > > You can't restrict the access network from hiding location ONLY IF > > the PSAP > > boundary is truly coarse. I'm also not so sure the access networks > > would be > > willing to give out coarse location down to, say, city. > > > > They do today - via the area code and exchange in phone numbers, > which are, as far as I know, disclosed to customers. Indeed, DT uses > phone numbers as the user identity for their DSL customers, if I > remember correctly. (In Germany, each city has its own area code, > more or less, so this fits your description of coarse location down > to a city pretty well; see http://www.deutschland-adressen.de/ > vorwahlen-02.php for an example) I haven't heard that this has caused > major revenue loss or heart burn to phone companies. > > > > So, I guess I disagree this is a fair trade-off. In fact, I think > > it's a > > non-starter. > > Are you representing carriers? > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 16:14:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdXah-0004W1-OZ; Mon, 16 Apr 2007 16:14:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdXag-0004UH-KZ for ecrit@ietf.org; Mon, 16 Apr 2007 16:14:22 -0400 Received: from mail7.exchange.microsoft.com ([131.107.1.27] helo=mail.exchange.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdXaf-0007g6-A0 for ecrit@ietf.org; Mon, 16 Apr 2007 16:14:22 -0400 Received: from df-bhd-02.exchange.corp.microsoft.com (157.54.71.211) by DF-GWY-07.exchange.corp.microsoft.com (157.54.63.164) with Microsoft SMTP Server (TLS) id 8.1.85.3; Mon, 16 Apr 2007 13:14:20 -0700 Received: from df-beagle-msg.exchange.corp.microsoft.com (157.54.69.136) by df-bhd-02.exchange.corp.microsoft.com (157.54.71.211) with Microsoft SMTP Server (TLS) id 8.1.103.0; Mon, 16 Apr 2007 13:14:20 -0700 Received: from DF-COLLIE-MSG.exchange.corp.microsoft.com ([10.255.255.1]) by DF-BEAGLE-MSG.exchange.corp.microsoft.com ([157.54.69.136]) with mapi; Mon, 16 Apr 2007 13:14:19 -0700 From: Mohammad Vakil To: "ecrit@ietf.org" Date: Mon, 16 Apr 2007 13:14:18 -0700 Thread-Topic: enterprise requirements Thread-Index: AceAVrh6uMPSbzp0QuG3G/vzpCl8FQAADTCwAAM1ZwA= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: [Ecrit] enterprise requirements X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0133959743==" Errors-To: ecrit-bounces@ietf.org --===============0133959743== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_EEE5E031772C2542A67EBD71227CE49C62641405F1DFCOLLIEMSGex_" --_000_EEE5E031772C2542A67EBD71227CE49C62641405F1DFCOLLIEMSGex_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Has there been any work in this wg to address enterprise requirements. E.g.= be able to allow on-premise security to tap E.911 call, know the location = of the caller, or first route it to on-premise security, etc? Thanks, -Mohammad --_000_EEE5E031772C2542A67EBD71227CE49C62641405F1DFCOLLIEMSGex_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Has there been any work in this wg to address enterpri= se requirements. E.g. be able to allow on-premise security to tap E.911 call, = know the location of the caller, or first route it to on-premise security, etc? =

 

Thanks,

-Mohammad

--_000_EEE5E031772C2542A67EBD71227CE49C62641405F1DFCOLLIEMSGex_-- --===============0133959743== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0133959743==-- From ecrit-bounces@ietf.org Mon Apr 16 16:17:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdXeA-0007sX-Am; Mon, 16 Apr 2007 16:17:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdXe9-0007gY-0m for ecrit@ietf.org; Mon, 16 Apr 2007 16:17:57 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdXe7-0000Qj-MV for ecrit@ietf.org; Mon, 16 Apr 2007 16:17:57 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 16 Apr 2007 16:17:55 -0400 X-IronPort-AV: i="4.14,415,1170651600"; d="scan'208,217"; a="118664867:sNHT95665786" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3GKHt3J004211; Mon, 16 Apr 2007 16:17:55 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3GKHoGj006146; Mon, 16 Apr 2007 20:17:55 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 16:17:53 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 16:17:53 -0400 From: "Marc Linsner" To: "'Mohammad Vakil'" , Subject: RE: [Ecrit] enterprise requirements Date: Mon, 16 Apr 2007 16:17:52 -0400 Message-ID: <00e501c78064$50109f20$2d0d0d0a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AceAVrh6uMPSbzp0QuG3G/vzpCl8FQAADTCwAAM1ZwAAABG/4A== X-OriginalArrivalTime: 16 Apr 2007 20:17:53.0371 (UTC) FILETIME=[502F4AB0:01C78064] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4215; t=1176754675; x=1177618675; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20enterprise=20requirements |Sender:=20 |To:=20=22'Mohammad=20Vakil'=22=20, =20; bh=TM8m2Gm/GZeWmdAWJChYpHNSBalVYRe03T503SvEASQ=; b=AttpNj5aJqpLEyhSW6111+ZkMqZXEjM5FH5STqy2dNFUi6yFMz0dVkikcDqiAecYHM5QPzh3 uIKkY76oVmODRx2UvoOuuK14VtJMV67LDnJxFPWSBkTKJA2NaAxpxNgF; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0312387468==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0312387468== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E6_01C78042.C8FEFF20" This is a multi-part message in MIME format. ------=_NextPart_000_00E6_01C78042.C8FEFF20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Has there been any work in this wg to address enterprise requirements. E.g. be able to allow on-premise security to tap E.911 call, know the location of the caller, or first route it to on-premise security, etc? There has been nothing to prevent such from happening. It should be an implementation and/of regulatory choice. -Marc- ------=_NextPart_000_00E6_01C78042.C8FEFF20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 


Has there been any work in this wg to address = enterprise=20 requirements. E.g. be able to allow on-premise security to tap E.911 = call,=20 know the location of the caller, or first route it to on-premise = security,=20 etc? 

 

There has been=20 nothing to prevent such from happening.  It should be an implementation and/of regulatory=20 choice.

 

-Marc-

------=_NextPart_000_00E6_01C78042.C8FEFF20-- --===============0312387468== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0312387468==-- From ecrit-bounces@ietf.org Mon Apr 16 16:31:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdXqm-0008PP-BH; Mon, 16 Apr 2007 16:31:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdXqk-0008Jl-Q9 for ecrit@ietf.org; Mon, 16 Apr 2007 16:30:58 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdXqa-0007Z3-SR for ecrit@ietf.org; Mon, 16 Apr 2007 16:30:58 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HdXpr-0002Av-JX; Mon, 16 Apr 2007 15:30:04 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , "'Mohammad Vakil'" , Subject: RE: [Ecrit] enterprise requirements Date: Mon, 16 Apr 2007 16:30:41 -0400 Message-ID: <093301c78066$1c5e7380$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceAVrh6uMPSbzp0QuG3G/vzpCl8FQAADTCwAAM1ZwAAABG/4AAAWW6A In-Reply-To: <00e501c78064$50109f20$2d0d0d0a@amer.cisco.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ba9b8496764663b12c333825fbf6b3d Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1007176924==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1007176924== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0934_01C78044.954CD380" This is a multi-part message in MIME format. ------=_NextPart_000_0934_01C78044.954CD380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I think the direction we are going will allow all of this. The primary way I think this will evolve in North America is to always send the call direct to 9-1-1, and send a notification to the local enterprise. The enterprise could ask to be included on the call. It would get location with the notification. The 9-1-1 people really believe that first getting to local (campus) security and then to 9-1-1 wastes time. They want the local security on the line in most cases, because they may be able to respond faster. "In an emergency, please contact" mechanisms are a part of what we call NG9-1-1 in North America. However, if the local access network returns a local URI for the local environment, the call will go there. If, in particular, the enterprise is authoritative for the local environment, even mobile carriers could get routing from it, and calls would go to the enterprise. I suspect not many carriers would permit that, but the system could support it. Brian _____ From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Monday, April 16, 2007 4:18 PM To: 'Mohammad Vakil'; ecrit@ietf.org Subject: RE: [Ecrit] enterprise requirements Has there been any work in this wg to address enterprise requirements. E.g. be able to allow on-premise security to tap E.911 call, know the location of the caller, or first route it to on-premise security, etc? There has been nothing to prevent such from happening. It should be an implementation and/of regulatory choice. -Marc- ------=_NextPart_000_0934_01C78044.954CD380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think the direction we are going = will allow all of this.

 

The primary way I think this will = evolve in North America is to always send = the call direct to 9-1-1, and send a notification to the local enterprise.  = The enterprise could ask to be included on the call.  It would get = location with the notification.

 

The 9-1-1 people really believe = that first getting to local (campus) security and then to 9-1-1 wastes time. =  They want the local security on the line in most cases, because they may be = able to respond faster.  “In an emergency, please contact” = mechanisms are a part of what we call NG9-1-1 in North = America.

 

However, if the local access = network returns a local URI for the local environment, the call will go = there.  If, in particular, the enterprise is authoritative for the local = environment, even mobile carriers could get routing from it, and calls would go to the enterprise.  I suspect not many carriers would permit that, but the = system could support it.

 

Brian

 

From: Marc = Linsner [mailto:mlinsner@cisco.com]
Sent: Monday, April 16, = 2007 4:18 PM
To: 'Mohammad Vakil'; ecrit@ietf.org
Subject: RE: [Ecrit] = enterprise requirements

 

 

=

 

Has there been any work in this wg to address enterprise requirements. E.g. = be able to allow on-premise security to tap E.911 call, know the location of the caller, or first route it to on-premise security, = etc? 

=

 

There has been nothing to prevent = such from happening.  It should be an implementation = and/of regulatory choice.

 

-Marc-

------=_NextPart_000_0934_01C78044.954CD380-- --===============1007176924== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1007176924==-- From ecrit-bounces@ietf.org Mon Apr 16 16:54:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdYDn-0001ht-26; Mon, 16 Apr 2007 16:54:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdYDk-0001gH-O5 for ecrit@ietf.org; Mon, 16 Apr 2007 16:54:44 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdYDj-0002l0-8h for ecrit@ietf.org; Mon, 16 Apr 2007 16:54:44 -0400 Received: from ([139.76.131.83]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.175207123; Mon, 16 Apr 2007 16:54:26 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 16 Apr 2007 16:54:26 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 16 Apr 2007 16:54:26 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Hiding (partial) locations Date: Mon, 16 Apr 2007 16:54:24 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA03938E73@crexc41p> In-Reply-To: <087301c78059$07dce430$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Importance: normal Priority: normal Thread-Topic: [Ecrit] Hiding (partial) locations Thread-Index: AceASo1Ou6M2GJGKRyGqiUv78Abk0AADVlMgAAQVCyA= References: <087301c78059$07dce430$640fa8c0@cis.neustar.com> From: "Stark, Barbara" To: "Brian Rosen" , "Henning Schulzrinne" X-OriginalArrivalTime: 16 Apr 2007 20:54:26.0018 (UTC) FILETIME=[6B1AAC20:01C78069] X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The way I envisioned partial locations, from my civic location bias, is to provide city, county, and state information. I'm not aware of cases where a city is sub-divided, so a provider in that situation would have to figure out the information needed to uniquely map for emergency services. But I know that around me, cities (incorporated areas) and counties (unincorporated) have responsibility for services within their borders. In some cases the counties provide service to cities by agreement. City boundaries do meander around, and split streets in half. But I'm not aware of cases where a city has told its residents to call another city for emergency services. Cities are responsible to the citizens within their borders, no matter how twisted those borders might be. The same goes for counties. Barbara -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Monday, April 16, 2007 2:57 PM To: 'Henning Schulzrinne' Cc: 'ECRIT' Subject: RE: [Ecrit] Hiding (partial) locations I don't understand this. If, in order to make a route decision, you need street name and house number, but the access network wishes to hide location from non emergency use cases, how the heck do we supply "coarse" location that is any different from full LbyV? You can't restrict the access network from hiding location ONLY IF the PSAP boundary is truly coarse. I'm also not so sure the access networks would be willing to give out coarse location down to, say, city. So, I guess I disagree this is a fair trade-off. In fact, I think it's a non-starter. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, April 16, 2007 1:15 PM > To: Brian Rosen > Cc: 'ECRIT' > Subject: Re: [Ecrit] Hiding (partial) locations >=20 >=20 > On Apr 16, 2007, at 11:19 AM, Brian Rosen wrote: >=20 > > This doesn't work in areas that don't have simple PSAP boundaries. >=20 > Agreed; it would require more precise location in those jurisdictions. > Those do seem to be the exception, however. >=20 > > > > Even in a case where the PSAP serves a city, the boundary of the=20 > > city is very often not exactly that of the municipal boundary. >=20 > Again, this would only force an ISP to provide more precise location=20 > information to those relative handful of exception cases. This seems=20 > like a fair trade-off. >=20 > > > > It definitely doesn't work in the U.S. where there are PSAP=20 > > boundaries that are one side or the other of the street (even and=20 > > odd addresses), or between two house numbers on a street. >=20 > My perception is that PSAP boundaries that don't correspond to=20 > community or county names occur, but only affect a tiny fraction of=20 > the population. >=20 > (Street don't matter. Broad Avenue, for example, traverses a half=20 > dozen communities in northern Bergen County, but each town has its own > PSAP, whose responsibility is defined by the community, not the > street.) >=20 >=20 > > > > Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA622 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 16 21:53:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdcsP-0003ZC-8j; Mon, 16 Apr 2007 21:53:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdcsN-0003WG-TJ; Mon, 16 Apr 2007 21:52:59 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdcsM-00088w-0R; Mon, 16 Apr 2007 21:52:59 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3H1qndS001815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Apr 2007 21:52:54 -0400 (EDT) In-Reply-To: <080a01c78034$084b5d40$640fa8c0@cis.neustar.com> References: <080a01c78034$084b5d40$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2AA6A71C-E65F-4B9D-9E5A-CDD1F7FA136B@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise [solutions] Date: Mon, 16 Apr 2007 21:52:40 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org [Removing items that we've beaten to death already.] On Apr 16, 2007, at 10:32 AM, Brian Rosen wrote: >> >> - DHCP: Since this is configuration information, adding a lot of >> extra material to DHCP seems ill-advised, particularly since the >> likelihood that this information actually reaches residential users >> is slim. After all, this motivated the whole L7-LCP discussion. This >> also has problems if the URL needs to be changed since the INFORM >> request expiration doesn't seem to be tied to the IP address >> expiration. The number of URLs could be substantial, given that we >> need more than one emergency service URL and that we may need service >> testing URLs. > I think we all believe DHCP is only viable in fixed environments, > but I use > the extreme example of a wired phone connected to a router with a > wireless > access installed in an RV traveling down the highway as a > counterexample. > Such situations exist, therefore it has to work, but they are > unusual, so it > can be less than optimal. > > In this case, we need DHCP responses that return LbyV and country > code and > probably another that returns the LoST data. I fail to see that as > a major > deviation from what DHCP does. The expiration is a red herring. > It won't > change much, and you do get it again at call time. I suspect you'll run into major objections, correctly, from the SIP community for replicating SIP configuration via DHCP. There are possible length issues, as one minor item, as you include a whole list of services. After all, this has to work for emergency and non- emergency LoST services. A bigger architectural issue is that if we do include PSAP URIs in the SIP configuration framework, we now have a fourth source of SIP-related configuration, which needs to be synchronized and conflict-tested. > > The number of URIs is an issue, and we may need to do something > clever about > that. > > However, I do suspect that the access network that does this will > use the L7 > LCP, and I don't think leaving DHCP out of this is a problem. > >> >> - L7 LCP: This subverts a location determination protocol into a >> general configuration protocol. > No it gives you information related to location (the PSAP URI > associated > with this location. By that token, *every* SIP configuration option is related to LCP and we might as well suggest that we replace the SIP configuration framework with LCP. > >> >> - LoST: This seems closest to our existing notion of returning a >> 'default' PSAP if no other resolution is possible. Nothing prevents >> an ISP-provided LoST client from using whatever information it has >> available, such as client IP addresses, to make this information >> better than a national call center. > I think this is a poor choice because it has too many restrictions > on who > operates the LoST server. You would either require that the LoST > server > operator be permitted to dereference, or the access network itself > operates > the LoST server. While that may be the case, it may not be and I > don't see > why we should tie these together. I'm not particularly fond of this choice, but others have proposed making the access provider LoST server "special" in that it can resolve LbyR location. > > >> >> If we go down this route, I think a better solution is to use the on- >> going work for SIP configuration mechanisms. One of the sources of >> configuration information is the local access network, so it has all >> the right properties. After all, emergency calling URLs are not >> fundamentally different from other configuration information for >> special servers. Plus, the configuration protocol will likely have >> mechanism of dealing with conflicting information. The more protocols >> you add, the higher the likelihood that a device will get conflicting >> information, with no deterministic way to resolve it. > Where did you make the leap that the Vonage configuration server knows > anything about the Comcast access network? I suspect you haven't been following this all that closely (which I sympathize with...), but consider taking a look at the configuration framework draft or review the recent SIPPING discussion on this topic. One of the sources of (SIP) configuration information is the access network. Henning > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 02:05:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdgoo-0001cL-8q; Tue, 17 Apr 2007 02:05:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdgon-0001cB-7b for ecrit@ietf.org; Tue, 17 Apr 2007 02:05:33 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hdgom-00060u-Qy for ecrit@ietf.org; Tue, 17 Apr 2007 02:05:33 -0400 Received: (qmail invoked by alias); 17 Apr 2007 06:05:31 -0000 Received: from ip-90-187-46-224.web.vodafone.de (EHLO [90.187.46.224]) [90.187.46.224] by mail.gmx.net (mp056) with SMTP; 17 Apr 2007 08:05:31 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19vzuNRxjNvImqpIrK+Kc6hvc8N9VybhieGfWZdEu CccXH53sa3w8eQ Message-ID: <462463AA.2000609@gmx.net> Date: Tue, 17 Apr 2007 08:05:30 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] LoST civic caching issue References: <2148EBA7-F442-43CE-BB62-5AD0B18BCFE9@cs.columbia.edu> <46210449.3020709@gmx.net> <635EDC7F-A2F3-4D13-B7DE-27E4EC709CC5@cs.columbia.edu> In-Reply-To: <635EDC7F-A2F3-4D13-B7DE-27E4EC709CC5@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Henning, Henning Schulzrinne wrote: > > On Apr 14, 2007, at 12:41 PM, Hannes Tschofenig wrote: > >> Hi Henning, >> >> thanks for raising this issue and it is in fact a difficult problem. >> >> I see two aspects with the "the donut problem", i.e., there is a >> larger service boundary with another service area within (the hole in >> the donut). There are two cases: >> >> * The entity responsible for the larger service area knows that there >> is a donut problem. In this case it would be reasonable to assume >> that this entity could mark the response as "non cachable". For geo >> one would want to express the service area as a donut -- currently we >> don't have a description how to describe such a shape. I now believe >> that we should add something to the PIDF-LO profile draft. > > Polygons can be used to describe structures with holes - you just have > to have the polygon 'wrap around' the hole and overlap in the middle. > It gets tedious for multiple holes. > > Also, it appears that common SQL databases with geo extensions, such > as the popular PostGIS, do not support such complicated shapes. Thus, > it may be a better idea to compose this, as a set of coverage polygons > [we got that] and a set of exceptions. > > This is indeed an alternative. I wonder how long it takes to "standardize" it. We should probably consult with Carl about this aspect. > >> >> * The entity responsible for the larger service area does NOT know >> about a potential donut problem. This case is actually not related to >> civic since it can appear in geo as well. I don't have an easy and >> nice answer for this case. > > That is indeed the hard case. However, I believe it is properly the > responsibility of the exception case to notify the surrounding entity > that it wants to be considered a 'hole'. My perception is that > institutions, such as university campuses, with their own police force > or ambulance corps coordinate with the local civic authorities, rather > than just freelance. I don't know the politics or legalities of > whether, say, the NYPD would allow the Columbia police force to be > declared officially in charge. If all else fails, the local LoST > resolver would have to implement local policy. This is similar to what > happens today: If you dial 911 on a cell phone while on the Columbia > campus, you'll be connected to the NYPD, not campus police. > I think we have to spell-out this case clearly in the document. > Henning Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 02:05:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdgoo-0001cV-Dq; Tue, 17 Apr 2007 02:05:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdgon-0001cG-Q1 for ecrit@ietf.org; Tue, 17 Apr 2007 02:05:33 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hdgom-00060o-Br for ecrit@ietf.org; Tue, 17 Apr 2007 02:05:33 -0400 Received: (qmail invoked by alias); 17 Apr 2007 06:05:29 -0000 Received: from ip-90-187-46-224.web.vodafone.de (EHLO [90.187.46.224]) [90.187.46.224] by mail.gmx.net (mp057) with SMTP; 17 Apr 2007 08:05:29 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19zuS4ZXLpzIQKvhnr6kABt+lChlhtPTEdYW/BSna C96c6Ggm/Ou2tn Message-ID: <462463A6.1030100@gmx.net> Date: Tue, 17 Apr 2007 08:05:26 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Ecrit] Slides for ESW07 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.5 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I got notes from Richard and Roger. I plan to upload them to the webpage once I polished them. Yesterday, I uploaded the slides. Took me more than 3 hours... Ciao Hannes Winterbottom, James wrote: > Hannes, > > I also noticed that a lot of people took very detailed notes. > Perhaps some of these people may be prepared to have their notes > published to the website also? > > Cheers > James > > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Saturday, 14 April 2007 12:21 AM >> To: Spencer Dawkins >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] Slides for ESW07 >> >> I will upload all slides as soon as possible. >> >> >> Spencer Dawkins wrote: >> >>> The website at http://www.emergency-services-coordination.info/2007/ >>> does have some slidesets available, but there are still a lot >>> > missing, > >>> including all the slidesets for the panelists. Is there a chance of >>> seeing the presentations soon? >>> >>> Thanks, >>> >>> Spencer >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 02:10:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdgtL-0005fm-Ke; Tue, 17 Apr 2007 02:10:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdgtJ-0005fS-Nb for ecrit@ietf.org; Tue, 17 Apr 2007 02:10:13 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdgtI-0006fM-S8 for ecrit@ietf.org; Tue, 17 Apr 2007 02:10:13 -0400 Received: (qmail invoked by alias); 17 Apr 2007 06:10:11 -0000 Received: from ip-90-187-46-224.web.vodafone.de (EHLO [90.187.46.224]) [90.187.46.224] by mail.gmx.net (mp047) with SMTP; 17 Apr 2007 08:10:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/1M0tgvpn1qx9/j21/IaOJ30L+MUppm1navDfc1v lpU2xaxBqgkR0F Message-ID: <462464C4.9040708@gmx.net> Date: Tue, 17 Apr 2007 08:10:12 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Brian Rosen References: <02f401c77de5$678e4bb0$640fa8c0@cis.neustar.com> <461FCFE0.10407@gmx.net> In-Reply-To: <461FCFE0.10407@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 442d80051e0361a34f3560325c4a7092 Cc: geopriv@ietf.org, "Rosen, Brian" , ecrit@ietf.org Subject: [Ecrit] Proposal that does not work X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org -- changed subject header Hi Brian, I just wanted to state that my proposal does not work (for deployment reasons) since the VSP would have a hard time figuring out whether the LIS is indeed at an access network. Demanding some relationship between the ASP/ISP and the VSP for authorization would make this solution to work but it would not be deployable anymore and that's what we do not want. Ciao Hannes Hannes Tschofenig wrote: > Hi Brian, > > > sorry that I confused everything. Maybe I am still suffering from a > post-SDO Emergency Service Workshop syndrome: > > Let me describe the procedure in a message sequence: > > Target => LIS: Request LbyR > > Target<= LIS: LbyR, PSAP URI, Service Number > > Target=> VSP-Proxy: SIP message including LbyR, PSAP URI > > VSP-Proxy=> LIS: Check PSAP URI at LbyR > > VSP-Proxy<= LIS: OK or NOT OK (LIS checks whether the location > information behind the LbyR translates to the PSAP URI presented by > the VSP-Proxy) > > DONE > > Note that yo can replace LIS with LoST server in this example. > > Does this make sense to you? > > Ciao > Hannes > > > Brian Rosen wrote: >> Huh, I didn't get that. >> >> I'd like to eliminate the country code thing, because otherwise we >> need a >> way to carry it in the SIP Geolocation. However, I don't really want >> the >> VSP having to ask the ASP/ISP for a dereference of any sort, and I'd >> like to >> minimize the work of the ASP/ISP. The notion that the ASP/ISP has to >> help >> the VSP determine if what it has is a valid PSAP URI strikes me as a >> problem. >> >> Now, you may remember WAAAY WAAY back, I strongly suggested that the geo >> form of location always include a country code. I suggested this for >> disputed areas. The access network is in a very good position to >> tell you >> how best to interpret which country actually is the on-the-ground >> administrator of the location. If you are connected to an Israeli >> access >> network, and you ask LoST for a PSAP URI, you probably want an >> Israeli fire >> brigade. If you are on a Palestinian access network, then you >> probably want >> a different answer. So, having country code in a PIDF with an >> otherwise geo >> location is actually helpful. >> >> The current answer for this is some kind of manual configuration of >> the LoST >> servers so you get the answer you want. While that can work, I think >> something more automatic might work better, and it fixes the problem. >> >> Brian >> >> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: Friday, April 13, 2007 11:26 AM >>> To: Rosen, Brian >>> Cc: geopriv@ietf.org; ecrit@ietf.org >>> Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do >>> endpoint centric LCP without giving away the store >>> >>> Hi Brian, >>> >>> I only described a different way of doing the verification without >>> returning a country code. >>> I also focus on LbyR only rather than LbyV. >>> >>> Ciao >>> Hannes >>> >>> Rosen, Brian wrote: >>> >>>> Hannes >>>> >>>> I am confused by your message. >>>> >>>> The problem you describe, where a VSP is trying to validate that the >>>> Request URI in what is claimed to be an emergency call is a bona fide >>>> PSAP URI seems to be a valid concern. My message described one way to >>>> do this validation when what the VSP received (in a SIP Geolocation >>>> header) is an LbyR. >>>> >>>> Are you now wondering how you validate when you have an LbyV? I would >>>> think you do the same thing: send the country code (or the whole >>>> location) and the PSAP URI to LoST and ask if the PSAP URI is valid. >>>> This does not require any query by the VSP to the ASP/ISP. The VSP >>>> should be able to query its local LoST server and be referred to the >>>> authoritative server for the location it proffers. >>>> >>>> I'd rather not have to have the VSP try to dereference an LbyR, and if >>>> you have an LbyV then you don't even know, necessarily, who the >>>> ASP/ISP >>>> is. >>>> >>>> Is there something else I'm missing here? >>>> >>>> Brian >>>> >>>> >>>>> -----Original Message----- >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> Sent: Friday, April 13, 2007 10:43 AM >>>>> To: Rosen, Brian >>>>> Cc: geopriv@ietf.org; ecrit@ietf.org >>>>> Subject: Re: [Ecrit] Not-so-grand compromise on how to do endpoint >>>>> >>>>> >>>> centric >>>> >>>> >>>>> LCP without giving away the store >>>>> >>>>> Hi Brian, >>>>> >>>>> thanks for posting this message. >>>>> >>>>> When the end host is provided with LbyV and triggers the LoST lookup >>>>> >>>>> >>>> and >>>> >>>> >>>>> routes the call via its VSP then the VSP (in some circumstances*) >>>>> >>>>> >>>> might >>>> >>>> >>>>> want to verify that the PSAP URI in the message indeed corresponds to >>>>> >>>>> >>>> a >>>> >>>> >>>>> PSAP. The idea that was mentioned a long time ago already was to let >>>>> >>>>> >>>> the >>>> >>>> >>>>> VSP to use the location information for LoST and to compare the >>>>> result >>>>> with the content of the message. >>>>> >>>>> The main goal here is that the VSP does not need to have a "business" >>>>> contract to the ASP/ISP. >>>>> >>>>> Since there is only a location reference that neither the end host >>>>> nor >>>>> the VSP can dereference it is necessary to enhance the existing >>>>> procedures a bit (as Brian mentioned). >>>>> >>>>> I see two ways todo so: >>>>> >>>>> a) Enhance LoST >>>>> b) Enhance the dereferencing protocol >>>>> >>>>> In both cases you want to have the LbyR as input and the PSAP URI >>>>> (and >>>>> potentially the service number) as output. >>>>> >>>>> For (a) you would have to address the LoST query to the LoST >>>>> server in >>>>> the ASP/ISP network and the result would be a nomal LoST response. >>>>> For (b) you would have todo a dereferencing step with an additional >>>>> parameter for "verify only". The response would be similar to the >>>>> >>>>> >>>> lookup >>>> >>>> >>>>> by the end host -- just the identity that is being used for the >>>>> lookup >>>>> would be different. >>>>> >>>>> Both approaches are possible and since the VSP has to support both >>>>> protocols it does not make a big difference which one to use. >>>>> >>>>> In both cases you would have to compare the result of the lookup with >>>>> the content of the message. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> *: It is only necessary when the VSP charges for individual calls or >>>>> >>>>> >>>> for >>>> >>>> >>>>> specific calls (with the given call falling into this category). >>>>> >>>>> Rosen, Brian wrote: >>>>> >>>>> >>>>>> In the Emergency Services SDO Coordination workshop, a familiar >>>>>> discussion took place: how does location get provided for emergency >>>>>> calls? The real issue is revenue. Access networks have location. >>>>>> >>>>>> >>>> They >>>> >>>> >>>>>> may be willing to (or may be regulated to be required to) provide >>>>>> location for emergency calls. However, they are not willing to give >>>>>> >>>>>> >>>> it >>>> >>>> >>>>>> away for free for other uses. The issue with that is how we support >>>>>> calling networks that don't have relationships with access networks, >>>>>> i.e. the Skype situation. How is location provided such that a >>>>>> >>>>>> >>>> Skype >>>> >>>> >>>>>> emergency call can be placed, but the access network can restrict >>>>>> >>>>>> >>>> what >>>> >>>> >>>>>> else may be done with the location it provides? >>>>>> >>>>>> We have been wrapped around the axle on this for, dare I say, years. >>>>>> >>>>>> So, I think Barbara Stark first described this, and it needs some >>>>>> >>>>>> >>>> work, >>>> >>>> >>>>>> but suppose that, as an option, an access network could supply: >>>>>> >>>>>> 1. A reference to location >>>>>> >>>>>> 2. The results of a LoST query on the location value (viz, PSAP URI >>>>>> >>>>>> >>>> and >>>> >>>> >>>>>> local dialstring) >>>>>> >>>>>> With this, an endpoint could recognize an emergency call and start >>>>>> routing it to the right PSAP. The LIS would agree to dereference >>>>>> >>>>>> >>>> for >>>> >>>> >>>>>> PSAPs, but could restrict other uses of location. >>>>>> >>>>>> Hannes points out that we need one more thing: the calling network >>>>>> >>>>>> >>>> has >>>> >>>> >>>>>> to be able to validate that the PSAP URI really is a PSAP URI so >>>>>> >>>>>> >>>> that >>>> >>>> >>>>>> charging (emergency calls generally are free) is protected. We need >>>>>> >>>>>> >>>> a >>>> >>>> >>>>>> mechanism for them to do that. >>>>>> >>>>>> Perhaps we include in the LoST return a country code for a query >>>>>> >>>>>> >>>> with a >>>> >>>> >>>>>> geo. We add a new operation to LoST that takes a service, a country >>>>>> code and a PSAP URI and returns yes/no validation ("Yes, that URI is >>>>>> >>>>>> >>>> a >>>> >>>> >>>>>> valid URI for that service in that country"). >>>>>> >>>>>> What would we need to do to make this happen? >>>>>> >>>>>> We need extensions to LCPs or some new protocol that returns an LbyR >>>>>> >>>>>> >>>> and >>>> >>>> >>>>>> the LoST results. I wonder if this is just more HELD work. >>>>>> >>>>>> We need the PSAP URI validation. >>>>>> >>>>>> Again, this is optional. The access network may well give up an >>>>>> >>>>>> >>>> LbyV. >>>> >>>> >>>>>> It may give up an LbyR that it will dereference for the endpoint. >>>>>> >>>>>> >>>> The >>>> >>>> >>>>>> access network may have a relationship with the calling network such >>>>>> that the endpoint need not be involved. >>>>>> >>>>>> The PSAP URI validation is actually useful without this idea, >>>>>> >>>>>> >>>> especially >>>> >>>> >>>>>> when location is an LbyR. Instead of having to have the calling >>>>>> >>>>>> >>>> network >>>> >>>> >>>>>> dereference, and then do a LoST query to validate, it can just do >>>>>> >>>>>> >>>> this >>>> >>>> >>>>>> PSAP URI validation. >>>>>> >>>>>> Would this solve our problem? Would access carriers concerned about >>>>>> revenue issues with "giving away" location to it's subscribers be >>>>>> willing to provide LbyR dereferenceable by PSAPs (again remembering >>>>>> >>>>>> >>>> that >>>> >>>> >>>>>> the access network are local to the PSAPs) as well as LoST query >>>>>> services to their endpoints? Would this address the concerns raised >>>>>> >>>>>> >>>> by >>>> >>>> >>>>>> Deutsche Telecom on this issue? >>>>>> >>>>>> Let me be very clear that I think this is an ugly solution. I think >>>>>> that everyone will be much better off if endpoints knew where they >>>>>> >>>>>> >>>> were, >>>> >>>> >>>>>> and apps could take advantage of that. I think we'll get there. I >>>>>> think tying location configuration with the LoST query is a bad >>>>>> >>>>>> >>>> idea. I >>>> >>>> >>>>>> think using LbyR for emergency calls is a bad idea. >>>>>> >>>>>> But I can live with it. >>>>>> >>>>>> Brian >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> >>>>>> >>> >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www1.ietf.org/mailman/listinfo/geopriv >>> > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 02:11:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdguv-0006Jn-H4; Tue, 17 Apr 2007 02:11:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdguu-0006Ji-E2 for ecrit@ietf.org; Tue, 17 Apr 2007 02:11:52 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdgut-0006lS-6O for ecrit@ietf.org; Tue, 17 Apr 2007 02:11:52 -0400 X-SEF-Processed: 5_0_0_910__2007_04_17_01_18_25 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 17 Apr 2007 01:18:25 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 01:11:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] LoST civic caching issue Date: Tue, 17 Apr 2007 01:11:48 -0500 Message-ID: In-Reply-To: <462463AA.2000609@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST civic caching issue Thread-Index: AceAtmxv3tmft4m1QBuF0NNiwz8FfQAAH8Sw From: "Thomson, Martin" To: "Hannes Tschofenig" , "Henning Schulzrinne" X-OriginalArrivalTime: 17 Apr 2007 06:11:49.0440 (UTC) FILETIME=[48EFE400:01C780B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1728552561==" Errors-To: ecrit-bounces@ietf.org --===============1728552561== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 DQo+ID4gQWxzbywgaXQgYXBwZWFycyB0aGF0IGNvbW1vbiBTUUwgZGF0YWJhc2VzIHdpdGggZ2Vv IGV4dGVuc2lvbnMsIHN1Y2gNCj4gPiBhcyB0aGUgcG9wdWxhciBQb3N0R0lTLCBkbyBub3Qgc3Vw cG9ydCBzdWNoIGNvbXBsaWNhdGVkIHNoYXBlcy4gVGh1cywNCj4gPiBpdCBtYXkgYmUgYSBiZXR0 ZXIgaWRlYSB0byBjb21wb3NlIHRoaXMsIGFzIGEgc2V0IG9mIGNvdmVyYWdlIHBvbHlnb25zDQo+ ID4gW3dlIGdvdCB0aGF0XSBhbmQgYSBzZXQgb2YgZXhjZXB0aW9ucy4NCj4gPg0KPiA+DQo+IA0K PiBUaGlzIGlzIGluZGVlZCBhbiBhbHRlcm5hdGl2ZS4gSSB3b25kZXIgaG93IGxvbmcgaXQgdGFr ZXMgdG8NCj4gInN0YW5kYXJkaXplIiBpdC4NCj4gV2Ugc2hvdWxkIHByb2JhYmx5IGNvbnN1bHQg d2l0aCBDYXJsIGFib3V0IHRoaXMgYXNwZWN0Lg0KPiANCg0KSW4gcmVsYXRpb24gdG8gdGhpcyBw b2ludCAtIEkgdGhpbmsgd2UgaGF2ZSBjb25jbHVkZWQgdGhhdCB0aGlzIGNhbiBiZSBhZGRyZXNz ZWQgd2l0aG91dCBhIGRlcGVuZGVuY3kgb24gZGF0YWJhc2UgaW1wbGVtZW50YXRpb24uICBFeGNl cHRpb25zIHdpbGwgbmVlZCB0byBiZSBoYW5kbGVkIGZvciBjaXZpYyAtIHNvIGEgZ2VuZXJhbCBz b2x1dGlvbiBjYW4gYmUgdXNlZCBmb3IgZWl0aGVyLg0KDQpUYSwNCk1hcnRpbg0KDQpwLnMuIEkg anVzdCBub3RpY2VkIHRoYXQgb25lIG9mIHRoZSBtYWpvciBjb21tZXJjaWFsIHZlbmRvcnMgY2xh aW1zIHN1cHBvcnQgZm9yIGhvbGVzOyB0aGV5IGFsc28gdG91dCBzdXBwb3J0IGZvciBHTUwuDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBm b3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxl Z2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklm IHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIN CmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1 c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0NCg== --===============1728552561== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1728552561==-- From ecrit-bounces@ietf.org Tue Apr 17 02:20:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdh2w-00036w-8s; Tue, 17 Apr 2007 02:20:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdh2v-00033w-6n for ecrit@ietf.org; Tue, 17 Apr 2007 02:20:09 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hdh2u-00087t-ON for ecrit@ietf.org; Tue, 17 Apr 2007 02:20:09 -0400 Received: (qmail invoked by alias); 17 Apr 2007 06:20:06 -0000 Received: from ip-90-187-46-224.web.vodafone.de (EHLO [90.187.46.224]) [90.187.46.224] by mail.gmx.net (mp045) with SMTP; 17 Apr 2007 08:20:06 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18z5MpebTIzUPLMcQu6slMt788upifvNT5RuXtnKz 5rNSS7sovz1M6n Message-ID: <46246715.7080006@gmx.net> Date: Tue, 17 Apr 2007 08:20:05 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCP without giving away the store References: <07f401c7802c$fc202570$640fa8c0@cis.neustar.com> In-Reply-To: <07f401c7802c$fc202570$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: geopriv@ietf.org, "Rosen, Brian" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hence, it suffers from the same problems as the solution I proposed unless you assume a relationship between the VSP and the ISP/ASP. Do you? Ciao Hannes Brian Rosen wrote: > Back from a weekend of no Internet access and lots of email to process: > > The country code is returned from the L7 LCP query when an LbyR is returned. > > The validation is done by the VSP when an emergency call is placed. > > Brian > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Saturday, April 14, 2007 12:02 PM >> To: Rosen, Brian >> Cc: geopriv@ietf.org; ecrit@ietf.org >> Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do >> endpoint centric LCP without giving away the store >> >> Hi Brian, >> >> ~snip~ >> >>> Perhaps we include in the LoST return a country code for a query with a >>> geo. We add a new operation to LoST that takes a service, a country >>> code and a PSAP URI and returns yes/no validation ("Yes, that URI is a >>> valid URI for that service in that country"). >>> >>> >> Please describe when the country code is returned and to whom. >> Who triggers the validation step? >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 02:52:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdhY3-0003SA-A6; Tue, 17 Apr 2007 02:52:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdhY1-0003Rz-R1 for ecrit@ietf.org; Tue, 17 Apr 2007 02:52:17 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdhY1-0007AX-1q for ecrit@ietf.org; Tue, 17 Apr 2007 02:52:17 -0400 Received: (qmail invoked by alias); 17 Apr 2007 06:39:44 -0000 Received: from ip-90-187-46-224.web.vodafone.de (EHLO [90.187.46.224]) [90.187.46.224] by mail.gmx.net (mp019) with SMTP; 17 Apr 2007 08:39:44 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/J0hsHT4vJkkE66g+TfObN8+eUWTGM0pAvwgQkGc f6CCxGI7XbfjhV Message-ID: <46246BAE.3060204@gmx.net> Date: Tue, 17 Apr 2007 08:39:42 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Stark, Barbara" Subject: Re: [Ecrit] Hiding (partial) locations References: <087301c78059$07dce430$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA03938E73@crexc41p> In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA03938E73@crexc41p> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Barbara, could you sell the partial location story within your company (i.e., providing the end host with information about country, state and city)? Ciao Hannes Stark, Barbara wrote: > The way I envisioned partial locations, from my civic location bias, is > to provide city, county, and state information. I'm not aware of cases > where a city is sub-divided, so a provider in that situation would have > to figure out the information needed to uniquely map for emergency > services. > > But I know that around me, cities (incorporated areas) and counties > (unincorporated) have responsibility for services within their borders. > In some cases the counties provide service to cities by agreement. > > City boundaries do meander around, and split streets in half. But I'm > not aware of cases where a city has told its residents to call another > city for emergency services. Cities are responsible to the citizens > within their borders, no matter how twisted those borders might be. The > same goes for counties. > Barbara > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, April 16, 2007 2:57 PM > To: 'Henning Schulzrinne' > Cc: 'ECRIT' > Subject: RE: [Ecrit] Hiding (partial) locations > > I don't understand this. > > If, in order to make a route decision, you need street name and house > number, but the access network wishes to hide location from non > emergency use cases, how the heck do we supply "coarse" location that is > any different from full LbyV? > > You can't restrict the access network from hiding location ONLY IF the > PSAP boundary is truly coarse. I'm also not so sure the access networks > would be willing to give out coarse location down to, say, city. > > So, I guess I disagree this is a fair trade-off. In fact, I think it's > a non-starter. > > Brian > > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Monday, April 16, 2007 1:15 PM >> To: Brian Rosen >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] Hiding (partial) locations >> >> >> On Apr 16, 2007, at 11:19 AM, Brian Rosen wrote: >> >> >>> This doesn't work in areas that don't have simple PSAP boundaries. >>> >> Agreed; it would require more precise location in those jurisdictions. >> > > >> Those do seem to be the exception, however. >> >> >>> Even in a case where the PSAP serves a city, the boundary of the >>> city is very often not exactly that of the municipal boundary. >>> >> Again, this would only force an ISP to provide more precise location >> information to those relative handful of exception cases. This seems >> like a fair trade-off. >> >> >>> It definitely doesn't work in the U.S. where there are PSAP >>> boundaries that are one side or the other of the street (even and >>> odd addresses), or between two house numbers on a street. >>> >> My perception is that PSAP boundaries that don't correspond to >> community or county names occur, but only affect a tiny fraction of >> the population. >> >> (Street don't matter. Broad Avenue, for example, traverses a half >> dozen communities in northern Bergen County, but each town has its own >> > > >> PSAP, whose responsibility is defined by the community, not the >> street.) >> >> >> >>> Brian >>> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > ***** > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 05:11:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdjit-0004KN-Qo; Tue, 17 Apr 2007 05:11:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdjir-0004FY-Vz for ecrit@ietf.org; Tue, 17 Apr 2007 05:11:38 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hdjiq-0005s7-Hd for ecrit@ietf.org; Tue, 17 Apr 2007 05:11:37 -0400 Received: (qmail invoked by alias); 17 Apr 2007 09:11:34 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp021) with SMTP; 17 Apr 2007 11:11:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19CWcV1XdxCDX3eSwToiAWFS+KBfP1mRisaibdkqg 2FRCfoanrYqbiq Message-ID: <46248F45.6030807@gmx.net> Date: Tue, 17 Apr 2007 11:11:33 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) 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-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: [Ecrit] Solution Approaches X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, I would like to share some potential solution approaches with you to deal with the problem of not providing precise location to the end host. I had a chance to discuss these aspects with Henning face-to-face last Friday. Here is a short summary. Note that the goal was to avoid some form of relationship (e.g., business relationship) between the VSP and the ASP/ISP (since this would impose a significant deployment problem). 1) Provide enough location information so that the emergency call can be routed to the correct PSAP. Precise location information would be provided to the PSAP. This approach was already discussed on the list. We need feedback from, for example, Barbara and Laura whether they feel comfortable with this approach. CONSEQUENCE: No changes needed. 2) Provide LbyR + Dial String + PSAP URI to the end host. We could ignore the potential security vulnerabilities if charging does not work on a call-by-call basis. CONSEQUENCE: No changes needed. 3) Provide LbyR + Dial String + PSAP URI to the end host. VSP does a reverse LoST lookup to verify the PSAP URI. CONSEQUENCE: Solution needs to be developed. 4) Provide LbyR + Dial String + PSAP URI to the end host. VSP verifies the PSAP URI with the PSAP URIs being flooded (using the LoST synchronization mechanism). This mechanism is potentially similar to (3) -- details might vary. (3) might use a distributed approach whereas this is brute force. CONSEQUENCE: Solution needs to be developed. 5) Emergency calls are routed via the SIP proxy of the VSP and subsequently via a SIP proxy in the ASP/ISP (redirect mode) SIP Location Conveyance would be used instead of GEOPRIV L7 LCP Assumption: No service level agreement (or business agreement) between VSP and ISP/ASP for this type of SIP emergency message routing required. CONSEQUENCE: No changes needed. Potential problems with SIP Identity possible 6) Emergency calls are routed via the SIP proxy of the VSP and subsequently via a SIP proxy in the ASP/ISP (no redirect mode) SIP Location Conveyance would be used instead of GEOPRIV L7 LCP Assumption: No service level agreement (or business agreement) between VSP and ISP/ASP for this type of SIP emergency message routing required. CONSEQUENCE: No changes needed. 7) Decoupled authentication for SIP message routing Authentication exchange between the end host and the VSP (e.g., TLS to obtain a SAML assertion) Authentication credentials are then added to the SIP emergency message that is routed via the SIP proxy in the VSP/ISP. No service level agreement (or business agreement) between VSP and ISP/ASP needed. CONSEQUENCE: Security extension for this purpose needs to be progressed (already available in draft form) 8) Country Code Routing LIS provides country code to the end host. The end host routes the SIP emergency message via the VSP towards a ESRP that corresponds to the country code. Then, ESRP fetches more detailed location information todo routing within the country. CONSEQUENCE: No changes to the protocol mechanisms. Deployment of ESRPs that work this way are needed. Establishment of ESRP <-> ISP/ASP is more difficult than with PSAP <-> ISP/ASP since there are far more nodes to consider. 9) Assume end hosts have certs for emergency services; routing via SIP proxy in ISP/ASP without traversing VSP in the emergency case. Existing credential infrastructure can be used when utilizing SIP Cert. CONSEQUENCE: Architectural aspects need to be developed. A little bit more difficult to deploy for VSP. Potential issues with callback (to AoR) since end host is not registered with VSP. 10) Routing via SIP proxy in ISP/ASP. Diameter SIP application used to authenticate end host Assumption: No roaming agreement assumed for ISP/ASP <-> VSP Diameter SIP interaction. CONSEQUENCE: Problems with legacy credentials, previously mentioned call back problems since end host is not registered with VSP, Diameter SIP application would need to be profiled. Thoughts? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 07:11:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdlb1-0002Yr-Vm; Tue, 17 Apr 2007 07:11:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdlb1-0002Ym-2E for ecrit@ietf.org; Tue, 17 Apr 2007 07:11:39 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdlaz-00030E-RS for ecrit@ietf.org; Tue, 17 Apr 2007 07:11:39 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3HBBSK2027232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 17 Apr 2007 07:11:31 -0400 (EDT) In-Reply-To: <462463AA.2000609@gmx.net> References: <2148EBA7-F442-43CE-BB62-5AD0B18BCFE9@cs.columbia.edu> <46210449.3020709@gmx.net> <635EDC7F-A2F3-4D13-B7DE-27E4EC709CC5@cs.columbia.edu> <462463AA.2000609@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1C5E1B69-040C-4A74-A8A0-D4087AEDD38E@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST civic caching issue Date: Tue, 17 Apr 2007 07:11:40 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > This is indeed an alternative. I wonder how long it takes to > "standardize" it. > We should probably consult with Carl about this aspect. > This is strictly a LoST syntax issue and just uses existing GML polygons. Thus, we don't have to wait for or depend on OGC, the pdif- lo draft or anything else. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 07:37:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdm06-0005ho-8k; Tue, 17 Apr 2007 07:37:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdm05-0005hj-Cf for ecrit@ietf.org; Tue, 17 Apr 2007 07:37:33 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdm03-0000Y3-5O for ecrit@ietf.org; Tue, 17 Apr 2007 07:37:33 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3HBbRt9029971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 17 Apr 2007 07:37:29 -0400 (EDT) In-Reply-To: <46248F45.6030807@gmx.net> References: <46248F45.6030807@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <218EBEE4-8857-40DE-A774-4CFED54DA2F7@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Solution Approaches Date: Tue, 17 Apr 2007 07:37:34 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > 2) Provide LbyR + Dial String + PSAP URI to the end host. > We could ignore the potential security vulnerabilities if charging > does not work on a call-by-call basis. > > CONSEQUENCE: No changes needed. > We still would need to define how the UA acquires the dial string and PSAP URI. Using LoST would require a change to LoST (resolving LbyR) and a business relationship between the LoST server and the ISP (as well as a way to discover the LoST server that can resolve the LbyR). The alternative is to provide the country code (via LCP/DHCP/...) to the UA and have the dial string be looked up via LoST, with the PSAP configured via SIP configuration. Thus, whichever way it's done, this requires additional protocol work. > 3) Provide LbyR + Dial String + PSAP URI to the end host. VSP does > a reverse LoST lookup to verify the PSAP URI. > > CONSEQUENCE: Solution needs to be developed. This seems to be the same as #2. > > 4) Provide LbyR + Dial String + PSAP URI to the end host. VSP > verifies the PSAP URI with the PSAP URIs being flooded (using the > LoST synchronization mechanism). This mechanism is potentially > similar to (3) -- details might vary. (3) might use a distributed > approach whereas this is brute force. > > CONSEQUENCE: Solution needs to be developed. Again, I'd like to separate the verify-URL-is-PSAP problem from the location problem. These are completely separate issues, as the verification problem only affects the VSP, as it charges for calls. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 08:13:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdmYl-0004IA-AV; Tue, 17 Apr 2007 08:13:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdmYk-0004Hw-JQ for ecrit@ietf.org; Tue, 17 Apr 2007 08:13:22 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdmYi-00008J-5m for ecrit@ietf.org; Tue, 17 Apr 2007 08:13:22 -0400 Received: (qmail invoked by alias); 17 Apr 2007 12:13:19 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp030) with SMTP; 17 Apr 2007 14:13:19 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19eafd7ilZeedOo0E7oLRPRMU0RGJUpTfHT2Khui4 bgfUt38vHvdC1I Message-ID: <4624B9DF.4090105@gmx.net> Date: Tue, 17 Apr 2007 14:13:19 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] LoST civic caching issue References: <2148EBA7-F442-43CE-BB62-5AD0B18BCFE9@cs.columbia.edu> <46210449.3020709@gmx.net> <635EDC7F-A2F3-4D13-B7DE-27E4EC709CC5@cs.columbia.edu> <462463AA.2000609@gmx.net> <1C5E1B69-040C-4A74-A8A0-D4087AEDD38E@cs.columbia.edu> In-Reply-To: <1C5E1B69-040C-4A74-A8A0-D4087AEDD38E@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org OK. There are certainly different ways to come to the same result. We could obviously create a structure, like > [enclosing polygon/civic without hole] > > [exception 1 (geo or civic)] > > > [exception 2 (geo or civic)] > > ... in LoST itself. Maybe this is just the simplest approach to pick. Ciao Hannes Henning Schulzrinne wrote: >> >> This is indeed an alternative. I wonder how long it takes to >> "standardize" it. >> We should probably consult with Carl about this aspect. >> > > This is strictly a LoST syntax issue and just uses existing GML > polygons. Thus, we don't have to wait for or depend on OGC, the > pdif-lo draft or anything else. > > Henning > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 09:08:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdnPx-00056F-Kk; Tue, 17 Apr 2007 09:08:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdnPw-000569-E5 for ecrit@ietf.org; Tue, 17 Apr 2007 09:08:20 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HdnPu-0004PS-0s for ecrit@ietf.org; Tue, 17 Apr 2007 09:08:20 -0400 Received: (qmail invoked by alias); 17 Apr 2007 13:08:17 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp037) with SMTP; 17 Apr 2007 15:08:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX183jdJHVGo3zVXyFmc6Tc6nLHZsnBw2CA5YWxOFQN S16/+vZgV3EldX Message-ID: <4624C6C0.50406@gmx.net> Date: Tue, 17 Apr 2007 15:08:16 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Solution Approaches References: <46248F45.6030807@gmx.net> <218EBEE4-8857-40DE-A774-4CFED54DA2F7@cs.columbia.edu> In-Reply-To: <218EBEE4-8857-40DE-A774-4CFED54DA2F7@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Henning, Henning Schulzrinne wrote: >> 2) Provide LbyR + Dial String + PSAP URI to the end host. >> We could ignore the potential security vulnerabilities if charging >> does not work on a call-by-call basis. >> >> CONSEQUENCE: No changes needed. >> > > We still would need to define how the UA acquires the dial string and > PSAP URI. > Right. I forgot that part. > Using LoST would require a change to LoST (resolving LbyR) and a > business relationship between the LoST server and the ISP (as well as > a way to discover the LoST server that can resolve the LbyR). > > The alternative is to provide the country code (via LCP/DHCP/...) to > the UA and have the dial string be looked up via LoST, with the PSAP > configured via SIP configuration. > > Thus, whichever way it's done, this requires additional protocol work. > Correct. > >> 3) Provide LbyR + Dial String + PSAP URI to the end host. VSP does a >> reverse LoST lookup to verify the PSAP URI. >> >> CONSEQUENCE: Solution needs to be developed. > > This seems to be the same as #2. > No. Item (2) just assumes that we ignore the security vulnerability (fraud) because we believe it is not a real problem. For item (3) we believe it is a problem and provide a solution to it. >> >> 4) Provide LbyR + Dial String + PSAP URI to the end host. VSP >> verifies the PSAP URI with the PSAP URIs being flooded (using the >> LoST synchronization mechanism). This mechanism is potentially >> similar to (3) -- details might vary. (3) might use a distributed >> approach whereas this is brute force. >> >> CONSEQUENCE: Solution needs to be developed. > > Again, I'd like to separate the verify-URL-is-PSAP problem from the > location problem. These are completely separate issues, as the > verification problem only affects the VSP, as it charges for calls. There are many aspects that play an important role for the solution: * location * verification * authentication * deployment considerations * callback aspects All these issues have to be considered and cannot be treated independently. For some of the solutions we solve the PSAP URI verification with call routing through a SIP proxy in the access. This also addresses the location aspect. Ciao Hannes > > > Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 11:36:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdpj1-0004ti-53; Tue, 17 Apr 2007 11:36:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdpiz-0004tM-RH for ecrit@ietf.org; Tue, 17 Apr 2007 11:36:09 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdpiz-0006Xg-Ap for ecrit@ietf.org; Tue, 17 Apr 2007 11:36:09 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 17 Apr 2007 17:36:07 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 17:36:07 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [Ecrit] Solution Approaches Date: Tue, 17 Apr 2007 17:36:07 +0200 Message-Id: <182C63BFBAF131428EA0C16F7FD2191B013584B5@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <46248F45.6030807@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Solution Approaches thread-index: AceA0IFqiJkGNc2wR5azqP4bVp3ysQANZfMg From: "Liess, Laura" To: , X-OriginalArrivalTime: 17 Apr 2007 15:36:07.0377 (UTC) FILETIME=[1DD71410:01C78106] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > -----Urspr=FCngliche Nachricht----- > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Gesendet: Dienstag, 17. April 2007 11:12 > An: ECRIT > Betreff: [Ecrit] Solution Approaches >=20 >=20 > Hi all, >=20 > I would like to share some potential solution approaches with you to=20 > deal with the problem of not providing precise location to=20 > the end host.=20 > I had a chance to discuss these aspects with Henning=20 > face-to-face last=20 > Friday. Here is a short summary. >=20 > Note that the goal was to avoid some form of relationship (e.g.,=20 > business relationship) between the VSP and the ASP/ISP (since=20 > this would=20 > impose a significant deployment problem). >=20 > 1) Provide enough location information so that the emergency=20 > call can be=20 > routed to the correct PSAP. Precise location information would be=20 > provided to the PSAP. > This approach was already discussed on the list. We need=20 > feedback from,=20 > for example, Barbara and Laura whether they feel comfortable=20 > with this=20 > approach. >=20 > CONSEQUENCE: No changes needed. >=20 > 2) Provide LbyR + Dial String + PSAP URI to the end host. > We could ignore the potential security vulnerabilities if=20 > charging does=20 > not work on a call-by-call basis. >=20 > CONSEQUENCE: No changes needed. >=20 > 3) Provide LbyR + Dial String + PSAP URI to the end host. VSP does a=20 > reverse LoST lookup to verify the PSAP URI. >=20 > CONSEQUENCE: Solution needs to be developed. >=20 > 4) Provide LbyR + Dial String + PSAP URI to the end host. VSP=20 > verifies=20 > the PSAP URI with the PSAP URIs being flooded (using the LoST=20 > synchronization mechanism). This mechanism is potentially=20 > similar to (3)=20 > -- details might vary. (3) might use a distributed approach=20 > whereas this=20 > is brute force. >=20 > CONSEQUENCE: Solution needs to be developed. >=20 > 5) Emergency calls are routed via the SIP proxy of the VSP and=20 > subsequently via a SIP proxy in the ASP/ISP (redirect mode) > SIP Location Conveyance would be used instead of GEOPRIV L7 LCP > Assumption: No service level agreement (or business=20 > agreement) between=20 > VSP and ISP/ASP for this type of SIP emergency message=20 > routing required. > =20 > CONSEQUENCE: No changes needed. Potential problems with SIP Identity=20 > possible >=20 > 6) Emergency calls are routed via the SIP proxy of the VSP and=20 > subsequently via a SIP proxy in the ASP/ISP (no redirect=20 > mode) SIP Location Conveyance would be used instead of GEOPRIV L7 LCP > Assumption: No service level agreement (or business=20 > agreement) between=20 > VSP and ISP/ASP for this type of SIP emergency message=20 > routing required. > =20 > CONSEQUENCE: No changes needed. >=20 > 7) Decoupled authentication for SIP message routing=20 > Authentication exchange between the end host and the VSP=20 > (e.g., TLS to=20 > obtain a SAML assertion) > Authentication credentials are then added to the SIP=20 > emergency message=20 > that is routed via the SIP proxy in the VSP/ISP. > No service level agreement (or business agreement) between VSP and=20 > ISP/ASP needed. >=20 > CONSEQUENCE: Security extension for this purpose needs to be=20 > progressed=20 > (already available in draft form) >=20 > 8) Country Code Routing >=20 > LIS provides country code to the end host. The end host=20 > routes the SIP=20 > emergency message via the VSP towards a ESRP that corresponds to the=20 > country code. Then, ESRP fetches more detailed location=20 > information todo=20 > routing within the country. >=20 > CONSEQUENCE: No changes to the protocol mechanisms.=20 > Deployment of ESRPs=20 > that work this way are needed. Establishment of ESRP <->=20 > ISP/ASP is more=20 > difficult than with PSAP <-> ISP/ASP since there are far more=20 > nodes to=20 > consider. >=20 > 9) Assume end hosts have certs for emergency services;=20 > routing via SIP=20 > proxy in ISP/ASP without traversing VSP in the emergency=20 > case. Existing credential infrastructure can be used when=20 > utilizing SIP Cert. >=20 > CONSEQUENCE: Architectural aspects need to be developed. A little bit=20 > more difficult to deploy for VSP. Potential issues with callback (to=20 > AoR) since end host is not registered with VSP. >=20 > 10) Routing via SIP proxy in ISP/ASP. Diameter SIP=20 > application used to=20 > authenticate end host > Assumption: No roaming agreement assumed for ISP/ASP <-> VSP Diameter=20 > SIP interaction. >=20 > CONSEQUENCE: Problems with legacy credentials, previously=20 > mentioned call=20 > back problems since end host is not registered with VSP, Diameter SIP=20 > application would need to be profiled. >=20 > Thoughts? >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 11:36:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdpjS-0004yp-HC; Tue, 17 Apr 2007 11:36:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdpjR-0004yh-3v for ecrit@ietf.org; Tue, 17 Apr 2007 11:36:37 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdpjQ-0006on-J6 for ecrit@ietf.org; Tue, 17 Apr 2007 11:36:37 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 17 Apr 2007 17:36:35 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 17:36:35 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [Ecrit] Solution Approaches Date: Tue, 17 Apr 2007 17:36:35 +0200 Message-Id: <182C63BFBAF131428EA0C16F7FD2191B013584B6@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <46248F45.6030807@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Solution Approaches thread-index: AceA0IFqiJkGNc2wR5azqP4bVp3ysQANaSew From: "Liess, Laura" To: , X-OriginalArrivalTime: 17 Apr 2007 15:36:35.0550 (UTC) FILETIME=[2EA1EFE0:01C78106] X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes, thanks a lot for putting the whole discussion together. =20 I can not give you a feedback which is agreed within DT (the internal = agreement process would probably take some time). But I roughly = discussed the approaches with people working on emergency calling. If we = understood the proposal correctly, we have a strong preference for the = approach number 8), which could work as follows:=20 The ASP/ISP provides to the client the LbyR, the country code (or = country and state codes)and the local EC dial string (at login and = whenever these data change).=20 The client queries LOST and gets back an ESRP URI.=20 When the caller dials the emergency calling number, the client queries = again the ASP/VSP for the LbyR and the country code and LOST query for = the ESRP URI. The VSP routes the call to the ESRP. The ESRP has a shared = secret with the LIS, gets the user location and the correct PSAP and = routes the call with the location info to the PSAP (TLS required). (ESRP = or a local LOST does load balancing for PSAPs an all this stuff). Alternatively, the VSPs SIP proxy can do the LOST queries.=20 Laura > -----Urspr=FCngliche Nachricht----- > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Gesendet: Dienstag, 17. April 2007 11:12 > An: ECRIT > Betreff: [Ecrit] Solution Approaches >=20 >=20 > Hi all, >=20 > I would like to share some potential solution approaches with you to=20 > deal with the problem of not providing precise location to=20 > the end host.=20 > I had a chance to discuss these aspects with Henning=20 > face-to-face last=20 > Friday. Here is a short summary. >=20 > Note that the goal was to avoid some form of relationship (e.g.,=20 > business relationship) between the VSP and the ASP/ISP (since=20 > this would=20 > impose a significant deployment problem). >=20 > 1) Provide enough location information so that the emergency=20 > call can be=20 > routed to the correct PSAP. Precise location information would be=20 > provided to the PSAP. > This approach was already discussed on the list. We need=20 > feedback from,=20 > for example, Barbara and Laura whether they feel comfortable=20 > with this=20 > approach. >=20 > CONSEQUENCE: No changes needed. >=20 > 2) Provide LbyR + Dial String + PSAP URI to the end host. > We could ignore the potential security vulnerabilities if=20 > charging does=20 > not work on a call-by-call basis. >=20 > CONSEQUENCE: No changes needed. >=20 > 3) Provide LbyR + Dial String + PSAP URI to the end host. VSP does a=20 > reverse LoST lookup to verify the PSAP URI. >=20 > CONSEQUENCE: Solution needs to be developed. >=20 > 4) Provide LbyR + Dial String + PSAP URI to the end host. VSP=20 > verifies=20 > the PSAP URI with the PSAP URIs being flooded (using the LoST=20 > synchronization mechanism). This mechanism is potentially=20 > similar to (3)=20 > -- details might vary. (3) might use a distributed approach=20 > whereas this=20 > is brute force. >=20 > CONSEQUENCE: Solution needs to be developed. >=20 > 5) Emergency calls are routed via the SIP proxy of the VSP and=20 > subsequently via a SIP proxy in the ASP/ISP (redirect mode) > SIP Location Conveyance would be used instead of GEOPRIV L7 LCP > Assumption: No service level agreement (or business=20 > agreement) between=20 > VSP and ISP/ASP for this type of SIP emergency message=20 > routing required. > =20 > CONSEQUENCE: No changes needed. Potential problems with SIP Identity=20 > possible >=20 > 6) Emergency calls are routed via the SIP proxy of the VSP and=20 > subsequently via a SIP proxy in the ASP/ISP (no redirect=20 > mode) SIP Location Conveyance would be used instead of GEOPRIV L7 LCP > Assumption: No service level agreement (or business=20 > agreement) between=20 > VSP and ISP/ASP for this type of SIP emergency message=20 > routing required. > =20 > CONSEQUENCE: No changes needed. >=20 > 7) Decoupled authentication for SIP message routing=20 > Authentication exchange between the end host and the VSP=20 > (e.g., TLS to=20 > obtain a SAML assertion) > Authentication credentials are then added to the SIP=20 > emergency message=20 > that is routed via the SIP proxy in the VSP/ISP. > No service level agreement (or business agreement) between VSP and=20 > ISP/ASP needed. >=20 > CONSEQUENCE: Security extension for this purpose needs to be=20 > progressed=20 > (already available in draft form) >=20 > 8) Country Code Routing >=20 > LIS provides country code to the end host. The end host=20 > routes the SIP=20 > emergency message via the VSP towards a ESRP that corresponds to the=20 > country code. Then, ESRP fetches more detailed location=20 > information todo=20 > routing within the country. >=20 > CONSEQUENCE: No changes to the protocol mechanisms.=20 > Deployment of ESRPs=20 > that work this way are needed. Establishment of ESRP <->=20 > ISP/ASP is more=20 > difficult than with PSAP <-> ISP/ASP since there are far more=20 > nodes to=20 > consider. >=20 > 9) Assume end hosts have certs for emergency services;=20 > routing via SIP=20 > proxy in ISP/ASP without traversing VSP in the emergency=20 > case. Existing credential infrastructure can be used when=20 > utilizing SIP Cert. >=20 > CONSEQUENCE: Architectural aspects need to be developed. A little bit=20 > more difficult to deploy for VSP. Potential issues with callback (to=20 > AoR) since end host is not registered with VSP. >=20 > 10) Routing via SIP proxy in ISP/ASP. Diameter SIP=20 > application used to=20 > authenticate end host > Assumption: No roaming agreement assumed for ISP/ASP <-> VSP Diameter=20 > SIP interaction. >=20 > CONSEQUENCE: Problems with legacy credentials, previously=20 > mentioned call=20 > back problems since end host is not registered with VSP, Diameter SIP=20 > application would need to be profiled. >=20 > Thoughts? >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 12:01:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdq71-0000iA-RN; Tue, 17 Apr 2007 12:00:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdq71-0000i5-F1 for ecrit@ietf.org; Tue, 17 Apr 2007 12:00:59 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdq70-0000ky-7X for ecrit@ietf.org; Tue, 17 Apr 2007 12:00:59 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3HG0uju017803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 17 Apr 2007 12:00:56 -0400 (EDT) In-Reply-To: <4624C6C0.50406@gmx.net> References: <46248F45.6030807@gmx.net> <218EBEE4-8857-40DE-A774-4CFED54DA2F7@cs.columbia.edu> <4624C6C0.50406@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Solution Approaches Date: Tue, 17 Apr 2007 12:02:09 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > No. Item (2) just assumes that we ignore the security vulnerability > (fraud) because we believe it is not a real problem. > For item (3) we believe it is a problem and provide a solution to it. I'd like to keep these two issues separate. Fraud impacts the VSP, not the ISP (unless you're talking about unauthenticated network access). Location hiding impacts the ISP, but not the VSP. > >>> >>> 4) Provide LbyR + Dial String + PSAP URI to the end host. VSP >>> verifies the PSAP URI with the PSAP URIs being flooded (using the >>> LoST synchronization mechanism). This mechanism is potentially >>> similar to (3) -- details might vary. (3) might use a distributed >>> approach whereas this is brute force. >>> >>> CONSEQUENCE: Solution needs to be developed. >> >> Again, I'd like to separate the verify-URL-is-PSAP problem from >> the location problem. These are completely separate issues, as the >> verification problem only affects the VSP, as it charges for calls. > There are many aspects that play an important role for the solution: > * location > * verification > * authentication > * deployment considerations > * callback aspects > > All these issues have to be considered and cannot be treated > independently. For some of the solutions we solve the PSAP URI > verification with call routing through a SIP proxy in the access. > This also addresses the location aspect. I agree that some solutions don't need to worry about URL verification, namely if the mapping and routing are done by parties trusted by the VSP (or ISP). Also, if you have an ESP, you might insert location there, thus avoiding the location hiding problem. But these are two special cases. However, in general, they are independent problems and they don't always appear in the same system. For example, DT seems to care about not revealing location data, but they don't care if a VSP gets cheated. > > > Ciao > Hannes > >> >> >> Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 13:00:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdr2d-0005y8-EC; Tue, 17 Apr 2007 13:00:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdr2c-0005y2-80 for ecrit@ietf.org; Tue, 17 Apr 2007 13:00:30 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdr2c-0004qx-0t for ecrit@ietf.org; Tue, 17 Apr 2007 13:00:30 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3HH0ILD013401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 17 Apr 2007 13:00:19 -0400 (EDT) In-Reply-To: <182C63BFBAF131428EA0C16F7FD2191B013584B6@S4DE8PSAAGM.mitte.t-com.de> References: <182C63BFBAF131428EA0C16F7FD2191B013584B6@S4DE8PSAAGM.mitte.t-com.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: AW: [Ecrit] Solution Approaches Date: Tue, 17 Apr 2007 13:01:31 -0400 To: "Liess, Laura" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 17, 2007, at 11:36 AM, Liess, Laura wrote: > > I can not give you a feedback which is agreed within DT (the > internal agreement process would probably take some time). But I > roughly discussed the approaches with people working on emergency > calling. If we understood the proposal correctly, we have a strong > preference for the approach number 8), which could work as follows: > > The ASP/ISP provides to the client the LbyR, the country code (or > country and state codes)and the local EC dial string (at login and > whenever these data change). Once you have the country code (via some location mechanism, including L7 or DHCP), LoST will provide you with the dial string, so I see no need for yet another mechanism to convey that. > The client queries LOST and gets back an ESRP URI. > When the caller dials the emergency calling number, the client > queries again the ASP/VSP for the LbyR and the country code and > LOST query for the ESRP URI. The VSP routes the call to the ESRP. > The ESRP has a shared secret with the LIS, gets the user location > and the correct PSAP and routes the call with the location info to > the PSAP (TLS required). (ESRP or a local LOST does load balancing > for PSAPs an all this stuff). > > Alternatively, the VSPs SIP proxy can do the LOST queries. While this works in some way, this has clear drawbacks and consequences: - It requires a national ESRP. - It does not allow the caller to verify, even roughly, its current address, thus making misroutes more likely. I suppose you could fix this by having the test function for emergency dialing read back the address to the caller, assuming that doesn't violate the ISPs strict confidentiality requirements on the customer's own address. > >> >> 8) Country Code Routing >> >> LIS provides country code to the end host. The end host >> routes the SIP >> emergency message via the VSP towards a ESRP that corresponds to the >> country code. Then, ESRP fetches more detailed location >> information todo >> routing within the country. >> >> CONSEQUENCE: No changes to the protocol mechanisms. >> Deployment of ESRPs >> that work this way are needed. Establishment of ESRP <-> >> ISP/ASP is more >> difficult than with PSAP <-> ISP/ASP since there are far more >> nodes to >> consider. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 14:58:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdst4-0000pE-Q8; Tue, 17 Apr 2007 14:58:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdst4-0000p6-DX for ecrit@ietf.org; Tue, 17 Apr 2007 14:58:46 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdst4-0003z9-0R for ecrit@ietf.org; Tue, 17 Apr 2007 14:58:46 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 17 Apr 2007 14:58:43 -0400 id 015881AA.462518E3.00002809 In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA03938DB4@crexc41p> References: <004f01c78035$638a0480$2d0d0d0a@amer.cisco.com> <081c01c78039$4de4f410$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA03938DB4@crexc41p> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1E4C64C1-5219-47E2-9428-57C0B9834EA0@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: A slightly different take: RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Date: Tue, 17 Apr 2007 14:58:43 -0400 To: ECRIT X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: Barbara Stark X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I agree with Barbara on this point. A VSP can do policing after the fact. But there is a tweak on this proposal I'd like to make. An ISP or access network wishing to keep a target's location information out of the hands of the target can do the following (and this is similar to Brian's original message in this thread): The access network provides to the client the following: 1) A reference to location. 2) The results of a LoST query, which are a PSAP URI, a LoST service boundary reference (instead of a country code), and the local dialstring. So that the target does not get the location information, I believe this could all be implemented in the LIS without need for protocol change. Essentially, the LIS knows something special about the target that enables it to know the target's location information. Why can't it also know not to all the target to dereference the LbyR? So the target can convey the LbyR to the PSAP and the PSAP can dereference it, the target can never dereference it because the LIS knows who the target is and knows that it is not authorized to have it. Doing so is a matter of local policy in the LIS. Also, I'd like to be clear on something. None of this or any of the alternatives discussed will preclude a network operator from deploying the standard architecture, right? -andy On Apr 16, 2007, at 1:41 PM, Stark, Barbara wrote: > If I were a VSP concerned with this problem, I wouldn't make the > validation sequential in the process. I would go ahead and route the > call and do the validation simultaneously. If it's really invalid, > then > I charge for it, or maybe shut down the call. That depends on how > big of > a problem this is. I would also probably cache valid emergency > URIs, so > I can do the validation locally. But that's just me. > Barbara > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, April 16, 2007 11:10 AM > To: 'Marc Linsner' > Cc: ecrit@ietf.org > Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to > doendpointcentric LCPwithout giving away the store > > Right, 2 seconds. > > You query LCP (that is local). Someone (endpoint or access network) > queries LoST (that is not real local, but not very far). You route. > The VSP validates (normally local, but may need a referral which could > be to anywhere, that may take time). > > Then it rings. > > The dereference happens after the ring starts. > > Brian > >> -----Original Message----- >> From: Marc Linsner [mailto:mlinsner@cisco.com] >> Sent: Monday, April 16, 2007 10:42 AM >> To: 'Brian Rosen' >> Cc: ecrit@ietf.org >> Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to >> do endpointcentric LCPwithout giving away the store >> >> Brian, >> >>> >>> You update the data at call time. You only use stale data if that >>> doesn't work. >> >> Remind us of the goal for 'send button to ringback' timing, >> please? 2 > >> seconds? >> >> -Marc- > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > ***** > > The information transmitted is intended only for the person or > entity to which it is addressed and may contain confidential, > proprietary, and/or privileged material. Any review, > retransmission, dissemination or other use of, or taking of any > action in reliance upon this information by persons or entities > other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material > from all computers. GA624 > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 15:15:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdt8r-0007te-1r; Tue, 17 Apr 2007 15:15:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdt8q-0007tW-0N for ecrit@ietf.org; Tue, 17 Apr 2007 15:15:04 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdt8p-0001Jf-6l for ecrit@ietf.org; Tue, 17 Apr 2007 15:15:03 -0400 Received: from ([139.76.131.83]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.20359895; Tue, 17 Apr 2007 15:14:47 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 17 Apr 2007 15:14:47 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 17 Apr 2007 15:14:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Hiding (partial) locations Date: Tue, 17 Apr 2007 15:14:46 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA03B0F1C8@crexc41p> In-Reply-To: <46246BAE.3060204@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Hiding (partial) locations Thread-Index: AceAvP2p7wmB5ky/SB+XIjPEkcmaFgAZ1YHQ References: <087301c78059$07dce430$640fa8c0@cis.neustar.com><7582BC68E4994F4ABF0BD4723975C3FA03938E73@crexc41p> <46246BAE.3060204@gmx.net> From: "Stark, Barbara" To: "Hannes Tschofenig" X-OriginalArrivalTime: 17 Apr 2007 19:14:46.0958 (UTC) FILETIME=[A9B844E0:01C78124] X-Spam-Score: 0.1 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I might be able to sell partial location, but I've heard from others who don't think that would be acceptable. And it doesn't get the dial strings to the device. The overall solution must get the dial strings to the device. Barbara=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Tuesday, April 17, 2007 2:40 AM To: Stark, Barbara Cc: ECRIT Subject: Re: [Ecrit] Hiding (partial) locations Barbara, could you sell the partial location story within your company (i.e., providing the end host with information about country, state and city)? Ciao Hannes Stark, Barbara wrote: > The way I envisioned partial locations, from my civic location bias,=20 > is to provide city, county, and state information. I'm not aware of=20 > cases where a city is sub-divided, so a provider in that situation=20 > would have to figure out the information needed to uniquely map for=20 > emergency services. > > But I know that around me, cities (incorporated areas) and counties > (unincorporated) have responsibility for services within their borders. > In some cases the counties provide service to cities by agreement. > > City boundaries do meander around, and split streets in half. But I'm=20 > not aware of cases where a city has told its residents to call another > city for emergency services. Cities are responsible to the citizens=20 > within their borders, no matter how twisted those borders might be.=20 > The same goes for counties. > Barbara > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, April 16, 2007 2:57 PM > To: 'Henning Schulzrinne' > Cc: 'ECRIT' > Subject: RE: [Ecrit] Hiding (partial) locations > > I don't understand this. > > If, in order to make a route decision, you need street name and house=20 > number, but the access network wishes to hide location from non=20 > emergency use cases, how the heck do we supply "coarse" location that=20 > is any different from full LbyV? > > You can't restrict the access network from hiding location ONLY IF the > PSAP boundary is truly coarse. I'm also not so sure the access=20 > networks would be willing to give out coarse location down to, say, city. > > So, I guess I disagree this is a fair trade-off. In fact, I think=20 > it's a non-starter. > > Brian > > =20 >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Monday, April 16, 2007 1:15 PM >> To: Brian Rosen >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] Hiding (partial) locations >> >> >> On Apr 16, 2007, at 11:19 AM, Brian Rosen wrote: >> >> =20 >>> This doesn't work in areas that don't have simple PSAP boundaries. >>> =20 >> Agreed; it would require more precise location in those jurisdictions. >> =20 > > =20 >> Those do seem to be the exception, however. >> >> =20 >>> Even in a case where the PSAP serves a city, the boundary of the=20 >>> city is very often not exactly that of the municipal boundary. >>> =20 >> Again, this would only force an ISP to provide more precise location=20 >> information to those relative handful of exception cases. This seems=20 >> like a fair trade-off. >> >> =20 >>> It definitely doesn't work in the U.S. where there are PSAP=20 >>> boundaries that are one side or the other of the street (even and=20 >>> odd addresses), or between two house numbers on a street. >>> =20 >> My perception is that PSAP boundaries that don't correspond to=20 >> community or county names occur, but only affect a tiny fraction of=20 >> the population. >> >> (Street don't matter. Broad Avenue, for example, traverses a half=20 >> dozen communities in northern Bergen County, but each town has its=20 >> own >> =20 > > =20 >> PSAP, whose responsibility is defined by the community, not the >> street.) >> >> >> =20 >>> Brian >>> =20 > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > ***** > > The information transmitted is intended only for the person or entity=20 > to which it is addressed and may contain confidential, proprietary,=20 > and/or privileged material. Any review, retransmission, dissemination=20 > or other use of, or taking of any action in reliance upon this=20 > information by persons or entities other than the intended recipient=20 > is prohibited. If you received this in error, please contact the=20 > sender and delete the material from all computers. GA622 > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 15:22:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdtFy-0004on-H2; Tue, 17 Apr 2007 15:22:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdtFx-0004oh-CV for ecrit@ietf.org; Tue, 17 Apr 2007 15:22:25 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdtFw-00035k-3W for ecrit@ietf.org; Tue, 17 Apr 2007 15:22:25 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3HJMKuC013080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 17 Apr 2007 15:22:21 -0400 (EDT) In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA03B0F1C8@crexc41p> References: <087301c78059$07dce430$640fa8c0@cis.neustar.com><7582BC68E4994F4ABF0BD4723975C3FA03938E73@crexc41p> <46246BAE.3060204@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA03B0F1C8@crexc41p> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Hiding (partial) locations Date: Tue, 17 Apr 2007 15:23:33 -0400 To: "Stark, Barbara" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org With partial location, LoST works just fine, i.e., can produce dial strings for the device. On Apr 17, 2007, at 3:14 PM, Stark, Barbara wrote: > I might be able to sell partial location, but I've heard from > others who > don't think that would be acceptable. And it doesn't get the dial > strings to the device. The overall solution must get the dial > strings to > the device. > Barbara > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 15:51:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdtiR-0004UU-N9; Tue, 17 Apr 2007 15:51:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdtiP-0004Ln-1p for ecrit@ietf.org; Tue, 17 Apr 2007 15:51:49 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdtiK-0002Z7-Ez for ecrit@ietf.org; Tue, 17 Apr 2007 15:51:49 -0400 Received: from ([139.76.131.87]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.20365056; Tue, 17 Apr 2007 15:51:22 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 17 Apr 2007 15:51:22 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 17 Apr 2007 15:51:22 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 17 Apr 2007 15:51:21 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA03B0F1F2@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Phonebcp comments thread-index: AceBKcW36FqDb+IBQnaOU3mPstkO7A== From: "Stark, Barbara" To: "ECRIT" X-OriginalArrivalTime: 17 Apr 2007 19:51:22.0161 (UTC) FILETIME=[C629AA10:01C78129] X-Spam-Score: 0.7 (/) X-Scan-Signature: 4de5d7f989d6c039c8b887f1940f36ab Subject: [Ecrit] Phonebcp comments X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1250653694==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1250653694== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78129.C642DA71" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78129.C642DA71 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are my phonebcp comments. Barbara 1. Section 2, numbered and bullet lists " 1. Device connects to access network, and obtains initial location 2. User dials visited location's emergency number " It would be nice if the steps in the bullet list of event could more closely map back to the steps in the numbered list. The LoST steps aren't currently reflected in the numbered list. I recommend the following changes to items 1 and 2 in the numbered list: 1. Device connects to access network and obtains initial location, emergency dialstring(s), and emergency urns with their associated PSAP URIs. 2. User dials an emergency dialstring. 2. Section 4.4=20 "It is essential for the location to be determined BEFORE any VPN tunnels are established. It is equally essential that this location information is *not* overwritten by any process engaged from establishing a VPN connection. In other words, the established VPN to Chicago from the device in Dallas MUST NOT overwrite the Dallas location for any reason especially an emergency call." I would prefer to see "MUST" verbiage, instead of "essential". I also think the MUST NOT verbiage needs to be applied to the more generic statement and not the example. I recommend rewording to: "Devices MUST determine location BEFORE establishing any VPN tunnels. This location information MUST NOT be overwritten by any process engaged over the VPN connection. In other words, the established VPN to Chicago from the device in Dallas must not overwrite the Dallas location for any reason, especially when there is an emergency call." 3. Section 4.5 Converting to PIDF-LO - Isn't there an IETF reference for how to do this for a DHCP-delivered location? 4. Section 5 In 2nd paragraph "Note:": "PSAPs prefer devices to use their local emergency call dialstring." I'd like to see this sentence deleted, since it seems out of context here, and this topic is described much better in the 8th paragraph of this section. 5. Section 6.1 Items 1 and 2, requirement to use sips There's a large movement to use IPsec instead of TLS, in many VSP arrangements. I'd like to see this be something like "The device MUST either specify a sips URI [RFC32361] or establish an IPsec [reference] session to use for SIP transport, unless neither a TLS nor an IPsec session can be established." 6. Section 6.5 Paragraph after the numbered list, "...the device should ring..." - would this be better as "...the device SHOULD "ring"..." [given that some devices vibrate or flash lights] 7. Section 6.5 Last paragraph - where did "5 minutes" come from? Is this a recommended default, or is it exactly the right number? If it's a default, what would be a reasonable range for configuration? 8. Section 6.6 Disabling of features I would prefer to see the first sentence reworded to be more explicit, like "When a calling device and/or service determines an emergency call is being made or is in progress, it SHOULD disable outgoing call features such as:" 9. Section 6.6 Disabling of features I'm not sure we should disable 3-way calling (which may require use of flash hook). I think there could be a case where someone has called their best friend to ask for help, instead of 9-1-1, and the friend then calls 9-1-1 and bridges the two legs together. If the first leg is lost, then the friend may need to try to re-establish the first leg, because the PSAP may not have the necessary info. 10. Section 6.6 Disabling of features Call waiting - what's the difference between "Call Waiting" in the first bullet list and "Call Waiting (all kinds)" in the second list? That is, why is "all kinds" specified for one and not the other? 11. Section 6.6 The disabling of VAD is easy t o overlook in section 8. I think that this is really important to do. Could we call out disabling of VAD specifically in section 6.6? 12. Section 9.1 Testing Mechanism 2nd paragraph, "For the latter, the PSAP SHOULD return location-by-value even if the original location delivered with the test was by-reference." I completely disagree. I believe the appropriate requirement is "For the latter, the PSAP MUST NOT return location-by-value when the original location delivered with the test was by-reference." 13. Section 9.1 4th paragraph. I'm not comfortable with the potential frequency of testing that these requirements would cause. Is there some way a PSAP can specifically tell an end device to not query this same PSAP uri in a given (in the SIP response) amount of time? To make the exception in the 5th paragraph work with the requirements in the 4th paragraph, I'd prefer words in the 4th paragraph like "...after a disconnect and subsequent change in IP address, unless this is due to a reboot." 14. Section 10.1 1st paragraph, last sentence, "The [L7 LCP] is not limited and TLS SHOULD be used to protect location privacy." It's possible to implement theL7 LCP in an environment and manner so that it is limited. I would prefer for this to read "The [L7 LCP] may not be limited and TLS SHOULD be used to protect location privacy." 15. Section 10.1 2nd paragraph, last sentence, "[L7 LCP] SHOULD use DIGEST authentication (or better) to identify the LIS." I don't understand this statement completely. What information does the LIS use to authenticate itself with the device? 16. Section 10.1 Last paragraph - what if IPsec is being used between the end device and its VSP? =20 --------------------------------------------------------------- Items I haven't been able to fully research yet (which means I may have comments on these): 1. Section 4.5 and 10.1, implications of using RFC 3118 to prevent against spoofing by the DHCP server. 2. Section 8, implications of requiring support for RFC 3428 and 3920 for instant messaging. 3. Section 10.2, implications of requiring use of P-Asserted-Identity or SIP Identity by calling networks. ---------------------------------------------------------------- Editorial Comments 1. Section 5, 3rd paragraph, "(i.e. 911 in North America)" - should this be an "e.g."? 2. Section 5, 4th paragraph, "responder specific" - hyphenate this to be "responder-specific" 3. Section 5, 6th paragraph, "This mapping be SHOULD performed..." -> "This mapping SHOULD be performed..." 4. Section 5, 7th paragraph, needs period "." At end of paragraph. 5. Section 5, 9th paragraph, "If that devices roam..." -> "If that device roams..." 6. Section 6.1, item 3, NOTE, "unintialized" -> "uninitialized" 7. Section 6.1, item 4, needs a period "." at the end. 8. Section 6.1, item 8, needs a period "." at the end. 9. Section 6.1, item 11, capitalize first word "If" 10. Section 6.2, item 1, "If it finds it it MUST" -> "If it finds this dialstring, it MUST" 11. Section 6.2, item 3, "...and the message is routing is now to be done..." -- delete the first "is" 12. Section 6.3, 1st paragraph, "...the previous mapping may no longer valid." -> ...the previous mapping may no longer be valid." 13. Section 6.3, 3rd paragraph, "geo reported" -> "geo-reported" 14. Section 7, 3rd paragraph, I recommend "...MAY reINVITE the endpoint and the 200 OK..." -> "MAY reINVITE the endpoint; in this case, the 200OK..." 15. Section 7, 3rd paragraph, "For calls send..." - > "For calls sent..." 16. Section 8, 2nd paragraph, need period after "...wideband codecs in the offer" 17. Section 10.2, last paragraph, "...endpoint SHOULD..." -> "...endpoints SHOULD..." ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA623 ------_=_NextPart_001_01C78129.C642DA71 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phonebcp comments

Here are my phonebcp comments.
Barbara

1. Section 2, numbered and bullet = lists
“ 1. Device connects to access = network, and obtains initial location
  2. User dials visited = location’s emergency number  “

It would be nice if the steps in the = bullet list of event could more closely map back to the steps in the = numbered list. The LoST steps aren’t currently reflected in the = numbered list. I recommend the following changes to items 1 and 2 in the = numbered list:

    1. Device connects to access network and = obtains initial location, emergency dialstring(s), and emergency urns = with their associated PSAP URIs.
    2. User dials an emergency = dialstring.


2. Section 4.4
“It is essential for the = location to be determined BEFORE any VPN tunnels are established. It is = equally essential that this location information is *not* overwritten by = any process engaged from establishing a VPN connection. In other words, = the established VPN to Chicago from the device in Dallas MUST NOT = overwrite the Dallas location for any reason especially an emergency = call.”

I would prefer to see = “MUST” verbiage, instead of “essential”. I also = think the MUST NOT verbiage needs to be applied to the more generic = statement and not the example. I recommend rewording to:

“Devices MUST determine location = BEFORE establishing any VPN tunnels. This location information MUST NOT = be overwritten by any process engaged over the VPN connection. In other = words, the established VPN to Chicago from the device in Dallas must not = overwrite the Dallas location for any reason, especially when there is = an emergency call.”

3. Section 4.5
Converting to PIDF-LO – = Isn’t there an IETF reference for how to do this for a = DHCP-delivered location?

4. Section 5
In 2nd paragraph = “Note:”: “PSAPs prefer devices to use their local = emergency call dialstring.”

I’d like to see this sentence = deleted, since it seems out of context here, and this topic is described = much better in the 8th paragraph of this section.

5. Section 6.1
Items 1 and 2, requirement to use = sips
There’s a large movement to use = IPsec instead of TLS, in many VSP arrangements. I’d like to see = this be something like “The device MUST either specify a sips URI = [RFC32361] or establish an IPsec [reference] session to use for SIP = transport, unless neither a TLS nor an IPsec session can be = established.”

6. Section 6.5
Paragraph after the numbered list, = “…the device should ring…” – would this be = better as “…the device SHOULD = “ring”…” [given that some devices vibrate or = flash lights]

7. Section 6.5
Last paragraph – where did = “5 minutes” come from? Is this a recommended default, or is = it exactly the right number? If it’s a default, what would be a = reasonable range for configuration?

8. Section 6.6 Disabling of = features
I would prefer to see the first = sentence reworded to be more explicit, like “When a calling device = and/or service determines an emergency call is being made or is in = progress, it SHOULD disable outgoing call features such = as:”

9. Section 6.6 Disabling of = features
I’m not sure we should disable = 3-way calling (which may require use of flash hook). I think there could = be a case where someone has called their best friend to ask for help, = instead of 9-1-1, and the friend then calls 9-1-1 and bridges the two = legs together. If the first leg is lost, then the friend may need to try = to re-establish the first leg, because the PSAP may not have the = necessary info.

10. Section 6.6 Disabling of = features
Call waiting – what’s the = difference between “Call Waiting” in the first bullet list = and “Call Waiting (all kinds)” in the second list? That is, = why is “all kinds” specified for one and not the = other?

11. Section 6.6
The disabling of VAD is easy t o = overlook in section 8. I think that this is really important to do. = Could we call out disabling of VAD specifically in section = 6.6?

12. Section 9.1 Testing = Mechanism
2nd paragraph, “For = the latter, the PSAP SHOULD return location-by-value even if the = original location delivered with the test was by-reference.” I = completely disagree. I believe the appropriate requirement is “For = the latter, the PSAP MUST NOT return location-by-value when the original = location delivered with the test was by-reference.”

13. Section 9.1
4th paragraph.
I’m not comfortable with the = potential frequency of testing that these requirements would cause. Is = there some way a PSAP can specifically tell an end device to not query = this same PSAP uri in a given (in the SIP response) amount of = time?

To make the exception in the = 5th paragraph work with the requirements in the = 4th paragraph, I’d prefer words in the 4th = paragraph like “…after a disconnect and subsequent change in = IP address, unless this is due to a reboot.”

14. Section 10.1
1st paragraph, last = sentence, “The [L7 LCP] is not limited and TLS SHOULD be used to = protect location privacy.”
It’s possible to implement = theL7 LCP in an environment and manner so that it is limited. I would = prefer for this to read “The [L7 LCP] may not be limited and TLS = SHOULD be used to protect location privacy.”

15. Section 10.1
2nd paragraph, last = sentence, “[L7 LCP] SHOULD use DIGEST authentication (or better) = to identify the LIS.” I don’t understand this statement = completely. What information does the LIS use to authenticate itself = with the device?

16. Section 10.1
Last paragraph – what if IPsec = is being used between the end device and its VSP?
 
---------------------------------------------------------------
Items I haven’t been able to = fully research yet (which means I may have comments on these):

    1. Section 4.5 and 10.1, implications of = using RFC 3118 to prevent against spoofing by the DHCP = server.
    2. Section 8, implications of requiring = support for RFC 3428 and 3920 for instant messaging.
    3. Section 10.2, implications of = requiring use of P-Asserted-Identity or SIP Identity by calling = networks.

----------------------------------------------------------------
Editorial Comments

    1. Section 5, 3rd paragraph, = “(i.e. 911 in North America)” – should this be an = “e.g.”?
    2. Section 5, 4th paragraph, = “responder specific” – hyphenate this to be = “responder-specific”
    3. Section 5, 6th paragraph, = “This mapping be SHOULD performed…” -> “This = mapping SHOULD be performed…”
    4. Section 5, 7th paragraph, = needs period “.” At end of paragraph.
    5. Section 5, 9th paragraph, = “If that devices roam…” -> “If that device = roams…”
    6. Section 6.1, item 3, NOTE, = “unintialized” -> “uninitialized”
    7. Section 6.1, item 4, needs a period = “.” at the end.
    8. Section 6.1, item 8, needs a period = “.” at the end.
    9. Section 6.1, item 11, capitalize = first word “If”
    10. Section 6.2, item 1, “If it = finds it it MUST” -> “If it finds this dialstring, it = MUST”
    11. Section 6.2, item 3, = “…and the message is routing is now to be done…” = -- delete the first "is"
    12. Section 6.3, 1st = paragraph, “…the previous mapping may no longer = valid.” -> …the previous mapping may no longer be = valid.”
    13. Section 6.3, 3rd = paragraph, “geo reported” -> = “geo-reported”
    14. Section 7, 3rd paragraph, = I recommend “…MAY reINVITE the endpoint and the 200 = OK…” -> “MAY reINVITE the endpoint; in this case, = the 200OK…”
    15. Section 7, 3rd paragraph, = “For calls send…” - > “For calls = sent…”
    16. Section 8, 2nd paragraph, = need period after “…wideband codecs in the = offer”
    17. Section 10.2, last paragraph, = “…endpoint SHOULD…” -> = “…endpoints SHOULD…”

*****

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

 ------_=_NextPart_001_01C78129.C642DA71-- --===============1250653694== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1250653694==-- From ecrit-bounces@ietf.org Tue Apr 17 16:03:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdttR-00088d-U0; Tue, 17 Apr 2007 16:03:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdttQ-00081Q-FA; Tue, 17 Apr 2007 16:03:12 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdttP-0005a0-43; Tue, 17 Apr 2007 16:03:12 -0400 Received: from dynamic-acs-24-154-127-115.zoominternet.net ([24.154.127.115] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HdttO-0006Yc-4M; Tue, 17 Apr 2007 15:03:10 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpoint centric LCP without giving away the store Date: Tue, 17 Apr 2007 16:03:07 -0400 Message-ID: <0a6701c7812b$6c921bc0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceAuFdHC4RIh1ZXSxGMgvUps/g6egAWcIow In-Reply-To: <46246715.7080006@gmx.net> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: geopriv@ietf.org, "Rosen, Brian" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org No, I don't. I assume that the LoST server the VSP consults to validate contains the same URIs that the LoST server used by the access network LIS to determine the URI. The endpoint passes a URI to its VSP and claims it's a bona fide PSAP URI from LoST. As long as that URI is in the LoST server (directly or via a referral) that the VSP uses, validation is possible. If the attacker can insert bogus data into the global LoST database, then we couldn't detect it, but that is not threat here. The access network and the endpoint can collude all they want, but unless the LoST server the VSP uses has bad data, it can determine if the PSAP URI is a genuine PSAP URI. No relationship between the VSP and the access network is needed. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, April 17, 2007 2:20 AM > To: Brian Rosen > Cc: Rosen, Brian; geopriv@ietf.org; ecrit@ietf.org > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do > endpoint centric LCP without giving away the store > > Hence, it suffers from the same problems as the solution I proposed > unless you assume a relationship between the VSP and the ISP/ASP. > Do you? > > Ciao > Hannes > > > Brian Rosen wrote: > > Back from a weekend of no Internet access and lots of email to process: > > > > The country code is returned from the L7 LCP query when an LbyR is > returned. > > > > The validation is done by the VSP when an emergency call is placed. > > > > Brian > > > > > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: Saturday, April 14, 2007 12:02 PM > >> To: Rosen, Brian > >> Cc: geopriv@ietf.org; ecrit@ietf.org > >> Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do > >> endpoint centric LCP without giving away the store > >> > >> Hi Brian, > >> > >> ~snip~ > >> > >>> Perhaps we include in the LoST return a country code for a query with > a > >>> geo. We add a new operation to LoST that takes a service, a country > >>> code and a PSAP URI and returns yes/no validation ("Yes, that URI is a > >>> valid URI for that service in that country"). > >>> > >>> > >> Please describe when the country code is returned and to whom. > >> Who triggers the validation step? > >> > >> Ciao > >> Hannes > >> > >> > >> _______________________________________________ > >> Geopriv mailing list > >> Geopriv@ietf.org > >> https://www1.ietf.org/mailman/listinfo/geopriv > >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 16:04:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdtuR-0000DH-0z; Tue, 17 Apr 2007 16:04:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdtuP-0000CD-Dz; Tue, 17 Apr 2007 16:04:13 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdtuP-0005lq-3e; Tue, 17 Apr 2007 16:04:13 -0400 Received: from ([139.76.131.79]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.175292796; Tue, 17 Apr 2007 16:04:04 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 17 Apr 2007 16:04:04 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 17 Apr 2007 16:04:04 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 17 Apr 2007 16:04:03 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA03B0F1FC@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: End device requirements (to be contributed to the DSL Forum) thread-index: AceBK4vQu+ynS7mwTe2fJyOlfmpu9A== From: "Stark, Barbara" To: "GEOPRIV WG" ,"ECRIT" X-OriginalArrivalTime: 17 Apr 2007 20:04:04.0154 (UTC) FILETIME=[8C5891A0:01C7812B] X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Subject: [Ecrit] End device requirements (to be contributed to the DSL Forum) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0915156114==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0915156114== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7812B.8C59EF7D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7812B.8C59EF7D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been writing a draft set of requirements for end devices to support location acquisition and LoST and such. This document goes into much greater detail than phonebcp, specifying default behavior and order of protocols. If anyone would like to see a copy of this before I submit it to the DSL Forum (expected date of May 7), please let me know. I'll be happy to send you a copy, and am willing to consider all comments. Once it goes to the DSL Forum, I assume it will be accepted as a DSLF work item. If any organizations would like to liaise on this topic with the DSL Forum (to see the current version of the work, and to provide comments), let me know that, as well. There's no need to "Reply All" on this -- just reply directly to me, if you have an interest. Thanks, Barbara ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA621 ------_=_NextPart_001_01C7812B.8C59EF7D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable End device requirements (to be contributed to the DSL = Forum)

I have been writing a draft set of = requirements for end devices to support location acquisition and LoST = and such. This document goes into much greater detail than phonebcp, = specifying default behavior and order of protocols. If anyone would like = to see a copy of this before I submit it to the DSL Forum (expected date = of May 7), please let me know. I'll be happy to send you a copy, and am = willing to consider all comments.

Once it goes to the DSL Forum, I assume = it will be accepted as a DSLF work item. If any organizations would like = to liaise on this topic with the DSL Forum (to see the current version = of the work, and to provide comments), let me know that, as = well.

There's no need to "Reply = All" on this -- just reply directly to me, if you have an interest. = Thanks,
Barbara

*****

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

 ------_=_NextPart_001_01C7812B.8C59EF7D-- --===============0915156114== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0915156114==-- From ecrit-bounces@ietf.org Tue Apr 17 16:33:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HduMc-0007N3-BV; Tue, 17 Apr 2007 16:33:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HduMb-0007Mv-C3 for ecrit@ietf.org; Tue, 17 Apr 2007 16:33:21 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HduMZ-0006QM-S2 for ecrit@ietf.org; Tue, 17 Apr 2007 16:33:21 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HduMX-0004Zi-WD; Tue, 17 Apr 2007 15:33:18 -0500 From: "Brian Rosen" To: "'Liess, Laura'" , , Subject: RE: [Ecrit] Solution Approaches Date: Tue, 17 Apr 2007 16:33:14 -0400 Message-ID: <0c6d01c7812f$a1c692e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceA0IFqiJkGNc2wR5azqP4bVp3ysQANaSewAAn+sgA= In-Reply-To: <182C63BFBAF131428EA0C16F7FD2191B013584B6@S4DE8PSAAGM.mitte.t-com.de> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Laura Although this might work for an access network operator who has a single ESRP per country, can you accept the fact that it will not be feasible = to have that situation in a country like the U.S., which has 6000 PSAPs and millions of emergency calls, and without a strong national organization = that could MANDATE that every PSAP use one ESRP? In such a circumstance, = your proposed solution fails. Your description requires one ESRP per = country. I suspect this will also fail in countries that have a small number of PSAPs, but also lack a strong national emergency service infrastructure. = I am familiar with several countries who could not reasonably organize = such a thing. In many countries, emergency services is VERY local, and = assuming a single operator of critical infrastructure would be very difficult to create. I'd also like to point out that your proposed solution REQUIRES an ESRP. While I think ESRPs are quite useful, I think requiring that there must = be an entity in the signaling path between the PSAP and the VSP is not such = a good idea. I think solutions that permit an arbitrary PSAP URI to come from LoST routing of the complete address is probably going to be necessary. Brian > -----Original Message----- > From: Liess, Laura [mailto:Laura.Liess@t-systems.com] > Sent: Tuesday, April 17, 2007 11:37 AM > To: Hannes.Tschofenig@gmx.net; ecrit@ietf.org > Subject: AW: [Ecrit] Solution Approaches >=20 >=20 > Hannes, >=20 > thanks a lot for putting the whole discussion together. >=20 > I can not give you a feedback which is agreed within DT (the internal > agreement process would probably take some time). But I roughly = discussed > the approaches with people working on emergency calling. If we = understood > the proposal correctly, we have a strong preference for the approach > number 8), which could work as follows: >=20 > The ASP/ISP provides to the client the LbyR, the country code (or = country > and state codes)and the local EC dial string (at login and whenever = these > data change). > The client queries LOST and gets back an ESRP URI. > When the caller dials the emergency calling number, the client queries > again the ASP/VSP for the LbyR and the country code and LOST query for = the > ESRP URI. The VSP routes the call to the ESRP. The ESRP has a shared > secret with the LIS, gets the user location and the correct PSAP and > routes the call with the location info to the PSAP (TLS required). = (ESRP > or a local LOST does load balancing for PSAPs an all this stuff). >=20 > Alternatively, the VSPs SIP proxy can do the LOST queries. >=20 >=20 > Laura >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Gesendet: Dienstag, 17. April 2007 11:12 > > An: ECRIT > > Betreff: [Ecrit] Solution Approaches > > > > > > Hi all, > > > > I would like to share some potential solution approaches with you to > > deal with the problem of not providing precise location to > > the end host. > > I had a chance to discuss these aspects with Henning > > face-to-face last > > Friday. Here is a short summary. > > > > Note that the goal was to avoid some form of relationship (e.g., > > business relationship) between the VSP and the ASP/ISP (since > > this would > > impose a significant deployment problem). > > > > 1) Provide enough location information so that the emergency > > call can be > > routed to the correct PSAP. Precise location information would be > > provided to the PSAP. > > This approach was already discussed on the list. We need > > feedback from, > > for example, Barbara and Laura whether they feel comfortable > > with this > > approach. > > > > CONSEQUENCE: No changes needed. > > > > 2) Provide LbyR + Dial String + PSAP URI to the end host. > > We could ignore the potential security vulnerabilities if > > charging does > > not work on a call-by-call basis. > > > > CONSEQUENCE: No changes needed. > > > > 3) Provide LbyR + Dial String + PSAP URI to the end host. VSP does a > > reverse LoST lookup to verify the PSAP URI. > > > > CONSEQUENCE: Solution needs to be developed. > > > > 4) Provide LbyR + Dial String + PSAP URI to the end host. VSP > > verifies > > the PSAP URI with the PSAP URIs being flooded (using the LoST > > synchronization mechanism). This mechanism is potentially > > similar to (3) > > -- details might vary. (3) might use a distributed approach > > whereas this > > is brute force. > > > > CONSEQUENCE: Solution needs to be developed. > > > > 5) Emergency calls are routed via the SIP proxy of the VSP and > > subsequently via a SIP proxy in the ASP/ISP (redirect mode) > > SIP Location Conveyance would be used instead of GEOPRIV L7 LCP > > Assumption: No service level agreement (or business > > agreement) between > > VSP and ISP/ASP for this type of SIP emergency message > > routing required. > > > > CONSEQUENCE: No changes needed. Potential problems with SIP Identity > > possible > > > > 6) Emergency calls are routed via the SIP proxy of the VSP and > > subsequently via a SIP proxy in the ASP/ISP (no redirect > > mode) SIP Location Conveyance would be used instead of GEOPRIV L7 = LCP > > Assumption: No service level agreement (or business > > agreement) between > > VSP and ISP/ASP for this type of SIP emergency message > > routing required. > > > > CONSEQUENCE: No changes needed. > > > > 7) Decoupled authentication for SIP message routing > > Authentication exchange between the end host and the VSP > > (e.g., TLS to > > obtain a SAML assertion) > > Authentication credentials are then added to the SIP > > emergency message > > that is routed via the SIP proxy in the VSP/ISP. > > No service level agreement (or business agreement) between VSP and > > ISP/ASP needed. > > > > CONSEQUENCE: Security extension for this purpose needs to be > > progressed > > (already available in draft form) > > > > 8) Country Code Routing > > > > LIS provides country code to the end host. The end host > > routes the SIP > > emergency message via the VSP towards a ESRP that corresponds to the > > country code. Then, ESRP fetches more detailed location > > information todo > > routing within the country. > > > > CONSEQUENCE: No changes to the protocol mechanisms. > > Deployment of ESRPs > > that work this way are needed. Establishment of ESRP <-> > > ISP/ASP is more > > difficult than with PSAP <-> ISP/ASP since there are far more > > nodes to > > consider. > > > > 9) Assume end hosts have certs for emergency services; > > routing via SIP > > proxy in ISP/ASP without traversing VSP in the emergency > > case. Existing credential infrastructure can be used when > > utilizing SIP Cert. > > > > CONSEQUENCE: Architectural aspects need to be developed. A little = bit > > more difficult to deploy for VSP. Potential issues with callback (to > > AoR) since end host is not registered with VSP. > > > > 10) Routing via SIP proxy in ISP/ASP. Diameter SIP > > application used to > > authenticate end host > > Assumption: No roaming agreement assumed for ISP/ASP <-> VSP = Diameter > > SIP interaction. > > > > CONSEQUENCE: Problems with legacy credentials, previously > > mentioned call > > back problems since end host is not registered with VSP, Diameter = SIP > > application would need to be profiled. > > > > Thoughts? > > > > Ciao > > Hannes > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 16:49:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HducO-0006NW-Pa; Tue, 17 Apr 2007 16:49:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HducO-0006NQ-9Y for ecrit@ietf.org; Tue, 17 Apr 2007 16:49:40 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HducM-0003do-R1 for ecrit@ietf.org; Tue, 17 Apr 2007 16:49:40 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HducL-0007AZ-Ee; Tue, 17 Apr 2007 15:49:37 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'ECRIT'" Subject: RE: A slightly different take: RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Date: Tue, 17 Apr 2007 16:49:34 -0400 Message-ID: <0c8a01c78131$e9a58d30$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceBIm2KnFm3+kImRPadTJ24KkJRVAADenMA In-Reply-To: <1E4C64C1-5219-47E2-9428-57C0B9834EA0@hxr.us> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: 'Barbara Stark' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'm not sure I understand the boundary. Since no one downstream of the LIS can get the location other than the PSAP, the boundary can't be used for its normal purpose. I think that the protocol changes Henning refers to are changes that allow an endpoint to query with the LCPs identifiers and get back the LbyR, PSAP URI, dial string and boundary/country code. Neither LoST nor any LCP has that operation so far. I don't think we need anything special to prohibit the endpoint from dereferencing; it would not have the credentials to dereference, which the PSAP would. I will note that if a LIS insists on credentials, and some kind of failure occurs and the PSAP is not able to get location, the LIS operator takes on some significant liability. And, I definitely agree that an access network can supply an LbyV or an LbyR that it will dereference for anyone and everything still works the way we originally envisioned. I even imagine some kind of tiered service the access provider offers has which allows a subscriber to have pay-per-dip dereferencing (for him or anyone else) or buck-a-month all-you-can-eat dereferencing. The LIS can hand out different kinds of references and keep them straight itself. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Tuesday, April 17, 2007 2:59 PM > To: ECRIT > Cc: Brian Rosen; Barbara Stark; Marc Linsner > Subject: A slightly different take: RE: [Ecrit] Not-so-grand compromise on > how to doendpointcentric LCPwithout giving away the store > > I agree with Barbara on this point. A VSP can do policing after the > fact. > > But there is a tweak on this proposal I'd like to make. > > An ISP or access network wishing to keep a target's location > information out of the hands of the target can do the following (and > this is similar to Brian's original message in this thread): The > access network provides to the client the following: > > 1) A reference to location. > 2) The results of a LoST query, which are a PSAP URI, a LoST service > boundary reference (instead of a country code), and the local > dialstring. > > So that the target does not get the location information, I believe > this could all be implemented in the LIS without need for protocol > change. Essentially, the LIS knows something special about the > target that enables it to know the target's location information. > Why can't it also know not to all the target to dereference the > LbyR? So the target can convey the LbyR to the PSAP and the PSAP can > dereference it, the target can never dereference it because the LIS > knows who the target is and knows that it is not authorized to have > it. Doing so is a matter of local policy in the LIS. > > Also, I'd like to be clear on something. None of this or any of the > alternatives discussed will preclude a network operator from > deploying the standard architecture, right? > > -andy > > On Apr 16, 2007, at 1:41 PM, Stark, Barbara wrote: > > > If I were a VSP concerned with this problem, I wouldn't make the > > validation sequential in the process. I would go ahead and route the > > call and do the validation simultaneously. If it's really invalid, > > then > > I charge for it, or maybe shut down the call. That depends on how > > big of > > a problem this is. I would also probably cache valid emergency > > URIs, so > > I can do the validation locally. But that's just me. > > Barbara > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Monday, April 16, 2007 11:10 AM > > To: 'Marc Linsner' > > Cc: ecrit@ietf.org > > Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to > > doendpointcentric LCPwithout giving away the store > > > > Right, 2 seconds. > > > > You query LCP (that is local). Someone (endpoint or access network) > > queries LoST (that is not real local, but not very far). You route. > > The VSP validates (normally local, but may need a referral which could > > be to anywhere, that may take time). > > > > Then it rings. > > > > The dereference happens after the ring starts. > > > > Brian > > > >> -----Original Message----- > >> From: Marc Linsner [mailto:mlinsner@cisco.com] > >> Sent: Monday, April 16, 2007 10:42 AM > >> To: 'Brian Rosen' > >> Cc: ecrit@ietf.org > >> Subject: RE: [Geopriv] RE: [Ecrit] Not-so-grand compromise on how to > >> do endpointcentric LCPwithout giving away the store > >> > >> Brian, > >> > >>> > >>> You update the data at call time. You only use stale data if that > >>> doesn't work. > >> > >> Remind us of the goal for 'send button to ringback' timing, > >> please? 2 > > > >> seconds? > >> > >> -Marc- > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > ***** > > > > The information transmitted is intended only for the person or > > entity to which it is addressed and may contain confidential, > > proprietary, and/or privileged material. Any review, > > retransmission, dissemination or other use of, or taking of any > > action in reliance upon this information by persons or entities > > other than the intended recipient is prohibited. If you received > > this in error, please contact the sender and delete the material > > from all computers. GA624 > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 16:51:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdueE-0007mj-P4; Tue, 17 Apr 2007 16:51:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdueD-0007md-F5 for ecrit@ietf.org; Tue, 17 Apr 2007 16:51:33 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdueB-00046c-Vq for ecrit@ietf.org; Tue, 17 Apr 2007 16:51:33 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 17 Apr 2007 22:51:30 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 22:51:01 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: AW: [Ecrit] Solution Approaches Date: Tue, 17 Apr 2007 22:51:00 +0200 Message-Id: <182C63BFBAF131428EA0C16F7FD2191B013584B8@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Ecrit] Solution Approaches thread-index: AceBEjlcF268R4Z5QByaCKK/usgcSgAFVL9g From: "Liess, Laura" To: X-OriginalArrivalTime: 17 Apr 2007 20:51:01.0306 (UTC) FILETIME=[1B7FD9A0:01C78132] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org =20 > -----Urspr=FCngliche Nachricht----- > Von: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Gesendet: Dienstag, 17. April 2007 19:02 > An: Liess, Laura > Cc: ecrit@ietf.org > Betreff: Re: AW: [Ecrit] Solution Approaches > > > > The ASP/ISP provides to the client the LbyR, the country code (or > > country and state codes)and the local EC dial string (at login and =20 > > whenever these data change). >=20 > Once you have the country code (via some location mechanism, =20 > including L7 or DHCP), LoST will provide you with the dial=20 > string, so =20 > I see no need for yet another mechanism to convey that. This is true and LOST is definitively the best way to get the dial = string. I overlooked it.=20 >=20 >=20 > > The client queries LOST and gets back an ESRP URI. > > When the caller dials the emergency calling number, the client > > queries again the ASP/VSP for the LbyR and the country code and =20 > > LOST query for the ESRP URI. The VSP routes the call to the ESRP. =20 > > The ESRP has a shared secret with the LIS, gets the user location =20 > > and the correct PSAP and routes the call with the location info to =20 > > the PSAP (TLS required). (ESRP or a local LOST does load balancing =20 > > for PSAPs an all this stuff). > > > > Alternatively, the VSPs SIP proxy can do the LOST queries. >=20 > While this works in some way, this has clear drawbacks and=20 > consequences: >=20 > - It requires a national ESRP. >=20 > - It does not allow the caller to verify, even roughly, its current =20 > address, thus making misroutes more likely. I suppose you could fix =20 > this by having the test function for emergency dialing read back the =20 > address to the caller, assuming that doesn't violate the ISPs strict =20 > confidentiality requirements on the customer's own address. I am aware of the drawbacks. But I didn't see any other solution we can = live with. Not only because of the location hiding issue, but also = because providing a more accurate location information for every end = device requires much more performant mechanisms than those we have = today. Today, the location information is provided by the system only = for emergency calls where the caller is not able to talk to the call = taker. Providing it at every login is another order of magnitude. I was = told that replacing the current mechanism requires changes in the whole = backend infrastructure and would cost millions. Nobody is willing to = spend so much money without a business case. >=20 >=20 >=20 > > > >> > >> 8) Country Code Routing > >> > >> LIS provides country code to the end host. The end host routes the=20 > >> SIP emergency message via the VSP towards a ESRP that=20 > corresponds to=20 > >> the country code. Then, ESRP fetches more detailed location > >> information todo > >> routing within the country. > >> > >> CONSEQUENCE: No changes to the protocol mechanisms. Deployment of=20 > >> ESRPs that work this way are needed. Establishment of ESRP <-> > >> ISP/ASP is more > >> difficult than with PSAP <-> ISP/ASP since there are far more > >> nodes to > >> consider. >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 17:02:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HduoN-0005o5-FA; Tue, 17 Apr 2007 17:02:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HduoL-0005nC-BD for ecrit@ietf.org; Tue, 17 Apr 2007 17:02:01 -0400 Received: from srvexchg2.positron.qc.ca ([199.84.137.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HduoI-0008Qk-P9 for ecrit@ietf.org; Tue, 17 Apr 2007 17:02:01 -0400 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 Subject: RE: [Ecrit] Solution Approaches Date: Tue, 17 Apr 2007 17:01:57 -0400 Message-ID: <567E04E775EA244A9F7E4140EAEB4111047255AA@srvexchg2.positron.qc.ca> In-Reply-To: <0c6d01c7812f$a1c692e0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Solution Approaches Thread-Index: AceA0IFqiJkGNc2wR5azqP4bVp3ysQANaSewAAn+sgAAAJJr8A== References: <182C63BFBAF131428EA0C16F7FD2191B013584B6@S4DE8PSAAGM.mitte.t-com.de> <0c6d01c7812f$a1c692e0$640fa8c0@cis.neustar.com> From: "Desjardins, Pierre" To: "Brian Rosen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: ecrit@ietf.org, "Liess, Laura" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, In your response below you state "requiring that there must be an entity = in the signaling path between the PSAP and the VSP is not such a good = idea". This seems to be contradictary to what we have been envisioning for NENA = i3 -- where ESINet calls reach the PSAP through at least one ESRP (which = handles congestion control and other policies for the PSAP). All I am interested in here is not having to deal with multiple = interfaces at the PSAP.=20 -pier =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, April 17, 2007 4:33 PM To: 'Liess, Laura'; Hannes.Tschofenig@gmx.net; ecrit@ietf.org Subject: RE: [Ecrit] Solution Approaches Laura Although this might work for an access network operator who has a single = ESRP per country, can you accept the fact that it will not be feasible = to have that situation in a country like the U.S., which has 6000 PSAPs = and millions of emergency calls, and without a strong national = organization that could MANDATE that every PSAP use one ESRP? In such a = circumstance, your proposed solution fails. Your description requires = one ESRP per country. I suspect this will also fail in countries that have a small number of = PSAPs, but also lack a strong national emergency service infrastructure. = I am familiar with several countries who could not reasonably organize = such a thing. In many countries, emergency services is VERY local, and = assuming a single operator of critical infrastructure would be very = difficult to create. I'd also like to point out that your proposed solution REQUIRES an ESRP. While I think ESRPs are quite useful, I think requiring that there must = be an entity in the signaling path between the PSAP and the VSP is not = such a good idea. I think solutions that permit an arbitrary PSAP URI to come from LoST = routing of the complete address is probably going to be necessary. Brian > -----Original Message----- > From: Liess, Laura [mailto:Laura.Liess@t-systems.com] > Sent: Tuesday, April 17, 2007 11:37 AM > To: Hannes.Tschofenig@gmx.net; ecrit@ietf.org > Subject: AW: [Ecrit] Solution Approaches >=20 >=20 > Hannes, >=20 > thanks a lot for putting the whole discussion together. >=20 > I can not give you a feedback which is agreed within DT (the internal=20 > agreement process would probably take some time). But I roughly=20 > discussed the approaches with people working on emergency calling. If=20 > we understood the proposal correctly, we have a strong preference for=20 > the approach number 8), which could work as follows: >=20 > The ASP/ISP provides to the client the LbyR, the country code (or=20 > country and state codes)and the local EC dial string (at login and=20 > whenever these data change). > The client queries LOST and gets back an ESRP URI. > When the caller dials the emergency calling number, the client queries = > again the ASP/VSP for the LbyR and the country code and LOST query for = > the ESRP URI. The VSP routes the call to the ESRP. The ESRP has a=20 > shared secret with the LIS, gets the user location and the correct=20 > PSAP and routes the call with the location info to the PSAP (TLS=20 > required). (ESRP or a local LOST does load balancing for PSAPs an all = this stuff). >=20 > Alternatively, the VSPs SIP proxy can do the LOST queries. >=20 >=20 > Laura >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Gesendet: Dienstag, 17. April 2007 11:12 > > An: ECRIT > > Betreff: [Ecrit] Solution Approaches > > > > > > Hi all, > > > > I would like to share some potential solution approaches with you to = > > deal with the problem of not providing precise location to the end=20 > > host. > > I had a chance to discuss these aspects with Henning face-to-face=20 > > last Friday. Here is a short summary. > > > > Note that the goal was to avoid some form of relationship (e.g.,=20 > > business relationship) between the VSP and the ASP/ISP (since this=20 > > would impose a significant deployment problem). > > > > 1) Provide enough location information so that the emergency call=20 > > can be routed to the correct PSAP. Precise location information=20 > > would be provided to the PSAP. > > This approach was already discussed on the list. We need feedback=20 > > from, for example, Barbara and Laura whether they feel comfortable=20 > > with this approach. > > > > CONSEQUENCE: No changes needed. > > > > 2) Provide LbyR + Dial String + PSAP URI to the end host. > > We could ignore the potential security vulnerabilities if charging=20 > > does not work on a call-by-call basis. > > > > CONSEQUENCE: No changes needed. > > > > 3) Provide LbyR + Dial String + PSAP URI to the end host. VSP does a = > > reverse LoST lookup to verify the PSAP URI. > > > > CONSEQUENCE: Solution needs to be developed. > > > > 4) Provide LbyR + Dial String + PSAP URI to the end host. VSP=20 > > verifies the PSAP URI with the PSAP URIs being flooded (using the=20 > > LoST synchronization mechanism). This mechanism is potentially=20 > > similar to (3) > > -- details might vary. (3) might use a distributed approach whereas=20 > > this is brute force. > > > > CONSEQUENCE: Solution needs to be developed. > > > > 5) Emergency calls are routed via the SIP proxy of the VSP and=20 > > subsequently via a SIP proxy in the ASP/ISP (redirect mode) SIP=20 > > Location Conveyance would be used instead of GEOPRIV L7 LCP > > Assumption: No service level agreement (or business > > agreement) between > > VSP and ISP/ASP for this type of SIP emergency message routing=20 > > required. > > > > CONSEQUENCE: No changes needed. Potential problems with SIP Identity = > > possible > > > > 6) Emergency calls are routed via the SIP proxy of the VSP and=20 > > subsequently via a SIP proxy in the ASP/ISP (no redirect > > mode) SIP Location Conveyance would be used instead of GEOPRIV L7=20 > > LCP > > Assumption: No service level agreement (or business > > agreement) between > > VSP and ISP/ASP for this type of SIP emergency message routing=20 > > required. > > > > CONSEQUENCE: No changes needed. > > > > 7) Decoupled authentication for SIP message routing Authentication=20 > > exchange between the end host and the VSP (e.g., TLS to obtain a=20 > > SAML assertion) Authentication credentials are then added to the SIP = > > emergency message that is routed via the SIP proxy in the VSP/ISP. > > No service level agreement (or business agreement) between VSP and=20 > > ISP/ASP needed. > > > > CONSEQUENCE: Security extension for this purpose needs to be=20 > > progressed (already available in draft form) > > > > 8) Country Code Routing > > > > LIS provides country code to the end host. The end host routes the=20 > > SIP emergency message via the VSP towards a ESRP that corresponds to = > > the country code. Then, ESRP fetches more detailed location=20 > > information todo routing within the country. > > > > CONSEQUENCE: No changes to the protocol mechanisms. > > Deployment of ESRPs > > that work this way are needed. Establishment of ESRP <-> ISP/ASP is=20 > > more difficult than with PSAP <-> ISP/ASP since there are far more=20 > > nodes to consider. > > > > 9) Assume end hosts have certs for emergency services; routing via=20 > > SIP proxy in ISP/ASP without traversing VSP in the emergency case.=20 > > Existing credential infrastructure can be used when utilizing SIP=20 > > Cert. > > > > CONSEQUENCE: Architectural aspects need to be developed. A little=20 > > bit more difficult to deploy for VSP. Potential issues with callback = > > (to > > AoR) since end host is not registered with VSP. > > > > 10) Routing via SIP proxy in ISP/ASP. Diameter SIP application used=20 > > to authenticate end host > > Assumption: No roaming agreement assumed for ISP/ASP <-> VSP=20 > > Diameter SIP interaction. > > > > CONSEQUENCE: Problems with legacy credentials, previously mentioned=20 > > call back problems since end host is not registered with VSP,=20 > > Diameter SIP application would need to be profiled. > > > > Thoughts? > > > > Ciao > > Hannes > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 17:11:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HduxK-0002Fj-4G; Tue, 17 Apr 2007 17:11:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HduxI-0002Ar-Uo for ecrit@ietf.org; Tue, 17 Apr 2007 17:11:16 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HduxE-0003Xv-7J for ecrit@ietf.org; Tue, 17 Apr 2007 17:11:16 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 17 Apr 2007 23:11:10 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 23:11:10 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [Ecrit] Solution Approaches Date: Tue, 17 Apr 2007 23:11:10 +0200 Message-Id: <182C63BFBAF131428EA0C16F7FD2191B013584B9@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <0c6d01c7812f$a1c692e0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Solution Approaches thread-index: AceA0IFqiJkGNc2wR5azqP4bVp3ysQANaSewAAn+sgAAAUSigA== From: "Liess, Laura" To: , , X-OriginalArrivalTime: 17 Apr 2007 21:11:10.0669 (UTC) FILETIME=[EC55FFD0:01C78134] X-Spam-Score: 0.0 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian,=20 then, what about this?=20 The ASP/ISP provides the client with the LbyR and a SIP URI of a node = which has the credentials to get the location from the LIS. This node = may be a PSAP, an ESRP or a SIP Proxy in the access network.=20 Otherwise we probably need more than one approach.=20 Laura > -----Urspr=FCngliche Nachricht----- > Von: Brian Rosen [mailto:br@brianrosen.net]=20 > Gesendet: Dienstag, 17. April 2007 22:33 > An: Liess, Laura; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > Betreff: RE: [Ecrit] Solution Approaches >=20 >=20 > Laura >=20 > Although this might work for an access network operator who=20 > has a single ESRP per country, can you accept the fact that=20 > it will not be feasible to have that situation in a country=20 > like the U.S., which has 6000 PSAPs and millions of emergency=20 > calls, and without a strong national organization that could=20 > MANDATE that every PSAP use one ESRP? In such a=20 > circumstance, your proposed solution fails. Your description=20 > requires one ESRP per country. >=20 > I suspect this will also fail in countries that have a small=20 > number of PSAPs, but also lack a strong national emergency=20 > service infrastructure. I am familiar with several countries=20 > who could not reasonably organize such a thing. In many=20 > countries, emergency services is VERY local, and assuming a=20 > single operator of critical infrastructure would be very=20 > difficult to create. >=20 > I'd also like to point out that your proposed solution=20 > REQUIRES an ESRP. While I think ESRPs are quite useful, I=20 > think requiring that there must be an entity in the signaling=20 > path between the PSAP and the VSP is not such a good idea. >=20 > I think solutions that permit an arbitrary PSAP URI to come=20 > from LoST routing of the complete address is probably going=20 > to be necessary. >=20 > Brian >=20 > > -----Original Message----- > > From: Liess, Laura [mailto:Laura.Liess@t-systems.com] > > Sent: Tuesday, April 17, 2007 11:37 AM > > To: Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > Subject: AW: [Ecrit] Solution Approaches > >=20 > >=20 > > Hannes, > >=20 > > thanks a lot for putting the whole discussion together. > >=20 > > I can not give you a feedback which is agreed within DT=20 > (the internal=20 > > agreement process would probably take some time). But I roughly=20 > > discussed the approaches with people working on emergency=20 > calling. If=20 > > we understood the proposal correctly, we have a strong=20 > preference for=20 > > the approach number 8), which could work as follows: > >=20 > > The ASP/ISP provides to the client the LbyR, the country code (or=20 > > country and state codes)and the local EC dial string (at login and=20 > > whenever these data change). The client queries LOST and=20 > gets back an=20 > > ESRP URI. When the caller dials the emergency calling number, the=20 > > client queries again the ASP/VSP for the LbyR and the=20 > country code and=20 > > LOST query for the ESRP URI. The VSP routes the call to the=20 > ESRP. The=20 > > ESRP has a shared secret with the LIS, gets the user=20 > location and the=20 > > correct PSAP and routes the call with the location info to the PSAP=20 > > (TLS required). (ESRP or a local LOST does load balancing=20 > for PSAPs an=20 > > all this stuff). > >=20 > > Alternatively, the VSPs SIP proxy can do the LOST queries. > >=20 > >=20 > > Laura > >=20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Gesendet: Dienstag, 17. April 2007 11:12 > > > An: ECRIT > > > Betreff: [Ecrit] Solution Approaches > > > > > > > > > Hi all, > > > > > > I would like to share some potential solution approaches=20 > with you to=20 > > > deal with the problem of not providing precise location=20 > to the end=20 > > > host. I had a chance to discuss these aspects with Henning > > > face-to-face last > > > Friday. Here is a short summary. > > > > > > Note that the goal was to avoid some form of relationship (e.g.,=20 > > > business relationship) between the VSP and the ASP/ISP=20 > (since this=20 > > > would impose a significant deployment problem). > > > > > > 1) Provide enough location information so that the emergency call=20 > > > can be routed to the correct PSAP. Precise location information=20 > > > would be provided to the PSAP. > > > This approach was already discussed on the list. We need > > > feedback from, > > > for example, Barbara and Laura whether they feel comfortable > > > with this > > > approach. > > > > > > CONSEQUENCE: No changes needed. > > > > > > 2) Provide LbyR + Dial String + PSAP URI to the end host.=20 > We could=20 > > > ignore the potential security vulnerabilities if charging does > > > not work on a call-by-call basis. > > > > > > CONSEQUENCE: No changes needed. > > > > > > 3) Provide LbyR + Dial String + PSAP URI to the end host.=20 > VSP does a=20 > > > reverse LoST lookup to verify the PSAP URI. > > > > > > CONSEQUENCE: Solution needs to be developed. > > > > > > 4) Provide LbyR + Dial String + PSAP URI to the end host. VSP=20 > > > verifies the PSAP URI with the PSAP URIs being flooded (using the=20 > > > LoST synchronization mechanism). This mechanism is potentially > > > similar to (3) > > > -- details might vary. (3) might use a distributed approach > > > whereas this > > > is brute force. > > > > > > CONSEQUENCE: Solution needs to be developed. > > > > > > 5) Emergency calls are routed via the SIP proxy of the VSP and=20 > > > subsequently via a SIP proxy in the ASP/ISP (redirect mode) SIP=20 > > > Location Conveyance would be used instead of GEOPRIV L7 LCP > > > Assumption: No service level agreement (or business > > > agreement) between > > > VSP and ISP/ASP for this type of SIP emergency message routing=20 > > > required. > > > > > > CONSEQUENCE: No changes needed. Potential problems with=20 > SIP Identity=20 > > > possible > > > > > > 6) Emergency calls are routed via the SIP proxy of the VSP and=20 > > > subsequently via a SIP proxy in the ASP/ISP (no redirect > > > mode) SIP Location Conveyance would be used instead of GEOPRIV L7=20 > > > LCP > > > Assumption: No service level agreement (or business > > > agreement) between > > > VSP and ISP/ASP for this type of SIP emergency message > > > routing required. > > > > > > CONSEQUENCE: No changes needed. > > > > > > 7) Decoupled authentication for SIP message routing=20 > Authentication=20 > > > exchange between the end host and the VSP (e.g., TLS to > > > obtain a SAML assertion) > > > Authentication credentials are then added to the SIP > > > emergency message > > > that is routed via the SIP proxy in the VSP/ISP. > > > No service level agreement (or business agreement) between VSP and > > > ISP/ASP needed. > > > > > > CONSEQUENCE: Security extension for this purpose needs to be=20 > > > progressed (already available in draft form) > > > > > > 8) Country Code Routing > > > > > > LIS provides country code to the end host. The end host=20 > routes the=20 > > > SIP emergency message via the VSP towards a ESRP that=20 > corresponds to=20 > > > the country code. Then, ESRP fetches more detailed location > > > information todo > > > routing within the country. > > > > > > CONSEQUENCE: No changes to the protocol mechanisms. Deployment of=20 > > > ESRPs that work this way are needed. Establishment of ESRP <-> > > > ISP/ASP is more > > > difficult than with PSAP <-> ISP/ASP since there are far more > > > nodes to > > > consider. > > > > > > 9) Assume end hosts have certs for emergency services;=20 > routing via=20 > > > SIP proxy in ISP/ASP without traversing VSP in the emergency > > > case. Existing credential infrastructure can be used when > > > utilizing SIP Cert. > > > > > > CONSEQUENCE: Architectural aspects need to be developed. A little=20 > > > bit more difficult to deploy for VSP. Potential issues=20 > with callback=20 > > > (to > > > AoR) since end host is not registered with VSP. > > > > > > 10) Routing via SIP proxy in ISP/ASP. Diameter SIP=20 > application used=20 > > > to authenticate end host > > > Assumption: No roaming agreement assumed for ISP/ASP <->=20 > VSP Diameter > > > SIP interaction. > > > > > > CONSEQUENCE: Problems with legacy credentials, previously=20 > mentioned=20 > > > call back problems since end host is not registered with VSP,=20 > > > Diameter SIP application would need to be profiled. > > > > > > Thoughts? > > > > > > Ciao > > > Hannes > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 17:16:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdv2I-0005Qd-Ex; Tue, 17 Apr 2007 17:16:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdv2H-0005QT-He for ecrit@ietf.org; Tue, 17 Apr 2007 17:16:25 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdv2G-0005PK-AC for ecrit@ietf.org; Tue, 17 Apr 2007 17:16:25 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3HLGN9o010713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 17 Apr 2007 17:16:23 -0400 (EDT) In-Reply-To: <182C63BFBAF131428EA0C16F7FD2191B013584B8@S4DE8PSAAGM.mitte.t-com.de> References: <182C63BFBAF131428EA0C16F7FD2191B013584B8@S4DE8PSAAGM.mitte.t-com.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4B859B7A-D560-4FFF-907E-1510CE7EC713@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: AW: AW: [Ecrit] Solution Approaches Date: Tue, 17 Apr 2007 17:17:36 -0400 To: "Liess, Laura" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 17, 2007, at 4:51 PM, Liess, Laura wrote: > > I am aware of the drawbacks. But I didn't see any other solution we > can live with. Not only because of the location hiding issue, but > also because providing a more accurate location information for > every end device requires much more performant mechanisms than > those we have today. Today, the location information is provided by > the system only for emergency calls where the caller is not able to > talk to the call taker. Providing it at every login is another > order of magnitude. I was told that replacing the current mechanism > requires changes in the whole backend infrastructure and would cost > millions. Nobody is willing to spend so much money without a > business case. > I obviously don't know the DT infrastructure, but I'm having a hard time believing the 'millions' part. A low-end web server can handle hundreds of request a second, particularly of the simple kind needed for HELD and similar protocols. Let's just say 100 requests/sec. (Our LoST server handles 180 req/sec., including a more elaborate database lookup.) This yields roughly 8 million customers for each server, assuming a once-a-day login (obviously, most hard phones and ATA devices would remain connected for much longer, without a reboot, but I don't know what the ratio between soft and hardphones would be. Our hard phones get rebooted when there's a software update, every six months or so.). Even assuming that DT has 80 million DSL customers that have VoIP, this would be ten servers, which cost (retail, with bandwidth and server rental) about $2000/month. Or, expressed differently, the incremental cost per customer is $0.000025 per month. I realize that there's a software development cost, but I'm suspecting that this isn't affected much by how often the system is being queried. If you'll pay millions for this server infrastructure, maybe I should offer our implementation services to DT... (Here, the modern server could simply be the caching front-end for the existing system.) Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 17:21:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdv79-0001Jf-Oh; Tue, 17 Apr 2007 17:21:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdv78-0001Ja-CD for ecrit@ietf.org; Tue, 17 Apr 2007 17:21:26 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdv77-0006ct-4H for ecrit@ietf.org; Tue, 17 Apr 2007 17:21:26 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 17 Apr 2007 17:21:25 -0400 X-IronPort-AV: i="4.14,420,1170651600"; d="scan'208"; a="57905613:sNHT44417188" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3HLLOtk000973; Tue, 17 Apr 2007 17:21:24 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3HLLNlS028767; Tue, 17 Apr 2007 21:21:24 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 17:21:20 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 17:21:19 -0400 From: "Marc Linsner" To: "'Liess, Laura'" Subject: RE: AW: [Ecrit] Solution Approaches Date: Tue, 17 Apr 2007 17:21:19 -0400 Message-ID: <011801c78136$57885cc0$2d0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceBEjlcF268R4Z5QByaCKK/usgcSgAFVL9gAANLVDA= In-Reply-To: <182C63BFBAF131428EA0C16F7FD2191B013584B8@S4DE8PSAAGM.mitte.t-com.de> X-OriginalArrivalTime: 17 Apr 2007 21:21:20.0000 (UTC) FILETIME=[57868800:01C78136] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=921; t=1176844884; x=1177708884; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20AW=3A=20[Ecrit]=20Solution=20Approaches |Sender:=20 |To:=20=22'Liess,=20Laura'=22=20; bh=82g0/GOyTjRnSbq2Na6UaUm0+M9iWlEIZG9gHilrVds=; b=cAgPa69GlcHYTMVABBUW2TUHO0riQBs9oDjbYkvHPRceMPBTCZ3TToxSqa/3ERhpralho6Uz /9g82oAB9Bouuhiym8mGsX44t+q4ReKC6EDTRMaWkjCMKCOaHxJq5lU9; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Laura, > I am aware of the drawbacks. But I didn't see any other > solution we can live with. Not only because of the location > hiding issue, but also because providing a more accurate > location information for every end device requires much more > performant mechanisms than those we have today. Today, the > location information is provided by the system only for > emergency calls where the caller is not able to talk to the > call taker. Providing it at every login is another order of > magnitude. I was told that replacing the current mechanism > requires changes in the whole backend infrastructure and > would cost millions. Nobody is willing to spend so much money > without a business case. Could you provide some more context here? I'm curious of the environment where providing location to an end-point is expensive. Wireless? Wireline Broadband? Thanks, -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 17:29:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdvFN-0005sq-VX; Tue, 17 Apr 2007 17:29:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdvFN-0005sh-4T for ecrit@ietf.org; Tue, 17 Apr 2007 17:29:57 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdvFM-0000WY-GK for ecrit@ietf.org; Tue, 17 Apr 2007 17:29:57 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HdvFK-0006vi-Ly; Tue, 17 Apr 2007 16:29:55 -0500 From: "Brian Rosen" To: "'Desjardins, Pierre'" Subject: RE: [Ecrit] Solution Approaches Date: Tue, 17 Apr 2007 17:29:51 -0400 Message-ID: <0cb001c78137$8a75d170$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceA0IFqiJkGNc2wR5azqP4bVp3ysQANaSewAAn+sgAAAJJr8AABtYiA In-Reply-To: <567E04E775EA244A9F7E4140EAEB4111047255AA@srvexchg2.positron.qc.ca> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Cc: ecrit@ietf.org, "'Liess, Laura'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think it will be common, I think it will not be universal, and = attempts to make it universal will lead to problems. The best example in the U.S. is probably New York City. There is = unlikely to be a New York State ESRP between the VSP and the New York City PSAP. It's big enough, and "powerful" in the political sense, to have a direct connection without an ESRP. Brian > -----Original Message----- > From: Desjardins, Pierre [mailto:pdesjardins@positron911.com] > Sent: Tuesday, April 17, 2007 5:02 PM > To: Brian Rosen > Cc: Liess, Laura; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > Subject: RE: [Ecrit] Solution Approaches >=20 > Brian, >=20 > In your response below you state "requiring that there must be an = entity > in the signaling path between the PSAP and the VSP is not such a good > idea". >=20 > This seems to be contradictary to what we have been envisioning for = NENA > i3 -- where ESINet calls reach the PSAP through at least one ESRP = (which > handles congestion control and other policies for the PSAP). >=20 > All I am interested in here is not having to deal with multiple = interfaces > at the PSAP. >=20 > -pier >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, April 17, 2007 4:33 PM > To: 'Liess, Laura'; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > Subject: RE: [Ecrit] Solution Approaches >=20 > Laura >=20 > Although this might work for an access network operator who has a = single > ESRP per country, can you accept the fact that it will not be feasible = to > have that situation in a country like the U.S., which has 6000 PSAPs = and > millions of emergency calls, and without a strong national = organization > that could MANDATE that every PSAP use one ESRP? In such a = circumstance, > your proposed solution fails. Your description requires one ESRP per > country. >=20 > I suspect this will also fail in countries that have a small number of > PSAPs, but also lack a strong national emergency service = infrastructure. > I am familiar with several countries who could not reasonably organize > such a thing. In many countries, emergency services is VERY local, = and > assuming a single operator of critical infrastructure would be very > difficult to create. >=20 > I'd also like to point out that your proposed solution REQUIRES an = ESRP. > While I think ESRPs are quite useful, I think requiring that there = must be > an entity in the signaling path between the PSAP and the VSP is not = such a > good idea. >=20 > I think solutions that permit an arbitrary PSAP URI to come from LoST > routing of the complete address is probably going to be necessary. >=20 > Brian >=20 > > -----Original Message----- > > From: Liess, Laura [mailto:Laura.Liess@t-systems.com] > > Sent: Tuesday, April 17, 2007 11:37 AM > > To: Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > Subject: AW: [Ecrit] Solution Approaches > > > > > > Hannes, > > > > thanks a lot for putting the whole discussion together. > > > > I can not give you a feedback which is agreed within DT (the = internal > > agreement process would probably take some time). But I roughly > > discussed the approaches with people working on emergency calling. = If > > we understood the proposal correctly, we have a strong preference = for > > the approach number 8), which could work as follows: > > > > The ASP/ISP provides to the client the LbyR, the country code (or > > country and state codes)and the local EC dial string (at login and > > whenever these data change). > > The client queries LOST and gets back an ESRP URI. > > When the caller dials the emergency calling number, the client = queries > > again the ASP/VSP for the LbyR and the country code and LOST query = for > > the ESRP URI. The VSP routes the call to the ESRP. The ESRP has a > > shared secret with the LIS, gets the user location and the correct > > PSAP and routes the call with the location info to the PSAP (TLS > > required). (ESRP or a local LOST does load balancing for PSAPs an = all > this stuff). > > > > Alternatively, the VSPs SIP proxy can do the LOST queries. > > > > > > Laura > > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Gesendet: Dienstag, 17. April 2007 11:12 > > > An: ECRIT > > > Betreff: [Ecrit] Solution Approaches > > > > > > > > > Hi all, > > > > > > I would like to share some potential solution approaches with you = to > > > deal with the problem of not providing precise location to the end > > > host. > > > I had a chance to discuss these aspects with Henning face-to-face > > > last Friday. Here is a short summary. > > > > > > Note that the goal was to avoid some form of relationship (e.g., > > > business relationship) between the VSP and the ASP/ISP (since this > > > would impose a significant deployment problem). > > > > > > 1) Provide enough location information so that the emergency call > > > can be routed to the correct PSAP. Precise location information > > > would be provided to the PSAP. > > > This approach was already discussed on the list. We need feedback > > > from, for example, Barbara and Laura whether they feel comfortable > > > with this approach. > > > > > > CONSEQUENCE: No changes needed. > > > > > > 2) Provide LbyR + Dial String + PSAP URI to the end host. > > > We could ignore the potential security vulnerabilities if charging > > > does not work on a call-by-call basis. > > > > > > CONSEQUENCE: No changes needed. > > > > > > 3) Provide LbyR + Dial String + PSAP URI to the end host. VSP does = a > > > reverse LoST lookup to verify the PSAP URI. > > > > > > CONSEQUENCE: Solution needs to be developed. > > > > > > 4) Provide LbyR + Dial String + PSAP URI to the end host. VSP > > > verifies the PSAP URI with the PSAP URIs being flooded (using the > > > LoST synchronization mechanism). This mechanism is potentially > > > similar to (3) > > > -- details might vary. (3) might use a distributed approach = whereas > > > this is brute force. > > > > > > CONSEQUENCE: Solution needs to be developed. > > > > > > 5) Emergency calls are routed via the SIP proxy of the VSP and > > > subsequently via a SIP proxy in the ASP/ISP (redirect mode) SIP > > > Location Conveyance would be used instead of GEOPRIV L7 LCP > > > Assumption: No service level agreement (or business > > > agreement) between > > > VSP and ISP/ASP for this type of SIP emergency message routing > > > required. > > > > > > CONSEQUENCE: No changes needed. Potential problems with SIP = Identity > > > possible > > > > > > 6) Emergency calls are routed via the SIP proxy of the VSP and > > > subsequently via a SIP proxy in the ASP/ISP (no redirect > > > mode) SIP Location Conveyance would be used instead of GEOPRIV L7 > > > LCP > > > Assumption: No service level agreement (or business > > > agreement) between > > > VSP and ISP/ASP for this type of SIP emergency message routing > > > required. > > > > > > CONSEQUENCE: No changes needed. > > > > > > 7) Decoupled authentication for SIP message routing Authentication > > > exchange between the end host and the VSP (e.g., TLS to obtain a > > > SAML assertion) Authentication credentials are then added to the = SIP > > > emergency message that is routed via the SIP proxy in the VSP/ISP. > > > No service level agreement (or business agreement) between VSP and > > > ISP/ASP needed. > > > > > > CONSEQUENCE: Security extension for this purpose needs to be > > > progressed (already available in draft form) > > > > > > 8) Country Code Routing > > > > > > LIS provides country code to the end host. The end host routes the > > > SIP emergency message via the VSP towards a ESRP that corresponds = to > > > the country code. Then, ESRP fetches more detailed location > > > information todo routing within the country. > > > > > > CONSEQUENCE: No changes to the protocol mechanisms. > > > Deployment of ESRPs > > > that work this way are needed. Establishment of ESRP <-> ISP/ASP = is > > > more difficult than with PSAP <-> ISP/ASP since there are far more > > > nodes to consider. > > > > > > 9) Assume end hosts have certs for emergency services; routing via > > > SIP proxy in ISP/ASP without traversing VSP in the emergency case. > > > Existing credential infrastructure can be used when utilizing SIP > > > Cert. > > > > > > CONSEQUENCE: Architectural aspects need to be developed. A little > > > bit more difficult to deploy for VSP. Potential issues with = callback > > > (to > > > AoR) since end host is not registered with VSP. > > > > > > 10) Routing via SIP proxy in ISP/ASP. Diameter SIP application = used > > > to authenticate end host > > > Assumption: No roaming agreement assumed for ISP/ASP <-> VSP > > > Diameter SIP interaction. > > > > > > CONSEQUENCE: Problems with legacy credentials, previously = mentioned > > > call back problems since end host is not registered with VSP, > > > Diameter SIP application would need to be profiled. > > > > > > Thoughts? > > > > > > Ciao > > > Hannes > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 17:57:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdvgM-0005B0-Ce; Tue, 17 Apr 2007 17:57:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdvgK-0005At-VX for ecrit@ietf.org; Tue, 17 Apr 2007 17:57:48 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdvgJ-0002rz-CK for ecrit@ietf.org; Tue, 17 Apr 2007 17:57:48 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HdvgH-00058T-FF; Tue, 17 Apr 2007 16:57:45 -0500 From: "Brian Rosen" To: "'Liess, Laura'" , , Subject: RE: [Ecrit] Solution Approaches Date: Tue, 17 Apr 2007 17:57:43 -0400 Message-ID: <0cc201c7813b$6ec61f80$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceA0IFqiJkGNc2wR5azqP4bVp3ysQANaSewAAn+sgAAAUSigAABwp4g In-Reply-To: <182C63BFBAF131428EA0C16F7FD2191B013584B9@S4DE8PSAAGM.mitte.t-com.de> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I don't understand how this would be easier on the access network than providing the LoST results (e.g. PSAP URI). That URI may well be an = ESRP or a PSAP URI. I don't think the access network would want to provide a = SIP proxy; that's getting in the middle of emergency call signaling. I have this feeling we're talking past one another. For example, if the access network knows that all of its infrastructure = (or at least all of it served by a single LIS) is in a single country, and = that country has a single ESRP, then it doesn't need to do a LoST lookup; the result is always a constant to it; the "PSAP URI" is always the ESRP, = the dialstring is always the same, and the boundary is always the same. = This makes it very simple if the access network is in such a situation. Many access networks will be in that situation. It won't need to determine = the fine grained location until a PSAP asks for it. Even in the U.S. with our crazy patchwork of PSAPs and odd boundaries, = many of the LIS service areas will be totally within one ESRP/PSAP boundary, = and no LoST access or fine grained location determination will be needed = until a PSAP query comes in. Brian > -----Original Message----- > From: Liess, Laura [mailto:Laura.Liess@t-systems.com] > Sent: Tuesday, April 17, 2007 5:11 PM > To: br@brianrosen.net; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > Subject: AW: [Ecrit] Solution Approaches >=20 > Brian, >=20 > then, what about this? > The ASP/ISP provides the client with the LbyR and a SIP URI of a node > which has the credentials to get the location from the LIS. This node = may > be a PSAP, an ESRP or a SIP Proxy in the access network. >=20 > Otherwise we probably need more than one approach. >=20 > Laura >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Brian Rosen [mailto:br@brianrosen.net] > > Gesendet: Dienstag, 17. April 2007 22:33 > > An: Liess, Laura; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > Betreff: RE: [Ecrit] Solution Approaches > > > > > > Laura > > > > Although this might work for an access network operator who > > has a single ESRP per country, can you accept the fact that > > it will not be feasible to have that situation in a country > > like the U.S., which has 6000 PSAPs and millions of emergency > > calls, and without a strong national organization that could > > MANDATE that every PSAP use one ESRP? In such a > > circumstance, your proposed solution fails. Your description > > requires one ESRP per country. > > > > I suspect this will also fail in countries that have a small > > number of PSAPs, but also lack a strong national emergency > > service infrastructure. I am familiar with several countries > > who could not reasonably organize such a thing. In many > > countries, emergency services is VERY local, and assuming a > > single operator of critical infrastructure would be very > > difficult to create. > > > > I'd also like to point out that your proposed solution > > REQUIRES an ESRP. While I think ESRPs are quite useful, I > > think requiring that there must be an entity in the signaling > > path between the PSAP and the VSP is not such a good idea. > > > > I think solutions that permit an arbitrary PSAP URI to come > > from LoST routing of the complete address is probably going > > to be necessary. > > > > Brian > > > > > -----Original Message----- > > > From: Liess, Laura [mailto:Laura.Liess@t-systems.com] > > > Sent: Tuesday, April 17, 2007 11:37 AM > > > To: Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > > Subject: AW: [Ecrit] Solution Approaches > > > > > > > > > Hannes, > > > > > > thanks a lot for putting the whole discussion together. > > > > > > I can not give you a feedback which is agreed within DT > > (the internal > > > agreement process would probably take some time). But I roughly > > > discussed the approaches with people working on emergency > > calling. If > > > we understood the proposal correctly, we have a strong > > preference for > > > the approach number 8), which could work as follows: > > > > > > The ASP/ISP provides to the client the LbyR, the country code (or > > > country and state codes)and the local EC dial string (at login and > > > whenever these data change). The client queries LOST and > > gets back an > > > ESRP URI. When the caller dials the emergency calling number, the > > > client queries again the ASP/VSP for the LbyR and the > > country code and > > > LOST query for the ESRP URI. The VSP routes the call to the > > ESRP. The > > > ESRP has a shared secret with the LIS, gets the user > > location and the > > > correct PSAP and routes the call with the location info to the = PSAP > > > (TLS required). (ESRP or a local LOST does load balancing > > for PSAPs an > > > all this stuff). > > > > > > Alternatively, the VSPs SIP proxy can do the LOST queries. > > > > > > > > > Laura > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > Gesendet: Dienstag, 17. April 2007 11:12 > > > > An: ECRIT > > > > Betreff: [Ecrit] Solution Approaches > > > > > > > > > > > > Hi all, > > > > > > > > I would like to share some potential solution approaches > > with you to > > > > deal with the problem of not providing precise location > > to the end > > > > host. I had a chance to discuss these aspects with Henning > > > > face-to-face last > > > > Friday. Here is a short summary. > > > > > > > > Note that the goal was to avoid some form of relationship (e.g., > > > > business relationship) between the VSP and the ASP/ISP > > (since this > > > > would impose a significant deployment problem). > > > > > > > > 1) Provide enough location information so that the emergency = call > > > > can be routed to the correct PSAP. Precise location information > > > > would be provided to the PSAP. > > > > This approach was already discussed on the list. We need > > > > feedback from, > > > > for example, Barbara and Laura whether they feel comfortable > > > > with this > > > > approach. > > > > > > > > CONSEQUENCE: No changes needed. > > > > > > > > 2) Provide LbyR + Dial String + PSAP URI to the end host. > > We could > > > > ignore the potential security vulnerabilities if charging does > > > > not work on a call-by-call basis. > > > > > > > > CONSEQUENCE: No changes needed. > > > > > > > > 3) Provide LbyR + Dial String + PSAP URI to the end host. > > VSP does a > > > > reverse LoST lookup to verify the PSAP URI. > > > > > > > > CONSEQUENCE: Solution needs to be developed. > > > > > > > > 4) Provide LbyR + Dial String + PSAP URI to the end host. VSP > > > > verifies the PSAP URI with the PSAP URIs being flooded (using = the > > > > LoST synchronization mechanism). This mechanism is potentially > > > > similar to (3) > > > > -- details might vary. (3) might use a distributed approach > > > > whereas this > > > > is brute force. > > > > > > > > CONSEQUENCE: Solution needs to be developed. > > > > > > > > 5) Emergency calls are routed via the SIP proxy of the VSP and > > > > subsequently via a SIP proxy in the ASP/ISP (redirect mode) SIP > > > > Location Conveyance would be used instead of GEOPRIV L7 LCP > > > > Assumption: No service level agreement (or business > > > > agreement) between > > > > VSP and ISP/ASP for this type of SIP emergency message routing > > > > required. > > > > > > > > CONSEQUENCE: No changes needed. Potential problems with > > SIP Identity > > > > possible > > > > > > > > 6) Emergency calls are routed via the SIP proxy of the VSP and > > > > subsequently via a SIP proxy in the ASP/ISP (no redirect > > > > mode) SIP Location Conveyance would be used instead of GEOPRIV = L7 > > > > LCP > > > > Assumption: No service level agreement (or business > > > > agreement) between > > > > VSP and ISP/ASP for this type of SIP emergency message > > > > routing required. > > > > > > > > CONSEQUENCE: No changes needed. > > > > > > > > 7) Decoupled authentication for SIP message routing > > Authentication > > > > exchange between the end host and the VSP (e.g., TLS to > > > > obtain a SAML assertion) > > > > Authentication credentials are then added to the SIP > > > > emergency message > > > > that is routed via the SIP proxy in the VSP/ISP. > > > > No service level agreement (or business agreement) between VSP = and > > > > ISP/ASP needed. > > > > > > > > CONSEQUENCE: Security extension for this purpose needs to be > > > > progressed (already available in draft form) > > > > > > > > 8) Country Code Routing > > > > > > > > LIS provides country code to the end host. The end host > > routes the > > > > SIP emergency message via the VSP towards a ESRP that > > corresponds to > > > > the country code. Then, ESRP fetches more detailed location > > > > information todo > > > > routing within the country. > > > > > > > > CONSEQUENCE: No changes to the protocol mechanisms. Deployment = of > > > > ESRPs that work this way are needed. Establishment of ESRP <-> > > > > ISP/ASP is more > > > > difficult than with PSAP <-> ISP/ASP since there are far more > > > > nodes to > > > > consider. > > > > > > > > 9) Assume end hosts have certs for emergency services; > > routing via > > > > SIP proxy in ISP/ASP without traversing VSP in the emergency > > > > case. Existing credential infrastructure can be used when > > > > utilizing SIP Cert. > > > > > > > > CONSEQUENCE: Architectural aspects need to be developed. A = little > > > > bit more difficult to deploy for VSP. Potential issues > > with callback > > > > (to > > > > AoR) since end host is not registered with VSP. > > > > > > > > 10) Routing via SIP proxy in ISP/ASP. Diameter SIP > > application used > > > > to authenticate end host > > > > Assumption: No roaming agreement assumed for ISP/ASP <-> > > VSP Diameter > > > > SIP interaction. > > > > > > > > CONSEQUENCE: Problems with legacy credentials, previously > > mentioned > > > > call back problems since end host is not registered with VSP, > > > > Diameter SIP application would need to be profiled. > > > > > > > > Thoughts? > > > > > > > > Ciao > > > > Hannes > > > > > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 21:19:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdypK-0008BA-Hg; Tue, 17 Apr 2007 21:19:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdypI-0008At-Gg for ecrit@ietf.org; Tue, 17 Apr 2007 21:19:16 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdypE-00083I-WE for ecrit@ietf.org; Tue, 17 Apr 2007 21:19:15 -0400 Received: from [10.0.1.110] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 17 Apr 2007 21:19:12 -0400 id 0158842A.46257210.00007CE2 In-Reply-To: <0c8a01c78131$e9a58d30$640fa8c0@cis.neustar.com> References: <0c8a01c78131$e9a58d30$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1F6CBE48-9F35-4B7E-A334-B2056AA2A77A@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: A slightly different take: RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Date: Tue, 17 Apr 2007 21:19:11 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: 'Barbara Stark' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 17, 2007, at 4:49 PM, Brian Rosen wrote: > I'm not sure I understand the boundary. Since no one downstream of > the LIS > can get the location other than the PSAP, the boundary can't be > used for its > normal purpose. I don't follow what you are saying. Note that I said "boundary reference", not boundary. A VSP could validate the boundary reference, which would be far more specific than just a country code. > I think that the protocol changes Henning refers to are changes > that allow > an endpoint to query with the LCPs identifiers and get back the > LbyR, PSAP > URI, dial string and boundary/country code. Neither LoST nor any > LCP has > that operation so far. If we are to make protocol changes, I'd rather not stray too far. The behavior we need is simply this: LoST returns boundary references with mappings, and these boundary references are simply put into well- known SIP URI parameters (to be used by the VSP later). To the client, the behavior is the same: 1) The client queries the LCP for location. 2) The LCP returns location that is very broad, perhaps just the country code. 3) The client gets configured with the LoST resolve of the access network. 4) The client queries LoST with its location. 5) The LoST resolver consults the LIS for the more specific location. 6) The LoST resolver then conducts the regular resolution. 7) The LoST resolver returns the normal answer to the client. 8) The client makes the call in the normal way. The only change here is to LoST to include boundary references in mappings, and to the clients so that they know to pass those references to the VSP. > I don't think we need anything special to prohibit > the endpoint from dereferencing; it would not have the credentials to > dereference, which the PSAP would. I will note that if a LIS > insists on > credentials, and some kind of failure occurs and the PSAP is not > able to get > location, the LIS operator takes on some significant liability. What credentials would the PSAP have? If we are talking about PKI, then I have a problem with that. Having the LIS simply know not to allow a dereference by the target, of which it has a solid understanding who that is, should be enough. And that requires absolutely no cross-domain coordination. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 22:04:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdzX0-0000hq-Aq; Tue, 17 Apr 2007 22:04:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdzWz-0000hU-Lp for ecrit@ietf.org; Tue, 17 Apr 2007 22:04:25 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdzWw-0005Zd-K2 for ecrit@ietf.org; Tue, 17 Apr 2007 22:04:25 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HdzWr-00087b-Fh; Tue, 17 Apr 2007 21:04:17 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: A slightly different take: RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Date: Tue, 17 Apr 2007 22:04:17 -0400 Message-ID: <0d1301c7815d$e1060c00$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceBV5JM+7sJJb7GTvGDJ6crpxsj2QAA6bVA In-Reply-To: <1F6CBE48-9F35-4B7E-A334-B2056AA2A77A@hxr.us> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: 'Barbara Stark' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Tuesday, April 17, 2007 9:19 PM > To: Brian Rosen > Cc: 'ECRIT'; 'Barbara Stark'; 'Marc Linsner' > Subject: Re: A slightly different take: RE: [Ecrit] Not-so-grand > compromise on how to doendpointcentric LCPwithout giving away the store > > > On Apr 17, 2007, at 4:49 PM, Brian Rosen wrote: > > > I'm not sure I understand the boundary. Since no one downstream of > > the LIS > > can get the location other than the PSAP, the boundary can't be > > used for its > > normal purpose. > > I don't follow what you are saying. Note that I said "boundary > reference", not boundary. A VSP could validate the boundary > reference, which would be far more specific than just a country code. The VSP doesn't have a location to verify a boundary. The original proposal was to reverse search the PSAP URI within a country. The country is really just a hint that may help the reverse search. Henning argues we don't need it at all, and he may be right. You could try to make the LoST server reverse search within a boundary, but I suspect that is a lot harder. I don't know why a reference is any more or less helpful than the actual boundary. > > > I think that the protocol changes Henning refers to are changes > > that allow > > an endpoint to query with the LCPs identifiers and get back the > > LbyR, PSAP > > URI, dial string and boundary/country code. Neither LoST nor any > > LCP has > > that operation so far. > > If we are to make protocol changes, I'd rather not stray too far. > The behavior we need is simply this: LoST returns boundary references > with mappings, and these boundary references are simply put into well- > known SIP URI parameters (to be used by the VSP later). > > To the client, the behavior is the same: > > 1) The client queries the LCP for location. > 2) The LCP returns location that is very broad, perhaps just the > country code. > 3) The client gets configured with the LoST resolve of the access > network. > 4) The client queries LoST with its location. > 5) The LoST resolver consults the LIS for the more specific location. > 6) The LoST resolver then conducts the regular resolution. > 7) The LoST resolver returns the normal answer to the client. > 8) The client makes the call in the normal way. > > The only change here is to LoST to include boundary references in > mappings, and to the clients so that they know to pass those > references to the VSP. I'm lost (pun, sorry). Country codes aren't useful enough to pick a PSAP. You know this, so I don't understand what that location does, but I'm even more confused than that. In step 5 you have LoST querying the LIS. That's a big step, and how is it doing this? With an LbyR? So far, the LCP has a coarse LbyV. See how lost I am? I really, truly don't understand the reluctance to simply combining a call to an LCP with a call to a LoST resolver into one step. It means the access network is calling LoST instead of the client, but I think we're mostly thinking the access network is pretty close to the LoST resolver, so that should be a no brainer. If you don't want to dirty the LCP protocol, we really can invent a new combo protocol; it's no big deal, since it's mostly the query syntax of the LCP with the return of the LCP+LoST as one data structure. > > > I don't think we need anything special to prohibit > > the endpoint from dereferencing; it would not have the credentials to > > dereference, which the PSAP would. I will note that if a LIS > > insists on > > credentials, and some kind of failure occurs and the PSAP is not > > able to get > > location, the LIS operator takes on some significant liability. > > What credentials would the PSAP have? If we are talking about PKI, > then I have a problem with that. Having the LIS simply know not to > allow a dereference by the target, of which it has a solid > understanding who that is, should be enough. And that requires > absolutely no cross-domain coordination. Well, since the LIS and the PSAP are local to one another they could use anything they agree to use. The point of the LbyR is to control WHO can dereference. The access network is happy to have anyone dereference as long as they pay for the privilege. It WANTS the endpoint to give the LbyR to anyone who wants it, to maximize it's revenue. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 17 22:19:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdzlq-0002Oz-MT; Tue, 17 Apr 2007 22:19:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdzlp-0002Nr-7n for ecrit@ietf.org; Tue, 17 Apr 2007 22:19:45 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdzlp-0002JT-0V for ecrit@ietf.org; Tue, 17 Apr 2007 22:19:45 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3I2JTmg021875 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 17 Apr 2007 22:19:30 -0400 (EDT) In-Reply-To: <0d1301c7815d$e1060c00$640fa8c0@cis.neustar.com> References: <0d1301c7815d$e1060c00$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1495C401-0F94-4964-B59B-20045FA67DC1@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: A slightly different take: RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Date: Tue, 17 Apr 2007 22:19:35 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: 'Barbara Stark' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > The VSP doesn't have a location to verify a boundary. The original > proposal > was to reverse search the PSAP URI within a country. The country > is really > just a hint that may help the reverse search. Henning argues we > don't need > it at all, and he may be right. You could try to make the LoST server > reverse search within a boundary, but I suspect that is a lot > harder. I > don't know why a reference is any more or less helpful than the actual > boundary. > My sense is that there are no objections, on business model grounds, to at least provide the country information to the user agent. This would be somewhat helpful for the PSAP URL verification and, more importantly, for the dial string. > > I really, truly don't understand the reluctance to simply combining > a call > to an LCP with a call to a LoST resolver into one step. It means > the access > This means changing either LCP (probably both L7 and DHCP) or LoST. LCP is then really a configuration protocol. This means that the UA behavior has to change and get more complicated. I'm opposed to such hacks. > network is calling LoST instead of the client, but I think we're > mostly > thinking the access network is pretty close to the LoST resolver, > so that > should be a no brainer. There are going to many different LoST resolvers, operated by VSP, ISPs and independent third parties. Thus, you now have to pick just the right one to get good information. Yet another complication. > > If you don't want to dirty the LCP protocol, we really can invent a > new > combo protocol; it's no big deal, since it's mostly the query > syntax of the > LCP with the return of the LCP+LoST as one data structure. I guess I have to keep repeating this for a while, but you're re- inventing SIP configuration. We really don't need two SIP configuration protocols and I will protest and raise a stink in SIPPING if we do. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 00:07:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He1S1-0007an-Ji; Wed, 18 Apr 2007 00:07:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He1S0-0007af-Kx for ecrit@ietf.org; Wed, 18 Apr 2007 00:07:24 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He1S0-0002Nr-7L for ecrit@ietf.org; Wed, 18 Apr 2007 00:07:24 -0400 Received: from [10.0.1.110] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 18 Apr 2007 00:07:23 -0400 id 01588118.4625997B.00001ED8 In-Reply-To: <0d1301c7815d$e1060c00$640fa8c0@cis.neustar.com> References: <0d1301c7815d$e1060c00$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: A slightly different take: RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Date: Wed, 18 Apr 2007 00:07:22 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: 'Barbara Stark' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, For some reason we seem to be miscommunicating, most likely because of the medium. I'll try to clarify below. On Apr 17, 2007, at 10:04 PM, Brian Rosen wrote: > The VSP doesn't have a location to verify a boundary. The original > proposal > was to reverse search the PSAP URI within a country. The country > is really > just a hint that may help the reverse search. Henning argues we > don't need > it at all, and he may be right. You could try to make the LoST server > reverse search within a boundary, but I suspect that is a lot > harder. I > don't know why a reference is any more or less helpful than the actual > boundary. My point about the boundary reference is that it can be used to get a from LoST. If you point LoST client A at a LoST server and it gets back a boundary reference, that reference can the be handed to LoST client B who can use it to retrieve the very same . Included in is the PSAP URI. If a VSP wants to validate that the URI it has been given is truly a PSAP URI, it can use the boundary reference to achieve the . That mapping should contain the very same PSAP URI. >> If we are to make protocol changes, I'd rather not stray too far. >> The behavior we need is simply this: LoST returns boundary references >> with mappings, and these boundary references are simply put into >> well- >> known SIP URI parameters (to be used by the VSP later). >> >> To the client, the behavior is the same: >> >> 1) The client queries the LCP for location. >> 2) The LCP returns location that is very broad, perhaps just the >> country code. >> 3) The client gets configured with the LoST resolve of the access >> network. >> 4) The client queries LoST with its location. >> 5) The LoST resolver consults the LIS for the more specific location. >> 6) The LoST resolver then conducts the regular resolution. >> 7) The LoST resolver returns the normal answer to the client. >> 8) The client makes the call in the normal way. >> >> The only change here is to LoST to include boundary references in >> mappings, and to the clients so that they know to pass those >> references to the VSP. > I'm lost (pun, sorry). > Country codes aren't useful enough to pick a PSAP. You know this, > so I > don't understand what that location does, but I'm even more > confused than > that. I didn't explain that well. In step 2, the LCP returns a place holder location. It might as well say "planet Earth", but that isn't valid within the protocol schemas. The point is, the client does not know that the location is just a place holder and treats it no differently. By definition, this location information has not real meaning. > In step 5 you have LoST querying the LIS. That's a big step, and > how > is it doing this? With an LbyR? So far, the LCP has a coarse > LbyV. See > how lost I am? Note that in step 3, the LoST server that the client gets configured with resides in the access network. It might as well be the LIS itself, just with a LoST interface. Since the access network knows the location of the target, it can combine the LIS and LoST functions together. It can also ignore the place holder location that will be given it by the client, because it knows the real location of the client... and that is what it will use for LoST. > I really, truly don't understand the reluctance to simply combining > a call > to an LCP with a call to a LoST resolver into one step. It means > the access > network is calling LoST instead of the client, but I think we're > mostly > thinking the access network is pretty close to the LoST resolver, > so that > should be a no brainer. I think we are on the same page, just reading different paragraphs. > If you don't want to dirty the LCP protocol, we really can invent a > new > combo protocol; it's no big deal, since it's mostly the query > syntax of the > LCP with the return of the LCP+LoST as one data structure. Personally I'd rather put this in LoST than have to go back and retrofit 5 LCPs. However, I'm also concerned with the behavior of the client. I would like it to do the same thing and have the same steps no matter if it is a network that attempts to hide its location or in a network that does not. Having separate client, endpoint behavior for these two situations may lead to trouble. >> What credentials would the PSAP have? If we are talking about PKI, >> then I have a problem with that. Having the LIS simply know not to >> allow a dereference by the target, of which it has a solid >> understanding who that is, should be enough. And that requires >> absolutely no cross-domain coordination. > Well, since the LIS and the PSAP are local to one another they > could use > anything they agree to use. The point of the LbyR is to control > WHO can > dereference. The access network is happy to have anyone > dereference as long > as they pay for the privilege. It WANTS the endpoint to give the > LbyR to > anyone who wants it, to maximize it's revenue. Ok. Here we are reading from different books. An LbyR is not the only thing a LIS needs to hand out to get paid for its location, unless you have a different perspective of that whole micro-payments thing from 10 years ago. Also, there may be networks that had location for client endpoints for reasons other than money. All that is besides the point, as you cannot predict that every PSAP will have a relationship with every access network within its jurisdiction. I know we've been over this time and again on this mailing list, but wishing that these multitude of entities will get together in a harmonious administrative effort is just that, wishing. If human nature worked like that, PGP would be a universally accepted technology. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 03:19:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He4RN-0007MV-Aa; Wed, 18 Apr 2007 03:18:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He4RM-0007MN-FQ for ecrit@ietf.org; Wed, 18 Apr 2007 03:18:56 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1He4RL-0006mI-2o for ecrit@ietf.org; Wed, 18 Apr 2007 03:18:56 -0400 Received: (qmail invoked by alias); 18 Apr 2007 07:12:14 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp032) with SMTP; 18 Apr 2007 09:12:14 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/VZPBVhZXVFEp0D1wpjMxgdCSYvNSfjpKFtu/XY7 IFXI260I1D3I+F Message-ID: <4625C4CC.9050406@gmx.net> Date: Wed, 18 Apr 2007 09:12:12 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: AW: [Ecrit] Solution Approaches References: <182C63BFBAF131428EA0C16F7FD2191B013584B6@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ecrit@ietf.org, "Liess, Laura" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Henning, ~snip~ > > While this works in some way, this has clear drawbacks and consequences: > > - It requires a national ESRP. > That's the main disadvantage of the approach. If you only have the country code available then you essentially need to fall-back to such a concept. For cases where you have more location information available you obviously do not need to route your calls through this ESRP. ~snip Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 04:16:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He5L1-0003pO-48; Wed, 18 Apr 2007 04:16:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He5Ky-0003nR-Ls for ecrit@ietf.org; Wed, 18 Apr 2007 04:16:24 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1He5Kx-0000as-T5 for ecrit@ietf.org; Wed, 18 Apr 2007 04:16:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Solution Approaches Date: Wed, 18 Apr 2007 10:16:19 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D46646E18@oefeg-s04.oefeg.loc> In-Reply-To: <182C63BFBAF131428EA0C16F7FD2191B013584B6@S4DE8PSAAGM.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Solution Approaches Thread-Index: AceA0IFqiJkGNc2wR5azqP4bVp3ysQANaSewACLh5SA= From: "Stastny Richard" To: "Liess, Laura" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Laura, In your proposal, you have one ESRP per country (or state)? Or am I missing something? Richard > -----Original Message----- > From: Liess, Laura [mailto:Laura.Liess@t-systems.com] > Sent: Tuesday, April 17, 2007 5:37 PM > To: Hannes.Tschofenig@gmx.net; ecrit@ietf.org > Subject: AW: [Ecrit] Solution Approaches >=20 >=20 > Hannes, >=20 > thanks a lot for putting the whole discussion together. >=20 > I can not give you a feedback which is agreed within DT (the internal > agreement process would probably take some time). But I roughly = discussed > the approaches with people working on emergency calling. If we = understood > the proposal correctly, we have a strong preference for the approach > number 8), which could work as follows: >=20 > The ASP/ISP provides to the client the LbyR, the country code (or = country > and state codes)and the local EC dial string (at login and whenever = these > data change). > The client queries LOST and gets back an ESRP URI. > When the caller dials the emergency calling number, the client queries > again the ASP/VSP for the LbyR and the country code and LOST query for = the > ESRP URI. The VSP routes the call to the ESRP. The ESRP has a shared > secret with the LIS, gets the user location and the correct PSAP and > routes the call with the location info to the PSAP (TLS required). = (ESRP > or a local LOST does load balancing for PSAPs an all this stuff). >=20 > Alternatively, the VSPs SIP proxy can do the LOST queries. >=20 >=20 > Laura >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Gesendet: Dienstag, 17. April 2007 11:12 > > An: ECRIT > > Betreff: [Ecrit] Solution Approaches > > > > > > Hi all, > > > > I would like to share some potential solution approaches with you to > > deal with the problem of not providing precise location to > > the end host. > > I had a chance to discuss these aspects with Henning > > face-to-face last > > Friday. Here is a short summary. > > > > Note that the goal was to avoid some form of relationship (e.g., > > business relationship) between the VSP and the ASP/ISP (since > > this would > > impose a significant deployment problem). > > > > 1) Provide enough location information so that the emergency > > call can be > > routed to the correct PSAP. Precise location information would be > > provided to the PSAP. > > This approach was already discussed on the list. We need > > feedback from, > > for example, Barbara and Laura whether they feel comfortable > > with this > > approach. > > > > CONSEQUENCE: No changes needed. > > > > 2) Provide LbyR + Dial String + PSAP URI to the end host. > > We could ignore the potential security vulnerabilities if > > charging does > > not work on a call-by-call basis. > > > > CONSEQUENCE: No changes needed. > > > > 3) Provide LbyR + Dial String + PSAP URI to the end host. VSP does a > > reverse LoST lookup to verify the PSAP URI. > > > > CONSEQUENCE: Solution needs to be developed. > > > > 4) Provide LbyR + Dial String + PSAP URI to the end host. VSP > > verifies > > the PSAP URI with the PSAP URIs being flooded (using the LoST > > synchronization mechanism). This mechanism is potentially > > similar to (3) > > -- details might vary. (3) might use a distributed approach > > whereas this > > is brute force. > > > > CONSEQUENCE: Solution needs to be developed. > > > > 5) Emergency calls are routed via the SIP proxy of the VSP and > > subsequently via a SIP proxy in the ASP/ISP (redirect mode) > > SIP Location Conveyance would be used instead of GEOPRIV L7 LCP > > Assumption: No service level agreement (or business > > agreement) between > > VSP and ISP/ASP for this type of SIP emergency message > > routing required. > > > > CONSEQUENCE: No changes needed. Potential problems with SIP Identity > > possible > > > > 6) Emergency calls are routed via the SIP proxy of the VSP and > > subsequently via a SIP proxy in the ASP/ISP (no redirect > > mode) SIP Location Conveyance would be used instead of GEOPRIV L7 = LCP > > Assumption: No service level agreement (or business > > agreement) between > > VSP and ISP/ASP for this type of SIP emergency message > > routing required. > > > > CONSEQUENCE: No changes needed. > > > > 7) Decoupled authentication for SIP message routing > > Authentication exchange between the end host and the VSP > > (e.g., TLS to > > obtain a SAML assertion) > > Authentication credentials are then added to the SIP > > emergency message > > that is routed via the SIP proxy in the VSP/ISP. > > No service level agreement (or business agreement) between VSP and > > ISP/ASP needed. > > > > CONSEQUENCE: Security extension for this purpose needs to be > > progressed > > (already available in draft form) > > > > 8) Country Code Routing > > > > LIS provides country code to the end host. The end host > > routes the SIP > > emergency message via the VSP towards a ESRP that corresponds to the > > country code. Then, ESRP fetches more detailed location > > information todo > > routing within the country. > > > > CONSEQUENCE: No changes to the protocol mechanisms. > > Deployment of ESRPs > > that work this way are needed. Establishment of ESRP <-> > > ISP/ASP is more > > difficult than with PSAP <-> ISP/ASP since there are far more > > nodes to > > consider. > > > > 9) Assume end hosts have certs for emergency services; > > routing via SIP > > proxy in ISP/ASP without traversing VSP in the emergency > > case. Existing credential infrastructure can be used when > > utilizing SIP Cert. > > > > CONSEQUENCE: Architectural aspects need to be developed. A little = bit > > more difficult to deploy for VSP. Potential issues with callback (to > > AoR) since end host is not registered with VSP. > > > > 10) Routing via SIP proxy in ISP/ASP. Diameter SIP > > application used to > > authenticate end host > > Assumption: No roaming agreement assumed for ISP/ASP <-> VSP = Diameter > > SIP interaction. > > > > CONSEQUENCE: Problems with legacy credentials, previously > > mentioned call > > back problems since end host is not registered with VSP, Diameter = SIP > > application would need to be profiled. > > > > Thoughts? > > > > Ciao > > Hannes > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 04:42:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He5k2-0003HS-98; Wed, 18 Apr 2007 04:42:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He5k1-0003HN-Br for ecrit@ietf.org; Wed, 18 Apr 2007 04:42:17 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1He5k0-0006jq-OE for ecrit@ietf.org; Wed, 18 Apr 2007 04:42:17 -0400 Received: (qmail invoked by alias); 18 Apr 2007 08:42:15 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp034) with SMTP; 18 Apr 2007 10:42:15 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+XlcJiMtyX8VSPi/MESwyipqxso4JW5EUWnKXgNy 2BSc0vAs5zlu/7 Message-ID: <4625D9E6.7000505@gmx.net> Date: Wed, 18 Apr 2007 10:42:14 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Ecrit] Solution Approaches References: <32755D354E6B65498C3BD9FD496C7D46646E18@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46646E18@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: ecrit@ietf.org, "Liess, Laura" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Yes. (but it does not need to be a single physical box) Stastny Richard wrote: > Laura, > > In your proposal, you have one ESRP per country (or state)? > > Or am I missing something? > > Richard > > >> -----Original Message----- >> From: Liess, Laura [mailto:Laura.Liess@t-systems.com] >> Sent: Tuesday, April 17, 2007 5:37 PM >> To: Hannes.Tschofenig@gmx.net; ecrit@ietf.org >> Subject: AW: [Ecrit] Solution Approaches >> >> >> Hannes, >> >> thanks a lot for putting the whole discussion together. >> >> I can not give you a feedback which is agreed within DT (the internal >> agreement process would probably take some time). But I roughly discussed >> the approaches with people working on emergency calling. If we understood >> the proposal correctly, we have a strong preference for the approach >> number 8), which could work as follows: >> >> The ASP/ISP provides to the client the LbyR, the country code (or country >> and state codes)and the local EC dial string (at login and whenever these >> data change). >> The client queries LOST and gets back an ESRP URI. >> When the caller dials the emergency calling number, the client queries >> again the ASP/VSP for the LbyR and the country code and LOST query for the >> ESRP URI. The VSP routes the call to the ESRP. The ESRP has a shared >> secret with the LIS, gets the user location and the correct PSAP and >> routes the call with the location info to the PSAP (TLS required). (ESRP >> or a local LOST does load balancing for PSAPs an all this stuff). >> >> Alternatively, the VSPs SIP proxy can do the LOST queries. >> >> >> Laura >> >> >> >>> -----Ursprüngliche Nachricht----- >>> Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Gesendet: Dienstag, 17. April 2007 11:12 >>> An: ECRIT >>> Betreff: [Ecrit] Solution Approaches >>> >>> >>> Hi all, >>> >>> I would like to share some potential solution approaches with you to >>> deal with the problem of not providing precise location to >>> the end host. >>> I had a chance to discuss these aspects with Henning >>> face-to-face last >>> Friday. Here is a short summary. >>> >>> Note that the goal was to avoid some form of relationship (e.g., >>> business relationship) between the VSP and the ASP/ISP (since >>> this would >>> impose a significant deployment problem). >>> >>> 1) Provide enough location information so that the emergency >>> call can be >>> routed to the correct PSAP. Precise location information would be >>> provided to the PSAP. >>> This approach was already discussed on the list. We need >>> feedback from, >>> for example, Barbara and Laura whether they feel comfortable >>> with this >>> approach. >>> >>> CONSEQUENCE: No changes needed. >>> >>> 2) Provide LbyR + Dial String + PSAP URI to the end host. >>> We could ignore the potential security vulnerabilities if >>> charging does >>> not work on a call-by-call basis. >>> >>> CONSEQUENCE: No changes needed. >>> >>> 3) Provide LbyR + Dial String + PSAP URI to the end host. VSP does a >>> reverse LoST lookup to verify the PSAP URI. >>> >>> CONSEQUENCE: Solution needs to be developed. >>> >>> 4) Provide LbyR + Dial String + PSAP URI to the end host. VSP >>> verifies >>> the PSAP URI with the PSAP URIs being flooded (using the LoST >>> synchronization mechanism). This mechanism is potentially >>> similar to (3) >>> -- details might vary. (3) might use a distributed approach >>> whereas this >>> is brute force. >>> >>> CONSEQUENCE: Solution needs to be developed. >>> >>> 5) Emergency calls are routed via the SIP proxy of the VSP and >>> subsequently via a SIP proxy in the ASP/ISP (redirect mode) >>> SIP Location Conveyance would be used instead of GEOPRIV L7 LCP >>> Assumption: No service level agreement (or business >>> agreement) between >>> VSP and ISP/ASP for this type of SIP emergency message >>> routing required. >>> >>> CONSEQUENCE: No changes needed. Potential problems with SIP Identity >>> possible >>> >>> 6) Emergency calls are routed via the SIP proxy of the VSP and >>> subsequently via a SIP proxy in the ASP/ISP (no redirect >>> mode) SIP Location Conveyance would be used instead of GEOPRIV L7 LCP >>> Assumption: No service level agreement (or business >>> agreement) between >>> VSP and ISP/ASP for this type of SIP emergency message >>> routing required. >>> >>> CONSEQUENCE: No changes needed. >>> >>> 7) Decoupled authentication for SIP message routing >>> Authentication exchange between the end host and the VSP >>> (e.g., TLS to >>> obtain a SAML assertion) >>> Authentication credentials are then added to the SIP >>> emergency message >>> that is routed via the SIP proxy in the VSP/ISP. >>> No service level agreement (or business agreement) between VSP and >>> ISP/ASP needed. >>> >>> CONSEQUENCE: Security extension for this purpose needs to be >>> progressed >>> (already available in draft form) >>> >>> 8) Country Code Routing >>> >>> LIS provides country code to the end host. The end host >>> routes the SIP >>> emergency message via the VSP towards a ESRP that corresponds to the >>> country code. Then, ESRP fetches more detailed location >>> information todo >>> routing within the country. >>> >>> CONSEQUENCE: No changes to the protocol mechanisms. >>> Deployment of ESRPs >>> that work this way are needed. Establishment of ESRP <-> >>> ISP/ASP is more >>> difficult than with PSAP <-> ISP/ASP since there are far more >>> nodes to >>> consider. >>> >>> 9) Assume end hosts have certs for emergency services; >>> routing via SIP >>> proxy in ISP/ASP without traversing VSP in the emergency >>> case. Existing credential infrastructure can be used when >>> utilizing SIP Cert. >>> >>> CONSEQUENCE: Architectural aspects need to be developed. A little bit >>> more difficult to deploy for VSP. Potential issues with callback (to >>> AoR) since end host is not registered with VSP. >>> >>> 10) Routing via SIP proxy in ISP/ASP. Diameter SIP >>> application used to >>> authenticate end host >>> Assumption: No roaming agreement assumed for ISP/ASP <-> VSP Diameter >>> SIP interaction. >>> >>> CONSEQUENCE: Problems with legacy credentials, previously >>> mentioned call >>> back problems since end host is not registered with VSP, Diameter SIP >>> application would need to be profiled. >>> >>> Thoughts? >>> >>> Ciao >>> Hannes >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 05:35:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He6Zg-0001Hv-3H; Wed, 18 Apr 2007 05:35:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He6Zf-0001Hc-BI for ecrit@ietf.org; Wed, 18 Apr 2007 05:35:39 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1He6Ze-0003et-22 for ecrit@ietf.org; Wed, 18 Apr 2007 05:35:39 -0400 Received: (qmail invoked by alias); 18 Apr 2007 09:35:37 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp047) with SMTP; 18 Apr 2007 11:35:37 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19K0tkIHCxKFmYTtbxy9oplzRyewB7dW6/qV5T9YZ 9iGYr0/Q3v4JaQ Message-ID: <4625E668.1000803@gmx.net> Date: Wed, 18 Apr 2007 11:35:36 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) 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-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Ecrit] Meeting Minutes X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, please take a look at the meeting minutes: http://www3.ietf.org/proceedings/07mar/minutes/ecrit.txt Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 05:57:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He6v0-000740-V2; Wed, 18 Apr 2007 05:57:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He6uz-00073p-B3 for ecrit@ietf.org; Wed, 18 Apr 2007 05:57:41 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1He6ux-0002pi-Tx for ecrit@ietf.org; Wed, 18 Apr 2007 05:57:41 -0400 Received: (qmail invoked by alias); 18 Apr 2007 09:57:38 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp036) with SMTP; 18 Apr 2007 11:57:38 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18cD34NGe4cHy/MzhMkiywjc0E/NjkmZp0JbeEv9w M4KYqnTIg90yOr Message-ID: <4625EB92.7040502@gmx.net> Date: Wed, 18 Apr 2007 11:57:38 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) 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-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Ecrit] IETF / ECRIT Meeting Minutes X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, Roger took some notes during our meeting. It would, however, be great if someone else could share their notes with me so that I can complete them: MONDAY, 3/19/07 IETF68 11:30am IEEE/ECRIT Emergency Svcs. Special Meeting -- Peter Blatherwick, LLDP-MED overview pres. - mentioned some NENA location req's not able to meet (e.g., MUST not require equipment upgrade) - (Peter will make a list known) -- Dan: IEEE 802.1ABrev - "Fast Start" - allows end-devices and base stations to exchange info w/o waiting for the other. Q What about triangulation? - Bernard (Wireless 802.) 802 (k) will convey location (geospatial only), which is incompatible with RFC3825 - Dorothy, draft std. has some triangulation mechanisms defined and fairly stable. (w and v) - Dorothy, 802.11w security encryption ok for data, but not for management or control frames (subject to further redo later) -- Peter, IEEE 802.3at "PoE Plus" at last Plenary, some decisions (?) made - certain amount of adoption. -- Dorothy Stanley, IEEE 802.11 (Pres. By Steve McCann + 802.21 media handover group) - Note: 802.P (Vehicular, automotive - whole separate work) - location determination and callback number they've heard as requirements - call integrity - slide 802.11 emergency call setup STA --- AP - unauthenticated access vs. credentialed access - emergency caller must be able to be supported via either (hot topic). - Location - Request/Response paradigm - client can ask where am I? and where is the station? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 06:00:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He6xJ-0008Ns-0n; Wed, 18 Apr 2007 06:00:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He6xH-0008Nk-NC for ecrit@ietf.org; Wed, 18 Apr 2007 06:00:03 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1He6xH-0003Dg-A2 for ecrit@ietf.org; Wed, 18 Apr 2007 06:00:03 -0400 Received: (qmail invoked by alias); 18 Apr 2007 10:00:02 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp053) with SMTP; 18 Apr 2007 12:00:02 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/X6UsG6RPXZXU+uBQTl8I+yH1SPSuFhQu3gFmUZk QIxvv9BcdsaRFu Message-ID: <4625EC21.1040003@gmx.net> Date: Wed, 18 Apr 2007 12:00:01 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ECRIT References: <4625EB92.7040502@gmx.net> In-Reply-To: <4625EB92.7040502@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Ecrit] IETF#68: IETF ECRIT - IEEE Meeting Minutes X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Wrong subject header... Hannes Tschofenig wrote: > Hi all, > > Roger took some notes during our meeting. It would, however, be great > if someone else could share their notes with me so that I can complete > them: > > MONDAY, 3/19/07 IETF68 > > 11:30am IEEE/ECRIT Emergency Svcs. Special Meeting > -- Peter Blatherwick, LLDP-MED overview pres. > - mentioned some NENA location req's not able to meet (e.g., MUST not > require equipment upgrade) > - (Peter will make a list known) > -- Dan: IEEE 802.1ABrev > - "Fast Start" - allows end-devices and base stations to exchange info > w/o waiting for the other. > Q What about triangulation? > - Bernard (Wireless 802.) 802 (k) will convey location (geospatial > only), which is incompatible with RFC3825 > - Dorothy, draft std. has some triangulation mechanisms defined and > fairly stable. (w and v) > - Dorothy, 802.11w security encryption ok for data, but not for > management or control frames (subject to further redo later) > -- Peter, IEEE 802.3at "PoE Plus" at last Plenary, some decisions (?) > made - certain amount of adoption. > -- Dorothy Stanley, IEEE 802.11 (Pres. By Steve McCann + 802.21 media > handover group) > - Note: 802.P (Vehicular, automotive - whole separate work) > - location determination and callback number they've heard as > requirements > - call integrity > - slide 802.11 emergency call setup STA --- AP > - unauthenticated access vs. credentialed access - emergency caller must > be able to be supported via either (hot topic). > - Location > - Request/Response paradigm > - client can ask where am I? and where is the station? > > > Ciao > Hannes > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 06:40:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He7ab-0007uP-F4; Wed, 18 Apr 2007 06:40:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He7aa-0007uK-Km for ecrit@ietf.org; Wed, 18 Apr 2007 06:40:40 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He7aZ-0004wY-5Z for ecrit@ietf.org; Wed, 18 Apr 2007 06:40:40 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 18 Apr 2007 12:40:38 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 12:40:35 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: AW: AW: [Ecrit] Solution Approaches Date: Wed, 18 Apr 2007 12:40:34 +0200 Message-Id: <182C63BFBAF131428EA0C16F7FD2191B013584BC@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <4B859B7A-D560-4FFF-907E-1510CE7EC713@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: AW: [Ecrit] Solution Approaches thread-index: AceBNavGIl7v1xSlRPm2vLIiO/umwQAakZHw From: "Liess, Laura" To: X-OriginalArrivalTime: 18 Apr 2007 10:40:35.0010 (UTC) FILETIME=[FEF05A20:01C781A5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org As far as I understood, the problem is not buying the web server, but = the todays T-Com Infrastructure being distributed between many different = databases from different manufacturers, operated by different DT = departaments, a lot of interfaces (many proprietary). It seems to be = quite costly to change this, at least this is what I was told (I don't = work myself in this area, so I have to believe what they tell me...).=20 Sorry for not having better news... > -----Urspr=FCngliche Nachricht----- > Von: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Gesendet: Dienstag, 17. April 2007 23:18 > An: Liess, Laura > Cc: ecrit@ietf.org > Betreff: Re: AW: AW: [Ecrit] Solution Approaches >=20 >=20 >=20 > On Apr 17, 2007, at 4:51 PM, Liess, Laura wrote: >=20 > > > > I am aware of the drawbacks. But I didn't see any other solution we > > can live with. Not only because of the location hiding issue, but =20 > > also because providing a more accurate location information for =20 > > every end device requires much more performant mechanisms than =20 > > those we have today. Today, the location information is=20 > provided by =20 > > the system only for emergency calls where the caller is not=20 > able to =20 > > talk to the call taker. Providing it at every login is another =20 > > order of magnitude. I was told that replacing the current=20 > mechanism =20 > > requires changes in the whole backend infrastructure and=20 > would cost =20 > > millions. Nobody is willing to spend so much money without a =20 > > business case. > > >=20 > I obviously don't know the DT infrastructure, but I'm having a hard =20 > time believing the 'millions' part. A low-end web server can handle =20 > hundreds of request a second, particularly of the simple kind needed =20 > for HELD and similar protocols. Let's just say 100=20 > requests/sec. (Our =20 > LoST server handles 180 req/sec., including a more elaborate=20 > database =20 > lookup.) This yields roughly 8 million customers for each server, =20 > assuming a once-a-day login (obviously, most hard phones and ATA =20 > devices would remain connected for much longer, without a=20 > reboot, but =20 > I don't know what the ratio between soft and hardphones would=20 > be. Our =20 > hard phones get rebooted when there's a software update, every six =20 > months or so.). Even assuming that DT has 80 million DSL customers =20 > that have VoIP, this would be ten servers, which cost (retail, with =20 > bandwidth and server rental) about $2000/month. Or, expressed =20 > differently, the incremental cost per customer is $0.000025 per month. >=20 > I realize that there's a software development cost, but I'm =20 > suspecting that this isn't affected much by how often the system is =20 > being queried. >=20 > If you'll pay millions for this server infrastructure, maybe=20 > I should =20 > offer our implementation services to DT... >=20 > (Here, the modern server could simply be the caching front-end for =20 > the existing system.) >=20 > Henning=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 07:32:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He8P8-0002ps-Ry; Wed, 18 Apr 2007 07:32:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He8P7-0002pb-Ch; Wed, 18 Apr 2007 07:32:53 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He8P5-0003z2-TX; Wed, 18 Apr 2007 07:32:53 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1He8Ov-0006Cz-8m; Wed, 18 Apr 2007 06:32:41 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Henning Schulzrinne'" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCP without giving away the store Date: Wed, 18 Apr 2007 07:32:47 -0400 Message-ID: <0e8101c781ad$4c161770$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceATWtuX3mauUovRdW4EH9bQXy2UABQGASgAAeeaWA= In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: geopriv@ietf.org, "Rosen, Brian" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Congestion at the PSAP is much less likely in next generation emergency calling networks. They will be designed to handle this kind of event much better than current ones. Calls will be able to be answered by other PSAPs. The goal is to build the networks such that in events larger than the "Katrina" disaster, all calls can be answered. Conventional networks may indeed congest, and of course IP networks can congest. We will have capacity for tens of thousands of calls to be answered simultaneously. That is millions per hour. All networks have limits, and these will too, but they will be orders of magnitude larger than they are now. Whether, and in what conditions, these facilities are used will be local decisions, but the networks will be designed to be able to answer every call that gets to the emergency services IP network. The emergency services networks will have call admission controls, and the media capacity will figure into these admission controls. We would like DiffServ marking of emergency calls, and slight priority over normal network traffic for them, but don't expect that most access networks would provide that. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Wednesday, April 18, 2007 3:52 AM > To: Henning Schulzrinne > Cc: geopriv@ietf.org; Rosen, Brian; ecrit@ietf.org > Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > doendpointcentric LCP without giving away the store > > The circumstances you detail are more likely to have an impact on the > ability to make calls at all. Significant congestion or disruptions to > quality of service in the access network are likely to render media > streams inoperative before they break the simple act of location > retrieval. > > There is an analog in cellular. Mass-calling events arising from > significant localized emergency events cause congestion in the serving > cells of those networks as well. Before they do that, however, they > cause congestion at the serving PSAP(s). > > Cheers, > Martin > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, 17 April 2007 3:35 AM > To: Dawson, Martin > Cc: Rosen, Brian; geopriv@ietf.org; ecrit@ietf.org > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do > endpointcentric LCP without giving away the store > > Location determination is not likely to be the major delaying factor, > although it can be under the wrong circumstances. If there's even > modest packet loss, any TCP connection establishment can be delayed > significantly, due to the exponential backoff retry. We'd have to do > 2 such lookups (L7 and LoST), plus DNS to resolve the LoST-returned > URL. Thus, we're talking roughly 10 round trip times (2 handshakes > for TCP, 2 query/response for LoST and L7, plus one round trip for > DNS). The initial TCP timeout is 500 ms, if I recall correctly and so > is the DNS timeout, both with exponential backoff.) > > I'm particularly concerned with mass casualty events, where the > infrastructure is under duress. Most of the time, none of this will > be problem; however, even with modest packet loss rates, there will > be a significant fraction of calls experiencing delays of one or more > seconds, which are indeed significant based on the performance > requirements we were given by the PSAP community. > > The critical timing is determining rough location and the URL lookup; > this can all be done ahead of the call with no loss of accuracy. > Thus, delaying PSAP URI determination until call time will indeed > degrade the timeliness of emergency calls. > > Henning > > On Apr 16, 2007, at 1:08 PM, Dawson, Martin wrote: > > > I really can't buy into the "significantly degrades > > performance/reliability" argument. > > > > Actually, I think that not doing it at call-initiation may cause the > > more significant degradation. > > > > It can't be assumed that the device "knows" that it's not mobile. As > > Brian mentioned, using Ethernet on a mobile platform (camper, train, > > plane...) make mobility invisible to the device. > > > > I can't imagine any sensibly implemented wireline access location > > technology that would impose anything more significant than sub-second > > response for maximal accuracy. For mobile networks, it may take > > longer - > > but it's exactly for mobile networks that it's preferable to determine > > location as close as possible to call origination time (just as is > > done > > in cellular today). > > > > I suppose that BCP could state that, in the absence of an updated > > location at the time of the call within the time required, the device > > may use the last-known location. That is an optimization and not a > > fundamental principle. A well defined fallback procedure should always > > be in place. > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Tuesday, 17 April 2007 2:54 AM > > To: Rosen, Brian > > Cc: Dawson, Martin; geopriv@ietf.org; ecrit@ietf.org > > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how > > to do > > endpointcentric LCP without giving away the store > > > > > > On Apr 16, 2007, at 12:14 PM, Rosen, Brian wrote: > > > >> Right. Good summary. > >> > >> However, because at least some networks have to get through Pay to > >> Play, > >> we need to provide mechanisms that work. > >> > >> The proposal (access networks that want pay to play must provide > >> LbyR, > >> PSAP URI and dialstrings seems a workable solution to those networks. > > > > This only works for stationary devices, barely, unless there's an > > event notification mechanism that updates that information, > > particularly the PSAP URL. > > > > Otherwise, you have to rely on call-time queries, which significantly > > degrade reliability and performance. In that case, you're not > > providing a service that is equivalent and the customer pays for the > > provider's pay-to-play dreams with their life and property. > > > > Henning > > > > ---------------------------------------------------------------------- > > > -------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > ---------------------------------------------------------------------- > > > -------------------------- > > [mf2] > > > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 07:34:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He8QE-00032s-Av; Wed, 18 Apr 2007 07:34:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He8QD-00032j-Oi; Wed, 18 Apr 2007 07:34:01 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He8QD-0004Dn-Dy; Wed, 18 Apr 2007 07:34:01 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns1.neustar.com (Postfix) with ESMTP id 33E0226EB2; Wed, 18 Apr 2007 11:34:01 +0000 (GMT) Received: from stntexch12.cis.neustar.com ([10.31.13.31]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 07:34:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCP without giving away the store Date: Wed, 18 Apr 2007 07:33:59 -0400 Message-ID: <886DD03D15173C43BCE98EA662A0101A01EB79CE@stntexch12.cis.neustar.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCP without giving away the store Thread-Index: AceASbiEZRLwAFJNTMapAQu8k4vgJQAAexMgAFC/HrAAB7BdAA== From: "Rosen, Brian" To: "Dawson, Martin" , "Brian Rosen" , "Henning Schulzrinne" X-OriginalArrivalTime: 18 Apr 2007 11:34:01.0116 (UTC) FILETIME=[75ED4DC0:01C781AD] X-Spam-Score: -2.8 (--) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: geopriv@ietf.org, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Yah, the PSAP URI is "by value" as much as any URI is by value. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Wednesday, April 18, 2007 3:55 AM > To: Brian Rosen; Henning Schulzrinne; Rosen, Brian > Cc: geopriv@ietf.org; ecrit@ietf.org > Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > doendpointcentric LCP without giving away the store >=20 > I certainly think that it's most optimal to get both location and PSAP > URI at the time of the call. I don't think anyone has suggested that the > PSAP URI should be provided "by reference" (right?) - it pretty much is > a reference anyway... >=20 > Cheers, > Martin >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, 17 April 2007 3:36 AM > To: 'Henning Schulzrinne'; Rosen, Brian > Cc: geopriv@ietf.org; Dawson, Martin; ecrit@ietf.org > Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > doendpointcentric LCP without giving away the store >=20 > Okay, let's look at this. >=20 > For fixed devices, the PSAP URI doesn't change often, the cached value > is > very likely to be good. However, it MIGHT change on short notice. The > call > time query fixes this, if it works. >=20 > For mobile devices, the endpoint may get a reference. The REFERENCE > doesn't > change. It's good for a long time (probably as long as the carrier - > subscriber relationship holds). If it gets a value, then it wants an > update > when it moves beyond the PSAP boundary. With a value, it queries LoST > and > gets the boundary, then passes that to its location determination > mechanism > and asks for a notification when it moves beyond that. >=20 > The above, of course, is fairly far from what IMS currently talks about, > but > that is what the IETF ecrit/presence architecture would say. >=20 > If the access network plays cozy with the location, so it passes a > reference > and a PSAP URI, then it needs a way to TELL the device when the PSAP URI > is > no longer valid. Perhaps we could define a SIP event package for this > purpose, so a LIS could notify an endpoint of a new PSAP URI when its > current location warranted that. I suppose this is a presence thing, > and > maybe we could tie this more strongly into the existing presence system. >=20 > Brian >=20 >=20 >=20 > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Monday, April 16, 2007 12:54 PM > > To: Rosen, Brian > > Cc: geopriv@ietf.org; Dawson, Martin; ecrit@ietf.org > > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > > doendpointcentric LCP without giving away the store > > > > > > On Apr 16, 2007, at 12:14 PM, Rosen, Brian wrote: > > > > > Right. Good summary. > > > > > > However, because at least some networks have to get through Pay to > > > Play, > > > we need to provide mechanisms that work. > > > > > > The proposal (access networks that want pay to play must provide > LbyR, > > > PSAP URI and dialstrings seems a workable solution to those > networks. > > > > This only works for stationary devices, barely, unless there's an > > event notification mechanism that updates that information, > > particularly the PSAP URL. > > > > Otherwise, you have to rely on call-time queries, which significantly > > degrade reliability and performance. In that case, you're not > > providing a service that is equivalent and the customer pays for the > > provider's pay-to-play dreams with their life and property. > > > > Henning > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv >=20 >=20 > ------------------------------------------------------------------------ -- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ -- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 07:38:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He8UN-00077J-Vy; Wed, 18 Apr 2007 07:38:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He8UN-000778-D4; Wed, 18 Apr 2007 07:38:19 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He8UN-0004o8-02; Wed, 18 Apr 2007 07:38:19 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1He8UC-0006Uz-GH; Wed, 18 Apr 2007 06:38:08 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Hannes Tschofenig'" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpoint centric LCP without giving away the store Date: Wed, 18 Apr 2007 07:38:14 -0400 Message-ID: <0e8201c781ae$0f290e70$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceAuFdHC4RIh1ZXSxGMgvUps/g6egAWcIowAB+6zmAAByVwQA== In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: geopriv@ietf.org, "Rosen, Brian" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Well, there is no place yet. We'd have to make one. Let's first get consensus if that's the approach we want, and then we can discuss the best way to do it. It would affect the LCP and -conveyance directly or indirectly, although there are many ways to carry it from endpoint to the VSP. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Wednesday, April 18, 2007 4:12 AM > To: Brian Rosen; Hannes Tschofenig > Cc: geopriv@ietf.org; Rosen, Brian; ecrit@ietf.org > Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > doendpoint centric LCP without giving away the store > > Hi Brian > > "The country code is returned with the reference" - was that your > suggestion...? I might not have all the thread. > > I'm fine with that model - do we have conveyance support for this > information though? In SIP, where does the country code go? Does the > client construct a bare bones PIDF-LO? > > Cheers, > Martin > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, 18 April 2007 6:03 AM > To: 'Hannes Tschofenig' > Cc: geopriv@ietf.org; Rosen, Brian; ecrit@ietf.org > Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > doendpoint centric LCP without giving away the store > > No, I don't. > > I assume that the LoST server the VSP consults to validate contains the > same > URIs that the LoST server used by the access network LIS to determine > the > URI. The endpoint passes a URI to its VSP and claims it's a bona fide > PSAP > URI from LoST. As long as that URI is in the LoST server (directly or > via a > referral) that the VSP uses, validation is possible. > > If the attacker can insert bogus data into the global LoST database, > then we > couldn't detect it, but that is not threat here. > > The access network and the endpoint can collude all they want, but > unless > the LoST server the VSP uses has bad data, it can determine if the PSAP > URI > is a genuine PSAP URI. > > No relationship between the VSP and the access network is needed. > > Brian > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Tuesday, April 17, 2007 2:20 AM > > To: Brian Rosen > > Cc: Rosen, Brian; geopriv@ietf.org; ecrit@ietf.org > > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > do > > endpoint centric LCP without giving away the store > > > > Hence, it suffers from the same problems as the solution I proposed > > unless you assume a relationship between the VSP and the ISP/ASP. > > Do you? > > > > Ciao > > Hannes > > > > > > Brian Rosen wrote: > > > Back from a weekend of no Internet access and lots of email to > process: > > > > > > The country code is returned from the L7 LCP query when an LbyR is > > returned. > > > > > > The validation is done by the VSP when an emergency call is placed. > > > > > > Brian > > > > > > > > >> -----Original Message----- > > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > >> Sent: Saturday, April 14, 2007 12:02 PM > > >> To: Rosen, Brian > > >> Cc: geopriv@ietf.org; ecrit@ietf.org > > >> Subject: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do > > >> endpoint centric LCP without giving away the store > > >> > > >> Hi Brian, > > >> > > >> ~snip~ > > >> > > >>> Perhaps we include in the LoST return a country code for a query > with > > a > > >>> geo. We add a new operation to LoST that takes a service, a > country > > >>> code and a PSAP URI and returns yes/no validation ("Yes, that URI > is a > > >>> valid URI for that service in that country"). > > >>> > > >>> > > >> Please describe when the country code is returned and to whom. > > >> Who triggers the validation step? > > >> > > >> Ciao > > >> Hannes > > >> > > >> > > >> _______________________________________________ > > >> Geopriv mailing list > > >> Geopriv@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/geopriv > > >> > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 07:38:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He8UU-0007Y4-Rl; Wed, 18 Apr 2007 07:38:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He8US-0007QF-T9 for ecrit@ietf.org; Wed, 18 Apr 2007 07:38:24 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1He8US-0004pG-Cn for ecrit@ietf.org; Wed, 18 Apr 2007 07:38:24 -0400 Received: (qmail invoked by alias); 18 Apr 2007 11:38:23 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp024) with SMTP; 18 Apr 2007 13:38:23 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18tbBQIGuwtOE8R2ERF3+EvP46giO5FN88iKIsmpw BV8Bt+QwajvZza Message-ID: <4626032E.1090006@gmx.net> Date: Wed, 18 Apr 2007 13:38:22 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Rosen, Brian" Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCP without giving away the store References: <886DD03D15173C43BCE98EA662A0101A01EB79CE@stntexch12.cis.neustar.com> In-Reply-To: <886DD03D15173C43BCE98EA662A0101A01EB79CE@stntexch12.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: geopriv@ietf.org, "Dawson, Martin" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I am sure that someone will sooner or late get the idea that it would be nice not to disclose the URI of the PSAP and hence we should just return a reference to it. Ciao Hannes Rosen, Brian wrote: > Yah, the PSAP URI is "by value" as much as any URI is by value. > > Brian > > >> -----Original Message----- >> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] >> Sent: Wednesday, April 18, 2007 3:55 AM >> To: Brian Rosen; Henning Schulzrinne; Rosen, Brian >> Cc: geopriv@ietf.org; ecrit@ietf.org >> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to >> doendpointcentric LCP without giving away the store >> >> I certainly think that it's most optimal to get both location and PSAP >> URI at the time of the call. I don't think anyone has suggested that >> > the > >> PSAP URI should be provided "by reference" (right?) - it pretty much >> > is > >> a reference anyway... >> >> Cheers, >> Martin >> >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Tuesday, 17 April 2007 3:36 AM >> To: 'Henning Schulzrinne'; Rosen, Brian >> Cc: geopriv@ietf.org; Dawson, Martin; ecrit@ietf.org >> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to >> doendpointcentric LCP without giving away the store >> >> Okay, let's look at this. >> >> For fixed devices, the PSAP URI doesn't change often, the cached value >> is >> very likely to be good. However, it MIGHT change on short notice. >> > The > >> call >> time query fixes this, if it works. >> >> For mobile devices, the endpoint may get a reference. The REFERENCE >> doesn't >> change. It's good for a long time (probably as long as the carrier - >> subscriber relationship holds). If it gets a value, then it wants an >> update >> when it moves beyond the PSAP boundary. With a value, it queries LoST >> and >> gets the boundary, then passes that to its location determination >> mechanism >> and asks for a notification when it moves beyond that. >> >> The above, of course, is fairly far from what IMS currently talks >> > about, > >> but >> that is what the IETF ecrit/presence architecture would say. >> >> If the access network plays cozy with the location, so it passes a >> reference >> and a PSAP URI, then it needs a way to TELL the device when the PSAP >> > URI > >> is >> no longer valid. Perhaps we could define a SIP event package for this >> purpose, so a LIS could notify an endpoint of a new PSAP URI when its >> current location warranted that. I suppose this is a presence thing, >> and >> maybe we could tie this more strongly into the existing presence >> > system. > >> Brian >> >> >> >> >>> -----Original Message----- >>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>> Sent: Monday, April 16, 2007 12:54 PM >>> To: Rosen, Brian >>> Cc: geopriv@ietf.org; Dawson, Martin; ecrit@ietf.org >>> Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to >>> doendpointcentric LCP without giving away the store >>> >>> >>> On Apr 16, 2007, at 12:14 PM, Rosen, Brian wrote: >>> >>> >>>> Right. Good summary. >>>> >>>> However, because at least some networks have to get through Pay to >>>> Play, >>>> we need to provide mechanisms that work. >>>> >>>> The proposal (access networks that want pay to play must provide >>>> >> LbyR, >> >>>> PSAP URI and dialstrings seems a workable solution to those >>>> >> networks. >> >>> This only works for stationary devices, barely, unless there's an >>> event notification mechanism that updates that information, >>> particularly the PSAP URL. >>> >>> Otherwise, you have to rely on call-time queries, which >>> > significantly > >>> degrade reliability and performance. In that case, you're not >>> providing a service that is equivalent and the customer pays for the >>> provider's pay-to-play dreams with their life and property. >>> >>> Henning >>> >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www1.ietf.org/mailman/listinfo/geopriv >>> >> >> > ------------------------------------------------------------------------ > -- > >> ---------------------- >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> >> > ------------------------------------------------------------------------ > -- > >> ---------------------- >> [mf2] >> > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 08:00:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He8pr-0005QH-Lm; Wed, 18 Apr 2007 08:00:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He8pc-0005CB-4w; Wed, 18 Apr 2007 08:00:16 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He8iO-0002Va-VL; Wed, 18 Apr 2007 07:52:49 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1He8iE-0007eH-3c; Wed, 18 Apr 2007 06:52:38 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "Rosen, Brian" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCP without giving away the store Date: Wed, 18 Apr 2007 07:52:44 -0400 Message-ID: <0e8601c781b0$15abdb40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceBrg5yaX8ixcsbQMOAEFQrOjhdrAAAPw+Q In-Reply-To: <4626032E.1090006@gmx.net> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: geopriv@ietf.org, "'Dawson, Martin'" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Actually, that is why the ESRP is there. It can obscure what PSAP actually gets the call. The argument that PSAPs want security by obscurity in this way has been asserted many times in NENA meetings. I have went so far as to get up in the front of the room with hundreds of technical and operational (NENA TDC/ODC general sessions) and ask if there were any PSAP people who believed this to please see me privately and explain. I have NEVER talked or heard of a PSAP who believed that his service area was a secret, or that some hiding of which calls go to them would be valuable. Now, several VENDORS asserted this was true, but so far, that assertion is, from my point of view, baseless. This gives rise to what the "PSAP URI" coming out of LoST when an ESRP is used really is. One possibility is: sip:psap@esrp.ny.us Another possibility is: sip:buffalo@esrp.ny.us In both cases, the esrp in New York state gets the call first. In the former, the esrp may need a LoST dip to determine which PSAP gets the call. In the latter, some policy decisions would need to be made, and in some circumstances a LoST dip, but in normal circumstances, the Buffalo, NY PSAP gets the call. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, April 18, 2007 7:38 AM > To: Rosen, Brian > Cc: Dawson, Martin; Brian Rosen; Henning Schulzrinne; geopriv@ietf.org; > ecrit@ietf.org > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > doendpointcentric LCP without giving away the store > > I am sure that someone will sooner or late get the idea that it would be > nice not to disclose the URI of the PSAP and hence we should just return > a reference to it. > > Ciao > Hannes > > Rosen, Brian wrote: > > Yah, the PSAP URI is "by value" as much as any URI is by value. > > > > Brian > > > > > >> -----Original Message----- > >> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > >> Sent: Wednesday, April 18, 2007 3:55 AM > >> To: Brian Rosen; Henning Schulzrinne; Rosen, Brian > >> Cc: geopriv@ietf.org; ecrit@ietf.org > >> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > >> doendpointcentric LCP without giving away the store > >> > >> I certainly think that it's most optimal to get both location and PSAP > >> URI at the time of the call. I don't think anyone has suggested that > >> > > the > > > >> PSAP URI should be provided "by reference" (right?) - it pretty much > >> > > is > > > >> a reference anyway... > >> > >> Cheers, > >> Martin > >> > >> -----Original Message----- > >> From: Brian Rosen [mailto:br@brianrosen.net] > >> Sent: Tuesday, 17 April 2007 3:36 AM > >> To: 'Henning Schulzrinne'; Rosen, Brian > >> Cc: geopriv@ietf.org; Dawson, Martin; ecrit@ietf.org > >> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > >> doendpointcentric LCP without giving away the store > >> > >> Okay, let's look at this. > >> > >> For fixed devices, the PSAP URI doesn't change often, the cached value > >> is > >> very likely to be good. However, it MIGHT change on short notice. > >> > > The > > > >> call > >> time query fixes this, if it works. > >> > >> For mobile devices, the endpoint may get a reference. The REFERENCE > >> doesn't > >> change. It's good for a long time (probably as long as the carrier - > >> subscriber relationship holds). If it gets a value, then it wants an > >> update > >> when it moves beyond the PSAP boundary. With a value, it queries LoST > >> and > >> gets the boundary, then passes that to its location determination > >> mechanism > >> and asks for a notification when it moves beyond that. > >> > >> The above, of course, is fairly far from what IMS currently talks > >> > > about, > > > >> but > >> that is what the IETF ecrit/presence architecture would say. > >> > >> If the access network plays cozy with the location, so it passes a > >> reference > >> and a PSAP URI, then it needs a way to TELL the device when the PSAP > >> > > URI > > > >> is > >> no longer valid. Perhaps we could define a SIP event package for this > >> purpose, so a LIS could notify an endpoint of a new PSAP URI when its > >> current location warranted that. I suppose this is a presence thing, > >> and > >> maybe we could tie this more strongly into the existing presence > >> > > system. > > > >> Brian > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>> Sent: Monday, April 16, 2007 12:54 PM > >>> To: Rosen, Brian > >>> Cc: geopriv@ietf.org; Dawson, Martin; ecrit@ietf.org > >>> Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > >>> doendpointcentric LCP without giving away the store > >>> > >>> > >>> On Apr 16, 2007, at 12:14 PM, Rosen, Brian wrote: > >>> > >>> > >>>> Right. Good summary. > >>>> > >>>> However, because at least some networks have to get through Pay to > >>>> Play, > >>>> we need to provide mechanisms that work. > >>>> > >>>> The proposal (access networks that want pay to play must provide > >>>> > >> LbyR, > >> > >>>> PSAP URI and dialstrings seems a workable solution to those > >>>> > >> networks. > >> > >>> This only works for stationary devices, barely, unless there's an > >>> event notification mechanism that updates that information, > >>> particularly the PSAP URL. > >>> > >>> Otherwise, you have to rely on call-time queries, which > >>> > > significantly > > > >>> degrade reliability and performance. In that case, you're not > >>> providing a service that is equivalent and the customer pays for the > >>> provider's pay-to-play dreams with their life and property. > >>> > >>> Henning > >>> > >>> _______________________________________________ > >>> Geopriv mailing list > >>> Geopriv@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/geopriv > >>> > >> > >> > > ------------------------------------------------------------------------ > > -- > > > >> ---------------------- > >> This message is for the designated recipient only and may > >> contain privileged, proprietary, or otherwise private information. > >> If you have received it in error, please notify the sender > >> immediately and delete the original. Any unauthorized use of > >> this email is prohibited. > >> > >> > > ------------------------------------------------------------------------ > > -- > > > >> ---------------------- > >> [mf2] > >> > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 08:14:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He93a-0006gy-EL; Wed, 18 Apr 2007 08:14:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He93Z-0006gk-AZ for ecrit@ietf.org; Wed, 18 Apr 2007 08:14:41 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He93Y-0001QJ-2H for ecrit@ietf.org; Wed, 18 Apr 2007 08:14:41 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3ICESp6022342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Apr 2007 08:14:33 -0400 (EDT) In-Reply-To: <182C63BFBAF131428EA0C16F7FD2191B013584BC@S4DE8PSAAGM.mitte.t-com.de> References: <182C63BFBAF131428EA0C16F7FD2191B013584BC@S4DE8PSAAGM.mitte.t-com.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <40CF3759-E54D-4C92-976C-A04FB28FEBDF@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: AW: AW: AW: [Ecrit] Solution Approaches Date: Wed, 18 Apr 2007 08:14:53 -0400 To: "Liess, Laura" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Given your description, I don't see how reducing the request rate is going to help, unless your system is essentially manual, i.e., an operator looks at various green-screen terminals and tries to figure out where somebody is. Otherwise, you could just export the information periodically to the modern infrastructure and never have the actual location request touch that infrastructure. (Existing US MSAGs and ALI databases are also not updated in real time, so such export would simply mimic the limitations of the existing infrastructure.) I have to admit that I find this discussion somewhat frustrating. We are discussing making major changes, reducing reliability and adding costs to everyone's implementation, based on second and third-hand information about infrastructure in one carrier, where it is not even clear that such changes will address the underlying root cause. Henning On Apr 18, 2007, at 6:40 AM, Liess, Laura wrote: > As far as I understood, the problem is not buying the web server, > but the todays T-Com Infrastructure being distributed between many > different databases from different manufacturers, operated by > different DT departaments, a lot of interfaces (many proprietary). > It seems to be quite costly to change this, at least this is what I > was told (I don't work myself in this area, so I have to believe > what they tell me...). > > Sorry for not having better news... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 08:23:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9Bj-0002UZ-Bc; Wed, 18 Apr 2007 08:23:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9Bh-0002TK-OT; Wed, 18 Apr 2007 08:23:05 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He9Bg-0005KW-IB; Wed, 18 Apr 2007 08:23:05 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3ICMmH4028118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Apr 2007 08:22:53 -0400 (EDT) In-Reply-To: <0e8201c781ae$0f290e70$640fa8c0@cis.neustar.com> References: <0e8201c781ae$0f290e70$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2CCBF497-7DEB-4912-970B-A6698627F1CC@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpoint centric LCP without giving away the store Date: Wed, 18 Apr 2007 08:23:13 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: GEOPRIV , Brian Rosen , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org PIDF-LO contains a country code, as does the DHCP civic format and thus LLDP-MED. Thus, I'm confused by your statement below. Henning On Apr 18, 2007, at 7:38 AM, Brian Rosen wrote: > Well, there is no place yet. We'd have to make one. > Let's first get consensus if that's the approach we want, and then > we can > discuss the best way to do it. > > It would affect the LCP and -conveyance directly or indirectly, > although > there are many ways to carry it from endpoint to the VSP. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 08:26:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9Em-0004dP-9H; Wed, 18 Apr 2007 08:26:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9Ek-0004cj-Tk; Wed, 18 Apr 2007 08:26:14 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He9Ej-0006q8-6S; Wed, 18 Apr 2007 08:26:14 -0400 Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id l3ICQ3Zi028053; Wed, 18 Apr 2007 14:26:03 +0200 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id l3ICPtiw013927; Wed, 18 Apr 2007 14:26:03 +0200 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 14:25: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 Subject: AW: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how todoendpoint centric LCP without giving away the store Date: Wed, 18 Apr 2007 14:25:33 +0200 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E701A29438@MCHP7R6A.ww002.siemens.net> In-Reply-To: <2CCBF497-7DEB-4912-970B-A6698627F1CC@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how todoendpoint centric LCP without giving away the store Thread-Index: AceBtFeFAeL/I5V3Q0ij8t+NjFGPfAAAD16A From: "Tschofenig, Hannes" To: "Henning Schulzrinne" , "Brian Rosen" X-OriginalArrivalTime: 18 Apr 2007 12:25:34.0120 (UTC) FILETIME=[A9804280:01C781B4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: GEOPRIV , Brian Rosen , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I don't see the impact either.=20 Particularly with this solution approach nothing needs to be done.=20 This is more a deployment consideration.=20 > -----Urspr=FCngliche Nachricht----- > Von: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Gesendet: Mittwoch, 18. April 2007 14:23 > An: Brian Rosen > Cc: GEOPRIV; Brian Rosen; ECRIT > Betreff: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on=20 > how todoendpoint centric LCP without giving away the store >=20 > PIDF-LO contains a country code, as does the DHCP civic format and =20 > thus LLDP-MED. Thus, I'm confused by your statement below. >=20 > Henning >=20 > On Apr 18, 2007, at 7:38 AM, Brian Rosen wrote: >=20 > > Well, there is no place yet. We'd have to make one. > > Let's first get consensus if that's the approach we want, and then =20 > > we can > > discuss the best way to do it. > > > > It would affect the LCP and -conveyance directly or indirectly, =20 > > although > > there are many ways to carry it from endpoint to the VSP. > > >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 08:32:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9Kg-000143-7w; Wed, 18 Apr 2007 08:32:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9Ke-0000v2-50; Wed, 18 Apr 2007 08:32:20 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He9Kc-00012a-UN; Wed, 18 Apr 2007 08:32:20 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3ICW801026309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Apr 2007 08:32:11 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9F962C82-4F2E-4AD9-ACBD-0DE6418E21DE@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to do endpointcentric LCP without giving away the store Date: Wed, 18 Apr 2007 08:32:34 -0400 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: geopriv@ietf.org, "Rosen, Brian" , ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org That is not true. You can still have an audio call at 10% packet loss, but you'll get a significant probability of the delays I mentioned at that point. During periods of stress, the more transactions you need to do, the higher the overall probability of failure. You might want to try this in a test bed with a loss emulator before making claims. The whole idea of going IP is to distribute the load among lots of PSAPs if there is a regional crisis, such as an earthquake or hurricane. We've discussed and had rough consensus on this long ago, so I'm surprised this comes up again. Maybe it's just convenient to ignore when it doesn't fit the agenda of hiding location. Henning On Apr 18, 2007, at 3:51 AM, Dawson, Martin wrote: > The circumstances you detail are more likely to have an impact on the > ability to make calls at all. Significant congestion or disruptions to > quality of service in the access network are likely to render media > streams inoperative before they break the simple act of location > retrieval. > > There is an analog in cellular. Mass-calling events arising from > significant localized emergency events cause congestion in the serving > cells of those networks as well. Before they do that, however, they > cause congestion at the serving PSAP(s). > > Cheers, > Martin _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 08:46:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9YA-0005E2-SY; Wed, 18 Apr 2007 08:46:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9Y9-0005Dr-BO for ecrit@ietf.org; Wed, 18 Apr 2007 08:46:17 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He9Y8-0006Hq-4c for ecrit@ietf.org; Wed, 18 Apr 2007 08:46:17 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1He9Y7-0007yo-5q for ecrit@ietf.org; Wed, 18 Apr 2007 08:46:15 -0400 Message-ID: <46261317.1070606@bbn.com> Date: Wed, 18 Apr 2007 08:46:15 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ecrit] A Concrete Proposal for LbyR Emergency Calling X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org As Hannes and Henning have pointed out, almost every proposal is going to require modifications to either LoST or the LCP(s). In light of that, ISTM that our goal should be to be "minimally invasive", i.e., to make the smallest number of changes to enable a reliable emergency calling function when location is only provisioned by reference. Here's my proposed set of changes: 1. Enable DHCP / LCP to convey a pointer to a LoST resolver (as is done with DNS servers within an access network) 2. Enable LoST to carry location-by-reference (possibly with an statement to limit applicability) A call flow would look something like this: 1. DHCP Server -> UA: LoST Resolver URI 2. LIS -> UA: Location reference 3. UA -> LoST Resolver: LoST query with Location reference 4. LoST Resolver -> UA: LoST response This would enable many of the approaches being discussed. LoST, extended in this way, could be used as the mechanism to deliver PSAP URIs, country codes, service boundaries, etc, since LoST already conveys them. And it mitigates the problem of the UA having to use the "right" LoST resolver (i.e., one that can do the dereference) since it allows the access network to explicitly indicate which one should be used. Thoughts? --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 08:57:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9id-0007PE-L1; Wed, 18 Apr 2007 08:57:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9ic-0007P1-Ol for ecrit@ietf.org; Wed, 18 Apr 2007 08:57:06 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He9ib-0002gu-9H for ecrit@ietf.org; Wed, 18 Apr 2007 08:57:06 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 18 Apr 2007 14:57:02 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 14:57:01 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: AW: [Ecrit] Solution Approaches Date: Wed, 18 Apr 2007 14:57:01 +0200 Message-Id: <182C63BFBAF131428EA0C16F7FD2191B013584BE@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <011801c78136$57885cc0$2d0d0d0a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Ecrit] Solution Approaches thread-index: AceBEjlcF268R4Z5QByaCKK/usgcSgAFVL9gAANLVDAAIPhGwA== From: "Liess, Laura" To: X-OriginalArrivalTime: 18 Apr 2007 12:57:01.0738 (UTC) FILETIME=[0E9BE8A0:01C781B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Mark, the environnment is the IP-Plattform for for fixed access wich has grown = over years, beginning with IP over phone lines, then fixed broadband, = currently WiFi hotspots are added. =20 Laura > -----Urspr=FCngliche Nachricht----- > Von: Marc Linsner [mailto:mlinsner@cisco.com]=20 > Gesendet: Dienstag, 17. April 2007 23:21 > An: Liess, Laura > Cc: ecrit@ietf.org > Betreff: RE: AW: [Ecrit] Solution Approaches >=20 >=20 > Laura,=20 >=20 >=20 > > I am aware of the drawbacks. But I didn't see any other > > solution we can live with. Not only because of the location=20 > > hiding issue, but also because providing a more accurate=20 > > location information for every end device requires much more=20 > > performant mechanisms than those we have today. Today, the=20 > > location information is provided by the system only for=20 > > emergency calls where the caller is not able to talk to the=20 > > call taker. Providing it at every login is another order of=20 > > magnitude. I was told that replacing the current mechanism=20 > > requires changes in the whole backend infrastructure and=20 > > would cost millions. Nobody is willing to spend so much money=20 > > without a business case. >=20 > Could you provide some more context here? I'm curious of the=20 > environment where providing location to an end-point is=20 > expensive. Wireless? Wireline Broadband? >=20 >=20 > Thanks, >=20 > -Marc- >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 09:01:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9mb-0000uv-5I; Wed, 18 Apr 2007 09:01:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9mZ-0000un-Hp; Wed, 18 Apr 2007 09:01:11 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He9mY-0003WF-7u; Wed, 18 Apr 2007 09:01:11 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1He9mM-0002X4-Oh; Wed, 18 Apr 2007 08:00:59 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpoint centric LCP without giving away the store Date: Wed, 18 Apr 2007 09:01:06 -0400 Message-ID: <0e9801c781b9$a2412660$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceBtEoPgdB4gkcgRWiVy0LaA2td7gAAfa6A In-Reply-To: <2CCBF497-7DEB-4912-970B-A6698627F1CC@cs.columbia.edu> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: 'GEOPRIV' , "Rosen, Brian" , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Is it appropriate to require an LCP and -conveyance to carry two locations: for example, a reference and a PIDF containing just a country code? Would it be more expedient to define a URI parameter that could be added to the reference? Either works, and clearly the former is less work. What would you rather see: INVITE sip:bob@biloxi.example.com SIP/2.0 ... Geolocation: ;inserted-by=endpoint or INVITE sip:bob@biloxi.example.com SIP/2.0 ... Geolocation: ;inserted-by=endpoint Geolocation: ;inserted-by=endpoint Supported: geolocation Accept: application/sdp, application/pidf+xml ... Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ... --boundary1 Content-Type: application/sdp ...SDP here --boundary1 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-ID: alice123@atlanta.example.com $ Content-Type: application/pidf+xml $ $ $ $ $ 2007-03-20T14:00:00Z $ $ $ $ $ US $ $ $ $ no $ 2007-03-24T18:00:00Z $ DHCP $ www.cisco.com $ $ $ $ $ --boundary1-- > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, April 18, 2007 8:23 AM > To: Brian Rosen > Cc: GEOPRIV; Brian Rosen; ECRIT > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > doendpoint centric LCP without giving away the store > > PIDF-LO contains a country code, as does the DHCP civic format and > thus LLDP-MED. Thus, I'm confused by your statement below. > > Henning > > On Apr 18, 2007, at 7:38 AM, Brian Rosen wrote: > > > Well, there is no place yet. We'd have to make one. > > Let's first get consensus if that's the approach we want, and then > > we can > > discuss the best way to do it. > > > > It would affect the LCP and -conveyance directly or indirectly, > > although > > there are many ways to carry it from endpoint to the VSP. > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 09:08:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9tZ-00061I-1l; Wed, 18 Apr 2007 09:08:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9tY-0005w6-2E; Wed, 18 Apr 2007 09:08:24 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He9tV-0005zF-Pi; Wed, 18 Apr 2007 09:08:24 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3ID8FPq026118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Apr 2007 09:08:16 -0400 (EDT) In-Reply-To: <0e9801c781b9$a2412660$640fa8c0@cis.neustar.com> References: <0e9801c781b9$a2412660$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8ED5BC85-C831-4311-A82D-16A47723FC57@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpoint centric LCP without giving away the store Date: Wed, 18 Apr 2007 09:08:42 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think two locations (of different resolution, whether they both be V or R, or some combination) is much cleaner and extends to other models, such as partial location. We don't want to encode state and community name in a URL parameter, for example. On Apr 18, 2007, at 9:01 AM, Brian Rosen wrote: > Is it appropriate to require an LCP and -conveyance to carry two > locations: > for example, a reference and a PIDF containing just a country > code? Would > it be more expedient to define a URI parameter that could be added > to the > reference? > > Either works, and clearly the former is less work. > > What would you rather see: > > INVITE sip:bob@biloxi.example.com SIP/2.0 > ... > Geolocation: countrycode=us> > ;inserted-by=endpoint > > or > > INVITE sip:bob@biloxi.example.com SIP/2.0 > ... > Geolocation: > ;inserted-by=endpoint > Geolocation: > ;inserted-by=endpoint > Supported: geolocation > Accept: application/sdp, application/pidf+xml > ... > Content-Type: multipart/mixed; boundary=boundary1 > Content-Length: ... > > --boundary1 > > Content-Type: application/sdp > > ...SDP here > > --boundary1 > > Content-Type: application/pkcs7-mime; > smime-type=enveloped-data; name=smime.p7m > Content-ID: alice123@atlanta.example.com > > $ Content-Type: application/pidf+xml > $ > $ > $ $ xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" > $ xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" > $ xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape" > $ entity="pres:alice@atlanta.example.com"> > $ > $ 2007-03-20T14:00:00Z > $ > $ > $ > $ > $ US > $ > $ > $ > $ no allowed> > $ 2007-03-24T18:00:00Z $ expiry> > $ DHCP > $ www.cisco.com > $ > $ > $ > $ > $ > --boundary1-- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 09:08:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9to-0006aO-Ir; Wed, 18 Apr 2007 09:08:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9tn-0006aJ-IR for ecrit@ietf.org; Wed, 18 Apr 2007 09:08:39 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1He9tm-00065h-4V for ecrit@ietf.org; Wed, 18 Apr 2007 09:08:39 -0400 Received: (qmail invoked by alias); 18 Apr 2007 13:08:37 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp044) with SMTP; 18 Apr 2007 15:08:37 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19Spw8G+MdSm/T9VWKbErfLsmKqUZOwuBN4ZpyCyW j1xGtTQY53sdWV Message-ID: <46261854.6060208@gmx.net> Date: Wed, 18 Apr 2007 15:08:36 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Richard Barnes Subject: Re: [Ecrit] A Concrete Proposal for LbyR Emergency Calling References: <46261317.1070606@bbn.com> In-Reply-To: <46261317.1070606@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Richard, Richard Barnes wrote: > As Hannes and Henning have pointed out, almost every proposal is going > to require modifications to either LoST or the LCP(s). In light of > that, ISTM that our goal should be to be "minimally invasive", i.e., > to make the smallest number of changes to enable a reliable emergency > calling function when location is only provisioned by reference. Keeping changes small is something I like. > Here's my proposed set of changes: > > 1. Enable DHCP / LCP to convey a pointer to a LoST resolver (as is > done with DNS servers within an access network) Would http://tools.ietf.org/id/draft-ietf-ecrit-dhc-lost-discovery-01.txt do the job for discovering a LoST server via DHCP? > 2. Enable LoST to carry location-by-reference (possibly with an > statement to limit applicability) > > A call flow would look something like this: > 1. DHCP Server -> UA: LoST Resolver URI > 2. LIS -> UA: Location reference > 3. UA -> LoST Resolver: LoST query with Location reference > 4. LoST Resolver -> UA: LoST response > > This would enable many of the approaches being discussed. LoST, > extended in this way, could be used as the mechanism to deliver PSAP > URIs, country codes, service boundaries, etc, since LoST already > conveys them. And it mitigates the problem of the UA having to use > the "right" LoST resolver (i.e., one that can do the dereference) > since it allows the access network to explicitly indicate which one > should be used. > > Thoughts? This would work. Ciao Hannes > --Richard > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 09:10:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9vE-0006nM-Bw; Wed, 18 Apr 2007 09:10:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He9vD-0006nH-Jj for ecrit@ietf.org; Wed, 18 Apr 2007 09:10:07 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He9vD-0006bA-A2 for ecrit@ietf.org; Wed, 18 Apr 2007 09:10:07 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1He9uy-00032W-Ji; Wed, 18 Apr 2007 08:09:56 -0500 From: "Brian Rosen" To: "'Richard Barnes'" , "'ECRIT'" Subject: RE: [Ecrit] A Concrete Proposal for LbyR Emergency Calling Date: Wed, 18 Apr 2007 09:10:00 -0400 Message-ID: <0e9f01c781ba$e2895660$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceBt4vuNnwGKSEPQ4WAZtxj9fvKVQAAl1oA In-Reply-To: <46261317.1070606@bbn.com> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Mine is: 1. DHCP server -> UA: HELD server URI 2. UA -> HELD server: Location request with identifiers 3. HELD server -> LoST Server: query with LbyV 4. LoST server -> HELD server: LoST Response 5. HELD server -> UA: LbyR + LoST response As before, in many cases, steps 3/4 can be omitted because the LIS service area is known to be within one PSAP boundary Brian > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Wednesday, April 18, 2007 8:46 AM > To: ECRIT > Subject: [Ecrit] A Concrete Proposal for LbyR Emergency Calling > > As Hannes and Henning have pointed out, almost every proposal is going > to require modifications to either LoST or the LCP(s). In light of > that, ISTM that our goal should be to be "minimally invasive", i.e., to > make the smallest number of changes to enable a reliable emergency > calling function when location is only provisioned by reference. Here's > my proposed set of changes: > > 1. Enable DHCP / LCP to convey a pointer to a LoST resolver (as is done > with DNS servers within an access network) > 2. Enable LoST to carry location-by-reference (possibly with an > statement to limit applicability) > > A call flow would look something like this: > 1. DHCP Server -> UA: LoST Resolver URI > 2. LIS -> UA: Location reference > 3. UA -> LoST Resolver: LoST query with Location reference > 4. LoST Resolver -> UA: LoST response > > This would enable many of the approaches being discussed. LoST, > extended in this way, could be used as the mechanism to deliver PSAP > URIs, country codes, service boundaries, etc, since LoST already conveys > them. And it mitigates the problem of the UA having to use the "right" > LoST resolver (i.e., one that can do the dereference) since it allows > the access network to explicitly indicate which one should be used. > > Thoughts? > --Richard > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 09:17:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeA2Y-0003BB-MW; Wed, 18 Apr 2007 09:17:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeA2X-0003B6-B7 for ecrit@ietf.org; Wed, 18 Apr 2007 09:17:41 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HeA2W-0000Xe-T8 for ecrit@ietf.org; Wed, 18 Apr 2007 09:17:41 -0400 Received: (qmail invoked by alias); 18 Apr 2007 13:17:40 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp046) with SMTP; 18 Apr 2007 15:17:40 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18GOgtA4wsGJj62aa/oNGeX5zC4ND84OCAOtmJRuv 5MzeoTBszmSq0e Message-ID: <46261A73.2060909@gmx.net> Date: Wed, 18 Apr 2007 15:17:39 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] A Concrete Proposal for LbyR Emergency Calling References: <0e9f01c781ba$e2895660$640fa8c0@cis.neustar.com> In-Reply-To: <0e9f01c781ba$e2895660$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The optimized version. The only problem with both versions: In a mobility environment the LoST response might have changed. Hence, the end host either (a) periodically needs to trigger step (2) - (5) or the protocol used between the SIP UA and the LIS is not based on HTTP but rather on SIP (and the LIS sends a notification when the location changed enough so that the LoST response changed as well). Ciao Hannes Brian Rosen wrote: > Mine is: > > 1. DHCP server -> UA: HELD server URI > 2. UA -> HELD server: Location request with identifiers > 3. HELD server -> LoST Server: query with LbyV > 4. LoST server -> HELD server: LoST Response > 5. HELD server -> UA: LbyR + LoST response > > As before, in many cases, steps 3/4 can be omitted because the LIS service > area is known to be within one PSAP boundary > > Brian > > >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Wednesday, April 18, 2007 8:46 AM >> To: ECRIT >> Subject: [Ecrit] A Concrete Proposal for LbyR Emergency Calling >> >> As Hannes and Henning have pointed out, almost every proposal is going >> to require modifications to either LoST or the LCP(s). In light of >> that, ISTM that our goal should be to be "minimally invasive", i.e., to >> make the smallest number of changes to enable a reliable emergency >> calling function when location is only provisioned by reference. Here's >> my proposed set of changes: >> >> 1. Enable DHCP / LCP to convey a pointer to a LoST resolver (as is done >> with DNS servers within an access network) >> 2. Enable LoST to carry location-by-reference (possibly with an >> statement to limit applicability) >> >> A call flow would look something like this: >> 1. DHCP Server -> UA: LoST Resolver URI >> 2. LIS -> UA: Location reference >> 3. UA -> LoST Resolver: LoST query with Location reference >> 4. LoST Resolver -> UA: LoST response >> >> This would enable many of the approaches being discussed. LoST, >> extended in this way, could be used as the mechanism to deliver PSAP >> URIs, country codes, service boundaries, etc, since LoST already conveys >> them. And it mitigates the problem of the UA having to use the "right" >> LoST resolver (i.e., one that can do the dereference) since it allows >> the access network to explicitly indicate which one should be used. >> >> Thoughts? >> --Richard >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 09:18:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeA3Z-0003Io-8O; Wed, 18 Apr 2007 09:18:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeA3X-0003Ij-Ja for ecrit@ietf.org; Wed, 18 Apr 2007 09:18:43 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeA3W-0000y6-DN for ecrit@ietf.org; Wed, 18 Apr 2007 09:18:43 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3IDIHYC005674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Apr 2007 09:18:18 -0400 (EDT) In-Reply-To: <0e9f01c781ba$e2895660$640fa8c0@cis.neustar.com> References: <0e9f01c781ba$e2895660$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <163B2FBD-EE31-48EB-813C-9BBCEA3F5BF9@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] A Concrete Proposal for LbyR Emergency Calling Date: Wed, 18 Apr 2007 09:18:41 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'll again protest as you're converting HELD into a SIP configuration protocol. This is an architecturally fundamentally bad idea. On Apr 18, 2007, at 9:10 AM, Brian Rosen wrote: > Mine is: > > 1. DHCP server -> UA: HELD server URI > 2. UA -> HELD server: Location request with identifiers > 3. HELD server -> LoST Server: query with LbyV > 4. LoST server -> HELD server: LoST Response > 5. HELD server -> UA: LbyR + LoST response > > As before, in many cases, steps 3/4 can be omitted because the LIS > service > area is known to be within one PSAP boundary > > Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 09:21:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeA5m-0003ZU-P9; Wed, 18 Apr 2007 09:21:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeA5l-0003XU-AQ for ecrit@ietf.org; Wed, 18 Apr 2007 09:21:01 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeA5j-0001Jp-36 for ecrit@ietf.org; Wed, 18 Apr 2007 09:21:01 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3IDKoAO009869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Apr 2007 09:20:50 -0400 (EDT) In-Reply-To: <46261A73.2060909@gmx.net> References: <0e9f01c781ba$e2895660$640fa8c0@cis.neustar.com> <46261A73.2060909@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <252BBEFA-B21A-4E4D-81DF-ED586D402B95@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] A Concrete Proposal for LbyR Emergency Calling Date: Wed, 18 Apr 2007 09:21:16 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Periodically doesn't cut it, since there's no way for the device to know how long it will be residing within that service region. (Obviously, querying every few seconds will work well enough, but this will kill any mobile device's battery.) I keep saying that, but somehow it doesn't seem to register. If you go that route, you need a subscription mechanism - just like the one already offered by SIP configuration. On Apr 18, 2007, at 9:17 AM, Hannes Tschofenig wrote: > The optimized version. > > The only problem with both versions: In a mobility environment the > LoST response might have changed. Hence, the end host either (a) > periodically needs to trigger step (2) - (5) or the protocol used > between the SIP UA and the LIS is not based on HTTP but rather on > SIP (and the LIS sends a notification when the location changed > enough so that the LoST response changed as well). > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 09:23:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeA82-0004vl-IP; Wed, 18 Apr 2007 09:23:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeA80-0004sF-Ut for ecrit@ietf.org; Wed, 18 Apr 2007 09:23:20 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeA7z-00028N-GW for ecrit@ietf.org; Wed, 18 Apr 2007 09:23:20 -0400 Received: from mail1.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l3IDNFwD000385; Wed, 18 Apr 2007 15:23:15 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id l3IDNFPc005987; Wed, 18 Apr 2007 15:23:15 +0200 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 15:23:15 +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 Subject: AW: [Ecrit] A Concrete Proposal for LbyR Emergency Calling Date: Wed, 18 Apr 2007 15:23:13 +0200 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E701A2949D@MCHP7R6A.ww002.siemens.net> In-Reply-To: <252BBEFA-B21A-4E4D-81DF-ED586D402B95@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] A Concrete Proposal for LbyR Emergency Calling Thread-Index: AceBvG1vPQu8LOm3RPaLc5BciuDF8gAABobQ From: "Tschofenig, Hannes" To: "Henning Schulzrinne" , "Hannes Tschofenig" X-OriginalArrivalTime: 18 Apr 2007 13:23:15.0609 (UTC) FILETIME=[B8B59090:01C781BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Yup.=20 I tried to hint to the subscription mechanism =20 > -----Urspr=FCngliche Nachricht----- > Von: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Gesendet: Mittwoch, 18. April 2007 15:21 > An: Hannes Tschofenig > Cc: 'ECRIT' > Betreff: Re: [Ecrit] A Concrete Proposal for LbyR Emergency Calling >=20 > Periodically doesn't cut it, since there's no way for the device to =20 > know how long it will be residing within that service region. =20 > (Obviously, querying every few seconds will work well enough, but =20 > this will kill any mobile device's battery.) I keep saying that, but =20 > somehow it doesn't seem to register. If you go that route,=20 > you need a =20 > subscription mechanism - just like the one already offered by SIP =20 > configuration. >=20 > On Apr 18, 2007, at 9:17 AM, Hannes Tschofenig wrote: >=20 > > The optimized version. > > > > The only problem with both versions: In a mobility environment the =20 > > LoST response might have changed. Hence, the end host either (a) =20 > > periodically needs to trigger step (2) - (5) or the protocol used =20 > > between the SIP UA and the LIS is not based on HTTP but rather on =20 > > SIP (and the LIS sends a notification when the location changed =20 > > enough so that the LoST response changed as well). > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 09:26:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeABS-0000ro-RH; Wed, 18 Apr 2007 09:26:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeABR-0000rj-Mu for ecrit@ietf.org; Wed, 18 Apr 2007 09:26:53 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeABP-0003Nu-FK for ecrit@ietf.org; Wed, 18 Apr 2007 09:26:53 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HeABE-0005eF-BT; Wed, 18 Apr 2007 08:26:40 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] A Concrete Proposal for LbyR Emergency Calling Date: Wed, 18 Apr 2007 09:26:47 -0400 Message-ID: <0ead01c781bd$3927a510$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceBvA8R6GgI+dOPQHqBQQuuFrFr8AAAJgtw In-Reply-To: <163B2FBD-EE31-48EB-813C-9BBCEA3F5BF9@cs.columbia.edu> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Where did we cross a bright line? I must have missed it. What you are saying is that an endpoint can do an LCP request and a LoST request separately, but something that combines them has to be SIP configuration. What if the endpoint uses, oh, say, AIM? Skype? LoST returns dialstrings. Is that SIP configuration? HELD returns things that go in -conveyance. Is that SIP configuration? Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, April 18, 2007 9:19 AM > To: Brian Rosen > Cc: 'Richard Barnes'; 'ECRIT' > Subject: Re: [Ecrit] A Concrete Proposal for LbyR Emergency Calling > > I'll again protest as you're converting HELD into a SIP configuration > protocol. This is an architecturally fundamentally bad idea. > > On Apr 18, 2007, at 9:10 AM, Brian Rosen wrote: > > > Mine is: > > > > 1. DHCP server -> UA: HELD server URI > > 2. UA -> HELD server: Location request with identifiers > > 3. HELD server -> LoST Server: query with LbyV > > 4. LoST server -> HELD server: LoST Response > > 5. HELD server -> UA: LbyR + LoST response > > > > As before, in many cases, steps 3/4 can be omitted because the LIS > > service > > area is known to be within one PSAP boundary > > > > Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 09:28:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeADP-0001CS-4G; Wed, 18 Apr 2007 09:28:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeADN-0001CK-VA; Wed, 18 Apr 2007 09:28:53 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeADM-0003re-KG; Wed, 18 Apr 2007 09:28:53 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HeADB-0005k5-8E; Wed, 18 Apr 2007 08:28:41 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpoint centric LCP without giving away the store Date: Wed, 18 Apr 2007 09:28:49 -0400 Message-ID: <0eae01c781bd$815bfd40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceBup2FYNd+UJkYS9O2SLHDxdngvgAAJi7Q In-Reply-To: <8ED5BC85-C831-4311-A82D-16A47723FC57@cs.columbia.edu> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: 'GEOPRIV' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Let's keep our eye on the goal, which was to allow validation of a PSAP URI by a downstream routing element. You suggested that we may not need it at all. We aren't providing two locations at different resolutions, we're providing a hint to minimize the reverse search space. While having a community name could further reduce the search space, it's not clear to me it helps enough to be worth it. Our simplest solution in this direction is to not send the country code, and just allow a reverse search in the LoST database ("flooding"). Having a community name is NOT sufficient to choose a PSAP in every case, and every case has to work. If the boundary is irregular, which it is in some circumstances, you would need street name and house number to know which PSAP. That would not be acceptable to an access network who is not willing to provide location to a VSP (or any other entity except a PSAP). I hope we're clear on that point. So, returning coarse location as an LbyVand using that in a LoST query is NOT an acceptable alternative to returning an LbyR that is not dereferenceable by the VSP. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, April 18, 2007 9:09 AM > To: Brian Rosen > Cc: GEOPRIV; ECRIT > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > doendpoint centric LCP without giving away the store > > I think two locations (of different resolution, whether they both be > V or R, or some combination) is much cleaner and extends to other > models, such as partial location. We don't want to encode state and > community name in a URL parameter, for example. > > On Apr 18, 2007, at 9:01 AM, Brian Rosen wrote: > > > Is it appropriate to require an LCP and -conveyance to carry two > > locations: > > for example, a reference and a PIDF containing just a country > > code? Would > > it be more expedient to define a URI parameter that could be added > > to the > > reference? > > > > Either works, and clearly the former is less work. > > > > What would you rather see: > > > > INVITE sip:bob@biloxi.example.com SIP/2.0 > > ... > > Geolocation: > countrycode=us> > > ;inserted-by=endpoint > > > > or > > > > INVITE sip:bob@biloxi.example.com SIP/2.0 > > ... > > Geolocation: > > ;inserted-by=endpoint > > Geolocation: > > ;inserted-by=endpoint > > Supported: geolocation > > Accept: application/sdp, application/pidf+xml > > ... > > Content-Type: multipart/mixed; boundary=boundary1 > > Content-Length: ... > > > > --boundary1 > > > > Content-Type: application/sdp > > > > ...SDP here > > > > --boundary1 > > > > Content-Type: application/pkcs7-mime; > > smime-type=enveloped-data; name=smime.p7m > > Content-ID: alice123@atlanta.example.com > > > > $ Content-Type: application/pidf+xml > > $ > > $ > > $ > $ xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" > > $ xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" > > $ xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape" > > $ entity="pres:alice@atlanta.example.com"> > > $ > > $ 2007-03-20T14:00:00Z > > $ > > $ > > $ > > $ > > $ US > > $ > > $ > > $ > > $ no > allowed> > > $ 2007-03-24T18:00:00Z > $ expiry> > > $ DHCP > > $ www.cisco.com > > $ > > $ > > $ > > $ > > $ > > --boundary1-- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 09:30:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAEg-0001Uy-3E; Wed, 18 Apr 2007 09:30:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAEe-0001Ut-A7 for ecrit@ietf.org; Wed, 18 Apr 2007 09:30:12 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HeAEd-00045w-20 for ecrit@ietf.org; Wed, 18 Apr 2007 09:30:12 -0400 Received: (qmail invoked by alias); 18 Apr 2007 13:30:10 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp033) with SMTP; 18 Apr 2007 15:30:10 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19kvqxvKeZklvjIooEbI+SUuNn98I3URCIupQ4lch p3wLYRfAWvzyVJ Message-ID: <46261D61.6080005@gmx.net> Date: Wed, 18 Apr 2007 15:30:09 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) 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-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Ecrit] Subscription Concept for Hiding (partial) locations X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all would folks be happy with the following exchange: UA <-> DHCP: URI to LIS UA --> LIS: Subscribe to LbyR+Dial String+PSAP URI UA <-- LIS: Notification Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 09:30:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAFL-00022s-94; Wed, 18 Apr 2007 09:30:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAFK-00022g-Jx for ecrit@ietf.org; Wed, 18 Apr 2007 09:30:54 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeAFJ-0004FT-CP for ecrit@ietf.org; Wed, 18 Apr 2007 09:30:54 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HeAF6-0002NE-Sx; Wed, 18 Apr 2007 08:30:42 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Hannes Tschofenig'" Subject: RE: [Ecrit] A Concrete Proposal for LbyR Emergency Calling Date: Wed, 18 Apr 2007 09:30:48 -0400 Message-ID: <0eb501c781bd$c957b940$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceBvF2/mFMPliO1QjmeALmJ+0rXZgAAOd4w In-Reply-To: <252BBEFA-B21A-4E4D-81DF-ED586D402B95@cs.columbia.edu> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Well, subscription, but presence, not configuration. The LIS notifies you when you go outside the boundary. The endpoint never sees the boundary, but the LIS (which is a presence server after all) does. If you had LbyV from the LIS, that's what you want: tell me when I go beyond this boundary. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, April 18, 2007 9:21 AM > To: Hannes Tschofenig > Cc: Brian Rosen; 'ECRIT' > Subject: Re: [Ecrit] A Concrete Proposal for LbyR Emergency Calling > > Periodically doesn't cut it, since there's no way for the device to > know how long it will be residing within that service region. > (Obviously, querying every few seconds will work well enough, but > this will kill any mobile device's battery.) I keep saying that, but > somehow it doesn't seem to register. If you go that route, you need a > subscription mechanism - just like the one already offered by SIP > configuration. > > On Apr 18, 2007, at 9:17 AM, Hannes Tschofenig wrote: > > > The optimized version. > > > > The only problem with both versions: In a mobility environment the > > LoST response might have changed. Hence, the end host either (a) > > periodically needs to trigger step (2) - (5) or the protocol used > > between the SIP UA and the LIS is not based on HTTP but rather on > > SIP (and the LIS sends a notification when the location changed > > enough so that the LoST response changed as well). > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 09:37:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeALK-0007Bq-BO; Wed, 18 Apr 2007 09:37:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeALJ-0007BX-Gs for ecrit@ietf.org; Wed, 18 Apr 2007 09:37:05 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HeALI-00067K-V4 for ecrit@ietf.org; Wed, 18 Apr 2007 09:37:05 -0400 Received: (qmail invoked by alias); 18 Apr 2007 13:37:04 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp040) with SMTP; 18 Apr 2007 15:37:04 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+8kdha3xK8YdD/uOiGaXheqk6MTFkjtKuTGJu7JD I9sA3N6cUXt3k2 Message-ID: <46261EFF.7050302@gmx.net> Date: Wed, 18 Apr 2007 15:37:03 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpoint centric LCP without giving away the store References: <0eae01c781bd$815bfd40$640fa8c0@cis.neustar.com> In-Reply-To: <0eae01c781bd$815bfd40$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: 'GEOPRIV' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian, Brian Rosen wrote: > Let's keep our eye on the goal, which was to allow validation of a PSAP URI > by a downstream routing element. You suggested that we may not need it at > all. We aren't providing two locations at different resolutions, we're > providing a hint to minimize the reverse search space. > > PSAP URI validation is not needed when the VSP provides a flat rate based charging scheme (since doing fraud with individual calls will not be possible). There might, however, be other things to consider (e.g., QoS reservations for preferential treatment etc.) that play a role here. > While having a community name could further reduce the search space, it's > not clear to me it helps enough to be worth it. Our simplest solution in > this direction is to not send the country code, and just allow a reverse > search in the LoST database ("flooding"). > The brute force version to solve the problem is not "simple" either. If a PSAP does not flood its URI then it will get blocked = bad thing. > Having a community name is NOT sufficient to choose a PSAP in every case, > and every case has to work. If the boundary is irregular, which it is in > some circumstances, you would need street name and house number to know > which PSAP. That would not be acceptable to an access network who is not > willing to provide location to a VSP (or any other entity except a PSAP). I > hope we're clear on that point. So, returning coarse location as an LbyVand > using that in a LoST query is NOT an acceptable alternative to returning an > LbyR that is not dereferenceable by the VSP. > It is true that the routing based on country level works only if you either * use an ESRP for the entire country (whereby this ESRP subsequently can do more detailed routing based on the location information it obtains from the ISP/ASP) OR * there is only a single PSAP per country. Ciao Hannes > Brian > > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Wednesday, April 18, 2007 9:09 AM >> To: Brian Rosen >> Cc: GEOPRIV; ECRIT >> Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to >> doendpoint centric LCP without giving away the store >> >> I think two locations (of different resolution, whether they both be >> V or R, or some combination) is much cleaner and extends to other >> models, such as partial location. We don't want to encode state and >> community name in a URL parameter, for example. >> >> On Apr 18, 2007, at 9:01 AM, Brian Rosen wrote: >> >> >>> Is it appropriate to require an LCP and -conveyance to carry two >>> locations: >>> for example, a reference and a PIDF containing just a country >>> code? Would >>> it be more expedient to define a URI parameter that could be added >>> to the >>> reference? >>> >>> Either works, and clearly the former is less work. >>> >>> What would you rather see: >>> >>> INVITE sip:bob@biloxi.example.com SIP/2.0 >>> ... >>> Geolocation: >> countrycode=us> >>> ;inserted-by=endpoint >>> >>> or >>> >>> INVITE sip:bob@biloxi.example.com SIP/2.0 >>> ... >>> Geolocation: >>> ;inserted-by=endpoint >>> Geolocation: >>> ;inserted-by=endpoint >>> Supported: geolocation >>> Accept: application/sdp, application/pidf+xml >>> ... >>> Content-Type: multipart/mixed; boundary=boundary1 >>> Content-Length: ... >>> >>> --boundary1 >>> >>> Content-Type: application/sdp >>> >>> ...SDP here >>> >>> --boundary1 >>> >>> Content-Type: application/pkcs7-mime; >>> smime-type=enveloped-data; name=smime.p7m >>> Content-ID: alice123@atlanta.example.com >>> >>> $ Content-Type: application/pidf+xml >>> $ >>> $ >>> $ >> $ xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" >>> $ xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" >>> $ xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape" >>> $ entity="pres:alice@atlanta.example.com"> >>> $ >>> $ 2007-03-20T14:00:00Z >>> $ >>> $ >>> $ >>> $ >>> $ US >>> $ >>> $ >>> $ >>> $ no>> allowed> >>> $ 2007-03-24T18:00:00Z>> $ expiry> >>> $ DHCP >>> $ www.cisco.com >>> $ >>> $ >>> $ >>> $ >>> $ >>> --boundary1-- >>> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 09:41:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAPa-0003ER-Jn; Wed, 18 Apr 2007 09:41:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAPa-0003EA-4D for ecrit@ietf.org; Wed, 18 Apr 2007 09:41:30 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeAPY-0007nC-Qp for ecrit@ietf.org; Wed, 18 Apr 2007 09:41:30 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Apr 2007 09:41:28 -0400 X-IronPort-AV: i="4.14,422,1170651600"; d="scan'208"; a="118831802:sNHT46373008" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3IDfSTG023743; Wed, 18 Apr 2007 09:41:28 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3IDf1lQ010598; Wed, 18 Apr 2007 13:41:23 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 09:41:08 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 09:41:07 -0400 From: "Marc Linsner" To: "'Brian Rosen'" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how todoendpoint centric LCP without giving away the store Date: Wed, 18 Apr 2007 09:41:06 -0400 Message-ID: <009701c781bf$379421e0$2d0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceBup2FYNd+UJkYS9O2SLHDxdngvgAAJi7QAADmMpA= In-Reply-To: <0eae01c781bd$815bfd40$640fa8c0@cis.neustar.com> X-OriginalArrivalTime: 18 Apr 2007 13:41:07.0365 (UTC) FILETIME=[37868D50:01C781BF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=272; t=1176903688; x=1177767688; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20Re=3A=20[Ecrit]=20Not-so-grand=20compromi se=20on=20how=20todoendpoint=20centric=20LCP=09without=20giving=20away=20t he=20store |Sender:=20 |To:=20=22'Brian=20Rosen'=22=20; bh=Kjw7v7TnQjKMQSwhOM6C81erYdnwG15S7nUMgHTdMYM=; b=C6Qxa9xOJPGzXIMVsZjCGBEHeRvtVFBSS0JWLX+0eRQqyGLXY4dOKd/YfdoruYaUu/dRMyI9 z26H9kKQZqa/l1p82shsVLppCo5tDF8Lq8rN9zgNmjGOLjaCIWWD0fWG; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > Let's keep our eye on the goal, which was to allow validation > of a PSAP URI by a downstream routing element. Did we decide that the access provider operating an ESRP is not an option? (facilitates hiding of all location info from the UA) -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 09:52:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAaI-0006pg-5i; Wed, 18 Apr 2007 09:52:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAaH-0006pT-2k; Wed, 18 Apr 2007 09:52:33 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeAaF-0001M6-Jg; Wed, 18 Apr 2007 09:52:33 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HeAa3-0003dX-PY; Wed, 18 Apr 2007 08:52:19 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpoint centric LCP without giving away the store Date: Wed, 18 Apr 2007 09:52:27 -0400 Message-ID: <0ec101c781c0$cee58240$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceBvqGzS/0QODWLR/CWbGXkY9+tYgAAOdOg In-Reply-To: <46261EFF.7050302@gmx.net> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: 'GEOPRIV' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Okay Hannes, I get that, but: Are we, or are we not agreeing that SOME VSPs need to validate a proffered PSAP URI? Your comment indicates reasons other than charging that may prompt VSPs to attempt validation. I assume you are not arguing we don't need the capability. I agree that "flooding" would be a requirement. The actual requirement is for a reverse lookup. Flooding is how you meet the requirement. Are we, or are we not agreeing that we can't force ESRP per country or single PSAP per country? If we agree that irregular boundaries per ESRP are possible, then coarse location is insufficient for a LoST query and we need some other solution. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, April 18, 2007 9:37 AM > To: Brian Rosen > Cc: 'Henning Schulzrinne'; 'GEOPRIV'; 'ECRIT' > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > doendpoint centric LCP without giving away the store > > Hi Brian, > > Brian Rosen wrote: > > Let's keep our eye on the goal, which was to allow validation of a PSAP > URI > > by a downstream routing element. You suggested that we may not need it > at > > all. We aren't providing two locations at different resolutions, we're > > providing a hint to minimize the reverse search space. > > > > > PSAP URI validation is not needed when the VSP provides a flat rate > based charging scheme (since doing fraud with individual calls will not > be possible). > There might, however, be other things to consider (e.g., QoS > reservations for preferential treatment etc.) that play a role here. > > > While having a community name could further reduce the search space, > it's > > not clear to me it helps enough to be worth it. Our simplest solution > in > > this direction is to not send the country code, and just allow a reverse > > search in the LoST database ("flooding"). > > > > The brute force version to solve the problem is not "simple" either. If > a PSAP does not flood its URI then it will get blocked = bad thing. > > > Having a community name is NOT sufficient to choose a PSAP in every > case, > > and every case has to work. If the boundary is irregular, which it is > in > > some circumstances, you would need street name and house number to know > > which PSAP. That would not be acceptable to an access network who is > not > > willing to provide location to a VSP (or any other entity except a > PSAP). I > > hope we're clear on that point. So, returning coarse location as an > LbyVand > > using that in a LoST query is NOT an acceptable alternative to returning > an > > LbyR that is not dereferenceable by the VSP. > > > It is true that the routing based on country level works only if you > either > * use an ESRP for the entire country (whereby this ESRP subsequently can > do more detailed routing based on the location information it obtains > from the ISP/ASP) > OR > * there is only a single PSAP per country. > > Ciao > Hannes > > > Brian > > > > > >> -----Original Message----- > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >> Sent: Wednesday, April 18, 2007 9:09 AM > >> To: Brian Rosen > >> Cc: GEOPRIV; ECRIT > >> Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > >> doendpoint centric LCP without giving away the store > >> > >> I think two locations (of different resolution, whether they both be > >> V or R, or some combination) is much cleaner and extends to other > >> models, such as partial location. We don't want to encode state and > >> community name in a URL parameter, for example. > >> > >> On Apr 18, 2007, at 9:01 AM, Brian Rosen wrote: > >> > >> > >>> Is it appropriate to require an LCP and -conveyance to carry two > >>> locations: > >>> for example, a reference and a PIDF containing just a country > >>> code? Would > >>> it be more expedient to define a URI parameter that could be added > >>> to the > >>> reference? > >>> > >>> Either works, and clearly the former is less work. > >>> > >>> What would you rather see: > >>> > >>> INVITE sip:bob@biloxi.example.com SIP/2.0 > >>> ... > >>> Geolocation: >>> countrycode=us> > >>> ;inserted-by=endpoint > >>> > >>> or > >>> > >>> INVITE sip:bob@biloxi.example.com SIP/2.0 > >>> ... > >>> Geolocation: > >>> ;inserted-by=endpoint > >>> Geolocation: > >>> ;inserted-by=endpoint > >>> Supported: geolocation > >>> Accept: application/sdp, application/pidf+xml > >>> ... > >>> Content-Type: multipart/mixed; boundary=boundary1 > >>> Content-Length: ... > >>> > >>> --boundary1 > >>> > >>> Content-Type: application/sdp > >>> > >>> ...SDP here > >>> > >>> --boundary1 > >>> > >>> Content-Type: application/pkcs7-mime; > >>> smime-type=enveloped-data; name=smime.p7m > >>> Content-ID: alice123@atlanta.example.com > >>> > >>> $ Content-Type: application/pidf+xml > >>> $ > >>> $ > >>> $ >>> $ xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" > >>> $ xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" > >>> $ xmlns:gs="urn:ietf:params:xml:ns:pidf:geopriv10:geoShape" > >>> $ entity="pres:alice@atlanta.example.com"> > >>> $ > >>> $ 2007-03-20T14:00:00Z > >>> $ > >>> $ > >>> $ > >>> $ > >>> $ US > >>> $ > >>> $ > >>> $ > >>> $ no >>> allowed> > >>> $ 2007-03-24T18:00:00Z >>> $ expiry> > >>> $ DHCP > >>> $ www.cisco.com > >>> $ > >>> $ > >>> $ > >>> $ > >>> $ > >>> --boundary1-- > >>> > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 09:55:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAdN-0007gC-Vp; Wed, 18 Apr 2007 09:55:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAdM-0007ds-QS for ecrit@ietf.org; Wed, 18 Apr 2007 09:55:44 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeAdL-0002cJ-Jb for ecrit@ietf.org; Wed, 18 Apr 2007 09:55:44 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HeAdA-0003xo-6m; Wed, 18 Apr 2007 08:55:32 -0500 From: "Brian Rosen" To: "'Marc Linsner'" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how todoendpoint centric LCP without giving away the store Date: Wed, 18 Apr 2007 09:55:40 -0400 Message-ID: <0ec201c781c1$419a2200$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceBup2FYNd+UJkYS9O2SLHDxdngvgAAJi7QAADmMpAAAIGnkA== In-Reply-To: <009701c781bf$379421e0$2d0d0d0a@amer.cisco.com> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think FORCING an access provider to deploy an ESRP when they don't agree to give location to endpoints or arbitrary VSPs is not an option. I also think having the access network as an active element in the call chain is very unattractive, especially when proxy routing has the VSP also in the call chain. I'm okay with allowing it. I think the PSAPs would have an opinion on its use. Brian > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Wednesday, April 18, 2007 9:41 AM > To: 'Brian Rosen' > Cc: 'ECRIT' > Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how > todoendpoint centric LCP without giving away the store > > > > > > > Let's keep our eye on the goal, which was to allow validation > > of a PSAP URI by a downstream routing element. > > Did we decide that the access provider operating an ESRP is not an option? > > (facilitates hiding of all location info from the UA) > > > -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 10:11:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAsw-0004q9-5j; Wed, 18 Apr 2007 10:11:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeAsu-0004q3-Q2 for ecrit@ietf.org; Wed, 18 Apr 2007 10:11:48 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeAsu-0008GX-G9 for ecrit@ietf.org; Wed, 18 Apr 2007 10:11:48 -0400 Received: from ([139.76.131.83]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.20406531; Wed, 18 Apr 2007 10:11:28 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 18 Apr 2007 10:11:28 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 18 Apr 2007 10:11:28 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] A Concrete Proposal for LbyR Emergency Calling X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Date: Wed, 18 Apr 2007 10:11:27 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA03B0F33C@crexc41p> In-Reply-To: <46261317.1070606@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] A Concrete Proposal for LbyR Emergency Calling thread-index: AceBt5tX5FgbPoK4Qn6H91mAvuTU9QAC2mfg References: <46261317.1070606@bbn.com> From: "Stark, Barbara" To: "Richard Barnes" ,"ECRIT" X-OriginalArrivalTime: 18 Apr 2007 14:11:28.0440 (UTC) FILETIME=[74F88B80:01C781C3] X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'm a bit fuzzy as to who will be running LoST servers. I thought I'd read somewhere that VSPs might have cached LoST data, and be able to tell their endpoints to come to their LoST server, first. If this is true, and if I don't trust VSPs to dereference, can I trust LoST servers to dereference? Or did I misunderstand the LoST server architecture somewhere down the line? Barbara -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com]=20 Sent: Wednesday, April 18, 2007 8:46 AM To: ECRIT Subject: [Ecrit] A Concrete Proposal for LbyR Emergency Calling As Hannes and Henning have pointed out, almost every proposal is going to require modifications to either LoST or the LCP(s). In light of that, ISTM that our goal should be to be "minimally invasive", i.e., to make the smallest number of changes to enable a reliable emergency calling function when location is only provisioned by reference. Here's my proposed set of changes: 1. Enable DHCP / LCP to convey a pointer to a LoST resolver (as is done with DNS servers within an access network) 2. Enable LoST to carry location-by-reference (possibly with an statement to limit applicability) A call flow would look something like this: 1. DHCP Server -> UA: LoST Resolver URI 2. LIS -> UA: Location reference 3. UA -> LoST Resolver: LoST query with Location reference 4. LoST Resolver -> UA: LoST response This would enable many of the approaches being discussed. LoST, extended in this way, could be used as the mechanism to deliver PSAP URIs, country codes, service boundaries, etc, since LoST already conveys them. And it mitigates the problem of the UA having to use the "right"=20 LoST resolver (i.e., one that can do the dereference) since it allows the access network to explicitly indicate which one should be used. Thoughts? --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA622 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 10:30:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBAe-0000EC-2a; Wed, 18 Apr 2007 10:30:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBAd-0000E7-FX for ecrit@ietf.org; Wed, 18 Apr 2007 10:30:07 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeBAc-0006cj-TR for ecrit@ietf.org; Wed, 18 Apr 2007 10:30:07 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HeBAQ-0005Zd-3E; Wed, 18 Apr 2007 09:29:54 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: A slightly different take: RE: [Ecrit] Not-so-grand compromise on how to doendpointcentric LCPwithout giving away the store Date: Wed, 18 Apr 2007 10:30:01 -0400 Message-ID: <0edd01c781c6$0ebfb160$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceBbxBoBolZw1aDR3W9fshvRv6z4gAQTXCQ In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: 'Barbara Stark' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Okay, I understand what you propose. I don't see a request in LoST where you supply a boundary reference, and you get back the uris. I see "getServiceBoundaryResponse" as in figure 11 in Lost-05, but it doesn't have the uri. I can see how it could, but the text doesn't say that it does. I don't see anything where you supply a boundary reference and get a mapping. Did I miss some text in the document? If you could, I see how this would work. I am not opposed to modifying LoST to solve the problem. I am opposed to REQUIRING that the LoST server be combined with the LIS. If I'm understanding what you propose, that isn't really necessary; you are just proposing the LIS have a LoST query interface the client uses to get the PSAP URI. The LIS could consult a "real" LoST server to get the info that it returns to the client. This has the problem that the UA must for sure use the access network to determine the LoST server. I don't think that will always work. I do think that the response to the LIS for location is an LbyR, and not something else. That is what it passes in -conveyance, and that is what the PSAP uses. Your point that the LIS could ignore it is sort of okay. It isn't really because the LoST query doesn't supply enough identifiers to the LIS to uniquely identify the endpoint. However, the LbyR does. But then you are back to accepting LbyR in a LoST request. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Wednesday, April 18, 2007 12:07 AM > To: Brian Rosen > Cc: 'ECRIT'; 'Barbara Stark'; 'Marc Linsner' > Subject: Re: A slightly different take: RE: [Ecrit] Not-so-grand > compromise on how to doendpointcentric LCPwithout giving away the store > > Brian, > > For some reason we seem to be miscommunicating, most likely because > of the medium. I'll try to clarify below. > > On Apr 17, 2007, at 10:04 PM, Brian Rosen wrote: > > The VSP doesn't have a location to verify a boundary. The original > > proposal > > was to reverse search the PSAP URI within a country. The country > > is really > > just a hint that may help the reverse search. Henning argues we > > don't need > > it at all, and he may be right. You could try to make the LoST server > > reverse search within a boundary, but I suspect that is a lot > > harder. I > > don't know why a reference is any more or less helpful than the actual > > boundary. > > My point about the boundary reference is that it can be used to get a > from LoST. If you point LoST client A at a LoST server and > it gets back a boundary reference, that reference can the be handed > to LoST client B who can use it to retrieve the very same . > Included in is the PSAP URI. > > If a VSP wants to validate that the URI it has been given is truly a > PSAP URI, it can use the boundary reference to achieve the > . That mapping should contain the very same PSAP URI. > > >> If we are to make protocol changes, I'd rather not stray too far. > >> The behavior we need is simply this: LoST returns boundary references > >> with mappings, and these boundary references are simply put into > >> well- > >> known SIP URI parameters (to be used by the VSP later). > >> > >> To the client, the behavior is the same: > >> > >> 1) The client queries the LCP for location. > >> 2) The LCP returns location that is very broad, perhaps just the > >> country code. > >> 3) The client gets configured with the LoST resolve of the access > >> network. > >> 4) The client queries LoST with its location. > >> 5) The LoST resolver consults the LIS for the more specific location. > >> 6) The LoST resolver then conducts the regular resolution. > >> 7) The LoST resolver returns the normal answer to the client. > >> 8) The client makes the call in the normal way. > >> > >> The only change here is to LoST to include boundary references in > >> mappings, and to the clients so that they know to pass those > >> references to the VSP. > > I'm lost (pun, sorry). > > Country codes aren't useful enough to pick a PSAP. You know this, > > so I > > don't understand what that location does, but I'm even more > > confused than > > that. > > I didn't explain that well. In step 2, the LCP returns a place > holder location. It might as well say "planet Earth", but that isn't > valid within the protocol schemas. The point is, the client does not > know that the location is just a place holder and treats it no > differently. By definition, this location information has not real > meaning. > > > In step 5 you have LoST querying the LIS. That's a big step, and > > how > > is it doing this? With an LbyR? So far, the LCP has a coarse > > LbyV. See > > how lost I am? > > Note that in step 3, the LoST server that the client gets configured > with resides in the access network. It might as well be the LIS > itself, just with a LoST interface. Since the access network knows > the location of the target, it can combine the LIS and LoST functions > together. It can also ignore the place holder location that will be > given it by the client, because it knows the real location of the > client... and that is what it will use for LoST. > > > I really, truly don't understand the reluctance to simply combining > > a call > > to an LCP with a call to a LoST resolver into one step. It means > > the access > > network is calling LoST instead of the client, but I think we're > > mostly > > thinking the access network is pretty close to the LoST resolver, > > so that > > should be a no brainer. > > I think we are on the same page, just reading different paragraphs. > > > If you don't want to dirty the LCP protocol, we really can invent a > > new > > combo protocol; it's no big deal, since it's mostly the query > > syntax of the > > LCP with the return of the LCP+LoST as one data structure. > > Personally I'd rather put this in LoST than have to go back and > retrofit 5 LCPs. However, I'm also concerned with the behavior of > the client. I would like it to do the same thing and have the same > steps no matter if it is a network that attempts to hide its location > or in a network that does not. Having separate client, endpoint > behavior for these two situations may lead to trouble. > > >> What credentials would the PSAP have? If we are talking about PKI, > >> then I have a problem with that. Having the LIS simply know not to > >> allow a dereference by the target, of which it has a solid > >> understanding who that is, should be enough. And that requires > >> absolutely no cross-domain coordination. > > Well, since the LIS and the PSAP are local to one another they > > could use > > anything they agree to use. The point of the LbyR is to control > > WHO can > > dereference. The access network is happy to have anyone > > dereference as long > > as they pay for the privilege. It WANTS the endpoint to give the > > LbyR to > > anyone who wants it, to maximize it's revenue. > > Ok. Here we are reading from different books. An LbyR is not the > only thing a LIS needs to hand out to get paid for its location, > unless you have a different perspective of that whole micro-payments > thing from 10 years ago. Also, there may be networks that had > location for client endpoints for reasons other than money. > > All that is besides the point, as you cannot predict that every PSAP > will have a relationship with every access network within its > jurisdiction. I know we've been over this time and again on this > mailing list, but wishing that these multitude of entities will get > together in a harmonious administrative effort is just that, > wishing. If human nature worked like that, PGP would be a > universally accepted technology. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 10:38:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBIL-00077V-3f; Wed, 18 Apr 2007 10:38:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBIJ-00077P-Mj for ecrit@ietf.org; Wed, 18 Apr 2007 10:38:03 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeBIJ-00083F-BH for ecrit@ietf.org; Wed, 18 Apr 2007 10:38:03 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HeBI7-0003ul-Ax; Wed, 18 Apr 2007 09:37:51 -0500 From: "Brian Rosen" To: "'Stark, Barbara'" , "'Richard Barnes'" , "'ECRIT'" Subject: RE: [Ecrit] A Concrete Proposal for LbyR Emergency Calling Date: Wed, 18 Apr 2007 10:37:59 -0400 Message-ID: <0ede01c781c7$2b3dbd90$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceBt5tX5FgbPoK4Qn6H91mAvuTU9QAC2mfgAADIFBA= In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA03B0F33C@crexc41p> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'll speak for the NENA work. The authoritative LoST servers will be operated by, or on behalf of the "9-1-1 Authority", which is often one level higher than a PSAP. It's most often a county agency, but in some places it's a state agency, and in other places it really is one PSAP and in other areas is a regional group of PSAPs not tied to "county" or "state". The 9-1-1 authority may authorize an access network (or a VSP) to have a replica of the data, which it can use for a local LoST resolver. I do think that assuming either the access network or the VSP can actually control what the endpoint uses for a LoST service is probably not viable. Consider, for example, a softclient using what we hope will be a standard api in the laptop to an O/S function that runs all the LCPs to find location. The location would be known before the softclient even started up. On the other hand, consider a hardwired sipphone that is supplied by a VSP and is configured to query the VSP's LoST service. Both are viable, both should work. Brian > -----Original Message----- > From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > Sent: Wednesday, April 18, 2007 10:11 AM > To: Richard Barnes; ECRIT > Subject: RE: [Ecrit] A Concrete Proposal for LbyR Emergency Calling > > I'm a bit fuzzy as to who will be running LoST servers. I thought I'd > read somewhere that VSPs might have cached LoST data, and be able to > tell their endpoints to come to their LoST server, first. If this is > true, and if I don't trust VSPs to dereference, can I trust LoST servers > to dereference? > > Or did I misunderstand the LoST server architecture somewhere down the > line? > Barbara > > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Wednesday, April 18, 2007 8:46 AM > To: ECRIT > Subject: [Ecrit] A Concrete Proposal for LbyR Emergency Calling > > As Hannes and Henning have pointed out, almost every proposal is going > to require modifications to either LoST or the LCP(s). In light of > that, ISTM that our goal should be to be "minimally invasive", i.e., to > make the smallest number of changes to enable a reliable emergency > calling function when location is only provisioned by reference. Here's > my proposed set of changes: > > 1. Enable DHCP / LCP to convey a pointer to a LoST resolver (as is done > with DNS servers within an access network) 2. Enable LoST to carry > location-by-reference (possibly with an statement to limit > applicability) > > A call flow would look something like this: > 1. DHCP Server -> UA: LoST Resolver URI > 2. LIS -> UA: Location reference > 3. UA -> LoST Resolver: LoST query with Location reference 4. LoST > Resolver -> UA: LoST response > > This would enable many of the approaches being discussed. LoST, > extended in this way, could be used as the mechanism to deliver PSAP > URIs, country codes, service boundaries, etc, since LoST already conveys > them. And it mitigates the problem of the UA having to use the "right" > LoST resolver (i.e., one that can do the dereference) since it allows > the access network to explicitly indicate which one should be used. > > Thoughts? > --Richard > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > ***** > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential, proprietary, and/or > privileged material. Any review, retransmission, dissemination or other > use of, or taking of any action in reliance upon this information by > persons or entities other than the intended recipient is prohibited. If > you received this in error, please contact the sender and delete the > material from all computers. GA622 > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 10:40:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBKD-0007cN-Hj; Wed, 18 Apr 2007 10:40:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBKC-0007cH-Gr for ecrit@ietf.org; Wed, 18 Apr 2007 10:40:00 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeBKB-00007Z-Nx for ecrit@ietf.org; Wed, 18 Apr 2007 10:40:00 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 18 Apr 2007 16:39:58 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 16:39:58 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [Ecrit] Solution Approaches Date: Wed, 18 Apr 2007 16:39:58 +0200 Message-Id: <182C63BFBAF131428EA0C16F7FD2191B013584C1@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <0cc201c7813b$6ec61f80$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Solution Approaches thread-index: AceA0IFqiJkGNc2wR5azqP4bVp3ysQANaSewAAn+sgAAAUSigAABwp4gAB+4eAA= From: "Liess, Laura" To: , , X-OriginalArrivalTime: 18 Apr 2007 14:39:58.0371 (UTC) FILETIME=[702B4F30:01C781C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, I am only trying to find something that works for both situations, a)the = VSP gets a country-code-level location (country code or ESRP URI) and b) = VSP gets a more detailed location (country and city or more or a local = PSAP URI).=20 Laura =20 > -----Urspr=FCngliche Nachricht----- > Von: Brian Rosen [mailto:br@brianrosen.net]=20 > Gesendet: Dienstag, 17. April 2007 23:58 > An: Liess, Laura; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > Betreff: RE: [Ecrit] Solution Approaches >=20 >=20 > I don't understand how this would be easier on the access=20 > network than providing the LoST results (e.g. PSAP URI). =20 > That URI may well be an ESRP or a PSAP URI. I don't think=20 > the access network would want to provide a SIP > proxy; that's getting in the middle of emergency call signaling. >=20 > I have this feeling we're talking past one another. >=20 > For example, if the access network knows that all of its=20 > infrastructure (or at least all of it served by a single LIS)=20 > is in a single country, and that country has a single ESRP,=20 > then it doesn't need to do a LoST lookup; the result is=20 > always a constant to it; the "PSAP URI" is always the ESRP,=20 > the dialstring is always the same, and the boundary is always=20 > the same. This makes it very simple if the access network is=20 > in such a situation. Many access networks will be in that=20 > situation. It won't need to determine the fine grained=20 > location until a PSAP asks for it. >=20 > Even in the U.S. with our crazy patchwork of PSAPs and odd=20 > boundaries, many of the LIS service areas will be totally=20 > within one ESRP/PSAP boundary, and no LoST access or fine=20 > grained location determination will be needed until a PSAP=20 > query comes in. >=20 > Brian >=20 > > -----Original Message----- > > From: Liess, Laura [mailto:Laura.Liess@t-systems.com] > > Sent: Tuesday, April 17, 2007 5:11 PM > > To: br@brianrosen.net; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > Subject: AW: [Ecrit] Solution Approaches > >=20 > > Brian, > >=20 > > then, what about this? > > The ASP/ISP provides the client with the LbyR and a SIP URI=20 > of a node=20 > > which has the credentials to get the location from the LIS.=20 > This node=20 > > may be a PSAP, an ESRP or a SIP Proxy in the access network. > >=20 > > Otherwise we probably need more than one approach. > >=20 > > Laura > >=20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Brian Rosen [mailto:br@brianrosen.net] > > > Gesendet: Dienstag, 17. April 2007 22:33 > > > An: Liess, Laura; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > > Betreff: RE: [Ecrit] Solution Approaches > > > > > > > > > Laura > > > > > > Although this might work for an access network operator who has a=20 > > > single ESRP per country, can you accept the fact that it=20 > will not be=20 > > > feasible to have that situation in a country like the U.S., which=20 > > > has 6000 PSAPs and millions of emergency calls, and=20 > without a strong=20 > > > national organization that could MANDATE that every PSAP use one=20 > > > ESRP? In such a circumstance, your proposed solution=20 > fails. Your=20 > > > description requires one ESRP per country. > > > > > > I suspect this will also fail in countries that have a=20 > small number=20 > > > of PSAPs, but also lack a strong national emergency service=20 > > > infrastructure. I am familiar with several countries who=20 > could not=20 > > > reasonably organize such a thing. In many countries, emergency=20 > > > services is VERY local, and assuming a single operator of=20 > critical=20 > > > infrastructure would be very difficult to create. > > > > > > I'd also like to point out that your proposed solution=20 > REQUIRES an=20 > > > ESRP. While I think ESRPs are quite useful, I think=20 > requiring that=20 > > > there must be an entity in the signaling path between the=20 > PSAP and=20 > > > the VSP is not such a good idea. > > > > > > I think solutions that permit an arbitrary PSAP URI to come from=20 > > > LoST routing of the complete address is probably going to be=20 > > > necessary. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Liess, Laura [mailto:Laura.Liess@t-systems.com] > > > > Sent: Tuesday, April 17, 2007 11:37 AM > > > > To: Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > > > Subject: AW: [Ecrit] Solution Approaches > > > > > > > > > > > > Hannes, > > > > > > > > thanks a lot for putting the whole discussion together. > > > > > > > > I can not give you a feedback which is agreed within DT > > > (the internal > > > > agreement process would probably take some time). But I roughly=20 > > > > discussed the approaches with people working on emergency > > > calling. If > > > > we understood the proposal correctly, we have a strong > > > preference for > > > > the approach number 8), which could work as follows: > > > > > > > > The ASP/ISP provides to the client the LbyR, the=20 > country code (or=20 > > > > country and state codes)and the local EC dial string=20 > (at login and=20 > > > > whenever these data change). The client queries LOST and > > > gets back an > > > > ESRP URI. When the caller dials the emergency calling=20 > number, the=20 > > > > client queries again the ASP/VSP for the LbyR and the > > > country code and > > > > LOST query for the ESRP URI. The VSP routes the call to the > > > ESRP. The > > > > ESRP has a shared secret with the LIS, gets the user > > > location and the > > > > correct PSAP and routes the call with the location info to the=20 > > > > PSAP (TLS required). (ESRP or a local LOST does load balancing > > > for PSAPs an > > > > all this stuff). > > > > > > > > Alternatively, the VSPs SIP proxy can do the LOST queries. > > > > > > > > > > > > Laura > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > > Gesendet: Dienstag, 17. April 2007 11:12 > > > > > An: ECRIT > > > > > Betreff: [Ecrit] Solution Approaches > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > I would like to share some potential solution approaches > > > with you to > > > > > deal with the problem of not providing precise location > > > to the end > > > > > host. I had a chance to discuss these aspects with Henning=20 > > > > > face-to-face last Friday. Here is a short summary. > > > > > > > > > > Note that the goal was to avoid some form of=20 > relationship (e.g.,=20 > > > > > business relationship) between the VSP and the ASP/ISP > > > (since this > > > > > would impose a significant deployment problem). > > > > > > > > > > 1) Provide enough location information so that the emergency=20 > > > > > call can be routed to the correct PSAP. Precise location=20 > > > > > information would be provided to the PSAP. This approach was=20 > > > > > already discussed on the list. We need feedback from, > > > > > for example, Barbara and Laura whether they feel comfortable > > > > > with this > > > > > approach. > > > > > > > > > > CONSEQUENCE: No changes needed. > > > > > > > > > > 2) Provide LbyR + Dial String + PSAP URI to the end host. > > > We could > > > > > ignore the potential security vulnerabilities if=20 > charging does=20 > > > > > not work on a call-by-call basis. > > > > > > > > > > CONSEQUENCE: No changes needed. > > > > > > > > > > 3) Provide LbyR + Dial String + PSAP URI to the end host. > > > VSP does a > > > > > reverse LoST lookup to verify the PSAP URI. > > > > > > > > > > CONSEQUENCE: Solution needs to be developed. > > > > > > > > > > 4) Provide LbyR + Dial String + PSAP URI to the end host. VSP=20 > > > > > verifies the PSAP URI with the PSAP URIs being flooded (using=20 > > > > > the LoST synchronization mechanism). This mechanism is=20 > > > > > potentially similar to (3) > > > > > -- details might vary. (3) might use a distributed approach=20 > > > > > whereas this is brute force. > > > > > > > > > > CONSEQUENCE: Solution needs to be developed. > > > > > > > > > > 5) Emergency calls are routed via the SIP proxy of=20 > the VSP and=20 > > > > > subsequently via a SIP proxy in the ASP/ISP (redirect=20 > mode) SIP=20 > > > > > Location Conveyance would be used instead of GEOPRIV L7 LCP > > > > > Assumption: No service level agreement (or business > > > > > agreement) between > > > > > VSP and ISP/ASP for this type of SIP emergency=20 > message routing=20 > > > > > required. > > > > > > > > > > CONSEQUENCE: No changes needed. Potential problems with > > > SIP Identity > > > > > possible > > > > > > > > > > 6) Emergency calls are routed via the SIP proxy of=20 > the VSP and=20 > > > > > subsequently via a SIP proxy in the ASP/ISP (no redirect > > > > > mode) SIP Location Conveyance would be used instead=20 > of GEOPRIV=20 > > > > > L7 LCP > > > > > Assumption: No service level agreement (or business > > > > > agreement) between > > > > > VSP and ISP/ASP for this type of SIP emergency=20 > message routing=20 > > > > > required. > > > > > > > > > > CONSEQUENCE: No changes needed. > > > > > > > > > > 7) Decoupled authentication for SIP message routing > > > Authentication > > > > > exchange between the end host and the VSP (e.g., TLS=20 > to obtain a=20 > > > > > SAML assertion) Authentication credentials are then=20 > added to the=20 > > > > > SIP emergency message > > > > > that is routed via the SIP proxy in the VSP/ISP. > > > > > No service level agreement (or business agreement)=20 > between VSP and > > > > > ISP/ASP needed. > > > > > > > > > > CONSEQUENCE: Security extension for this purpose needs to be=20 > > > > > progressed (already available in draft form) > > > > > > > > > > 8) Country Code Routing > > > > > > > > > > LIS provides country code to the end host. The end host > > > routes the > > > > > SIP emergency message via the VSP towards a ESRP that > > > corresponds to > > > > > the country code. Then, ESRP fetches more detailed location=20 > > > > > information todo routing within the country. > > > > > > > > > > CONSEQUENCE: No changes to the protocol mechanisms.=20 > Deployment=20 > > > > > of ESRPs that work this way are needed. Establishment of ESRP=20 > > > > > <-> ISP/ASP is more difficult than with PSAP <->=20 > ISP/ASP since=20 > > > > > there are far more nodes to > > > > > consider. > > > > > > > > > > 9) Assume end hosts have certs for emergency services; > > > routing via > > > > > SIP proxy in ISP/ASP without traversing VSP in the emergency=20 > > > > > case. Existing credential infrastructure can be used when=20 > > > > > utilizing SIP Cert. > > > > > > > > > > CONSEQUENCE: Architectural aspects need to be developed. A=20 > > > > > little bit more difficult to deploy for VSP. Potential issues > > > with callback > > > > > (to > > > > > AoR) since end host is not registered with VSP. > > > > > > > > > > 10) Routing via SIP proxy in ISP/ASP. Diameter SIP > > > application used > > > > > to authenticate end host > > > > > Assumption: No roaming agreement assumed for ISP/ASP <-> > > > VSP Diameter > > > > > SIP interaction. > > > > > > > > > > CONSEQUENCE: Problems with legacy credentials, previously > > > mentioned > > > > > call back problems since end host is not registered with VSP,=20 > > > > > Diameter SIP application would need to be profiled. > > > > > > > > > > Thoughts? > > > > > > > > > > Ciao > > > > > Hannes > > > > > > > > > > > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 10:54:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBY0-0000YC-7B; Wed, 18 Apr 2007 10:54:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBXy-0000WL-In for ecrit@ietf.org; Wed, 18 Apr 2007 10:54:14 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeBXw-0004hq-Al for ecrit@ietf.org; Wed, 18 Apr 2007 10:54:14 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HeBXv-000898-5i; Wed, 18 Apr 2007 10:54:11 -0400 Message-ID: <46263112.9010506@bbn.com> Date: Wed, 18 Apr 2007 10:54:10 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] A Concrete Proposal for LbyR Emergency Calling References: <0e9f01c781ba$e2895660$640fa8c0@cis.neustar.com> <46261A73.2060909@gmx.net> <252BBEFA-B21A-4E4D-81DF-ED586D402B95@cs.columbia.edu> In-Reply-To: <252BBEFA-B21A-4E4D-81DF-ED586D402B95@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning, Since LoST is only defined at the XML level, couldn't you just define a SIP binding (possibly an event package)? The target could subscribe it's LoST status on the access network LoST resolver. --RB Henning Schulzrinne wrote: > Periodically doesn't cut it, since there's no way for the device to know > how long it will be residing within that service region. (Obviously, > querying every few seconds will work well enough, but this will kill any > mobile device's battery.) I keep saying that, but somehow it doesn't > seem to register. If you go that route, you need a subscription > mechanism - just like the one already offered by SIP configuration. > > On Apr 18, 2007, at 9:17 AM, Hannes Tschofenig wrote: > >> The optimized version. >> >> The only problem with both versions: In a mobility environment the >> LoST response might have changed. Hence, the end host either (a) >> periodically needs to trigger step (2) - (5) or the protocol used >> between the SIP UA and the LIS is not based on HTTP but rather on SIP >> (and the LIS sends a notification when the location changed enough so >> that the LoST response changed as well). >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 10:55:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBZf-0001at-7I; Wed, 18 Apr 2007 10:55:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBZd-0001ZQ-Sq for ecrit@ietf.org; Wed, 18 Apr 2007 10:55:57 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeBZb-0004pM-MQ for ecrit@ietf.org; Wed, 18 Apr 2007 10:55:57 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3IEtmug004945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Apr 2007 10:55:48 -0400 (EDT) In-Reply-To: <0ec201c781c1$419a2200$640fa8c0@cis.neustar.com> References: <0ec201c781c1$419a2200$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <47579E5E-5255-434A-93C1-4BEDF7070C9A@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how todoendpoint centric LCP without giving away the store Date: Wed, 18 Apr 2007 10:57:03 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org My concern is that we're engineering in the dark. Currently, we have exactly one carrier that has provided a semblance of design requirements. My translation of these requirements is "I don't want to build new infrastructure (since nobody is going to pay me for it)". However, all the proposals so far involve significant new infrastructure, while increasing complexity in the end system. The complexity I'm concerned about is not so much protocol complexity, although that's an issue, but rather having a multitude of code paths that an end system has to try. Each of these has to be tested and debugged; our experience with that in other SIP features has not been good. The complexity takes the form of lots of decisions of the "If this configuration option is set, but the other one is not, and that request returns a foo rather than a bar, do this, but otherwise wait for 30 seconds and try something else" kind. Many of these will never be exercised - until a customer takes the device to place where it hasn't been before. This is why I'm insisting on having a very simple logic so that a device always does the same thing, even if the environment changes. (Requirements for data synchronization and coordination is another common source of failures.) The ESRP solution again has this drawback, as it needs to be discovered. It can't be discovered via LoST, since it would only be used for a specific access provider, not universally. Thus, you now need to have an explicit configuration option for ESRP, adding another diamond to the flow chart. You then have to answer questions such as: Should I use the ESRP even if I have additional location information? Is the ESRP only available to subscribers? (This could happen for a WiFi device using a DT-provided DSL access, but with built-in GPS.) Is the ESRP serving all emergency services, or is the gas leak service on a different one or not reachable at all? The same is true for LbyR that are only resolvable by the PSAP. The UA can't know that, so it means having to branch on failure - yet another test case that's unlikely to be exercised by developers if this mode of operation only occurs in a few access networks. Thus, I'm advocating a solution that follows the simple logic flow for what we hope to be the common case, i.e., where end systems obtain location: - get location, even if incomplete; if an LbyR, it has to resolve to something useful, even if authorized users (PSAPs) get more detailed information - get a URL from any LoST server, using that exact information, operated by any number of organizations - send the request Henning On Apr 18, 2007, at 9:55 AM, Brian Rosen wrote: > I think FORCING an access provider to deploy an ESRP when they > don't agree > to give location to endpoints or arbitrary VSPs is not an option. > > I also think having the access network as an active element in the > call > chain is very unattractive, especially when proxy routing has the > VSP also > in the call chain. > > I'm okay with allowing it. I think the PSAPs would have an opinion > on its > use. > > Brian > >> -----Original Message----- >> From: Marc Linsner [mailto:mlinsner@cisco.com] >> Sent: Wednesday, April 18, 2007 9:41 AM >> To: 'Brian Rosen' >> Cc: 'ECRIT' >> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how >> todoendpoint centric LCP without giving away the store >> >> >> >>> >>> Let's keep our eye on the goal, which was to allow validation >>> of a PSAP URI by a downstream routing element. >> >> Did we decide that the access provider operating an ESRP is not an >> option? >> >> (facilitates hiding of all location info from the UA) >> >> >> -Marc- > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 10:56:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBaA-0001sp-W2; Wed, 18 Apr 2007 10:56:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBaA-0001rj-3P for ecrit@ietf.org; Wed, 18 Apr 2007 10:56:30 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeBa8-0004uA-Sf for ecrit@ietf.org; Wed, 18 Apr 2007 10:56:30 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HeBa8-0008BC-5W; Wed, 18 Apr 2007 10:56:28 -0400 Message-ID: <4626319B.1050100@bbn.com> Date: Wed, 18 Apr 2007 10:56:27 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] A Concrete Proposal for LbyR Emergency Calling References: <0ead01c781bd$3927a510$640fa8c0@cis.neustar.com> In-Reply-To: <0ead01c781bd$3927a510$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think the point is that LCP does one thing (location provisioning) and LoST does another (mapping); both are restricted types of configuration. It's just clean engineering to use distinct protocols for distinct functions when possible. --Richard Brian Rosen wrote: > Where did we cross a bright line? > > I must have missed it. > > What you are saying is that an endpoint can do an LCP request and a LoST > request separately, but something that combines them has to be SIP > configuration. > > What if the endpoint uses, oh, say, AIM? Skype? > > LoST returns dialstrings. Is that SIP configuration? > HELD returns things that go in -conveyance. Is that SIP configuration? > > Brian > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Wednesday, April 18, 2007 9:19 AM >> To: Brian Rosen >> Cc: 'Richard Barnes'; 'ECRIT' >> Subject: Re: [Ecrit] A Concrete Proposal for LbyR Emergency Calling >> >> I'll again protest as you're converting HELD into a SIP configuration >> protocol. This is an architecturally fundamentally bad idea. >> >> On Apr 18, 2007, at 9:10 AM, Brian Rosen wrote: >> >>> Mine is: >>> >>> 1. DHCP server -> UA: HELD server URI >>> 2. UA -> HELD server: Location request with identifiers >>> 3. HELD server -> LoST Server: query with LbyV >>> 4. LoST server -> HELD server: LoST Response >>> 5. HELD server -> UA: LbyR + LoST response >>> >>> As before, in many cases, steps 3/4 can be omitted because the LIS >>> service >>> area is known to be within one PSAP boundary >>> >>> Brian > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 10:59:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBdW-0002IY-0W; Wed, 18 Apr 2007 10:59:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBdV-0002IS-G4 for ecrit@ietf.org; Wed, 18 Apr 2007 10:59:57 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeBdU-0005pk-7M for ecrit@ietf.org; Wed, 18 Apr 2007 10:59:57 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3IExhpW006055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Apr 2007 10:59:43 -0400 (EDT) In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA03B0F33C@crexc41p> References: <46261317.1070606@bbn.com> <7582BC68E4994F4ABF0BD4723975C3FA03B0F33C@crexc41p> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] A Concrete Proposal for LbyR Emergency Calling Date: Wed, 18 Apr 2007 11:00:59 -0400 To: "Stark, Barbara" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org We're all guessing here, but LoST servers have been advocated as being run by at least four entities: - the ISP - a pseudo-ISP (e.g., a hotel or mid-sized enterprise) - the VSP - some public entity, such as a state, DOT or FEMA (or even NENA) I don't think any of us knows, but I think we have to prepared for the case that there will be multiple hierarchies and certainly multiple resolvers, just like we have for DNS today. Thus, a single UA might have access to multiple LoST servers (and that's a good thing). Henning On Apr 18, 2007, at 10:11 AM, Stark, Barbara wrote: > I'm a bit fuzzy as to who will be running LoST servers. I thought I'd > read somewhere that VSPs might have cached LoST data, and be able to > tell their endpoints to come to their LoST server, first. If this is > true, and if I don't trust VSPs to dereference, can I trust LoST > servers > to dereference? > > Or did I misunderstand the LoST server architecture somewhere down the > line? > Barbara _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 11:03:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBgv-0002vJ-Gn; Wed, 18 Apr 2007 11:03:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBgt-0002vE-VW for ecrit@ietf.org; Wed, 18 Apr 2007 11:03:27 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeBgr-0006O4-OE for ecrit@ietf.org; Wed, 18 Apr 2007 11:03:27 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3IF34CD003278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Apr 2007 11:03:04 -0400 (EDT) In-Reply-To: <46263112.9010506@bbn.com> References: <0e9f01c781ba$e2895660$640fa8c0@cis.neustar.com> <46261A73.2060909@gmx.net> <252BBEFA-B21A-4E4D-81DF-ED586D402B95@cs.columbia.edu> <46263112.9010506@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <725A291D-8518-4EC9-909A-52878003426A@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] A Concrete Proposal for LbyR Emergency Calling Date: Wed, 18 Apr 2007 11:04:18 -0400 To: Richard Barnes X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Yes, you've just re-discovered how SIP configuration works. On Apr 18, 2007, at 10:54 AM, Richard Barnes wrote: > Henning, > > Since LoST is only defined at the XML level, couldn't you just > define a SIP binding (possibly an event package)? The target could > subscribe it's LoST status on the access network LoST resolver. > > --RB > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 11:08:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBlG-0002Ql-Fo; Wed, 18 Apr 2007 11:07:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeBlE-0002Qb-Sa; Wed, 18 Apr 2007 11:07:56 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeBlC-0007Kf-EG; Wed, 18 Apr 2007 11:07:56 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3IF7m3X027193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Apr 2007 11:07:48 -0400 (EDT) In-Reply-To: <0ec101c781c0$cee58240$640fa8c0@cis.neustar.com> References: <0ec101c781c0$cee58240$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <412BA868-9E51-4E01-8526-388789C505D7@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpoint centric LCP without giving away the store Date: Wed, 18 Apr 2007 11:09:04 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: 'GEOPRIV' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > Are we, or are we not agreeing that we can't force ESRP per country or > single PSAP per country? If we agree that irregular boundaries per > ESRP are > possible, then coarse location is insufficient for a LoST query and > we need > some other solution. > That's not true. It just means that coarse location can't be used everywhere. That's a very different statement. I'd rather have 5% of the population get their street address than have to add complexity to 100% of the UAs, with additional failure modes. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 11:24:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeC1b-0005LD-00; Wed, 18 Apr 2007 11:24:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeC1Z-0005EA-Fp for ecrit@ietf.org; Wed, 18 Apr 2007 11:24:49 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeC1Z-00047x-18 for ecrit@ietf.org; Wed, 18 Apr 2007 11:24:49 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HeC1M-0002rc-Iw; Wed, 18 Apr 2007 10:24:36 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how todoendpoint centric LCP without giving away the store Date: Wed, 18 Apr 2007 11:24:45 -0400 Message-ID: <0f0601c781cd$b38ab800$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceByaM2xwz8WTnZSICGcBQvpdCFewAAS0jw In-Reply-To: <47579E5E-5255-434A-93C1-4BEDF7070C9A@cs.columbia.edu> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I understand your point of view, and I'm sympathetic to it. I just don't see how to do it simpler and meet the constraints. You insist that we prove there is a requirement to not reveal location to endpoints and/or VSPs. I'll work on that, but please, I really, truly think it's a significant barrier to deployment of the entire mechanism. I think Martin is right about how it will evolve, but I've heard the problem from quite a few people now. Enough so that I've given up fighting it. I don't like it, but it's a piece of reality to me now. You always have to run the LCP first. I think if it returns the LoST results, stop, otherwise query LoST is indeed a complication, but a simple one. If we can get flooding to work so VSP validation of PSAP URI takes no client effort, maybe that's what we should do. Fixing LoST so it can take what it gets from the LCP and work is another viable path, although I don't see how to do it cleanly yet. Richard and Andy are trying, but it doesn't work for me yet. If it does, that's a complication, but acceptable to me. I do think we could help ourselves by listing the requirements here: 1. An LbyR may not be dereferenceable by the endpoint, yet it must be able to get LoST results 2. A PSAP URI may not be valid (because of theft of service), and a VSP must be able to validate it. The VSP may not be able to dereference the LbyR either 3. We cannot assume ESRP per country/state/city; boundaries may be irregular 4. We cannot assume the access network or the VSP can control which LoST server is used Others? Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, April 18, 2007 10:57 AM > To: Brian Rosen > Cc: 'Marc Linsner'; 'ECRIT' > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how > todoendpoint centric LCP without giving away the store > > My concern is that we're engineering in the dark. Currently, we have > exactly one carrier that has provided a semblance of design > requirements. My translation of these requirements is "I don't want > to build new infrastructure (since nobody is going to pay me for > it)". However, all the proposals so far involve significant new > infrastructure, while increasing complexity in the end system. > > The complexity I'm concerned about is not so much protocol > complexity, although that's an issue, but rather having a multitude > of code paths that an end system has to try. Each of these has to be > tested and debugged; our experience with that in other SIP features > has not been good. The complexity takes the form of lots of decisions > of the > > "If this configuration option is set, but the other one is not, and > that request returns a foo rather than a bar, do this, but otherwise > wait for 30 seconds and try something else" > > kind. Many of these will never be exercised - until a customer takes > the device to place where it hasn't been before. This is why I'm > insisting on having a very simple logic so that a device always does > the same thing, even if the environment changes. (Requirements for > data synchronization and coordination is another common source of > failures.) > > The ESRP solution again has this drawback, as it needs to be > discovered. It can't be discovered via LoST, since it would only be > used for a specific access provider, not universally. Thus, you now > need to have an explicit configuration option for ESRP, adding > another diamond to the flow chart. You then have to answer questions > such as: Should I use the ESRP even if I have additional location > information? Is the ESRP only available to subscribers? (This could > happen for a WiFi device using a DT-provided DSL access, but with > built-in GPS.) Is the ESRP serving all emergency services, or is the > gas leak service on a different one or not reachable at all? > > The same is true for LbyR that are only resolvable by the PSAP. The > UA can't know that, so it means having to branch on failure - yet > another test case that's unlikely to be exercised by developers if > this mode of operation only occurs in a few access networks. > > Thus, I'm advocating a solution that follows the simple logic flow > for what we hope to be the common case, i.e., where end systems > obtain location: > > - get location, even if incomplete; if an LbyR, it has to resolve to > something useful, even if authorized users (PSAPs) get more detailed > information > > - get a URL from any LoST server, using that exact information, > operated by any number of organizations > > - send the request > > Henning > > On Apr 18, 2007, at 9:55 AM, Brian Rosen wrote: > > > I think FORCING an access provider to deploy an ESRP when they > > don't agree > > to give location to endpoints or arbitrary VSPs is not an option. > > > > I also think having the access network as an active element in the > > call > > chain is very unattractive, especially when proxy routing has the > > VSP also > > in the call chain. > > > > I'm okay with allowing it. I think the PSAPs would have an opinion > > on its > > use. > > > > Brian > > > >> -----Original Message----- > >> From: Marc Linsner [mailto:mlinsner@cisco.com] > >> Sent: Wednesday, April 18, 2007 9:41 AM > >> To: 'Brian Rosen' > >> Cc: 'ECRIT' > >> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how > >> todoendpoint centric LCP without giving away the store > >> > >> > >> > >>> > >>> Let's keep our eye on the goal, which was to allow validation > >>> of a PSAP URI by a downstream routing element. > >> > >> Did we decide that the access provider operating an ESRP is not an > >> option? > >> > >> (facilitates hiding of all location info from the UA) > >> > >> > >> -Marc- > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 11:25:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeC2a-000656-17; Wed, 18 Apr 2007 11:25:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeC2Y-00061x-Dk for ecrit@ietf.org; Wed, 18 Apr 2007 11:25:50 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeC2W-0004Cq-On for ecrit@ietf.org; Wed, 18 Apr 2007 11:25:50 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HeC2W-0001M4-3u; Wed, 18 Apr 2007 11:25:48 -0400 Message-ID: <4626387A.4040807@bbn.com> Date: Wed, 18 Apr 2007 11:25:46 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] A Concrete Proposal for LbyR Emergency Calling References: <0e9f01c781ba$e2895660$640fa8c0@cis.neustar.com> <46261A73.2060909@gmx.net> <252BBEFA-B21A-4E4D-81DF-ED586D402B95@cs.columbia.edu> <46263112.9010506@bbn.com> <725A291D-8518-4EC9-909A-52878003426A@cs.columbia.edu> In-Reply-To: <725A291D-8518-4EC9-909A-52878003426A@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The difference being that LoST is (1) more specialized than general SIP configuration, and (2) more generally applicable than SIP configuration. --RB Henning Schulzrinne wrote: > Yes, you've just re-discovered how SIP configuration works. > > On Apr 18, 2007, at 10:54 AM, Richard Barnes wrote: > >> Henning, >> >> Since LoST is only defined at the XML level, couldn't you just define >> a SIP binding (possibly an event package)? The target could subscribe >> it's LoST status on the access network LoST resolver. >> >> --RB >> >> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 11:32:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeC8j-00033F-9a; Wed, 18 Apr 2007 11:32:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeC8h-00033A-CW for ecrit@ietf.org; Wed, 18 Apr 2007 11:32:11 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeC8g-00057J-6H for ecrit@ietf.org; Wed, 18 Apr 2007 11:32:11 -0400 Received: from [160.39.242.199] (dyn-160-39-242-199.dyn.columbia.edu [160.39.242.199]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3IFVuQ3004409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Apr 2007 11:31:56 -0400 (EDT) In-Reply-To: <4626387A.4040807@bbn.com> References: <0e9f01c781ba$e2895660$640fa8c0@cis.neustar.com> <46261A73.2060909@gmx.net> <252BBEFA-B21A-4E4D-81DF-ED586D402B95@cs.columbia.edu> <46263112.9010506@bbn.com> <725A291D-8518-4EC9-909A-52878003426A@cs.columbia.edu> <4626387A.4040807@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] A Concrete Proposal for LbyR Emergency Calling Date: Wed, 18 Apr 2007 11:31:55 -0400 To: Richard Barnes X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org But your notion of a SIP event package ties it to SIP, so you've now created some weird hybrid which is neither LoST nor SIP configuration. Plus, again, you've increased UA behavorial options, as the UA now has to discover whether to use LoST-over-SIP or LoST- over-HTTP. Yet more complexity and failure modes. On Apr 18, 2007, at 11:25 AM, Richard Barnes wrote: > The difference being that LoST is (1) more specialized than general > SIP configuration, and (2) more generally applicable than SIP > configuration. > --RB > > > > Henning Schulzrinne wrote: >> Yes, you've just re-discovered how SIP configuration works. >> On Apr 18, 2007, at 10:54 AM, Richard Barnes wrote: >>> Henning, >>> >>> Since LoST is only defined at the XML level, couldn't you just >>> define a SIP binding (possibly an event package)? The target >>> could subscribe it's LoST status on the access network LoST >>> resolver. >>> >>> --RB >>> >>> > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 11:33:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeC9w-0004EM-Br; Wed, 18 Apr 2007 11:33:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeC9u-00045P-4a; Wed, 18 Apr 2007 11:33:26 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeC9s-0005FH-SD; Wed, 18 Apr 2007 11:33:26 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HeC9g-000314-37; Wed, 18 Apr 2007 10:33:12 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpoint centric LCP without giving away the store Date: Wed, 18 Apr 2007 11:33:20 -0400 Message-ID: <0f0a01c781ce$e6da22d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceBy037gnfr/27bRPSm7/G1aAGbygAAsN1Q In-Reply-To: <412BA868-9E51-4E01-8526-388789C505D7@cs.columbia.edu> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 'GEOPRIV' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'm not sure I understand what you are saying. I'll agree that coarse location may work some times. I wouldn't care to speculate how often it does or doesn't. I don't think it matters. It doesn't sometimes. Does that mean we should misroute in those cases where you only get coarse location, and you have an irregular boundary that "misses"? I suspect that would not fly with the access networks that have the hiding problem. You are giving them an unacceptable choice: give up accurate location to the endpoint or be responsible for misroute. That may meet your notion of endpoint simplicity, but it won't be deployed I think. You also seem to be willing to accept that the client will have two locations to deal with: coarse LbyV and fine LbyR. Not a complication I would want to have to deal with given my alternative. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, April 18, 2007 11:09 AM > To: Brian Rosen > Cc: 'Hannes Tschofenig'; 'GEOPRIV'; 'ECRIT' > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > doendpoint centric LCP without giving away the store > > > > > Are we, or are we not agreeing that we can't force ESRP per country or > > single PSAP per country? If we agree that irregular boundaries per > > ESRP are > > possible, then coarse location is insufficient for a LoST query and > > we need > > some other solution. > > > > That's not true. It just means that coarse location can't be used > everywhere. That's a very different statement. I'd rather have 5% of > the population get their street address than have to add complexity > to 100% of the UAs, with additional failure modes. > > Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 11:50:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCQX-0007eB-Ke; Wed, 18 Apr 2007 11:50:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeCQW-0007e3-Jy for ecrit@ietf.org; Wed, 18 Apr 2007 11:50:36 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeCQV-00017q-CU for ecrit@ietf.org; Wed, 18 Apr 2007 11:50:36 -0400 Received: from [160.39.242.199] (dyn-160-39-242-199.dyn.columbia.edu [160.39.242.199]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3IFoPtP009926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Apr 2007 11:50:29 -0400 (EDT) In-Reply-To: <0f0601c781cd$b38ab800$640fa8c0@cis.neustar.com> References: <0f0601c781cd$b38ab800$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <072E3A77-AA06-42CC-ADD4-539D6683BF04@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how todoendpoint centric LCP without giving away the store Date: Wed, 18 Apr 2007 11:50:25 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > You always have to run the LCP first. I think if it returns the LoST > results, stop, otherwise query LoST is indeed a complication, but a > simple > Like others, I disagree with the assumption of combining LCP and LoST results. > > > I do think we could help ourselves by listing the requirements here: > > 1. An LbyR may not be dereferenceable by the endpoint, yet it must > be able > to get LoST results > No, this yields another failure mode, since the UA can't know that an LbyR is meant only for somebody else. An LbyR provided to the UA MUST always return some information, even if an authenticated user gets more and even if that public information is only a country code. > 2. A PSAP URI may not be valid (because of theft of service), and a > VSP must > be able to validate it. The VSP may not be able to dereference the > LbyR > either That's a separate discussion. I think it would be helpful to keep it separate, as the location hiding stuff is messy enough as is. A VSP would need this with or without location hiding. I agree with the second sentence, but it is not connected to the problem in the first part of the sentence. > 3. We cannot assume ESRP per country/state/city; boundaries may be > irregular However, for some deployment cases, this is viable. For example, for DT, this might actually be a good solution, since it would allow them to build a cheap location infrastructure that simply returns the city of the DSLAM, given that this alignment seems to exist in the country they provide service to. This requires no interaction with the OSS (which seems to be the cause of the infrastructure expense), as the user identifier in RADIUS contains that information already. > 4. We cannot assume the access network or the VSP can control which > LoST > server is used > Agreed. > Others? > 5. User agents cannot require additional configuration to discover which particular environment (hiding or no hiding) they find themselves in. UAs should not have to deduce the desired behavior by having other operations, such as LbyR resolutions, fail, as failures can take a long time. 6. User agents need to be able to determine PSAP/ESRP URLs prior to the call. 7. UAs need to be able to discover at least their country code so that they can obtain the dial string ahead of the emergency call via LoST. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 12:57:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeDSq-0003cR-5n; Wed, 18 Apr 2007 12:57:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeDSk-0003X5-Cj; Wed, 18 Apr 2007 12:56:58 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeDQP-0001kh-1F; Wed, 18 Apr 2007 12:54:33 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3IGsI3o005886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Apr 2007 12:54:18 -0400 (EDT) In-Reply-To: <0f0a01c781ce$e6da22d0$640fa8c0@cis.neustar.com> References: <0f0a01c781ce$e6da22d0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpoint centric LCP without giving away the store Date: Wed, 18 Apr 2007 12:55:34 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: 'GEOPRIV' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 18, 2007, at 11:33 AM, Brian Rosen wrote: > I'm not sure I understand what you are saying. > > I'll agree that coarse location may work some times. I wouldn't > care to > speculate how often it does or doesn't. I don't think it matters. It This seems to be very country-specific. Thus, in some countries, this will be quite viable, in others, less so. For DT, for example, you could have a very simple architecture: - Use normal LCP, returning Gemeinde (city/town), Bundesstaat (state) and country (DE). This is sufficient for determining the PSAP and requires zero interaction with the OSS. - Return an LbyR that is similar to what is used today as an identifier (phone number?), which resolves to the rough information above. > doesn't sometimes. Does that mean we should misroute in those > cases where > you only get coarse location, and you have an irregular boundary that > "misses"? I suspect that would not fly with the access networks > that have Definitely not. It would be the responsibility of the ISP to deliver location information of sufficient granularity to prevent misroutes. In some small number of corner cases (typically, the one boundary street between PSAP regions), this would mean delivering a street address or a geo region. This is easy for the ISP to determine - they just query LoST and get the coverage regions. If you don't want to do this, just return the *geo* boundary of the PSAP to the customer as location information via LCP, just like you'd return an imprecise mapping from a wireless system, as a polygon. By our mapping rules, LoST computes the centroid (trivial) and returns the PSAP URL. I think this is somewhat similar to what Andy is proposing, but requires no new effort. This reveals zero additional information to the client, beyond the coverage region of the PSAP, but the UA behavior is exactly the same as in the no-hiding case. > the hiding problem. You are giving them an unacceptable choice: > give up > accurate location to the endpoint or be responsible for misroute. > That may > meet your notion of endpoint simplicity, but it won't be deployed I > think. I don't see this as the alternative. All I require is that ISP give up a tiny fraction of its location information in some corner cases. In most communities, all of the customers will only get city-level or county-level information, which corresponds to what their phone number already tells them. I think this is a fair bargain. I'd like to hear good reasons from real carriers as to why this is not acceptable. Shadow boxing, without talking to real customers, seems likely to lead us to design something that doesn't actually help. (Just as I believe that the whole architecture proposed doesn't actually address the don't-spend- money objective of DT.) > > You also seem to be willing to accept that the client will have two > locations to deal with: coarse LbyV and fine LbyR. Not a > complication I > would want to have to deal with given my alternative. Not really. I advocate returning a single LbyR, which resolves to minimal information sufficient for routing for the general public and, with PSAP authentication, to precise location information for dispatch. Henning > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 14:02:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeETw-0002xw-85; Wed, 18 Apr 2007 14:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeETu-0002mp-Cf; Wed, 18 Apr 2007 14:02:14 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeETs-00010o-TK; Wed, 18 Apr 2007 14:02:14 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HeETe-0007nA-7M; Wed, 18 Apr 2007 13:01:58 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to doendpoint centric LCP without giving away the store Date: Wed, 18 Apr 2007 14:02:07 -0400 Message-ID: <0f5c01c781e3$b004eaa0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceB2jLjCmvef5D7QMe9NoQWMgzx9gAB4mHQ In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: 'GEOPRIV' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I can live with this way out of the mess. I rather like the idea of returning the PSAP service boundary polygon on the endpoint's (or VSP's) dereference. The latter (as well as coarse location when it works) also fixes the validation problem; the VSP dereferences, gets the polygon, queries LoST with it, and gets the PSAP URI. I agree that in lots of cases, a very coarse location return from the LbyR is sufficient, and access networks ought to be able to take advantage of it when it happens. I guess we need to hear from carriers. I think you already raised the point that in most cases, an IP address yields city level location, albeit VPNs often obscure that. And while you brought it up, I do think a very nice user part of a location reference is a hashed telephone number. Most of the DSL networks, for example, do have telephone numbers which actually are easy to turn into service address in the existing databases. I'd prefer it be hashed so that we don't reveal extra user information. I particularly think that idea will be quite useful in dealing with legacy wireline systems, which already associate TN with location. Adding a (hash of) TN with a provisioned LIS domain on a Geolocation header in, or near a PSTN to SIP gateway would be a very painless way to get location from a legacy wireline system into a next generation emergency call system. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, April 18, 2007 12:56 PM > To: Brian Rosen > Cc: 'Hannes Tschofenig'; 'GEOPRIV'; 'ECRIT' > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > doendpoint centric LCP without giving away the store > > > On Apr 18, 2007, at 11:33 AM, Brian Rosen wrote: > > > I'm not sure I understand what you are saying. > > > > I'll agree that coarse location may work some times. I wouldn't > > care to > > speculate how often it does or doesn't. I don't think it matters. It > > This seems to be very country-specific. Thus, in some countries, this > will be quite viable, in others, less so. > > For DT, for example, you could have a very simple architecture: > > - Use normal LCP, returning Gemeinde (city/town), Bundesstaat > (state) and country (DE). This is sufficient for determining the PSAP > and requires zero interaction with the OSS. > > - Return an LbyR that is similar to what is used today as an > identifier (phone number?), which resolves to the rough information > above. > > > > doesn't sometimes. Does that mean we should misroute in those > > cases where > > you only get coarse location, and you have an irregular boundary that > > "misses"? I suspect that would not fly with the access networks > > that have > > Definitely not. It would be the responsibility of the ISP to deliver > location information of sufficient granularity to prevent misroutes. > In some small number of corner cases (typically, the one boundary > street between PSAP regions), this would mean delivering a street > address or a geo region. This is easy for the ISP to determine - they > just query LoST and get the coverage regions. > > If you don't want to do this, just return the *geo* boundary of the > PSAP to the customer as location information via LCP, just like you'd > return an imprecise mapping from a wireless system, as a polygon. By > our mapping rules, LoST computes the centroid (trivial) and returns > the PSAP URL. I think this is somewhat similar to what Andy is > proposing, but requires no new effort. > > This reveals zero additional information to the client, beyond the > coverage region of the PSAP, but the UA behavior is exactly the same > as in the no-hiding case. > > > > the hiding problem. You are giving them an unacceptable choice: > > give up > > accurate location to the endpoint or be responsible for misroute. > > That may > > meet your notion of endpoint simplicity, but it won't be deployed I > > think. > > I don't see this as the alternative. All I require is that ISP give > up a tiny fraction of its location information in some corner cases. > In most communities, all of the customers will only get city-level or > county-level information, which corresponds to what their phone > number already tells them. > > I think this is a fair bargain. I'd like to hear good reasons from > real carriers as to why this is not acceptable. Shadow boxing, > without talking to real customers, seems likely to lead us to design > something that doesn't actually help. (Just as I believe that the > whole architecture proposed doesn't actually address the don't-spend- > money objective of DT.) > > > > > > You also seem to be willing to accept that the client will have two > > locations to deal with: coarse LbyV and fine LbyR. Not a > > complication I > > would want to have to deal with given my alternative. > > Not really. I advocate returning a single LbyR, which resolves to > minimal information sufficient for routing for the general public > and, with PSAP authentication, to precise location information for > dispatch. > > Henning > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 14:10:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeEc5-0008Pk-ST; Wed, 18 Apr 2007 14:10:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeEc4-0008PT-Mz for ecrit@ietf.org; Wed, 18 Apr 2007 14:10:40 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeEc2-0003W7-O7 for ecrit@ietf.org; Wed, 18 Apr 2007 14:10:40 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3IIAb14026056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Apr 2007 14:10:37 -0400 (EDT) In-Reply-To: <46261D61.6080005@gmx.net> References: <46261D61.6080005@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <67E3053F-FA62-4A76-A7AD-9D92D9CF1D8B@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Subscription Concept for Hiding (partial) locations Date: Wed, 18 Apr 2007 14:11:52 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 18, 2007, at 9:30 AM, Hannes Tschofenig wrote: > Hi all > > would folks be happy with the following exchange: > > UA <-> DHCP: URI to LIS DHCP or SIP configuration, yes. > UA --> LIS: Subscribe to LbyR+Dial String+PSAP URI This would be a new protocol, as no current proposal supports that. I thought one of the consensus calls in Prague was not to abuse HTTP into a event notification protocol, for example. > UA <-- LIS: Notification Again, this is the SIP configuration model. Since the notification protocol is, by definition, going to be a particular protocol, you are either going to create a wholly new event notification architecture that is neither XMPP nor SIP, or use SIP (or XMPP), which then makes it ill-suited for native speakers of other protocols. We've had this problem before, in the context of using SIP as LCP (I have a semi-stale draft on that, if you like...), where there was protest based on "I don't speak SIP and don't want to implement SIP just to get location information". I'm sure if we pick XMPP, say, we'd get the same complaint from the SIP crowd. > > Ciao > Hannes > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 14:15:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeEgT-0004e1-Ks; Wed, 18 Apr 2007 14:15:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeEgR-0004dw-HS for ecrit@ietf.org; Wed, 18 Apr 2007 14:15:11 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeEgO-0004O4-Uk for ecrit@ietf.org; Wed, 18 Apr 2007 14:15:11 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 18 Apr 2007 20:15:07 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 20:15:06 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [Ecrit] Solution Approaches Date: Wed, 18 Apr 2007 20:15:06 +0200 Message-Id: <182C63BFBAF131428EA0C16F7FD2191B013584C2@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D46646E18@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Solution Approaches thread-index: AceA0IFqiJkGNc2wR5azqP4bVp3ysQANaSewACLh5SAADYG1MA== From: "Liess, Laura" To: , , X-OriginalArrivalTime: 18 Apr 2007 18:15:06.0647 (UTC) FILETIME=[7E19EA70:01C781E5] X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Richard, currently, our own SIP-proxy routes emergency calls comming from our = IP-access network to the old PSTN PSAPs. Currently we don't have or = plan neither LOST nor ESRP nor IP PSAPs. We just assume for Germany = national ESRP would be a solution all main players can live with.=20 Laura > -----Urspr=FCngliche Nachricht----- > Von: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Gesendet: Mittwoch, 18. April 2007 10:16 > An: Liess, Laura; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > Betreff: RE: [Ecrit] Solution Approaches >=20 >=20 > Laura, >=20 > In your proposal, you have one ESRP per country (or state)? >=20 > Or am I missing something? >=20 > Richard >=20 > > -----Original Message----- > > From: Liess, Laura [mailto:Laura.Liess@t-systems.com] > > Sent: Tuesday, April 17, 2007 5:37 PM > > To: Hannes.Tschofenig@gmx.net; ecrit@ietf.org > > Subject: AW: [Ecrit] Solution Approaches > >=20 > >=20 > > Hannes, > >=20 > > thanks a lot for putting the whole discussion together. > >=20 > > I can not give you a feedback which is agreed within DT > (the internal > > agreement process would probably take some time). But I roughly > > discussed the approaches with people working on emergency=20 > calling. If > > we understood the proposal correctly, we have a strong > preference for > > the approach number 8), which could work as follows: > >=20 > > The ASP/ISP provides to the client the LbyR, the country code (or > > country and state codes)and the local EC dial string (at login and=20 > > whenever these data change). The client queries LOST and=20 > gets back an > > ESRP URI. When the caller dials the emergency calling number, the > > client queries again the ASP/VSP for the LbyR and the=20 > country code and > > LOST query for the ESRP URI. The VSP routes the call to the > ESRP. The > > ESRP has a shared secret with the LIS, gets the user > location and the > > correct PSAP and routes the call with the location info to the PSAP > > (TLS required). (ESRP or a local LOST does load balancing=20 > for PSAPs an > > all this stuff). > >=20 > > Alternatively, the VSPs SIP proxy can do the LOST queries. > >=20 > >=20 > > Laura > >=20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Gesendet: Dienstag, 17. April 2007 11:12 > > > An: ECRIT > > > Betreff: [Ecrit] Solution Approaches > > > > > > > > > Hi all, > > > > > > I would like to share some potential solution approaches > with you to > > > deal with the problem of not providing precise location > to the end > > > host. I had a chance to discuss these aspects with Henning=20 > > > face-to-face last Friday. Here is a short summary. > > > > > > Note that the goal was to avoid some form of relationship (e.g., > > > business relationship) between the VSP and the ASP/ISP=20 > (since this > > > would impose a significant deployment problem). > > > > > > 1) Provide enough location information so that the emergency call > > > can be routed to the correct PSAP. Precise location information=20 > > > would be provided to the PSAP. > > > This approach was already discussed on the list. We need > > > feedback from, > > > for example, Barbara and Laura whether they feel comfortable > > > with this > > > approach. > > > > > > CONSEQUENCE: No changes needed. > > > > > > 2) Provide LbyR + Dial String + PSAP URI to the end host. > We could > > > ignore the potential security vulnerabilities if charging does not = > > > work on a call-by-call basis. > > > > > > CONSEQUENCE: No changes needed. > > > > > > 3) Provide LbyR + Dial String + PSAP URI to the end host. > VSP does a > > > reverse LoST lookup to verify the PSAP URI. > > > > > > CONSEQUENCE: Solution needs to be developed. > > > > > > 4) Provide LbyR + Dial String + PSAP URI to the end host. VSP > > > verifies the PSAP URI with the PSAP URIs being flooded (using the=20 > > > LoST synchronization mechanism). This mechanism is potentially > > > similar to (3) > > > -- details might vary. (3) might use a distributed approach > > > whereas this > > > is brute force. > > > > > > CONSEQUENCE: Solution needs to be developed. > > > > > > 5) Emergency calls are routed via the SIP proxy of the VSP and > > > subsequently via a SIP proxy in the ASP/ISP (redirect mode) SIP=20 > > > Location Conveyance would be used instead of GEOPRIV L7 LCP > > > Assumption: No service level agreement (or business > > > agreement) between > > > VSP and ISP/ASP for this type of SIP emergency message routing=20 > > > required. > > > > > > CONSEQUENCE: No changes needed. Potential problems with > SIP Identity > > > possible > > > > > > 6) Emergency calls are routed via the SIP proxy of the VSP and > > > subsequently via a SIP proxy in the ASP/ISP (no redirect > > > mode) SIP Location Conveyance would be used instead of GEOPRIV L7=20 > > > LCP > > > Assumption: No service level agreement (or business > > > agreement) between > > > VSP and ISP/ASP for this type of SIP emergency message > > > routing required. > > > > > > CONSEQUENCE: No changes needed. > > > > > > 7) Decoupled authentication for SIP message routing > Authentication > > > exchange between the end host and the VSP (e.g., TLS to obtain a=20 > > > SAML assertion) Authentication credentials are then added to the=20 > > > SIP emergency message > > > that is routed via the SIP proxy in the VSP/ISP. > > > No service level agreement (or business agreement) between VSP and > > > ISP/ASP needed. > > > > > > CONSEQUENCE: Security extension for this purpose needs to be > > > progressed (already available in draft form) > > > > > > 8) Country Code Routing > > > > > > LIS provides country code to the end host. The end host > routes the > > > SIP emergency message via the VSP towards a ESRP that > corresponds to > > > the country code. Then, ESRP fetches more detailed location=20 > > > information todo routing within the country. > > > > > > CONSEQUENCE: No changes to the protocol mechanisms. Deployment of > > > ESRPs that work this way are needed. Establishment of ESRP <-> > > > ISP/ASP is more > > > difficult than with PSAP <-> ISP/ASP since there are far more > > > nodes to > > > consider. > > > > > > 9) Assume end hosts have certs for emergency services; > routing via > > > SIP proxy in ISP/ASP without traversing VSP in the emergency case. = > > > Existing credential infrastructure can be used when utilizing SIP=20 > > > Cert. > > > > > > CONSEQUENCE: Architectural aspects need to be developed. A little > > > bit more difficult to deploy for VSP. Potential issues=20 > with callback > > > (to > > > AoR) since end host is not registered with VSP. > > > > > > 10) Routing via SIP proxy in ISP/ASP. Diameter SIP > application used > > > to authenticate end host > > > Assumption: No roaming agreement assumed for ISP/ASP <-> > VSP Diameter > > > SIP interaction. > > > > > > CONSEQUENCE: Problems with legacy credentials, previously > mentioned > > > call back problems since end host is not registered with VSP, > > > Diameter SIP application would need to be profiled. > > > > > > Thoughts? > > > > > > Ciao > > > Hannes > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit > > > > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 14:27:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeEsW-0002KN-O1; Wed, 18 Apr 2007 14:27:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeEsV-0002KI-Bo for ecrit@ietf.org; Wed, 18 Apr 2007 14:27:39 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeEsU-0006vI-48 for ecrit@ietf.org; Wed, 18 Apr 2007 14:27:39 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3IIRVa2004086 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Apr 2007 14:27:35 -0400 (EDT) In-Reply-To: <182C63BFBAF131428EA0C16F7FD2191B013584C2@S4DE8PSAAGM.mitte.t-com.de> References: <182C63BFBAF131428EA0C16F7FD2191B013584C2@S4DE8PSAAGM.mitte.t-com.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D8E9FB3-FCDA-47A3-8364-9CA436AFC4B7@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: AW: [Ecrit] Solution Approaches Date: Wed, 18 Apr 2007 14:28:46 -0400 To: "Liess, Laura" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Laura, it would be most helpful if DT could implement a pseudo-servers at least, i.e., an LCP that always returns the geo boundaries of Germany (or DE in civic) and, for its own customers at least, a LoST server that always returns the address of the ESRP and '1-1-2' as the service number. Other VSPs can obviously run their own LoST servers. That way, software and hardware not made in Germany can function normally, while imposing trivial cost on DT. Would that be something that you'd consider? Otherwise, we lose one of the core objectives of the whole ECRIT work, namely the ability to plug in a device and make an emergency call, without custom software development or manual configuration. (Given that policing is a state, rather than federal, function in Germany, I'm actually surprised that you'll find somebody to operate the ESRP, but maybe the Bundeskriminalamt or Innenministerium would do that?) Henning On Apr 18, 2007, at 2:15 PM, Liess, Laura wrote: > Richard, > > currently, our own SIP-proxy routes emergency calls comming from > our IP-access network to the old PSTN PSAPs. Currently we don't > have or plan neither LOST nor ESRP nor IP PSAPs. We just assume for > Germany national ESRP would be a solution all main players can live > with. > Laura _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 14:38:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeF2s-0003FQ-71; Wed, 18 Apr 2007 14:38:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeF2q-0003Dj-Rb; Wed, 18 Apr 2007 14:38:20 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeF2p-0000eL-Jb; Wed, 18 Apr 2007 14:38:20 -0400 Received: from ([139.76.131.79]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.175371833; Wed, 18 Apr 2007 14:37:48 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 18 Apr 2007 14:37:49 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 18 Apr 2007 14:37:49 -0400 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 MimeOLE V6.00.3790.2826 Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto doendpoint centric LCP without giving away the store Date: Wed, 18 Apr 2007 14:37:48 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA03B0F49E@crexc41p> In-Reply-To: <0f5c01c781e3$b004eaa0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto doendpoint centric LCP without giving away the store thread-index: AceB2jLjCmvef5D7QMe9NoQWMgzx9gAB4mHQAAGdzbA= References: <0f5c01c781e3$b004eaa0$640fa8c0@cis.neustar.com> From: "Stark, Barbara" To: "Brian Rosen" , "Henning Schulzrinne" X-OriginalArrivalTime: 18 Apr 2007 18:37:49.0301 (UTC) FILETIME=[AA4E6A50:01C781E8] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian said:=20 > And while you brought it up, I do think a very nice user part of a location reference is a hashed telephone number. Most of the DSL networks, for example, do have telephone numbers which actually are easy to turn into service address in the existing databases. I'd prefer it be hashed so that we don't reveal extra user information. I particularly think that idea will be quite useful in dealing with legacy wireline systems, which already associate TN with location. Adding a (hash of) TN with a provisioned LIS domain on a Geolocation header in, or near a PSTN to SIP gateway would be a very painless way to get location from a legacy wireline system into a next generation emergency call system. < Actually, given requirements for "naked" DSL, without an underlying POTS phone number, we're moving to "Circuit ID".=20 Barbara ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA621 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 14:49:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeFDD-00046h-GL; Wed, 18 Apr 2007 14:49:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeFDC-00046T-29; Wed, 18 Apr 2007 14:49:02 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeFDB-0003fa-Pj; Wed, 18 Apr 2007 14:49:02 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HeFCx-0000S6-0k; Wed, 18 Apr 2007 13:48:47 -0500 From: "Brian Rosen" To: "'Stark, Barbara'" , "'Henning Schulzrinne'" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto doendpoint centric LCP without giving away the store Date: Wed, 18 Apr 2007 14:48:57 -0400 Message-ID: <0f6801c781ea$3a812120$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceB2jLjCmvef5D7QMe9NoQWMgzx9gAB4mHQAAGdzbAAAFz5UA== In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA03B0F49E@crexc41p> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'GEOPRIV' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org That's fine, hash the circuit ID and make that the user part of the location reference. Of course, this is NOT a requirement; it's just one way to make the implementation simpler. It's totally within the access provider's domain, and only it cares what the URI looks like, thus it's not subject to standardization except insofar as it might optimize intra-carrier system purchases (e.g. if there was an agreement on how to do it, the OSS guys and the LIS guys may be able to make their sub-systems interoperate). Brian > -----Original Message----- > From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > Sent: Wednesday, April 18, 2007 2:38 PM > To: Brian Rosen; Henning Schulzrinne > Cc: GEOPRIV; ECRIT > Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto > doendpoint centric LCP without giving away the store > > Brian said: > > And while you brought it up, I do think a very nice user part of a > location reference is a hashed telephone number. Most of the DSL > networks, for example, do have telephone numbers which actually are easy > to turn into service address in the existing databases. I'd prefer it > be hashed so that we don't reveal extra user information. I > particularly think that idea will be quite useful in dealing with legacy > wireline systems, which already associate TN with location. Adding a > (hash of) TN with a provisioned LIS domain on a Geolocation header in, > or near a PSTN to SIP gateway would be a very painless way to get > location from a legacy wireline system into a next generation emergency > call system. < > > Actually, given requirements for "naked" DSL, without an underlying POTS > phone number, we're moving to "Circuit ID". > Barbara > > ***** > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential, proprietary, and/or > privileged material. Any review, retransmission, dissemination or other > use of, or taking of any action in reliance upon this information by > persons or entities other than the intended recipient is prohibited. If > you received this in error, please contact the sender and delete the > material from all computers. GA621 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 15:00:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeFNo-0005aF-EI; Wed, 18 Apr 2007 15:00:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeFNm-0005a7-Uv; Wed, 18 Apr 2007 14:59:58 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeFNl-00089A-NA; Wed, 18 Apr 2007 14:59:58 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3IIxqjF008349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 18 Apr 2007 14:59:56 -0400 (EDT) In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA03B0F49E@crexc41p> References: <0f5c01c781e3$b004eaa0$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA03B0F49E@crexc41p> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <66DDF0E9-8C5D-4107-BB6D-40A1A50634CA@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Wed, 18 Apr 2007 15:01:07 -0400 To: "Stark, Barbara" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: GEOPRIV , ECRIT Subject: [Ecrit] Circuit ID X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > Just out of curiosity, what does a circuit ID look like? Is that the NAS identifier used in RADIUS or where is it visible? > Actually, given requirements for "naked" DSL, without an underlying > POTS > phone number, we're moving to "Circuit ID". > Barbara _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 15:09:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeFX5-0001wG-SA; Wed, 18 Apr 2007 15:09:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeFX4-0001wA-Nj for ecrit@ietf.org; Wed, 18 Apr 2007 15:09:34 -0400 Received: from mail.skype.net ([193.88.6.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeFX4-0001pt-3O for ecrit@ietf.org; Wed, 18 Apr 2007 15:09:34 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id BBB211100EA for ; Wed, 18 Apr 2007 21:08:54 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfXt0j7O+5-y for ; Wed, 18 Apr 2007 21:08:54 +0200 (CEST) Received: from [10.254.233.35] (unknown [216.113.168.141]) by mail.skype.net (Postfix) with ESMTP id 3E0851100BD for ; Wed, 18 Apr 2007 21:08:52 +0200 (CEST) User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 18 Apr 2007 11:08:15 -0700 From: Andres K=?ISO-8859-1?B?/A==?=tt To: Message-ID: Thread-Topic: Ecrit Digest, Vol 27, Issue 30 Thread-Index: AceB5Ii9x1lyr+3XEdu/GQAX8i4icA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [Ecrit] Re: Ecrit Digest, Vol 27, Issue 30 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi, As I understand it, all of the methods have shortcomings and in an ideal world, it would probably make sense to use different models in different scenario. Here come my comments: > 1) Provide enough location information so that the emergency call can be > routed to the correct PSAP. Precise location information would be > provided to the PSAP. > This approach was already discussed on the list. We need feedback from, > for example, Barbara and Laura whether they feel comfortable with this > approach. > > CONSEQUENCE: No changes needed. This implies that the access provider knows how much information is needed to determine the PSAP which in turn implies that the it also knows about PSAP topology. Can we make that assumption? > 2) Provide LbyR + Dial String + PSAP URI to the end host. > We could ignore the potential security vulnerabilities if charging does > not work on a call-by-call basis. > > CONSEQUENCE: No changes needed. We can't make that assumption, I think. The solution has to be invariant towards whatever charging scheme the VSP uses. > 3) Provide LbyR + Dial String + PSAP URI to the end host. VSP does a > reverse LoST lookup to verify the PSAP URI. > > CONSEQUENCE: Solution needs to be developed. Seems fine as long we can ensure the integrity of the LoST query. > 4) Provide LbyR + Dial String + PSAP URI to the end host. VSP verifies > the PSAP URI with the PSAP URIs being flooded (using the LoST > synchronization mechanism). This mechanism is potentially similar to (3) > -- details might vary. (3) might use a distributed approach whereas this > is brute force. > > CONSEQUENCE: Solution needs to be developed. Does not seem very architecturally consistent, but might work. > 5) Emergency calls are routed via the SIP proxy of the VSP and > subsequently via a SIP proxy in the ASP/ISP (redirect mode) > SIP Location Conveyance would be used instead of GEOPRIV L7 LCP > Assumption: No service level agreement (or business agreement) between > VSP and ISP/ASP for this type of SIP emergency message routing required. > > > CONSEQUENCE: No changes needed. Potential problems with SIP Identity > possible This does not work with devices that do not use SIP on the client side. Like yours truly. > 6) Emergency calls are routed via the SIP proxy of the VSP and > subsequently via a SIP proxy in the ASP/ISP (no redirect mode) > SIP Location Conveyance would be used instead of GEOPRIV L7 LCP > Assumption: No service level agreement (or business agreement) between > VSP and ISP/ASP for this type of SIP emergency message routing required. > > CONSEQUENCE: No changes needed. Same as above. > 7) Decoupled authentication for SIP message routing > Authentication exchange between the end host and the VSP (e.g., TLS to > obtain a SAML assertion) > Authentication credentials are then added to the SIP emergency message > that is routed via the SIP proxy in the VSP/ISP. > No service level agreement (or business agreement) between VSP and > ISP/ASP needed. > > CONSEQUENCE: Security extension for this purpose needs to be progressed > (already available in draft form) Do not understand this. The calling infrastructure needs to be authenticated from end to end anyway if any sort of billing is to happen? > 8) Country Code Routing > > LIS provides country code to the end host. The end host routes the SIP > emergency message via the VSP towards a ESRP that corresponds to the > country code. Then, ESRP fetches more detailed location information todo > routing within the country. > > CONSEQUENCE: No changes to the protocol mechanisms. Deployment of ESRPs > that work this way are needed. Establishment of ESRP <-> ISP/ASP is more > difficult than with PSAP <-> ISP/ASP since there are far more nodes to > consider. How would the ESRP be able to determine the location of the caller? > 9) Assume end hosts have certs for emergency services; routing via SIP > proxy in ISP/ASP without traversing VSP in the emergency case. > Existing credential infrastructure can be used when utilizing SIP Cert. > > CONSEQUENCE: Architectural aspects need to be developed. A little bit > more difficult to deploy for VSP. Potential issues with callback (to > AoR) since end host is not registered with VSP. Would not work for devices not using SIP + several issues with certs and things. Bear in mind that a lot of SIP devices out there can not be updated easily so anything if an authentication method is compromised, for example. > 10) Routing via SIP proxy in ISP/ASP. Diameter SIP application used to > authenticate end host > Assumption: No roaming agreement assumed for ISP/ASP <-> VSP Diameter > SIP interaction. > > CONSEQUENCE: Problems with legacy credentials, previously mentioned call > back problems since end host is not registered with VSP, Diameter SIP > application would need to be profiled. Could you explain that in a little bit more detail? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 17:10:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHPd-00011B-8Q; Wed, 18 Apr 2007 17:10:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeHPO-0000jU-Nt for ecrit@ietf.org; Wed, 18 Apr 2007 17:09:46 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeHLd-0002Ju-L8 for ecrit@ietf.org; Wed, 18 Apr 2007 17:05:54 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 18 Apr 2007 23:05:52 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Apr 2007 23:05:52 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: AW: [Ecrit] Solution Approaches Date: Wed, 18 Apr 2007 23:05:51 +0200 Message-Id: <182C63BFBAF131428EA0C16F7FD2191B013584C4@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <3D8E9FB3-FCDA-47A3-8364-9CA436AFC4B7@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Ecrit] Solution Approaches thread-index: AceB50PKg+bdL+BAQdKtwRotEc3K4AACTuwA From: "Liess, Laura" To: X-OriginalArrivalTime: 18 Apr 2007 21:05:52.0663 (UTC) FILETIME=[5933E270:01C781FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning, > Laura, >=20 > it would be most helpful if DT could implement a pseudo-servers at =20 > least, i.e., an LCP that always returns the geo boundaries of=20 > Germany =20 > (or DE in civic) and, for its own customers at least, a LoST server =20 > that always returns the address of the ESRP and '1-1-2' as the =20 > service number. Other VSPs can obviously run their own LoST servers. >=20 > That way, software and hardware not made in Germany can function =20 > normally, while imposing trivial cost on DT. Would that be something =20 > that you'd consider? Speaking for myself, I would realy like very much to see this happen.=20 I can not make any promise for DT. But I could imagine them providing this service as a free add-on to DT access customers. DT providing ESRP services for people using Skype and other ASP/ISP's access could be subject of discussions with the Bundesnetzagentur. =20 For my feeling, in Germany we will need ESRPs, national or not and an operator for them. The today's PSTN PSAPs have phone numbers which can not be dialed by end users (contains hexadecimal digits). This was a requirement of the PSAPs operators, that calls can be routing to them only by the network. I can imagine them not wanting any untrusted SIP proxy routing calls to them.=20 I think, sending the country code and the LbyR to the VSP and providing LOST and ESRP services is a solution DT could in principle live with, sending the city to the VSP is not. When the Ecrit direction is more clear, I can try to convince people to begin talking to the Bundesnetzagentur about LOST and ESRP and who operates which servers.=20 Laura =20 >=20 > Otherwise, we lose one of the core objectives of the whole ECRIT =20 > work, namely the ability to plug in a device and domake an emergency =20 > call, without custom software development or manual configuration. >=20 > (Given that policing is a state, rather than federal, function in =20 > Germany, I'm actually surprised that you'll find somebody to operate =20 > the ESRP, but maybe the Bundeskriminalamt or Innenministerium would =20 > do that?) >=20 > Henning >=20 > On Apr 18, 2007, at 2:15 PM, Liess, Laura wrote: >=20 > > Richard, > > > > currently, our own SIP-proxy routes emergency calls comming from > > our IP-access network to the old PSTN PSAPs. Currently we don't =20 > > have or plan neither LOST nor ESRP nor IP PSAPs. We just=20 > assume for =20 > > Germany national ESRP would be a solution all main players=20 > can live =20 > > with. > > Laura >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 17:55:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeI7y-0003rF-Rp; Wed, 18 Apr 2007 17:55:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeI7y-0003rA-5e for ecrit@ietf.org; Wed, 18 Apr 2007 17:55:50 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeI7v-0002wm-BX for ecrit@ietf.org; Wed, 18 Apr 2007 17:55:50 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HeI7d-0002Hq-OR; Wed, 18 Apr 2007 16:55:30 -0500 From: "Brian Rosen" To: "'Liess, Laura'" , Subject: RE: AW: [Ecrit] Solution Approaches Date: Wed, 18 Apr 2007 17:55:42 -0400 Message-ID: <105401c78204$51a89030$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceB50PKg+bdL+BAQdKtwRotEc3K4AACTuwAAAS/SyA= In-Reply-To: <182C63BFBAF131428EA0C16F7FD2191B013584C4@S4DE8PSAAGM.mitte.t-com.de> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning recently made a proposal I agreed with involving an LbyR that when queried by anyone other than a PSAP or ESRP returns a coarse location suitable to locate an ESRP OR returns a polygon covering the ESRP/PSAP service area, which is another way to get the same result. Do you think that would be acceptable? As Henning points out, that solves the location hiding and VSP "PSAP URI" validation problems with no changes to LCPs or LoST or -conveyance. Brian > -----Original Message----- > From: Liess, Laura [mailto:Laura.Liess@t-systems.com] > Sent: Wednesday, April 18, 2007 5:06 PM > To: hgs@cs.columbia.edu > Cc: ecrit@ietf.org > Subject: AW: AW: [Ecrit] Solution Approaches > > Henning, > > > > Laura, > > > > it would be most helpful if DT could implement a pseudo-servers at > > least, i.e., an LCP that always returns the geo boundaries of > > Germany > > (or DE in civic) and, for its own customers at least, a LoST server > > that always returns the address of the ESRP and '1-1-2' as the > > service number. Other VSPs can obviously run their own LoST servers. > > > > That way, software and hardware not made in Germany can function > > normally, while imposing trivial cost on DT. Would that be something > > that you'd consider? > > Speaking for myself, I would realy like very much to see this happen. > > I can not make any promise for DT. But I could imagine them providing > this service as a free add-on to DT access customers. DT providing ESRP > services for people using Skype and other ASP/ISP's access could be > subject of discussions with the Bundesnetzagentur. > > For my feeling, in Germany we will need ESRPs, national or not and an > operator for them. The today's PSTN PSAPs have phone numbers which can > not be dialed by end users (contains hexadecimal digits). This was a > requirement of the PSAPs operators, that calls can be routing to them > only by the network. I can imagine them not wanting any untrusted SIP > proxy routing calls to them. > > I think, sending the country code and the LbyR to the VSP and providing > LOST and ESRP services is a solution DT could in principle live with, > sending the city to the VSP is not. When the Ecrit direction is more > clear, I can try to convince people to begin talking to the > Bundesnetzagentur about LOST and ESRP and who operates which servers. > > Laura > > > > > Otherwise, we lose one of the core objectives of the whole ECRIT > > work, namely the ability to plug in a device and domake an emergency > > call, without custom software development or manual configuration. > > > > > > > > > (Given that policing is a state, rather than federal, function in > > Germany, I'm actually surprised that you'll find somebody to operate > > the ESRP, but maybe the Bundeskriminalamt or Innenministerium would > > do that?) > > > > Henning > > > > On Apr 18, 2007, at 2:15 PM, Liess, Laura wrote: > > > > > Richard, > > > > > > currently, our own SIP-proxy routes emergency calls comming from > > > our IP-access network to the old PSTN PSAPs. Currently we don't > > > have or plan neither LOST nor ESRP nor IP PSAPs. We just > > assume for > > > Germany national ESRP would be a solution all main players > > can live > > > with. > > > Laura > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 18 18:05:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeIH7-0003u6-2q; Wed, 18 Apr 2007 18:05:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeIH5-0003u1-S5 for ecrit@ietf.org; Wed, 18 Apr 2007 18:05:15 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeIH5-0007EC-CE for ecrit@ietf.org; Wed, 18 Apr 2007 18:05:15 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 19 Apr 2007 00:05:14 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 00:05:14 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: AW: [Ecrit] Solution Approaches Date: Thu, 19 Apr 2007 00:05:13 +0200 Message-Id: <182C63BFBAF131428EA0C16F7FD2191B013584C6@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <105401c78204$51a89030$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Ecrit] Solution Approaches thread-index: AceB50PKg+bdL+BAQdKtwRotEc3K4AACTuwAAAS/SyAAAFQW8A== From: "Liess, Laura" To: , X-OriginalArrivalTime: 18 Apr 2007 22:05:14.0054 (UTC) FILETIME=[A3F50660:01C78205] X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, I think we are OK with it. And I really like it.=20 Laura=20 > Henning recently made a proposal I agreed with involving an=20 > LbyR that when queried by anyone other than a PSAP or ESRP=20 > returns a coarse location suitable to locate an ESRP OR=20 > returns a polygon covering the ESRP/PSAP service area, which=20 > is another way to get the same result. Do you think that=20 > would be acceptable? >=20 > As Henning points out, that solves the location hiding and=20 > VSP "PSAP URI" validation problems with no changes to LCPs or=20 > LoST or -conveyance. >=20 > Brian >=20 > > -----Original Message----- > > From: Liess, Laura [mailto:Laura.Liess@t-systems.com] > > Sent: Wednesday, April 18, 2007 5:06 PM > > To: hgs@cs.columbia.edu > > Cc: ecrit@ietf.org > > Subject: AW: AW: [Ecrit] Solution Approaches > >=20 > > Henning, > >=20 > >=20 > > > Laura, > > > > > > it would be most helpful if DT could implement a=20 > pseudo-servers at=20 > > > least, i.e., an LCP that always returns the geo boundaries of=20 > > > Germany (or DE in civic) and, for its own customers at=20 > least, a LoST=20 > > > server that always returns the address of the ESRP and '1-1-2' as=20 > > > the service number. Other VSPs can obviously run their own LoST=20 > > > servers. > > > > > > That way, software and hardware not made in Germany can function=20 > > > normally, while imposing trivial cost on DT. Would that=20 > be something=20 > > > that you'd consider? > >=20 > > Speaking for myself, I would realy like very much to see=20 > this happen. > >=20 > > I can not make any promise for DT. But I could imagine them=20 > providing=20 > > this service as a free add-on to DT access customers. DT providing=20 > > ESRP services for people using Skype and other ASP/ISP's=20 > access could=20 > > be subject of discussions with the Bundesnetzagentur. > >=20 > > For my feeling, in Germany we will need ESRPs, national or=20 > not and an=20 > > operator for them. The today's PSTN PSAPs have phone=20 > numbers which can=20 > > not be dialed by end users (contains hexadecimal digits).=20 > This was a=20 > > requirement of the PSAPs operators, that calls can be=20 > routing to them=20 > > only by the network. I can imagine them not wanting any=20 > untrusted SIP=20 > > proxy routing calls to them. > >=20 > > I think, sending the country code and the LbyR to the VSP and=20 > > providing LOST and ESRP services is a solution DT could in=20 > principle=20 > > live with, sending the city to the VSP is not. When the Ecrit=20 > > direction is more clear, I can try to convince people to=20 > begin talking=20 > > to the Bundesnetzagentur about LOST and ESRP and who operates which=20 > > servers. > >=20 > > Laura > >=20 > > > > > > Otherwise, we lose one of the core objectives of the whole ECRIT=20 > > > work, namely the ability to plug in a device and domake=20 > an emergency=20 > > > call, without custom software development or manual configuration. > >=20 > >=20 > >=20 > >=20 > >=20 > > > > > > (Given that policing is a state, rather than federal, function in=20 > > > Germany, I'm actually surprised that you'll find somebody=20 > to operate=20 > > > the ESRP, but maybe the Bundeskriminalamt or=20 > Innenministerium would=20 > > > do that?) > > > > > > Henning > > > > > > On Apr 18, 2007, at 2:15 PM, Liess, Laura wrote: > > > > > > > Richard, > > > > > > > > currently, our own SIP-proxy routes emergency calls=20 > comming from=20 > > > > our IP-access network to the old PSTN PSAPs. Currently=20 > we don't=20 > > > > have or plan neither LOST nor ESRP nor IP PSAPs. We just > > > assume for > > > > Germany national ESRP would be a solution all main players > > > can live > > > > with. > > > > Laura > > > > > > > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 14:24:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HebJ9-0002x2-4E; Thu, 19 Apr 2007 14:24:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HebJ7-0002wp-VK; Thu, 19 Apr 2007 14:24:37 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HebJ7-0000A4-B0; Thu, 19 Apr 2007 14:24:37 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HebId-0001Dd-7E; Thu, 19 Apr 2007 13:24:07 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Henning Schulzrinne'" Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto doendpoint centric LCP without giving away the store Date: Thu, 19 Apr 2007 14:24:32 -0400 Message-ID: <122301c782af$fc0ee230$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceB2jLjCmvef5D7QMe9NoQWMgzx9gAB4mHQACKi+WAAEArp8A== In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: 'GEOPRIV' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Okay, well, discussion has died down now, so I'd like to see if we have consensus on how we allow access networks to hide location from endpoints (and VSPs) and yet result in correct emergency call routing. The proposal requires no changes to existing documents (other than explanations in -framework and -phonebcp). It requires no changes in endpoint, VSP, ESRP or PSAP behavior. It is confined to LIS behavior for LIS' that wish to hide location. It works as follows: 1. The endpoint uses an LCP to request location. The LIS returns an LbyR 2. The endpoint dereferences the LbyR. 3. The LIS, noticing that the dereference request is from the endpoint (or at least not from any entity that is entitled to get fine grained location), takes the fine grained location and uses LoST to determine the PSAP that serves that location. 4. The LIS returns to the endpoint a location which, if submitted to LoST, would return the same PSAP URI the fine grained location would. In some circumstances, this could be a civic with only a country. An alternative that works for all circumstances is to return the polygon that defines the service boundary of the PSAP (which LoST can return). Is essential that the PSAP URI returned from a LoST query with whatever the LIS gives the endpoint would be the same PSAP URI any querier using the fine grained location would get. 5. The endpoint uses the (coarse) location value it obtains to query LoST. It gets the (correct) PSAP URI 6. This is repeated at call time. The endpoint has a valid LbyR and a valid PSAP URI, which it uses to construct the emergency call 7. A VSP wishing to validate the PSAP URI takes the LbyR and dereferences it. The result will be the same (coarse) location the endpoint got. The VSP does a LoST query with that location, and should get the same PSAP URI that is in the Request URI on the call. This validation works for coarse or fine validation, and of course works for LbyV without the dereference step. 8. The PSAP (or ESRP) which is the target of the PSAP URI gets the call. It dereferences the LbyR but gets the fine grained location; the LIS must have a relationship with the ESRP/PSAP to assure this. 9. Any succeeding ESRPs or PSAPs can also dereference and get fine grained location. Some observations: a) The LIS probably ought to query LoST with its calculated coarse location to assure that it gets the same PSAP URI as the fine grained location. b) The coarse LoST lookups can be cached. For a given LIS, there is likely only a few of them c) The VSP can cache validated PSAP URIs and avoid LoST lookups in most cases d) The endpoint could send both the coarse location by value and the reference, but this would really only help the VSP because the ESRP/PSAP is going to want to dereference to get the fine grained location. e) The LIS can identify ESRPs and PSAPs in a number of ways. It could use IP address filtering, VPNs, IPSEC tunnels or other address restrictive mechanisms. It could use TLS credentials of any form it finds acceptable. It is essential that the mechanism work for any valid PSAP that could get the call, and any ESRP that could handle the call, even when there are failures. Now, do we have any objections to making this the answer to the problem posed? To be clear, I'm asking if you can live with it, not if you would prefer another one of the proposals that have been made. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Thursday, April 19, 2007 6:25 AM > To: Brian Rosen; Henning Schulzrinne > Cc: GEOPRIV; ECRIT > Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto > doendpoint centric LCP without giving away the store > > Well... I just posted on an alternative thread - about preferring the > location request be made at the time of the call - where Henning seems > to be taking the position that this is a dangerous additional > transaction requirement. Yet, here we appear to be suggesting that a > location dereference be made to determine coarse routing... > > I don't actually object to the additional transaction (per my previous > thread) though I will note that the VSP is inherently "further" from the > LIS than the device is. It just seems cleaner to me if the VSP has no > requirement to interact with the LIS and that, in the case of emergency > calls, all LIS interactions occur locally - either from the device or > jurisdictional entities such as the LoST server, VPC, and/or PSAPs. This > also obviates the need for the LIS to distinguish between "allowed" > versus "non-allowed" granularity. > > Cheers, > Martin > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, 19 April 2007 4:02 AM > To: 'Henning Schulzrinne' > Cc: 'GEOPRIV'; 'ECRIT' > Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto > doendpoint centric LCP without giving away the store > > I can live with this way out of the mess. > > I rather like the idea of returning the PSAP service boundary polygon on > the > endpoint's (or VSP's) dereference. The latter (as well as coarse > location > when it works) also fixes the validation problem; the VSP dereferences, > gets > the polygon, queries LoST with it, and gets the PSAP URI. > > I agree that in lots of cases, a very coarse location return from the > LbyR > is sufficient, and access networks ought to be able to take advantage of > it > when it happens. > > I guess we need to hear from carriers. I think you already raised the > point > that in most cases, an IP address yields city level location, albeit > VPNs > often obscure that. > > And while you brought it up, I do think a very nice user part of a > location > reference is a hashed telephone number. Most of the DSL networks, for > example, do have telephone numbers which actually are easy to turn into > service address in the existing databases. I'd prefer it be hashed so > that > we don't reveal extra user information. I particularly think that idea > will > be quite useful in dealing with legacy wireline systems, which already > associate TN with location. Adding a (hash of) TN with a provisioned > LIS > domain on a Geolocation header in, or near a PSTN to SIP gateway would > be a > very painless way to get location from a legacy wireline system into a > next > generation emergency call system. > > Brian > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Wednesday, April 18, 2007 12:56 PM > > To: Brian Rosen > > Cc: 'Hannes Tschofenig'; 'GEOPRIV'; 'ECRIT' > > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to > > doendpoint centric LCP without giving away the store > > > > > > On Apr 18, 2007, at 11:33 AM, Brian Rosen wrote: > > > > > I'm not sure I understand what you are saying. > > > > > > I'll agree that coarse location may work some times. I wouldn't > > > care to > > > speculate how often it does or doesn't. I don't think it matters. > It > > > > This seems to be very country-specific. Thus, in some countries, this > > will be quite viable, in others, less so. > > > > For DT, for example, you could have a very simple architecture: > > > > - Use normal LCP, returning Gemeinde (city/town), Bundesstaat > > (state) and country (DE). This is sufficient for determining the PSAP > > and requires zero interaction with the OSS. > > > > - Return an LbyR that is similar to what is used today as an > > identifier (phone number?), which resolves to the rough information > > above. > > > > > > > doesn't sometimes. Does that mean we should misroute in those > > > cases where > > > you only get coarse location, and you have an irregular boundary > that > > > "misses"? I suspect that would not fly with the access networks > > > that have > > > > Definitely not. It would be the responsibility of the ISP to deliver > > location information of sufficient granularity to prevent misroutes. > > In some small number of corner cases (typically, the one boundary > > street between PSAP regions), this would mean delivering a street > > address or a geo region. This is easy for the ISP to determine - they > > just query LoST and get the coverage regions. > > > > If you don't want to do this, just return the *geo* boundary of the > > PSAP to the customer as location information via LCP, just like you'd > > return an imprecise mapping from a wireless system, as a polygon. By > > our mapping rules, LoST computes the centroid (trivial) and returns > > the PSAP URL. I think this is somewhat similar to what Andy is > > proposing, but requires no new effort. > > > > This reveals zero additional information to the client, beyond the > > coverage region of the PSAP, but the UA behavior is exactly the same > > as in the no-hiding case. > > > > > > > the hiding problem. You are giving them an unacceptable choice: > > > give up > > > accurate location to the endpoint or be responsible for misroute. > > > That may > > > meet your notion of endpoint simplicity, but it won't be deployed I > > > think. > > > > I don't see this as the alternative. All I require is that ISP give > > up a tiny fraction of its location information in some corner cases. > > In most communities, all of the customers will only get city-level or > > county-level information, which corresponds to what their phone > > number already tells them. > > > > I think this is a fair bargain. I'd like to hear good reasons from > > real carriers as to why this is not acceptable. Shadow boxing, > > without talking to real customers, seems likely to lead us to design > > something that doesn't actually help. (Just as I believe that the > > whole architecture proposed doesn't actually address the don't-spend- > > money objective of DT.) > > > > > > > > > > You also seem to be willing to accept that the client will have two > > > locations to deal with: coarse LbyV and fine LbyR. Not a > > > complication I > > > would want to have to deal with given my alternative. > > > > Not really. I advocate returning a single LbyR, which resolves to > > minimal information sufficient for routing for the general public > > and, with PSAP authentication, to precise location information for > > dispatch. > > > > Henning > > > > > > > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 15:08:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hebyl-0007pJ-BQ; Thu, 19 Apr 2007 15:07:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hebyk-0007pE-By for ecrit@ietf.org; Thu, 19 Apr 2007 15:07:38 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hebyi-0001JG-ND for ecrit@ietf.org; Thu, 19 Apr 2007 15:07:38 -0400 Received: (qmail invoked by alias); 19 Apr 2007 19:07:34 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp055) with SMTP; 19 Apr 2007 21:07:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+8aRBRzR68MY2DEWtGsD4i6CvhZQ5q8Yu/ZDM3UV iKG2yPNp1Yry6L Message-ID: <4627BDF5.9050605@gmx.net> Date: Thu, 19 Apr 2007 21:07:33 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Andres_K=FCtt?= Subject: Re: [Ecrit] Re: Ecrit Digest, Vol 27, Issue 30 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Andreas, Andres Kütt wrote: > Hi, > > As I understand it, all of the methods have shortcomings and in an ideal > world, it would probably make sense to use different models in different > scenario. Here come my comments: > > > >> 1) Provide enough location information so that the emergency call can be >> routed to the correct PSAP. Precise location information would be >> provided to the PSAP. >> This approach was already discussed on the list. We need feedback from, >> for example, Barbara and Laura whether they feel comfortable with this >> approach. >> >> CONSEQUENCE: No changes needed. >> > This implies that the access provider knows how much information is needed > to determine the PSAP which in turn implies that the it also knows about > PSAP topology. Can we make that assumption? > > Yes; I believe we can make this assumption. >> 2) Provide LbyR + Dial String + PSAP URI to the end host. >> We could ignore the potential security vulnerabilities if charging does >> not work on a call-by-call basis. >> >> CONSEQUENCE: No changes needed. >> > We can't make that assumption, I think. The solution has to be invariant > towards whatever charging scheme the VSP uses. > > I wanted to list it for completeness reasons. I also don't believe that it is a reasonable design to just ignore security vulnerabilities. >> 3) Provide LbyR + Dial String + PSAP URI to the end host. VSP does a >> reverse LoST lookup to verify the PSAP URI. >> >> CONSEQUENCE: Solution needs to be developed. >> > Seems fine as long we can ensure the integrity of the LoST query. > > >> 4) Provide LbyR + Dial String + PSAP URI to the end host. VSP verifies >> the PSAP URI with the PSAP URIs being flooded (using the LoST >> synchronization mechanism). This mechanism is potentially similar to (3) >> -- details might vary. (3) might use a distributed approach whereas this >> is brute force. >> >> CONSEQUENCE: Solution needs to be developed. >> > Does not seem very architecturally consistent, but might work. > > This solution will probably not win a beauty contest. >> 5) Emergency calls are routed via the SIP proxy of the VSP and >> subsequently via a SIP proxy in the ASP/ISP (redirect mode) >> SIP Location Conveyance would be used instead of GEOPRIV L7 LCP >> Assumption: No service level agreement (or business agreement) between >> VSP and ISP/ASP for this type of SIP emergency message routing required. >> >> >> CONSEQUENCE: No changes needed. Potential problems with SIP Identity >> possible >> > This does not work with devices that do not use SIP on the client side. Like > yours truly. > > That's true. I should have added this part. The challenge is that for unauthenticated network access you need to implement one protocol anyway, very likely SIP, since otherwise you introduce EXTREMELY HUGE security vulnerabilities. >> 6) Emergency calls are routed via the SIP proxy of the VSP and >> subsequently via a SIP proxy in the ASP/ISP (no redirect mode) >> SIP Location Conveyance would be used instead of GEOPRIV L7 LCP >> Assumption: No service level agreement (or business agreement) between >> VSP and ISP/ASP for this type of SIP emergency message routing required. >> >> CONSEQUENCE: No changes needed. >> > Same as above. > > >> 7) Decoupled authentication for SIP message routing >> Authentication exchange between the end host and the VSP (e.g., TLS to >> obtain a SAML assertion) >> Authentication credentials are then added to the SIP emergency message >> that is routed via the SIP proxy in the VSP/ISP. >> No service level agreement (or business agreement) between VSP and >> ISP/ASP needed. >> >> CONSEQUENCE: Security extension for this purpose needs to be progressed >> (already available in draft form) >> > Do not understand this. The calling infrastructure needs to be authenticated > >from end to end anyway if any sort of billing is to happen? > > The end host / user is authenticated with a mechanism independent of SIP and then the receipt of that authentication action is added to the emergency call for consumption at the PSAP (to provide him some identity information). >> 8) Country Code Routing >> >> LIS provides country code to the end host. The end host routes the SIP >> emergency message via the VSP towards a ESRP that corresponds to the >> country code. Then, ESRP fetches more detailed location information todo >> routing within the country. >> >> CONSEQUENCE: No changes to the protocol mechanisms. Deployment of ESRPs >> that work this way are needed. Establishment of ESRP <-> ISP/ASP is more >> difficult than with PSAP <-> ISP/ASP since there are far more nodes to >> consider. >> > How would the ESRP be able to determine the location of the caller? > > It needs to resolve the reference the LIS in the access network sent to the end host and that is then subsequently forwarded to the ESRP. This reference is dereferenced at the LIS >> 9) Assume end hosts have certs for emergency services; routing via SIP >> proxy in ISP/ASP without traversing VSP in the emergency case. >> Existing credential infrastructure can be used when utilizing SIP Cert. >> >> CONSEQUENCE: Architectural aspects need to be developed. A little bit >> more difficult to deploy for VSP. Potential issues with callback (to >> AoR) since end host is not registered with VSP. >> > Would not work for devices not using SIP + several issues with certs and > things. Bear in mind that a lot of SIP devices out there can not be updated > easily so anything if an authentication method is compromised, for example. > > Note that there aren't problems with CERTs as such. The main issue is mostly with the PKI that comes with most certificates. If you utilize something like SIP Certs then things are different since you can use your existing credential infrastructure and you use certificates just as a technical vehicle. Here is the draft: http://www.ietf.org/internet-drafts/draft-ietf-sip-certs-03.txt > >> 10) Routing via SIP proxy in ISP/ASP. Diameter SIP application used to >> authenticate end host >> Assumption: No roaming agreement assumed for ISP/ASP <-> VSP Diameter >> SIP interaction. >> >> CONSEQUENCE: Problems with legacy credentials, previously mentioned call >> back problems since end host is not registered with VSP, Diameter SIP >> application would need to be profiled. >> > Could you explain that in a little bit more detail? > > > This document gives you the details: http://www.rfc-editor.org/rfc/rfc4740.txt Here is the relevant picture: +--------+ UAR/UAA +--->|Diameter| LIR/LIA | | server | | +--------+ | | v +------+ SIP +--------+ SIP +--------+ SIP +------+ | SIP |<--------->| SIP |<-------->| ESRP |<--------->| PSAP | | UA | |server 1| | | | | +------+ +--------+ +--------+ +------+ SIP Server in access network Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 15:10:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hec1l-0000T2-Uj; Thu, 19 Apr 2007 15:10:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hec1l-0000Qk-Hb for ecrit@ietf.org; Thu, 19 Apr 2007 15:10:45 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hec1l-00022Y-2p for ecrit@ietf.org; Thu, 19 Apr 2007 15:10:45 -0400 Received: (qmail invoked by alias); 19 Apr 2007 19:10:44 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp010) with SMTP; 19 Apr 2007 21:10:44 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18OJ/NjIy0Oj3gd7hTMPdfogTXXw11ao0afST/Hoq nBeaqtj/OS64sz Message-ID: <4627BEB2.1030009@gmx.net> Date: Thu, 19 Apr 2007 21:10:42 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Subscription Concept for Hiding (partial) locations References: <46261D61.6080005@gmx.net> <67E3053F-FA62-4A76-A7AD-9D92D9CF1D8B@cs.columbia.edu> In-Reply-To: <67E3053F-FA62-4A76-A7AD-9D92D9CF1D8B@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Henning, I know that this is not ideal either. Yes; I had the LocationRef mechanism in mind. Ciao Hannes Henning Schulzrinne wrote: > > On Apr 18, 2007, at 9:30 AM, Hannes Tschofenig wrote: > >> Hi all >> >> would folks be happy with the following exchange: >> >> UA <-> DHCP: URI to LIS > > DHCP or SIP configuration, yes. > >> UA --> LIS: Subscribe to LbyR+Dial String+PSAP URI > > This would be a new protocol, as no current proposal supports that. I > thought one of the consensus calls in Prague was not to abuse HTTP > into a event notification protocol, for example. > > >> UA <-- LIS: Notification > > Again, this is the SIP configuration model. Since the notification > protocol is, by definition, going to be a particular protocol, you are > either going to create a wholly new event notification architecture > that is neither XMPP nor SIP, or use SIP (or XMPP), which then makes > it ill-suited for native speakers of other protocols. We've had this > problem before, in the context of using SIP as LCP (I have a > semi-stale draft on that, if you like...), where there was protest > based on "I don't speak SIP and don't want to implement SIP just to > get location information". I'm sure if we pick XMPP, say, we'd get the > same complaint from the SIP crowd. > >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 15:14:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hec4r-0007bF-4f; Thu, 19 Apr 2007 15:13:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hec4q-0007SU-4q for ecrit@ietf.org; Thu, 19 Apr 2007 15:13:56 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hec4p-0002yL-Fc for ecrit@ietf.org; Thu, 19 Apr 2007 15:13:56 -0400 Received: (qmail invoked by alias); 19 Apr 2007 19:13:53 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp044) with SMTP; 19 Apr 2007 21:13:53 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/iV3taxH7iaxiWV2hH62m+B3NwQlE7FZ1Xibn194 j51l4HsGoMUJQq Message-ID: <4627BF6F.607@gmx.net> Date: Thu, 19 Apr 2007 21:13:51 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Liess, Laura" Subject: Re: AW: [Ecrit] Solution Approaches References: <182C63BFBAF131428EA0C16F7FD2191B013584C2@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <182C63BFBAF131428EA0C16F7FD2191B013584C2@S4DE8PSAAGM.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Cc: Richard.Stastny@oefeg.at, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Laura, that's also an option. The problem here is that the PSAP does not get identity information about the emergency caller since the identity is unknown to to the access providers if they happen to use a VSP that is different from the ISP/ASP. In my list of solution approaches I thought that this would be a problem. Given the complexity we currently discuss I would suggest people to always go for unauthenticated network access and use the local SIP proxy. Ciao Hannes Liess, Laura wrote: > Richard, > > currently, our own SIP-proxy routes emergency calls comming from our IP-access network to the old PSTN PSAPs. Currently we don't have or plan neither LOST nor ESRP nor IP PSAPs. We just assume for Germany national ESRP would be a solution all main players can live with. > Laura > > >> -----Ursprüngliche Nachricht----- >> Von: Stastny Richard [mailto:Richard.Stastny@oefeg.at] >> Gesendet: Mittwoch, 18. April 2007 10:16 >> An: Liess, Laura; Hannes.Tschofenig@gmx.net; ecrit@ietf.org >> Betreff: RE: [Ecrit] Solution Approaches >> >> >> Laura, >> >> In your proposal, you have one ESRP per country (or state)? >> >> Or am I missing something? >> >> Richard >> >> >>> -----Original Message----- >>> From: Liess, Laura [mailto:Laura.Liess@t-systems.com] >>> Sent: Tuesday, April 17, 2007 5:37 PM >>> To: Hannes.Tschofenig@gmx.net; ecrit@ietf.org >>> Subject: AW: [Ecrit] Solution Approaches >>> >>> >>> Hannes, >>> >>> thanks a lot for putting the whole discussion together. >>> >>> I can not give you a feedback which is agreed within DT >>> >> (the internal >> >>> agreement process would probably take some time). But I roughly >>> discussed the approaches with people working on emergency >>> >> calling. If >> >>> we understood the proposal correctly, we have a strong >>> >> preference for >> >>> the approach number 8), which could work as follows: >>> >>> The ASP/ISP provides to the client the LbyR, the country code (or >>> country and state codes)and the local EC dial string (at login and >>> whenever these data change). The client queries LOST and >>> >> gets back an >> >>> ESRP URI. When the caller dials the emergency calling number, the >>> client queries again the ASP/VSP for the LbyR and the >>> >> country code and >> >>> LOST query for the ESRP URI. The VSP routes the call to the >>> >> ESRP. The >> >>> ESRP has a shared secret with the LIS, gets the user >>> >> location and the >> >>> correct PSAP and routes the call with the location info to the PSAP >>> (TLS required). (ESRP or a local LOST does load balancing >>> >> for PSAPs an >> >>> all this stuff). >>> >>> Alternatively, the VSPs SIP proxy can do the LOST queries. >>> >>> >>> Laura >>> >>> >>> >>>> -----Ursprüngliche Nachricht----- >>>> Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Gesendet: Dienstag, 17. April 2007 11:12 >>>> An: ECRIT >>>> Betreff: [Ecrit] Solution Approaches >>>> >>>> >>>> Hi all, >>>> >>>> I would like to share some potential solution approaches >>>> >> with you to >> >>>> deal with the problem of not providing precise location >>>> >> to the end >> >>>> host. I had a chance to discuss these aspects with Henning >>>> face-to-face last Friday. Here is a short summary. >>>> >>>> Note that the goal was to avoid some form of relationship (e.g., >>>> business relationship) between the VSP and the ASP/ISP >>>> >> (since this >> >>>> would impose a significant deployment problem). >>>> >>>> 1) Provide enough location information so that the emergency call >>>> can be routed to the correct PSAP. Precise location information >>>> would be provided to the PSAP. >>>> This approach was already discussed on the list. We need >>>> feedback from, >>>> for example, Barbara and Laura whether they feel comfortable >>>> with this >>>> approach. >>>> >>>> CONSEQUENCE: No changes needed. >>>> >>>> 2) Provide LbyR + Dial String + PSAP URI to the end host. >>>> >> We could >> >>>> ignore the potential security vulnerabilities if charging does not >>>> work on a call-by-call basis. >>>> >>>> CONSEQUENCE: No changes needed. >>>> >>>> 3) Provide LbyR + Dial String + PSAP URI to the end host. >>>> >> VSP does a >> >>>> reverse LoST lookup to verify the PSAP URI. >>>> >>>> CONSEQUENCE: Solution needs to be developed. >>>> >>>> 4) Provide LbyR + Dial String + PSAP URI to the end host. VSP >>>> verifies the PSAP URI with the PSAP URIs being flooded (using the >>>> LoST synchronization mechanism). This mechanism is potentially >>>> similar to (3) >>>> -- details might vary. (3) might use a distributed approach >>>> whereas this >>>> is brute force. >>>> >>>> CONSEQUENCE: Solution needs to be developed. >>>> >>>> 5) Emergency calls are routed via the SIP proxy of the VSP and >>>> subsequently via a SIP proxy in the ASP/ISP (redirect mode) SIP >>>> Location Conveyance would be used instead of GEOPRIV L7 LCP >>>> Assumption: No service level agreement (or business >>>> agreement) between >>>> VSP and ISP/ASP for this type of SIP emergency message routing >>>> required. >>>> >>>> CONSEQUENCE: No changes needed. Potential problems with >>>> >> SIP Identity >> >>>> possible >>>> >>>> 6) Emergency calls are routed via the SIP proxy of the VSP and >>>> subsequently via a SIP proxy in the ASP/ISP (no redirect >>>> mode) SIP Location Conveyance would be used instead of GEOPRIV L7 >>>> LCP >>>> Assumption: No service level agreement (or business >>>> agreement) between >>>> VSP and ISP/ASP for this type of SIP emergency message >>>> routing required. >>>> >>>> CONSEQUENCE: No changes needed. >>>> >>>> 7) Decoupled authentication for SIP message routing >>>> >> Authentication >> >>>> exchange between the end host and the VSP (e.g., TLS to obtain a >>>> SAML assertion) Authentication credentials are then added to the >>>> SIP emergency message >>>> that is routed via the SIP proxy in the VSP/ISP. >>>> No service level agreement (or business agreement) between VSP and >>>> ISP/ASP needed. >>>> >>>> CONSEQUENCE: Security extension for this purpose needs to be >>>> progressed (already available in draft form) >>>> >>>> 8) Country Code Routing >>>> >>>> LIS provides country code to the end host. The end host >>>> >> routes the >> >>>> SIP emergency message via the VSP towards a ESRP that >>>> >> corresponds to >> >>>> the country code. Then, ESRP fetches more detailed location >>>> information todo routing within the country. >>>> >>>> CONSEQUENCE: No changes to the protocol mechanisms. Deployment of >>>> ESRPs that work this way are needed. Establishment of ESRP <-> >>>> ISP/ASP is more >>>> difficult than with PSAP <-> ISP/ASP since there are far more >>>> nodes to >>>> consider. >>>> >>>> 9) Assume end hosts have certs for emergency services; >>>> >> routing via >> >>>> SIP proxy in ISP/ASP without traversing VSP in the emergency case. >>>> Existing credential infrastructure can be used when utilizing SIP >>>> Cert. >>>> >>>> CONSEQUENCE: Architectural aspects need to be developed. A little >>>> bit more difficult to deploy for VSP. Potential issues >>>> >> with callback >> >>>> (to >>>> AoR) since end host is not registered with VSP. >>>> >>>> 10) Routing via SIP proxy in ISP/ASP. Diameter SIP >>>> >> application used >> >>>> to authenticate end host >>>> Assumption: No roaming agreement assumed for ISP/ASP <-> >>>> >> VSP Diameter >> >>>> SIP interaction. >>>> >>>> CONSEQUENCE: Problems with legacy credentials, previously >>>> >> mentioned >> >>>> call back problems since end host is not registered with VSP, >>>> Diameter SIP application would need to be profiled. >>>> >>>> Thoughts? >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 15:44:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HecY3-0003yN-Cr; Thu, 19 Apr 2007 15:44:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HecY1-0003wQ-WF for ecrit@ietf.org; Thu, 19 Apr 2007 15:44:06 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HecY1-0000Mj-6x for ecrit@ietf.org; Thu, 19 Apr 2007 15:44:05 -0400 Received: (qmail invoked by alias); 19 Apr 2007 19:44:03 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp021) with SMTP; 19 Apr 2007 21:44:03 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/i9NEbfrbi5KKBFV0foMR1Mpgw2vBIxq9O3FFZH9 B64r/nc34qJ3R+ Message-ID: <4627C682.2070604@gmx.net> Date: Thu, 19 Apr 2007 21:44:02 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: 'ECRIT' References: <122301c782af$fc0ee230$640fa8c0@cis.neustar.com> In-Reply-To: <122301c782af$fc0ee230$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: GEOPRIV Subject: [Ecrit] Soliciting Feedback: (Partial) Location Hiding Emergency Services Architecture X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, I think it is good to solicit feedback from the group. Brian compiled text in a previous mail and I just changed the subject header and shorted the text a bit. Note that the drawback of this architecture is the need to deploy a ESRP for a country, the need to establish a relationship between the ESRP and the LIS (in order for the ESRP to obtain more detailed location information) and the need to route emergency SIP messages through the ESRP. So far we haven't received a lot of comments from operators. Please find my questions below: Brian Rosen wrote: > Okay, well, discussion has died down now, so I'd like to see if we have > consensus on how we allow access networks to hide location from endpoints > (and VSPs) and yet result in correct emergency call routing. > > The proposal requires no changes to existing documents (other than > explanations in -framework and -phonebcp). > > It requires no changes in endpoint, VSP, ESRP or PSAP behavior. It is > confined to LIS behavior for LIS' that wish to hide location. > > It works as follows: > > 1. The endpoint uses an LCP to request location. The LIS returns an LbyR > 2. The endpoint dereferences the LbyR. > 3. The LIS, noticing that the dereference request is from the endpoint (or > at least not from any entity that is entitled to get fine grained location), > takes the fine grained location and uses LoST to determine the PSAP that > serves that location. > 4. The LIS returns to the endpoint a location which, if submitted to LoST, > would return the same PSAP URI the fine grained location would. In some > circumstances, this could be a civic with only a country. An alternative > that works for all circumstances is to return the polygon that defines the > service boundary of the PSAP (which LoST can return). Is essential that the > PSAP URI returned from a LoST query with whatever the LIS gives the endpoint > would be the same PSAP URI any querier using the fine grained location would > get. > 5. The endpoint uses the (coarse) location value it obtains to query LoST. > It gets the (correct) PSAP URI > 6. This is repeated at call time. The endpoint has a valid LbyR and a valid > PSAP URI, which it uses to construct the emergency call > 7. A VSP wishing to validate the PSAP URI takes the LbyR and dereferences > it. The result will be the same (coarse) location the endpoint got. The > VSP does a LoST query with that location, and should get the same PSAP URI > that is in the Request URI on the call. This validation works for coarse or > fine validation, and of course works for LbyV without the dereference step. > 8. The PSAP (or ESRP) which is the target of the PSAP URI gets the SIP message. It > dereferences the LbyR but gets the fine grained location; the LIS must have > a relationship with the ESRP/PSAP to assure this. > 9. Any succeeding ESRPs or PSAPs can also dereference and get fine grained > location. > > Here are the questions: 1) Do you think that the problem statement is valid (i.e., the problem that some ASP/ISP do not reveal precise location information for free, for emergency services)? 2) Do you think we should investigate the proposed approach in more detail? 3) Do you understand the drawbacks? 4) Do you think it is necessary to solicit feedback from VoIP providers, PSAP operators, regulators and network operators on this issue? Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 15:49:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hecda-0002Kz-Tt; Thu, 19 Apr 2007 15:49:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HecdZ-0002J2-58; Thu, 19 Apr 2007 15:49:49 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HecdY-0001Bf-Hv; Thu, 19 Apr 2007 15:49:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Soliciting Feedback: (Partial) Location Hiding Emergency Services Architecture Date: Thu, 19 Apr 2007 21:48:31 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D466B1D7F@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Soliciting Feedback: (Partial) Location Hiding Emergency Services Architecture Thread-Index: AceCux8olWAzKokYQimdeeZQhw7SogAAJY6X References: <122301c782af$fc0ee230$640fa8c0@cis.neustar.com> <4627C682.2070604@gmx.net> From: "Stastny Richard" To: "Hannes Tschofenig" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: GEOPRIV X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org >Note that the drawback of this architecture is the need to deploy a = ESRP >for a country, Where did you get this from? It could be, but it need not =20 Richard ________________________________ Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Gesendet: Do 19.04.2007 21:44 An: 'ECRIT' Cc: GEOPRIV Betreff: [Ecrit] Soliciting Feedback: (Partial) Location Hiding = Emergency Services Architecture Hi all, I think it is good to solicit feedback from the group. Brian compiled text in a previous mail and I just changed the subject header and shorted the text a bit. Note that the drawback of this architecture is the need to deploy a ESRP for a country, the need to establish a relationship between the ESRP and the LIS (in order for the ESRP to obtain more detailed location information) and the need to route emergency SIP messages through the = ESRP. So far we haven't received a lot of comments from operators. Please find my questions below: Brian Rosen wrote: > Okay, well, discussion has died down now, so I'd like to see if we = have > consensus on how we allow access networks to hide location from = endpoints > (and VSPs) and yet result in correct emergency call routing. > > The proposal requires no changes to existing documents (other than > explanations in -framework and -phonebcp). > > It requires no changes in endpoint, VSP, ESRP or PSAP behavior. It is > confined to LIS behavior for LIS' that wish to hide location. > > It works as follows: > > 1. The endpoint uses an LCP to request location. The LIS returns an = LbyR > 2. The endpoint dereferences the LbyR.=20 > 3. The LIS, noticing that the dereference request is from the endpoint = (or > at least not from any entity that is entitled to get fine grained = location), > takes the fine grained location and uses LoST to determine the PSAP = that > serves that location. > 4. The LIS returns to the endpoint a location which, if submitted to = LoST, > would return the same PSAP URI the fine grained location would. In = some > circumstances, this could be a civic with only a country. An = alternative > that works for all circumstances is to return the polygon that defines = the > service boundary of the PSAP (which LoST can return). Is essential = that the > PSAP URI returned from a LoST query with whatever the LIS gives the = endpoint > would be the same PSAP URI any querier using the fine grained location = would > get. > 5. The endpoint uses the (coarse) location value it obtains to query = LoST. > It gets the (correct) PSAP URI > 6. This is repeated at call time. The endpoint has a valid LbyR and a = valid > PSAP URI, which it uses to construct the emergency call > 7. A VSP wishing to validate the PSAP URI takes the LbyR and = dereferences > it. The result will be the same (coarse) location the endpoint got. = The > VSP does a LoST query with that location, and should get the same PSAP = URI > that is in the Request URI on the call. This validation works for = coarse or > fine validation, and of course works for LbyV without the dereference = step. > 8. The PSAP (or ESRP) which is the target of the PSAP URI gets the SIP = message. It > dereferences the LbyR but gets the fine grained location; the LIS must = have > a relationship with the ESRP/PSAP to assure this. > 9. Any succeeding ESRPs or PSAPs can also dereference and get fine = grained > location. > > =20 Here are the questions: 1) Do you think that the problem statement is valid (i.e., the problem that some ASP/ISP do not reveal precise location information for free, for emergency services)? 2) Do you think we should investigate the proposed approach in more = detail? 3) Do you understand the drawbacks? 4) Do you think it is necessary to solicit feedback from VoIP providers, PSAP operators, regulators and network operators on this issue? Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 15:52:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hecfu-0005HP-OT; Thu, 19 Apr 2007 15:52:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hecft-0005FZ-Jw; Thu, 19 Apr 2007 15:52:13 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hecfs-0001uS-At; Thu, 19 Apr 2007 15:52:13 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3JJqABg025863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 19 Apr 2007 15:52:10 -0400 (EDT) In-Reply-To: <4627C682.2070604@gmx.net> References: <122301c782af$fc0ee230$640fa8c0@cis.neustar.com> <4627C682.2070604@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4C22645C-BFA9-4C72-A4B7-D7A569D45269@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Thu, 19 Apr 2007 15:53:27 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: GEOPRIV , 'ECRIT' Subject: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial) Location Hiding Emergency Services Architecture X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > 1) Do you think that the problem statement is valid (i.e., the > problem that some ASP/ISP do not reveal precise location > information for free, for emergency services)? Fortunately, if it turns out that this is a non-issue in the immediate or further future, the cost to end systems is nil. It is rather unlikely that we'll get feedback from a representative sample of operators. Some future operators, such as WiMax operators, may not exist at this time. > 2) Do you think we should investigate the proposed approach in more > detail? > 3) Do you understand the drawbacks? > 4) Do you think it is necessary to solicit feedback from VoIP > providers, PSAP operators, regulators and network operators on this > issue? > I think feedback should be solicited for the whole architecture, not this specific aspect. I don't think we want to encourage people to hide location or to make that the default behavior, given the difficulty of end-user fault detection, say. By the way, I think it would be helpful if the framework or phonebcp would recommend that PSAPs read back location information via text-to- speech when test calls are being placed. > Ciao > Hannes & Marc > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 15:56:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heck7-0007iM-ME; Thu, 19 Apr 2007 15:56:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heck6-0007hH-EO for ecrit@ietf.org; Thu, 19 Apr 2007 15:56:34 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Heck4-00033K-Ua for ecrit@ietf.org; Thu, 19 Apr 2007 15:56:34 -0400 Received: (qmail invoked by alias); 19 Apr 2007 19:56:31 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp018) with SMTP; 19 Apr 2007 21:56:31 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19GYK4SWhdGVCiWaJC3SnjrpzzbjdH25c2/j1+uwV O6rt4CrIQrEOmK Message-ID: <4627C96E.6030506@gmx.net> Date: Thu, 19 Apr 2007 21:56:30 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Ecrit] Soliciting Feedback: (Partial) Location Hiding Emergency Services Architecture References: <122301c782af$fc0ee230$640fa8c0@cis.neustar.com> <4627C682.2070604@gmx.net> <32755D354E6B65498C3BD9FD496C7D466B1D7F@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D466B1D7F@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Richard, if the access networks returns only the country code (in the worst case) then LoST will return (in the worst case) an ESRP corresponding to that country. The emergency call would then be routed to this ESRP and subsequently this ESRP would have to fetch more detailed location information for routing within this country. Do I miss something? Ciao Hannes Stastny Richard wrote: >> Note that the drawback of this architecture is the need to deploy a ESRP >> for a country, >> > > Where did you get this from? It could be, but it need not > > Richard > > ________________________________ > > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Gesendet: Do 19.04.2007 21:44 > An: 'ECRIT' > Cc: GEOPRIV > Betreff: [Ecrit] Soliciting Feedback: (Partial) Location Hiding Emergency Services Architecture > > > > Hi all, > > I think it is good to solicit feedback from the group. Brian compiled > text in a previous mail and I just changed the subject header and > shorted the text a bit. > > Note that the drawback of this architecture is the need to deploy a ESRP > for a country, the need to establish a relationship between the ESRP and > the LIS (in order for the ESRP to obtain more detailed location > information) and the need to route emergency SIP messages through the ESRP. > > So far we haven't received a lot of comments from operators. > > Please find my questions below: > > Brian Rosen wrote: > >> Okay, well, discussion has died down now, so I'd like to see if we have >> consensus on how we allow access networks to hide location from endpoints >> (and VSPs) and yet result in correct emergency call routing. >> >> The proposal requires no changes to existing documents (other than >> explanations in -framework and -phonebcp). >> >> It requires no changes in endpoint, VSP, ESRP or PSAP behavior. It is >> confined to LIS behavior for LIS' that wish to hide location. >> >> It works as follows: >> >> 1. The endpoint uses an LCP to request location. The LIS returns an LbyR >> 2. The endpoint dereferences the LbyR. >> 3. The LIS, noticing that the dereference request is from the endpoint (or >> at least not from any entity that is entitled to get fine grained location), >> takes the fine grained location and uses LoST to determine the PSAP that >> serves that location. >> 4. The LIS returns to the endpoint a location which, if submitted to LoST, >> would return the same PSAP URI the fine grained location would. In some >> circumstances, this could be a civic with only a country. An alternative >> that works for all circumstances is to return the polygon that defines the >> service boundary of the PSAP (which LoST can return). Is essential that the >> PSAP URI returned from a LoST query with whatever the LIS gives the endpoint >> would be the same PSAP URI any querier using the fine grained location would >> get. >> 5. The endpoint uses the (coarse) location value it obtains to query LoST. >> It gets the (correct) PSAP URI >> 6. This is repeated at call time. The endpoint has a valid LbyR and a valid >> PSAP URI, which it uses to construct the emergency call >> 7. A VSP wishing to validate the PSAP URI takes the LbyR and dereferences >> it. The result will be the same (coarse) location the endpoint got. The >> VSP does a LoST query with that location, and should get the same PSAP URI >> that is in the Request URI on the call. This validation works for coarse or >> fine validation, and of course works for LbyV without the dereference step. >> 8. The PSAP (or ESRP) which is the target of the PSAP URI gets the SIP message. It >> dereferences the LbyR but gets the fine grained location; the LIS must have >> a relationship with the ESRP/PSAP to assure this. >> 9. Any succeeding ESRPs or PSAPs can also dereference and get fine grained >> location. >> >> >> > > Here are the questions: > > 1) Do you think that the problem statement is valid (i.e., the problem > that some ASP/ISP do not reveal precise location information for free, > for emergency services)? > 2) Do you think we should investigate the proposed approach in more detail? > 3) Do you understand the drawbacks? > 4) Do you think it is necessary to solicit feedback from VoIP providers, > PSAP operators, regulators and network operators on this issue? > > Ciao > Hannes & Marc > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 16:03:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HecqU-00007s-L7; Thu, 19 Apr 2007 16:03:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HecqS-0008T5-G3 for ecrit@ietf.org; Thu, 19 Apr 2007 16:03:08 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HecqR-0004wz-29 for ecrit@ietf.org; Thu, 19 Apr 2007 16:03:08 -0400 Received: (qmail invoked by alias); 19 Apr 2007 20:03:06 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp050) with SMTP; 19 Apr 2007 22:03:06 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19I8lFioUJIloJIEX4FKKx5/tVOoloc7Kr4vBGcNl 5E0F/mbxSWpGHv Message-ID: <4627CAF8.8060405@gmx.net> Date: Thu, 19 Apr 2007 22:03:04 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Henning Schulzrinne References: <122301c782af$fc0ee230$640fa8c0@cis.neustar.com> <4627C682.2070604@gmx.net> <4C22645C-BFA9-4C72-A4B7-D7A569D45269@cs.columbia.edu> In-Reply-To: <4C22645C-BFA9-4C72-A4B7-D7A569D45269@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: GEOPRIV , 'ECRIT' Subject: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial) Location Hiding Emergency Services Architecture X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Henning Henning Schulzrinne wrote: >> >> 1) Do you think that the problem statement is valid (i.e., the >> problem that some ASP/ISP do not reveal precise location information >> for free, for emergency services)? > > Fortunately, if it turns out that this is a non-issue in the immediate > or further future, the cost to end systems is nil. It is rather > unlikely that we'll get feedback from a representative sample of > operators. Some future operators, such as WiMax operators, may not > exist at this time. > > >> 2) Do you think we should investigate the proposed approach in more >> detail? >> 3) Do you understand the drawbacks? >> 4) Do you think it is necessary to solicit feedback from VoIP >> providers, PSAP operators, regulators and network operators on this >> issue? >> > > I think feedback should be solicited for the whole architecture, not > this specific aspect. I don't think we want to encourage people to > hide location or to make that the default behavior, given the > difficulty of end-user fault detection, say. We don't want to encourage people to hide location for various reasons. You are right that we don't want to solicit feedback only on this issue. On the other hand we are designing an "enhancement" based on the feedback we got from a few operators regarding partial location hiding. Shouldn't we get feedback from a number of stakeholders about the validity of this architectural facet? > > By the way, I think it would be helpful if the framework or phonebcp > would recommend that PSAPs read back location information via > text-to-speech when test calls are being placed. Sounds good to me. Ciao Hannes > >> Ciao >> Hannes & Marc >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 16:16:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hed2j-0003bP-Hy; Thu, 19 Apr 2007 16:15:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hed2i-0003bH-O8; Thu, 19 Apr 2007 16:15:48 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hed2h-0007Ps-Gz; Thu, 19 Apr 2007 16:15:48 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3JKFT5X025517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 19 Apr 2007 16:15:36 -0400 (EDT) In-Reply-To: <4627C96E.6030506@gmx.net> References: <122301c782af$fc0ee230$640fa8c0@cis.neustar.com> <4627C682.2070604@gmx.net> <32755D354E6B65498C3BD9FD496C7D466B1D7F@oefeg-s04.oefeg.loc> <4627C96E.6030506@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Re: [Ecrit] Soliciting Feedback: (Partial) Location Hiding Emergency Services Architecture Date: Thu, 19 Apr 2007 16:16:46 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: GEOPRIV , Stastny Richard , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org There clearly is a linkage here between the PSAP coverage region (or ESRP region and, conversely, the number of them) and the information returned. An ISP can't just say "sorry, I'm only going to give you country-level information and it's your problem to set up an ESRP, but I will only give location information to certain favored VSPs that might operate such a proxy". I suspect regulators are smart enough to recognize any such hypothetical attempts at trying to restrain competition, but I doubt we can force this through technology design. An ISP that is willing to release complete location information to the end user can essentially wash their hand of the whole emergency calling thing; an ISP wishing to hide such information needs to work more closely with local authorities and PSAPs, both in terms of architecture and in terms of access authorization. ISPs can then make business and technology choices, constrained by the local regulator, as to which mode they prefer to work in. This may well change over time; for example, future customer-facing and OSS systems may make location conveyance cheaper and easier, thus removing one incentive to hide this information. To some extent, this is a trade-off between capital and operational/lawyer expenses. I think the best we can do is to offer reasonable choices and hope that operators are both rational actors and have the life and safety of their customers at heart. Henning On Apr 19, 2007, at 3:56 PM, Hannes Tschofenig wrote: > Hi Richard, > > if the access networks returns only the country code (in the worst > case) then LoST will return (in the worst case) an ESRP > corresponding to that country. > The emergency call would then be routed to this ESRP and > subsequently this ESRP would have to fetch more detailed location > information for routing within this country. > > Do I miss something? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 16:18:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hed5Y-0007bi-RW; Thu, 19 Apr 2007 16:18:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hed5Y-0007ba-2U; Thu, 19 Apr 2007 16:18:44 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hed5W-0007zg-SI; Thu, 19 Apr 2007 16:18:44 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1Hed51-0000uC-Nz; Thu, 19 Apr 2007 15:18:11 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Hannes Tschofenig'" Subject: RE: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial) LocationHiding Emergency Services Architecture Date: Thu, 19 Apr 2007 16:18:38 -0400 Message-ID: <123f01c782bf$ec69f580$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceCvCnLU7nGzWyDSsKyP3L5NFaA1QAA5NkA In-Reply-To: <4C22645C-BFA9-4C72-A4B7-D7A569D45269@cs.columbia.edu> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: 'GEOPRIV' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > By the way, I think it would be helpful if the framework or phonebcp > would recommend that PSAPs read back location information via text-to- > speech when test calls are being placed. Uh, well, in a form suitable for the media offered in the first place. That may be text, it may be text to sign language. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 16:24:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HedAm-0003n3-Hr; Thu, 19 Apr 2007 16:24:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HedAl-0003mv-H5; Thu, 19 Apr 2007 16:24:07 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HedAj-0000Qq-LC; Thu, 19 Apr 2007 16:24:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] Soliciting Feedback: (Partial) Location Hiding Emergency Services Architecture Date: Thu, 19 Apr 2007 22:22:00 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D466B1D80@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Soliciting Feedback: (Partial) Location Hiding Emergency Services Architecture Thread-Index: AceCvNYeB7zm7BGWTjyIFNFzJj6Q1wAA4yQ2 References: <122301c782af$fc0ee230$640fa8c0@cis.neustar.com> <4627C682.2070604@gmx.net> <32755D354E6B65498C3BD9FD496C7D466B1D7F@oefeg-s04.oefeg.loc> <4627C96E.6030506@gmx.net> From: "Stastny Richard" To: "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes, =20 as you say, this is the worst case. but you can go down to village level if you want >> Note that the drawback of this architecture is the need to deploy a = ESRP >> for a country, =20 this sounds like the worst case is the only option Richard ________________________________ Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Gesendet: Do 19.04.2007 21:56 An: Stastny Richard Cc: ECRIT; GEOPRIV Betreff: Re: [Ecrit] Soliciting Feedback: (Partial) Location Hiding = Emergency Services Architecture Hi Richard, if the access networks returns only the country code (in the worst case) then LoST will return (in the worst case) an ESRP corresponding to that country. The emergency call would then be routed to this ESRP and subsequently this ESRP would have to fetch more detailed location information for routing within this country. Do I miss something? Ciao Hannes Stastny Richard wrote: >> Note that the drawback of this architecture is the need to deploy a = ESRP >> for a country, >> =20 > > Where did you get this from? It could be, but it need not >=20 > Richard > > ________________________________ > > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Gesendet: Do 19.04.2007 21:44 > An: 'ECRIT' > Cc: GEOPRIV > Betreff: [Ecrit] Soliciting Feedback: (Partial) Location Hiding = Emergency Services Architecture > > > > Hi all, > > I think it is good to solicit feedback from the group. Brian compiled > text in a previous mail and I just changed the subject header and > shorted the text a bit. > > Note that the drawback of this architecture is the need to deploy a = ESRP > for a country, the need to establish a relationship between the ESRP = and > the LIS (in order for the ESRP to obtain more detailed location > information) and the need to route emergency SIP messages through the = ESRP. > > So far we haven't received a lot of comments from operators. > > Please find my questions below: > > Brian Rosen wrote: > =20 >> Okay, well, discussion has died down now, so I'd like to see if we = have >> consensus on how we allow access networks to hide location from = endpoints >> (and VSPs) and yet result in correct emergency call routing. >> >> The proposal requires no changes to existing documents (other than >> explanations in -framework and -phonebcp). >> >> It requires no changes in endpoint, VSP, ESRP or PSAP behavior. It = is >> confined to LIS behavior for LIS' that wish to hide location. >> >> It works as follows: >> >> 1. The endpoint uses an LCP to request location. The LIS returns an = LbyR >> 2. The endpoint dereferences the LbyR. >> 3. The LIS, noticing that the dereference request is from the = endpoint (or >> at least not from any entity that is entitled to get fine grained = location), >> takes the fine grained location and uses LoST to determine the PSAP = that >> serves that location. >> 4. The LIS returns to the endpoint a location which, if submitted to = LoST, >> would return the same PSAP URI the fine grained location would. In = some >> circumstances, this could be a civic with only a country. An = alternative >> that works for all circumstances is to return the polygon that = defines the >> service boundary of the PSAP (which LoST can return). Is essential = that the >> PSAP URI returned from a LoST query with whatever the LIS gives the = endpoint >> would be the same PSAP URI any querier using the fine grained = location would >> get. >> 5. The endpoint uses the (coarse) location value it obtains to query = LoST. >> It gets the (correct) PSAP URI >> 6. This is repeated at call time. The endpoint has a valid LbyR and = a valid >> PSAP URI, which it uses to construct the emergency call >> 7. A VSP wishing to validate the PSAP URI takes the LbyR and = dereferences >> it. The result will be the same (coarse) location the endpoint got. = The >> VSP does a LoST query with that location, and should get the same = PSAP URI >> that is in the Request URI on the call. This validation works for = coarse or >> fine validation, and of course works for LbyV without the dereference = step. >> 8. The PSAP (or ESRP) which is the target of the PSAP URI gets the = SIP message. It >> dereferences the LbyR but gets the fine grained location; the LIS = must have >> a relationship with the ESRP/PSAP to assure this. >> 9. Any succeeding ESRPs or PSAPs can also dereference and get fine = grained >> location. >> >>=20 >> =20 > > Here are the questions: > > 1) Do you think that the problem statement is valid (i.e., the problem > that some ASP/ISP do not reveal precise location information for free, > for emergency services)? > 2) Do you think we should investigate the proposed approach in more = detail? > 3) Do you understand the drawbacks? > 4) Do you think it is necessary to solicit feedback from VoIP = providers, > PSAP operators, regulators and network operators on this issue? > > Ciao > Hannes & Marc > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 16:28:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HedES-0000nR-Dl; Thu, 19 Apr 2007 16:27:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HedER-0000nI-E2; Thu, 19 Apr 2007 16:27:55 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HedEQ-0001V0-7B; Thu, 19 Apr 2007 16:27:55 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3JKReN2004732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 19 Apr 2007 16:27:40 -0400 (EDT) In-Reply-To: <123f01c782bf$ec69f580$640fa8c0@cis.neustar.com> References: <123f01c782bf$ec69f580$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial) LocationHiding Emergency Services Architecture Date: Thu, 19 Apr 2007 16:28:57 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 'GEOPRIV' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Certainly; I'm getting infected with the voice-centric virus... On Apr 19, 2007, at 4:18 PM, Brian Rosen wrote: >> By the way, I think it would be helpful if the framework or phonebcp >> would recommend that PSAPs read back location information via text- >> to- >> speech when test calls are being placed. > Uh, well, in a form suitable for the media offered in the first > place. That > may be text, it may be text to sign language. > > Brian > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 16:29:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HedGA-0002L5-1i; Thu, 19 Apr 2007 16:29:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HedG8-0002K3-EG; Thu, 19 Apr 2007 16:29:40 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HedG7-0002D4-3b; Thu, 19 Apr 2007 16:29:40 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3JKTAnn011572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Apr 2007 13:29:11 -0700 Received: from [129.46.226.38] (carbuncle.qualcomm.com [129.46.226.38]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3JKT90J027214; Thu, 19 Apr 2007 13:29:09 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <123f01c782bf$ec69f580$640fa8c0@cis.neustar.com> References: <123f01c782bf$ec69f580$640fa8c0@cis.neustar.com> Date: Thu, 19 Apr 2007 13:29:08 -0700 To: "Brian Rosen" , "'Henning Schulzrinne'" , "'Hannes Tschofenig'" From: Ted Hardie Subject: RE: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial) LocationHiding Emergency Services Architecture Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 'GEOPRIV' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 4:18 PM -0400 4/19/07, Brian Rosen wrote: > > By the way, I think it would be helpful if the framework or phonebcp >> would recommend that PSAPs read back location information via text-to- >> speech when test calls are being placed. >Uh, well, in a form suitable for the media offered in the first place. That >may be text, it may be text to sign language. > >Brian First off, I'm not sure why Geopriv is cc'ed on this message. Isn't what is in framework/phonebcp purely an ECRIT matter? Second, why are the UI elements of test call responses in scope for an IETF document? If I understand this right, we're not talking about the protocol elements returned when someone is validating a location prior to making a call, this is about what happens if someone makes a test call to the actual PSAP. How is this within the IETF's scope/knowledge? Confused, Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 16:30:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HedGn-0002pL-VH; Thu, 19 Apr 2007 16:30:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HedGn-0002pC-2w for ecrit@ietf.org; Thu, 19 Apr 2007 16:30:21 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HedGm-0002GG-Ii for ecrit@ietf.org; Thu, 19 Apr 2007 16:30:21 -0400 Received: (qmail invoked by alias); 19 Apr 2007 20:30:19 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp019) with SMTP; 19 Apr 2007 22:30:19 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19Z3A4CNgFZOF+GyGGQdeaqI14f9fl8bReqklj6xm cf1cj3HTn8mTMR Message-ID: <4627D159.5020004@gmx.net> Date: Thu, 19 Apr 2007 22:30:17 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Stastny Richard Subject: Re: [Ecrit] Soliciting Feedback: (Partial) Location Hiding Emergency Services Architecture References: <122301c782af$fc0ee230$640fa8c0@cis.neustar.com> <4627C682.2070604@gmx.net> <32755D354E6B65498C3BD9FD496C7D466B1D7F@oefeg-s04.oefeg.loc> <4627C96E.6030506@gmx.net> <32755D354E6B65498C3BD9FD496C7D466B1D80@oefeg-s04.oefeg.loc> In-Reply-To: <32755D354E6B65498C3BD9FD496C7D466B1D80@oefeg-s04.oefeg.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Richard, Stastny Richard wrote: > Hannes, > > as you say, this is the worst case. > but you can go down to village level if you want > > Correct. >>> Note that the drawback of this architecture is the need to deploy a ESRP >>> for a country, >>> > > this sounds like the worst case is the only option > > No. It really depends on the regulatory environment in a particular country. The remarks by Henning also apply. Ciao Hannes > Richard > > ________________________________ > > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Gesendet: Do 19.04.2007 21:56 > An: Stastny Richard > Cc: ECRIT; GEOPRIV > Betreff: Re: [Ecrit] Soliciting Feedback: (Partial) Location Hiding Emergency Services Architecture > > > > Hi Richard, > > if the access networks returns only the country code (in the worst case) > then LoST will return (in the worst case) an ESRP corresponding to that > country. > The emergency call would then be routed to this ESRP and subsequently > this ESRP would have to fetch more detailed location information for > routing within this country. > > Do I miss something? > > Ciao > Hannes > > Stastny Richard wrote: > >>> Note that the drawback of this architecture is the need to deploy a ESRP >>> for a country, >>> >>> >> Where did you get this from? It could be, but it need not >> >> Richard >> >> ________________________________ >> >> Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Gesendet: Do 19.04.2007 21:44 >> An: 'ECRIT' >> Cc: GEOPRIV >> Betreff: [Ecrit] Soliciting Feedback: (Partial) Location Hiding Emergency Services Architecture >> >> >> >> Hi all, >> >> I think it is good to solicit feedback from the group. Brian compiled >> text in a previous mail and I just changed the subject header and >> shorted the text a bit. >> >> Note that the drawback of this architecture is the need to deploy a ESRP >> for a country, the need to establish a relationship between the ESRP and >> the LIS (in order for the ESRP to obtain more detailed location >> information) and the need to route emergency SIP messages through the ESRP. >> >> So far we haven't received a lot of comments from operators. >> >> Please find my questions below: >> >> Brian Rosen wrote: >> >> >>> Okay, well, discussion has died down now, so I'd like to see if we have >>> consensus on how we allow access networks to hide location from endpoints >>> (and VSPs) and yet result in correct emergency call routing. >>> >>> The proposal requires no changes to existing documents (other than >>> explanations in -framework and -phonebcp). >>> >>> It requires no changes in endpoint, VSP, ESRP or PSAP behavior. It is >>> confined to LIS behavior for LIS' that wish to hide location. >>> >>> It works as follows: >>> >>> 1. The endpoint uses an LCP to request location. The LIS returns an LbyR >>> 2. The endpoint dereferences the LbyR. >>> 3. The LIS, noticing that the dereference request is from the endpoint (or >>> at least not from any entity that is entitled to get fine grained location), >>> takes the fine grained location and uses LoST to determine the PSAP that >>> serves that location. >>> 4. The LIS returns to the endpoint a location which, if submitted to LoST, >>> would return the same PSAP URI the fine grained location would. In some >>> circumstances, this could be a civic with only a country. An alternative >>> that works for all circumstances is to return the polygon that defines the >>> service boundary of the PSAP (which LoST can return). Is essential that the >>> PSAP URI returned from a LoST query with whatever the LIS gives the endpoint >>> would be the same PSAP URI any querier using the fine grained location would >>> get. >>> 5. The endpoint uses the (coarse) location value it obtains to query LoST. >>> It gets the (correct) PSAP URI >>> 6. This is repeated at call time. The endpoint has a valid LbyR and a valid >>> PSAP URI, which it uses to construct the emergency call >>> 7. A VSP wishing to validate the PSAP URI takes the LbyR and dereferences >>> it. The result will be the same (coarse) location the endpoint got. The >>> VSP does a LoST query with that location, and should get the same PSAP URI >>> that is in the Request URI on the call. This validation works for coarse or >>> fine validation, and of course works for LbyV without the dereference step. >>> 8. The PSAP (or ESRP) which is the target of the PSAP URI gets the SIP message. It >>> dereferences the LbyR but gets the fine grained location; the LIS must have >>> a relationship with the ESRP/PSAP to assure this. >>> 9. Any succeeding ESRPs or PSAPs can also dereference and get fine grained >>> location. >>> >>> >>> >>> >> Here are the questions: >> >> 1) Do you think that the problem statement is valid (i.e., the problem >> that some ASP/ISP do not reveal precise location information for free, >> for emergency services)? >> 2) Do you think we should investigate the proposed approach in more detail? >> 3) Do you understand the drawbacks? >> 4) Do you think it is necessary to solicit feedback from VoIP providers, >> PSAP operators, regulators and network operators on this issue? >> >> Ciao >> Hannes & Marc >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> >> > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 16:33:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HedJZ-0006pT-UL; Thu, 19 Apr 2007 16:33:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HedJY-0006nb-KG for ecrit@ietf.org; Thu, 19 Apr 2007 16:33:12 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HedJX-0002iU-7X for ecrit@ietf.org; Thu, 19 Apr 2007 16:33:12 -0400 Received: (qmail invoked by alias); 19 Apr 2007 20:33:08 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp046) with SMTP; 19 Apr 2007 22:33:08 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19aP5RAs5RaCxNqYBEVhUJsH7ao+qu/ClUhiuhczS VCrKGGJcLthzIv Message-ID: <4627D202.8000006@gmx.net> Date: Thu, 19 Apr 2007 22:33:06 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial) LocationHiding Emergency Services Architecture References: <123f01c782bf$ec69f580$640fa8c0@cis.neustar.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: 'GEOPRIV' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Ted, ~snip~ > First off, I'm not sure why Geopriv is cc'ed on this message. Isn't what is > in framework/phonebcp purely an ECRIT matter? > > I thought about that as well. With the previous discussions we came up with a couple of solutions that required changes to the GEOPRIV L7 LCP work. This particular proposal does not require changes (or introduces new requirements) but some of the GEOPRIV members might be interested in the different approach. I don't want to exclude them. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 16:39:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HedPT-0005br-1f; Thu, 19 Apr 2007 16:39:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HedPR-0005bg-WC; Thu, 19 Apr 2007 16:39:18 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HedPQ-0003sJ-1Q; Thu, 19 Apr 2007 16:39:17 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HedOt-0008Lm-KD; Thu, 19 Apr 2007 15:38:44 -0500 From: "Brian Rosen" To: "'Stastny Richard'" , "'Hannes Tschofenig'" Subject: RE: [Geopriv] Re: [Ecrit] Soliciting Feedback: (Partial) LocationHiding Emergency Services Architecture Date: Thu, 19 Apr 2007 16:39:10 -0400 Message-ID: <124901c782c2$cad288d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceCvNYeB7zm7BGWTjyIFNFzJj6Q1wAA4yQ2AABMY/A= In-Reply-To: <32755D354E6B65498C3BD9FD496C7D466B1D80@oefeg-s04.oefeg.loc> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: 'GEOPRIV' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Wait, we're spinning out of the universe. What is required is ONLY that the PSAP URI returned from the coarse location is the same PSAP URI returned from the fine location. That is the only constraint. If country code satisfies that, because every location in some country returns the same result from a LoST query, great. If that isn't true, then country code is insufficient. What always works is the polygon representing the service boundary of the (fine grained location) target PSAP. If the LIS queries LoST with fine grained location, it can get back a suitable polygon. Something between the two examples above MAY work, but the constraint has to be satisfied: LoST(coarse location, service) == LoST(fine location, service) We don't REQUIRE country level ESRPs. You won't get that in North America. In some cases you may get a state level ESRP, but you can't guarantee that. If the service area of the LIS is a proper subset of the service area of the ESRP/PSAP, which is very common, especially with any aggregation via an ESRP, then the LIS' task is simple. Also note that the LIS can't use a specially modified LoST server. The validation depends on a VSP being able to ask its LoST server what the PSAP URI for the proffered location is. Brian > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, April 19, 2007 4:22 PM > To: Hannes Tschofenig > Cc: GEOPRIV; ECRIT > Subject: [Geopriv] Re: [Ecrit] Soliciting Feedback: (Partial) > LocationHiding Emergency Services Architecture > > Hannes, > > as you say, this is the worst case. > but you can go down to village level if you want > > >> Note that the drawback of this architecture is the need to deploy a > ESRP > >> for a country, > > this sounds like the worst case is the only option > > Richard > > ________________________________ > > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Gesendet: Do 19.04.2007 21:56 > An: Stastny Richard > Cc: ECRIT; GEOPRIV > Betreff: Re: [Ecrit] Soliciting Feedback: (Partial) Location Hiding > Emergency Services Architecture > > > > Hi Richard, > > if the access networks returns only the country code (in the worst case) > then LoST will return (in the worst case) an ESRP corresponding to that > country. > The emergency call would then be routed to this ESRP and subsequently > this ESRP would have to fetch more detailed location information for > routing within this country. > > Do I miss something? > > Ciao > Hannes > > Stastny Richard wrote: > >> Note that the drawback of this architecture is the need to deploy a > ESRP > >> for a country, > >> > > > > Where did you get this from? It could be, but it need not > > > > Richard > > > > ________________________________ > > > > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Gesendet: Do 19.04.2007 21:44 > > An: 'ECRIT' > > Cc: GEOPRIV > > Betreff: [Ecrit] Soliciting Feedback: (Partial) Location Hiding > Emergency Services Architecture > > > > > > > > Hi all, > > > > I think it is good to solicit feedback from the group. Brian compiled > > text in a previous mail and I just changed the subject header and > > shorted the text a bit. > > > > Note that the drawback of this architecture is the need to deploy a ESRP > > for a country, the need to establish a relationship between the ESRP and > > the LIS (in order for the ESRP to obtain more detailed location > > information) and the need to route emergency SIP messages through the > ESRP. > > > > So far we haven't received a lot of comments from operators. > > > > Please find my questions below: > > > > Brian Rosen wrote: > > > >> Okay, well, discussion has died down now, so I'd like to see if we have > >> consensus on how we allow access networks to hide location from > endpoints > >> (and VSPs) and yet result in correct emergency call routing. > >> > >> The proposal requires no changes to existing documents (other than > >> explanations in -framework and -phonebcp). > >> > >> It requires no changes in endpoint, VSP, ESRP or PSAP behavior. It is > >> confined to LIS behavior for LIS' that wish to hide location. > >> > >> It works as follows: > >> > >> 1. The endpoint uses an LCP to request location. The LIS returns an > LbyR > >> 2. The endpoint dereferences the LbyR. > >> 3. The LIS, noticing that the dereference request is from the endpoint > (or > >> at least not from any entity that is entitled to get fine grained > location), > >> takes the fine grained location and uses LoST to determine the PSAP > that > >> serves that location. > >> 4. The LIS returns to the endpoint a location which, if submitted to > LoST, > >> would return the same PSAP URI the fine grained location would. In > some > >> circumstances, this could be a civic with only a country. An > alternative > >> that works for all circumstances is to return the polygon that defines > the > >> service boundary of the PSAP (which LoST can return). Is essential > that the > >> PSAP URI returned from a LoST query with whatever the LIS gives the > endpoint > >> would be the same PSAP URI any querier using the fine grained location > would > >> get. > >> 5. The endpoint uses the (coarse) location value it obtains to query > LoST. > >> It gets the (correct) PSAP URI > >> 6. This is repeated at call time. The endpoint has a valid LbyR and a > valid > >> PSAP URI, which it uses to construct the emergency call > >> 7. A VSP wishing to validate the PSAP URI takes the LbyR and > dereferences > >> it. The result will be the same (coarse) location the endpoint got. > The > >> VSP does a LoST query with that location, and should get the same PSAP > URI > >> that is in the Request URI on the call. This validation works for > coarse or > >> fine validation, and of course works for LbyV without the dereference > step. > >> 8. The PSAP (or ESRP) which is the target of the PSAP URI gets the SIP > message. It > >> dereferences the LbyR but gets the fine grained location; the LIS must > have > >> a relationship with the ESRP/PSAP to assure this. > >> 9. Any succeeding ESRPs or PSAPs can also dereference and get fine > grained > >> location. > >> > >> > >> > > > > Here are the questions: > > > > 1) Do you think that the problem statement is valid (i.e., the problem > > that some ASP/ISP do not reveal precise location information for free, > > for emergency services)? > > 2) Do you think we should investigate the proposed approach in more > detail? > > 3) Do you understand the drawbacks? > > 4) Do you think it is necessary to solicit feedback from VoIP providers, > > PSAP operators, regulators and network operators on this issue? > > > > Ciao > > Hannes & Marc > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 16:44:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HedUc-0007yi-6Z; Thu, 19 Apr 2007 16:44:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HedUa-0007yJ-JB; Thu, 19 Apr 2007 16:44:36 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HedUZ-0005k2-Px; Thu, 19 Apr 2007 16:44:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Geopriv] Re: [Ecrit] Soliciting Feedback: (Partial) LocationHiding Emergency Services Architecture Date: Thu, 19 Apr 2007 22:43:58 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D466B1D82@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Re: [Ecrit] Soliciting Feedback: (Partial) LocationHiding Emergency Services Architecture Thread-Index: AceCvNYeB7zm7BGWTjyIFNFzJj6Q1wAA4yQ2AABMY/AAAHf1Pg== References: <124901c782c2$cad288d0$640fa8c0@cis.neustar.com> From: "Stastny Richard" To: "Brian Rosen" , "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Fully agree This is what I wanted to say =20 Richard ________________________________ Von: Brian Rosen [mailto:br@brianrosen.net] Gesendet: Do 19.04.2007 22:39 An: Stastny Richard; 'Hannes Tschofenig' Cc: 'GEOPRIV'; 'ECRIT' Betreff: RE: [Geopriv] Re: [Ecrit] Soliciting Feedback: (Partial) = LocationHiding Emergency Services Architecture Wait, we're spinning out of the universe. What is required is ONLY that the PSAP URI returned from the coarse = location is the same PSAP URI returned from the fine location. That is the only constraint. If country code satisfies that, because every location in some country returns the same result from a LoST query, great. If that isn't true, = then country code is insufficient. What always works is the polygon representing the service boundary of = the (fine grained location) target PSAP. If the LIS queries LoST with fine grained location, it can get back a suitable polygon. Something between the two examples above MAY work, but the constraint = has to be satisfied: LoST(coarse location, service) =3D=3D LoST(fine location, = service) We don't REQUIRE country level ESRPs. You won't get that in North = America. In some cases you may get a state level ESRP, but you can't guarantee = that. If the service area of the LIS is a proper subset of the service area of = the ESRP/PSAP, which is very common, especially with any aggregation via an ESRP, then the LIS' task is simple. Also note that the LIS can't use a specially modified LoST server. The validation depends on a VSP being able to ask its LoST server what the = PSAP URI for the proffered location is.=20 Brian > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Thursday, April 19, 2007 4:22 PM > To: Hannes Tschofenig > Cc: GEOPRIV; ECRIT > Subject: [Geopriv] Re: [Ecrit] Soliciting Feedback: (Partial) > LocationHiding Emergency Services Architecture > > Hannes, > > as you say, this is the worst case. > but you can go down to village level if you want > > >> Note that the drawback of this architecture is the need to deploy a > ESRP > >> for a country, > > this sounds like the worst case is the only option > > Richard > > ________________________________ > > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Gesendet: Do 19.04.2007 21:56 > An: Stastny Richard > Cc: ECRIT; GEOPRIV > Betreff: Re: [Ecrit] Soliciting Feedback: (Partial) Location Hiding > Emergency Services Architecture > > > > Hi Richard, > > if the access networks returns only the country code (in the worst = case) > then LoST will return (in the worst case) an ESRP corresponding to = that > country. > The emergency call would then be routed to this ESRP and subsequently > this ESRP would have to fetch more detailed location information for > routing within this country. > > Do I miss something? > > Ciao > Hannes > > Stastny Richard wrote: > >> Note that the drawback of this architecture is the need to deploy a > ESRP > >> for a country, > >> > > > > Where did you get this from? It could be, but it need not > > > > Richard > > > > ________________________________ > > > > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Gesendet: Do 19.04.2007 21:44 > > An: 'ECRIT' > > Cc: GEOPRIV > > Betreff: [Ecrit] Soliciting Feedback: (Partial) Location Hiding > Emergency Services Architecture > > > > > > > > Hi all, > > > > I think it is good to solicit feedback from the group. Brian = compiled > > text in a previous mail and I just changed the subject header and > > shorted the text a bit. > > > > Note that the drawback of this architecture is the need to deploy a = ESRP > > for a country, the need to establish a relationship between the ESRP = and > > the LIS (in order for the ESRP to obtain more detailed location > > information) and the need to route emergency SIP messages through = the > ESRP. > > > > So far we haven't received a lot of comments from operators. > > > > Please find my questions below: > > > > Brian Rosen wrote: > > > >> Okay, well, discussion has died down now, so I'd like to see if we = have > >> consensus on how we allow access networks to hide location from > endpoints > >> (and VSPs) and yet result in correct emergency call routing. > >> > >> The proposal requires no changes to existing documents (other than > >> explanations in -framework and -phonebcp). > >> > >> It requires no changes in endpoint, VSP, ESRP or PSAP behavior. It = is > >> confined to LIS behavior for LIS' that wish to hide location. > >> > >> It works as follows: > >> > >> 1. The endpoint uses an LCP to request location. The LIS returns = an > LbyR > >> 2. The endpoint dereferences the LbyR. > >> 3. The LIS, noticing that the dereference request is from the = endpoint > (or > >> at least not from any entity that is entitled to get fine grained > location), > >> takes the fine grained location and uses LoST to determine the PSAP > that > >> serves that location. > >> 4. The LIS returns to the endpoint a location which, if submitted = to > LoST, > >> would return the same PSAP URI the fine grained location would. In > some > >> circumstances, this could be a civic with only a country. An > alternative > >> that works for all circumstances is to return the polygon that = defines > the > >> service boundary of the PSAP (which LoST can return). Is essential > that the > >> PSAP URI returned from a LoST query with whatever the LIS gives the > endpoint > >> would be the same PSAP URI any querier using the fine grained = location > would > >> get. > >> 5. The endpoint uses the (coarse) location value it obtains to = query > LoST. > >> It gets the (correct) PSAP URI > >> 6. This is repeated at call time. The endpoint has a valid LbyR = and a > valid > >> PSAP URI, which it uses to construct the emergency call > >> 7. A VSP wishing to validate the PSAP URI takes the LbyR and > dereferences > >> it. The result will be the same (coarse) location the endpoint = got. > The > >> VSP does a LoST query with that location, and should get the same = PSAP > URI > >> that is in the Request URI on the call. This validation works for > coarse or > >> fine validation, and of course works for LbyV without the = dereference > step. > >> 8. The PSAP (or ESRP) which is the target of the PSAP URI gets the = SIP > message. It > >> dereferences the LbyR but gets the fine grained location; the LIS = must > have > >> a relationship with the ESRP/PSAP to assure this. > >> 9. Any succeeding ESRPs or PSAPs can also dereference and get fine > grained > >> location. > >> > >> > >> > > > > Here are the questions: > > > > 1) Do you think that the problem statement is valid (i.e., the = problem > > that some ASP/ISP do not reveal precise location information for = free, > > for emergency services)? > > 2) Do you think we should investigate the proposed approach in more > detail? > > 3) Do you understand the drawbacks? > > 4) Do you think it is necessary to solicit feedback from VoIP = providers, > > PSAP operators, regulators and network operators on this issue? > > > > Ciao > > Hannes & Marc > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 16:46:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HedWF-0001eX-HL; Thu, 19 Apr 2007 16:46:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HedWE-0001ZM-Em for ecrit@ietf.org; Thu, 19 Apr 2007 16:46:18 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HedWD-0006Fu-68 for ecrit@ietf.org; Thu, 19 Apr 2007 16:46:18 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HedVf-000482-WA; Thu, 19 Apr 2007 15:45:44 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Henning Schulzrinne'" , "'Hannes Tschofenig'" Subject: RE: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial) LocationHiding Emergency Services Architecture Date: Thu, 19 Apr 2007 16:46:11 -0400 Message-ID: <124a01c782c3$c5676630$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceCwVf/EReu4Z89RJWV3NhaKzoMEgAAYGIg In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I dropped geopriv Please look at -phonebcp for the current test procedure. This would add a step. It's not a UI element, it's a protocol exchange. The contents of the media stream may not be subject to standardization, but the mechanism to signal it would be as well as the behavior of the ends. The current procedure specifies a loopback of media. We would need something that opened a one way media stream from the PSAP to the endpoint. It would be a normal SIP thing, but we have to know to do it. Brian > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Thursday, April 19, 2007 4:29 PM > To: Brian Rosen; 'Henning Schulzrinne'; 'Hannes Tschofenig' > Cc: 'GEOPRIV'; 'ECRIT' > Subject: RE: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial) > LocationHiding Emergency Services Architecture > > At 4:18 PM -0400 4/19/07, Brian Rosen wrote: > > > By the way, I think it would be helpful if the framework or phonebcp > >> would recommend that PSAPs read back location information via text-to- > >> speech when test calls are being placed. > >Uh, well, in a form suitable for the media offered in the first place. > That > >may be text, it may be text to sign language. > > > >Brian > > First off, I'm not sure why Geopriv is cc'ed on this message. Isn't what > is > in framework/phonebcp purely an ECRIT matter? > > Second, why are the UI elements of test call responses in scope for an > IETF > document? If I understand this right, we're not talking about the > protocol > elements returned when someone is validating a location prior to making > a call, this is about what happens if someone makes a test call to the > actual > PSAP. How is this within the IETF's scope/knowledge? > > Confused, > Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 16:55:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hedeb-0003Cn-Ht; Thu, 19 Apr 2007 16:54:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hedea-0003Ci-HE for ecrit@ietf.org; Thu, 19 Apr 2007 16:54:56 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HedeZ-0007x4-QL for ecrit@ietf.org; Thu, 19 Apr 2007 16:54:56 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 19 Apr 2007 22:54:54 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 22:54:54 +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 Subject: AW: AW: [Ecrit] Solution Approaches Date: Thu, 19 Apr 2007 22:54:53 +0200 Message-Id: <182C63BFBAF131428EA0C16F7FD2191B013584CC@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <4627BF6F.607@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Ecrit] Solution Approaches thread-index: AceCtuFuGmX5UTFYSuOOoIVE9e6RFAAChA1g From: "Liess, Laura" To: X-OriginalArrivalTime: 19 Apr 2007 20:54:54.0152 (UTC) FILETIME=[FB1CD480:01C782C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 65215b440f7ab00ca9514de4a7a89926 Cc: Richard.Stastny@oefeg.at, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes, I think there is some misunderstanding here. Our planned Emergency = Calling routes only emergency calls from our VoIP and access customers, = so we can authenticate the SIP INVITE. A second reason against ASP/ISP = SIP Proxy is very bad experience with new clients. The first = interoperability tests failed. Probably many emergency calls will not go = through due to interoperability problems.=20 I like very much Henning's idea to return a coarse location to the = client and the fine location to the ESRP/PSAP. I think there is the = unique solution all player can live with.=20 Laura routing for not There is a second reson freanother Another problem with = emergency calls being sent to a SIP Proxy in the access is that in the = real world from our I using an ASP/ISP SIP-Proxy in the the we us the = =20 > -----Urspr=FCngliche Nachricht----- > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Gesendet: Donnerstag, 19. April 2007 21:14 > An: Liess, Laura > Cc: Richard.Stastny@oefeg.at; ecrit@ietf.org > Betreff: Re: AW: [Ecrit] Solution Approaches >=20 >=20 > Hi Laura, >=20 > that's also an option. The problem here is that the PSAP does not get=20 > identity information about the emergency caller since the identity is=20 > unknown to to the access providers if they happen to use a=20 > VSP that is=20 > different from the ISP/ASP. >=20 > In my list of solution approaches I thought that this would be a=20 > problem. Given the complexity we currently discuss I would suggest=20 > people to always go for unauthenticated network access and=20 > use the local=20 > SIP proxy. >=20 > Ciao > Hannes >=20 >=20 >=20 > Liess, Laura wrote: > > Richard, > > > > currently, our own SIP-proxy routes emergency calls comming=20 > from our=20 > > IP-access network to the old PSTN PSAPs. Currently we =20 > don't have or plan neither LOST nor ESRP nor IP PSAPs. We=20 > just assume for Germany national ESRP would be a solution all=20 > main players can live with. > > Laura > > > > =20 > >> -----Urspr=FCngliche Nachricht----- > >> Von: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > >> Gesendet: Mittwoch, 18. April 2007 10:16 > >> An: Liess, Laura; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > >> Betreff: RE: [Ecrit] Solution Approaches > >> > >> > >> Laura, > >> > >> In your proposal, you have one ESRP per country (or state)? > >> > >> Or am I missing something? > >> > >> Richard > >> > >> =20 > >>> -----Original Message----- > >>> From: Liess, Laura [mailto:Laura.Liess@t-systems.com] > >>> Sent: Tuesday, April 17, 2007 5:37 PM > >>> To: Hannes.Tschofenig@gmx.net; ecrit@ietf.org > >>> Subject: AW: [Ecrit] Solution Approaches > >>> > >>> > >>> Hannes, > >>> > >>> thanks a lot for putting the whole discussion together. > >>> > >>> I can not give you a feedback which is agreed within DT > >>> =20 > >> (the internal > >> =20 > >>> agreement process would probably take some time). But I roughly=20 > >>> discussed the approaches with people working on emergency > >>> =20 > >> calling. If > >> =20 > >>> we understood the proposal correctly, we have a strong > >>> =20 > >> preference for > >> =20 > >>> the approach number 8), which could work as follows: > >>> > >>> The ASP/ISP provides to the client the LbyR, the country code (or=20 > >>> country and state codes)and the local EC dial string (at=20 > login and=20 > >>> whenever these data change). The client queries LOST and > >>> =20 > >> gets back an > >> =20 > >>> ESRP URI. When the caller dials the emergency calling number, the=20 > >>> client queries again the ASP/VSP for the LbyR and the > >>> =20 > >> country code and > >> =20 > >>> LOST query for the ESRP URI. The VSP routes the call to the > >>> =20 > >> ESRP. The > >> =20 > >>> ESRP has a shared secret with the LIS, gets the user > >>> =20 > >> location and the > >> =20 > >>> correct PSAP and routes the call with the location info=20 > to the PSAP=20 > >>> (TLS required). (ESRP or a local LOST does load balancing > >>> =20 > >> for PSAPs an > >> =20 > >>> all this stuff). > >>> > >>> Alternatively, the VSPs SIP proxy can do the LOST queries. > >>> > >>> > >>> Laura > >>> > >>> > >>> =20 > >>>> -----Urspr=FCngliche Nachricht----- > >>>> Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>> Gesendet: Dienstag, 17. April 2007 11:12 > >>>> An: ECRIT > >>>> Betreff: [Ecrit] Solution Approaches > >>>> > >>>> > >>>> Hi all, > >>>> > >>>> I would like to share some potential solution approaches > >>>> =20 > >> with you to > >> =20 > >>>> deal with the problem of not providing precise location > >>>> =20 > >> to the end > >> =20 > >>>> host. I had a chance to discuss these aspects with Henning > >>>> face-to-face last Friday. Here is a short summary. > >>>> > >>>> Note that the goal was to avoid some form of relationship (e.g.,=20 > >>>> business relationship) between the VSP and the ASP/ISP > >>>> =20 > >> (since this > >> =20 > >>>> would impose a significant deployment problem). > >>>> > >>>> 1) Provide enough location information so that the=20 > emergency call=20 > >>>> can be routed to the correct PSAP. Precise location information=20 > >>>> would be provided to the PSAP. This approach was already=20 > discussed=20 > >>>> on the list. We need feedback from, > >>>> for example, Barbara and Laura whether they feel comfortable > >>>> with this > >>>> approach. > >>>> > >>>> CONSEQUENCE: No changes needed. > >>>> > >>>> 2) Provide LbyR + Dial String + PSAP URI to the end host. > >>>> =20 > >> We could > >> =20 > >>>> ignore the potential security vulnerabilities if=20 > charging does not > >>>> work on a call-by-call basis. > >>>> > >>>> CONSEQUENCE: No changes needed. > >>>> > >>>> 3) Provide LbyR + Dial String + PSAP URI to the end host. > >>>> =20 > >> VSP does a > >> =20 > >>>> reverse LoST lookup to verify the PSAP URI. > >>>> > >>>> CONSEQUENCE: Solution needs to be developed. > >>>> > >>>> 4) Provide LbyR + Dial String + PSAP URI to the end host. VSP=20 > >>>> verifies the PSAP URI with the PSAP URIs being flooded=20 > (using the=20 > >>>> LoST synchronization mechanism). This mechanism is potentially=20 > >>>> similar to (3) > >>>> -- details might vary. (3) might use a distributed=20 > approach whereas=20 > >>>> this is brute force. > >>>> > >>>> CONSEQUENCE: Solution needs to be developed. > >>>> > >>>> 5) Emergency calls are routed via the SIP proxy of the VSP and=20 > >>>> subsequently via a SIP proxy in the ASP/ISP (redirect mode) SIP=20 > >>>> Location Conveyance would be used instead of GEOPRIV L7 LCP > >>>> Assumption: No service level agreement (or business > >>>> agreement) between > >>>> VSP and ISP/ASP for this type of SIP emergency message routing > >>>> required. > >>>> > >>>> CONSEQUENCE: No changes needed. Potential problems with > >>>> =20 > >> SIP Identity > >> =20 > >>>> possible > >>>> > >>>> 6) Emergency calls are routed via the SIP proxy of the VSP and=20 > >>>> subsequently via a SIP proxy in the ASP/ISP (no redirect > >>>> mode) SIP Location Conveyance would be used instead of GEOPRIV L7 > >>>> LCP > >>>> Assumption: No service level agreement (or business > >>>> agreement) between > >>>> VSP and ISP/ASP for this type of SIP emergency message > >>>> routing required. > >>>> > >>>> CONSEQUENCE: No changes needed. > >>>> > >>>> 7) Decoupled authentication for SIP message routing > >>>> =20 > >> Authentication > >> =20 > >>>> exchange between the end host and the VSP (e.g., TLS to obtain a > >>>> SAML assertion) Authentication credentials are then added to the=20 > >>>> SIP emergency message > >>>> that is routed via the SIP proxy in the VSP/ISP. > >>>> No service level agreement (or business agreement)=20 > between VSP and > >>>> ISP/ASP needed. > >>>> > >>>> CONSEQUENCE: Security extension for this purpose needs to be=20 > >>>> progressed (already available in draft form) > >>>> > >>>> 8) Country Code Routing > >>>> > >>>> LIS provides country code to the end host. The end host > >>>> =20 > >> routes the > >> =20 > >>>> SIP emergency message via the VSP towards a ESRP that > >>>> =20 > >> corresponds to > >> =20 > >>>> the country code. Then, ESRP fetches more detailed location > >>>> information todo routing within the country. > >>>> > >>>> CONSEQUENCE: No changes to the protocol mechanisms.=20 > Deployment of=20 > >>>> ESRPs that work this way are needed. Establishment of ESRP <->=20 > >>>> ISP/ASP is more difficult than with PSAP <-> ISP/ASP since there=20 > >>>> are far more nodes to > >>>> consider. > >>>> > >>>> 9) Assume end hosts have certs for emergency services; > >>>> =20 > >> routing via > >> =20 > >>>> SIP proxy in ISP/ASP without traversing VSP in the=20 > emergency case. > >>>> Existing credential infrastructure can be used when=20 > utilizing SIP=20 > >>>> Cert. > >>>> > >>>> CONSEQUENCE: Architectural aspects need to be developed.=20 > A little=20 > >>>> bit more difficult to deploy for VSP. Potential issues > >>>> =20 > >> with callback > >> =20 > >>>> (to > >>>> AoR) since end host is not registered with VSP. > >>>> > >>>> 10) Routing via SIP proxy in ISP/ASP. Diameter SIP > >>>> =20 > >> application used > >> =20 > >>>> to authenticate end host > >>>> Assumption: No roaming agreement assumed for ISP/ASP <-> > >>>> =20 > >> VSP Diameter > >> =20 > >>>> SIP interaction. > >>>> > >>>> CONSEQUENCE: Problems with legacy credentials, previously > >>>> =20 > >> mentioned > >> =20 > >>>> call back problems since end host is not registered with VSP,=20 > >>>> Diameter SIP application would need to be profiled. > >>>> > >>>> Thoughts? > >>>> > >>>> Ciao > >>>> Hannes > >>>> > >>>> > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit > >>>> > >>>> =20 > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/ecrit > >>> =20 >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 17:05:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HedoQ-0004Ff-No; Thu, 19 Apr 2007 17:05:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HedoQ-0004FW-45; Thu, 19 Apr 2007 17:05:06 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HedoP-00018x-A3; Thu, 19 Apr 2007 17:05:06 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 19 Apr 2007 23:05:02 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 23:05:01 +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 Subject: AW: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto doendpointcentric LCP without giving away the store Date: Thu, 19 Apr 2007 23:05:01 +0200 Message-Id: <182C63BFBAF131428EA0C16F7FD2191B013584CD@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <122301c782af$fc0ee230$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto doendpointcentric LCP without giving away the store thread-index: AceB2jLjCmvef5D7QMe9NoQWMgzx9gAB4mHQACKi+WAAEArp8AAGPNdg From: "Liess, Laura" To: X-OriginalArrivalTime: 19 Apr 2007 21:05:01.0662 (UTC) FILETIME=[65377FE0:01C782C6] X-Spam-Score: 0.0 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd Cc: geopriv@ietf.org, Martin.Dawson@andrew.com, ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, this is for us (DT) the prefered solution and, from the alternatives we = had, the only one we can live with.=20 Laura > -----Urspr=FCngliche Nachricht----- > Von: Brian Rosen [mailto:br@brianrosen.net]=20 > Gesendet: Donnerstag, 19. April 2007 20:25 > An: 'Dawson, Martin'; 'Henning Schulzrinne' > Cc: 'GEOPRIV'; 'ECRIT' > Betreff: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on=20 > howto doendpointcentric LCP without giving away the store >=20 >=20 > Okay, well, discussion has died down now, so I'd like to see=20 > if we have consensus on how we allow access networks to hide=20 > location from endpoints (and VSPs) and yet result in correct=20 > emergency call routing. >=20 > The proposal requires no changes to existing documents (other=20 > than explanations in -framework and -phonebcp). >=20 > It requires no changes in endpoint, VSP, ESRP or PSAP=20 > behavior. It is confined to LIS behavior for LIS' that wish=20 > to hide location. >=20 > It works as follows: >=20 > 1. The endpoint uses an LCP to request location. The LIS=20 > returns an LbyR 2. The endpoint dereferences the LbyR. =20 > 3. The LIS, noticing that the dereference request is from the=20 > endpoint (or at least not from any entity that is entitled to=20 > get fine grained location), takes the fine grained location=20 > and uses LoST to determine the PSAP that serves that=20 > location. 4. The LIS returns to the endpoint a location=20 > which, if submitted to LoST, would return the same PSAP URI=20 > the fine grained location would. In some circumstances, this=20 > could be a civic with only a country. An alternative that=20 > works for all circumstances is to return the polygon that=20 > defines the service boundary of the PSAP (which LoST can=20 > return). Is essential that the PSAP URI returned from a LoST=20 > query with whatever the LIS gives the endpoint would be the=20 > same PSAP URI any querier using the fine grained location=20 > would get. 5. The endpoint uses the (coarse) location value=20 > it obtains to query LoST. It gets the (correct) PSAP URI 6.=20 > This is repeated at call time. The endpoint has a valid LbyR=20 > and a valid PSAP URI, which it uses to construct the=20 > emergency call 7. A VSP wishing to validate the PSAP URI=20 > takes the LbyR and dereferences it. The result will be the=20 > same (coarse) location the endpoint got. The VSP does a LoST=20 > query with that location, and should get the same PSAP URI=20 > that is in the Request URI on the call. This validation=20 > works for coarse or fine validation, and of course works for=20 > LbyV without the dereference step. 8. The PSAP (or ESRP)=20 > which is the target of the PSAP URI gets the call. It=20 > dereferences the LbyR but gets the fine grained location; the=20 > LIS must have a relationship with the ESRP/PSAP to assure=20 > this. 9. Any succeeding ESRPs or PSAPs can also dereference=20 > and get fine grained location. >=20 > Some observations: > a) The LIS probably ought to query LoST with its calculated=20 > coarse location to assure that it gets the same PSAP URI as=20 > the fine grained location. =20 > b) The coarse LoST lookups can be cached. For a given LIS,=20 > there is likely only a few of them > c) The VSP can cache validated PSAP URIs and avoid LoST=20 > lookups in most cases > d) The endpoint could send both the coarse location by value=20 > and the reference, but this would really only help the VSP=20 > because the ESRP/PSAP is going to want to dereference to get=20 > the fine grained location. > e) The LIS can identify ESRPs and PSAPs in a number of ways. =20 > It could use IP address filtering, VPNs, IPSEC tunnels or=20 > other address restrictive mechanisms. It could use TLS=20 > credentials of any form it finds acceptable. It is essential=20 > that the mechanism work for any valid PSAP that could get the=20 > call, and any ESRP that could handle the call, even when=20 > there are failures. =20 >=20 > Now, do we have any objections to making this the answer to=20 > the problem posed? To be clear, I'm asking if you can live=20 > with it, not if you would prefer another one of the proposals=20 > that have been made. >=20 > Brian=20 >=20 > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: Thursday, April 19, 2007 6:25 AM > > To: Brian Rosen; Henning Schulzrinne > > Cc: GEOPRIV; ECRIT > > Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto=20 > > doendpoint centric LCP without giving away the store > >=20 > > Well... I just posted on an alternative thread - about=20 > preferring the=20 > > location request be made at the time of the call - where=20 > Henning seems=20 > > to be taking the position that this is a dangerous additional=20 > > transaction requirement. Yet, here we appear to be=20 > suggesting that a=20 > > location dereference be made to determine coarse routing... > >=20 > > I don't actually object to the additional transaction (per=20 > my previous > > thread) though I will note that the VSP is inherently=20 > "further" from=20 > > the LIS than the device is. It just seems cleaner to me if=20 > the VSP has=20 > > no requirement to interact with the LIS and that, in the case of=20 > > emergency calls, all LIS interactions occur locally -=20 > either from the=20 > > device or jurisdictional entities such as the LoST server,=20 > VPC, and/or=20 > > PSAPs. This also obviates the need for the LIS to=20 > distinguish between=20 > > "allowed" versus "non-allowed" granularity. > >=20 > > Cheers, > > Martin > >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, 19 April 2007 4:02 AM > > To: 'Henning Schulzrinne' > > Cc: 'GEOPRIV'; 'ECRIT' > > Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto=20 > > doendpoint centric LCP without giving away the store > >=20 > > I can live with this way out of the mess. > >=20 > > I rather like the idea of returning the PSAP service=20 > boundary polygon=20 > > on the endpoint's (or VSP's) dereference. The latter (as well as=20 > > coarse location > > when it works) also fixes the validation problem; the VSP=20 > dereferences, > > gets > > the polygon, queries LoST with it, and gets the PSAP URI. > >=20 > > I agree that in lots of cases, a very coarse location=20 > return from the=20 > > LbyR is sufficient, and access networks ought to be able to take=20 > > advantage of it > > when it happens. > >=20 > > I guess we need to hear from carriers. I think you already=20 > raised the=20 > > point that in most cases, an IP address yields city level location,=20 > > albeit VPNs > > often obscure that. > >=20 > > And while you brought it up, I do think a very nice user part of a=20 > > location reference is a hashed telephone number. Most of the DSL=20 > > networks, for example, do have telephone numbers which actually are=20 > > easy to turn into service address in the existing databases. I'd=20 > > prefer it be hashed so that > > we don't reveal extra user information. I particularly=20 > think that idea > > will > > be quite useful in dealing with legacy wireline systems,=20 > which already > > associate TN with location. Adding a (hash of) TN with a=20 > provisioned > > LIS > > domain on a Geolocation header in, or near a PSTN to SIP=20 > gateway would > > be a > > very painless way to get location from a legacy wireline=20 > system into a > > next > > generation emergency call system. > >=20 > > Brian > >=20 > > > -----Original Message----- > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > Sent: Wednesday, April 18, 2007 12:56 PM > > > To: Brian Rosen > > > Cc: 'Hannes Tschofenig'; 'GEOPRIV'; 'ECRIT' > > > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand=20 > compromise on how to=20 > > > doendpoint centric LCP without giving away the store > > > > > > > > > On Apr 18, 2007, at 11:33 AM, Brian Rosen wrote: > > > > > > > I'm not sure I understand what you are saying. > > > > > > > > I'll agree that coarse location may work some times. I=20 > wouldn't=20 > > > > care to speculate how often it does or doesn't. I=20 > don't think it=20 > > > > matters. > > It > > > > > > This seems to be very country-specific. Thus, in some countries,=20 > > > this will be quite viable, in others, less so. > > > > > > For DT, for example, you could have a very simple architecture: > > > > > > - Use normal LCP, returning Gemeinde (city/town), Bundesstaat > > > (state) and country (DE). This is sufficient for determining the=20 > > > PSAP and requires zero interaction with the OSS. > > > > > > - Return an LbyR that is similar to what is used today as an=20 > > > identifier (phone number?), which resolves to the rough=20 > information=20 > > > above. > > > > > > > > > > doesn't sometimes. Does that mean we should misroute in those=20 > > > > cases where you only get coarse location, and you have an=20 > > > > irregular boundary > > that > > > > "misses"? I suspect that would not fly with the access=20 > networks=20 > > > > that have > > > > > > Definitely not. It would be the responsibility of the ISP=20 > to deliver=20 > > > location information of sufficient granularity to prevent=20 > misroutes.=20 > > > In some small number of corner cases (typically, the one boundary=20 > > > street between PSAP regions), this would mean delivering a street=20 > > > address or a geo region. This is easy for the ISP to determine -=20 > > > they just query LoST and get the coverage regions. > > > > > > If you don't want to do this, just return the *geo*=20 > boundary of the=20 > > > PSAP to the customer as location information via LCP, just like=20 > > > you'd return an imprecise mapping from a wireless system, as a=20 > > > polygon. By our mapping rules, LoST computes the centroid=20 > (trivial)=20 > > > and returns the PSAP URL. I think this is somewhat=20 > similar to what=20 > > > Andy is proposing, but requires no new effort. > > > > > > This reveals zero additional information to the client,=20 > beyond the=20 > > > coverage region of the PSAP, but the UA behavior is=20 > exactly the same=20 > > > as in the no-hiding case. > > > > > > > > > > the hiding problem. You are giving them an=20 > unacceptable choice:=20 > > > > give up accurate location to the endpoint or be responsible for=20 > > > > misroute. That may > > > > meet your notion of endpoint simplicity, but it won't=20 > be deployed I > > > > think. > > > > > > I don't see this as the alternative. All I require is=20 > that ISP give=20 > > > up a tiny fraction of its location information in some=20 > corner cases.=20 > > > In most communities, all of the customers will only get=20 > city-level=20 > > > or county-level information, which corresponds to what=20 > their phone=20 > > > number already tells them. > > > > > > I think this is a fair bargain. I'd like to hear good=20 > reasons from=20 > > > real carriers as to why this is not acceptable. Shadow boxing,=20 > > > without talking to real customers, seems likely to lead=20 > us to design=20 > > > something that doesn't actually help. (Just as I believe that the=20 > > > whole architecture proposed doesn't actually address the=20 > > > don't-spend- money objective of DT.) > > > > > > > > > > > > > > You also seem to be willing to accept that the client will have=20 > > > > two locations to deal with: coarse LbyV and fine LbyR. Not a=20 > > > > complication I would want to have to deal with given my=20 > > > > alternative. > > > > > > Not really. I advocate returning a single LbyR, which resolves to=20 > > > minimal information sufficient for routing for the general public=20 > > > and, with PSAP authentication, to precise location=20 > information for=20 > > > dispatch. > > > > > > Henning > > > > > > > > > > > >=20 > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv > >=20 > >=20 > ---------------------------------------------------------------------- > > ---- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > >=20 > -------------------------------------------------------------- > ------------ > > ---------------------- > > [mf2] >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 17:09:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heds8-00082l-LV; Thu, 19 Apr 2007 17:08:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heds7-0007zY-31; Thu, 19 Apr 2007 17:08:55 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heds5-0001bn-Tn; Thu, 19 Apr 2007 17:08:55 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 19 Apr 2007 17:08:53 -0400 id 01588103.4627DA65.000067D5 In-Reply-To: <4627C682.2070604@gmx.net> References: <122301c782af$fc0ee230$640fa8c0@cis.neustar.com> <4627C682.2070604@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6844961F-C498-41D3-AC7D-59D41A2C99BC@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Date: Thu, 19 Apr 2007 17:08:51 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: GEOPRIV , 'ECRIT' Subject: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial) Location Hiding Emergency Services Architecture X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org First, thanks for spelling this out. This sounds more reasonable than all the other solutions. And it touches little while solving the problem. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 17:44:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeeQQ-0004Sz-KB; Thu, 19 Apr 2007 17:44:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeeQO-0004SS-3F for ecrit@ietf.org; Thu, 19 Apr 2007 17:44:20 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeeQL-00085K-Cn for ecrit@ietf.org; Thu, 19 Apr 2007 17:44:20 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3JLi1mS025445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Apr 2007 14:44:02 -0700 Received: from [129.46.226.38] (carbuncle.qualcomm.com [129.46.226.38]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3JLi0Qh004272; Thu, 19 Apr 2007 14:44:01 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <124a01c782c3$c5676630$640fa8c0@cis.neustar.com> References: <124a01c782c3$c5676630$640fa8c0@cis.neustar.com> Date: Thu, 19 Apr 2007 14:43:59 -0700 To: "Brian Rosen" , "'Henning Schulzrinne'" , "'Hannes Tschofenig'" From: Ted Hardie Subject: RE: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial) LocationHiding Emergency Services Architecture Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 4:46 PM -0400 4/19/07, Brian Rosen wrote: >I dropped geopriv > >Please look at -phonebcp for the current test procedure. This would add a >step. So, the proposal is to add this to 9.1. The current version says: INVITE requests to a service urn with a urn parameter of "test" indicates a request for an automated test. For example, "urn:service.sos.fire;test". As in standard SIP, a 200 (OK) response indicates that the address was recognized and a 404 (Not found) that it was not. A 486 (Busy Here) MUST be returned if the test service is busy, and a 488 (Not Acceptable Here) MUST be returned if the PSAP does not support the test mechanism. In its response to the test, the PSAP MAY include a text body indicating the identity of the PSAP, the requested service, and the location reported with the call. For the latter, the PSAP SHOULD return location-by-value even if the original location delivered with the test was by-reference. A PSAP accepting a test call SHOULD accept a media loopback test[I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp-pkt- loopback" and "rtp-start-loopback" options. The user agent would specify a loopback attribute of "loopback-source", the PSAP being the mirror. User Agents should expect the PSAP to loop back no more than 3 packets of each media type accepted, after which the PSAP would normally send BYE. User agents SHOULD perform a full call test, including media loopback, after a disconnect and subsequent change in IP address. After an initial IP address assignment test, a full test SHOULD be repeated approximately every 30 days with a random interval. User agents MUST NOT place a test call immediately after booting, as a widespread power outage and subsequent restoration would impose an inordinate load on the emergency call routing system. PSAPs MAY refuse repeated requests for test from the same device in a short period of time. This seems to me to be a set of tests which would never require the user to be aware that the call was going on. The User Agent would perform this test periodically (with the noted random interval) and would throw an error only if it failed in some unexpected way. That is, I would not expect an error to reach the end user if it said "busy here" or "not acceptable here", since both of those could be normal. But shifting this to something that "reads out" the location in text-to-speech bumps this up to the UI, in my opinion. That is only useful if the user is aware of it and has some way to listen to the read-aloud portion. That's a pretty major change to the functionality, and I don't think it is justified. In the case where location-by-value was used, it just consumes a media stream to read aloud something that is stored on the end device anyway. When the network provided the location, it does return something of value, but in a less-than useful way. The PSAP already MAY return the location accompanying the call. If the end device wants to read that aloud, let it; or let it display it, or whatever. So, I don't think there is any reason to add a one-way media stream from PSAP to the terminal in this, as I think the added burden on the PSAP gets the terminal basically nothing. I have to say, I also find the timing on this: User agents SHOULD perform a full call test, including media loopback, after a disconnect and subsequent change in IP address. After an initial IP address assignment test, a full test SHOULD be repeated approximately every 30 days with a random interval. pretty ridiculous. This would have me test the softphone on my laptop no less than three times in my usual day, as I get IP address changes as I move among networks (home, wireline office, wireless conference room). I think we should recommend a bound on this for mobile or nomadic devices; the alternative will be pretty stressful on the infrastructure for no good reason. Ted >It's not a UI element, it's a protocol exchange. The contents of the media >stream may not be subject to standardization, but the mechanism to signal it >would be as well as the behavior of the ends. The current procedure >specifies a loopback of media. We would need something that opened a one >way media stream from the PSAP to the endpoint. It would be a normal SIP >thing, but we have to know to do it. > >Brian > >> -----Original Message----- >> From: Ted Hardie [mailto:hardie@qualcomm.com] >> Sent: Thursday, April 19, 2007 4:29 PM >> To: Brian Rosen; 'Henning Schulzrinne'; 'Hannes Tschofenig' >> Cc: 'GEOPRIV'; 'ECRIT' >> Subject: RE: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial) >> LocationHiding Emergency Services Architecture >> >> At 4:18 PM -0400 4/19/07, Brian Rosen wrote: >> > > By the way, I think it would be helpful if the framework or phonebcp >> >> would recommend that PSAPs read back location information via text-to- >> >> speech when test calls are being placed. >> >Uh, well, in a form suitable for the media offered in the first place. >> That >> >may be text, it may be text to sign language. >> > >> >Brian >> >> First off, I'm not sure why Geopriv is cc'ed on this message. Isn't what >> is >> in framework/phonebcp purely an ECRIT matter? >> >> Second, why are the UI elements of test call responses in scope for an >> IETF >> document? If I understand this right, we're not talking about the >> protocol >> elements returned when someone is validating a location prior to making >> a call, this is about what happens if someone makes a test call to the >> actual >> PSAP. How is this within the IETF's scope/knowledge? >> >> Confused, >> Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 17:51:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeeXD-0004db-Kc; Thu, 19 Apr 2007 17:51:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeeXD-0004dT-8C; Thu, 19 Apr 2007 17:51:23 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeeXC-00018N-1z; Thu, 19 Apr 2007 17:51:23 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3JLp2Sq007899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 19 Apr 2007 17:51:10 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto doendpoint centric LCP without giving away the store Date: Thu, 19 Apr 2007 17:52:18 -0400 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org We're talking about resolvers, i.e., not the authoritative servers. They can be administered by anybody, including the famous VSP in Sierra Leone that Brian subscribes to. The resolver has no business relationship with the ISP, but needs to dereference the location reference, as it otherwise has no idea what to do next. Thus, I'm afraid that your proposal is not workable given the current LoST architecture and design. Henning On Apr 19, 2007, at 5:39 PM, Dawson, Martin wrote: > Well - I think it's awful but I could live with it. It seems like a > long > winded way to avoid having the LoST server do a dereference. > > Does anyone think that a LoST server for Portugal will be administered > by an entity anywhere other than Portugal? I don't. And in that > case, I > don't see any issue for those jurisdictions that want to apply auth > +auth > on the dereference. The LoST server in such a jurisdiction can > reasonably be expected to be authorised. > > Cheers, > Martin > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 18:00:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heeg0-0004QL-2J; Thu, 19 Apr 2007 18:00:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heefy-0004QG-3G for ecrit@ietf.org; Thu, 19 Apr 2007 18:00:26 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heefw-00034Q-L7 for ecrit@ietf.org; Thu, 19 Apr 2007 18:00:26 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HeefQ-0005uS-Bb; Thu, 19 Apr 2007 16:59:52 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Henning Schulzrinne'" , "'Hannes Tschofenig'" Subject: RE: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial) LocationHiding Emergency Services Architecture Date: Thu, 19 Apr 2007 18:00:20 -0400 Message-ID: <127801c782ce$214a2690$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceCy8d6uTsmQWV4RfaIRxTCK3MrRwAAWHRQ In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think there is value to the read out, but it does change the mechanism from fully automatic to manual at the user side. We could have two test processes. I'll listen to others and move as the consensus dictates. I'm not sure how to address the timing issue you raise. If you DO switch between 3 addresses every day, what IS reasonable advice? At the very least, you could cache IP addresses and reduce the testing when you have the same address. That works in a lot of cases. But, suppose you get a new address every time? What IS the right advice? We could say "any address in the same subnet" is assumed to be the same using the mask, so don't repeat. Brian > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Thursday, April 19, 2007 5:44 PM > To: Brian Rosen; 'Henning Schulzrinne'; 'Hannes Tschofenig' > Cc: 'ECRIT' > Subject: RE: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial) > LocationHiding Emergency Services Architecture > > At 4:46 PM -0400 4/19/07, Brian Rosen wrote: > >I dropped geopriv > > > >Please look at -phonebcp for the current test procedure. This would add > a > >step. > > So, the proposal is to add this to 9.1. The current version says: > > > INVITE requests to a service urn with a urn parameter of "test" > indicates a request for an automated test. For example, > "urn:service.sos.fire;test". As in standard SIP, a 200 (OK) response > indicates that the address was recognized and a 404 (Not found) that > it was not. A 486 (Busy Here) MUST be returned if the test service > is busy, and a 488 (Not Acceptable Here) MUST be returned if the PSAP > does not support the test mechanism. > > In its response to the test, the PSAP MAY include a text body > indicating the identity of the PSAP, the requested service, and the > location reported with the call. For the latter, the PSAP SHOULD > return location-by-value even if the original location delivered with > the test was by-reference. > > A PSAP accepting a test call SHOULD accept a media loopback > test[I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp-pkt- > loopback" and "rtp-start-loopback" options. The user agent would > specify a loopback attribute of "loopback-source", the PSAP being the > mirror. User Agents should expect the PSAP to loop back no more than > 3 packets of each media type accepted, after which the PSAP would > normally send BYE. > > User agents SHOULD perform a full call test, including media > loopback, after a disconnect and subsequent change in IP address. > After an initial IP address assignment test, a full test SHOULD be > repeated approximately every 30 days with a random interval. > > User agents MUST NOT place a test call immediately after booting, as > a widespread power outage and subsequent restoration would impose an > inordinate load on the emergency call routing system. > > PSAPs MAY refuse repeated requests for test from the same device in a > short period of time. > > This seems to me to be a set of tests which would never require > the user to be aware that the call was going on. The User Agent > would perform this test periodically (with the noted random interval) > and would throw an error only if it failed in some unexpected way. > That is, I would not expect an error to reach the end user if it > said "busy here" or "not acceptable here", since both of those could > be normal. > > But shifting this to something that "reads out" the > location in text-to-speech bumps this up to the UI, in my opinion. > That is only useful if the user is aware of it and has some way to listen > to the read-aloud portion. That's a pretty major change to the > functionality, > and I don't think it is justified. In the case where location-by-value > was used, it just consumes a media stream to read aloud something > that is stored on the end device anyway. When the network provided > the location, it does return something of value, but in a less-than > useful way. The PSAP already MAY return the location accompanying > the call. If the end device wants to read that aloud, let it; or let it > display it, or whatever. So, I don't think there is any reason to add > a one-way media stream from PSAP to the terminal in this, as > I think the added burden on the PSAP gets the terminal basically nothing. > > I have to say, I also find the timing on this: > > User agents SHOULD perform a full call test, including media > loopback, after a disconnect and subsequent change in IP address. > After an initial IP address assignment test, a full test SHOULD be > repeated approximately every 30 days with a random interval. > > pretty ridiculous. This would have me test the softphone on my > laptop no less than three times in my usual day, as I get IP > address changes as I move among networks (home, wireline > office, wireless conference room). I think we should recommend > a bound on this for mobile or nomadic devices; the alternative will > be pretty stressful on the infrastructure for no good reason. > > Ted > > > > >It's not a UI element, it's a protocol exchange. The contents of the > media > >stream may not be subject to standardization, but the mechanism to signal > it > >would be as well as the behavior of the ends. The current procedure > >specifies a loopback of media. We would need something that opened a one > >way media stream from the PSAP to the endpoint. It would be a normal SIP > >thing, but we have to know to do it. > > > >Brian > > > >> -----Original Message----- > >> From: Ted Hardie [mailto:hardie@qualcomm.com] > >> Sent: Thursday, April 19, 2007 4:29 PM > >> To: Brian Rosen; 'Henning Schulzrinne'; 'Hannes Tschofenig' > >> Cc: 'GEOPRIV'; 'ECRIT' > >> Subject: RE: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial) > >> LocationHiding Emergency Services Architecture > >> > >> At 4:18 PM -0400 4/19/07, Brian Rosen wrote: > >> > > By the way, I think it would be helpful if the framework or > phonebcp > >> >> would recommend that PSAPs read back location information via text- > to- > >> >> speech when test calls are being placed. > >> >Uh, well, in a form suitable for the media offered in the first place. > >> That > >> >may be text, it may be text to sign language. > >> > > >> >Brian > >> > >> First off, I'm not sure why Geopriv is cc'ed on this message. Isn't > what > >> is > >> in framework/phonebcp purely an ECRIT matter? > >> > >> Second, why are the UI elements of test call responses in scope for an > >> IETF > >> document? If I understand this right, we're not talking about the > >> protocol > >> elements returned when someone is validating a location prior to making > >> a call, this is about what happens if someone makes a test call to the > >> actual > >> PSAP. How is this within the IETF's scope/knowledge? > >> > >> Confused, > >> Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 18:03:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heeis-0000Qn-Mw; Thu, 19 Apr 2007 18:03:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heeiq-0000Lo-36 for ecrit@ietf.org; Thu, 19 Apr 2007 18:03:24 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heeio-0003mB-Rl for ecrit@ietf.org; Thu, 19 Apr 2007 18:03:24 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3JM3IlY024162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 19 Apr 2007 18:03:18 -0400 (EDT) In-Reply-To: References: <124a01c782c3$c5676630$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial) LocationHiding Emergency Services Architecture Date: Thu, 19 Apr 2007 18:04:33 -0400 To: Ted Hardie X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The whole point is that the caller can, if he so desires, verify the location information. Incorrect location information is a major source of mis-routes and false dispatches today (see the NYT article I sent around a few weeks ago). Since location information, even without hiding, can be added by a proxy, this is the only way for the end system to determine what information will be conveyed to the PSAP in all cases. In existing system, finding this out is extremely tedious and burdensome to the PSAP, as you actually have to call 911 to see what address your carrier has registered for you. You really don't want to resolve the "No, I'm not living at 123 Main Street, that's my billing address" during an emergency call. I have no objection to returning this PSAP-seen information in some other way, such as location-conveyance, but I expected to hear screams from the hide-location crowd in that case. Thus, I was trying to find a way that achieves most of the goals, while not stepping on sensitive toes. Since the existing test text includes the return of location information, albeit in a format that is left unspecified (which should be fixed), I'm happy with that. I also have no objection to making this an optional request in the call, so that unattended test calls do not generate this, but I'm not convinced that the complexity is worth it. Thus, I believe that this mechanism adds significantly to the overall reliability of the system and we should encourage that it be provided, whether as location-conveyance, audio or just a PIDF-LO attachment in the 200 OK. (This generally won't work well, given the difficulty real phones have with multipart, but that's a different topic.) Henning On Apr 19, 2007, at 5:43 PM, Ted Hardie wrote: > At 4:46 PM -0400 4/19/07, Brian Rosen wrote: >> I dropped geopriv >> >> Please look at -phonebcp for the current test procedure. This >> would add a >> step. > > So, the proposal is to add this to 9.1. The current version says: > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 18:26:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hef5D-0006Rs-F0; Thu, 19 Apr 2007 18:26:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hef5C-0006PU-6J for ecrit@ietf.org; Thu, 19 Apr 2007 18:26:30 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hef5B-0000GX-Nl for ecrit@ietf.org; Thu, 19 Apr 2007 18:26:30 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3JMPHdu027497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Apr 2007 15:25:17 -0700 Received: from [129.46.226.38] (carbuncle.qualcomm.com [129.46.226.38]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3JMPFaY011240; Thu, 19 Apr 2007 15:25:16 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <124a01c782c3$c5676630$640fa8c0@cis.neustar.com> Date: Thu, 19 Apr 2007 15:25:14 -0700 To: Henning Schulzrinne From: Ted Hardie Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial) LocationHiding Emergency Services Architecture Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 6:04 PM -0400 4/19/07, Henning Schulzrinne wrote: >The whole point is that the caller can, if he so desires, verify the location information. Incorrect location information is a major source of mis-routes and false dispatches today (see the NYT article I sent around a few weeks ago). > >Since location information, even without hiding, can be added by a proxy, this is the only way for the end system to determine what information will be conveyed to the PSAP in all cases. In existing system, finding this out is extremely tedious and burdensome to the PSAP, as you actually have to call 911 to see what address your carrier has registered for you. You really don't want to resolve the "No, I'm not living at 123 Main Street, that's my billing address" during an emergency call. Do you believe, then, that the user has to be aware of the test call, and responsive during it? That's very different from the way the BCP seems to be written now, and I suspect there are some pretty scaly dragons there. If, at a random interval, the phone rings and reports on the status of a pseudo-911 call, I think users are going to be surprised and may be alarmed. I'd rather leave it as something where the phone confirms that the test works and stores the outcome, so that a user may review it and make corrections if needed. But that means storing time and date along with the test call info (imagine someone saying, "I'm at 3 Wall Street, and this thing believes I'm at JFK" where it really meant that the most recent test call was when the user was at the airport). >I have no objection to returning this PSAP-seen information in some other way, such as location-conveyance, but I expected to hear screams from the hide-location crowd in that case. Thus, I was trying to find a way that achieves most of the goals, while not stepping on sensitive toes. Since the existing test text includes the return of location information, albeit in a format that is left unspecified (which should be fixed), I'm happy with that. I agree that the format should be specified. I believe that returning it in a text body, as 9.1 already allows the end system to determine the best way to present it to the end user, if it desires to do so. I think the media stream is a less-optimal and heavier weight mechanism for accomplishing that. >I also have no objection to making this an optional request in the call, so that unattended test calls do not generate this, but I'm not convinced that the complexity is worth it. I think we should assume that the typical test call will be unattended. How far off the consensus am I on that? >Thus, I believe that this mechanism adds significantly to the overall reliability of the system and we should encourage that it be provided, whether as location-conveyance, audio or just a PIDF-LO attachment in the 200 OK. (This generally won't work well, given the difficulty real phones have with multipart, but that's a different topic.) I think incorporating it into the response to the 200 OK is the best way forward, and that making it part of the text actually relieves some of the location hiding concerns (since the information would need to be scraped from there into other applications). Ted >Henning > >On Apr 19, 2007, at 5:43 PM, Ted Hardie wrote: > >>At 4:46 PM -0400 4/19/07, Brian Rosen wrote: >>>I dropped geopriv >>> >>>Please look at -phonebcp for the current test procedure. This would add a >>>step. >> >>So, the proposal is to add this to 9.1. The current version says: _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 19:42:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HegGg-0000CP-CQ; Thu, 19 Apr 2007 19:42:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HegGf-0000CK-DA for ecrit@ietf.org; Thu, 19 Apr 2007 19:42:25 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HegGd-00022F-Uv for ecrit@ietf.org; Thu, 19 Apr 2007 19:42:25 -0400 Received: from [192.168.0.48] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3JNgCeq023497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 19 Apr 2007 19:42:12 -0400 (EDT) In-Reply-To: References: <124a01c782c3$c5676630$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9A60EA48-FABA-41CA-B1EC-27FCF15F7F6C@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial) LocationHiding Emergency Services Architecture Date: Thu, 19 Apr 2007 19:42:12 -0400 To: Ted Hardie X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > Based on my experience, there are two kinds of test calls: - automatic: done to verify NAT operation, LoST lookups and such; nothing is reported unless there's a problem; done fairly regularly when network conditions change; no human interaction. - manual: explicitly invoked by the user; for example, done when moving into a new house. There is no ringback or anything else - the user picks up the phone, clicks on the "test emergency call" link and gets information back, similar to the test numbers that regular phone service has (including such numbers as 1 700 555.4141 [http:// www.cs.columbia.edu/~hgs/internet/telephone.html]). For example, when we installed our new departmental PBX, we wanted to make sure 911 worked and delivered the right number and location to the PSAP. We had to call the "real" 911, which our sys admin did with great trepidation. > Do you believe, then, that the user has to be aware of the test > call, and responsive > during it? That's very different from the way the BCP seems to be > written now, > and I suspect there are some pretty scaly dragons there. If, at a > random interval, > the phone rings and reports on the status of a pseudo-911 call, I > think users > are going to be surprised and may be alarmed. I'd rather leave it > as something > where the phone confirms that the test works and stores the > outcome, so that a > user may review it and make corrections if needed. But that means > storing > time and date along with the test call info (imagine someone saying, > "I'm at 3 Wall Street, and this thing believes I'm at JFK" where it > really meant > that the most recent test call was when the user was at the airport). > > > I think we should assume that the typical test call will be > unattended. How > far off the consensus am I on that? > See above; we need both. >> Thus, I believe that this mechanism adds significantly to the >> overall reliability of the system and we should encourage that it >> be provided, whether as location-conveyance, audio or just a PIDF- >> LO attachment in the 200 OK. (This generally won't work well, >> given the difficulty real phones have with multipart, but that's a >> different topic.) > > I think incorporating it into the response to the 200 OK is the > best way forward, > and that making it part of the text actually relieves some of the > location hiding > concerns (since the information would need to be scraped from there > into other > applications). I don't know what you have in mind. I'm sure you are not proposing to put it as 200 OK (123 Main Street) Putting it in plain text as a body (text/plain) isn't likely to deter scraping unless it is so obfuscated that it confuses humans, too. Plus, you lose the ability to know which elements are actually populated, so that a correct-looking address is actually unusable for routing or dispatch. For example, showing Room 123 456 Corporate Plaza Anytown CA 01234 can still have "Room 123" show up in the street address field in PIDF- LO, even though the text "looks" ok. Plus, text isn't too useful for an ATA (terminal adapter) device. It can't show the text, since it has no display. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 19 20:04:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HegcA-0005wl-KG; Thu, 19 Apr 2007 20:04:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hegc9-0005wd-Nf; Thu, 19 Apr 2007 20:04:37 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hegc5-0005fq-Fd; Thu, 19 Apr 2007 20:04:37 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3K04TGr010498 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 19 Apr 2007 20:04:30 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto doendpoint centric LCP without giving away the store Date: Thu, 19 Apr 2007 20:04:27 -0400 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 19, 2007, at 6:17 PM, Dawson, Martin wrote: > OK I see... > > If we're talking about VSPs (which I didn't think were necessary for > ECRIT) then I agree. However, that's the same challenge that i2 has - > except it's not just a routing question, it has to go to the right VPC > so the PSAP can get the location information from it out of band. As per our definitions, VSPs could be something like a corporation or university campus, not necessarily an operator such as SunRocket, Verizon or Vonage. As noted before, a LoST server could also be operated by an independent party, just like STUN servers are today (e.g., http://www.stunserver.org/). > > If this is the only scenario we are talking about, then I still think > there are less convoluted solutions from the perspective of the > device. > > How about the "resolver" does a dereference and the LIS, realizing > it's > not an authorized requestor, just returns a country code. Or there may That's roughly what happens in the proposal, except that the query is done by the UA. But that doesn't solve the problem of finding the right PSAP and doesn't seem to change the problems leading to the currently-proposed solution. > actually be standard HTTP (for example) error constructs that would > provide the equivalent information. Or, as I tentatively suggested, a > convention for the URL construction could indicate the jurisdiction > - or > the LIS request could include a URL and a bare bones PIDF-LO (both of > which eliminate the additional transaction altogether). I don't think > any of those proposals require changes to existing specifications > either > (apart from LoST doing the dereference). My general perception is that encoding information into URLs (not URNs) is considered a hack, as they are supposed to be opaque to the HTTP client. > > Anyway, my response stands. I could live with the solution but it > feels > unnecessarily convoluted. > > Cheers, > Martin > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 04:56:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heouj-0005WQ-4M; Fri, 20 Apr 2007 04:56:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeouD-0004sl-5o for ecrit@ietf.org; Fri, 20 Apr 2007 04:55:49 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Heooc-0000kT-7E for ecrit@ietf.org; Fri, 20 Apr 2007 04:50:02 -0400 Received: (qmail invoked by alias); 20 Apr 2007 08:50:01 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp040) with SMTP; 20 Apr 2007 10:50:01 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18KFwcfrJwKX3fXDLpt146y+v1cmtc1oZdWD20jMa pTA7Clw7M69g+l Message-ID: <46287EB9.7060006@gmx.net> Date: Fri, 20 Apr 2007 10:50:01 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) 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-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Ecrit] Consensus Call: Precise Location Information not available to End Host X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, let me try it again (I got it wrong in my previous mail). Henning and Brian suggested an approach that * works nicely with the emergency services architecture we investigated over the past few years, and * addresses the case where a network operator does not want to disclose precise location information. Here is the procedure: 1. The endpoint uses an LCP to request location. The LIS returns an LbyR 2. The endpoint dereferences the LbyR. 3. The LIS, noticing that the dereference request is from the endpoint (or at least not from any entity that is entitled to get fine grained location), takes the fine grained location and uses LoST to determine the PSAP that serves that location. 4. The LIS returns to the endpoint a location which, if submitted to LoST, would return the same PSAP URI the fine grained location would. In some circumstances, this could be a civic with only a country. An alternative that works for all circumstances is to return the polygon that defines the service boundary of the PSAP (which LoST can return). Is essential that the PSAP URI returned from a LoST query with whatever the LIS gives the endpoint would be the same PSAP URI any querier using the fine grained location would get. 5. The endpoint uses the (coarse) location value it obtains to query LoST. It gets the (correct) PSAP URI 6. This is repeated at call time. The endpoint has a valid LbyR and a valid PSAP URI, which it uses to construct the emergency call 7. A VSP wishing to validate the PSAP URI takes the LbyR and dereferences it. The result will be the same (coarse) location the endpoint got. The VSP does a LoST query with that location, and should get the same PSAP URI that is in the Request URI on the call. This validation works for coarse or fine validation, and of course works for LbyV without the dereference step. 8. The PSAP (or ESRP) which is the target of the PSAP URI gets the call. It dereferences the LbyR but gets the fine grained location; the LIS must have a relationship with the ESRP/PSAP to assure this. 9. Any succeeding ESRPs or PSAPs can also dereference and get fine grained location. QUESTION: Is this approach acceptable for you? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 06:32:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeqPH-0005oc-4I; Fri, 20 Apr 2007 06:31:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeqPF-0005no-KP for ecrit@ietf.org; Fri, 20 Apr 2007 06:31:57 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeqPF-0005xF-5T for ecrit@ietf.org; Fri, 20 Apr 2007 06:31:57 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Fri, 20 Apr 2007 12:31:56 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 12:31:55 +0200 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 Subject: AW: [Ecrit] Consensus Call: Precise Location Information not available to End Host Date: Fri, 20 Apr 2007 12:31:54 +0200 Message-Id: <182C63BFBAF131428EA0C16F7FD2191B013584D1@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <46287EB9.7060006@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Consensus Call: Precise Location Information not available to End Host thread-index: AceDKcuT9TDqAd+1Q+Kwo4ajFBFvbwABGhqw From: "Liess, Laura" To: , X-OriginalArrivalTime: 20 Apr 2007 10:31:55.0581 (UTC) FILETIME=[1E2946D0:01C78337] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org =20 Hi, > Here is the procedure: >=20 > 1. The endpoint uses an LCP to request location. The LIS > returns an LbyR 2. The endpoint dereferences the LbyR. =20 > 3. The LIS, noticing that the dereference request is from the=20 > endpoint (or at least not from any entity that is entitled to=20 > get fine grained location), takes the fine grained location=20 > and uses LoST to determine the PSAP that serves that=20 > location. 4. The LIS returns to the endpoint a location=20 > which, if submitted to LoST, would return the the same PSAP URI=20 > the fine grained location would or . In some circumstances, this=20 > could be a civic with only a country. An alternative that=20 > works for all circumstances is to return the polygon that=20 > defines the service boundary of the PSAP (which LoST can=20 > return). Is essential that the PSAP URI returned from a LoST=20 > query with whatever the LIS gives the endpoint would be the=20 > same PSAP URI any querier using the fine grained location=20 > would get. 5. The endpoint uses the (coarse) location value=20 > it obtains to query LoST. It gets the (correct) PSAP URI 6.=20 Does this mean that if for a country the LOST directory has an entry DE resolving to an ESRP_DE, more fine grained LOST entries as Frankfurt either a)must resolve to the same ESRP_DE as the DE entry or b)if the Frankfurt entry resolves to a local PSAP-_Frankfurt every ASP/ISP MUST return for locations in Frankfurt the local PSAP_Frankfurt or c) there are no more fine grained entries?=20 Or did I miss something?=20 Thanks a lot Laura =20 > This is repeated at call time. The endpoint has a valid LbyR > and a valid PSAP URI, which it uses to construct the=20 > emergency call 7. A VSP wishing to validate the PSAP URI=20 > takes the LbyR and dereferences it. The result will be the=20 > same (coarse) location the endpoint got. The VSP does a LoST=20 > query with that location, and should get the same PSAP URI=20 > that is in the Request URI on the call. This validation=20 > works for coarse or fine validation, and of course works for=20 > LbyV without the dereference step. 8. The PSAP (or ESRP)=20 > which is the target of the PSAP URI gets the call. It=20 > dereferences the LbyR but gets the fine grained location; the=20 > LIS must have a relationship with the ESRP/PSAP to assure=20 > this. 9. Any succeeding ESRPs or PSAPs can also dereference=20 > and get fine grained location. >=20 > QUESTION: Is this approach acceptable for you? >=20 > Ciao > Hannes >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 07:44:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HerXk-0003k5-RE; Fri, 20 Apr 2007 07:44:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HerXj-0003jy-Pv for ecrit@ietf.org; Fri, 20 Apr 2007 07:44:47 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HerXi-0000DW-HF for ecrit@ietf.org; Fri, 20 Apr 2007 07:44:47 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HerX3-0004KT-Sk; Fri, 20 Apr 2007 06:44:06 -0500 From: "Brian Rosen" To: "'Liess, Laura'" , , Subject: RE: [Ecrit] Consensus Call: Precise Location Information notavailable to End Host Date: Fri, 20 Apr 2007 07:44:39 -0400 Message-ID: <135d01c78341$4a882de0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceDKcuT9TDqAd+1Q+Kwo4ajFBFvbwABGhqwAARakuA= In-Reply-To: <182C63BFBAF131428EA0C16F7FD2191B013584D1@S4DE8PSAAGM.mitte.t-com.de> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > Does this mean that if for a country the LOST directory has an entry DE > resolving to an ESRP_DE, more fine grained LOST entries as Frankfurt > either a)must resolve to the same ESRP_DE as the DE entry or b)if the > Frankfurt entry resolves to a local PSAP-_Frankfurt every ASP/ISP MUST > return for locations in Frankfurt the local PSAP_Frankfurt or c) there > are no more fine grained entries? I'm not really sure I understand your question, but let me tell you how I think this will work in North America: There will be state level ESRPs (we won't be able to have a national ESRP, and we probably wouldn't want one anyway). All calls in New Jersey would go to the New Jersey ESRP. The LoST entries for every location in New Jersey will have the New Jersey ESRP as the URI. The New Jersey ESRP will have another service, which will only be available inside the Emergency Services IP Network, and thus to any ESRP or PSAP in New Jersey, which supplies the URI of the actual PSAP that gets the call. The ESRP will make a LoST query with that service to route the call onward. That same mechanism will be used by the PSAP to query for the responder agencies (police, fire, ems). A regular LoST query to urn:service:sos.police would return the New Jersey ESRP. In some areas, there will be a second level of ESRP, perhaps at the county level. The state ESRP will route to the county ESRP, the county ESRP will route to PSAP. This means that the LIS will effectively reveal the state the caller is in, but not the city, since the service boundary returned by LoST for urn:service:sos would be the state boundary. Of course in a smaller country, you may have a country level ESRP. Does that answer your question? If it does not, perhaps you could explain what you mean more fully. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 08:18:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hes3v-00066Z-Hw; Fri, 20 Apr 2007 08:18:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hes3t-00065Y-DP for ecrit@ietf.org; Fri, 20 Apr 2007 08:18:01 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hes3r-00035e-Qt for ecrit@ietf.org; Fri, 20 Apr 2007 08:18:01 -0400 Received: from ([139.76.131.79]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.175499884; Fri, 20 Apr 2007 08:17:43 -0400 Received: from 01AL10015010627.AD.BLS.COM ([90.152.44.196]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 20 Apr 2007 08:17:42 -0400 Received: from 01AL10015010647.AD.BLS.COM ([90.152.44.147]) by 01AL10015010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 20 Apr 2007 07:17:42 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Apr 2007 07:17:42 -0500 Message-ID: <6FEBBDAA0B74D34E806D366A431F36B7030F3F0C@brexc47p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Please remove my name -UNSUBSCRIBE thread-index: AceDReX5hjUxA6hEQcKL4hZSV7WQWA== From: "Beyer, Loraine" To: X-OriginalArrivalTime: 20 Apr 2007 12:17:42.0412 (UTC) FILETIME=[E52AD4C0:01C78345] X-Spam-Score: 0.3 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [Ecrit] Please remove my name -UNSUBSCRIBE X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1070001054==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1070001054== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78345.E5482595" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78345.E5482595 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Loraine Beyer Thank you ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA621 ------_=_NextPart_001_01C78345.E5482595 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please remove my name -UNSUBSCRIBE

Loraine Beyer


Thank you

*****

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

 ------_=_NextPart_001_01C78345.E5482595-- --===============1070001054== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1070001054==-- From ecrit-bounces@ietf.org Fri Apr 20 10:09:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heto4-0001Z6-Bf; Fri, 20 Apr 2007 10:09:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heto2-0001Ys-W7; Fri, 20 Apr 2007 10:09:47 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Heto1-0006Bz-95; Fri, 20 Apr 2007 10:09:46 -0400 Received: from ([139.76.131.79]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.20585668; Fri, 20 Apr 2007 10:09:20 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 20 Apr 2007 10:09:19 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 20 Apr 2007 10:09:19 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial)LocationHiding Emergency Services Architecture Date: Fri, 20 Apr 2007 10:09:18 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA03B0F89C@crexc41p> In-Reply-To: <123f01c782bf$ec69f580$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial)LocationHiding Emergency Services Architecture thread-index: AceCvCnLU7nGzWyDSsKyP3L5NFaA1QAA5NkAACTCWmA= References: <4C22645C-BFA9-4C72-A4B7-D7A569D45269@cs.columbia.edu> <123f01c782bf$ec69f580$640fa8c0@cis.neustar.com> From: "Stark, Barbara" To: "Brian Rosen" , "Henning Schulzrinne" , "Hannes Tschofenig" X-OriginalArrivalTime: 20 Apr 2007 14:09:19.0298 (UTC) FILETIME=[7CD28A20:01C78355] X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I see this as an attempt to get around the access provider's "hiding". I can see people using the PSAP test call now as not only a means of testing whether an unauthenticated phone works, but as a tool to figure out their location, if the access provider won't give it to them.=20 I'm against this recommendation. But I won't fight hard, since the recommendation has no teeth. I should point out, though, that phonebcp currently only describes the UA doing automated testing, and not providing a user interface to support user-initiated testing. And support of media (above and beyond SIP signaling) appears to only be a "SHOULD". In my phonebcp comments, I did object to the recommendation that PSAPs respond with the location value in their SIP response, if a reference were sent in the request. But again, I won't argue hard. This will ultimately be a matter of local or national policy, independent of the IETF attempts to impact such policy. Barbara -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Thursday, April 19, 2007 4:19 PM To: 'Henning Schulzrinne'; 'Hannes Tschofenig' Cc: 'GEOPRIV'; 'ECRIT' Subject: RE: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial)LocationHiding Emergency Services Architecture > By the way, I think it would be helpful if the framework or phonebcp=20 > would recommend that PSAPs read back location information via text-to- > speech when test calls are being placed. Uh, well, in a form suitable for the media offered in the first place. That may be text, it may be text to sign language. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA621 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 10:36:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeuEE-0004o4-Lw; Fri, 20 Apr 2007 10:36:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeuED-0004jL-1t for ecrit@ietf.org; Fri, 20 Apr 2007 10:36:49 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeuEB-0003so-JT for ecrit@ietf.org; Fri, 20 Apr 2007 10:36:49 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Fri, 20 Apr 2007 16:36:46 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 16:36:46 +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 Subject: AW: [Ecrit] Consensus Call: Precise Location Information notavailable to End Host Date: Fri, 20 Apr 2007 16:36:46 +0200 Message-Id: <182C63BFBAF131428EA0C16F7FD2191B013584D4@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <135d01c78341$4a882de0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Consensus Call: Precise Location Information notavailable to End Host thread-index: AceDKcuT9TDqAd+1Q+Kwo4ajFBFvbwABGhqwAARakuAABkT4sA== From: "Liess, Laura" To: , , X-OriginalArrivalTime: 20 Apr 2007 14:36:46.0335 (UTC) FILETIME=[528870F0:01C78359] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, yes, that answers my question and I am OK with this approach.=20 Thanks a lot Laura =20 > -----Urspr=FCngliche Nachricht----- > Von: Brian Rosen [mailto:br@brianrosen.net]=20 > Gesendet: Freitag, 20. April 2007 13:45 > An: Liess, Laura; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > Betreff: RE: [Ecrit] Consensus Call: Precise Location=20 > Information notavailable to End Host >=20 >=20 > > Does this mean that if for a country the LOST directory has=20 > an entry=20 > > DE resolving to an ESRP_DE, more fine grained LOST entries as=20 > > Frankfurt either a)must resolve to the same ESRP_DE as the=20 > DE entry=20 > > or b)if the Frankfurt entry resolves to a local=20 > PSAP-_Frankfurt every=20 > > ASP/ISP MUST return for locations in Frankfurt the local=20 > > PSAP_Frankfurt or c) there are no more fine grained entries? >=20 > I'm not really sure I understand your question, but let me=20 > tell you how I think this will work in North America: >=20 > There will be state level ESRPs (we won't be able to have a=20 > national ESRP, and we probably wouldn't want one anyway). =20 > All calls in New Jersey would go to the New Jersey ESRP. The=20 > LoST entries for every location in New Jersey will have the=20 > New Jersey ESRP as the URI. >=20 > The New Jersey ESRP will have another service, which will=20 > only be available inside the Emergency Services IP Network,=20 > and thus to any ESRP or PSAP in New Jersey, which supplies=20 > the URI of the actual PSAP that gets the call. The ESRP will=20 > make a LoST query with that service to route the call onward.=20 > That same mechanism will be used by the PSAP to query for the=20 > responder agencies (police, fire, ems). A regular LoST query=20 > to urn:service:sos.police would return the New Jersey ESRP.=20 >=20 > In some areas, there will be a second level of ESRP, perhaps=20 > at the county level. The state ESRP will route to the county=20 > ESRP, the county ESRP will route to PSAP. >=20 > This means that the LIS will effectively reveal the state the=20 > caller is in, but not the city, since the service boundary=20 > returned by LoST for urn:service:sos would be the state=20 > boundary. Of course in a smaller country, you may have a=20 > country level ESRP. >=20 > Does that answer your question? If it does not, perhaps you=20 > could explain what you mean more fully. >=20 > Brian >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 10:57:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeuXu-0005q5-JT; Fri, 20 Apr 2007 10:57:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeuXt-0005pv-Tm; Fri, 20 Apr 2007 10:57:09 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeuXs-0000WJ-Ml; Fri, 20 Apr 2007 10:57:09 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3KEuxMq014144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Apr 2007 10:57:00 -0400 (EDT) In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA03B0F89C@crexc41p> References: <4C22645C-BFA9-4C72-A4B7-D7A569D45269@cs.columbia.edu> <123f01c782bf$ec69f580$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA03B0F89C@crexc41p> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial)LocationHiding Emergency Services Architecture Date: Fri, 20 Apr 2007 10:58:17 -0400 To: "Stark, Barbara" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The IETF specs are mainly directed towards implementors and mainly read by them. Implementors need to be aware of the data coming back from a test call, so they MUST implement the necessary functionality. It is up to the regulator, as you hint at, whether to allow or force the PSAP to return the information. I see nothing wrong with documenting, however, operational considerations that indicate that this is a good thing for the customer, as it allows verification. It is then up to the lobbyists of the telcos to convince the regulators that their business interests trump the public safety interests; it's not the role of the IETF to hide our technical opinion simply because it's inconvenient to the lobbyists. Henning On Apr 20, 2007, at 10:09 AM, Stark, Barbara wrote: > I see this as an attempt to get around the access provider's > "hiding". I > can see people using the PSAP test call now as not only a means of > testing whether an unauthenticated phone works, but as a tool to > figure > out their location, if the access provider won't give it to them. > > I'm against this recommendation. But I won't fight hard, since the > recommendation has no teeth. > > I should point out, though, that phonebcp currently only describes the > UA doing automated testing, and not providing a user interface to > support user-initiated testing. And support of media (above and beyond > SIP signaling) appears to only be a "SHOULD". In my phonebcp > comments, I > did object to the recommendation that PSAPs respond with the location > value in their SIP response, if a reference were sent in the request. > But again, I won't argue hard. This will ultimately be a matter of > local > or national policy, independent of the IETF attempts to impact such > policy. > Barbara > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 11:16:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeuqH-0008Gx-9Q; Fri, 20 Apr 2007 11:16:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeuqG-0008Gs-70 for ecrit@ietf.org; Fri, 20 Apr 2007 11:16:08 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeuqF-0005yD-1I for ecrit@ietf.org; Fri, 20 Apr 2007 11:16:08 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 20 Apr 2007 11:16:06 -0400 id 01588370.4628D936.000052FD In-Reply-To: <46287EB9.7060006@gmx.net> References: <46287EB9.7060006@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host Date: Fri, 20 Apr 2007 11:16:04 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 20, 2007, at 4:50 AM, Hannes Tschofenig wrote: > QUESTION: Is this approach acceptable for you? I'm not sure you want us to chime in again, but yes. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 11:22:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeuwA-00079f-Ki; Fri, 20 Apr 2007 11:22:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heuw9-00079a-Ov for ecrit@ietf.org; Fri, 20 Apr 2007 11:22:13 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heuw9-00078r-5o for ecrit@ietf.org; Fri, 20 Apr 2007 11:22:13 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Heuw8-0006dI-4w; Fri, 20 Apr 2007 11:22:12 -0400 Received: from [127.0.0.1] (col-dhcp33-244-171.bbn.com [128.33.244.171]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l3KFMBw23305; Fri, 20 Apr 2007 11:22:11 -0400 (EDT) Message-ID: <4628DAA2.5030605@bbn.com> Date: Fri, 20 Apr 2007 11:22:10 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host References: <46287EB9.7060006@gmx.net> In-Reply-To: <46287EB9.7060006@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes, I haven't had time to keep up with the hailstorm of discussion, but I have a several concerns about this approach: 1. Confusion over location semantics This approach has two different types of location objects (LbyV) -- one that describes the actual location of the endpoint, and one that guides the LoST query. This makes me worry about the two getting mixed up: E.g., LIS provides not a service boundary (too big) but an arbitrary point within the service boundary, and PSAP routes first responders to that point. Even requiring that the LIS always provide a service boundary isn't enough, since the party that consumes the LO has no way to know that it's a service boundary and not an estimate of the hosts location. So there needs to be some explicit syntax here to differentiate these two cases (e.g., a "service-boundary" tag on the LO or on the Geolocation header, or a Service-area: SIP header). 2. Assumptions about the LIS (privacy concerns) This approach assumes that the LIS is willing to give out any location information at all to unauthenticated/unauthorized parties (e.g., the client and the VSP). I think this is a big assumption: Since a VSP can be any host on the Internet (from the LIS's perspective), this approach requires the LIS to give information on a client's location to anyone on the internet, a massive privacy risk. Moreover, if a client runs into a LIS that doesn't give out course location (for whatever reason), then it's out of luck -- it has no idea where to turn for help. 3. Mixing of LoST and Location Dereference This approach requires the LIS to do a LoST query with only location -- without any knowledge of what service is desired. For example: Even if it queries for all available services, it could get back different service areas for each -- which service area should it return to the client? It can't return the union (that would lead to LoST mis-routes), and returning the intersection adds to the granularity of the location provided. So, I guess in summary, > QUESTION: Is this approach acceptable for you? No. --Richard Hannes Tschofenig wrote: > Hi all, > let me try it again (I got it wrong in my previous mail). > Henning and Brian suggested an approach that * works nicely with the > emergency services architecture we > investigated over the past few years, and > * addresses the case where a network operator does not want to disclose > precise location information. > Here is the procedure: > > 1. The endpoint uses an LCP to request location. The LIS returns an LbyR > 2. The endpoint dereferences the LbyR. 3. The LIS, noticing that the > dereference request is from the endpoint (or > at least not from any entity that is entitled to get fine grained > location), > takes the fine grained location and uses LoST to determine the PSAP that > serves that location. > 4. The LIS returns to the endpoint a location which, if submitted to LoST, > would return the same PSAP URI the fine grained location would. In some > circumstances, this could be a civic with only a country. An alternative > that works for all circumstances is to return the polygon that defines the > service boundary of the PSAP (which LoST can return). Is essential that > the > PSAP URI returned from a LoST query with whatever the LIS gives the > endpoint > would be the same PSAP URI any querier using the fine grained location > would > get. > 5. The endpoint uses the (coarse) location value it obtains to query LoST. > It gets the (correct) PSAP URI > 6. This is repeated at call time. The endpoint has a valid LbyR and a > valid > PSAP URI, which it uses to construct the emergency call > 7. A VSP wishing to validate the PSAP URI takes the LbyR and dereferences > it. The result will be the same (coarse) location the endpoint got. The > VSP does a LoST query with that location, and should get the same PSAP URI > that is in the Request URI on the call. This validation works for > coarse or > fine validation, and of course works for LbyV without the dereference step. > 8. The PSAP (or ESRP) which is the target of the PSAP URI gets the > call. It > dereferences the LbyR but gets the fine grained location; the LIS must have > a relationship with the ESRP/PSAP to assure this. > 9. Any succeeding ESRPs or PSAPs can also dereference and get fine grained > location. > > Ciao > Hannes > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 11:35:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hev9I-00019T-Bj; Fri, 20 Apr 2007 11:35:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hev9G-00019O-Jv for ecrit@ietf.org; Fri, 20 Apr 2007 11:35:46 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hev9F-0001do-BR for ecrit@ietf.org; Fri, 20 Apr 2007 11:35:46 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3KFZYPU009256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Apr 2007 11:35:34 -0400 (EDT) In-Reply-To: <4628DAA2.5030605@bbn.com> References: <46287EB9.7060006@gmx.net> <4628DAA2.5030605@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host Date: Fri, 20 Apr 2007 11:36:52 -0400 To: Richard Barnes X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 20, 2007, at 11:22 AM, Richard Barnes wrote: > Hannes, > > I haven't had time to keep up with the hailstorm of discussion, but > I have a several concerns about this approach: > > 1. Confusion over location semantics > This approach has two different types of location objects (LbyV) -- > one that describes the actual location of the endpoint, and one > that guides the LoST query. This makes me worry about the two > getting mixed up: E.g., LIS provides not a service boundary (too > big) but an arbitrary point within the service boundary, and PSAP > routes first responders to that point. Even requiring that the LIS > always provide a service boundary isn't enough, since the party > that consumes the LO has no way to know that it's a service > boundary and not an estimate of the hosts location. So there needs > to be some explicit syntax here to differentiate these two cases > (e.g., a "service-boundary" tag on the LO or on the Geolocation > header, or a Service-area: SIP header). This doesn't seem fundamentally different from having a wireless provider provide the outline of a sector or other large coverage region. We have not proposed a separate label for that. > > 2. Assumptions about the LIS (privacy concerns) > This approach assumes that the LIS is willing to give out any > location information at all to unauthenticated/unauthorized parties > (e.g., the client and the VSP). I think this is a big assumption: > Since a VSP can be any host on the Internet (from the LIS's > perspective), this approach requires the LIS to give information on > a client's location to anyone on the internet, a massive privacy > risk. Moreover, if a client runs into a LIS that doesn't give out > course location (for whatever reason), then it's out of luck -- it > has no idea where to turn for help. You seem to be mis-understanding the proposal. The LIS only hands out location information sufficient to identify the PSAP/ESRP to unauthenticated users. All proposals so far have involved handing out the PSAP URL, so this is exactly equivalent in terms of location revealed. > > 3. Mixing of LoST and Location Dereference > This approach requires the LIS to do a LoST query with only > location -- without any knowledge of what service is desired. For > example: Even if it queries for all available services, it could > get back different service areas for each -- which service area > should it return to the client? It can't return the union (that > would lead to LoST mis-routes), and returning the intersection adds > to the granularity of the location provided. Again, this seems to be a misreading of the proposal. The LIS makes no LoST queries in this proposal; the UA does this as normal. > > So, I guess in summary, > > QUESTION: Is this approach acceptable for you? > No. If you have alternatives that satisfy the requirements and has a precise description of behavior that includes both hiding and non- hiding cases, please describe it. So far, alternatives have all failed one or more of: - No business or trust relationship between ISPs and VSPs. - VSPs can be outside the jurisdiction of the PSAP and can be Joe's Bakery and Car Repair. - No magic configuration for UAs. - Multiple LoST server hierarchies, with resolvers that have no trust relationship with the PSAP or the ISP. - Minimal impact on UAs; in particular, fail-and-try-something-else is not acceptable. Bonus points for avoiding modifications to LoST, SIP location conveyance, DHCP. I'm not claiming elegance for the solution, but "least bad" status. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 11:42:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HevFi-0006oB-1m; Fri, 20 Apr 2007 11:42:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HevFh-0006o6-IP for ecrit@ietf.org; Fri, 20 Apr 2007 11:42:25 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HevFf-0003MQ-2g for ecrit@ietf.org; Fri, 20 Apr 2007 11:42:25 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HevEy-0003UY-K0; Fri, 20 Apr 2007 10:41:40 -0500 From: "Brian Rosen" To: "'Richard Barnes'" , "'Hannes Tschofenig'" Subject: RE: [Ecrit] Consensus Call: Precise Location Information not availableto End Host Date: Fri, 20 Apr 2007 11:42:19 -0400 Message-ID: <13ff01c78362$7c80d4c0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceDX5Wy9k+LxnZ+ShugmETVYbnc8wAALZzQ In-Reply-To: <4628DAA2.5030605@bbn.com> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Woah Nellie. You don't understand the proposal. The endpoint gets an LbyR. It can dereference to get an LbyV, but it puts the LbyR on the call. That should be normal behavior. No one forwards the LbyV to anyone. If they have permission, they forward the LbyR. As we have observed, you have to treat an LbyR with the same degree of care you treat an LbyV. No one hands out the LbyR to anyone except as per the user's privacy policy (as modified by local laws, which apply in the emergency case). The LIS provides the polygon as the location, not a point in it. The target is somewhere in the polygon. This polygon is an acceptable location to route emergency calls on; if used in a LoST query (by the endpoint for example), it will yield the correct PSAP URI. It is true that we are dependent on the LIS giving out coarse location to its subscriber. We are asking access network operators if that is acceptable. So far, it appears they are okay. If you know different, please cite an example. If they refuse to supply any form of location, the whole scheme fails. I note that if they give out a PSAP URI, that is equivalent to the polygon we are talking about. Regardless of who does the LoST query, if the endpoint gets back a PSAP URI, they can, with little effort, determine the coarse location. There is a pretty simple fix for the boundary-per-service issue. The algorithm used by LoST to deal with a polygon as input is defined. The LIS can produce a polygon that yields a correct answer for all the services while still providing quite coarse location. It's a little more work for the LIS, but not a whole lot. It could return a point, but I think that would be very misleading and it should not do that. Brian > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Friday, April 20, 2007 11:22 AM > To: Hannes Tschofenig > Cc: ECRIT > Subject: Re: [Ecrit] Consensus Call: Precise Location Information not > availableto End Host > > Hannes, > > I haven't had time to keep up with the hailstorm of discussion, but I > have a several concerns about this approach: > > 1. Confusion over location semantics > This approach has two different types of location objects (LbyV) -- one > that describes the actual location of the endpoint, and one that guides > the LoST query. This makes me worry about the two getting mixed up: > E.g., LIS provides not a service boundary (too big) but an arbitrary > point within the service boundary, and PSAP routes first responders to > that point. Even requiring that the LIS always provide a service > boundary isn't enough, since the party that consumes the LO has no way > to know that it's a service boundary and not an estimate of the hosts > location. So there needs to be some explicit syntax here to > differentiate these two cases (e.g., a "service-boundary" tag on the LO > or on the Geolocation header, or a Service-area: SIP header). > > 2. Assumptions about the LIS (privacy concerns) > This approach assumes that the LIS is willing to give out any location > information at all to unauthenticated/unauthorized parties (e.g., the > client and the VSP). I think this is a big assumption: Since a VSP can > be any host on the Internet (from the LIS's perspective), this approach > requires the LIS to give information on a client's location to anyone on > the internet, a massive privacy risk. Moreover, if a client runs into a > LIS that doesn't give out course location (for whatever reason), then > it's out of luck -- it has no idea where to turn for help. > > 3. Mixing of LoST and Location Dereference > This approach requires the LIS to do a LoST query with only location -- > without any knowledge of what service is desired. For example: Even if > it queries for all available services, it could get back different > service areas for each -- which service area should it return to the > client? It can't return the union (that would lead to LoST mis-routes), > and returning the intersection adds to the granularity of the location > provided. > > So, I guess in summary, > > QUESTION: Is this approach acceptable for you? > No. > > --Richard > > Hannes Tschofenig wrote: > > Hi all, > > let me try it again (I got it wrong in my previous mail). > > Henning and Brian suggested an approach that * works nicely with the > > emergency services architecture we > > investigated over the past few years, and > > * addresses the case where a network operator does not want to disclose > > precise location information. > > Here is the procedure: > > > > 1. The endpoint uses an LCP to request location. The LIS returns an > LbyR > > 2. The endpoint dereferences the LbyR. 3. The LIS, noticing that the > > dereference request is from the endpoint (or > > at least not from any entity that is entitled to get fine grained > > location), > > takes the fine grained location and uses LoST to determine the PSAP that > > serves that location. > > 4. The LIS returns to the endpoint a location which, if submitted to > LoST, > > would return the same PSAP URI the fine grained location would. In some > > circumstances, this could be a civic with only a country. An > alternative > > that works for all circumstances is to return the polygon that defines > the > > service boundary of the PSAP (which LoST can return). Is essential that > > the > > PSAP URI returned from a LoST query with whatever the LIS gives the > > endpoint > > would be the same PSAP URI any querier using the fine grained location > > would > > get. > > 5. The endpoint uses the (coarse) location value it obtains to query > LoST. > > It gets the (correct) PSAP URI > > 6. This is repeated at call time. The endpoint has a valid LbyR and a > > valid > > PSAP URI, which it uses to construct the emergency call > > 7. A VSP wishing to validate the PSAP URI takes the LbyR and > dereferences > > it. The result will be the same (coarse) location the endpoint got. > The > > VSP does a LoST query with that location, and should get the same PSAP > URI > > that is in the Request URI on the call. This validation works for > > coarse or > > fine validation, and of course works for LbyV without the dereference > step. > > 8. The PSAP (or ESRP) which is the target of the PSAP URI gets the > > call. It > > dereferences the LbyR but gets the fine grained location; the LIS must > have > > a relationship with the ESRP/PSAP to assure this. > > 9. Any succeeding ESRPs or PSAPs can also dereference and get fine > grained > > location. > > > > > Ciao > > Hannes > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 12:10:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hevgt-0007W1-9C; Fri, 20 Apr 2007 12:10:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hevgr-0007Q8-6A for ecrit@ietf.org; Fri, 20 Apr 2007 12:10:29 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hevgq-0005XS-Sd for ecrit@ietf.org; Fri, 20 Apr 2007 12:10:29 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Hevgq-0007Es-4J; Fri, 20 Apr 2007 12:10:28 -0400 Received: from [127.0.0.1] (col-dhcp33-244-171.bbn.com [128.33.244.171]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l3KGAQw02657; Fri, 20 Apr 2007 12:10:26 -0400 (EDT) Message-ID: <4628E5F0.3030201@bbn.com> Date: Fri, 20 Apr 2007 12:10:24 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host References: <46287EB9.7060006@gmx.net> <4628DAA2.5030605@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > This doesn't seem fundamentally different from having a wireless > provider provide the outline of a sector or other large coverage region. > We have not proposed a separate label for that. The fundamental difference is that a sector (or similar region) is intended to communicate the location of the endpoint, whereas the location returned by the LIS in response to an unauthorized dereference request is intended, in effect, to communicate the identity of a PSAP. Depending on both of these semantics without clear differentiation risks confusing the two purposes, and is an abuse of location by reference to effectively do LoST. > You seem to be mis-understanding the proposal. The LIS only hands out > location information sufficient to identify the PSAP/ESRP to > unauthenticated users. All proposals so far have involved handing out > the PSAP URL, so this is exactly equivalent in terms of location revealed. You're correct, provided that only one service area or PSAP URL is handed out, or that all PSAP URLs or service areas returned are the same. However, where there are several autonomous emergency services with different service areas, the service returned has to be the intersection of all these service areas, to ensure that LoST routing works right for all of them. Depending on how service areas overlay, this could be a small area. This wouldn't be a big problem, except that this area doesn't just get returned to the client, but to any unauthenticated/unauthorized dereference client. The client has no control over how his location information (in this rough form) is disseminated. > Again, this seems to be a misreading of the proposal. The LIS makes no > LoST queries in this proposal; the UA does this as normal. Hannes' description says that the LIS "takes the fine grained location and uses LoST to determine the PSAP that serves that location," but I understand your point; the LIS doesn't necessarily need to do a LoST query for every dereference. Nonetheless, the LIS needs some way to determine what service area(s) to return, so it will likely need to use LoST at some point. > If you have alternatives that satisfy the requirements and has a precise > description of behavior that includes both hiding and non-hiding cases, > please describe it. I've proposed one alternative, but I think I need to restate myself more clearly. I'll give another try in a separate message. --Richard > So far, alternatives have all failed one or more of: > > - No business or trust relationship between ISPs and VSPs. > > - VSPs can be outside the jurisdiction of the PSAP and can be Joe's > Bakery and Car Repair. > > - No magic configuration for UAs. > > - Multiple LoST server hierarchies, with resolvers that have no trust > relationship with the PSAP or the ISP. > > - Minimal impact on UAs; in particular, fail-and-try-something-else is > not acceptable. > > Bonus points for avoiding modifications to LoST, SIP location > conveyance, DHCP. > > I'm not claiming elegance for the solution, but "least bad" status. > > Henning > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 12:26:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hevvy-00087M-4w; Fri, 20 Apr 2007 12:26:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hevvw-00087F-TW for ecrit@ietf.org; Fri, 20 Apr 2007 12:26:04 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hevvv-0002Nu-CJ for ecrit@ietf.org; Fri, 20 Apr 2007 12:26:04 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Hevvs-0007Nh-5k; Fri, 20 Apr 2007 12:26:00 -0400 Received: from [127.0.0.1] (col-dhcp33-244-171.bbn.com [128.33.244.171]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l3KGPxw05457; Fri, 20 Apr 2007 12:25:59 -0400 (EDT) Message-ID: <4628E994.2020902@bbn.com> Date: Fri, 20 Apr 2007 12:25:56 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Consensus Call: Precise Location Information not availableto End Host References: <13ff01c78362$7c80d4c0$640fa8c0@cis.neustar.com> In-Reply-To: <13ff01c78362$7c80d4c0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > The endpoint gets an LbyR. It can dereference to get an LbyV, but it puts > the LbyR on the call. That should be normal behavior. No one forwards the > LbyV to anyone. If they have permission, they forward the LbyR. I agree that not transmitting the LbyV helps somewhat, since it forces location recipients to dereference. But in the end, it doesn't really matter if the LbyV gets transmitted or not, since any party that wants it can get it by dereferencing the LbyR. > As we have observed, you have to treat an LbyR with the same degree of care > you treat an LbyV. No one hands out the LbyR to anyone except as per the > user's privacy policy (as modified by local laws, which apply in the > emergency case). As has been argued before (and I thought we agreed in the LbyR design team), this is not a tenable as a universal policy. E.g., SIP has no protection for headers, so any eavesdropper to a SIP call would have access to an LbyR included in a Geolocation header. In addition, since the LbyR has no syntax for privacy rules, such a policy would force everyone who receives an LbyR to dereference it before doing anything with it. > The LIS provides the polygon as the location, not a point in it. The target > is somewhere in the polygon. This polygon is an acceptable location to > route emergency calls on; if used in a LoST query (by the endpoint for > example), it will yield the correct PSAP URI. This would need to be specified to be the case. Hannes' description just said that the LIS returns "a location which, if submitted to LoST, would return the same PSAP URI the fine grained location would." By this description, it could very well be any random point in the service area. > It is true that we are dependent on the LIS giving out coarse location to > its subscriber. We are asking access network operators if that is > acceptable. So far, it appears they are okay. If you know different, > please cite an example. I don't know different, but the operator's opinion is only half of the story. It also needs to be OK with the client/target that the coarse-grained location get distributed. > If they refuse to supply any form of location, the > whole scheme fails. I note that if they give out a PSAP URI, that is > equivalent to the polygon we are talking about. Regardless of who does the > LoST query, if the endpoint gets back a PSAP URI, they can, with little > effort, determine the coarse location. When an endpoint does LoST with an LbyV, its location remains confidential to it and the LoST infrastructure; it only reveals its coarse location at emergency call time, and then only to entities that handle the call. By contrast, if any unauth'ed dereference gives a PSAP service area, then this level of location is available to anyone who knows or can guess the LbyR, at all times. A concrete example: Suppose I'm a location-based service operator, and the client provided his LbyR to me at one time. Now, at any time thereafter, I can dereference that LbyR to get a coarse idea of his location. This lets me wait until he leaves town to go and break into his house. And the client has no way to turn this off. > There is a pretty simple fix for the boundary-per-service issue. The > algorithm used by LoST to deal with a polygon as input is defined. The LIS > can produce a polygon that yields a correct answer for all the services > while still providing quite coarse location. It's a little more work for > the LIS, but not a whole lot. It could return a point, but I think that > would be very misleading and it should not do that. As I think about it, in order to ensure proper routing, the LIS would need to return the intersection of all the service boundaries, or a subset of it. But as I've said, this introduces extra granularity into a location that is universally available. I do agree that returning a point is a bad idea, but this would need to be specified. --Richard > > Brian > > > >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Friday, April 20, 2007 11:22 AM >> To: Hannes Tschofenig >> Cc: ECRIT >> Subject: Re: [Ecrit] Consensus Call: Precise Location Information not >> availableto End Host >> >> Hannes, >> >> I haven't had time to keep up with the hailstorm of discussion, but I >> have a several concerns about this approach: >> >> 1. Confusion over location semantics >> This approach has two different types of location objects (LbyV) -- one >> that describes the actual location of the endpoint, and one that guides >> the LoST query. This makes me worry about the two getting mixed up: >> E.g., LIS provides not a service boundary (too big) but an arbitrary >> point within the service boundary, and PSAP routes first responders to >> that point. Even requiring that the LIS always provide a service >> boundary isn't enough, since the party that consumes the LO has no way >> to know that it's a service boundary and not an estimate of the hosts >> location. So there needs to be some explicit syntax here to >> differentiate these two cases (e.g., a "service-boundary" tag on the LO >> or on the Geolocation header, or a Service-area: SIP header). >> >> 2. Assumptions about the LIS (privacy concerns) >> This approach assumes that the LIS is willing to give out any location >> information at all to unauthenticated/unauthorized parties (e.g., the >> client and the VSP). I think this is a big assumption: Since a VSP can >> be any host on the Internet (from the LIS's perspective), this approach >> requires the LIS to give information on a client's location to anyone on >> the internet, a massive privacy risk. Moreover, if a client runs into a >> LIS that doesn't give out course location (for whatever reason), then >> it's out of luck -- it has no idea where to turn for help. >> >> 3. Mixing of LoST and Location Dereference >> This approach requires the LIS to do a LoST query with only location -- >> without any knowledge of what service is desired. For example: Even if >> it queries for all available services, it could get back different >> service areas for each -- which service area should it return to the >> client? It can't return the union (that would lead to LoST mis-routes), >> and returning the intersection adds to the granularity of the location >> provided. >> >> So, I guess in summary, >> > QUESTION: Is this approach acceptable for you? >> No. >> >> --Richard >> >> Hannes Tschofenig wrote: >>> Hi all, >>> let me try it again (I got it wrong in my previous mail). >>> Henning and Brian suggested an approach that * works nicely with the >>> emergency services architecture we >>> investigated over the past few years, and >>> * addresses the case where a network operator does not want to disclose >>> precise location information. >>> Here is the procedure: >>> >>> 1. The endpoint uses an LCP to request location. The LIS returns an >> LbyR >>> 2. The endpoint dereferences the LbyR. 3. The LIS, noticing that the >>> dereference request is from the endpoint (or >>> at least not from any entity that is entitled to get fine grained >>> location), >>> takes the fine grained location and uses LoST to determine the PSAP that >>> serves that location. >>> 4. The LIS returns to the endpoint a location which, if submitted to >> LoST, >>> would return the same PSAP URI the fine grained location would. In some >>> circumstances, this could be a civic with only a country. An >> alternative >>> that works for all circumstances is to return the polygon that defines >> the >>> service boundary of the PSAP (which LoST can return). Is essential that >>> the >>> PSAP URI returned from a LoST query with whatever the LIS gives the >>> endpoint >>> would be the same PSAP URI any querier using the fine grained location >>> would >>> get. >>> 5. The endpoint uses the (coarse) location value it obtains to query >> LoST. >>> It gets the (correct) PSAP URI >>> 6. This is repeated at call time. The endpoint has a valid LbyR and a >>> valid >>> PSAP URI, which it uses to construct the emergency call >>> 7. A VSP wishing to validate the PSAP URI takes the LbyR and >> dereferences >>> it. The result will be the same (coarse) location the endpoint got. >> The >>> VSP does a LoST query with that location, and should get the same PSAP >> URI >>> that is in the Request URI on the call. This validation works for >>> coarse or >>> fine validation, and of course works for LbyV without the dereference >> step. >>> 8. The PSAP (or ESRP) which is the target of the PSAP URI gets the >>> call. It >>> dereferences the LbyR but gets the fine grained location; the LIS must >> have >>> a relationship with the ESRP/PSAP to assure this. >>> 9. Any succeeding ESRPs or PSAPs can also dereference and get fine >> grained >>> location. >>> >>> Ciao >>> Hannes >>> >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 12:27:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hevxn-0000YG-75; Fri, 20 Apr 2007 12:27:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hevxm-0000Y8-5y for ecrit@ietf.org; Fri, 20 Apr 2007 12:27:58 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hevxl-0002pg-Sa for ecrit@ietf.org; Fri, 20 Apr 2007 12:27:58 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Apr 2007 12:27:54 -0400 X-IronPort-AV: i="4.14,433,1170651600"; d="scan'208"; a="58195194:sNHT48899976" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3KGRrnu032443; Fri, 20 Apr 2007 12:27:53 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3KGRdlc002572; Fri, 20 Apr 2007 16:27:53 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 12:27:47 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.20.40]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 12:27:47 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 20 Apr 2007 11:27:46 -0500 To: Hannes Tschofenig , ECRIT From: "James M. Polk" Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host In-Reply-To: <46287EB9.7060006@gmx.net> References: <46287EB9.7060006@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 20 Apr 2007 16:27:47.0579 (UTC) FILETIME=[D4F19CB0:01C78368] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2666; t=1177086473; x=1177950473; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Consensus=20Call=3A=20Precise=20Location=20 Information=20not=0A=20=20available=20to=20End=20Host |Sender:=20 |To:=20Hannes=20Tschofenig=20, =20ECRIT=20; bh=Jz7YrkwaNaDQkhjgqE3YAFEAKzAqAUS3tGkG5s9fnqU=; b=UdEMrXJGZ2loLAoITc/uYM0U4HLN+DqnTffa9Rj62IM5+GexQVd0/CTTp6K9dPbyrlkiokWD 6FOwQcU4RQZRM4irYzCS/WHldMaeWTWYrcEvNHjQGO/YA62xGebjdW2k; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes What you are detailing is a technical solution to a business decision, not a technical solution to a technical problem/requirement. I am opposed to this compromise (i.e. cave). At 03:50 AM 4/20/2007, Hannes Tschofenig wrote: >Hi all, >let me try it again (I got it wrong in my previous mail). >Henning and Brian suggested an approach that * works nicely with the >emergency services architecture we >investigated over the past few years, and >* addresses the case where a network operator does not want to >disclose precise location information. >Here is the procedure: > >1. The endpoint uses an LCP to request location. The LIS returns an LbyR >2. The endpoint dereferences the LbyR. >3. The LIS, noticing that the dereference request is from the endpoint (or >at least not from any entity that is entitled to get fine grained location), >takes the fine grained location and uses LoST to determine the PSAP that >serves that location. >4. The LIS returns to the endpoint a location which, if submitted to LoST, >would return the same PSAP URI the fine grained location would. In some >circumstances, this could be a civic with only a country. An alternative >that works for all circumstances is to return the polygon that defines the >service boundary of the PSAP (which LoST can return). Is essential that the >PSAP URI returned from a LoST query with whatever the LIS gives the endpoint >would be the same PSAP URI any querier using the fine grained location would >get. >5. The endpoint uses the (coarse) location value it obtains to query LoST. >It gets the (correct) PSAP URI >6. This is repeated at call time. The endpoint has a valid LbyR and a valid >PSAP URI, which it uses to construct the emergency call >7. A VSP wishing to validate the PSAP URI takes the LbyR and dereferences >it. The result will be the same (coarse) location the endpoint got. The >VSP does a LoST query with that location, and should get the same PSAP URI >that is in the Request URI on the call. This validation works for coarse or >fine validation, and of course works for LbyV without the dereference step. >8. The PSAP (or ESRP) which is the target of the PSAP URI gets the call. It >dereferences the LbyR but gets the fine grained location; the LIS must have >a relationship with the ESRP/PSAP to assure this. >9. Any succeeding ESRPs or PSAPs can also dereference and get fine grained >location. > >QUESTION: Is this approach acceptable for you? >Ciao >Hannes > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 12:40:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hew9s-0001v7-G4; Fri, 20 Apr 2007 12:40:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hew9q-0001uz-Tl for ecrit@ietf.org; Fri, 20 Apr 2007 12:40:26 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hew9q-00057D-AS for ecrit@ietf.org; Fri, 20 Apr 2007 12:40:26 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1Hew99-0002cy-2o; Fri, 20 Apr 2007 11:39:43 -0500 From: "Brian Rosen" To: "'Richard Barnes'" Subject: RE: [Ecrit] Consensus Call: Precise Location Information not availableto End Host Date: Fri, 20 Apr 2007 12:40:22 -0400 Message-ID: <141a01c7836a$988e1990$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceDaH2TCZXBTJGXSA+qv+fdRxewggAASJ2Q In-Reply-To: <4628E994.2020902@bbn.com> 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Correct me if I'm wrong, but I think you are objecting to LbyR, and not this compromise on hiding location. An LbyR which, when dereferenced by anyone, would provide fine grained location has all of the issues you describe (except the last issue on multiple services). To address them, we would have to not provide LbyR, right? The algorithm in LoST to route on a polygon computes a centroid and routes on the centroid. A suitable algorithm would be to intersect all the boundaries to create the largest polygon which is contained in all the service boundaries, pick any point in that polygon, and return a circle with that point as the center and a radius of 50kM. The target would be within that circle, and every service would yield the correct URI when that circle was input to the LoST server. Brian > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Friday, April 20, 2007 12:26 PM > To: Brian Rosen > Cc: 'Hannes Tschofenig'; 'ECRIT' > Subject: Re: [Ecrit] Consensus Call: Precise Location Information not > availableto End Host > > > The endpoint gets an LbyR. It can dereference to get an LbyV, but it > puts > > the LbyR on the call. That should be normal behavior. No one forwards > the > > LbyV to anyone. If they have permission, they forward the LbyR. > > I agree that not transmitting the LbyV helps somewhat, since it forces > location recipients to dereference. But in the end, it doesn't really > matter if the LbyV gets transmitted or not, since any party that wants > it can get it by dereferencing the LbyR. > > > As we have observed, you have to treat an LbyR with the same degree of > care > > you treat an LbyV. No one hands out the LbyR to anyone except as per > the > > user's privacy policy (as modified by local laws, which apply in the > > emergency case). > > As has been argued before (and I thought we agreed in the LbyR design > team), this is not a tenable as a universal policy. E.g., SIP has no > protection for headers, so any eavesdropper to a SIP call would have > access to an LbyR included in a Geolocation header. In addition, since > the LbyR has no syntax for privacy rules, such a policy would force > everyone who receives an LbyR to dereference it before doing anything > with it. > > > The LIS provides the polygon as the location, not a point in it. The > target > > is somewhere in the polygon. This polygon is an acceptable location to > > route emergency calls on; if used in a LoST query (by the endpoint for > > example), it will yield the correct PSAP URI. > > This would need to be specified to be the case. Hannes' description > just said that the LIS returns "a location which, if submitted to LoST, > would return the same PSAP URI the fine grained location would." By > this description, it could very well be any random point in the service > area. > > > It is true that we are dependent on the LIS giving out coarse location > to > > its subscriber. We are asking access network operators if that is > > acceptable. So far, it appears they are okay. If you know different, > > please cite an example. > > I don't know different, but the operator's opinion is only half of the > story. It also needs to be OK with the client/target that the > coarse-grained location get distributed. > > > If they refuse to supply any form of location, the > > whole scheme fails. I note that if they give out a PSAP URI, that is > > equivalent to the polygon we are talking about. Regardless of who does > the > > LoST query, if the endpoint gets back a PSAP URI, they can, with little > > effort, determine the coarse location. > > When an endpoint does LoST with an LbyV, its location remains > confidential to it and the LoST infrastructure; it only reveals its > coarse location at emergency call time, and then only to entities that > handle the call. By contrast, if any unauth'ed dereference gives a PSAP > service area, then this level of location is available to anyone who > knows or can guess the LbyR, at all times. > > A concrete example: Suppose I'm a location-based service operator, and > the client provided his LbyR to me at one time. Now, at any time > thereafter, I can dereference that LbyR to get a coarse idea of his > location. This lets me wait until he leaves town to go and break into > his house. And the client has no way to turn this off. > > > There is a pretty simple fix for the boundary-per-service issue. The > > algorithm used by LoST to deal with a polygon as input is defined. The > LIS > > can produce a polygon that yields a correct answer for all the services > > while still providing quite coarse location. It's a little more work > for > > the LIS, but not a whole lot. It could return a point, but I think > that > > would be very misleading and it should not do that. > > As I think about it, in order to ensure proper routing, the LIS would > need to return the intersection of all the service boundaries, or a > subset of it. But as I've said, this introduces extra granularity into > a location that is universally available. I do agree that returning a > point is a bad idea, but this would need to be specified. > > --Richard > > > > > Brian > > > > > > > >> -----Original Message----- > >> From: Richard Barnes [mailto:rbarnes@bbn.com] > >> Sent: Friday, April 20, 2007 11:22 AM > >> To: Hannes Tschofenig > >> Cc: ECRIT > >> Subject: Re: [Ecrit] Consensus Call: Precise Location Information not > >> availableto End Host > >> > >> Hannes, > >> > >> I haven't had time to keep up with the hailstorm of discussion, but I > >> have a several concerns about this approach: > >> > >> 1. Confusion over location semantics > >> This approach has two different types of location objects (LbyV) -- one > >> that describes the actual location of the endpoint, and one that guides > >> the LoST query. This makes me worry about the two getting mixed up: > >> E.g., LIS provides not a service boundary (too big) but an arbitrary > >> point within the service boundary, and PSAP routes first responders to > >> that point. Even requiring that the LIS always provide a service > >> boundary isn't enough, since the party that consumes the LO has no way > >> to know that it's a service boundary and not an estimate of the hosts > >> location. So there needs to be some explicit syntax here to > >> differentiate these two cases (e.g., a "service-boundary" tag on the LO > >> or on the Geolocation header, or a Service-area: SIP header). > >> > >> 2. Assumptions about the LIS (privacy concerns) > >> This approach assumes that the LIS is willing to give out any location > >> information at all to unauthenticated/unauthorized parties (e.g., the > >> client and the VSP). I think this is a big assumption: Since a VSP can > >> be any host on the Internet (from the LIS's perspective), this approach > >> requires the LIS to give information on a client's location to anyone > on > >> the internet, a massive privacy risk. Moreover, if a client runs into > a > >> LIS that doesn't give out course location (for whatever reason), then > >> it's out of luck -- it has no idea where to turn for help. > >> > >> 3. Mixing of LoST and Location Dereference > >> This approach requires the LIS to do a LoST query with only location -- > >> without any knowledge of what service is desired. For example: Even if > >> it queries for all available services, it could get back different > >> service areas for each -- which service area should it return to the > >> client? It can't return the union (that would lead to LoST mis- > routes), > >> and returning the intersection adds to the granularity of the location > >> provided. > >> > >> So, I guess in summary, > >> > QUESTION: Is this approach acceptable for you? > >> No. > >> > >> --Richard > >> > >> Hannes Tschofenig wrote: > >>> Hi all, > >>> let me try it again (I got it wrong in my previous mail). > >>> Henning and Brian suggested an approach that * works nicely with the > >>> emergency services architecture we > >>> investigated over the past few years, and > >>> * addresses the case where a network operator does not want to > disclose > >>> precise location information. > >>> Here is the procedure: > >>> > >>> 1. The endpoint uses an LCP to request location. The LIS returns an > >> LbyR > >>> 2. The endpoint dereferences the LbyR. 3. The LIS, noticing that the > >>> dereference request is from the endpoint (or > >>> at least not from any entity that is entitled to get fine grained > >>> location), > >>> takes the fine grained location and uses LoST to determine the PSAP > that > >>> serves that location. > >>> 4. The LIS returns to the endpoint a location which, if submitted to > >> LoST, > >>> would return the same PSAP URI the fine grained location would. In > some > >>> circumstances, this could be a civic with only a country. An > >> alternative > >>> that works for all circumstances is to return the polygon that defines > >> the > >>> service boundary of the PSAP (which LoST can return). Is essential > that > >>> the > >>> PSAP URI returned from a LoST query with whatever the LIS gives the > >>> endpoint > >>> would be the same PSAP URI any querier using the fine grained location > >>> would > >>> get. > >>> 5. The endpoint uses the (coarse) location value it obtains to query > >> LoST. > >>> It gets the (correct) PSAP URI > >>> 6. This is repeated at call time. The endpoint has a valid LbyR and a > >>> valid > >>> PSAP URI, which it uses to construct the emergency call > >>> 7. A VSP wishing to validate the PSAP URI takes the LbyR and > >> dereferences > >>> it. The result will be the same (coarse) location the endpoint got. > >> The > >>> VSP does a LoST query with that location, and should get the same PSAP > >> URI > >>> that is in the Request URI on the call. This validation works for > >>> coarse or > >>> fine validation, and of course works for LbyV without the dereference > >> step. > >>> 8. The PSAP (or ESRP) which is the target of the PSAP URI gets the > >>> call. It > >>> dereferences the LbyR but gets the fine grained location; the LIS must > >> have > >>> a relationship with the ESRP/PSAP to assure this. > >>> 9. Any succeeding ESRPs or PSAPs can also dereference and get fine > >> grained > >>> location. > >>> > >>> Ciao > >>> Hannes > >>> > >>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/ecrit > >>> > >>> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 12:59:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HewSd-00043H-M7; Fri, 20 Apr 2007 12:59:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HewSc-0003xn-Kb for ecrit@ietf.org; Fri, 20 Apr 2007 12:59:50 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HewSb-0006A3-Av for ecrit@ietf.org; Fri, 20 Apr 2007 12:59:50 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3KGxbrR013257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Apr 2007 12:59:37 -0400 (EDT) In-Reply-To: References: <46287EB9.7060006@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7DBB6474-3DAD-4619-A2A1-21E2D703A402@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host Date: Fri, 20 Apr 2007 13:00:55 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org James, I'm no friend of location hiding, as I've made amply clear, but I was trying to find a solution that does not actually impose any new requirements on user agents nor makes life more expensive for the rest of the world. So far, all the alternatives I've seen either yield non-interoperable islands or impose cost shifting, where innocent third parties pay for the business decisions of the ISP. I'd like the requirement to go away, but it has apparently been a very convenient rationale for not playing along with the whole ECRIT architecture. Henning On Apr 20, 2007, at 12:27 PM, James M. Polk wrote: > Hannes > > What you are detailing is a technical solution to a business > decision, not a technical solution to a technical problem/ > requirement. I am opposed to this compromise (i.e. cave). > > At 03:50 AM 4/20/2007, Hannes Tschofenig wrote: >> Hi all, >> let me try it again (I got it wrong in my previous mail). >> Henning and Brian suggested an approach that * works nicely with >> the emergency services architecture we >> investigated over the past few years, and >> * addresses the case where a network operator does not want to >> disclose precise location information. >> Here is the procedure: >> >> 1. The endpoint uses an LCP to request location. The LIS returns >> an LbyR >> 2. The endpoint dereferences the LbyR. >> 3. The LIS, noticing that the dereference request is from the >> endpoint (or >> at least not from any entity that is entitled to get fine grained >> location), >> takes the fine grained location and uses LoST to determine the >> PSAP that >> serves that location. >> 4. The LIS returns to the endpoint a location which, if submitted >> to LoST, >> would return the same PSAP URI the fine grained location would. >> In some >> circumstances, this could be a civic with only a country. An >> alternative >> that works for all circumstances is to return the polygon that >> defines the >> service boundary of the PSAP (which LoST can return). Is >> essential that the >> PSAP URI returned from a LoST query with whatever the LIS gives >> the endpoint >> would be the same PSAP URI any querier using the fine grained >> location would >> get. >> 5. The endpoint uses the (coarse) location value it obtains to >> query LoST. >> It gets the (correct) PSAP URI >> 6. This is repeated at call time. The endpoint has a valid LbyR >> and a valid >> PSAP URI, which it uses to construct the emergency call >> 7. A VSP wishing to validate the PSAP URI takes the LbyR and >> dereferences >> it. The result will be the same (coarse) location the endpoint >> got. The >> VSP does a LoST query with that location, and should get the same >> PSAP URI >> that is in the Request URI on the call. This validation works for >> coarse or >> fine validation, and of course works for LbyV without the >> dereference step. >> 8. The PSAP (or ESRP) which is the target of the PSAP URI gets the >> call. It >> dereferences the LbyR but gets the fine grained location; the LIS >> must have >> a relationship with the ESRP/PSAP to assure this. >> 9. Any succeeding ESRPs or PSAPs can also dereference and get fine >> grained >> location. >> >> QUESTION: Is this approach acceptable for you? >> Ciao >> Hannes >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 13:09:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hewbc-0007Q7-UB; Fri, 20 Apr 2007 13:09:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hewbb-0007PR-9S for ecrit@ietf.org; Fri, 20 Apr 2007 13:09:07 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hewba-0001KQ-SR for ecrit@ietf.org; Fri, 20 Apr 2007 13:09:07 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Apr 2007 13:09:07 -0400 X-IronPort-AV: i="4.14,433,1170651600"; d="scan'208"; a="119073279:sNHT53540016" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3KH96lO024288; Fri, 20 Apr 2007 13:09:06 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3KH8XH9011214; Fri, 20 Apr 2007 17:09:06 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 13:08:56 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.20.40]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 13:08:56 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 20 Apr 2007 12:08:59 -0500 To: Henning Schulzrinne From: "James M. Polk" Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host In-Reply-To: <7DBB6474-3DAD-4619-A2A1-21E2D703A402@cs.columbia.edu> References: <46287EB9.7060006@gmx.net> <7DBB6474-3DAD-4619-A2A1-21E2D703A402@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 20 Apr 2007 17:08:56.0344 (UTC) FILETIME=[94714180:01C7836E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4257; t=1177088946; x=1177952946; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Consensus=20Call=3A=20Precise=20Location=20 Information=20not=0A=20=20available=20to=20End=20Host |Sender:=20 |To:=20Henning=20Schulzrinne=20; bh=Y0ag+DCr32/lQ0OVd/mhKnlK93ImGNpl94Nlu3vfWeI=; b=JDNkPWu3uTNhVeuMdzU96gBTD/PKDUDkvhBoc0wWBp3LtL6AzbEQwx1M0nzn1mNhJsgR8H7G I0pESe3agGlbg5ocV2ilIU7OHuf6G384AjovfgOBhyColt5QvkY4cMHx; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning Doesn't this center around either location is given to the client for free or for fee? If we agree there can be a fee, even if hidden (because service customers always end up paying for everything explicitly or implicitly), doesn't this "requirement" go away in most people's minds? This was the point of Barbara last week - that AT&T is not going to deliver location for free. I don't think anyone I'm aware of suggested this infrastructure be put in place for free, to be used by other service companies for their use only. At 12:00 PM 4/20/2007, Henning Schulzrinne wrote: >James, > >I'm no friend of location hiding, as I've made amply clear, but I was >trying to find a solution that does not actually impose any new >requirements on user agents nor makes life more expensive for the >rest of the world. > >So far, all the alternatives I've seen either yield non-interoperable >islands or impose cost shifting, where innocent third parties pay for >the business decisions of the ISP. I'd like the requirement to go >away, but it has apparently been a very convenient rationale for not >playing along with the whole ECRIT architecture. > >Henning > >On Apr 20, 2007, at 12:27 PM, James M. Polk wrote: > >>Hannes >> >>What you are detailing is a technical solution to a business >>decision, not a technical solution to a technical problem/ >>requirement. I am opposed to this compromise (i.e. cave). >> >>At 03:50 AM 4/20/2007, Hannes Tschofenig wrote: >>>Hi all, >>>let me try it again (I got it wrong in my previous mail). >>>Henning and Brian suggested an approach that * works nicely with >>>the emergency services architecture we >>>investigated over the past few years, and >>>* addresses the case where a network operator does not want to >>>disclose precise location information. >>>Here is the procedure: >>> >>>1. The endpoint uses an LCP to request location. The LIS returns >>>an LbyR >>>2. The endpoint dereferences the LbyR. >>>3. The LIS, noticing that the dereference request is from the >>>endpoint (or >>>at least not from any entity that is entitled to get fine grained >>>location), >>>takes the fine grained location and uses LoST to determine the >>>PSAP that >>>serves that location. >>>4. The LIS returns to the endpoint a location which, if submitted >>>to LoST, >>>would return the same PSAP URI the fine grained location would. >>>In some >>>circumstances, this could be a civic with only a country. An >>>alternative >>>that works for all circumstances is to return the polygon that >>>defines the >>>service boundary of the PSAP (which LoST can return). Is >>>essential that the >>>PSAP URI returned from a LoST query with whatever the LIS gives >>>the endpoint >>>would be the same PSAP URI any querier using the fine grained >>>location would >>>get. >>>5. The endpoint uses the (coarse) location value it obtains to >>>query LoST. >>>It gets the (correct) PSAP URI >>>6. This is repeated at call time. The endpoint has a valid LbyR >>>and a valid >>>PSAP URI, which it uses to construct the emergency call >>>7. A VSP wishing to validate the PSAP URI takes the LbyR and >>>dereferences >>>it. The result will be the same (coarse) location the endpoint >>>got. The >>>VSP does a LoST query with that location, and should get the same >>>PSAP URI >>>that is in the Request URI on the call. This validation works for >>>coarse or >>>fine validation, and of course works for LbyV without the >>>dereference step. >>>8. The PSAP (or ESRP) which is the target of the PSAP URI gets the >>>call. It >>>dereferences the LbyR but gets the fine grained location; the LIS >>>must have >>>a relationship with the ESRP/PSAP to assure this. >>>9. Any succeeding ESRPs or PSAPs can also dereference and get fine >>>grained >>>location. >>> >>>QUESTION: Is this approach acceptable for you? >>>Ciao >>>Hannes >>> >>> >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 13:27:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HewtA-0003lT-SV; Fri, 20 Apr 2007 13:27:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hewt9-0003lE-1R for ecrit@ietf.org; Fri, 20 Apr 2007 13:27:15 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hewt8-0000cU-Mz for ecrit@ietf.org; Fri, 20 Apr 2007 13:27:15 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3KHR20Q027465 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Apr 2007 13:27:02 -0400 (EDT) In-Reply-To: References: <46287EB9.7060006@gmx.net> <7DBB6474-3DAD-4619-A2A1-21E2D703A402@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host Date: Fri, 20 Apr 2007 13:28:20 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org If the requirement goes away, either by regulation or by paying a fee, no harm is done. As I said, the UA won't even notice. Thus, I consider this as "insurance" - it allows us to move forward and close our documents, rather than speculate what may or may not happen a year or two or five down the road. Your guess may well be right, but it remains, like my predictions on the ability to monetize location information, a prediction with high uncertainty. We all want to see IP-based emergency calling deployed sooner rather than after years of regulatory fights, particularly fights where the deck is stacked not necessarily in the consumer's favor. This is a (very small) contribution to removing one item to fight over. If there were huge (complexity or infrastructure) costs associated with the proposal, I would share your concerns. But there aren't, as far as I can tell. Henning On Apr 20, 2007, at 1:08 PM, James M. Polk wrote: > Henning > > Doesn't this center around either location is given to the client > for free or for fee? > > If we agree there can be a fee, even if hidden (because service > customers always end up paying for everything explicitly or > implicitly), doesn't this "requirement" go away in most people's > minds? > > This was the point of Barbara last week - that AT&T is not going to > deliver location for free. I don't think anyone I'm aware of > suggested this infrastructure be put in place for free, to be used > by other service companies for their use only. > > At 12:00 PM 4/20/2007, Henning Schulzrinne wrote: >> James, >> >> I'm no friend of location hiding, as I've made amply clear, but I was >> trying to find a solution that does not actually impose any new >> requirements on user agents nor makes life more expensive for the >> rest of the world. >> >> So far, all the alternatives I've seen either yield non-interoperable >> islands or impose cost shifting, where innocent third parties pay for >> the business decisions of the ISP. I'd like the requirement to go >> away, but it has apparently been a very convenient rationale for not >> playing along with the whole ECRIT architecture. >> >> Henning >> >> On Apr 20, 2007, at 12:27 PM, James M. Polk wrote: >> >>> Hannes >>> >>> What you are detailing is a technical solution to a business >>> decision, not a technical solution to a technical problem/ >>> requirement. I am opposed to this compromise (i.e. cave). >>> >>> At 03:50 AM 4/20/2007, Hannes Tschofenig wrote: >>>> Hi all, >>>> let me try it again (I got it wrong in my previous mail). >>>> Henning and Brian suggested an approach that * works nicely with >>>> the emergency services architecture we >>>> investigated over the past few years, and >>>> * addresses the case where a network operator does not want to >>>> disclose precise location information. >>>> Here is the procedure: >>>> >>>> 1. The endpoint uses an LCP to request location. The LIS returns >>>> an LbyR >>>> 2. The endpoint dereferences the LbyR. >>>> 3. The LIS, noticing that the dereference request is from the >>>> endpoint (or >>>> at least not from any entity that is entitled to get fine grained >>>> location), >>>> takes the fine grained location and uses LoST to determine the >>>> PSAP that >>>> serves that location. >>>> 4. The LIS returns to the endpoint a location which, if submitted >>>> to LoST, >>>> would return the same PSAP URI the fine grained location would. >>>> In some >>>> circumstances, this could be a civic with only a country. An >>>> alternative >>>> that works for all circumstances is to return the polygon that >>>> defines the >>>> service boundary of the PSAP (which LoST can return). Is >>>> essential that the >>>> PSAP URI returned from a LoST query with whatever the LIS gives >>>> the endpoint >>>> would be the same PSAP URI any querier using the fine grained >>>> location would >>>> get. >>>> 5. The endpoint uses the (coarse) location value it obtains to >>>> query LoST. >>>> It gets the (correct) PSAP URI >>>> 6. This is repeated at call time. The endpoint has a valid LbyR >>>> and a valid >>>> PSAP URI, which it uses to construct the emergency call >>>> 7. A VSP wishing to validate the PSAP URI takes the LbyR and >>>> dereferences >>>> it. The result will be the same (coarse) location the endpoint >>>> got. The >>>> VSP does a LoST query with that location, and should get the same >>>> PSAP URI >>>> that is in the Request URI on the call. This validation works for >>>> coarse or >>>> fine validation, and of course works for LbyV without the >>>> dereference step. >>>> 8. The PSAP (or ESRP) which is the target of the PSAP URI gets the >>>> call. It >>>> dereferences the LbyR but gets the fine grained location; the LIS >>>> must have >>>> a relationship with the ESRP/PSAP to assure this. >>>> 9. Any succeeding ESRPs or PSAPs can also dereference and get fine >>>> grained >>>> location. >>>> >>>> QUESTION: Is this approach acceptable for you? >>>> Ciao >>>> Hannes >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 13:49:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HexF5-0004tc-Os; Fri, 20 Apr 2007 13:49:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HexF4-0004t4-E3 for ecrit@ietf.org; Fri, 20 Apr 2007 13:49:54 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HexF4-0008CR-32 for ecrit@ietf.org; Fri, 20 Apr 2007 13:49:54 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HexF1-0007sC-5g for ecrit@ietf.org; Fri, 20 Apr 2007 13:49:51 -0400 Received: from [127.0.0.1] (col-dhcp33-244-171.bbn.com [128.33.244.171]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l3KHnow20313 for ; Fri, 20 Apr 2007 13:49:50 -0400 (EDT) Message-ID: <4628FD3E.5080009@bbn.com> Date: Fri, 20 Apr 2007 13:49:50 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Subject: [Ecrit] An alternative proposal X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Using LbyR to provision location raises two problems that I'd like to address separately: 1. Endpoint acquisition of a appropriate PSAP URI, and 2. VSP verification of a supposed PSAP URI. Henning's requirements 1,2,4,6 apply to problem 1, and 3,4,5,6 apply to problem 2. ===== Endpoint acquisition of a appropriate PSAP URI ===== Proposal 1(a): Extend LoST to carry LbyR. Proposal 1(b): Require that every LIS act as a LoST server for endpoints that it serves. [Proposal 1(b) could be softened with "... or explicitly delegate to a LoST server that is authorized to dereference, e.g., with an SIP or HTTP 3xx response"]. Scenario: 1. The endpoint uses an LCP to request location. 2. The LIS returns an LbyR. 3. The endpoint sends a LoST query to the LIS containing this LbyR. 4. The LIS does the same LoST query, but with LbyR replaced with LbyV. 5. The LIS sends the LoST response back to the endpoint. Call flow: Client LIS LoST | LCP Req. | | |----------->| | | LbyR | | |<-----------| | | LoST/LbyR | | |----------->| | | | LoST/LbyV | | |-------------->| | | LoST Resp. | | |<--------------| | Lost Resp. | | |<-----------| | | | | Requirements: 3. No magic configuration for UAs. No configuration necessary beyond LIS discovery. 4. Multiple LoST server hierarchies, with resolvers that have no trust relationship with the PSAP or the ISP. Depends on your semantics. The endpoint effectively uses the LIS as a resolver, but beyond that there are no extraordinary trust relationships. In the "rough location" proposal, the client implicitly trusts the LIS to LoST anyway; this just makes it explicit. 5. Minimal impact on UAs; in particular, fail-and-try-something-else is not acceptable. Not sure what this means in this case. 6. Bonus points for avoiding modifications to LoST, SIP location conveyance, DHCP. This only requires a small modification to LoST, so it's pretty straightforward, but no bonus points. ===== VSP verification of a supposed PSAP URI ===== There are two questions a VSP could ask: 1. Is this URI the URI of any PSAP? 2. Is this URI the URI of the PSAP that this UA should be calling? Note that the first question is independent of whether location is carried byV or byR, and thus a much simpler mechanism could be used to answer it. Proposal 2: Introduce a Reverse-LoST protocol that accepts a PSAP URI as input and returns a service area (or even just a boolean). Requirements: 1. No business or trust relationship between ISPs and VSPs None required. 2. VSPs can be outside the jurisdiction of the PSAP and can be Joe's Bakery and Car Repair. Anyone can do the verification, so in particular, Joe's Bakery and Car Repair can. 4. Multiple LoST server hierarchies, with resolvers that have no trust relationship with the PSAP or the ISP. No trust relationships necessary, as no sensitive data is passed. 6. Bonus points for avoiding modifications to LoST, SIP location conveyance, DHCP. I guess this one gets bonus points, but at the expense of a new protocol. IMHO, the first question is the only reasonable one to support: 1. It is not the role of the VSP to distinguish among emergency calls; that's the job of the routing infrastructure. It's entirely possible for this verification to fail because the endpoint has crossed into a neighboring PSAP coverage area, and I think we agree that the call shouldn't fail in this case. 2. Trying to support the second question often leads to unacceptable privacy consequences. The privacy risks incurred by the "rough location" proposal are due to the fact that it tries to answer the second question: Since VSPs can be (effectively) anyone, the LIS has to give out location to everyone in order for VSPs to be able to use location for this purpose. It's tempting to say that either question could be answered by a query to the LoST function of the LIS, or via LoST/LbyR, with some LoST server authenticating itself to the LIS, but both of these introduce the same privacy risks as the "rough location" proposal. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 14:48:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeyA2-00078o-AE; Fri, 20 Apr 2007 14:48:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeyA1-00078h-F1 for ecrit@ietf.org; Fri, 20 Apr 2007 14:48:45 -0400 Received: from mail1.exchange.microsoft.com ([131.107.1.17] helo=mail.exchange.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeyA0-0000XA-Qd for ecrit@ietf.org; Fri, 20 Apr 2007 14:48:45 -0400 Received: from df-bhd-01.exchange.corp.microsoft.com (157.54.54.216) by DF-GWY-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 20 Apr 2007 11:48:44 -0700 Received: from df-beagle-msg.exchange.corp.microsoft.com (157.54.69.136) by df-bhd-01.exchange.corp.microsoft.com (157.54.54.216) with Microsoft SMTP Server (TLS) id 8.1.103.0; Fri, 20 Apr 2007 11:48:44 -0700 Received: from DF-COLLIE-MSG.exchange.corp.microsoft.com ([10.255.255.1]) by DF-BEAGLE-MSG.exchange.corp.microsoft.com ([157.54.69.136]) with mapi; Fri, 20 Apr 2007 11:48:43 -0700 From: Mohammad Vakil To: Brian Rosen , 'Marc Linsner' , "ecrit@ietf.org" Date: Fri, 20 Apr 2007 11:48:41 -0700 Subject: RE: [Ecrit] enterprise requirements Thread-Topic: [Ecrit] enterprise requirements Thread-Index: AceAVrh6uMPSbzp0QuG3G/vzpCl8FQAADTCwAAM1ZwAAABG/4AAAWW6AAMWb2vA= Message-ID: References: <00e501c78064$50109f20$2d0d0d0a@amer.cisco.com> <093301c78066$1c5e7380$640fa8c0@cis.neustar.com> In-Reply-To: <093301c78066$1c5e7380$640fa8c0@cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 1.2 (+) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0670040981==" Errors-To: ecrit-bounces@ietf.org --===============0670040981== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_EEE5E031772C2542A67EBD71227CE49C64D1AFDAFFDFCOLLIEMSGex_" --_000_EEE5E031772C2542A67EBD71227CE49C64D1AFDAFFDFCOLLIEMSGex_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Brian, Is there any one agreed upon mechanism (or anything under discussion) for s= ending this "notification" to the local enterprise security? And sending lo= cation along with this "notification"? What if they want to also barge in a= n on-going call with PSAP? I know there're ways to do these, but would be nice to agree on a way of do= ing this. Thanks, -Mohammad From: Brian Rosen [mailto:br@brianrosen.net] Sent: Monday, April 16, 2007 1:31 PM To: 'Marc Linsner'; Mohammad Vakil; ecrit@ietf.org Subject: RE: [Ecrit] enterprise requirements I think the direction we are going will allow all of this. The primary way I think this will evolve in North America is to always send= the call direct to 9-1-1, and send a notification to the local enterprise.= The enterprise could ask to be included on the call. It would get locati= on with the notification. The 9-1-1 people really believe that first getting to local (campus) securi= ty and then to 9-1-1 wastes time. They want the local security on the line= in most cases, because they may be able to respond faster. "In an emergen= cy, please contact" mechanisms are a part of what we call NG9-1-1 in North = America. However, if the local access network returns a local URI for the local envi= ronment, the call will go there. If, in particular, the enterprise is auth= oritative for the local environment, even mobile carriers could get routing= from it, and calls would go to the enterprise. I suspect not many carrier= s would permit that, but the system could support it. Brian ________________________________ From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Monday, April 16, 2007 4:18 PM To: 'Mohammad Vakil'; ecrit@ietf.org Subject: RE: [Ecrit] enterprise requirements Has there been any work in this wg to address enterprise requirements. E.g.= be able to allow on-premise security to tap E.911 call, know the location = of the caller, or first route it to on-premise security, etc? There has been nothing to prevent such from happening. It should be an imp= lementation and/of regulatory choice. -Marc- --_000_EEE5E031772C2542A67EBD71227CE49C64D1AFDAFFDFCOLLIEMSGex_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Brian,

 =

Is there any one agreed = upon mechanism (or anything under discussion) for sending this “notification” = to the local enterprise security? And sending location along with this “notificati= on”? What if they want to also barge in an on-going call with PSAP?

 =

I know there’re wa= ys to do these, but would be nice to agree on a way of doing this.

 =

Thanks,

-Mohammad

 =

From: Brian Rosen [mailto:br@brianrosen.net]
Sent: Monday, April 16, 2007 1:31 PM
To: 'Marc Linsner'; Mohammad Vakil; ecrit@ietf.org
Subject: RE: [Ecrit] enterprise requirements

 

I think the direction we are going will allow all of this.=

 

The primary way I think this will evolve in North America is to always send the call direct to 9-1-1, and send a notification to the local enterprise.  The enterprise could ask to be included on the call. &nbs= p;It would get location with the notification.

 

The 9-1-1 people really believe that first getting to local (campus) security and then to 9-1-1 wastes time.  They want the local security on the line in most cases, because they may be able to respond fas= ter.  “In an emergency, please contact” mechanisms are a part o= f what we call NG9-1-1 in North America.

 

However, if the local access network returns a local URI for th= e local environment, the call will go there.  If, in particular, the enterprise is authoritative for the local environment, even mobile carriers could get routing from it, and calls would go to the enterprise.  I suspect not many carriers would permit that, but the system could support i= t.

 

Brian

 

From: Marc Linsner [mailto:mlinsner@cisco.com]
Sent: Monday, April 16, 2007 4:18 PM
To: 'Mohammad Vakil'; ecrit@ietf.org
Subject: RE: [Ecrit] enterprise requirements

 

 

 

Has there been any work in this wg to address enterpri= se requirements. E.g. be able to allow on-premise security to tap E.911 call, = know the location of the caller, or first route it to on-premise security, etc?<= span style=3D'font-size:10.0pt;color:blue'> 

 

There has been nothing to prevent such from happening.&n= bsp; It should be an implementation and/o= f regulatory choice.

 

-Marc-

--_000_EEE5E031772C2542A67EBD71227CE49C64D1AFDAFFDFCOLLIEMSGex_-- --===============0670040981== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0670040981==-- From ecrit-bounces@ietf.org Fri Apr 20 15:13:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeyYB-0008GX-Vq; Fri, 20 Apr 2007 15:13:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeyYA-00087W-4j for ecrit@ietf.org; Fri, 20 Apr 2007 15:13:42 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeyY9-00014b-LT for ecrit@ietf.org; Fri, 20 Apr 2007 15:13:42 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 20 Apr 2007 15:13:42 -0400 X-IronPort-AV: i="4.14,433,1170651600"; d="scan'208"; a="58212351:sNHT59618660" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3KJDf83020322; Fri, 20 Apr 2007 15:13:41 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3KJDSHD017271; Fri, 20 Apr 2007 19:13:41 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 15:13:41 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.20.40]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 15:13:40 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 20 Apr 2007 14:13:41 -0500 To: Henning Schulzrinne From: "James M. Polk" Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host In-Reply-To: References: <46287EB9.7060006@gmx.net> <7DBB6474-3DAD-4619-A2A1-21E2D703A402@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 20 Apr 2007 19:13:40.0645 (UTC) FILETIME=[016EF550:01C78380] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6201; t=1177096421; x=1177960421; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Consensus=20Call=3A=20Precise=20Location=20 Information=20not=0A=20=20available=20to=20End=20Host |Sender:=20 |To:=20Henning=20Schulzrinne=20; bh=QOOw5aBmevFUjvaNqoq2dgqMAeymUy7b3Mc820OSwn8=; b=p/ofUqAWCLyAD+2HtQpKc9i+PrciR7AkiVUMLcyMDUIGIXAPlSUjz6ncEhnDv0kWvETYYcdU Bd1a8ON8bRQftlxTO+vD4fSRivsO0EDOJ3DKZibNNXnLk9Ub8IbFFA8U; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning Please explain steps #4 & 5. How does a course location return the Colleyville, Texas PSAP URI, or even the Tarrant county ESRP URI? I live in Colleyville, Texas, one of 47 cities in Tarrant County - which contains Forth Worth (next to Dallas), for those wanting to understand the references I'm using. Each city in Tarrant county has a PSAP today. The metro area of Dallas/Ft. Worth (DFW) has an ERC that answers all 911 cell calls due to non-compliance with wireless phase I or II. In all this, I'm wondering how my state level precision (suggested below as "the solution") gets my emergency call to where I want it to before I or a family member dies. At 12:28 PM 4/20/2007, Henning Schulzrinne wrote: >If the requirement goes away, either by regulation or by paying a >fee, no harm is done. As I said, the UA won't even notice. Thus, I >consider this as "insurance" - it allows us to move forward and close >our documents, rather than speculate what may or may not happen a >year or two or five down the road. Your guess may well be right, but >it remains, like my predictions on the ability to monetize location >information, a prediction with high uncertainty. We all want to see >IP-based emergency calling deployed sooner rather than after years of >regulatory fights, particularly fights where the deck is stacked not >necessarily in the consumer's favor. This is a (very small) >contribution to removing one item to fight over. > >If there were huge (complexity or infrastructure) costs associated >with the proposal, I would share your concerns. But there aren't, as >far as I can tell. > >Henning > >On Apr 20, 2007, at 1:08 PM, James M. Polk wrote: > >>Henning >> >>Doesn't this center around either location is given to the client >>for free or for fee? >> >>If we agree there can be a fee, even if hidden (because service >>customers always end up paying for everything explicitly or >>implicitly), doesn't this "requirement" go away in most people's >>minds? >> >>This was the point of Barbara last week - that AT&T is not going to >>deliver location for free. I don't think anyone I'm aware of >>suggested this infrastructure be put in place for free, to be used >>by other service companies for their use only. >> >>At 12:00 PM 4/20/2007, Henning Schulzrinne wrote: >>>James, >>> >>>I'm no friend of location hiding, as I've made amply clear, but I was >>>trying to find a solution that does not actually impose any new >>>requirements on user agents nor makes life more expensive for the >>>rest of the world. >>> >>>So far, all the alternatives I've seen either yield non-interoperable >>>islands or impose cost shifting, where innocent third parties pay for >>>the business decisions of the ISP. I'd like the requirement to go >>>away, but it has apparently been a very convenient rationale for not >>>playing along with the whole ECRIT architecture. >>> >>>Henning >>> >>>On Apr 20, 2007, at 12:27 PM, James M. Polk wrote: >>> >>>>Hannes >>>> >>>>What you are detailing is a technical solution to a business >>>>decision, not a technical solution to a technical problem/ >>>>requirement. I am opposed to this compromise (i.e. cave). >>>> >>>>At 03:50 AM 4/20/2007, Hannes Tschofenig wrote: >>>>>Hi all, >>>>>let me try it again (I got it wrong in my previous mail). >>>>>Henning and Brian suggested an approach that * works nicely with >>>>>the emergency services architecture we >>>>>investigated over the past few years, and >>>>>* addresses the case where a network operator does not want to >>>>>disclose precise location information. >>>>>Here is the procedure: >>>>> >>>>>1. The endpoint uses an LCP to request location. The LIS returns >>>>>an LbyR >>>>>2. The endpoint dereferences the LbyR. >>>>>3. The LIS, noticing that the dereference request is from the >>>>>endpoint (or >>>>>at least not from any entity that is entitled to get fine grained >>>>>location), >>>>>takes the fine grained location and uses LoST to determine the >>>>>PSAP that >>>>>serves that location. >>>>>4. The LIS returns to the endpoint a location which, if submitted >>>>>to LoST, >>>>>would return the same PSAP URI the fine grained location would. >>>>>In some >>>>>circumstances, this could be a civic with only a country. An >>>>>alternative >>>>>that works for all circumstances is to return the polygon that >>>>>defines the >>>>>service boundary of the PSAP (which LoST can return). Is >>>>>essential that the >>>>>PSAP URI returned from a LoST query with whatever the LIS gives >>>>>the endpoint >>>>>would be the same PSAP URI any querier using the fine grained >>>>>location would >>>>>get. >>>>>5. The endpoint uses the (coarse) location value it obtains to >>>>>query LoST. >>>>>It gets the (correct) PSAP URI >>>>>6. This is repeated at call time. The endpoint has a valid LbyR >>>>>and a valid >>>>>PSAP URI, which it uses to construct the emergency call >>>>>7. A VSP wishing to validate the PSAP URI takes the LbyR and >>>>>dereferences >>>>>it. The result will be the same (coarse) location the endpoint >>>>>got. The >>>>>VSP does a LoST query with that location, and should get the same >>>>>PSAP URI >>>>>that is in the Request URI on the call. This validation works for >>>>>coarse or >>>>>fine validation, and of course works for LbyV without the >>>>>dereference step. >>>>>8. The PSAP (or ESRP) which is the target of the PSAP URI gets the >>>>>call. It >>>>>dereferences the LbyR but gets the fine grained location; the LIS >>>>>must have >>>>>a relationship with the ESRP/PSAP to assure this. >>>>>9. Any succeeding ESRPs or PSAPs can also dereference and get fine >>>>>grained >>>>>location. >>>>> >>>>>QUESTION: Is this approach acceptable for you? >>>>>Ciao >>>>>Hannes >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>Ecrit mailing list >>>>>Ecrit@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/ecrit >>>> >>>>_______________________________________________ >>>>Ecrit mailing list >>>>Ecrit@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 15:20:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeyfC-0006Yk-8V; Fri, 20 Apr 2007 15:20:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeyfA-0006Rh-Oi for ecrit@ietf.org; Fri, 20 Apr 2007 15:20:56 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heyf8-0002PT-T2 for ecrit@ietf.org; Fri, 20 Apr 2007 15:20:56 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HeyeP-0006ra-5U; Fri, 20 Apr 2007 14:20:10 -0500 From: "Brian Rosen" To: "'Mohammad Vakil'" , "'Marc Linsner'" , Subject: RE: [Ecrit] enterprise requirements Date: Fri, 20 Apr 2007 15:20:49 -0400 Message-ID: <147801c78381$03580b30$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceAVrh6uMPSbzp0QuG3G/vzpCl8FQAADTCwAAM1ZwAAABG/4AAAWW6AAMWb2vAAAQyYEA== In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.2 (+) X-Scan-Signature: 3b3673afe71d94a7551c8fbc5adb8948 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2064007388==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============2064007388== Content-Type: multipart/alternative; boundary="----=_NextPart_000_1479_01C7835F.7C466B30" This is a multi-part message in MIME format. ------=_NextPart_000_1479_01C7835F.7C466B30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit There will be a defined place to put things that are specifically about a call, and about a location. In the case you are discussing, it's probably additional information the location, so that any call from the enterprise, regardless of carrier or caller gets the treatment. The mechanism for additional information about location is another LoST service. The resulting URI will point to an XML data structure that defines all sorts of location related data, of which this is one. Building floor plans, elevator state, surveillance video, etc will be included in this data structure as well as "In emergency, please notify..". The local security won't be able to "barge in", but the call taker will be alerted that they request to be added, and the system will be able to add them if the call taker agrees (there is also an overriding per-PSAP policy decision that controls whether this function is available). The thing that is not defined is the XML data structure. I'm not sure yet where we will do this. If no better venue occurs, we will do it in NENA. Brian _____ From: Mohammad Vakil [mailto:mvakil@exchange.microsoft.com] Sent: Friday, April 20, 2007 2:49 PM To: Brian Rosen; 'Marc Linsner'; ecrit@ietf.org Subject: RE: [Ecrit] enterprise requirements Brian, Is there any one agreed upon mechanism (or anything under discussion) for sending this "notification" to the local enterprise security? And sending location along with this "notification"? What if they want to also barge in an on-going call with PSAP? I know there're ways to do these, but would be nice to agree on a way of doing this. Thanks, -Mohammad From: Brian Rosen [mailto:br@brianrosen.net] Sent: Monday, April 16, 2007 1:31 PM To: 'Marc Linsner'; Mohammad Vakil; ecrit@ietf.org Subject: RE: [Ecrit] enterprise requirements I think the direction we are going will allow all of this. The primary way I think this will evolve in North America is to always send the call direct to 9-1-1, and send a notification to the local enterprise. The enterprise could ask to be included on the call. It would get location with the notification. The 9-1-1 people really believe that first getting to local (campus) security and then to 9-1-1 wastes time. They want the local security on the line in most cases, because they may be able to respond faster. "In an emergency, please contact" mechanisms are a part of what we call NG9-1-1 in North America. However, if the local access network returns a local URI for the local environment, the call will go there. If, in particular, the enterprise is authoritative for the local environment, even mobile carriers could get routing from it, and calls would go to the enterprise. I suspect not many carriers would permit that, but the system could support it. Brian _____ From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Monday, April 16, 2007 4:18 PM To: 'Mohammad Vakil'; ecrit@ietf.org Subject: RE: [Ecrit] enterprise requirements Has there been any work in this wg to address enterprise requirements. E.g. be able to allow on-premise security to tap E.911 call, know the location of the caller, or first route it to on-premise security, etc? There has been nothing to prevent such from happening. It should be an implementation and/of regulatory choice. -Marc- ------=_NextPart_000_1479_01C7835F.7C466B30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There will be a defined place to = put things that are specifically about a call, and about a location. =  In the case you are discussing, it’s probably additional information the location, so that any call from the enterprise, regardless of carrier or = caller gets the treatment.  The mechanism for additional information about location is another LoST service.  The resulting URI will point to = an XML data structure that defines all sorts of location related data, of which = this is one.  Building floor plans, elevator state, surveillance video, = etc will be included in this data structure as well as “In emergency, = please notify….”.  

 

The local security won’t be = able to “barge in”, but the call taker will be alerted that they request to be = added, and the system will be able to add them if the call taker agrees (there = is also an overriding per-PSAP policy decision that controls whether this = function is available).

 

The thing that is not defined is = the XML data structure.  I’m not sure yet where we will do this. =  If no better venue occurs, we will do it in NENA.

 

Brian

 

From: = Mohammad Vakil [mailto:mvakil@exchange.microsoft.com]
Sent: Friday, April 20, = 2007 2:49 PM
To: Brian Rosen; 'Marc = Linsner'; ecrit@ietf.org
Subject: RE: [Ecrit] = enterprise requirements

 

Brian, =

 <= /p>

Is there any one agreed upon = mechanism (or anything under discussion) for sending this = “notification” to the local enterprise security? And sending location along with this = “notification”? What if they want to also barge in an on-going call with PSAP? =

 <= /p>

I know there’re ways to = do these, but would be nice to agree on a way of doing this. =

 <= /p>

Thanks,=

-Mohammad =

 <= /p>

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: Monday, April 16, = 2007 1:31 PM
To: 'Marc Linsner'; = Mohammad Vakil; ecrit@ietf.org
Subject: RE: [Ecrit] = enterprise requirements

 

I think the direction we are going = will allow all of this.

 

The primary way I think this will = evolve in North America is to always send = the call direct to 9-1-1, and send a notification to the local enterprise.  = The enterprise could ask to be included on the call.  It would get = location with the notification.

 

The 9-1-1 people really believe = that first getting to local (campus) security and then to 9-1-1 wastes time. =  They want the local security on the line in most cases, because they may be = able to respond faster.  “In an emergency, please contact” = mechanisms are a part of what we call NG9-1-1 in North = America.

 

However, if the local access = network returns a local URI for the local environment, the call will go = there.  If, in particular, the enterprise is authoritative for the local = environment, even mobile carriers could get routing from it, and calls would go to = the enterprise.  I suspect not many carriers would permit that, but the = system could support it.

 

Brian

 

From: Marc = Linsner [mailto:mlinsner@cisco.com]
Sent: Monday, April 16, = 2007 4:18 PM
To: 'Mohammad Vakil'; ecrit@ietf.org
Subject: RE: [Ecrit] = enterprise requirements

 

 

=

 

Has there been any work in this wg to address enterprise requirements. E.g. = be able to allow on-premise security to tap E.911 call, know the location of the caller, or first route it to on-premise security, = etc? 

=

 

There has been nothing to prevent = such from happening.  It should be an implementation = and/of regulatory choice.

 

-Marc-

------=_NextPart_000_1479_01C7835F.7C466B30-- --===============2064007388== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============2064007388==-- From ecrit-bounces@ietf.org Fri Apr 20 15:27:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heylw-0005UH-0d; Fri, 20 Apr 2007 15:27:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heylu-0005LI-4N for ecrit@ietf.org; Fri, 20 Apr 2007 15:27:54 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heylt-0003bn-3s for ecrit@ietf.org; Fri, 20 Apr 2007 15:27:54 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1Heyl9-0004DK-Qx; Fri, 20 Apr 2007 14:27:08 -0500 From: "Brian Rosen" To: "'James M. Polk'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Consensus Call: Precise Location Information notavailable to End Host Date: Fri, 20 Apr 2007 15:27:47 -0400 Message-ID: <148301c78381$fcec1a60$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceDf+pmQiLCFB0/SlmpmvfZfZQJDwAATjUw In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This is more a question for NENA than IETF. There probably WILL be a Texas ESRP, and all locations in Texas probably will route to the Texas ESRP. The Texas ESRP will do another LoST dip using a different service that NENA will define. This service, which will only operate within the Emergency Services IP network where the ESRP is located, will return, possibly, a Tarrant County ESRP URI. The Tarrant County ESRP will do a similar operation and return the Colleyville URI. Each of the ESRPs will have to dereference the LbyR, and each will query LoST. The LIS will cache the dereference result, so its response will be fast. Actually, I suspect that Tarrant County will not operate an ESRP, and the Texas ESRP will route directly to Colleyville, but that is up to the Tarrant County 9-1-1 Authority. I know those guys, and they are up to speed on most of this already. You may very well have one of the first real "i3" installations (although the Harris County guys may beat you). Brian > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Friday, April 20, 2007 3:14 PM > To: Henning Schulzrinne > Cc: ECRIT > Subject: Re: [Ecrit] Consensus Call: Precise Location Information > notavailable to End Host > > Henning > > Please explain steps #4 & 5. How does a course location return the > Colleyville, Texas PSAP URI, or even the Tarrant county ESRP URI? > > I live in Colleyville, Texas, one of 47 cities in Tarrant County - > which contains Forth Worth (next to Dallas), for those wanting to > understand the references I'm using. Each city in Tarrant county has > a PSAP today. The metro area of Dallas/Ft. Worth (DFW) has an ERC > that answers all 911 cell calls due to non-compliance with wireless > phase I or II. > > In all this, I'm wondering how my state level precision (suggested > below as "the solution") gets my emergency call to where I want it to > before I or a family member dies. > > At 12:28 PM 4/20/2007, Henning Schulzrinne wrote: > >If the requirement goes away, either by regulation or by paying a > >fee, no harm is done. As I said, the UA won't even notice. Thus, I > >consider this as "insurance" - it allows us to move forward and close > >our documents, rather than speculate what may or may not happen a > >year or two or five down the road. Your guess may well be right, but > >it remains, like my predictions on the ability to monetize location > >information, a prediction with high uncertainty. We all want to see > >IP-based emergency calling deployed sooner rather than after years of > >regulatory fights, particularly fights where the deck is stacked not > >necessarily in the consumer's favor. This is a (very small) > >contribution to removing one item to fight over. > > > >If there were huge (complexity or infrastructure) costs associated > >with the proposal, I would share your concerns. But there aren't, as > >far as I can tell. > > > >Henning > > > >On Apr 20, 2007, at 1:08 PM, James M. Polk wrote: > > > >>Henning > >> > >>Doesn't this center around either location is given to the client > >>for free or for fee? > >> > >>If we agree there can be a fee, even if hidden (because service > >>customers always end up paying for everything explicitly or > >>implicitly), doesn't this "requirement" go away in most people's > >>minds? > >> > >>This was the point of Barbara last week - that AT&T is not going to > >>deliver location for free. I don't think anyone I'm aware of > >>suggested this infrastructure be put in place for free, to be used > >>by other service companies for their use only. > >> > >>At 12:00 PM 4/20/2007, Henning Schulzrinne wrote: > >>>James, > >>> > >>>I'm no friend of location hiding, as I've made amply clear, but I was > >>>trying to find a solution that does not actually impose any new > >>>requirements on user agents nor makes life more expensive for the > >>>rest of the world. > >>> > >>>So far, all the alternatives I've seen either yield non-interoperable > >>>islands or impose cost shifting, where innocent third parties pay for > >>>the business decisions of the ISP. I'd like the requirement to go > >>>away, but it has apparently been a very convenient rationale for not > >>>playing along with the whole ECRIT architecture. > >>> > >>>Henning > >>> > >>>On Apr 20, 2007, at 12:27 PM, James M. Polk wrote: > >>> > >>>>Hannes > >>>> > >>>>What you are detailing is a technical solution to a business > >>>>decision, not a technical solution to a technical problem/ > >>>>requirement. I am opposed to this compromise (i.e. cave). > >>>> > >>>>At 03:50 AM 4/20/2007, Hannes Tschofenig wrote: > >>>>>Hi all, > >>>>>let me try it again (I got it wrong in my previous mail). > >>>>>Henning and Brian suggested an approach that * works nicely with > >>>>>the emergency services architecture we > >>>>>investigated over the past few years, and > >>>>>* addresses the case where a network operator does not want to > >>>>>disclose precise location information. > >>>>>Here is the procedure: > >>>>> > >>>>>1. The endpoint uses an LCP to request location. The LIS returns > >>>>>an LbyR > >>>>>2. The endpoint dereferences the LbyR. > >>>>>3. The LIS, noticing that the dereference request is from the > >>>>>endpoint (or > >>>>>at least not from any entity that is entitled to get fine grained > >>>>>location), > >>>>>takes the fine grained location and uses LoST to determine the > >>>>>PSAP that > >>>>>serves that location. > >>>>>4. The LIS returns to the endpoint a location which, if submitted > >>>>>to LoST, > >>>>>would return the same PSAP URI the fine grained location would. > >>>>>In some > >>>>>circumstances, this could be a civic with only a country. An > >>>>>alternative > >>>>>that works for all circumstances is to return the polygon that > >>>>>defines the > >>>>>service boundary of the PSAP (which LoST can return). Is > >>>>>essential that the > >>>>>PSAP URI returned from a LoST query with whatever the LIS gives > >>>>>the endpoint > >>>>>would be the same PSAP URI any querier using the fine grained > >>>>>location would > >>>>>get. > >>>>>5. The endpoint uses the (coarse) location value it obtains to > >>>>>query LoST. > >>>>>It gets the (correct) PSAP URI > >>>>>6. This is repeated at call time. The endpoint has a valid LbyR > >>>>>and a valid > >>>>>PSAP URI, which it uses to construct the emergency call > >>>>>7. A VSP wishing to validate the PSAP URI takes the LbyR and > >>>>>dereferences > >>>>>it. The result will be the same (coarse) location the endpoint > >>>>>got. The > >>>>>VSP does a LoST query with that location, and should get the same > >>>>>PSAP URI > >>>>>that is in the Request URI on the call. This validation works for > >>>>>coarse or > >>>>>fine validation, and of course works for LbyV without the > >>>>>dereference step. > >>>>>8. The PSAP (or ESRP) which is the target of the PSAP URI gets the > >>>>>call. It > >>>>>dereferences the LbyR but gets the fine grained location; the LIS > >>>>>must have > >>>>>a relationship with the ESRP/PSAP to assure this. > >>>>>9. Any succeeding ESRPs or PSAPs can also dereference and get fine > >>>>>grained > >>>>>location. > >>>>> > >>>>>QUESTION: Is this approach acceptable for you? > >>>>>Ciao > >>>>>Hannes > >>>>> > >>>>> > >>>>> > >>>>>_______________________________________________ > >>>>>Ecrit mailing list > >>>>>Ecrit@ietf.org > >>>>>https://www1.ietf.org/mailman/listinfo/ecrit > >>>> > >>>>_______________________________________________ > >>>>Ecrit mailing list > >>>>Ecrit@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 15:51:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hez8T-00080m-Vq; Fri, 20 Apr 2007 15:51:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hez7x-0006fh-FM for ecrit@ietf.org; Fri, 20 Apr 2007 15:50:42 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hez7n-0007P4-0S for ecrit@ietf.org; Fri, 20 Apr 2007 15:50:41 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 20 Apr 2007 15:50:30 -0400 id 0158837C.46291986.00001871 In-Reply-To: <46287EB9.7060006@gmx.net> References: <46287EB9.7060006@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host Date: Fri, 20 Apr 2007 15:50:28 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org After having some more time to noodle on this... On Apr 20, 2007, at 4:50 AM, Hannes Tschofenig wrote: > 7. A VSP wishing to validate the PSAP URI takes the LbyR and > dereferences > it. The result will be the same (coarse) location the endpoint > got. The > VSP does a LoST query with that location, and should get the same > PSAP URI > that is in the Request URI on the call. This validation works for > coarse or > fine validation, and of course works for LbyV without the > dereference step. This works without modification of LoST for civic, but I think it requires a modification of LoST for geo. The LoST geodetic-2d location profile takes a point as input, not an area. That being said, I'm willing to live with the change to LoST to accommodate this requirement. We could create a new location profile or modify geodetic-2d, but then every geodetic (or non-civic) location profile would have to accommodate this use case. If we are to do this, I'd rather have a more generic mechanism that requires no changes to location profiles by re-using the service boundary reference. Such a service boundary reference could be conveyed in a PIDF-LO in a new element. That also allows LoST resolvers to optimize their lookup to a simple key vs. the more complex location information. The VSP wouldn't use the query for policing, but the query. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 16:20:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hezas-0004sX-Rm; Fri, 20 Apr 2007 16:20:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hezar-0004sM-Mu for ecrit@ietf.org; Fri, 20 Apr 2007 16:20:33 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hezar-0000js-Dr for ecrit@ietf.org; Fri, 20 Apr 2007 16:20:33 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3KKKPEQ026605 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Apr 2007 16:20:25 -0400 (EDT) In-Reply-To: References: <46287EB9.7060006@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host Date: Fri, 20 Apr 2007 16:21:43 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org We had talked about a more generic 2D polygon description earlier, primarily for wireless cases, so we may just get to do it now rather than later. We already have the necessary location profile (polygon), as it is used for the boundary. I don't see how re-using the service boundary reference helps. The UA still has to understand the reference and polygon. Can you describe exactly how this would work? I'd rather avoid special-casing this particular use case ("do one thing when you get a reference to a point, do something completely different when you get a reference to a polygon"). On Apr 20, 2007, at 3:50 PM, Andrew Newton wrote: > After having some more time to noodle on this... > > On Apr 20, 2007, at 4:50 AM, Hannes Tschofenig wrote: > >> 7. A VSP wishing to validate the PSAP URI takes the LbyR and >> dereferences >> it. The result will be the same (coarse) location the endpoint >> got. The >> VSP does a LoST query with that location, and should get the same >> PSAP URI >> that is in the Request URI on the call. This validation works for >> coarse or >> fine validation, and of course works for LbyV without the >> dereference step. > > This works without modification of LoST for civic, but I think it > requires a modification of LoST for geo. The LoST geodetic-2d > location profile takes a point as input, not an area. > > That being said, I'm willing to live with the change to LoST to > accommodate this requirement. We could create a new location > profile or modify geodetic-2d, but then every geodetic (or non- > civic) location profile would have to accommodate this use case. > If we are to do this, I'd rather have a more generic mechanism that > requires no changes to location profiles by re-using the service > boundary reference. Such a service boundary reference could be > conveyed in a PIDF-LO in a new element. That also allows LoST > resolvers to optimize their lookup to a simple key vs. the more > complex location information. The VSP wouldn't use the > query for policing, but the query. > > -andy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 16:24:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HezeF-0006As-DB; Fri, 20 Apr 2007 16:24:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HezeD-0006Ad-RL for ecrit@ietf.org; Fri, 20 Apr 2007 16:24:01 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HezeC-0001Gs-C0 for ecrit@ietf.org; Fri, 20 Apr 2007 16:24:01 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Apr 2007 16:23:31 -0400 X-IronPort-AV: i="4.14,433,1170651600"; d="scan'208"; a="119093883:sNHT2080215260" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3KKNVZu019801; Fri, 20 Apr 2007 16:23:31 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3KKNMlY009082; Fri, 20 Apr 2007 20:23:26 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 16:23:11 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.20.40]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Apr 2007 16:23:10 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 20 Apr 2007 15:23:09 -0500 To: Richard Barnes , ECRIT From: "James M. Polk" Subject: Re: [Ecrit] An alternative proposal In-Reply-To: <4628FD3E.5080009@bbn.com> References: <4628FD3E.5080009@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 20 Apr 2007 20:23:10.0551 (UTC) FILETIME=[B6E41E70:01C78389] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4971; t=1177100611; x=1177964611; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20An=20alternative=20proposal |Sender:=20 |To:=20Richard=20Barnes=20,=20ECRIT=20; bh=h8zX01aXdABj7WHMnMm/SChACNcbCa3/dG7ePR4Sk9M=; b=KMsyoq7DHl8+eoPUXpUW+o3ak+7+UbLSLK5QoHI7tT/QWitM5pEA9YbXc8hGQ4RCOnao3pqe M8kYvVJU/4jgsavuNrwaNmYY/jqvCSG/Q4lfu/irk9a/T0i9fX9T/U4c; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org this should be in a draft, to give the WG the ability to focus and comment on a fixed target (the contents of the ID) and not a moving thread that can change as often as the wind James At 12:49 PM 4/20/2007, Richard Barnes wrote: >Using LbyR to provision location raises two problems that I'd like >to address separately: >1. Endpoint acquisition of a appropriate PSAP URI, and >2. VSP verification of a supposed PSAP URI. > >Henning's requirements 1,2,4,6 apply to problem 1, and 3,4,5,6 apply >to problem 2. > >===== Endpoint acquisition of a appropriate PSAP URI ===== >Proposal 1(a): Extend LoST to carry LbyR. >Proposal 1(b): Require that every LIS act as a LoST server for >endpoints that it serves. > >[Proposal 1(b) could be softened with "... or explicitly delegate to >a LoST server that is authorized to dereference, e.g., with an SIP >or HTTP 3xx response"]. > >Scenario: >1. The endpoint uses an LCP to request location. >2. The LIS returns an LbyR. >3. The endpoint sends a LoST query to the LIS containing this LbyR. >4. The LIS does the same LoST query, but with LbyR replaced with LbyV. >5. The LIS sends the LoST response back to the endpoint. > >Call flow: >Client LIS LoST > | LCP Req. | | > |----------->| | > | LbyR | | > |<-----------| | > | LoST/LbyR | | > |----------->| | > | | LoST/LbyV | > | |-------------->| > | | LoST Resp. | > | |<--------------| > | Lost Resp. | | > |<-----------| | > | | | > >Requirements: >3. No magic configuration for UAs. >No configuration necessary beyond LIS discovery. > >4. Multiple LoST server hierarchies, with resolvers that have no >trust relationship with the PSAP or the ISP. >Depends on your semantics. The endpoint effectively uses the LIS as >a resolver, but beyond that there are no extraordinary trust >relationships. In the "rough location" proposal, the client >implicitly trusts the LIS to LoST anyway; this just makes it explicit. > >5. Minimal impact on UAs; in particular, fail-and-try-something-else >is not acceptable. >Not sure what this means in this case. > >6. Bonus points for avoiding modifications to LoST, SIP location >conveyance, DHCP. >This only requires a small modification to LoST, so it's pretty >straightforward, but no bonus points. > > > > >===== VSP verification of a supposed PSAP URI ===== >There are two questions a VSP could ask: >1. Is this URI the URI of any PSAP? >2. Is this URI the URI of the PSAP that this UA should be calling? > >Note that the first question is independent of whether location is >carried byV or byR, and thus a much simpler mechanism could be used >to answer it. >Proposal 2: Introduce a Reverse-LoST protocol that accepts a PSAP >URI as input and returns a service area (or even just a boolean). > >Requirements: >1. No business or trust relationship between ISPs and VSPs >None required. > >2. VSPs can be outside the jurisdiction of the PSAP and can be Joe's >Bakery and Car Repair. >Anyone can do the verification, so in particular, Joe's Bakery and >Car Repair can. > >4. Multiple LoST server hierarchies, with resolvers that have no >trust relationship with the PSAP or the ISP. >No trust relationships necessary, as no sensitive data is passed. > >6. Bonus points for avoiding modifications to LoST, SIP location >conveyance, DHCP. >I guess this one gets bonus points, but at the expense of a new protocol. > > >IMHO, the first question is the only reasonable one to support: >1. It is not the role of the VSP to distinguish among emergency >calls; that's the job of the routing infrastructure. It's entirely >possible for this verification to fail because the endpoint has >crossed into a neighboring PSAP coverage area, and I think we agree >that the call shouldn't fail in this case. >2. Trying to support the second question often leads to unacceptable >privacy consequences. The privacy risks incurred by the "rough >location" proposal are due to the fact that it tries to answer the >second question: Since VSPs can be (effectively) anyone, the LIS has >to give out location to everyone in order for VSPs to be able to use >location for this purpose. > >It's tempting to say that either question could be answered by a >query to the LoST function of the LIS, or via LoST/LbyR, with some >LoST server authenticating itself to the LIS, but both of these >introduce the same privacy risks as the "rough location" proposal. > > > > > > > > > > > > > > > > > > > > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 16:30:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hezk0-0002UJ-Fp; Fri, 20 Apr 2007 16:30:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HezF9-0007iv-Ab for ecrit@ietf.org; Fri, 20 Apr 2007 15:58:07 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hez9D-00081f-4g for ecrit@ietf.org; Fri, 20 Apr 2007 15:52:11 -0400 Received: from ([139.76.131.87]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.175558764; Fri, 20 Apr 2007 15:51:40 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 20 Apr 2007 15:51:39 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 20 Apr 2007 15:51:39 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Consensus Call: Precise Location Information not available to End Host Date: Fri, 20 Apr 2007 15:51:38 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA03B0FA03@crexc41p> In-Reply-To: <46287EB9.7060006@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Consensus Call: Precise Location Information not available to End Host thread-index: AceDKdTANiMuFJJbReSkXpBojm4sLAAWtRlw References: <46287EB9.7060006@gmx.net> From: "Stark, Barbara" To: "Hannes Tschofenig" ,"ECRIT" X-OriginalArrivalTime: 20 Apr 2007 19:51:39.0551 (UTC) FILETIME=[4FC46AF0:01C78385] X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This is ok for me. Barbara=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Friday, April 20, 2007 4:50 AM To: ECRIT Subject: [Ecrit] Consensus Call: Precise Location Information not available to End Host Hi all,=20 let me try it again (I got it wrong in my previous mail).=20 Henning and Brian suggested an approach that * works nicely with the emergency services architecture we investigated over the past few years, and * addresses the case where a network operator does not want to disclose precise location information.=20 Here is the procedure: 1. The endpoint uses an LCP to request location. The LIS returns an LbyR 2. The endpoint dereferences the LbyR. =20 3. The LIS, noticing that the dereference request is from the endpoint (or at least not from any entity that is entitled to get fine grained location), takes the fine grained location and uses LoST to determine the PSAP that serves that location. 4. The LIS returns to the endpoint a location which, if submitted to LoST, would return the same PSAP URI the fine grained location would. In some circumstances, this could be a civic with only a country. An alternative that works for all circumstances is to return the polygon that defines the service boundary of the PSAP (which LoST can return). Is essential that the PSAP URI returned from a LoST query with whatever the LIS gives the endpoint would be the same PSAP URI any querier using the fine grained location would get. 5. The endpoint uses the (coarse) location value it obtains to query LoST. It gets the (correct) PSAP URI 6. This is repeated at call time. The endpoint has a valid LbyR and a valid PSAP URI, which it uses to construct the emergency call 7. A VSP wishing to validate the PSAP URI takes the LbyR and dereferences it. The result will be the same (coarse) location the endpoint got. The VSP does a LoST query with that location, and should get the same PSAP URI that is in the Request URI on the call. This validation works for coarse or fine validation, and of course works for LbyV without the dereference step. 8. The PSAP (or ESRP) which is the target of the PSAP URI gets the call. It dereferences the LbyR but gets the fine grained location; the LIS must have a relationship with the ESRP/PSAP to assure this. 9. Any succeeding ESRPs or PSAPs can also dereference and get fine grained location. QUESTION: Is this approach acceptable for you?=20 Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA623 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 16:35:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HezpM-0006MH-Pa; Fri, 20 Apr 2007 16:35:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HezpK-0006M7-C0 for ecrit@ietf.org; Fri, 20 Apr 2007 16:35:30 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HezpJ-0004Ul-4B for ecrit@ietf.org; Fri, 20 Apr 2007 16:35:30 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3KKZKps008741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Apr 2007 16:35:20 -0400 (EDT) In-Reply-To: <4628FD3E.5080009@bbn.com> References: <4628FD3E.5080009@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <730D0441-E19F-4092-BDEF-4905947C0AC3@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] An alternative proposal Date: Fri, 20 Apr 2007 16:36:39 -0400 To: Richard Barnes X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'll split my response in two, since there are two problems. On Apr 20, 2007, at 1:49 PM, Richard Barnes wrote: > > ===== VSP verification of a supposed PSAP URI ===== > There are two questions a VSP could ask: > 1. Is this URI the URI of any PSAP? > 2. Is this URI the URI of the PSAP that this UA should be calling? > > Note that the first question is independent of whether location is > carried byV or byR, and thus a much simpler mechanism could be used > to answer it. > Proposal 2: Introduce a Reverse-LoST protocol that accepts a PSAP > URI as input and returns a service area (or even just a boolean). This can be done, but requires significant, non-trivial extensions to LoST, unlike the existing proposal summarized by Brian and Hannes. So far, the only concrete proposal along these lines that has more than handwaving behind it is to flood all PSAP URLs, at least within a single tree. > > 6. Bonus points for avoiding modifications to LoST, SIP location > conveyance, DHCP. > I guess this one gets bonus points, but at the expense of a new > protocol. > LoST modifications are required. > > IMHO, the first question is the only reasonable one to support: > 1. It is not the role of the VSP to distinguish among emergency > calls; that's the job of the routing infrastructure. It's entirely > possible for this verification to fail because the endpoint has > crossed into a neighboring PSAP coverage area, and I think we agree > that the call shouldn't fail in this case. > 2. Trying to support the second question often leads to > unacceptable privacy consequences. The privacy risks incurred by > the "rough location" proposal are due to the fact that it tries to > answer the second question: Since VSPs can be (effectively) anyone, > the LIS has to give out location to everyone in order for VSPs to > be able to use location for this purpose. As has been stated many times before, the privacy content of the PSAP URL and the boundary are exactly the same. In other words, as soon as an emergency call reaches the VSP, the VSP can determine that the caller is in the coverage area of the PSAP. Nothing new here. > > It's tempting to say that either question could be answered by a > query to the LoST function of the LIS, or via LoST/LbyR, with some > LoST server authenticating itself to the LIS, but both of these > introduce the same privacy risks as the "rough location" proposal. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 16:39:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hezt2-000265-RV; Fri, 20 Apr 2007 16:39:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hezt1-00025Z-Np for ecrit@ietf.org; Fri, 20 Apr 2007 16:39:19 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hezt1-0005cM-GV for ecrit@ietf.org; Fri, 20 Apr 2007 16:39:19 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3KKdA10019184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Apr 2007 16:39:11 -0400 (EDT) In-Reply-To: <4628FD3E.5080009@bbn.com> References: <4628FD3E.5080009@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6B1313E5-2B92-49BC-8991-321CB90347C2@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] An alternative proposal Date: Fri, 20 Apr 2007 16:40:28 -0400 To: Richard Barnes X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 20, 2007, at 1:49 PM, Richard Barnes wrote: > Using LbyR to provision location raises two problems that I'd like > to address separately: > 1. Endpoint acquisition of a appropriate PSAP URI, and > 2. VSP verification of a supposed PSAP URI. > > Henning's requirements 1,2,4,6 apply to problem 1, and 3,4,5,6 > apply to problem 2. > > ===== Endpoint acquisition of a appropriate PSAP URI ===== > Proposal 1(a): Extend LoST to carry LbyR. This, as I've tried to explain to you numerous times, serves no purpose. > Proposal 1(b): Require that every LIS act as a LoST server for > endpoints that it serves. This violates the requirement that LoST servers can be operated by multiple, independent entities. > > [Proposal 1(b) could be softened with "... or explicitly delegate > to a LoST server that is authorized to dereference, e.g., with an > SIP or HTTP 3xx response"]. This requires, as I've stated several times before, that LoST servers know about each other. They don't. If I contact the LoST server operated by my VSP, it has no clue about my ISP or its favored LoST server. Thus, this violates the 'no trust/business relationship between ISP and VSP' requirement and is thus disqualified. > > Scenario: > 1. The endpoint uses an LCP to request location. > 2. The LIS returns an LbyR. > 3. The endpoint sends a LoST query to the LIS containing this LbyR. > 4. The LIS does the same LoST query, but with LbyR replaced with LbyV. > 5. The LIS sends the LoST response back to the endpoint. > > Call flow: > Client LIS LoST > | LCP Req. | | > |----------->| | > | LbyR | | > |<-----------| | > | LoST/LbyR | | > |----------->| | > | | LoST/LbyV | > | |-------------->| > | | LoST Resp. | > | |<--------------| > | Lost Resp. | | > |<-----------| | > | | | > > Requirements: > 3. No magic configuration for UAs. > No configuration necessary beyond LIS discovery. > > 4. Multiple LoST server hierarchies, with resolvers that have no > trust relationship with the PSAP or the ISP. > Depends on your semantics. The endpoint effectively uses the LIS > as a resolver, but beyond that there are no extraordinary trust > relationships. In the "rough location" proposal, the client > implicitly trusts the LIS to LoST anyway; this just makes it explicit. > > 5. Minimal impact on UAs; in particular, fail-and-try-something- > else is not acceptable. > Not sure what this means in this case. > > 6. Bonus points for avoiding modifications to LoST, SIP location > conveyance, DHCP. > This only requires a small modification to LoST, so it's pretty > straightforward, but no bonus points. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 17:04:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf0HO-00034T-56; Fri, 20 Apr 2007 17:04:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf0HN-00034K-3R for ecrit@ietf.org; Fri, 20 Apr 2007 17:04:29 -0400 Received: from mail.skype.net ([193.88.6.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf0HL-00045r-Id for ecrit@ietf.org; Fri, 20 Apr 2007 17:04:29 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 2CB67110167; Fri, 20 Apr 2007 23:03:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-M-Ieqtv0v2; Fri, 20 Apr 2007 23:03:43 +0200 (CEST) Received: from [10.254.233.35] (unknown [216.113.168.141]) by mail.skype.net (Postfix) with ESMTP id CB3EE11016F; Fri, 20 Apr 2007 23:03:42 +0200 (CEST) User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 20 Apr 2007 14:04:17 -0700 Subject: Re: [Ecrit] Re: Ecrit Digest, Vol 27, Issue 30 From: Andres K=?ISO-8859-1?B?/A==?=tt To: Hannes Tschofenig Message-ID: Thread-Topic: [Ecrit] Re: Ecrit Digest, Vol 27, Issue 30 Thread-Index: AceDj3UCs2NieO+CEduWpgAX8i4icA== In-Reply-To: <4627BDF5.9050605@gmx.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi, Thank you for answers, have still some comments On 4/19/07 12:07 PM, "Hannes Tschofenig" wrote: >>> 1) Provide enough location information so that the emergency call can be >>> routed to the correct PSAP. Precise location information would be >>> provided to the PSAP. >>> This approach was already discussed on the list. We need feedback from, >>> for example, Barbara and Laura whether they feel comfortable with this >>> approach. >>> >>> CONSEQUENCE: No changes needed. >>> >> This implies that the access provider knows how much information is needed >> to determine the PSAP which in turn implies that the it also knows about >> PSAP topology. Can we make that assumption? >> >> > Yes; I believe we can make this assumption. For APs, this assumption does not hold. How would a $50 wifi AP know of PSAPs? >>> 5) Emergency calls are routed via the SIP proxy of the VSP and >>> subsequently via a SIP proxy in the ASP/ISP (redirect mode) >>> SIP Location Conveyance would be used instead of GEOPRIV L7 LCP >>> Assumption: No service level agreement (or business agreement) between >>> VSP and ISP/ASP for this type of SIP emergency message routing required. >>> >>> >>> CONSEQUENCE: No changes needed. Potential problems with SIP Identity >>> possible >>> >> This does not work with devices that do not use SIP on the client side. Like >> yours truly. >> >> > That's true. I should have added this part. > > The challenge is that for unauthenticated network access you need to > implement one protocol anyway, very likely SIP, since otherwise you > introduce EXTREMELY HUGE security vulnerabilities. Not really. We can either assume some internal built-in identity or enable certain functionality without the client being logged in. This has nothing to do with the protocol that is used. >>> 7) Decoupled authentication for SIP message routing >>> Authentication exchange between the end host and the VSP (e.g., TLS to >>> obtain a SAML assertion) >>> Authentication credentials are then added to the SIP emergency message >>> that is routed via the SIP proxy in the VSP/ISP. >>> No service level agreement (or business agreement) between VSP and >>> ISP/ASP needed. >>> >>> CONSEQUENCE: Security extension for this purpose needs to be progressed >>> (already available in draft form) >>> >> Do not understand this. The calling infrastructure needs to be authenticated >>> from end to end anyway if any sort of billing is to happen? >> >> > The end host / user is authenticated with a mechanism independent of SIP > and then the receipt of that authentication action is added to the > emergency call for consumption at the PSAP (to provide him some identity > information). This is only true for unauthenticated user as for everybody else a VSP always has an authentication mechanism in place (and thus it does not need to be described in a standard) and can forward it to PSAP. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 17:23:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf0ZN-0006Qh-DZ; Fri, 20 Apr 2007 17:23:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf0ZM-0006Np-7P; Fri, 20 Apr 2007 17:23:04 -0400 Received: from mail.skype.net ([193.88.6.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf0ZJ-0002Im-UX; Fri, 20 Apr 2007 17:23:04 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id B026511016B; Fri, 20 Apr 2007 23:22:18 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUDRLgbYSwbw; Fri, 20 Apr 2007 23:22:16 +0200 (CEST) Received: from [10.254.233.35] (unknown [216.113.168.141]) by mail.skype.net (Postfix) with ESMTP id 63A93110168; Fri, 20 Apr 2007 23:22:15 +0200 (CEST) User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 20 Apr 2007 14:22:49 -0700 From: Andres K=?ISO-8859-1?B?/A==?=tt To: , Message-ID: Thread-Topic: Ecrit Digest, Vol 27, Issue 50 Thread-Index: AceDkgvQSnueJe+FEduWpgAX8i4icA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: dabfd8cc2c196ec56401c44f64d155c2 Subject: [Ecrit] Re: Ecrit Digest, Vol 27, Issue 50 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Yes, As long as other flows (an AP knowing exactly where it is and broadcasting that information) are possible, the suggestion makes sense. Yours, Andres On 4/20/07 7:36 AM, "ecrit-request@ietf.org" wrote= : > Send Ecrit mailing list submissions to > ecrit@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/ecrit > or, via email, send a message with subject or body 'help' to > ecrit-request@ietf.org >=20 > You can reach the person managing the list at > ecrit-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ecrit digest..." >=20 >=20 > Today's Topics: >=20 > 1. Re: Re: [Geopriv] Soliciting Feedback: (Partial) > LocationHiding Emergency Services Architecture (Henning Schulzrinne= ) > 2. Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto > doendpoint centric LCP without giving away the store > (Henning Schulzrinne) > 3. Consensus Call: Precise Location Information not available to > End Host (Hannes Tschofenig) > 4. AW: [Ecrit] Consensus Call: Precise Location Information not > available to End Host (Liess, Laura) > 5. RE: Consensus Call: Precise Location Information notavailable > to End Host (Brian Rosen) > 6. Please remove my name -UNSUBSCRIBE (Beyer, Loraine) > 7. RE: Re: [Geopriv] Soliciting Feedback: > (Partial)LocationHiding Emergency Services Architecture > (Stark, Barbara) > 8. AW: [Ecrit] Consensus Call: Precise Location Information > notavailable to End Host (Liess, Laura) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Thu, 19 Apr 2007 19:42:12 -0400 > From: Henning Schulzrinne > Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial) > LocationHiding Emergency Services Architecture > To: Ted Hardie > Cc: 'ECRIT' > Message-ID: <9A60EA48-FABA-41CA-B1EC-27FCF15F7F6C@cs.columbia.edu> > Content-Type: text/plain; charset=3DUS-ASCII; delsp=3Dyes; format=3Dflowed >=20 >>=20 >=20 > Based on my experience, there are two kinds of test calls: >=20 > - automatic: done to verify NAT operation, LoST lookups and such; > nothing is reported unless there's a problem; done fairly regularly > when network conditions change; no human interaction. >=20 > - manual: explicitly invoked by the user; for example, done when > moving into a new house. There is no ringback or anything else - the > user picks up the phone, clicks on the "test emergency call" link and > gets information back, similar to the test numbers that regular phone > service has (including such numbers as 1 700 555.4141 [http:// > www.cs.columbia.edu/~hgs/internet/telephone.html]). >=20 > For example, when we installed our new departmental PBX, we wanted to > make sure 911 worked and delivered the right number and location to > the PSAP. We had to call the "real" 911, which our sys admin did with > great trepidation. >=20 >=20 >> Do you believe, then, that the user has to be aware of the test >> call, and responsive >> during it? That's very different from the way the BCP seems to be >> written now, >> and I suspect there are some pretty scaly dragons there. If, at a >> random interval, >> the phone rings and reports on the status of a pseudo-911 call, I >> think users >> are going to be surprised and may be alarmed. I'd rather leave it >> as something >> where the phone confirms that the test works and stores the >> outcome, so that a >> user may review it and make corrections if needed. But that means >> storing >> time and date along with the test call info (imagine someone saying, >> "I'm at 3 Wall Street, and this thing believes I'm at JFK" where it >> really meant >> that the most recent test call was when the user was at the airport). >>=20 >>=20 >> I think we should assume that the typical test call will be >> unattended. How >> far off the consensus am I on that? >>=20 >=20 > See above; we need both. >=20 >>> Thus, I believe that this mechanism adds significantly to the >>> overall reliability of the system and we should encourage that it >>> be provided, whether as location-conveyance, audio or just a PIDF- >>> LO attachment in the 200 OK. (This generally won't work well, >>> given the difficulty real phones have with multipart, but that's a >>> different topic.) >>=20 >> I think incorporating it into the response to the 200 OK is the >> best way forward, >> and that making it part of the text actually relieves some of the >> location hiding >> concerns (since the information would need to be scraped from there >> into other >> applications). >=20 > I don't know what you have in mind. I'm sure you are not proposing to > put it as >=20 > 200 OK (123 Main Street) >=20 > Putting it in plain text as a body (text/plain) isn't likely to deter > scraping unless it is so obfuscated that it confuses humans, too. > Plus, you lose the ability to know which elements are actually > populated, so that a correct-looking address is actually unusable for > routing or dispatch. For example, showing >=20 > Room 123 456 Corporate Plaza > Anytown CA 01234 >=20 > can still have "Room 123" show up in the street address field in PIDF- > LO, even though the text "looks" ok. >=20 > Plus, text isn't too useful for an ATA (terminal adapter) device. It > can't show the text, since it has no display. >=20 > Henning >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > ------------------------------ >=20 > Message: 2 > Date: Thu, 19 Apr 2007 20:04:27 -0400 > From: Henning Schulzrinne > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto > doendpoint centric LCP without giving away the store > To: "Dawson, Martin" > Cc: GEOPRIV , ECRIT > Message-ID: > Content-Type: text/plain; charset=3DUS-ASCII; delsp=3Dyes; format=3Dflowed >=20 >=20 > On Apr 19, 2007, at 6:17 PM, Dawson, Martin wrote: >=20 >> OK I see... >>=20 >> If we're talking about VSPs (which I didn't think were necessary for >> ECRIT) then I agree. However, that's the same challenge that i2 has - >> except it's not just a routing question, it has to go to the right VPC >> so the PSAP can get the location information from it out of band. >=20 > As per our definitions, VSPs could be something like a corporation or > university campus, not necessarily an operator such as SunRocket, > Verizon or Vonage. As noted before, a LoST server could also be > operated by an independent party, just like STUN servers are today > (e.g., http://www.stunserver.org/). >=20 >=20 >=20 >=20 >>=20 >> If this is the only scenario we are talking about, then I still think >> there are less convoluted solutions from the perspective of the >> device. >>=20 >> How about the "resolver" does a dereference and the LIS, realizing >> it's >> not an authorized requestor, just returns a country code. Or there may >=20 > That's roughly what happens in the proposal, except that the query is > done by the UA. But that doesn't solve the problem of finding the > right PSAP and doesn't seem to change the problems leading to the > currently-proposed solution. >=20 >> actually be standard HTTP (for example) error constructs that would >> provide the equivalent information. Or, as I tentatively suggested, a >> convention for the URL construction could indicate the jurisdiction >> - or >> the LIS request could include a URL and a bare bones PIDF-LO (both of >> which eliminate the additional transaction altogether). I don't think >> any of those proposals require changes to existing specifications >> either >> (apart from LoST doing the dereference). >=20 > My general perception is that encoding information into URLs (not > URNs) is considered a hack, as they are supposed to be opaque to the > HTTP client. >=20 >=20 >=20 >>=20 >> Anyway, my response stands. I could live with the solution but it >> feels >> unnecessarily convoluted. >=20 >>=20 >> Cheers, >> Martin >>=20 >=20 >=20 >=20 >=20 > ------------------------------ >=20 > Message: 3 > Date: Fri, 20 Apr 2007 10:50:01 +0200 > From: Hannes Tschofenig > Subject: [Ecrit] Consensus Call: Precise Location Information not > available to End Host > To: ECRIT > Message-ID: <46287EB9.7060006@gmx.net> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >=20 > Hi all,=20 >=20 > let me try it again (I got it wrong in my previous mail). >=20 > Henning and Brian suggested an approach that > * works nicely with the emergency services architecture we > investigated over the past few years, and > * addresses the case where a network operator > does not want to disclose precise location information. >=20 > Here is the procedure: >=20 > 1. The endpoint uses an LCP to request location. The LIS returns an LbyR > 2. The endpoint dereferences the LbyR. > 3. The LIS, noticing that the dereference request is from the endpoint (o= r > at least not from any entity that is entitled to get fine grained locatio= n), > takes the fine grained location and uses LoST to determine the PSAP that > serves that location. > 4. The LIS returns to the endpoint a location which, if submitted to LoST= , > would return the same PSAP URI the fine grained location would. In some > circumstances, this could be a civic with only a country. An alternative > that works for all circumstances is to return the polygon that defines th= e > service boundary of the PSAP (which LoST can return). Is essential that = the > PSAP URI returned from a LoST query with whatever the LIS gives the endpo= int > would be the same PSAP URI any querier using the fine grained location wo= uld > get. > 5. The endpoint uses the (coarse) location value it obtains to query LoST= . > It gets the (correct) PSAP URI > 6. This is repeated at call time. The endpoint has a valid LbyR and a va= lid > PSAP URI, which it uses to construct the emergency call > 7. A VSP wishing to validate the PSAP URI takes the LbyR and dereferences > it. The result will be the same (coarse) location the endpoint got. The > VSP does a LoST query with that location, and should get the same PSAP UR= I > that is in the Request URI on the call. This validation works for coarse= or > fine validation, and of course works for LbyV without the dereference ste= p. > 8. The PSAP (or ESRP) which is the target of the PSAP URI gets the call. = It > dereferences the LbyR but gets the fine grained location; the LIS must ha= ve > a relationship with the ESRP/PSAP to assure this. > 9. Any succeeding ESRPs or PSAPs can also dereference and get fine graine= d > location. >=20 > QUESTION: Is this approach acceptable for you? >=20 > Ciao > Hannes >=20 >=20 >=20 >=20 >=20 > ------------------------------ >=20 > Message: 4 > Date: Fri, 20 Apr 2007 12:31:54 +0200 > From: "Liess, Laura" > Subject: AW: [Ecrit] Consensus Call: Precise Location Information not > available to End Host > To: , > Message-ID: > <182C63BFBAF131428EA0C16F7FD2191B013584D1@S4DE8PSAAGM.mitte.t-com.de> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > =20 > Hi, >=20 >> Here is the procedure: >>=20 >> 1. The endpoint uses an LCP to request location. The LIS >> returns an LbyR 2. The endpoint dereferences the LbyR. >> 3. The LIS, noticing that the dereference request is from the >> endpoint (or at least not from any entity that is entitled to >> get fine grained location), takes the fine grained location >> and uses LoST to determine the PSAP that serves that >> location. 4. The LIS returns to the endpoint a location >> which, if submitted to LoST, would return the the same PSAP URI >> the fine grained location would or . In some circumstances, this >> could be a civic with only a country. An alternative that >> works for all circumstances is to return the polygon that >> defines the service boundary of the PSAP (which LoST can >> return). Is essential that the PSAP URI returned from a LoST >> query with whatever the LIS gives the endpoint would be the >> same PSAP URI any querier using the fine grained location >> would get. 5. The endpoint uses the (coarse) location value >> it obtains to query LoST. It gets the (correct) PSAP URI 6. >=20 > Does this mean that if for a country the LOST directory has an entry DE > resolving to an ESRP_DE, more fine grained LOST entries as Frankfurt > either a)must resolve to the same ESRP_DE as the DE entry or b)if the > Frankfurt entry resolves to a local PSAP-_Frankfurt every ASP/ISP MUST > return for locations in Frankfurt the local PSAP_Frankfurt or c) there > are no more fine grained entries? >=20 > Or did I miss something? >=20 > Thanks a lot > Laura >=20 > =20 >=20 >> This is repeated at call time. The endpoint has a valid LbyR >> and a valid PSAP URI, which it uses to construct the >> emergency call 7. A VSP wishing to validate the PSAP URI >> takes the LbyR and dereferences it. The result will be the >> same (coarse) location the endpoint got. The VSP does a LoST >> query with that location, and should get the same PSAP URI >> that is in the Request URI on the call. This validation >> works for coarse or fine validation, and of course works for >> LbyV without the dereference step. 8. The PSAP (or ESRP) >> which is the target of the PSAP URI gets the call. It >> dereferences the LbyR but gets the fine grained location; the >> LIS must have a relationship with the ESRP/PSAP to assure >> this. 9. Any succeeding ESRPs or PSAPs can also dereference >> and get fine grained location. >>=20 >> QUESTION: Is this approach acceptable for you? >>=20 >> Ciao >> Hannes >>=20 >>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >>=20 >=20 >=20 >=20 > ------------------------------ >=20 > Message: 5 > Date: Fri, 20 Apr 2007 07:44:39 -0400 > From: "Brian Rosen" > Subject: RE: [Ecrit] Consensus Call: Precise Location Information > notavailable to End Host > To: "'Liess, Laura'" , > , > Message-ID: <135d01c78341$4a882de0$640fa8c0@cis.neustar.com> > Content-Type: text/plain; charset=3D"us-ascii" >=20 >> Does this mean that if for a country the LOST directory has an entry DE >> resolving to an ESRP_DE, more fine grained LOST entries as Frankfurt >> either a)must resolve to the same ESRP_DE as the DE entry or b)if the >> Frankfurt entry resolves to a local PSAP-_Frankfurt every ASP/ISP MUST >> return for locations in Frankfurt the local PSAP_Frankfurt or c) there >> are no more fine grained entries? >=20 > I'm not really sure I understand your question, but let me tell you how I > think this will work in North America: >=20 > There will be state level ESRPs (we won't be able to have a national ESRP= , > and we probably wouldn't want one anyway). All calls in New Jersey would= go > to the New Jersey ESRP. The LoST entries for every location in New Jerse= y > will have the New Jersey ESRP as the URI. >=20 > The New Jersey ESRP will have another service, which will only be availab= le > inside the Emergency Services IP Network, and thus to any ESRP or PSAP in > New Jersey, which supplies the URI of the actual PSAP that gets the call. > The ESRP will make a LoST query with that service to route the call onwar= d. > That same mechanism will be used by the PSAP to query for the responder > agencies (police, fire, ems). A regular LoST query to > urn:service:sos.police would return the New Jersey ESRP. >=20 > In some areas, there will be a second level of ESRP, perhaps at the count= y > level. The state ESRP will route to the county ESRP, the county ESRP wil= l > route to PSAP. >=20 > This means that the LIS will effectively reveal the state the caller is i= n, > but not the city, since the service boundary returned by LoST for > urn:service:sos would be the state boundary. Of course in a smaller > country, you may have a country level ESRP. >=20 > Does that answer your question? If it does not, perhaps you could explai= n > what you mean more fully. >=20 > Brian >=20 >=20 >=20 >=20 > ------------------------------ >=20 > Message: 6 > Date: Fri, 20 Apr 2007 07:17:42 -0500 > From: "Beyer, Loraine" > Subject: [Ecrit] Please remove my name -UNSUBSCRIBE > To: > Message-ID: <6FEBBDAA0B74D34E806D366A431F36B7030F3F0C@brexc47p> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Loraine Beyer >=20 >=20 > Thank you >=20 > ***** >=20 > The information transmitted is intended only for the person or entity to = which > it is addressed and may contain confidential, proprietary, and/or privile= ged > material. Any review, retransmission, dissemination or other use of, or t= aking > of any action in reliance upon this information by persons or entities ot= her > than the intended recipient is prohibited. If you received this in error, > please contact the sender and delete the material from all computers. GA6= 21 >=20 >=20 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL:=20 > http://www1.ietf.org/pipermail/ecrit/attachments/20070420/134d7498/attach= ment. > html >=20 > ------------------------------ >=20 > Message: 7 > Date: Fri, 20 Apr 2007 10:09:18 -0400 > From: "Stark, Barbara" > Subject: RE: [Ecrit] Re: [Geopriv] Soliciting Feedback: > (Partial)LocationHiding Emergency Services Architecture > To: "Brian Rosen" , "Henning Schulzrinne" > , "Hannes Tschofenig" > Cc: GEOPRIV , ECRIT > Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA03B0F89C@crexc41p> > Content-Type: text/plain; charset=3D"US-ASCII" >=20 > I see this as an attempt to get around the access provider's "hiding". I > can see people using the PSAP test call now as not only a means of > testing whether an unauthenticated phone works, but as a tool to figure > out their location, if the access provider won't give it to them. >=20 > I'm against this recommendation. But I won't fight hard, since the > recommendation has no teeth. >=20 > I should point out, though, that phonebcp currently only describes the > UA doing automated testing, and not providing a user interface to > support user-initiated testing. And support of media (above and beyond > SIP signaling) appears to only be a "SHOULD". In my phonebcp comments, I > did object to the recommendation that PSAPs respond with the location > value in their SIP response, if a reference were sent in the request. > But again, I won't argue hard. This will ultimately be a matter of local > or national policy, independent of the IETF attempts to impact such > policy. > Barbara >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, April 19, 2007 4:19 PM > To: 'Henning Schulzrinne'; 'Hannes Tschofenig' > Cc: 'GEOPRIV'; 'ECRIT' > Subject: RE: [Ecrit] Re: [Geopriv] Soliciting Feedback: > (Partial)LocationHiding Emergency Services Architecture >=20 >> By the way, I think it would be helpful if the framework or phonebcp >> would recommend that PSAPs read back location information via text-to- >=20 >> speech when test calls are being placed. > Uh, well, in a form suitable for the media offered in the first place. > That may be text, it may be text to sign language. >=20 > Brian >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 > ***** >=20 > The information transmitted is intended only for the person or entity to = which > it is addressed and may contain confidential, proprietary, and/or privile= ged > material. Any review, retransmission, dissemination or other use of, or t= aking > of any action in reliance upon this information by persons or entities ot= her > than the intended recipient is prohibited. If you received this in error, > please contact the sender and delete the material from all computers. GA6= 21 >=20 >=20 >=20 >=20 >=20 > ------------------------------ >=20 > Message: 8 > Date: Fri, 20 Apr 2007 16:36:46 +0200 > From: "Liess, Laura" > Subject: AW: [Ecrit] Consensus Call: Precise Location Information > notavailable to End Host > To: , , > Message-ID: > <182C63BFBAF131428EA0C16F7FD2191B013584D4@S4DE8PSAAGM.mitte.t-com.de> > Content-Type: text/plain; charset=3D"iso-8859-1" >=20 >=20 > Brian, >=20 > yes, that answers my question and I am OK with this approach. >=20 > Thanks a lot > Laura =20 >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: Brian Rosen [mailto:br@brianrosen.net] >> Gesendet: Freitag, 20. April 2007 13:45 >> An: Liess, Laura; Hannes.Tschofenig@gmx.net; ecrit@ietf.org >> Betreff: RE: [Ecrit] Consensus Call: Precise Location >> Information notavailable to End Host >>=20 >>=20 >>> Does this mean that if for a country the LOST directory has >> an entry=20 >>> DE resolving to an ESRP_DE, more fine grained LOST entries as >>> Frankfurt either a)must resolve to the same ESRP_DE as the >> DE entry=20 >>> or b)if the Frankfurt entry resolves to a local >> PSAP-_Frankfurt every >>> ASP/ISP MUST return for locations in Frankfurt the local >>> PSAP_Frankfurt or c) there are no more fine grained entries? >>=20 >> I'm not really sure I understand your question, but let me >> tell you how I think this will work in North America: >>=20 >> There will be state level ESRPs (we won't be able to have a >> national ESRP, and we probably wouldn't want one anyway). >> All calls in New Jersey would go to the New Jersey ESRP. The >> LoST entries for every location in New Jersey will have the >> New Jersey ESRP as the URI. >>=20 >> The New Jersey ESRP will have another service, which will >> only be available inside the Emergency Services IP Network, >> and thus to any ESRP or PSAP in New Jersey, which supplies >> the URI of the actual PSAP that gets the call. The ESRP will >> make a LoST query with that service to route the call onward. >> That same mechanism will be used by the PSAP to query for the >> responder agencies (police, fire, ems). A regular LoST query >> to urn:service:sos.police would return the New Jersey ESRP. >>=20 >> In some areas, there will be a second level of ESRP, perhaps >> at the county level. The state ESRP will route to the county >> ESRP, the county ESRP will route to PSAP. >>=20 >> This means that the LIS will effectively reveal the state the >> caller is in, but not the city, since the service boundary >> returned by LoST for urn:service:sos would be the state >> boundary. Of course in a smaller country, you may have a >> country level ESRP. >>=20 >> Does that answer your question? If it does not, perhaps you >> could explain what you mean more fully. >>=20 >> Brian >>=20 >>=20 >=20 >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > End of Ecrit Digest, Vol 27, Issue 50 > ************************************* _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 17:29:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf0g1-0004PL-Hw; Fri, 20 Apr 2007 17:29:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf0g0-0004OT-B4 for ecrit@ietf.org; Fri, 20 Apr 2007 17:29:56 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf0g0-000443-1E for ecrit@ietf.org; Fri, 20 Apr 2007 17:29:56 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 20 Apr 2007 17:29:55 -0400 id 01588376.462930D3.00003043 In-Reply-To: <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host Date: Fri, 20 Apr 2007 17:29:54 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Well, the point I was trying to make was that each new location profile would have to account for location providing. So, if we do geodetic-3d or rfc3825 or linser-locrel or whatever else comes along, we have to account for the fact that output has to also be the input. I know that may not be such a big deal, but we never really know. A simple key is easier on databases than the complex searching needed for location information, especially as the location profiles get more complex. I agree about the special case. But the behavior does not have to be a special case, it can be done all the time. Essentially, a reference always exists inside a LoST mapping. Anytime a LoST mapping is converted into a PIDF-LO, such as when the LIS is trying to get a the service boundary for a PSAP to use as location information, that reference goes along with it. Later on, a VSP or whoever can simply use that reference to check the PSAP URI vs. using the location. I admit, this is an optimization. But we already have to change LoST a little bit. We might as well try to make the subsequent policing against abuse as low cost as possible. -andy On Apr 20, 2007, at 4:21 PM, Henning Schulzrinne wrote: > We had talked about a more generic 2D polygon description earlier, > primarily for wireless cases, so we may just get to do it now > rather than later. > > We already have the necessary location profile (polygon), as it is > used for the boundary. > > I don't see how re-using the service boundary reference helps. The > UA still has to understand the reference and polygon. Can you > describe exactly how this would work? I'd rather avoid special- > casing this particular use case ("do one thing when you get a > reference to a point, do something completely different when you > get a reference to a polygon"). > > On Apr 20, 2007, at 3:50 PM, Andrew Newton wrote: > >> After having some more time to noodle on this... >> >> On Apr 20, 2007, at 4:50 AM, Hannes Tschofenig wrote: >> >>> 7. A VSP wishing to validate the PSAP URI takes the LbyR and >>> dereferences >>> it. The result will be the same (coarse) location the endpoint >>> got. The >>> VSP does a LoST query with that location, and should get the same >>> PSAP URI >>> that is in the Request URI on the call. This validation works >>> for coarse or >>> fine validation, and of course works for LbyV without the >>> dereference step. >> >> This works without modification of LoST for civic, but I think it >> requires a modification of LoST for geo. The LoST geodetic-2d >> location profile takes a point as input, not an area. >> >> That being said, I'm willing to live with the change to LoST to >> accommodate this requirement. We could create a new location >> profile or modify geodetic-2d, but then every geodetic (or non- >> civic) location profile would have to accommodate this use case. >> If we are to do this, I'd rather have a more generic mechanism >> that requires no changes to location profiles by re-using the >> service boundary reference. Such a service boundary reference >> could be conveyed in a PIDF-LO in a new element. That also allows >> LoST resolvers to optimize their lookup to a simple key vs. the >> more complex location information. The VSP wouldn't use the >> query for policing, but the query. >> >> -andy >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 20 19:13:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf2I0-00079i-UT; Fri, 20 Apr 2007 19:13:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf2I0-00079d-2Y for ecrit@ietf.org; Fri, 20 Apr 2007 19:13:16 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf2Hx-00033w-RG for ecrit@ietf.org; Fri, 20 Apr 2007 19:13:16 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3KND6uN007627 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Apr 2007 19:13:10 -0400 (EDT) In-Reply-To: References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host Date: Fri, 20 Apr 2007 19:13:02 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think one of the objectives should be that a UA can copy location information from a PIDF-LO-speaking protocol to LoST without knowing anything about the content. It really doesn't care and it won't really be able to manipulate location information in any event. I'm not sure this is currently as easy as it could be. Obviously, LCP can't just dump random stuff into LoST queries, as this is likely to fail, but the number of LoST servers is always going to be much smaller than the number of clients (and LoST servers are more likely to be upgradeable). On Apr 20, 2007, at 5:29 PM, Andrew Newton wrote: > Well, the point I was trying to make was that each new location > profile would have to account for location providing. So, if we do > geodetic-3d or rfc3825 or linser-locrel or whatever else comes > along, we have to account for the fact that output has to also be > the input. I know that may not be such a big deal, but we never > really know. A simple key is easier on databases than the complex > searching needed for location information, especially as the > location profiles get more complex. > > I agree about the special case. But the behavior does not have to > be a special case, it can be done all the time. Essentially, a > reference always exists inside a LoST mapping. Anytime a LoST > mapping is converted into a PIDF-LO, such as when the LIS is trying > to get a the service boundary for a PSAP to use as location > information, that reference goes along with it. Later on, a VSP or > whoever can simply use that reference to check the PSAP URI vs. > using the location. > > I admit, this is an optimization. But we already have to change > LoST a little bit. We might as well try to make the subsequent > policing against abuse as low cost as possible. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 21 09:19:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfFV1-0007pO-2F; Sat, 21 Apr 2007 09:19:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfFV0-0007pE-2Y for ecrit@ietf.org; Sat, 21 Apr 2007 09:19:34 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfFUy-0005RO-GD for ecrit@ietf.org; Sat, 21 Apr 2007 09:19:34 -0400 Received: (qmail 20922 invoked by uid 0); 21 Apr 2007 13:19:31 -0000 Received: from 90.187.161.22 by www036.gmx.net with HTTP; Sat, 21 Apr 2007 15:19:31 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 21 Apr 2007 15:19:31 +0200 From: "Hannes Tschofenig" In-Reply-To: Message-ID: <20070421131931.181720@gmx.net> MIME-Version: 1.0 References: Subject: Re: [Ecrit] Re: Ecrit Digest, Vol 27, Issue 50 To: =?iso-8859-1?Q?=22Andres_K=FCtt=22?= , ecrit-request@ietf.org, ecrit@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX19kDawi3rxkKRjdyebFI6H16K0kpMxzw2eBajvobl fHIIBbYDmwXM89CvVNqGSoCK3TQZm6oKOnBQ== Content-Transfer-Encoding: 8bit X-GMX-UID: UTYSc8A1bmwoT4ERqjZLCBJPUzc4cpG2 X-Spam-Score: 0.0 (/) X-Scan-Signature: b148ead9c6581b10314b24a9438d3a5f Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Andres, Thanks for your feedback. You correctly understood the suggestion. The current proposal does not replace the case where networks provide detailed location information to the end host for emergency call routing. Ciao Hannes PS: From a VoIP provider, like Skype, another challenge with emergency call signaling itself is that the PSAP (and the ESRP) is likely to support only SIP and not many other protocols (but that's independent to this discussion). -------- Original-Nachricht -------- Datum: Fri, 20 Apr 2007 14:22:49 -0700 Von: "Andres Kütt" An: ecrit@ietf.org, ecrit-request@ietf.org Betreff: [Ecrit] Re: Ecrit Digest, Vol 27, Issue 50 > Yes, > > As long as other flows (an AP knowing exactly where it is and > broadcasting that information) are possible, the suggestion makes sense. > > Yours, > Andres > > > On 4/20/07 7:36 AM, "ecrit-request@ietf.org" > wrote: > > > Send Ecrit mailing list submissions to > > ecrit@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www1.ietf.org/mailman/listinfo/ecrit > > or, via email, send a message with subject or body 'help' to > > ecrit-request@ietf.org > > > > You can reach the person managing the list at > > ecrit-owner@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Ecrit digest..." > > > > > > Today's Topics: > > > > 1. Re: Re: [Geopriv] Soliciting Feedback: (Partial) > > LocationHiding Emergency Services Architecture (Henning > Schulzrinne) > > 2. Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto > > doendpoint centric LCP without giving away the store > > (Henning Schulzrinne) > > 3. Consensus Call: Precise Location Information not available to > > End Host (Hannes Tschofenig) > > 4. AW: [Ecrit] Consensus Call: Precise Location Information not > > available to End Host (Liess, Laura) > > 5. RE: Consensus Call: Precise Location Information notavailable > > to End Host (Brian Rosen) > > 6. Please remove my name -UNSUBSCRIBE (Beyer, Loraine) > > 7. RE: Re: [Geopriv] Soliciting Feedback: > > (Partial)LocationHiding Emergency Services Architecture > > (Stark, Barbara) > > 8. AW: [Ecrit] Consensus Call: Precise Location Information > > notavailable to End Host (Liess, Laura) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Thu, 19 Apr 2007 19:42:12 -0400 > > From: Henning Schulzrinne > > Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial) > > LocationHiding Emergency Services Architecture > > To: Ted Hardie > > Cc: 'ECRIT' > > Message-ID: <9A60EA48-FABA-41CA-B1EC-27FCF15F7F6C@cs.columbia.edu> > > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > >> > > > > Based on my experience, there are two kinds of test calls: > > > > - automatic: done to verify NAT operation, LoST lookups and such; > > nothing is reported unless there's a problem; done fairly regularly > > when network conditions change; no human interaction. > > > > - manual: explicitly invoked by the user; for example, done when > > moving into a new house. There is no ringback or anything else - the > > user picks up the phone, clicks on the "test emergency call" link and > > gets information back, similar to the test numbers that regular phone > > service has (including such numbers as 1 700 555.4141 [http:// > > www.cs.columbia.edu/~hgs/internet/telephone.html]). > > > > For example, when we installed our new departmental PBX, we wanted to > > make sure 911 worked and delivered the right number and location to > > the PSAP. We had to call the "real" 911, which our sys admin did with > > great trepidation. > > > > > >> Do you believe, then, that the user has to be aware of the test > >> call, and responsive > >> during it? That's very different from the way the BCP seems to be > >> written now, > >> and I suspect there are some pretty scaly dragons there. If, at a > >> random interval, > >> the phone rings and reports on the status of a pseudo-911 call, I > >> think users > >> are going to be surprised and may be alarmed. I'd rather leave it > >> as something > >> where the phone confirms that the test works and stores the > >> outcome, so that a > >> user may review it and make corrections if needed. But that means > >> storing > >> time and date along with the test call info (imagine someone saying, > >> "I'm at 3 Wall Street, and this thing believes I'm at JFK" where it > >> really meant > >> that the most recent test call was when the user was at the airport). > >> > >> > >> I think we should assume that the typical test call will be > >> unattended. How > >> far off the consensus am I on that? > >> > > > > See above; we need both. > > > >>> Thus, I believe that this mechanism adds significantly to the > >>> overall reliability of the system and we should encourage that it > >>> be provided, whether as location-conveyance, audio or just a PIDF- > >>> LO attachment in the 200 OK. (This generally won't work well, > >>> given the difficulty real phones have with multipart, but that's a > >>> different topic.) > >> > >> I think incorporating it into the response to the 200 OK is the > >> best way forward, > >> and that making it part of the text actually relieves some of the > >> location hiding > >> concerns (since the information would need to be scraped from there > >> into other > >> applications). > > > > I don't know what you have in mind. I'm sure you are not proposing to > > put it as > > > > 200 OK (123 Main Street) > > > > Putting it in plain text as a body (text/plain) isn't likely to deter > > scraping unless it is so obfuscated that it confuses humans, too. > > Plus, you lose the ability to know which elements are actually > > populated, so that a correct-looking address is actually unusable for > > routing or dispatch. For example, showing > > > > Room 123 456 Corporate Plaza > > Anytown CA 01234 > > > > can still have "Room 123" show up in the street address field in PIDF- > > LO, even though the text "looks" ok. > > > > Plus, text isn't too useful for an ATA (terminal adapter) device. It > > can't show the text, since it has no display. > > > > Henning > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------ > > > > Message: 2 > > Date: Thu, 19 Apr 2007 20:04:27 -0400 > > From: Henning Schulzrinne > > Subject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto > > doendpoint centric LCP without giving away the store > > To: "Dawson, Martin" > > Cc: GEOPRIV , ECRIT > > Message-ID: > > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > > > > On Apr 19, 2007, at 6:17 PM, Dawson, Martin wrote: > > > >> OK I see... > >> > >> If we're talking about VSPs (which I didn't think were necessary for > >> ECRIT) then I agree. However, that's the same challenge that i2 has - > >> except it's not just a routing question, it has to go to the right VPC > >> so the PSAP can get the location information from it out of band. > > > > As per our definitions, VSPs could be something like a corporation or > > university campus, not necessarily an operator such as SunRocket, > > Verizon or Vonage. As noted before, a LoST server could also be > > operated by an independent party, just like STUN servers are today > > (e.g., http://www.stunserver.org/). > > > > > > > > > >> > >> If this is the only scenario we are talking about, then I still think > >> there are less convoluted solutions from the perspective of the > >> device. > >> > >> How about the "resolver" does a dereference and the LIS, realizing > >> it's > >> not an authorized requestor, just returns a country code. Or there may > > > > That's roughly what happens in the proposal, except that the query is > > done by the UA. But that doesn't solve the problem of finding the > > right PSAP and doesn't seem to change the problems leading to the > > currently-proposed solution. > > > >> actually be standard HTTP (for example) error constructs that would > >> provide the equivalent information. Or, as I tentatively suggested, a > >> convention for the URL construction could indicate the jurisdiction > >> - or > >> the LIS request could include a URL and a bare bones PIDF-LO (both of > >> which eliminate the additional transaction altogether). I don't think > >> any of those proposals require changes to existing specifications > >> either > >> (apart from LoST doing the dereference). > > > > My general perception is that encoding information into URLs (not > > URNs) is considered a hack, as they are supposed to be opaque to the > > HTTP client. > > > > > > > >> > >> Anyway, my response stands. I could live with the solution but it > >> feels > >> unnecessarily convoluted. > > > >> > >> Cheers, > >> Martin > >> > > > > > > > > > > ------------------------------ > > > > Message: 3 > > Date: Fri, 20 Apr 2007 10:50:01 +0200 > > From: Hannes Tschofenig > > Subject: [Ecrit] Consensus Call: Precise Location Information not > > available to End Host > > To: ECRIT > > Message-ID: <46287EB9.7060006@gmx.net> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > Hi all, > > > > let me try it again (I got it wrong in my previous mail). > > > > Henning and Brian suggested an approach that > > * works nicely with the emergency services architecture we > > investigated over the past few years, and > > * addresses the case where a network operator > > does not want to disclose precise location information. > > > > Here is the procedure: > > > > 1. The endpoint uses an LCP to request location. The LIS returns an > LbyR > > 2. The endpoint dereferences the LbyR. > > 3. The LIS, noticing that the dereference request is from the endpoint > (or > > at least not from any entity that is entitled to get fine grained > location), > > takes the fine grained location and uses LoST to determine the PSAP that > > serves that location. > > 4. The LIS returns to the endpoint a location which, if submitted to > LoST, > > would return the same PSAP URI the fine grained location would. In some > > circumstances, this could be a civic with only a country. An > alternative > > that works for all circumstances is to return the polygon that defines > the > > service boundary of the PSAP (which LoST can return). Is essential that > the > > PSAP URI returned from a LoST query with whatever the LIS gives the > endpoint > > would be the same PSAP URI any querier using the fine grained location > would > > get. > > 5. The endpoint uses the (coarse) location value it obtains to query > LoST. > > It gets the (correct) PSAP URI > > 6. This is repeated at call time. The endpoint has a valid LbyR and a > valid > > PSAP URI, which it uses to construct the emergency call > > 7. A VSP wishing to validate the PSAP URI takes the LbyR and > dereferences > > it. The result will be the same (coarse) location the endpoint got. > The > > VSP does a LoST query with that location, and should get the same PSAP > URI > > that is in the Request URI on the call. This validation works for > coarse or > > fine validation, and of course works for LbyV without the dereference > step. > > 8. The PSAP (or ESRP) which is the target of the PSAP URI gets the call. > It > > dereferences the LbyR but gets the fine grained location; the LIS must > have > > a relationship with the ESRP/PSAP to assure this. > > 9. Any succeeding ESRPs or PSAPs can also dereference and get fine > grained > > location. > > > > QUESTION: Is this approach acceptable for you? > > > > Ciao > > Hannes > > > > > > > > > > > > ------------------------------ > > > > Message: 4 > > Date: Fri, 20 Apr 2007 12:31:54 +0200 > > From: "Liess, Laura" > > Subject: AW: [Ecrit] Consensus Call: Precise Location Information not > > available to End Host > > To: , > > Message-ID: > > <182C63BFBAF131428EA0C16F7FD2191B013584D1@S4DE8PSAAGM.mitte.t-com.de> > > Content-Type: text/plain; charset="us-ascii" > > > > > > Hi, > > > >> Here is the procedure: > >> > >> 1. The endpoint uses an LCP to request location. The LIS > >> returns an LbyR 2. The endpoint dereferences the LbyR. > >> 3. The LIS, noticing that the dereference request is from the > >> endpoint (or at least not from any entity that is entitled to > >> get fine grained location), takes the fine grained location > >> and uses LoST to determine the PSAP that serves that > >> location. 4. The LIS returns to the endpoint a location > >> which, if submitted to LoST, would return the the same PSAP URI > >> the fine grained location would or . In some circumstances, this > >> could be a civic with only a country. An alternative that > >> works for all circumstances is to return the polygon that > >> defines the service boundary of the PSAP (which LoST can > >> return). Is essential that the PSAP URI returned from a LoST > >> query with whatever the LIS gives the endpoint would be the > >> same PSAP URI any querier using the fine grained location > >> would get. 5. The endpoint uses the (coarse) location value > >> it obtains to query LoST. It gets the (correct) PSAP URI 6. > > > > Does this mean that if for a country the LOST directory has an entry DE > > resolving to an ESRP_DE, more fine grained LOST entries as Frankfurt > > either a)must resolve to the same ESRP_DE as the DE entry or b)if the > > Frankfurt entry resolves to a local PSAP-_Frankfurt every ASP/ISP MUST > > return for locations in Frankfurt the local PSAP_Frankfurt or c) there > > are no more fine grained entries? > > > > Or did I miss something? > > > > Thanks a lot > > Laura > > > > > > > >> This is repeated at call time. The endpoint has a valid LbyR > >> and a valid PSAP URI, which it uses to construct the > >> emergency call 7. A VSP wishing to validate the PSAP URI > >> takes the LbyR and dereferences it. The result will be the > >> same (coarse) location the endpoint got. The VSP does a LoST > >> query with that location, and should get the same PSAP URI > >> that is in the Request URI on the call. This validation > >> works for coarse or fine validation, and of course works for > >> LbyV without the dereference step. 8. The PSAP (or ESRP) > >> which is the target of the PSAP URI gets the call. It > >> dereferences the LbyR but gets the fine grained location; the > >> LIS must have a relationship with the ESRP/PSAP to assure > >> this. 9. Any succeeding ESRPs or PSAPs can also dereference > >> and get fine grained location. > >> > >> QUESTION: Is this approach acceptable for you? > >> > >> Ciao > >> Hannes > >> > >> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > >> > > > > > > > > ------------------------------ > > > > Message: 5 > > Date: Fri, 20 Apr 2007 07:44:39 -0400 > > From: "Brian Rosen" > > Subject: RE: [Ecrit] Consensus Call: Precise Location Information > > notavailable to End Host > > To: "'Liess, Laura'" , > > , > > Message-ID: <135d01c78341$4a882de0$640fa8c0@cis.neustar.com> > > Content-Type: text/plain; charset="us-ascii" > > > >> Does this mean that if for a country the LOST directory has an entry DE > >> resolving to an ESRP_DE, more fine grained LOST entries as Frankfurt > >> either a)must resolve to the same ESRP_DE as the DE entry or b)if the > >> Frankfurt entry resolves to a local PSAP-_Frankfurt every ASP/ISP MUST > >> return for locations in Frankfurt the local PSAP_Frankfurt or c) there > >> are no more fine grained entries? > > > > I'm not really sure I understand your question, but let me tell you how > I > > think this will work in North America: > > > > There will be state level ESRPs (we won't be able to have a national > ESRP, > > and we probably wouldn't want one anyway). All calls in New Jersey > would go > > to the New Jersey ESRP. The LoST entries for every location in New > Jersey > > will have the New Jersey ESRP as the URI. > > > > The New Jersey ESRP will have another service, which will only be > available > > inside the Emergency Services IP Network, and thus to any ESRP or PSAP > in > > New Jersey, which supplies the URI of the actual PSAP that gets the > call. > > The ESRP will make a LoST query with that service to route the call > onward. > > That same mechanism will be used by the PSAP to query for the responder > > agencies (police, fire, ems). A regular LoST query to > > urn:service:sos.police would return the New Jersey ESRP. > > > > In some areas, there will be a second level of ESRP, perhaps at the > county > > level. The state ESRP will route to the county ESRP, the county ESRP > will > > route to PSAP. > > > > This means that the LIS will effectively reveal the state the caller is > in, > > but not the city, since the service boundary returned by LoST for > > urn:service:sos would be the state boundary. Of course in a smaller > > country, you may have a country level ESRP. > > > > Does that answer your question? If it does not, perhaps you could > explain > > what you mean more fully. > > > > Brian > > > > > > > > > > ------------------------------ > > > > Message: 6 > > Date: Fri, 20 Apr 2007 07:17:42 -0500 > > From: "Beyer, Loraine" > > Subject: [Ecrit] Please remove my name -UNSUBSCRIBE > > To: > > Message-ID: <6FEBBDAA0B74D34E806D366A431F36B7030F3F0C@brexc47p> > > Content-Type: text/plain; charset="us-ascii" > > > > Loraine Beyer > > > > > > Thank you > > > > ***** > > > > The information transmitted is intended only for the person or entity to > which > > it is addressed and may contain confidential, proprietary, and/or > privileged > > material. Any review, retransmission, dissemination or other use of, or > taking > > of any action in reliance upon this information by persons or entities > other > > than the intended recipient is prohibited. If you received this in > error, > > please contact the sender and delete the material from all computers. > GA621 > > > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > > http://www1.ietf.org/pipermail/ecrit/attachments/20070420/134d7498/attachment. > > html > > > > ------------------------------ > > > > Message: 7 > > Date: Fri, 20 Apr 2007 10:09:18 -0400 > > From: "Stark, Barbara" > > Subject: RE: [Ecrit] Re: [Geopriv] Soliciting Feedback: > > (Partial)LocationHiding Emergency Services Architecture > > To: "Brian Rosen" , "Henning Schulzrinne" > > , "Hannes Tschofenig" > > Cc: GEOPRIV , ECRIT > > Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA03B0F89C@crexc41p> > > Content-Type: text/plain; charset="US-ASCII" > > > > I see this as an attempt to get around the access provider's "hiding". I > > can see people using the PSAP test call now as not only a means of > > testing whether an unauthenticated phone works, but as a tool to figure > > out their location, if the access provider won't give it to them. > > > > I'm against this recommendation. But I won't fight hard, since the > > recommendation has no teeth. > > > > I should point out, though, that phonebcp currently only describes the > > UA doing automated testing, and not providing a user interface to > > support user-initiated testing. And support of media (above and beyond > > SIP signaling) appears to only be a "SHOULD". In my phonebcp comments, I > > did object to the recommendation that PSAPs respond with the location > > value in their SIP response, if a reference were sent in the request. > > But again, I won't argue hard. This will ultimately be a matter of local > > or national policy, independent of the IETF attempts to impact such > > policy. > > Barbara > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, April 19, 2007 4:19 PM > > To: 'Henning Schulzrinne'; 'Hannes Tschofenig' > > Cc: 'GEOPRIV'; 'ECRIT' > > Subject: RE: [Ecrit] Re: [Geopriv] Soliciting Feedback: > > (Partial)LocationHiding Emergency Services Architecture > > > >> By the way, I think it would be helpful if the framework or phonebcp > >> would recommend that PSAPs read back location information via text-to- > > > >> speech when test calls are being placed. > > Uh, well, in a form suitable for the media offered in the first place. > > That may be text, it may be text to sign language. > > > > Brian > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > ***** > > > > The information transmitted is intended only for the person or entity to > which > > it is addressed and may contain confidential, proprietary, and/or > privileged > > material. Any review, retransmission, dissemination or other use of, or > taking > > of any action in reliance upon this information by persons or entities > other > > than the intended recipient is prohibited. If you received this in > error, > > please contact the sender and delete the material from all computers. > GA621 > > > > > > > > > > > > ------------------------------ > > > > Message: 8 > > Date: Fri, 20 Apr 2007 16:36:46 +0200 > > From: "Liess, Laura" > > Subject: AW: [Ecrit] Consensus Call: Precise Location Information > > notavailable to End Host > > To: , , > > Message-ID: > > <182C63BFBAF131428EA0C16F7FD2191B013584D4@S4DE8PSAAGM.mitte.t-com.de> > > Content-Type: text/plain; charset="iso-8859-1" > > > > > > Brian, > > > > yes, that answers my question and I am OK with this approach. > > > > Thanks a lot > > Laura > > > >> -----Ursprüngliche Nachricht----- > >> Von: Brian Rosen [mailto:br@brianrosen.net] > >> Gesendet: Freitag, 20. April 2007 13:45 > >> An: Liess, Laura; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > >> Betreff: RE: [Ecrit] Consensus Call: Precise Location > >> Information notavailable to End Host > >> > >> > >>> Does this mean that if for a country the LOST directory has > >> an entry > >>> DE resolving to an ESRP_DE, more fine grained LOST entries as > >>> Frankfurt either a)must resolve to the same ESRP_DE as the > >> DE entry > >>> or b)if the Frankfurt entry resolves to a local > >> PSAP-_Frankfurt every > >>> ASP/ISP MUST return for locations in Frankfurt the local > >>> PSAP_Frankfurt or c) there are no more fine grained entries? > >> > >> I'm not really sure I understand your question, but let me > >> tell you how I think this will work in North America: > >> > >> There will be state level ESRPs (we won't be able to have a > >> national ESRP, and we probably wouldn't want one anyway). > >> All calls in New Jersey would go to the New Jersey ESRP. The > >> LoST entries for every location in New Jersey will have the > >> New Jersey ESRP as the URI. > >> > >> The New Jersey ESRP will have another service, which will > >> only be available inside the Emergency Services IP Network, > >> and thus to any ESRP or PSAP in New Jersey, which supplies > >> the URI of the actual PSAP that gets the call. The ESRP will > >> make a LoST query with that service to route the call onward. > >> That same mechanism will be used by the PSAP to query for the > >> responder agencies (police, fire, ems). A regular LoST query > >> to urn:service:sos.police would return the New Jersey ESRP. > >> > >> In some areas, there will be a second level of ESRP, perhaps > >> at the county level. The state ESRP will route to the county > >> ESRP, the county ESRP will route to PSAP. > >> > >> This means that the LIS will effectively reveal the state the > >> caller is in, but not the city, since the service boundary > >> returned by LoST for urn:service:sos would be the state > >> boundary. Of course in a smaller country, you may have a > >> country level ESRP. > >> > >> Does that answer your question? If it does not, perhaps you > >> could explain what you mean more fully. > >> > >> Brian > >> > >> > > > > > > > > ------------------------------ > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > End of Ecrit Digest, Vol 27, Issue 50 > > ************************************* > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 21 11:26:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfHTJ-0007XN-JF; Sat, 21 Apr 2007 11:25:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfHTI-0007XI-6U for ecrit@ietf.org; Sat, 21 Apr 2007 11:25:56 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfHTG-0002Ph-KB for ecrit@ietf.org; Sat, 21 Apr 2007 11:25:56 -0400 Received: (qmail 30318 invoked by uid 0); 21 Apr 2007 15:25:53 -0000 Received: from 90.187.15.126 by www076.gmx.net with HTTP; Sat, 21 Apr 2007 17:25:53 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" Date: Sat, 21 Apr 2007 17:25:53 +0200 From: "Hannes Tschofenig" In-Reply-To: Message-ID: <20070421152553.181760@gmx.net> MIME-Version: 1.0 References: <46287EB9.7060006@gmx.net> Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host To: Andrew Newton X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX19fdRsXlLVftWfcd55jUZIceUwUkx5nf2froG1gFk ttOnqcNuwTM1YFYUPnJcmZIS0Ovv+Q3VRLgw== Content-Transfer-Encoding: 7bit X-GMX-UID: MxQSczw0bmwoT4ERqjZLujFPUzc4cpG8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Andy, > After having some more time to noodle on this... > > On Apr 20, 2007, at 4:50 AM, Hannes Tschofenig wrote: > > > 7. A VSP wishing to validate the PSAP URI takes the LbyR and > > dereferences > > it. The result will be the same (coarse) location the endpoint > > got. The > > VSP does a LoST query with that location, and should get the same > > PSAP URI > > that is in the Request URI on the call. This validation works for > > coarse or > > fine validation, and of course works for LbyV without the > > dereference step. > > This works without modification of LoST for civic, but I think it > requires a modification of LoST for geo. The LoST geodetic-2d > location profile takes a point as input, not an area. You are right. Good catch. > > That being said, I'm willing to live with the change to LoST to > accommodate this requirement. We could create a new location profile > or modify geodetic-2d, True. but then every geodetic (or non-civic) > location profile would have to accommodate this use case. What do you mean? If we are > to do this, I'd rather have a more generic mechanism that requires no > changes to location profiles by re-using the service boundary > reference. Such a service boundary reference could be conveyed in a > PIDF-LO in a new element. That also allows LoST resolvers to > optimize their lookup to a simple key vs. the more complex location > information. The VSP wouldn't use the query for > policing, but the query. I am not sure about this approach. >From a PIDF-LO point of view there is no difference between conveying a point or an area. Ciao Hannes > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Apr 21 13:16:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfJBx-0000GR-JQ; Sat, 21 Apr 2007 13:16:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfJBw-0000CK-Sl for ecrit@ietf.org; Sat, 21 Apr 2007 13:16:08 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfJBw-0002Nn-KG for ecrit@ietf.org; Sat, 21 Apr 2007 13:16:08 -0400 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sat, 21 Apr 2007 13:16:07 -0400 id 01588425.462A46D7.00000996 In-Reply-To: <20070421152553.181760@gmx.net> References: <46287EB9.7060006@gmx.net> <20070421152553.181760@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host Date: Sat, 21 Apr 2007 13:16:06 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 1.2 (+) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 21, 2007, at 11:25 AM, Hannes Tschofenig wrote: >> This works without modification of LoST for civic, but I think it >> requires a modification of LoST for geo. The LoST geodetic-2d >> location profile takes a point as input, not an area. > > You are right. Good catch. > >> >> That being said, I'm willing to live with the change to LoST to >> accommodate this requirement. We could create a new location profile >> or modify geodetic-2d, > > True. > > but then every geodetic (or non-civic) >> location profile would have to accommodate this use case. > > What do you mean? Every non-civic location type will have to be able to take in the equivalent of a service boundary as input. Assuming exact service boundaries are the input every time, we have no problem. However, what's a resolver to do if the input (a polygon in geodetic-2d or perhaps an ellipse in geodetic-3d) crosses boundaries, which would now be perfectly legal. We've been down this path before and nobody has been able to explain the behavior of this case satisfactorily. > If we are >> to do this, I'd rather have a more generic mechanism that requires no >> changes to location profiles by re-using the service boundary >> reference. Such a service boundary reference could be conveyed in a >> PIDF-LO in a new element. That also allows LoST resolvers to >> optimize their lookup to a simple key vs. the more complex location >> information. The VSP wouldn't use the query for >> policing, but the query. > > I am not sure about this approach. > > From a PIDF-LO point of view there is no difference between > conveying a point or an area. Well, I did screw up a few details. We'd have to define a new LoST query, like . And there is potential for gaming this, though I think the whole fraud issue here is not that big of a deal (speaking as somebody who will have to deal with it). But this approach is less likely to cause a resolver any problems and result in faster database lookups during the VSP check. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Apr 22 06:45:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfZZi-0005Rg-Mm; Sun, 22 Apr 2007 06:45:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfZZh-0005RW-Aq for ecrit@ietf.org; Sun, 22 Apr 2007 06:45:45 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfZZf-0005Ug-PW for ecrit@ietf.org; Sun, 22 Apr 2007 06:45:45 -0400 Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id l3MAjg43027471; Sun, 22 Apr 2007 12:45:42 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id l3MAjfZM007425; Sun, 22 Apr 2007 12:45:42 +0200 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Apr 2007 12:45:41 +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 Subject: AW: [Ecrit] Re: Ecrit Digest, Vol 27, Issue 30 Date: Sun, 22 Apr 2007 12:45:38 +0200 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E701A6166D@MCHP7R6A.ww002.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: Ecrit Digest, Vol 27, Issue 30 Thread-Index: AceDj3UCs2NieO+CEduWpgAX8i4icABOj0ng From: "Tschofenig, Hannes" To: =?iso-8859-1?Q?Andres_K=FCtt?= , "Hannes Tschofenig" X-OriginalArrivalTime: 22 Apr 2007 10:45:41.0933 (UTC) FILETIME=[5F8815D0:01C784CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Andres,=20 > Hi, >=20 > Thank you for answers, have still some comments >=20 >=20 > On 4/19/07 12:07 PM, "Hannes Tschofenig"=20 > wrote: >=20 > > >>> 1) Provide enough location information so that the=20 > emergency call can be > >>> routed to the correct PSAP. Precise location information would be > >>> provided to the PSAP. > >>> This approach was already discussed on the list. We need=20 > feedback from, > >>> for example, Barbara and Laura whether they feel=20 > comfortable with this > >>> approach. > >>>=20 > >>> CONSEQUENCE: No changes needed. > >>> =20 > >> This implies that the access provider knows how much=20 > information is needed > >> to determine the PSAP which in turn implies that the it=20 > also knows about > >> PSAP topology. Can we make that assumption? > >>=20 > >> =20 > > Yes; I believe we can make this assumption. > For APs, this assumption does not hold. How would a $50 wifi=20 > AP know of > PSAPs?=20 I guess we would have to discuss what the role of the WiFi AP actually = is in this particular scenario. If these Aps belong to the network = operator then the network operator would have to=20 * decide how much location information they are willing to share * how the specific PSAP infrastructure looks like (in that country) * what the regulatory requirements are.=20 Depending on the outcome of the above investigation the LoST database is = filled with values.=20 In any case, LoST would provide the protocol machinery.=20 >=20 > > >>> 5) Emergency calls are routed via the SIP proxy of the VSP and > >>> subsequently via a SIP proxy in the ASP/ISP (redirect mode) > >>> SIP Location Conveyance would be used instead of GEOPRIV L7 LCP > >>> Assumption: No service level agreement (or business=20 > agreement) between > >>> VSP and ISP/ASP for this type of SIP emergency message=20 > routing required. > >>>=20 > >>>=20 > >>> CONSEQUENCE: No changes needed. Potential problems with=20 > SIP Identity > >>> possible > >>> =20 > >> This does not work with devices that do not use SIP on the=20 > client side. Like > >> yours truly.=20 > >>=20 > >> =20 > > That's true. I should have added this part. > >=20 > > The challenge is that for unauthenticated network access you need to > > implement one protocol anyway, very likely SIP, since otherwise you > > introduce EXTREMELY HUGE security vulnerabilities. > Not really. We can either assume some internal built-in=20 > identity or enable > certain functionality without the client being logged in.=20 > This has nothing > to do with the protocol that is used. The problem with unauthenticated network access is that you have to = place a SIP proxy in the access network to deal with the security = problems. With unauthenticated network access there is no identity information = available.=20 >=20 > >>> 7) Decoupled authentication for SIP message routing > >>> Authentication exchange between the end host and the VSP=20 > (e.g., TLS to > >>> obtain a SAML assertion) > >>> Authentication credentials are then added to the SIP=20 > emergency message > >>> that is routed via the SIP proxy in the VSP/ISP. > >>> No service level agreement (or business agreement) between VSP and > >>> ISP/ASP needed. > >>>=20 > >>> CONSEQUENCE: Security extension for this purpose needs to=20 > be progressed > >>> (already available in draft form) > >>> =20 > >> Do not understand this. The calling infrastructure needs=20 > to be authenticated > >>> from end to end anyway if any sort of billing is to happen? > >>=20 > >> =20 > > The end host / user is authenticated with a mechanism=20 > independent of SIP > > and then the receipt of that authentication action is added to the > > emergency call for consumption at the PSAP (to provide him=20 > some identity > > information). > This is only true for unauthenticated user as for everybody else a VSP > always has an authentication mechanism in place (and thus it=20 > does not need > to be described in a standard) and can forward it to PSAP. In this particular case I do not consider unauthenticated network = access.=20 It is possible to split the authentication from the actual VoIP = signaling. Since nobody liked this approach anyway it does not really matter too = much.=20 Ciao Hannes >=20 > >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Apr 22 15:52:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfi6z-0006eW-Qg; Sun, 22 Apr 2007 15:52:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfi6y-0006eQ-UZ for ecrit@ietf.org; Sun, 22 Apr 2007 15:52:40 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hfi6x-0003XJ-Ga for ecrit@ietf.org; Sun, 22 Apr 2007 15:52:40 -0400 Received: (qmail invoked by alias); 22 Apr 2007 19:52:37 -0000 Received: from p54984A8A.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.74.138] by mail.gmx.net (mp047) with SMTP; 22 Apr 2007 21:52:37 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18xrloxaHgxLkTHDwG71MFQtAspfI4Q+tr64lWU50 m2fKz6Oz05e5bG Message-ID: <462BBD04.9060602@gmx.net> Date: Sun, 22 Apr 2007 21:52:36 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Tiny remark: Henning Schulzrinne wrote: > I think one of the objectives should be that a UA can copy location > information from a PIDF-LO-speaking protocol to LoST without knowing > anything about the content. Currently it has to understand at least a little bit since the location shapes are much simpler than the stuff provided in http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-06.txt The translation from DHCP civic is without problems a copy-and-paste operation. The translation from DHCP geo isn't a problem if we do not consider compound location information and if we ignore the topic of resolution. The latter aspect caused a lot of discussion..... Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Apr 22 15:57:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfiBU-0008TI-FO; Sun, 22 Apr 2007 15:57:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfiBT-0008T6-Eu for ecrit@ietf.org; Sun, 22 Apr 2007 15:57:19 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HfiBS-0005dw-DE for ecrit@ietf.org; Sun, 22 Apr 2007 15:57:19 -0400 Received: (qmail invoked by alias); 22 Apr 2007 19:57:17 -0000 Received: from p54984a8a.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.74.138] by mail.gmx.net (mp027) with SMTP; 22 Apr 2007 21:57:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+3E6I/YN63t84Rm8EV7E7fEeJVoqzjMWN0/niTrD MTeTA0S4k6txN7 Message-ID: <462BBE1C.2070908@gmx.net> Date: Sun, 22 Apr 2007 21:57:16 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> In-Reply-To: <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning Schulzrinne wrote: > We had talked about a more generic 2D polygon description earlier, > primarily for wireless cases, so we may just get to do it now rather > than later. > We could do that. That's true. For the cellular case we could support the full http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-06.txt. I would, however, leave this as an extension for later. For the service boundary case we could obviously go for a much simpler approach. > We already have the necessary location profile (polygon), as it is > used for the boundary. Yes. > > I don't see how re-using the service boundary reference helps. The UA > still has to understand the reference and polygon. Can you describe > exactly how this would work? I'd rather avoid special-casing this > particular use case ("do one thing when you get a reference to a > point, do something completely different when you get a reference to a > polygon"). I also believe that defining a new location profile (or extending an existing one) would be much simpler. > > On Apr 20, 2007, at 3:50 PM, Andrew Newton wrote: > >> After having some more time to noodle on this... >> >> On Apr 20, 2007, at 4:50 AM, Hannes Tschofenig wrote: >> >>> 7. A VSP wishing to validate the PSAP URI takes the LbyR and >>> dereferences >>> it. The result will be the same (coarse) location the endpoint >>> got. The >>> VSP does a LoST query with that location, and should get the same >>> PSAP URI >>> that is in the Request URI on the call. This validation works for >>> coarse or >>> fine validation, and of course works for LbyV without the >>> dereference step. >> >> This works without modification of LoST for civic, but I think it >> requires a modification of LoST for geo. The LoST geodetic-2d >> location profile takes a point as input, not an area. >> >> That being said, I'm willing to live with the change to LoST to >> accommodate this requirement. We could create a new location profile >> or modify geodetic-2d, but then every geodetic (or non-civic) >> location profile would have to accommodate this use case. If we are >> to do this, I'd rather have a more generic mechanism that requires no >> changes to location profiles by re-using the service boundary >> reference. Such a service boundary reference could be conveyed in a >> PIDF-LO in a new element. That also allows LoST resolvers to >> optimize their lookup to a simple key vs. the more complex location >> information. The VSP wouldn't use the query for >> policing, but the query. >> >> -andy >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Apr 22 20:34:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfmVa-0008UF-92; Sun, 22 Apr 2007 20:34:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfmVZ-0008U9-1S for ecrit@ietf.org; Sun, 22 Apr 2007 20:34:21 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfmVX-0002kt-Qc for ecrit@ietf.org; Sun, 22 Apr 2007 20:34:21 -0400 X-SEF-Processed: 5_0_0_910__2007_04_22_19_40_59 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 22 Apr 2007 19:40:59 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Apr 2007 19:34:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Consensus Call: Precise Location Information notavailable to End Host Date: Sun, 22 Apr 2007 19:34:16 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Consensus Call: Precise Location Information notavailable to End Host Thread-Index: AceEOMPiyHrtBsM+Qv+YbUo4I44zQQBBfMdA From: "Thomson, Martin" To: "Andrew Newton" , "Hannes Tschofenig" X-OriginalArrivalTime: 23 Apr 2007 00:34:17.0220 (UTC) FILETIME=[2026DC40:01C7853F] X-Spam-Score: 1.1 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1716191757==" Errors-To: ecrit-bounces@ietf.org --===============1716191757== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 PiANCj4gRXZlcnkgbm9uLWNpdmljIGxvY2F0aW9uIHR5cGUgd2lsbCBoYXZlIHRvIGJlIGFibGUg dG8gdGFrZSBpbiB0aGUNCj4gZXF1aXZhbGVudCBvZiBhIHNlcnZpY2UgYm91bmRhcnkgYXMgaW5w dXQuICBBc3N1bWluZyBleGFjdCBzZXJ2aWNlDQo+IGJvdW5kYXJpZXMgYXJlIHRoZSBpbnB1dCBl dmVyeSB0aW1lLCB3ZSBoYXZlIG5vIHByb2JsZW0uICBIb3dldmVyLA0KPiB3aGF0J3MgYSByZXNv bHZlciB0byBkbyBpZiB0aGUgaW5wdXQgKGEgcG9seWdvbiBpbiBnZW9kZXRpYy0yZCBvcg0KPiBw ZXJoYXBzIGFuIGVsbGlwc2UgaW4gZ2VvZGV0aWMtM2QpIGNyb3NzZXMgYm91bmRhcmllcywgd2hp Y2ggd291bGQNCj4gbm93IGJlIHBlcmZlY3RseSBsZWdhbC4gIFdlJ3ZlIGJlZW4gZG93biB0aGlz IHBhdGggYmVmb3JlIGFuZCBub2JvZHkNCj4gaGFzIGJlZW4gYWJsZSB0byBleHBsYWluIHRoZSBi ZWhhdmlvciBvZiB0aGlzIGNhc2Ugc2F0aXNmYWN0b3JpbHkuDQoNClRoZXJlIGlzIGEgc29sdXRp b24uICBIb3dldmVyLCB0aGVyZSB3ZXJlIGNvbmNlcm5zIGFib3V0IHRoZSBpbXBsaWNhdGlvbnMg b2YgdGhlIHNvbHV0aW9uLiAgIFRoYXQgaXMsIGZvcmtpbmcgb2YgTG9TVCBxdWVyaWVzIHdvdWxk IGJlIHJlcXVpcmVkLiAgSSBjYW4ndCBzZWUgYSB3YXkgb3V0IG9mIHRoYXQgcGFydGljdWxhciBw cm9ibGVtLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1l c3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRh aW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0 aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1 dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJdDQo= --===============1716191757== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1716191757==-- From ecrit-bounces@ietf.org Sun Apr 22 20:50:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfmlM-0003WV-Pq; Sun, 22 Apr 2007 20:50:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfmlL-0003WQ-76 for ecrit@ietf.org; Sun, 22 Apr 2007 20:50:39 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfmlK-0008G7-0T for ecrit@ietf.org; Sun, 22 Apr 2007 20:50:39 -0400 Received: from [10.0.1.110] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sun, 22 Apr 2007 20:50:37 -0400 id 01588024.462C02DD.00007ACF In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Consensus Call: Precise Location Information notavailable to End Host Date: Sun, 22 Apr 2007 20:50:33 -0400 To: "Thomson, Martin" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 22, 2007, at 8:34 PM, Thomson, Martin wrote: > > There is a solution. However, there were concerns about the > implications of the solution. That is, forking of LoST queries > would be required. I can't see a way out of that particular problem. Exactly, we are now full circle back to that problem. One other point about using a mapping or service boundary reference, it allows the data hiding to be as granular or fine as the LIS desires. Currently, the "unauthorized" LbyR cannot be more granular than the PSAP service boundary of the endpoint. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Apr 22 20:56:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfmrJ-0001yU-FR; Sun, 22 Apr 2007 20:56:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfmrI-0001xt-NS for ecrit@ietf.org; Sun, 22 Apr 2007 20:56:48 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HfmrH-0003Kz-Dj for ecrit@ietf.org; Sun, 22 Apr 2007 20:56:48 -0400 Received: from [10.0.1.110] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sun, 22 Apr 2007 20:56:45 -0400 id 01588016.462C044D.00007C76 In-Reply-To: <462BBE1C.2070908@gmx.net> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBE1C.2070908@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <68F36998-36AF-4D03-866D-8E150C5863C5@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host Date: Sun, 22 Apr 2007 20:56:44 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 22, 2007, at 3:57 PM, Hannes Tschofenig wrote: > I also believe that defining a new location profile (or extending > an existing one) would be much simpler. Can you explain "simpler"? How do you arrive at that conclusion? Defining a new location profile or extending an existing one is certainly simpler for the current specification and probably the on- the-wire LoST protocol. But the server implementations are not simpler. At the authoritative server, a "is this polygon inside this polygon" query is more compute intensive (though I realize it is just an iterative form of "is this point inside this polygon"), and at the resolvers there is now the possibility of forking (which might require protocol changes anyway). -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 08:16:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfxSz-0007Ng-Gt; Mon, 23 Apr 2007 08:16:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heex2-0006ZB-J2; Thu, 19 Apr 2007 18:18:04 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heex1-0006gS-9l; Thu, 19 Apr 2007 18:18:04 -0400 X-SEF-Processed: 5_0_0_910__2007_04_19_17_24_38 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 19 Apr 2007 17:24:38 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 17:18:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto doendpoint centric LCP without giving away the store Date: Thu, 19 Apr 2007 17:17:58 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto doendpoint centric LCP without giving away the store Thread-Index: AceCzN0oC90ubMndQiKMnzkzFRRJYgAAOCEw From: "Dawson, Martin" To: "Henning Schulzrinne" X-OriginalArrivalTime: 19 Apr 2007 22:18:00.0452 (UTC) FILETIME=[972DD440:01C782D0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-Mailman-Approved-At: Mon, 23 Apr 2007 08:16:23 -0400 Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org OK I see...=0D=0A=0D=0AIf we're talking about VSPs (which I didn't think we= re necessary for=0D=0AECRIT) then I agree. However, that's the same challen= ge that i2 has -=0D=0Aexcept it's not just a routing question, it has to go= to the right VPC=0D=0Aso the PSAP can get the location information from it= out of band.=0D=0A=0D=0AIf this is the only scenario we are talking about,= then I still think=0D=0Athere are less convoluted solutions from the persp= ective of the device.=0D=0A=0D=0AHow about the "resolver" does a dereferenc= e and the LIS, realizing it's=0D=0Anot an authorized requestor, just return= s a country code. Or there may=0D=0Aactually be standard HTTP (for example)= error constructs that would=0D=0Aprovide the equivalent information. Or, a= s I tentatively suggested, a=0D=0Aconvention for the URL construction could= indicate the jurisdiction - or=0D=0Athe LIS request could include a URL an= d a bare bones PIDF-LO (both of=0D=0Awhich eliminate the additional transac= tion altogether). I don't think=0D=0Aany of those proposals require changes= to existing specifications either=0D=0A(apart from LoST doing the derefere= nce).=0D=0A=0D=0AAnyway, my response stands. I could live with the solution= but it feels=0D=0Aunnecessarily convoluted.=0D=0A=0D=0ACheers,=0D=0AMartin=0D= =0A=0D=0A-----Original Message-----=0D=0AFrom: Henning Schulzrinne [mailto:= hgs@cs.columbia.edu]=20=0D=0ASent: Friday, 20 April 2007 7:52 AM=0D=0ATo: D= awson, Martin=0D=0ACc: Brian Rosen; GEOPRIV; ECRIT=0D=0ASubject: Re: [Geopr= iv] Re: [Ecrit] Not-so-grand compromise on howto=0D=0Adoendpoint centric From ecrit-bounces@ietf.org Mon Apr 23 08:16:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfxSz-0007Ng-Gt; Mon, 23 Apr 2007 08:16:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heex2-0006ZB-J2; Thu, 19 Apr 2007 18:18:04 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heex1-0006gS-9l; Thu, 19 Apr 2007 18:18:04 -0400 X-SEF-Processed: 5_0_0_910__2007_04_19_17_24_38 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 19 Apr 2007 17:24:38 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 17:18:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto doendpoint centric LCP without giving away the store Date: Thu, 19 Apr 2007 17:17:58 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto doendpoint centric LCP without giving away the store Thread-Index: AceCzN0oC90ubMndQiKMnzkzFRRJYgAAOCEw From: "Dawson, Martin" To: "Henning Schulzrinne" X-OriginalArrivalTime: 19 Apr 2007 22:18:00.0452 (UTC) FILETIME=[972DD440:01C782D0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-Mailman-Approved-At: Mon, 23 Apr 2007 08:16:23 -0400 Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org OK I see...=0D=0A=0D=0AIf we're talking about VSPs (which I didn't think we= re necessary for=0D=0AECRIT) then I agree. However, that's the same challen= ge that i2 has -=0D=0Aexcept it's not just a routing question, it has to go= to the right VPC=0D=0Aso the PSAP can get the location information from it= out of band.=0D=0A=0D=0AIf this is the only scenario we are talking about,= then I still think=0D=0Athere are less convoluted solutions from the persp= ective of the device.=0D=0A=0D=0AHow about the "resolver" does a dereferenc= e and the LIS, realizing it's=0D=0Anot an authorized requestor, just return= s a country code. Or there may=0D=0Aactually be standard HTTP (for example)= error constructs that would=0D=0Aprovide the equivalent information. Or, a= s I tentatively suggested, a=0D=0Aconvention for the URL construction could= indicate the jurisdiction - or=0D=0Athe LIS request could include a URL an= d a bare bones PIDF-LO (both of=0D=0Awhich eliminate the additional transac= tion altogether). I don't think=0D=0Aany of those proposals require changes= to existing specifications either=0D=0A(apart from LoST doing the derefere= nce).=0D=0A=0D=0AAnyway, my response stands. I could live with the solution= but it feels=0D=0Aunnecessarily convoluted.=0D=0A=0D=0ACheers,=0D=0AMartin=0D= =0A=0D=0A-----Original Message-----=0D=0AFrom: Henning Schulzrinne [mailto:= hgs@cs.columbia.edu]=20=0D=0ASent: Friday, 20 April 2007 7:52 AM=0D=0ATo: D= awson, Martin=0D=0ACc: Brian Rosen; GEOPRIV; ECRIT=0D=0ASubject: Re: [Geopr= iv] Re: [Ecrit] Not-so-grand compromise on howto=0D=0Adoendpoint centric LC= P without giving away the store=0D=0A=0D=0AWe're talking about resolvers, i= =2Ee., not the authoritative servers. =20=0D=0AThey can be administered by = anybody, including the famous VSP in =20=0D=0ASierra Leone that Brian subsc= ribes to. The resolver has no business =20=0D=0Arelationship with the ISP, = but needs to dereference the location =20=0D=0Areference, as it otherwise h= as no idea what to do next. Thus, I'm =20=0D=0Aafraid that your proposal is= not workable given the current LoST =20=0D=0Aarchitecture and design.=0D=0A=0D= =0AHenning=0D=0A=0D=0AOn Apr 19, 2007, at 5:39 PM, Dawson, Martin wrote:=0D= =0A=0D=0A> Well - I think it's awful but I could live with it. It seems lik= e a =20=0D=0A> long=0D=0A> winded way to avoid having the LoST server do a = dereference.=0D=0A>=0D=0A> Does anyone think that a LoST server for Portuga= l will be administered=0D=0A> by an entity anywhere other than Portugal=3F = I don't. And in that =20=0D=0A> case, I=0D=0A> don't see any issue for thos= e jurisdictions that want to apply auth=20=0D=0A> +auth=0D=0A> on the deref= erence. The LoST server in such a jurisdiction can=0D=0A> reasonably be exp= ected to be authorised.=0D=0A>=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=0D=0A=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 08:16:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfxSz-0007NV-BG; Mon, 23 Apr 2007 08:16:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeeLV-00085G-6x; Thu, 19 Apr 2007 17:39:17 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeeLU-0007YS-KL; Thu, 19 Apr 2007 17:39:17 -0400 X-SEF-Processed: 5_0_0_910__2007_04_19_16_45_54 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 19 Apr 2007 16:45:54 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 16:39:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto doendpoint centric LCP without giving away the store Date: Thu, 19 Apr 2007 16:39:13 -0500 Message-ID: In-Reply-To: <122301c782af$fc0ee230$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto doendpoint centric LCP without giving away the store Thread-Index: AceB2jLjCmvef5D7QMe9NoQWMgzx9gAB4mHQACKi+WAAEArp8AAHknag From: "Dawson, Martin" To: "Brian Rosen" , "Henning Schulzrinne" X-OriginalArrivalTime: 19 Apr 2007 21:39:16.0322 (UTC) FILETIME=[2DE3BC20:01C782CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc X-Mailman-Approved-At: Mon, 23 Apr 2007 08:16:23 -0400 Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: Well - I think it's awful but I could live with it. It seems lik= e a =20=0D=0A> long=0D=0A> winded way to avoid having the LoST server do a = dereference.=0D=0A>=0D=0A> Does anyone think that a LoST server for Portuga= l will be administered=0D=0A> by an entity anywhere other than Portugal=3F = I don't. And in that =20=0D=0A> case, I=0D=0A> don't see any issue for thos= e jurisdictions that want to apply auth=20=0D=0A> +auth=0D=0A> on the deref= erence. The LoST server in such a jurisdiction can=0D=0A> reasonably be exp= ected to be authorised.=0D=0A>=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=0D=0A=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 08:16:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfxSz-0007NV-BG; Mon, 23 Apr 2007 08:16:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeeLV-00085G-6x; Thu, 19 Apr 2007 17:39:17 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeeLU-0007YS-KL; Thu, 19 Apr 2007 17:39:17 -0400 X-SEF-Processed: 5_0_0_910__2007_04_19_16_45_54 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 19 Apr 2007 16:45:54 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Apr 2007 16:39:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto doendpoint centric LCP without giving away the store Date: Thu, 19 Apr 2007 16:39:13 -0500 Message-ID: In-Reply-To: <122301c782af$fc0ee230$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto doendpoint centric LCP without giving away the store Thread-Index: AceB2jLjCmvef5D7QMe9NoQWMgzx9gAB4mHQACKi+WAAEArp8AAHknag From: "Dawson, Martin" To: "Brian Rosen" , "Henning Schulzrinne" X-OriginalArrivalTime: 19 Apr 2007 21:39:16.0322 (UTC) FILETIME=[2DE3BC20:01C782CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc X-Mailman-Approved-At: Mon, 23 Apr 2007 08:16:23 -0400 Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Well - I think it's awful but I could live with it. It seems like a long=0D= =0Awinded way to avoid having the LoST server do a dereference.=0D=0A=0D=0A= Does anyone think that a LoST server for Portugal will be administered=0D=0A= by an entity anywhere other than Portugal=3F I don't. And in that case, I=0D= =0Adon't see any issue for those jurisdictions that want to apply auth+auth=0D= =0Aon the dereference. The LoST server in such a jurisdiction can=0D=0Areas= onably be expected to be authorised.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D= =0A=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Brian Rosen [mailto:br= @brianrosen.net]=20=0D=0ASent: Friday, 20 April 2007 4:25 AM=0D=0ATo: Dawso= n, Martin; 'Henning Schulzrinne'=0D=0ACc: 'GEOPRIV'; 'ECRIT'=0D=0ASubject: = RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto=0D=0Adoendpoint = centric LCP without giving away the store=0D=0A=0D=0AOkay, well, discussion= has died down now, so I'd like to see if we have=0D=0Aconsensus on how we = allow access networks to hide location from=0D=0Aendpoints=0D=0A(and VSPs) = and yet result in correct emergency call routing.=0D=0A=0D=0AThe proposal r= equires no changes to existing documents (other than=0D=0Aexplanations in -= framework and -phonebcp).=0D=0A=0D=0AIt requires no changes in endpoint, VS= P, ESRP or PSAP behavior. It is=0D=0Aconfined to LIS behavior for LIS' tha= t wish to hide location.=0D=0A=0D=0AIt works as follows:=0D=0A=0D=0A1. The = endpoint uses an LCP to request location. The LIS returns an=0D=0ALbyR=0D=0A= 2. The endpoint dereferences the LbyR. =20=0D=0A3. The LIS, noticing that t= he dereference request is from the endpoint=0D=0A(or=0D=0Aat least not from= any entity that is entitled to get fine grained=0D=0Alocation),=0D=0Atakes= the fine grained location and uses LoST to determine the PSAP that=0D=0Ase= rves that location.=0D=0A4. The LIS returns to the endpoint a location whic= h, if submitted to=0D=0ALoST,=0D=0Awould return the same PSAP URI the fine = grained location would. In some=0D=0Acircumstances, this could be a civic = with only a country. An=0D=0Aalternative=0D=0Athat works for all circumsta= nces is to return the polygon that defines=0D=0Athe=0D=0Aservice boundary o= f the PSAP (which LoST can return). Is essential that=0D=0Athe=0D=0APSAP U= RI returned from a LoST query with whatever the LIS gives the=0D=0Aendpoint=0D= =0Awould be the same PSAP URI any querier using the fine grained location=0D= =0Awould=0D=0Aget.=0D=0A5. The endpoint uses the (coarse) location value it= obtains to query=0D=0ALoST.=0D=0AIt gets the (correct) PSAP URI=0D=0A6. Th= is is repeated at call time. The endpoint has a valid LbyR and a=0D=0Avali= d=0D=0APSAP URI, which it uses to construct the emergency call=0D=0A7. A VS= P wishing to validate the PSAP URI takes the LbyR and=0D=0Adereferences=0D=0A= it. The result will be the same (coarse) location the endpoint got.=0D=0AT= he=0D=0AVSP does a LoST query with that location, and should get the same P= SAP=0D=0AURI=0D=0Athat is in the Request URI on the call. This validation = works for=0D=0Acoarse or=0D=0Afine validation, and of course works for LbyV= without the dereference=0D=0Astep.=0D=0A8. The PSAP (or ESRP) which is the= target of the PSAP URI gets the call.=0D=0AIt=0D=0Adereferences the LbyR b= ut gets the fine grained location; the LIS must=0D=0Ahave=0D=0Aa relationsh= ip with the ESRP/PSAP to assure this.=0D=0A9. Any succeeding ESRPs or PSAPs= can also dereference and get fine=0D=0Agrained=0D=0Alocation.=0D=0A=0D=0AS= ome observations:=0D=0Aa) The LIS probably ought to query LoST with its cal= culated coarse=0D=0Alocation=0D=0Ato assure that it gets the same PSAP URI = as the fine grained location. =20=0D=0Ab) Thehttps://www1.ietf.org/mailman/listinfo/ecrit>, List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Well - I think it's awful but I could live with it. It seems like a long=0D= =0Awinded way to avoid having the LoST server do a dereference.=0D=0A=0D=0A= Does anyone think that a LoST server for Portugal will be administered=0D=0A= by an entity anywhere other than Portugal=3F I don't. And in that case, I=0D= =0Adon't see any issue for those jurisdictions that want to apply auth+auth=0D= =0Aon the dereference. The LoST server in such a jurisdiction can=0D=0Areas= onably be expected to be authorised.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D= =0A=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Brian Rosen [mailto:br= @brianrosen.net]=20=0D=0ASent: Friday, 20 April 2007 4:25 AM=0D=0ATo: Dawso= n, Martin; 'Henning Schulzrinne'=0D=0ACc: 'GEOPRIV'; 'ECRIT'=0D=0ASubject: = RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howto=0D=0Adoendpoint = centric LCP without giving away the store=0D=0A=0D=0AOkay, well, discussion= has died down now, so I'd like to see if we have=0D=0Aconsensus on how we = allow access networks to hide location from=0D=0Aendpoints=0D=0A(and VSPs) = and yet result in correct emergency call routing.=0D=0A=0D=0AThe proposal r= equires no changes to existing documents (other than=0D=0Aexplanations in -= framework and -phonebcp).=0D=0A=0D=0AIt requires no changes in endpoint, VS= P, ESRP or PSAP behavior. It is=0D=0Aconfined to LIS behavior for LIS' tha= t wish to hide location.=0D=0A=0D=0AIt works as follows:=0D=0A=0D=0A1. The = endpoint uses an LCP to request location. The LIS returns an=0D=0ALbyR=0D=0A= 2. The endpoint dereferences the LbyR. =20=0D=0A3. The LIS, noticing that t= he dereference request is from the endpoint=0D=0A(or=0D=0Aat least not from= any entity that is entitled to get fine grained=0D=0Alocation),=0D=0Atakes= the fine grained location and uses LoST to determine the PSAP that=0D=0Ase= rves that location.=0D=0A4. The LIS returns to the endpoint a location whic= h, if submitted to=0D=0ALoST,=0D=0Awould return the same PSAP URI the fine = grained location would. In some=0D=0Acircumstances, this could be a civic = with only a country. An=0D=0Aalternative=0D=0Athat works for all circumsta= nces is to return the polygon that defines=0D=0Athe=0D=0Aservice boundary o= f the PSAP (which LoST can return). Is essential that=0D=0Athe=0D=0APSAP U= RI returned from a LoST query with whatever the LIS gives the=0D=0Aendpoint=0D= =0Awould be the same PSAP URI any querier using the fine grained location=0D= =0Awould=0D=0Aget.=0D=0A5. The endpoint uses the (coarse) location value it= obtains to query=0D=0ALoST.=0D=0AIt gets the (correct) PSAP URI=0D=0A6. Th= is is repeated at call time. The endpoint has a valid LbyR and a=0D=0Avali= d=0D=0APSAP URI, which it uses to construct the emergency call=0D=0A7. A VS= P wishing to validate the PSAP URI takes the LbyR and=0D=0Adereferences=0D=0A= it. The result will be the same (coarse) location the endpoint got.=0D=0AT= he=0D=0AVSP does a LoST query with that location, and should get the same P= SAP=0D=0AURI=0D=0Athat is in the Request URI on the call. This validation = works for=0D=0Acoarse or=0D=0Afine validation, and of course works for LbyV= without the dereference=0D=0Astep.=0D=0A8. The PSAP (or ESRP) which is the= target of the PSAP URI gets the call.=0D=0AIt=0D=0Adereferences the LbyR b= ut gets the fine grained location; the LIS must=0D=0Ahave=0D=0Aa relationsh= ip with the ESRP/PSAP to assure this.=0D=0A9. Any succeeding ESRPs or PSAPs= can also dereference and get fine=0D=0Agrained=0D=0Alocation.=0D=0A=0D=0AS= ome observations:=0D=0Aa) The LIS probably ought to query LoST with its cal= culated coarse=0D=0Alocation=0D=0Ato assure that it gets the same PSAP URI = as the fine grained location. =20=0D=0Ab) The coarse LoST lookups can be ca= ched. For a given LIS, there is=0D=0Alikely=0D=0Aonly a few of them=0D=0Ac= ) The VSP can cache validated PSAP URIs and avoid LoST lookups in most=0D=0A= cases=0D=0Ad) The endpoint could send both the coarse location by value and= the=0D=0Areference, but this would really only help the VSP because the ES= RP/PSAP=0D=0Ais=0D=0Agoing to want to dereference to get the fine grained l= ocation.=0D=0Ae) The LIS can identify ESRPs and PSAPs in a number of ways. = It could=0D=0Ause=0D=0AIP address filtering, VPNs, IPSEC tunnels or other = address restrictive=0D=0Amechanisms. It could use TLS credentials of any f= orm it finds=0D=0Aacceptable.=0D=0AIt is essential that the mechanism work = for any valid PSAP that could=0D=0Aget=0D=0Athe call, and any ESRP that cou= ld handle the call, even when there are=0D=0Afailures. =20=0D=0A=0D=0ANow, = do we have any objections to making this the answer to the problem=0D=0Apos= ed=3F To be clear, I'm asking if you can live with it, not if you=0D=0Awou= ld=0D=0Aprefer another one of the proposals that have been made.=0D=0A=0D=0A= Brian=20=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Dawson, Marti= n [mailto:Martin.Dawson@andrew.com]=0D=0A> Sent: Thursday, April 19, 2007 6= :25 AM=0D=0A> To: Brian Rosen; Henning Schulzrinne=0D=0A> Cc: GEOPRIV; ECRI= T=0D=0A> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howt= o=0D=0A> doendpoint centric LCP without giving away the store=0D=0A>=20=0D=0A= > Well... I just posted on an alternative thread - about preferring the=0D=0A= > location request be made at the time of the call - where Henning seems=0D= =0A> to be taking the position that this is a dangerous additional=0D=0A> t= ransaction requirement. Yet, here we appear to be suggesting that a=0D=0A> = location dereference be made to determine coarse routing...=0D=0A>=20=0D=0A= > I don't actually object to the additional transaction (per my previous=0D= =0A> thread) though I will note that the VSP is inherently "further" from=0D= =0Athe=0D=0A> LIS than the device is. It just seems cleaner to me if the VS= P has no=0D=0A> requirement to interact with the LIS and that, in the case = of=0D=0Aemergency=0D=0A> calls, all LIS interactions occur locally - either= from the device or=0D=0A> jurisdictional entities such as the LoST server,= VPC, and/or PSAPs.=0D=0AThis=0D=0A> also obviates the need for the LIS to = distinguish between "allowed"=0D=0A> versus "non-allowed" granularity.=0D=0A= >=20=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=20=0D=0A> -----Original Message---= --=0D=0A> From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> Sent: Thursda= y, 19 April 2007 4:02 AM=0D=0A> To: 'Henning Schulzrinne'=0D=0A> Cc: 'GEOPR= IV'; 'ECRIT'=0D=0A> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand comprom= ise on howto=0D=0A> doendpoint centric LCP without giving away the store=0D= =0A>=20=0D=0A> I can live with this way out of the mess.=0D=0A>=20=0D=0A> I= rather like the idea of returning the PSAP service boundary polygon=0D=0Ao= n=0D=0A> the=0D=0A> endpoint's (or VSP's) dereference. The latter (as well= as coarse=0D=0A> location=0D=0A> when it works) also fixes the validation = problem; the VSP=0D=0Adereferences,=0D=0A> gets=0D=0A> the polygon, queries= LoST with it, and gets the PSAP URI.=0D=0A>=20=0D=0A> I agree that in lots= of cases, a very coarse location return from the=0D=0A> LbyR=0D=0A> is suf= ficient, and access networks ought to be able to take advantage=0D=0Aof=0D=0A= > it=0D=0A> when it happens.=0D=0A>=20=0D=0A> I guess we need to hear from = carriers. I think you already raised the=0D=0A> point=0D=0A> that in most = cases, an IP address yields city level location, albeit=0D=0A> VPNs=0D=0A> = often obscure that.=0D=0A>=20=0D=0A> And while you brought it up, I do thin= k a very nice user part of a=0D=0A> location=0D=0A> reference is a hashed t= elephone number. Most of the DSL networks, for=0D=0A> example, do have tel= ephone numbers which actually are easy to turn=0D=0Ainto=0D=0A> service add= ress in the existing databases. I'd prefer it be coarse LoST lookups can be ca= ched. For a given LIS, there is=0D=0Alikely=0D=0Aonly a few of them=0D=0Ac= ) The VSP can cache validated PSAP URIs and avoid LoST lookups in most=0D=0A= cases=0D=0Ad) The endpoint could send both the coarse location by value and= the=0D=0Areference, but this would really only help the VSP because the ES= RP/PSAP=0D=0Ais=0D=0Agoing to want to dereference to get the fine grained l= ocation.=0D=0Ae) The LIS can identify ESRPs and PSAPs in a number of ways. = It could=0D=0Ause=0D=0AIP address filtering, VPNs, IPSEC tunnels or other = address restrictive=0D=0Amechanisms. It could use TLS credentials of any f= orm it finds=0D=0Aacceptable.=0D=0AIt is essential that the mechanism work = for any valid PSAP that could=0D=0Aget=0D=0Athe call, and any ESRP that cou= ld handle the call, even when there are=0D=0Afailures. =20=0D=0A=0D=0ANow, = do we have any objections to making this the answer to the problem=0D=0Apos= ed=3F To be clear, I'm asking if you can live with it, not if you=0D=0Awou= ld=0D=0Aprefer another one of the proposals that have been made.=0D=0A=0D=0A= Brian=20=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Dawson, Marti= n [mailto:Martin.Dawson@andrew.com]=0D=0A> Sent: Thursday, April 19, 2007 6= :25 AM=0D=0A> To: Brian Rosen; Henning Schulzrinne=0D=0A> Cc: GEOPRIV; ECRI= T=0D=0A> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand compromise on howt= o=0D=0A> doendpoint centric LCP without giving away the store=0D=0A>=20=0D=0A= > Well... I just posted on an alternative thread - about preferring the=0D=0A= > location request be made at the time of the call - where Henning seems=0D= =0A> to be taking the position that this is a dangerous additional=0D=0A> t= ransaction requirement. Yet, here we appear to be suggesting that a=0D=0A> = location dereference be made to determine coarse routing...=0D=0A>=20=0D=0A= > I don't actually object to the additional transaction (per my previous=0D= =0A> thread) though I will note that the VSP is inherently "further" from=0D= =0Athe=0D=0A> LIS than the device is. It just seems cleaner to me if the VS= P has no=0D=0A> requirement to interact with the LIS and that, in the case = of=0D=0Aemergency=0D=0A> calls, all LIS interactions occur locally - either= from the device or=0D=0A> jurisdictional entities such as the LoST server,= VPC, and/or PSAPs.=0D=0AThis=0D=0A> also obviates the need for the LIS to = distinguish between "allowed"=0D=0A> versus "non-allowed" granularity.=0D=0A= >=20=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=20=0D=0A> -----Original Message---= --=0D=0A> From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> Sent: Thursda= y, 19 April 2007 4:02 AM=0D=0A> To: 'Henning Schulzrinne'=0D=0A> Cc: 'GEOPR= IV'; 'ECRIT'=0D=0A> Subject: RE: [Geopriv] Re: [Ecrit] Not-so-grand comprom= ise on howto=0D=0A> doendpoint centric LCP without giving away the store=0D= =0A>=20=0D=0A> I can live with this way out of the mess.=0D=0A>=20=0D=0A> I= rather like the idea of returning the PSAP service boundary polygon=0D=0Ao= n=0D=0A> the=0D=0A> endpoint's (or VSP's) dereference. The latter (as well= as coarse=0D=0A> location=0D=0A> when it works) also fixes the validation = problem; the VSP=0D=0Adereferences,=0D=0A> gets=0D=0A> the polygon, queries= LoST with it, and gets the PSAP URI.=0D=0A>=20=0D=0A> I agree that in lots= of cases, a very coarse location return from the=0D=0A> LbyR=0D=0A> is suf= ficient, and access networks ought to be able to take advantage=0D=0Aof=0D=0A= > it=0D=0A> when it happens.=0D=0A>=20=0D=0A> I guess we need to hear from = carriers. I think you already raised the=0D=0A> point=0D=0A> that in most = cases, an IP address yields city level location, albeit=0D=0A> VPNs=0D=0A> = often obscure that.=0D=0A>=20=0D=0A> And while you brought it up, I do thin= k a very nice user part of a=0D=0A> location=0D=0A> reference is a hashed t= elephone number. Most of the DSL networks, for=0D=0A> example, do have tel= ephone numbers which actually are easy to turn=0D=0Ainto=0D=0A> service add= ress in the existing databases. I'd prefer it be hashed so=0D=0A> that=0D=0A= > we don't reveal extra user information. I particularly think that=0D=0Ai= dea=0D=0A> will=0D=0A> be quite useful in dealing with legacy wireline syst= ems, which already=0D=0A> associate TN with location. Adding a (hash of) T= N with a provisioned=0D=0A> LIS=0D=0A> domain on a Geolocation header in, o= r near a PSTN to SIP gateway would=0D=0A> be a=0D=0A> very painless way to = get location from a legacy wireline system into a=0D=0A> next=0D=0A> genera= tion emergency call system.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A> > -----= Original Message-----=0D=0A> > From: Henning Schulzrinne [mailto:hgs@cs.col= umbia.edu]=0D=0A> > Sent: Wednesday, April 18, 2007 12:56 PM=0D=0A> > To: B= rian Rosen=0D=0A> > Cc: 'Hannes Tschofenig'; 'GEOPRIV'; 'ECRIT'=0D=0A> > Su= bject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to=0D=0A> >= doendpoint centric LCP without giving away the store=0D=0A> >=0D=0A> >=0D=0A= > > On Apr 18, 2007, at 11:33 AM, Brian Rosen wrote:=0D=0A> >=0D=0A> > > I'= m not sure I understand what you are saying.=0D=0A> > >=0D=0A> > > I'll agr= ee that coarse location may work some times. I wouldn't=0D=0A> > > care to=0D= =0A> > > speculate how often it does or doesn't. I don't think it matters.=0D= =0A> It=0D=0A> >=0D=0A> > This seems to be very country-specific. Thus, in = some countries,=0D=0Athis=0D=0A> > will be quite viable, in others, less so= =2E=0D=0A> >=0D=0A> > For DT, for example, you could have a very simple arc= hitecture:=0D=0A> >=0D=0A> > - Use normal LCP, returning Gemeinde (city/to= wn), Bundesstaat=0D=0A> > (state) and country (DE). This is sufficient for = determining the=0D=0APSAP=0D=0A> > and requires zero interaction with the O= SS.=0D=0A> >=0D=0A> > - Return an LbyR that is similar to what is used toda= y as an=0D=0A> > identifier (phone number=3F), which resolves to the rough = information=0D=0A> > above.=0D=0A> >=0D=0A> >=0D=0A> > > doesn't sometimes.= Does that mean we should misroute in those=0D=0A> > > cases where=0D=0A> = > > you only get coarse location, and you have an irregular boundary=0D=0A>= that=0D=0A> > > "misses"=3F I suspect that would not fly with the access = networks=0D=0A> > > that have=0D=0A> >=0D=0A> > Definitely not. It would be= the responsibility of the ISP to deliver=0D=0A> > location information of = sufficient granularity to prevent misroutes.=0D=0A> > In some small number = of corner cases (typically, the one boundary=0D=0A> > street between PSAP r= egions), this would mean delivering a street=0D=0A> > address or a geo regi= on. This is easy for the ISP to determine -=0D=0Athey=0D=0A> > just query L= oST and get the coverage regions.=0D=0A> >=0D=0A> > If you don't want to do= this, just return the *geo* boundary of the=0D=0A> > PSAP to the customer = as location information via LCP, just like=0D=0Ayou'd=0D=0A> > return an im= precise mapping from a wireless system, as a polygon. By=0D=0A> > our mappi= ng rules, LoST computes the centroid (trivial) and returns=0D=0A> > the PSA= P URL. I think this is somewhat similar to what Andy is=0D=0A> > proposing,= but requires no new effort.=0D=0A> >=0D=0A> > This reveals zero additional= information to the client, beyond the=0D=0A> > coverage region of the PSAP= , but the UA behavior is exactly the same=0D=0A> > as in the no-hiding case= =2E=0D=0A> >=0D=0A> >=0D=0A> > > the hiding problem. You are giving them a= n unacceptable choice:=0D=0A> > > give up=0D=0A> > > accurate location to t= he endpoint or be responsible for misroute.=0D=0A> > > That may=0D=0A> > > = meet your notion of endpoint simplicity, but it won't be deployed=0D=0AI=0D= =0A> > > think.=0D=0A> >=0D=0A> > I don't see this as the alternative. All = I require is that ISP give=0D=0A> > up a tiny fraction of its location info= rmation in some corner cases.=0D=0A> > In most communities, all of the cust= omers will only get city-level=0D=0Aor=0D=0A> > county-level information, w= hich corresponds to what their phone=0D=0A> > number already tells them.=0D= =0A> >=0D=0A> > I think this is a fair bargain. I'd likhashed so=0D=0A> that=0D=0A= > we don't reveal extra user information. I particularly think that=0D=0Ai= dea=0D=0A> will=0D=0A> be quite useful in dealing with legacy wireline syst= ems, which already=0D=0A> associate TN with location. Adding a (hash of) T= N with a provisioned=0D=0A> LIS=0D=0A> domain on a Geolocation header in, o= r near a PSTN to SIP gateway would=0D=0A> be a=0D=0A> very painless way to = get location from a legacy wireline system into a=0D=0A> next=0D=0A> genera= tion emergency call system.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A> > -----= Original Message-----=0D=0A> > From: Henning Schulzrinne [mailto:hgs@cs.col= umbia.edu]=0D=0A> > Sent: Wednesday, April 18, 2007 12:56 PM=0D=0A> > To: B= rian Rosen=0D=0A> > Cc: 'Hannes Tschofenig'; 'GEOPRIV'; 'ECRIT'=0D=0A> > Su= bject: Re: [Geopriv] Re: [Ecrit] Not-so-grand compromise on how to=0D=0A> >= doendpoint centric LCP without giving away the store=0D=0A> >=0D=0A> >=0D=0A= > > On Apr 18, 2007, at 11:33 AM, Brian Rosen wrote:=0D=0A> >=0D=0A> > > I'= m not sure I understand what you are saying.=0D=0A> > >=0D=0A> > > I'll agr= ee that coarse location may work some times. I wouldn't=0D=0A> > > care to=0D= =0A> > > speculate how often it does or doesn't. I don't think it matters.=0D= =0A> It=0D=0A> >=0D=0A> > This seems to be very country-specific. Thus, in = some countries,=0D=0Athis=0D=0A> > will be quite viable, in others, less so= =2E=0D=0A> >=0D=0A> > For DT, for example, you could have a very simple arc= hitecture:=0D=0A> >=0D=0A> > - Use normal LCP, returning Gemeinde (city/to= wn), Bundesstaat=0D=0A> > (state) and country (DE). This is sufficient for = determining the=0D=0APSAP=0D=0A> > and requires zero interaction with the O= SS.=0D=0A> >=0D=0A> > - Return an LbyR that is similar to what is used toda= y as an=0D=0A> > identifier (phone number=3F), which resolves to the rough = information=0D=0A> > above.=0D=0A> >=0D=0A> >=0D=0A> > > doesn't sometimes.= Does that mean we should misroute in those=0D=0A> > > cases where=0D=0A> = > > you only get coarse location, and you have an irregular boundary=0D=0A>= that=0D=0A> > > "misses"=3F I suspect that would not fly with the access = networks=0D=0A> > > that have=0D=0A> >=0D=0A> > Definitely not. It would be= the responsibility of the ISP to deliver=0D=0A> > location information of = sufficient granularity to prevent misroutes.=0D=0A> > In some small number = of corner cases (typically, the one boundary=0D=0A> > street between PSAP r= egions), this would mean delivering a street=0D=0A> > address or a geo regi= on. This is easy for the ISP to determine -=0D=0Athey=0D=0A> > just query L= oST and get the coverage regions.=0D=0A> >=0D=0A> > If you don't want to do= this, just return the *geo* boundary of the=0D=0A> > PSAP to the customer = as location information via LCP, just like=0D=0Ayou'd=0D=0A> > return an im= precise mapping from a wireless system, as a polygon. By=0D=0A> > our mappi= ng rules, LoST computes the centroid (trivial) and returns=0D=0A> > the PSA= P URL. I think this is somewhat similar to what Andy is=0D=0A> > proposing,= but requires no new effort.=0D=0A> >=0D=0A> > This reveals zero additional= information to the client, beyond the=0D=0A> > coverage region of the PSAP= , but the UA behavior is exactly the same=0D=0A> > as in the no-hiding case= =2E=0D=0A> >=0D=0A> >=0D=0A> > > the hiding problem. You are giving them a= n unacceptable choice:=0D=0A> > > give up=0D=0A> > > accurate location to t= he endpoint or be responsible for misroute.=0D=0A> > > That may=0D=0A> > > = meet your notion of endpoint simplicity, but it won't be deployed=0D=0AI=0D= =0A> > > think.=0D=0A> >=0D=0A> > I don't see this as the alternative. All = I require is that ISP give=0D=0A> > up a tiny fraction of its location info= rmation in some corner cases.=0D=0A> > In most communities, all of the cust= omers will only get city-level=0D=0Aor=0D=0A> > county-level information, w= hich corresponds to what their phone=0D=0A> > number already tells them.=0D= =0A> >=0D=0A> > I think this is a fair bargain. I'd like to hear good reaso= ns from=0D=0A> > real carriers as to why this is not acceptable. Shadow box= ing,=0D=0A> > without talking to real customers, seems likely to lead us to= design=0D=0A> > something that doesn't actually help. (Just as I believe t= hat the=0D=0A> > whole architecture proposed doesn't actually address the=0D= =0Adon't-spend-=0D=0A> > money objective of DT.)=0D=0A> >=0D=0A> >=0D=0A> >= >=0D=0A> > > You also seem to be willing to accept that the client will ha= ve=0D=0Atwo=0D=0A> > > locations to deal with: coarse LbyV and fine LbyR. = Not a=0D=0A> > > complication I=0D=0A> > > would want to have to deal with = given my alternative.=0D=0A> >=0D=0A> > Not really. I advocate returning a = single LbyR, which resolves to=0D=0A> > minimal information sufficient for = routing for the general public=0D=0A> > and, with PSAP authentication, to p= recise location information for=0D=0A> > dispatch.=0D=0A> >=0D=0A> > Hennin= g=0D=0A> >=0D=0A> >=0D=0A> > >=0D=0A>=20=0D=0A>=20=0D=0A> _________________= ______________________________=0D=0A> Geopriv mailing list=0D=0A> Geopriv@i= etf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A>=20=0D=0A= >=0D=0A--------------------------------------------------------------------= ----=0D=0A--=0D=0A> ----------------------=0D=0A> This message is for the d= esignated recipient only and may=0D=0A> contain privileged, proprietary, or= otherwise private information.=0D=0A> If you have received it in error, pl= ease notify the sender=0D=0A> immediately and delete the original. Any una= uthorized use of=0D=0A> this email is prohibited.=0D=0A>=0D=0A-------------= -----------------------------------------------------------=0D=0A--=0D=0A> = ----------------------=0D=0A> [mf2]=0D=0A=0D=0A=0D=0A----------------------= --------------------------------------------------------------------------=0D= =0AThis message is for the designated recipient only and may=0D=0Acontain p= rivileged, proprietary, or otherwise private information. =20=0D=0AIf you h= ave received it in error, please notify the sender=0D=0Aimmediately and del= ete the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit e to hear good reaso= ns from=0D=0A> > real carriers as to why this is not acceptable. Shadow box= ing,=0D=0A> > without talking to real customers, seems likely to lead us to= design=0D=0A> > something that doesn't actually help. (Just as I believe t= hat the=0D=0A> > whole architecture proposed doesn't actually address the=0D= =0Adon't-spend-=0D=0A> > money objective of DT.)=0D=0A> >=0D=0A> >=0D=0A> >= >=0D=0A> > > You also seem to be willing to accept that the client will ha= ve=0D=0Atwo=0D=0A> > > locations to deal with: coarse LbyV and fine LbyR. = Not a=0D=0A> > > complication I=0D=0A> > > would want to have to deal with = given my alternative.=0D=0A> >=0D=0A> > Not really. I advocate returning a = single LbyR, which resolves to=0D=0A> > minimal information sufficient for = routing for the general public=0D=0A> > and, with PSAP authentication, to p= recise location information for=0D=0A> > dispatch.=0D=0A> >=0D=0A> > Hennin= g=0D=0A> >=0D=0A> >=0D=0A> > >=0D=0A>=20=0D=0A>=20=0D=0A> _________________= ______________________________=0D=0A> Geopriv mailing list=0D=0A> Geopriv@i= etf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A>=20=0D=0A= >=0D=0A--------------------------------------------------------------------= ----=0D=0A--=0D=0A> ----------------------=0D=0A> This message is for the d= esignated recipient only and may=0D=0A> contain privileged, proprietary, or= otherwise private information.=0D=0A> If you have received it in error, pl= ease notify the sender=0D=0A> immediately and delete the original. Any una= uthorized use of=0D=0A> this email is prohibited.=0D=0A>=0D=0A-------------= -----------------------------------------------------------=0D=0A--=0D=0A> = ----------------------=0D=0A> [mf2]=0D=0A=0D=0A=0D=0A----------------------= --------------------------------------------------------------------------=0D= =0AThis message is for the designated recipient only and may=0D=0Acontain p= rivileged, proprietary, or otherwise private information. =20=0D=0AIf you h= ave received it in error, please notify the sender=0D=0Aimmediately and del= ete the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 09:15:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfyNx-0004yb-62; Mon, 23 Apr 2007 09:15:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfyNw-0004vg-JL for ecrit@ietf.org; Mon, 23 Apr 2007 09:15:16 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfyNr-0008T7-DG for ecrit@ietf.org; Mon, 23 Apr 2007 09:15:16 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HfyMS-0004vU-SP; Mon, 23 Apr 2007 08:13:45 -0500 From: "Brian Rosen" To: "'Thomson, Martin'" , "'Andrew Newton'" , "'Hannes Tschofenig'" Subject: RE: [Ecrit] Consensus Call: Precise Location Information notavailableto End Host Date: Mon, 23 Apr 2007 09:15:07 -0400 Message-ID: <040601c785a9$6b6d9760$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: AceEOMPiyHrtBsM+Qv+YbUo4I44zQQBBfMdAABp274A= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 1.1 (+) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Maybe I'm dense. I thought we do a simple geometry calculation that yields a single result. That result may not always be correct, but then, no algorithm we know of would yield a single correct answer. When we have a true case of uncertainty that creates a situation where the target could reasonably be in more than one PSAP service area, you pick one, send the call there and let them deal with it. It's much more important to be decisive (and predictable) than to try to achieve perfection if it costs time and could stress already stressed systems. You never send the call to two places. Flipping a coin is okay if there is roughly equal probability of being in two service areas. It should be possible to avoid the problem in the "hiding" case of course; we're just talking about the consequences of allowing all the shapes in -profile to be a location. Brian > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Sunday, April 22, 2007 8:34 PM > To: Andrew Newton; Hannes Tschofenig > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] Consensus Call: Precise Location Information > notavailableto End Host > > > > > Every non-civic location type will have to be able to take in the > > equivalent of a service boundary as input. Assuming exact service > > boundaries are the input every time, we have no problem. However, > > what's a resolver to do if the input (a polygon in geodetic-2d or > > perhaps an ellipse in geodetic-3d) crosses boundaries, which would > > now be perfectly legal. We've been down this path before and nobody > > has been able to explain the behavior of this case satisfactorily. > > There is a solution. However, there were concerns about the implications > of the solution. That is, forking of LoST queries would be required. I > can't see a way out of that particular problem. > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 10:41:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfzix-0002qa-1A; Mon, 23 Apr 2007 10:41:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hfziv-0002px-T1 for ecrit@ietf.org; Mon, 23 Apr 2007 10:41:01 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hfziu-000339-62 for ecrit@ietf.org; Mon, 23 Apr 2007 10:41:01 -0400 Received: from ([139.76.131.91]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.175622472; Mon, 23 Apr 2007 10:40:50 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 23 Apr 2007 10:40:48 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 23 Apr 2007 10:40:48 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: [Ecrit] phonebcp and testing location correctness X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 23 Apr 2007 10:40:47 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA03B0FB2A@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] phonebcp and testing location correctness thread-index: AceCzqCpLipzJlT2TryY3i1JodKddAC5Yw1w References: <124a01c782c3$c5676630$640fa8c0@cis.neustar.com> From: "Stark, Barbara" To: "Henning Schulzrinne" , "Ted Hardie" X-OriginalArrivalTime: 23 Apr 2007 14:40:48.0228 (UTC) FILETIME=[61F3A240:01C785B5] X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Having thought about this over the weekend, I think I prefer recommending the voice-back of the de-referenced location, over providing a PIDF-LO in the 200 OK. For all the reasons that Henning mentioned. But I don't know how this would work if the negotiated medium were something other than a voice codec. Does support of this function for non-voice media need to be recommended? Barbara -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Thursday, April 19, 2007 6:05 PM To: Ted Hardie Cc: 'ECRIT' Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: (Partial)LocationHiding Emergency Services Architecture The whole point is that the caller can, if he so desires, verify the location information. Incorrect location information is a major source of mis-routes and false dispatches today (see the NYT article I sent around a few weeks ago). Since location information, even without hiding, can be added by a proxy, this is the only way for the end system to determine what information will be conveyed to the PSAP in all cases. In existing system, finding this out is extremely tedious and burdensome to the PSAP, as you actually have to call 911 to see what address your carrier has registered for you. You really don't want to resolve the "No, I'm not living at 123 Main Street, that's my billing address" =20 during an emergency call. I have no objection to returning this PSAP-seen information in some other way, such as location-conveyance, but I expected to hear screams from the hide-location crowd in that case. Thus, I was trying to find a way that achieves most of the goals, while not stepping on sensitive toes. Since the existing test text includes the return of location information, albeit in a format that is left unspecified (which should be fixed), I'm happy with that. I also have no objection to making this an optional request in the call, so that unattended test calls do not generate this, but I'm not convinced that the complexity is worth it. Thus, I believe that this mechanism adds significantly to the overall reliability of the system and we should encourage that it be provided, whether as location-conveyance, audio or just a PIDF-LO attachment in the 200 OK. (This generally won't work well, given the difficulty real phones have with multipart, but that's a different topic.) Henning On Apr 19, 2007, at 5:43 PM, Ted Hardie wrote: > At 4:46 PM -0400 4/19/07, Brian Rosen wrote: >> I dropped geopriv >> >> Please look at -phonebcp for the current test procedure. This would=20 >> add a step. > > So, the proposal is to add this to 9.1. The current version says: > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 11:10:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg0BW-00010t-1T; Mon, 23 Apr 2007 11:10:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg0BU-0000pL-6S for ecrit@ietf.org; Mon, 23 Apr 2007 11:10:32 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg0BT-00065r-R2 for ecrit@ietf.org; Mon, 23 Apr 2007 11:10:32 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1Hg0A4-0005MN-L9; Mon, 23 Apr 2007 10:09:04 -0500 From: "Brian Rosen" To: "'Stark, Barbara'" , "'Henning Schulzrinne'" , "'Ted Hardie'" Subject: RE: [Ecrit] phonebcp and testing location correctness Date: Mon, 23 Apr 2007 11:10:25 -0400 Message-ID: <04b001c785b9$88263dc0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA03B0FB2A@crexc41p> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: AceCzqCpLipzJlT2TryY3i1JodKddAC5Yw1wAADhLqA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org You have the problem with the deaf community; a very vocal and effective lobbyist for something I consider a very reasonable point of view: they want equivalent service. The specs require support for IM and real time interactive text. If that is the media asserted on the test INVITE, they would expect the location coming back as text. Similarly, if they ask for video, they are expecting sign language. I have a query into them about the practicality of text to sign language. I don't see why it won't work just fine. Presumably you wouldn't have a problem with that. Brian > -----Original Message----- > From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > Sent: Monday, April 23, 2007 10:41 AM > To: Henning Schulzrinne; Ted Hardie > Cc: ECRIT > Subject: [Ecrit] phonebcp and testing location correctness > > Having thought about this over the weekend, I think I prefer > recommending the voice-back of the de-referenced location, over > providing a PIDF-LO in the 200 OK. For all the reasons that Henning > mentioned. But I don't know how this would work if the negotiated medium > were something other than a voice codec. Does support of this function > for non-voice media need to be recommended? > Barbara > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, April 19, 2007 6:05 PM > To: Ted Hardie > Cc: 'ECRIT' > Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: > (Partial)LocationHiding Emergency Services Architecture > > The whole point is that the caller can, if he so desires, verify the > location information. Incorrect location information is a major source > of mis-routes and false dispatches today (see the NYT article I sent > around a few weeks ago). > > Since location information, even without hiding, can be added by a > proxy, this is the only way for the end system to determine what > information will be conveyed to the PSAP in all cases. In existing > system, finding this out is extremely tedious and burdensome to the > PSAP, as you actually have to call 911 to see what address your carrier > has registered for you. You really don't want to resolve the "No, I'm > not living at 123 Main Street, that's my billing address" > during an emergency call. > > I have no objection to returning this PSAP-seen information in some > other way, such as location-conveyance, but I expected to hear screams > from the hide-location crowd in that case. Thus, I was trying to find a > way that achieves most of the goals, while not stepping on sensitive > toes. Since the existing test text includes the return of location > information, albeit in a format that is left unspecified (which should > be fixed), I'm happy with that. > > I also have no objection to making this an optional request in the call, > so that unattended test calls do not generate this, but I'm not > convinced that the complexity is worth it. > > Thus, I believe that this mechanism adds significantly to the overall > reliability of the system and we should encourage that it be provided, > whether as location-conveyance, audio or just a PIDF-LO attachment in > the 200 OK. (This generally won't work well, given the difficulty real > phones have with multipart, but that's a different > topic.) > > Henning > > On Apr 19, 2007, at 5:43 PM, Ted Hardie wrote: > > > At 4:46 PM -0400 4/19/07, Brian Rosen wrote: > >> I dropped geopriv > >> > >> Please look at -phonebcp for the current test procedure. This would > >> add a step. > > > > So, the proposal is to add this to 9.1. The current version says: > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 11:42:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg0fz-0001yZ-5e; Mon, 23 Apr 2007 11:42:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg0fx-0001w6-W4 for ecrit@ietf.org; Mon, 23 Apr 2007 11:42:01 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg0fv-00074J-N9 for ecrit@ietf.org; Mon, 23 Apr 2007 11:42:01 -0400 Received: from [160.39.243.75] (dyn-160-39-243-75.dyn.columbia.edu [160.39.243.75]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3NFeM9f003844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Apr 2007 11:41:53 -0400 (EDT) In-Reply-To: <462BBD04.9060602@gmx.net> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host Date: Mon, 23 Apr 2007 09:19:25 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'm less worried about DHCP, but rather about PIDF-LO, as the variability and extensibility of that data element is much larger. One of the problems is that a device has to mark the location information with a profile, instead of just copying the data. I think it would be better to have the client provide the LO, and the server reject it if can't parse that particular GML-derived format. This imposes little additional burden on the server, since it will have to check the LO in any event. After all, just because the client says it's sending 2D-geo doesn't mean that the XML actually contains no more than 2D-geo. We still need to define a set of must-implement profiles for the server. Negotiation makes no sense in this case (due to the multi-hop nature of LoST), so this set is likely to remain fairly constant over long time periods. (Obviously, a client still has to indicate what kind of service region information it understands.) Henning On Apr 22, 2007, at 3:52 PM, Hannes Tschofenig wrote: > Tiny remark: > > Henning Schulzrinne wrote: >> I think one of the objectives should be that a UA can copy >> location information from a PIDF-LO-speaking protocol to LoST >> without knowing anything about the content. > > Currently it has to understand at least a little bit since the > location shapes are much simpler than the stuff provided in > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo- > profile-06.txt > > The translation from DHCP civic is without problems a copy-and- > paste operation. > The translation from DHCP geo isn't a problem if we do not consider > compound location information and if we ignore the topic of > resolution. > The latter aspect caused a lot of discussion..... > > Ciao > Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 11:42:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg0fz-0001yi-AD; Mon, 23 Apr 2007 11:42:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg0fy-0001x7-9C for ecrit@ietf.org; Mon, 23 Apr 2007 11:42:02 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg0fv-00074M-Ny for ecrit@ietf.org; Mon, 23 Apr 2007 11:42:02 -0400 Received: from [160.39.243.75] (dyn-160-39-243-75.dyn.columbia.edu [160.39.243.75]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3NFeM9g003844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Apr 2007 11:41:56 -0400 (EDT) In-Reply-To: <68F36998-36AF-4D03-866D-8E150C5863C5@hxr.us> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBE1C.2070908@gmx.net> <68F36998-36AF-4D03-866D-8E150C5863C5@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <52FFCA18-2943-444B-9DB1-439B9A2371D1@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host Date: Mon, 23 Apr 2007 09:22:50 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org You just do centroid computation on the location-describing polygon, which is very simple for polygons without holes. (Polygons with holes are only of interest for service regions, so they don't affect the problem in the subject line.) On Apr 22, 2007, at 8:56 PM, Andrew Newton wrote: > > On Apr 22, 2007, at 3:57 PM, Hannes Tschofenig wrote: > >> I also believe that defining a new location profile (or extending >> an existing one) would be much simpler. > > Can you explain "simpler"? How do you arrive at that conclusion? > Defining a new location profile or extending an existing one is > certainly simpler for the current specification and probably the on- > the-wire LoST protocol. But the server implementations are not > simpler. At the authoritative server, a "is this polygon inside > this polygon" query is more compute intensive (though I realize it > is just an iterative form of "is this point inside this polygon"), > and at the resolvers there is now the possibility of forking (which > might require protocol changes anyway). > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 11:44:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg0id-0005Ym-Gr; Mon, 23 Apr 2007 11:44:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg0ib-0005Ya-RF for ecrit@ietf.org; Mon, 23 Apr 2007 11:44:45 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg0ib-0000LW-Jb for ecrit@ietf.org; Mon, 23 Apr 2007 11:44:45 -0400 Received: from [160.39.243.75] (dyn-160-39-243-75.dyn.columbia.edu [160.39.243.75]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3NFiMHH005094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Apr 2007 11:44:43 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Consensus Call: Precise Location Information notavailable to End Host Date: Mon, 23 Apr 2007 11:40:22 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Let's not try to solve problems we don't have for this particular thread. So far, the location is at least as precise as the PSAP boundary. Otherwise, as we had discussed before, the server takes the centroid as the most likely point and uses that for mapping. That works even if the location estimate should span multiple service regions. This beats returning no answer. A while ago, I had written a long message as to why computations involving anything else (probabilities, etc.) are unlikely to be more precise, given the limitations of these approaches. On Apr 22, 2007, at 8:50 PM, Andrew Newton wrote: > > On Apr 22, 2007, at 8:34 PM, Thomson, Martin wrote: > >> >> There is a solution. However, there were concerns about the >> implications of the solution. That is, forking of LoST queries >> would be required. I can't see a way out of that particular problem. > > Exactly, we are now full circle back to that problem. > > One other point about using a mapping or service boundary > reference, it allows the data hiding to be as granular or fine as > the LIS desires. Currently, the "unauthorized" LbyR cannot be more > granular than the PSAP service boundary of the endpoint. > > -andy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 11:47:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg0ky-0007Uc-T6; Mon, 23 Apr 2007 11:47:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg0kx-0007S2-Fz for ecrit@ietf.org; Mon, 23 Apr 2007 11:47:11 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg0kv-0000lT-2P for ecrit@ietf.org; Mon, 23 Apr 2007 11:47:11 -0400 Received: from ([139.76.131.91]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.175633570; Mon, 23 Apr 2007 11:46:47 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 23 Apr 2007 11:46:45 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 23 Apr 2007 11:46:44 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] phonebcp and testing location correctness X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 23 Apr 2007 11:46:44 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA03B0FB87@crexc41p> In-Reply-To: <04b001c785b9$88263dc0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] phonebcp and testing location correctness thread-index: AceCzqCpLipzJlT2TryY3i1JodKddAC5Yw1wAADhLqAAAZLBoA== References: <7582BC68E4994F4ABF0BD4723975C3FA03B0FB2A@crexc41p> <04b001c785b9$88263dc0$640fa8c0@cis.neustar.com> From: "Stark, Barbara" To: "Brian Rosen" , "Henning Schulzrinne" , "Ted Hardie" X-OriginalArrivalTime: 23 Apr 2007 15:46:44.0970 (UTC) FILETIME=[985A8CA0:01C785BE] X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I would think that video letter-by-letter automated spelling of a location would be rather tedious to watch. Could we send a JPG picture of a street map with a star where the location is? Barbara=20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Monday, April 23, 2007 11:10 AM To: Stark, Barbara; 'Henning Schulzrinne'; 'Ted Hardie' Cc: 'ECRIT' Subject: RE: [Ecrit] phonebcp and testing location correctness You have the problem with the deaf community; a very vocal and effective lobbyist for something I consider a very reasonable point of view: they want equivalent service. The specs require support for IM and real time interactive text. If that is the media asserted on the test INVITE, they would expect the location coming back as text. Similarly, if they ask for video, they are expecting sign language. I have a query into them about the practicality of text to sign language. I don't see why it won't work just fine. Presumably you wouldn't have a problem with that. Brian > -----Original Message----- > From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > Sent: Monday, April 23, 2007 10:41 AM > To: Henning Schulzrinne; Ted Hardie > Cc: ECRIT > Subject: [Ecrit] phonebcp and testing location correctness >=20 > Having thought about this over the weekend, I think I prefer=20 > recommending the voice-back of the de-referenced location, over=20 > providing a PIDF-LO in the 200 OK. For all the reasons that Henning=20 > mentioned. But I don't know how this would work if the negotiated=20 > medium were something other than a voice codec. Does support of this=20 > function for non-voice media need to be recommended? > Barbara >=20 > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, April 19, 2007 6:05 PM > To: Ted Hardie > Cc: 'ECRIT' > Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: > (Partial)LocationHiding Emergency Services Architecture >=20 > The whole point is that the caller can, if he so desires, verify the=20 > location information. Incorrect location information is a major source > of mis-routes and false dispatches today (see the NYT article I sent=20 > around a few weeks ago). >=20 > Since location information, even without hiding, can be added by a=20 > proxy, this is the only way for the end system to determine what=20 > information will be conveyed to the PSAP in all cases. In existing=20 > system, finding this out is extremely tedious and burdensome to the=20 > PSAP, as you actually have to call 911 to see what address your=20 > carrier has registered for you. You really don't want to resolve the=20 > "No, I'm not living at 123 Main Street, that's my billing address" > during an emergency call. >=20 > I have no objection to returning this PSAP-seen information in some=20 > other way, such as location-conveyance, but I expected to hear screams > from the hide-location crowd in that case. Thus, I was trying to find=20 > a way that achieves most of the goals, while not stepping on sensitive > toes. Since the existing test text includes the return of location=20 > information, albeit in a format that is left unspecified (which should > be fixed), I'm happy with that. >=20 > I also have no objection to making this an optional request in the=20 > call, so that unattended test calls do not generate this, but I'm not=20 > convinced that the complexity is worth it. >=20 > Thus, I believe that this mechanism adds significantly to the overall=20 > reliability of the system and we should encourage that it be provided, > whether as location-conveyance, audio or just a PIDF-LO attachment in=20 > the 200 OK. (This generally won't work well, given the difficulty real > phones have with multipart, but that's a different > topic.) >=20 > Henning >=20 > On Apr 19, 2007, at 5:43 PM, Ted Hardie wrote: >=20 > > At 4:46 PM -0400 4/19/07, Brian Rosen wrote: > >> I dropped geopriv > >> > >> Please look at -phonebcp for the current test procedure. This=20 > >> would add a step. > > > > So, the proposal is to add this to 9.1. The current version says: > > >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 12:06:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg13m-0006oB-UC; Mon, 23 Apr 2007 12:06:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg13m-0006o5-HV for ecrit@ietf.org; Mon, 23 Apr 2007 12:06:38 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg13e-0007m7-Te for ecrit@ietf.org; Mon, 23 Apr 2007 12:06:38 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1Hg12F-0002NN-4R; Mon, 23 Apr 2007 11:05:03 -0500 From: "Brian Rosen" To: "'Stark, Barbara'" , "'Henning Schulzrinne'" , "'Ted Hardie'" Subject: RE: [Ecrit] phonebcp and testing location correctness Date: Mon, 23 Apr 2007 12:06:23 -0400 Message-ID: <04d301c785c1$58d38cf0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA03B0FB87@crexc41p> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: AceCzqCpLipzJlT2TryY3i1JodKddAC5Yw1wAADhLqAAAZLBoAAAw3bw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Yeah, maybe. I don't know how well that works on MPEG encoded video. However, spelling is just about the only way to sign a street address; there are no signs for some street names and many city names. Spelling is one of the most common signs everyone learns. Good CAs spell really fast. Brian > -----Original Message----- > From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > Sent: Monday, April 23, 2007 11:47 AM > To: Brian Rosen; Henning Schulzrinne; Ted Hardie > Cc: ECRIT > Subject: RE: [Ecrit] phonebcp and testing location correctness > > I would think that video letter-by-letter automated spelling of a > location would be rather tedious to watch. > > Could we send a JPG picture of a street map with a star where the > location is? > Barbara > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, April 23, 2007 11:10 AM > To: Stark, Barbara; 'Henning Schulzrinne'; 'Ted Hardie' > Cc: 'ECRIT' > Subject: RE: [Ecrit] phonebcp and testing location correctness > > You have the problem with the deaf community; a very vocal and effective > lobbyist for something I consider a very reasonable point of view: they > want equivalent service. The specs require support for IM and real time > interactive text. If that is the media asserted on the test INVITE, > they would expect the location coming back as text. > > Similarly, if they ask for video, they are expecting sign language. I > have a query into them about the practicality of text to sign language. > I don't see why it won't work just fine. Presumably you wouldn't have a > problem with that. > > Brian > > > -----Original Message----- > > From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > > Sent: Monday, April 23, 2007 10:41 AM > > To: Henning Schulzrinne; Ted Hardie > > Cc: ECRIT > > Subject: [Ecrit] phonebcp and testing location correctness > > > > Having thought about this over the weekend, I think I prefer > > recommending the voice-back of the de-referenced location, over > > providing a PIDF-LO in the 200 OK. For all the reasons that Henning > > mentioned. But I don't know how this would work if the negotiated > > medium were something other than a voice codec. Does support of this > > function for non-voice media need to be recommended? > > Barbara > > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Thursday, April 19, 2007 6:05 PM > > To: Ted Hardie > > Cc: 'ECRIT' > > Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: > > (Partial)LocationHiding Emergency Services Architecture > > > > The whole point is that the caller can, if he so desires, verify the > > location information. Incorrect location information is a major source > > > of mis-routes and false dispatches today (see the NYT article I sent > > around a few weeks ago). > > > > Since location information, even without hiding, can be added by a > > proxy, this is the only way for the end system to determine what > > information will be conveyed to the PSAP in all cases. In existing > > system, finding this out is extremely tedious and burdensome to the > > PSAP, as you actually have to call 911 to see what address your > > carrier has registered for you. You really don't want to resolve the > > "No, I'm not living at 123 Main Street, that's my billing address" > > during an emergency call. > > > > I have no objection to returning this PSAP-seen information in some > > other way, such as location-conveyance, but I expected to hear screams > > > from the hide-location crowd in that case. Thus, I was trying to find > > a way that achieves most of the goals, while not stepping on sensitive > > > toes. Since the existing test text includes the return of location > > information, albeit in a format that is left unspecified (which should > > > be fixed), I'm happy with that. > > > > I also have no objection to making this an optional request in the > > call, so that unattended test calls do not generate this, but I'm not > > convinced that the complexity is worth it. > > > > Thus, I believe that this mechanism adds significantly to the overall > > reliability of the system and we should encourage that it be provided, > > > whether as location-conveyance, audio or just a PIDF-LO attachment in > > the 200 OK. (This generally won't work well, given the difficulty real > > > phones have with multipart, but that's a different > > topic.) > > > > Henning > > > > On Apr 19, 2007, at 5:43 PM, Ted Hardie wrote: > > > > > At 4:46 PM -0400 4/19/07, Brian Rosen wrote: > > >> I dropped geopriv > > >> > > >> Please look at -phonebcp for the current test procedure. This > > >> would add a step. > > > > > > So, the proposal is to add this to 9.1. The current version says: > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 12:26:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1N1-000757-CW; Mon, 23 Apr 2007 12:26:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1N0-00073t-8F for ecrit@ietf.org; Mon, 23 Apr 2007 12:26:30 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg1LA-0005E7-1i for ecrit@ietf.org; Mon, 23 Apr 2007 12:24:37 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 23 Apr 2007 12:24:35 -0400 id 01588104.462CDDC3.00003DE3 In-Reply-To: References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host Date: Mon, 23 Apr 2007 12:24:34 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 23, 2007, at 9:19 AM, Henning Schulzrinne wrote: > I'm less worried about DHCP, but rather about PIDF-LO, as the > variability and extensibility of that data element is much larger. > One of the problems is that a device has to mark the location > information with a profile, instead of just copying the data. I > think it would be better to have the client provide the LO, and the > server reject it if can't parse that particular GML-derived format. The entire LO? I thought it was a part of our requirements that identifying information not be sent inside of LoST. It just needs to copy the location information XML. I don't really understand your concern. BTW, while some of us implicitly understand this, do have it written anywhere that RFC 3825 without floor is geodetic-2d and that RFC 4776 is the civic profile. > This imposes little additional burden on the server, since it will > have to check the LO in any event. After all, just because the > client says it's sending 2D-geo doesn't mean that the XML actually > contains no more than 2D-geo. I agree. > We still need to define a set of must-implement profiles for the > server. Negotiation makes no sense in this case (due to the multi- > hop nature of LoST), so this set is likely to remain fairly > constant over long time periods. Huh? Didn't we already discuss this? geodetic-2d and civic are the two base profiles. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 12:27:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1OB-0000QM-MO; Mon, 23 Apr 2007 12:27:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1OA-0000QB-2I for ecrit@ietf.org; Mon, 23 Apr 2007 12:27:42 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg1O8-00067t-Sz for ecrit@ietf.org; Mon, 23 Apr 2007 12:27:42 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 23 Apr 2007 12:27:40 -0400 id 01588104.462CDE7C.00003E8B In-Reply-To: <52FFCA18-2943-444B-9DB1-439B9A2371D1@cs.columbia.edu> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBE1C.2070908@gmx.net> <68F36998-36AF-4D03-866D-8E150C5863C5@hxr.us> <52FFCA18-2943-444B-9DB1-439B9A2371D1@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6167C70C-69C8-4FC9-B301-11D3FFAFF63D@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host Date: Mon, 23 Apr 2007 12:27:39 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 23, 2007, at 9:22 AM, Henning Schulzrinne wrote: > You just do centroid computation on the location-describing > polygon, which is very simple for polygons without holes. (Polygons > with holes are only of interest for service regions, so they don't > affect the problem in the subject line.) I understand your argument. There is a long, inconclusive email thread on it. Your point about holes actually makes this a bit more troublesome though. What do you mean by service regions? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 12:54:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1o9-0006zd-G1; Mon, 23 Apr 2007 12:54:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg1o7-0006wi-Rb for ecrit@ietf.org; Mon, 23 Apr 2007 12:54:31 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg1o6-0007Mw-84 for ecrit@ietf.org; Mon, 23 Apr 2007 12:54:31 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Hg1o5-0003Ly-5p; Mon, 23 Apr 2007 12:54:29 -0400 Received: from [127.0.0.1] (col-dhcp33-244-156.bbn.com [128.33.244.156]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l3NGsSw17569; Mon, 23 Apr 2007 12:54:28 -0400 (EDT) Message-ID: <462CE4C4.9010002@bbn.com> Date: Mon, 23 Apr 2007 12:54:28 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] An alternative proposal References: <4628FD3E.5080009@bbn.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------080101090301080700030705" X-Spam-Score: 0.0 (/) X-Scan-Signature: 847361531d5cb2b89126844012e81b58 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --------------080101090301080700030705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit James, Good idea. I've written down my perception of the problem statement and requirements (with some of the below analysis) in a short I-D: Until it posts, a copy is attached. --Richard James M. Polk wrote: > this should be in a draft, to give the WG the ability to focus and > comment on a fixed target (the contents of the ID) and not a moving > thread that can change as often as the wind > > James > > At 12:49 PM 4/20/2007, Richard Barnes wrote: >> Using LbyR to provision location raises two problems that I'd like to >> address separately: >> 1. Endpoint acquisition of a appropriate PSAP URI, and >> 2. VSP verification of a supposed PSAP URI. >> >> Henning's requirements 1,2,4,6 apply to problem 1, and 3,4,5,6 apply >> to problem 2. >> >> ===== Endpoint acquisition of a appropriate PSAP URI ===== >> Proposal 1(a): Extend LoST to carry LbyR. >> Proposal 1(b): Require that every LIS act as a LoST server for >> endpoints that it serves. >> >> [Proposal 1(b) could be softened with "... or explicitly delegate to a >> LoST server that is authorized to dereference, e.g., with an SIP or >> HTTP 3xx response"]. >> >> Scenario: >> 1. The endpoint uses an LCP to request location. >> 2. The LIS returns an LbyR. >> 3. The endpoint sends a LoST query to the LIS containing this LbyR. >> 4. The LIS does the same LoST query, but with LbyR replaced with LbyV. >> 5. The LIS sends the LoST response back to the endpoint. >> >> Call flow: >> Client LIS LoST >> | LCP Req. | | >> |----------->| | >> | LbyR | | >> |<-----------| | >> | LoST/LbyR | | >> |----------->| | >> | | LoST/LbyV | >> | |-------------->| >> | | LoST Resp. | >> | |<--------------| >> | Lost Resp. | | >> |<-----------| | >> | | | >> >> Requirements: >> 3. No magic configuration for UAs. >> No configuration necessary beyond LIS discovery. >> >> 4. Multiple LoST server hierarchies, with resolvers that have no trust >> relationship with the PSAP or the ISP. >> Depends on your semantics. The endpoint effectively uses the LIS as a >> resolver, but beyond that there are no extraordinary trust >> relationships. In the "rough location" proposal, the client >> implicitly trusts the LIS to LoST anyway; this just makes it explicit. >> >> 5. Minimal impact on UAs; in particular, fail-and-try-something-else >> is not acceptable. >> Not sure what this means in this case. >> >> 6. Bonus points for avoiding modifications to LoST, SIP location >> conveyance, DHCP. >> This only requires a small modification to LoST, so it's pretty >> straightforward, but no bonus points. >> >> >> >> >> ===== VSP verification of a supposed PSAP URI ===== >> There are two questions a VSP could ask: >> 1. Is this URI the URI of any PSAP? >> 2. Is this URI the URI of the PSAP that this UA should be calling? >> >> Note that the first question is independent of whether location is >> carried byV or byR, and thus a much simpler mechanism could be used to >> answer it. >> Proposal 2: Introduce a Reverse-LoST protocol that accepts a PSAP URI >> as input and returns a service area (or even just a boolean). >> >> Requirements: >> 1. No business or trust relationship between ISPs and VSPs >> None required. >> >> 2. VSPs can be outside the jurisdiction of the PSAP and can be Joe's >> Bakery and Car Repair. >> Anyone can do the verification, so in particular, Joe's Bakery and Car >> Repair can. >> >> 4. Multiple LoST server hierarchies, with resolvers that have no trust >> relationship with the PSAP or the ISP. >> No trust relationships necessary, as no sensitive data is passed. >> >> 6. Bonus points for avoiding modifications to LoST, SIP location >> conveyance, DHCP. >> I guess this one gets bonus points, but at the expense of a new protocol. >> >> >> IMHO, the first question is the only reasonable one to support: >> 1. It is not the role of the VSP to distinguish among emergency calls; >> that's the job of the routing infrastructure. It's entirely possible >> for this verification to fail because the endpoint has crossed into a >> neighboring PSAP coverage area, and I think we agree that the call >> shouldn't fail in this case. >> 2. Trying to support the second question often leads to unacceptable >> privacy consequences. The privacy risks incurred by the "rough >> location" proposal are due to the fact that it tries to answer the >> second question: Since VSPs can be (effectively) anyone, the LIS has >> to give out location to everyone in order for VSPs to be able to use >> location for this purpose. >> >> It's tempting to say that either question could be answered by a query >> to the LoST function of the LIS, or via LoST/LbyR, with some LoST >> server authenticating itself to the LIS, but both of these introduce >> the same privacy risks as the "rough location" proposal. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > --------------080101090301080700030705 Content-Type: text/plain; name="draft-barnes-ecrit-lbyr-reqs-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-barnes-ecrit-lbyr-reqs-00.txt" Network Working Group R. Barnes Internet-Draft BBN Technologies Intended status: Informational April 2005 Expires: October 3, 2005 Requirements for Emergency Calling with Location by Reference draft-barnes-ecrit-lbyr-reqs-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 3, 2005. Copyright Notice Copyright (C) The IETF Trust (2005). Abstract It is anticipated that there will be networks in which endpoints will not be provided their own location via a location reference that they cannot dereference, so that endpoints will not have access to their own location. In order to ensure that emergency calling services are available to endpoints in such environments, it may be necessary to modify existing or proposed ECRIT protocols, and to recommend a high- level architecture in which these protocols are used together for emergency calling in such an environment. This document describes Barnes Expires October 3, 2005 [Page 1] Internet-Draft L-by-R Emergency Calling April 2005 the problem, lists requirements for such protocol modifications and architectures, and examines some privacy implications of the requirements. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. PSAP URI Verification & Privacy . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 7 Barnes Expires October 3, 2005 [Page 2] Internet-Draft L-by-R Emergency Calling April 2005 1. Introduction As the location-provisioning functions necessary for VoIP emergency calling are deployed, it is anticipated that some networks will choose not to provision location information directly to end hosts, instead provisioning location references (that the endpoint may not be able to dereference). (A discussion of motivations for such a policy is outside the scope of this document.) On the other hand, several existing or candidate IETF protocols that support emergency calling depend on the assumption that endpoints have explicit knowledge of their own location. Thus, there is some question as to whether existing protocols can be used to support emergency calling in an environment where this assumption may be false. For clarity, we recall here the steps for making an emergency call when an endpoint is provisioned with its own location: 1. The endpoint acquires its location via a Location Configuration Protocol (LCP) 2. The endpoint queries a Location to Service Translation (LoST) server with its location and a desired emergency service to obtain the URI of a PSAP providing that service 3. The endpoint sends a SIP INVITE message with that PSAP URI in the Request-URI field, and with its location in the body of the INVITE 4. Any proxy handling this INVITE can verify that the Request-URI in the INVITE is a valid PSAP by performing the same LoST query that the client did. (Note that although in this example the client performs the mapping operation and uses SIP, it is straightforward to adapt it to scenarios in which a SIP proxy performs the mapping operation (based on a service URN and location in the INVITE), or in which a protocol other than SIP is used to place the call.) In order to ensure support for emergency calling in environments where location is provisioned by reference, two problems need to be solved. First, corresponding to step 2 above, there must be a mechanism by which the endpoint can obtain a URI for the PSAP that serves it. And second, corresponding to step 4, there must be a mechanism by which third parties (e.g. SIP proxies handling an emergency call) can verify that a URI that is claimed to be a PSAP URI actually is one. (The latter problem, PSAP URI verification, is more general; it could arise, for example, if the location transmitted in a call were encrypted with the public key of a PSAP.) Barnes Expires October 3, 2005 [Page 3] Internet-Draft L-by-R Emergency Calling April 2005 The most significant obstacles to solving these problems are authenticity and privacy. There are four classes of entities involved in emergency call setup: endpoints, Internet service providers (ISPs, i.e., access networks), voice service providers (VSPs), and PSAPs. The first three of these classes are expected to be so numerous, autonomous, and widely dispersed that it is infeasible to construct an infrastructure to authenticate them to each other, so solutions must not depend on such relationships. However, at the same time, privacy restrictions imposed by endpoints and ISPs must remain in force. 2. Requirements Provisioning-1. Minimal configuration: Any necessary configuration of UAs SHOULD be possible using existing protocols for that purpose. Provisioning-2. LoST servers involved in the mapping operation SHOULD NOT need to have a trust relationship with either the PSAP or the ISP. Verification-1. Trust relationships between ISPs and VSPs SHOULD NOT be required. Verification-1. It SHOULD be possible for any VSP to verify a PSAP URI, in particular VSPs outside of the PSAP's jurisdiction and without any credential attesting to their status as a VSP. Common-1. The solution(s) MUST NOT require that any participant disclose the location of an endpoint to an unauthorized party, even at the granularity of PSAP boundaries. Common-2. The solutions(s) SHOULD avoid modification to existing protocols (e.g., LoST, SIP location conveyance, or DHCP options) 3. PSAP URI Verification & Privacy There are three questions that a VSP might ask about a URI that is claimed to be a PSAP URI in an emergency call, each with with different implications for location privacy: 1. Is this URI the URI for a PSAP (i.e., any PSAP, anywhere)? 2. What is the PSAP service area for this URI (empty if it is not a PSAP URI)? Barnes Expires October 3, 2005 [Page 4] Internet-Draft L-by-R Emergency Calling April 2005 3. Is this URI the URI for the PSAP serving the caller? Answering the first question involves no sensitive location data. The location of the caller is irrelevant to this question, and the answer contains only a binary true/false value. The second question does expose the location of the caller, at PSAP service-area granularity, by virtue of the fact that a given PSAP URI is included in call signaling that identifies the caller. However, this correlation between PSAP and identity is only available to entities that participate in emergency call setup, who are required to know the caller's location (at that granularity) for the call to be properly routed. To answer the third question, the querier (hereafter assumed to be a VSP) must know the location of the caller (at PSAP service-area granularity) so that the proper PSAP and PSAP URI for the caller can be determined, and this requires that the VSP to be authorized by the ISP and the endpoint to have access to this location information. However, in order for this authorization to be made, VSPs and PSAPs must be able to authenticate themselves to the entity that grants access to location (presumably a location server operated by the ISP), since otherwise any host that knows or can guess the location reference would be able to obtain the endpoint's location. Thus, answering question three while protecting the privacy of the endpoint's location requires that VSPs and PSAPs be able to authenticate to the endpoint's ISP; i.e, a system that answers question three cannot simultaneously comply with requirements Common-1 and Verification-1. 4. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5. Security Considerations 6. Acknowledgements 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Barnes Expires October 3, 2005 [Page 5] Internet-Draft L-by-R Emergency Calling April 2005 Author's Address Richard Barnes BBN Technologies 9861 Broken Land Pkwy Columbia, Maryland 21046 USA Phone: +1-410-290-6169 Email: rbarnes@bbn.com Barnes Expires October 3, 2005 [Page 6] Internet-Draft L-by-R Emergency Calling April 2005 Full Copyright Statement Copyright (C) The IETF Trust (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Barnes Expires October 3, 2005 [Page 7] --------------080101090301080700030705 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --------------080101090301080700030705-- From ecrit-bounces@ietf.org Mon Apr 23 13:27:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2Jf-00024n-HG; Mon, 23 Apr 2007 13:27:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2Je-0001z5-Ff for ecrit@ietf.org; Mon, 23 Apr 2007 13:27:06 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg2Je-00085l-7N for ecrit@ietf.org; Mon, 23 Apr 2007 13:27:06 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Hg2Je-0003kq-3F; Mon, 23 Apr 2007 13:27:06 -0400 Received: from [127.0.0.1] (col-dhcp33-244-156.bbn.com [128.33.244.156]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l3NHR5w23831; Mon, 23 Apr 2007 13:27:05 -0400 (EDT) Message-ID: <462CEC68.7060805@bbn.com> Date: Mon, 23 Apr 2007 13:27:04 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] An alternative proposal References: <4628FD3E.5080009@bbn.com> <730D0441-E19F-4092-BDEF-4905947C0AC3@cs.columbia.edu> In-Reply-To: <730D0441-E19F-4092-BDEF-4905947C0AC3@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > This can be done, but requires significant, non-trivial extensions to > LoST, unlike the existing proposal summarized by Brian and Hannes. So > far, the only concrete proposal along these lines that has more than > handwaving behind it is to flood all PSAP URLs, at least within a single > tree. This doesn't have to be done with LoST, if that's not convenient. You could define a really tiny XML protocol to do it, or you might even be able to do something clever with NAPTR records in the DNS. In any case, it's just not that big a problem. If the U.S., with 300M people, has 6K PSAPs, then we're talking about a database with something like 120K entries to cover the whole world. Even if it scales up two more orders of magnitude in the long run, that's only a little over a GB of data. For that size, you could create a dedicated FG (or FG cluster) that could collect flooded URIs from trees and handle queries. >> 2. Trying to support the second question often leads to unacceptable >> privacy consequences. The privacy risks incurred by the "rough >> location" proposal are due to the fact that it tries to answer the >> second question: Since VSPs can be (effectively) anyone, the LIS has >> to give out location to everyone in order for VSPs to be able to use >> location for this purpose. > > As has been stated many times before, the privacy content of the PSAP > URL and the boundary are exactly the same. In other words, as soon as an > emergency call reaches the VSP, the VSP can determine that the caller is > in the coverage area of the PSAP. Nothing new here. If you're determining the location of a caller based on the fact that a PSAP URI is in an INVITE, you need to have both the PSAP URI and the INVITE. These only get sent out to proxies involved in call setup, in which a certain amount of trust is vested anyway. In effect, the VSP is authorized to have that information because the caller sent it to him. On the other hand, if an unauthorized dereference returns a rough location, then any host that knows or can guess the reference can track the caller (with PSAP service-area granularity); the caller/target has no say. You can't restrict this sort of dereference to VSPs since you've assumed that you can't authenticate VSPs. So the novelty is that instead of revealing the caller's location to signaling entities, the you end up revealing it to everybody. --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 13:36:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2Su-0000m9-DO; Mon, 23 Apr 2007 13:36:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2St-0000lz-B3 for ecrit@ietf.org; Mon, 23 Apr 2007 13:36:39 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg2Ss-0002Pz-SA for ecrit@ietf.org; Mon, 23 Apr 2007 13:36:39 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Hg2Sq-0003rc-4H; Mon, 23 Apr 2007 13:36:36 -0400 Received: from [127.0.0.1] (col-dhcp33-244-156.bbn.com [128.33.244.156]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l3NHaZw25520; Mon, 23 Apr 2007 13:36:35 -0400 (EDT) Message-ID: <462CEEA2.3040909@bbn.com> Date: Mon, 23 Apr 2007 13:36:34 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host References: <46287EB9.7060006@gmx.net> In-Reply-To: <46287EB9.7060006@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Could we save time by just having the LCP return both LbyR AND the rough location (by value)? Pros: + Avoids dereference overhead + Avoids LIS having to authenticate endpoint + Avoids some confusion of having a dereference return two different values depending on authorization. + Think this is already supported by HELD Cons: - Don't know how well this works with DHCP Result would be: 1. The endpoint uses an LCP to request location. 2-4. Unnecessary 5. The endpoint uses the (coarse) location value it obtains to query LoST. It gets the (correct) PSAP URI As for step 7, we need a different mechanism that doesn't rely on rough location being returned by an unauthorized dereference. --Richard Hannes Tschofenig wrote: > Hi all, > let me try it again (I got it wrong in my previous mail). > Henning and Brian suggested an approach that * works nicely with the > emergency services architecture we > investigated over the past few years, and > * addresses the case where a network operator does not want to disclose > precise location information. > Here is the procedure: > > 1. The endpoint uses an LCP to request location. The LIS returns an LbyR > 2. The endpoint dereferences the LbyR. 3. The LIS, noticing that the > dereference request is from the endpoint (or > at least not from any entity that is entitled to get fine grained > location), > takes the fine grained location and uses LoST to determine the PSAP that > serves that location. > 4. The LIS returns to the endpoint a location which, if submitted to LoST, > would return the same PSAP URI the fine grained location would. In some > circumstances, this could be a civic with only a country. An alternative > that works for all circumstances is to return the polygon that defines the > service boundary of the PSAP (which LoST can return). Is essential that > the > PSAP URI returned from a LoST query with whatever the LIS gives the > endpoint > would be the same PSAP URI any querier using the fine grained location > would > get. > 5. The endpoint uses the (coarse) location value it obtains to query LoST. > It gets the (correct) PSAP URI > 6. This is repeated at call time. The endpoint has a valid LbyR and a > valid > PSAP URI, which it uses to construct the emergency call > 7. A VSP wishing to validate the PSAP URI takes the LbyR and dereferences > it. The result will be the same (coarse) location the endpoint got. The > VSP does a LoST query with that location, and should get the same PSAP URI > that is in the Request URI on the call. This validation works for > coarse or > fine validation, and of course works for LbyV without the dereference step. > 8. The PSAP (or ESRP) which is the target of the PSAP URI gets the > call. It > dereferences the LbyR but gets the fine grained location; the LIS must have > a relationship with the ESRP/PSAP to assure this. > 9. Any succeeding ESRPs or PSAPs can also dereference and get fine grained > location. > > QUESTION: Is this approach acceptable for you? > Ciao > Hannes > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 13:38:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2UZ-0001nE-Ns; Mon, 23 Apr 2007 13:38:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2UY-0001k5-Cz for ecrit@ietf.org; Mon, 23 Apr 2007 13:38:22 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg2UX-0002bn-5w for ecrit@ietf.org; Mon, 23 Apr 2007 13:38:22 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1Hg2T6-000899-3h; Mon, 23 Apr 2007 12:36:52 -0500 From: "Brian Rosen" To: "'Richard Barnes'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] An alternative proposal Date: Mon, 23 Apr 2007 13:38:17 -0400 Message-ID: <050801c785ce$2f929040$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <462CEC68.7060805@bbn.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: AceFzGxKAr1+rEkkTI6HjVKAkFaw1AAAQiHg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > On the other hand, if an unauthorized dereference returns a rough > location, then any host that knows or can guess the reference can track > the caller (with PSAP service-area granularity); the caller/target has > no say. You can't restrict this sort of dereference to VSPs since > you've assumed that you can't authenticate VSPs. How many times, and in how many ways, do we have to say this: The security of a reference is THE SAME as the security of the value. You cannot treat the reference with any less care than you treat the value. Somehow, we don't seem to be able to get through to people that you can't distribute the reference widely and expect the dereference system to control privacy. If you want a secure location treat the reference as if it were the value and don't give it to anyone you don't want to have the value. There is no such thing as an "unauthorized dereference" with respect to the user/target. If an entity has the reference, then you must assume they can acquire the value. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 14:03:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2se-0006Ur-A7; Mon, 23 Apr 2007 14:03:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2sc-0006U7-9d for ecrit@ietf.org; Mon, 23 Apr 2007 14:03:14 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg2sb-0008L2-21 for ecrit@ietf.org; Mon, 23 Apr 2007 14:03:14 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3NI32nu017635 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Apr 2007 14:03:07 -0400 (EDT) In-Reply-To: <6167C70C-69C8-4FC9-B301-11D3FFAFF63D@hxr.us> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBE1C.2070908@gmx.net> <68F36998-36AF-4D03-866D-8E150C5863C5@hxr.us> <52FFCA18-2943-444B-9DB1-439B9A2371D1@cs.columbia.edu> <6167C70C-69C8-4FC9-B301-11D3FFAFF63D@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <21F1E73C-C9C1-42AC-993A-CA87A6F91603@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host Date: Mon, 23 Apr 2007 14:04:28 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I don't know if the thread was inconclusive as such. I proposed the simple centroid rule, and, if I recall correctly, nobody offered an implementable alternative that was provably more accurate and did not involve forking. Service regions is the region returned in the mapping, i.e., . Holes in that boundary don't affect the centroid-based search. What will happen depends a bit on the way the information is stored. In simple cases, where the PSAPs serving the hole are stored in the same authoritative server (or represented as summaries in those servers), a point that hits that hole will generate two matches: the surrounding-area PSAP and the more specific one. The server can then inspect the holes registered for the surrounding-area PSAP and discover easily that the special-case PSAP for the hole is the right answer. There are optimizations you can do to make this efficient, in particular since the area of the hole is by definition smaller than the surrounding area (without taking the whole into account). Henning On Apr 23, 2007, at 12:27 PM, Andrew Newton wrote: > > On Apr 23, 2007, at 9:22 AM, Henning Schulzrinne wrote: > >> You just do centroid computation on the location-describing >> polygon, which is very simple for polygons without holes. >> (Polygons with holes are only of interest for service regions, so >> they don't affect the problem in the subject line.) > > I understand your argument. There is a long, inconclusive email > thread on it. Your point about holes actually makes this a bit > more troublesome though. What do you mean by service regions? > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 14:06:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2vT-00085f-0k; Mon, 23 Apr 2007 14:06:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg2vR-00085a-IT for ecrit@ietf.org; Mon, 23 Apr 2007 14:06:09 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg2vP-0000L1-99 for ecrit@ietf.org; Mon, 23 Apr 2007 14:06:09 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Hg2vO-0004Ii-5W; Mon, 23 Apr 2007 14:06:06 -0400 Received: from [127.0.0.1] (col-dhcp33-244-156.bbn.com [128.33.244.156]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l3NI65w02003; Mon, 23 Apr 2007 14:06:05 -0400 (EDT) Message-ID: <462CF58B.4000204@bbn.com> Date: Mon, 23 Apr 2007 14:06:03 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] An alternative proposal References: <050801c785ce$2f929040$640fa8c0@cis.neustar.com> In-Reply-To: <050801c785ce$2f929040$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I thought we'd been through this in the LbyR design team. There are requirements in draft-marshall-geopriv-lbyr-requirements-01 that say that location-by-reference needs to support authentication and authorization of both dereference clients and servers, and the dereference servers need to abide by privacy rules. Even if that weren't the case, it's not enough to just say "don't hand out your reference to anyone you don't want to have it." People can guess references so you need significant amounts of randomness in your references, so you can't have convenient references like . And you'll have to keep inventing new references all the time, unless you want Domino's to be able to keep track of you. Expiration is a form of access control; are expiring references allowed? In any case, if there's no control on dereference, then we shouldn't be in this thread anyway, since the endpoint can just dereference to get its location. --Richard Brian Rosen wrote: >> On the other hand, if an unauthorized dereference returns a rough >> location, then any host that knows or can guess the reference can track >> the caller (with PSAP service-area granularity); the caller/target has >> no say. You can't restrict this sort of dereference to VSPs since >> you've assumed that you can't authenticate VSPs. > How many times, and in how many ways, do we have to say this: > The security of a reference is THE SAME as the security of the value. > You cannot treat the reference with any less care than you treat the value. > > Somehow, we don't seem to be able to get through to people that you can't > distribute the reference widely and expect the dereference system to control > privacy. If you want a secure location treat the reference as if it were > the value and don't give it to anyone you don't want to have the value. > > There is no such thing as an "unauthorized dereference" with respect to the > user/target. If an entity has the reference, then you must assume they can > acquire the value. > > Brian > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 14:24:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3DQ-0006Wt-Iv; Mon, 23 Apr 2007 14:24:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3DO-0006WZ-Lt for ecrit@ietf.org; Mon, 23 Apr 2007 14:24:42 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg3DN-0005TX-75 for ecrit@ietf.org; Mon, 23 Apr 2007 14:24:42 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 23 Apr 2007 14:24:40 -0400 id 015880CA.462CF9E8.00005A96 In-Reply-To: <21F1E73C-C9C1-42AC-993A-CA87A6F91603@cs.columbia.edu> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBE1C.2070908@gmx.net> <68F36998-36AF-4D03-866D-8E150C5863C5@hxr.us> <52FFCA18-2943-444B-9DB1-439B9A2371D1@cs.columbia.edu> <6167C70C-69C8-4FC9-B301-11D3FFAFF63D@hxr.us> <21F1E73C-C9C1-42AC-993A-CA87A6F91603@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D7DECAC-BE61-4507-82EA-E6A1E2DBFC76@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host Date: Mon, 23 Apr 2007 14:24:39 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 23, 2007, at 2:04 PM, Henning Schulzrinne wrote: > > Holes in that boundary don't affect the centroid-based search. What > will happen depends a bit on the way the information is stored. In > simple cases, where the PSAPs serving the hole are stored in the > same authoritative server (or represented as summaries in those > servers), a point that hits that hole will generate two matches: > the surrounding-area PSAP and the more specific one. The server > can then inspect the holes registered for the surrounding-area PSAP > and discover easily that the special-case PSAP for the hole is the > right answer. There are optimizations you can do to make this > efficient, in particular since the area of the hole is by > definition smaller than the surrounding area (without taking the > whole into account). So, how does a server know that the input polygon should match an exact polygon in the db (as is needed for the VSP test) vs a need to find the centroid before looking for a match (as would be needed for regular uses of LoST)? In the first case, the VSP test will fail because it will match the more specific polygon, according to your description above. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 14:33:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3MF-0005vK-1c; Mon, 23 Apr 2007 14:33:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3ME-0005vC-Ia for ecrit@ietf.org; Mon, 23 Apr 2007 14:33:50 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg3MB-000862-U8 for ecrit@ietf.org; Mon, 23 Apr 2007 14:33:50 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3NIWV91029061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Apr 2007 11:32:32 -0700 Received: from [76.102.225.135] (carbuncle.qualcomm.com [129.46.226.38]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3NIWSjs014457; Mon, 23 Apr 2007 11:32:30 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <04d301c785c1$58d38cf0$640fa8c0@cis.neustar.com> References: <04d301c785c1$58d38cf0$640fa8c0@cis.neustar.com> Date: Mon, 23 Apr 2007 11:32:26 -0700 To: "Brian Rosen" , "'Stark, Barbara'" , "'Henning Schulzrinne'" From: Ted Hardie Subject: RE: [Ecrit] phonebcp and testing location correctness Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 12:06 PM -0400 4/23/07, Brian Rosen wrote: >Yeah, maybe. I don't know how well that works on MPEG encoded video. > >However, spelling is just about the only way to sign a street address; there >are no signs for some street names and many city names. Spelling is one of >the most common signs everyone learns. Good CAs spell really fast. > >Brian I think you are now seriously over-engineering a test system. Saying that the test system can be expected to return the location in a form which may be rendered by the device at its UI discretion is the right on-the-wire choice. Moving from that to one where you negotiate and then carry the UI presentation itself is a distant second. Decided that negotiation must carry all possible representations is silly. For a test system, representations of the location in text are likely to be valid for pretty much any user and if you add in voice to text, you've covered the deaf and blind communities as well as the users with both of those facilities. Allowing an image with a map might be useful, but switching to video to watch someone finger-spell on a letter by letter basis is now targeting a very limited audience: those with very high end devices, no ability to read text, and who are guaranteed to be able to map the finger-spelled version to whatever sign is normally used in their language community for the area/street/etc. You do realize that you have whacked yourself into an internationalization problem as well, right? British Sign and American Sign Language are not mutual intelligible, and you're now going to have to negotiate sign language communities of interest, even where you can presume a mutually intelligible language in text? Send the location object, and let the local rendering engine worry about it! It will be configured for the user's needs. And, since I haven't said this for a day or two, it is now very, very clear to me that the document needs to cover both an automated test system and a separate user-invoked one. If our putative high-end-system-using signer loses his dhcp lease and gets a new IP, having the system start signing at him is going way past the principle of least surprise. Ted > >> -----Original Message----- >> From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] >> Sent: Monday, April 23, 2007 11:47 AM >> To: Brian Rosen; Henning Schulzrinne; Ted Hardie >> Cc: ECRIT >> Subject: RE: [Ecrit] phonebcp and testing location correctness >> >> I would think that video letter-by-letter automated spelling of a >> location would be rather tedious to watch. >> >> Could we send a JPG picture of a street map with a star where the >> location is? >> Barbara >> >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Monday, April 23, 2007 11:10 AM >> To: Stark, Barbara; 'Henning Schulzrinne'; 'Ted Hardie' >> Cc: 'ECRIT' >> Subject: RE: [Ecrit] phonebcp and testing location correctness >> >> You have the problem with the deaf community; a very vocal and effective >> lobbyist for something I consider a very reasonable point of view: they >> want equivalent service. The specs require support for IM and real time >> interactive text. If that is the media asserted on the test INVITE, >> they would expect the location coming back as text. >> >> Similarly, if they ask for video, they are expecting sign language. I >> have a query into them about the practicality of text to sign language. >> I don't see why it won't work just fine. Presumably you wouldn't have a >> problem with that. >> >> Brian >> >> > -----Original Message----- >> > From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] >> > Sent: Monday, April 23, 2007 10:41 AM >> > To: Henning Schulzrinne; Ted Hardie >> > Cc: ECRIT >> > Subject: [Ecrit] phonebcp and testing location correctness >> > >> > Having thought about this over the weekend, I think I prefer > > > recommending the voice-back of the de-referenced location, over >> > providing a PIDF-LO in the 200 OK. For all the reasons that Henning >> > mentioned. But I don't know how this would work if the negotiated >> > medium were something other than a voice codec. Does support of this >> > function for non-voice media need to be recommended? >> > Barbara >> > >> > -----Original Message----- >> > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> > Sent: Thursday, April 19, 2007 6:05 PM >> > To: Ted Hardie >> > Cc: 'ECRIT' >> > Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: >> > (Partial)LocationHiding Emergency Services Architecture >> > >> > The whole point is that the caller can, if he so desires, verify the >> > location information. Incorrect location information is a major source >> >> > of mis-routes and false dispatches today (see the NYT article I sent >> > around a few weeks ago). >> > >> > Since location information, even without hiding, can be added by a >> > proxy, this is the only way for the end system to determine what >> > information will be conveyed to the PSAP in all cases. In existing >> > system, finding this out is extremely tedious and burdensome to the >> > PSAP, as you actually have to call 911 to see what address your >> > carrier has registered for you. You really don't want to resolve the >> > "No, I'm not living at 123 Main Street, that's my billing address" >> > during an emergency call. >> > >> > I have no objection to returning this PSAP-seen information in some >> > other way, such as location-conveyance, but I expected to hear screams >> >> > from the hide-location crowd in that case. Thus, I was trying to find >> > a way that achieves most of the goals, while not stepping on sensitive >> >> > toes. Since the existing test text includes the return of location >> > information, albeit in a format that is left unspecified (which should >> >> > be fixed), I'm happy with that. >> > >> > I also have no objection to making this an optional request in the >> > call, so that unattended test calls do not generate this, but I'm not >> > convinced that the complexity is worth it. >> > >> > Thus, I believe that this mechanism adds significantly to the overall >> > reliability of the system and we should encourage that it be provided, >> >> > whether as location-conveyance, audio or just a PIDF-LO attachment in >> > the 200 OK. (This generally won't work well, given the difficulty real >> >> > phones have with multipart, but that's a different >> > topic.) >> > >> > Henning >> > >> > On Apr 19, 2007, at 5:43 PM, Ted Hardie wrote: >> > >> > > At 4:46 PM -0400 4/19/07, Brian Rosen wrote: >> > >> I dropped geopriv >> > >> >> > >> Please look at -phonebcp for the current test procedure. This >> > >> would add a step. >> > > >> > > So, the proposal is to add this to 9.1. The current version says: >> > > >> > >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www1.ietf.org/mailman/listinfo/ecrit >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 15:04:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3ph-0008Oq-9w; Mon, 23 Apr 2007 15:04:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg3pg-0008Ol-TF for ecrit@ietf.org; Mon, 23 Apr 2007 15:04:16 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg3pf-0008L4-DK for ecrit@ietf.org; Mon, 23 Apr 2007 15:04:16 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1Hg3oD-0004qH-5g; Mon, 23 Apr 2007 14:02:45 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Stark, Barbara'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] phonebcp and testing location correctness Date: Mon, 23 Apr 2007 15:04:10 -0400 Message-ID: <051a01c785da$2f21fdb0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: AceF1ZD39ngq1tATTcS+ysFlPXSt2gABBrAw 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Ted You just haven't been in the room with the deaf folks much. They reasonably demand equal service. They get it, because they ask for reasonable accommodation. There are laws about that. We pay attention. It's the right thing to do. There is no technical difficulty in providing text to signing. I don't think an IETF spec has to say that, it just says: responds with a media stream in the form negotiated containing the location in a human understandable form (e.g. using text to speech). Agree that automated test is different from user interactive test. Brian > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Monday, April 23, 2007 2:32 PM > To: Brian Rosen; 'Stark, Barbara'; 'Henning Schulzrinne' > Cc: 'ECRIT' > Subject: RE: [Ecrit] phonebcp and testing location correctness > > At 12:06 PM -0400 4/23/07, Brian Rosen wrote: > >Yeah, maybe. I don't know how well that works on MPEG encoded video. > > > >However, spelling is just about the only way to sign a street address; > there > >are no signs for some street names and many city names. Spelling is one > of > >the most common signs everyone learns. Good CAs spell really fast. > > > >Brian > > I think you are now seriously over-engineering a test system. Saying that > the test system can be expected to return the location in a form which > may be rendered by the device at its UI discretion is the right on-the- > wire > choice. Moving from that to one where you negotiate and then carry > the UI presentation itself is a distant second. Decided that negotiation > must carry all possible representations is silly. For a test system, > representations of the location in text are likely to be valid for pretty > much any user and if you add in voice to text, you've covered the deaf > and blind communities as well as the users with both of those facilities. > Allowing an image with a map might be useful, but switching to video > to watch someone finger-spell on a letter by letter basis is now targeting > a very limited audience: those with very high end devices, no ability > to read text, and who are guaranteed to be able to map the finger-spelled > version to whatever sign is normally used in their language community > for the area/street/etc. > > You do realize that you have whacked yourself into an internationalization > problem as well, right? British Sign and American Sign Language are not > mutual > intelligible, and you're now going to have to negotiate sign language > communities > of interest, even where you can presume a mutually intelligible language > in text? > > Send the location object, and let the local rendering engine worry about > it! It > will be configured for the user's needs. > > And, since I haven't said this for a day or two, it is now very, very > clear to me > that the document needs to cover both an automated test system and > a separate user-invoked one. If our putative high-end-system-using > signer loses his dhcp lease and gets a new IP, having the system start > signing at him is going way past the principle of least surprise. > > Ted > > > > > > > > > > > >> -----Original Message----- > >> From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > >> Sent: Monday, April 23, 2007 11:47 AM > >> To: Brian Rosen; Henning Schulzrinne; Ted Hardie > >> Cc: ECRIT > >> Subject: RE: [Ecrit] phonebcp and testing location correctness > >> > >> I would think that video letter-by-letter automated spelling of a > >> location would be rather tedious to watch. > >> > >> Could we send a JPG picture of a street map with a star where the > >> location is? > >> Barbara > >> > >> -----Original Message----- > >> From: Brian Rosen [mailto:br@brianrosen.net] > >> Sent: Monday, April 23, 2007 11:10 AM > >> To: Stark, Barbara; 'Henning Schulzrinne'; 'Ted Hardie' > >> Cc: 'ECRIT' > >> Subject: RE: [Ecrit] phonebcp and testing location correctness > >> > >> You have the problem with the deaf community; a very vocal and > effective > >> lobbyist for something I consider a very reasonable point of view: they > >> want equivalent service. The specs require support for IM and real > time > >> interactive text. If that is the media asserted on the test INVITE, > >> they would expect the location coming back as text. > >> > >> Similarly, if they ask for video, they are expecting sign language. I > >> have a query into them about the practicality of text to sign language. > >> I don't see why it won't work just fine. Presumably you wouldn't have > a > >> problem with that. > >> > >> Brian > >> > >> > -----Original Message----- > >> > From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > >> > Sent: Monday, April 23, 2007 10:41 AM > >> > To: Henning Schulzrinne; Ted Hardie > >> > Cc: ECRIT > >> > Subject: [Ecrit] phonebcp and testing location correctness > >> > > >> > Having thought about this over the weekend, I think I prefer > > > > recommending the voice-back of the de-referenced location, over > >> > providing a PIDF-LO in the 200 OK. For all the reasons that Henning > >> > mentioned. But I don't know how this would work if the negotiated > >> > medium were something other than a voice codec. Does support of this > >> > function for non-voice media need to be recommended? > >> > Barbara > >> > > >> > -----Original Message----- > >> > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >> > Sent: Thursday, April 19, 2007 6:05 PM > >> > To: Ted Hardie > >> > Cc: 'ECRIT' > >> > Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: > >> > (Partial)LocationHiding Emergency Services Architecture > >> > > >> > The whole point is that the caller can, if he so desires, verify the > >> > location information. Incorrect location information is a major > source > >> > >> > of mis-routes and false dispatches today (see the NYT article I sent > >> > around a few weeks ago). > >> > > >> > Since location information, even without hiding, can be added by a > >> > proxy, this is the only way for the end system to determine what > >> > information will be conveyed to the PSAP in all cases. In existing > >> > system, finding this out is extremely tedious and burdensome to the > >> > PSAP, as you actually have to call 911 to see what address your > >> > carrier has registered for you. You really don't want to resolve the > >> > "No, I'm not living at 123 Main Street, that's my billing address" > >> > during an emergency call. > >> > > >> > I have no objection to returning this PSAP-seen information in some > >> > other way, such as location-conveyance, but I expected to hear > screams > >> > >> > from the hide-location crowd in that case. Thus, I was trying to find > >> > a way that achieves most of the goals, while not stepping on > sensitive > >> > >> > toes. Since the existing test text includes the return of location > >> > information, albeit in a format that is left unspecified (which > should > >> > >> > be fixed), I'm happy with that. > >> > > >> > I also have no objection to making this an optional request in the > >> > call, so that unattended test calls do not generate this, but I'm not > >> > convinced that the complexity is worth it. > >> > > >> > Thus, I believe that this mechanism adds significantly to the overall > >> > reliability of the system and we should encourage that it be > provided, > >> > >> > whether as location-conveyance, audio or just a PIDF-LO attachment in > >> > the 200 OK. (This generally won't work well, given the difficulty > real > >> > >> > phones have with multipart, but that's a different > >> > topic.) > >> > > >> > Henning > >> > > >> > On Apr 19, 2007, at 5:43 PM, Ted Hardie wrote: > >> > > >> > > At 4:46 PM -0400 4/19/07, Brian Rosen wrote: > >> > >> I dropped geopriv > >> > >> > >> > >> Please look at -phonebcp for the current test procedure. This > >> > >> would add a step. > >> > > > >> > > So, the proposal is to add this to 9.1. The current version says: > >> > > > >> > > >> > > >> > _______________________________________________ > >> > Ecrit mailing list > >> > Ecrit@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/ecrit > >> > > >> > _______________________________________________ > >> > Ecrit mailing list > >> > Ecrit@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 15:30:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4FI-0004iq-Om; Mon, 23 Apr 2007 15:30:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4FG-0004ig-S0 for ecrit@ietf.org; Mon, 23 Apr 2007 15:30:42 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg4FG-0008QP-CF for ecrit@ietf.org; Mon, 23 Apr 2007 15:30:42 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Hg4FF-0006L6-5y; Mon, 23 Apr 2007 15:30:41 -0400 Received: from [127.0.0.1] (col-dhcp33-244-156.bbn.com [128.33.244.156]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l3NJUfw18836; Mon, 23 Apr 2007 15:30:41 -0400 (EDT) Message-ID: <462D095F.2010701@bbn.com> Date: Mon, 23 Apr 2007 15:30:39 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] phonebcp and testing location correctness References: <051a01c785da$2f21fdb0$640fa8c0@cis.neustar.com> In-Reply-To: <051a01c785da$2f21fdb0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: "'Stark, Barbara'" , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org To echo Ted, providing machine-readable location is the right *on-the-wire* choice. Given a machine-readable LO, the user's equipment can render it as text, braille, a map, sign language, or interpretive dance -- it's much more easily adaptable for users with different abilities. If you force the presentation onto the wire, you only get the presentation that the server sends you. --RB Brian Rosen wrote: > Ted > > You just haven't been in the room with the deaf folks much. > > They reasonably demand equal service. They get it, because they ask for > reasonable accommodation. There are laws about that. We pay attention. > It's the right thing to do. > > There is no technical difficulty in providing text to signing. I don't > think an IETF spec has to say that, it just says: responds with a media > stream in the form negotiated containing the location in a human > understandable form (e.g. using text to speech). > > Agree that automated test is different from user interactive test. > > Brian > >> -----Original Message----- >> From: Ted Hardie [mailto:hardie@qualcomm.com] >> Sent: Monday, April 23, 2007 2:32 PM >> To: Brian Rosen; 'Stark, Barbara'; 'Henning Schulzrinne' >> Cc: 'ECRIT' >> Subject: RE: [Ecrit] phonebcp and testing location correctness >> >> At 12:06 PM -0400 4/23/07, Brian Rosen wrote: >>> Yeah, maybe. I don't know how well that works on MPEG encoded video. >>> >>> However, spelling is just about the only way to sign a street address; >> there >>> are no signs for some street names and many city names. Spelling is one >> of >>> the most common signs everyone learns. Good CAs spell really fast. >>> >>> Brian >> I think you are now seriously over-engineering a test system. Saying that >> the test system can be expected to return the location in a form which >> may be rendered by the device at its UI discretion is the right on-the- >> wire >> choice. Moving from that to one where you negotiate and then carry >> the UI presentation itself is a distant second. Decided that negotiation >> must carry all possible representations is silly. For a test system, >> representations of the location in text are likely to be valid for pretty >> much any user and if you add in voice to text, you've covered the deaf >> and blind communities as well as the users with both of those facilities. >> Allowing an image with a map might be useful, but switching to video >> to watch someone finger-spell on a letter by letter basis is now targeting >> a very limited audience: those with very high end devices, no ability >> to read text, and who are guaranteed to be able to map the finger-spelled >> version to whatever sign is normally used in their language community >> for the area/street/etc. >> >> You do realize that you have whacked yourself into an internationalization >> problem as well, right? British Sign and American Sign Language are not >> mutual >> intelligible, and you're now going to have to negotiate sign language >> communities >> of interest, even where you can presume a mutually intelligible language >> in text? >> >> Send the location object, and let the local rendering engine worry about >> it! It >> will be configured for the user's needs. >> >> And, since I haven't said this for a day or two, it is now very, very >> clear to me >> that the document needs to cover both an automated test system and >> a separate user-invoked one. If our putative high-end-system-using >> signer loses his dhcp lease and gets a new IP, having the system start >> signing at him is going way past the principle of least surprise. >> >> Ted >> >> >> >> >> >> >> >> >>>> -----Original Message----- >>>> From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] >>>> Sent: Monday, April 23, 2007 11:47 AM >>>> To: Brian Rosen; Henning Schulzrinne; Ted Hardie >>>> Cc: ECRIT >>>> Subject: RE: [Ecrit] phonebcp and testing location correctness >>>> >>>> I would think that video letter-by-letter automated spelling of a >>>> location would be rather tedious to watch. >>>> >>>> Could we send a JPG picture of a street map with a star where the >>>> location is? >>>> Barbara >>>> >>>> -----Original Message----- >>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>> Sent: Monday, April 23, 2007 11:10 AM >>>> To: Stark, Barbara; 'Henning Schulzrinne'; 'Ted Hardie' >>>> Cc: 'ECRIT' >>>> Subject: RE: [Ecrit] phonebcp and testing location correctness >>>> >>>> You have the problem with the deaf community; a very vocal and >> effective >>>> lobbyist for something I consider a very reasonable point of view: they >>>> want equivalent service. The specs require support for IM and real >> time >>>> interactive text. If that is the media asserted on the test INVITE, >>>> they would expect the location coming back as text. >>>> >>>> Similarly, if they ask for video, they are expecting sign language. I >>>> have a query into them about the practicality of text to sign language. >>>> I don't see why it won't work just fine. Presumably you wouldn't have >> a >>>> problem with that. >>>> >>>> Brian >>>> >>>>> -----Original Message----- >>>>> From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] >>>>> Sent: Monday, April 23, 2007 10:41 AM >>>>> To: Henning Schulzrinne; Ted Hardie >>>>> Cc: ECRIT >>>>> Subject: [Ecrit] phonebcp and testing location correctness >>>>> >>>>> Having thought about this over the weekend, I think I prefer >>>>> recommending the voice-back of the de-referenced location, over >>>>> providing a PIDF-LO in the 200 OK. For all the reasons that Henning >>>>> mentioned. But I don't know how this would work if the negotiated >>>>> medium were something other than a voice codec. Does support of this >>>>> function for non-voice media need to be recommended? >>>>> Barbara >>>>> >>>>> -----Original Message----- >>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>> Sent: Thursday, April 19, 2007 6:05 PM >>>>> To: Ted Hardie >>>>> Cc: 'ECRIT' >>>>> Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: >>>>> (Partial)LocationHiding Emergency Services Architecture >>>>> >>>>> The whole point is that the caller can, if he so desires, verify the >>>>> location information. Incorrect location information is a major >> source >>>>> of mis-routes and false dispatches today (see the NYT article I sent >>>>> around a few weeks ago). >>>>> >>>>> Since location information, even without hiding, can be added by a >>>>> proxy, this is the only way for the end system to determine what >>>>> information will be conveyed to the PSAP in all cases. In existing >>>>> system, finding this out is extremely tedious and burdensome to the >>>>> PSAP, as you actually have to call 911 to see what address your >>>>> carrier has registered for you. You really don't want to resolve the >>>>> "No, I'm not living at 123 Main Street, that's my billing address" >>>>> during an emergency call. >>>>> >>>>> I have no objection to returning this PSAP-seen information in some >>>>> other way, such as location-conveyance, but I expected to hear >> screams >>>>> from the hide-location crowd in that case. Thus, I was trying to find >>>>> a way that achieves most of the goals, while not stepping on >> sensitive >>>>> toes. Since the existing test text includes the return of location >>>>> information, albeit in a format that is left unspecified (which >> should >>>>> be fixed), I'm happy with that. >>>>> >>>>> I also have no objection to making this an optional request in the >>>>> call, so that unattended test calls do not generate this, but I'm not >>>>> convinced that the complexity is worth it. >>>>> >>>>> Thus, I believe that this mechanism adds significantly to the overall >>>>> reliability of the system and we should encourage that it be >> provided, >>>>> whether as location-conveyance, audio or just a PIDF-LO attachment in >>>>> the 200 OK. (This generally won't work well, given the difficulty >> real >>>>> phones have with multipart, but that's a different >>>>> topic.) >>>>> >>>>> Henning >>>>> >>>>> On Apr 19, 2007, at 5:43 PM, Ted Hardie wrote: >>>>> >>>>>> At 4:46 PM -0400 4/19/07, Brian Rosen wrote: >>>>>>> I dropped geopriv >>>>>>> >>>>>>> Please look at -phonebcp for the current test procedure. This >>>>>>> would add a step. >>>>>> So, the proposal is to add this to 9.1. The current version says: >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 15:42:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4QU-00059T-Ot; Mon, 23 Apr 2007 15:42:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4QT-00055Z-VV for ecrit@ietf.org; Mon, 23 Apr 2007 15:42:17 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg4QT-0002eN-Cc for ecrit@ietf.org; Mon, 23 Apr 2007 15:42:17 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1Hg4P0-000581-HH; Mon, 23 Apr 2007 14:40:47 -0500 From: "Brian Rosen" To: "'Richard Barnes'" Subject: RE: [Ecrit] phonebcp and testing location correctness Date: Mon, 23 Apr 2007 15:42:13 -0400 Message-ID: <052e01c785df$7faf13d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <462D095F.2010701@bbn.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: AceF3a2XPWhlXKtkSvCRl4UrjmJFTwAAXK0A 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Cc: "'Stark, Barbara'" , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org You want a video endpoint that could be used by a deaf user to render video from text? You want every telephone that could be used by a blind user to render audio from text? This is a local service, and can reasonably use local conventions (and caller prefs). Brian > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Monday, April 23, 2007 3:31 PM > To: Brian Rosen > Cc: 'Ted Hardie'; 'Stark, Barbara'; 'Henning Schulzrinne'; 'ECRIT' > Subject: Re: [Ecrit] phonebcp and testing location correctness > > To echo Ted, providing machine-readable location is the right > *on-the-wire* choice. Given a machine-readable LO, the user's equipment > can render it as text, braille, a map, sign language, or interpretive > dance -- it's much more easily adaptable for users with different > abilities. > > If you force the presentation onto the wire, you only get the > presentation that the server sends you. > > --RB > > > Brian Rosen wrote: > > Ted > > > > You just haven't been in the room with the deaf folks much. > > > > They reasonably demand equal service. They get it, because they ask for > > reasonable accommodation. There are laws about that. We pay attention. > > It's the right thing to do. > > > > There is no technical difficulty in providing text to signing. I don't > > think an IETF spec has to say that, it just says: responds with a media > > stream in the form negotiated containing the location in a human > > understandable form (e.g. using text to speech). > > > > Agree that automated test is different from user interactive test. > > > > Brian > > > >> -----Original Message----- > >> From: Ted Hardie [mailto:hardie@qualcomm.com] > >> Sent: Monday, April 23, 2007 2:32 PM > >> To: Brian Rosen; 'Stark, Barbara'; 'Henning Schulzrinne' > >> Cc: 'ECRIT' > >> Subject: RE: [Ecrit] phonebcp and testing location correctness > >> > >> At 12:06 PM -0400 4/23/07, Brian Rosen wrote: > >>> Yeah, maybe. I don't know how well that works on MPEG encoded video. > >>> > >>> However, spelling is just about the only way to sign a street address; > >> there > >>> are no signs for some street names and many city names. Spelling is > one > >> of > >>> the most common signs everyone learns. Good CAs spell really fast. > >>> > >>> Brian > >> I think you are now seriously over-engineering a test system. Saying > that > >> the test system can be expected to return the location in a form which > >> may be rendered by the device at its UI discretion is the right on-the- > >> wire > >> choice. Moving from that to one where you negotiate and then carry > >> the UI presentation itself is a distant second. Decided that > negotiation > >> must carry all possible representations is silly. For a test system, > >> representations of the location in text are likely to be valid for > pretty > >> much any user and if you add in voice to text, you've covered the deaf > >> and blind communities as well as the users with both of those > facilities. > >> Allowing an image with a map might be useful, but switching to video > >> to watch someone finger-spell on a letter by letter basis is now > targeting > >> a very limited audience: those with very high end devices, no ability > >> to read text, and who are guaranteed to be able to map the finger- > spelled > >> version to whatever sign is normally used in their language community > >> for the area/street/etc. > >> > >> You do realize that you have whacked yourself into an > internationalization > >> problem as well, right? British Sign and American Sign Language are > not > >> mutual > >> intelligible, and you're now going to have to negotiate sign language > >> communities > >> of interest, even where you can presume a mutually intelligible > language > >> in text? > >> > >> Send the location object, and let the local rendering engine worry > about > >> it! It > >> will be configured for the user's needs. > >> > >> And, since I haven't said this for a day or two, it is now very, very > >> clear to me > >> that the document needs to cover both an automated test system and > >> a separate user-invoked one. If our putative high-end-system-using > >> signer loses his dhcp lease and gets a new IP, having the system start > >> signing at him is going way past the principle of least surprise. > >> > >> Ted > >> > >> > >> > >> > >> > >> > >> > >> > >>>> -----Original Message----- > >>>> From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > >>>> Sent: Monday, April 23, 2007 11:47 AM > >>>> To: Brian Rosen; Henning Schulzrinne; Ted Hardie > >>>> Cc: ECRIT > >>>> Subject: RE: [Ecrit] phonebcp and testing location correctness > >>>> > >>>> I would think that video letter-by-letter automated spelling of a > >>>> location would be rather tedious to watch. > >>>> > >>>> Could we send a JPG picture of a street map with a star where the > >>>> location is? > >>>> Barbara > >>>> > >>>> -----Original Message----- > >>>> From: Brian Rosen [mailto:br@brianrosen.net] > >>>> Sent: Monday, April 23, 2007 11:10 AM > >>>> To: Stark, Barbara; 'Henning Schulzrinne'; 'Ted Hardie' > >>>> Cc: 'ECRIT' > >>>> Subject: RE: [Ecrit] phonebcp and testing location correctness > >>>> > >>>> You have the problem with the deaf community; a very vocal and > >> effective > >>>> lobbyist for something I consider a very reasonable point of view: > they > >>>> want equivalent service. The specs require support for IM and real > >> time > >>>> interactive text. If that is the media asserted on the test INVITE, > >>>> they would expect the location coming back as text. > >>>> > >>>> Similarly, if they ask for video, they are expecting sign language. > I > >>>> have a query into them about the practicality of text to sign > language. > >>>> I don't see why it won't work just fine. Presumably you wouldn't > have > >> a > >>>> problem with that. > >>>> > >>>> Brian > >>>> > >>>>> -----Original Message----- > >>>>> From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > >>>>> Sent: Monday, April 23, 2007 10:41 AM > >>>>> To: Henning Schulzrinne; Ted Hardie > >>>>> Cc: ECRIT > >>>>> Subject: [Ecrit] phonebcp and testing location correctness > >>>>> > >>>>> Having thought about this over the weekend, I think I prefer > >>>>> recommending the voice-back of the de-referenced location, over > >>>>> providing a PIDF-LO in the 200 OK. For all the reasons that Henning > >>>>> mentioned. But I don't know how this would work if the negotiated > >>>>> medium were something other than a voice codec. Does support of this > >>>>> function for non-voice media need to be recommended? > >>>>> Barbara > >>>>> > >>>>> -----Original Message----- > >>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>>>> Sent: Thursday, April 19, 2007 6:05 PM > >>>>> To: Ted Hardie > >>>>> Cc: 'ECRIT' > >>>>> Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: > >>>>> (Partial)LocationHiding Emergency Services Architecture > >>>>> > >>>>> The whole point is that the caller can, if he so desires, verify the > >>>>> location information. Incorrect location information is a major > >> source > >>>>> of mis-routes and false dispatches today (see the NYT article I sent > >>>>> around a few weeks ago). > >>>>> > >>>>> Since location information, even without hiding, can be added by a > >>>>> proxy, this is the only way for the end system to determine what > >>>>> information will be conveyed to the PSAP in all cases. In existing > >>>>> system, finding this out is extremely tedious and burdensome to the > >>>>> PSAP, as you actually have to call 911 to see what address your > >>>>> carrier has registered for you. You really don't want to resolve the > >>>>> "No, I'm not living at 123 Main Street, that's my billing address" > >>>>> during an emergency call. > >>>>> > >>>>> I have no objection to returning this PSAP-seen information in some > >>>>> other way, such as location-conveyance, but I expected to hear > >> screams > >>>>> from the hide-location crowd in that case. Thus, I was trying to > find > >>>>> a way that achieves most of the goals, while not stepping on > >> sensitive > >>>>> toes. Since the existing test text includes the return of location > >>>>> information, albeit in a format that is left unspecified (which > >> should > >>>>> be fixed), I'm happy with that. > >>>>> > >>>>> I also have no objection to making this an optional request in the > >>>>> call, so that unattended test calls do not generate this, but I'm > not > >>>>> convinced that the complexity is worth it. > >>>>> > >>>>> Thus, I believe that this mechanism adds significantly to the > overall > >>>>> reliability of the system and we should encourage that it be > >> provided, > >>>>> whether as location-conveyance, audio or just a PIDF-LO attachment > in > >>>>> the 200 OK. (This generally won't work well, given the difficulty > >> real > >>>>> phones have with multipart, but that's a different > >>>>> topic.) > >>>>> > >>>>> Henning > >>>>> > >>>>> On Apr 19, 2007, at 5:43 PM, Ted Hardie wrote: > >>>>> > >>>>>> At 4:46 PM -0400 4/19/07, Brian Rosen wrote: > >>>>>>> I dropped geopriv > >>>>>>> > >>>>>>> Please look at -phonebcp for the current test procedure. This > >>>>>>> would add a step. > >>>>>> So, the proposal is to add this to 9.1. The current version says: > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Ecrit mailing list > >>>>> Ecrit@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>> > >>>>> _______________________________________________ > >>>>> Ecrit mailing list > >>>>> Ecrit@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 15:45:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4Tw-0000Lz-9p; Mon, 23 Apr 2007 15:45:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4Tv-0000Jv-Ux for ecrit@ietf.org; Mon, 23 Apr 2007 15:45:51 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg4Tu-0003sQ-KN for ecrit@ietf.org; Mon, 23 Apr 2007 15:45:51 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3NJjdfe028425 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Apr 2007 15:45:39 -0400 (EDT) In-Reply-To: <462CEC68.7060805@bbn.com> References: <4628FD3E.5080009@bbn.com> <730D0441-E19F-4092-BDEF-4905947C0AC3@cs.columbia.edu> <462CEC68.7060805@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5AC252CE-2EE7-4338-B473-1DBDEACF4ECD@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] An alternative proposal Date: Mon, 23 Apr 2007 15:47:04 -0400 To: Richard Barnes X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 23, 2007, at 1:27 PM, Richard Barnes wrote: >> This can be done, but requires significant, non-trivial extensions >> to LoST, unlike the existing proposal summarized by Brian and >> Hannes. So far, the only concrete proposal along these lines that >> has more than handwaving behind it is to flood all PSAP URLs, at >> least within a single tree. > > This doesn't have to be done with LoST, if that's not convenient. > You could define a really tiny XML protocol to do it, or you might > even be able to do something clever with NAPTR records in the DNS. Concrete proposals would be most helpful. The syntax is not the problem (we can all whip up some XML to do this), but how global distribution would work. It is, as noted, yet another protocol that needs to be implemented, secured and deployed, for no gain. > > In any case, it's just not that big a problem. If the U.S., with > 300M people, has 6K PSAPs, then we're talking about a database with > something like 120K entries to cover the whole world. Even if it > scales up two more orders of magnitude in the long run, that's only > a little over a GB of data. > The data volume is not the problem, as I have pointed out in an early message on this thread. Getting every VSP to recognize every legitimate PSAP URL in a timely fashion is slightly harder, as you really want to avoid false negatives. > For that size, you could create a dedicated FG (or FG cluster) that > could collect flooded URIs from trees and handle queries. The normal query volume is relatively low, but it's another vector for DOS attacks. (Send calls to random URLs claiming to be emergency calls, every single one of which generates a query to the FG.) > >>> 2. Trying to support the second question often leads to >>> unacceptable privacy consequences. The privacy risks incurred by >>> the "rough location" proposal are due to the fact that it tries >>> to answer the second question: Since VSPs can be (effectively) >>> anyone, the LIS has to give out location to everyone in order for >>> VSPs to be able to use location for this purpose. >> As has been stated many times before, the privacy content of the >> PSAP URL and the boundary are exactly the same. In other words, as >> soon as an emergency call reaches the VSP, the VSP can determine >> that the caller is in the coverage area of the PSAP. Nothing new >> here. > > If you're determining the location of a caller based on the fact > that a PSAP URI is in an INVITE, you need to have both the PSAP URI > and the INVITE. These only get sent out to proxies involved in > call setup, in which a certain amount of trust is vested anyway. > In effect, the VSP is authorized to have that information because > the caller sent it to him. > > On the other hand, if an unauthorized dereference returns a rough > location, then any host that knows or can guess the reference can > track the caller (with PSAP service-area granularity); the caller/ > target has no say. You can't restrict this sort of dereference to > VSPs since you've assumed that you can't authenticate VSPs. > > So the novelty is that instead of revealing the caller's location > to signaling entities, the you end up revealing it to everybody. I'm confused. It's not revealed to everybody, just to everybody who has access to the LbyR. If the call is protected by TLS, that would only be the signaling entities. If not, it is only the entities that can physically intercept the call. As Brian has pointed out, references are cryptographically-random. If they are not, it doesn't really matter, either. Say, an ISP returns http://lis.isp.net/psap1 http://lis.isp.net/psap2 ... which return the polygons and service URLs for PSAP1, PSAP2, etc. These can be published on a web page - all they reveal to anybody querying is the URL of PSAP1 and its service boundary, which we assume to be public information. Thus, in this particular instance, the reference doesn't even have to be random. (Obviously, this wouldn't work for the fine-grained resolution, but the information that's public is exactly the same.) > > > --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 16:04:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4mB-0008W3-76; Mon, 23 Apr 2007 16:04:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4mA-0008Vx-8X for ecrit@ietf.org; Mon, 23 Apr 2007 16:04:42 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg4m9-0007h1-H4 for ecrit@ietf.org; Mon, 23 Apr 2007 16:04:42 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3NK4SsB008407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Apr 2007 13:04:28 -0700 Received: from [76.102.225.135] (carbuncle.qualcomm.com [129.46.226.38]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3NK4Q00022753; Mon, 23 Apr 2007 13:04:27 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <051a01c785da$2f21fdb0$640fa8c0@cis.neustar.com> References: <051a01c785da$2f21fdb0$640fa8c0@cis.neustar.com> Date: Mon, 23 Apr 2007 13:04:24 -0700 To: "Brian Rosen" , "'Stark, Barbara'" , "'Henning Schulzrinne'" From: Ted Hardie Subject: RE: [Ecrit] phonebcp and testing location correctness Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by numenor.qualcomm.com id l3NK4SsB008407 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 3:04 PM -0400 4/23/07, Brian Rosen wrote: >Ted > >You just haven't been in the room with the deaf folks much. Brian, I have been in the room with lots of deaf folks. I used to sign fairly fluently because I worked with both ASL interpreters and deaf engineers. I'm rusty, but plenty aware of the concerns. >They reasonably demand equal service. They get it, because they ask for >reasonable accommodation. There are laws about that. We pay attention. >It's the right thing to do. Giving reasonably equal service is the law and it is the right thing to d= o. It is also the right thing to do to meet the needs of multiple language communities, to recognize that some of the folks using a location object will not be locals, and to provide facilities for that. But the way you are proposing to meet those needs is not the most effective solution. Will you provide for the needs of the deaf-blind by shipping braille punches over the wire? No, you will ship something that you presume their UI can transform into something they can read and which they will use for further interaction.=20 Shipping a location object back with the presumption that the that the user who needs text-to-signing will have a UI that provides it makes a lot more sense, just as a UI can provide multiple ways to present a geolocation or translate the pidf-lo entities into something meaningful in the language of the user (Does the read aloud you have in mind really say "A6" or does it say "street" or "rue" or "calle" or "Strasse" or "=03=F8=03=A5=03=C3=03=AC" ?) >There is no technical difficulty in providing text to signing. I don't >think an IETF spec has to say that, it just says: responds with a media >stream in the form negotiated containing the location in a human >understandable form (e.g. using text to speech).=20 This form of content negotiation is not trivial and maintaining the facil= ities to meet the needs of all users is certainly not trivial. Imagine for a m= oment you got stuck going 3ppp SA2, and you are in Beijing. You're running a test of your system to make sure it works with the Beijing emergency services. For this to work in your test scenario, they will need to take the location you provide them in a nice independent format, confirm it (which can be done very simply at the protocol level by re-affirming it in that independent format), then move it from that forma= t into English for read-aloud. Since that's a dominant language, you're pr= obably in luck. If your native language were Wolof, you would have a harder prob= lem, and I suspect you're going to get a non-native version (French, maybe) instead. If your native language were British Sign, you definitely would have a harder problem. But if the British Sign user had gotten back the confirming location object and had it rendered into sign, they would be getting back something that their UI can likely handle (either by convert= ing it to appropriate text or the appropriate sign). Note that I am not arguing for providing this back just for the deaf user= s. This is the right way to design the system for all the users, for the loc= alization reasons I gave above. It's just how that localization works in this case. If a user would need facilities for specific media streams (e.g. audio, t= ext, video), then the loopback mechanism can be used to test whether the PSAP can handle those media. But that doesn't need to be combined with using those media to do this type of confirmation. >Agree that automated test is different from user interactive test. Well, we've gotten to one point of agreement, at least. Good for that. Ted >Brian > >> -----Original Message----- >> From: Ted Hardie [mailto:hardie@qualcomm.com] >> Sent: Monday, April 23, 2007 2:32 PM >> To: Brian Rosen; 'Stark, Barbara'; 'Henning Schulzrinne' >> Cc: 'ECRIT' >> Subject: RE: [Ecrit] phonebcp and testing location correctness > > >> At 12:06 PM -0400 4/23/07, Brian Rosen wrote: >> >Yeah, maybe. I don't know how well that works on MPEG encoded video. >> > >> >However, spelling is just about the only way to sign a street address= ; >> there >> >are no signs for some street names and many city names. Spelling is = one >> of >> >the most common signs everyone learns. Good CAs spell really fast. >> > >> >Brian >> >> I think you are now seriously over-engineering a test system. Saying = that >> the test system can be expected to return the location in a form which >> may be rendered by the device at its UI discretion is the right on-the= - >> wire >> choice. Moving from that to one where you negotiate and then carry >> the UI presentation itself is a distant second. Decided that negotiat= ion >> must carry all possible representations is silly. For a test system, >> representations of the location in text are likely to be valid for pre= tty >> much any user and if you add in voice to text, you've covered the deaf >> and blind communities as well as the users with both of those faciliti= es. >> Allowing an image with a map might be useful, but switching to video >> to watch someone finger-spell on a letter by letter basis is now targe= ting >> a very limited audience: those with very high end devices, no ability >> to read text, and who are guaranteed to be able to map the finger-spel= led >> version to whatever sign is normally used in their language community >> for the area/street/etc. >> >> You do realize that you have whacked yourself into an internationaliza= tion >> problem as well, right? British Sign and American Sign Language are n= ot >> mutual >> intelligible, and you're now going to have to negotiate sign language >> communities >> of interest, even where you can presume a mutually intelligible langua= ge >> in text? >> >> Send the location object, and let the local rendering engine worry abo= ut >> it! It >> will be configured for the user's needs. >> >> And, since I haven't said this for a day or two, it is now very, very >> clear to me >> that the document needs to cover both an automated test system and >> a separate user-invoked one. If our putative high-end-system-using >> signer loses his dhcp lease and gets a new IP, having the system start >> signing at him is going way past the principle of least surprise. >> >> Ted >> >> >> >> >> >> >> >> >> > >> >> -----Original Message----- >> >> From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] >> >> Sent: Monday, April 23, 2007 11:47 AM >> >> To: Brian Rosen; Henning Schulzrinne; Ted Hardie >> >> Cc: ECRIT >> >> Subject: RE: [Ecrit] phonebcp and testing location correctness >> >> >> >> I would think that video letter-by-letter automated spelling of a >> >> location would be rather tedious to watch. >> >> >> >> Could we send a JPG picture of a street map with a star where the >> >> location is? >> >> Barbara >> >> >> >> -----Original Message----- >> >> From: Brian Rosen [mailto:br@brianrosen.net] >> >> Sent: Monday, April 23, 2007 11:10 AM >> >> To: Stark, Barbara; 'Henning Schulzrinne'; 'Ted Hardie' >> >> Cc: 'ECRIT' >> >> Subject: RE: [Ecrit] phonebcp and testing location correctness >> >> >> >> You have the problem with the deaf community; a very vocal and >> effective >> >> lobbyist for something I consider a very reasonable point of view: = they >> >> want equivalent service. The specs require support for IM and real >> time >> >> interactive text. If that is the media asserted on the test INVITE= , >> >> they would expect the location coming back as text. >> >> >> >> Similarly, if they ask for video, they are expecting sign language.= I >> >> have a query into them about the practicality of text to sign langu= age. >> >> I don't see why it won't work just fine. Presumably you wouldn't h= ave >> a >> >> problem with that. >> >> >> >> Brian >> >> >> >> > -----Original Message----- >> >> > From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] >> >> > Sent: Monday, April 23, 2007 10:41 AM >> >> > To: Henning Schulzrinne; Ted Hardie >> >> > Cc: ECRIT >> >> > Subject: [Ecrit] phonebcp and testing location correctness >> >> > >> >> > Having thought about this over the weekend, I think I prefer >> > > > recommending the voice-back of the de-referenced location, over > > >> > providing a PIDF-LO in the 200 OK. For all the reasons that Henn= ing >> >> > mentioned. But I don't know how this would work if the negotiated >> >> > medium were something other than a voice codec. Does support of t= his >> >> > function for non-voice media need to be recommended? >> >> > Barbara >> >> > >> >> > -----Original Message----- >> >> > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> >> > Sent: Thursday, April 19, 2007 6:05 PM >> >> > To: Ted Hardie >> >> > Cc: 'ECRIT' >> >> > Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: >> >> > (Partial)LocationHiding Emergency Services Architecture >> >> > >> >> > The whole point is that the caller can, if he so desires, verify = the >> >> > location information. Incorrect location information is a major >> source >> >> >> >> > of mis-routes and false dispatches today (see the NYT article I s= ent >> >> > around a few weeks ago). >> >> > >> >> > Since location information, even without hiding, can be added by = a >> >> > proxy, this is the only way for the end system to determine what >> >> > information will be conveyed to the PSAP in all cases. In existin= g >> >> > system, finding this out is extremely tedious and burdensome to t= he >> >> > PSAP, as you actually have to call 911 to see what address your >> >> > carrier has registered for you. You really don't want to resolve = the >> >> > "No, I'm not living at 123 Main Street, that's my billing address= " >> >> > during an emergency call. >> >> > >> >> > I have no objection to returning this PSAP-seen information in so= me >> >> > other way, such as location-conveyance, but I expected to hear >> screams >> >> >> >> > from the hide-location crowd in that case. Thus, I was trying to = find >> >> > a way that achieves most of the goals, while not stepping on >> sensitive >> >> >> >> > toes. Since the existing test text includes the return of locatio= n >> >> > information, albeit in a format that is left unspecified (which >> should >> >> >> >> > be fixed), I'm happy with that. >> >> > >> >> > I also have no objection to making this an optional request in th= e >> >> > call, so that unattended test calls do not generate this, but I'm= not >> >> > convinced that the complexity is worth it. >> >> > >> >> > Thus, I believe that this mechanism adds significantly to the ove= rall >> >> > reliability of the system and we should encourage that it be >> provided, >> >> >> >> > whether as location-conveyance, audio or just a PIDF-LO attachmen= t in >> >> > the 200 OK. (This generally won't work well, given the difficulty >> real >> >> >> >> > phones have with multipart, but that's a different >> >> > topic.) >> >> > >> >> > Henning >> >> > >> >> > On Apr 19, 2007, at 5:43 PM, Ted Hardie wrote: >> >> > >> >> > > At 4:46 PM -0400 4/19/07, Brian Rosen wrote: >> >> > >> I dropped geopriv >> >> > >> >> >> > >> Please look at -phonebcp for the current test procedure. This >> >> > >> would add a step. >> >> > > >> >> > > So, the proposal is to add this to 9.1. The current version sa= ys: >> >> > > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Ecrit mailing list >> >> > Ecrit@ietf.org >> >> > https://www1.ietf.org/mailman/listinfo/ecrit >> >> > >> >> > _______________________________________________ >> >> > Ecrit mailing list >> >> > Ecrit@ietf.org >> >> > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 16:09:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4qR-0001YJ-JD; Mon, 23 Apr 2007 16:09:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4fb-0006VL-GV for ecrit@ietf.org; Mon, 23 Apr 2007 15:57:56 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg4fa-0003aO-Jp for ecrit@ietf.org; Mon, 23 Apr 2007 15:57:55 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1Hg4e7-00011b-5K; Mon, 23 Apr 2007 14:56:24 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] phonebcp and testing location correctness Date: Mon, 23 Apr 2007 15:57:50 -0400 Message-ID: <054b01c785e1$ae2fc310$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: AceF4IyEHoOsOEa4QNuVkeulm36XmQAAJAkw 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608 Cc: "'Stark, Barbara'" , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org If a video endpoint is given a machine readable response, then it has to render something meaningful to the user. A deaf user may be able to read a map, but a videophone constructing the map may or may not be easy. It would be impossibly difficult to expect the videophone to render video of text to signing. The PSAP could provide that at its end reasonably. Having a telephone render speech from text for a blind user is similarly unreasonable, and also reasonable from the PSAP side. Sending the presentation on the wire as media in the form the SDP specifies is not unreasonable. Forcing the endpoint to generate media from machine readable information is unreasonable. Barbara doesn't want to send machine readable information. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Monday, April 23, 2007 3:51 PM > To: Brian Rosen > Cc: 'Richard Barnes'; 'Stark, Barbara'; 'ECRIT' > Subject: Re: [Ecrit] phonebcp and testing location correctness > > Brian, > > I don't understand your response here. But I agree with Richard and > Ted. > > -andy > > On Apr 23, 2007, at 3:42 PM, Brian Rosen wrote: > > > You want a video endpoint that could be used by a deaf user to > > render video > > from text? > > > > You want every telephone that could be used by a blind user to > > render audio > > from text? > > > > This is a local service, and can reasonably use local conventions (and > > caller prefs). > > > > Brian > >> -----Original Message----- > >> From: Richard Barnes [mailto:rbarnes@bbn.com] > >> Sent: Monday, April 23, 2007 3:31 PM > >> To: Brian Rosen > >> Cc: 'Ted Hardie'; 'Stark, Barbara'; 'Henning Schulzrinne'; 'ECRIT' > >> Subject: Re: [Ecrit] phonebcp and testing location correctness > >> > >> To echo Ted, providing machine-readable location is the right > >> *on-the-wire* choice. Given a machine-readable LO, the user's > >> equipment > >> can render it as text, braille, a map, sign language, or interpretive > >> dance -- it's much more easily adaptable for users with different > >> abilities. > >> > >> If you force the presentation onto the wire, you only get the > >> presentation that the server sends you. > >> > >> --RB > >> > >> > >> Brian Rosen wrote: > >>> Ted > >>> > >>> You just haven't been in the room with the deaf folks much. > >>> > >>> They reasonably demand equal service. They get it, because they > >>> ask for > >>> reasonable accommodation. There are laws about that. We pay > >>> attention. > >>> It's the right thing to do. > >>> > >>> There is no technical difficulty in providing text to signing. I > >>> don't > >>> think an IETF spec has to say that, it just says: responds with a > >>> media > >>> stream in the form negotiated containing the location in a human > >>> understandable form (e.g. using text to speech). > >>> > >>> Agree that automated test is different from user interactive test. > >>> > >>> Brian > >>> > >>>> -----Original Message----- > >>>> From: Ted Hardie [mailto:hardie@qualcomm.com] > >>>> Sent: Monday, April 23, 2007 2:32 PM > >>>> To: Brian Rosen; 'Stark, Barbara'; 'Henning Schulzrinne' > >>>> Cc: 'ECRIT' > >>>> Subject: RE: [Ecrit] phonebcp and testing location correctness > >>>> > >>>> At 12:06 PM -0400 4/23/07, Brian Rosen wrote: > >>>>> Yeah, maybe. I don't know how well that works on MPEG encoded > >>>>> video. > >>>>> > >>>>> However, spelling is just about the only way to sign a street > >>>>> address; > >>>> there > >>>>> are no signs for some street names and many city names. > >>>>> Spelling is > >> one > >>>> of > >>>>> the most common signs everyone learns. Good CAs spell really > >>>>> fast. > >>>>> > >>>>> Brian > >>>> I think you are now seriously over-engineering a test system. > >>>> Saying > >> that > >>>> the test system can be expected to return the location in a form > >>>> which > >>>> may be rendered by the device at its UI discretion is the right > >>>> on-the- > >>>> wire > >>>> choice. Moving from that to one where you negotiate and then carry > >>>> the UI presentation itself is a distant second. Decided that > >> negotiation > >>>> must carry all possible representations is silly. For a test > >>>> system, > >>>> representations of the location in text are likely to be valid for > >> pretty > >>>> much any user and if you add in voice to text, you've covered > >>>> the deaf > >>>> and blind communities as well as the users with both of those > >> facilities. > >>>> Allowing an image with a map might be useful, but switching to > >>>> video > >>>> to watch someone finger-spell on a letter by letter basis is now > >> targeting > >>>> a very limited audience: those with very high end devices, no > >>>> ability > >>>> to read text, and who are guaranteed to be able to map the finger- > >> spelled > >>>> version to whatever sign is normally used in their language > >>>> community > >>>> for the area/street/etc. > >>>> > >>>> You do realize that you have whacked yourself into an > >> internationalization > >>>> problem as well, right? British Sign and American Sign Language > >>>> are > >> not > >>>> mutual > >>>> intelligible, and you're now going to have to negotiate sign > >>>> language > >>>> communities > >>>> of interest, even where you can presume a mutually intelligible > >> language > >>>> in text? > >>>> > >>>> Send the location object, and let the local rendering engine worry > >> about > >>>> it! It > >>>> will be configured for the user's needs. > >>>> > >>>> And, since I haven't said this for a day or two, it is now very, > >>>> very > >>>> clear to me > >>>> that the document needs to cover both an automated test system and > >>>> a separate user-invoked one. If our putative high-end-system-using > >>>> signer loses his dhcp lease and gets a new IP, having the system > >>>> start > >>>> signing at him is going way past the principle of least surprise. > >>>> > >>>> Ted > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>> -----Original Message----- > >>>>>> From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > >>>>>> Sent: Monday, April 23, 2007 11:47 AM > >>>>>> To: Brian Rosen; Henning Schulzrinne; Ted Hardie > >>>>>> Cc: ECRIT > >>>>>> Subject: RE: [Ecrit] phonebcp and testing location correctness > >>>>>> > >>>>>> I would think that video letter-by-letter automated spelling of a > >>>>>> location would be rather tedious to watch. > >>>>>> > >>>>>> Could we send a JPG picture of a street map with a star where the > >>>>>> location is? > >>>>>> Barbara > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Brian Rosen [mailto:br@brianrosen.net] > >>>>>> Sent: Monday, April 23, 2007 11:10 AM > >>>>>> To: Stark, Barbara; 'Henning Schulzrinne'; 'Ted Hardie' > >>>>>> Cc: 'ECRIT' > >>>>>> Subject: RE: [Ecrit] phonebcp and testing location correctness > >>>>>> > >>>>>> You have the problem with the deaf community; a very vocal and > >>>> effective > >>>>>> lobbyist for something I consider a very reasonable point of > >>>>>> view: > >> they > >>>>>> want equivalent service. The specs require support for IM and > >>>>>> real > >>>> time > >>>>>> interactive text. If that is the media asserted on the test > >>>>>> INVITE, > >>>>>> they would expect the location coming back as text. > >>>>>> > >>>>>> Similarly, if they ask for video, they are expecting sign > >>>>>> language. > >> I > >>>>>> have a query into them about the practicality of text to sign > >> language. > >>>>>> I don't see why it won't work just fine. Presumably you wouldn't > >> have > >>>> a > >>>>>> problem with that. > >>>>>> > >>>>>> Brian > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > >>>>>>> Sent: Monday, April 23, 2007 10:41 AM > >>>>>>> To: Henning Schulzrinne; Ted Hardie > >>>>>>> Cc: ECRIT > >>>>>>> Subject: [Ecrit] phonebcp and testing location correctness > >>>>>>> > >>>>>>> Having thought about this over the weekend, I think I prefer > >>>>>>> recommending the voice-back of the de-referenced location, over > >>>>>>> providing a PIDF-LO in the 200 OK. For all the reasons that > >>>>>>> Henning > >>>>>>> mentioned. But I don't know how this would work if the > >>>>>>> negotiated > >>>>>>> medium were something other than a voice codec. Does support > >>>>>>> of this > >>>>>>> function for non-voice media need to be recommended? > >>>>>>> Barbara > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>>>>>> Sent: Thursday, April 19, 2007 6:05 PM > >>>>>>> To: Ted Hardie > >>>>>>> Cc: 'ECRIT' > >>>>>>> Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: > >>>>>>> (Partial)LocationHiding Emergency Services Architecture > >>>>>>> > >>>>>>> The whole point is that the caller can, if he so desires, > >>>>>>> verify the > >>>>>>> location information. Incorrect location information is a major > >>>> source > >>>>>>> of mis-routes and false dispatches today (see the NYT article > >>>>>>> I sent > >>>>>>> around a few weeks ago). > >>>>>>> > >>>>>>> Since location information, even without hiding, can be added > >>>>>>> by a > >>>>>>> proxy, this is the only way for the end system to determine what > >>>>>>> information will be conveyed to the PSAP in all cases. In > >>>>>>> existing > >>>>>>> system, finding this out is extremely tedious and burdensome > >>>>>>> to the > >>>>>>> PSAP, as you actually have to call 911 to see what address your > >>>>>>> carrier has registered for you. You really don't want to > >>>>>>> resolve the > >>>>>>> "No, I'm not living at 123 Main Street, that's my billing > >>>>>>> address" > >>>>>>> during an emergency call. > >>>>>>> > >>>>>>> I have no objection to returning this PSAP-seen information > >>>>>>> in some > >>>>>>> other way, such as location-conveyance, but I expected to hear > >>>> screams > >>>>>>> from the hide-location crowd in that case. Thus, I was trying to > >> find > >>>>>>> a way that achieves most of the goals, while not stepping on > >>>> sensitive > >>>>>>> toes. Since the existing test text includes the return of > >>>>>>> location > >>>>>>> information, albeit in a format that is left unspecified (which > >>>> should > >>>>>>> be fixed), I'm happy with that. > >>>>>>> > >>>>>>> I also have no objection to making this an optional request > >>>>>>> in the > >>>>>>> call, so that unattended test calls do not generate this, but > >>>>>>> I'm > >> not > >>>>>>> convinced that the complexity is worth it. > >>>>>>> > >>>>>>> Thus, I believe that this mechanism adds significantly to the > >> overall > >>>>>>> reliability of the system and we should encourage that it be > >>>> provided, > >>>>>>> whether as location-conveyance, audio or just a PIDF-LO > >>>>>>> attachment > >> in > >>>>>>> the 200 OK. (This generally won't work well, given the > >>>>>>> difficulty > >>>> real > >>>>>>> phones have with multipart, but that's a different > >>>>>>> topic.) > >>>>>>> > >>>>>>> Henning > >>>>>>> > >>>>>>> On Apr 19, 2007, at 5:43 PM, Ted Hardie wrote: > >>>>>>> > >>>>>>>> At 4:46 PM -0400 4/19/07, Brian Rosen wrote: > >>>>>>>>> I dropped geopriv > >>>>>>>>> > >>>>>>>>> Please look at -phonebcp for the current test procedure. This > >>>>>>>>> would add a step. > >>>>>>>> So, the proposal is to add this to 9.1. The current version > >>>>>>>> says: > >>>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Ecrit mailing list > >>>>>>> Ecrit@ietf.org > >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Ecrit mailing list > >>>>>>> Ecrit@ietf.org > >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/ecrit > >>> > >>> > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 16:20:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4Zw-0007ek-TB; Mon, 23 Apr 2007 15:52:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4ZH-000657-DO for ecrit@ietf.org; Mon, 23 Apr 2007 15:51:23 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg4Z8-0007UH-UW for ecrit@ietf.org; Mon, 23 Apr 2007 15:51:23 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 23 Apr 2007 15:51:14 -0400 id 015880BA.462D0E32.00007164 In-Reply-To: <052e01c785df$7faf13d0$640fa8c0@cis.neustar.com> References: <052e01c785df$7faf13d0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] phonebcp and testing location correctness Date: Mon, 23 Apr 2007 15:51:13 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Cc: "'Stark, Barbara'" , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, I don't understand your response here. But I agree with Richard and Ted. -andy On Apr 23, 2007, at 3:42 PM, Brian Rosen wrote: > You want a video endpoint that could be used by a deaf user to > render video > from text? > > You want every telephone that could be used by a blind user to > render audio > from text? > > This is a local service, and can reasonably use local conventions (and > caller prefs). > > Brian >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Monday, April 23, 2007 3:31 PM >> To: Brian Rosen >> Cc: 'Ted Hardie'; 'Stark, Barbara'; 'Henning Schulzrinne'; 'ECRIT' >> Subject: Re: [Ecrit] phonebcp and testing location correctness >> >> To echo Ted, providing machine-readable location is the right >> *on-the-wire* choice. Given a machine-readable LO, the user's >> equipment >> can render it as text, braille, a map, sign language, or interpretive >> dance -- it's much more easily adaptable for users with different >> abilities. >> >> If you force the presentation onto the wire, you only get the >> presentation that the server sends you. >> >> --RB >> >> >> Brian Rosen wrote: >>> Ted >>> >>> You just haven't been in the room with the deaf folks much. >>> >>> They reasonably demand equal service. They get it, because they >>> ask for >>> reasonable accommodation. There are laws about that. We pay >>> attention. >>> It's the right thing to do. >>> >>> There is no technical difficulty in providing text to signing. I >>> don't >>> think an IETF spec has to say that, it just says: responds with a >>> media >>> stream in the form negotiated containing the location in a human >>> understandable form (e.g. using text to speech). >>> >>> Agree that automated test is different from user interactive test. >>> >>> Brian >>> >>>> -----Original Message----- >>>> From: Ted Hardie [mailto:hardie@qualcomm.com] >>>> Sent: Monday, April 23, 2007 2:32 PM >>>> To: Brian Rosen; 'Stark, Barbara'; 'Henning Schulzrinne' >>>> Cc: 'ECRIT' >>>> Subject: RE: [Ecrit] phonebcp and testing location correctness >>>> >>>> At 12:06 PM -0400 4/23/07, Brian Rosen wrote: >>>>> Yeah, maybe. I don't know how well that works on MPEG encoded >>>>> video. >>>>> >>>>> However, spelling is just about the only way to sign a street >>>>> address; >>>> there >>>>> are no signs for some street names and many city names. >>>>> Spelling is >> one >>>> of >>>>> the most common signs everyone learns. Good CAs spell really >>>>> fast. >>>>> >>>>> Brian >>>> I think you are now seriously over-engineering a test system. >>>> Saying >> that >>>> the test system can be expected to return the location in a form >>>> which >>>> may be rendered by the device at its UI discretion is the right >>>> on-the- >>>> wire >>>> choice. Moving from that to one where you negotiate and then carry >>>> the UI presentation itself is a distant second. Decided that >> negotiation >>>> must carry all possible representations is silly. For a test >>>> system, >>>> representations of the location in text are likely to be valid for >> pretty >>>> much any user and if you add in voice to text, you've covered >>>> the deaf >>>> and blind communities as well as the users with both of those >> facilities. >>>> Allowing an image with a map might be useful, but switching to >>>> video >>>> to watch someone finger-spell on a letter by letter basis is now >> targeting >>>> a very limited audience: those with very high end devices, no >>>> ability >>>> to read text, and who are guaranteed to be able to map the finger- >> spelled >>>> version to whatever sign is normally used in their language >>>> community >>>> for the area/street/etc. >>>> >>>> You do realize that you have whacked yourself into an >> internationalization >>>> problem as well, right? British Sign and American Sign Language >>>> are >> not >>>> mutual >>>> intelligible, and you're now going to have to negotiate sign >>>> language >>>> communities >>>> of interest, even where you can presume a mutually intelligible >> language >>>> in text? >>>> >>>> Send the location object, and let the local rendering engine worry >> about >>>> it! It >>>> will be configured for the user's needs. >>>> >>>> And, since I haven't said this for a day or two, it is now very, >>>> very >>>> clear to me >>>> that the document needs to cover both an automated test system and >>>> a separate user-invoked one. If our putative high-end-system-using >>>> signer loses his dhcp lease and gets a new IP, having the system >>>> start >>>> signing at him is going way past the principle of least surprise. >>>> >>>> Ted >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>>> -----Original Message----- >>>>>> From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] >>>>>> Sent: Monday, April 23, 2007 11:47 AM >>>>>> To: Brian Rosen; Henning Schulzrinne; Ted Hardie >>>>>> Cc: ECRIT >>>>>> Subject: RE: [Ecrit] phonebcp and testing location correctness >>>>>> >>>>>> I would think that video letter-by-letter automated spelling of a >>>>>> location would be rather tedious to watch. >>>>>> >>>>>> Could we send a JPG picture of a street map with a star where the >>>>>> location is? >>>>>> Barbara >>>>>> >>>>>> -----Original Message----- >>>>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>>>> Sent: Monday, April 23, 2007 11:10 AM >>>>>> To: Stark, Barbara; 'Henning Schulzrinne'; 'Ted Hardie' >>>>>> Cc: 'ECRIT' >>>>>> Subject: RE: [Ecrit] phonebcp and testing location correctness >>>>>> >>>>>> You have the problem with the deaf community; a very vocal and >>>> effective >>>>>> lobbyist for something I consider a very reasonable point of >>>>>> view: >> they >>>>>> want equivalent service. The specs require support for IM and >>>>>> real >>>> time >>>>>> interactive text. If that is the media asserted on the test >>>>>> INVITE, >>>>>> they would expect the location coming back as text. >>>>>> >>>>>> Similarly, if they ask for video, they are expecting sign >>>>>> language. >> I >>>>>> have a query into them about the practicality of text to sign >> language. >>>>>> I don't see why it won't work just fine. Presumably you wouldn't >> have >>>> a >>>>>> problem with that. >>>>>> >>>>>> Brian >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] >>>>>>> Sent: Monday, April 23, 2007 10:41 AM >>>>>>> To: Henning Schulzrinne; Ted Hardie >>>>>>> Cc: ECRIT >>>>>>> Subject: [Ecrit] phonebcp and testing location correctness >>>>>>> >>>>>>> Having thought about this over the weekend, I think I prefer >>>>>>> recommending the voice-back of the de-referenced location, over >>>>>>> providing a PIDF-LO in the 200 OK. For all the reasons that >>>>>>> Henning >>>>>>> mentioned. But I don't know how this would work if the >>>>>>> negotiated >>>>>>> medium were something other than a voice codec. Does support >>>>>>> of this >>>>>>> function for non-voice media need to be recommended? >>>>>>> Barbara >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>>>> Sent: Thursday, April 19, 2007 6:05 PM >>>>>>> To: Ted Hardie >>>>>>> Cc: 'ECRIT' >>>>>>> Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: >>>>>>> (Partial)LocationHiding Emergency Services Architecture >>>>>>> >>>>>>> The whole point is that the caller can, if he so desires, >>>>>>> verify the >>>>>>> location information. Incorrect location information is a major >>>> source >>>>>>> of mis-routes and false dispatches today (see the NYT article >>>>>>> I sent >>>>>>> around a few weeks ago). >>>>>>> >>>>>>> Since location information, even without hiding, can be added >>>>>>> by a >>>>>>> proxy, this is the only way for the end system to determine what >>>>>>> information will be conveyed to the PSAP in all cases. In >>>>>>> existing >>>>>>> system, finding this out is extremely tedious and burdensome >>>>>>> to the >>>>>>> PSAP, as you actually have to call 911 to see what address your >>>>>>> carrier has registered for you. You really don't want to >>>>>>> resolve the >>>>>>> "No, I'm not living at 123 Main Street, that's my billing >>>>>>> address" >>>>>>> during an emergency call. >>>>>>> >>>>>>> I have no objection to returning this PSAP-seen information >>>>>>> in some >>>>>>> other way, such as location-conveyance, but I expected to hear >>>> screams >>>>>>> from the hide-location crowd in that case. Thus, I was trying to >> find >>>>>>> a way that achieves most of the goals, while not stepping on >>>> sensitive >>>>>>> toes. Since the existing test text includes the return of >>>>>>> location >>>>>>> information, albeit in a format that is left unspecified (which >>>> should >>>>>>> be fixed), I'm happy with that. >>>>>>> >>>>>>> I also have no objection to making this an optional request >>>>>>> in the >>>>>>> call, so that unattended test calls do not generate this, but >>>>>>> I'm >> not >>>>>>> convinced that the complexity is worth it. >>>>>>> >>>>>>> Thus, I believe that this mechanism adds significantly to the >> overall >>>>>>> reliability of the system and we should encourage that it be >>>> provided, >>>>>>> whether as location-conveyance, audio or just a PIDF-LO >>>>>>> attachment >> in >>>>>>> the 200 OK. (This generally won't work well, given the >>>>>>> difficulty >>>> real >>>>>>> phones have with multipart, but that's a different >>>>>>> topic.) >>>>>>> >>>>>>> Henning >>>>>>> >>>>>>> On Apr 19, 2007, at 5:43 PM, Ted Hardie wrote: >>>>>>> >>>>>>>> At 4:46 PM -0400 4/19/07, Brian Rosen wrote: >>>>>>>>> I dropped geopriv >>>>>>>>> >>>>>>>>> Please look at -phonebcp for the current test procedure. This >>>>>>>>> would add a step. >>>>>>>> So, the proposal is to add this to 9.1. The current version >>>>>>>> says: >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 17:09:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg5n8-0005l8-6M; Mon, 23 Apr 2007 17:09:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg5n6-0005jr-Mf for ecrit@ietf.org; Mon, 23 Apr 2007 17:09:44 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg5n5-0004Lv-FK for ecrit@ietf.org; Mon, 23 Apr 2007 17:09:44 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3NL9TRI006420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Apr 2007 17:09:29 -0400 (EDT) In-Reply-To: References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host Date: Mon, 23 Apr 2007 17:10:54 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 23, 2007, at 12:24 PM, Andrew Newton wrote: > > On Apr 23, 2007, at 9:19 AM, Henning Schulzrinne wrote: > >> I'm less worried about DHCP, but rather about PIDF-LO, as the >> variability and extensibility of that data element is much larger. >> One of the problems is that a device has to mark the location >> information with a profile, instead of just copying the data. I >> think it would be better to have the client provide the LO, and >> the server reject it if can't parse that particular GML-derived >> format. > > The entire LO? I thought it was a part of our requirements that > identifying information not be sent inside of LoST. It just needs > to copy the location information XML. I don't really understand > your concern. I was being imprecise. I'm talking about the part of PIDF-LO only, not the rest. That part does not identify the profile to be used. > > BTW, while some of us implicitly understand this, do have it > written anywhere that RFC 3825 without floor is geodetic-2d and > that RFC 4776 is the civic profile. A UA would presumably translate either into , so I don't think we need to declare this explicitly, as the raw DHCP data isn't visible to the server. > >> We still need to define a set of must-implement profiles for the >> server. Negotiation makes no sense in this case (due to the multi- >> hop nature of LoST), so this set is likely to remain fairly >> constant over long time periods. > > Huh? Didn't we already discuss this? geodetic-2d and civic are > the two base profiles. > Certainly; I was just commenting, in case that somebody was inferring the opposite, that we still need profiles. Just that having the client declare the profile of the location it is sending is not too useful. In short, my proposal is simple: - Remove the restriction that the profile used for sending data is the same as that used for processing the . This avoids having thje client guess what profile a (new) corresponds to. - The profile declaration thus only applies to the allowable responses. - A server can continue to indicate the mapping point format it supports. Henning > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 17:23:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg601-00066Y-J8; Mon, 23 Apr 2007 17:23:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg600-00066T-CI for ecrit@ietf.org; Mon, 23 Apr 2007 17:23:04 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg5zy-0007lV-KZ for ecrit@ietf.org; Mon, 23 Apr 2007 17:23:04 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3NLMtJp018612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Apr 2007 14:22:55 -0700 Received: from [76.102.225.135] (carbuncle.qualcomm.com [129.46.226.38]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3NLMrgX029064; Mon, 23 Apr 2007 14:22:54 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <054b01c785e1$ae2fc310$640fa8c0@cis.neustar.com> References: <054b01c785e1$ae2fc310$640fa8c0@cis.neustar.com> Date: Mon, 23 Apr 2007 14:22:51 -0700 To: "Brian Rosen" , "'Andrew Newton'" From: Ted Hardie Subject: RE: [Ecrit] phonebcp and testing location correctness Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b Cc: "'Stark, Barbara'" , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 3:57 PM -0400 4/23/07, Brian Rosen wrote: >If a video endpoint is given a machine readable response, then it has to >render something meaningful to the user. A deaf user may be able to read a >map, but a videophone constructing the map may or may not be easy. It would >be impossibly difficult to expect the videophone to render video of text to >signing. The PSAP could provide that at its end reasonably. Are you imagining it gets sent video of text, and turns that into video of signing? That would be very hard. But the core object isn't video in the proposal I've made; it is the PIDF-LO. Assuming the PIDF-LO can be rendered into text, any text-to-sign system available to the UI would work. If there is no text-to-sign available, text alone would be available. You were only talking about finger spelling, if I understood your original proposal, and using a large finger spelling font would cover at least that much. If something better were available I would, of course, expect it to be used. >Having a telephone render speech from text for a blind user is similarly >unreasonable, and also reasonable from the PSAP side. Why do you think having the phone do this is unreasonable? There are already phones that do short speech-to-text (e.g. the Samsung p207) and that is much harder. Both the p207 and a890 also do speech-to-text. I am assuming a specialized device or software set, I grant you, but it seemed to me you were as well. Are you concerned that this requirement would have to be met by all phones? Using a relay seems much more likely to be the case for a special needs user and a regular phone. >Sending the presentation on the wire as media in the form the SDP specifies >is not unreasonable. Forcing the endpoint to generate media from machine >readable information is unreasonable. This seems like a dogmatic assertion. It certainly isn't going to be unreasonable to generate text from the pidf-lo, and that really is going to cover a lot of cases where the phone has a screen. >Barbara doesn't want to send machine readable information. > >Brian If I understood Barbara, she wasn't going to fight on this point, as she thought it was really going to be up to regulators rather than us. But perhaps we should both speak for ourselves and let Barbara raise what concerns she has. Ted > > -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Monday, April 23, 2007 3:51 PM >> To: Brian Rosen >> Cc: 'Richard Barnes'; 'Stark, Barbara'; 'ECRIT' >> Subject: Re: [Ecrit] phonebcp and testing location correctness >> >> Brian, >> >> I don't understand your response here. But I agree with Richard and >> Ted. >> >> -andy >> >> On Apr 23, 2007, at 3:42 PM, Brian Rosen wrote: >> >> > You want a video endpoint that could be used by a deaf user to >> > render video >> > from text? >> > >> > You want every telephone that could be used by a blind user to >> > render audio >> > from text? >> > >> > This is a local service, and can reasonably use local conventions (and >> > caller prefs). >> > >> > Brian >> >> -----Original Message----- >> >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> >> Sent: Monday, April 23, 2007 3:31 PM >> >> To: Brian Rosen >> >> Cc: 'Ted Hardie'; 'Stark, Barbara'; 'Henning Schulzrinne'; 'ECRIT' >> >> Subject: Re: [Ecrit] phonebcp and testing location correctness >> >> >> >> To echo Ted, providing machine-readable location is the right >> >> *on-the-wire* choice. Given a machine-readable LO, the user's >> >> equipment >> >> can render it as text, braille, a map, sign language, or interpretive >> >> dance -- it's much more easily adaptable for users with different >> >> abilities. >> >> >> >> If you force the presentation onto the wire, you only get the >> >> presentation that the server sends you. >> >> >> >> --RB >> >> >> >> >> >> Brian Rosen wrote: >> >>> Ted > > >>> >> >>> You just haven't been in the room with the deaf folks much. >> >>> >> >>> They reasonably demand equal service. They get it, because they >> >>> ask for >> >>> reasonable accommodation. There are laws about that. We pay >> >>> attention. >> >>> It's the right thing to do. >> >>> >> >>> There is no technical difficulty in providing text to signing. I >> >>> don't >> >>> think an IETF spec has to say that, it just says: responds with a >> >>> media >> >>> stream in the form negotiated containing the location in a human >> >>> understandable form (e.g. using text to speech). >> >>> >> >>> Agree that automated test is different from user interactive test. >> >>> >> >>> Brian >> >>> >> >>>> -----Original Message----- >> >>>> From: Ted Hardie [mailto:hardie@qualcomm.com] >> >>>> Sent: Monday, April 23, 2007 2:32 PM >> >>>> To: Brian Rosen; 'Stark, Barbara'; 'Henning Schulzrinne' >> >>>> Cc: 'ECRIT' >> >>>> Subject: RE: [Ecrit] phonebcp and testing location correctness >> >>>> >> >>>> At 12:06 PM -0400 4/23/07, Brian Rosen wrote: >> >>>>> Yeah, maybe. I don't know how well that works on MPEG encoded >> >>>>> video. >> >>>>> >> >>>>> However, spelling is just about the only way to sign a street >> >>>>> address; >> >>>> there >> >>>>> are no signs for some street names and many city names. >> >>>>> Spelling is >> >> one >> >>>> of >> >>>>> the most common signs everyone learns. Good CAs spell really >> >>>>> fast. >> >>>>> >> >>>>> Brian >> >>>> I think you are now seriously over-engineering a test system. >> >>>> Saying >> >> that >> >>>> the test system can be expected to return the location in a form >> >>>> which >> >>>> may be rendered by the device at its UI discretion is the right >> >>>> on-the- >> >>>> wire >> >>>> choice. Moving from that to one where you negotiate and then carry >> >>>> the UI presentation itself is a distant second. Decided that >> >> negotiation >> >>>> must carry all possible representations is silly. For a test >> >>>> system, >> >>>> representations of the location in text are likely to be valid for >> >> pretty >> >>>> much any user and if you add in voice to text, you've covered >> >>>> the deaf >> >>>> and blind communities as well as the users with both of those >> >> facilities. >> >>>> Allowing an image with a map might be useful, but switching to >> >>>> video >> >>>> to watch someone finger-spell on a letter by letter basis is now >> >> targeting >> >>>> a very limited audience: those with very high end devices, no >> >>>> ability >> >>>> to read text, and who are guaranteed to be able to map the finger- >> >> spelled >> >>>> version to whatever sign is normally used in their language >> >>>> community >> >>>> for the area/street/etc. >> >>>> >> >>>> You do realize that you have whacked yourself into an >> >> internationalization >> >>>> problem as well, right? British Sign and American Sign Language >> >>>> are >> >> not >> >>>> mutual >> >>>> intelligible, and you're now going to have to negotiate sign >> >>>> language >> >>>> communities >> >>>> of interest, even where you can presume a mutually intelligible >> >> language >> >>>> in text? >> >>>> >> >>>> Send the location object, and let the local rendering engine worry >> >> about >> >>>> it! It >> >>>> will be configured for the user's needs. >> >>>> >> >>>> And, since I haven't said this for a day or two, it is now very, >> >>>> very >> >>>> clear to me >> >>>> that the document needs to cover both an automated test system and >> >>>> a separate user-invoked one. If our putative high-end-system-using >> >>>> signer loses his dhcp lease and gets a new IP, having the system >> >>>> start >> >>>> signing at him is going way past the principle of least surprise. >> >>>> >> >>>> Ted >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>>>> -----Original Message----- >> >>>>>> From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] >> >>>>>> Sent: Monday, April 23, 2007 11:47 AM >> >>>>>> To: Brian Rosen; Henning Schulzrinne; Ted Hardie >> >>>>>> Cc: ECRIT >> >>>>>> Subject: RE: [Ecrit] phonebcp and testing location correctness >> >>>>>> >> >>>>>> I would think that video letter-by-letter automated spelling of a > > >>>>>> location would be rather tedious to watch. >> >>>>>> >> >>>>>> Could we send a JPG picture of a street map with a star where the >> >>>>>> location is? >> >>>>>> Barbara >> >>>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: Brian Rosen [mailto:br@brianrosen.net] >> >>>>>> Sent: Monday, April 23, 2007 11:10 AM >> >>>>>> To: Stark, Barbara; 'Henning Schulzrinne'; 'Ted Hardie' >> >>>>>> Cc: 'ECRIT' >> >>>>>> Subject: RE: [Ecrit] phonebcp and testing location correctness >> >>>>>> >> >>>>>> You have the problem with the deaf community; a very vocal and >> >>>> effective >> >>>>>> lobbyist for something I consider a very reasonable point of >> >>>>>> view: >> >> they >> >>>>>> want equivalent service. The specs require support for IM and >> >>>>>> real >> >>>> time >> >>>>>> interactive text. If that is the media asserted on the test >> >>>>>> INVITE, >> >>>>>> they would expect the location coming back as text. >> >>>>>> >> >>>>>> Similarly, if they ask for video, they are expecting sign >> >>>>>> language. >> >> I >> >>>>>> have a query into them about the practicality of text to sign >> >> language. >> >>>>>> I don't see why it won't work just fine. Presumably you wouldn't >> >> have >> >>>> a >> >>>>>> problem with that. >> >>>>>> >> >>>>>> Brian >> >>>>>> >> >>>>>>> -----Original Message----- >> >>>>>>> From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] >> >>>>>>> Sent: Monday, April 23, 2007 10:41 AM >> >>>>>>> To: Henning Schulzrinne; Ted Hardie >> >>>>>>> Cc: ECRIT >> >>>>>>> Subject: [Ecrit] phonebcp and testing location correctness >> >>>>>>> >> >>>>>>> Having thought about this over the weekend, I think I prefer >> >>>>>>> recommending the voice-back of the de-referenced location, over >> >>>>>>> providing a PIDF-LO in the 200 OK. For all the reasons that >> >>>>>>> Henning >> >>>>>>> mentioned. But I don't know how this would work if the >> >>>>>>> negotiated >> >>>>>>> medium were something other than a voice codec. Does support >> >>>>>>> of this >> >>>>>>> function for non-voice media need to be recommended? >> >>>>>>> Barbara >> >>>>>>> >> >>>>>>> -----Original Message----- >> >>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> >>>>>>> Sent: Thursday, April 19, 2007 6:05 PM >> >>>>>>> To: Ted Hardie >> >>>>>>> Cc: 'ECRIT' >> >>>>>>> Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: >> >>>>>>> (Partial)LocationHiding Emergency Services Architecture >> >>>>>>> >> >>>>>>> The whole point is that the caller can, if he so desires, >> >>>>>>> verify the >> >>>>>>> location information. Incorrect location information is a major >> >>>> source >> >>>>>>> of mis-routes and false dispatches today (see the NYT article >> >>>>>>> I sent >> >>>>>>> around a few weeks ago). >> >>>>>>> >> >>>>>>> Since location information, even without hiding, can be added >> >>>>>>> by a >> >>>>>>> proxy, this is the only way for the end system to determine what >> >>>>>>> information will be conveyed to the PSAP in all cases. In >> >>>>>>> existing >> >>>>>>> system, finding this out is extremely tedious and burdensome >> >>>>>>> to the >> >>>>>>> PSAP, as you actually have to call 911 to see what address your >> >>>>>>> carrier has registered for you. You really don't want to >> >>>>>>> resolve the >> >>>>>>> "No, I'm not living at 123 Main Street, that's my billing >> >>>>>>> address" >> >>>>>>> during an emergency call. >> >>>>>>> >> >>>>>>> I have no objection to returning this PSAP-seen information >> >>>>>>> in some >> >>>>>>> other way, such as location-conveyance, but I expected to hear >> >>>> screams >> >>>>>>> from the hide-location crowd in that case. Thus, I was trying to >> >> find >> >>>>>>> a way that achieves most of the goals, while not stepping on >> >>>> sensitive >> >>>>>>> toes. Since the existing test text includes the return of >> >>>>>>> location >> >>>>>>> information, albeit in a format that is left unspecified (which >> >>>> should >> >>>>>>> be fixed), I'm happy with that. >> >>>>>>> >> >>>>>>> I also have no objection to making this an optional request >> >>>>>>> in the >> >>>>>>> call, so that unattended test calls do not generate this, but >> >>>>>>> I'm >> >> not > > >>>>>>> convinced that the complexity is worth it. >> >>>>>>> >> >>>>>>> Thus, I believe that this mechanism adds significantly to the >> >> overall >> >>>>>>> reliability of the system and we should encourage that it be >> >>>> provided, >> >>>>>>> whether as location-conveyance, audio or just a PIDF-LO >> >>>>>>> attachment >> >> in >> >>>>>>> the 200 OK. (This generally won't work well, given the >> >>>>>>> difficulty >> >>>> real >> >>>>>>> phones have with multipart, but that's a different >> >>>>>>> topic.) >> >>>>>>> >> >>>>>>> Henning >> >>>>>>> >> >>>>>>> On Apr 19, 2007, at 5:43 PM, Ted Hardie wrote: >> >>>>>>> >> >>>>>>>> At 4:46 PM -0400 4/19/07, Brian Rosen wrote: >> >>>>>>>>> I dropped geopriv >> >>>>>>>>> >> >>>>>>>>> Please look at -phonebcp for the current test procedure. This >> >>>>>>>>> would add a step. >> >>>>>>>> So, the proposal is to add this to 9.1. The current version >> >>>>>>>> says: >> >>>>>>>> >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> Ecrit mailing list >> >>>>>>> Ecrit@ietf.org >> >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> Ecrit mailing list >> >>>>>>> Ecrit@ietf.org >> >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >> >>> >> >>> >> >>> _______________________________________________ >> >>> Ecrit mailing list >> >>> Ecrit@ietf.org >> >>> https://www1.ietf.org/mailman/listinfo/ecrit >> >>> >> >>> >> > >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www1.ietf.org/mailman/listinfo/ecrit > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 17:28:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg64o-0007VR-SP; Mon, 23 Apr 2007 17:28:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg64n-0007VD-PA for ecrit@ietf.org; Mon, 23 Apr 2007 17:28:01 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg64n-0008Sb-3H for ecrit@ietf.org; Mon, 23 Apr 2007 17:28:01 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1Hg63J-0005en-Lb; Mon, 23 Apr 2007 16:26:30 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Stark, Barbara'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] phonebcp and testing location correctness Date: Mon, 23 Apr 2007 17:27:56 -0400 Message-ID: <061001c785ee$44738300$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: AceF4mZfp9U0acfKShiGnhPxVncbCAACJoiQ 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 919b3965bd46f7460d234f848680b238 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Ted Although it may be possible for a videophone to render text, and might = be acceptable to most deaf folks, do you think it is reasonable for a voice phone to render speech for a blind person? I get to needing text to = sign by realizing I have to serve blind folks by the media of their choice and = back myself into having to serve signing folks in the media of their choice. Is it reasonable for any phone to render text in a variety of languages = for this purpose? Do you think, realistically, it will happen? Given Barbara's concerns about revealing location, do you think PSAPs = will choose to jeopardize local access network's efforts to supply location = by revealing it in machine readable form? On the other hand, do you think it would be reasonable for a PSAP (or = some contractor operating under authority of a PSAP or other agency) to = provide text to speech and text to sign for this purpose? I fear we can write the specs to say send a PIDF back, it will not = result in a useful service to users. =20 Brian > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Monday, April 23, 2007 4:04 PM > To: Brian Rosen; 'Stark, Barbara'; 'Henning Schulzrinne' > Cc: 'ECRIT' > Subject: RE: [Ecrit] phonebcp and testing location correctness >=20 > At 3:04 PM -0400 4/23/07, Brian Rosen wrote: > >Ted > > > >You just haven't been in the room with the deaf folks much. >=20 > Brian, I have been in the room with lots of deaf folks. I used to > sign fairly fluently because I worked with both ASL interpreters > and deaf engineers. I'm rusty, but plenty aware of the concerns. >=20 > >They reasonably demand equal service. They get it, because they ask = for > >reasonable accommodation. There are laws about that. We pay = attention. > >It's the right thing to do. >=20 > Giving reasonably equal service is the law and it is the right thing = to > do. > It is also the right thing to do to meet the needs of multiple = language > communities, to recognize that some of the folks using a location > object will not be locals, and to provide facilities for that. But = the > way you are proposing to meet those needs is not the most effective > solution. Will you provide for the needs of the deaf-blind by = shipping > braille punches over the wire? No, you will ship something that you > presume their UI can transform into something they can read and > which they will use for further interaction. >=20 > Shipping a location object back with the presumption that the that > the user who needs text-to-signing will have a UI that provides > it makes a lot more sense, just as a UI can provide multiple ways to > present a geolocation or translate the pidf-lo entities into something > meaningful in the language of the user (Does the read aloud you have > in mind really say "A6" or does it say "street" or "rue" or "calle" or > "Strasse" or "=03=F8=03=A5=03=C3=03=AC" ?) >=20 > >There is no technical difficulty in providing text to signing. I = don't > >think an IETF spec has to say that, it just says: responds with a = media > >stream in the form negotiated containing the location in a human > >understandable form (e.g. using text to speech). >=20 > This form of content negotiation is not trivial and maintaining the > facilities > to meet the needs of all users is certainly not trivial. Imagine for = a > moment > you got stuck going 3ppp SA2, and you are in Beijing. You're running > a test of your system to make sure it works with the Beijing emergency > services. For this to work in your test scenario, they will need to > take the location you provide them in a nice independent format, > confirm it (which can be done very simply at the protocol level by > re-affirming it in that independent format), then move it from that = format > into English for read-aloud. Since that's a dominant language, you're > probably > in luck. If your native language were Wolof, you would have a harder > problem, > and I suspect you're going to get a non-native version (French, maybe) > instead. If your native language were British Sign, you definitely = would > have a harder problem. But if the British Sign user had gotten back = the > confirming location object and had it rendered into sign, they would = be > getting back something that their UI can likely handle (either by > converting > it to appropriate text or the appropriate sign). >=20 > Note that I am not arguing for providing this back just for the deaf > users. > This is the right way to design the system for all the users, for the > localization > reasons I gave above. It's just how that localization works in this = case. >=20 > If a user would need facilities for specific media streams (e.g. = audio, > text, > video), then the loopback mechanism can be used to test whether the = PSAP > can handle those media. But that doesn't need to be combined with = using > those media to do this type of confirmation. >=20 > >Agree that automated test is different from user interactive test. >=20 > Well, we've gotten to one point of agreement, at least. Good for = that. >=20 > Ted >=20 >=20 > >Brian > > > >> -----Original Message----- > >> From: Ted Hardie [mailto:hardie@qualcomm.com] > >> Sent: Monday, April 23, 2007 2:32 PM > >> To: Brian Rosen; 'Stark, Barbara'; 'Henning Schulzrinne' > >> Cc: 'ECRIT' > >> Subject: RE: [Ecrit] phonebcp and testing location correctness > > > > >> At 12:06 PM -0400 4/23/07, Brian Rosen wrote: > >> >Yeah, maybe. I don't know how well that works on MPEG encoded = video. > >> > > >> >However, spelling is just about the only way to sign a street = address; > >> there > >> >are no signs for some street names and many city names. Spelling = is > one > >> of > >> >the most common signs everyone learns. Good CAs spell really = fast. > >> > > >> >Brian > >> > >> I think you are now seriously over-engineering a test system. = Saying > that > >> the test system can be expected to return the location in a form = which > >> may be rendered by the device at its UI discretion is the right = on-the- > >> wire > >> choice. Moving from that to one where you negotiate and then carry > >> the UI presentation itself is a distant second. Decided that > negotiation > >> must carry all possible representations is silly. For a test = system, > >> representations of the location in text are likely to be valid for > pretty > >> much any user and if you add in voice to text, you've covered the = deaf > >> and blind communities as well as the users with both of those > facilities. > >> Allowing an image with a map might be useful, but switching to = video > >> to watch someone finger-spell on a letter by letter basis is now > targeting > >> a very limited audience: those with very high end devices, no = ability > >> to read text, and who are guaranteed to be able to map the finger- > spelled > >> version to whatever sign is normally used in their language = community > >> for the area/street/etc. > >> > >> You do realize that you have whacked yourself into an > internationalization > >> problem as well, right? British Sign and American Sign Language = are > not > >> mutual > >> intelligible, and you're now going to have to negotiate sign = language > >> communities > >> of interest, even where you can presume a mutually intelligible > language > >> in text? > >> > >> Send the location object, and let the local rendering engine worry > about > >> it! It > >> will be configured for the user's needs. > >> > >> And, since I haven't said this for a day or two, it is now very, = very > >> clear to me > >> that the document needs to cover both an automated test system and > >> a separate user-invoked one. If our putative high-end-system-using > >> signer loses his dhcp lease and gets a new IP, having the system = start > >> signing at him is going way past the principle of least surprise. > >> > >> Ted > >> > >> > >> > >> > >> > >> > >> > >> > >> > > >> >> -----Original Message----- > >> >> From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > >> >> Sent: Monday, April 23, 2007 11:47 AM > >> >> To: Brian Rosen; Henning Schulzrinne; Ted Hardie > >> >> Cc: ECRIT > >> >> Subject: RE: [Ecrit] phonebcp and testing location correctness > >> >> > >> >> I would think that video letter-by-letter automated spelling of = a > >> >> location would be rather tedious to watch. > >> >> > >> >> Could we send a JPG picture of a street map with a star where = the > >> >> location is? > >> >> Barbara > >> >> > >> >> -----Original Message----- > >> >> From: Brian Rosen [mailto:br@brianrosen.net] > >> >> Sent: Monday, April 23, 2007 11:10 AM > >> >> To: Stark, Barbara; 'Henning Schulzrinne'; 'Ted Hardie' > >> >> Cc: 'ECRIT' > >> >> Subject: RE: [Ecrit] phonebcp and testing location correctness > >> >> > >> >> You have the problem with the deaf community; a very vocal and > >> effective > >> >> lobbyist for something I consider a very reasonable point of = view: > they > >> >> want equivalent service. The specs require support for IM and = real > >> time > >> >> interactive text. If that is the media asserted on the test = INVITE, > >> >> they would expect the location coming back as text. > >> >> > >> >> Similarly, if they ask for video, they are expecting sign = language. > I > >> >> have a query into them about the practicality of text to sign > language. > >> >> I don't see why it won't work just fine. Presumably you = wouldn't > have > >> a > >> >> problem with that. > >> >> > >> >> Brian > >> >> > >> >> > -----Original Message----- > >> >> > From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > >> >> > Sent: Monday, April 23, 2007 10:41 AM > >> >> > To: Henning Schulzrinne; Ted Hardie > >> >> > Cc: ECRIT > >> >> > Subject: [Ecrit] phonebcp and testing location correctness > >> >> > > >> >> > Having thought about this over the weekend, I think I prefer > >> > > > recommending the voice-back of the de-referenced location, = over > > > >> > providing a PIDF-LO in the 200 OK. For all the reasons that > Henning > >> >> > mentioned. But I don't know how this would work if the = negotiated > >> >> > medium were something other than a voice codec. Does support = of > this > >> >> > function for non-voice media need to be recommended? > >> >> > Barbara > >> >> > > >> >> > -----Original Message----- > >> >> > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >> >> > Sent: Thursday, April 19, 2007 6:05 PM > >> >> > To: Ted Hardie > >> >> > Cc: 'ECRIT' > >> >> > Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: > >> >> > (Partial)LocationHiding Emergency Services Architecture > >> >> > > >> >> > The whole point is that the caller can, if he so desires, = verify > the > >> >> > location information. Incorrect location information is a = major > >> source > >> >> > >> >> > of mis-routes and false dispatches today (see the NYT article = I > sent > >> >> > around a few weeks ago). > >> >> > > >> >> > Since location information, even without hiding, can be added = by a > >> >> > proxy, this is the only way for the end system to determine = what > >> >> > information will be conveyed to the PSAP in all cases. In = existing > >> >> > system, finding this out is extremely tedious and burdensome = to > the > >> >> > PSAP, as you actually have to call 911 to see what address = your > >> >> > carrier has registered for you. You really don't want to = resolve > the > >> >> > "No, I'm not living at 123 Main Street, that's my billing = address" > >> >> > during an emergency call. > >> >> > > >> >> > I have no objection to returning this PSAP-seen information in > some > >> >> > other way, such as location-conveyance, but I expected to hear > >> screams > >> >> > >> >> > from the hide-location crowd in that case. Thus, I was trying = to > find > >> >> > a way that achieves most of the goals, while not stepping on > >> sensitive > >> >> > >> >> > toes. Since the existing test text includes the return of = location > >> >> > information, albeit in a format that is left unspecified = (which > >> should > >> >> > >> >> > be fixed), I'm happy with that. > >> >> > > >> >> > I also have no objection to making this an optional request in = the > >> >> > call, so that unattended test calls do not generate this, but = I'm > not > >> >> > convinced that the complexity is worth it. > >> >> > > >> >> > Thus, I believe that this mechanism adds significantly to the > overall > >> >> > reliability of the system and we should encourage that it be > >> provided, > >> >> > >> >> > whether as location-conveyance, audio or just a PIDF-LO = attachment > in > >> >> > the 200 OK. (This generally won't work well, given the = difficulty > >> real > >> >> > >> >> > phones have with multipart, but that's a different > >> >> > topic.) > >> >> > > >> >> > Henning > >> >> > > >> >> > On Apr 19, 2007, at 5:43 PM, Ted Hardie wrote: > >> >> > > >> >> > > At 4:46 PM -0400 4/19/07, Brian Rosen wrote: > >> >> > >> I dropped geopriv > >> >> > >> > >> >> > >> Please look at -phonebcp for the current test procedure. = This > >> >> > >> would add a step. > >> >> > > > >> >> > > So, the proposal is to add this to 9.1. The current version > says: > >> >> > > > >> >> > > >> >> > > >> >> > _______________________________________________ > >> >> > Ecrit mailing list > >> >> > Ecrit@ietf.org > >> >> > https://www1.ietf.org/mailman/listinfo/ecrit > >> >> > > >> >> > _______________________________________________ > >> >> > Ecrit mailing list > >> >> > Ecrit@ietf.org > >> >> > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 17:41:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg6Hd-0001Cs-R2; Mon, 23 Apr 2007 17:41:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg6Hc-0001CW-4t for ecrit@ietf.org; Mon, 23 Apr 2007 17:41:16 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg6Ha-00039u-Ti for ecrit@ietf.org; Mon, 23 Apr 2007 17:41:16 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3NLf5LF007386 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 23 Apr 2007 17:41:05 -0400 (EDT) In-Reply-To: <061001c785ee$44738300$640fa8c0@cis.neustar.com> References: <061001c785ee$44738300$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] phonebcp and testing location correctness Date: Mon, 23 Apr 2007 17:42:30 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: "'Stark, Barbara'" , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org In the case of video, plain video-rendered text is obviously the easiest. After all, CNN and Bloomberg have no problem producing video that contains text, nor does your local airport. (Indeed, titling hardware and software is a common staple in every video production facility.) MPEG does the same video compression as JPEG, so you get the same quality and artifacts. As Barbara (?) mentioned, a map would work nicely, although it may be hard to read on the usual CIF/QCIF video devices with heavy compression. Personally, I'd prefer having both as a matter of course, i.e., SIP location conveyance for PIDF-LO and a media-appropriate format (text- to-speech, etc.). From a user perspective, the latter is easier to work with for limited-UI and limited-capability devices, such as your typical Polyberg video-conferencing system or a voice-only terminal adapter ("ATA"), which isn't suddenly going to incorporate a full- fledged text-to-speech system just to read back addresses. As Brian notes, this sensible answer may not be feasible if the local carrier insists on "no machine-readable format" and the regulator or PSAP lets them get away with it. Henning On Apr 23, 2007, at 5:27 PM, Brian Rosen wrote: > Ted > > Although it may be possible for a videophone to render text, and > might be > acceptable to most deaf folks, do you think it is reasonable for a > voice > phone to render speech for a blind person? I get to needing text > to sign by > realizing I have to serve blind folks by the media of their choice > and back > myself into having to serve signing folks in the media of their > choice. > > Is it reasonable for any phone to render text in a variety of > languages for > this purpose? Do you think, realistically, it will happen? > > Given Barbara's concerns about revealing location, do you think > PSAPs will > choose to jeopardize local access network's efforts to supply > location by > revealing it in machine readable form? > > On the other hand, do you think it would be reasonable for a PSAP > (or some > contractor operating under authority of a PSAP or other agency) to > provide > text to speech and text to sign for this purpose? > > I fear we can write the specs to say send a PIDF back, it will not > result in > a useful service to users. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 17:41:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg6Hx-00028d-1P; Mon, 23 Apr 2007 17:41:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg6Hu-00020f-74 for ecrit@ietf.org; Mon, 23 Apr 2007 17:41:34 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg6Ht-0003B0-G0 for ecrit@ietf.org; Mon, 23 Apr 2007 17:41:34 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3NLfPUs026484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Apr 2007 14:41:26 -0700 Received: from [76.102.225.135] (carbuncle.qualcomm.com [129.46.226.38]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3NLfNoD000048; Mon, 23 Apr 2007 14:41:24 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <054b01c785e1$ae2fc310$640fa8c0@cis.neustar.com> Date: Mon, 23 Apr 2007 14:41:22 -0700 To: "Brian Rosen" , "'Andrew Newton'" From: Ted Hardie Subject: RE: [Ecrit] phonebcp and testing location correctness Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 Cc: "'Stark, Barbara'" , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 2:22 PM -0700 4/23/07, Ted Hardie wrote: > >Why do you think having the phone do this is unreasonable? There are >already phones that do short speech-to-text (e.g. the Samsung p207) >and that is much harder. Both the p207 and a890 also do speech-to-text. I meant they do text-to-speech. Sorry. Ted >I am assuming a specialized device or software set, I grant >you, but it seemed to me you were as well. Are you concerned that this >requirement would have to be met by all phones? Using a relay >seems much more likely to be the case for a special needs user and >a regular phone. > >>Sending the presentation on the wire as media in the form the SDP specifies >>is not unreasonable. Forcing the endpoint to generate media from machine >>readable information is unreasonable. > >This seems like a dogmatic assertion. It certainly isn't going to be unreasonable >to generate text from the pidf-lo, and that really is going to cover a lot of >cases where the phone has a screen. > >>Barbara doesn't want to send machine readable information. >> >>Brian > >If I understood Barbara, she wasn't going to fight on this point, as she >thought it was really going to be up to regulators rather than us. But >perhaps we should both speak for ourselves and let Barbara raise what >concerns she has. > > Ted > > > >> > -----Original Message----- >>> From: Andrew Newton [mailto:andy@hxr.us] >>> Sent: Monday, April 23, 2007 3:51 PM >>> To: Brian Rosen >>> Cc: 'Richard Barnes'; 'Stark, Barbara'; 'ECRIT' >>> Subject: Re: [Ecrit] phonebcp and testing location correctness >>> >>> Brian, >>> >>> I don't understand your response here. But I agree with Richard and >>> Ted. >>> >>> -andy >>> >>> On Apr 23, 2007, at 3:42 PM, Brian Rosen wrote: >>> >>> > You want a video endpoint that could be used by a deaf user to >>> > render video >>> > from text? >>> > >>> > You want every telephone that could be used by a blind user to >>> > render audio >>> > from text? >>> > >>> > This is a local service, and can reasonably use local conventions (and >>> > caller prefs). >>> > >>> > Brian >>> >> -----Original Message----- >>> >> From: Richard Barnes [mailto:rbarnes@bbn.com] >>> >> Sent: Monday, April 23, 2007 3:31 PM >>> >> To: Brian Rosen >>> >> Cc: 'Ted Hardie'; 'Stark, Barbara'; 'Henning Schulzrinne'; 'ECRIT' >>> >> Subject: Re: [Ecrit] phonebcp and testing location correctness > >> >> >>> >> To echo Ted, providing machine-readable location is the right >>> >> *on-the-wire* choice. Given a machine-readable LO, the user's >>> >> equipment >>> >> can render it as text, braille, a map, sign language, or interpretive >>> >> dance -- it's much more easily adaptable for users with different >>> >> abilities. >>> >> >>> >> If you force the presentation onto the wire, you only get the >>> >> presentation that the server sends you. >>> >> >>> >> --RB >>> >> >>> >> >>> >> Brian Rosen wrote: >>> >>> Ted >> > >>> >>> >>> You just haven't been in the room with the deaf folks much. >>> >>> >>> >>> They reasonably demand equal service. They get it, because they >>> >>> ask for >>> >>> reasonable accommodation. There are laws about that. We pay >>> >>> attention. >>> >>> It's the right thing to do. >>> >>> >>> >>> There is no technical difficulty in providing text to signing. I >>> >>> don't >>> >>> think an IETF spec has to say that, it just says: responds with a >>> >>> media >>> >>> stream in the form negotiated containing the location in a human >>> >>> understandable form (e.g. using text to speech). >>> >>> >>> >>> Agree that automated test is different from user interactive test. >>> >>> >>> >>> Brian >>> >>> >>> >>>> -----Original Message----- >>> >>>> From: Ted Hardie [mailto:hardie@qualcomm.com] >>> >>>> Sent: Monday, April 23, 2007 2:32 PM >>> >>>> To: Brian Rosen; 'Stark, Barbara'; 'Henning Schulzrinne' >>> >>>> Cc: 'ECRIT' >>> >>>> Subject: RE: [Ecrit] phonebcp and testing location correctness > >> >>>> >>> >>>> At 12:06 PM -0400 4/23/07, Brian Rosen wrote: >>> >>>>> Yeah, maybe. I don't know how well that works on MPEG encoded >>> >>>>> video. >>> >>>>> >>> >>>>> However, spelling is just about the only way to sign a street >>> >>>>> address; >>> >>>> there >>> >>>>> are no signs for some street names and many city names. >>> >>>>> Spelling is >>> >> one >>> >>>> of >>> >>>>> the most common signs everyone learns. Good CAs spell really >>> >>>>> fast. >>> >>>>> >>> >>>>> Brian >>> >>>> I think you are now seriously over-engineering a test system. >>> >>>> Saying >>> >> that >>> >>>> the test system can be expected to return the location in a form >>> >>>> which >>> >>>> may be rendered by the device at its UI discretion is the right >>> >>>> on-the- >>> >>>> wire >>> >>>> choice. Moving from that to one where you negotiate and then carry >>> >>>> the UI presentation itself is a distant second. Decided that >>> >> negotiation >>> >>>> must carry all possible representations is silly. For a test >>> >>>> system, > >> >>>> representations of the location in text are likely to be valid for >>> >> pretty >>> >>>> much any user and if you add in voice to text, you've covered >>> >>>> the deaf >>> >>>> and blind communities as well as the users with both of those >>> >> facilities. >>> >>>> Allowing an image with a map might be useful, but switching to >>> >>>> video >>> >>>> to watch someone finger-spell on a letter by letter basis is now >>> >> targeting >>> >>>> a very limited audience: those with very high end devices, no >>> >>>> ability >>> >>>> to read text, and who are guaranteed to be able to map the finger- >>> >> spelled >>> >>>> version to whatever sign is normally used in their language >>> >>>> community >>> >>>> for the area/street/etc. >>> >>>> >>> >>>> You do realize that you have whacked yourself into an >>> >> internationalization >>> >>>> problem as well, right? British Sign and American Sign Language >>> >>>> are >>> >> not >>> >>>> mutual >>> >>>> intelligible, and you're now going to have to negotiate sign >>> >>>> language >>> >>>> communities >>> >>>> of interest, even where you can presume a mutually intelligible >>> >> language >>> >>>> in text? >>> >>>> >>> >>>> Send the location object, and let the local rendering engine worry >>> >> about >>> >>>> it! It >>> >>>> will be configured for the user's needs. >>> >>>> >>> >>>> And, since I haven't said this for a day or two, it is now very, >>> >>>> very >>> >>>> clear to me >>> >>>> that the document needs to cover both an automated test system and >>> >>>> a separate user-invoked one. If our putative high-end-system-using >>> >>>> signer loses his dhcp lease and gets a new IP, having the system > >> >>>> start >>> >>>> signing at him is going way past the principle of least surprise. >>> >>>> >>> >>>> Ted >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>>>> -----Original Message----- >>> >>>>>> From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] >>> >>>>>> Sent: Monday, April 23, 2007 11:47 AM >>> >>>>>> To: Brian Rosen; Henning Schulzrinne; Ted Hardie >>> >>>>>> Cc: ECRIT >>> >>>>>> Subject: RE: [Ecrit] phonebcp and testing location correctness >>> >>>>>> >>> >>>>>> I would think that video letter-by-letter automated spelling of a >> > >>>>>> location would be rather tedious to watch. >>> >>>>>> >>> >>>>>> Could we send a JPG picture of a street map with a star where the >>> >>>>>> location is? >>> >>>>>> Barbara >>> >>>>>> >>> >>>>>> -----Original Message----- >>> >>>>>> From: Brian Rosen [mailto:br@brianrosen.net] >>> >>>>>> Sent: Monday, April 23, 2007 11:10 AM >>> >>>>>> To: Stark, Barbara; 'Henning Schulzrinne'; 'Ted Hardie' >>> >>>>>> Cc: 'ECRIT' >>> >>>>>> Subject: RE: [Ecrit] phonebcp and testing location correctness >>> >>>>>> >>> >>>>>> You have the problem with the deaf community; a very vocal and >>> >>>> effective >>> >>>>>> lobbyist for something I consider a very reasonable point of >>> >>>>>> view: >>> >> they >>> >>>>>> want equivalent service. The specs require support for IM and >>> >>>>>> real >>> >>>> time >>> >>>>>> interactive text. If that is the media asserted on the test >>> >>>>>> INVITE, > >> >>>>>> they would expect the location coming back as text. >>> >>>>>> >>> >>>>>> Similarly, if they ask for video, they are expecting sign >>> >>>>>> language. >>> >> I >>> >>>>>> have a query into them about the practicality of text to sign >>> >> language. >>> >>>>>> I don't see why it won't work just fine. Presumably you wouldn't >>> >> have >>> >>>> a >>> >>>>>> problem with that. >>> >>>>>> >>> >>>>>> Brian >>> >>>>>> >>> >>>>>>> -----Original Message----- >>> >>>>>>> From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] >>> >>>>>>> Sent: Monday, April 23, 2007 10:41 AM >>> >>>>>>> To: Henning Schulzrinne; Ted Hardie >>> >>>>>>> Cc: ECRIT >>> >>>>>>> Subject: [Ecrit] phonebcp and testing location correctness >>> >>>>>>> >>> >>>>>>> Having thought about this over the weekend, I think I prefer >>> >>>>>>> recommending the voice-back of the de-referenced location, over >>> >>>>>>> providing a PIDF-LO in the 200 OK. For all the reasons that >>> >>>>>>> Henning >>> >>>>>>> mentioned. But I don't know how this would work if the >>> >>>>>>> negotiated >>> >>>>>>> medium were something other than a voice codec. Does support >>> >>>>>>> of this >>> >>>>>>> function for non-voice media need to be recommended? >>> >>>>>>> Barbara >>> >>>>>>> >>> >>>>>>> -----Original Message----- >>> >>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>> >>>>>>> Sent: Thursday, April 19, 2007 6:05 PM >>> >>>>>>> To: Ted Hardie >>> >>>>>>> Cc: 'ECRIT' >>> >>>>>>> Subject: Re: [Ecrit] Re: [Geopriv] Soliciting Feedback: >>> >>>>>>> (Partial)LocationHiding Emergency Services Architecture >>> >>>>>>> >>> >>>>>>> The whole point is that the caller can, if he so desires, >>> >>>>>>> verify the >>> >>>>>>> location information. Incorrect location information is a major >>> >>>> source >>> >>>>>>> of mis-routes and false dispatches today (see the NYT article >>> >>>>>>> I sent >>> >>>>>>> around a few weeks ago). >>> >>>>>>> >>> >>>>>>> Since location information, even without hiding, can be added >>> >>>>>>> by a >>> >>>>>>> proxy, this is the only way for the end system to determine what >>> >>>>>>> information will be conveyed to the PSAP in all cases. In >>> >>>>>>> existing >>> >>>>>>> system, finding this out is extremely tedious and burdensome >>> >>>>>>> to the >>> >>>>>>> PSAP, as you actually have to call 911 to see what address your >>> >>>>>>> carrier has registered for you. You really don't want to >>> >>>>>>> resolve the >>> >>>>>>> "No, I'm not living at 123 Main Street, that's my billing >>> >>>>>>> address" >>> >>>>>>> during an emergency call. >>> >>>>>>> >>> >>>>>>> I have no objection to returning this PSAP-seen information >>> >>>>>>> in some >>> >>>>>>> other way, such as location-conveyance, but I expected to hear > >> >>>> screams >>> >>>>>>> from the hide-location crowd in that case. Thus, I was trying to >>> >> find >>> >>>>>>> a way that achieves most of the goals, while not stepping on >>> >>>> sensitive >>> >>>>>>> toes. Since the existing test text includes the return of >>> >>>>>>> location >>> >>>>>>> information, albeit in a format that is left unspecified (which >>> >>>> should >>> >>>>>>> be fixed), I'm happy with that. >>> >>>>>>> >>> >>>>>>> I also have no objection to making this an optional request >>> >>>>>>> in the >>> >>>>>>> call, so that unattended test calls do not generate this, but >>> >>>>>>> I'm >>> >> not >> > >>>>>>> convinced that the complexity is worth it. >>> >>>>>>> >>> >>>>>>> Thus, I believe that this mechanism adds significantly to the >>> >> overall >>> >>>>>>> reliability of the system and we should encourage that it be >>> >>>> provided, >>> >>>>>>> whether as location-conveyance, audio or just a PIDF-LO >>> >>>>>>> attachment >>> >> in >>> >>>>>>> the 200 OK. (This generally won't work well, given the >>> >>>>>>> difficulty >>> >>>> real >>> >>>>>>> phones have with multipart, but that's a different >>> >>>>>>> topic.) >>> >>>>>>> >>> >>>>>>> Henning >>> >>>>>>> >>> >>>>>>> On Apr 19, 2007, at 5:43 PM, Ted Hardie wrote: >>> >>>>>>> >>> >>>>>>>> At 4:46 PM -0400 4/19/07, Brian Rosen wrote: >>> >>>>>>>>> I dropped geopriv >>> >>>>>>>>> >>> >>>>>>>>> Please look at -phonebcp for the current test procedure. This > >> >>>>>>>>> would add a step. >>> >>>>>>>> So, the proposal is to add this to 9.1. The current version >>> >>>>>>>> says: >>> >>>>>>>> >>> >>>>>>> >>> >>>>>>> _______________________________________________ >>> >>>>>>> Ecrit mailing list >>> >>>>>>> Ecrit@ietf.org >>> >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>>>>>> >>> >>>>>>> _______________________________________________ >>> >>>>>>> Ecrit mailing list >>> >>>>>>> Ecrit@ietf.org >>> >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Ecrit mailing list >>> >>> Ecrit@ietf.org >>> >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >>> >>> >>> > >>> > >>> > _______________________________________________ >>> > Ecrit mailing list >>> > Ecrit@ietf.org >>> > https://www1.ietf.org/mailman/listinfo/ecrit >> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 17:45:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg6LM-0004FF-Eb; Mon, 23 Apr 2007 17:45:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg6LK-0004F8-OK for ecrit@ietf.org; Mon, 23 Apr 2007 17:45:06 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg6LK-0004zM-EF for ecrit@ietf.org; Mon, 23 Apr 2007 17:45:06 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1Hg6Jq-0005YR-SB; Mon, 23 Apr 2007 16:43:35 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Andrew Newton'" Subject: RE: [Ecrit] phonebcp and testing location correctness Date: Mon, 23 Apr 2007 17:45:02 -0400 Message-ID: <061201c785f0$a7a6cc00$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: AceF7VtedlepevOtSMyY7rfO4TDPzAAAaNJQ 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: "'Stark, Barbara'" , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Messages crossing in the Ether. > > Are you imagining it gets sent video of text, and turns that into video of > signing? That would be very hard. But the core object isn't video in > the proposal I've made; it is the PIDF-LO. Assuming the PIDF-LO can > be rendered into text, any text-to-sign system available to the UI > would work. No, I am imagining the PSAP sends video of finger spelling. I am not imagining a videophone could reasonably produce finger spelling from PIDF. I am imagining a server at a PSAP could do that, but see below. > > If there is no text-to-sign available, text alone would be available. You > were only talking about finger spelling, if I understood your original > proposal, > and using a large finger spelling font would cover at least that much. > If something better were available I would, of course, expect it to be > used. As per my previous message, I got to a requirement that the PSAP send finger spelling by working back from speech for a blind person. > > >Having a telephone render speech from text for a blind user is similarly > >unreasonable, and also reasonable from the PSAP side. > > Why do you think having the phone do this is unreasonable? There are > already phones that do short speech-to-text (e.g. the Samsung p207) > and that is much harder. Both the p207 and a890 also do speech-to-text. I am reasonably conversant in the technology to do text to speech for street addresses. It is not something that would fit in current phones, or even what is contemplated for next generation. There could be a hybrid system like that being developed for speech understanding in mobile devices, where the quality of the audio coming over the air is hard to do speech recognition on. In that environment, they do some of the front end work on the mobile, and then do the rest on the server, with a protocol in the middle. We have a work group doing the protocol (speechsc). I could imagine some kind of hybrid for text to speech, but that would be a lot of work to develop, and not be justified for this purpose (alone). > > I am assuming a specialized device or software set, I grant > you, but it seemed to me you were as well. Are you concerned that this > requirement would have to be met by all phones? Using a relay > seems much more likely to be the case for a special needs user and > a regular phone. Letting a relay do this did not occur to me, I'll admit, and that may help. I was thinking it would have to be done by all phones. > > >Sending the presentation on the wire as media in the form the SDP > specifies > >is not unreasonable. Forcing the endpoint to generate media from machine > >readable information is unreasonable. > > This seems like a dogmatic assertion. It certainly isn't going to be > unreasonable > to generate text from the pidf-lo, and that really is going to cover a lot > of > cases where the phone has a screen. Agree, if you get a PIDF-LO. > > >Barbara doesn't want to send machine readable information. > > If I understood Barbara, she wasn't going to fight on this point, as she > thought it was really going to be up to regulators rather than us. But > perhaps we should both speak for ourselves and let Barbara raise what > concerns she has. I'll do the same _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 23 18:29:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg72U-0007pp-4W; Mon, 23 Apr 2007 18:29:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg72T-0007pO-42 for ecrit@ietf.org; Mon, 23 Apr 2007 18:29:41 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg72S-0007vl-MY for ecrit@ietf.org; Mon, 23 Apr 2007 18:29:41 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3NMTXxr026604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Apr 2007 15:29:34 -0700 Received: from [76.102.225.135] (carbuncle.qualcomm.com [129.46.226.38]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3NMTU0d030974; Mon, 23 Apr 2007 15:29:31 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <061201c785f0$a7a6cc00$640fa8c0@cis.neustar.com> References: <061201c785f0$a7a6cc00$640fa8c0@cis.neustar.com> Date: Mon, 23 Apr 2007 15:29:29 -0700 To: "Brian Rosen" , "'Andrew Newton'" From: Ted Hardie Subject: RE: [Ecrit] phonebcp and testing location correctness Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: "'Stark, Barbara'" , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 5:45 PM -0400 4/23/07, Brian Rosen wrote: >Messages crossing in the Ether. Twice, at least. I'm sending this knowing it's probably crossing one of yours. > > >> Are you imagining it gets sent video of text, and turns that into video of >> signing? That would be very hard. But the core object isn't video in >> the proposal I've made; it is the PIDF-LO. Assuming the PIDF-LO can >> be rendered into text, any text-to-sign system available to the UI >> would work. >No, I am imagining the PSAP sends video of finger spelling. I am not >imagining a videophone could reasonably produce finger spelling from PIDF. >I am imagining a server at a PSAP could do that, but see below. > >> >> If there is no text-to-sign available, text alone would be available. You >> were only talking about finger spelling, if I understood your original >> proposal, >> and using a large finger spelling font would cover at least that much. >> If something better were available I would, of course, expect it to be >> used. >As per my previous message, I got to a requirement that the PSAP send finger >spelling by working back from speech for a blind person. So, the base requirement is "Return the location so that the user can confirm it". That's underneath all of this, and we're working out how, for a variety of users, right? > > >> >Having a telephone render speech from text for a blind user is similarly >> >unreasonable, and also reasonable from the PSAP side. >> >> Why do you think having the phone do this is unreasonable? There are >> already phones that do short speech-to-text (e.g. the Samsung p207) >> and that is much harder. Both the p207 and a890 also do speech-to-text. >I am reasonably conversant in the technology to do text to speech for street >addresses. It is not something that would fit in current phones, or even >what is contemplated for next generation. Is there something about addresses that is particularly bad about this? At least Samsung, Nokia, and Pantech have phones that do speech to text in multiple languages (English, Korean, Russian, and Mandarin, if I read the press reports right). This isn't next generation for mobiles; these are shipping phones (The Nokia Series 60 and the Pantech PG-6200, PG-8000, and PG-3700). There is even 50k free download of a VoiceXML SDK from Voicent. These aren't low end phones (or targeted at low-end phones), but it also doesn't seem to be the case that text-to-speech is generally seen out of the ballpark here. >There could be a hybrid system >like that being developed for speech understanding in mobile devices, where >the quality of the audio coming over the air is hard to do speech >recognition on. Why is speech recognition needed? The phone gets an object, translates it from XML to localized text, and reads it out. > In that environment, they do some of the front end work on >the mobile, and then do the rest on the server, with a protocol in the >middle. We have a work group doing the protocol (speechsc). I could >imagine some kind of hybrid for text to speech, but that would be a lot of >work to develop, and not be justified for this purpose (alone). > >> >> I am assuming a specialized device or software set, I grant >> you, but it seemed to me you were as well. Are you concerned that this >> requirement would have to be met by all phones? Using a relay >> seems much more likely to be the case for a special needs user and >> a regular phone. >Letting a relay do this did not occur to me, I'll admit, and that may help. >I was thinking it would have to be done by all phones. Ah, I was assuming relays where the phones were not designed with UIs for their user communities. I believe this is reasonable for a test service that is user-initiated. It would again make automated testing a distinct case, as the idea of the phone calling up the relay...just not okay. > > >> >Sending the presentation on the wire as media in the form the SDP >> specifies >> >is not unreasonable. Forcing the endpoint to generate media from machine >> >readable information is unreasonable. >> >> This seems like a dogmatic assertion. It certainly isn't going to be >> unreasonable >> to generate text from the pidf-lo, and that really is going to cover a lot >> of >> cases where the phone has a screen. >Agree, if you get a PIDF-LO. If we agree on this point, then the architecturally correct way forward is probably pretty obvious. > > >Barbara doesn't want to send machine readable information. >> >> If I understood Barbara, she wasn't going to fight on this point, as she >> thought it was really going to be up to regulators rather than us. But >> perhaps we should both speak for ourselves and let Barbara raise what >> concerns she has. >I'll do the same Barbara, as you marshall your comments, can you think about relays in addition to the methods described above? thanks, Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 24 03:54:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgFrL-0004aD-Ri; Tue, 24 Apr 2007 03:54:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgFrK-0004W2-Am for ecrit@ietf.org; Tue, 24 Apr 2007 03:54:46 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgFrH-0002i2-Tu for ecrit@ietf.org; Tue, 24 Apr 2007 03:54:46 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTPś id l3O7sCif025008Tue, 24 Apr 2007 07:54:12 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1HgFqb-000GU1-00; Tue, 24 Apr 2007 08:54:01 +0100 Date: Tue, 24 Apr 2007 08:54:01 +0100 From: "Clive D.W. Feather" To: "Tschofenig, Hannes" Subject: Re: [Ecrit] Hiding (partial) locations Message-ID: <20070424075401.GI58320@finch-staff-1.thus.net> References: <20070416092329.GE49101@finch-staff-1.thus.net> <8F6CBC7005099442AECDB784C9E9D7E701A289BC@MCHP7R6A.ww002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8F6CBC7005099442AECDB784C9E9D7E701A289BC@MCHP7R6A.ww002.siemens.net> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Tschofenig, Hannes said: > Are you saying that you think that the idea of providing enough information for routing by the ISP is good or do you think that the ISP will not even want to provide this information? I'm not saying either. I'm saying that if: >>> This level of location information >>> is also more or less what you can get for free already from services >>> such as http://www.ip2location.com/free.asp or MaxMind. is meant to represent state of the art, then this whole thing is dead in the water: one of them couldn't even find the right *COUNTRY*. The test addresses I used were not special or "tricks"; they should have been easy. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 24 07:16:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgJ0C-0006Lu-V8; Tue, 24 Apr 2007 07:16:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgJ0B-0006LU-Fm for ecrit@ietf.org; Tue, 24 Apr 2007 07:16:07 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgJ08-00048a-UX for ecrit@ietf.org; Tue, 24 Apr 2007 07:16:06 -0400 Received: from [10.0.1.110] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 24 Apr 2007 07:16:04 -0400 id 01588152.462DE6F4.00002F56 In-Reply-To: <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Consensus Call: Precise Location Information not available to End Host Date: Tue, 24 Apr 2007 07:16:00 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 23, 2007, at 5:10 PM, Henning Schulzrinne wrote: > In short, my proposal is simple: > > - Remove the restriction that the profile used for sending data is > the same as that used for processing the . This > avoids having thje client guess what profile a (new) info> corresponds to. > > - The profile declaration thus only applies to the allowable > responses. > > - A server can continue to indicate the mapping point format it > supports. This then leaves the server to guess about the type of location information. I don't understand your reasoning for believing servers should not need to know the profile, but that clients do. If one guesses at the type of information it is receiving, then they both can. And it doesn't sound too helpful to do at either end. And I'm confused about the relevance of this to the current discussion. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 24 07:32:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgJGD-0004QF-6w; Tue, 24 Apr 2007 07:32:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgJGB-0004ON-U3 for ecrit@ietf.org; Tue, 24 Apr 2007 07:32:39 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgJGA-0001kJ-Ik for ecrit@ietf.org; Tue, 24 Apr 2007 07:32:39 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HgJEY-0003NZ-Ea; Tue, 24 Apr 2007 06:30:58 -0500 From: "Brian Rosen" To: "'Clive D.W. Feather'" , "'Tschofenig, Hannes'" Subject: RE: [Ecrit] Hiding (partial) locations Date: Tue, 24 Apr 2007 07:32:34 -0400 Message-ID: <070501c78664$42c3d390$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20070424075401.GI58320@finch-staff-1.thus.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: AceGRZyC67/HQj+dSvu9j0xzq7z5wwAHe2cQ 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Right. No one responded to the original of that because we understand the issues with those kinds of services. VPNs, and the variability of carrier network design make such mechanisms have high error rate; certainly no where near good enough for any kind of emergency services. We've discussed them before. They are often accurate to roughly city level for residential deployments without VPNs obscuring them, but "roughly" and "city level" and "without" make them useless for any practical purpose. Any multi-site enterprise typically reports all sites as being the HQ site. Brian > -----Original Message----- > From: Clive D.W. Feather [mailto:clive@demon.net] > Sent: Tuesday, April 24, 2007 3:54 AM > To: Tschofenig, Hannes > Cc: ECRIT > Subject: Re: [Ecrit] Hiding (partial) locations > > Tschofenig, Hannes said: > > Are you saying that you think that the idea of providing enough > information for routing by the ISP is good or do you think that the ISP > will not even want to provide this information? > > I'm not saying either. I'm saying that if: > > >>> This level of location information > >>> is also more or less what you can get for free already from services > >>> such as http://www.ip2location.com/free.asp or MaxMind. > > is meant to represent state of the art, then this whole thing is dead in > the water: one of them couldn't even find the right *COUNTRY*. > > The test addresses I used were not special or "tricks"; they should have > been easy. > > -- > Clive D.W. Feather | Work: | Tel: +44 20 8495 > 6138 > Internet Expert | Home: | Fax: +44 870 051 > 9937 > Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 > THUS plc | | > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 24 09:14:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgKqG-00065S-Ro; Tue, 24 Apr 2007 09:14:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgKqF-00061d-2T for ecrit@ietf.org; Tue, 24 Apr 2007 09:13:59 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgKqE-00039L-I9 for ecrit@ietf.org; Tue, 24 Apr 2007 09:13:59 -0400 Received: from ([139.76.131.83]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.20771750; Tue, 24 Apr 2007 09:13:38 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 24 Apr 2007 09:13:35 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 24 Apr 2007 09:13:35 -0400 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 MimeOLE V6.00.3790.2826 Subject: RE: [Ecrit] phonebcp and testing location correctness Date: Tue, 24 Apr 2007 09:13:32 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA03B0FD22@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] phonebcp and testing location correctness thread-index: AceF9uVlZ08+tOEER0eNZtyPEjYrvAAd5GUA References: <061201c785f0$a7a6cc00$640fa8c0@cis.neustar.com> From: "Stark, Barbara" To: "Ted Hardie" , "Brian Rosen" , "Andrew Newton" X-OriginalArrivalTime: 24 Apr 2007 13:13:35.0377 (UTC) FILETIME=[5D57B010:01C78672] X-Spam-Score: 0.1 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I thought Brian was doing a great job expressing my views... Oh well. I'm thinking that it does makes sense for the test capability described in phonebcp to include returning a PIDF-LO, since that really is the most flexible and easiest format. But, since I think location-hiding access providers won't like this to be used in areas they serve, I think it would also be good to describe returning the de-referenced location in media, as well. While this isn't the "best" way to do it, it's better than an all-or-nothing solution, where either a PIDF-LO is returned, or people get no location confirmation capability at all. I wasn't going to fight it in phonebcp, because I figured regulators could be convinced to use the "nothing" approach in exchange for access providers building the ability to deliver location.=20 The existence of relays to support in translation is an interesting topic, but I don't think it has a real impact on the possible options for how or whether a PSAP returns a dereferenced location. I don't think the PSAP can assume a relay, unless we want to get into having the PSAP authenticate where test requests come from. And I'm pretty sure that no-one wants that! Barbara -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com]=20 Sent: Monday, April 23, 2007 6:29 PM To: Brian Rosen; 'Andrew Newton' Cc: Stark, Barbara; 'ECRIT' Subject: RE: [Ecrit] phonebcp and testing location correctness At 5:45 PM -0400 4/23/07, Brian Rosen wrote: >Messages crossing in the Ether. Twice, at least. I'm sending this knowing it's probably crossing one of yours. > > >> Are you imagining it gets sent video of text, and turns that into video of >> signing? That would be very hard. But the core object isn't video in >> the proposal I've made; it is the PIDF-LO. Assuming the PIDF-LO can=20 >> be rendered into text, any text-to-sign system available to the UI=20 >> would work. >No, I am imagining the PSAP sends video of finger spelling. I am not=20 >imagining a videophone could reasonably produce finger spelling from PIDF. >I am imagining a server at a PSAP could do that, but see below. > >> >> If there is no text-to-sign available, text alone would be available. >> You were only talking about finger spelling, if I understood your=20 >> original proposal, and using a large finger spelling font would cover >> at least that much. >> If something better were available I would, of course, expect it to=20 >> be used. >As per my previous message, I got to a requirement that the PSAP send=20 >finger spelling by working back from speech for a blind person. So, the base requirement is "Return the location so that the user can confirm it". That's underneath all of this, and we're working out how, for a variety of users, right? > > >> >Having a telephone render speech from text for a blind user is=20 >> >similarly unreasonable, and also reasonable from the PSAP side. >> >> Why do you think having the phone do this is unreasonable? There are >> already phones that do short speech-to-text (e.g. the Samsung p207)=20 >> and that is much harder. Both the p207 and a890 also do speech-to-text. >I am reasonably conversant in the technology to do text to speech for=20 >street addresses. It is not something that would fit in current=20 >phones, or even what is contemplated for next generation. Is there something about addresses that is particularly bad about this? At least Samsung, Nokia, and Pantech have phones that do speech to text in multiple languages (English, Korean, Russian, and Mandarin, if I read the press reports right). This isn't next generation for mobiles; these are shipping phones (The Nokia Series 60 and the Pantech PG-6200, PG-8000, and PG-3700). There is even 50k free download of a VoiceXML SDK from Voicent. These aren't low end phones (or targeted at low-end phones), but it also doesn't seem to be the case that text-to-speech is generally seen out of the ballpark here. >There could be a hybrid system >like that being developed for speech understanding in mobile devices,=20 >where the quality of the audio coming over the air is hard to do speech >recognition on. Why is speech recognition needed? The phone gets an object, translates it from XML to localized text, and reads it out. > In that environment, they do some of the front end work on the mobile, >and then do the rest on the server, with a protocol in the middle. We=20 >have a work group doing the protocol (speechsc). I could imagine some=20 >kind of hybrid for text to speech, but that would be a lot of work to=20 >develop, and not be justified for this purpose (alone). > >> >> I am assuming a specialized device or software set, I grant you, but=20 >> it seemed to me you were as well. Are you concerned that this=20 >> requirement would have to be met by all phones? Using a relay seems=20 >> much more likely to be the case for a special needs user and a=20 >> regular phone. >Letting a relay do this did not occur to me, I'll admit, and that may help. >I was thinking it would have to be done by all phones. Ah, I was assuming relays where the phones were not designed with UIs for their user communities. I believe this is reasonable for a test service that is user-initiated. It would again make automated testing a distinct case, as the idea of the phone calling up the relay...just not okay. > > >> >Sending the presentation on the wire as media in the form the SDP >> specifies >> >is not unreasonable. Forcing the endpoint to generate media from=20 >> >machine readable information is unreasonable. >> >> This seems like a dogmatic assertion. It certainly isn't going to be >> unreasonable to generate text from the pidf-lo, and that really is=20 >> going to cover a lot of cases where the phone has a screen. >Agree, if you get a PIDF-LO. If we agree on this point, then the architecturally correct way forward is probably pretty obvious. > > >Barbara doesn't want to send machine readable information. >> >> If I understood Barbara, she wasn't going to fight on this point, as=20 >> she thought it was really going to be up to regulators rather than=20 >> us. But perhaps we should both speak for ourselves and let Barbara=20 >> raise what concerns she has. >I'll do the same Barbara, as you marshall your comments, can you think about relays in addition to the methods described above? thanks, Ted ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA622 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 24 12:07:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgNY4-0007RX-2K; Tue, 24 Apr 2007 12:07:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgNY2-0007RR-T6 for ecrit@ietf.org; Tue, 24 Apr 2007 12:07:22 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgNY1-0007pk-JQ for ecrit@ietf.org; Tue, 24 Apr 2007 12:07:22 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3OG7FTX006958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Apr 2007 12:07:15 -0400 (EDT) In-Reply-To: <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles (was: Consensus Call) Date: Tue, 24 Apr 2007 12:08:42 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I changed the subject line, since we've strayed a bit from the original topic, even though this is still motivated by the topic. Let me try again to work through the steps: - We currently use profiles for both sending and receiving location, namely for when requesting a mapping and in the when such a mapping is being returned. The discussion is only about the former, not about the latter. - In "regular" presence, there is no profile information. In other words, if I use RFC 4119, the receiver of presence information has to recognize the namespace indicators and the XML tags, as in all other XML applications. This has not generated any particular controversy, as far as I can tell. Indeed, http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo- profile-06 continues that tradition. There is no profile information, just, say, or . The receiver of such information, e.g., in a NOTIFY, would simply recognize or and parse it accordingly. - We agree that for the , the profile information only provides a hint. The receiver (here, the LoST server) still has to recognize the XML tags and has to be prepared to deal with XML that doesn't actually follow the profile. - The XML is self-sufficient. In other words, once you have the GML tag, the profile doesn't provide any additional information. - We all agree, I think, that we should avoid a proliferation of data formats, so that the profile in draft-ietf-geopriv-pdif-lo-profile-06 and similar efforts should guide implementors of PIDF-LO-using systems, but this affects producers of LOs and their final consumers. LoST clients just copy them. - The core problem is that the profile notion makes it impossible to upgrade any LCP without upgrading all clients since a client (LCP querier and LoST seeker) would have to recognize the format to insert the right profile information, even though the client doesn't touch the and simply copies it from LCP to LoST verbatim. As far as I know, HELD provides no way to request a specific LoST profile, either. Thus, I believe that using the location-profile for LoST queries, in , serves no purpose and simply makes system upgrades hard or impossible. Henning On Apr 24, 2007, at 7:16 AM, Andrew Newton wrote: > > On Apr 23, 2007, at 5:10 PM, Henning Schulzrinne wrote: > >> In short, my proposal is simple: >> >> - Remove the restriction that the profile used for sending data is >> the same as that used for processing the . This >> avoids having thje client guess what profile a (new) > info> corresponds to. >> >> - The profile declaration thus only applies to the allowable >> responses. >> >> - A server can continue to indicate the mapping point format it >> supports. > > This then leaves the server to guess about the type of location > information. I don't understand your reasoning for believing > servers should not need to know the profile, but that clients do. > If one guesses at the type of information it is receiving, then > they both can. And it doesn't sound too helpful to I'm not sure where you got the notion from the above that "servers should not need to know the profile, but clients do". It's the opposite. > do at either end. And I'm confused about the relevance of this to > the current discussion. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 24 14:07:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgPQH-0004Um-1F; Tue, 24 Apr 2007 14:07:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgPQF-0004US-9V for ecrit@ietf.org; Tue, 24 Apr 2007 14:07:27 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgPQB-00008G-Na for ecrit@ietf.org; Tue, 24 Apr 2007 14:07:27 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 24 Apr 2007 14:07:23 -0400 id 0158813F.462E475B.00000B1C In-Reply-To: <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles (was: Consensus Call) Date: Tue, 24 Apr 2007 14:07:22 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 24, 2007, at 12:08 PM, Henning Schulzrinne wrote: > - The core problem is that the profile notion makes it impossible > to upgrade any LCP without upgrading all clients since a client > (LCP querier and LoST seeker) would have to recognize the info> format to insert the right profile information, even though > the client doesn't touch the and simply copies it > from LCP to LoST verbatim. As far as I know, HELD provides no way > to request a specific LoST profile, either. Actually, this introduces more problems as the server has to guess at the meaning of the data. Take for instance a future location profile based on RFC 3825... and you find this in draft-ietf-geopriv-lo- profile-06: -43.5723 153.21760 2 Just looking at the GML XML namespace is not enough to know that the format is 3825. Also, there's the problem I brought up yesterday. If a server sees this input, where a polygon has a whole in it: ... ... Now, is the server to find the centroid of the polygon or is it suppose to look for an exact match of the polygon? I do understand your concern. You don't want the clients to have to know much of anything; they should just do a copy and paste. Well, with DHCP they have to be smarter than that just because of the difference in protocols (binary vs. XML). But an XML based LCP can almost be that simple (almost, XML namespaces do require normalization). And I agree, that would be good. However, the way to approach this is to subtly change the way we do profile identifiers. Essentially, if we move them out of the element and into their own child element, this bit of data can be shuttled around with the location information without any specific knowledge of the client. So, a location hiding LIS queries LoST for the PSAPs polygon. It gets back: ... The LIS has a simple algorithm; copy all elements inside the element. It then hands the following information over to the client: ... The client information gets passed along, eventually being re-input into a LoST server (the VSP verification step) where the intention of this data is known. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 24 15:52:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgR4B-000103-Nr; Tue, 24 Apr 2007 15:52:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgR4A-0000zq-P3 for ecrit@ietf.org; Tue, 24 Apr 2007 15:52:46 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgR48-0004mL-GB for ecrit@ietf.org; Tue, 24 Apr 2007 15:52:46 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HgR48-0001LW-3J; Tue, 24 Apr 2007 15:52:44 -0400 Received: from [127.0.0.1] (dhcp89-073-068.bbn.com [128.89.73.68]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l3OJqhw18058; Tue, 24 Apr 2007 15:52:43 -0400 (EDT) Message-ID: <462E6009.5000804@bbn.com> Date: Tue, 24 Apr 2007 15:52:41 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Henning Schulzrinne , ECRIT Subject: Re: [Ecrit] An alternative proposal References: <4628FD3E.5080009@bbn.com> <730D0441-E19F-4092-BDEF-4905947C0AC3@cs.columbia.edu> <462CEC68.7060805@bbn.com> <5AC252CE-2EE7-4338-B473-1DBDEACF4ECD@cs.columbia.edu> In-Reply-To: <5AC252CE-2EE7-4338-B473-1DBDEACF4ECD@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org ~trimmed to contain message length~ > Concrete proposals would be most helpful. The syntax is not the problem > (we can all whip up some XML to do this), but how global distribution > would work. It is, as noted, yet another protocol that needs to be > implemented, secured and deployed, for no gain. How about this: 1. Whip up some XML to do the queries as part of LoST 2. Create a set of FGs to store PSAP URIs (possibly with their coverage areas). This set can be large and distributed for fault-tolerance. 3. These FGs peer with as many tree roots as possible; each tree sends its PSAP URIs (+coverage) to the FG, and the FGs share with each other. Note that this doesn't have to be done using LoST -- it could be an extension to LoST-sync, or just rsync on a flat list of URIs. 4. Any "Reverse LoST" queries go to one of these FGs > The normal query volume is relatively low, but it's another vector for > DOS attacks. (Send calls to random URLs claiming to be emergency calls, > every single one of which generates a query to the FG.) The total query volume will probably be significantly smaller than the volume of regular LoST queries, since endpoints query LoST peridically, while VSPs would only query at emergency call time. In any case, you can address this by clustering FGs. > I'm confused. It's not revealed to everybody, just to everybody who has > access to the LbyR. If the call is protected by TLS, that would only be > the signaling entities. If not, it is only the entities that can > physically intercept the call. This is only true if the references are in fact cryptographically random. This would have to be specified. You also have to address the issue of people accessing the reference after the fact. I thought that one requirement was that even the PSAP shouldn't have access to the callers location forever, but it seems like this proposal would give it to him, at least for the lifetime of the reference. So even though you adopted LbyR so you wouldn't have to constantly push LbyV to the client, you end up having to push expiring, cryptographically random references. > If they are not, it doesn't really matter, > either. Say, an ISP returns > > http://lis.isp.net/psap1 > http://lis.isp.net/psap2 If you're going to do that, then you might as well just hand out LbyV with coarse resolution. The point of LbyR is to provide a mechanism that (1) gives the user's current location, and (2) has access controls. --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 24 21:05:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgVwE-00088g-21; Tue, 24 Apr 2007 21:04:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgVwC-00088W-IV for ecrit@ietf.org; Tue, 24 Apr 2007 21:04:52 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgVwB-0006gS-Bi for ecrit@ietf.org; Tue, 24 Apr 2007 21:04:52 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3P14jbo020467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Apr 2007 21:04:46 -0400 (EDT) In-Reply-To: <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4991CDE0-BA87-42E5-BCEA-2A8ED6324FA1@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Tue, 24 Apr 2007 21:04:43 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org There seem to be several different topics here, so I'll split my response. On Apr 24, 2007, at 2:07 PM, Andrew Newton wrote: > > On Apr 24, 2007, at 12:08 PM, Henning Schulzrinne wrote: >> - The core problem is that the profile notion makes it impossible >> to upgrade any LCP without upgrading all clients since a client >> (LCP querier and LoST seeker) would have to recognize the >> format to insert the right profile information, >> even though the client doesn't touch the and >> simply copies it from LCP to LoST verbatim. As far as I know, >> HELD provides no way to request a specific LoST profile, either. > > Actually, this introduces more problems as the server has to guess > at the meaning of the data. Take for instance a future location > profile based on RFC 3825... and you find this in draft-ietf- > geopriv-lo-profile-06: > > -43.5723 153.21760 > > > 2 > > > Just looking at the GML XML namespace is not enough to know that > the format is 3825. The receiver doesn't care that the format is derived from RFC 3825. The namespace declaration (which you elided in your example) xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" identifies the schema, so the receiver can easily tell whether it should ignore or handle the XML tags or not (or decide that it needs to give up instead). Thus, it can tell what meaning FLR has and whether it knows anything about that particular XML tag. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 24 21:22:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgWD8-0004wC-Bc; Tue, 24 Apr 2007 21:22:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgWD7-0004w6-5z for ecrit@ietf.org; Tue, 24 Apr 2007 21:22:21 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgWD6-0001fg-0D for ecrit@ietf.org; Tue, 24 Apr 2007 21:22:21 -0400 Received: from [10.0.1.110] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 24 Apr 2007 21:22:11 -0400 id 01588416.462EAD43.0000618A In-Reply-To: <4991CDE0-BA87-42E5-BCEA-2A8ED6324FA1@cs.columbia.edu> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <4991CDE0-BA87-42E5-BCEA-2A8ED6324FA1@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Tue, 24 Apr 2007 21:22:06 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 24, 2007, at 9:04 PM, Henning Schulzrinne wrote: > The receiver doesn't care that the format is derived from RFC 3825. > The namespace declaration (which you elided in your example) > > xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" > > identifies the schema, so the receiver can easily tell whether it > should ignore or handle the XML tags or not (or decide that it > needs to give up instead). Thus, it can tell what meaning FLR has > and whether it knows anything about that particular XML tag. No. The way you are describing it, it must recognize both the GML and the civicAddr namespaces. And a 3825 based location profile could easily use urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc for the namespace identifier. It would be better if the sender let the receiver in on what type of location it is sending. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 24 21:30:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgWKy-0004GO-H7; Tue, 24 Apr 2007 21:30:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgWKx-0004GI-Tp for ecrit@ietf.org; Tue, 24 Apr 2007 21:30:27 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgWKw-0005Sq-Mb for ecrit@ietf.org; Tue, 24 Apr 2007 21:30:27 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3P1UKdY000044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Apr 2007 21:30:25 -0400 (EDT) In-Reply-To: <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles (was: Consensus Call) - hole Date: Tue, 24 Apr 2007 21:30:19 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > Also, there's the problem I brought up yesterday. If a server sees > this input, where a polygon has a whole in it: > > > > > ... > > > > > ... > > > > > Now, is the server to find the centroid of the polygon or is it > suppose to look for an exact match of the polygon? > That seems like a completely different question compared to the profile issue, or at least I'm missing the connection. This is indeed a real problem, but only if the location of the querier itself has a hole. There is no problem for the case where the service boundary has one or more holes. The location-with-hole case only occurs in the location hiding case, as far as I can tell, and is relatively uncommon even there. There are two solutions, neither of which is totally satisfying. (1) Exact match, as you indicate. In other words, a LoST server first tries to find an exact match for the boundary. For the location- hiding case, this will always work. Advantage: The client doesn't have to know. Disadvantage: LoST servers need a special case. (2) Transformation in LIS: The carrier that wants to hide a location creates a convex location region that has no holes and includes the location of the UA. A very simple way to do this is to return a triangle (square, circle, ...) that includes the caller's location (not in the center) and whose centroid falls into the PSAP service area. This has to be done only once (unless the PSAP boundary changes), so the computational burden is trivial. Advantage: No special case in LoST servers. Disadvantage: Requires some special geometric treatment for special cases. I have some preference for (2), since it's a bit cleaner and it's conceptually no different from a wireless location system with a very imprecise location technology, such as cell-face only. It requires no standardization as such, as long as we standardize the centroid behavior. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 24 22:12:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgWzP-0007Bu-Q7; Tue, 24 Apr 2007 22:12:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgWzN-0007Bk-NR for ecrit@ietf.org; Tue, 24 Apr 2007 22:12:13 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgWzM-0004wt-H9 for ecrit@ietf.org; Tue, 24 Apr 2007 22:12:13 -0400 Received: from [10.0.1.110] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 24 Apr 2007 22:12:11 -0400 id 01588418.462EB8FB.00006D39 In-Reply-To: References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <93297558-09D6-472E-8F04-3BA6734C1833@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles (was: Consensus Call) - hole Date: Tue, 24 Apr 2007 22:12:10 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 24, 2007, at 9:30 PM, Henning Schulzrinne wrote: > (2) Transformation in LIS: The carrier that wants to hide a > location creates a convex location region that has no holes and > includes the location of the UA. A very simple way to do this is to > return a triangle (square, circle, ...) that includes the caller's > location (not in the center) and whose centroid falls into the PSAP > service area. This has to be done only once (unless the PSAP > boundary changes), so the computational burden is trivial. Well, that's certainly a creative approach, and complex. And it screws with the caching and periodic requery at the end point. The created shape must fall entirely within service boundary. If any part of it overlaps the service boundary, then there is the potential for a misrouted call. If the created shape falls within the service boundary, it will be less than the area of the service boundary and cause needless requerys by the endpoints, which will believe they may have crossed from one service boundary to another when, in fact, they haven't. That seems like a lot of extra burden on the system, when we could just add some meta-data to the service boundary and allow LoST servers to do exact matches. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 24 22:33:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgXJT-0005M1-B9; Tue, 24 Apr 2007 22:32:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgXJS-0005Lw-BQ for ecrit@ietf.org; Tue, 24 Apr 2007 22:32:58 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgXJR-0008Re-4E for ecrit@ietf.org; Tue, 24 Apr 2007 22:32:58 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3P2WnbD008559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Apr 2007 22:32:54 -0400 (EDT) In-Reply-To: <93297558-09D6-472E-8F04-3BA6734C1833@hxr.us> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <93297558-09D6-472E-8F04-3BA6734C1833@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <146B26C8-0988-45B6-95D1-EB4266DEE300@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles (was: Consensus Call) - hole Date: Tue, 24 Apr 2007 22:32:44 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 24, 2007, at 10:12 PM, Andrew Newton wrote: > > On Apr 24, 2007, at 9:30 PM, Henning Schulzrinne wrote: >> (2) Transformation in LIS: The carrier that wants to hide a >> location creates a convex location region that has no holes and >> includes the location of the UA. A very simple way to do this is >> to return a triangle (square, circle, ...) that includes the >> caller's location (not in the center) and whose centroid falls >> into the PSAP service area. This has to be done only once (unless >> the PSAP boundary changes), so the computational burden is trivial. > > Well, that's certainly a creative approach, and complex. And it > screws with the caching and periodic requery at the end point. The > created shape must fall entirely within service boundary. If any > part of it overlaps the service Not really; caching works just as before. The created shape does *not* have to fall completely within the service boundary, given the centroid computation that determines matching. As per the previous discussion, any non-point shape will need to be transformed to a point (centroid) by the LoST server. > boundary, then there is the potential for a misrouted call. If the > created shape falls within the service boundary, it will be less > than the area of the service boundary and cause needless requerys > by the endpoints, which will believe they may have crossed from one > service boundary to another when, in fact, they haven't. > > That seems like a lot of extra burden on the system, when we could > just add some meta-data to the service boundary and allow LoST > servers to do exact matches. This would not be the service boundary, but it would have to be the element, so it would have to be a PIDF-LO extension, which seems rather strange. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 24 22:39:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgXPj-0000ZD-84; Tue, 24 Apr 2007 22:39:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgXPh-0000Z8-PB for ecrit@ietf.org; Tue, 24 Apr 2007 22:39:25 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgXPg-0002Ic-HZ for ecrit@ietf.org; Tue, 24 Apr 2007 22:39:25 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3P2dFlI010184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Apr 2007 22:39:21 -0400 (EDT) In-Reply-To: References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <4991CDE0-BA87-42E5-BCEA-2A8ED6324FA1@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Tue, 24 Apr 2007 22:39:12 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I don't understand your comment. The namespace better identify completely the list of XML tags that are permissible, as something is terribly wrong with the XML validity otherwise. I also don't see why a purely civic address would need a GML name space, but that's a separate issue. On Apr 24, 2007, at 9:22 PM, Andrew Newton wrote: > > On Apr 24, 2007, at 9:04 PM, Henning Schulzrinne wrote: >> The receiver doesn't care that the format is derived from RFC >> 3825. The namespace declaration (which you elided in your example) >> >> xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" >> >> identifies the schema, so the receiver can easily tell whether it >> should ignore or handle the XML tags or not (or decide that it >> needs to give up instead). Thus, it can tell what meaning FLR has >> and whether it knows anything about that particular XML tag. > > No. The way you are describing it, it must recognize both the GML > and the civicAddr namespaces. And a 3825 based location profile > could easily use urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc for > the namespace identifier. It would be better if the sender let the > receiver in on what type of location it is sending. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 24 22:43:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgXTx-00067j-VL; Tue, 24 Apr 2007 22:43:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgXTx-00067e-09 for ecrit@ietf.org; Tue, 24 Apr 2007 22:43:49 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgXTw-0005a4-Pi for ecrit@ietf.org; Tue, 24 Apr 2007 22:43:48 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3P2hjk3010819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Apr 2007 22:43:46 -0400 (EDT) In-Reply-To: <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <48691367-FB10-48CD-8749-6E0894D7BDF3@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles (was: Consensus Call) Date: Tue, 24 Apr 2007 22:43:43 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > I do understand your concern. You don't want the clients to have > to know much of anything; they should just do a copy and paste. > Well, with DHCP they have to be smarter than that just because of > the difference in protocols (binary vs. XML). But an XML based LCP > can almost be that simple (almost, XML namespaces do require > normalization). And I agree, that would be good. The XML namespaces can just be copied, as far as I can tell. I don't know what you mean by normalization, except that you'd have to make sure that name clashes are avoided. (If LoST uses namespace short hand X, you have to transform the LO namespaces to something other than X, but that's a purely mechanical and blind transformation.) I.e., may become if LoST happens to be using 'cl'. > > However, the way to approach this is to subtly change the way we do > profile identifiers. Essentially, if we move them out of the > element and into their own child element, this bit > of data can be shuttled around with the location information > without any specific knowledge of the client. > > So, a location hiding LIS queries LoST for the PSAPs polygon. It > gets back: > > > > > ... > > > > The LIS has a simple algorithm; copy all elements inside the > element. It then hands the following information > over to the client: > > > > ... > > > The client information gets passed along, eventually being re-input > into a LoST server (the VSP verification step) where the intention > of this data is known. This requires an addition to PIDF-LO, namely a LoST profile identifier, which serves no purpose and is specific to LoST. I'm opposed to such a solution. Henning > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 24 23:40:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgYMm-0004WU-2V; Tue, 24 Apr 2007 23:40:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgYMk-0004WI-TF for ecrit@ietf.org; Tue, 24 Apr 2007 23:40:26 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgYMj-0004C7-Iy for ecrit@ietf.org; Tue, 24 Apr 2007 23:40:26 -0400 X-SEF-Processed: 5_0_0_910__2007_04_24_22_47_09 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 24 Apr 2007 22:47:09 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Apr 2007 22:40:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Profiles (was: Consensus Call) - hole Date: Tue, 24 Apr 2007 22:40:23 -0500 Message-ID: In-Reply-To: <146B26C8-0988-45B6-95D1-EB4266DEE300@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Profiles (was: Consensus Call) - hole Thread-Index: AceG4h1/N8JuqcymS2+kB+HMfGlUmwACBy1g From: "Winterbottom, James" To: "Henning Schulzrinne" , "Andrew Newton" X-OriginalArrivalTime: 25 Apr 2007 03:40:25.0143 (UTC) FILETIME=[75942C70:01C786EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Depending on how you see LoST being used it may be easiest just to not=0D=0A= allow holes in location being proffered to the LoST server.=0D=0A=0D=0AIn P= IDF-LO profile we made the assumption that the location being=0D=0Adescribe= d was that of the device/user hence a hole was not required.=0D=0A=0D=0AHol= es in service boundaries is a different issue and I think that this=0D=0Aca= n easily be addressed with the exception case described by Martin=0D=0AThom= son.=0D=0A=0D=0AI don't like the concept of LoST truncating data down to a = point in=0D=0Aorder to do the service mapping, and I have stated my reasons= for this=0D=0Aon numerous occasions, misrouting being one of them. I also = don't buy=0D=0Athe argument that the complexity to do area overlaps is hard= , it is my=0D=0Aunderstanding that most commercial GIS systems can do this = type of=0D=0Acalculation today without batting an eyelid.=0D=0A=0D=0AI acce= pt that this is not the current profile, and that there is scope=0D=0Ain Lo= ST for future profiles, and this why I don't see this last point as=0D=0Aa = show stopper for LoST.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A> ----= -Original Message-----=0D=0A> From: Henning Schulzrinne [mailto:hgs@cs.colu= mbia.edu]=0D=0A> Sent: Wednesday, 25 April 2007 12:33 PM=0D=0A> To: Andrew = Newton=0D=0A> Cc: ECRIT=0D=0A> Subject: Re: [Ecrit] Profiles (was: Consensu= s Call) - hole=0D=0A>=20=0D=0A>=20=0D=0A> On Apr 24, 2007, at 10:12 PM, And= rew Newton wrote:=0D=0A>=20=0D=0A> >=0D=0A> > On Apr 24, 2007, at 9:30 PM, = Henning Schulzrinne wrote:=0D=0A> >> (2) Transformation in LIS: The carrier= that wants to hide a=0D=0A> >> location creates a convex location region t= hat has no holes and=0D=0A> >> includes the location of the UA. A very simp= le way to do this is=0D=0A> >> to return a triangle (square, circle, ...) t= hat includes the=0D=0A> >> caller's location (not in the center) and whose = centroid falls=0D=0A> >> into the PSAP service area. This has to be done on= ly once (unless=0D=0A> >> the PSAP boundary changes), so the computational = burden is trivial.=0D=0A> >=0D=0A> > Well, that's certainly a creative appr= oach, and complex. And it=0D=0A> > screws with the caching and periodic re= query at the end point. The=0D=0A> > created shape must fall entirely with= in service boundary. If any=0D=0A> > part of it overlaps the service=0D=0A= >=20=0D=0A> Not really; caching works just as before. The created shape doe= s=0D=0A> *not* have to fall completely within the service boundary, given t= he=0D=0A> centroid computation that determines matching. As per the previou= s=0D=0A> discussion, any non-point shape will need to be transformed to a=0D= =0A> point (centroid) by the LoST server.=0D=0A>=20=0D=0A> > boundary, then= there is the potential for a misrouted call. If the=0D=0A> > created shap= e falls within the service boundary, it will be less=0D=0A> > than the area= of the service boundary and cause needless requerys=0D=0A> > by the endpoi= nts, which will believe they may have crossed from one=0D=0A> > service bou= ndary to another when, in fact, they haven't.=0D=0A> >=0D=0A> > That seems = like a lot of extra burden on the system, when we could=0D=0A> > just add s= ome meta-data to the service boundary and allow LoST=0D=0A> > servers to do= exact matches.=0D=0A>=20=0D=0A> This would not be the service boundary, bu= t it would have to be the=0D=0A> element, so it would have = to be a PIDF-LO extension,=0D=0A> which seems rather strange.=0D=0A>=20=0D=0A= >=20=0D=0A> >=0D=0A> > -andy=0D=0A>=20=0D=0A>=20=0D=0A> ___________________= ____________________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.or= g=0D=0A> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A----------= ---------------------------------------------------------------------------= -----------=0D=0AThis message is for the designated recipient only and may=0D= =0Acontain privileged, proprietary, or otherwise private information. =20=0D= =0AIf you have received it in error, please notify the sender=0D=0Aimmediat= ely and delete the original. Any unauthorized use of=0D=0Athis email is pr= ohibited.=0D=0A------------------------------------------------------------= ------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Apr 24 23:47:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgYTu-0000Wc-Ua; Tue, 24 Apr 2007 23:47:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgYTt-0000WP-NR for ecrit@ietf.org; Tue, 24 Apr 2007 23:47:49 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgYTs-0005X4-GU for ecrit@ietf.org; Tue, 24 Apr 2007 23:47:49 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3P3lcmb018133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Apr 2007 23:47:40 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <66C32837-FDCA-433A-884C-453F0AD40168@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles (was: Consensus Call) - hole Date: Tue, 24 Apr 2007 23:47:37 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 24, 2007, at 11:40 PM, Winterbottom, James wrote: > Depending on how you see LoST being used it may be easiest just to not > allow holes in location being proffered to the LoST server. I fully agree with that. > > I don't like the concept of LoST truncating data down to a point in > order to do the service mapping, and I have stated my reasons for this > on numerous occasions, misrouting being one of them. I also don't buy > the argument that the complexity to do area overlaps is hard, it is my > understanding that most commercial GIS systems can do this type of > calculation today without batting an eyelid. You have never answered my extensive description of why this is hard and useless. This has nothing to do with GIS systems, but rather with issues of forking and with the fake accuracy implied by such mappings, which have nothing to do with measured reality. In other words, lots of complexity for nothing except symbolic gains. Please review my message on the notions of probability implied by such mappings. > > I accept that this is not the current profile, and that there is scope > in LoST for future profiles, and this why I don't see this last > point as > a show stopper for LoST. I'm not sure what this has to do with profiles. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 25 04:37:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgd0Y-0006LE-1A; Wed, 25 Apr 2007 04:37:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgd0W-0006L4-HR; Wed, 25 Apr 2007 04:37:48 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgd0V-0002S5-5K; Wed, 25 Apr 2007 04:37:48 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTPś id l3P8bfR6006468Wed, 25 Apr 2007 08:37:41 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1Hgd0B-000K08-00; Wed, 25 Apr 2007 09:37:27 +0100 Date: Wed, 25 Apr 2007 09:37:27 +0100 From: "Clive D.W. Feather" To: Henning Schulzrinne Subject: Re: [Ecrit] Circuit ID Message-ID: <20070425083727.GC70951@finch-staff-1.thus.net> References: <0f5c01c781e3$b004eaa0$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA03B0F49E@crexc41p> <66DDF0E9-8C5D-4107-BB6D-40A1A50634CA@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66DDF0E9-8C5D-4107-BB6D-40A1A50634CA@cs.columbia.edu> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: GEOPRIV , "Stark, Barbara" , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning Schulzrinne said: > Just out of curiosity, what does a circuit ID look like? Is that the > NAS identifier used in RADIUS or where is it visible? In the UK it's not currently standardised, though we're looking at it. I would *expect* it to end up something like BT-EA12345678 or 001-EA12345678 where the first part identifies the circuit owner (either a short name or a CUPID) and the second half is decided by the provider; BT appear to use a two letter region code followed by an 8 digit number). >> Actually, given requirements for "naked" DSL, without an underlying POTS >> phone number, we're moving to "Circuit ID". That's not the only scenario - the UK is looking at an arrangement whereby one telco (Openreach, part of BT) provides the circuit and another telco provides the call server and thus the number; Openreach and BT will have no visibility of the number - if any - allocated to the line. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 25 09:42:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HghlV-00041f-JA; Wed, 25 Apr 2007 09:42:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HghlU-00040m-U7 for ecrit@ietf.org; Wed, 25 Apr 2007 09:42:36 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HghlT-0002Hw-Nv for ecrit@ietf.org; Wed, 25 Apr 2007 09:42:36 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 25 Apr 2007 09:42:34 -0400 id 01588369.462F5ACA.00000F11 In-Reply-To: <146B26C8-0988-45B6-95D1-EB4266DEE300@cs.columbia.edu> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <93297558-09D6-472E-8F04-3BA6734C1833@hxr.us> <146B26C8-0988-45B6-95D1-EB4266DEE300@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles (was: Consensus Call) - hole Date: Wed, 25 Apr 2007 09:42:34 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 24, 2007, at 10:32 PM, Henning Schulzrinne wrote: >> That seems like a lot of extra burden on the system, when we could >> just add some meta-data to the service boundary and allow LoST >> servers to do exact matches. > > This would not be the service boundary, but it would have to be the > element, so it would have to be a PIDF-LO > extension, which seems rather strange. PIDF-LO allows multiple elements from other namespaces inside the . That is not strange, that is very common in XML. The meta-data is not an extension to PIDF-LO itself. That is a mischaracterization. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 25 09:47:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hghq3-00046d-B5; Wed, 25 Apr 2007 09:47:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hghq2-00046V-Go for ecrit@ietf.org; Wed, 25 Apr 2007 09:47:18 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hghq2-0004Eq-6q for ecrit@ietf.org; Wed, 25 Apr 2007 09:47:18 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 25 Apr 2007 09:47:17 -0400 id 01588369.462F5BE5.00001053 In-Reply-To: References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <4991CDE0-BA87-42E5-BCEA-2A8ED6324FA1@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Wed, 25 Apr 2007 09:47:17 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org XML validity and XML namespaces are separate features. XML validity, in the form of DTDs, existed before XML namespaces. It just so happens that the more modern XML schema languages, such as Relax NG and XML Schema, account for XML namespaces and allow the validity to check the namespace, which wasn't possible with DTDs. However, validation checking will not solve this problem, as each XML fragment is valid against its schema. This means such validation must be done by the application. -andy On Apr 24, 2007, at 10:39 PM, Henning Schulzrinne wrote: > I don't understand your comment. The namespace better identify > completely the list of XML tags that are permissible, as something > is terribly wrong with the XML validity otherwise. > > I also don't see why a purely civic address would need a GML name > space, but that's a separate issue. > > On Apr 24, 2007, at 9:22 PM, Andrew Newton wrote: > >> >> On Apr 24, 2007, at 9:04 PM, Henning Schulzrinne wrote: >>> The receiver doesn't care that the format is derived from RFC >>> 3825. The namespace declaration (which you elided in your example) >>> >>> xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" >>> >>> identifies the schema, so the receiver can easily tell whether it >>> should ignore or handle the XML tags or not (or decide that it >>> needs to give up instead). Thus, it can tell what meaning FLR has >>> and whether it knows anything about that particular XML tag. >> >> No. The way you are describing it, it must recognize both the GML >> and the civicAddr namespaces. And a 3825 based location profile >> could easily use urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc >> for the namespace identifier. It would be better if the sender >> let the receiver in on what type of location it is sending. >> >> -andy > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 25 09:53:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hghvd-0002yj-1T; Wed, 25 Apr 2007 09:53:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hghvb-0002yZ-UP for ecrit@ietf.org; Wed, 25 Apr 2007 09:53:03 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hghva-0005MI-Np for ecrit@ietf.org; Wed, 25 Apr 2007 09:53:03 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 25 Apr 2007 09:53:02 -0400 id 01588369.462F5D3E.000011A3 In-Reply-To: <48691367-FB10-48CD-8749-6E0894D7BDF3@cs.columbia.edu> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <48691367-FB10-48CD-8749-6E0894D7BDF3@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <38F51001-96C5-4BF5-BEB6-71E9998A6387@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles (was: Consensus Call) Date: Wed, 25 Apr 2007 09:53:01 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 24, 2007, at 10:43 PM, Henning Schulzrinne wrote: > The XML namespaces can just be copied, as far as I can tell. I > don't know what you mean by normalization, except that you'd have > to make sure that name clashes are avoided. (If LoST uses namespace > short hand X, you have to transform the LO namespaces to something > other than X, but that's a purely mechanical and blind > transformation.) I.e., > > > > may become > > > > if LoST happens to be using 'cl'. I don't think we are in disagreement here. The algorithm for the transformation is the same regardless of profile. This isn't even a LoST or PIDF-LO issue... its a general XML issue. > This requires an addition to PIDF-LO, namely a LoST profile > identifier, which serves no purpose and is specific to LoST. I'm > opposed to such a solution. Again, it is not an addition to PIDF-LO. And I gave you a good reason why we need the profile identifiers, its just that you would rather have a LIS contort LoST service boundaries, which is a less straight forward way of handling this. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 25 10:24:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgiQV-0006Do-3C; Wed, 25 Apr 2007 10:24:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgiQT-00063k-Cx for ecrit@ietf.org; Wed, 25 Apr 2007 10:24:57 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgiQS-00045F-2y for ecrit@ietf.org; Wed, 25 Apr 2007 10:24:57 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HgiQR-0007Pz-55; Wed, 25 Apr 2007 10:24:55 -0400 Received: from [127.0.0.1] (dhcp89-073-062.bbn.com [128.89.73.62]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l3PEOtw28461; Wed, 25 Apr 2007 10:24:55 -0400 (EDT) Message-ID: <462F64B5.9000102@bbn.com> Date: Wed, 25 Apr 2007 10:24:53 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Profiles References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Just want to note that since LoST does allow for multiple services for a given location, and since the LIS doesn't know which an endpoint might try to get via LoST, the area that the LIS returns will have to be a subset of the intersection of all the service areas that contain the endpoint's location In particular, you can't do an exact match in general, since the LIS can't be relied on to provide the exact service area for any particular service. --Richard Henning Schulzrinne wrote: >> >> Also, there's the problem I brought up yesterday. If a server sees >> this input, where a polygon has a whole in it: >> >> >> >> >> ... >> >> >> >> >> ... >> >> >> >> >> Now, is the server to find the centroid of the polygon or is it >> suppose to look for an exact match of the polygon? >> > > That seems like a completely different question compared to the profile > issue, or at least I'm missing the connection. > > This is indeed a real problem, but only if the location of the querier > itself has a hole. There is no problem for the case where the service > boundary has one or more holes. The location-with-hole case only occurs > in the location hiding case, as far as I can tell, and is relatively > uncommon even there. > > There are two solutions, neither of which is totally satisfying. > > (1) Exact match, as you indicate. In other words, a LoST server first > tries to find an exact match for the boundary. For the location-hiding > case, this will always work. > > Advantage: The client doesn't have to know. > Disadvantage: LoST servers need a special case. > > (2) Transformation in LIS: The carrier that wants to hide a location > creates a convex location region that has no holes and includes the > location of the UA. A very simple way to do this is to return a triangle > (square, circle, ...) that includes the caller's location (not in the > center) and whose centroid falls into the PSAP service area. This has to > be done only once (unless the PSAP boundary changes), so the > computational burden is trivial. > > Advantage: No special case in LoST servers. > Disadvantage: Requires some special geometric treatment for special cases. > > I have some preference for (2), since it's a bit cleaner and it's > conceptually no different from a wireless location system with a very > imprecise location technology, such as cell-face only. It requires no > standardization as such, as long as we standardize the centroid behavior. > > Henning > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 25 11:04:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgj2P-0008KU-8v; Wed, 25 Apr 2007 11:04:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgj2O-0008KP-DJ for ecrit@ietf.org; Wed, 25 Apr 2007 11:04:08 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgj2N-0005y7-3G for ecrit@ietf.org; Wed, 25 Apr 2007 11:04:08 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 25 Apr 2007 11:04:06 -0400 id 01588369.462F6DE6.00002337 In-Reply-To: <462F64B5.9000102@bbn.com> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <462F64B5.9000102@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <70211C7B-2066-4D69-99B0-A7CDE9D09A5B@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles Date: Wed, 25 Apr 2007 11:04:06 -0400 To: Richard Barnes X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Well, that's an interesting wrinkle. I don't think this is specific to exact match of service boundaries or the convex location. This is born out of the fact that the LIS doesn't know the service that may be queried, and the assumption in this entire location hiding idea has been that the LIS and the LoST seeker are using the querying for the same service -- something that can't actually be assumed. Back to the drawing board! -andy On Apr 25, 2007, at 10:24 AM, Richard Barnes wrote: > Just want to note that since LoST does allow for multiple services > for a given location, and since the LIS doesn't know which an > endpoint might try to get via LoST, the area that the LIS returns > will have to be a subset of the intersection of all the service > areas that contain the endpoint's location > > In particular, you can't do an exact match in general, since the > LIS can't be relied on to provide the exact service area for any > particular service. > > --Richard > > > Henning Schulzrinne wrote: >>> >>> Also, there's the problem I brought up yesterday. If a server >>> sees this input, where a polygon has a whole in it: >>> >>> >>> >>> >>> ... >>> >>> >>> >>> >>> ... >>> >>> >>> >>> >>> Now, is the server to find the centroid of the polygon or is it >>> suppose to look for an exact match of the polygon? >>> >> That seems like a completely different question compared to the >> profile issue, or at least I'm missing the connection. >> This is indeed a real problem, but only if the location of the >> querier itself has a hole. There is no problem for the case where >> the service boundary has one or more holes. The location-with-hole >> case only occurs in the location hiding case, as far as I can >> tell, and is relatively uncommon even there. >> There are two solutions, neither of which is totally satisfying. >> (1) Exact match, as you indicate. In other words, a LoST server >> first tries to find an exact match for the boundary. For the >> location-hiding case, this will always work. >> Advantage: The client doesn't have to know. >> Disadvantage: LoST servers need a special case. >> (2) Transformation in LIS: The carrier that wants to hide a >> location creates a convex location region that has no holes and >> includes the location of the UA. A very simple way to do this is >> to return a triangle (square, circle, ...) that includes the >> caller's location (not in the center) and whose centroid falls >> into the PSAP service area. This has to be done only once (unless >> the PSAP boundary changes), so the computational burden is trivial. >> Advantage: No special case in LoST servers. >> Disadvantage: Requires some special geometric treatment for >> special cases. >> I have some preference for (2), since it's a bit cleaner and it's >> conceptually no different from a wireless location system with a >> very imprecise location technology, such as cell-face only. It >> requires no standardization as such, as long as we standardize the >> centroid behavior. >> Henning >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 25 11:31:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgjT2-0007mP-Qz; Wed, 25 Apr 2007 11:31:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgjRZ-0006yw-02; Wed, 25 Apr 2007 11:30:09 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgjQ6-0004sq-KR; Wed, 25 Apr 2007 11:28:40 -0400 Received: from ([139.76.131.87]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.20885855; Wed, 25 Apr 2007 11:28:24 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 25 Apr 2007 11:28:20 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 25 Apr 2007 11:28:20 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Circuit ID Date: Wed, 25 Apr 2007 11:28:19 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA03B10049@crexc41p> In-Reply-To: <20070425083727.GC70951@finch-staff-1.thus.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Circuit ID thread-index: AceHFQyqZlnQ5g2ETgCZ331d4v3yGgAN65nw References: <0f5c01c781e3$b004eaa0$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA03B0F49E@crexc41p> <66DDF0E9-8C5D-4107-BB6D-40A1A50634CA@cs.columbia.edu> <20070425083727.GC70951@finch-staff-1.thus.net> From: "Stark, Barbara" To: "Clive D.W. Feather" , "Henning Schulzrinne" X-OriginalArrivalTime: 25 Apr 2007 15:28:20.0272 (UTC) FILETIME=[5ABA8300:01C7874E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Circuit IDs have nothing to do with RADIUS, that I'm aware of. "Circuit ID" format is defined by whatever system an access company uses to manage its inventory of circuits. The most common such system in the US is TIRKS(R), which is now developed by Telcordia. It was initially developed by AT&T Bell Labs in the late 1970's. Fortunately, it has managed to evolve a bit since then. Most of the baby Bells continue to use it, I think. There's a really short Wikipedia description of TIRKS at http://en.wikipedia.org/wiki/TIRKS In short, a Circuit ID uniquely identifies a circuit within an access provider's operations systems. Many different types of circuits exist (POTS, T1, DS3, SONET, etc.). Different types use different formats. Barbara -----Original Message----- From: Clive D.W. Feather [mailto:clive@demon.net]=20 Sent: Wednesday, April 25, 2007 4:37 AM To: Henning Schulzrinne Cc: Stark, Barbara; GEOPRIV; ECRIT Subject: Re: [Ecrit] Circuit ID Henning Schulzrinne said: > Just out of curiosity, what does a circuit ID look like? Is that the=20 > NAS identifier used in RADIUS or where is it visible? In the UK it's not currently standardised, though we're looking at it. I would *expect* it to end up something like BT-EA12345678 or 001-EA12345678 where the first part identifies the circuit owner (either a short name or a CUPID) and the second half is decided by the provider; BT appear to use a two letter region code followed by an 8 digit number). >> Actually, given requirements for "naked" DSL, without an underlying=20 >> POTS phone number, we're moving to "Circuit ID". That's not the only scenario - the UK is looking at an arrangement whereby one telco (Openreach, part of BT) provides the circuit and another telco provides the call server and thus the number; Openreach and BT will have no visibility of the number - if any - allocated to the line. --=20 Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA623 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 25 13:32:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HglLj-00010C-MC; Wed, 25 Apr 2007 13:32:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HglLi-000106-FA for ecrit@ietf.org; Wed, 25 Apr 2007 13:32:14 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HglLg-0005nG-QX for ecrit@ietf.org; Wed, 25 Apr 2007 13:32:14 -0400 X-SEF-Processed: 5_0_0_910__2007_04_25_12_38_55 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 25 Apr 2007 12:38:54 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 12:32:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Profiles Date: Wed, 25 Apr 2007 12:32:08 -0500 Message-ID: In-Reply-To: <70211C7B-2066-4D69-99B0-A7CDE9D09A5B@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Profiles Thread-Index: AceHSvtSlAulV866SBqC3TZWuwx9/wAE8JLQ From: "Winterbottom, James" To: "Andrew Newton" , "Richard Barnes" X-OriginalArrivalTime: 25 Apr 2007 17:32:09.0976 (UTC) FILETIME=[A72D5F80:01C7875F] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Isn't this in part a function of what the LCP can provide=3F=0D=0AIt was my= understanding that access providers don't mind providing the=0D=0Aactual l= ocation of an end-point, but that they want to charge for the=0D=0Aprivileg= e.=20=0D=0A=0D=0AThis would mean to me, that I can expect emergency service= s to work, but=0D=0Anot pizza delivery or other local-routing type services= =2E This seems=0D=0Areasonable, and shrinks the applicability down substant= ially. The=0D=0Aproblem manifests itself for emergency services where the s= ervices=0D=0Athemselves are addressed individually, that is fire is differe= nt to=0D=0Aambulance etc. Is this what you were getting at Richard and Andy= =3F=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A> -----Original Message-----=0D= =0A> From: Andrew Newton [mailto:andy@hxr.us]=0D=0A> Sent: Thursday, 26 Apr= il 2007 1:04 AM=0D=0A> To: Richard Barnes=0D=0A> Cc: ECRIT=0D=0A> Subject: = Re: [Ecrit] Profiles=0D=0A>=20=0D=0A> Well, that's an interesting wrinkle. = I don't think this is specific=0D=0A> to exact match of service boundaries= or the convex location. This is=0D=0A> born out of the fact that the LIS = doesn't know the service that may=0D=0A> be queried, and the assumption in = this entire location hiding idea=0D=0A> has been that the LIS and the LoST = seeker are using the querying for=0D=0A> the same service -- something that= can't actually be assumed.=0D=0A>=20=0D=0A> Back to the drawing board!=0D=0A= >=20=0D=0A> -andy=0D=0A>=20=0D=0A> On Apr 25, 2007, at 10:24 AM, Richard Ba= rnes wrote:=0D=0A>=20=0D=0A> > Just want to note that since LoST does allow= for multiple services=0D=0A> > for a given location, and since the LIS doe= sn't know which an=0D=0A> > endpoint might try to get via LoST, the area th= at the LIS returns=0D=0A> > will have to be a subset of the intersection of= all the service=0D=0A> > areas that contain the endpoint's location=0D=0A>= >=0D=0A> > In particular, you can't do an exact match in general, since th= e=0D=0A> > LIS can't be relied on to provide the exact service area for any=0D= =0A> > particular service.=0D=0A> >=0D=0A> > --Richard=0D=0A> >=0D=0A> >=0D= =0A> > Henning Schulzrinne wrote:=0D=0A> >>>=0D=0A> >>> Also, there's the p= roblem I brought up yesterday. If a server=0D=0A> >>> sees this input, whe= re a polygon has a whole in it:=0D=0A> >>>=0D=0A> >>> =0D=0A> >>> =0D=0A> >>> =0D=0A> >>> ...=0D=0A> >>> =0D=0A= > >>> =0D=0A> >>> =0D=0A> >>> =0D=0A> >>> ...=0D=0A> >>> =0D=0A> >>> = =0D=0A> >>> =0D=0A> >>>=0D=0A> >>> Now, is = the server to find the centroid of the polygon or is it=0D=0A> >>> suppose = to look for an exact match of the polygon=3F=0D=0A> >>>=0D=0A> >> That seem= s like a completely different question compared to the=0D=0A> >> profile is= sue, or at least I'm missing the connection.=0D=0A> >> This is indeed a rea= l problem, but only if the location of the=0D=0A> >> querier itself has a h= ole. There is no problem for the case where=0D=0A> >> the service boundary = has one or more holes. The location-with-hole=0D=0A> >> case only occurs in= the location hiding case, as far as I can=0D=0A> >> tell, and is relativel= y uncommon even there.=0D=0A> >> There are two solutions, neither of which = is totally satisfying.=0D=0A> >> (1) Exact match, as you indicate. In other= words, a LoST server=0D=0A> >> first tries to find an exact match for the = boundary. For the=0D=0A> >> location-hiding case, this will always work.=0D= =0A> >> Advantage: The client doesn't have to know.=0D=0A> >> Disadvantage:= LoST servers need a special case.=0D=0A> >> (2) Transformation in LIS: The= carrier that wants to hide a=0D=0A> >> location creates a convex location = region that has no holes and=0D=0A> >> includes the location of the UA. A v= ery simple way to do this is=0D=0A> >> to return a triangle (square, circle= , ...) that includes the=0D=0A> >> caller's location (not in the center) an= d whose centroid falls=0D=0A> >> into the PSAP service area. This has to be= done only once (unless=0D=0A> >> the PSAP boundary changes), so the comput= ational burden is trivial.=0D=0A> >> Advantage: No special case in LoST ser= vers.=0D=0A> >> Disadvantage: Requires some special geometric treatment for=0D= =0A> >> special cases.=0D=0A> >> I have some preference for (2), since it's= a bit cleaner and it's=0D=0A> >> conceptually no different from a wireless= location system with a=0D=0A> >> very imprecise location technology, such = as cell-face only. It=0D=0A> >> requires no standardization as such, as lon= g as we standardize the=0D=0A> >> centroid behavior.=0D=0A> >> Henning=0D=0A= > >> _______________________________________________=0D=0A> >> Ecrit mailin= g list=0D=0A> >> Ecrit@ietf.org=0D=0A> >> https://www1.ietf.org/mailman/lis= tinfo/ecrit=0D=0A> >=0D=0A>=20=0D=0A>=20=0D=0A> ___________________________= ____________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A>= https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A------------------= ---------------------------------------------------------------------------= ---=0D=0AThis message is for the designated recipient only and may=0D=0Acon= tain privileged, proprietary, or otherwise private information. =20=0D=0AIf= you have received it in error, please notify the sender=0D=0Aimmediately a= nd delete the original. Any unauthorized use of=0D=0Athis email is prohibi= ted.=0D=0A-----------------------------------------------------------------= -------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 25 14:26:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgmBu-0004Sl-52; Wed, 25 Apr 2007 14:26:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgmBt-0004Sg-5v for ecrit@ietf.org; Wed, 25 Apr 2007 14:26:09 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgmBs-0004KJ-O9 for ecrit@ietf.org; Wed, 25 Apr 2007 14:26:09 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1Hgm9w-0002xg-EO; Wed, 25 Apr 2007 13:24:09 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Andrew Newton'" , "'Richard Barnes'" Subject: RE: [Ecrit] Profiles Date: Wed, 25 Apr 2007 14:26:00 -0400 Message-ID: <027001c78767$30e677a0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceHSvtSlAulV866SBqC3TZWuwx9/wAE8JLQAAILP9A= 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I gave an example of an algorithm that solves this problem: Intersect all the (emergency) services boundaries, computing the largest polygon contained in all boundaries. Pick any point in the polygon. Use that as the center of a circle with 50kM radius Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Wednesday, April 25, 2007 1:32 PM > To: Andrew Newton; Richard Barnes > Cc: ECRIT > Subject: RE: [Ecrit] Profiles > > Isn't this in part a function of what the LCP can provide? > It was my understanding that access providers don't mind providing the > actual location of an end-point, but that they want to charge for the > privilege. > > This would mean to me, that I can expect emergency services to work, but > not pizza delivery or other local-routing type services. This seems > reasonable, and shrinks the applicability down substantially. The > problem manifests itself for emergency services where the services > themselves are addressed individually, that is fire is different to > ambulance etc. Is this what you were getting at Richard and Andy? > > Cheers > James > > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Thursday, 26 April 2007 1:04 AM > > To: Richard Barnes > > Cc: ECRIT > > Subject: Re: [Ecrit] Profiles > > > > Well, that's an interesting wrinkle. I don't think this is specific > > to exact match of service boundaries or the convex location. This is > > born out of the fact that the LIS doesn't know the service that may > > be queried, and the assumption in this entire location hiding idea > > has been that the LIS and the LoST seeker are using the querying for > > the same service -- something that can't actually be assumed. > > > > Back to the drawing board! > > > > -andy > > > > On Apr 25, 2007, at 10:24 AM, Richard Barnes wrote: > > > > > Just want to note that since LoST does allow for multiple services > > > for a given location, and since the LIS doesn't know which an > > > endpoint might try to get via LoST, the area that the LIS returns > > > will have to be a subset of the intersection of all the service > > > areas that contain the endpoint's location > > > > > > In particular, you can't do an exact match in general, since the > > > LIS can't be relied on to provide the exact service area for any > > > particular service. > > > > > > --Richard > > > > > > > > > Henning Schulzrinne wrote: > > >>> > > >>> Also, there's the problem I brought up yesterday. If a server > > >>> sees this input, where a polygon has a whole in it: > > >>> > > >>> > > >>> > > >>> > > >>> ... > > >>> > > >>> > > >>> > > >>> > > >>> ... > > >>> > > >>> > > >>> > > >>> > > >>> Now, is the server to find the centroid of the polygon or is it > > >>> suppose to look for an exact match of the polygon? > > >>> > > >> That seems like a completely different question compared to the > > >> profile issue, or at least I'm missing the connection. > > >> This is indeed a real problem, but only if the location of the > > >> querier itself has a hole. There is no problem for the case where > > >> the service boundary has one or more holes. The location-with-hole > > >> case only occurs in the location hiding case, as far as I can > > >> tell, and is relatively uncommon even there. > > >> There are two solutions, neither of which is totally satisfying. > > >> (1) Exact match, as you indicate. In other words, a LoST server > > >> first tries to find an exact match for the boundary. For the > > >> location-hiding case, this will always work. > > >> Advantage: The client doesn't have to know. > > >> Disadvantage: LoST servers need a special case. > > >> (2) Transformation in LIS: The carrier that wants to hide a > > >> location creates a convex location region that has no holes and > > >> includes the location of the UA. A very simple way to do this is > > >> to return a triangle (square, circle, ...) that includes the > > >> caller's location (not in the center) and whose centroid falls > > >> into the PSAP service area. This has to be done only once (unless > > >> the PSAP boundary changes), so the computational burden is trivial. > > >> Advantage: No special case in LoST servers. > > >> Disadvantage: Requires some special geometric treatment for > > >> special cases. > > >> I have some preference for (2), since it's a bit cleaner and it's > > >> conceptually no different from a wireless location system with a > > >> very imprecise location technology, such as cell-face only. It > > >> requires no standardization as such, as long as we standardize the > > >> centroid behavior. > > >> Henning > > >> _______________________________________________ > > >> Ecrit mailing list > > >> Ecrit@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 25 17:45:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgpIv-0007kB-Em; Wed, 25 Apr 2007 17:45:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgpIu-0007k3-8i for ecrit@ietf.org; Wed, 25 Apr 2007 17:45:36 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgpIt-0006fd-TW for ecrit@ietf.org; Wed, 25 Apr 2007 17:45:36 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3PLjKQH029670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Apr 2007 17:45:20 -0400 (EDT) In-Reply-To: <027001c78767$30e677a0$640fa8c0@cis.neustar.com> References: <027001c78767$30e677a0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4CFE0EC5-089F-4DA6-8C22-6CBCA8E96038@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles Date: Wed, 25 Apr 2007 17:46:48 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, that's roughly (modulo some different shapes) the suggestion I made yesterday, so I'm confused. James, I don't think this is a matter of charging, except maybe in theory. I don't think anybody has illusions about per-dip charging, given the complexity of setting up a micropayment system. (Also, in many cases, it's not the target that would gain value from location information, but rather the recipient, which makes this even more challenging.) Henning On Apr 25, 2007, at 2:26 PM, Brian Rosen wrote: > I gave an example of an algorithm that solves this problem: > Intersect all the (emergency) services boundaries, computing the > largest > polygon contained in all boundaries. Pick any point in the > polygon. Use > that as the center of a circle with 50kM radius > > Brian > >> -----Original Message----- >> From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] >> Sent: Wednesday, April 25, 2007 1:32 PM >> To: Andrew Newton; Richard Barnes >> Cc: ECRIT >> Subject: RE: [Ecrit] Profiles >> >> Isn't this in part a function of what the LCP can provide? >> It was my understanding that access providers don't mind providing >> the >> actual location of an end-point, but that they want to charge for the >> privilege. >> >> This would mean to me, that I can expect emergency services to >> work, but >> not pizza delivery or other local-routing type services. This seems >> reasonable, and shrinks the applicability down substantially. The >> problem manifests itself for emergency services where the services >> themselves are addressed individually, that is fire is different to >> ambulance etc. Is this what you were getting at Richard and Andy? >> >> Cheers >> James >> >>> -----Original Message----- >>> From: Andrew Newton [mailto:andy@hxr.us] >>> Sent: Thursday, 26 April 2007 1:04 AM >>> To: Richard Barnes >>> Cc: ECRIT >>> Subject: Re: [Ecrit] Profiles >>> >>> Well, that's an interesting wrinkle. I don't think this is specific >>> to exact match of service boundaries or the convex location. >>> This is >>> born out of the fact that the LIS doesn't know the service that may >>> be queried, and the assumption in this entire location hiding idea >>> has been that the LIS and the LoST seeker are using the querying for >>> the same service -- something that can't actually be assumed. >>> >>> Back to the drawing board! >>> >>> -andy >>> >>> On Apr 25, 2007, at 10:24 AM, Richard Barnes wrote: >>> >>>> Just want to note that since LoST does allow for multiple services >>>> for a given location, and since the LIS doesn't know which an >>>> endpoint might try to get via LoST, the area that the LIS returns >>>> will have to be a subset of the intersection of all the service >>>> areas that contain the endpoint's location >>>> >>>> In particular, you can't do an exact match in general, since the >>>> LIS can't be relied on to provide the exact service area for any >>>> particular service. >>>> >>>> --Richard >>>> >>>> >>>> Henning Schulzrinne wrote: >>>>>> >>>>>> Also, there's the problem I brought up yesterday. If a server >>>>>> sees this input, where a polygon has a whole in it: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Now, is the server to find the centroid of the polygon or is it >>>>>> suppose to look for an exact match of the polygon? >>>>>> >>>>> That seems like a completely different question compared to the >>>>> profile issue, or at least I'm missing the connection. >>>>> This is indeed a real problem, but only if the location of the >>>>> querier itself has a hole. There is no problem for the case where >>>>> the service boundary has one or more holes. The location-with-hole >>>>> case only occurs in the location hiding case, as far as I can >>>>> tell, and is relatively uncommon even there. >>>>> There are two solutions, neither of which is totally satisfying. >>>>> (1) Exact match, as you indicate. In other words, a LoST server >>>>> first tries to find an exact match for the boundary. For the >>>>> location-hiding case, this will always work. >>>>> Advantage: The client doesn't have to know. >>>>> Disadvantage: LoST servers need a special case. >>>>> (2) Transformation in LIS: The carrier that wants to hide a >>>>> location creates a convex location region that has no holes and >>>>> includes the location of the UA. A very simple way to do this is >>>>> to return a triangle (square, circle, ...) that includes the >>>>> caller's location (not in the center) and whose centroid falls >>>>> into the PSAP service area. This has to be done only once (unless >>>>> the PSAP boundary changes), so the computational burden is >>>>> trivial. >>>>> Advantage: No special case in LoST servers. >>>>> Disadvantage: Requires some special geometric treatment for >>>>> special cases. >>>>> I have some preference for (2), since it's a bit cleaner and it's >>>>> conceptually no different from a wireless location system with a >>>>> very imprecise location technology, such as cell-face only. It >>>>> requires no standardization as such, as long as we standardize the >>>>> centroid behavior. >>>>> Henning >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>> >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >> >> --------------------------------------------------------------------- >> ----- >> ---------------------- >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> --------------------------------------------------------------------- >> ----- >> ---------------------- >> [mf2] >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 25 20:36:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgryA-0000Xf-6T; Wed, 25 Apr 2007 20:36:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgry9-0000Xa-5d for ecrit@ietf.org; Wed, 25 Apr 2007 20:36:21 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgry7-0002Su-V0 for ecrit@ietf.org; Wed, 25 Apr 2007 20:36:21 -0400 Received: from [10.0.1.110] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 25 Apr 2007 20:36:19 -0400 id 0158813F.462FF403.00001D9E In-Reply-To: <027001c78767$30e677a0$640fa8c0@cis.neustar.com> References: <027001c78767$30e677a0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4E631237-4F68-4128-87B9-9B2F2E5CC034@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles Date: Wed, 25 Apr 2007 20:36:18 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 25, 2007, at 2:26 PM, Brian Rosen wrote: > I gave an example of an algorithm that solves this problem: > Intersect all the (emergency) services boundaries, computing the > largest > polygon contained in all boundaries. Pick any point in the > polygon. Use > that as the center of a circle with 50kM radius That assumes all polygons intersect. That may not be the case. Plus LoST services can be more than emergency services. How is a LIS suppose to know. I'm beginning to see Martin's point. We seem to be bending over backwards to avoid doing dereferences in LoST. Perhaps that is the real answer. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 25 20:59:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgsKF-0006i0-Gm; Wed, 25 Apr 2007 20:59:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgsKE-0006fC-Fm for ecrit@ietf.org; Wed, 25 Apr 2007 20:59:10 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgsKD-0004vF-8R for ecrit@ietf.org; Wed, 25 Apr 2007 20:59:10 -0400 X-SEF-Processed: 5_0_0_910__2007_04_25_20_05_54 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 25 Apr 2007 20:05:53 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 19:59:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Profiles Date: Wed, 25 Apr 2007 19:59:07 -0500 Message-ID: In-Reply-To: <4E631237-4F68-4128-87B9-9B2F2E5CC034@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Profiles Thread-Index: AceHmumdfQvyaMJbT2etrHB8PjUp3gAAx0Xg From: "Winterbottom, James" To: "Andrew Newton" , "Brian Rosen" X-OriginalArrivalTime: 26 Apr 2007 00:59:08.0610 (UTC) FILETIME=[18542A20:01C7879E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Or you have to include services in the request to the LIS, which is a=0D=0A= hack!=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Andrew Newton [m= ailto:andy@hxr.us]=0D=0A> Sent: Thursday, 26 April 2007 10:36 AM=0D=0A> To:= Brian Rosen=0D=0A> Cc: Winterbottom, James; 'Richard Barnes'; 'ECRIT'=0D=0A= > Subject: Re: [Ecrit] Profiles=0D=0A>=20=0D=0A>=20=0D=0A> On Apr 25, 2007,= at 2:26 PM, Brian Rosen wrote:=0D=0A>=20=0D=0A> > I gave an example of an = algorithm that solves this problem:=0D=0A> > Intersect all the (emergency) = services boundaries, computing the=0D=0A> > largest=0D=0A> > polygon contai= ned in all boundaries. Pick any point in the=0D=0A> > polygon. Use=0D=0A>= > that as the center of a circle with 50kM radius=0D=0A>=20=0D=0A> That as= sumes all polygons intersect. That may not be the case. Plus=0D=0A> LoST = services can be more than emergency services. How is a LIS=0D=0A> suppose = to know.=0D=0A>=20=0D=0A> I'm beginning to see Martin's point. We seem to = be bending over=0D=0A> backwards to avoid doing dereferences in LoST. Perh= aps that is the=0D=0A> real answer.=0D=0A>=20=0D=0A> -andy=0D=0A=0D=0A-----= ---------------------------------------------------------------------------= ----------------=0D=0AThis message is for the designated recipient only and= may=0D=0Acontain privileged, proprietary, or otherwise private information= =2E =20=0D=0AIf you have received it in error, please notify the sender=0D=0A= immediately and delete the original. Any unauthorized use of=0D=0Athis ema= il is prohibited.=0D=0A----------------------------------------------------= --------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 25 22:03:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgtKV-0002vx-Ew; Wed, 25 Apr 2007 22:03:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgtKV-0002vs-3n for ecrit@ietf.org; Wed, 25 Apr 2007 22:03:31 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgtKT-000172-RU for ecrit@ietf.org; Wed, 25 Apr 2007 22:03:31 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3Q23BR9005019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Apr 2007 22:03:11 -0400 (EDT) In-Reply-To: <4E631237-4F68-4128-87B9-9B2F2E5CC034@hxr.us> References: <027001c78767$30e677a0$640fa8c0@cis.neustar.com> <4E631237-4F68-4128-87B9-9B2F2E5CC034@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <80103DF1-11E1-47F0-91A5-E77203FD298E@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles Date: Wed, 25 Apr 2007 22:03:09 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 25, 2007, at 8:36 PM, Andrew Newton wrote: > > On Apr 25, 2007, at 2:26 PM, Brian Rosen wrote: > >> I gave an example of an algorithm that solves this problem: >> Intersect all the (emergency) services boundaries, computing the >> largest >> polygon contained in all boundaries. Pick any point in the >> polygon. Use >> that as the center of a circle with 50kM radius > > That assumes all polygons intersect. That may not be the case. They have to intersect at the location of the caller, at least, since every single service polygon covers the caller's location by definition. Can you give an example where they would not intersect? > Plus LoST services can be more than emergency services. How is a > LIS suppose to know. > > I'm beginning to see Martin's point. We seem to be bending over > backwards to avoid doing dereferences in LoST. Perhaps that is the > real answer. But that has its own set of problems, amply discussed earlier. The problem gets worse if you have multiple non-emergency services since they can be provided by multiple independent LoST hierarchies. I think we need to be somewhat practical. We can imagine all kinds of strange scenarios, but it seems unwise to create a whole lot of machinery for a special case (location hiding) that is hopefully rare or transient, and then optimize corner cases of that scenario. Clearly, in the US, there's only a single 9-1-1 service. > > -andy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 25 23:12:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HguPA-0008Kr-FN; Wed, 25 Apr 2007 23:12:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HguP9-0008Km-Mp for ecrit@ietf.org; Wed, 25 Apr 2007 23:12:23 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HguP8-00015D-GX for ecrit@ietf.org; Wed, 25 Apr 2007 23:12:23 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3Q3CBap005835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Apr 2007 23:12:13 -0400 (EDT) In-Reply-To: <38F51001-96C5-4BF5-BEB6-71E9998A6387@hxr.us> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <48691367-FB10-48CD-8749-6E0894D7BDF3@cs.columbia.edu> <38F51001-96C5-4BF5-BEB6-71E9998A6387@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles (was: Consensus Call) Date: Wed, 25 Apr 2007 23:12:09 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > Again, it is not an addition to PIDF-LO. And I gave you a good > reason why we need the profile identifiers, its just that you would > rather have a LIS contort LoST service boundaries, which is a less > straight forward way of handling this. > I don't see what this has to do with profiles. If I understood you correctly, you were suggesting a flag indicating a modification of the matching algorithm (point vs. whole polygon), which seems orthogonal to profiles. Subsequent discussion seems to indicate that this may not work in all cases. > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 25 23:14:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HguRG-0002Wn-3H; Wed, 25 Apr 2007 23:14:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HguRE-0002Wi-GA for ecrit@ietf.org; Wed, 25 Apr 2007 23:14:32 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HguRD-0001Na-8Y for ecrit@ietf.org; Wed, 25 Apr 2007 23:14:32 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3Q3ESNd012017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Apr 2007 23:14:28 -0400 (EDT) In-Reply-To: References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <4991CDE0-BA87-42E5-BCEA-2A8ED6324FA1@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Wed, 25 Apr 2007 23:14:26 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The point I'm making is that the namespace identifier is sufficient to determine what XML is valid, since you can determine the corresponding schema, whether expressed in RelaxNG or XML Schema. We are not using DTD. Thus, I fail to see what this has to do with another label. We don't have profile labels in SIP presence, for example, and the problem is pretty much the same. On Apr 25, 2007, at 9:47 AM, Andrew Newton wrote: > XML validity and XML namespaces are separate features. XML > validity, in the form of DTDs, existed before XML namespaces. It > just so happens that the more modern XML schema languages, such as > Relax NG and XML Schema, account for XML namespaces and allow the > validity to check the namespace, which wasn't possible with DTDs. > > However, validation checking will not solve this problem, as each > XML fragment is valid against its schema. This means such > validation must be done by the application. > > -andy > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Apr 25 23:16:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HguTE-0004ee-Pa; Wed, 25 Apr 2007 23:16:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HguTD-0004eW-Lg for ecrit@ietf.org; Wed, 25 Apr 2007 23:16:35 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HguTC-0001W8-Dw for ecrit@ietf.org; Wed, 25 Apr 2007 23:16:35 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3Q3GWRV012315 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Apr 2007 23:16:33 -0400 (EDT) In-Reply-To: References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <93297558-09D6-472E-8F04-3BA6734C1833@hxr.us> <146B26C8-0988-45B6-95D1-EB4266DEE300@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <988DE847-3F00-4B5B-B39C-1C0137ED784D@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles (was: Consensus Call) - hole Date: Wed, 25 Apr 2007 23:16:29 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org We seem to be talking past each other. The strange part is that this extension is specific to LoST usage and makes no sense elsewhere. Obviously, there is no syntactic problem. You still haven't answered what purpose the identifier serves, given that all other 4119 applications seem to survive just fine without it. On Apr 25, 2007, at 9:42 AM, Andrew Newton wrote: > > On Apr 24, 2007, at 10:32 PM, Henning Schulzrinne wrote: > >>> That seems like a lot of extra burden on the system, when we >>> could just add some meta-data to the service boundary and allow >>> LoST servers to do exact matches. >> >> This would not be the service boundary, but it would have to be >> the element, so it would have to be a PIDF-LO >> extension, which seems rather strange. > > PIDF-LO allows multiple elements from other namespaces inside the > . That is not strange, that is very common in XML. > The meta-data is not an extension to PIDF-LO itself. That is a > mischaracterization. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 26 11:20:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh5lv-0007ny-AN; Thu, 26 Apr 2007 11:20:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh5lu-0007nl-IQ; Thu, 26 Apr 2007 11:20:38 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh5lt-0007tW-3U; Thu, 26 Apr 2007 11:20:38 -0400 Received: from ([139.76.131.91]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.20976504; Thu, 26 Apr 2007 11:20:21 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 26 Apr 2007 11:20:17 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 26 Apr 2007 11:20:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Circuit ID Date: Thu, 26 Apr 2007 11:20:15 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA03D0E215@crexc41p> In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA03B10049@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Circuit ID thread-index: AceHFQyqZlnQ5g2ETgCZ331d4v3yGgAN65nwADJEieA= References: <20070425083727.GC70951@finch-staff-1.thus.net> <7582BC68E4994F4ABF0BD4723975C3FA03B10049@crexc41p> From: "Stark, Barbara" To: "Stark, Barbara" , "Clive D.W. Feather" , "Henning Schulzrinne" X-OriginalArrivalTime: 26 Apr 2007 15:20:17.0230 (UTC) FILETIME=[6539E6E0:01C78816] X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org It turns out I was wrong about the Circuit ID and RADIUS. I just can't seem to keep up with the architecture changes going on. Yes, in newer equipment, the Access Node (DSLAM) adds the Circuit ID to both DHCP and PPP protocols. This is copied into the message sent to RADIUS. Barbara=20 -----Original Message----- From: Stark, Barbara=20 Sent: Wednesday, April 25, 2007 11:28 AM To: Clive D.W. Feather; Henning Schulzrinne Cc: GEOPRIV; ECRIT Subject: RE: [Ecrit] Circuit ID Circuit IDs have nothing to do with RADIUS, that I'm aware of. "Circuit ID" format is defined by whatever system an access company uses to manage its inventory of circuits. The most common such system in the US is TIRKS(R), which is now developed by Telcordia. It was initially developed by AT&T Bell Labs in the late 1970's. Fortunately, it has managed to evolve a bit since then. Most of the baby Bells continue to use it, I think. There's a really short Wikipedia description of TIRKS at http://en.wikipedia.org/wiki/TIRKS In short, a Circuit ID uniquely identifies a circuit within an access provider's operations systems. Many different types of circuits exist (POTS, T1, DS3, SONET, etc.). Different types use different formats. Barbara -----Original Message----- From: Clive D.W. Feather [mailto:clive@demon.net] Sent: Wednesday, April 25, 2007 4:37 AM To: Henning Schulzrinne Cc: Stark, Barbara; GEOPRIV; ECRIT Subject: Re: [Ecrit] Circuit ID Henning Schulzrinne said: > Just out of curiosity, what does a circuit ID look like? Is that the=20 > NAS identifier used in RADIUS or where is it visible? In the UK it's not currently standardised, though we're looking at it. I would *expect* it to end up something like BT-EA12345678 or 001-EA12345678 where the first part identifies the circuit owner (either a short name or a CUPID) and the second half is decided by the provider; BT appear to use a two letter region code followed by an 8 digit number). >> Actually, given requirements for "naked" DSL, without an underlying=20 >> POTS phone number, we're moving to "Circuit ID". That's not the only scenario - the UK is looking at an arrangement whereby one telco (Openreach, part of BT) provides the circuit and another telco provides the call server and thus the number; Openreach and BT will have no visibility of the number - if any - allocated to the line. --=20 Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 26 11:57:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh6M2-0003n1-M9; Thu, 26 Apr 2007 11:57:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh6M2-0003mg-AT for ecrit@ietf.org; Thu, 26 Apr 2007 11:57:58 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh6M0-0004jK-3f for ecrit@ietf.org; Thu, 26 Apr 2007 11:57:58 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 26 Apr 2007 11:57:55 -0400 id 015884A4.4630CC03.00006DD1 In-Reply-To: <80103DF1-11E1-47F0-91A5-E77203FD298E@cs.columbia.edu> References: <027001c78767$30e677a0$640fa8c0@cis.neustar.com> <4E631237-4F68-4128-87B9-9B2F2E5CC034@hxr.us> <80103DF1-11E1-47F0-91A5-E77203FD298E@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <43DB12D8-E875-4FFA-8F4B-6DE7CA879BFF@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles Date: Thu, 26 Apr 2007 11:57:51 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 25, 2007, at 10:03 PM, Henning Schulzrinne wrote: > They have to intersect at the location of the caller, at least, > since every single service polygon covers the caller's location by > definition. Can you give an example where they would not intersect? Sorry. You are right. I was thinking of separate mappings per service. Still, that does not get around... >> Plus LoST services can be more than emergency services. How is a >> LIS suppose to know. this. >> I'm beginning to see Martin's point. We seem to be bending over >> backwards to avoid doing dereferences in LoST. Perhaps that is >> the real answer. > > But that has its own set of problems, amply discussed earlier. The > problem gets worse if you have multiple non-emergency services > since they can be provided by multiple independent LoST hierarchies. I don't understand this point. > I think we need to be somewhat practical. We can imagine all kinds > of strange scenarios, but it seems unwise to create a whole lot of > machinery for a special case (location hiding) that is hopefully > rare or transient, and then optimize corner cases of that scenario. > Clearly, in the US, there's only a single 9-1-1 service. Just because a couple of technologists believe it is a rare or transient use case, doesn't make it so. After all, some of these same technologists believed that legislatures would simply require the location information to flow unimpeded. But now that seems to be an unlikely reality. Given the size of some of the access networks that have expressed interest in location hiding, I doubt it will be rare. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 26 12:44:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh758-00053k-G8; Thu, 26 Apr 2007 12:44:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh757-00053M-Fj for ecrit@ietf.org; Thu, 26 Apr 2007 12:44:33 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh756-000561-0M for ecrit@ietf.org; Thu, 26 Apr 2007 12:44:33 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 26 Apr 2007 12:44:31 -0400 id 015884A9.4630D6EF.00007814 In-Reply-To: References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <48691367-FB10-48CD-8749-6E0894D7BDF3@cs.columbia.edu> <38F51001-96C5-4BF5-BEB6-71E9998A6387@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8FFF02FC-D02E-4190-9F45-341257F11A85@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles (was: Consensus Call) Date: Thu, 26 Apr 2007 12:44:30 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 25, 2007, at 11:12 PM, Henning Schulzrinne wrote: > I don't see what this has to do with profiles. If I understood you > correctly, you were suggesting a flag indicating a modification of > the matching algorithm (point vs. whole polygon), which seems > orthogonal to profiles. Subsequent discussion seems to indicate > that this may not work in all cases. Ok. That is another way of solving the problem. But the subsequent discussion was not about the flag or matching, but rather about the fact that there are different boundaries for different services and that the LIS does not know the service type being queried via LoST. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 26 12:45:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh76K-0008Ta-W4; Thu, 26 Apr 2007 12:45:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh76K-0008Q7-Cu for ecrit@ietf.org; Thu, 26 Apr 2007 12:45:48 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh76J-0005MB-6e for ecrit@ietf.org; Thu, 26 Apr 2007 12:45:48 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 26 Apr 2007 12:45:46 -0400 id 015884A9.4630D73A.00007865 In-Reply-To: References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <4991CDE0-BA87-42E5-BCEA-2A8ED6324FA1@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D8F471D-84F5-412D-9BFC-26209827F3CD@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Thu, 26 Apr 2007 12:45:45 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org So you are advocating the creation of a schema that glues the two different schemas together, so it can be validated via the XML namespace? If so, ok. But that is just one step further than a profile identifier. -andy On Apr 25, 2007, at 11:14 PM, Henning Schulzrinne wrote: > The point I'm making is that the namespace identifier is sufficient > to determine what XML is valid, since you can determine the > corresponding schema, whether expressed in RelaxNG or XML Schema. > We are not using DTD. > > Thus, I fail to see what this has to do with another label. We > don't have profile labels in SIP presence, for example, and the > problem is pretty much the same. > > On Apr 25, 2007, at 9:47 AM, Andrew Newton wrote: > >> XML validity and XML namespaces are separate features. XML >> validity, in the form of DTDs, existed before XML namespaces. It >> just so happens that the more modern XML schema languages, such as >> Relax NG and XML Schema, account for XML namespaces and allow the >> validity to check the namespace, which wasn't possible with DTDs. >> >> However, validation checking will not solve this problem, as each >> XML fragment is valid against its schema. This means such >> validation must be done by the application. >> >> -andy >> > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 26 12:47:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh77t-0003sf-1r; Thu, 26 Apr 2007 12:47:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh77r-0003i0-1Y for ecrit@ietf.org; Thu, 26 Apr 2007 12:47:23 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh77p-0005d3-SA for ecrit@ietf.org; Thu, 26 Apr 2007 12:47:23 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 26 Apr 2007 12:47:21 -0400 id 015884A9.4630D799.0000788F In-Reply-To: <988DE847-3F00-4B5B-B39C-1C0137ED784D@cs.columbia.edu> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <93297558-09D6-472E-8F04-3BA6734C1833@hxr.us> <146B26C8-0988-45B6-95D1-EB4266DEE300@cs.columbia.edu> <988DE847-3F00-4B5B-B39C-1C0137ED784D@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles (was: Consensus Call) - hole Date: Thu, 26 Apr 2007 12:47:20 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 25, 2007, at 11:16 PM, Henning Schulzrinne wrote: > We seem to be talking past each other. The strange part is that > this extension is specific to LoST usage and makes no sense > elsewhere. Obviously, there is no syntactic problem. I'm glad we are past this point. :) > You still haven't answered what purpose the identifier serves, > given that all other 4119 applications seem to survive just fine > without it. To identify the validity of the combination of data from two different schemas. What are the other widely deployed 4119 applications? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 26 12:48:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh78m-0006MT-W0; Thu, 26 Apr 2007 12:48:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh78m-0006LM-Iw for ecrit@ietf.org; Thu, 26 Apr 2007 12:48:20 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh78l-0005lq-D8 for ecrit@ietf.org; Thu, 26 Apr 2007 12:48:20 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3QGmAWI014681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Apr 2007 12:48:10 -0400 (EDT) In-Reply-To: <8FFF02FC-D02E-4190-9F45-341257F11A85@hxr.us> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <48691367-FB10-48CD-8749-6E0894D7BDF3@cs.columbia.edu> <38F51001-96C5-4BF5-BEB6-71E9998A6387@hxr.us> <8FFF02FC-D02E-4190-9F45-341257F11A85@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6114F32E-2146-4591-A9B8-5DF2D65CA4A2@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles (was: Consensus Call) Date: Thu, 26 Apr 2007 12:49:39 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Right - but the multiple-service problem makes an exact-match flag no longer particularly helpful. On Apr 26, 2007, at 12:44 PM, Andrew Newton wrote: > Ok. That is another way of solving the problem. But the > subsequent discussion was not about the flag or matching, but > rather about the fact that there are different boundaries for > different services and that the LIS does not know the service type > being queried via LoST. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 26 12:51:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7Ba-0007cL-Lx; Thu, 26 Apr 2007 12:51:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7BZ-0007Z1-AC for ecrit@ietf.org; Thu, 26 Apr 2007 12:51:13 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh7BY-0006A5-4J for ecrit@ietf.org; Thu, 26 Apr 2007 12:51:13 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3QGpBu5015318 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Apr 2007 12:51:11 -0400 (EDT) In-Reply-To: References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <93297558-09D6-472E-8F04-3BA6734C1833@hxr.us> <146B26C8-0988-45B6-95D1-EB4266DEE300@cs.columbia.edu> <988DE847-3F00-4B5B-B39C-1C0137ED784D@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <805E1A85-5EA1-495C-A0BD-AF0C470598C2@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles (was: Consensus Call) - hole Date: Thu, 26 Apr 2007 12:52:40 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 26, 2007, at 12:47 PM, Andrew Newton wrote: > >> You still haven't answered what purpose the identifier serves, >> given that all other 4119 applications seem to survive just fine >> without it. > > To identify the validity of the combination of data from two > different schemas. What are the other widely deployed 4119 > applications? Widely deployed is probably the wrong phrase for any of these things, but plain old presence, as in RFC 4079. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 26 13:12:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7Vh-0002Ln-TZ; Thu, 26 Apr 2007 13:12:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh7Vg-0002Lg-AZ for ecrit@ietf.org; Thu, 26 Apr 2007 13:12:00 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh7Vf-0001eg-4F for ecrit@ietf.org; Thu, 26 Apr 2007 13:12:00 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1Hh7VU-0001t8-Ge; Thu, 26 Apr 2007 12:11:48 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Profiles Date: Thu, 26 Apr 2007 13:11:55 -0400 Message-ID: <04e901c78825$ff6eafc0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <43DB12D8-E875-4FFA-8F4B-6DE7CA879BFF@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceIG6UsgCIoZpVvT+eumReNjShnUwACcZmg 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > >> Plus LoST services can be more than emergency services. How is a > >> LIS suppose to know. > > this. I think this is simple: it doesn't, and it doesn't care. A paying customer will get fine grained location, and can use LoST. "Paying customer" could be the endpoint or the VSP. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 26 14:01:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh8H4-0004rQ-Pr; Thu, 26 Apr 2007 14:00:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh8H3-0004nz-Un for ecrit@ietf.org; Thu, 26 Apr 2007 14:00:57 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh8H2-0004t6-MM for ecrit@ietf.org; Thu, 26 Apr 2007 14:00:57 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3QI0tkK027753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Apr 2007 14:00:55 -0400 (EDT) In-Reply-To: <3D8F471D-84F5-412D-9BFC-26209827F3CD@hxr.us> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <4991CDE0-BA87-42E5-BCEA-2A8ED6324FA1@cs.columbia.edu> <3D8F471D-84F5-412D-9BFC-26209827F3CD@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Thu, 26 Apr 2007 14:02:24 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'm somehow missing the problem. All namespaces, and thus, the corresponding schema, are already identified in the XML instance, for GML and the other LoST components. What additional information would I need to provide? Why would I need to glue together the schema? As far as I know, a single XML document can have components from multiple schema. This seems common for XML documents, including the work in XMPP or NetConf. Neither, as far as I know, has the notion of a profile. On Apr 26, 2007, at 12:45 PM, Andrew Newton wrote: > So you are advocating the creation of a schema that glues the two > different schemas together, so it can be validated via the XML > namespace? If so, ok. But that is just one step further than a > profile identifier. > > -andy > > On Apr 25, 2007, at 11:14 PM, Henning Schulzrinne wrote: > >> The point I'm making is that the namespace identifier is >> sufficient to determine what XML is valid, since you can determine >> the corresponding schema, whether expressed in RelaxNG or XML >> Schema. We are not using DTD. >> >> Thus, I fail to see what this has to do with another label. We >> don't have profile labels in SIP presence, for example, and the >> problem is pretty much the same. >> >> On Apr 25, 2007, at 9:47 AM, Andrew Newton wrote: >> >>> XML validity and XML namespaces are separate features. XML >>> validity, in the form of DTDs, existed before XML namespaces. It >>> just so happens that the more modern XML schema languages, such >>> as Relax NG and XML Schema, account for XML namespaces and allow >>> the validity to check the namespace, which wasn't possible with >>> DTDs. >>> >>> However, validation checking will not solve this problem, as each >>> XML fragment is valid against its schema. This means such >>> validation must be done by the application. >>> >>> -andy >>> >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 26 14:09:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh8Ou-0007xm-Sc; Thu, 26 Apr 2007 14:09:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh8Ot-0007ul-OY for ecrit@ietf.org; Thu, 26 Apr 2007 14:09:03 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hh8Os-0002VM-D6 for ecrit@ietf.org; Thu, 26 Apr 2007 14:09:03 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3QI91S2029624 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Apr 2007 14:09:01 -0400 (EDT) In-Reply-To: <43DB12D8-E875-4FFA-8F4B-6DE7CA879BFF@hxr.us> References: <027001c78767$30e677a0$640fa8c0@cis.neustar.com> <4E631237-4F68-4128-87B9-9B2F2E5CC034@hxr.us> <80103DF1-11E1-47F0-91A5-E77203FD298E@cs.columbia.edu> <43DB12D8-E875-4FFA-8F4B-6DE7CA879BFF@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles Date: Thu, 26 Apr 2007 14:10:31 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 26, 2007, at 11:57 AM, Andrew Newton wrote: >> But that has its own set of problems, amply discussed earlier. The >> problem gets worse if you have multiple non-emergency services >> since they can be provided by multiple independent LoST hierarchies. > > I don't understand this point. > I'm assuming that the LoST resolver would need to convert a reference to a value. I'm also assuming that different services use different LoST hierarchies, as currently defined in the architecture spec. For example, the urn:service:food.pizza might have a different tree than emergency services. There are now two choices: (1) The ISP has to run LoST resolvers for every possible service, including pizza. It also has to decide which services get location information and which don't. (2) If not, there have to be two resolvers, at least. Now, there's a fairly complicated set of steps: (a) UA gets LbyR; it has no way of knowing whether the LbyR provides coarse location, fine-grained location or no location at all. Thus, the UA has to try to resolve the reference, getting a failure, according to Richard's proposal. Another round-trip delay added. With that failure, it now proceeds to step 2. (If there were no failure, it would presumably include the location value returned in the LoST query, since it has no way of knowing whether the LIS restricts access to the reference by IP address, as proposed by Richard, so it can't know whether the LoST server would actually be able to resolve a reference handed to it by the LIS.) (b) Let's assume that the standard process is to directly issue a LoST query or that this happens after a failure. The UA has no idea which services are supported by the ISP-provided LoST server [it can find this out with yet another LoST query] and which services allow fine-grained location. These two sets may not be the same. Indeed, it has no good way to find such a server. (DHCP may not cut it, as it has the same issues that are leading us to using L7 LCP.) Now, the LoST server may or may not be able to dereference or be willing to provide fine-grained location for that service. Thus, the LoST query might fail. At that point, the device might try to use other location-information or maybe a different LoST server, maybe derived from mapping its IP address. Even if it succeeds, the reference may or may not be dereferencable by the service provider, but that's something the UA can't know ahead of time, either. This all seems pretty messy to me, with a low chance of working in real life, but lots of chances for a very frustrating user experience and calls to the help line. Just testing all these combinations of cases seems like a nightmare. >> I think we need to be somewhat practical. We can imagine all kinds >> of strange scenarios, but it seems unwise to create a whole lot of >> machinery for a special case (location hiding) that is hopefully >> rare or transient, and then optimize corner cases of that >> scenario. Clearly, in the US, there's only a single 9-1-1 service. > > Just because a couple of technologists believe it is a rare or > transient use case, doesn't make it so. After all, some of these > same technologists believed that legislatures would simply require > the location information to flow unimpeded. But now that seems to > be an unlikely reality. Given the size of some of the access > networks that have expressed interest in location hiding, I doubt > it will be rare. Location hiding may or may not be rare, but only the combination of hiding with multiple services causes some complexity. However, with Brian's proposal, the complexity is limited to the service provider in that case, which is in a much better position to deal with it. In the vast majority of cases (single emergency number, no holes) things work fine. In the other cases, there's more effort required, but no new protocol work and no additional client complexity or call setup delay. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 26 19:12:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhD8u-0006PW-FH; Thu, 26 Apr 2007 19:12:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhD8t-0006PR-6q for ecrit@ietf.org; Thu, 26 Apr 2007 19:12:51 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhD8r-0004yE-SX for ecrit@ietf.org; Thu, 26 Apr 2007 19:12:51 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3QNCcuv008165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Apr 2007 16:12:38 -0700 Received: from [76.102.225.135] (vpn-10-50-0-169.qualcomm.com [10.50.0.169]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3QNCZIf020592; Thu, 26 Apr 2007 16:12:36 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <027001c78767$30e677a0$640fa8c0@cis.neustar.com> <4E631237-4F68-4128-87B9-9B2F2E5CC034@hxr.us> <80103DF1-11E1-47F0-91A5-E77203FD298E@cs.columbia.edu> <43DB12D8-E875-4FFA-8F4B-6DE7CA879BFF@hxr.us> Date: Thu, 26 Apr 2007 16:12:34 -0700 To: Henning Schulzrinne , Andrew Newton From: Ted Hardie Subject: Re: [Ecrit] Profiles Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > >Location hiding may or may not be rare, but only the combination of hiding with multiple services causes some complexity. Are there other services for which the kind of location-is-hidden-but-service-supported tricks we're planning for ECRIT make any sense? I've been trying to find something that fits that, and my imagination is failing. It seems more likely that the service will simply be unsupported if someone hasn't paid for location in those cases. The hack James suggested, of including the service in the request to the LIS, begins to look like a reasonable choice, if there are no others. Have the request to the LIS include an appropriate emergency service flag if appropriate seems to simplify the problem at least some. Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 26 22:51:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhGXz-000436-3x; Thu, 26 Apr 2007 22:50:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhGXx-00042v-Di for ecrit@ietf.org; Thu, 26 Apr 2007 22:50:57 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HhGXv-0001v4-75 for ecrit@ietf.org; Thu, 26 Apr 2007 22:50:57 -0400 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 26 Apr 2007 22:50:54 -0400 id 015884CE.4631650E.0000051C In-Reply-To: References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <4991CDE0-BA87-42E5-BCEA-2A8ED6324FA1@cs.columbia.edu> <3D8F471D-84F5-412D-9BFC-26209827F3CD@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <58F11B2F-0FE7-41FD-9938-3B560968942B@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Thu, 26 Apr 2007 22:50:48 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org There is validation about the XML components being glued together. A LoST server must assume that civicAddr XML preceded by GML is 3825 location information. Having software make assumptions is usually not a good idea. -andy On Apr 26, 2007, at 2:02 PM, Henning Schulzrinne wrote: > I'm somehow missing the problem. All namespaces, and thus, the > corresponding schema, are already identified in the XML instance, > for GML and the other LoST components. What additional information > would I need to provide? Why would I need to glue together the schema? > > As far as I know, a single XML document can have components from > multiple schema. This seems common for XML documents, including the > work in XMPP or NetConf. Neither, as far as I know, has the notion > of a profile. > > On Apr 26, 2007, at 12:45 PM, Andrew Newton wrote: > >> So you are advocating the creation of a schema that glues the two >> different schemas together, so it can be validated via the XML >> namespace? If so, ok. But that is just one step further than a >> profile identifier. >> >> -andy >> >> On Apr 25, 2007, at 11:14 PM, Henning Schulzrinne wrote: >> >>> The point I'm making is that the namespace identifier is >>> sufficient to determine what XML is valid, since you can >>> determine the corresponding schema, whether expressed in RelaxNG >>> or XML Schema. We are not using DTD. >>> >>> Thus, I fail to see what this has to do with another label. We >>> don't have profile labels in SIP presence, for example, and the >>> problem is pretty much the same. >>> >>> On Apr 25, 2007, at 9:47 AM, Andrew Newton wrote: >>> >>>> XML validity and XML namespaces are separate features. XML >>>> validity, in the form of DTDs, existed before XML namespaces. >>>> It just so happens that the more modern XML schema languages, >>>> such as Relax NG and XML Schema, account for XML namespaces and >>>> allow the validity to check the namespace, which wasn't possible >>>> with DTDs. >>>> >>>> However, validation checking will not solve this problem, as >>>> each XML fragment is valid against its schema. This means such >>>> validation must be done by the application. >>>> >>>> -andy >>>> >>> > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 26 22:53:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhGaI-0004YY-Bo; Thu, 26 Apr 2007 22:53:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhGaH-0004YN-GD for ecrit@ietf.org; Thu, 26 Apr 2007 22:53:21 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhGaG-0007s8-8n for ecrit@ietf.org; Thu, 26 Apr 2007 22:53:21 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3R2rIWN027900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Apr 2007 22:53:19 -0400 (EDT) In-Reply-To: <58F11B2F-0FE7-41FD-9938-3B560968942B@hxr.us> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <4991CDE0-BA87-42E5-BCEA-2A8ED6324FA1@cs.columbia.edu> <3D8F471D-84F5-412D-9BFC-26209827F3CD@hxr.us> <58F11B2F-0FE7-41FD-9938-3B560968942B@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1A8339C1-B5C4-425F-A697-0F93AC93754A@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Thu, 26 Apr 2007 22:53:16 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I've asked a few times, but why would LoST care that the civicAddr is derived from DHCP as opposed to, say, entered manually? Obviously, the current profile doesn't convey that information, either. On Apr 26, 2007, at 10:50 PM, Andrew Newton wrote: > There is validation about the XML components being glued together. > A LoST server must assume that civicAddr XML preceded by GML is > 3825 location information. Having software make assumptions is > usually not a good idea. > > -andy > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 26 22:58:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhGer-0006wv-De; Thu, 26 Apr 2007 22:58:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhGeq-0006wk-Ig for ecrit@ietf.org; Thu, 26 Apr 2007 22:58:04 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HhGep-00033p-Aw for ecrit@ietf.org; Thu, 26 Apr 2007 22:58:04 -0400 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 26 Apr 2007 22:58:01 -0400 id 015884CE.463166B9.00000648 In-Reply-To: <04e901c78825$ff6eafc0$640fa8c0@cis.neustar.com> References: <04e901c78825$ff6eafc0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8BD959C9-C4AA-459F-AE1D-8F391BFC084E@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles Date: Thu, 26 Apr 2007 22:58:00 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 26, 2007, at 1:11 PM, Brian Rosen wrote: > I think this is simple: it doesn't, and it doesn't care. A paying > customer > will get fine grained location, and can use LoST. "Paying > customer" could > be the endpoint or the VSP. For clarification, are you applying this to emergency services, or to other services? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 26 22:59:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhGgc-0001Tk-DM; Thu, 26 Apr 2007 22:59:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhGgb-0001Tb-9i for ecrit@ietf.org; Thu, 26 Apr 2007 22:59:53 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhGgZ-0001AN-V4 for ecrit@ietf.org; Thu, 26 Apr 2007 22:59:53 -0400 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 26 Apr 2007 22:59:51 -0400 id 015884CE.46316727.00000697 In-Reply-To: References: <027001c78767$30e677a0$640fa8c0@cis.neustar.com> <4E631237-4F68-4128-87B9-9B2F2E5CC034@hxr.us> <80103DF1-11E1-47F0-91A5-E77203FD298E@cs.columbia.edu> <43DB12D8-E875-4FFA-8F4B-6DE7CA879BFF@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <85829981-6B91-4697-8A64-F9E4CADCCFFD@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles Date: Thu, 26 Apr 2007 22:59:49 -0400 To: Ted Hardie X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 26, 2007, at 7:12 PM, Ted Hardie wrote: > The hack James suggested, of including the service in the request > to the LIS, > begins to look like a reasonable choice, if there are no others. > Have the request > to the LIS include an appropriate emergency service flag if > appropriate seems > to simplify the problem at least some. I'm not against this. I thought others were, including James. I don't know how it would work with DHCP and LLDP-MED. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 26 23:03:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhGkI-0004PK-CX; Thu, 26 Apr 2007 23:03:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhGkG-0004PB-Je for ecrit@ietf.org; Thu, 26 Apr 2007 23:03:40 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhGkF-0001eF-EI for ecrit@ietf.org; Thu, 26 Apr 2007 23:03:40 -0400 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 26 Apr 2007 23:03:39 -0400 id 015884CD.4631680B.00000726 In-Reply-To: <1A8339C1-B5C4-425F-A697-0F93AC93754A@cs.columbia.edu> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <4991CDE0-BA87-42E5-BCEA-2A8ED6324FA1@cs.columbia.edu> <3D8F471D-84F5-412D-9BFC-26209827F3CD@hxr.us> <58F11B2F-0FE7-41FD-9938-3B560968942B@hxr.us> <1A8339C1-B5C4-425F-A697-0F93AC93754A@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Thu, 26 Apr 2007 23:03:37 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 26, 2007, at 10:53 PM, Henning Schulzrinne wrote: > I've asked a few times, but why would LoST care that the civicAddr > is derived from DHCP as opposed to, say, entered manually? > Obviously, the current profile doesn't convey that information, > either. I don't think it should care. The point wasn't that it came from DHCP, the point was that it was a 3825-like compound location. Sorry if that was confusing. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 26 23:26:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhH6n-0001cF-Qt; Thu, 26 Apr 2007 23:26:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhH6n-0001cA-Fn for ecrit@ietf.org; Thu, 26 Apr 2007 23:26:57 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhH6m-0007m7-8b for ecrit@ietf.org; Thu, 26 Apr 2007 23:26:57 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3R3QoUo025533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Apr 2007 23:26:55 -0400 (EDT) In-Reply-To: References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <4991CDE0-BA87-42E5-BCEA-2A8ED6324FA1@cs.columbia.edu> <3D8F471D-84F5-412D-9BFC-26209827F3CD@hxr.us> <58F11B2F-0FE7-41FD-9938-3B560968942B@hxr.us> <1A8339C1-B5C4! ! -425F-A697-0F93AC93754A@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <57D0B17F-E13B-4EA9-85C0-5803C02E9390@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Thu, 26 Apr 2007 23:26:46 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Maybe we need to restart this discussion, as I'm lost. I still haven't heard a single technical argument as to what additional information a profile name, outside the XML, contains that would not be visible in the namespace and tag declarations. I was taught that XML documents could stand alone, without additional meta information, once you have pointers to the namespaces. Do you have a citation that indicates that this is wrong? I'm looking at Walmsley, "Definitive XML Schema" and it says: "Instances can be related to schemas in a variety of ways ... * ... * dereferencing the namespace. The namespace can be dereferenced to retrieve a schema document or resource directory." In this case, this is a URN and all relevant schema will be known to the receiver and we have a one-to-one relationship between namespace and schema, so there's no ambiguity. (Walmsley points out various reasons why an HTTP-like namespace identifier may not be a good idea, but none of them seem to apply here.) Also, as I mentioned before, XMPP seems to follow roughly the same model as 4119. E.g., the core spec defines a schema and namespace urn:ietf:params:xml:ns:xmpp-sasl and urn:ietf:params:xml:ns:xmpp-tls. There is no profile indication, as far as I can tell, even for the various extensions (say, namespace jabber:x:data). Can you please provide a reference or other authority that supports or explains your view? Henning On Apr 26, 2007, at 11:03 PM, Andrew Newton wrote: > > On Apr 26, 2007, at 10:53 PM, Henning Schulzrinne wrote: > >> I've asked a few times, but why would LoST care that the civicAddr >> is derived from DHCP as opposed to, say, entered manually? >> Obviously, the current profile doesn't convey that information, >> either. > > I don't think it should care. The point wasn't that it came from > DHCP, the point was that it was a 3825-like compound location. > Sorry if that was confusing. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Apr 26 23:54:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhHXN-0005h7-Eq; Thu, 26 Apr 2007 23:54:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhHXM-0005gx-FD for ecrit@ietf.org; Thu, 26 Apr 2007 23:54:24 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhHXL-0006ig-B6 for ecrit@ietf.org; Thu, 26 Apr 2007 23:54:24 -0400 Received: from [10.0.1.110] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 26 Apr 2007 23:54:23 -0400 id 015884CE.463173EF.00000DC4 In-Reply-To: <57D0B17F-E13B-4EA9-85C0-5803C02E9390@cs.columbia.edu> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <4991CDE0-BA87-42E5-BCEA-2A8ED6324FA1@cs.columbia.edu> <3D8F471D-84F5-412D-9BFC-26209827F3CD@hxr.us> <58F11B2F-0FE7-41FD-9938-3B560968942B@hxr.us> <1A8339C1-B5C4! ! -425F-A697-0F93AC93754A@cs.columbia.edu> <57D0B17F-E13B-4EA9-85C0-5803C02E9390@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Thu, 26 Apr 2007 23:54:21 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Perhaps we do need to restart the discussion. I was never arguing for anything as strong as XML validity. That was one of your arguments. However, if you take a schema that has the following definition (pasted from 4119): Now take a look at the following from draft-ietf-geopriv-pdif-lo- profile: -43.5723 153.21760 2 What is there to say that can legally follow ? Nothing. From an XML processors perspective, it could be GML followed by some other stuff that can be ignored (look at processContents="lax"). What's the cue to the application that it shouldn't ignore ? How does it know that is important information, if even it may not have the schema in its catalog? -andy On Apr 26, 2007, at 11:26 PM, Henning Schulzrinne wrote: > Maybe we need to restart this discussion, as I'm lost. I still > haven't heard a single technical argument as to what additional > information a profile name, outside the XML, contains that would > not be visible in the namespace and tag declarations. I was taught > that XML documents could stand alone, without additional meta > information, once you have pointers to the namespaces. Do you have > a citation that indicates that this is wrong? > > I'm looking at Walmsley, "Definitive XML Schema" and it says: > > "Instances can be related to schemas in a variety of ways ... > > * ... > * dereferencing the namespace. The namespace can be dereferenced to > retrieve a schema document or resource directory." > > In this case, this is a URN and all relevant schema will be known > to the receiver and we have a one-to-one relationship between > namespace and schema, so there's no ambiguity. (Walmsley points out > various reasons why an HTTP-like namespace identifier may not be a > good idea, but none of them seem to apply here.) > > Also, as I mentioned before, XMPP seems to follow roughly the same > model as 4119. E.g., the core spec defines a schema and namespace > urn:ietf:params:xml:ns:xmpp-sasl and urn:ietf:params:xml:ns:xmpp- > tls. There is no profile indication, as far as I can tell, even for > the various extensions (say, namespace jabber:x:data). > > Can you please provide a reference or other authority that supports > or explains your view? > > Henning > > On Apr 26, 2007, at 11:03 PM, Andrew Newton wrote: > >> >> On Apr 26, 2007, at 10:53 PM, Henning Schulzrinne wrote: >> >>> I've asked a few times, but why would LoST care that the >>> civicAddr is derived from DHCP as opposed to, say, entered >>> manually? Obviously, the current profile doesn't convey that >>> information, either. >> >> I don't think it should care. The point wasn't that it came from >> DHCP, the point was that it was a 3825-like compound location. >> Sorry if that was confusing. >> >> -andy > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 01:07:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhIfu-0008G8-6W; Fri, 27 Apr 2007 01:07:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhIft-0008DH-5D for ecrit@ietf.org; Fri, 27 Apr 2007 01:07:17 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhIfr-0002lX-SN for ecrit@ietf.org; Fri, 27 Apr 2007 01:07:17 -0400 X-SEF-Processed: 5_0_0_910__2007_04_27_00_13_59 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 27 Apr 2007 00:13:59 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 00:07:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Profiles Date: Fri, 27 Apr 2007 00:07:11 -0500 Message-ID: In-Reply-To: <85829981-6B91-4697-8A64-F9E4CADCCFFD@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Profiles Thread-Index: AceIeCLdSkf0dgffR1eXCKJv6EAISQAETsRQ From: "Winterbottom, James" To: "Andrew Newton" , "Ted Hardie" X-OriginalArrivalTime: 27 Apr 2007 05:07:12.0811 (UTC) FILETIME=[EA6ABFB0:01C78889] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org If this is the best way to address the problem then sobeit, though it=0D=0A= would not be my first choice of solution.=0D=0AI agree with your analysis o= n DHCP and LLDP-MED in that I don't know how=0D=0Ato make it work with them= either, does it have to=3F=0D=0ASome functionality is simply going to be m= ore easily accomplished using=0D=0Aone solution over another.=0D=0A=0D=0ACh= eers=0D=0AJames=20=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A= > From: Andrew Newton [mailto:andy@hxr.us]=0D=0A> Sent: Friday, 27 April 20= 07 1:00 PM=0D=0A> To: Ted Hardie=0D=0A> Cc: ECRIT=0D=0A> Subject: Re: [Ecri= t] Profiles=0D=0A>=20=0D=0A>=20=0D=0A> On Apr 26, 2007, at 7:12 PM, Ted Har= die wrote:=0D=0A>=20=0D=0A> > The hack James suggested, of including the se= rvice in the request=0D=0A> > to the LIS,=0D=0A> > begins to look like a re= asonable choice, if there are no others.=0D=0A> > Have the request=0D=0A> >= to the LIS include an appropriate emergency service flag if=0D=0A> > appro= priate seems=0D=0A> > to simplify the problem at least some.=0D=0A>=20=0D=0A= > I'm not against this. I thought others were, including James. I=0D=0A> = don't know how it would work with DHCP and LLDP-MED.=0D=0A>=20=0D=0A> -andy=0D= =0A>=20=0D=0A> _______________________________________________=0D=0A> Ecrit= mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mailman/li= stinfo/ecrit=0D=0A=0D=0A---------------------------------------------------= ---------------------------------------------=0D=0AThis message is for the = designated recipient only and may=0D=0Acontain privileged, proprietary, or = otherwise private information. =20=0D=0AIf you have received it in error, p= lease notify the sender=0D=0Aimmediately and delete the original. Any unau= thorized use of=0D=0Athis email is prohibited.=0D=0A-----------------------= -------------------------------------------------------------------------=0D= =0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 05:12:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhMV4-0005bU-Je; Fri, 27 Apr 2007 05:12:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhMU2-00059A-E2 for ecrit@ietf.org; Fri, 27 Apr 2007 05:11:18 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HhMPA-0007GE-UT for ecrit@ietf.org; Fri, 27 Apr 2007 05:06:19 -0400 Received: (qmail invoked by alias); 27 Apr 2007 09:06:15 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp053) with SMTP; 27 Apr 2007 11:06:15 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19qm/lS0vFqm4sAyl8iU8f9PGx7iBK6kuXsezExMz cvN7t8p5qxzGiO Message-ID: <4631BD06.8040308@gmx.net> Date: Fri, 27 Apr 2007 11:06:14 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Ecrit] IETF ECRIT / IEEE emergency services information sharing event X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, we have produced a video podcast of the IETF ECRIT / IEEE emergency services information sharing event at the IETF#68 meeting in Prague, 19th March. Please find the video and the slides at: http://www.emergency-services-coordination.info/ieee-ecrit-2007.html We aren’t podcast experts, as you might easily recognize. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 05:13:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhMW8-0006PO-N7; Fri, 27 Apr 2007 05:13:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhMTz-00058T-4h for ecrit@ietf.org; Fri, 27 Apr 2007 05:11:15 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HhMSW-0008CV-Io for ecrit@ietf.org; Fri, 27 Apr 2007 05:09:45 -0400 Received: (qmail invoked by alias); 27 Apr 2007 09:09:43 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp053) with SMTP; 27 Apr 2007 11:09:43 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+UEfpk4kSUASHO0KnmchO2t2Cfh7XoFmmYP4uWJc CjQc0bF1l+0VZw Message-ID: <4631BDD5.4030500@gmx.net> Date: Fri, 27 Apr 2007 11:09:41 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ecrit] =?windows-1252?q?ESW=9207=3A_Meeting_Minutes_=26_Picture?= =?windows-1252?q?s_Available?= X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, pictures from the meeting are available: http://www.emergency-services-coordination.info/2007/pics/index.html Meeting minutes (by Richard Barnes and by Roger Marshall) are available here: http://www.emergency-services-coordination.info/2007/ESW07_Notes_RichardBarnes.doc http://www.emergency-services-coordination.info/2007/ESW07_Notes_RogerMarshall.rtf Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 07:36:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhOkW-0003FK-Ij; Fri, 27 Apr 2007 07:36:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhOkV-0003FA-LM for ecrit@ietf.org; Fri, 27 Apr 2007 07:36:27 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhOkU-0007I8-EN for ecrit@ietf.org; Fri, 27 Apr 2007 07:36:27 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HhOk8-00055x-Bk; Fri, 27 Apr 2007 06:36:04 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] Profiles Date: Fri, 27 Apr 2007 07:36:22 -0400 Message-ID: <069601c788c0$49d67bc0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8BD959C9-C4AA-459F-AE1D-8F391BFC084E@hxr.us> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceId9gEollc5wEHRiColyzs+XufbwASD2cg 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org We need a solution for emergency calls. If we use the "return coarse information" then the coarse information is for emergency calls, and may not work for any other purpose If we have another solution for emergency calls, such as LoST dereference, we may not need coarse location. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Thursday, April 26, 2007 10:58 PM > To: Brian Rosen > Cc: 'Henning Schulzrinne'; 'ECRIT' > Subject: Re: [Ecrit] Profiles > > > On Apr 26, 2007, at 1:11 PM, Brian Rosen wrote: > > > I think this is simple: it doesn't, and it doesn't care. A paying > > customer > > will get fine grained location, and can use LoST. "Paying > > customer" could > > be the endpoint or the VSP. > > For clarification, are you applying this to emergency services, or to > other services? > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 07:41:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhOpQ-0006bD-O0; Fri, 27 Apr 2007 07:41:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhOpP-0006b6-8x for ecrit@ietf.org; Fri, 27 Apr 2007 07:41:31 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhOpO-0000Dk-Ua for ecrit@ietf.org; Fri, 27 Apr 2007 07:41:31 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HhOp0-0007ZJ-UT; Fri, 27 Apr 2007 06:41:07 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Andrew Newton'" , "'Ted Hardie'" Subject: RE: [Ecrit] Profiles Date: Fri, 27 Apr 2007 07:41:25 -0400 Message-ID: <069701c788c0$fe38c460$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceIeCLdSkf0dgffR1eXCKJv6EAISQAETsRQAA3ICBA= 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think that location hiders will use HELD, and we don't need to bend the other LCPs to make them work with location hiding. I don't think we need the service in the request to the LIS. I don't like the implications of this for endpoint code in an area that has multiple emergency services. It would have to query the LIS for each service. If we use the "find the common polygon, pick a point in it, return an area with that point" works without this hack. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Friday, April 27, 2007 1:07 AM > To: Andrew Newton; Ted Hardie > Cc: ECRIT > Subject: RE: [Ecrit] Profiles > > If this is the best way to address the problem then sobeit, though it > would not be my first choice of solution. > I agree with your analysis on DHCP and LLDP-MED in that I don't know how > to make it work with them either, does it have to? > Some functionality is simply going to be more easily accomplished using > one solution over another. > > Cheers > James > > > > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Friday, 27 April 2007 1:00 PM > > To: Ted Hardie > > Cc: ECRIT > > Subject: Re: [Ecrit] Profiles > > > > > > On Apr 26, 2007, at 7:12 PM, Ted Hardie wrote: > > > > > The hack James suggested, of including the service in the request > > > to the LIS, > > > begins to look like a reasonable choice, if there are no others. > > > Have the request > > > to the LIS include an appropriate emergency service flag if > > > appropriate seems > > > to simplify the problem at least some. > > > > I'm not against this. I thought others were, including James. I > > don't know how it would work with DHCP and LLDP-MED. > > > > -andy > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 08:44:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhPoE-0007Um-MY; Fri, 27 Apr 2007 08:44:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhPoD-0007UX-3R; Fri, 27 Apr 2007 08:44:21 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhPoB-0003Zc-Ea; Fri, 27 Apr 2007 08:44:21 -0400 Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id l3RCiGPU032218; Fri, 27 Apr 2007 14:44:16 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id l3RCiGA3009166; Fri, 27 Apr 2007 14:44:16 +0200 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 14:44:15 +0200 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: Fri, 27 Apr 2007 14:44:14 +0200 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E701A9411A@MCHP7R6A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of "DHCP-based LoST Discovery Procedure" Thread-Index: AceIycMQ48+woUGsSQ+kRyeItjGung== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 27 Apr 2007 12:44:16.0009 (UTC) FILETIME=[C3EAAF90:01C788C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: jari.arkko@piuha.net, Marc Linsner , ECRIT Subject: [Ecrit] Review of "DHCP-based LoST Discovery Procedure" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all,=20 In the ECRIT working group we have discovered the need to define a discovery mechanism based on DHCP for LoST servers. Please find the document here: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery- 01.txt We would appreciate the review of this document.=20 Ciao Hannes PS: Marc has contacted the DHC chairs when we did the WGLC in ECRIT already but I couldn't find the message anymore. Hence, I just want to make sure that the document receives adequate review.=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 09:23:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhQPu-0007re-Tm; Fri, 27 Apr 2007 09:23:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhQPu-0007rX-3M for ecrit@ietf.org; Fri, 27 Apr 2007 09:23:18 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhQPs-0007xM-Sh for ecrit@ietf.org; Fri, 27 Apr 2007 09:23:18 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 27 Apr 2007 09:23:18 -0400 X-IronPort-AV: i="4.14,462,1170651600"; d="scan'208"; a="58789484:sNHT52788736" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3RDNGIo022982; Fri, 27 Apr 2007 09:23:16 -0400 Received: from [68.49.215.249] (che-vpn-cluster-2-30.cisco.com [10.86.242.30]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3RDNFGd011388; Fri, 27 Apr 2007 13:23:16 GMT In-Reply-To: References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <4991CDE0-BA87-42E5-BCEA-2A8ED6324FA1@cs.columbia.edu> <3D8F471D-84F5-412D-9BFC-26209827F3CD@hxr.us> <58F11B2F-0FE7-41FD-9938-3B560968942B@hxr.us> <1A8339C1-B5C4-425F-A697-0F93AC93754A@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <299A00CE-3894-4766-89DD-6BE1F5B823F5@cisco.com> Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Fri, 27 Apr 2007 09:23:13 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=763; t=1177680196; x=1178544196; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jschnizl@cisco.com; z=From:=20John=20Schnizlein=20 |Subject:=20Re=3A=20[Ecrit]=20Profiles=20(was=3A=20Consensus=20Call)=20-= 20namespaces |Sender:=20 |To:=20Andrew=20Newton=20; bh=agTbEmtEFy6d0MsCe9eNbpRWT8Y5x2NxyP9/518bzac=; b=Jp7QlDlqzVIY25MB+0lsXC8EsYWvBym+/7uqRnyIhezpDER5UbDbl0JIkSoSuu7gm7W1wyil I/xKHb4rE4gItZS04VQRb3lKnzzLCe1w1B4ub3CMiMz+/aef9z6YqthV; Authentication-Results: rtp-dkim-2; header.From=jschnizl@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org What is "a 3825-like compound location"? My understanding is that the XML for location obtained from the mechanism defined in RFC 3825 is just latitude, longitude and altitude, each with the correct number of significant digits. John On Apr 26, 2007, at 11:03 PM, Andrew Newton wrote: > > On Apr 26, 2007, at 10:53 PM, Henning Schulzrinne wrote: > >> I've asked a few times, but why would LoST care that the civicAddr >> is derived from DHCP as opposed to, say, entered manually? >> Obviously, the current profile doesn't convey that information, >> either. > > I don't think it should care. The point wasn't that it came from > DHCP, the point was that it was a 3825-like compound location. > Sorry if that was confusing. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 09:23:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhQQ5-0007v6-AR; Fri, 27 Apr 2007 09:23:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhQQ4-0007v1-O1 for ecrit@ietf.org; Fri, 27 Apr 2007 09:23:28 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhQQ3-0007zV-Hl for ecrit@ietf.org; Fri, 27 Apr 2007 09:23:28 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3RDNLWb001639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Apr 2007 09:23:24 -0400 (EDT) In-Reply-To: <069701c788c0$fe38c460$640fa8c0@cis.neustar.com> References: <069701c788c0$fe38c460$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <55F43709-BC3D-41CB-950F-DBB9C7D89BC6@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles Date: Fri, 27 Apr 2007 09:23:18 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 27, 2007, at 7:41 AM, Brian Rosen wrote: > I think that location hiders will use HELD, and we don't need to > bend the > other LCPs to make them work with location hiding. > Agreed. > I don't think we need the service in the request to the LIS. I > don't like > the implications of this for endpoint code in an area that has > multiple > emergency services. It would have to query the LIS for each service. This also has rather undesirable scaling properties: Since the UA can't know who is hiding location, it would have to query for all dozen or so emergency services, plus possibly non-emergency services individually. Thus, the non-hiding ISPs would have to pay for the business model of their hiding competitors by suffering a tenfold increase in query load. That doesn't seem particularly fair. A slightly better alternative is that the LIS would return service- specific polygons if they exist. In almost all cases, that would be one and only in specialized cases more than one. Still puts a burden of complexity on the UA, as the UA now has to track multiple polygons. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 09:49:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhQoq-0007nw-Ke; Fri, 27 Apr 2007 09:49:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhQop-0007nh-14 for ecrit@ietf.org; Fri, 27 Apr 2007 09:49:03 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HhQon-0008FA-Jt for ecrit@ietf.org; Fri, 27 Apr 2007 09:49:03 -0400 Received: (qmail invoked by alias); 27 Apr 2007 13:49:00 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp048) with SMTP; 27 Apr 2007 15:49:00 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/1J7B9m3j1p5oDMqZdlgz9Lo83OWahnne3r7NXvb 5t6BJ/voyumpZk Message-ID: <4631FF49.1040508@gmx.net> Date: Fri, 27 Apr 2007 15:48:57 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: John Schnizlein Subject: Re: [Ecrit] Profiles References: <46287EB9.7060006@gmx.net> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <4991CDE0-BA87-42E5-BCEA-2A8ED6324FA1@cs.columbia.edu> <3D8F471D-84F5-412D-9BFC-26209827F3CD@hxr.us> <58F11B2F-0FE7-41FD-9938-3B560968942B@hxr.us> <1A8339C1-B5C4-425F-A697-0F93AC93754A@cs.columbia.edu> <299A00CE-3894-4766-89DD-6BE1F5B823F5@cisco.com> In-Reply-To: <299A00CE-3894-4766-89DD-6BE1F5B823F5@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org We used the term compound location when civic location and geodetic location information is mixed into one location object. Look at Section 3.2 of http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-06#page-8. John Schnizlein wrote: > What is "a 3825-like compound location"? My understanding is that the > XML for location obtained from the mechanism defined in RFC 3825 is > just latitude, longitude and altitude, each with the correct number of > significant digits. > > John > > On Apr 26, 2007, at 11:03 PM, Andrew Newton wrote: >> >> On Apr 26, 2007, at 10:53 PM, Henning Schulzrinne wrote: >> >>> I've asked a few times, but why would LoST care that the civicAddr >>> is derived from DHCP as opposed to, say, entered manually? >>> Obviously, the current profile doesn't convey that information, either. >> >> I don't think it should care. The point wasn't that it came from >> DHCP, the point was that it was a 3825-like compound location. Sorry >> if that was confusing. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 10:50:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRjK-0006uA-GI; Fri, 27 Apr 2007 10:47:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRjE-0006bd-Jk; Fri, 27 Apr 2007 10:47:20 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhRbo-0006Zd-Fm; Fri, 27 Apr 2007 10:39:41 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 27 Apr 2007 10:39:40 -0400 X-IronPort-AV: i="4.14,462,1170651600"; d="scan'208"; a="119671502:sNHT48858892" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3REdeEw003113; Fri, 27 Apr 2007 10:39:40 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3REdTHH005194; Fri, 27 Apr 2007 14:39:40 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 10:39:03 -0400 Received: from [10.86.241.100] ([10.86.241.100]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 10:39:03 -0400 Message-ID: <46320B05.2040807@cisco.com> Date: Fri, 27 Apr 2007 10:39:01 -0400 From: Mark Stapp User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Tschofenig, Hannes" References: <8F6CBC7005099442AECDB784C9E9D7E701A9411A@MCHP7R6A.ww002.siemens.net> In-Reply-To: <8F6CBC7005099442AECDB784C9E9D7E701A9411A@MCHP7R6A.ww002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2007 14:39:03.0215 (UTC) FILETIME=[CD02EBF0:01C788D9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1875; t=1177684780; x=1178548780; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mjs@cisco.com; z=From:=20Mark=20Stapp=20 |Subject:=20Re=3A=20[dhcwg]=20Review=20of=20=22DHCP-based=20LoST=20Discov ery=20Procedure=22 |Sender:=20 |To:=20=22Tschofenig,=20Hannes=22=20; bh=eOfoX+MwCIAnddgFgD4B7PJ38xDh3afgFQMPgC2Fvcg=; b=YssLOTXT2G3n4eNf43nUC5P/+icZjZ5LZVpT6npWoW05t6SjuVcLeES08cTgOCbFXOyHLG1P ddXCWwnyFwIfso5NfwQh2Ejsk3woZryLkvBiAdbUFzLRkOrzVMEklo0V; Authentication-Results: rtp-dkim-1; header.From=mjs@cisco.com; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: dhcwg@ietf.org, Marc Linsner , ECRIT Subject: [Ecrit] Re: [dhcwg] Review of "DHCP-based LoST Discovery Procedure" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes, Marc, just a couple of comments: section 3: do you think it's better to spell this out, or would it be better to just reference DNS encoding? section 4: there's a v4 analogue to the v6 "Option Request Option": the "Parameter Request List" option. you mention the v6 option in section 5, but don't mention the v4 option here. section 7: you're using the mnemonic OPTION_LOST for both the v4 and v6 option codes. would it be clearer to use OPTION_V6_LOST or something like that? section 10: I think the RFC3396 ref should be 'normative', since you're making it mandatory. I think you should include 1034 in the 'normative' section, since there's no way for the client to use the info in the option without it. the 'LoST' protocol draft is in the 'normative' section, but I don't think it's needed there. you're just specifying options that point a client at a server: you're not requiring any LoST behavior in this draft, so I think the LoST reference could be informative. the draft doesn't appear to reference 3319 or 3361, but they are included in the 'informative' section? Thanks, Mark Tschofenig, Hannes wrote: > Hi all, > > In the ECRIT working group we have discovered the need to define a > discovery mechanism based on DHCP for LoST servers. Please find the > document here: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery- > 01.txt > > We would appreciate the review of this document. > > Ciao > Hannes > > PS: Marc has contacted the DHC chairs when we did the WGLC in ECRIT > already but I couldn't find the message anymore. Hence, I just want to > make sure that the document receives adequate review. > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 11:00:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRw9-0001J6-2i; Fri, 27 Apr 2007 11:00:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhRw7-0001Ip-4e for ecrit@ietf.org; Fri, 27 Apr 2007 11:00:39 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhRw4-0005oS-Ed for ecrit@ietf.org; Fri, 27 Apr 2007 11:00:39 -0400 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 27 Apr 2007 11:00:36 -0400 id 015880AC.46321014.00002217 In-Reply-To: <299A00CE-3894-4766-89DD-6BE1F5B823F5@cisco.com> References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <4991CDE0-BA87-42E5-BCEA-2A8ED6324FA1@cs.columbia.edu> <3D8F471D-84F5-412D-9BFC-26209827F3CD@hxr.us> <58F11B2F-0FE7-41FD-9938-3B560968942B@hxr.us> <1A8339C1-B5C4-425F-A697-0F93AC93754A@cs.columbia.edu> <299A00CE-3894-4766-89DD-6BE1F5B823F5@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Fri, 27 Apr 2007 11:00:30 -0400 To: John Schnizlein X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org By compound, I mean the combination of geodetic and civic components to form location information, such as is possible with RFC 3825. 3825 is just one example. Other types of compound location information are possible, such as civic address plus x distance relative. -andy On Apr 27, 2007, at 9:23 AM, John Schnizlein wrote: > What is "a 3825-like compound location"? My understanding is that > the XML for location obtained from the mechanism defined in RFC > 3825 is just latitude, longitude and altitude, each with the > correct number of significant digits. > > John > > On Apr 26, 2007, at 11:03 PM, Andrew Newton wrote: >> >> On Apr 26, 2007, at 10:53 PM, Henning Schulzrinne wrote: >> >>> I've asked a few times, but why would LoST care that the >>> civicAddr is derived from DHCP as opposed to, say, entered >>> manually? Obviously, the current profile doesn't convey that >>> information, either. >> >> I don't think it should care. The point wasn't that it came from >> DHCP, the point was that it was a 3825-like compound location. >> Sorry if that was confusing. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 11:37:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhSVQ-0008KH-Vz; Fri, 27 Apr 2007 11:37:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhSVO-0008JZ-Vo for ecrit@ietf.org; Fri, 27 Apr 2007 11:37:06 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhSVN-0005T2-MM for ecrit@ietf.org; Fri, 27 Apr 2007 11:37:06 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 27 Apr 2007 11:37:05 -0400 X-IronPort-AV: i="4.14,462,1170651600"; d="scan'208"; a="119678879:sNHT43863180" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3RFb58M028709; Fri, 27 Apr 2007 11:37:05 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3RFaflW016936; Fri, 27 Apr 2007 15:36:59 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 11:36:46 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 11:36:45 -0400 From: "Marc Linsner" To: "'Andrew Newton'" Subject: RE: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Fri, 27 Apr 2007 11:36:45 -0400 Message-ID: <003901c788e1$dd1616e0$2d0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceI3NiDlEcY90leTFqB2oxMISxDvgAAwQqg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 27 Apr 2007 15:36:45.0310 (UTC) FILETIME=[DC94B1E0:01C788E1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=539; t=1177688225; x=1178552225; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20Profiles=20(was=3A=20Consensus=20Call)=20-= 20namespaces |Sender:=20 |To:=20=22'Andrew=20Newton'=22=20; bh=pseWlkv8wjfCjtaNXBssxSffdQNt9aT8Ke9xF9jUXtA=; b=FRJ+I/v++M3rgYLUVYjrlXGK56fqh4nKWs4LcJHMGYT9MS3GiQeUF58IxG4rcQXLAgs7fBcv yn2chw8f5n3Nf42kG3dSBfiDWlx3x9hyPLxQ9mGwq0IEV6SnLyAdmSMp; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > By compound, I mean the combination of geodetic and civic components > to form location information, such as is possible with RFC 3825. > 3825 is just one example. Other types of compound location > information are possible, such as civic address plus x > distance relative. > > -andy Self-inflicted by the decision to adopt the GML schema vs. defining a new one, correct? BTW, since the proposal for relative location is an *addition* to the civic location, why are you considering it compound? -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 11:54:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhSlk-0001PZ-DN; Fri, 27 Apr 2007 11:54:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhSlj-0001PK-BJ for ecrit@ietf.org; Fri, 27 Apr 2007 11:53:59 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhSlg-0000F2-Fj for ecrit@ietf.org; Fri, 27 Apr 2007 11:53:59 -0400 Received: from ([139.76.131.79]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.176002733; Fri, 27 Apr 2007 11:53:44 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 27 Apr 2007 11:53:39 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 27 Apr 2007 11:53:38 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Profiles Date: Fri, 27 Apr 2007 11:53:37 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA03D0E478@crexc41p> In-Reply-To: <069601c788c0$49d67bc0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Profiles thread-index: AceId9gEollc5wEHRiColyzs+XufbwASD2cgAAiNWUA= References: <8BD959C9-C4AA-459F-AE1D-8F391BFC084E@hxr.us> <069601c788c0$49d67bc0$640fa8c0@cis.neustar.com> From: "Stark, Barbara" To: "Brian Rosen" ,"Andrew Newton" X-OriginalArrivalTime: 27 Apr 2007 15:53:39.0024 (UTC) FILETIME=[38CD2D00:01C788E4] X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I agree with this. We need a solution for emergency calls.=20 Barbara -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Friday, April 27, 2007 7:36 AM To: 'Andrew Newton' Cc: 'ECRIT' Subject: RE: [Ecrit] Profiles We need a solution for emergency calls. If we use the "return coarse information" then the coarse information is for emergency calls, and may not work for any other purpose If we have another solution for emergency calls, such as LoST dereference, we may not need coarse location. Brian ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA621 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 12:11:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhT2w-0004rl-K8; Fri, 27 Apr 2007 12:11:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhT2u-0004lp-Su for ecrit@ietf.org; Fri, 27 Apr 2007 12:11:44 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhT2r-00064D-MO for ecrit@ietf.org; Fri, 27 Apr 2007 12:11:44 -0400 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 27 Apr 2007 12:11:41 -0400 id 015880AC.463220BD.000031F7 In-Reply-To: <003901c788e1$dd1616e0$2d0d0d0a@amer.cisco.com> References: <003901c788e1$dd1616e0$2d0d0d0a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Fri, 27 Apr 2007 12:11:40 -0400 To: "Marc Linsner" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 27, 2007, at 11:36 AM, Marc Linsner wrote: > Self-inflicted by the decision to adopt the GML schema vs. defining > a new > one, correct? Sure, that could be done. Nobody seems to be proposing it though. > BTW, since the proposal for relative location is an *addition* to > the civic > location, why are you considering it compound? Together, they are two different types of information. Is there something wrong with that? Is there something wrong with calling it compound? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 12:17:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhT8c-0005Gr-6U; Fri, 27 Apr 2007 12:17:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhT8a-0005Gm-Jv for ecrit@ietf.org; Fri, 27 Apr 2007 12:17:36 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhT8Z-0007Kl-DL for ecrit@ietf.org; Fri, 27 Apr 2007 12:17:36 -0400 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 27 Apr 2007 12:17:35 -0400 id 015880AC.4632221F.0000336E In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA03D0E478@crexc41p> References: <8BD959C9-C4AA-459F-AE1D-8F391BFC084E@hxr.us> <069601c788c0$49d67bc0$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA03D0E478@crexc41p> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8D1F8F53-C538-470F-9931-E78DEB6A396A@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles Date: Fri, 27 Apr 2007 12:17:29 -0400 To: "Stark, Barbara" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Just to be clear, I'm not disagreeing. I just wanted to understand Brian's point. -andy On Apr 27, 2007, at 11:53 AM, Stark, Barbara wrote: > I agree with this. We need a solution for emergency calls. > Barbara > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, April 27, 2007 7:36 AM > To: 'Andrew Newton' > Cc: 'ECRIT' > Subject: RE: [Ecrit] Profiles > > We need a solution for emergency calls. > If we use the "return coarse information" then the coarse > information is > for emergency calls, and may not work for any other purpose > > If we have another solution for emergency calls, such as LoST > dereference, we may not need coarse location. > > Brian > > ***** > > The information transmitted is intended only for the person or > entity to which it is addressed and may contain confidential, > proprietary, and/or privileged material. Any review, > retransmission, dissemination or other use of, or taking of any > action in reliance upon this information by persons or entities > other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material > from all computers. GA621 > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 12:23:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhTEd-0002xH-LF; Fri, 27 Apr 2007 12:23:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhTEc-0002xC-5x for ecrit@ietf.org; Fri, 27 Apr 2007 12:23:50 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhTEa-00015f-Uw for ecrit@ietf.org; Fri, 27 Apr 2007 12:23:50 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 27 Apr 2007 12:23:48 -0400 X-IronPort-AV: i="4.14,462,1170651600"; d="scan'208"; a="119685580:sNHT43897404" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3RGNm4V025317; Fri, 27 Apr 2007 12:23:48 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3RGNmlG004259; Fri, 27 Apr 2007 16:23:48 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 12:23:44 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 12:23:43 -0400 From: "Marc Linsner" To: "'Andrew Newton'" Subject: RE: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Fri, 27 Apr 2007 12:23:43 -0400 Message-ID: <005301c788e8$6d1aeda0$2d0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AceI5u1kVGDKhbMXRlqdMW/TK35FIAAAFi9Q In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 27 Apr 2007 16:23:44.0081 (UTC) FILETIME=[6CB30410:01C788E8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=787; t=1177691028; x=1178555028; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20Profiles=20(was=3A=20Consensus=20Call)=20-= 20namespaces |Sender:=20 |To:=20=22'Andrew=20Newton'=22=20; bh=MRk8zUEcNTOr8bKDAPTuJuNVFI9B/PeGxlX0RbtWwfE=; b=dB9KKfLgxEZSohiSFS48gYGp8vajgmT/xec/wxSgEJP32d/wO5vCtdQ7GoccCSjvBRnYkRlg j0gI6QveRII/Ie/AVHO4qzka4QJIx6XPrd4V3TNGSFvQlWmNkWXbxk/Q; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > BTW, since the proposal for relative location is an > *addition* to the > > civic location, why are you considering it compound? > > Together, they are two different types of information. Is > there something wrong with that? Is there something wrong > with calling it compound? I am/was deriving the definition of *compound* from the 3825 illustration of 'part geo, part civic'. Hence, relative location is *all* civic, therefore didn't fit the derived definition. But, it's certainly obvious by now that I'm not a XML schema junkie. Actually, I don't view relative location as 'different' from elements like: seat, cubicle, room, etc. I intend to define the scope/applicability of the relative loc better in the next version of the draft. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 12:24:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhTFb-000363-57; Fri, 27 Apr 2007 12:24:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhTFa-00035x-2U for ecrit@ietf.org; Fri, 27 Apr 2007 12:24:50 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhTFY-0001Iq-PM for ecrit@ietf.org; Fri, 27 Apr 2007 12:24:50 -0400 X-SEF-Processed: 5_0_0_910__2007_04_27_11_31_35 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 27 Apr 2007 11:31:35 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 11:24:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Fri, 27 Apr 2007 11:24:46 -0500 Message-ID: In-Reply-To: <299A00CE-3894-4766-89DD-6BE1F5B823F5@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Profiles (was: Consensus Call) - namespaces Thread-Index: AceIzzpccH85pDgdRyu437Na0yRXkAAGSW6w From: "Winterbottom, James" To: "John Schnizlein" , "Andrew Newton" X-OriginalArrivalTime: 27 Apr 2007 16:24:47.0837 (UTC) FILETIME=[92B368D0:01C788E8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Then I strongly suggest that you go and re-read your own RFC John.=0D=0AAlt= itude can be expressed in floors and this requires a compound=0D=0Alocation= of both civic and geodetic information in the resultant=0D=0APIDF-LO.=0D=0A= or is this a misinterpretation also=3F=0D=0A=0D=0A=0D=0A> -----Original Mes= sage-----=0D=0A> From: John Schnizlein [mailto:jschnizl@cisco.com]=0D=0A> S= ent: Friday, 27 April 2007 11:23 PM=0D=0A> To: Andrew Newton=0D=0A> Cc: ECR= IT=0D=0A> Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces=0D= =0A>=20=0D=0A> What is "a 3825-like compound location"=3F My understanding= is that=0D=0A> the XML for location obtained from the mechanism defined in= RFC 3825=0D=0A> is just latitude, longitude and altitude, each with the co= rrect=0D=0A> number of significant digits.=0D=0A>=20=0D=0A> John=0D=0A>=20=0D= =0A> On Apr 26, 2007, at 11:03 PM, Andrew Newton wrote:=0D=0A> >=0D=0A> > O= n Apr 26, 2007, at 10:53 PM, Henning Schulzrinne wrote:=0D=0A> >=0D=0A> >> = I've asked a few times, but why would LoST care that the civicAddr=0D=0A> >= > is derived from DHCP as opposed to, say, entered manually=3F=0D=0A> >> Ob= viously, the current profile doesn't convey that information,=0D=0A> >> eit= her.=0D=0A> >=0D=0A> > I don't think it should care. The point wasn't that= it came from=0D=0A> > DHCP, the point was that it was a 3825-like compound= location.=0D=0A> > Sorry if that was confusing.=0D=0A>=20=0D=0A> _________= ______________________________________=0D=0A> Ecrit mailing list=0D=0A> Ecr= it@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0AThis message is for the designated recipient onl= y and may=0D=0Acontain privileged, proprietary, or otherwise private inform= ation. =20=0D=0AIf you have received it in error, please notify the sender=0D= =0Aimmediately and delete the original. Any unauthorized use of=0D=0Athis = email is prohibited.=0D=0A-------------------------------------------------= -----------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 12:40:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhTUG-0007D8-Om; Fri, 27 Apr 2007 12:40:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhTUG-0007D3-3K for ecrit@ietf.org; Fri, 27 Apr 2007 12:40:00 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhTUF-0005BC-Qd for ecrit@ietf.org; Fri, 27 Apr 2007 12:40:00 -0400 X-SEF-Processed: 5_0_0_910__2007_04_27_11_46_43 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 27 Apr 2007 11:46:43 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 11:39:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Profiles Date: Fri, 27 Apr 2007 11:39:55 -0500 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA03D0E478@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Profiles Thread-Index: AceId9gEollc5wEHRiColyzs+XufbwASD2cgAAiNWUAAAgvqgA== From: "Winterbottom, James" To: "Stark, Barbara" , "Brian Rosen" , "Andrew Newton" X-OriginalArrivalTime: 27 Apr 2007 16:39:56.0628 (UTC) FILETIME=[B061E940:01C788EA] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I know that I was off the air for a bit and I haven't been through the=0D=0A= whole 1500 emails that I got while I was out.=0D=0A=0D=0ABut what happened = to the idea of doing a reverse URI lookup to arrive at=0D=0Athe correspondi= ng service=3F=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A> -----Original Messa= ge-----=0D=0A> From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com]=0D= =0A> Sent: Saturday, 28 April 2007 1:54 AM=0D=0A> To: Brian Rosen; Andrew N= ewton=0D=0A> Cc: ECRIT=0D=0A> Subject: RE: [Ecrit] Profiles=0D=0A>=20=0D=0A= > I agree with this. We need a solution for emergency calls.=0D=0A> Barbara=0D= =0A>=20=0D=0A> -----Original Message-----=0D=0A> From: Brian Rosen [mailto:= br@brianrosen.net]=0D=0A> Sent: Friday, April 27, 2007 7:36 AM=0D=0A> To: '= Andrew Newton'=0D=0A> Cc: 'ECRIT'=0D=0A> Subject: RE: [Ecrit] Profiles=0D=0A= >=20=0D=0A> We need a solution for emergency calls.=0D=0A> If we use the "r= eturn coarse information" then the coarse information=0D=0Ais=0D=0A> for em= ergency calls, and may not work for any other purpose=0D=0A>=20=0D=0A> If w= e have another solution for emergency calls, such as LoST=0D=0A> dereferenc= e, we may not need coarse location.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A>= *****=0D=0A>=20=0D=0A> The information transmitted is intended only for th= e person or entity=0D=0Ato=0D=0A> which it is addressed and may contain con= fidential, proprietary,=0D=0Aand/or=0D=0A> privileged material. Any review,= retransmission, dissemination or=0D=0Aother=0D=0A> use of, or taking of an= y action in reliance upon this information by=0D=0A> persons or entities ot= her than the intended recipient is prohibited.=0D=0AIf=0D=0A> you received = this in error, please contact the sender and delete the=0D=0A> material fro= m all computers. GA621=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> _______________= ________________________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@iet= f.org=0D=0A> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A------= ---------------------------------------------------------------------------= ---------------=0D=0AThis message is for the designated recipient only and = may=0D=0Acontain privileged, proprietary, or otherwise private information.= =20=0D=0AIf you have received it in error, please notify the sender=0D=0Ai= mmediately and delete the original. Any unauthorized use of=0D=0Athis emai= l is prohibited.=0D=0A-----------------------------------------------------= -------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 12:46:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhTa5-0000ox-Ba; Fri, 27 Apr 2007 12:46:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhTa3-0000or-VB for ecrit@ietf.org; Fri, 27 Apr 2007 12:45:59 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhTa3-0006Sp-Kd for ecrit@ietf.org; Fri, 27 Apr 2007 12:45:59 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HhTZd-0001P1-Qo; Fri, 27 Apr 2007 11:45:34 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Stark, Barbara'" , "'Andrew Newton'" Subject: RE: [Ecrit] Profiles Date: Fri, 27 Apr 2007 12:45:55 -0400 Message-ID: <071401c788eb$880ec570$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceId9gEollc5wEHRiColyzs+XufbwASD2cgAAiNWUAAAgvqgAAANDuQ 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Keep reading. It's still on the list as a possible solution paired with the LCP+LoST query as a single operation to a LIS. I think that solution can be made to work, but is less attractive than the "coarse location" deref solution. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Friday, April 27, 2007 12:40 PM > To: Stark, Barbara; Brian Rosen; Andrew Newton > Cc: ECRIT > Subject: RE: [Ecrit] Profiles > > I know that I was off the air for a bit and I haven't been through the > whole 1500 emails that I got while I was out. > > But what happened to the idea of doing a reverse URI lookup to arrive at > the corresponding service? > > Cheers > James > > > -----Original Message----- > > From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] > > Sent: Saturday, 28 April 2007 1:54 AM > > To: Brian Rosen; Andrew Newton > > Cc: ECRIT > > Subject: RE: [Ecrit] Profiles > > > > I agree with this. We need a solution for emergency calls. > > Barbara > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, April 27, 2007 7:36 AM > > To: 'Andrew Newton' > > Cc: 'ECRIT' > > Subject: RE: [Ecrit] Profiles > > > > We need a solution for emergency calls. > > If we use the "return coarse information" then the coarse information > is > > for emergency calls, and may not work for any other purpose > > > > If we have another solution for emergency calls, such as LoST > > dereference, we may not need coarse location. > > > > Brian > > > > ***** > > > > The information transmitted is intended only for the person or entity > to > > which it is addressed and may contain confidential, proprietary, > and/or > > privileged material. Any review, retransmission, dissemination or > other > > use of, or taking of any action in reliance upon this information by > > persons or entities other than the intended recipient is prohibited. > If > > you received this in error, please contact the sender and delete the > > material from all computers. GA621 > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 12:48:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhTcX-0001Mv-E3; Fri, 27 Apr 2007 12:48:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhTcW-0001Mq-EY for ecrit@ietf.org; Fri, 27 Apr 2007 12:48:32 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhTcV-0006qs-T1 for ecrit@ietf.org; Fri, 27 Apr 2007 12:48:32 -0400 X-SEF-Processed: 5_0_0_910__2007_04_27_11_55_07 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 27 Apr 2007 11:55:06 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 11:48:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Profiles Date: Fri, 27 Apr 2007 11:48:18 -0500 Message-ID: In-Reply-To: <071401c788eb$880ec570$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Profiles Thread-Index: AceId9gEollc5wEHRiColyzs+XufbwASD2cgAAiNWUAAAgvqgAAANDuQAAAff1A= From: "Winterbottom, James" To: "Brian Rosen" , "Stark, Barbara" , "Andrew Newton" X-OriginalArrivalTime: 27 Apr 2007 16:48:19.0749 (UTC) FILETIME=[DC441550:01C788EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org >From a connected node perspective it certainly seems simpler to me.=0D=0ABu= t it may not be that simple to do in LoST I suppose.=0D=0A=0D=0A> -----Orig= inal Message-----=0D=0A> From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A= > Sent: Saturday, 28 April 2007 2:46 AM=0D=0A> To: Winterbottom, James; 'St= ark, Barbara'; 'Andrew Newton'=0D=0A> Cc: 'ECRIT'=0D=0A> Subject: RE: [Ecri= t] Profiles=0D=0A>=20=0D=0A> Keep reading.=0D=0A>=20=0D=0A> It's still on t= he list as a possible solution paired with the LCP+LoST=0D=0A> query=0D=0A>= as a single operation to a LIS.=0D=0A>=20=0D=0A> I think that solution can= be made to work, but is less attractive than=0D=0Athe=0D=0A> "coarse locat= ion" deref solution.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A> > -----Origina= l Message-----=0D=0A> > From: Winterbottom, James [mailto:James.Winterbotto= m@andrew.com]=0D=0A> > Sent: Friday, April 27, 2007 12:40 PM=0D=0A> > To: S= tark, Barbara; Brian Rosen; Andrew Newton=0D=0A> > Cc: ECRIT=0D=0A> > Subje= ct: RE: [Ecrit] Profiles=0D=0A> >=0D=0A> > I know that I was off the air fo= r a bit and I haven't been through=0D=0Athe=0D=0A> > whole 1500 emails that= I got while I was out.=0D=0A> >=0D=0A> > But what happened to the idea of = doing a reverse URI lookup to=0D=0Aarrive at=0D=0A> > the corresponding ser= vice=3F=0D=0A> >=0D=0A> > Cheers=0D=0A> > James=0D=0A> >=0D=0A> > > -----Or= iginal Message-----=0D=0A> > > From: Stark, Barbara [mailto:Barbara.Stark@B= ellSouth.com]=0D=0A> > > Sent: Saturday, 28 April 2007 1:54 AM=0D=0A> > > T= o: Brian Rosen; Andrew Newton=0D=0A> > > Cc: ECRIT=0D=0A> > > Subject: RE: = [Ecrit] Profiles=0D=0A> > >=0D=0A> > > I agree with this. We need a solutio= n for emergency calls.=0D=0A> > > Barbara=0D=0A> > >=0D=0A> > > -----Origin= al Message-----=0D=0A> > > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A= > > > Sent: Friday, April 27, 2007 7:36 AM=0D=0A> > > To: 'Andrew Newton'=0D= =0A> > > Cc: 'ECRIT'=0D=0A> > > Subject: RE: [Ecrit] Profiles=0D=0A> > >=0D= =0A> > > We need a solution for emergency calls.=0D=0A> > > If we use the "= return coarse information" then the coarse=0D=0Ainformation=0D=0A> > is=0D=0A= > > > for emergency calls, and may not work for any other purpose=0D=0A> > = >=0D=0A> > > If we have another solution for emergency calls, such as LoST=0D= =0A> > > dereference, we may not need coarse location.=0D=0A> > >=0D=0A> > = > Brian=0D=0A> > >=0D=0A> > > *****=0D=0A> > >=0D=0A> > > The information t= ransmitted is intended only for the person or=0D=0Aentity=0D=0A> > to=0D=0A= > > > which it is addressed and may contain confidential, proprietary,=0D=0A= > > and/or=0D=0A> > > privileged material. Any review, retransmission, diss= emination or=0D=0A> > other=0D=0A> > > use of, or taking of any action in r= eliance upon this information=0D=0Aby=0D=0A> > > persons or entities other = than the intended recipient is=0D=0Aprohibited.=0D=0A> > If=0D=0A> > > you = received this in error, please contact the sender and delete=0D=0Athe=0D=0A= > > > material from all computers. GA621=0D=0A> > >=0D=0A> > >=0D=0A> > >=0D= =0A> > > _______________________________________________=0D=0A> > > Ecrit m= ailing list=0D=0A> > > Ecrit@ietf.org=0D=0A> > > https://www1.ietf.org/mail= man/listinfo/ecrit=0D=0A> >=0D=0A> >=0D=0A---------------------------------= ---------------------------------------=0D=0A> --=0D=0A> > ----------------= ------=0D=0A> > This message is for the designated recipient only and may=0D= =0A> > contain privileged, proprietary, or otherwise private information.=0D= =0A> > If you have received it in error, please notify the sender=0D=0A> > = immediately and delete the original. Any unauthorized use of=0D=0A> > this= email is prohibited.=0D=0A> >=0D=0A---------------------------------------= ---------------------------------=0D=0A> --=0D=0A> > ----------------------=0D= =0A> > [mf2]=0D=0A>=20=0D=0A=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0AThis message i= s for the designated recipient only and may=0D=0Acontain privileged, propri= etary, or otherwise private information. =20=0D=0AIf you have received it i= n error, please notify the sender=0D=0Aimmediately and delete the original.= Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A-------------= ---------------------------------------------------------------------------= --------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 15:23:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhW2E-0006cw-7A; Fri, 27 Apr 2007 15:23:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhW2D-0006cm-Bv for ecrit@ietf.org; Fri, 27 Apr 2007 15:23:13 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhW2C-00052L-1O for ecrit@ietf.org; Fri, 27 Apr 2007 15:23:13 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3RJMwCZ010701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 27 Apr 2007 12:22:59 -0700 Received: from [129.46.226.38] (carbuncle.qualcomm.com [129.46.226.38]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3RJMvbN005053; Fri, 27 Apr 2007 12:22:58 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <55F43709-BC3D-41CB-950F-DBB9C7D89BC6@cs.columbia.edu> References: <069701c788c0$fe38c460$640fa8c0@cis.neustar.com> <55F43709-BC3D-41CB-950F-DBB9C7D89BC6@cs.columbia.edu> Date: Fri, 27 Apr 2007 12:22:56 -0700 To: Henning Schulzrinne , Brian Rosen From: Ted Hardie Subject: Re: [Ecrit] Profiles Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 9:23 AM -0400 4/27/07, Henning Schulzrinne wrote: > >>I don't think we need the service in the request to the LIS. I don't like >>the implications of this for endpoint code in an area that has multiple >>emergency services. It would have to query the LIS for each service. > >This also has rather undesirable scaling properties: Since the UA can't know who is hiding location, it would have to query for all dozen or so emergency services, plus possibly non-emergency services individually. I was assuming the hack included which emergency service, which eliminates this. Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 15:50:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhWSL-0002ah-A3; Fri, 27 Apr 2007 15:50:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhWSC-0002ZC-NM; Fri, 27 Apr 2007 15:50:04 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhWSA-00049k-Bw; Fri, 27 Apr 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 52855329D9; Fri, 27 Apr 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HhWSA-0002QH-7M; Fri, 27 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 27 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-security-threats-04.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org --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 : Security Threats and Requirements for Emergency Call Marking and Mapping Author(s) : T. Taylor, et al. Filename : draft-ietf-ecrit-security-threats-04.txt Pages : 18 Date : 2007-4-27 This document reviews the security threats associated with: o the marking of signalling messages to indicate that they are related to an emergency; and o the process of mapping from locations to Universal Resource Identifiers (URIs) pointing to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network. Based on the identified threats, this document establishes a set of security requirements for the mapping protocol and for the handling of emergency-marked calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-security-threats-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-security-threats-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-security-threats-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-27105045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-security-threats-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-security-threats-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-27105045.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Fri Apr 27 17:18:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhXpe-0004Ru-Cg; Fri, 27 Apr 2007 17:18:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhXpd-0004Rp-A8 for ecrit@ietf.org; Fri, 27 Apr 2007 17:18:21 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhXpc-000866-3o for ecrit@ietf.org; Fri, 27 Apr 2007 17:18:21 -0400 Received: from [160.39.251.22] (dyn-160-39-251-22.dyn.columbia.edu [160.39.251.22]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3RLGqAt025072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Apr 2007 17:16:59 -0400 (EDT) In-Reply-To: References: <069701c788c0$fe38c460$640fa8c0@cis.neustar.com> <55F43709-BC3D-41CB-950F-DBB9C7D89BC6@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles Date: Fri, 27 Apr 2007 17:18:16 -0400 To: Ted Hardie X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I don't understand your comment. If the LIS query includes the service URN, the UA has to query for each of the dozen or so different emergency services (urn:service:sos.fire, etc.). On Apr 27, 2007, at 3:22 PM, Ted Hardie wrote: > At 9:23 AM -0400 4/27/07, Henning Schulzrinne wrote: >> >>> I don't think we need the service in the request to the LIS. I >>> don't like >>> the implications of this for endpoint code in an area that has >>> multiple >>> emergency services. It would have to query the LIS for each >>> service. >> >> This also has rather undesirable scaling properties: Since the UA >> can't know who is hiding location, it would have to query for all >> dozen or so emergency services, plus possibly non-emergency >> services individually. > > I was assuming the hack included which emergency service, which > eliminates this. > Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 18:03:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhYXB-0002k8-Qp; Fri, 27 Apr 2007 18:03:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhYXA-0002k3-ST for ecrit@ietf.org; Fri, 27 Apr 2007 18:03:20 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhYX9-0007lC-Hj for ecrit@ietf.org; Fri, 27 Apr 2007 18:03:20 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l3RM29E3020598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 27 Apr 2007 15:02:09 -0700 Received: from [129.46.226.38] (carbuncle.qualcomm.com [129.46.226.38]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l3RM26vQ026190; Fri, 27 Apr 2007 15:02:08 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <069701c788c0$fe38c460$640fa8c0@cis.neustar.com> <55F43709-BC3D-41CB-950F-DBB9C7D89BC6@cs.columbia.edu> Date: Fri, 27 Apr 2007 15:02:06 -0700 To: Henning Schulzrinne From: Ted Hardie Subject: Re: [Ecrit] Profiles Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 5:18 PM -0400 4/27/07, Henning Schulzrinne wrote: >I don't understand your comment. If the LIS query includes the service URN, the UA has to query for each of the dozen or so different emergency services (urn:service:sos.fire, etc.). If the LIS query includes the service urn:service.sos.fire, why would it need to query for other emergencies? Are you assuming that this occurring on boot, and so has to be queried/retained for multiple emergency services in case any of them come up? For the call time use, this seems unlikely to be needed or useful. Ted >On Apr 27, 2007, at 3:22 PM, Ted Hardie wrote: > >>At 9:23 AM -0400 4/27/07, Henning Schulzrinne wrote: >>> >>>>I don't think we need the service in the request to the LIS. I don't like >>>>the implications of this for endpoint code in an area that has multiple >>>>emergency services. It would have to query the LIS for each service. >>> >>>This also has rather undesirable scaling properties: Since the UA can't know who is hiding location, it would have to query for all dozen or so emergency services, plus possibly non-emergency services individually. >> >>I was assuming the hack included which emergency service, which eliminates this. >> Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 18:54:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhZKw-0002qk-Md; Fri, 27 Apr 2007 18:54:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhZKv-0002qf-TE for ecrit@ietf.org; Fri, 27 Apr 2007 18:54:45 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhZKu-0001xh-K2 for ecrit@ietf.org; Fri, 27 Apr 2007 18:54:45 -0400 X-SEF-Processed: 5_0_0_910__2007_04_27_18_01_31 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 27 Apr 2007 18:01:31 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 17:54:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Profiles Date: Fri, 27 Apr 2007 17:54:42 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Profiles Thread-Index: AceJF+EpY2Z7SnBFQpyJ6xKr06/VlAABr6rQ From: "Winterbottom, James" To: "Ted Hardie" , "Henning Schulzrinne" X-OriginalArrivalTime: 27 Apr 2007 22:54:44.0137 (UTC) FILETIME=[0BFB7990:01C7891F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org But at boot time the end-point would simply say to the LIS "Gimme=0D=0Aemer= gency service stuff please", and it would get a bunch of URIs,=0D=0Apresuma= bly one for each service that was distinguishably applicable for=0D=0Athe l= ocation. Certainly if I were designing and implementing this I=0D=0Awould n= ot make it query for each one on the off chance that it yields a=0D=0Adiffe= rent result. Once I have the initial set, then I can query based on=0D=0Ath= e service I require at call-time if need be.=0D=0A=0D=0ACheers=0D=0AJames=0D= =0A=0D=0A> -----Original Message-----=0D=0A> From: Ted Hardie [mailto:hardi= e@qualcomm.com]=0D=0A> Sent: Saturday, 28 April 2007 8:02 AM=0D=0A> To: Hen= ning Schulzrinne=0D=0A> Cc: ECRIT=0D=0A> Subject: Re: [Ecrit] Profiles=0D=0A= >=20=0D=0A> At 5:18 PM -0400 4/27/07, Henning Schulzrinne wrote:=0D=0A> >I = don't understand your comment. If the LIS query includes the=0D=0Aservice=0D= =0A> URN, the UA has to query for each of the dozen or so different=0D=0Aem= ergency=0D=0A> services (urn:service:sos.fire, etc.).=0D=0A>=20=0D=0A> If = the LIS query includes the service urn:service.sos.fire, why would=0D=0Ait=0D= =0A> need to=0D=0A> query for other emergencies=3F Are you assuming that = this occurring on=0D=0A> boot,=0D=0A> and so has to be queried/retained for= multiple emergency services in=0D=0Acase=0D=0A> any of them=0D=0A> come up= =3F For the call time use, this seems unlikely to be needed or=0D=0A> usef= ul.=0D=0A> =09=09=09Ted=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> >On Apr 27, 20= 07, at 3:22 PM, Ted Hardie wrote:=0D=0A> >=0D=0A> >>At 9:23 AM -0400 4/27/0= 7, Henning Schulzrinne wrote:=0D=0A> >>>=0D=0A> >>>>I don't think we need t= he service in the request to the LIS. I=0D=0Adon't=0D=0A> like=0D=0A> >>>>= the implications of this for endpoint code in an area that has=0D=0A> multi= ple=0D=0A> >>>>emergency services. It would have to query the LIS for each=0D= =0Aservice.=0D=0A> >>>=0D=0A> >>>This also has rather undesirable scaling p= roperties: Since the UA=0D=0Acan't=0D=0A> know who is hiding location, it w= ould have to query for all dozen or=0D=0Aso=0D=0A> emergency services, plus= possibly non-emergency services individually.=0D=0A> >>=0D=0A> >>I was ass= uming the hack included which emergency service, which=0D=0A> eliminates th= is.=0D=0A> >>=09=09=09=09Ted=0D=0A>=20=0D=0A>=20=0D=0A> ___________________= ____________________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.or= g=0D=0A> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A----------= ---------------------------------------------------------------------------= -----------=0D=0AThis message is for the designated recipient only and may=0D= =0Acontain privileged, proprietary, or otherwise private information. =20=0D= =0AIf you have received it in error, please notify the sender=0D=0Aimmediat= ely and delete the original. Any unauthorized use of=0D=0Athis email is pr= ohibited.=0D=0A------------------------------------------------------------= ------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 20:15:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhab6-0002VD-PJ; Fri, 27 Apr 2007 20:15:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhab4-0002Qx-TB for ecrit@ietf.org; Fri, 27 Apr 2007 20:15:30 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hhab3-0003bV-Mp for ecrit@ietf.org; Fri, 27 Apr 2007 20:15:30 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3S0EXve008165 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Apr 2007 20:15:23 -0400 (EDT) In-Reply-To: References: <069701c788c0$fe38c460$640fa8c0@cis.neustar.com> <55F43709-BC3D-41CB-950F-DBB9C7D89BC6@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <740DE9AB-A4E7-47B0-9B6F-8DA316F83803@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles Date: Fri, 27 Apr 2007 20:15:22 -0400 To: Ted Hardie X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org One of the requirements has been to be able to determine location pre- call, to reduce call setup latency and the chance for errors. I agree that this is not a problem at call time. On Apr 27, 2007, at 6:02 PM, Ted Hardie wrote: > At 5:18 PM -0400 4/27/07, Henning Schulzrinne wrote: >> I don't understand your comment. If the LIS query includes the >> service URN, the UA has to query for each of the dozen or so >> different emergency services (urn:service:sos.fire, etc.). > > If the LIS query includes the service urn:service.sos.fire, why > would it need to > query for other emergencies? Are you assuming that this occurring > on boot, > and so has to be queried/retained for multiple emergency services > in case any of them > come up? For the call time use, this seems unlikely to be needed > or useful. > Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 21:31:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhbmT-0004A1-Lv; Fri, 27 Apr 2007 21:31:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhbmT-00049w-2i for ecrit@ietf.org; Fri, 27 Apr 2007 21:31:21 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhbmR-0002eh-Rx for ecrit@ietf.org; Fri, 27 Apr 2007 21:31:21 -0400 Received: from [10.0.1.52] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 27 Apr 2007 21:31:19 -0400 id 015884E3.4632A3E7.00001336 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Profiles Date: Fri, 27 Apr 2007 21:31:17 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Apr 27, 2007, at 6:54 PM, Winterbottom, James wrote: > But at boot time the end-point would simply say to the LIS "Gimme > emergency service stuff please", and it would get a bunch of URIs, > presumably one for each service that was distinguishably applicable > for > the location. Interesting. James Polk and I argued for just such a thing once upon a time. He even wrote a draft about how to do it via DHCP. But the group insisted that route determination must happen separately. It seems some of the design decisions made early on this working group are now being dropped. Perhaps James should revive his draft. It would solve the problem of location hiding with DHCP. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 22:35:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhcmf-00050M-Bx; Fri, 27 Apr 2007 22:35:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhcmd-0004yS-NT for ecrit@ietf.org; Fri, 27 Apr 2007 22:35:35 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hhcmd-0004uN-G2 for ecrit@ietf.org; Fri, 27 Apr 2007 22:35:35 -0400 Received: from [192.168.0.41] (pool-70-21-193-163.nwrk.east.verizon.net [70.21.193.163]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l3S2ZTdb027747 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Apr 2007 22:35:34 -0400 (EDT) In-Reply-To: References: <46287EB9.7060006@gmx.net> <49FF4F48-F84A-48F9-AE2B-92F25A40F2D5@cs.columbia.edu> <462BBD04.9060602@gmx.net> <1D561D03-EB45-4327-A4A9-FEBAAAD454F8@cs.columbia.edu> <7B68E227-27CE-4588-9A5E-CAA7EAA8EE4D@hxr.us> <60619E48-C54B-4963-AEE1-4F8E177074DE@cs.columbia.edu> <87EDE06A-5F25-4707-838D-862C04A4D1E8@hxr.us> <4991CDE0-BA87-42E5-BCEA-2A8ED6324FA1@cs.columbia.edu> <3D8F471D-84F5-412D-9BFC-26209827F3CD@hxr.us> <58F11B2F-0FE7-41FD-9938-3B560968942B@hxr.us> <1A8339C1-B5C4! ! ! ! -425F-A697-0F93AC93754A@cs.columbia.edu> <57D0B17F-E13B-4EA9-85C0-5803C02E9390@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <259FCD67-0815-4DFD-9BEE-E48AE824BFBB@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Profiles (was: Consensus Call) - namespaces Date: Fri, 27 Apr 2007 22:35:30 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This concrete example is helpful. Since applications such as LoST don't typically do schema validation, maybe it's more helpful to look at what an application would actually do, such as using SAX and DOM. Clearly, the application only has a limited repertoire of XML tags that it recognizes and then parses. It will presumably build up its internal data structure from those elements. There are two cases: (1) Senders can only generate certain orderings of elements, such as Point followed by civicAddress, even though the schema allows any ordering. A 'profile' specifies this. (2) Any ordering permitted by the schema can appear in the XML document. Doing (1) simplifies processing, since there are fewer elements that can occur at any given time, but with an event-based or DOM-based model, it doesn't seem to make a whole lot of difference. We obviously do want to restrict the GML elements that can occur in the XML sent, but that's a standardization issue, not a labeling issue. Thus, I'm all in favor of defining profiles for the sender. I just don't see how a profile label (beyond the namespace indications) would simplify the processing or improve error processing. Henning On Apr 26, 2007, at 11:54 PM, Andrew Newton wrote: > Perhaps we do need to restart the discussion. I was never arguing > for anything as strong as XML validity. That was one of your > arguments. However, if you take a schema that has the following > definition (pasted from 4119): > > > maxOccurs="unbounded"/> > > > Now take a look at the following from draft-ietf-geopriv-pdif-lo- > profile: > > > > -43.5723 153.21760 > > > 2 > > > > > > What is there to say that can legally follow > ? Nothing. From an XML processors perspective, it > could be GML followed by some other stuff that can be ignored (look > at processContents="lax"). What's the cue to the application that > it shouldn't ignore ? How does it know that is > important information, if even it may not have the schema in its > catalog? Either LoST knows about a civicAddress or it doesn't. Just having the schema in the catalog doesn't make a difference, as it has to understand the semantics, e.g., to do matching and caching. > > -andy > > On Apr 26, 2007, at 11:26 PM, Henning Schulzrinne wrote: _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Apr 27 23:35:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hhdia-0002BG-GV; Fri, 27 Apr 2007 23:35:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhdiZ-0002BB-6C for ecrit@ietf.org; Fri, 27 Apr 2007 23:35:27 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhdiX-0006By-Uw for ecrit@ietf.org; Fri, 27 Apr 2007 23:35:27 -0400 X-SEF-Processed: 5_0_0_910__2007_04_27_22_42_13 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 27 Apr 2007 22:42:13 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Apr 2007 22:35:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Profiles Date: Fri, 27 Apr 2007 22:35:24 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Profiles Thread-Index: AceJNO8LX0c+emyHQeSiShc7xRkZbwAET48A From: "Winterbottom, James" To: "Andrew Newton" X-OriginalArrivalTime: 28 Apr 2007 03:35:25.0545 (UTC) FILETIME=[423E6590:01C78946] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I have no problem with that, and I don't think that I argued either for=0D=0A= or against such a proposal.=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D= =0A> From: Andrew Newton [mailto:andy@hxr.us]=0D=0A> Sent: Saturday, 28 Apr= il 2007 11:31 AM=0D=0A> To: Winterbottom, James=0D=0A> Cc: Ted Hardie; Henn= ing Schulzrinne; ECRIT; James M. Polk=0D=0A> Subject: Re: [Ecrit] Profiles=0D= =0A>=20=0D=0A>=20=0D=0A> On Apr 27, 2007, at 6:54 PM, Winterbottom, James w= rote:=0D=0A>=20=0D=0A> > But at boot time the end-point would simply say to= the LIS "Gimme=0D=0A> > emergency service stuff please", and it would get = a bunch of URIs,=0D=0A> > presumably one for each service that was distingu= ishably applicable=0D=0A> > for=0D=0A> > the location.=0D=0A>=20=0D=0A> Int= eresting. James Polk and I argued for just such a thing once upon=0D=0A> a= time. He even wrote a draft about how to do it via DHCP. But the=0D=0A> = group insisted that route determination must happen separately. It=0D=0A> = seems some of the design decisions made early on this working group=0D=0A> = are now being dropped. Perhaps James should revive his draft. It=0D=0A> w= ould solve the problem of location hiding with DHCP.=0D=0A>=20=0D=0A> -andy=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 30 15:48:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hibrd-0003W3-FB; Mon, 30 Apr 2007 15:48:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hibrc-0003Vy-6v for ecrit@ietf.org; Mon, 30 Apr 2007 15:48:48 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HibrZ-0003Os-P6 for ecrit@ietf.org; Mon, 30 Apr 2007 15:48:48 -0400 Received: (qmail invoked by alias); 30 Apr 2007 19:48:44 -0000 Received: from p54986906.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.105.6] by mail.gmx.net (mp003) with SMTP; 30 Apr 2007 21:48:44 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18F4tQLq7MFXjXNTjiQeb5EOIZQBLfETBbgI3/33V 3EZhm1jZ2bSum1 Message-ID: <4636481B.8050908@gmx.net> Date: Mon, 30 Apr 2007 21:48:43 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) 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-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Ecrit] Location Hiding: Summary X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, we exchanged a huge number of emails on the topic of supporting location hiding in the emergency services architecture. It is fair to say that not everyone has had time to read all mail exchanges. Henning created a summary with input from Richard, Andy, Brian, James, Barbara, and Guy. You can find his summary here: http://www1.cs.columbia.edu:8080/display/~hgs/ECRIT+location+hiding To allow everyone to add a comments to the text I have copied the text to this Wiki: http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/LocationHiding Use the following credentials to make modifications: Username: EcritGroup Passwd: hide-it Here is the plan: 1) Read through the summary and express your opinion. Add something to the Wiki or post comments to the list. 2) We will ask the group about their preference for a specific solution. The details about the different solution proposals will help to get a better understanding of the tradeoffs. 3) Our WG drafts need to get updated. We will put a subset of the summary text into some documents to capture our discussions. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Apr 30 15:52:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HibvF-0008HR-1v; Mon, 30 Apr 2007 15:52:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HibvD-0008EH-Nw for ecrit@ietf.org; Mon, 30 Apr 2007 15:52:31 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HibvB-0004P6-36 for ecrit@ietf.org; Mon, 30 Apr 2007 15:52:31 -0400 Received: (qmail invoked by alias); 30 Apr 2007 19:52:28 -0000 Received: from p54986906.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.105.6] by mail.gmx.net (mp033) with SMTP; 30 Apr 2007 21:52:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18K/C1kC9IKzN4d9MbKY6sy9z6rIEykxCaFBk6iFQ wA1VccHFkrtam7 Message-ID: <463648FB.60009@gmx.net> Date: Mon, 30 Apr 2007 21:52:27 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ecrit] IETF ECRIT / IEEE Emergency Services Information Sharing Event: Video Podcast X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, we have produced a video podcast of the IETF ECRIT / IEEE emergency services information sharing event at the IETF#68 meeting in Prague, 19th March. Please find the video here: http://www.emergency-services-coordination.info/ieee-ecrit-2007.html We aren’t podcast experts, as you might easily recognize… Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit