On Nov 2, 2006, at 7:35= PM, Brian Rosen wrote:

I think it= is necessary.=A0 Effectivel= y, I think you HAVE to have an order.

The error return effectively says "you have a good count= ry, state/province

an= d community name, but I don't see a Willow Street in Anywhere, PA"=

Without order, what you are= saying is "well, somewhere in my database, there

is a state named PA, and I also have an Anyw= here, although it may or may not

be in PA, but I don't have any streets named Willow anywhere = in my database.

We were talking about this in a NENA meeting this mor= ning.=A0 It would be nice

if you, for example, mi= sspelled the name of the community, but got

everything else right, that the error you got was = "all fields good except

for community name".=A0 B= ut there is no feasible way to do that unless there

is exactly one Willow street in the state o= f PA, which is unlikely.=A0 = The

best you can do i= s say "there is no Anywher" in PA. = =A0

If your entry was 100 Main St, Anywher, PA, you don't want= "Street Valid"

<= FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">just = because there is a 100 Main St, Somewhere, PA.

Again, who is gonna be issuing a correction?=A0 A computer o= r a human?=A0 If a human is doing address validation for 123 Willow Stree= t, Anywhere PA and the computer says, "You have something wrong with eith= er Willow as a street or Anywhere as a city."=A0 I would hope the human c= ould figure it out.

The permutations of Anywhere is valid as a city for PA but not CA, = MD,... and Willow is valid as a street for Anywhere as a city in PA and A= nywhere as a city in NY.... can get complex fast.

All of this is a far cry from the ori= ginally stated requirement, which was a boolean flag for the address bein= g valid or invalid.

-andy

--=_zeke.ecotroph.net-3636-1162515330-0001-2-- --===============0014780670== 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 --===============0014780670==-- From ecrit-bounces@ietf.org Thu Nov 02 20:27:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfnp5-0000AI-7W; Thu, 02 Nov 2006 20:26:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfnp3-00005P-D8 for ecrit@ietf.org; Thu, 02 Nov 2006 20:26:17 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfnp2-0001JC-1z for ecrit@ietf.org; Thu, 02 Nov 2006 20:26:17 -0500 Received: from lion.cs.columbia.edu (IDENT:dDONdo13BPUSRDudoaMRf7m/5hdfkN/+@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id kA31Px7l028908 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Thu, 2 Nov 2006 20:25:59 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id kA31Pwg7000391 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 2 Nov 2006 20:25:58 -0500 Message-ID: <454A9AA1.2050500@cs.columbia.edu> Date: Thu, 02 Nov 2006 20:25:53 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Changes in LoST -02 References: <034e01c6fee0$05a13c20$640fa8c0@cis.neustar.com> <30A750F6-52DE-4D64-8BCF-7E307567634C@hxr.us> In-Reply-To: <30A750F6-52DE-4D64-8BCF-7E307567634C@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, X-Seen-By filter1.cs.columbia.edu X-Spam-Score: 0.0 (/) 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'm not sure we're all that far apart. Clearly, there is a (rough) implied hierarchy in address validation, but I don't think one needs to specify the precise algorithm in a standard. One reasonable mechanism might be: (1) Match complete address in database, using all fields that are in the database, omitting others. If ok, return list of all such fields. (2) Remove the house number. (3) Remove the street address components. (4.1) If (3) fails, prune back to country and A1 through A6. Repeat. (4.2) If (4.1) fails, prune back to country and A1 through A5. Repeat. (4.3) etc. The details could depend a bit on the country, but that's ok, since the authoritative database is likely going to be country-specific. What is beyond the scope of the draft is to do guessing, such as "No Mian Street but maybe you meant Main Street" or "No North Main Street, just North-East Main Street". Simply indicating that there's an error should in almost all cases be sufficient to identify the problem, particularly for the common spelling mistakes. If not, one needs more elaborate mechanisms, such as the listing of all streets in a city or a map, where somebody can find their home by neighboring streets. Even without standards, this is all pretty much common sense for implementors. Whether a national body, such as NENA, wants to provide guidance on elements that should always be treated as a unit and a hierarchy is another issue. Henning Andrew Newton wrote: > > On Nov 2, 2006, at 7:35 PM, Brian Rosen wrote: > >> I think it is necessary. Effectively, I think you HAVE to have an order. >> >> The error return effectively says "you have a good country, state/province >> >> and community name, but I don't see a Willow Street in Anywhere, PA" >> >> Without order, what you are saying is "well, somewhere in my database, >> there >> >> is a state named PA, and I also have an Anywhere, although it may or >> may not >> >> be in PA, but I don't have any streets named Willow anywhere in my >> database. >> >> >> We were talking about this in a NENA meeting this morning. It would >> be nice >> >> if you, for example, misspelled the name of the community, but got >> >> everything else right, that the error you got was "all fields good except >> >> for community name". But there is no feasible way to do that unless there >> >> is exactly one Willow street in the state of PA, which is unlikely. The >> >> best you can do is say "there is no Anywher" in PA. >> >> >> If your entry was 100 Main St, Anywher, PA, you don't want "Street Valid" >> >> just because there is a 100 Main St, Somewhere, PA. >> > > Again, who is gonna be issuing a correction? A computer or a human? If > a human is doing address validation for 123 Willow Street, Anywhere PA > and the computer says, "You have something wrong with either Willow as a > street or Anywhere as a city." I would hope the human could figure it out. > > The permutations of Anywhere is valid as a city for PA but not CA, > MD,... and Willow is valid as a street for Anywhere as a city in PA and > Anywhere as a city in NY.... can get complex fast. > > All of this is a far cry from the originally stated requirement, which > was a boolean flag for the address being valid or invalid. > > -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 Thu Nov 02 20:40:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfo2w-00067u-CW; Thu, 02 Nov 2006 20:40:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfo2u-00065A-Js for ecrit@ietf.org; Thu, 02 Nov 2006 20:40:36 -0500 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfo2t-0002r1-Dr for ecrit@ietf.org; Thu, 02 Nov 2006 20:40:36 -0500 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; Thu, 02 Nov 2006 20:40:11 -0500 id 01588075.454A9DFB.000017E8 In-Reply-To: <454A9AA1.2050500@cs.columbia.edu> References: <034e01c6fee0$05a13c20$640fa8c0@cis.neustar.com> <30A750F6-52DE-4D64-8BCF-7E307567634C@hxr.us> <454A9AA1.2050500@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <35426D66-C313-4AE9-9786-CB1AEF225D54@hxr.us> From: Andrew Newton Subject: Re: [Ecrit] Changes in LoST -02 Date: Thu, 2 Nov 2006 20:40:12 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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="===============1604538261==" Errors-To: ecrit-bounces@ietf.org --===============1604538261== Content-Type: multipart/alternative; boundary=Apple-Mail-2--472780774 --Apple-Mail-2--472780774 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Nov 2, 2006, at 8:25 PM, Henning Schulzrinne wrote: > The details could depend a bit on the country, but that's ok, since > the authoritative database is likely going to be country-specific. This sounds very reasonable to me. -andy --Apple-Mail-2--472780774 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=US-ASCII

On Nov 2, 2006, at 8:25 PM, Henning Schulzrinne wrote:

The details could depend a bit on the country, but that's ok, since the authoritative database is likely going to be country-specific.

This sounds very reasonable to me.

-andy

--Apple-Mail-2--472780774-- --===============1604538261== 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 --===============1604538261==-- From ecrit-bounces@ietf.org Thu Nov 02 20:50:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfoBv-0000Ed-A9; Thu, 02 Nov 2006 20:49:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfoBt-0000AA-97 for ecrit@ietf.org; Thu, 02 Nov 2006 20:49:53 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfoBr-0004Bb-Tg for ecrit@ietf.org; Thu, 02 Nov 2006 20:49:53 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GfoBe-0003gl-6g; Thu, 02 Nov 2006 19:49:41 -0600 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Ecrit] Changes in LoST -02 Date: Thu, 2 Nov 2006 20:49:43 -0500 Message-ID: <037701c6feea$593a6780$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.2869 Thread-Index: Acb+4sD1eRV4OFc4RSSVJgmmmFgZxQAAO+oQ In-Reply-To: <30A750F6-52DE-4D64-8BCF-7E307567634C@hxr.us> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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: 10d3e4e3c32e363f129e380e644649be 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 We're talking past each other. I want something simple and easy to describe and use. Ultimately, the correction comes from a human. All the computer can do is help. As I understand the current definition, if I queried with Willow, Anywher, PA and there was a Willow in Anywhere, then I would get valid, not valid, valid. How would you expect to display to the human "there is a problem with Anywher as a city or Willow as a street" out of that? However the real problem is that if there was a Willow in Somewhere, PA but not in Anywhere, PA, then the query today would be valid, not valid, valid, and you really get confused. Now, admittedly, that is an example of two errors, and most systems that try to do error diagnosis fail miserably with two errors. Small aside with relevance to this discussion: You should be allowed to query with community name blank (just as you should be able to query with county name blank). If the fields you supply yield a SINGLE record, you should get a successful return. If it yields more than one, you have an error I propose that if you have a miss, you examine fields in a defined order. As soon as you find an error, stop. Two errors would return a more meaningful error diagnosis with this algorithm, a small benefit. I admit that it would be nice if there was a single record that matched 123 Willow, Anywher, PA, US because Willow only occurred in Anywhere that it be able to say that, but I don't think it's really necessary. If you would like to get that, you can complicate the algorithm by looking at the fields in order until you get something not found. Then you try to find a SINGLE record with that field omitted. If you find ONE, you can clarify the error. In the example, if the input is: "123 Willow, Anywher, PA" and there is a Willow St in both Somewhere and Anywhere, you can't say anything meaningful about Willow. It's incorrect to say it is wrong. It is incorrect to say that it is right. You just don't know. Would it help to change the return to be three state (good, bad, unknown)? I recognize that you don't have a strict order in the addressing scheme. For example, postal code is NOT realy ordered in the coutry/state/county/city scheme. All that matters is that there is a defined order. Actually, you could make the order country specific, not publish it, and it would be okay, if we sent the "unknown" state back. What matters is that you say "there is no Anywher in PA, US" Brian ________________________________________ From: Andrew Newton [mailto:andy@hxr.us] Sent: Thursday, November 02, 2006 7:56 PM To: Brian Rosen Cc: 'Desjardins, Pierre'; ecrit@ietf.org Subject: Re: [Ecrit] Changes in LoST -02 On Nov 2, 2006, at 7:35 PM, Brian Rosen wrote: I think it is necessary. Effectively, I think you HAVE to have an order. The error return effectively says "you have a good country, state/province and community name, but I don't see a Willow Street in Anywhere, PA" Without order, what you are saying is "well, somewhere in my database, there is a state named PA, and I also have an Anywhere, although it may or may not be in PA, but I don't have any streets named Willow anywhere in my database. We were talking about this in a NENA meeting this morning. It would be nice if you, for example, misspelled the name of the community, but got everything else right, that the error you got was "all fields good except for community name". But there is no feasible way to do that unless there is exactly one Willow street in the state of PA, which is unlikely. The best you can do is say "there is no Anywher" in PA. If your entry was 100 Main St, Anywher, PA, you don't want "Street Valid" just because there is a 100 Main St, Somewhere, PA. Again, who is gonna be issuing a correction? A computer or a human? If a human is doing address validation for 123 Willow Street, Anywhere PA and the computer says, "You have something wrong with either Willow as a street or Anywhere as a city." I would hope the human could figure it out. The permutations of Anywhere is valid as a city for PA but not CA, MD,... and Willow is valid as a street for Anywhere as a city in PA and Anywhere as a city in NY.... can get complex fast. All of this is a far cry from the originally stated requirement, which was a boolean flag for the address being valid or invalid. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 02 20:50:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfoCg-0000Wv-Tf; Thu, 02 Nov 2006 20:50:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfoCg-0000Wq-8T for ecrit@ietf.org; Thu, 02 Nov 2006 20:50:42 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfoCe-0004Hr-SE for ecrit@ietf.org; Thu, 02 Nov 2006 20:50:42 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1GfoCO-0006oW-Hd; Thu, 02 Nov 2006 19:50:25 -0600 From: "Brian Rosen" To: "'Andrew Newton'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Changes in LoST -02 Date: Thu, 2 Nov 2006 20:50:28 -0500 Message-ID: <037801c6feea$7375cc20$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acb+6RY08Xc/yi+qSx6gKLuXKArEFQAAVO9A In-Reply-To: <35426D66-C313-4AE9-9786-CB1AEF225D54@hxr.us> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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.2 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd 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="===============1500708327==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1500708327== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0379_01C6FEC0.8A9FC420" This is a multi-part message in MIME format. ------=_NextPart_000_0379_01C6FEC0.8A9FC420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Me too. _____ From: Andrew Newton [mailto:andy@hxr.us] Sent: Thursday, November 02, 2006 8:40 PM To: Henning Schulzrinne Cc: ecrit@ietf.org Subject: Re: [Ecrit] Changes in LoST -02 On Nov 2, 2006, at 8:25 PM, Henning Schulzrinne wrote: The details could depend a bit on the country, but that's ok, since the authoritative database is likely going to be country-specific. This sounds very reasonable to me. -andy ------=_NextPart_000_0379_01C6FEC0.8A9FC420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Me = too.

From: = Andrew Newton [mailto:andy@hxr.us]
Sent: Thursday, November = 02, 2006 8:40 PM
To: Henning = Schulzrinne
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] = Changes in LoST -02

On Nov 2, 2006, at 8:25 PM, Henning Schulzrinne = wrote:

The details could depend = a bit on the country, but that's ok, since the authoritative database is likely = going to be country-specific.

This sounds very reasonable to me.

-andy

------=_NextPart_000_0379_01C6FEC0.8A9FC420-- --===============1500708327== 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 --===============1500708327==-- From ecrit-bounces@ietf.org Fri Nov 03 18:42:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg8g7-00040M-RY; Fri, 03 Nov 2006 18:42:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg8g5-0003yS-Ki; Fri, 03 Nov 2006 18:42:25 -0500 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg8g4-0005lm-D4; Fri, 03 Nov 2006 18:42:25 -0500 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 1Gg8fn-00026T-4k; Fri, 03 Nov 2006 18:42:10 -0500 Message-ID: <454BD3C6.1060609@bbn.com> Date: Fri, 03 Nov 2006 18:41:58 -0500 From: "Richard L. Barnes" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: geopriv@ietf.org, ECRIT Content-Type: multipart/mixed; boundary="------------090302000900000304020802" X-Spam-Score: 2.3 (++) X-Scan-Signature: e2b1c21e3dfd00bd40339b153dfe4f6a Cc: Matt Lepinski , Steve Kent Subject: [Ecrit] New draft on Secure Location Objects X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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. --------------090302000900000304020802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The issue of the security of location information in the GEOPRIV architecture has gotten a lot of discussion, so we wanted to examine some ways that security features might be embedded in location objects. The internet-drafts queue seems to be saturated, so please find draft-barnes-geopriv-secure-location-object-00.txt attached. Cheers, --Richard --------------090302000900000304020802 Content-Type: text/plain; name="draft-barnes-geopriv-secure-location-object-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-barnes-geopriv-secure-location-object-00.txt" Network Working Group R. Barnes Internet-Draft M. Lepinski Intended status: Informational R. Watro Expires: April 27, 2007 BBN Technologies October 24, 2006 Secure Location Objects draft-barnes-geopriv-secure-location-object-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 April 27, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Protection of location information is an essential requirement of the GEOPRIV architecture. Since using protocols cannot be relied upon to provide adequate protections to the location objects they carry, the location objects themselves must be secured. This document examines several candidates for a Secure Location Object format in the context of GEOPRIV and ECRIT security requirements, including both locations by value and by reference. Barnes, et al. Expires April 27, 2007 [Page 1] Internet-Draft Secure Location Objects October 2006 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. Security Threats . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Disclosure of Location Information . . . . . . . . . . . . 4 2.2. Use of Fake Location Information . . . . . . . . . . . . . 4 2.3. Denial of Location-based Services . . . . . . . . . . . . 5 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 6 3.1. Integration with LoST . . . . . . . . . . . . . . . . . . 6 3.2. GEOPRIV Considerations . . . . . . . . . . . . . . . . . . 7 3.3. ECRIT Considerations . . . . . . . . . . . . . . . . . . . 7 3.4. Technical Considerations . . . . . . . . . . . . . . . . . 7 4. Candidate Secure Location Object Formats . . . . . . . . . . . 7 4.1. Location By Value . . . . . . . . . . . . . . . . . . . . 8 4.1.1. Signed Location . . . . . . . . . . . . . . . . . . . 8 4.1.2. Encrypted Location . . . . . . . . . . . . . . . . . . 9 4.2. Location By Reference . . . . . . . . . . . . . . . . . . 11 4.3. Trust Models . . . . . . . . . . . . . . . . . . . . . . . 12 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Barnes, et al. Expires April 27, 2007 [Page 2] Internet-Draft Secure Location Objects October 2006 1. Introduction The security of location objects as they are stored and transmitted over the Internet is an essential enabler of the GEOPRIV architecture. Without the ability to guarantee the confidentiality of transmitted location information, an eavesdropper can circumvent GEOPRIV privacy rules; without authenticity and integrity, a third party can forge location information and degrade the reliability of the entire architecture. Even though such security guarantees may at times need to be relaxed -- for instance, in an emergency calling -- it is essential that the components of the GEOPRIV architecture make available a suite of security services. The fundamental unit of location information in the GEOPRIV architecture is the Location Object (LO): Location Objects are constructed by Location Generators; stored, transformed, and forwarded by Location Servers; and consumed by Location Recipients. In practice, these different entities are often under separate administrative domains, joined by various relationships and separated by diverse networks. The sensitive location information contained in these LOs is thus stored and transmitted in a wide variety of circumstances, and faces the risk of unauthorized access at several points, even in the presence of privacy rules. While the GEOPRIV architecture does make certain requirements of "using protocols" -- protocols that read or modify LI -- it explicitly makes no specifications with regard to protocols used only for transport of LOs. There are several transport mechanisms currently defined for conveying LOs from one point to another: Extensions have been defined for SIP, DHCP, and RADIUS, and others are being developed. Of these, only SIP has any claim of secure transport, and even the mechanisms that SIP offers are either seldom implemented (S/MIME) or widely regarded as ineffective (SIPS). The security of LOs used in GEOPRIV thus cannot rely on the security of the underlying transport, but must instead by enforced by security features inherent in the location object itself. We call location objects with such features Secure Location Objects, or SLOs. Below, we summarize the threats to location information that have been identified by the ECRIT and GEOPRIV working groups to date, identify some additional design constraints that must be taken into account by an SLO design, and examine the feasibility of several possible SLO formats in light of these conditions. 2. Security Threats Prior work by both the ECRIT and GEOPRIV working groups has Barnes, et al. Expires April 27, 2007 [Page 3] Internet-Draft Secure Location Objects October 2006 identified a set of risks facing location information, which are summarized here as the risks of unauthorized disclosure, forgery, and denial of location-based services. While these risks have special importance in the context of emergency calling, they apply broadly to the GEOPRIV architecture as a whole. 2.1. Disclosure of Location Information The most immediate threat to location information is the disclosure of sensitive location information to unauthorized parties. In particular, this allows an eavesdropper to circumvent any privacy rules that are supposed to govern the use of a LO. Such disclosure could occur in either of the following ways: o An attacker located on the path of communication to a legitimate location recipient may intercept a LO and extract sensitive location information. For example, an attacker could be a compromised router on the public internet who scans incoming packets for insecure LOs. Alternatively, such an attacker could be a compromised proxy server for some location-using protocol such as SIP o An attacker may impersonate a legitimate location recipient in order to obtain a LO from location server. For example, an attacker could attack the LoST service to cause legitimate users to send LOs to an attacker-controlled URI. Alternatively, an attacker could supply forged credentials to a location server to request a LO stored on the server. This threat is discussed in [Geopriv-Threats], Section 4.1.1 as well as [Geopriv-L7], Section 10.2. In the setting of emergency services, this threat is especially pertinent because the requester of emergency services is often in a vulnerable position and hence location information is particularly sensitive. For example, a motorist injured in an accident on a deserted highway is an easy target for robbery. The disclosure of location information in the event of an emergency is discussed in Security Threats and Requirements for Emergency Call Marking and Mapping [Ecrit-Threats] Section 5.2.3. 2.2. Use of Fake Location Information A second threat to location information is the ability of an attacker to create LOs that contain false location information, i.e., a location that does not correspond to a target's true location. There are several scenarios in which this might be accomplished: Barnes, et al. Expires April 27, 2007 [Page 4] Internet-Draft Secure Location Objects October 2006 o An attacker could replay location information corresponding to the attacker's true location at an earlier point in time. For example, an attacker who visits New York City in January could obtain a legitimate LO indicating his location in New York. The attacker could then use this previously obtained LO to claim he is in New York the following summer. o An attacker could replay location information corresponding to another target's location at an earlier point in time. For example, an attacker who has never been to New York City may obtain a legitimate LO that indicates that Alice is in New York City. The attacker could then later use this LO to claim that he is in New York. Note that this attack may or not require the attacker to be able to extract information from the LO. o An attacker could from scratch generate a forged LO corresponding to an arbitrary location. For example, an attacker could forge a LO indicating that he is in New York City. The attacker could then pass this LO off as legitimate and claim he is in New York even though he doesn't know of anyone who has been there. An extensive discussion of this threat appears in [Geopriv-L7], Section 8. The threat is also discussed in also discussed in [Geopriv-Threats] Section 4.1.2. In the setting of emergency services, this threat is especially pertinent because fake location information can be used to force scarce emergency-response resources to be improperly allocated. For example, in the event of a disaster, when the demand for emergency services exceeds supply, an attacker using a fake location could cause an ambulance to be sent to a location where no one is present. Even worse, an attacker could generate huge numbers of emergency phone calls from all over the world that all claim to be from a particular city. Such an attack could easily overwhelm the public safety access point and deny emergency services to legitimate residents of the city. The use of fake location information as it pertains to emergency services is discussed briefly in [Ecrit-Threats] Section 5.2.3. 2.3. Denial of Location-based Services In a similar vein, an attacker could deny location-based services to an individual with legitimate need for these services. In the current, unsecured architecture, this could occur in several ways: o As discussed in Section 2.2, an attacker can deny access to location-based services by using forged location information to overwhelm location-based services for a particular location. Barnes, et al. Expires April 27, 2007 [Page 5] Internet-Draft Secure Location Objects October 2006 o An attacker could alter a location object to indicate an incorrect location of a target. For example, when a legitimate user attempts to access a location-based service, an attacker on the path of communication may alter the location object to cause the request to be routed to the wrong service provider. o An attacker could prevent a location recipient from obtaining a location information. For example, an attacker might prevent a service provider from dereferencing a reference to a location object making it difficult for the user to receive location- appropriate services. This threat is discussed in the context of emergency services in [Ecrit-Threats] Section 5.2.2, but is equally applicable to other uses of the GEOPRIV architecture. 3. Design Considerations In addition to the security objectives discussed in Section 2 above, there are several other constraints on the design of SLOs. In general, use of SLOs must be compatible with other GEOPRIV and ECRIT protocols and architectures, with minimal modifications to either. One particular issue that is likely to arise is that in several possible SLO designs, the user (e.g., a UAC in the SIP model) may not have access to his own location (by value). 3.1. Integration with LoST Currently, many of the proposed use cases for the Location-to-Service Translation Protocol (LoST [LoST]) assume that the UAC has access to its own location. For instance: o As currently defined, a LoST query includes the location of the target in GML. In the case that the UAC is both the target of the query and the originator of the query, this means that the UAC must have access to its own location. o LoST responses typically contain a service boundary so that a UAC can determine when it has left the region in which its current PSAP URI is valid, and thus must query the LoST server again. Such a boundary is useful only if the UAC is aware of its own location. A security architecture in which a UAC may not know its own location, may necessitate revisions to the way that LoST is used. For instance, access networks or VoIP providers may need to provide LoST proxies that have access to location information. Barnes, et al. Expires April 27, 2007 [Page 6] Internet-Draft Secure Location Objects October 2006 3.2. GEOPRIV Considerations It is as yet unclear which communications in the GEOPRIV architecture can or should make use of SLOs when exchanging location data. The areas of application likely will be determined by the number of each GEOPRIV entity and the contractual, regulatory, or other trust relationships among them; these considerations also will affect the trust model underlying a SLO design. In addition, the functions required of each entity in the GEOPRIV architecture will dictate certain levels of access, and SLOs must accommodate these requirements. For instance, since the GEOPRIV architecture specifies that privacy rules are applied by a Location Server, use of SLOs must not preclude the Location Server from having sufficient knowledge of location information to apply these rules. 3.3. ECRIT Considerations A critical usage of GEOPRIV location objects is in emergency services, both for routing emergency calls to the correct PSAP and for directing emergency services to the location of the emergency. In such situations, it is essential that all relevant location information be available to all emergency responders that require it. When adding confidentiality features to a location object, therefore, appropriate failover mechanisms must be available. 3.4. Technical Considerations User devices that are expected to handle location objects are becoming increasingly mobile. In the context of SIP, this will be especially true as SIP is applied within cellular wireless networks. In order to facilitate the use of SLOs by these devices, an SLO design should be adaptable for use in an environment where there are constraints on both the processing power and bandwidth available to user devices. SLOs are generally amenable to such environments, since they require no cryptographic operations to be performed in order to store or transmit them securely, and, at least when expressed as locations by reference, can consume very little bandwidth and storage space. 4. Candidate Secure Location Object Formats Following the convention of SIP Location Conveyance [SIPLocation], we broadly divide the category of SLOs (objects that can be transmitted while still maintaining certain security properties) into those based on location by value and those based on location by reference. We then discuss candidate SLOs in both categories and discuss the properties of a trust model relied upon by any SLO. Note, however, Barnes, et al. Expires April 27, 2007 [Page 7] Internet-Draft Secure Location Objects October 2006 that in spite of this division, these two types of SLO can be naturally combined, for instance multi-layer access control could be achieved by using a secured location reference to refer to a secured location value. 4.1. Location By Value Conveyance of location by value is the act of transmitting an entire LO, rather than a reference to it. Security properties can be added to such a location object by either signing the location object, encrypting it, or both, using a technology such as S/MIME or XMLDsig. Each type of object -- signed, encrypted, or both -- has a different set of security properties, discussed below. Although we separately discuss the signing and encrypting of LOs, it is natural to consider combining the two approaches. This raises the question of whether a LO should be first signed and then encrypted, or vice-versa. We therefore briefly discuss the advantages of both approaches. o In settings where denial of service attacks are likely, signing an already encrypted LO is advantageous because a recipient of such LOs can quickly discard LOs with invalid signatures without needing to spend resources decrypting the object. Additionally, in settings where some fields of the LO should be encrypted and other fields should be left unencrypted, it is advantageous to sign the entire LO after the private fields have been encrypted. o The use of objects that are first signed and then encrypted requires less work on the part of the location producer. Indeed, a location producer may produce a single signed object which can then be encrypted, by a separate party, for delivery to multiple recipients. Similarly, the recipient of such an LO can re-encrypt the signed object for delivery to a new recipient without the involvement of the location producer. Additionally, in settings where different portions of an LO should be signed by different entities, it is advantageous to first sign and then encrypt the LO. 4.1.1. Signed Location A "signed location" SLO consists of a LO together with a signature of some or all of the LO by a recognized authority, likely a Location Server or Location Generator. Use of a signed location SLO has the following security implications: o Perhaps most importantly, use of a signed location SLO mitigates all of the threats in Section 2.2 arising from the use of forged Barnes, et al. Expires April 27, 2007 [Page 8] Internet-Draft Secure Location Objects October 2006 location information. An attacker who is not an authorized signer in the underlying trust model is unable to create fake location objects. In particular, this prevents an attacker from claiming he is at a distant location. Additionally, if a timestamp is included in the signed object, an attacker cannot replay a previously obtained location object (either his own or someone else's). o Use of a signed location SLO partially mitigates the threats in Section 2.3 regarding denial of service. An attacker on the communication path between a user and a location-based service provider cannot alter the location object in transit to make it appear that the user is at a distant location. Obviously, certain attackers on the communication path can always deny service to an individual by dropping the individual's request. However, an attack that drops the entire request is simpler to detect and respond to an attack that alters the location, since when a request is dropped the user finds out immediately (as soon as the time-out fails) but if a location is altered it is unclear how long it will take to determine that a problem has occurred. Naturally, the security properties granted by use of signed location SLOs fundamentally rely on a suitable trust model; as discussed in section 4.3, development of this trust model is a nontrivial but tractable problem. In order for signed location to be useful, it must be difficult for an attacker to compromise an authorized signer of location information. When signed location SLOs are used, it is the responsibility of the using protocol to take appropriate action when the signature fails to verify. For example, in most cases, a signed SLO with an invalid signature might be discarded altogether, but in the special case of emergency services, a call with a location signature that fails to verify might be answered but given lower priority than calls with valid SLOs. 4.1.2. Encrypted Location An "encrypted location" SLO is a LO encrypted in such a way that it is readable only by its intended recipient(s). Use of an encrypted location SLO has the following security implications: o Use of an encrypted location SLO mitigates all of the threats in Section 2.1 arising from improper disclosure of location information. Unless the attacker is able to compromise the secret decryption key of the intended location recipient, it is infeasible for him to extract information from any encrypted location SLO he might obtain. Therefore, even if the attacker is able, for example, to compromise a proxy on the communication path to a location recipient the sensitive location information Barnes, et al. Expires April 27, 2007 [Page 9] Internet-Draft Secure Location Objects October 2006 contained in the SLO remains private. o Use of an encrypted location SLO only partially mitigates the threats in Section 2.2 regarding forgery of location information. Depending on the key distribution architecture, it may be possible for an attacker to obtain the encryption key of a legitimate location recipient and forge an encrypted location SLO. Of course, these threats can be mitigated (as described in Section 4.1.1) by combining signing and encrypting of location objects. On the other hand, because an eavesdropper does not have access to the information contained in an encrypted location SLO, it is very difficult for him to modify the location in transit. o Use of an encrypted location SLO can pose additional risks regarding the denial of service threats discussed in Section 2.3. In particular, use of an encrypted location SLO introduces the possibility that a user is denied a service because the service provider cannot decrypt the SLO to extract LI. This could occur because of a key-management error, or because of an attack on the mechanism used to distribute public keys. The use of encrypted location SLOs relies fundamentally on a reliable mechanism to distribute the keys belonging to legitimate service providers; the difficulty of this task will derive from the underlying trust model. In the context of emergency services, for example, one might use the LoST protocol to return a certificate for a PSAP in addition to the PSAP's URI. This reduces the incremental risk of using encryption, since an attacker who is able to use LoST to distribute incorrect public keys can surely disrupt emergency services in other ways. One often-mentioned advantage of location-by-reference is that the required dereference operation creates an opportunity for location providers to enforce a scheme in which the party dereferencing the URL pays the provider for the location. A secondary advantage of encrypted location SLOs is that they can be used to extend this model to location by value: The encrypted location object can be transmitted to the location recipient, but encrypted in such a way that the SLO cannot be used by the recipient until he performs a second decryption or key exchange transaction with the location provider. However, just as the by-reference payment scheme is viable only if a user cannot dereference a URL to obtain his own location, this model forces a transaction only if a user cannot decrypt an encrypted location SLO containing his location. While this may force some adaptation of existing protocols (as discussed in Section 3), it seems that use of encrypted location SLOs for this purpose is still consistent with broader usage. For example, LoST servers could be operated by entities that maintain business relationships with Barnes, et al. Expires April 27, 2007 [Page 10] Internet-Draft Secure Location Objects October 2006 location providers, so that encrypted location SLOs included in LoST queries could be decrypted. 4.2. Location By Reference Conveyance of location by reference is the act of transmitting not an object containing LI, but rather a URL (or other pointer) that can be dereferenced to obtain a LO. Location URLs have several important security implications: o Perhaps most importantly, use of location by reference forces a location recipient to conduct a separate transaction in order to obtain the desired LI, which has the effect of allowing any security decisions to be delayed until the time when a location URL is dereferenced. This property allows much more complicated security and privacy policies to be enforced at the location server (such as rules about location expiration and retransmission), rather than delegating trust to using protocols. At the same time, however, it also lends itself very naturally to failover, since the location server can make a decision to grant access to parties that can demonstrate a need and authority for access, such as emergency service providers. o Because a location URL references a resource held by a third party (commonly, a location server), not by the location target or location recipient, location references cannot be constructed by a user, but rather must be obtained from an location server. This yields very powerful anti-forgery (hence anti-spam) properties, since a user cannot forge a location URL that references LI indicating that he is elsewhere than he is, and likewise, a third party (e.g., a man in the middle) cannot modify a URL to deny location-based services. We call a location reference that employs one or more security protocols in its dereference a secured location reference. Any security protocols used in conjunction with location references will be reliant on a suitable trust model; as discussed in section 4.3, development of this trust model seems to be a nontrivial, but tractable problem. In order for secured location references to be suitable for use in emergency services, the dereferencing protocol and any security protocols employed between the recipient and the location server must be made sufficiently reliable for use in an emergency. As is the case with normal, unsecured location references, the most significant risk is introduced by the dereferencing protocol, since the location server is capable of granting access to LI independent of security policies and protocols. Barnes, et al. Expires April 27, 2007 [Page 11] Internet-Draft Secure Location Objects October 2006 4.3. Trust Models Any SLO system will be based on an underlying trust model. The structure of this model deeply influences the nature of the security guarantees that the SLO system can provide. Such guarantees include: o Authentication of location recipients: Use of SLOs offers another mechanism for authenticating identities referenced by privacy rules. Using secure location by value, objects can be encrypted for a specific recipient, and using secure location by reference, a location server can interpret a cryptographic credential to grant or deny access to specific recipients. In particular, emergency service providers could be unambiguously identified by their credentials to be assured access to the LI they require. o Authentication and integrity of location information: In the PSTN, location information is provided by wireline or wireless operators, and thus assumed by all using parties to be reliable. Use of location signing in secure location objects provides a mechanism to translate these assurances to IP-based telephony and other location-based Internet services. o Non-repudiation of location information: By the same token as above, the current PSTN architecture allows failures of the location architecture to be clearly attributed to the provider of faulty LI, for purposes of determining regulatory or civil liability. For location-based services over IP, particularly emergency services, this is an important function that can be enabled by secure location objects. These features require the identification and issuance of credentials for two classes of entities: Location producers and location consumers. The case of location consumers seems to be the simpler, if we envision two major use cases, (1) emergency services calling, and (2) client-server style location-based services. In the former case, the set of PSAPs and emergency service providers is small and stable enough to be manageable. In some cases, even further simplification will be possible: In the NENA i3 architecture, for example, one might need to manage credentials only for gateways between emergency services networks and the Internet. For other client-server location-based services, there are several current trust models that could be adapted, such as the broad, flat PKI model used by HTTPS or the more flexible model used in DNSSEC. Constructing a system for authenticating location producers is more difficult. For example, an organization that administers a corporate network of SIP-based desk phones might provision these phones with fine-grained location information, such as their floor and room Barnes, et al. Expires April 27, 2007 [Page 12] Internet-Draft Secure Location Objects October 2006 number. By some calculations [ref:Henning], in New York City alone there are thousands of organizations that might be expected to do become location producers in this way, several of which appear and disappear each day. On the other hand, such location producers need only be included in a trust model if the goal of this trust model is to provide guarantees stronger than are offered by the PSTN. An initial capability to provide PSTN-equivalent security would require only the inclusion of telecommunications and internet service providers; construction of a PKI on the scale of the former is already being under taken by the SIDR working group and the Regional Internet Registries. In addition, many VoIP providers currently outsource location determination functions to other entities, which further consolidates the set of location producers. Note also that although we have treated here the specific example of location for VoIP, the same access networks that provide location for these services will be used to access other location-based services, so a trust model for location producers in a VoIP setting would be extensible to a model for more general location-based services. 5. Conclusions The purpose of this document is to start a discussion about the requirements of GEOPRIV and ECRIT for security in location objects. Clearly, it is tempting to push responsibility for security onto the protocols that carry LOs and the using protocols that process them. Currently, however, these protocols are unable to provide the end-to- end security guarantees necessary to mitigate threats to the privacy of location information and the integrity of location-based services. Without securing the location object itself, entities that generate LOs have no assurances that the LOs will not be misused, and critical applications such as emergency services have no assurances that the LOs they receive have not been forged or otherwise tampered with. In this document, we considered three approaches to securing LOs. Signing a location object can prevent forgery and mitigate resulting denial of service attacks. Encrypting location objects can prevent the improper disclosure of location information, but encryption results in an opaque location object that may require adaptation of using protocols. Using location by reference in conjunction with a secure dereferencing transaction can prevent both forgery and improper disclosure of location information. However, obtaining location information from a location-by-reference object requires an additional transaction that could introduce additional risk in time- critical applications such as emergency services. Naturally, these techniques for securing location objects can be combined to obtain stronger security guarantees or increased robustness. For example, a location reference could be appended to a signed and encrypted Barnes, et al. Expires April 27, 2007 [Page 13] Internet-Draft Secure Location Objects October 2006 location object to obtain the security guarantees of location-by- reference and yet require a separate de-referencing transaction only in the event that decryption fails. Achieving security through any of these mechanisms will require an appropriate trust model. 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 7. Security Considerations The focus of this document is security; hence security considerations permeate this specification. 8. Acknowledgements 9. References 9.1. Normative References [RFC2119] "", 2005. 9.2. Informative References [Ecrit-Threats] Nortel, Siemens, Columbia University, and Siemens, "Security Threats and Requirements for Emergency Call Marking and Mapping", July 2006. [Geopriv-L7] Siemens Networks and Columbia University, "Geopriv Layer 7 Location Configuration Protocol; Problem Statement and Requirements", October 2006. [Geopriv-Threats] Technology and Public Policy Clinic, Technology and Public Policy Clinic, Center for Democracy and Technology, and NeuStar, "Threat Analysis of the Geopriv Protocol", February 2004. [LoST] Qualcomm, Inc., SunRocket, Columbia University, and Barnes, et al. Expires April 27, 2007 [Page 14] Internet-Draft Secure Location Objects October 2006 Siemens, "LoST: A Location-to-Service Translation Protocol", September 2006. [RFC3693] Siemens AG, Center for Democracy and Technology, Technology and Public Policy Clinic, NeuStar, and Cisco, "Geopriv Requirements", February 2004. [SIPLocation] Qualcomm, Inc. and SunRocket, "Session Initiation Protocol Location Conveyance", October 2006. Authors' Addresses Richard Barnes BBN Technologies 9861 Broken Land Pkwy Columbia, Maryland 21046 USA Phone: +1-410-290-6169 Email: rbarnes@bbn.com Matt Lepinski BBN Technologies 10 Moulton St. Cambridge, Massachusetts 02138 USA Phone: +1-617-873-5939 Email: mlepinsk@bbn.com Ron Watro BBN Technologies 10 Moulton St. Cambridge, Massachusetts 02138 USA Phone: +1-617-873-2551 Email: rwatro@bbn.com Barnes, et al. Expires April 27, 2007 [Page 15] Internet-Draft Secure Location Objects October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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 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, et al. Expires April 27, 2007 [Page 16] --------------090302000900000304020802 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 --------------090302000900000304020802-- From ecrit-bounces@ietf.org Sat Nov 04 16:21:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgSwI-00013Y-Io; Sat, 04 Nov 2006 16:20:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgSwH-00013B-DD; Sat, 04 Nov 2006 16:20:29 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgSmI-0000xm-Jt; Sat, 04 Nov 2006 16:10:12 -0500 Received: from [192.168.0.41] (pool-141-153-178-200.mad.east.verizon.net [141.153.178.200]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kA4L9jDq016676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 4 Nov 2006 16:09:50 -0500 (EST) In-Reply-To: <454BD3C6.1060609@bbn.com> References: <454BD3C6.1060609@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6AD351BE-7106-4DF9-8902-70C6A1CA0534@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Sat, 4 Nov 2006 16:09:19 -0500 To: "Richard L. Barnes" 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: 0ddefe323dd869ab027dbfff7eff0465 Cc: geopriv@ietf.org, ECRIT , Steve Kent Subject: [Ecrit] Re: [Geopriv] New draft on Secure Location Objects X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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, your author group may benefit from perusing the ECRIT and GEOPRIV mailing list archives, as they discuss many of these issues in depth. Unfortunately, issues such as what it means to sign a location (how can the receiver tell who can legitimately sign for an unknown user's location?) do not seem to be reflected in your draft. Given the long and contentious debates on these topics, it would seem helpful to avoid having them again, so I think you could do the working groups a favor by reflecting those discussions in your draft. If you're able to summarize and reflect on those issues, your draft could be potentially useful to move the discussion forward, rather than just having the same discussion again. Many of these items are already discussed in the L7 and conveyance document, so it might be useful to reduce the overlap. Henning On Nov 3, 2006, at 6:41 PM, Richard L. Barnes wrote: > The issue of the security of location information in the GEOPRIV > architecture has gotten a lot of discussion, so we wanted to > examine some ways that security features might be embedded in > location objects. > > The internet-drafts queue seems to be saturated, so please find > draft-barnes-geopriv-secure-location-object-00.txt attached. > > Cheers, > --Richard > > > > Network Working Group R. > Barnes > Internet-Draft M. > Lepinski > Intended status: Informational R. > Watro > Expires: April 27, 2007 BBN > Technologies > October 24, > 2006 > > > Secure Location Objects > draft-barnes-geopriv-secure-location-object-00 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Nov 05 18:39:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgraN-0005Hd-EW; Sun, 05 Nov 2006 18:39:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgraM-0005HX-OH for ecrit@ietf.org; Sun, 05 Nov 2006 18:39:30 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgraI-0003P9-8t for ecrit@ietf.org; Sun, 05 Nov 2006 18:39:30 -0500 Received: from [130.129.71.98] ([130.129.71.98]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id kA5NdD828862; Sun, 5 Nov 2006 16:39:13 -0700 Message-ID: <454E761C.8060603@ntt-at.com> Date: Sun, 05 Nov 2006 15:39:08 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Changes in LoST -02 References: <454120F9.50402@cs.columbia.edu> In-Reply-To: <454120F9.50402@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: 6ffdee8af20de249c24731d8414917d3 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; General comments on the 02 version of the draft. BTW Overall I really like where the draft is going. 1. Now that the protocol is allowed to carry more than 1 location information in the findservice query, it may be a good idea to indicate which location was used to find out the URIs. > Otherwise I don't see how a server(proxy etc.) would be able to cache a response and later correlate it to a new request. 2. Last paragraph in section 1 talks about how LoST is able to provide list of services that are provided in the location requested. Does this always hold true? I can see that the server is able to provide a list of services that the server in question can provide but I don't see how server will be aware of all the services that is provided in the area.. (What if service X is provided at a state level but service Y is provided at a city level??) 3. With many location possibly included in the findService is there any way to prioritize and indicate the location user wants LoST server to use? (I might have read the draft wrong but section 6.3.1 reads as if you can have more than one location with the same location-profile..) 4. There is no text explaining the ordering of and its semantics. If there is no rule, there is no way for an endpoint to figure out which LoST server provided the final resolution. 5. What happens when the LoST query is exhausted while it's being iterated? 6. Can client put an asterisk to indicate it wants all the possible information LoST server can provide in "include" attribute. 7. Figure 6 shows a response with the ServiceBoundry but it is not requested in the request. Is serviceBoundry a MUST in a response? 8. Section 6.4.7. is the only thing that is declared optional in the draft? Is everything else mandatory?? 9. Section 6.4.4. Let's say the LoST server being queried is responsible for the city, and it only provides X and Y. But the server responsible for state may provide service X, Y and Z. Would it only return the alternative it is aware of or should it query the server responsible for the state and respond according to what it finds out.. 10. I don't understand why needs to be defined. Can't we just use the findService and have include 11. does not have the serviceURN in question. I am assuming that with LoST server possibly providing different services, each services can also have different boundary. If so the request and response should have the relevant service. 12. TTL should be absolute time. I don't see how servers can effectively cache the value otherwise. It also will promote replay attack if it's just indicated in seconds. 13. It doesn't say what can be set in the "include" attribute. I think this should be specified. Regards Shida Schubert Henning Schulzrinne wrote: > Changes: > > - each request now has its own response; > > - rewrite of introduction and, to a lesser extent, other sections for > continuity and to remove redundancy; > > - location profiles to describe allowable location types; > > - ServiceBoundary by reference, not just by value; > > - include mechanism, to allow clients to specify which information > they want the server to return; > > - , , indicate which pieces of civic > address data have been checked, are invalid and have not been checked, > respectively; > > Open issues: > > - syntax for error responses (the proposal in the draft has known > problems); > > - expiration time - absolute or relative; > > - handling of 'include' (specifies minimum set vs. strict set) - this > primarily affects the cacheability of responses > > 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 Sun Nov 05 18:56:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggrpi-0007TM-Jz; Sun, 05 Nov 2006 18:55:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggrph-0007TH-Cc for ecrit@ietf.org; Sun, 05 Nov 2006 18:55:21 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggrpg-0005Yr-3G for ecrit@ietf.org; Sun, 05 Nov 2006 18:55:21 -0500 Received: from [130.129.71.98] ([130.129.71.98]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id kA5NtJS03327; Sun, 5 Nov 2006 16:55:19 -0700 Message-ID: <454E79E4.9070102@ntt-at.com> Date: Sun, 05 Nov 2006 15:55:16 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [Ecrit] Comments on draft-ietf-ecrit-framework-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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; Few comments on the draft. 1. What is the early URL? I can guess what this is but I think it should be clarified somewhere as it 2. Section 3, 4th paragraph explains how the proxy(ESRP) would query the LoST server to resolve a Service URN but this is based on the assumption that the URI in the route header addressing the PSAP(assuming we are using the loose-route Jonathan proposed.) is stale. But is it really? And how do we know. There is no indication to show how fresh the psap-URI is. So UA can literally have obtained a new psap-URI just before it initiated an emergency call but according to the draft, ESRP or proxy would still redo the mapping.. Worse yet, because there is no indication that mapping has been accomplished, we may see multiple proxies redoing the mapping as it can't tell if the mapping has been executed already.. I don't know if there is any resolution to this and I actually don't know if this is really a problem but I figured I should share my concern.. 3. Section 5.8 talks about location being validated prior to a device placing an actual emergency call. I don't understand what the text is trying to say here. How could the validation take place without the actual request?? I am probably being stupid here and not fully understanding the text here so clarification would be much appreciated. 4. Section 16.5. Call Signaling Integrity I think is better provided by SIP-Identity, which can provide over some headers and message body end-to-end over TLS which only provides integrity hop-by-hop. You already recommend the use of sip-identity to provide caller-authentication, it won't hurt to recommend its use to provide signaling integrity. Regards Shida _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 06 12:53:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8ei-0007mD-2D; Mon, 06 Nov 2006 12:53:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8eg-0007lq-D5; Mon, 06 Nov 2006 12:53:06 -0500 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh8ec-000269-3Z; Mon, 06 Nov 2006 12:53:06 -0500 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 1Gh8eX-0005ym-5V; Mon, 06 Nov 2006 12:52:57 -0500 Message-ID: <454F766D.9090002@bbn.com> Date: Mon, 06 Nov 2006 09:52:45 -0800 From: "Richard L. Barnes" User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Henning Schulzrinne References: <454BD3C6.1060609@bbn.com> <6AD351BE-7106-4DF9-8902-70C6A1CA0534@cs.columbia.edu> In-Reply-To: <6AD351BE-7106-4DF9-8902-70C6A1CA0534@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: 4b800b1eab964a31702fa68f1ff0e955 Cc: geopriv@ietf.org, ECRIT , Matt Lepinski , Steve Kent Subject: [Ecrit] Re: [Geopriv] New draft on Secure Location Objects X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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, You're certainly right that we don't need to revisit the arguments that have gone on about location signing (and other security issues). In this draft, I think we were hoping to sidestep some of that by treating mechanisms for security separately from the underlying trust models. That is, this draft is trying to examine the tradeoffs of various security mechanisms, and their performance against security threats in current GEOPRIV and ECRIT documents -- independent of the trust model and associated semantics. I agree that the trust model that supports GEOPRIV security is a complicated and difficult question, and one we should elaborate on more in our next draft. We will try to incorporate the prior ECRIT and GEOPRIV discussions, in addition to the current documents. However, we should bear in mind that the selection of a trust model is a separate and independent problem from defining formats and mechanisms that might rely on such a trust model. Thanks, --Richard Henning Schulzrinne wrote: > Richard, > > your author group may benefit from perusing the ECRIT and GEOPRIV > mailing list archives, as they discuss many of these issues in depth. > Unfortunately, issues such as what it means to sign a location (how > can the receiver tell who can legitimately sign for an unknown user's > location?) do not seem to be reflected in your draft. Given the long > and contentious debates on these topics, it would seem helpful to > avoid having them again, so I think you could do the working groups a > favor by reflecting those discussions in your draft. If you're able to > summarize and reflect on those issues, your draft could be potentially > useful to move the discussion forward, rather than just having the > same discussion again. > > Many of these items are already discussed in the L7 and conveyance > document, so it might be useful to reduce the overlap. > > Henning > > > On Nov 3, 2006, at 6:41 PM, Richard L. Barnes wrote: > >> The issue of the security of location information in the GEOPRIV >> architecture has gotten a lot of discussion, so we wanted to examine >> some ways that security features might be embedded in location objects. >> >> The internet-drafts queue seems to be saturated, so please find >> draft-barnes-geopriv-secure-location-object-00.txt attached. >> >> Cheers, >> --Richard >> >> >> >> Network Working Group R. Barnes >> Internet-Draft M. Lepinski >> Intended status: Informational R. Watro >> Expires: April 27, 2007 BBN Technologies >> October 24, 2006 >> >> >> Secure Location Objects >> draft-barnes-geopriv-secure-location-object-00 > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 06 13:50:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9Xs-0004f6-IC; Mon, 06 Nov 2006 13:50:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9Xr-0004eo-Nb for ecrit@ietf.org; Mon, 06 Nov 2006 13:50:07 -0500 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh9Xp-0000cW-Cc for ecrit@ietf.org; Mon, 06 Nov 2006 13:50:07 -0500 Received: from [130.129.65.110] ([::ffff:130.129.65.110]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 06 Nov 2006 13:50:00 -0500 id 0158C199.454F83D8.00002E95 In-Reply-To: <454E761C.8060603@ntt-at.com> References: <454120F9.50402@cs.columbia.edu> <454E761C.8060603@ntt-at.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] Changes in LoST -02 Date: Mon, 6 Nov 2006 13:49:59 -0500 To: Shida Schubert X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f 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 Shida, I'll try to answer these as best as possible. Hopefully Henning, Ted, and Hannes can elaborate on the items I don't cover well. On Nov 5, 2006, at 6:39 PM, Shida Schubert wrote: > 1. Now that the protocol is allowed to carry more than 1 location > information > in the findservice query, it may be a good idea to indicate > which location was > used to find out the URIs. > > Otherwise I don't see how a server(proxy etc.) would be able > to cache a response and > later correlate it to a new request. Though I cannot see it in the draft, I thought there was wording about the ordering of the elements to indicate preference and likewise in the response. That would resolve the issue above. But you are correct, we need to be able to indicate which location profile was used for the answer. > 2. Last paragraph in section 1 talks about how LoST is able to > provide list of services that > are provided in the location requested. Does this always hold > true? I can see that the server > is able to provide a list of services that the server in > question can provide but I don't see > how server will be aware of all the services that is provided > in the area.. (What if service > X is provided at a state level but service Y is provided at a > city level??) Good question. I think that a query would not reach an authoritative server. It would always either be answered by a caching resolver via how it was configured to do resolution or from information from a forrest guide. > 3. With many location possibly included in the findService is there > any way to > prioritize and indicate the location user wants LoST server > to use? (I might have read the > draft wrong but section 6.3.1 reads as if you can have more > than one location with the > same location-profile..) See #1. > 4. There is no text explaining the ordering of and its > semantics. If there is no rule, > there is no way for an endpoint to figure out which LoST server > provided the final > resolution. We inadvertently removed that text during some wordsmithing to make section 6.4.1 read more clearly. Thanks for pointing this out. > 5. What happens when the LoST query is exhausted while it's being > iterated? Either a or a . > 6. Can client put an asterisk to indicate it wants all the possible > information LoST server > can provide in "include" attribute. I'll see if we can do this. It shouldn't be too hard in the Relax NG. > 7. Figure 6 shows a response with the ServiceBoundry but it is not > requested in the > request. Is serviceBoundry a MUST in a response? That's a mistake in the example. No, it is not a MUST. > 8. Section 6.4.7. is the only thing that is > declared optional in the > draft? Is everything else mandatory?? No. While we do have the mismatch with the Relax NG and some of the wording, every element in is optional. > 9. Section 6.4.4. Let's say the LoST server being queried is > responsible for the city, > and it only provides X and Y. But the server responsible for > state may provide > service X, Y and Z. Would it only return the alternative it is > aware of or should > it query the server responsible for the state and respond > according to what it > finds out.. See #2. > 10. I don't understand why needs to be > defined. Can't > we just use the findService and have include The include attribute in specifies either serviceBoundary or serviceBoundaryReference. This allows a client to retrieve the service boundary in a separate message using the query. This might be useful in networks with low bandwidth with service boundaries that might take a lot to express. > 11. does not have the serviceURN in question. > I am assuming > that with LoST server possibly providing different services, > each services can also > have different boundary. If so the request and response should > have the relevant > service. The key should be good enough. If a server wants to implement the creating of the key with the URN embedded in the key, then it is free to do so. Though perhaps we should relax the regex to allow this. Thanks for pointing this out. > 12. TTL should be absolute time. I don't see how servers can > effectively cache the > value otherwise. It also will promote replay attack if it's > just indicated in seconds. Quite easily. DNS, the largest distributed, caching, inter-domain, distributed database uses relative TTLs with no problems. And there is nothing inherent in absolute times themselves that prevent replay attacks. > 13. It doesn't say what can be set in the "include" attribute. I > think this should be > specified. That is explicitly listed in the relax ng schema. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 06 21:59:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHAs-0005da-Ha; Mon, 06 Nov 2006 21:58:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHAr-0005dK-5N for ecrit@ietf.org; Mon, 06 Nov 2006 21:58:53 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhHAn-0005Pg-Rk for ecrit@ietf.org; Mon, 06 Nov 2006 21:58:53 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 06 Nov 2006 18:58:48 -0800 X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="340157020:sNHT48180924" 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.20060308/8.12.11) with ESMTP id kA72wnlT016291 for ; Mon, 6 Nov 2006 18:58:49 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kA72wnOV009027 for ; Mon, 6 Nov 2006 18:58:49 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:58:48 -0800 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:58:48 -0800 From: "Marc Linsner" To: Date: Mon, 6 Nov 2006 21:58:48 -0500 Message-ID: <000f01c70218$a5b17690$d97a150a@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.2962 Thread-Index: AccCGKP4gzVV2RX9QwaBoonZ/BUdkw== X-OriginalArrivalTime: 07 Nov 2006 02:58:48.0842 (UTC) FILETIME=[A5DB1EA0:01C70218] DKIM-Signature: a=rsa-sha1; q=dns; l=191; t=1162868329; x=1163732329; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:Slides=20for=20wg=20meeting...; X=v=3Dcisco.com=3B=20h=3D5Qt9nVq09euOg6Tv6Hn/WSPYFvA=3D; b=cRPPNWqSAbanCIHpHZNVsb2MJCJ76WzQ0rqKeINxFzBfrVnzZtw5ubSfzGbToDgEvA82qiYI hBV/b/qyfwqk6Z859tx8o3GLb86pxLDbsX/2GJ/afBysxIekWFpbHaOd; Authentication-Results: sj-dkim-8.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [Ecrit] Slides for wg 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: , Errors-To: ecrit-bounces@ietf.org If you are presenting at ecrit, please send the slides to Hannes or myself. We want to post them PRIOR to the start of the session so the remote attendees can see them... Marc & Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 06 22:13:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHPL-0006jL-Uf; Mon, 06 Nov 2006 22:13:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhHPK-0006j7-Ko for ecrit@ietf.org; Mon, 06 Nov 2006 22:13:50 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhHPJ-0007mG-5W for ecrit@ietf.org; Mon, 06 Nov 2006 22:13:50 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 06 Nov 2006 19:13:48 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAH2GT0WrR7O6W2dsb2JhbACMPxUOKw X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="448479970:sNHT28261220" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA73DlNg032133 for ; Mon, 6 Nov 2006 19:13:47 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA73DlW4007596 for ; Mon, 6 Nov 2006 19:13:47 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 19:13:47 -0800 Received: from [130.129.71.49] ([10.21.82.238]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 19:13:47 -0800 Message-ID: <454FF9EB.6010606@cisco.com> Date: Mon, 06 Nov 2006 22:13:47 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2006 03:13:47.0573 (UTC) FILETIME=[BD8A9650:01C7021A] DKIM-Signature: a=rsa-sha1; q=dns; l=1900; t=1162869228; x=1163733228; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:ICE=20tutorial=3A=20Lunch=20logistics=20update=20[DO=20NOT=20REPLY]; X=v=3Dcisco.com=3B=20h=3Dwvzj+J9U4bGAuwmnCCs9T7HKQa8=3D; b=BcT5WYy7oa6qYQZHB3gWW07XYMSetIGcf8yFgQBFtcBGuYwTaRcP7BLc3ZwBnqZqnLmVVOAa WCm1qgLr6bq0s/WCjai3adVMB95TW7+OqrPFKwr3Gl3H0zY31b/DzOUG; Authentication-Results: sj-dkim-2.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Ecrit] ICE tutorial: Lunch logistics update [DO NOT REPLY] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-12.txt) WHEN: Tuesday, November 7 1130-1300 Lunch will be provided at a nominal fee of $10 Sandwiches, salad and chips Bring-your-own beverage Please get me your $10 prior to the end of the IETF meeting. Only 90 lunches have been ordered, its first-come-first-served I am covering this out of my own pocket, so please do get me your $10 if you partake of the food. I'm not tracking who eats or pays - we're on the honor system here! WHERE: Grande Ballroom A WHO: Anyone with an interest in RAI work that would like to learn more about ICE. WHY: ICE is one of the 'core' SIP specifications (according to the SIP hitchhikers guide) and seeing some good adoption. It's the IETF tool for NAT traversal for SIP-based media. However, it's a complex specification. The tutorial will assume only basic familiarity with SIP, SDP and NAT, and explain the rest. Participants will emerge with a high level understanding of the operation of ICE. The tutorial will be based on the pending -12 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice). !DO NOT REPLY TO THIS NOTE! -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 07 17:08:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZ6t-0005VJ-Eq; Tue, 07 Nov 2006 17:07:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZ6r-0005UL-Lb for Ecrit@ietf.org; Tue, 07 Nov 2006 17:07:57 -0500 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhZ6q-0004eO-Co for Ecrit@ietf.org; Tue, 07 Nov 2006 17:07:57 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1143417ugd for ; Tue, 07 Nov 2006 14:07:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=eHTmm2WLnUyPcXG0ZpDmP5E9a+Tv3eB5IAPiCIm4NxhnKRfYCTT90oU1nkwPZ3a1iyhmtMQcFYxUsOzL6MpNb+Vc9wR2B3RylQG0N/DGzUhoKh8KPDh90q8UQUqlCjeWZYnqgTMTg3lXqaCrwRupBR7fBNXph9tcAwF75FDXp40= Received: by 10.78.164.13 with SMTP id m13mr5545196hue.1162937274465; Tue, 07 Nov 2006 14:07:54 -0800 (PST) Received: by 10.78.200.9 with HTTP; Tue, 7 Nov 2006 14:07:54 -0800 (PST) Message-ID: <953beacc0611071407w7b2e9793j7fae9415eae42c9@mail.gmail.com> Date: Tue, 7 Nov 2006 14:07:54 -0800 From: "Rohan Mahy" To: Ecrit@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: rohan@ekabal.com Subject: [Ecrit] support for multiple display names in LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org LoST can provide a display name. I think the schema should allow multiple display names so if I can have support for multiple languages (for example English/French in Canada, Flemmish/French in Belgium, etc..) I added this to the issue tracker as issue #17. thanks, -rohan _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 07 17:52:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZo9-0006Sr-J9; Tue, 07 Nov 2006 17:52:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZo8-0006MJ-0I for ecrit@ietf.org; Tue, 07 Nov 2006 17:52:40 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhZo6-0002Lb-No for ecrit@ietf.org; Tue, 07 Nov 2006 17:52:39 -0500 Received: (qmail invoked by alias); 07 Nov 2006 22:52:37 -0000 Received: from dhcp66-103.ietf67.org (EHLO [130.129.66.103]) [130.129.66.103] by mail.gmx.net (mp043) with SMTP; 07 Nov 2006 23:52:37 +0100 X-Authenticated: #29516787 Message-ID: <45510E35.6040508@gmx.net> Date: Tue, 07 Nov 2006 14:52:37 -0800 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) 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] Marking Input by Jonathan X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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, during the meeting Jonathan mentioned that he worked on a draft that is relevant for our marking discussion: http://tools.ietf.org/wg/sip/draft-rosenberg-sip-ua-loose-route-00.txt It has a section about emergency services. Please read it. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 07 18:03:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZyC-0005f5-37; Tue, 07 Nov 2006 18:03:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZyA-0005ez-Iy for ecrit@ietf.org; Tue, 07 Nov 2006 18:03:02 -0500 Received: from rwcrmhc13.comcast.net ([204.127.192.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhZy8-00042j-7w for ecrit@ietf.org; Tue, 07 Nov 2006 18:03:02 -0500 Received: from s73602 (dhcp66-117.ietf67.org[130.129.66.117]) by comcast.net (rwcrmhc13) with SMTP id <20061107230259m1300l6qlue>; Tue, 7 Nov 2006 23:02:59 +0000 Message-ID: <139c01c702c0$794e27d0$0500a8c0@china.huawei.com> From: "Spencer Dawkins" To: Date: Tue, 7 Nov 2006 15:00:09 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.3 (/) X-Scan-Signature: 717d651095a319b49fc3b6c7b72cb4dd Subject: [Ecrit] My raw notes from 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="===============0558027001==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0558027001== Content-Type: multipart/alternative; boundary="----=_NextPart_000_1399_01C7027D.6AE30960" This is a multi-part message in MIME format. ------=_NextPart_000_1399_01C7027D.6AE30960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hope these are helpful! Spencer Emergency Context Resolution with Internet Technologies WG (ECRIT) = Agenda for IETF 67 TUESDAY, November 7, 2006 1300-1500 Afternoon Session I Grande Ballroom A 1. Agenda Bashing, Document Status and Milestones Chairs (15 minutes) No agenda bashing noted a. draft-ietf-ecrit-requirements-12.txt b. draft-ietf-ecrit-service-urn-05.txt c. draft-ietf-ecrit-security-threats-03.txt Have been forwarded to the IESG for publication (the good news), may = hear back from them (the bad news). Proto writeup is all done. We're running close to our milestones (amaze your friends in the IETF). There is now an unofficial ECRIT blog from the supplementary web page, = and an implementation tracker page (with mailing list - contact chairs = to join). 2. Report about the SDO Emergency Services Coordination Workshop Hannes Tschofenig / Marc Linsner (30 minutes) Acknowledgements to those who helped and participated... Several links to information are included in the slides from this = presentation. More than 30 presentations from various SDOs. a.. 3GPP - had already had a workshop with 3GPP in July, were already = aware of many details, but 3GPP2 also confirmed requirements. b.. IEEE 802.11 emergency service identification, location, = unauthenticated access.=20 c.. IEEE 802.1AB - link layer discovery protocol and LDP-MED. d.. Several presentations from ECRIT WG.=20 e.. PacketCable showed architecture and solutions. f.. NENA g.. TIA -TR-45 h.. OMA i.. ITU-T - focused on early warning, not working on 911 j.. ETSI EMTEL doing requirements, k.. OCG talked about GML l.. EU Commission (regulatory framework, player responsibilities in = our architecture) m.. COMCARE pointers to OASIS standards for authority-to-authority = communication, n.. ESIF NGES talked about NENA i3 requirements and their plans to = build on those requirements o.. ANSI HSSP offered forum for standards and coordination. They are = also working on a white paper. p.. US department of transportation q.. Emergency Services in Austria - for current VoIP provider r.. Emergency Services Prototype from Henning. Major open issues a.. Architectural b.. Whether to send location information to the endpoints c.. Who should develop which protocols d.. Role of a "global coordinator" Next Steps a.. Schedule another workshop in six months b.. Inform other SDOs about this work c.. Request feedback from other SDOs about LoST, Phone BCP, etc. d.. Topic-specific liaisons, if necessary (discuss this with IAB) e.. Perform workshops with SDOs on selected topics - possibly IEEE, = OMA - IPR policy incompatibility concerns here Peter - concerns about streaming from this workshop, poor quality Henning - versioning problem. Some people are supporting existing PSAP = architectures, NENE i-2, not i-3 versions. =20 Marc - i-2 is being stretched to cover more environments (mobile, etc, = never intended to cover these). Brian - effort in NENA is to get i-3 deployed as quickly as possible, = but funding issues are serious. Most people differentiate between = current system and next-gen stuff, redoing entire system. Trying to fund = this in less than a decade, more optimistic after the meeting. WiMAX = folks were worrisome, but they made a connection that didn't exist = before the meeting. Need to follow up with IEEE/WiMAX, need better = communication. Hannes - WiMAX isn't IEEE, it's the user forum, right? Steve Norris - we have the list of problems that need to be solved, but = slides didn't capture synergies between groups. They vary by timescales, = but that's the only difference, this is their opportunity to push the = world. Bernard - what liaison does this working group want to carry forward? At = your disposal if you have a plan. Brian - specific suggestion - joint working group between 3GPP and IETF = was productive, would like to see same thing with IEEE.=20 Bernard - could start with a conversation. Don't even see IEEE groups = talking to each other, so there's still work to do. Jonathan - don't paper over differences between 3GPP and other = architectures, device moves into another network and simply doesn't = work. Need some common fallback, etc. Bernard - look at IAB liaison documents - WGs can send letters (with WG = consensus) - get things down on paper first, where others can look at it Brian - start with framework document and ask for comments, then we can = work on details 3. A Location-to-Service Translation Protocol (LoST) draft-ietf-ecrit-lost-02.txt Henning Schulzrinne / Andy Newton=20 (15 minutes) Pattern now is three request elements and response elements Find service Include attributes added to show valid/invalid/unchecked. Author team met this morning, has additional changes they want to make. Service Boundary reference added for low-bandwidth clients, etc.=20 Brian - question the use of this - if you can't handle a large amount of = traffic, you still get it when you dereference? Henning - not convinced it's a huge advantage, but assume service = boundaries are political and long-term stable. Retrieve once and check = for changes. Andy - don't know if anyone has talked about deltas for the deferenced = information. Henning - maybe have a smaller description of a simpler polygon - not = sure worthwhile to have this complexity. Brian - complexity tradeoff could also be how often you get complexity Andy - interesting in many ways, take this conversation to the list. = Like Henning's use case, hadn't thought of that before Hannes - discussed at last meeting, people complained, Austria had large = polygons.=20 Henning - don't have to get too uptight about protocol complexity here.=20 Andy - need to talk about lifetime of reference, etc. Unchecked indicator added in this version of the spec. Brian - unchecked is very valuable. On list - is there hierarchy? Location profiles are biggest addition in this version of the document. = Geo is where the number of identifiers really goes up. Multiple = namespaces, very flexible. Rohan - really like this, mandatory-to-implement is a really good thing. Brian - useful enough to replicate to other location users (location = conveyance, etc.)? Andy - good point. May want to talk about this.=20 James - geoshape only defines half a dozen shapes - is that reasonable? Andy - don't think everyone supports all the shapes. No one has defined = what 3D looks like.Prism doesn't exist yet ... the return value is the = interesting part. No one has defined all the details.=20 Hannes - ???? Andy - service boundary and location element both support multiple = namespaces, easily see ??? being added. MUST IMPLEMENT profiles - geodetic-2D, civid Client must support both 2D and civic responses, servers must implement = both. Open issues a.. Error responses changed. b.. TTL will be absolute. c.. "include" effects on caching d.. Ordering of element names e.. Order preference of location profiles f.. Algorithm for adding (was lost) g.. Loosen uip service value syntax h.. Signing Rohan - should have multiple display names, will post to issue tracker Andy - good suggestion. Want to separate errors from warnings, SIP interaction will be specified = in another document. Steve Norris - still worried about this - person making emergency call = needs to do something, but they will be panicing. Machine can do this, = but people behave strangely Henning - want to return something useful if possible, but may be = nothing useful to return (invalid country code, etc). Hope is that we = don't need to do this at call time. What if there's no emergency = equipment there? Errors come in several flavors (don't understand = specific request, don't understand location information). If you can = return a default value, please do that.=20 Andy - benefits no one to return an answer with an error. Authors think errors/warnngs make more sense, enable resolver data = insertion, move to absolute TTL to accommodate D-SIG (just not in this = pass). There is a difference between asking about locations and asking what = services are supported for the location. Ted - making location option seemed to be the right thing to so, please = check this Brian - big step forward, still have a hole about finding servers in the = forest. Henning- charter date for this item, want to get this work done. = Addressed all known issues? Second - create new document, not even = chartered yet. This is a synchronization problem. Not THAT complicated, = needs to be done. Andy document will go to WGLC soon (couple of weeks?) Keith - geopriv issue, still have no way to map areas to protocols.=20 Henning - author team talked on this, not on these slides. Will do the = same thing as SIP - when we change protocols, we add a flag. Keith - ??? Marc - how many people understand this draft? Not many - please comment = soon! want WGLC before too much longer. Hannes - need some expert reviewers.=20 4. Location-to-URL Mapping Architecture and Framework draft-ietf-ecrit-mapping-arch-00 Henning Schulzrinne (15 minutes) Document hasn't changed much, so these are upcoming changes. Two-minute refresher... Resolvers know forest guides, not trees. Forest guides are neutral arbitrators.=20 Individual "trees" will share information. Caching required for resiliency, at multiple levels.=20 Basic text is stable, need to generalize to multiple services, need to = move operational guidance to BCP. WGLC after next revision (01). Brian - don't know protocols are right until I see the architecture=20 (grabbing volunteer reviewers) Andy - don't think we need to see this document to do the protocol. Brian - this is so basic... needs to correctly reflect the protocol. Henning - we can panic later if this document is really late. Jonathan - with Brian - this is hard stuff, should take a look later. 5. Framework for Emergency Calling draft-ietf-ecrit-framework-00=20 Brian Rosen, Henning Schulzrinne, Andrew Newton, James Polk (15 minutes) Should not have any normative text in this document (please let Brian = know if you see any).=20 Changed terminology. Need to update to match LoST 02. Open issues - marking, insufficient review. Want to make sure the = document is right, means what it says. Hannes - finished by December? Solicit feedback from external = organizations, need time for this.=20 Expert reviewers? Peter? Steve? yes. Andy - marking is in framework document? Brian - yes, but normative is in phone BCP. Andy - can we come to resolution here? If we have time. Keith - anything special about call-back? Do we mark these as special?=20 Brian - don't think this is completely specified. 6. Best Current Practice for Communications Services in support of = Emergency Calling draft-ietf-ecrit-phonebcp-00.txt James Polk / Brian Rosen (15 minutes) Updating to reflect mechanism changes in LoST No open issues, but marking will lead to changes.=20 Don't need expert review, but please read the documents. Keith - document requires you to reveal your identity, unless you are = using an anonymizer.=20 Peter - document structure - another BCP on system side and = infrastructure?=20 Brian - clients and servers in this document - could rename the document = to reflect this, don't think we're breaking document into two parts. = Should give guidance to anyone to show what they must do with this = stuff. 7. A DHCP based LoST Discovery Procedure draft-polk-ecrit-dhc-lost-discovery-01.txt Henning Schulzrinne / James Polk (5 minutes) DHC will be one of several such mechanisms (like SIP configuration, = Geopriv on list discovery, etc.).=20 Draft is one powerpoint bullet - one domain name, no IP addresses or = anything else. You do translation before you send request. Doman name representation has been worked out with DHC chairs. Assume exactly one LoST server, use NAPTR for multiple servers. Need to do joint last call with DHC, no dependencies on anything else. DHC will do review at the end of our process. Who has read the draft? A few. Progress as WG item? Humms - many yes, no "no" humms. 8. IANA Registering a SIP Resource Priority Header=20 Namespace for Local Emergency Communications draft-polk-ecrit-local-emergency-rph-namespace-00 James Polk (5 minutes)=20 Indications for mesages - had a spare four hours and wrote this draft, = just a new resource priority namespace, didn't propose a specific = namespace, but there are several alternatives, don't care which. Just floating the idea - resource priority took six years, need to start = now. NENA needs this. Requires standards-track RFC. Multiple priorities? in the draft, not a solid proposal.=20 4412 goal is not to have lots of name spaces, so looking to consolidate. Jonathan - worries about this for users making calls. We already have = marking on the call, can't allow this if call isn't emergency call, so = it should already be marked. James - Brian and I agree, this is the alternative marking proposal. Jonathan - mark me opposed! Henning - objection on mailing list - conflating user authority and = forwarding authority - need one namespace. Be careful - marking = emergency calls has a lot of side effects, bundle so you can't get one = without the other. SIP has lots of headers already. Don't look at = details of this proposal, look at broader marking discussion. Brian Stucker - callbacks don't suffer from huge authorization problem, = don't have other considerations for this. Brian - useful for call-in/call-out, asking for resource priority, do = have some redundancy, but they mean different things and have different = effects. Janet - these namespaces are not expected to be used for PSAP-PSAP or = PSAP-first responders. Steve Norris - would all be marked in the same way and treated the same = way - we have two kinds of marking (off and on). Ted - understand issue Jonathan raised and agree. If you aren't also = going to service URN as a target, this shouldn't work, but ... there is = a tight binding here. Jonathan - when you have two things that have to be the same, then = you're introducing error conditions where they aren't the same. Ted - is inferring this sufficient? Henning - last thing we want to do is fail the call - at least handle at = normal priority, not drop. MARKING DISCUSSION - HENNING Marking needs to survive translations (redirections, etc.). Would be = nice to ensure that only emergency calls get this marking, so you can = never call your aunt as an emergency call unless she works at a PSAP - = these are two core requirements. Request URI, To URI, special header, caller preferences, parameter - = these are the possibilities. Brian - Route?=20 Henning - probably not, identiies PSAP but not marking. Choices seem to be request URI and route header. Steve Norris - separation of marker from routing. You could do = reconciliation. Lots of operator systems in UK, but not emergency calls. = Henning - this was first requirement.=20 Jonathan - only thing you use is the marker that says "going to PSAP" - = this is the request URI.=20 Henning - People haven't read draft, so maybe we should give people time = to digest.=20 Henning - BCP-level thing - is it the obligation to verify route at = every proxy?=20 James - focusing too much on only getting to a PSAP, that's only part of = the problem. Going from a PSAP to a valid person? Brian - this would work, because if you hand off, you're still going to = onother PSAP. Henning - "I'm an emergency operator, you should check out your = account". Authorization is more trait-based. Keep this separate because = issues are different. James - trait-based assertion is harder on intermediate nodes. Jonathan - this is a general SIP problem. Every proxy has to have rules = for routing incoming requests. You're in this framework.=20 Brian??? - problem with 3GPP - request URI has backwards compatibility = problems if we're not using telephone number. Dennis Burke? - interest is for routing, not priority? Henning - solve routing problem first, then make determination about = whether request URI is sufficient or now.=20 Brian Stucker - has nothing to do with authorization, proxy has to do = lots of checks anyway before treating the call specially. Don't = understand combining who I am calling and how I am handling the call. = Don't agree you have to solve the routing problem first. "This is the = way I want to be treated", regardless of routing. (Out of time at this point) ------=_NextPart_000_1399_01C7027D.6AE30960 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hope these are=20 helpful!

Spencer

Emergency Context = Resolution with=20 Internet Technologies WG (ECRIT) Agenda for IETF 67
TUESDAY, November = 7,=20 2006
1300-1500 Afternoon Session I
Grande Ballroom A

1. = Agenda=20 Bashing, Document Status and Milestones
Chairs
(15 = minutes)

No=20 agenda bashing noted

a. = draft-ietf-ecrit-requirements-12.txt
b.=20 draft-ietf-ecrit-service-urn-05.txt
c.=20 draft-ietf-ecrit-security-threats-03.txt

Have been forwarded to = the IESG=20 for publication (the good news), may hear back from them (the bad news). = Proto=20 writeup is all done.

We're running close to our milestones (amaze = your=20 friends in the IETF).

There is now an unofficial ECRIT blog from = the=20 supplementary web page, and an implementation tracker page (with mailing = list -=20 contact chairs to join).

2. Report about the SDO Emergency = Services=20 Coordination Workshop
Hannes Tschofenig / Marc Linsner
(30=20 minutes)

Acknowledgements to those who helped and=20 participated...

Several links to information are included in the = slides=20 from this presentation.

More than 30 presentations from various=20 SDOs.

3GPP - had already had a workshop with 3GPP in July, were already = aware of=20 many details, but 3GPP2 also confirmed requirements.
IEEE 802.11 emergency service identification, location, = unauthenticated=20 access.
IEEE 802.1AB - link layer discovery protocol and LDP-MED.
Several presentations from ECRIT WG.
PacketCable showed architecture and solutions.
NENA
TIA -TR-45
OMA
ITU-T - focused on early warning, not working on 911
ETSI EMTEL doing requirements,
OCG talked about GML
EU Commission (regulatory framework, player responsibilities in = our=20 architecture)
COMCARE pointers to OASIS standards for authority-to-authority=20 communication,
ESIF NGES talked about NENA i3 requirements and their plans to = build on=20 those requirements
ANSI HSSP offered forum for standards and coordination. They are = also=20 working on a white paper.
US department of transportation
Emergency Services in Austria - for current VoIP provider
Emergency Services Prototype from Henning.

Major open issues

Architectural
Whether to send location information to the endpoints
Who should develop which protocols
Role of a "global coordinator"

Next Steps

Schedule another workshop in six months
Inform other SDOs about this work
Request feedback from other SDOs about LoST, Phone BCP, etc.
Topic-specific liaisons, if necessary (discuss this with = IAB)
Perform workshops with SDOs on selected topics - possibly IEEE, = OMA - IPR=20 policy incompatibility concerns here

Peter - concerns about streaming from this workshop, poor=20 quality

Henning - versioning problem. Some people are supporting = existing=20 PSAP architectures, NENE i-2, not i-3 versions.

Marc - i-2 = is=20 being stretched to cover more environments (mobile, etc, never intended = to cover=20 these).

Brian - effort in NENA is to get i-3 deployed as quickly = as=20 possible, but funding issues are serious. Most people differentiate = between=20 current system and next-gen stuff, redoing entire system. Trying to fund = this in=20 less than a decade, more optimistic after the meeting. WiMAX folks were=20 worrisome, but they made a connection that didn't exist before the = meeting. Need=20 to follow up with IEEE/WiMAX, need better communication.

Hannes - = WiMAX=20 isn't IEEE, it's the user forum, right?

Steve Norris - we have = the list=20 of problems that need to be solved, but slides didn't capture synergies = between=20 groups. They vary by timescales, but that's the only difference, this is = their=20 opportunity to push the world.

Bernard - what liaison does this = working=20 group want to carry forward? At your disposal if you have a = plan.

Brian -=20 specific suggestion - joint working group between 3GPP and IETF was = productive,=20 would like to see same thing with IEEE.

Bernard - could start = with a=20 conversation. Don't even see IEEE groups talking to each other, so = there's still=20 work to do.

Jonathan - don't paper over differences between 3GPP = and=20 other architectures, device moves into another network and simply = doesn't work.=20 Need some common fallback, etc.

Bernard - look at IAB liaison = documents -=20 WGs can send letters (with WG consensus) - get things down on paper = first, where=20 others can look at it

Brian - start with framework document and = ask for=20 comments, then we can work on details

3. A Location-to-Service=20 Translation Protocol (LoST)
draft-ietf-ecrit-lost-02.txt
Henning=20 Schulzrinne / Andy Newton
(15 minutes)

Pattern now is three = request=20 elements and response elements

Find service Include attributes = added to=20 show valid/invalid/unchecked.

Author team met this morning, has=20 additional changes they want to make.

Service Boundary reference = added=20 for low-bandwidth clients, etc.

Brian - question the use of this = - if=20 you can't handle a large amount of traffic, you still get it when you=20 dereference?

Henning - not convinced it's a huge advantage, but = assume=20 service boundaries are political and long-term stable. Retrieve once and = check=20 for changes.

Andy - don't know if anyone has talked about deltas = for the=20 deferenced information.

Henning - maybe have a smaller = description of a=20 simpler polygon - not sure worthwhile to have this = complexity.

Brian -=20 complexity tradeoff could also be how often you get = complexity

Andy -=20 interesting in many ways, take this conversation to the list. Like = Henning's use=20 case, hadn't thought of that before

Hannes - discussed at last = meeting,=20 people complained, Austria had large polygons.

Henning - don't = have to=20 get too uptight about protocol complexity here.

Andy - need to = talk=20 about lifetime of reference, etc.

Unchecked indicator added in = this=20 version of the spec.

Brian - unchecked is very valuable. On list = - is=20 there hierarchy?

Location profiles are biggest addition in this = version=20 of the document. Geo is where the number of identifiers really goes up. = Multiple=20 namespaces, very flexible.

Rohan - really like this,=20 mandatory-to-implement is a really good thing.

Brian - useful = enough to=20 replicate to other location users (location conveyance, = etc.)?

Andy -=20 good point. May want to talk about this.

James - geoshape only = defines=20 half a dozen shapes - is that reasonable?

Andy - don't think = everyone=20 supports all the shapes. No one has defined what 3D looks like.Prism = doesn't=20 exist yet ... the return value is the interesting part. No one has = defined all=20 the details.

Hannes - ????

Andy - service boundary and = location=20 element both support multiple namespaces, easily see ??? being=20 added.

MUST IMPLEMENT profiles - geodetic-2D, civid

Client = must=20 support both 2D and civic responses, servers must implement = both.

Open=20 issues

Error responses changed.
TTL will be absolute.
"include" effects on caching
Ordering of element names
Order preference of location profiles
Algorithm for adding <via> (was lost)
Loosen uip service value syntax
Signing

Rohan - should have multiple display names, will post to issue=20 tracker

Andy - good suggestion.

Want to separate errors = from=20 warnings, SIP interaction will be specified in another = document.

Steve=20 Norris - still worried about this - person making emergency call needs = to do=20 something, but they will be panicing. Machine can do this, but people = behave=20 strangely

Henning - want to return something useful if possible, = but may=20 be nothing useful to return (invalid country code, etc). Hope is that we = don't=20 need to do this at call time. What if there's no emergency equipment = there?=20 Errors come in several flavors (don't understand specific request, don't = understand location information). If you can return a default value, = please do=20 that.

Andy - benefits no one to return an answer with an=20 error.

Authors think errors/warnngs make more sense, enable = resolver data=20 insertion, move to absolute TTL to accommodate D-SIG (just not in this=20 pass).

There is a difference between asking about locations and = asking=20 what services are supported for the location.

Ted - making = location=20 option seemed to be the right thing to so, please check = this

Brian - big=20 step forward, still have a hole about finding servers in the=20 forest.

Henning- charter date for this item, want to get this = work done.=20 Addressed all known issues? Second - create new document, not even = chartered=20 yet. This is a synchronization problem. Not THAT complicated, = needs to be=20 done.

Andy document will go to WGLC soon (couple of = weeks?)

Keith=20 - geopriv issue, still have no way to map areas to protocols. =

Henning -=20 author team talked on this, not on these slides. Will do the same thing = as SIP -=20 when we change protocols, we add a flag.

Keith - ???

Marc = - how=20 many people understand this draft? Not many - please comment soon! want = WGLC=20 before too much longer.

Hannes - need some expert reviewers. =

4.=20 Location-to-URL Mapping Architecture and=20 Framework
draft-ietf-ecrit-mapping-arch-00
Henning = Schulzrinne
(15=20 minutes)

Document hasn't changed much, so these are upcoming=20 changes.

Two-minute refresher...

Resolvers know forest = guides, not=20 trees.

Forest guides are neutral arbitrators.

Individual = "trees"=20 will share information.

Caching required for resiliency, at = multiple=20 levels.

Basic text is stable, need to generalize to multiple = services,=20 need to move operational guidance to BCP. WGLC after next revision=20 (01).

Brian - don't know protocols are right until I see the = architecture=20

(grabbing volunteer reviewers)

Andy - don't think we need = to see=20 this document to do the protocol.

Brian - this is so basic... = needs to=20 correctly reflect the protocol.

Henning - we can panic later if = this=20 document is really late.

Jonathan - with Brian - this is hard = stuff,=20 should take a look later.

5. Framework for Emergency=20 Calling
draft-ietf-ecrit-framework-00
Brian Rosen, Henning = Schulzrinne,=20 Andrew Newton, James Polk
(15 minutes)

Should not have any = normative=20 text in this document (please let Brian know if you see any). =

Changed=20 terminology. Need to update to match LoST 02.

Open issues - = marking,=20 insufficient review. Want to make sure the document is right, means what = it=20 says.

Hannes - finished by December? Solicit feedback from = external=20 organizations, need time for this.

Expert reviewers? = Peter? Steve?=20 yes.

Andy - marking is in framework document?

Brian - yes, = but=20 normative is in phone BCP.

Andy - can we come to resolution here? = If we=20 have time.

Keith - anything special about call-back? Do we mark = these as=20 special?

Brian - don't think this is completely = specified.

6.=20 Best Current Practice for Communications Services in support of = Emergency=20 Calling
draft-ietf-ecrit-phonebcp-00.txt
James Polk / Brian = Rosen
(15=20 minutes)

Updating to reflect mechanism changes in LoST

No = open=20 issues, but marking will lead to changes.

Don't need expert = review, but=20 please read the documents.

Keith - document requires you to = reveal your=20 identity, unless you are using an anonymizer.

Peter - document = structure=20 - another BCP on system side and infrastructure?

Brian - clients = and=20 servers in this document - could rename the document to reflect this, = don't=20 think we're breaking document into two parts. Should give guidance to = anyone to=20 show what they must do with this stuff.

7. A DHCP based LoST = Discovery=20 Procedure
draft-polk-ecrit-dhc-lost-discovery-01.txt
Henning = Schulzrinne /=20 James Polk
(5 minutes)

DHC will be one of several such = mechanisms=20 (like SIP configuration, Geopriv on list discovery, etc.).

Draft = is one=20 powerpoint bullet - one domain name, no IP addresses or anything else. = You do=20 translation before you send request.

Doman name representation = has been=20 worked out with DHC chairs.

Assume exactly one LoST server, use = NAPTR for=20 multiple servers.

Need to do joint last call with DHC, no = dependencies on=20 anything else.

DHC will do review at the end of our = process.

Who=20 has read the draft? A few.

Progress as WG item? Humms - many yes, = no "no"=20 humms.

8. IANA Registering a SIP Resource Priority Header =
Namespace=20 for Local Emergency=20 Communications
draft-polk-ecrit-local-emergency-rph-namespace-00
Ja= mes=20 Polk
(5 minutes)

Indications for mesages - had a spare four = hours and=20 wrote this draft, just a new resource priority namespace, didn't propose = a=20 specific namespace, but there are several alternatives, don't care=20 which.

Just floating the idea - resource priority took six years, = need to=20 start now.

NENA needs this.

Requires standards-track=20 RFC.

Multiple priorities? in the draft, not a solid proposal.=20

4412 goal is not to have lots of name spaces, so looking to=20 consolidate.

Jonathan - worries about this for users making = calls. We=20 already have marking on the call, can't allow this if call isn't = emergency call,=20 so it should already be marked.

James - Brian and I agree, this = is the=20 alternative marking proposal.

Jonathan - mark me = opposed!

Henning=20 - objection on mailing list - conflating user authority and forwarding = authority=20 - need one namespace. Be careful - marking emergency calls has a lot of = side=20 effects, bundle so you can't get one without the other. SIP has lots of = headers=20 already. Don't look at details of this proposal, look at broader marking = discussion.

Brian Stucker - callbacks don't suffer from huge=20 authorization problem, don't have other considerations for = this.

Brian -=20 useful for call-in/call-out, asking for resource priority, do have some=20 redundancy, but they mean different things and have different=20 effects.

Janet - these namespaces are not expected to be used for = PSAP-PSAP or PSAP-first responders.

Steve Norris - would all be = marked in=20 the same way and treated the same way - we have two kinds of marking = (off and=20 on).

Ted - understand issue Jonathan raised and agree. If you = aren't also=20 going to service URN as a target, this shouldn't work, but ... there is = a tight=20 binding here.

Jonathan - when you have two things that have to be = the=20 same, then you're introducing error conditions where they aren't the=20 same.

Ted - is inferring this sufficient?

Henning - last = thing we=20 want to do is fail the call - at least handle at normal priority, not=20 drop.

MARKING DISCUSSION - HENNING

Marking needs to = survive=20 translations (redirections, etc.). Would be nice to ensure that only = emergency=20 calls get this marking, so you can never call your aunt as an emergency = call=20 unless she works at a PSAP - these are two core = requirements.

Request=20 URI, To URI, special header, caller preferences, parameter - these are = the=20 possibilities.

Brian - Route?

Henning - probably not, = identiies=20 PSAP but not marking.

Choices seem to be request URI and route=20 header.

Steve Norris - separation of marker from routing. You = could do=20 reconciliation. Lots of operator systems in UK, but not emergency calls. =

Henning - this was first requirement.

Jonathan - only = thing you=20 use is the marker that says "going to PSAP" - this is the request URI.=20

Henning - People haven't read draft, so maybe we should give = people time=20 to digest.

Henning - BCP-level thing - is it the obligation to = verify=20 route at every proxy?

James - focusing too much on only getting = to a=20 PSAP, that's only part of the problem. Going from a PSAP to a valid=20 person?

Brian - this would work, because if you hand off, you're = still=20 going to onother PSAP.

Henning - "I'm an emergency operator, you = should=20 check out your account". Authorization is more trait-based. Keep this = separate=20 because issues are different.

James - trait-based assertion is = harder on=20 intermediate nodes.

Jonathan - this is a general SIP problem. = Every proxy=20 has to have rules for routing incoming requests. You're in this = framework.=20

Brian??? - problem with 3GPP - request URI has backwards = compatibility=20 problems if we're not using telephone number.

Dennis Burke? - = interest is=20 for routing, not priority?

Henning - solve routing problem first, = then=20 make determination about whether request URI is sufficient or now. =

Brian=20 Stucker - has nothing to do with authorization, proxy has to do lots of = checks=20 anyway before treating the call specially. Don't understand combining = who I am=20 calling and how I am handling the call. Don't agree you have to solve = the=20 routing problem first. "This is the way I want to be treated", = regardless of=20 routing.

(Out of time at this point)

------=_NextPart_000_1399_01C7027D.6AE30960-- --===============0558027001== 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 --===============0558027001==-- From ecrit-bounces@ietf.org Tue Nov 07 18:45:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghacq-0007xE-Ve; Tue, 07 Nov 2006 18:45:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghacp-0007wz-NG for ecrit@ietf.org; Tue, 07 Nov 2006 18:45:03 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghacp-00014i-Lu for ecrit@ietf.org; Tue, 07 Nov 2006 18:45:03 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ghacp-0005lH-EX for ecrit@ietf.org; Tue, 07 Nov 2006 18:45:03 -0500 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns4.neustar.com (Postfix) with ESMTP id 5EC432AC14 for ; Tue, 7 Nov 2006 23:44:33 +0000 (GMT) Received: from stntexch12.cis.neustar.com ([10.31.13.31]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 18:44:32 -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: Tue, 7 Nov 2006 18:44:31 -0500 Message-ID: <886DD03D15173C43BCE98EA662A0101A14945C@stntexch12.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UA Loose Route mechanism as Marking Thread-Index: AccCxqwDMLmIj2vzTBqtZ3j4NHAowQ== From: "Rosen, Brian" To: , X-OriginalArrivalTime: 07 Nov 2006 23:44:32.0686 (UTC) FILETIME=[ACA89CE0:01C702C6] X-Spam-Score: -2.8 (--) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ecrit@ietf.org Subject: [Ecrit] UA Loose Route mechanism as Marking X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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 thing not handled by UA loose route is to differentiate the case where an emergency call has been detected, but no route has yet been determined.=20 Consider: INVITE urn:service:sos To: 911@example.com Route: e-cscf.example.com From INVITE urn:service:sos To: 911@example.com Route: psap@nyc.ny.us The first is an example where the (forgive me) P-CSCF did dialstring recognition for a really dumb UA, but the E-CSCF has not yet routed the call using LoST. In the second, it has. The only difference is the actual URI in the Route header. =20 I'm concerned that the only way to determine if LoST routing has been done is to do it again and analyze the Route headers. Not a good plan I would think. INVITE urn:service:sos To: urn:service:sos Route: p-cscf.example.com Route: psap@nyc.ny.us This is what I would think the UA that does its own dialstring and LoST routing would put out. Do we need a "dip indicator"? Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 07 19:17:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghb7p-0008T4-Jw; Tue, 07 Nov 2006 19:17:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghb7o-0008Sz-W8 for ecrit@ietf.org; Tue, 07 Nov 2006 19:17:04 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghb7n-0005Pw-OO for ecrit@ietf.org; Tue, 07 Nov 2006 19:17:04 -0500 Received: from [130.129.66.46] (dhcp66-46.ietf67.org [130.129.66.46]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kA80GpH1022967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 7 Nov 2006 19:16:52 -0500 (EST) In-Reply-To: <886DD03D15173C43BCE98EA662A0101A14945C@stntexch12.cis.neustar.com> References: <886DD03D15173C43BCE98EA662A0101A14945C@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 Date: Tue, 7 Nov 2006 16:16:49 -0800 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.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ecrit@ietf.org Subject: [Ecrit] Re: UA Loose Route mechanism as Marking X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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 this is a problem. In the first case, the E-CSCF will do the LoST dip and is indeed the destination of the route. Thus, it clearly has to do *something*. It only has to recognize itself, as per normal Route behavior. On Nov 7, 2006, at 3:44 PM, Rosen, Brian wrote: > One thing not handled by UA loose route is to differentiate the case > where an emergency call has been detected, but no route has yet been > determined. > > Consider: > > INVITE urn:service:sos > To: 911@example.com > Route: e-cscf.example.com > > From > INVITE urn:service:sos > To: 911@example.com > Route: psap@nyc.ny.us > > The first is an example where the (forgive me) P-CSCF did dialstring > recognition for a really dumb UA, but the E-CSCF has not yet routed > the > call using LoST. In the second, it has. The only difference is the > actual URI in the Route header. > > I'm concerned that the only way to determine if LoST routing has been > done is to do it again and analyze the Route headers. Not a good > plan I > would think. > > INVITE urn:service:sos > To: urn:service:sos > Route: p-cscf.example.com > Route: psap@nyc.ny.us > > This is what I would think the UA that does its own dialstring and > LoST > routing would put out. > > Do we need a "dip indicator"? > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 07 19:29:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhbJd-0000wp-LC; Tue, 07 Nov 2006 19:29:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhbJc-0000wj-4g for ecrit@ietf.org; Tue, 07 Nov 2006 19:29:16 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhbJa-0006Ye-QX for ecrit@ietf.org; Tue, 07 Nov 2006 19:29:16 -0500 Received: from [130.129.71.98] (dhcp71-98.ietf67.org [130.129.71.98]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id kA80T2F19218; Tue, 7 Nov 2006 17:29:02 -0700 Message-ID: <455124C7.6090702@ntt-at.com> Date: Tue, 07 Nov 2006 16:28:55 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Re: UA Loose Route mechanism as Marking References: <886DD03D15173C43BCE98EA662A0101A14945C@stntexch12.cis.neustar.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: c0bedb65cce30976f0bf60a0a39edea4 Cc: "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 agree with Henning that there is no worries if there is only one entity that queries the LoST on the signaling path, that the indicator is not necessary. But if there is more than one entity including the originator doing the LoST query, not having the dip indicator can impose some issues(delay, in case later dip fails etc.).. I really don't know if this is an issue, but may be.. Regards Shida Henning Schulzrinne wrote: > I'm not sure this is a problem. In the first case, the E-CSCF will do > the LoST dip and is indeed the destination of the route. Thus, it > clearly has to do *something*. It only has to recognize itself, as per > normal Route behavior. > > On Nov 7, 2006, at 3:44 PM, Rosen, Brian wrote: > >> One thing not handled by UA loose route is to differentiate the case >> where an emergency call has been detected, but no route has yet been >> determined. >> >> Consider: >> >> INVITE urn:service:sos >> To: 911@example.com >> Route: e-cscf.example.com >> >> From >> INVITE urn:service:sos >> To: 911@example.com >> Route: psap@nyc.ny.us >> >> The first is an example where the (forgive me) P-CSCF did dialstring >> recognition for a really dumb UA, but the E-CSCF has not yet routed the >> call using LoST. In the second, it has. The only difference is the >> actual URI in the Route header. >> >> I'm concerned that the only way to determine if LoST routing has been >> done is to do it again and analyze the Route headers. Not a good plan I >> would think. >> >> INVITE urn:service:sos >> To: urn:service:sos >> Route: p-cscf.example.com >> Route: psap@nyc.ny.us >> >> This is what I would think the UA that does its own dialstring and LoST >> routing would put out. >> >> Do we need a "dip indicator"? >> >> 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 Tue Nov 07 19:40:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhbUB-000150-F0; Tue, 07 Nov 2006 19:40:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhbU9-00013s-Mk for ecrit@ietf.org; Tue, 07 Nov 2006 19:40:09 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhbU8-0007wV-EQ for ecrit@ietf.org; Tue, 07 Nov 2006 19:40:09 -0500 Received: from [130.129.66.46] (dhcp66-46.ietf67.org [130.129.66.46]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kA80druS018372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 7 Nov 2006 19:39:58 -0500 (EST) In-Reply-To: <455124C7.6090702@ntt-at.com> References: <886DD03D15173C43BCE98EA662A0101A14945C@stntexch12.cis.neustar.com> <455124C7.6090702@ntt-at.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1278CAB7-E83B-4A95-A684-510D24C2B1E6@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Re: UA Loose Route mechanism as Marking Date: Tue, 7 Nov 2006 16:39:52 -0800 To: Shida Schubert 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: c3a18ef96977fc9bcc21a621cbf1174b Cc: "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 think this recurses: The first LoST-querying proxy inserts a route, which directs the request to a second proxy (say, state-level). There, that second proxy, the one identified in the Route header, repeats the mapping, maybe yielding the county proxy. And so on. As long as the general rule is that the destination of the Route does the lookup, things should work automatically. (I don't think you want some entity in the middle of the route list to do the lookup, essentially overriding the existing route, but that's more of a policy issue.) Clearly, that last proxy has to do the lookup, since it has run out of other indications of where to send the request. Henning On Nov 7, 2006, at 4:28 PM, Shida Schubert wrote: > > I agree with Henning that there is no worries if there is only one > entity that queries the > LoST on the signaling path, that the indicator is not necessary. > But if there is more > than one entity including the originator doing the LoST query, not > having the dip indicator > can impose some issues(delay, in case later dip fails etc.).. > > I really don't know if this is an issue, but may be.. > > Regards > Shida > > Henning Schulzrinne wrote: >> I'm not sure this is a problem. In the first case, the E-CSCF will >> do the LoST dip and is indeed the destination of the route. Thus, >> it clearly has to do *something*. It only has to recognize itself, >> as per normal Route behavior. >> >> On Nov 7, 2006, at 3:44 PM, Rosen, Brian wrote: >> >>> One thing not handled by UA loose route is to differentiate the case >>> where an emergency call has been detected, but no route has yet been >>> determined. >>> >>> Consider: >>> >>> INVITE urn:service:sos >>> To: 911@example.com >>> Route: e-cscf.example.com >>> >>> From >>> INVITE urn:service:sos >>> To: 911@example.com >>> Route: psap@nyc.ny.us >>> >>> The first is an example where the (forgive me) P-CSCF did dialstring >>> recognition for a really dumb UA, but the E-CSCF has not yet >>> routed the >>> call using LoST. In the second, it has. The only difference is the >>> actual URI in the Route header. >>> >>> I'm concerned that the only way to determine if LoST routing has >>> been >>> done is to do it again and analyze the Route headers. Not a good >>> plan I >>> would think. >>> >>> INVITE urn:service:sos >>> To: urn:service:sos >>> Route: p-cscf.example.com >>> Route: psap@nyc.ny.us >>> >>> This is what I would think the UA that does its own dialstring >>> and LoST >>> routing would put out. >>> >>> Do we need a "dip indicator"? >>> >>> 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 Tue Nov 07 22:12:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghdra-00060P-EJ; Tue, 07 Nov 2006 22:12:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhdrZ-0005yR-Dh for ecrit@ietf.org; Tue, 07 Nov 2006 22:12:29 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghde0-0000e0-Lo for ecrit@ietf.org; Tue, 07 Nov 2006 21:58:29 -0500 Received: from [130.129.66.46] (dhcp66-46.ietf67.org [130.129.66.46]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kA82wOke004923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 7 Nov 2006 21:58:25 -0500 (EST) In-Reply-To: References: <454120F9.50402@cs.columbia.edu> <454E761C.8060603@ntt-at.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <46EC8B4F-37FA-4017-AAEF-7F269EA9B724@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Changes in LoST -02 Date: Tue, 7 Nov 2006 18:58:24 -0800 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.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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 Nov 5, 2006, at 6:39 PM, Shida Schubert wrote: >> 1. Now that the protocol is allowed to carry more than 1 location >> information >> in the findservice query, it may be a good idea to indicate >> which location was >> used to find out the URIs. >> > Otherwise I don't see how a server(proxy etc.) would be able >> to cache a response and >> later correlate it to a new request. > > Though I cannot see it in the draft, I thought there was wording > about the ordering of the elements to indicate > preference and likewise in the response. That would resolve the > issue above. But you are correct, we need to be able to indicate > which location profile was used for the answer. Given the previous discussion, it might be helpful to add that we clearly don't want to allow a LoST request to describe multiple points or even in different notations (civic and geo, say). > >> 2. Last paragraph in section 1 talks about how LoST is able to >> provide list of services that >> are provided in the location requested. Does this always hold >> true? I can see that the server >> is able to provide a list of services that the server in >> question can provide but I don't see >> how server will be aware of all the services that is provided >> in the area.. (What if service >> X is provided at a state level but service Y is provided at a >> city level??) > > Good question. I think that a query would not reach > an authoritative server. It would always either be answered by a > caching resolver via how it was configured to do resolution or from > information from a forrest guide. I agree that this needs clarification. There are really two separate questions: (1) What (top-level) services can a server handle? Each top-level service is likely to have its own forest guide, so asking my local emergency-only resolver for urn:service:restaurant isn't likely to be useful. This would be without a location. (2) What specific services are available for a particular region? This would have to travel to the authoritative server, unless the resolver has cached the answer to the query for that particular region. This calls for more description, assuming we agree on these two functions. > >> 6. Can client put an asterisk to indicate it wants all the >> possible information LoST server >> can provide in "include" attribute. > > I'll see if we can do this. It shouldn't be too hard in the Relax NG. We need to define what omitting 'include' means. We could define that no include means "give me everything you got". > >> 10. I don't understand why needs to be >> defined. Can't >> we just use the findService and have include > > The include attribute in specifies either > serviceBoundary or serviceBoundaryReference. This allows a client > to retrieve the service boundary in a separate message using the > query. This might be useful in networks with > low bandwidth with service boundaries that might take a lot to > express. To amplify this: service boundaries can be 8000 bytes long, based on our county boundary examples. This is large enough that it might be an issue for mobile devices. > >> 11. does not have the serviceURN in question. >> I am assuming >> that with LoST server possibly providing different services, >> each services can also >> have different boundary. If so the request and response >> should have the relevant >> service. > > The key should be good enough. If a server wants to implement the > creating of the key with the URN embedded in the key, then it is > free to do so. Though perhaps we should relax the regex to allow > this. Thanks for pointing this out. > The important properties are (probabilistically) global uniqueness and opaqueness, along with easy byte-by-byte comparison. For example, if somebody uses a URN, the recipient should not have to understand the URN scheme. In the interest of simplicity, I don't see great advantage of allowing more than just base-64 characters or even just the DNS ASCII character subset [A-Z0-9-], as opposed to, say, full UTF-8. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Nov 08 12:40:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhrOm-00063e-3S; Wed, 08 Nov 2006 12:39:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhrOk-00063O-TM for ecrit@ietf.org; Wed, 08 Nov 2006 12:39:38 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhrOj-0006Ox-FJ for ecrit@ietf.org; Wed, 08 Nov 2006 12:39:38 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA8HdKPG020339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 8 Nov 2006 09:39:21 -0800 Received: from [130.129.66.113] (vpn-10-50-16-45.qualcomm.com [10.50.16.45]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA8HdHgd016062; Wed, 8 Nov 2006 09:39:19 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <46EC8B4F-37FA-4017-AAEF-7F269EA9B724@cs.columbia.edu> References: <454120F9.50402@cs.columbia.edu> <454E761C.8060603@ntt-at.com> <46EC8B4F-37FA-4017-AAEF-7F269EA9B724@cs.columbia.edu> Date: Wed, 8 Nov 2006 09:39:17 -0800 To: Henning Schulzrinne , Andrew Newton From: Ted Hardie Subject: Re: [Ecrit] Changes in LoST -02 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 At 6:58 PM -0800 11/7/06, Henning Schulzrinne wrote: >>>6. Can client put an asterisk to indicate it wants all the possible information LoST server >>> can provide in "include" attribute. >> >>I'll see if we can do this. It shouldn't be too hard in the Relax NG. > >We need to define what omitting 'include' means. We could define that no include means "give me everything you got". What would that mean to a proxy? "Give me everything you currently know." (which might be limited to things previous clients had ed ) or "Give me everything, doing whatever discovery would be required"? Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Nov 08 14:15:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhstK-0005Ix-DN; Wed, 08 Nov 2006 14:15:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhstJ-0005Im-Uy for ecrit@ietf.org; Wed, 08 Nov 2006 14:15:17 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhstG-0004Ty-7m for ecrit@ietf.org; Wed, 08 Nov 2006 14:15:17 -0500 Received: from [130.129.34.108] (dhcp34-108.ietf67.org [130.129.34.108]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kA8JF7OA029287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 8 Nov 2006 14:15:11 -0500 (EST) In-Reply-To: References: <454120F9.50402@cs.columbia.edu> <454E761C.8060603@ntt-at.com> <46EC8B4F-37FA-4017-AAEF-7F269EA9B724@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: <464D5BE2-A336-48DF-A45D-C347398E54C6@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Changes in LoST -02 Date: Wed, 8 Nov 2006 11:15:07 -0800 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.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 > Thinking about this a bit more, I'm actually somewhat worried that such an option could be dangerous if future optional objects are large. Including things the receiver can't parse isn't too helpful and the semantics of "include at least this, but return more if you have it" already addresses the caching concerns. Maybe we should step back and ask what this would be needed for. > What would that mean to a proxy? "Give me everything you currently > know." > (which might be limited to things previous clients had > ed ) or > "Give me everything, doing whatever discovery would be required"? > > Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Nov 08 14:20:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghsxp-0007BI-Gf; Wed, 08 Nov 2006 14:19:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghsxo-00079v-5P for ecrit@ietf.org; Wed, 08 Nov 2006 14:19:56 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghsxm-000529-Ul for ecrit@ietf.org; Wed, 08 Nov 2006 14:19:56 -0500 Received: from [130.129.34.108] (dhcp34-108.ietf67.org [130.129.34.108]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kA8JJnrK008422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 8 Nov 2006 14:19:54 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: "Ecrit@Ietf.Org" From: Henning Schulzrinne Date: Wed, 8 Nov 2006 11:19:49 -0800 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.5 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ecrit] LoST issue: authoritative answer only, please X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Should there be a query flag that allows a seeker to specify that it would like the resolver to obtain an authoritative answer (recursively) from the authoritative mapping server (AMS), rather than a cached answer? In favor: Can bypass broken caches and allows easier debugging. Against: (1) Possibly dangerous tool that exposes the tree infrastructure to a much higher load if used indiscriminately. (2) Can be approximated by redirect mode. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Nov 08 17:06:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhvYn-0001tB-5S; Wed, 08 Nov 2006 17:06:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhvYm-0001sy-AX for ecrit@ietf.org; Wed, 08 Nov 2006 17:06:16 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhvYl-0006AN-28 for ecrit@ietf.org; Wed, 08 Nov 2006 17:06:16 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 08 Nov 2006 14:06:10 -0800 X-IronPort-AV: i="4.09,401,1157353200"; d="scan'208"; a="340913366:sNHT9836770726" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA8M6AdM026043; Wed, 8 Nov 2006 14:06:10 -0800 Received: from [130.129.71.37] (sjc-vpn4-302.cisco.com [10.21.81.46]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kA8M6AbF001822; Wed, 8 Nov 2006 14:06:10 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit] LoST issue: authoritative answer only, please Date: Wed, 8 Nov 2006 14:06:09 -0800 To: Henning Schulzrinne X-Mailer: Apple Mail (2.624) DKIM-Signature: a=rsa-sha1; q=dns; l=994; t=1163023570; x=1163887570; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jschnizl@cisco.com; z=From:John=20Schnizlein=20 |Subject:Re=3A=20[Ecrit]=20LoST=20issue=3A=20authoritative=20answer=20only, =20ple ase; X=v=3Dcisco.com=3B=20h=3DSG12/OD9yLzmmdUU3o/9/9MB9BY=3D; b=WA7gXteTzpmRmXEts4MBuNI7N5XlkSXHTmMpucIFrK0QMEcxShP56j+fK3UwOFYe8toipkRP Byh2+4cfHfOvKcJdq/q6TrWEqOvv7qQcOqO1xmURnYoPJMj8l3wdl7t5; Authentication-Results: sj-dkim-6.cisco.com; header.From=jschnizl@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Recreating the problems that DNS has with recursion for this protocol seems unwise, especially just as draft-ietf-dnsop-reflectors-are-evil is in Last Call in DNS-OP. At the very least, any recursion-desired flag should be accompanied by a flag that indicates the server's recursion-available status. If this approach is taken, the advice for mitigating denial-of-service in "reflectors-are-evil" should be included. John On Nov 8, 2006, at 11:19 AM, Henning Schulzrinne wrote: > Should there be a query flag that allows a seeker to specify that it > would like the resolver to obtain an authoritative answer > (recursively) from the authoritative mapping server (AMS), rather than > a cached answer? > > In favor: > Can bypass broken caches and allows easier debugging. > > Against: > (1) Possibly dangerous tool that exposes the tree infrastructure to > a much higher load if used indiscriminately. > (2) Can be approximated by redirect mode. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Nov 08 17:12:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhvfB-0000rb-Dt; Wed, 08 Nov 2006 17:12:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghvf9-0000rP-GW for ecrit@ietf.org; Wed, 08 Nov 2006 17:12:51 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghvf8-0007YU-9i for ecrit@ietf.org; Wed, 08 Nov 2006 17:12:51 -0500 Received: from [130.129.66.46] (dhcp66-46.ietf67.org [130.129.66.46]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kA8MCGlj024815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 8 Nov 2006 17:12:21 -0500 (EST) 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: <0D17AF2B-4369-435D-BA67-504F7FEF11C6@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST issue: authoritative answer only, please Date: Wed, 8 Nov 2006 14:12:16 -0800 To: John Schnizlein 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: e1e48a527f609d1be2bc8d8a70eb76cb 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 note in the introduction of that draft: asides perhaps the fact that DNS relies heavily on UDP, the easy abuse of which is at the source of the problem. Currently, only TCP has been specified as a transport protocol, although we've obviously had proposals to provide LoST-over-UDP as well. Any such proposals presumably would have to worry about the reflector attacks mentioned in the draft you cite. Thanks for providing the reference. On Nov 8, 2006, at 2:06 PM, John Schnizlein wrote: > Recreating the problems that DNS has with recursion for this > protocol seems unwise, especially just as draft-ietf-dnsop- > reflectors-are-evil is in Last Call in DNS-OP. > > At the very least, any recursion-desired flag should be accompanied > by a flag that indicates the server's recursion-available status. > If this approach is taken, the advice for mitigating denial-of- > service in "reflectors-are-evil" should be included. > > John > > On Nov 8, 2006, at 11:19 AM, Henning Schulzrinne wrote: > >> Should there be a query flag that allows a seeker to specify that >> it would like the resolver to obtain an authoritative answer >> (recursively) from the authoritative mapping server (AMS), rather >> than a cached answer? >> >> In favor: >> Can bypass broken caches and allows easier debugging. >> >> Against: >> (1) Possibly dangerous tool that exposes the tree infrastructure >> to a much higher load if used indiscriminately. >> (2) Can be approximated by redirect mode. >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Nov 08 17:25:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghvqn-0003BD-9Y; Wed, 08 Nov 2006 17:24:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghvql-0003B4-9j for ecrit@ietf.org; Wed, 08 Nov 2006 17:24:51 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghvqk-0001Vq-1C for ecrit@ietf.org; Wed, 08 Nov 2006 17:24:51 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 08 Nov 2006 14:24:49 -0800 X-IronPort-AV: i="4.09,401,1157353200"; d="scan'208"; a="340921921:sNHT36771046" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA8MOnFE026845 for ; Wed, 8 Nov 2006 14:24:49 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA8MOcB8017201 for ; Wed, 8 Nov 2006 14:24:49 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 14:24:40 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.145.156]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 14:24:37 -0800 Message-Id: <4.3.2.7.2.20061108162424.02dc2308@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Nov 2006 16:24:35 -0600 To: "'ecrit@ietf.org'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 08 Nov 2006 22:24:38.0187 (UTC) FILETIME=[AD53DFB0:01C70384] DKIM-Signature: a=rsa-sha1; q=dns; l=0; t=1163024689; x=1163888689; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:test,=20please=20ignore; X=v=3Dcisco.com=3B=20h=3DWTULUqcvj9ZVy6+rMrc8JvKwr3c=3D; b=Xeb6HVwtEOv7wxSdpcuRkaw1mrOtDeoI1sex188JgF+PV46ZTPE6zKemQJVWSL8qH1dPAVRV zACkhpjyWqmR7Dpi71TbT1xa6FU+wZjCFB6IwLJQi6VKosyyHoM7Ygd7; Authentication-Results: sj-dkim-3.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 Subject: [Ecrit] test, please ignore X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Nov 08 17:33:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhvyZ-0005D2-Ma; Wed, 08 Nov 2006 17:32:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhvyY-0005CP-Bj for ecrit@ietf.org; Wed, 08 Nov 2006 17:32:54 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhvyX-0003D1-1b for ecrit@ietf.org; Wed, 08 Nov 2006 17:32:54 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 08 Nov 2006 14:32:52 -0800 X-IronPort-AV: i="4.09,401,1157353200"; d="scan'208"; a="755462331:sNHT46601236" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA8MWqY1009356 for ; Wed, 8 Nov 2006 14:32:52 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA8MWqAo024944 for ; Wed, 8 Nov 2006 14:32:52 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 14:32:52 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.145.156]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 14:32:51 -0800 Message-Id: <4.3.2.7.2.20061108163204.031b01a0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Nov 2006 16:32:50 -0600 To: ecrit@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 08 Nov 2006 22:32:52.0123 (UTC) FILETIME=[D3BC86B0:01C70385] DKIM-Signature: a=rsa-sha1; q=dns; l=2228; t=1163025172; x=1163889172; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Any=20desire=20to=20indicate=20who=20inserted=20location=20in=20a=20mess age?; X=v=3Dcisco.com=3B=20h=3DK2GvULP0HJYhGnOxnxqdr2M/AQI=3D; b=MZwRp7Kl0bdof+uJLC73U6l+ljwe14VDRfQlsVUNqZ3FBuuBa0puWPevYzNGfNm7PsWWZoqq 3q9oFTg2zeoz6TJ6YWnsBMCC6o9HIwGBTrpxBFP0y3h2cIZrg1CbpfW9; Authentication-Results: sj-dkim-2.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Ecrit] Any desire to indicate who inserted location in a message? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org ECRIT [sent again, as the last one hasn't appeared, yet my test message did immediately] I'm working on the ABNF of the Geolocation header for SIP location conveyance, and have discovered a means of indicating which entity (currently by type) inserted the location *at*that*URI*, per URI in the header (i.e. this will be a header parameter, not a URI parameter). For example, if a SIP message includes location-by-value, the Geolocation header would have a "cid:" URI that can have a header parameter to indicate whether the original phone ( SIP UAC) inserted the by-value location, which would be different than if an intermediary server (say a SIP proxy) inserts location by-reference. Here, the Geolocation header would have a reference URI, which can indicate that a intermediary (and not the original phone) inserted the location. Here is an example in which there are two locations in a message: Geolocation: , The above header has 2 locations (one by-value, inserted by the phone) and one inserted by a proxy along the signaling path. An interesting facet of this is the ability to indicate which location the message was routed on if a message has multiple locations. I know this has been asked for over the years in both Geopriv and ECRIT. Here is what that additional header parameter could look like (notice the "message-routed-on" parameter associated with the location-by-reference): Geolocation: , This plays directly to the open issue we have had for some time in the case of more than one location within a message, answering "who inserted which location?" and "which was used to route the message?". [ BTW - I'm posting similar messages to this one on the GEOPRIV, ECRIT and SIP lists, but not doing one large cross-posting message - as this idea has to get multi-list visibility] Is this a desireable feature/function (indication)? James _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Nov 08 18:38:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghwzk-0004Pa-1t; Wed, 08 Nov 2006 18:38:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghwzi-0004NZ-ML for ecrit@ietf.org; Wed, 08 Nov 2006 18:38:10 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ghwzg-0006QZ-Ly for ecrit@ietf.org; Wed, 08 Nov 2006 18:38:10 -0500 Received: (qmail invoked by alias); 08 Nov 2006 23:38:06 -0000 Received: from dhcp66-103.ietf67.org (EHLO [130.129.66.103]) [130.129.66.103] by mail.gmx.net (mp011) with SMTP; 09 Nov 2006 00:38:06 +0100 X-Authenticated: #29516787 Message-ID: <45526A5F.8000602@gmx.net> Date: Wed, 08 Nov 2006 15:38:07 -0800 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) 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: 7d33c50f3756db14428398e2bdedd581 Subject: [Ecrit] Expert Reviewers Nominated X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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, during the ECRIT meeting today we selected a few expert reviews for our documents: * LoST: Jonathan Rosenberg, Tom Taylor, Shida Schubert, Steve Norreys * LoST Mapping Architecture: Cullen Jennings, Rohan Mahy, Murugaraj Shanmugam, Richard Barnes * Framework for Emergency Calling: Jonathan Rosenberg, Peter Blatherwick, Steve Norreys We would like to thank these persons in advance. Their work will obviously appropriately acknowledged in the respective drafts. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Nov 08 21:15:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhzRJ-00041M-E5; Wed, 08 Nov 2006 21:14:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhzRI-0003xm-HD for ecrit@ietf.org; Wed, 08 Nov 2006 21:14:48 -0500 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhzRC-0003N5-9n for ecrit@ietf.org; Wed, 08 Nov 2006 21:14:48 -0500 Received: from [130.129.65.110] ([::ffff:130.129.65.110]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 08 Nov 2006 21:14:17 -0500 id 0158C15C.45528EFA.0000102D In-Reply-To: References: Mime-Version: 1.0 Message-Id: <2C217A44-25ED-4088-91AC-031D39877361@hxr.us> From: Andrew Newton Subject: Re: [Ecrit] LoST issue: authoritative answer only, please Date: Wed, 8 Nov 2006 21:14:16 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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="===============1248313646==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1248313646== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-4143-1163038476-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-4143-1163038476-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Nov 8, 2006, at 2:19 PM, Henning Schulzrinne wrote: > Should there be a query flag that allows a seeker to specify that > it would like the resolver to obtain an authoritative answer > (recursively) from the authoritative mapping server (AMS), rather > than a cached answer? Considering that a resolver may just disallow/ignore this flag for load purposes, I don't think it is worth it. Plus, if a seeker really needs this type of information, then it could use the information in the to do its own investigation. I don't see this flag of use in normal operation. -andy --=_zeke.ecotroph.net-4143-1163038476-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.3

On Nov 8, 2006, at 2:19= PM, Henning Schulzrinne wrote:

Sh= ould there be a query flag that allows a seeker to specify that it would = like the resolver to obtain an authoritative answer (recursively) from th= e authoritative mapping server (AMS), rather than a cached answer?=

Considering that a resolver may just dis= allow/ignore this flag for load purposes, I don't think it is worth it.=A0= Plus, if a seeker really needs this type of information, then it could u= se the information in the <via> to do its own investigation.=A0 I d= on't see this flag of use in normal operation.

-andy

--=_zeke.ecotroph.net-4143-1163038476-0001-2-- --===============1248313646== 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 --===============1248313646==-- From ecrit-bounces@ietf.org Thu Nov 09 01:39:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi3Z1-0002ai-Hq; Thu, 09 Nov 2006 01:39:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gi3Yz-0002a2-Vf for ecrit@ietf.org; Thu, 09 Nov 2006 01:39:01 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghuwu-0006EV-9W for ecrit@ietf.org; Wed, 08 Nov 2006 16:27:08 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GhuXa-0001i5-86 for ecrit@ietf.org; Wed, 08 Nov 2006 16:01:00 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 08 Nov 2006 13:00:11 -0800 X-IronPort-AV: i="4.09,401,1157353200"; d="scan'208"; a="449138355:sNHT49948028" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA8L0BgS013335 for ; Wed, 8 Nov 2006 13:00:11 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA8L0Bip006482 for ; Wed, 8 Nov 2006 13:00:11 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 13:00:11 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.145.156]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 13:00:10 -0800 Message-Id: <4.3.2.7.2.20061108145853.02e14540@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Nov 2006 15:00:09 -0600 To: "'ecrit@ietf.org'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 08 Nov 2006 21:00:11.0064 (UTC) FILETIME=[E1164380:01C70378] DKIM-Signature: a=rsa-sha1; q=dns; l=2139; t=1163019611; x=1163883611; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Any=20desire=20to=20indicate=20who=20inserted=20location=20in=20a=20mess age?; X=v=3Dcisco.com=3B=20h=3DK2GvULP0HJYhGnOxnxqdr2M/AQI=3D; b=BapveUH5mtacfRXaFT7h38+mbAkDEQ94cYtuMYVUJE7zyC3jb+1CmGbYaXZ/m+9rfbEa0uJT 1UgPskd3b1bYXFvzNG++UxWMJsjxfgHV2VZpjidi908pgK+9QPzC5xLz; Authentication-Results: sj-dkim-3.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Ecrit] Any desire to indicate who inserted location in a message? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org ECRIT I'm working on the ABNF of the Geolocation header for SIP location conveyance, and have discovered a means of indicating which entity (currently by type) inserted the location *at*that*URI*, per URI in the header (i.e. this will be a header parameter, not a URI parameter). For example, if a SIP message includes location-by-value, the Geolocation header would have a "cid:" URI that can have a header parameter to indicate whether the original phone ( SIP UAC) inserted the by-value location, which would be different than if an intermediary server (say a SIP proxy) inserts location by-reference. Here, the Geolocation header would have a reference URI, which can indicate that a intermediary (and not the original phone) inserted the location. Here is an example in which there are two locations in a message: Geolocation: , The above header has 2 locations (one by-value, inserted by the phone) and one inserted by a proxy along the signaling path. An interesting facet of this is the ability to indicate which location the message was routed on if a message has multiple locations. I know this has been asked for over the years in both Geopriv and ECRIT. Here is what that additional header parameter could look like (notice the "message-routed-on" parameter associated with the location-by-reference): Geolocation: , This plays directly to the open issue we have had for some time in the case of more than one location within a message, answering "who inserted which location?" and "which was used to route the message?". [ BTW - I'm posting similar messages to this one on the GEOPRIV, ECRIT and SIP lists, but not doing one large cross-posting message - as this idea has to get multi-list visibility] Is this a desireable feature/function (indication)? James _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 09 11:57:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDDE-0007QA-Ay; Thu, 09 Nov 2006 11:57:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDDD-0007Q3-KN for ecrit@ietf.org; Thu, 09 Nov 2006 11:57:11 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiDDA-00075B-2x for ecrit@ietf.org; Thu, 09 Nov 2006 11:57:11 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kA9Gv7eX024373 for ; Thu, 9 Nov 2006 10:57:07 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Nov 2006 10:57:07 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 9 Nov 2006 17:57:05 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 9 Nov 2006 17:57:04 +0100 Message-ID: <5D1A7985295922448D5550C94DE29180775620@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed conference call on IETF/3GPP emergency call Thread-Index: AccEIBVx5pK45tO5QAixfKbHlycFtw== From: "Drage, Keith $Keith$" To: "ECRIT" X-OriginalArrivalTime: 09 Nov 2006 16:57:05.0852 (UTC) FILETIME=[160947C0:01C70420] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [Ecrit] Proposed conference call on IETF/3GPP emergency 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: , Errors-To: ecrit-bounces@ietf.org Between 3GPP / ETSI TISPAN and IETF ECRIT we have some key convergence issues we could do with discussing. I am therefore proposing to host the following conference call to see if we can come up with some ideas we could progress this with. Documentation ------------- The 3GPP stage 2 is contained in: http://www.3gpp.org/ftp/Specs/html-info/23167.htm The 3GPP stage 3 is contained in: http://www.3gpp.org/ftp/Specs/html-info/24229.htm Specifically sections 5.1.6, 5.2.10, 5.4.8 and 5.11. The TISPAN stage 2, which is an endorsement of the above is (ETSI TS 182009 - if the link does not work): http://pda.etsi.org/PDA/copy_file.asp?Action_type=3D&Action_Nb=3D&Profile= _id =3DQjgue5axQBa7L4A86'9Ao&Wki_Id=3D7ooWqIsa1YnpntptUveYX The IETF documents are: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-00.txt http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-00.txt And the normative references from these. Conference details ------------------ Details for the call are as follows: Date: Wednesday 15th November Time: 8:00 am Central US time 9:00 am Eastern US time 2:00 pm UK time 3:00 pm Central European time 4:00 pm Finland I will leave others to extrapolate for other locations. Chairperson Name: KEITH DRAGE Company: LUCENT TECHNOLOGIES READY ACCESS Access Phone Number: 8007718734 International Access Phone Number: +1 6477233953 7-Digit Access Code: 5776249=20 Participation ------------- I am circulating this mail to participants in 3GPP SA2, 3GPP CT1, ETSI TISPAN WG2, ETSI TISPAN WG3, IETF ECRIT. If you know someone who should be involved, please forward this email. This is an open conference call. The conference bridge is good up to about 50 ports. However this will not be a tutorial. You will be expected to have a working knowledge of at least some of the key documents.=20 I will attempt to ensure we have some notes of the discussions to circulate. It would help to send me a mail indicating you intend to participate, if only to ensure that I get your name spelled right on the notes. Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 09 12:02:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDIM-0002ea-Ik; Thu, 09 Nov 2006 12:02:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDIL-0002eV-Bf for ecrit@ietf.org; Thu, 09 Nov 2006 12:02:29 -0500 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GiDIK-0007kl-2F for ecrit@ietf.org; Thu, 09 Nov 2006 12:02:29 -0500 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-4.tower-121.messagelabs.com!1163091746!11682585!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 8688 invoked from network); 9 Nov 2006 17:02:27 -0000 Received: from unknown (HELO attrh9i.attrh.att.com) (134.24.146.4) by server-4.tower-121.messagelabs.com with SMTP; 9 Nov 2006 17:02:27 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh9i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kA9Gtlr3023853; Thu, 9 Nov 2006 11:55:48 -0500 (EST) Received: from OCCLUST04EVS1.ugd.att.com (ocst07.ugd.att.com [135.38.164.12]) by attrh9i.attrh.att.com (8.13.7/8.13.7) with ESMTP id kA9Gtgni023808; Thu, 9 Nov 2006 11:55:42 -0500 (EST) 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] Any desire to indicate who inserted location in a message? Date: Thu, 9 Nov 2006 11:02:19 -0600 Message-ID: <28F05913385EAC43AF019413F674A017101B71A6@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <4.3.2.7.2.20061108145853.02e14540@email.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Any desire to indicate who inserted location in a message? Thread-Index: AccDykT7HKuiku8TTjWnkEYGOMmWPwAVmtoQ From: "Dolly, Martin C, ALABS" To: "James M. Polk" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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 James, I believe this would be a useful capability Martin=20 -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com]=20 Sent: Wednesday, November 08, 2006 4:00 PM To: 'ecrit@ietf.org' Subject: [Ecrit] Any desire to indicate who inserted location in a message? ECRIT I'm working on the ABNF of the Geolocation header for SIP location=20 conveyance, and have discovered a means of indicating which entity=20 (currently by type) inserted the location *at*that*URI*, per URI in the=20 header (i.e. this will be a header parameter, not a URI parameter). For example, if a SIP message includes location-by-value, the Geolocation=20 header would have a "cid:" URI that can have a header parameter to indicate=20 whether the original phone ( SIP UAC) inserted the by-value location, which=20 would be different than if an intermediary server (say a SIP proxy) inserts=20 location by-reference. Here, the Geolocation header would have a reference=20 URI, which can indicate that a intermediary (and not the original phone) inserted the location. Here is an example in which there are two locations in a message: Geolocation: , The above header has 2 locations (one by-value, inserted by the phone) and=20 one inserted by a proxy along the signaling path. An interesting facet of this is the ability to indicate which location the=20 message was routed on if a message has multiple locations. I know this has=20 been asked for over the years in both Geopriv and ECRIT. Here is what that=20 additional header parameter could look like (notice the "message-routed-on"=20 parameter associated with the location-by-reference): Geolocation: , This plays directly to the open issue we have had for some time in the case=20 of more than one location within a message, answering "who inserted which=20 location?" and "which was used to route the message?". [ BTW - I'm posting similar messages to this one on the GEOPRIV, ECRIT and=20 SIP lists, but not doing one large cross-posting message - as this idea has=20 to get multi-list visibility] Is this a desireable feature/function (indication)? James _______________________________________________ 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 Nov 14 10:47:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0VQ-0002Un-Og; Tue, 14 Nov 2006 10:47:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0VP-0002Ue-Pa for ecrit@ietf.org; Tue, 14 Nov 2006 10:47:23 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0VK-0005sx-Mb for ecrit@ietf.org; Tue, 14 Nov 2006 10:47:23 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id kAEFlCnu010380; Tue, 14 Nov 2006 09:47:18 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Nov 2006 09:47:13 -0600 Received: from DEEXC1U01.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 14 Nov 2006 16:47:11 +0100 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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Nov 2006 16:47:10 +0100 Message-ID: <5D1A7985295922448D5550C94DE291807B61D8@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Conference call on IETF/3GPP emergency call Thread-Index: AccIAuWMop8faSm+RwOxFjWpkK8deQ== From: "Drage, Keith $Keith$" To: <3GPP_TSG_CT_WG1@LIST.ETSI.ORG>, , <3GPP_TSG_SA_WG2@LIST.ETSI.ORG>, , X-OriginalArrivalTime: 14 Nov 2006 15:47:11.0183 (UTC) FILETIME=[25E255F0:01C70804] X-Spam-Score: 0.8 (/) X-Scan-Signature: d424907374faffed8e9e11e94f671eb2 Cc: Subject: [Ecrit] Conference call on IETF/3GPP emergency 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: , Errors-To: ecrit-bounces@ietf.org A repeat of the conference call information and some discussion points at the end of the mail. Documentation ------------- The 3GPP stage 2 is contained in: http://www.3gpp.org/ftp/Specs/html-info/23167.htm You may also wish to browse 23.271 referenced from this document. The 3GPP stage 3 is contained in: http://www.3gpp.org/ftp/Specs/html-info/24229.htm Specifically sections 5.1.6, 5.2.10, 5.4.8 and 5.11. The TISPAN stage 2, which is an endorsement of the above is (ETSI TS 182009 - if the link does not work): http://pda.etsi.org/PDA/copy_file.asp?Action_type=3D&Action_Nb=3D&Profile= _id =3DQjgue5axQBa7L4A86'9Ao&Wki_Id=3D7ooWqIsa1YnpntptUveYX The IETF documents are: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-00.txt http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-00.txt And the normative references from these. Conference details ------------------ Details for the call are as follows: Date: Wednesday 15th November Time: 8:00 am Central US time 9:00 am Eastern US time 2:00 pm UK time 3:00 pm Central European time 4:00 pm Finland I will leave others to extrapolate for other locations. Expected duration: 2 hours - if we need longer we will organise follow call(s). Chairperson Name: KEITH DRAGE Company: LUCENT TECHNOLOGIES READY ACCESS Access Phone Number: 8007718734 International Access Phone Number: +1 6477233953 7-Digit Access Code: 5776249=20 Participation ------------- I am circulating this mail to participants in 3GPP SA2, 3GPP CT1, ETSI TISPAN WG2, ETSI TISPAN WG3, IETF ECRIT. If you know someone who should be involved, please forward this email. This is an open conference call. The conference bridge is good up to about 50 ports. However this will not be a tutorial. You will be expected to have a working knowledge of at least some of the key documents.=20 I will attempt to ensure we have some notes of the discussions to circulate. It would help to send me a mail indicating you intend to participate, if only to ensure that I get your name spelled right on the notes. Terminology =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The 3GPP E-CSCF and the IETF ECRIT ESRP (Emergency Service Routeing Proxy) appear to be roughly compatible in functionality. Note that the 3GPP P-CSCF also has to recognise emergency calls in order to route them to the E-CSCF. Discussion points (no particular order and some are minor) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D I did a quick work through of the documents to identify areas where things are different, or just not covered, and should therefore be discussed. We may want to skip minor issues until later. A) LCP --------- draft-ietf-ecrit-phonebcp-00 section 4: Draft-ietf-ecrit-framework-00 section 5.5: For devices that operate on a network where the network operator controls the specification of every device connected to that network that could be used for emergency calls, the method by which location is determined need not be an IETF standard, but can be any method that achieves the desired result. Such a method MUST be specified, and every device MUST support it. For all other devices, location configuration by DHCP, [Placeholder for L7 LCP] and LLDP-MED MUST be supported. DHCP [RFC2131] has been enhanced to provide the location of a device. [RFC3825] describes how a geo-location (lat/lon/alt) may be obtained and [I-D.schulzrinne-geopriv-dhcp-civil] describes how a civic (street address) location can be obtained via DHCP. ... For devices that operate on a network where the network operator does not control the specification of every device connected to the network, at least one of DHCP, [L7 LCP] or LLDP-MED MUST be supported on the network. ... Devices SHOULD get location immediately after obtaining local network configuration information. 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 should not overwrite the Dallas location for any reason especially an emergency call. Referring to LCP: Where an access network can control the specification of EVERY endpoint that could make an emergency call that is directly connected to the network, or indirectly connected (for example, a device on a LAN behind a network attachment unit), it may specify any protocol it wishes for each endpoint. This is a very unusual case; nearly every access network can be used to support an Ethernet based LAN behind it. For example, existing mobile networks are being used to support routers and LANs behind a wireless data network WAN connection. It is possible that the access network supports a protocol not on the phonebcp list, but another element which the access network provider controls the specification of can acquire location using that protocol and then that element can support one of the phonebcp's list of protocols. For example, if the access network provider supplies a router which includes a DHCP server, it can acquire location using an access network specific protocol, and use the location information to supply it to its clients via DHCP. I don't believe that 3GPP, after the work with TISPAN, can now claim the exemption, as TISPAN allows legacy SIP terminals on the system. 3GPP does not support a location configuration protocol on its terminals.=20 B) LoST usage ---------------- Draft-ietf-ecrit-framework-00 section 3: draft-ietf-ecrit-phonebcp-00 section 2: draft-ietf-ecrit-phonebcp-00 section 6.1: draft-ietf-ecrit-phonebcp-00 section 6.2: We route( (Section 6)) the call based on location using the LoST protocol ( [I-D.ietf-ecrit-lost]) which maps a location to a set of PSAP URIs. Each URI resolves to a PSAP or an Emergency Services Routing Proxy which serves a group of PSAPs. The call arrives at the PSAP with the location included in the INVITE request. o It would determine the PSAP's URI by using the [I-D.ietf-ecrit-lost] mapping server from the location provided in the signaling 1. The Request URI SHOULD be a PSAP URI obtained from LoST (see Section 6.2). If the device cannot access a LoST server, the To: SHOULD be a service URN in the "sos" tree. If the device cannot do local dialstring interpretation, the Request URI: SHOULD be a dialstring URI [I-D.rosen-iptel-dialstring]with the dialed digits. sips MUST be specified, unless the operation must be retried due to a failure to establish a TLS connection. User agents that can obtain location information MUST perform the mapping from location information to PSAP URI using [I-D.ietf-ecrit-lost]. The mapping is performed whenever the UA acquires new location information that is outside the bounds of the current PSAP coverage region specified in the LoST response or the time-to-live value of that response has expired. No current 3GPP decision to use LoST, although it could be suitable between E-CSCF and LRF. Certainly there is no guarantee of support of a LoST query from the terminal. C) Recognition of emergency calls ------------------------------------ draft-ietf-ecrit-phonebcp-00 section 6.2: All proxies in the outbound path SHOULD recognize emergency calls with a Request URI of the service URN in the "sos" tree. A proxy recognizing such a call (which indicates that the endpoint understood the call was an emergency call, but was unable to map its location to a PSAP URI) MUST perform the LoST mapping and retarget the call to the PSAP URI (the service URN SHOULD remain as a Route header). To deal with old user agents that predate this specification and with UAs that do not have access to their own location data, proxies that recognize a call as an emergency call that is not marked as such (see Section 5) or where the Request-URI is a service:sos URN MUST also perform this mapping, with the best location it has available for the endpoint. The resulting PSAP URI would become the Request URI. In 3GPP all intermediate proxies recognise emergency calls. However they route emergency calls to a special proxy called E-CSCF that performs the location to URI mapping rather than perform it at the proxy concerned. D) Usage of sos URN ---------------------- draft-ietf-ecrit-phonebcp-00 section 5: draft-ietf-ecrit-phonebcp-00 section 6.1: Devices MUST use the service:sos URN scheme to mark emergency calls. To determine which calls are emergency calls, some entity needs to map a user entered dialstring into this URN scheme. A user may "dial" 1-1-2, but the call would be sent to urn:service:sos. This mapping is SHOULD performed at the endpoint device, but MAY be performed at an intermediate entity (such as a SIP proxy server). 2. The To: header MUST be present and SHOULD be a service URN in the "sos" tree. If the device cannot do local dialstring interpretation, the To: SHOULD be a dialstring URI with the dialed digits. sips MUST be specified, unless the operation must be retried due to a failure to establish a TLS connection. Not an issue in 3GPP, as this is what is specified. Except that 3GPP IMS cannot support TLS connections. Note that SIPS may not in any case be appropriate for PSTN connected PSAPs where interworking is involved. E) Dialstring provisioning ----------------------------- draft-ietf-ecrit-phonebcp-00 section 5: The home emergency dialstrings MAY be provisioned into the device (or other element doing dialstring to universal emergency call URN mapping). [I-D.ietf-ecrit-lost]) provides dialstrings for a given location and SHOULD be used by devices to learn the local (i.e. "visited" dialstrings. 3GPP currently has its own mechanisms for doing this, and does not use LoST. These mechanism are however access specific, and are not provided (except by prior configuration) in WLAN terminals and DSL terminals. F) Location -------------- Draft-ietf-ecrit-framework-00 section 5.2: Cell tower/sector: Cell tower and sectors identify the cell tower and the antenna sector that the mobile device is currently using. Traditionally, the tower location is expressed as a point, and routing decisions are made on that point. Cell/sector information could also be transmitted as an irregularly shaped polygon of geospatial coordinates reflecting the likely geospatial location of the mobile device. For 3GPP IMS, in addition to normal location field, this information would be expected to be available at the E-CSCF in the P-Access-Network-Info header (for 3GPP/3GPP2 accesses). For DSL it would contain a location id which would have to be mapped using some database to a real location. For WLAN it may ultimately be some form of MAC address. G) Delivery of location to PSAP ---------------------------------- Draft-ietf-ecrit-framework-00 section 5.3: All location objects MUST be delivered to the PSAP. To facilitate such policy decisions, location information should contain information about the source of data, such as GPS, manually entered or based on access network topology. In addition, the generator of the location information should be included. The ability of the UA to understand how it learned its location, and include this information element in the location object that is sent to the PSAP, provides the call-taker with many pieces of information to make decisions upon, and ask the caller with. Not necessarily an issue in itself, but may be difficult to interwork with the PSTN to supply to PSTN based PSAPs. H) Indication of location used for routeing ---------------------------------------------- Draft-ietf-ecrit-framework-00 section 5.3: The call should indicate which location information has been used for routing, so that the same location information is used for all call routing decisions. Otherwise, two proxies might pick different location information from the call request, resulting in different routing decisions for different transactions. Not yet covered in 3GPP documentation. I) Security mechanisms ------------------------- Draft-ietf-ecrit-framework-00 section 7: Since emergency calls carry privacy-sensitive information, they are subject to the requirements for geospatial protocols [RFC3693]. In particular, signaling information should be carried in TLS, i.e., in 'sips' mode. While requiring TLS is actually the way the standards are written, it is unacceptable to have an emergency call fail to complete because a TLS connection was not created, for any reason. In many cases, persistent TLS connections can be maintained between elements to minimize the time needed to establish them. 3GPP networks do not use TLS, but provide security using trust relationships and IPsec. J) GRUU usage ---------------- Draft-ietf-ecrit-framework-00 section 9: The call-taker must be able to reach the emergency caller if the original call is disconnected. In traditional emergency calls, wireline and wireless emergency calls include a callback identifier for this purpose. In SIP systems, the caller should include a Contact header field indicating its device URI, if available, or possibly a GRUU[I-D.ietf-sip-gruu] if calls need to be routed via a proxy. This identifier would be used to initiate call-backs immediately by the call-taker if, for example, the call is prematurely dropped. GRUU will be supported in 3GPP release 7. GRUU requires registration. Not all 3GPP emergency calls require prior registration. In 3GPP also not considered the interaction of GRUU with 3GPP emergency registration. K) Calling identity ---------------------- Draft-ietf-ecrit-framework-00 section 9 and 16.1: draft-ietf-ecrit-phonebcp-00 section 6.1: In addition, a call-back identifier should be included either as the URI in the From header field [RFC3261] preferably verified by SIP Identity[RFC4474]. This identifier would be used to initiate a call- back at a later time and may reach the caller, not necessarily on the same device (and at the same location) as the original emergency call. Fraudulent calls to PSAPs is a significant concern. Current systems rely on inherent security mechanisms in the PSTN to make sure the identity of the caller is known. As Internet technologies are increasingly used to place calls, it is becoming easier to hide the indentity of a caller. Use of the SIP Identity mechanism [RFC4474] i is recommended. If SIP Identity cannot be provided, carriers should make use of P-Asserted-Identity, [RFC3325] 3. The From: header MUST be present and SHOULD be the AoR of the caller. 4. A Via: header MUST be present and SHOULD include the URI of the device 6. Either a P-Asserted-Identity [RFC3325] or an Identity header [RFC4474], or both, SHOULD be included to identify the sender. TISPAN emergency call requirements, based on NTT input, require privacy rules to be adhered to for emergency calls. Neither TISPAN or 3GPP have indicated any intent to adopt RFC 4474 and currently use only RFC 3325. 3GPP indicates that if privacy is required then To: field should be set to anonymous (this is an ordinary call bit of text that applies by default to emergency calls as well). L) REFER usage ----------------- Draft-ietf-ecrit-framework-00 section 10: draft-ietf-ecrit-phonebcp-00 section 6.4: A PSAP may need to REFER[RFC3515] a call to a bridge for conferencing. The caller should also be prepared to have the call transferred (usually attended, but possibly blind) as per[I-D.ietf-sipping-service-examples]. The PSAP is expected to use normal signaling (e.g. SIP) as per IETF standards. Devices and proxies should expect to: 1. Be REFERed to a conference bridge; PSAPs often include dispatchers, responders or specialists on a call. 2. Be REFERed to a secondary PSAP. Some responder's dispatchers are not located in the primary PSAP. The call may have to be transferred to another PSAP. Most often this will be an attended transfer, or a bridged transfer. Not taken account of by 3GPP specifications. If PSAP is PSTN connected, REFER currently not supported by interworking gateway. In 3GPP specs, REFER is currently optional to UAs. M) Presence -------------- draft-ietf-ecrit-phonebcp-00 section 6.4: 3. (For devices that are Mobile) SUBSCRIBE to the Presence of the AoR (or equivalent for other signaling schemes) to get location updates. Presence support is optional in 3GPP terminals. N) Session timer ------------------- draft-ietf-ecrit-phonebcp-00 section 6.4: 4. Support Session Timer (or equivalent) to guard against session corruption Session timer support is optional in 3GPP terminals. O) Session clearing ---------------------- draft-ietf-ecrit-phonebcp-00 section 6.4: Devices with an active emergency call (i.e. SIP Dialog) MUST NOT generate a BYE request (or equivalent for other non-SIP signaling). The PSAP must be the only entity that can terminate a call. If the user "hangs up" an emergency call, the device should ring, and when answered, reconnect the caller to the PSAP. 3GPP terminals are not allowed to hang up, but specification of the user interface is outside the scope of the 3GPP specifications, so the detail about local ringing has not been covered. P) Media types ----------------- Draft-ietf-ecrit-framework-00 section 12: draft-ietf-ecrit-phonebcp-00 section 3: draft-ietf-ecrit-phonebcp-00 section 6.1: Newer text forms are rapidly appearing, with Instant Messaging now very common, PSAPs should accept IM with at least [RFC3428] as well as [RFC3920]. Using current (evolving) standards, devices that create media sessions and exchange audio, video and/or text, and have the capability to establish sessions to a wide variety of addresses, and communicate over private IP networks or the Internet, should support emergency calls. 13. A normal SDP offer SHOULD be included in the INVITE. The offer SHOULD NOT include compressed audio codecs, although a wideband codec offer MAY be included. Note: Silence suppression (Voice Activity Detection methods) MUST NOT be used on emergency calls. PSAP call takers sometimes get information on what is happening in the background to determine how to process the call. Currently 3GPP has only specified voice. MESSAGE method is not included. MSRP and real time text would be subject to end to end negotiation with the PSAP and would not be supported by an intermediate PSTN gateway. Neither would they be interworked with existing mechanisms. What is a compressed audio codec. Is AMR one? If so this is the only codec likely to be used from 3GPP terminals. Operators are unlikely to approve of G.711 over the air, assuming there was enough bandwidth to get it there in the first place - it would need at least 3G speeds. Q) Supplementary services ---------------------------- draft-ietf-ecrit-phonebcp-00 section 6.5: The calling device and/or service SHOULD disable outgoing call features such as: o Call Waiting o Call Transfer o Three Way Call o Flash hold o Outbound Call Blocking The emergency dialstrings SHOULD NOT be permitted in Call Forward numbers or speed dial lists. The device and/or service SHOULD disable the following incoming call features on calls from the PSAP: o Call Waiting (all kinds) o Do Not Disturb o Call Forward (all kinds) (if the PSAP calls back within some (30min?) interval) Not covered at the moment in 3GPP specifications. R) Test ---------- draft-ietf-ecrit-phonebcp-00 section 7.1: 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) should be returned if the test service is busy, and a 488 (Not Acceptable Here) should be returned if the PSAP does not support the test mechanism. ... 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. Not covered at moment in 3GPP specifications. S) Configuration ------------------- Draft-ietf-ecrit-framework-00 section 18.1: draft-ietf-sipping-config-framework is included in the normative references, but no text exists in the document apparently. It should be noted that 3GPP at the moment only supports OMA DM for terminal configuration. Other discussion points =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Some of these may come up in the discussion above, but these have been specifically suggested to me. T) emergency registration (not currently part of the IETF architecture) U) call identification (likely IETF outcome: request URI =3D sos URN plus loose routing) V) location determination mechanisms, and underlying 3GPP location architecture Regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 14 15:21:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk4mH-0006Rz-C8; Tue, 14 Nov 2006 15:21:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk4mF-0006R8-Se for ecrit@ietf.org; Tue, 14 Nov 2006 15:21:03 -0500 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gk4mE-0005tx-Js for ecrit@ietf.org; Tue, 14 Nov 2006 15:21:03 -0500 Received: (qmail invoked by alias); 14 Nov 2006 20:21:01 -0000 Received: from p549849D0.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.73.208] by mail.gmx.net (mp041) with SMTP; 14 Nov 2006 21:21:01 +0100 X-Authenticated: #29516787 Message-ID: <455A2532.5030401@gmx.net> Date: Tue, 14 Nov 2006 21:21:06 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) 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.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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, here are the meeting minutes. Please take a look at them: http://www3.ietf.org/proceedings/06nov/minutes/ecrit.txt Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 14 15:49:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk5Db-0008LG-MQ; Tue, 14 Nov 2006 15:49:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk5Da-0008L9-JR for ecrit@ietf.org; Tue, 14 Nov 2006 15:49:18 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk5DY-0002KQ-8y for ecrit@ietf.org; Tue, 14 Nov 2006 15:49:18 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 14 Nov 2006 12:49:15 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kAEKnFdo029886; Tue, 14 Nov 2006 12:49:15 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAEKnDio009358; Tue, 14 Nov 2006 12:49:13 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 12:49:13 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.152.62]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 12:49:13 -0800 Message-Id: <4.3.2.7.2.20061114144228.02b2abd0@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 14 Nov 2006 14:49:11 -0600 To: "Drage, Keith $Keith$" , <3GPP_TSG_CT_WG1@LIST.ETSI.ORG>, , <3GPP_TSG_SA_WG2@LIST.ETSI.ORG>, , From: "James M. Polk" Subject: Re: [Ecrit] Conference call on IETF/3GPP emergency call In-Reply-To: <5D1A7985295922448D5550C94DE291807B61D8@DEEXC1U01.de.lucent .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 14 Nov 2006 20:49:13.0436 (UTC) FILETIME=[5796B1C0:01C7082E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1304; t=1163537355; x=1164401355; c=relaxed/simple; s=sjdkim2002; 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]=20Conference=20call=20on=20IETF/3GPP=20emerge ncy=20call |Sender:=20; bh=1XE0ah6bJ/oye3cOTVMY7kbq4qvmrgYfOGilZ6sDVZ0=; b=ZWiTJqtbOChGnp8g8GSRmccLMClG006tS3bVuI8I/g3gEV8rBNnEoON/CQFCM8LJwLoaSZ8k s5/dhddffUvYoEJjtmxgEqbreQ9xxbtD8FZEcRlxmCZsV63fX0Ywl4ia; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 At 04:47 PM 11/14/2006 +0100, Drage, Keith $Keith$ wrote: >H) Indication of location used for routeing >---------------------------------------------- > >Draft-ietf-ecrit-framework-00 section 5.3: > > The call should indicate which location information has been used for > routing, so that the same location information is used for all call > routing decisions. Otherwise, two proxies might pick different > location information from the call request, resulting in different > routing decisions for different transactions. > >Not yet covered in 3GPP documentation. All draft-ietf-sip-location-conveyance-05 is the current version of the Location Conveyance ID, but -06 is coming very soon (in 1 to 2 weeks, not months) that changes the ABNF of the Geolocation header to indicate which location the message was routed on. I presented the -05 to -06 changes last Friday, and this facet did not meet any resistance, so I believe it is in (as far as an ID is concerned). Obviously this still has to go through WGLC (also coming very soon), in which this may change, but I don't believe it should - considering the positive responses on the SIP, ECRIT and Geopriv lists so far. This was presented in SIP at last week's IETF meeting. James _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Nov 15 08:58:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkLH4-0007DS-VG; Wed, 15 Nov 2006 08:57:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkLH3-0007Cr-Bc for ecrit@ietf.org; Wed, 15 Nov 2006 08:57:57 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GkLH1-0007n9-Gn for ecrit@ietf.org; Wed, 15 Nov 2006 08:57:57 -0500 Received: (qmail invoked by alias); 15 Nov 2006 13:57:53 -0000 Received: from p54985BE9.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.91.233] by mail.gmx.net (mp044) with SMTP; 15 Nov 2006 14:57:53 +0100 X-Authenticated: #29516787 Message-ID: <455B1CD1.1080103@gmx.net> Date: Wed, 15 Nov 2006 14:57:37 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) 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: 1a1bf7677bfe77d8af1ebe0e91045c5b Subject: [Ecrit] Comments for draft-ietf-ecrit-phonebcp-00.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 Hi all, I went through the document and it looks good. I still have a few comments: * In the introduction you point to the difference to ETS. Why is this necessary? Why don't you mention authority-to-citizen communication? * I don't think that the message steps listed in the introduction are helpful unless you mention that this is just an example. Why don't you point to the framework document instead? * Terminology section: You might want to state that the RFC 2119 language refers to the implementation/usage at SIP end points and at SIP proxies and not to a protocol specification. * Section 4 leaves the Geopriv L7 LCP as a place holder. I see this being a problem for finishing the document given that it might take some time to finish the Geopriv work on this subject. I don't have a good idea how to resolve it. * The following sentence is repeated: " For devices that operate on a network where the network operator controls the specification of every device connected to that network that could be used for emergency calls, the method by which location is determined need not be an IETF standard, but can be any method that achieves the desired result. " I suspect what you would like to say is that in an environment where a network operator cannot control all the end points you have to either support many protocols in the access network or at the end points. * Could you explain this statement: "Self Reported location is generally unacceptable in emergency calls, ..."? * You write: " It is essential for the location to be determined BEFORE any VPN tunnels are established. " It would be good to refer to tunnels with examples to VPN tunnels or mobility specific tunnels (e.g., MIP). * Regarding the time limits indicated in Section 4, it would be good to provide references (if you know some of them). * Please double-check the terminology used in Section 5 with the terms introduced in Section 3.6 of http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-12.txt * Please provide a reference regarding the following statement: " Note: It is undesirable to have a single "button" emergency call user interface element. These mechanisms have a very high false call rate. PSAPs prefer devices to use their local emergency call dialstring. " * The following paragraph is still an open issue: " [I-D.schulzrinne-sipping-service] introduces a universal emergency service URN scheme. On the wire, emergency calls SHOULD include this type of URI as a Route header [RFC3261]. The scheme includes a single emergency URN (urn:service:sos) and responder specific ones (urn:service:sos.police). Using the service:sos URN scheme, emergency calls can be recognized as such throughout the Internet. " * You write: "Devices MUST use the service:sos URN scheme to mark emergency calls." In the next paragraph you also consider the case where end hosts does not understand emergency calls: " To determine which calls are emergency calls, some entity needs to map a user entered dialstring into this URN scheme. A user may "dial" 1-1-2, but the call would be sent to urn:service:sos. This mapping is SHOULD performed at the endpoint device, but MAY be performed at an intermediate entity (such as a SIP proxy server). " The problem with the end host not understanding emergency calls should be highlighted. If the end host does not understand emergency calls (and thereby does not understand the service URN) the aspects listed in Section 6.5 are not relevant either. * Section 6 is quite difficult to read. Wouldn't it be useful to cluster the description in three cases: 1) End host obtains location information and performs the resolution to a PSAP URI 2) End host obtains location information and the proxy performs the resolution to a PSAP URI 3) The proxy obtains location information and performs the resolution to a PSAP URI Additionally, it might be worth mentioning unauthenticated emergency calls. You briefly mention 'uninitialized devices' which already goes (conceptually) in this direction. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Nov 15 09:14:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkLX8-0004YB-Sr; Wed, 15 Nov 2006 09:14:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkLX7-0004Y6-KR for ecrit@ietf.org; Wed, 15 Nov 2006 09:14:33 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GkLX3-0001Xu-Cu for ecrit@ietf.org; Wed, 15 Nov 2006 09:14:33 -0500 Received: (qmail invoked by alias); 15 Nov 2006 14:14:26 -0000 Received: from p54985BE9.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.91.233] by mail.gmx.net (mp041) with SMTP; 15 Nov 2006 15:14:26 +0100 X-Authenticated: #29516787 Message-ID: <455B20C7.6040805@gmx.net> Date: Wed, 15 Nov 2006 15:14:31 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Drage, Keith $Keith$" Subject: Re: [Ecrit] Conference call on IETF/3GPP emergency call References: <5D1A7985295922448D5550C94DE291807B61D8@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE291807B61D8@DEEXC1U01.de.lucent.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: 559439f19b20fd64c5cd872aef84c6f3 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: