From ecrit-bounces@ietf.org Sat Sep 01 16:53:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRZwJ-00017g-Ho; Sat, 01 Sep 2007 16:51:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRZwH-00017b-FR for ecrit@ietf.org; Sat, 01 Sep 2007 16:51:29 -0400 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 1IRZwG-0006OC-Pn for ecrit@ietf.org; Sat, 01 Sep 2007 16:51:29 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 01 Sep 2007 13:51:03 -0700 X-IronPort-AV: i="4.20,197,1186383600"; d="scan'208"; a="519621712:sNHT70060053278" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l81Kp2qT010309; Sat, 1 Sep 2007 13:51:02 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l81KoqZI024735; Sat, 1 Sep 2007 20:50:52 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Sep 2007 13:50:52 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.145.9]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Sep 2007 13:50:51 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 01 Sep 2007 15:50:49 -0500 To: "Winterbottom, James" , "Brian Rosen" , "Clive D.W. Feather" From: "James M. Polk" Subject: RE: [Ecrit] Comments on location-hiding-requirements-01 In-Reply-To: References: <045b01c7ea7f$0d724fd0$640fa8c0@cis.neustar.com> <20070831151122.GQ61323@finch-staff-1.thus.net> <024a01c7ebe3$46e0f540$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 01 Sep 2007 20:50:52.0013 (UTC) FILETIME=[C88D99D0:01C7ECD9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3977; t=1188679862; x=1189543862; c=relaxed/simple; s=sjdkim3002; 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]=20Comments=20on=20location-hiding-requirement s-01 |Sender:=20; bh=xQph2Ya6rZ/xzfH5sSXZjyzVpCGBfOfroN8gDLZA9EM=; b=QGxe350nSQOYn/NtOyye3r+lzEbQC1ncdUBP4C8SsQqg4133HTkVBmdYBfSosWmAqgxTLxSz +2bxIpzy1NpEK8naTXkyiTV6joXONSnMU8gVtb5Mu2B382MORLtnPCBa; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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 05:00 PM 8/31/2007, Winterbottom, James wrote: >Yes, but we MUST choose an implementation such that the cost of >implementing and it running doesn't exceed the revenue or costs of just >giving location away for free in the first place. This is a little bit over-dramatic. No service provided to your phone (pick any one you own and this applies) is free. If you have a phone, you pay for _the_whole_service_. Why are folks insisting that Location be the first to be given away for free? It clearly will not be - so get off this FUD, please! If providing location to all subscribers costs 25 or 50 or 75 cents more a month, then all subscribers will pay that in their bill each month. That's the economic solution to this "problem". > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Saturday, 1 September 2007 1:26 AM > > To: 'Clive D.W. Feather' > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Comments on location-hiding-requirements-01 > > > > Nah, the UA can't be fooled easily, especially if it does the dial >string > > interpretation. The information can't easily be extracted along the >way > > if > > the bcp guidelines are followed (the location would be encrypted). > > > > Agree that the ISP doesn't have a problem giving location to a PSAP. > > > > It has a problem giving it to a UA who can then use it for things >other > > than > > an emergency call. It has the same problem giving it to the ASP who >runs > > the calling network. > > > > This is not a security problem, it is an economic problem. That >doesn't > > make it any less real, and we're going to have to solve it. > > > > Brian > > > > > > > -----Original Message----- > > > From: Clive D.W. Feather [mailto:clive@demon.net] > > > Sent: Friday, August 31, 2007 11:11 AM > > > To: Brian Rosen > > > Cc: 'James M. Polk'; ecrit@ietf.org > > > Subject: Re: [Ecrit] Comments on location-hiding-requirements-01 > > > > > > Brian Rosen said: > > > > The answer to your question is that it is the fact that we ARE > > requiring > > > > location to be provided to the UA and/or the calling network that > > makes > > > IP > > > > different. In the current PSTN, the access network provides the > > > location > > > > directly to the PSAP. In the Internet, we don't do that. > > > > > > Actually, I think that the point is that in the PSTN the location is > > > provided *only* to genuine PSAPs - the access network provides that > > > (unwritten) guarantee. > > > > > > I don't believe ISPs are objecting to providing location information >to > > > PSAPs. They're objecting to providing it to any Tom, Delila, and >Harry > > who > > > can look enough like a PSAP to fool the UA or who can extract the > > > information along the way. > > > > > > -- > > > Clive D.W. Feather | Work: | Tel: +44 20 >8495 > > > 6138 > > > Internet Expert | Home: | Fax: +44 870 >051 > > > 9937 > > > Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 > > 377646 > > > THUS plc | | > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 01 16:57:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRa0j-0004dq-Vn; Sat, 01 Sep 2007 16:56:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRa0i-0004di-Bf for ecrit@ietf.org; Sat, 01 Sep 2007 16:56:04 -0400 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 1IRa0h-0006Rx-HX for ecrit@ietf.org; Sat, 01 Sep 2007 16:56:04 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 01 Sep 2007 13:56:03 -0700 X-IronPort-AV: i="4.20,197,1186383600"; d="scan'208"; a="519622192:sNHT66506336" 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 l81Ku2eh006537; Sat, 1 Sep 2007 13:56:02 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l81Ku25x007887; Sat, 1 Sep 2007 20:56:02 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Sep 2007 13:56:02 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.145.9]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Sep 2007 13:56:01 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 01 Sep 2007 15:55:59 -0500 To: "Winterbottom, James" , "Ted Hardie" , "Brian Rosen" , "Clive D.W. Feather" From: "James M. Polk" Subject: RE: [Ecrit] Comments on location-hiding-requirements-01 In-Reply-To: References: <045b01c7ea7f$0d72 4fd0$640fa8c0@cis.neustar.com> <20070831151122.GQ61323@finch-staff-1.thus.n et> <024a01c7ebe3$46e0f540$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 01 Sep 2007 20:56:01.0731 (UTC) FILETIME=[8128D130:01C7ECDA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4244; t=1188680162; x=1189544162; 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]=20Comments=20on=20location-hiding-requirement s-01 |Sender:=20; bh=A1sZ+3WhK+2RyBZmpa/4qSK1nBpzp76qNHff/c4XBYc=; b=mExHnm9YHz42KpluwXfLUXJrwnifq8FI0jMdFC1JaGN71odN3By13reZusuJxFYg3idamVuV N7/trpVYedqwAMsMha8Wqwd5NJSvnkGKqR0au9on+naTvemmQE8Yf2Pa; 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: 944ecb6e61f753561f559a497458fb4f 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 05:55 PM 8/31/2007, Winterbottom, James wrote: >Perhaps less expensive is not the right term. >We must not make the deployment cost of location hiding so exorbitant >that no amount of charging for value added service can recoup the cost. > >I think we also need to be very mindful of who is paying for the >location infrastructure in the first place. that would be us, not them. In fact, they will charge us for the cost of the infrastructure, then the start-up and ongoing operational costs of providing the service, then they will charge more for their profit margins - whatever they might be. >These are people that I am >talking about, and a solution that is best for them, the access >providers, may well not be best for further down consumers such as >net-based VSPs. I see the resolution of the problem for the VSPs as a >different problem, which may require a different solution. > >Cheers >James > > > -----Original Message----- > > From: Ted Hardie [mailto:hardie@qualcomm.com] > > Sent: Saturday, 1 September 2007 8:48 AM > > To: Winterbottom, James; Brian Rosen; Clive D.W. Feather > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] Comments on location-hiding-requirements-01 > > > > At 5:30 PM -0500 8/31/07, Winterbottom, James wrote: > > >I meant the "we" in the IETF sense need to consider the potential > > >operational costs in any solution we propose. > > > > > > > Yes, but that does not follow from the second half of what you said: > > > > >Yes, but we MUST choose an implementation such that the cost of > > >> >implementing and it running doesn't exceed the revenue or costs of > > >just > > >> >giving location away for free in the first place. > > > > > > > > > > > We can and should make sure that our protocols are as efficient as > > possible, and that includes a healthy sense of the operational costs > > and realities of deploying them in the real world. But that's not > > a comparative. Making the implementation of location hiding > > less expensive than giving location away may well be impossible > > in many deployments without artificially raising the cost of giving > > it away. And there's a naughty, naughty name for that. > > > > Ted > > > > > > > > > > > >> -----Original Message----- > > >> From: Ted Hardie [mailto:hardie@qualcomm.com] > > >> Sent: Saturday, 1 September 2007 8:29 AM > > >> To: Winterbottom, James; Brian Rosen; Clive D.W. Feather > > >> Cc: ecrit@ietf.org > > >> Subject: RE: [Ecrit] Comments on location-hiding-requirements-01 > > >> > > >> At 5:00 PM -0500 8/31/07, Winterbottom, James wrote: > > > > >Yes, but we MUST choose an implementation such that the cost of > > >> >implementing and it running doesn't exceed the revenue or costs of > > >just > > >> >giving location away for free in the first place. > > >> > > > > > > > >> Mind clarifying who the "we" is in the statement above? > > >> > > >> thanks, > > >> Ted > > > > > > >----------------------------------------------------------------------- >-- > > ----------------------- > > >This message is for the designated recipient only and may > > >contain privileged, proprietary, or otherwise private information. > > >If you have received it in error, please notify the sender > > >immediately and delete the original. Any unauthorized use of > > >this email is prohibited. > > > >----------------------------------------------------------------------- >-- > > ----------------------- > > >[mf2] > > > > > > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 03 02:24:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS5KC-0006bk-5I; Mon, 03 Sep 2007 02:22:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS5KB-0006bd-2X for ecrit@ietf.org; Mon, 03 Sep 2007 02:22:15 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IS5KA-0000ud-71 for ecrit@ietf.org; Mon, 03 Sep 2007 02:22:15 -0400 X-SEF-Processed: 5_0_0_910__2007_09_03_01_31_24 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 03 Sep 2007 01:31:24 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Sep 2007 01:22:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Comments on location-hiding-requirements-01 Date: Mon, 3 Sep 2007 01:22:08 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on location-hiding-requirements-01 Thread-Index: Acfs2eKW1WC6fSqiRQmj13KFwt5G1gBF4zLg References: <045b01c7ea7f$0d724fd0$640fa8c0@cis.neustar.com> <20070831151122.GQ61323@finch-staff-1.thus.net> <024a01c7ebe3$46e0f540$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "James M. Polk" , "Brian Rosen" , "Clive D.W. Feather" X-OriginalArrivalTime: 03 Sep 2007 06:22:11.0853 (UTC) FILETIME=[C357D3D0:01C7EDF2] X-Spam-Score: 1.8 (+) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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 To the best of my knowledge, and forgive me if it is different in the=0D=0A= US, existing location dependent routing services generally charge the=0D=0A= destination, and not the caller. That is Pizza Hut pay a great deal of=0D=0A= money to the SCP owner to support an LDR service map for their franchise=0D= =0Aboundaries. What you are prescribing is having the end-point attached to=0D= =0Athe network paying for this. I am merely stating that that is not the=0D= =0Aonly model, and may end up being an expensive model to pursue. I also=0D= =0Ahave severe reservation about it costing as little as you are suggesting=0D= =0Aif you include the upfront costs to the infrastructure owners of initial=0D= =0Adeployments.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A> -----Original Mes= sage-----=0D=0A> From: James M. Polk [mailto:jmpolk@cisco.com]=0D=0A> Sent:= Sunday, 2 September 2007 6:51 AM=0D=0A> To: Winterbottom, James; Brian Ros= en; Clive D.W. Feather=0D=0A> Cc: ecrit@ietf.org=0D=0A> Subject: RE: [Ecrit= ] Comments on location-hiding-requirements-01=0D=0A>=20=0D=0A> At 05:00 PM = 8/31/2007, Winterbottom, James wrote:=0D=0A> >Yes, but we MUST choose an im= plementation such that the cost of=0D=0A> >implementing and it running does= n't exceed the revenue or costs of=0D=0Ajust=0D=0A> >giving location away f= or free in the first place.=0D=0A>=20=0D=0A> This is a little bit over-dram= atic. No service provided to your phone=0D=0A> (pick any one you own and th= is applies) is free. If you have a=0D=0A> phone, you pay for _the_whole_se= rvice_. Why are folks insisting that=0D=0A> Location be the first to be giv= en away for free=3F=0D=0A>=20=0D=0A> It clearly will not be - so get off th= is FUD, please!=0D=0A>=20=0D=0A> If providing location to all subscribers c= osts 25 or 50 or 75 cents=0D=0A> more a month, then all subscribers will pa= y that in their bill each=0D=0A> month. That's the economic solution to thi= s "problem".=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> > > -= ----Original Message-----=0D=0A> > > From: Brian Rosen [mailto:br@brianrose= n.net]=0D=0A> > > Sent: Saturday, 1 September 2007 1:26 AM=0D=0A> > > To: '= Clive D.W. Feather'=0D=0A> > > Cc: ecrit@ietf.org=0D=0A> > > Subject: RE: [= Ecrit] Comments on location-hiding-requirements-01=0D=0A> > >=0D=0A> > > Na= h, the UA can't be fooled easily, especially if it does the dial=0D=0A> >st= ring=0D=0A> > > interpretation. The information can't easily be extracted = along=0D=0Athe=0D=0A> >way=0D=0A> > > if=0D=0A> > > the bcp guidelines are = followed (the location would be encrypted).=0D=0A> > >=0D=0A> > > Agree tha= t the ISP doesn't have a problem giving location to a=0D=0APSAP.=0D=0A> > >=0D= =0A> > > It has a problem giving it to a UA who can then use it for things=0D= =0A> >other=0D=0A> > > than=0D=0A> > > an emergency call. It has the same = problem giving it to the ASP=0D=0Awho=0D=0A> >runs=0D=0A> > > the calling n= etwork.=0D=0A> > >=0D=0A> > > This is not a security problem, it is an econ= omic problem. That=0D=0A> >doesn't=0D=0A> > > make it any less real, and w= e're going to have to solve it.=0D=0A> > >=0D=0A> > > Brian=0D=0A> > >=0D=0A= > > >=0D=0A> > > > -----Original Message-----=0D=0A> > > > From: Clive D.W.= Feather [mailto:clive@demon.net]=0D=0A> > > > Sent: Friday, August 31, 200= 7 11:11 AM=0D=0A> > > > To: Brian Rosen=0D=0A> > > > Cc: 'James M. Polk'; e= crit@ietf.org=0D=0A> > > > Subject: Re: [Ecrit] Comments on location-hiding= -requirements-01=0D=0A> > > >=0D=0A> > > > Brian Rosen said:=0D=0A> > > > >= The answer to your question is that it is the fact that we ARE=0D=0A> > > = requiring=0D=0A> > > > > location to be provided to the UA and/or the calli= ng network=0D=0Athat=0D=0A> > > makes=0D=0A> > > > IP=0D=0A> > > > > differ= ent. In the current PSTN, the access network provides=0D=0Athe=0D=0A> > > = > location=0D=0A> > > > > directly to the PSAP. In the Internet, we don't = do that.=0D=0A> > > >=0D=0A> > > > Actually, I think that the point is that= in the PSTN the=0D=0Alocation is=0D=0A> > > > provided *only* to genuine P= SAPs - the access network provides=0D=0Athat=0D=0A> > > > (unwritten) guara= ntee.=0D=0A> > > >=0D=0A> > > > I don't believe ISPs are objecting to provi= ding location=0D=0Ainformation=0D=0A> >to=0D=0A> > > > PSAPs. They're objec= ting to providing it to any Tom, Delila, and=0D=0A> >Harry=0D=0A> > > who=0D= =0A> > > > can look enough like a PSAP to fool the UA or who can extract=0D= =0Athe=0D=0A> > > > information along the way.=0D=0A> > > >=0D=0A> > > > --=0D= =0A> > > > Clive D.W. Feather | Work: | Tel: +44=0D= =0A20=0D=0A> >8495=0D=0A> > > > 6138=0D=0A> > > > Internet Expert | Hom= e: | Fax: +44=0D=0A870=0D=0A> >051=0D=0A> > > > 993= 7=0D=0A> > > > Demon Internet | WWW: http://www.davros.org | Mobile: += 44=0D=0A7973=0D=0A> > > 377646=0D=0A> > > > THUS plc | = |=0D=0A> > >=0D=0A> > >=0D=0A> > > ______________________= _________________________=0D=0A> > > Ecrit mailing list=0D=0A> > > Ecrit@ie= tf.org=0D=0A> > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> >=0D=0A= >=0D=0A>-------------------------------------------------------------------= ----=0D=0A--=0D=0A> -----------------------=0D=0A> >This message is for the= designated recipient only and may=0D=0A> >contain privileged, proprietary,= or otherwise private information.=0D=0A> >If you have received it in error= , please notify the sender=0D=0A> >immediately and delete the original. An= y unauthorized use of=0D=0A> >this email is prohibited.=0D=0A>=0D=0A>------= -----------------------------------------------------------------=0D=0A--=0D= =0A> -----------------------=0D=0A> >[mf2]=0D=0A> >=0D=0A> >=0D=0A> >______= _________________________________________=0D=0A> >Ecrit mailing list=0D=0A>= >Ecrit@ietf.org=0D=0A> >https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0AThis message is for the designated recipient = only and may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 03 02:35:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS5Vc-0007I9-8w; Mon, 03 Sep 2007 02:34:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS5Va-0007Em-I2 for ecrit@ietf.org; Mon, 03 Sep 2007 02:34:02 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IS5VZ-0006xl-OI for ecrit@ietf.org; Mon, 03 Sep 2007 02:34:02 -0400 X-SEF-Processed: 5_0_0_910__2007_09_03_01_43_12 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 03 Sep 2007 01:43:12 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Sep 2007 01:33:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Comments on location-hiding-requirements-01 Date: Mon, 3 Sep 2007 01:33:56 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on location-hiding-requirements-01 Thread-Index: Acfs2oLLlb7AntJ/R+SXeHcYM3P13gBGExFg References: <045b01c7ea7f$0d72 4fd0$640fa8c0@cis.neustar.com> <20070831151122.GQ61323@finch-staff-1.thus.n et> <024a01c7ebe3$46e0f540$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "James M. Polk" , "Ted Hardie" , "Brian Rosen" , "Clive D.W. Feather" X-OriginalArrivalTime: 03 Sep 2007 06:33:59.0335 (UTC) FILETIME=[69090370:01C7EDF4] X-Spam-Score: 1.8 (+) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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 Ummm... I don't agree at all.=0D=0AIf the cost of your DSL service jumped b= y 60% over night to meet the=0D=0Apotential $60M outlay for infrastructure = support, would you remain with=0D=0Athe access provider=3F I seriously doub= t it.=0D=0A=0D=0AReality is that you will not be charged for the upfront co= sts, the up=0D=0Afront costs will be born by the access provider and will t= ake time to=0D=0Arecoup.=20=0D=0A=0D=0AOn a side note I find this hostile r= eaction to infrastructure providers=0D=0Areally quite absurd.=20=0D=0A=0D=0A= Regards=0D=0AJames=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Jam= es M. Polk [mailto:jmpolk@cisco.com]=0D=0A> Sent: Sunday, 2 September 2007 = 6:56 AM=0D=0A> To: Winterbottom, James; Ted Hardie; Brian Rosen; Clive D.W.= Feather=0D=0A> Cc: ecrit@ietf.org=0D=0A> Subject: RE: [Ecrit] Comments on = location-hiding-requirements-01=0D=0A>=20=0D=0A> At 05:55 PM 8/31/2007, Win= terbottom, James wrote:=0D=0A> >Perhaps less expensive is not the right ter= m.=0D=0A> >We must not make the deployment cost of location hiding so exorb= itant=0D=0A> >that no amount of charging for value added service can recoup= the=0D=0Acost.=0D=0A> >=0D=0A> >I think we also need to be very mindful of= who is paying for the=0D=0A> >location infrastructure in the first place.=0D= =0A>=20=0D=0A> that would be us, not them.=0D=0A>=20=0D=0A> In fact, they w= ill charge us for the cost of the infrastructure, then=0D=0A> the start-up = and ongoing operational costs of providing the service,=0D=0A> then they wi= ll charge more for their profit margins - whatever they=0D=0Amight=0D=0A> b= e.=0D=0A>=20=0D=0A> >These are people that I am=0D=0A> >talking about, and = a solution that is best for them, the access=0D=0A> >providers, may well no= t be best for further down consumers such as=0D=0A> >net-based VSPs. I see = the resolution of the problem for the VSPs as a=0D=0A> >different problem, = which may require a different solution.=0D=0A> >=0D=0A> >Cheers=0D=0A> >Jam= es=0D=0A> >=0D=0A> > > -----Original Message-----=0D=0A> > > From: Ted Hard= ie [mailto:hardie@qualcomm.com]=0D=0A> > > Sent: Saturday, 1 September 2007= 8:48 AM=0D=0A> > > To: Winterbottom, James; Brian Rosen; Clive D.W. Feathe= r=0D=0A> > > Cc: ecrit@ietf.org=0D=0A> > > Subject: RE: [Ecrit] Comments on= location-hiding-requirements-01=0D=0A> > >=0D=0A> > > At 5:30 PM -0500 8/3= 1/07, Winterbottom, James wrote:=0D=0A> > > >I meant the "we" in the IETF s= ense need to consider the potential=0D=0A> > > >operational costs in any so= lution we propose.=0D=0A> > > >=0D=0A> > >=0D=0A> > > Yes, but that does no= t follow from the second half of what you=0D=0Asaid:=0D=0A> > >=0D=0A> > > = >Yes, but we MUST choose an implementation such that the cost of=0D=0A> > >= >> >implementing and it running doesn't exceed the revenue or=0D=0Acosts o= f=0D=0A> > > >just=0D=0A> > > >> >giving location away for free in the firs= t place.=0D=0A> > > > > >=0D=0A> > >=0D=0A> > >=0D=0A> > > We can and shoul= d make sure that our protocols are as efficient as=0D=0A> > > possible, and= that includes a healthy sense of the operational=0D=0Acosts=0D=0A> > > an= d realities of deploying them in the real world. But that's not=0D=0A> > >= a comparative. Making the implementation of location hiding=0D=0A> > > le= ss expensive than giving location away may well be impossible=0D=0A> > > in= many deployments without artificially raising the cost of=0D=0Agiving=0D=0A= > > > it away. And there's a naughty, naughty name for that.=0D=0A> > >=0D= =0A> > > Ted=0D=0A> > >=0D=0A> > >=0D=0A> > >=0D= =0A> > > >=0D=0A> > > >> -----Original Message-----=0D=0A> > > >> From: Ted= Hardie [mailto:hardie@qualcomm.com]=0D=0A> > > >> Sent: Saturday, 1 Septem= ber 2007 8:29 AM=0D=0A> > > >> To: Winterbottom, James; Brian Rosen; Clive = D.W. Feather=0D=0A> > > >> Cc: ecrit@ietf.org=0D=0A> > > >> Subject: RE: [E= crit] Comments on=0D=0Alocation-hiding-requirements-01=0D=0A> > > >>=0D=0A>= > > >> At 5:00 PM -0500 8/31/07, Winterbottom, James wrote:=0D=0A> > > > >= >Yes, but we MUST choose an implementation such that the cost=0D=0Aof=0D=0A= > > > >> >implementing and it running doesn't exceed the revenue or=0D=0Aco= sts of=0D=0A> > > >just=0D=0A> > > >> >giving location away for free in the= first place.=0D=0A> > > >> >=0D=0A> > > > >=0D=0A> > > >> Mind clarifying = who the "we" is in the statement above=3F=0D=0A> > > >>=0D=0A> > > >> = thanks,=0D=0A> > > >> Ted=0D=0A> >= > >=0D=0A> > >=0D=0A> >=0D=0A>--------------------------------------------= ---------------------------=0D=0A> >--=0D=0A> > > -----------------------=0D= =0A> > > >This message is for the designated recipient only and may=0D=0A> = > > >contain privileged, proprietary, or otherwise private=0D=0Ainformation= =2E=0D=0A> > > >If you have received it in error, please notify the sender=0D= =0A> > > >immediately and delete the original. Any unauthorized use of=0D=0A= > > > >this email is prohibited.=0D=0A> > >=0D=0A> >=0D=0A>----------------= -------------------------------------------------------=0D=0A> >--=0D=0A> >= > -----------------------=0D=0A> > > >[mf2]=0D=0A> > > >=0D=0A> > >=0D=0A>= >=0D=0A>=0D=0A>-----------------------------------------------------------= ------------=0D=0A--=0D=0A> -----------------------=0D=0A> >This message is= for the designated recipient only and may=0D=0A> >contain privileged, prop= rietary, or otherwise private information.=0D=0A> >If you have received it = in error, please notify the sender=0D=0A> >immediately and delete the origi= nal. Any unauthorized use of=0D=0A> >this email is prohibited.=0D=0A>=0D=0A= >-----------------------------------------------------------------------=0D= =0A--=0D=0A> -----------------------=0D=0A> >[mf2]=0D=0A> >=0D=0A> >=0D=0A>= >_______________________________________________=0D=0A> >Ecrit mailing lis= t=0D=0A> >Ecrit@ietf.org=0D=0A> >https://www1.ietf.org/mailman/listinfo/ecr= it=0D=0A=0D=0A-------------------------------------------------------------= -----------------------------------=0D=0AThis message is for the designated= recipient only and may=0D=0Acontain privileged, proprietary, or otherwise = private information. =20=0D=0AIf you have received it in error, please noti= fy the sender=0D=0Aimmediately and delete the original. Any unauthorized u= se of=0D=0Athis email is prohibited.=0D=0A---------------------------------= ---------------------------------------------------------------=0D=0A[mf2]=0D= =0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 03 03:28:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS6Kv-0006oa-W0; Mon, 03 Sep 2007 03:27:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IS6Ku-0006oU-OQ for ecrit@ietf.org; Mon, 03 Sep 2007 03:27:04 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IS6Kt-0008JY-Hy for ecrit@ietf.org; Mon, 03 Sep 2007 03:27:04 -0400 X-SEF-Processed: 5_0_0_910__2007_09_03_02_36_16 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 03 Sep 2007 02:36:14 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Sep 2007 02:27:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Comments on location-hiding-requirements-01 Date: Mon, 3 Sep 2007 02:26:59 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on location-hiding-requirements-01 Thread-Index: Acfs2eYGNHzACq8kRlurNHsSsOhrPgBHSWBQ References: <045b01c7ea7f$0d724fd0$640fa8c0@cis.neustar.com><20070831151122.GQ61323@finch-staff-1.thus.net><024a01c7ebe3$46e0f540$640fa8c0@cis.neustar.com> From: "Dawson, Martin" To: "James M. Polk" , "Winterbottom, James" , "Brian Rosen" , "Clive D.W. Feather" X-OriginalArrivalTime: 03 Sep 2007 07:27:01.0881 (UTC) FILETIME=[D1FAFE90:01C7EDFB] X-Spam-Score: 1.8 (+) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 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 James (P),=0D=0A=0D=0AI agree with you to the extent that I think, logic= ally, the cost of=0D=0Alocation infrastructure is best recouped through the= subscriptions paid=0D=0Afor access. That is, IP location is an access serv= ice, so the cost of it=0D=0Ais wrapped up in that particular subscription.=0D= =0A=0D=0AWe've got a bit of a legacy business model to deal with. Carriers = who=0D=0Ahave been providing location infrastructure for quite a few years = (i.e.=0D=0Acellular carriers) have typically charged third party applicatio= ns for=0D=0Aaccess to the location of the subscribers. The Mobile Originate= d service=0D=0Ayou refer to is routinely disabled in networks; only mobile-= terminated=0D=0A(or application originated) requests are supported. The sub= scriber opts=0D=0Ain, and may pay their subscription directly to a third pa= rty, but the=0D=0Acarrier gets their amortization by levying a charge on th= at third party=0D=0Aapplication provider. Agreed - the subscriber pays in t= he end.=0D=0ANevertheless, there hasn't been a model of charging subscriber= s simply=0D=0Ato have their access "location enabled"; there has only been = a model of=0D=0Acharging for location applications.=0D=0A=0D=0AI think this= needs to change - and probably will eventually. The=0D=0Aparadigm that nee= ds to be broken is the continued tendency to couple=0D=0Aaccess and service= provision. What cellular carriers have really been=0D=0Acharging third par= ty application providers for is the location of their=0D=0A*service* subscr= ibers. Applications query the gateway in the cellular=0D=0Anetwork for the = location of a particular "MSISDN" - i.e. the phone=0D=0Anumber, or actual s= ubscriber identity. It's not based on the transient=0D=0ATMSI that the devi= ce is known by in the network, or even the IMSI.=0D=0A=0D=0AWhat cellular o= perators have actually been charging for is access to the=0D=0Alocation of = the subscribers to a *presence* service. These applications=0D=0Aare intere= sted in the location of a particular individual as identified=0D=0Aby their= subscriber identity. The home location register (HLR - a=0D=0Apresence ser= ver by any other name) is key to finding out how to proceed=0D=0Awith the l= ocation determination. In fact it's semantically identical to=0D=0Agetting = a location reference. Back to today and considering Internet=0D=0Aservices,= the ability for a presence client to register the location=0D=0Avalue/refe= rence that it obtains from an arbitrary access network is key=0D=0Ato provi= ding the equivalent capability.=0D=0A=0D=0A*Service* providers, and this in= cludes the cellular operators who are=0D=0Aevolving into IMS providers, wil= l still be able to charge third party=0D=0Aapplications for a location feed= to their subscribers through the=0D=0Apresence service and based on the su= bscriber identity - not the=0D=0Atransient IP address. Currently, the acces= s and the service aspects of=0D=0Alocation are still conceptually aggregate= d - which creates pressure to=0D=0Asupport something like location hiding w= ith a view that location will=0D=0Anever be determined except for the purpo= ses of an application known to=0D=0Athe access network provider. This is an= invalid view - and also doesn't=0D=0Ascale for an Internet service model. = Does Google-Navigation (I made that=0D=0Aup - but wouldn't be surprised if = it exists in their lab; everything=0D=0Aelse seems to :) ) need to have an = authentication record and=0D=0Arelationship with every conceivable Internet= access network in the=0D=0Aworld=3F It's the same issue as VoIP emergency = services; it doesn't work.=0D=0A=0D=0AOperators who, for example, provide I= nternet access as well as, say, IMS=0D=0Aservices will actually be able to = charge access subscribers for the=0D=0Ageneral location service (location a= ssociated with my device's current=0D=0AIP address)*and* service subscriber= identity location (location=0D=0Aassociated with my current IMS subscriber= s SIP identity). Pure Internet=0D=0Apresence service providers will only be= able to charge for the latter;=0D=0Apure Internet access providers will on= ly be able to charge for the=0D=0Aformer.=0D=0A=0D=0AI, for one, will be qu= ite happy to pay extra for my wireless Internet=0D=0A(and wireline) access = to have it provide me with the location service.=0D=0A"Yes, please location= -enable my WiMAX access for an extra $X per month".=0D=0AFor the price of t= hat premium on my subscription, I want to be able to=0D=0Aget location for = any application, and not just have it available to=0D=0Aemergency services.= I'll register the location information with my=0D=0Apresence service(s) an= d applications that query that service based on my=0D=0Apresence identity w= ill also be served; my presence service provider may=0D=0Acharge them for t= hat privilege, but I won't see that.=0D=0A=0D=0AWhat's new here, from the p= erspective of established operators, is the=0D=0Aidea of just charging for = location capability as part of the access=0D=0Aservice. Nevertheless, assum= ing they introduce that option, or if they=0D=0Apersist with trying to cont= rol access to location information by all=0D=0Aapplications for some interi= m period, there still needs to be an option=0D=0Ato only have location info= rmation available for emergency services.=0D=0A=0D=0AYou are arguing that a= ccess network operators should not give their=0D=0Asubscribers the option o= f paying for the location service explicitly.=0D=0AThey should be given it,= and charged for it, regardless. There aren't=0D=0Atoo many new network ser= vices that get introduced that way. I don't=0D=0Athink we can insist that i= t be done this way. I think the important goal=0D=0Ais to get access networ= ks location-enabled as quickly as possible so=0D=0Athat emergency services = for VoIP work as quickly as possible. Playing=0D=0Achicken with operators b= y deliberately not supporting "location hiding"=0D=0Ain the location protoc= ols is not in keeping with that goal - and, I'm=0D=0Asure, wouldn't work an= yway. At best it will delay the availability of a=0D=0Aubiquitous location = service.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message---= --=0D=0AFrom: James M. Polk [mailto:jmpolk@cisco.com]=20=0D=0ASent: Sunday,= 2 September 2007 6:51 AM=0D=0ATo: Winterbottom, James; Brian Rosen; Clive = D.W. Feather=0D=0ACc: ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Comments on = location-hiding-requirements-01=0D=0A=0D=0AAt 05:00 PM 8/31/2007, Winterbot= tom, James wrote:=0D=0A>Yes, but we MUST choose an implementation such that= the cost of=0D=0A>implementing and it running doesn't exceed the revenue o= r costs of just=0D=0A>giving location away for free in the first place.=0D=0A=0D= =0AThis is a little bit over-dramatic. No service provided to your phone =0D= =0A(pick any one you own and this applies) is free. If you have a=20=0D=0A= phone, you pay for _the_whole_service_. Why are folks insisting that=20=0D=0A= Location be the first to be given away for free=3F=0D=0A=0D=0AIt clearly wi= ll not be - so get off this FUD, please!=0D=0A=0D=0AIf providing location t= o all subscribers costs 25 or 50 or 75 cents=20=0D=0Amore a month, then all= subscribers will pay that in their bill each=20=0D=0Amonth. That's the eco= nomic solution to this "problem".=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A> > --= ---Original Message-----=0D=0A> > From: Brian Rosen [mailto:br@brianrosen.n= et]=0D=0A> > Sent: Saturday, 1 September 2007 1:26 AM=0D=0A> > To: 'Clive D= =2EW. Feather'=0D=0A> > Cc: ecrit@ietf.org=0D=0A> > Subject: RE: [Ecrit] Co= mments on location-hiding-requirements-01=0D=0A> >=0D=0A> > Nah, the UA can= 't be fooled easily, especially if it does the dial=0D=0A>string=0D=0A> > i= nterpretation. The information can't easily be extracted along the=0D=0A>w= ay=0D=0A> > if=0D=0A> > the bcp guidelines are followed (the location would= be encrypted).=0D=0A> >=0D=0A> > Agree that the ISP doesn't have a problem= giving location to a PSAP.=0D=0A> >=0D=0A> > It has a problem giving it to= a UA who can then use it for things=0D=0A>other=0D=0A> > than=0D=0A> > an = emergency call. It has the same problem giving it to the ASP who=0D=0A>run= s=0D=0A> > the calling network.=0D=0A> >=0D=0A> > This is not a security pr= oblem, it is an economic problem. That=0D=0A>doesn't=0D=0A> > make it any = less real, and we're going to have to solve it.=0D=0A> >=0D=0A> > Brian=0D=0A= > >=0D=0A> >=0D=0A> > > -----Original Message-----=0D=0A> > > From: Clive D= =2EW. Feather [mailto:clive@demon.net]=0D=0A> > > Sent: Friday, August 31, = 2007 11:11 AM=0D=0A> > > To: Brian Rosen=0D=0A> > > Cc: 'James M. Polk'; ec= rit@ietf.org=0D=0A> > > Subject: Re: [Ecrit] Comments on location-hiding-re= quirements-01=0D=0A> > >=0D=0A> > > Brian Rosen said:=0D=0A> > > > The answ= er to your question is that it is the fact that we ARE=0D=0A> > requiring=0D= =0A> > > > location to be provided to the UA and/or the calling network=0D=0A= that=0D=0A> > makes=0D=0A> > > IP=0D=0A> > > > different. In the current P= STN, the access network provides the=0D=0A> > > location=0D=0A> > > > direc= tly to the PSAP. In the Internet, we don't do that.=0D=0A> > >=0D=0A> > > = Actually, I think that the point is that in the PSTN the location=0D=0Ais=0D= =0A> > > provided *only* to genuine PSAPs - the access network provides=0D=0A= that=0D=0A> > > (unwritten) guarantee.=0D=0A> > >=0D=0A> > > I don't believ= e ISPs are objecting to providing location=0D=0Ainformation=0D=0A>to=0D=0A>= > > PSAPs. They're objecting to providing it to any Tom, Delila, and=0D=0A= >Harry=0D=0A> > who=0D=0A> > > can look enough like a PSAP to fool the UA o= r who can extract the=0D=0A> > > information along the way.=0D=0A> > >=0D=0A= > > > --=0D=0A> > > Clive D.W. Feather | Work: | Tel:= +44 20=0D=0A>8495=0D=0A> > > 6138=0D=0A> > > Internet Expert | Home= : | Fax: +44 870=0D=0A>051=0D=0A> > > 9937=0D=0A> >= > Demon Internet | WWW: http://www.davros.org | Mobile: +44=0D=0A7973=0D= =0A> > 377646=0D=0A> > > THUS plc | |=0D= =0A> >=0D=0A> >=0D=0A> > _______________________________________________=0D= =0A> > Ecrit mailing list=0D=0A> > Ecrit@ietf.org=0D=0A> > https://www1.iet= f.org/mailman/listinfo/ecrit=0D=0A>=0D=0A>---------------------------------= --------------------------------------=0D=0A-------------------------=0D=0A= >This message is for the designated recipient only and may=0D=0A>contain pr= ivileged, proprietary, or otherwise private information.=0D=0A>If you have = received it in error, please notify the sender=0D=0A>immediately and delete= the original. Any unauthorized use of=0D=0A>this email is prohibited.=0D=0A= >-----------------------------------------------------------------------=0D= =0A-------------------------=0D=0A>[mf2]=0D=0A>=0D=0A>=0D=0A>______________= _________________________________=0D=0A>Ecrit mailing list=0D=0A>Ecrit@ietf= =2Eorg=0D=0A>https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A______= _________________________________________=0D=0AEcrit mailing list=0D=0AEcri= t@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A---= ---------------------------------------------------------------------------= ------------------=0D=0AThis message is for the designated recipient only a= nd may=0D=0Acontain privileged, proprietary, or otherwise private informati= on. =20=0D=0AIf you have received it in error, please notify the sender=0D=0A= immediately and delete the original. Any unauthorized use of=0D=0Athis ema= il is prohibited.=0D=0A----------------------------------------------------= --------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 03 16:00:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISI4C-0005Rl-3U; Mon, 03 Sep 2007 15:58:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISI4B-0005Rd-F2 for ecrit@ietf.org; Mon, 03 Sep 2007 15:58:35 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ISI49-0006j4-ME for ecrit@ietf.org; Mon, 03 Sep 2007 15:58:35 -0400 Received: (qmail invoked by alias); 03 Sep 2007 19:58:32 -0000 Received: from p54985118.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.81.24] by mail.gmx.net (mp035) with SMTP; 03 Sep 2007 21:58:32 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+RHplcZ6SRGsuRSJjnuBiQT0RF9iSpvUpNOtWgI4 HNN04B5ojC5iHQ Message-ID: <46DC6762.2010706@gmx.net> Date: Mon, 03 Sep 2007 21:58:26 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) 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: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Ecrit] Request URI in Phone BCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org There is a mistake in the Phone BCP in Section 6.1, bullet (1). Here is the text: " 1. The Request URI SHOULD be a PSAP URI obtained from LoST (see Section 6.3). If the device cannot access a LoST server, the To: SHOULD be a service URN in the "sos" tree. " Instead of talking about the To in the second sentence it should say Request URI. Here is the changed text: " 1. The Request URI SHOULD be a PSAP URI obtained from LoST (see Section 6.3). If the device cannot access a LoST server, the Request URI SHOULD be a service URN in the "sos" tree. " I believe that item (5) should be removed: " 5. A Route header SHOULD be present with the service URN in the "sos" tree, and the loose route parameter. " The 3GPP IMS emergency service spec, TS 24.229, does not use it either. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 03 16:01:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISI5B-0006NU-M5; Mon, 03 Sep 2007 15:59:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISI5B-0006Ly-8Y for ecrit@ietf.org; Mon, 03 Sep 2007 15:59:37 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ISI59-0006jy-Si for ecrit@ietf.org; Mon, 03 Sep 2007 15:59:37 -0400 Received: (qmail invoked by alias); 03 Sep 2007 19:59:34 -0000 Received: from p54985118.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.81.24] by mail.gmx.net (mp057) with SMTP; 03 Sep 2007 21:59:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18FoQY9PVgFObf5aK0K2LUFT+7tkjljMq2K9k0jNp u953W5TjIj/s/m Message-ID: <46DC67A0.60809@gmx.net> Date: Mon, 03 Sep 2007 21:59:28 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dean Willis Subject: Re: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt References: <46CAE441.8080504@gmx.net> <46D1C942.7010501@gmx.net> <46D264F9.6080101@softarmor.com> In-Reply-To: <46D264F9.6080101@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: IETF SIP List , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Dean, in ECRIT we assumed that the Request URI contains the service URN. We put that stuff into the Phone BCP document (which unfortunately still contains an error I just noticed). That's what we told the 3GPP in the past as well. Hence, they wrote it in their specs. See TS 24.229, Section 5.1.6.8.3, bullet (1). Within the ECRIT group we weren't aware that this issue has not been decided and hence we are a bit concerned about the recent change given that other SDOs followed our suggestion already. Do you have an idea what we should do now? Ciao Hannes Dean Willis wrote: > Hannes Tschofenig wrote: >> No response received -- resend. >> >> Hannes Tschofenig wrote: >> >>> Dear SIP WG members, >>> >>> during the ECRIT meeting we learned that the SIP working group >>> "rejected" the concept described in >>> draft-rosenberg-sip-ua-loose-route-01.txt. >>> >>> Could someone please give us more information about this decision as >>> it impacts the work we do in ECRIT? > > I wouldn't say that UA Loose Route was "rejected" so much as "does not > yet have consensus". > > This is in part influenced by "WG doesn't seem to have a compelling > reason to make such a significant change." > > Perhaps ECRIT has a compelling reason? > > -- > Dean _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 03 22:32:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISOBg-0005II-8Q; Mon, 03 Sep 2007 22:30:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISOBe-0005Gx-Pf for ecrit@ietf.org; Mon, 03 Sep 2007 22:30:42 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISOBe-0007Xx-B8 for ecrit@ietf.org; Mon, 03 Sep 2007 22:30:42 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1ISOBc-0004aW-HX; Mon, 03 Sep 2007 21:30:40 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'ECRIT'" References: <46DC6762.2010706@gmx.net> Subject: RE: [Ecrit] Request URI in Phone BCP Date: Mon, 3 Sep 2007 22:30:38 -0400 Message-ID: <064f01c7ee9b$9669b4c0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <46DC6762.2010706@gmx.net> Thread-Index: AcfuZRCKR47BG6ZKSB695C33mvUMvAANYgUA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I don't think that is right, and I think the loose route draft is correct. If you put the PSAP URI in the Request URI then you don't know it's an emergency call, and you don't know what service was requested. The service URN is the marker that the call is an emergency call. If you put the service URN in the Request URI, and the PSAP URI in a Route header, then the call will be routed to the PSAP correctly, and the Request URI will remain as the service URN. You can't depend on To:, although if the UA recognizes the dial string, then the To: would also have the service URN. If it did not detect the dialstring, the To: would have the dial string. If the UA did not do the LoST dip, then there would not be a Route header. This allows the first hop proxy to determine what it needs to do. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Monday, September 03, 2007 3:58 PM > To: ECRIT > Subject: [Ecrit] Request URI in Phone BCP > > There is a mistake in the Phone BCP in Section 6.1, bullet (1). Here is > the text: > > " > 1. The Request URI SHOULD be a PSAP URI obtained from LoST (see Section > 6.3). If the device cannot access a LoST server, the To: SHOULD be a > service URN in the "sos" tree. > " > > Instead of talking about the To in the second sentence it should say > Request URI. Here is the changed text: > > " > 1. The Request URI SHOULD be a PSAP URI obtained from LoST (see Section > 6.3). If the device cannot access a LoST server, the Request URI SHOULD > be a service URN in the "sos" tree. > " > > I believe that item (5) should be removed: > > " > 5. A Route header SHOULD be present with the service URN in the "sos" > tree, and the loose route parameter. > " > > The 3GPP IMS emergency service spec, TS 24.229, does not use it either. > > Ciao > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 03 23:53:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISPSW-0001zG-D9; Mon, 03 Sep 2007 23:52:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISPSV-0001z1-85 for ecrit@ietf.org; Mon, 03 Sep 2007 23:52:11 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISPST-0002cB-Es for ecrit@ietf.org; Mon, 03 Sep 2007 23:52:10 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 03 Sep 2007 20:52:09 -0700 X-IronPort-AV: i="4.20,203,1186383600"; d="scan'208"; a="211487241:sNHT53150400" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l843q8IB019716; Mon, 3 Sep 2007 20:52:08 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l843q6Qt001367; Tue, 4 Sep 2007 03:52:08 GMT 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, 3 Sep 2007 20:52:06 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.126.187]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Sep 2007 20:52:05 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 03 Sep 2007 22:52:01 -0500 To: "Brian Rosen" , "'Hannes Tschofenig'" , "'ECRIT'" From: "James M. Polk" Subject: RE: [Ecrit] Request URI in Phone BCP In-Reply-To: <064f01c7ee9b$9669b4c0$640fa8c0@cis.neustar.com> References: <46DC6762.2010706@gmx.net> <064f01c7ee9b$9669b4c0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 04 Sep 2007 03:52:05.0981 (UTC) FILETIME=[F5D690D0:01C7EEA6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3413; t=1188877928; x=1189741928; c=relaxed/simple; s=sjdkim4002; 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]=20Request=20URI=20in=20Phone=20BCP |Sender:=20; bh=4xnsAMtCzjWQUGyafZgntbwlswKaYzDBkrOjmUmgwYg=; b=GnIQYvnCJBd2OZNviZwGL1iZSGKUxieAgivGyUpM3byIrmxhP7yhxWpEMldTEp2BWgZOLIYG MJI5i1OEhBBPim4Mfv3vuE628saufqZEIiAnz6cChzvFSbR4hGJrLaIM; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes I agree with Brian. We need to have an 'emergency' indication in all SIP requests. Since the To cannot be relied upon not to have been changed along the way, the indication needs to be somewhere other than the To header. The Route header is intended to be untouched by any entity until the request gets to the device at that (the Route header's) URI, so integrity is at least intended. We can't even say this for the To header. Leaving the R-URI as the service URN leaves the emergency indication in the request. If the next destination hop is not in the R-URI position in the request, it needs to be in the Route header (with an "lr" (for 'loose route' URI parameter). This accomplishes what we all want: - the request to have a service indication (in the R-URI placement) - the request to be routed at the PSAP URI (the URI in the Route header, with the lr parameter) - no trust required from the To header (i.e., not extending the integrity of the To header, like the pains PAI did - which has limited applicability anywhere it's used) At 09:30 PM 9/3/2007, Brian Rosen wrote: >I don't think that is right, and I think the loose route draft is correct. >If you put the PSAP URI in the Request URI then you don't know it's an >emergency call, and you don't know what service was requested. The service >URN is the marker that the call is an emergency call. > >If you put the service URN in the Request URI, and the PSAP URI in a Route >header, then the call will be routed to the PSAP correctly, and the Request >URI will remain as the service URN. > >You can't depend on To:, although if the UA recognizes the dial string, then >the To: would also have the service URN. If it did not detect the >dialstring, the To: would have the dial string. > >If the UA did not do the LoST dip, then there would not be a Route header. >This allows the first hop proxy to determine what it needs to do. > >Brian > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Monday, September 03, 2007 3:58 PM > > To: ECRIT > > Subject: [Ecrit] Request URI in Phone BCP > > > > There is a mistake in the Phone BCP in Section 6.1, bullet (1). Here is > > the text: > > > > " > > 1. The Request URI SHOULD be a PSAP URI obtained from LoST (see Section > > 6.3). If the device cannot access a LoST server, the To: SHOULD be a > > service URN in the "sos" tree. > > " > > > > Instead of talking about the To in the second sentence it should say > > Request URI. Here is the changed text: > > > > " > > 1. The Request URI SHOULD be a PSAP URI obtained from LoST (see Section > > 6.3). If the device cannot access a LoST server, the Request URI SHOULD > > be a service URN in the "sos" tree. > > " > > > > I believe that item (5) should be removed: > > > > " > > 5. A Route header SHOULD be present with the service URN in the "sos" > > tree, and the loose route parameter. > > " > > > > The 3GPP IMS emergency service spec, TS 24.229, does not use it either. > > > > Ciao > > Hannes > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 04 02:41:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISS4i-0006kW-Df; Tue, 04 Sep 2007 02:39:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISS4h-0006k8-Hw for ecrit@ietf.org; Tue, 04 Sep 2007 02:39:47 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ISS4f-0006GT-RU for ecrit@ietf.org; Tue, 04 Sep 2007 02:39:47 -0400 Received: (qmail invoked by alias); 04 Sep 2007 06:39:44 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp012) with SMTP; 04 Sep 2007 08:39:44 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+A8jl4T8WA6q3yCcsxd5FJcHK1n6Pkf7gOdIkoh0 PZpp3C5mSfDeBn Message-ID: <46DCFDAA.7060607@gmx.net> Date: Tue, 04 Sep 2007 08:39:38 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Request URI in Phone BCP References: <46DC6762.2010706@gmx.net> <064f01c7ee9b$9669b4c0$640fa8c0@cis.neustar.com> In-Reply-To: <064f01c7ee9b$9669b4c0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian, Brian Rosen wrote: > I don't think that is right, and I think the loose route draft is correct. > I my mail I mentioned 2 issues. The loose route draft talks about the Request URI and in my opinion that's a good approach. This would require a bugfix for the first sentence that talks about "To:" instead of "Request URI". > If you put the PSAP URI in the Request URI then you don't know it's an > emergency call, and you don't know what service was requested. I fully agree with you. > The service > URN is the marker that the call is an emergency call. > > Correct. > If you put the service URN in the Request URI, and the PSAP URI in a Route > header, then the call will be routed to the PSAP correctly, and the Request > URI will remain as the service URN. > I agree that the service URN needs to be put into the Request URI. That's fine. I am not sure why you need to put the PSAP URI into the Route header instead of putting it into the To header if you run LoST at the end host. > You can't depend on To:, although if the UA recognizes the dial string, then > the To: would also have the service URN. Correct. > If it did not detect the > dialstring, the To: would have the dial string. > Correct. > If the UA did not do the LoST dip, then there would not be a Route header. > Correct. > This allows the first hop proxy to determine what it needs to do. > > To be a bit more systematic, we have the following cases: * UA does not recognize the emergency call. To: would have the dial string. * UA runs LoST and determines the PSAP URI: Request URI: Service URN My suggestion: To: would have the PSAP URI. * UA does not run LoST but recognizes the emergency call. Request URI: Service URN To: Service URN Ciao Hannes > Brian > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Monday, September 03, 2007 3:58 PM >> To: ECRIT >> Subject: [Ecrit] Request URI in Phone BCP >> >> There is a mistake in the Phone BCP in Section 6.1, bullet (1). Here is >> the text: >> >> " >> 1. The Request URI SHOULD be a PSAP URI obtained from LoST (see Section >> 6.3). If the device cannot access a LoST server, the To: SHOULD be a >> service URN in the "sos" tree. >> " >> >> Instead of talking about the To in the second sentence it should say >> Request URI. Here is the changed text: >> >> " >> 1. The Request URI SHOULD be a PSAP URI obtained from LoST (see Section >> 6.3). If the device cannot access a LoST server, the Request URI SHOULD >> be a service URN in the "sos" tree. >> " >> >> I believe that item (5) should be removed: >> >> " >> 5. A Route header SHOULD be present with the service URN in the "sos" >> tree, and the loose route parameter. >> " >> >> The 3GPP IMS emergency service spec, TS 24.229, does not use it either. >> >> Ciao >> Hannes >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 04 02:45:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISS8v-0002No-BN; Tue, 04 Sep 2007 02:44:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISS8u-0002Ng-Dz for ecrit@ietf.org; Tue, 04 Sep 2007 02:44:08 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISS8t-00051d-FE for ecrit@ietf.org; Tue, 04 Sep 2007 02:44:08 -0400 Received: (qmail invoked by alias); 04 Sep 2007 06:44:05 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp003) with SMTP; 04 Sep 2007 08:44:05 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+yDhlr2Cmy6qbc4m5S9+b44bzrqI9hRAX7CfN83K 7m8kDb+fECaKMQ Message-ID: <46DCFEAF.3020702@gmx.net> Date: Tue, 04 Sep 2007 08:43:59 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] Request URI in Phone BCP References: <46DC6762.2010706@gmx.net> <064f01c7ee9b$9669b4c0$640fa8c0@cis.neustar.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi James, James M. Polk wrote: > Hannes > > I agree with Brian. We need to have an 'emergency' indication in all > SIP requests. I agree. > Since the To cannot be relied upon not to have been changed along the > way, the indication needs to be somewhere other than the To header. I agree as well. This was the motivation for the "UA Loose Routing" draft. > The Route header is intended to be untouched by any entity until the > request gets to the device at that (the Route header's) URI, so > integrity is at least intended. True. If I understood the Loose Routing draft correctly then this would be an alternative solution. Jonathan, however, proposed the usage of the Request URI instead of using the Route header. > We can't even say this for the To header. I know. Retargeting would change it. > > > Leaving the R-URI as the service URN leaves the emergency indication > in the request. Correct. This was my assumption until I learned about the lack of excitement for the UA Loose Routing draft in the SIP WG. Hence, I have asked them for clarification in my mail. > > If the next destination hop is not in the R-URI position in the > request, it needs to be in the Route header (with an "lr" (for 'loose > route' URI parameter). I don't understand that sentence. > > This accomplishes what we all want: > - the request to have a service indication (in the R-URI placement) Correct. > - the request to be routed at the PSAP URI (the URI in the Route > header, with the lr parameter) Why doesn't the PSAP URI belong into the To header? > - no trust required from the To header (i.e., not extending the > integrity of the To header, like the pains PAI did - which has limited > applicability anywhere it's used) I don't understand that sentence I am not sure this solution is inline with what the SIP guys are discussing. Ciao Hannes > > At 09:30 PM 9/3/2007, Brian Rosen wrote: >> I don't think that is right, and I think the loose route draft is >> correct. >> If you put the PSAP URI in the Request URI then you don't know it's an >> emergency call, and you don't know what service was requested. The >> service >> URN is the marker that the call is an emergency call. >> >> If you put the service URN in the Request URI, and the PSAP URI in a >> Route >> header, then the call will be routed to the PSAP correctly, and the >> Request >> URI will remain as the service URN. >> >> You can't depend on To:, although if the UA recognizes the dial >> string, then >> the To: would also have the service URN. If it did not detect the >> dialstring, the To: would have the dial string. >> >> If the UA did not do the LoST dip, then there would not be a Route >> header. >> This allows the first hop proxy to determine what it needs to do. >> >> Brian >> >> > -----Original Message----- >> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> > Sent: Monday, September 03, 2007 3:58 PM >> > To: ECRIT >> > Subject: [Ecrit] Request URI in Phone BCP >> > >> > There is a mistake in the Phone BCP in Section 6.1, bullet (1). >> Here is >> > the text: >> > >> > " >> > 1. The Request URI SHOULD be a PSAP URI obtained from LoST (see >> Section >> > 6.3). If the device cannot access a LoST server, the To: SHOULD be a >> > service URN in the "sos" tree. >> > " >> > >> > Instead of talking about the To in the second sentence it should say >> > Request URI. Here is the changed text: >> > >> > " >> > 1. The Request URI SHOULD be a PSAP URI obtained from LoST (see >> Section >> > 6.3). If the device cannot access a LoST server, the Request URI >> SHOULD >> > be a service URN in the "sos" tree. >> > " >> > >> > I believe that item (5) should be removed: >> > >> > " >> > 5. A Route header SHOULD be present with the service URN in the "sos" >> > tree, and the loose route parameter. >> > " >> > >> > The 3GPP IMS emergency service spec, TS 24.229, does not use it >> either. >> > >> > Ciao >> > Hannes >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www1.ietf.org/mailman/listinfo/ecrit >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 04 03:19:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISSfp-0003cx-8P; Tue, 04 Sep 2007 03:18:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISSfo-0003ci-9L for ecrit@ietf.org; Tue, 04 Sep 2007 03:18:08 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ISSfm-00073d-5p for ecrit@ietf.org; Tue, 04 Sep 2007 03:18:08 -0400 Received: (qmail invoked by alias); 04 Sep 2007 07:18:05 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp042) with SMTP; 04 Sep 2007 09:18:05 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+pBCgvMOyp1MKQI/zaVWMMxScNAOICusH16y3aXn H2GL55k9XWJEPF Message-ID: <46DD06A4.2080000@gmx.net> Date: Tue, 04 Sep 2007 09:17:56 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt References: <46CAE441.8080504@gmx.net> <46D1C942.7010501@gmx.net><46D264F9.6080101@softarmor.com> <46DC67A0.60809@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: IETF SIP List , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Christer, Christer Holmberg (JO/LMF) wrote: > Hi, > > In 3GPP, it is true that the UE inserts the service URN into the > Request-URI. > > But, in the current specification the E-CSCF converts the URN into a > routable PSAP address, i.e. the mechanism in the loose-route draft is > not used. > > Why was this done? Do you expect that the call uses a different emergency call marking technique went it enters the PSAP operator network? Do you expect that the call is directly sent from the E-CSCF to the PSAP and that there are no other hops in between? > Regards, > > Christer > > Ciao Hannes > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: 3. syyskuuta 2007 22:59 >> To: Dean Willis >> Cc: IETF SIP List; ECRIT >> Subject: Re: [Ecrit] Re: [Sip] >> draft-rosenberg-sip-ua-loose-route-01.txt >> >> Hi Dean, >> >> in ECRIT we assumed that the Request URI contains the service >> URN. We put that stuff into the Phone BCP document (which >> unfortunately still contains an error I just noticed). >> That's what we told the 3GPP in the past as well. Hence, they >> wrote it in their specs. See TS 24.229, Section 5.1.6.8.3, bullet (1). >> >> Within the ECRIT group we weren't aware that this issue has >> not been decided and hence we are a bit concerned about the >> recent change given that other SDOs followed our suggestion already. >> >> Do you have an idea what we should do now? >> >> Ciao >> Hannes >> >> >> Dean Willis wrote: >> >>> Hannes Tschofenig wrote: >>> >>>> No response received -- resend. >>>> >>>> Hannes Tschofenig wrote: >>>> >>>> >>>>> Dear SIP WG members, >>>>> >>>>> during the ECRIT meeting we learned that the SIP working group >>>>> "rejected" the concept described in >>>>> draft-rosenberg-sip-ua-loose-route-01.txt. >>>>> >>>>> Could someone please give us more information about this >>>>> >> decision as >> >>>>> it impacts the work we do in ECRIT? >>>>> >>> I wouldn't say that UA Loose Route was "rejected" so much >>> >> as "does not >> >>> yet have consensus". >>> >>> This is in part influenced by "WG doesn't seem to have a compelling >>> reason to make such a significant change." >>> >>> Perhaps ECRIT has a compelling reason? >>> >>> -- >>> Dean >>> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 04 08:07:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISXAT-0008Iw-CX; Tue, 04 Sep 2007 08:06:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISXAR-0008I6-Ab; Tue, 04 Sep 2007 08:06:03 -0400 Received: from david.siemens.de ([192.35.17.14]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISXAQ-0006zM-Do; Tue, 04 Sep 2007 08:06:03 -0400 Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id l84C60t0009031; Tue, 4 Sep 2007 14:06:00 +0200 Received: from demuprx017.emea.nsn-intra.net (demuprx017.emea.nsn-intra.net [10.150.129.56]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id l84C5xqL022702; Tue, 4 Sep 2007 14:05:59 +0200 Received: from demuexc023.nsn-intra.net ([10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id l84C5v9n030850; Tue, 4 Sep 2007 14:05:59 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 14:05:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Date: Tue, 4 Sep 2007 14:05:57 +0200 Message-ID: <5FB585F183235B42A9E70095055136FB0555C4@DEMUEXC012.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Thread-Index: Acfuw70diwY/GuHHQOGgmm2anxo1/QACAr2gAAfgDNA= References: <46CAE441.8080504@gmx.net><46D1C942.7010501@gmx.net><46D264F9.6080101@softarmor.com><46DC67A0.60809@gmx.net><46DD06A4.2080000@gmx.net> From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" To: "ext Christer Holmberg (JO/LMF)" , "Hannes Tschofenig" X-OriginalArrivalTime: 04 Sep 2007 12:05:57.0740 (UTC) FILETIME=[F3BE2AC0:01C7EEEB] X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: IETF SIP List , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Christer,=20 Thanks for your quick response.=20 Please find a few comments below:=20 > -----Urspr=FCngliche Nachricht----- > Von: ext Christer Holmberg (JO/LMF)=20 > [mailto:christer.holmberg@ericsson.com]=20 > Gesendet: Dienstag, 4. September 2007 14:00 > An: Hannes Tschofenig > Cc: IETF SIP List; ECRIT; Dean Willis > Betreff: RE: [Ecrit] Re: [Sip]=20 > draft-rosenberg-sip-ua-loose-route-01.txt >=20 >=20 > Hi,=20 >=20 > >>In 3GPP, it is true that the UE inserts the service URN into the > Request-URI. > >> > >>But, in the current specification the E-CSCF converts the=20 > URN into a=20 > >>routable PSAP address, i.e. the mechanism in the=20 > loose-route draft is=20 > >>not used. > >> > >> =20 > >Why was this done? >=20 > I don't have all the details, but one reason was that the same > procedures were wanted towards a PSAP and an MGCF, and at least in the > previous 3GPP releases the MGCF does the called party number mapping > based on the Request-URI value. You mean that the MGCF wouldn't know what todo with the Request URI.=20 This sounds like a backwards compatibility aspect. > Also, since this was done a while ago, > the loose-route draft mechanism wasn't even discussed. That's probably true.=20 Also, since > neither the PSAP or MGCF registers themselves to the E-CSCF, the > loose-route draft mechanism wouldn't be used towards those=20 > entities even > if adopted by IMS. I don't think that the Request URI has anything todo with registrations. = >=20 > >Do you expect that the call uses a different emergency call marking > technique went it enters the PSAP operator network? >=20 > I think it is up to each operator to decide how the marking is done. In the 3GPP model with the E-CSCF and the PSAP having a close = relationship you could leave this issue open. It would, however, make = their life easier.=20 > There will always be agreements between the PSAP operators=20 > and the other > ("public") operators using them. Only in the 3GPP IMS alike architecture. The IETF emergency services = architecture is a bit different.=20 I guess it would also be possible to > put the original service URN into the P-Called-Party-Id header (as for > normal calls), eventhough I don't think it's currently specified. I am not sure whether this is a good solution.=20 >=20 > >Do you expect that the call is directly sent from the E-CSCF to the > PSAP and that there are no other hops in between? >=20 > I think both cases are applicable. When you have intermediate entities that need to recognize emergency = calls and need to treat the call differently then you might want to = define the procedures since otherwise there is a chance that things = don't work as expected.=20 Ciao Hannes >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > > >> -----Original Message----- > > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > >> Sent: 3. syyskuuta 2007 22:59 > > >> To: Dean Willis > > >> Cc: IETF SIP List; ECRIT > > >> Subject: Re: [Ecrit] Re: [Sip] > > >> draft-rosenberg-sip-ua-loose-route-01.txt > > >> > > >> Hi Dean, > > >> > > >> in ECRIT we assumed that the Request URI contains the=20 > > service URN. We=20 > > >> put that stuff into the Phone BCP document (which=20 > > unfortunately still=20 > > >> contains an error I just noticed). > > >> That's what we told the 3GPP in the past as well. Hence,=20 > > they wrote=20 > > >> it in their specs. See TS 24.229, Section 5.1.6.8.3, bullet (1). > > >> > > >> Within the ECRIT group we weren't aware that this issue=20 > > has not been=20 > > >> decided and hence we are a bit concerned about the recent change=20 > > >> given that other SDOs followed our suggestion already. > > >> > > >> Do you have an idea what we should do now? > > >> > > >> Ciao > > >> Hannes > > >> > > >> > > >> Dean Willis wrote: > > >> =20 > > >>> Hannes Tschofenig wrote: > > >>> =20 > > >>>> No response received -- resend. > > >>>> > > >>>> Hannes Tschofenig wrote: > > >>>> > > >>>> =20 > > >>>>> Dear SIP WG members, > > >>>>> > > >>>>> during the ECRIT meeting we learned that the SIP=20 > working group=20 > > >>>>> "rejected" the concept described in=20 > > >>>>> draft-rosenberg-sip-ua-loose-route-01.txt. > > >>>>> > > >>>>> Could someone please give us more information about this > > >>>>> =20 > > >> decision as > > >> =20 > > >>>>> it impacts the work we do in ECRIT? > > >>>>> =20 > > >>> I wouldn't say that UA Loose Route was "rejected" so much > > >>> =20 > > >> as "does not > > >> =20 > > >>> yet have consensus". > > >>> > > >>> This is in part influenced by "WG doesn't seem to have a=20 > > compelling=20 > > >>> reason to make such a significant change." > > >>> > > >>> Perhaps ECRIT has a compelling reason? > > >>> > > >>> -- > > >>> Dean > > >>> =20 > > >> > > >> _______________________________________________ > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > >> This list is for NEW development of the core SIP Protocol Use=20 > > >> sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > >> sipping@ietf.org for new developments on the application of sip > > >> > > >> =20 > >=20 > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 04 08:52:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISXrP-0006Nq-5C; Tue, 04 Sep 2007 08:50:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISXrN-0006N3-6K; Tue, 04 Sep 2007 08:50:25 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISXrL-0000Bk-RF; Tue, 04 Sep 2007 08:50:25 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1ISXrC-0005Y4-Gu; Tue, 04 Sep 2007 07:50:14 -0500 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - DE/Germany - MiniMD\)'" , "'ext Christer Holmberg \(JO/LMF\)'" , "'Hannes Tschofenig'" References: <46CAE441.8080504@gmx.net><46D1C942.7010501@gmx.net><46D264F9.6080101@softarmor.com><46DC67A0.60809@gmx.net><46DD06A4.2080000@gmx.net> <5FB585F183235B42A9E70095055136FB0555C4@DEMUEXC012.nsn-intra.net> Subject: RE: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Date: Tue, 4 Sep 2007 08:50:18 -0400 Message-ID: <06d601c7eef2$27ba3700$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <5FB585F183235B42A9E70095055136FB0555C4@DEMUEXC012.nsn-intra.net> Thread-Index: Acfuw70diwY/GuHHQOGgmm2anxo1/QACAr2gAAfgDNAAAZdBoA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: 'IETF SIP List' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Just FYI, NENA is likely to require what ecrit decides, assuming that = there does not appear to be a large burden on carriers. This is one of the areas where it would appear there could be gratuitous differences between the IETF architecture and the IMS architecture which need to be addressed. Brian > -----Original Message----- > From: Tschofenig,Hannes (NSN - DE/Germany - MiniMD) > [mailto:hannes.tschofenig@nsn.com] > Sent: Tuesday, September 04, 2007 8:06 AM > To: ext Christer Holmberg (JO/LMF); Hannes Tschofenig > Cc: IETF SIP List; ECRIT > Subject: AW: [Ecrit] Re: [Sip] = draft-rosenberg-sip-ua-loose-route-01.txt >=20 > Hi Christer, >=20 > Thanks for your quick response. > Please find a few comments below: >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: ext Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Gesendet: Dienstag, 4. September 2007 14:00 > > An: Hannes Tschofenig > > Cc: IETF SIP List; ECRIT; Dean Willis > > Betreff: RE: [Ecrit] Re: [Sip] > > draft-rosenberg-sip-ua-loose-route-01.txt > > > > > > Hi, > > > > >>In 3GPP, it is true that the UE inserts the service URN into the > > Request-URI. > > >> > > >>But, in the current specification the E-CSCF converts the > > URN into a > > >>routable PSAP address, i.e. the mechanism in the > > loose-route draft is > > >>not used. > > >> > > >> > > >Why was this done? > > > > I don't have all the details, but one reason was that the same > > procedures were wanted towards a PSAP and an MGCF, and at least in = the > > previous 3GPP releases the MGCF does the called party number mapping > > based on the Request-URI value. >=20 > You mean that the MGCF wouldn't know what todo with the Request URI. > This sounds like a backwards compatibility aspect. >=20 > > Also, since this was done a while ago, > > the loose-route draft mechanism wasn't even discussed. > That's probably true. >=20 > Also, since > > neither the PSAP or MGCF registers themselves to the E-CSCF, the > > loose-route draft mechanism wouldn't be used towards those > > entities even > > if adopted by IMS. >=20 > I don't think that the Request URI has anything todo with = registrations. >=20 > > > > >Do you expect that the call uses a different emergency call marking > > technique went it enters the PSAP operator network? > > > > I think it is up to each operator to decide how the marking is done. >=20 >=20 > In the 3GPP model with the E-CSCF and the PSAP having a close = relationship > you could leave this issue open. It would, however, make their life > easier. >=20 > > There will always be agreements between the PSAP operators > > and the other > > ("public") operators using them. >=20 > Only in the 3GPP IMS alike architecture. The IETF emergency services > architecture is a bit different. >=20 > I guess it would also be possible to > > put the original service URN into the P-Called-Party-Id header (as = for > > normal calls), eventhough I don't think it's currently specified. >=20 > I am not sure whether this is a good solution. >=20 > > > > >Do you expect that the call is directly sent from the E-CSCF to the > > PSAP and that there are no other hops in between? > > > > I think both cases are applicable. > When you have intermediate entities that need to recognize emergency = calls > and need to treat the call differently then you might want to define = the > procedures since otherwise there is a chance that things don't work as > expected. >=20 > Ciao > Hannes >=20 > > > > Regards, > > > > Christer > > > > > > > > > > > > > >> -----Original Message----- > > > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > >> Sent: 3. syyskuuta 2007 22:59 > > > >> To: Dean Willis > > > >> Cc: IETF SIP List; ECRIT > > > >> Subject: Re: [Ecrit] Re: [Sip] > > > >> draft-rosenberg-sip-ua-loose-route-01.txt > > > >> > > > >> Hi Dean, > > > >> > > > >> in ECRIT we assumed that the Request URI contains the > > > service URN. We > > > >> put that stuff into the Phone BCP document (which > > > unfortunately still > > > >> contains an error I just noticed). > > > >> That's what we told the 3GPP in the past as well. Hence, > > > they wrote > > > >> it in their specs. See TS 24.229, Section 5.1.6.8.3, bullet = (1). > > > >> > > > >> Within the ECRIT group we weren't aware that this issue > > > has not been > > > >> decided and hence we are a bit concerned about the recent = change > > > >> given that other SDOs followed our suggestion already. > > > >> > > > >> Do you have an idea what we should do now? > > > >> > > > >> Ciao > > > >> Hannes > > > >> > > > >> > > > >> Dean Willis wrote: > > > >> > > > >>> Hannes Tschofenig wrote: > > > >>> > > > >>>> No response received -- resend. > > > >>>> > > > >>>> Hannes Tschofenig wrote: > > > >>>> > > > >>>> > > > >>>>> Dear SIP WG members, > > > >>>>> > > > >>>>> during the ECRIT meeting we learned that the SIP > > working group > > > >>>>> "rejected" the concept described in > > > >>>>> draft-rosenberg-sip-ua-loose-route-01.txt. > > > >>>>> > > > >>>>> Could someone please give us more information about this > > > >>>>> > > > >> decision as > > > >> > > > >>>>> it impacts the work we do in ECRIT? > > > >>>>> > > > >>> I wouldn't say that UA Loose Route was "rejected" so much > > > >>> > > > >> as "does not > > > >> > > > >>> yet have consensus". > > > >>> > > > >>> This is in part influenced by "WG doesn't seem to have a > > > compelling > > > >>> reason to make such a significant change." > > > >>> > > > >>> Perhaps ECRIT has a compelling reason? > > > >>> > > > >>> -- > > > >>> Dean > > > >>> > > > >> > > > >> _______________________________________________ > > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > >> This list is for NEW development of the core SIP Protocol Use > > > >> sip-implementors@cs.columbia.edu for questions on > > current sip Use > > > >> sipping@ietf.org for new developments on the application of sip > > > >> > > > >> > > > > > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 04 09:01:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISY02-00027P-Tm; Tue, 04 Sep 2007 08:59:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISY01-00027I-9g for ecrit@ietf.org; Tue, 04 Sep 2007 08:59:21 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISY00-0008S1-M2 for ecrit@ietf.org; Tue, 04 Sep 2007 08:59:21 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1ISXzs-000395-GT; Tue, 04 Sep 2007 07:59:12 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" References: <46DC6762.2010706@gmx.net> <064f01c7ee9b$9669b4c0$640fa8c0@cis.neustar.com> <46DCFDAA.7060607@gmx.net> Subject: RE: [Ecrit] Request URI in Phone BCP Date: Tue, 4 Sep 2007 08:59:16 -0400 Message-ID: <06d701c7eef3$68704400$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <46DCFDAA.7060607@gmx.net> Thread-Index: AcfuvmWn3KzJutESQ0mzkG4ib96b4gAM8RJA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes The To: header is not used to route. Request-URI and Route are used to route. How can we put the actual destination of the call in a To: field alone and expect the call to be routed there? Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, September 04, 2007 2:40 AM > To: Brian Rosen > Cc: 'ECRIT' > Subject: Re: [Ecrit] Request URI in Phone BCP > > Hi Brian, > > Brian Rosen wrote: > > I don't think that is right, and I think the loose route draft is > correct. > > > I my mail I mentioned 2 issues. > > The loose route draft talks about the Request URI and in my opinion > that's a good approach. > This would require a bugfix for the first sentence that talks about > "To:" instead of "Request URI". > > > If you put the PSAP URI in the Request URI then you don't know it's an > > emergency call, and you don't know what service was requested. > I fully agree with you. > > > The service > > URN is the marker that the call is an emergency call. > > > > > Correct. > > > If you put the service URN in the Request URI, and the PSAP URI in a > Route > > header, then the call will be routed to the PSAP correctly, and the > Request > > URI will remain as the service URN. > > > I agree that the service URN needs to be put into the Request URI. > That's fine. > I am not sure why you need to put the PSAP URI into the Route header > instead of putting it into the To header if you run LoST at the end host. > > > You can't depend on To:, although if the UA recognizes the dial string, > then > > the To: would also have the service URN. > Correct. > > If it did not detect the > > dialstring, the To: would have the dial string. > > > Correct. > > > If the UA did not do the LoST dip, then there would not be a Route > header. > > > Correct. > > > This allows the first hop proxy to determine what it needs to do. > > > > > To be a bit more systematic, we have the following cases: > > * UA does not recognize the emergency call. > > To: would have the dial string. > > > * UA runs LoST and determines the PSAP URI: > > Request URI: Service URN > My suggestion: To: would have the PSAP URI. > > > * UA does not run LoST but recognizes the emergency call. > > Request URI: Service URN > > To: Service URN > > > Ciao > Hannes > > > Brian > > > > > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: Monday, September 03, 2007 3:58 PM > >> To: ECRIT > >> Subject: [Ecrit] Request URI in Phone BCP > >> > >> There is a mistake in the Phone BCP in Section 6.1, bullet (1). Here is > >> the text: > >> > >> " > >> 1. The Request URI SHOULD be a PSAP URI obtained from LoST (see Section > >> 6.3). If the device cannot access a LoST server, the To: SHOULD be a > >> service URN in the "sos" tree. > >> " > >> > >> Instead of talking about the To in the second sentence it should say > >> Request URI. Here is the changed text: > >> > >> " > >> 1. The Request URI SHOULD be a PSAP URI obtained from LoST (see Section > >> 6.3). If the device cannot access a LoST server, the Request URI SHOULD > >> be a service URN in the "sos" tree. > >> " > >> > >> I believe that item (5) should be removed: > >> > >> " > >> 5. A Route header SHOULD be present with the service URN in the "sos" > >> tree, and the loose route parameter. > >> " > >> > >> The 3GPP IMS emergency service spec, TS 24.229, does not use it > either. > >> > >> Ciao > >> Hannes > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 04 09:10:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISY8r-00055C-8J; Tue, 04 Sep 2007 09:08:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISY8p-000557-RD for ecrit@ietf.org; Tue, 04 Sep 2007 09:08:27 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISY8o-0000GT-Vc for ecrit@ietf.org; Tue, 04 Sep 2007 09:08:27 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l84D89id002682 for ; Tue, 4 Sep 2007 08:08:21 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 08:06:44 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 15:06:39 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Date: Tue, 4 Sep 2007 15:06:37 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001636C13@DEEXC1U01.de.lucent.com> In-Reply-To: <5FB585F183235B42A9E70095055136FB0555C4@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Thread-Index: Acfuw70diwY/GuHHQOGgmm2anxo1/QACAr2gAAfgDNAAADNa4A== References: <46CAE441.8080504@gmx.net><46D1C942.7010501@gmx.net><46D264F9.6080101@softarmor.com><46DC67A0.60809@gmx.net><46DD06A4.2080000@gmx.net> <5FB585F183235B42A9E70095055136FB0555C4@DEMUEXC012.nsn-intra.net> From: "DRAGE, Keith \(Keith\)" To: "ECRIT" X-OriginalArrivalTime: 04 Sep 2007 13:06:39.0483 (UTC) FILETIME=[6E640CB0:01C7EEF4] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org (Removing parties from the original list distribution) The situation in 3GPP is that we have so far failed to agree any marking = or other carriage of other information (with a significant number of the = objections coming from the organisation Christer works for), not that we = have agreed we don't want one. I believe the appropriate way forward on marking for special handling is = actually the Resource-Priority header solution identified by =20 http://www.ietf.org/internet-drafts/draft-polk-ecrit-local-emergency-rph-= namespace-01.txt In terms of special handling, this makes a lot of sense for those SIP = entities that already have to implement RFC 4412 for other regulatory = reasons. As already indicated, the 3GPP E-CSCF (the emergency routeing proxy) = changes the Request-URI to the PSAP URI, and the original Reuqest-URI is = lost. Once we have reached the E-CSCF, is the original Request-URI (the = service URN) still important for any issue apart from special handling? Regards Keith > -----Original Message----- > From: Tschofenig,Hannes (NSN - DE/Germany - MiniMD)=20 > [mailto:hannes.tschofenig@nsn.com]=20 > Sent: Tuesday, September 04, 2007 1:06 PM > To: ext Christer Holmberg (JO/LMF); Hannes Tschofenig > Cc: IETF SIP List; ECRIT; Dean Willis > Subject: AW: [Ecrit] Re: [Sip]=20 > draft-rosenberg-sip-ua-loose-route-01.txt >=20 > Hi Christer,=20 >=20 > Thanks for your quick response.=20 > Please find a few comments below:=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: ext Christer Holmberg (JO/LMF) > > [mailto:christer.holmberg@ericsson.com] > > Gesendet: Dienstag, 4. September 2007 14:00 > > An: Hannes Tschofenig > > Cc: IETF SIP List; ECRIT; Dean Willis > > Betreff: RE: [Ecrit] Re: [Sip] > > draft-rosenberg-sip-ua-loose-route-01.txt > >=20 > >=20 > > Hi,=20 > >=20 > > >>In 3GPP, it is true that the UE inserts the service URN into the > > Request-URI. > > >> > > >>But, in the current specification the E-CSCF converts the=20 > > URN into a=20 > > >>routable PSAP address, i.e. the mechanism in the=20 > > loose-route draft is=20 > > >>not used. > > >> > > >> =20 > > >Why was this done? > >=20 > > I don't have all the details, but one reason was that the same > > procedures were wanted towards a PSAP and an MGCF, and at=20 > least in the > > previous 3GPP releases the MGCF does the called party number mapping > > based on the Request-URI value. >=20 > You mean that the MGCF wouldn't know what todo with the Request URI.=20 > This sounds like a backwards compatibility aspect. >=20 > > Also, since this was done a while ago, > > the loose-route draft mechanism wasn't even discussed. > That's probably true.=20 >=20 > Also, since > > neither the PSAP or MGCF registers themselves to the E-CSCF, the > > loose-route draft mechanism wouldn't be used towards those=20 > > entities even > > if adopted by IMS. >=20 > I don't think that the Request URI has anything todo with=20 > registrations.=20 >=20 > >=20 > > >Do you expect that the call uses a different emergency call marking > > technique went it enters the PSAP operator network? > >=20 > > I think it is up to each operator to decide how the marking is done. >=20 >=20 > In the 3GPP model with the E-CSCF and the PSAP having a close=20 > relationship you could leave this issue open. It would,=20 > however, make their life easier.=20 >=20 > > There will always be agreements between the PSAP operators=20 > > and the other > > ("public") operators using them. >=20 > Only in the 3GPP IMS alike architecture. The IETF emergency=20 > services architecture is a bit different.=20 >=20 > I guess it would also be possible to > > put the original service URN into the P-Called-Party-Id=20 > header (as for > > normal calls), eventhough I don't think it's currently specified. >=20 > I am not sure whether this is a good solution.=20 >=20 > >=20 > > >Do you expect that the call is directly sent from the E-CSCF to the > > PSAP and that there are no other hops in between? > >=20 > > I think both cases are applicable. > When you have intermediate entities that need to recognize=20 > emergency calls and need to treat the call differently then=20 > you might want to define the procedures since otherwise there=20 > is a chance that things don't work as expected.=20 >=20 > Ciao > Hannes >=20 > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > > > >> -----Original Message----- > > > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > >> Sent: 3. syyskuuta 2007 22:59 > > > >> To: Dean Willis > > > >> Cc: IETF SIP List; ECRIT > > > >> Subject: Re: [Ecrit] Re: [Sip] > > > >> draft-rosenberg-sip-ua-loose-route-01.txt > > > >> > > > >> Hi Dean, > > > >> > > > >> in ECRIT we assumed that the Request URI contains the=20 > > > service URN. We=20 > > > >> put that stuff into the Phone BCP document (which=20 > > > unfortunately still=20 > > > >> contains an error I just noticed). > > > >> That's what we told the 3GPP in the past as well. Hence,=20 > > > they wrote=20 > > > >> it in their specs. See TS 24.229, Section 5.1.6.8.3,=20 > bullet (1). > > > >> > > > >> Within the ECRIT group we weren't aware that this issue=20 > > > has not been=20 > > > >> decided and hence we are a bit concerned about the=20 > recent change=20 > > > >> given that other SDOs followed our suggestion already. > > > >> > > > >> Do you have an idea what we should do now? > > > >> > > > >> Ciao > > > >> Hannes > > > >> > > > >> > > > >> Dean Willis wrote: > > > >> =20 > > > >>> Hannes Tschofenig wrote: > > > >>> =20 > > > >>>> No response received -- resend. > > > >>>> > > > >>>> Hannes Tschofenig wrote: > > > >>>> > > > >>>> =20 > > > >>>>> Dear SIP WG members, > > > >>>>> > > > >>>>> during the ECRIT meeting we learned that the SIP=20 > > working group=20 > > > >>>>> "rejected" the concept described in=20 > > > >>>>> draft-rosenberg-sip-ua-loose-route-01.txt. > > > >>>>> > > > >>>>> Could someone please give us more information about this > > > >>>>> =20 > > > >> decision as > > > >> =20 > > > >>>>> it impacts the work we do in ECRIT? > > > >>>>> =20 > > > >>> I wouldn't say that UA Loose Route was "rejected" so much > > > >>> =20 > > > >> as "does not > > > >> =20 > > > >>> yet have consensus". > > > >>> > > > >>> This is in part influenced by "WG doesn't seem to have a=20 > > > compelling=20 > > > >>> reason to make such a significant change." > > > >>> > > > >>> Perhaps ECRIT has a compelling reason? > > > >>> > > > >>> -- > > > >>> Dean > > > >>> =20 > > > >> > > > >> _______________________________________________ > > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > >> This list is for NEW development of the core SIP Protocol Use=20 > > > >> sip-implementors@cs.columbia.edu for questions on=20 > > current sip Use=20 > > > >> sipping@ietf.org for new developments on the application of sip > > > >> > > > >> =20 > > >=20 > > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > >=20 >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 04 09:25:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISYNv-00024x-R2; Tue, 04 Sep 2007 09:24:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISYNu-00024m-NA for ecrit@ietf.org; Tue, 04 Sep 2007 09:24:02 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISYNu-0000iw-Ef for ecrit@ietf.org; Tue, 04 Sep 2007 09:24:02 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1ISYNl-0001g2-KX; Tue, 04 Sep 2007 08:23:53 -0500 From: "Brian Rosen" To: "'DRAGE, Keith \(Keith\)'" , "'ECRIT'" References: <46CAE441.8080504@gmx.net><46D1C942.7010501@gmx.net><46D264F9.6080101@softarmor.com><46DC67A0.60809@gmx.net><46DD06A4.2080000@gmx.net><5FB585F183235B42A9E70095055136FB0555C4@DEMUEXC012.nsn-intra.net> <5D1A7985295922448D5550C94DE2918001636C13@DEEXC1U01.de.lucent.com> Subject: RE: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Date: Tue, 4 Sep 2007 09:23:58 -0400 Message-ID: <06e501c7eef6$db68ea40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <5D1A7985295922448D5550C94DE2918001636C13@DEEXC1U01.de.lucent.com> Thread-Index: Acfuw70diwY/GuHHQOGgmm2anxo1/QACAr2gAAfgDNAAADNa4AACgHLA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 > .... Once we have reached the E-CSCF, is the original Request-URI (the > service URN) still important for any issue apart from special handling? Yes You need to know what service was requested, which may or may not be what PSAP it ended up on. This is especially true in disasters where regardless of what you asked for, the call may end up in some temporary call center. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 04 09:27:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISYQ3-00033J-3J; Tue, 04 Sep 2007 09:26:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISYQ1-000335-CN for ecrit@ietf.org; Tue, 04 Sep 2007 09:26:13 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISYPz-0001Ar-PY for ecrit@ietf.org; Tue, 04 Sep 2007 09:26:13 -0400 Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id l84DQ03p027791; Tue, 4 Sep 2007 15:26:00 +0200 Received: from demuprx016.emea.nsn-intra.net (demuprx016.emea.nsn-intra.net [10.150.129.55]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id l84DPxEY030820; Tue, 4 Sep 2007 15:25:59 +0200 Received: from demuexc022.nsn-intra.net ([10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id l84DPxKb007011; Tue, 4 Sep 2007 15:25:59 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 15:25:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Date: Tue, 4 Sep 2007 15:25:58 +0200 Message-ID: <5FB585F183235B42A9E70095055136FB150BDA@DEMUEXC012.nsn-intra.net> In-Reply-To: <5D1A7985295922448D5550C94DE2918001636C13@DEEXC1U01.de.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Thread-Index: Acfuw70diwY/GuHHQOGgmm2anxo1/QACAr2gAAfgDNAAADNa4AACeMeA References: <46CAE441.8080504@gmx.net><46D1C942.7010501@gmx.net><46D264F9.6080101@softarmor.com><46DC67A0.60809@gmx.net><46DD06A4.2080000@gmx.net><5FB585F183235B42A9E70095055136FB0555C4@DEMUEXC012.nsn-intra.net> <5D1A7985295922448D5550C94DE2918001636C13@DEEXC1U01.de.lucent.com> From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" To: "ext DRAGE, Keith (Keith)" , "ECRIT" X-OriginalArrivalTime: 04 Sep 2007 13:25:59.0834 (UTC) FILETIME=[22038FA0:01C7EEF7] X-Spam-Score: 0.0 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Keith,=20 > (Removing parties from the original list distribution) >=20 > The situation in 3GPP is that we have so far failed to agree=20 > any marking or other carriage of other information (with a=20 > significant number of the objections coming from the=20 > organisation Christer works for), not that we have agreed we=20 > don't want one. >=20 Understood.=20 > I believe the appropriate way forward on marking for special=20 > handling is actually the Resource-Priority header solution=20 > identified by =20 >=20 > http://www.ietf.org/internet-drafts/draft-polk-ecrit-local-eme rgency-rph-namespace-01.txt Good to hear that.=20 > In terms of special handling, this makes a lot of sense for=20 > those SIP entities that already have to implement RFC 4412=20 > for other regulatory reasons. Aren't these somewhat different entities given that RFC 4412 has it's = origin in the MLPP work (if I understood it correctly). > As already indicated, the 3GPP E-CSCF (the emergency routeing=20 > proxy) changes the Request-URI to the PSAP URI, and the=20 > original Reuqest-URI is lost. Once we have reached the=20 > E-CSCF, is the original Request-URI (the service URN) still=20 > important for any issue apart from special handling? In the 3GPP when the call leaves the E-CSCF towards the PSAP then it = might not be that important. (It is yet another issue whether there = needs to be call marking in the PSAP operators network itself -- NENA = might tell us more about that.) Is there some marking when messages are = sent between P-CSCF/E-CSCF and the user's home network? In the IETF architecture the call might travel through intermediate SIP = proxy when it leaves the user's home network.=20 Ciao Hannes >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: Tschofenig,Hannes (NSN - DE/Germany - MiniMD)=20 > > [mailto:hannes.tschofenig@nsn.com]=20 > > Sent: Tuesday, September 04, 2007 1:06 PM > > To: ext Christer Holmberg (JO/LMF); Hannes Tschofenig > > Cc: IETF SIP List; ECRIT; Dean Willis > > Subject: AW: [Ecrit] Re: [Sip]=20 > > draft-rosenberg-sip-ua-loose-route-01.txt > >=20 > > Hi Christer,=20 > >=20 > > Thanks for your quick response.=20 > > Please find a few comments below:=20 > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: ext Christer Holmberg (JO/LMF) > > > [mailto:christer.holmberg@ericsson.com] > > > Gesendet: Dienstag, 4. September 2007 14:00 > > > An: Hannes Tschofenig > > > Cc: IETF SIP List; ECRIT; Dean Willis > > > Betreff: RE: [Ecrit] Re: [Sip] > > > draft-rosenberg-sip-ua-loose-route-01.txt > > >=20 > > >=20 > > > Hi,=20 > > >=20 > > > >>In 3GPP, it is true that the UE inserts the service URN into the > > > Request-URI. > > > >> > > > >>But, in the current specification the E-CSCF converts the=20 > > > URN into a=20 > > > >>routable PSAP address, i.e. the mechanism in the=20 > > > loose-route draft is=20 > > > >>not used. > > > >> > > > >> =20 > > > >Why was this done? > > >=20 > > > I don't have all the details, but one reason was that the same > > > procedures were wanted towards a PSAP and an MGCF, and at=20 > > least in the > > > previous 3GPP releases the MGCF does the called party=20 > number mapping > > > based on the Request-URI value. > >=20 > > You mean that the MGCF wouldn't know what todo with the=20 > Request URI.=20 > > This sounds like a backwards compatibility aspect. > >=20 > > > Also, since this was done a while ago, > > > the loose-route draft mechanism wasn't even discussed. > > That's probably true.=20 > >=20 > > Also, since > > > neither the PSAP or MGCF registers themselves to the E-CSCF, the > > > loose-route draft mechanism wouldn't be used towards those=20 > > > entities even > > > if adopted by IMS. > >=20 > > I don't think that the Request URI has anything todo with=20 > > registrations.=20 > >=20 > > >=20 > > > >Do you expect that the call uses a different emergency=20 > call marking > > > technique went it enters the PSAP operator network? > > >=20 > > > I think it is up to each operator to decide how the=20 > marking is done. > >=20 > >=20 > > In the 3GPP model with the E-CSCF and the PSAP having a close=20 > > relationship you could leave this issue open. It would,=20 > > however, make their life easier.=20 > >=20 > > > There will always be agreements between the PSAP operators=20 > > > and the other > > > ("public") operators using them. > >=20 > > Only in the 3GPP IMS alike architecture. The IETF emergency=20 > > services architecture is a bit different.=20 > >=20 > > I guess it would also be possible to > > > put the original service URN into the P-Called-Party-Id=20 > > header (as for > > > normal calls), eventhough I don't think it's currently specified. > >=20 > > I am not sure whether this is a good solution.=20 > >=20 > > >=20 > > > >Do you expect that the call is directly sent from the=20 > E-CSCF to the > > > PSAP and that there are no other hops in between? > > >=20 > > > I think both cases are applicable. > > When you have intermediate entities that need to recognize=20 > > emergency calls and need to treat the call differently then=20 > > you might want to define the procedures since otherwise there=20 > > is a chance that things don't work as expected.=20 > >=20 > > Ciao > > Hannes > >=20 > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > > >> -----Original Message----- > > > > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > > >> Sent: 3. syyskuuta 2007 22:59 > > > > >> To: Dean Willis > > > > >> Cc: IETF SIP List; ECRIT > > > > >> Subject: Re: [Ecrit] Re: [Sip] > > > > >> draft-rosenberg-sip-ua-loose-route-01.txt > > > > >> > > > > >> Hi Dean, > > > > >> > > > > >> in ECRIT we assumed that the Request URI contains the=20 > > > > service URN. We=20 > > > > >> put that stuff into the Phone BCP document (which=20 > > > > unfortunately still=20 > > > > >> contains an error I just noticed). > > > > >> That's what we told the 3GPP in the past as well. Hence,=20 > > > > they wrote=20 > > > > >> it in their specs. See TS 24.229, Section 5.1.6.8.3,=20 > > bullet (1). > > > > >> > > > > >> Within the ECRIT group we weren't aware that this issue=20 > > > > has not been=20 > > > > >> decided and hence we are a bit concerned about the=20 > > recent change=20 > > > > >> given that other SDOs followed our suggestion already. > > > > >> > > > > >> Do you have an idea what we should do now? > > > > >> > > > > >> Ciao > > > > >> Hannes > > > > >> > > > > >> > > > > >> Dean Willis wrote: > > > > >> =20 > > > > >>> Hannes Tschofenig wrote: > > > > >>> =20 > > > > >>>> No response received -- resend. > > > > >>>> > > > > >>>> Hannes Tschofenig wrote: > > > > >>>> > > > > >>>> =20 > > > > >>>>> Dear SIP WG members, > > > > >>>>> > > > > >>>>> during the ECRIT meeting we learned that the SIP=20 > > > working group=20 > > > > >>>>> "rejected" the concept described in=20 > > > > >>>>> draft-rosenberg-sip-ua-loose-route-01.txt. > > > > >>>>> > > > > >>>>> Could someone please give us more information about this > > > > >>>>> =20 > > > > >> decision as > > > > >> =20 > > > > >>>>> it impacts the work we do in ECRIT? > > > > >>>>> =20 > > > > >>> I wouldn't say that UA Loose Route was "rejected" so much > > > > >>> =20 > > > > >> as "does not > > > > >> =20 > > > > >>> yet have consensus". > > > > >>> > > > > >>> This is in part influenced by "WG doesn't seem to have a=20 > > > > compelling=20 > > > > >>> reason to make such a significant change." > > > > >>> > > > > >>> Perhaps ECRIT has a compelling reason? > > > > >>> > > > > >>> -- > > > > >>> Dean > > > > >>> =20 > > > > >> > > > > >> _______________________________________________ > > > > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > > >> This list is for NEW development of the core SIP=20 > Protocol Use=20 > > > > >> sip-implementors@cs.columbia.edu for questions on=20 > > > current sip Use=20 > > > > >> sipping@ietf.org for new developments on the=20 > application of sip > > > > >> > > > > >> =20 > > > >=20 > > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > > This list is for NEW development of the core SIP Protocol > > > Use sip-implementors@cs.columbia.edu for questions on current sip > > > Use sipping@ietf.org for new developments on the=20 > application of sip > > >=20 > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 04 09:29:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISYRW-0004kS-4b; Tue, 04 Sep 2007 09:27:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISYRU-0004kK-Uj for ecrit@ietf.org; Tue, 04 Sep 2007 09:27:44 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISYRT-0001DO-8p for ecrit@ietf.org; Tue, 04 Sep 2007 09:27:44 -0400 Received: from mail2.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id l84DRUMY018919; Tue, 4 Sep 2007 15:27:31 +0200 Received: from demuprx017.emea.nsn-intra.net (demuprx017.emea.nsn-intra.net [10.150.129.56]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id l84DRU7V022298; Tue, 4 Sep 2007 15:27:30 +0200 Received: from demuexc022.nsn-intra.net ([10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id l84DRUnF019206; Tue, 4 Sep 2007 15:27:30 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 15:27:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Date: Tue, 4 Sep 2007 15:27:30 +0200 Message-ID: <5FB585F183235B42A9E70095055136FB150BDC@DEMUEXC012.nsn-intra.net> In-Reply-To: <06e501c7eef6$db68ea40$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Thread-Index: Acfuw70diwY/GuHHQOGgmm2anxo1/QACAr2gAAfgDNAAADNa4AACgHLAAABORxA= References: <46CAE441.8080504@gmx.net><46D1C942.7010501@gmx.net><46D264F9.6080101@softarmor.com><46DC67A0.60809@gmx.net><46DD06A4.2080000@gmx.net><5FB585F183235B42A9E70095055136FB0555C4@DEMUEXC012.nsn-intra.net><5D1A7985295922448D5550C94DE2918001636C13@DEEXC1U01.de.lucent.com> <06e501c7eef6$db68ea40$640fa8c0@cis.neustar.com> From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" To: "ext Brian Rosen" , "DRAGE, Keith (Keith)" , "ECRIT" X-OriginalArrivalTime: 04 Sep 2007 13:27:30.0617 (UTC) FILETIME=[581FF290:01C7EEF7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I forgot that part. You are completely right, Brian.=20 Ciao Hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: ext Brian Rosen [mailto:br@brianrosen.net]=20 > Gesendet: Dienstag, 4. September 2007 15:24 > An: 'DRAGE, Keith (Keith)'; 'ECRIT' > Betreff: RE: [Ecrit] Re: [Sip]=20 > draft-rosenberg-sip-ua-loose-route-01.txt >=20 > > .... Once we have reached the E-CSCF, is the original=20 > Request-URI (the > > service URN) still important for any issue apart from=20 > special handling? > Yes >=20 > You need to know what service was requested, which may or may=20 > not be what > PSAP it ended up on. This is especially true in disasters=20 > where regardless > of what you asked for, the call may end up in some temporary=20 > call center. >=20 > Brian >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 04 09:39:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISYb7-0003Il-CW; Tue, 04 Sep 2007 09:37:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISYb5-0003IL-KR for ecrit@ietf.org; Tue, 04 Sep 2007 09:37:39 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISYb5-000164-1I for ecrit@ietf.org; Tue, 04 Sep 2007 09:37:39 -0400 Received: (qmail invoked by alias); 04 Sep 2007 13:37:35 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp056) with SMTP; 04 Sep 2007 15:37:35 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19kLOM1SodkhDRJz/Mg/PkqNrNCtjTabRV2Cv/gqm OL0TyZ1WkfGIY5 Message-ID: <46DD5F9F.1040409@gmx.net> Date: Tue, 04 Sep 2007 15:37:35 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Subject: Re: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt References: <46CAE441.8080504@gmx.net><46D1C942.7010501@gmx.net><46D264F9.6080101@softarmor.com><46DC67A0.60809@gmx.net><46DD06A4.2080000@gmx.net> <5FB585F183235B42A9E70095055136FB0555C4@DEMUEXC012.nsn-intra.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: IETF SIP List , "Tschofenig, Hannes \(NSN - DE/Germany - MiniMD\)" , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Christer, >>> Also, since neither the PSAP or MGCF registers themselves to the >>> > E-CSCF, the > >>> loose-route draft mechanism wouldn't be used towards those >>> entities even if adopted by IMS. >>> >> I don't think that the Request URI has anything todo with >> > registrations. > > The mechanism in the draft is only used towards users that in the > registration have indicated support for it. > This seems to be a "capability discovery" approach. Since the PSAP does not register at the E-CSCF the "capability discovery" would not work. > > >>>> Do you expect that the call uses a different emergency call marking >>>> technique went it enters the PSAP operator network? >>>> >>> I think it is up to each operator to decide how the marking is done. >>> >> >> In the 3GPP model with the E-CSCF and the PSAP having a close >> relationship you could leave this issue open. It would, >> however, make their life easier. >> >> >>> There will always be agreements between the PSAP operators and the >>> > other > >>> ("public") operators using them. >>> >> Only in the 3GPP IMS alike architecture. The IETF emergency services >> > architecture is a bit different. > > Well, you asked how it works in IMS :) > Correct. I asked for the IMS description. But you understand that we would like to use mechanisms in a generic way whenever possible regardless whether the call starts in a 3GPP, Wimax, DSL, WLAN or enterprise network. > > >>> I guess it would also be possible to put the original service URN into >>> > the P-Called-Party-Id > >>> header (as for normal calls), eventhough I don't think it's currently >>> > specified. > >> I am not sure whether this is a good solution. >> > > Why not? > > I read through http://tools.ietf.org/wg/sip/draft-rosenberg-sip-ua-loose-route-01.txt and I got the impression that Jonathan has encountered a generic problem and the description he provided looked reasonable to me to argue for the Request URI to remains unchanged end-to-end and not to use other solutions. He listed two other solutions and the P- header approach does not look generic to me. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 04 11:25:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISaFc-0007YK-Po; Tue, 04 Sep 2007 11:23:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISaFX-0007Wl-7r for ecrit@ietf.org; Tue, 04 Sep 2007 11:23:31 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISaFW-00049P-7L for ecrit@ietf.org; Tue, 04 Sep 2007 11:23:31 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 04 Sep 2007 08:23:18 -0700 X-IronPort-AV: i="4.20,207,1186383600"; d="scan'208"; a="211831376:sNHT1396952640" 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/8.12.11) with ESMTP id l84FNICq014564; Tue, 4 Sep 2007 08:23:18 -0700 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 l84FNH69014446; Tue, 4 Sep 2007 15:23:17 GMT 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); Tue, 4 Sep 2007 08:23:09 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.114.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 08:23:09 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Sep 2007 10:23:08 -0500 To: Hannes Tschofenig From: "James M. Polk" Subject: Re: [Ecrit] Request URI in Phone BCP In-Reply-To: <46DCFEAF.3020702@gmx.net> References: <46DC6762.2010706@gmx.net> <064f01c7ee9b$9669b4c0$640fa8c0@cis.neustar.com> <46DCFEAF.3020702@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 04 Sep 2007 15:23:09.0341 (UTC) FILETIME=[7FED34D0:01C7EF07] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5207; t=1188919398; x=1189783398; c=relaxed/simple; s=sjdkim3002; 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]=20Request=20URI=20in=20Phone=20BCP |Sender:=20; bh=xTZ/E6w0ZPZEzJgvtNuzZCOTwjRXrEPwBMS3LnrQjNY=; b=Mqn3cr2m5aPkAYTS9nRpEg3B8D+DRRmn42twuszBOIcPWujMgAMzgbuLYPMSwYWHAYOvOKja 4g6v4VNZXyxiSePVb9JToQ+QSg1ANHy0/1unZDYOk50sZ4k+Q9u6HSQ1; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes comments in-line At 01:43 AM 9/4/2007, Hannes Tschofenig wrote: >Hi James, > >James M. Polk wrote: >>Hannes >> >>I agree with Brian. We need to have an 'emergency' indication in >>all SIP requests. >I agree. > >>Since the To cannot be relied upon not to have been changed along >>the way, the indication needs to be somewhere other than the To header. >I agree as well. This was the motivation for the "UA Loose Routing" draft. > >> The Route header is intended to be untouched by any entity until >> the request gets to the device at that (the Route header's) URI, >> so integrity is at least intended. > >True. If I understood the Loose Routing draft correctly then this >would be an alternative solution. Jonathan, however, proposed the >usage of the Request URI instead of using the Route header. > >> We can't even say this for the To header. >I know. Retargeting would change it. > >> >> >>Leaving the R-URI as the service URN leaves the emergency >>indication in the request. >Correct. This was my assumption until I learned about the lack of >excitement for the UA Loose Routing draft in the SIP WG. >Hence, I have asked them for clarification in my mail. > >> >>If the next destination hop is not in the R-URI position in the >>request, it needs to be in the Route header (with an "lr" (for >>'loose route' URI parameter). >I don't understand that sentence. This is classic SIP, per RFC 3261. A request is targeted at the URI in the status line (the first line of a SIP request) unless there is a Route header field with an "lr" URI parameter - which takes over as where (to the URI in the Route header) the request is targeted at until the message reaches this SIP element >>This accomplishes what we all want: >>- the request to have a service indication (in the R-URI placement) >Correct. >>- the request to be routed at the PSAP URI (the URI in the Route >>header, with the lr parameter) >Why doesn't the PSAP URI belong into the To header? it can be, but there is no trust in what's in the To header, that's the point >>- no trust required from the To header (i.e., not extending the >>integrity of the To header, like the pains PAI did - which has >>limited applicability anywhere it's used) >I don't understand that sentence because there is no integrity in the To header, P-Asserted-Identity (RFC3325) created a difficult solution that only works in a single domain. This limitation makes it not usable, and proves using the To header is not recommended. >I am not sure this solution is inline with what the SIP guys are discussing. huh? This is "the SIP solution"... I didn't originate it >Ciao >Hannes > >> >>At 09:30 PM 9/3/2007, Brian Rosen wrote: >>>I don't think that is right, and I think the loose route draft is correct. >>>If you put the PSAP URI in the Request URI then you don't know it's an >>>emergency call, and you don't know what service was requested. The service >>>URN is the marker that the call is an emergency call. >>> >>>If you put the service URN in the Request URI, and the PSAP URI in a Route >>>header, then the call will be routed to the PSAP correctly, and the Request >>>URI will remain as the service URN. >>> >>>You can't depend on To:, although if the UA recognizes the dial string, then >>>the To: would also have the service URN. If it did not detect the >>>dialstring, the To: would have the dial string. >>> >>>If the UA did not do the LoST dip, then there would not be a Route header. >>>This allows the first hop proxy to determine what it needs to do. >>> >>>Brian >>> >>> > -----Original Message----- >>> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> > Sent: Monday, September 03, 2007 3:58 PM >>> > To: ECRIT >>> > Subject: [Ecrit] Request URI in Phone BCP >>> > >>> > There is a mistake in the Phone BCP in Section 6.1, bullet (1). Here is >>> > the text: >>> > >>> > " >>> > 1. The Request URI SHOULD be a PSAP URI obtained from LoST (see Section >>> > 6.3). If the device cannot access a LoST server, the To: SHOULD be a >>> > service URN in the "sos" tree. >>> > " >>> > >>> > Instead of talking about the To in the second sentence it should say >>> > Request URI. Here is the changed text: >>> > >>> > " >>> > 1. The Request URI SHOULD be a PSAP URI obtained from LoST (see Section >>> > 6.3). If the device cannot access a LoST server, the Request URI SHOULD >>> > be a service URN in the "sos" tree. >>> > " >>> > >>> > I believe that item (5) should be removed: >>> > >>> > " >>> > 5. A Route header SHOULD be present with the service URN in the "sos" >>> > tree, and the loose route parameter. >>> > " >>> > >>> > The 3GPP IMS emergency service spec, TS 24.229, does not use it either. >>> > >>> > Ciao >>> > Hannes >>> > >>> > _______________________________________________ >>> > Ecrit mailing list >>> > Ecrit@ietf.org >>> > https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 04 11:44:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISaXr-0006Cl-Ds; Tue, 04 Sep 2007 11:42:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISaXq-0006Ce-ET for ecrit@ietf.org; Tue, 04 Sep 2007 11:42:26 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISaXp-0004lS-VY for ecrit@ietf.org; Tue, 04 Sep 2007 11:42:26 -0400 Received: from mail.bbn.com ([128.33.1.19]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1ISaXp-0002xs-3x; Tue, 04 Sep 2007 11:42:25 -0400 Received: from dhcp89-089-033.bbn.com ([128.89.89.33] helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.67) (envelope-from ) id 1ISaXp-00065O-5e; Tue, 04 Sep 2007 11:42:25 -0400 Message-ID: <46DD7CE0.5090305@bbn.com> Date: Tue, 04 Sep 2007 11:42:24 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Request URI in Phone BCP References: <46DC6762.2010706@gmx.net> <064f01c7ee9b$9669b4c0$640fa8c0@cis.neustar.com> In-Reply-To: <064f01c7ee9b$9669b4c0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Maybe I'm being simplistic, but why are we conflating emergency indication with routing? I realize that there's a need for emergency call marking, but it seems abusive to use the Route header for that. I think we need to find a header with a more appropriate semantic (even To seems better, since that's the logical destination). If there's not a header available that's has appropriate semantics and isn't modifiable, then we should define a new header field for emergency indication that MUST NOT be modified by any entity other than the UAC. --Richard Brian Rosen wrote: > I don't think that is right, and I think the loose route draft is correct. > If you put the PSAP URI in the Request URI then you don't know it's an > emergency call, and you don't know what service was requested. The service > URN is the marker that the call is an emergency call. > > If you put the service URN in the Request URI, and the PSAP URI in a Route > header, then the call will be routed to the PSAP correctly, and the Request > URI will remain as the service URN. > > You can't depend on To:, although if the UA recognizes the dial string, then > the To: would also have the service URN. If it did not detect the > dialstring, the To: would have the dial string. > > If the UA did not do the LoST dip, then there would not be a Route header. > This allows the first hop proxy to determine what it needs to do. > > Brian > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Monday, September 03, 2007 3:58 PM >> To: ECRIT >> Subject: [Ecrit] Request URI in Phone BCP >> >> There is a mistake in the Phone BCP in Section 6.1, bullet (1). Here is >> the text: >> >> " >> 1. The Request URI SHOULD be a PSAP URI obtained from LoST (see Section >> 6.3). If the device cannot access a LoST server, the To: SHOULD be a >> service URN in the "sos" tree. >> " >> >> Instead of talking about the To in the second sentence it should say >> Request URI. Here is the changed text: >> >> " >> 1. The Request URI SHOULD be a PSAP URI obtained from LoST (see Section >> 6.3). If the device cannot access a LoST server, the Request URI SHOULD >> be a service URN in the "sos" tree. >> " >> >> I believe that item (5) should be removed: >> >> " >> 5. A Route header SHOULD be present with the service URN in the "sos" >> tree, and the loose route parameter. >> " >> >> The 3GPP IMS emergency service spec, TS 24.229, does not use it either. >> >> Ciao >> Hannes >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 04 11:48:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISabz-0002pz-I1; Tue, 04 Sep 2007 11:46:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISaby-0002gx-4l for ecrit@ietf.org; Tue, 04 Sep 2007 11:46:42 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISabw-00059c-Tv for ecrit@ietf.org; Tue, 04 Sep 2007 11:46:42 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l84FkRbH014655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 4 Sep 2007 11:46:27 -0400 (EDT) In-Reply-To: <5FB585F183235B42A9E70095055136FB150BDC@DEMUEXC012.nsn-intra.net> References: <46CAE441.8080504@gmx.net><46D1C942.7010501@gmx.net><46D264F9.6080101@softarmor.com><46DC67A0.60809@gmx.net><46DD06A4.2080000@gmx.net><5FB585F183235B42A9E70095055136FB0555C4@DEMUEXC012.nsn-intra.net><5D1A7985295922448D5550C94DE2918001636C13@DEEXC1U01.de.lucent.com> <06e501c7eef6$db68ea40$640fa8c0@cis.neustar.com> <5FB585F183235B42A9E70095055136FB150BDC@DEMUEXC012.nsn-intra.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <2737DCC0-62F2-4633-843A-0AA770FB0648@cs.columbia.edu> Content-Transfer-Encoding: quoted-printable From: Henning Schulzrinne Subject: Re: AW: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Date: Tue, 4 Sep 2007 11:47:35 -0400 To: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" 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: -1.0 (-) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org While this is far from elegant, there is really no practical problem =20 with having multiple URIs end up in the same place. In other words, =20 each service URN can be mapped to different request URIs =20 (fire@overflowpsap, ambulance@overflowpsap, ....) and still be =20 answered by the same system or group of call takers. The user part =20 has only local significance, after all, and N-to-1 URI mappings are =20 quite common for other purposes. Henning On Sep 4, 2007, at 9:27 AM, Tschofenig, Hannes (NSN - DE/Germany - =20 MiniMD) wrote: > I forgot that part. You are completely right, Brian. > > Ciao > Hannes > > >> -----Urspr=FCngliche Nachricht----- >> Von: ext Brian Rosen [mailto:br@brianrosen.net] >> Gesendet: Dienstag, 4. September 2007 15:24 >> An: 'DRAGE, Keith (Keith)'; 'ECRIT' >> Betreff: RE: [Ecrit] Re: [Sip] >> draft-rosenberg-sip-ua-loose-route-01.txt >> >>> .... Once we have reached the E-CSCF, is the original >> Request-URI (the >>> service URN) still important for any issue apart from >> special handling? >> Yes >> >> You need to know what service was requested, which may or may >> not be what >> PSAP it ended up on. This is especially true in disasters >> where regardless >> of what you asked for, the call may end up in some temporary >> call center. >> >> 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 04 12:04:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISar1-0006ZR-3L; Tue, 04 Sep 2007 12:02:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISaqz-0006Z1-T1 for ecrit@ietf.org; Tue, 04 Sep 2007 12:02:13 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISaqx-0005X3-Sk for ecrit@ietf.org; Tue, 04 Sep 2007 12:02:13 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1ISaqn-0008D9-4T; Tue, 04 Sep 2007 11:02:01 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Tschofenig, Hannes \(NSN - DE/Germany - MiniMD\)'" References: <46CAE441.8080504@gmx.net><46D1C942.7010501@gmx.net><46D264F9.6080101@softarmor.com><46DC67A0.60809@gmx.net><46DD06A4.2080000@gmx.net><5FB585F183235B42A9E70095055136FB0555C4@DEMUEXC012.nsn-intra.net><5D1A7985295922448D5550C94DE2918001636C13@DEEXC1U01.de.lucent.com> <06e501c7eef6$db68ea40$640fa8c0@cis.neustar.com> <5FB585F183235B42A9E70095055136FB150BDC@DEMUEXC012.nsn-intra.net> <2737DCC0-62F2-4633-843A-0AA770FB0648@cs.columbia.edu> Subject: RE: AW: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Date: Tue, 4 Sep 2007 12:02:07 -0400 Message-ID: <072901c7ef0c$f3965470$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <2737DCC0-62F2-4633-843A-0AA770FB0648@cs.columbia.edu> Thread-Index: AcfvCsNhXG5tJVdlSrKSV23j+iLZxgAAOjBA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I thought about that. It gets a lot more complicated, but I imagine we could make it work. It would end up using something like: sip:fire+mytownpsap@provinceESRP.net A parameter could also be used. Everyone else would just pass it = through from LoST server to the PSAP. I'd really rather have an unambiguous marker. I also think the logic in Jonathan's loose-route draft is pretty good. Using the same idea in multiple environments is good. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, September 04, 2007 11:48 AM > To: Tschofenig, Hannes (NSN - DE/Germany - MiniMD) > Cc: ext Brian Rosen; DRAGE, Keith (Keith); ECRIT > Subject: Re: AW: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route- > 01.txt >=20 > While this is far from elegant, there is really no practical problem > with having multiple URIs end up in the same place. In other words, > each service URN can be mapped to different request URIs > (fire@overflowpsap, ambulance@overflowpsap, ....) and still be > answered by the same system or group of call takers. The user part > has only local significance, after all, and N-to-1 URI mappings are > quite common for other purposes. >=20 > Henning >=20 > On Sep 4, 2007, at 9:27 AM, Tschofenig, Hannes (NSN - DE/Germany - > MiniMD) wrote: >=20 > > I forgot that part. You are completely right, Brian. > > > > Ciao > > Hannes > > > > > >> -----Urspr=FCngliche Nachricht----- > >> Von: ext Brian Rosen [mailto:br@brianrosen.net] > >> Gesendet: Dienstag, 4. September 2007 15:24 > >> An: 'DRAGE, Keith (Keith)'; 'ECRIT' > >> Betreff: RE: [Ecrit] Re: [Sip] > >> draft-rosenberg-sip-ua-loose-route-01.txt > >> > >>> .... Once we have reached the E-CSCF, is the original > >> Request-URI (the > >>> service URN) still important for any issue apart from > >> special handling? > >> Yes > >> > >> You need to know what service was requested, which may or may > >> not be what > >> PSAP it ended up on. This is especially true in disasters > >> where regardless > >> of what you asked for, the call may end up in some temporary > >> call center. > >> > >> 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 04 12:08:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISav1-000493-0t; Tue, 04 Sep 2007 12:06:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISav0-00048K-EF for ecrit@ietf.org; Tue, 04 Sep 2007 12:06:22 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISauz-0005dd-3G for ecrit@ietf.org; Tue, 04 Sep 2007 12:06:22 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 04 Sep 2007 09:06:20 -0700 X-IronPort-AV: i="4.20,207,1186383600"; d="scan'208"; a="211860782:sNHT57142170" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l84G6KAK028518; Tue, 4 Sep 2007 09:06:20 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l84G6GZK015304; Tue, 4 Sep 2007 16:06:16 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 09:06:16 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.114.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 09:06:15 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 04 Sep 2007 11:06:14 -0500 To: Richard Barnes , Brian Rosen From: "James M. Polk" Subject: Re: [Ecrit] Request URI in Phone BCP In-Reply-To: <46DD7CE0.5090305@bbn.com> References: <46DC6762.2010706@gmx.net> <064f01c7ee9b$9669b4c0$640fa8c0@cis.neustar.com> <46DD7CE0.5090305@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 04 Sep 2007 16:06:15.0823 (UTC) FILETIME=[859709F0:01C7EF0D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3919; t=1188921980; x=1189785980; c=relaxed/simple; s=sjdkim1004; 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]=20Request=20URI=20in=20Phone=20BCP |Sender:=20; bh=ShCyqumWnMd0eWG8wGvhLKLpVwXPQowQCQK6THaqX8k=; b=l3k60qtuLQn6aJi2nDRr02ABLX5Ufi1tFkmF4dyjObFx/ghWkpVneEhaeh+yJqzyF6h6kjqX 1o/ISVAKbM32zZRa/dVJN9gf6iLGJMS5HI+saCjmyXMe17exwBRyjgg1ARJMUpQfClNHl4bmG8 5na4uGvAl9QDGdLQsg7AZeWo4=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Richard We're not conflating the two (at least I don't believe I am). I was stating that the emergency indication is needed. Routing to the correct PSAP is necessary. SIP requests are routed based on the URI in the R-URI in the status line *unless* there is a URI in a Route header. With the _PSAP_URI in the Route header, the R-URI can be the emergency indication (the sos service URN) with an implication that this value not change in transit. The To header cannot be trusted to be the same , whether this is a URI or emergency indication. SIP does not (lowercase 'r') route on the contents of the To header - therefore it should not be used at all for emergency calling for any field that needs to be relied upon. see below for the final answer At 10:42 AM 9/4/2007, Richard Barnes wrote: >Maybe I'm being simplistic, but why are we conflating emergency >indication with routing? I realize that there's a need for >emergency call marking, but it seems abusive to use the Route header >for that. I think we need to find a header with a more appropriate >semantic (even To seems better, since that's the logical destination). >If there's not a header available that's has appropriate semantics >and isn't modifiable, then we should define a new header field for >emergency indication that MUST NOT be modified by any entity other >than the UAC. The R-URI shouldn't change if there is a Route header with a URI of the PSAP. >--Richard > > > >Brian Rosen wrote: >>I don't think that is right, and I think the loose route draft is correct. >>If you put the PSAP URI in the Request URI then you don't know it's an >>emergency call, and you don't know what service was requested. The service >>URN is the marker that the call is an emergency call. >>If you put the service URN in the Request URI, and the PSAP URI in a Route >>header, then the call will be routed to the PSAP correctly, and the Request >>URI will remain as the service URN. >>You can't depend on To:, although if the UA recognizes the dial string, then >>the To: would also have the service URN. If it did not detect the >>dialstring, the To: would have the dial string. >>If the UA did not do the LoST dip, then there would not be a Route header. >>This allows the first hop proxy to determine what it needs to do. >>Brian >> >>>-----Original Message----- >>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>Sent: Monday, September 03, 2007 3:58 PM >>>To: ECRIT >>>Subject: [Ecrit] Request URI in Phone BCP >>> >>>There is a mistake in the Phone BCP in Section 6.1, bullet (1). Here is >>>the text: >>> >>>" >>>1. The Request URI SHOULD be a PSAP URI obtained from LoST (see Section >>>6.3). If the device cannot access a LoST server, the To: SHOULD be a >>>service URN in the "sos" tree. >>>" >>> >>>Instead of talking about the To in the second sentence it should say >>>Request URI. Here is the changed text: >>> >>>" >>>1. The Request URI SHOULD be a PSAP URI obtained from LoST (see Section >>>6.3). If the device cannot access a LoST server, the Request URI SHOULD >>>be a service URN in the "sos" tree. >>>" >>> >>>I believe that item (5) should be removed: >>> >>>" >>>5. A Route header SHOULD be present with the service URN in the "sos" >>>tree, and the loose route parameter. >>>" >>> >>>The 3GPP IMS emergency service spec, TS 24.229, does not use it either. >>> >>>Ciao >>>Hannes >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 04 14:16:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IScvg-0006Vb-W8; Tue, 04 Sep 2007 14:15:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IScvf-0006VO-Qb for ecrit@ietf.org; Tue, 04 Sep 2007 14:15:11 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IScve-00084X-VE for ecrit@ietf.org; Tue, 04 Sep 2007 14:15:11 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l84IEp99023784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Sep 2007 11:14:52 -0700 Received: from [76.102.94.28] (vpn-10-50-0-80.qualcomm.com [10.50.0.80]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l84IEldg024229; Tue, 4 Sep 2007 11:14:50 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <072901c7ef0c$f3965470$640fa8c0@cis.neustar.com> References: <46CAE441.8080504@gmx.net><46D1C942.7010501@gmx.net><46D264F9.6080101@soft armor.com><46DC67A0.60809@gmx.net><46DD06A4.2080000@gmx.net><5FB585F183235B42A9E 70095055136FB0555C4@DEMUEXC012.nsn-intra.net><5D1A7985295922448D5550C94DE2 918001636C13@DEEXC1U01.de.lucent.com> <06e501c7eef6$db68ea40$640fa8c0@cis.neustar.com> <5FB585F183235B42A9E70095055136FB150BDC@DEMUEXC012.nsn-intra.net> <2737DCC0-62F2-4633-843A-0AA770FB0648@cs.columbia.edu> <072901c7ef0c$f3965470$640fa8c0@cis.neustar.com> Date: Tue, 4 Sep 2007 11:14:46 -0700 To: "Brian Rosen" , "'Henning Schulzrinne'" , "'Tschofenig, Hannes \(NSN - DE/Germany - MiniMD\)'" From: Ted Hardie Subject: RE: AW: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by numenor.qualcomm.com id l84IEp99023784 X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 12:02 PM -0400 9/4/07, Brian Rosen wrote: >I thought about that. It gets a lot more complicated, but I imagine we >could make it work. It would end up using something like: >sip:fire+mytownpsap@provinceESRP.net > >A parameter could also be used. Everyone else would just pass it throug= h >from LoST server to the PSAP. Assuming you mean something like sip:mytownpsap@provinceESRP.net; service-urn=3Durn:service:sos.fire I like that better. If the parameter not present, the PSAP doesn't know = what service was used to route to it, but that's not really much worse than where we = are now.=20 It would still reach the right. I'm less happy about fire+mytownpsap@provinceESRP.net or even fire@overflowpsap.example, because I worry that someone may incorrectly construct the left hand side there and get rejected. In other words, if someone forget to include mountainrescue@neworleans.lousiana.ESRP.net in the local default maping, it might not get through the routing process= , where psap@neworleans.lousiana.ESRP.net; service-urn=3Durn:service:sos.mountain= -rescue would get through despite the bug.=20 Does that make sense? Ted >I'd really rather have an unambiguous marker. >I also think the logic in Jonathan's loose-route draft is pretty good. >Using the same idea in multiple environments is good. > >Brian > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Tuesday, September 04, 2007 11:48 AM >> To: Tschofenig, Hannes (NSN - DE/Germany - MiniMD) >> Cc: ext Brian Rosen; DRAGE, Keith (Keith); ECRIT >> Subject: Re: AW: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route- >> 01.txt >> >> While this is far from elegant, there is really no practical problem >> with having multiple URIs end up in the same place. In other words, >> each service URN can be mapped to different request URIs >> (fire@overflowpsap, ambulance@overflowpsap, ....) and still be >> answered by the same system or group of call takers. The user part >> has only local significance, after all, and N-to-1 URI mappings are >> quite common for other purposes. >> >> Henning >> >> On Sep 4, 2007, at 9:27 AM, Tschofenig, Hannes (NSN - DE/Germany - >> MiniMD) wrote: >> >> > I forgot that part. You are completely right, Brian. >> > >> > Ciao >> > Hannes >> > >> > >> >> -----Urspr=FCngliche Nachricht----- >> >> Von: ext Brian Rosen [mailto:br@brianrosen.net] >> >> Gesendet: Dienstag, 4. September 2007 15:24 >> >> An: 'DRAGE, Keith (Keith)'; 'ECRIT' >> >> Betreff: RE: [Ecrit] Re: [Sip] >> >> draft-rosenberg-sip-ua-loose-route-01.txt >> >> >> >>> .... Once we have reached the E-CSCF, is the original >> >> Request-URI (the >> >>> service URN) still important for any issue apart from >> >> special handling? >> >> Yes >> >> >> >> You need to know what service was requested, which may or may >> >> not be what >> >> PSAP it ended up on. This is especially true in disasters >> >> where regardless >> >> of what you asked for, the call may end up in some temporary >> >> call center. >> >> >> >> 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 > > >_______________________________________________ >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 Sep 04 14:35:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdDy-0007Ot-8F; Tue, 04 Sep 2007 14:34:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdDx-0007Oo-HK for ecrit@ietf.org; Tue, 04 Sep 2007 14:34:05 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISdDw-0008V3-8U for ecrit@ietf.org; Tue, 04 Sep 2007 14:34:05 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1ISdDk-0005JZ-Ks; Tue, 04 Sep 2007 13:33:52 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Henning Schulzrinne'" , "'Tschofenig, Hannes \(NSN - DE/Germany - MiniMD\)'" References: <46CAE441.8080504@gmx.net><46D1C942.7010501@gmx.net><46D264F9.6080101@soft armor.com><46DC67A0.60809@gmx.net><46DD06A4.2080000@gmx.net><5FB585F183235B42A9E 70095055136FB0555C4@DEMUEXC012.nsn-intra.net><5D1A7985295922448D5550C94DE2 918001636C13@DEEXC1U01.de.lucent.com> <06e501c7eef6$db68ea40$640fa8c0@cis.neustar.com> <5FB585F183235B42A9E70095055136FB150BDC@DEMUEXC012.nsn-intra.net> <2737DCC0-62F2-4633-843A-0AA770FB0648@cs.columbia.edu> <072901c7ef0c$f3965470$640fa8c0@cis.neustar.com> Subject: RE: AW: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Date: Tue, 4 Sep 2007 14:34:00 -0400 Message-ID: <076b01c7ef22$2b1743e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcfvH3zKii7a93VKR3uuiMbp40Y2/AAAkGCQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org You did interpret what I meant by parameter correct. All of this works because it is PSAP management that has to specify the contents of the LoST PSAP URI, so it can put in whatever it needs to "do = the right thing". I personally like the parameter better than mucking with = the user part of the sip URI. However, I like loose route better than that. It seems to do exactly = what is needed, and as far as all systems prior to the PSAP, it follows 3261. The PSAP could actually pop the route header when it chose the call = taker to get the call. Or not. Brian > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Tuesday, September 04, 2007 2:15 PM > To: Brian Rosen; 'Henning Schulzrinne'; 'Tschofenig, Hannes (NSN - > DE/Germany - MiniMD)' > Cc: 'ECRIT' > Subject: RE: AW: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route- > 01.txt >=20 > At 12:02 PM -0400 9/4/07, Brian Rosen wrote: > >I thought about that. It gets a lot more complicated, but I imagine = we > >could make it work. It would end up using something like: > >sip:fire+mytownpsap@provinceESRP.net > > > >A parameter could also be used. Everyone else would just pass it = through > >from LoST server to the PSAP. >=20 > Assuming you mean something like >=20 > sip:mytownpsap@provinceESRP.net; service-urn=3Durn:service:sos.fire >=20 > I like that better. If the parameter not present, the PSAP doesn't = know > what service > was used to route to it, but that's not really much worse than where = we > are now. > It would still reach the right. I'm less happy about > fire+mytownpsap@provinceESRP.net or even fire@overflowpsap.example, > because I worry that someone may incorrectly construct the left hand = side > there and get rejected. In other words, if someone forget to include >=20 > mountainrescue@neworleans.lousiana.ESRP.net >=20 > in the local default maping, it might not get through the routing = process, > where > psap@neworleans.lousiana.ESRP.net; = service-urn=3Durn:service:sos.mountain- > rescue > would get through despite the bug. >=20 > Does that make sense? > Ted >=20 >=20 > >I'd really rather have an unambiguous marker. > >I also think the logic in Jonathan's loose-route draft is pretty = good. > >Using the same idea in multiple environments is good. > > > >Brian > > > >> -----Original Message----- > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >> Sent: Tuesday, September 04, 2007 11:48 AM > >> To: Tschofenig, Hannes (NSN - DE/Germany - MiniMD) > >> Cc: ext Brian Rosen; DRAGE, Keith (Keith); ECRIT > >> Subject: Re: AW: [Ecrit] Re: [Sip] = draft-rosenberg-sip-ua-loose-route- > >> 01.txt > >> > >> While this is far from elegant, there is really no practical = problem > >> with having multiple URIs end up in the same place. In other words, > >> each service URN can be mapped to different request URIs > >> (fire@overflowpsap, ambulance@overflowpsap, ....) and still be > >> answered by the same system or group of call takers. The user part > >> has only local significance, after all, and N-to-1 URI mappings are > >> quite common for other purposes. > >> > >> Henning > >> > >> On Sep 4, 2007, at 9:27 AM, Tschofenig, Hannes (NSN - DE/Germany - > >> MiniMD) wrote: > >> > >> > I forgot that part. You are completely right, Brian. > >> > > >> > Ciao > >> > Hannes > >> > > >> > > >> >> -----Urspr=FCngliche Nachricht----- > >> >> Von: ext Brian Rosen [mailto:br@brianrosen.net] > >> >> Gesendet: Dienstag, 4. September 2007 15:24 > >> >> An: 'DRAGE, Keith (Keith)'; 'ECRIT' > >> >> Betreff: RE: [Ecrit] Re: [Sip] > >> >> draft-rosenberg-sip-ua-loose-route-01.txt > >> >> > >> >>> .... Once we have reached the E-CSCF, is the original > >> >> Request-URI (the > >> >>> service URN) still important for any issue apart from > >> >> special handling? > >> >> Yes > >> >> > >> >> You need to know what service was requested, which may or may > >> >> not be what > >> >> PSAP it ended up on. This is especially true in disasters > >> >> where regardless > >> >> of what you asked for, the call may end up in some temporary > >> >> call center. > >> >> > >> >> 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 > > > > > >_______________________________________________ > >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 Sep 04 14:36:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdEa-0007TK-Nc; Tue, 04 Sep 2007 14:34:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdEZ-0007TC-T0 for ecrit@ietf.org; Tue, 04 Sep 2007 14:34:43 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISdEZ-0008V8-0m for ecrit@ietf.org; Tue, 04 Sep 2007 14:34:43 -0400 Received: (qmail invoked by alias); 04 Sep 2007 18:34:41 -0000 Received: from p54986F96.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.111.150] by mail.gmx.net (mp035) with SMTP; 04 Sep 2007 20:34:41 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/SP/1f1LrSt3pemsH56IIX0t6e5xXn8zv1TPpiVx qB7PavPMP5Pdka Message-ID: <46DDA538.3060407@gmx.net> Date: Tue, 04 Sep 2007 20:34:32 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Richard Barnes Subject: Re: [Ecrit] Request URI in Phone BCP References: <46DC6762.2010706@gmx.net> <064f01c7ee9b$9669b4c0$640fa8c0@cis.neustar.com> <46DD7CE0.5090305@bbn.com> In-Reply-To: <46DD7CE0.5090305@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Have you look at this document? draft-polk-ecrit-local-emergency-rph-namespace-01.txt Richard Barnes wrote: > Maybe I'm being simplistic, but why are we conflating emergency > indication with routing? I realize that there's a need for emergency > call marking, but it seems abusive to use the Route header for that. > I think we need to find a header with a more appropriate semantic > (even To seems better, since that's the logical destination). If > there's not a header available that's has appropriate semantics and > isn't modifiable, then we should define a new header field for > emergency indication that MUST NOT be modified by any entity other > than the UAC. > > --Richard > > > > Brian Rosen wrote: >> I don't think that is right, and I think the loose route draft is >> correct. >> If you put the PSAP URI in the Request URI then you don't know it's an >> emergency call, and you don't know what service was requested. The >> service >> URN is the marker that the call is an emergency call. >> >> If you put the service URN in the Request URI, and the PSAP URI in a >> Route >> header, then the call will be routed to the PSAP correctly, and the >> Request >> URI will remain as the service URN. >> >> You can't depend on To:, although if the UA recognizes the dial >> string, then >> the To: would also have the service URN. If it did not detect the >> dialstring, the To: would have the dial string. >> >> If the UA did not do the LoST dip, then there would not be a Route >> header. >> This allows the first hop proxy to determine what it needs to do. >> >> Brian >> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: Monday, September 03, 2007 3:58 PM >>> To: ECRIT >>> Subject: [Ecrit] Request URI in Phone BCP >>> >>> There is a mistake in the Phone BCP in Section 6.1, bullet (1). Here is >>> the text: >>> >>> " >>> 1. The Request URI SHOULD be a PSAP URI obtained from LoST (see Section >>> 6.3). If the device cannot access a LoST server, the To: SHOULD be a >>> service URN in the "sos" tree. >>> " >>> >>> Instead of talking about the To in the second sentence it should say >>> Request URI. Here is the changed text: >>> >>> " >>> 1. The Request URI SHOULD be a PSAP URI obtained from LoST (see Section >>> 6.3). If the device cannot access a LoST server, the Request URI SHOULD >>> be a service URN in the "sos" tree. >>> " >>> >>> I believe that item (5) should be removed: >>> >>> " >>> 5. A Route header SHOULD be present with the service URN in the "sos" >>> tree, and the loose route parameter. >>> " >>> >>> The 3GPP IMS emergency service spec, TS 24.229, does not use it >>> either. >>> >>> Ciao >>> Hannes >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 04 15:09:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdkk-0000yj-6l; Tue, 04 Sep 2007 15:07:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdki-0000ul-RP for ecrit@ietf.org; Tue, 04 Sep 2007 15:07:56 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISdkh-0000by-99 for ecrit@ietf.org; Tue, 04 Sep 2007 15:07:56 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l84J7LTa019253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 4 Sep 2007 15:07:22 -0400 (EDT) In-Reply-To: <5D1A7985295922448D5550C94DE2918001636C13@DEEXC1U01.de.lucent.com> References: <46CAE441.8080504@gmx.net><46D1C942.7010501@gmx.net><46D264F9.6080101@softarmor.com><46DC67A0.60809@gmx.net><46DD06A4.2080000@gmx.net> <5FB585F183235B42A9E70095055136FB0555C4@DEMUEXC012.nsn-intra.net> <5D1A7985295922448D5550C94DE2918001636C13@DEEXC1U01.de.lucent.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <30940889-193E-47AF-B6D4-44856CE09B96@cs.columbia.edu> Content-Transfer-Encoding: quoted-printable From: Henning Schulzrinne Subject: Re: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Date: Tue, 4 Sep 2007 15:08:30 -0400 To: "DRAGE, Keith ((Keith))" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: -1.0 (-) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org As for Brian, my preferred solution is the loose-route proposal. If we want an explicit marking, I think an explicit header would be =20 clearest, as in Service: urn:service:sos.fire (I don't want this to be conflated with the service discussion in =20 SIP; this has nothing to do with what's been discussed there. I don't =20= care about the header label.) Resource priority is, in my opinion, not appropriate for marking the =20 service requested since such calls may not actually get resource =20 priority and since it is unlikely that fire calls will get a =20 different priority from police calls. Conversely, the RPH header is =20 dangerous outside carefully controlled environments, since it can be =20 a DOS tool. In particular, RPH requires strong client authentication, =20= which is generally not available in emergency calls. Within the =20 (trusted) ESN, this isn't a major problem, but letting end users or =20 VSPs set that header field is asking for trouble unless other =20 entities can verify that the call is indeed an emergency call. If =20 they can do that, then you don't need the header. Overloading headers just because they are available doesn't strike me =20= as architecturally appropriate. Henning On Sep 4, 2007, at 9:06 AM, DRAGE, Keith ((Keith)) wrote: > (Removing parties from the original list distribution) > > The situation in 3GPP is that we have so far failed to agree any =20 > marking or other carriage of other information (with a significant =20 > number of the objections coming from the organisation Christer =20 > works for), not that we have agreed we don't want one. > > I believe the appropriate way forward on marking for special =20 > handling is actually the Resource-Priority header solution =20 > identified by > > http://www.ietf.org/internet-drafts/draft-polk-ecrit-local-=20 > emergency-rph-namespace-01.txt > > In terms of special handling, this makes a lot of sense for those =20 > SIP entities that already have to implement RFC 4412 for other =20 > regulatory reasons. > > As already indicated, the 3GPP E-CSCF (the emergency routeing =20 > proxy) changes the Request-URI to the PSAP URI, and the original =20 > Reuqest-URI is lost. Once we have reached the E-CSCF, is the =20 > original Request-URI (the service URN) still important for any =20 > issue apart from special handling? > > Regards > > Keith > >> -----Original Message----- >> From: Tschofenig,Hannes (NSN - DE/Germany - MiniMD) >> [mailto:hannes.tschofenig@nsn.com] >> Sent: Tuesday, September 04, 2007 1:06 PM >> To: ext Christer Holmberg (JO/LMF); Hannes Tschofenig >> Cc: IETF SIP List; ECRIT; Dean Willis >> Subject: AW: [Ecrit] Re: [Sip] >> draft-rosenberg-sip-ua-loose-route-01.txt >> >> Hi Christer, >> >> Thanks for your quick response. >> Please find a few comments below: >> >>> -----Urspr=FCngliche Nachricht----- >>> Von: ext Christer Holmberg (JO/LMF) >>> [mailto:christer.holmberg@ericsson.com] >>> Gesendet: Dienstag, 4. September 2007 14:00 >>> An: Hannes Tschofenig >>> Cc: IETF SIP List; ECRIT; Dean Willis >>> Betreff: RE: [Ecrit] Re: [Sip] >>> draft-rosenberg-sip-ua-loose-route-01.txt >>> >>> >>> Hi, >>> >>>>> In 3GPP, it is true that the UE inserts the service URN into the >>> Request-URI. >>>>> >>>>> But, in the current specification the E-CSCF converts the >>> URN into a >>>>> routable PSAP address, i.e. the mechanism in the >>> loose-route draft is >>>>> not used. >>>>> >>>>> >>>> Why was this done? >>> >>> I don't have all the details, but one reason was that the same >>> procedures were wanted towards a PSAP and an MGCF, and at >> least in the >>> previous 3GPP releases the MGCF does the called party number mapping >>> based on the Request-URI value. >> >> You mean that the MGCF wouldn't know what todo with the Request URI. >> This sounds like a backwards compatibility aspect. >> >>> Also, since this was done a while ago, >>> the loose-route draft mechanism wasn't even discussed. >> That's probably true. >> >> Also, since >>> neither the PSAP or MGCF registers themselves to the E-CSCF, the >>> loose-route draft mechanism wouldn't be used towards those >>> entities even >>> if adopted by IMS. >> >> I don't think that the Request URI has anything todo with >> registrations. >> >>> >>>> Do you expect that the call uses a different emergency call marking >>> technique went it enters the PSAP operator network? >>> >>> I think it is up to each operator to decide how the marking is done. >> >> >> In the 3GPP model with the E-CSCF and the PSAP having a close >> relationship you could leave this issue open. It would, >> however, make their life easier. >> >>> There will always be agreements between the PSAP operators >>> and the other >>> ("public") operators using them. >> >> Only in the 3GPP IMS alike architecture. The IETF emergency >> services architecture is a bit different. >> >> I guess it would also be possible to >>> put the original service URN into the P-Called-Party-Id >> header (as for >>> normal calls), eventhough I don't think it's currently specified. >> >> I am not sure whether this is a good solution. >> >>> >>>> Do you expect that the call is directly sent from the E-CSCF to the >>> PSAP and that there are no other hops in between? >>> >>> I think both cases are applicable. >> When you have intermediate entities that need to recognize >> emergency calls and need to treat the call differently then >> you might want to define the procedures since otherwise there >> is a chance that things don't work as expected. >> >> Ciao >> Hannes >> >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>>>>> -----Original Message----- >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>> Sent: 3. syyskuuta 2007 22:59 >>>>>> To: Dean Willis >>>>>> Cc: IETF SIP List; ECRIT >>>>>> Subject: Re: [Ecrit] Re: [Sip] >>>>>> draft-rosenberg-sip-ua-loose-route-01.txt >>>>>> >>>>>> Hi Dean, >>>>>> >>>>>> in ECRIT we assumed that the Request URI contains the >>>> service URN. We >>>>>> put that stuff into the Phone BCP document (which >>>> unfortunately still >>>>>> contains an error I just noticed). >>>>>> That's what we told the 3GPP in the past as well. Hence, >>>> they wrote >>>>>> it in their specs. See TS 24.229, Section 5.1.6.8.3, >> bullet (1). >>>>>> >>>>>> Within the ECRIT group we weren't aware that this issue >>>> has not been >>>>>> decided and hence we are a bit concerned about the >> recent change >>>>>> given that other SDOs followed our suggestion already. >>>>>> >>>>>> Do you have an idea what we should do now? >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> >>>>>> Dean Willis wrote: >>>>>> >>>>>>> Hannes Tschofenig wrote: >>>>>>> >>>>>>>> No response received -- resend. >>>>>>>> >>>>>>>> Hannes Tschofenig wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Dear SIP WG members, >>>>>>>>> >>>>>>>>> during the ECRIT meeting we learned that the SIP >>> working group >>>>>>>>> "rejected" the concept described in >>>>>>>>> draft-rosenberg-sip-ua-loose-route-01.txt. >>>>>>>>> >>>>>>>>> Could someone please give us more information about this >>>>>>>>> >>>>>> decision as >>>>>> >>>>>>>>> it impacts the work we do in ECRIT? >>>>>>>>> >>>>>>> I wouldn't say that UA Loose Route was "rejected" so much >>>>>>> >>>>>> as "does not >>>>>> >>>>>>> yet have consensus". >>>>>>> >>>>>>> This is in part influenced by "WG doesn't seem to have a >>>> compelling >>>>>>> reason to make such a significant change." >>>>>>> >>>>>>> Perhaps ECRIT has a compelling reason? >>>>>>> >>>>>>> -- >>>>>>> Dean >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>>> This list is for NEW development of the core SIP Protocol Use >>>>>> sip-implementors@cs.columbia.edu for questions on >>> current sip Use >>>>>> sipping@ietf.org for new developments on the application of sip >>>>>> >>>>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ > 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 Sep 04 15:15:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdqF-0006zv-CZ; Tue, 04 Sep 2007 15:13:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdqC-0006zX-GI; Tue, 04 Sep 2007 15:13:36 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISdqB-0000i8-7p; Tue, 04 Sep 2007 15:13:36 -0400 Received: from [192.168.2.101] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id l84JDUQs027716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 4 Sep 2007 14:13:32 -0500 In-Reply-To: <46DC67A0.60809@gmx.net> References: <46CAE441.8080504@gmx.net> <46D1C942.7010501@gmx.net> <46D264F9.6080101@softarmor.com> <46DC67A0.60809@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <50E0593E-BCE3-4725-A85B-49A6F5F37900@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Date: Tue, 4 Sep 2007 14:13:21 -0500 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: IETF SIP List , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Sep 3, 2007, at 2:59 PM, Hannes Tschofenig wrote: > Hi Dean, > > in ECRIT we assumed that the Request URI contains the service URN. > We put that stuff into the Phone BCP document (which unfortunately > still contains an error I just noticed). > That's what we told the 3GPP in the past as well. Hence, they wrote > it in their specs. See TS 24.229, Section 5.1.6.8.3, bullet (1). > > Within the ECRIT group we weren't aware that this issue has not > been decided and hence we are a bit concerned about the recent > change given that other SDOs followed our suggestion already. > > Do you have an idea what we should do now? Tell them not to translate the emergency service URN into something that doesn't preserve the requisite information? In IMS that should be easy, even if the CSCF is translating into a routable PSAP entry. In the broader IETF case, I suspect it means "NEVER retarget a request URI that contains a service URN unless you're the terminating PSAP's proxy, and then do so very carefully." -- Dean _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 04 15:23:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdy5-0008G2-CB; Tue, 04 Sep 2007 15:21:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISdxu-0008AF-ID for ecrit@ietf.org; Tue, 04 Sep 2007 15:21:35 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISdxt-0001wq-7O for ecrit@ietf.org; Tue, 04 Sep 2007 15:21:34 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1ISdxg-0004Av-My; Tue, 04 Sep 2007 14:21:21 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'DRAGE, Keith \(\(Keith\)\)'" References: <46CAE441.8080504@gmx.net><46D1C942.7010501@gmx.net><46D264F9.6080101@softarmor.com><46DC67A0.60809@gmx.net><46DD06A4.2080000@gmx.net><5FB585F183235B42A9E70095055136FB0555C4@DEMUEXC012.nsn-intra.net><5D1A7985295922448D5550C94DE2918001636C13@DEEXC1U01.de.lucent.com> <30940889-193E-47AF-B6D4-44856CE09B96@cs.columbia.edu> Subject: RE: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Date: Tue, 4 Sep 2007 15:21:28 -0400 Message-ID: <077c01c7ef28$ccf4bcf0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <30940889-193E-47AF-B6D4-44856CE09B96@cs.columbia.edu> Thread-Index: AcfvJyXIScix1Ux9TRqMKoBZxGQYlAAAKugw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Agree We may end up trying to use RPH within a public network, but I don't = think it can do a whole lot for the reasons Henning gives. It's more likely = to be of value in the emergency services IP networks. I look at RPH exactly as its name suggests: a RESOURCE priority header; = it specifies how the individual entities treat the call with respect to resources they manage. It's analogous, to me, with a DiffServ code = point, which specifies how routers treat the underlying packet streams with = respect to the resources they manage. The Service URN specifies the service that was requested, independent of = any resources that may be needed. I'm particularly concerned that the endpoint not have yet one more = mechanism it has to implement. We're asking they implement the Service URN. I'd rather not MUST them into RPH. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, September 04, 2007 3:09 PM > To: DRAGE, Keith ((Keith)) > Cc: ECRIT > Subject: Re: [Ecrit] Re: [Sip] = draft-rosenberg-sip-ua-loose-route-01.txt >=20 > As for Brian, my preferred solution is the loose-route proposal. >=20 > If we want an explicit marking, I think an explicit header would be > clearest, as in >=20 > Service: urn:service:sos.fire >=20 > (I don't want this to be conflated with the service discussion in > SIP; this has nothing to do with what's been discussed there. I don't > care about the header label.) >=20 > Resource priority is, in my opinion, not appropriate for marking the > service requested since such calls may not actually get resource > priority and since it is unlikely that fire calls will get a > different priority from police calls. Conversely, the RPH header is > dangerous outside carefully controlled environments, since it can be > a DOS tool. In particular, RPH requires strong client authentication, > which is generally not available in emergency calls. Within the > (trusted) ESN, this isn't a major problem, but letting end users or > VSPs set that header field is asking for trouble unless other > entities can verify that the call is indeed an emergency call. If > they can do that, then you don't need the header. >=20 > Overloading headers just because they are available doesn't strike me > as architecturally appropriate. >=20 > Henning >=20 > On Sep 4, 2007, at 9:06 AM, DRAGE, Keith ((Keith)) wrote: >=20 > > (Removing parties from the original list distribution) > > > > The situation in 3GPP is that we have so far failed to agree any > > marking or other carriage of other information (with a significant > > number of the objections coming from the organisation Christer > > works for), not that we have agreed we don't want one. > > > > I believe the appropriate way forward on marking for special > > handling is actually the Resource-Priority header solution > > identified by > > > > http://www.ietf.org/internet-drafts/draft-polk-ecrit-local- > > emergency-rph-namespace-01.txt > > > > In terms of special handling, this makes a lot of sense for those > > SIP entities that already have to implement RFC 4412 for other > > regulatory reasons. > > > > As already indicated, the 3GPP E-CSCF (the emergency routeing > > proxy) changes the Request-URI to the PSAP URI, and the original > > Reuqest-URI is lost. Once we have reached the E-CSCF, is the > > original Request-URI (the service URN) still important for any > > issue apart from special handling? > > > > Regards > > > > Keith > > > >> -----Original Message----- > >> From: Tschofenig,Hannes (NSN - DE/Germany - MiniMD) > >> [mailto:hannes.tschofenig@nsn.com] > >> Sent: Tuesday, September 04, 2007 1:06 PM > >> To: ext Christer Holmberg (JO/LMF); Hannes Tschofenig > >> Cc: IETF SIP List; ECRIT; Dean Willis > >> Subject: AW: [Ecrit] Re: [Sip] > >> draft-rosenberg-sip-ua-loose-route-01.txt > >> > >> Hi Christer, > >> > >> Thanks for your quick response. > >> Please find a few comments below: > >> > >>> -----Urspr=FCngliche Nachricht----- > >>> Von: ext Christer Holmberg (JO/LMF) > >>> [mailto:christer.holmberg@ericsson.com] > >>> Gesendet: Dienstag, 4. September 2007 14:00 > >>> An: Hannes Tschofenig > >>> Cc: IETF SIP List; ECRIT; Dean Willis > >>> Betreff: RE: [Ecrit] Re: [Sip] > >>> draft-rosenberg-sip-ua-loose-route-01.txt > >>> > >>> > >>> Hi, > >>> > >>>>> In 3GPP, it is true that the UE inserts the service URN into the > >>> Request-URI. > >>>>> > >>>>> But, in the current specification the E-CSCF converts the > >>> URN into a > >>>>> routable PSAP address, i.e. the mechanism in the > >>> loose-route draft is > >>>>> not used. > >>>>> > >>>>> > >>>> Why was this done? > >>> > >>> I don't have all the details, but one reason was that the same > >>> procedures were wanted towards a PSAP and an MGCF, and at > >> least in the > >>> previous 3GPP releases the MGCF does the called party number = mapping > >>> based on the Request-URI value. > >> > >> You mean that the MGCF wouldn't know what todo with the Request = URI. > >> This sounds like a backwards compatibility aspect. > >> > >>> Also, since this was done a while ago, > >>> the loose-route draft mechanism wasn't even discussed. > >> That's probably true. > >> > >> Also, since > >>> neither the PSAP or MGCF registers themselves to the E-CSCF, the > >>> loose-route draft mechanism wouldn't be used towards those > >>> entities even > >>> if adopted by IMS. > >> > >> I don't think that the Request URI has anything todo with > >> registrations. > >> > >>> > >>>> Do you expect that the call uses a different emergency call = marking > >>> technique went it enters the PSAP operator network? > >>> > >>> I think it is up to each operator to decide how the marking is = done. > >> > >> > >> In the 3GPP model with the E-CSCF and the PSAP having a close > >> relationship you could leave this issue open. It would, > >> however, make their life easier. > >> > >>> There will always be agreements between the PSAP operators > >>> and the other > >>> ("public") operators using them. > >> > >> Only in the 3GPP IMS alike architecture. The IETF emergency > >> services architecture is a bit different. > >> > >> I guess it would also be possible to > >>> put the original service URN into the P-Called-Party-Id > >> header (as for > >>> normal calls), eventhough I don't think it's currently specified. > >> > >> I am not sure whether this is a good solution. > >> > >>> > >>>> Do you expect that the call is directly sent from the E-CSCF to = the > >>> PSAP and that there are no other hops in between? > >>> > >>> I think both cases are applicable. > >> When you have intermediate entities that need to recognize > >> emergency calls and need to treat the call differently then > >> you might want to define the procedures since otherwise there > >> is a chance that things don't work as expected. > >> > >> Ciao > >> Hannes > >> > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> > >>> > >>> > >>>>>> -----Original Message----- > >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>>> Sent: 3. syyskuuta 2007 22:59 > >>>>>> To: Dean Willis > >>>>>> Cc: IETF SIP List; ECRIT > >>>>>> Subject: Re: [Ecrit] Re: [Sip] > >>>>>> draft-rosenberg-sip-ua-loose-route-01.txt > >>>>>> > >>>>>> Hi Dean, > >>>>>> > >>>>>> in ECRIT we assumed that the Request URI contains the > >>>> service URN. We > >>>>>> put that stuff into the Phone BCP document (which > >>>> unfortunately still > >>>>>> contains an error I just noticed). > >>>>>> That's what we told the 3GPP in the past as well. Hence, > >>>> they wrote > >>>>>> it in their specs. See TS 24.229, Section 5.1.6.8.3, > >> bullet (1). > >>>>>> > >>>>>> Within the ECRIT group we weren't aware that this issue > >>>> has not been > >>>>>> decided and hence we are a bit concerned about the > >> recent change > >>>>>> given that other SDOs followed our suggestion already. > >>>>>> > >>>>>> Do you have an idea what we should do now? > >>>>>> > >>>>>> Ciao > >>>>>> Hannes > >>>>>> > >>>>>> > >>>>>> Dean Willis wrote: > >>>>>> > >>>>>>> Hannes Tschofenig wrote: > >>>>>>> > >>>>>>>> No response received -- resend. > >>>>>>>> > >>>>>>>> Hannes Tschofenig wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> Dear SIP WG members, > >>>>>>>>> > >>>>>>>>> during the ECRIT meeting we learned that the SIP > >>> working group > >>>>>>>>> "rejected" the concept described in > >>>>>>>>> draft-rosenberg-sip-ua-loose-route-01.txt. > >>>>>>>>> > >>>>>>>>> Could someone please give us more information about this > >>>>>>>>> > >>>>>> decision as > >>>>>> > >>>>>>>>> it impacts the work we do in ECRIT? > >>>>>>>>> > >>>>>>> I wouldn't say that UA Loose Route was "rejected" so much > >>>>>>> > >>>>>> as "does not > >>>>>> > >>>>>>> yet have consensus". > >>>>>>> > >>>>>>> This is in part influenced by "WG doesn't seem to have a > >>>> compelling > >>>>>>> reason to make such a significant change." > >>>>>>> > >>>>>>> Perhaps ECRIT has a compelling reason? > >>>>>>> > >>>>>>> -- > >>>>>>> Dean > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>>>>> This list is for NEW development of the core SIP Protocol Use > >>>>>> sip-implementors@cs.columbia.edu for questions on > >>> current sip Use > >>>>>> sipping@ietf.org for new developments on the application of sip > >>>>>> > >>>>>> > >>>> > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol > >>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>> Use sipping@ietf.org for new developments on the application of = sip > >>> > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 04 16:02:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISeZZ-0008L3-26; Tue, 04 Sep 2007 16:00:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISeZY-0008Ko-63 for ecrit@ietf.org; Tue, 04 Sep 2007 16:00:28 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISeZX-0003DG-DQ for ecrit@ietf.org; Tue, 04 Sep 2007 16:00:27 -0400 Received: (qmail invoked by alias); 04 Sep 2007 20:00:26 -0000 Received: from p549846DC.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.70.220] by mail.gmx.net (mp028) with SMTP; 04 Sep 2007 22:00:26 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/YBtUHgUzYFr07Jj/XNZmKVZXyu6T6DmPs1oZGQE g6Or3BP4abOW9E Message-ID: <46DDB951.9010007@gmx.net> Date: Tue, 04 Sep 2007 22:00:17 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) 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: e8a67952aa972b528dd04570d58ad8fe Subject: [Ecrit] Service URN X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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, after a chat with Brian and here a short summary of what we discussed: (I hope I captured it correctly.) == End Host Procedures == * UA does not recognize the emergency call. To: Dial String Request URI: Dial String No Route header * UA runs LoST and determines the PSAP URI: Request URI: Service URN To: Service URN Route Header: PSAP URI * UA does not run LoST but recognizes the emergency call. Request URI: Service URN To: Service URN No Route header == Proxy Procedures == * Incoming request contains Service URN; Proxy runs LoST and determines the PSAP URI --- Input: Request URI: Service URN To: Service URN No Route header --- Output: Request URI: Service URN To: Service URN Route Header: PSAP URI * Incoming request contains Dial String; UA runs LoST and determines the PSAP URI: --- Input: Request URI: Dial String To: Dial String No Route header --- Output: Request URI: Service URN To: Service URN Route Header: PSAP URI Please check whether this is correct. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 04 17:18:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISfl5-0000RX-A2; Tue, 04 Sep 2007 17:16:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISfl2-0000NP-Gc for ecrit@ietf.org; Tue, 04 Sep 2007 17:16:25 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISfl1-0005Sw-1g for ecrit@ietf.org; Tue, 04 Sep 2007 17:16:24 -0400 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 l84LGLjc030604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 4 Sep 2007 14:16:22 -0700 Received: from [76.102.94.28] (vpn-10-50-0-80.qualcomm.com [10.50.0.80]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l84LGJMU005361 for ; Tue, 4 Sep 2007 14:16:21 -0700 Mime-Version: 1.0 Message-Id: Date: Tue, 4 Sep 2007 14:16:18 -0700 To: ecrit@ietf.org From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -3.6 (---) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ecrit] About that 911 button... X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org http://news.vzw.com/news/2007/09/pr2007-09-04a.html augmented with 3 "in case of emergency buttons", and a dedicated 911 key right above the power button. http://news.vzw.com/images/releases/Coupe-CDM-8630OpenH4Web.jpg It got a Goodhouskeeping Seal, too. Note that despite saying that it had color coded keys for specific functions, the 911 key is not color coded. By any chance has anyone checked the UI on this, to see if there is a "confirm"? Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 05 02:31:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISoOT-0007JY-QS; Wed, 05 Sep 2007 02:29:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISoOS-0007JT-EE for ecrit@ietf.org; Wed, 05 Sep 2007 02:29:40 -0400 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 1ISoOR-0001aX-Pm for ecrit@ietf.org; Wed, 05 Sep 2007 02:29:40 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 04 Sep 2007 23:29:39 -0700 X-IronPort-AV: i="4.20,209,1186383600"; d="scan'208"; a="520544094:sNHT56658492" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l856TdfC012903; Tue, 4 Sep 2007 23:29:39 -0700 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 l856TcM3016620; Wed, 5 Sep 2007 06:29:38 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 23:29:38 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.147.230]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Sep 2007 23:29:38 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 05 Sep 2007 01:29:27 -0500 To: Henning Schulzrinne , "DRAGE, Keith ((Keith))" From: "James M. Polk" Subject: Re: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt In-Reply-To: <30940889-193E-47AF-B6D4-44856CE09B96@cs.columbia.edu> References: <46CAE441.8080504@gmx.net> <46D1C942.7010501@gmx.net> <46D264F9.6080101@softarmor.com> <46DC67A0.60809@gmx.net> <46DD06A4.2080000@gmx.net> <5FB585F183235B42A9E70095055136FB0555C4@DEMUEXC012.nsn-intra.net> <5D1A7985295922448D5550C94DE2918001636C13@DEEXC1U01.de.lucent.com> <30940889-193E-47AF-B6D4-44856CE09B96@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 05 Sep 2007 06:29:38.0465 (UTC) FILETIME=[225EE910:01C7EF86] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3273; t=1188973779; x=1189837779; c=relaxed/simple; s=sjdkim4002; 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]=20Re=3A=20[Sip]=20draft-rosenberg-sip-ua-loos e-route-01.txt |Sender:=20; bh=GS5TBKJqPhzexJ0J8pMd0oTC5fIbnLepjhiIocZJUy4=; b=dhmOw48ERguMaeGAW9Rm5ti20m61yV9Ggg7XrfsLLZrmFoWLltVgY6DAnirw4TEPerXA4cpx XZjQb1YuY6t06Ft02nAG/2rTQClu/xOTKNGhg369RBqVmi3ElLraQrBs; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I believe I agree that the RPH shouldn't be relied upon as the (or the only) enduring indication a call is an emergency call. I think the sos RPH namespace should be used within emergency networks for resource treatment. draft-polk-ecrit-local-emergency-rph-namespace-01.txt talks about this. I also think it should be up to the arrangements between the emergency network to and a service provider, say one with an IMS architecture, to establish trust to a particular server, perhaps each E-CSCF within that provider's network, to appropriate PSAPs. In this scenario, which should be possible, but not necessarily pushed at this time, the *-CSCF can add the sos RPH to an emergency SIP request. The SP would be taking on the charge of making sure the RPH wouldn't cause harm within their network to the emergency services network. At 02:08 PM 9/4/2007, Henning Schulzrinne wrote: >As for Brian, my preferred solution is the loose-route proposal. > >If we want an explicit marking, I think an explicit header would be >clearest, as in > >Service: urn:service:sos.fire > >(I don't want this to be conflated with the service discussion in >SIP; this has nothing to do with what's been discussed there. I don't >care about the header label.) > >Resource priority is, in my opinion, not appropriate for marking the >service requested since such calls may not actually get resource >priority and since it is unlikely that fire calls will get a >different priority from police calls. Conversely, the RPH header is >dangerous outside carefully controlled environments, since it can be >a DOS tool. In particular, RPH requires strong client authentication, >which is generally not available in emergency calls. Within the >(trusted) ESN, this isn't a major problem, but letting end users or >VSPs set that header field is asking for trouble unless other >entities can verify that the call is indeed an emergency call. If >they can do that, then you don't need the header. > >Overloading headers just because they are available doesn't strike me >as architecturally appropriate. > >Henning > >On Sep 4, 2007, at 9:06 AM, DRAGE, Keith ((Keith)) wrote: > >>(Removing parties from the original list distribution) >> >>The situation in 3GPP is that we have so far failed to agree any >>marking or other carriage of other information (with a significant >>number of the objections coming from the organisation Christer >>works for), not that we have agreed we don't want one. >> >>I believe the appropriate way forward on marking for special >>handling is actually the Resource-Priority header solution >>identified by >> >>http://www.ietf.org/internet-drafts/draft-polk-ecrit-local- >>emergency-rph-namespace-01.txt >> >>In terms of special handling, this makes a lot of sense for those >>SIP entities that already have to implement RFC 4412 for other >>regulatory reasons. >> >>As already indicated, the 3GPP E-CSCF (the emergency routeing >>proxy) changes the Request-URI to the PSAP URI, and the original >>Reuqest-URI is lost. Once we have reached the E-CSCF, is the >>original Request-URI (the service URN) still important for any >>issue apart from special handling? >> >>Regards >> >>Keith _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 05 04:49:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISqXb-0001uw-Oi; Wed, 05 Sep 2007 04:47:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISqXa-0001uo-Og for ecrit@ietf.org; Wed, 05 Sep 2007 04:47:14 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ISqXa-0005x4-A0 for ecrit@ietf.org; Wed, 05 Sep 2007 04:47:14 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id l858kL0e024698Wed, 5 Sep 2007 08:46:21 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1ISqWj-000MbA-00; Wed, 05 Sep 2007 09:46:21 +0100 Date: Wed, 5 Sep 2007 09:46:21 +0100 From: "Clive D.W. Feather" To: Brian Rosen Subject: Re: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Message-ID: <20070905084620.GC80605@finch-staff-1.thus.net> References: <5D1A7985295922448D5550C94DE2918001636C13@DEEXC1U01.de.lucent.com> <06e501c7eef6$db68ea40$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06e501c7eef6$db68ea40$640fa8c0@cis.neustar.com> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian Rosen said: >> .... Once we have reached the E-CSCF, is the original Request-URI (the >> service URN) still important for any issue apart from special handling? > > You need to know what service was requested, which may or may not be what > PSAP it ended up on. This is especially true in disasters where regardless > of what you asked for, the call may end up in some temporary call center. Furthermore, no matter whether or not everything else handles it correctly, it strikes me as a really bad idea to throw away information like this. Even if the original Request-URI ends up in a Original-Emergency-Request-URI header that we have to invent, let's not throw away data that could be a matter of life and death (literally). -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 05 08:50:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISuJa-00059r-CH; Wed, 05 Sep 2007 08:49:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISuJY-00057e-Fy for ecrit@ietf.org; Wed, 05 Sep 2007 08:49:00 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISuJX-0002I1-3E for ecrit@ietf.org; Wed, 05 Sep 2007 08:49:00 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E6420213F1 for ; Wed, 5 Sep 2007 14:47:05 +0200 (CEST) X-AuditID: c1b4fb3e-b1036bb0000007e1-68-46dea549cb09 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 96D182145A for ; Wed, 5 Sep 2007 14:47:05 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Sep 2007 14:47:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Date: Wed, 5 Sep 2007 14:46:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Thread-Index: Acfvutm2tJc2xRZNTy+TFd+p3fHQPw== From: "Christer Holmberg (JO/LMF)" To: "ECRIT" X-OriginalArrivalTime: 05 Sep 2007 12:47:05.0159 (UTC) FILETIME=[DCDA2D70:01C7EFBA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org >>.... Once we have reached the E-CSCF, is the original Request-URI (the >>service URN) still important for any issue apart from special handling?=20 >> >You need to know what service was requested, which may or may not be what=20 >PSAP it ended up on. This is especially true in disasters where regardless=20 >of what you asked for, the call may end up in some temporary call center.=20 >Furthermore, no matter whether or not everything else handles it correctly,=20 >it strikes me as a really bad idea to throw away information like this. >Even if the original Request-URI ends up in a Original-Emergency-Request-URI=20 >header that we have to invent, let's not throw away data that could be a=20 >matter of life and death (literally).=20 There is no need to invent a new header - you can use P-Called-Party-Id. Regards, Christer _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 05 09:05:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISuY9-0000re-Im; Wed, 05 Sep 2007 09:04:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISuY8-0000ot-0e for ecrit@ietf.org; Wed, 05 Sep 2007 09:04:04 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISuY6-0002nm-Pa for ecrit@ietf.org; Wed, 05 Sep 2007 09:04:03 -0400 Received: from [24.154.127.115] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1ISuXw-0007oL-AL; Wed, 05 Sep 2007 08:03:52 -0500 From: "Brian Rosen" To: "'Christer Holmberg \(JO/LMF\)'" , "'ECRIT'" References: Subject: RE: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Date: Wed, 5 Sep 2007 09:03:57 -0400 Message-ID: <094b01c7efbd$39b43fc0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Acfvutm2tJc2xRZNTy+TFd+p3fHQPwAAaO/Q X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 Note that we would have to write a new RFC to do this, as 3455 defines P-Called-Party-Id as inserted by a proxy by copying the Request-URI. For an endpoint that did LoST dips, this would not work. It would work with an endpoint that did dial string resolution, but not LoST dip. I recognize that this is the current IMS direction. It would not work with an endpoint that did not do dial string resolution. Using loose route does not even need Jonathan's draft; we can just BCP it into the PSAP (i.e. the service URN gets you to the PSAP, the PSAP can pop the route header). It works with all variations, as described by Hannes and I. Brian > -----Original Message----- > From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, September 05, 2007 8:47 AM > To: ECRIT > Subject: Re: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt > > > >>.... Once we have reached the E-CSCF, is the original Request-URI (the > > >>service URN) still important for any issue apart from special > handling? > >> > >You need to know what service was requested, which may or may not be > what > >PSAP it ended up on. This is especially true in disasters where > regardless > >of what you asked for, the call may end up in some temporary call > center. > >Furthermore, no matter whether or not everything else handles it > correctly, > >it strikes me as a really bad idea to throw away information like this. > > >Even if the original Request-URI ends up in a > Original-Emergency-Request-URI > >header that we have to invent, let's not throw away data that could be > a > >matter of life and death (literally). > > There is no need to invent a new header - you can use P-Called-Party-Id. > > Regards, > > Christer > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 05 11:32:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISwq6-00048y-T3; Wed, 05 Sep 2007 11:30:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISwq4-00048p-PV for ecrit@ietf.org; Wed, 05 Sep 2007 11:30:45 -0400 Received: from mu-out-0910.google.com ([209.85.134.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISwq3-0006LV-HN for ecrit@ietf.org; Wed, 05 Sep 2007 11:30:44 -0400 Received: by mu-out-0910.google.com with SMTP id w8so2626262mue for ; Wed, 05 Sep 2007 08:30:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=e2eycLTSvUsEvslDIKKNTc7tCMxSf2FrJ9Vdb6IFFDKDAh5o91cSK7dkCHhYHvTn7+6ZSy4RGNBO+G+FpeDmspV8J7p9j0NErw7GwATf3d/5MO448f+RuJ03NHLVzplKVhfkDWkiz8RLsPrHpczMHYyuh3BYytJnKC+A6Z5dslo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=i3qt1JmiNFo/uZUClICPfn5CLablwxyVYCfNPSmvWzSnSYBLaBJ7ev8QJM89feDyiiBCSD2RGJtikH0akRT91Q3idABNKDjv+kQZa8mKsDHSWfPG/lfI/F4O5bWkSOB2+JAEZJx2G59/A/LiO3+BCx2qqRejjqx9xaEKRVMiJ7g= Received: by 10.82.156.12 with SMTP id d12mr9231351bue.1189006242228; Wed, 05 Sep 2007 08:30:42 -0700 (PDT) Received: by 10.82.108.10 with HTTP; Wed, 5 Sep 2007 08:30:42 -0700 (PDT) Message-ID: <317ceda50709050830k42d524e5rdacdb5f3cd49e86e@mail.gmail.com> Date: Wed, 5 Sep 2007 23:30:42 +0800 From: "Peili Xu" To: "Hannes Tschofenig" Subject: Re: [Ecrit] Service URN In-Reply-To: <46DDB951.9010007@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46DDB951.9010007@gmx.net> X-Google-Sender-Auth: 443c054217e80885 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org good summary, comments in-line 2007/9/5, Hannes Tschofenig : > Hi all, > > after a chat with Brian and here a short summary of what we discussed: > (I hope I captured it correctly.) > > == End Host Procedures == > > * UA does not recognize the emergency call. > > To: Dial String > Request URI: Dial String > No Route header > > * UA runs LoST and determines the PSAP URI: > > Request URI: Service URN > To: Service URN > Route Header: PSAP URI This case means the UA recognizes the emergency call, right? > > * UA does not run LoST but recognizes the emergency call. > > Request URI: Service URN > To: Service URN > No Route header > > > == Proxy Procedures == > > * Incoming request contains Service URN; Proxy runs LoST and determines > the PSAP URI > > --- Input: > > Request URI: Service URN > To: Service URN > No Route header > > --- Output: > > Request URI: Service URN > To: Service URN > Route Header: PSAP URI > > * Incoming request contains Dial String; UA runs LoST and determines the > PSAP URI: I guess you actually want to say Proxy in the above sentence. > > --- Input: > > Request URI: Dial String > To: Dial String > No Route header > > --- Output: > > Request URI: Service URN > To: Service URN > Route Header: PSAP URI > > Please check whether this is correct. > > Ciao > Hannes > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 05 11:50:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISx7m-0000LI-AS; Wed, 05 Sep 2007 11:49:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISx7l-0000LC-E8 for ecrit@ietf.org; Wed, 05 Sep 2007 11:49:01 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ISx7k-0000el-Mi for ecrit@ietf.org; Wed, 05 Sep 2007 11:49:01 -0400 Received: (qmail invoked by alias); 05 Sep 2007 15:48:59 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp023) with SMTP; 05 Sep 2007 17:48:59 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/8IKwvBr38aEijFqEGSmbldKzUv1pafZ4mQuUBsQ /nkQWh57Ry4JqY Message-ID: <46DECFE1.3040904@gmx.net> Date: Wed, 05 Sep 2007 17:48:49 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Peili Xu Subject: Re: [Ecrit] Service URN References: <46DDB951.9010007@gmx.net> <317ceda50709050830k42d524e5rdacdb5f3cd49e86e@mail.gmail.com> In-Reply-To: <317ceda50709050830k42d524e5rdacdb5f3cd49e86e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Peili Xu wrote: > good summary, comments in-line > > 2007/9/5, Hannes Tschofenig : > >> Hi all, >> >> after a chat with Brian and here a short summary of what we discussed: >> (I hope I captured it correctly.) >> >> == End Host Procedures == >> >> * UA does not recognize the emergency call. >> >> To: Dial String >> Request URI: Dial String >> No Route header >> >> * UA runs LoST and determines the PSAP URI: >> >> Request URI: Service URN >> To: Service URN >> Route Header: PSAP URI >> > > This case means the UA recognizes the emergency call, right? > > Yes. You cannot start LoST when you don't recognize the emergency call. >> * UA does not run LoST but recognizes the emergency call. >> >> Request URI: Service URN >> To: Service URN >> No Route header >> >> >> == Proxy Procedures == >> >> * Incoming request contains Service URN; Proxy runs LoST and determines >> the PSAP URI >> >> --- Input: >> >> Request URI: Service URN >> To: Service URN >> No Route header >> >> --- Output: >> >> Request URI: Service URN >> To: Service URN >> Route Header: PSAP URI >> >> > > >> * Incoming request contains Dial String; UA runs LoST and determines the >> PSAP URI: >> > > I guess you actually want to say Proxy in the above sentence. > > Correct. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 05 14:56:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT01C-0004Ze-21; Wed, 05 Sep 2007 14:54:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT01A-0004ZX-Gz for ecrit@ietf.org; Wed, 05 Sep 2007 14:54:24 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IT018-0002sn-S5 for ecrit@ietf.org; Wed, 05 Sep 2007 14:54:24 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IT00w-00087L-Sb; Wed, 05 Sep 2007 13:54:11 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , References: Subject: RE: [Ecrit] About that 911 button... Date: Wed, 5 Sep 2007 14:54:17 -0400 Message-ID: <09c501c7efee$2bf9e200$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcfvORi0eQfdG/BVRB+2p+MyLXQyiQAtJf5A X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.4 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I talked to the Verizon 9-1-1 folks. First of all, they weren't aware of this phone. The marketing guys don't ask them about features like this. Then, it actually takes two key presses: you have to press the 911 key and then press send. It also is a clamshell design, which means that it is harder to have the keys get pressed automatically in a pocket or purse. In my opinion, it's still a bad design, and likely there will be many more false emergency calls with this phone than any other phone in the Verizon line-up. Brian > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Tuesday, September 04, 2007 5:16 PM > To: ecrit@ietf.org > Subject: [Ecrit] About that 911 button... > > http://news.vzw.com/news/2007/09/pr2007-09-04a.html > > augmented with 3 "in case of emergency buttons", and > a dedicated 911 key right above the power button. > > http://news.vzw.com/images/releases/Coupe-CDM-8630OpenH4Web.jpg > > It got a Goodhouskeeping Seal, too. Note that despite saying that > it had color coded keys for specific functions, the 911 key is > not color coded. > > By any chance has anyone checked the UI on this, to see if there > is a "confirm"? > > Ted > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 05 15:21:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT0Pk-0004rB-67; Wed, 05 Sep 2007 15:19:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT0Pj-0004ok-BH for ecrit@ietf.org; Wed, 05 Sep 2007 15:19:47 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IT0Pb-0003vD-Bf for ecrit@ietf.org; Wed, 05 Sep 2007 15:19:47 -0400 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 l85JJSpJ016752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Sep 2007 12:19:29 -0700 Received: from [129.46.226.27] (carbuncle.qualcomm.com [129.46.226.27]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l85JJRNA031622; Wed, 5 Sep 2007 12:19:28 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <09c501c7efee$2bf9e200$640fa8c0@cis.neustar.com> References: <09c501c7efee$2bf9e200$640fa8c0@cis.neustar.com> Date: Wed, 5 Sep 2007 12:19:27 -0700 To: "Brian Rosen" , From: Ted Hardie Subject: RE: [Ecrit] About that 911 button... Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -3.6 (---) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 2:54 PM -0400 9/5/07, Brian Rosen wrote: >I talked to the Verizon 9-1-1 folks. > >First of all, they weren't aware of this phone. The marketing guys don't >ask them about features like this. > >Then, it actually takes two key presses: you have to press the 911 key and >then press send. Ah, that's the equivalent of the "confirm" that I was wondering about. Thanks for checking that out. That should limit things somewhat, as will the clamshell. But I agree that it is likely to be a source of unintended calls. Ted >It also is a clamshell design, which means that it is harder to have the >keys get pressed automatically in a pocket or purse. > >In my opinion, it's still a bad design, and likely there will be many more >false emergency calls with this phone than any other phone in the Verizon >line-up. > >Brian > >> -----Original Message----- >> From: Ted Hardie [mailto:hardie@qualcomm.com] >> Sent: Tuesday, September 04, 2007 5:16 PM >> To: ecrit@ietf.org >> Subject: [Ecrit] About that 911 button... >> >> http://news.vzw.com/news/2007/09/pr2007-09-04a.html >> >> augmented with 3 "in case of emergency buttons", and >> a dedicated 911 key right above the power button. >> >> http://news.vzw.com/images/releases/Coupe-CDM-8630OpenH4Web.jpg >> >> It got a Goodhouskeeping Seal, too. Note that despite saying that >> it had color coded keys for specific functions, the 911 key is >> not color coded. >> >> By any chance has anyone checked the UI on this, to see if there >> is a "confirm"? >> >> Ted >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 08 06:18:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITxMU-0003CW-Re; Sat, 08 Sep 2007 06:16:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITxMT-0003CN-PN for ecrit@ietf.org; Sat, 08 Sep 2007 06:16:21 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ITxMT-0002ia-0x for ecrit@ietf.org; Sat, 08 Sep 2007 06:16:21 -0400 Received: (qmail invoked by alias); 08 Sep 2007 10:16:19 -0000 Received: from p54986D37.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.109.55] by mail.gmx.net (mp032) with SMTP; 08 Sep 2007 12:16:19 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19FFlNnLltFap/X0Q/BbI80x+NtE3vkRuIxFZ/UdB /piagaQ3nkNhg6 Message-ID: <46E2766C.9040608@gmx.net> Date: Sat, 08 Sep 2007 12:16:12 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 1.7 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Alain.VAN-GAEVER@ec.europa.eu Subject: [Ecrit] Expert Group on Emergency Access (EGEA): Document Reviewers Needed X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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, The Expert Group on Emergency Access (EGEA) is a subgroup of the European Commission's Communications Committee, and was established to deal with the forward looking aspects of Access to Emergency Services at European level. One of the deliverables of the Expert Group is the Operational Needs document (EGEA07-02). The Operational Needs document establishes a common set of needs focusing on the interconnection between public operators and the entry point of the public safety answering point (PSAP), for calls from the public to the emergency authorities. Defining common operational needs at EU level will, amongst others, help to bridge the gap between legislation and work being done by standards & protocol developing bodies. We would welcome feedback of industry and standardisation organisations on this document, and more specifically on: – the structure (division in common/supplementary needs), – the operational needs and the level of detail – the degree to which this work fits with the work of your organisation Please let us know if you are interested in reviewing the document. We will send you a copy. Deadline for the review: 28th of September 2007. Send your comments to us, the chairs, so that we can discuss them with Alain. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 08 06:34:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITxcH-0000B6-U8; Sat, 08 Sep 2007 06:32:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITxcG-00009s-6m for ecrit@ietf.org; Sat, 08 Sep 2007 06:32:40 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ITxcF-00033W-F0 for ecrit@ietf.org; Sat, 08 Sep 2007 06:32:39 -0400 Received: (qmail invoked by alias); 08 Sep 2007 10:32:38 -0000 Received: from p54986D37.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.109.55] by mail.gmx.net (mp039) with SMTP; 08 Sep 2007 12:32:38 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18eazJ9XQMey7OvffZl7LsKLWJtnWsOn7sQmF+MVk y90BMl0aCjgqOx Message-ID: <46E27A3F.4070808@gmx.net> Date: Sat, 08 Sep 2007 12:32:31 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 CC: ecrit@ietf.org References: <001501c7e022$f76e7670$8ef0560a@amer.cisco.com> In-Reply-To: <001501c7e022$f76e7670$8ef0560a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 1.6 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Ecrit] Re: [dhcwg] WGLC: A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The 2nd working group last call for this document has finished without additional comments. We will therefore compile the PROTO writeup and forward the document to the IESG. Ciao Hannes & Marc Marc Linsner wrote: > All, > > This message marks the issuance of a working group last call (WGLC) on > ECRIT's Internet Draft entitled "A Dynamic Host Configuration Protocol > (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery > Procedure" (draft-ietf-ecrit-dhc-lost-discovery-02.txt). You may view this > document at > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-02.t > xt. > > Please post comments and questions to the ECRIT (preferred) or DHC mailing > list no later than 31 August 2007. > > Thank you, > > Marc Linsner > ECRIT co-chair > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 08 06:34:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITxck-0000E7-GF; Sat, 08 Sep 2007 06:33:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITxcj-0000E2-VR for ecrit@ietf.org; Sat, 08 Sep 2007 06:33:09 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ITxci-0005uY-DI for ecrit@ietf.org; Sat, 08 Sep 2007 06:33:09 -0400 Received: (qmail invoked by alias); 08 Sep 2007 10:33:07 -0000 Received: from p54986D37.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.109.55] by mail.gmx.net (mp005) with SMTP; 08 Sep 2007 12:33:07 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19cFaQ03mNcWU8GZFNB5TF5suMAyheKYwAgrslsD0 02ynfZ9RMsB94g Message-ID: <46E27A5C.8030008@gmx.net> Date: Sat, 08 Sep 2007 12:33:00 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - Location-to-URL Mapping Architecture and Framework References: <004601c7e008$c3550e40$91d2520a@amer.cisco.com> In-Reply-To: <004601c7e008$c3550e40$91d2520a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The working group last call for this document has finished without additional comments. We will therefore compile the PROTO writeup and forward the document to the IESG. Ciao Hannes & Marc Marc Linsner wrote: > All, > > This message marks the issuance of a working group last call (WGLC) on > ECRIT's Internet Draft entitled "Location-to-URL Mapping Architecture and > Framework" (draft-ietf-ecrit-mapping-arch-02). You may view this document > at http://www.ietf.org/internet-drafts/draft-ietf-ecrit-mapping-arch-02.txt. > > Please post comments and questions to this mailing list no later than 31 > August 2007. > > -Marc Linsner- > ECRIT co-chair > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 08 06:35:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITxdA-0000QO-6y; Sat, 08 Sep 2007 06:33:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITxd9-0000QI-35 for ecrit@ietf.org; Sat, 08 Sep 2007 06:33:35 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ITxd8-00034T-Iz for ecrit@ietf.org; Sat, 08 Sep 2007 06:33:35 -0400 Received: (qmail invoked by alias); 08 Sep 2007 10:33:33 -0000 Received: from p54986D37.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.109.55] by mail.gmx.net (mp039) with SMTP; 08 Sep 2007 12:33:33 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18hJuYWQI4hZjI1YEyxlIovY0rqHJ2ng3BA2kN5BZ MsDqFe/mbIVxUQ Message-ID: <46E27A76.3040509@gmx.net> Date: Sat, 08 Sep 2007 12:33:26 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - LoST: A Location-to-Service Translation Protocol References: <003501c7df37$7af43ad0$18f0520a@amer.cisco.com> In-Reply-To: <003501c7df37$7af43ad0$18f0520a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The 2nd working group last call for this document has finished without additional comments. We will therefore compile the PROTO writeup and forward the document to the IESG. Ciao Hannes & Marc Marc Linsner wrote: > All, > > This message marks the issuance of a working group last call (WGLC) on > ECRIT's Internet Draft entitled "LoST: A Location-to-Service Translation > Protocol" (draft-ietf-ecrit-lost-06.txt). You may view this document at > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-06.txt. > > Please post comments and questions to this mailing list no later than 30 > August 2007. > > -Marc Linsner- > ECRIT co-chair > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 08 08:44:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITzdr-0000oG-Dd; Sat, 08 Sep 2007 08:42:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITzdq-0000oA-7W for ecrit@ietf.org; Sat, 08 Sep 2007 08:42:26 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITzdo-0000ns-V1 for ecrit@ietf.org; Sat, 08 Sep 2007 08:42:26 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1ITzdg-0006Rl-NJ; Sat, 08 Sep 2007 07:42:16 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'ECRIT'" References: <46E2766C.9040608@gmx.net> Subject: RE: [Ecrit] Expert Group on Emergency Access (EGEA): Document ReviewersNeeded Date: Sat, 8 Sep 2007 08:42:20 -0400 Message-ID: <008101c7f215$b474b190$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <46E2766C.9040608@gmx.net> Thread-Index: AcfyAZJ+c5fFl0KFRNStjE423XmXpwAFA0uw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Alain.VAN-GAEVER@ec.europa.eu X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'll review it (after I get out a framework and phonebcp update) > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Saturday, September 08, 2007 6:16 AM > To: ECRIT > Cc: Alain.VAN-GAEVER@ec.europa.eu > Subject: [Ecrit] Expert Group on Emergency Access (EGEA): Document > ReviewersNeeded > > Hi all, > > The Expert Group on Emergency Access (EGEA) is a subgroup of the European > Commission's Communications Committee, and was established to deal with > the forward > looking aspects of Access to Emergency Services at European level. > > One of the deliverables of the Expert Group is the Operational Needs > document > (EGEA07-02). > > The Operational Needs document establishes a common set of needs > focusing on the > interconnection between public operators and the entry point of the > public safety > answering point (PSAP), for calls from the public to the emergency > authorities. > > Defining common operational needs at EU level will, amongst others, help > to bridge the > gap between legislation and work being done by standards & protocol > developing bodies. > > We would welcome feedback of industry and standardisation organisations > on this > document, and more specifically on: > - the structure (division in common/supplementary needs), > - the operational needs and the level of detail > - the degree to which this work fits with the work of your organisation > > Please let us know if you are interested in reviewing the document. We > will send you a copy. > > Deadline for the review: 28th of September 2007. > > Send your comments to us, the chairs, so that we can discuss them with > Alain. > > Ciao > Hannes > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 10 03:23:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUdaY-0005et-Fj; Mon, 10 Sep 2007 03:21:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUdaX-0005eg-Hc for ecrit@ietf.org; Mon, 10 Sep 2007 03:21:41 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IUdaV-0003ny-Vf for ecrit@ietf.org; Mon, 10 Sep 2007 03:21:41 -0400 Received: (qmail invoked by alias); 10 Sep 2007 07:21:38 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp048) with SMTP; 10 Sep 2007 09:21:38 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/70up0yav7Vhz2yvi/d7h2vZD6HWSUD3k4kiMtLE OAJeyhH2h6hmtP Message-ID: <46E4F078.4070402@gmx.net> Date: Mon, 10 Sep 2007 09:21:28 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IETF SIP List , 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: 25620135586de10c627e3628c432b04a Cc: Subject: [Ecrit] Service URN Usage (UA Loose Routing) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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, after some discussions on the usage of the Service URN it seems that most people in ECRIT agreed to move forward with the initially planned approach. Below, you can find a description of how the Service URN would be used in various scenarios. Are there any objections? Ciao Hannes --------------------- == End Host Procedures == * UA does not recognize the emergency call. To: Dial String Request URI: Dial String No Route header * UA runs LoST and determines the PSAP URI: Request URI: Service URN To: Service URN Route Header: PSAP URI * UA does not run LoST but recognizes the emergency call. Request URI: Service URN To: Service URN No Route header == Proxy Procedures == * Incoming request contains Service URN; Proxy runs LoST and determines the PSAP URI --- Input: Request URI: Service URN To: Service URN No Route header --- Output: Request URI: Service URN To: Service URN Route Header: PSAP URI * Incoming request contains Dial String; Proxy runs LoST and determines the PSAP URI: --- Input: Request URI: Dial String To: Dial String No Route header --- Output: Request URI: Service URN To: Dial String Route Header: PSAP URI Remark: "Dial String" refers to http://tools.ietf.org/html/rfc4967 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 10 08:35:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUiSj-0003I7-3Y; Mon, 10 Sep 2007 08:33:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUiSg-0003H0-La; Mon, 10 Sep 2007 08:33:54 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUiSf-0003bq-AE; Mon, 10 Sep 2007 08:33:54 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 0FD52205B7; Mon, 10 Sep 2007 14:33:52 +0200 (CEST) X-AuditID: c1b4fb3e-b0034bb0000007e1-24-46e539af52e8 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DD9252054F; Mon, 10 Sep 2007 14:33:51 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 14:33:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Service URN Usage (UA Loose Routing) Date: Mon, 10 Sep 2007 14:33:50 +0200 Message-ID: In-Reply-To: <46E4F078.4070402@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Service URN Usage (UA Loose Routing) Thread-Index: Acfze0Gs7n/4Pb2BRh2HaEE//sjZHgAK3L3w References: <46E4F078.4070402@gmx.net> From: "Christer Holmberg (JO/LMF)" To: "Hannes Tschofenig" , "IETF SIP List" , "ECRIT" X-OriginalArrivalTime: 10 Sep 2007 12:33:51.0728 (UTC) FILETIME=[D7FEF700:01C7F3A6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi, I don't have any objections. I have only clarified how it works in IMS, and why. It's up to you to decide what/if to do with that information. Also, in the ECRIT documentation, I think you should indicate that your solution does not work with MGCs that route the destination number based on the Request-URI (that is not an IMS specific MGC behavior). I do have one question for clarification, though: in the examples there is only one Route header, pointing towards the PSAP. IF there are intermediate entities that also need to be in the path, is it assumed that the one inserting the PSAP Route has information about those, in order to insert Route headers also for those entities if needed? Regards, Christer =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: 10. syyskuuta 2007 10:21 > To: IETF SIP List; ECRIT > Subject: [Ecrit] Service URN Usage (UA Loose Routing) >=20 > Hi all, >=20 > after some discussions on the usage of the Service URN it=20 > seems that most people in ECRIT agreed to move forward with=20 > the initially planned approach. Below, you can find a=20 > description of how the Service URN would be used in various scenarios. >=20 > Are there any objections? >=20 > Ciao > Hannes >=20 > --------------------- >=20 > =3D=3D End Host Procedures =3D=3D >=20 > * UA does not recognize the emergency call. >=20 > To: Dial String > Request URI: Dial String > No Route header >=20 > * UA runs LoST and determines the PSAP URI: >=20 > Request URI: Service URN > To: Service URN > Route Header: PSAP URI >=20 > * UA does not run LoST but recognizes the emergency call. >=20 > Request URI: Service URN > To: Service URN > No Route header >=20 >=20 > =3D=3D Proxy Procedures =3D=3D >=20 > * Incoming request contains Service URN; Proxy runs LoST >=20 > and determines the PSAP URI >=20 > --- Input: >=20 > Request URI: Service URN > To: Service URN > No Route header >=20 > --- Output: >=20 > Request URI: Service URN > To: Service URN > Route Header: PSAP URI >=20 > * Incoming request contains Dial String; Proxy runs LoST >=20 > and determines the PSAP URI: >=20 > --- Input: >=20 > Request URI: Dial String > To: Dial String > No Route header >=20 > --- Output: >=20 > Request URI: Service URN > To: Dial String > Route Header: PSAP URI >=20 >=20 >=20 > Remark: "Dial String" refers to http://tools.ietf.org/html/rfc4967 >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 10 08:44:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUiar-000202-9t; Mon, 10 Sep 2007 08:42:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUiao-0001yl-FK; Mon, 10 Sep 2007 08:42:18 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUiao-0004e8-0s; Mon, 10 Sep 2007 08:42:18 -0400 Received: from mail.bbn.com ([128.33.1.19]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IUian-00022W-4G; Mon, 10 Sep 2007 08:42:17 -0400 Received: from col-dhcp33-244-152.bbn.com ([128.33.244.152] helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.67) (envelope-from ) id 1IUiam-00043u-1r; Mon, 10 Sep 2007 08:42:16 -0400 Message-ID: <46E53BA5.4080903@bbn.com> Date: Mon, 10 Sep 2007 08:42:13 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Service URN Usage (UA Loose Routing) References: <46E4F078.4070402@gmx.net> In-Reply-To: <46E4F078.4070402@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: IETF SIP List , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes, I'm still worried that because we're using the routing fields for marking, there's a risk that proxies will do things to those headers that will remove the marking and cause the emergency call to fail. For instance, I've heard tell that some proxies like to strip all Route headers from INVITE messages passing through them. In your example below, that would cause the call to need another LoST lookup, which may be impossible if no subsequent proxy supports LoST, or if there's no proxy-readable location in the INVITE. Moreover, if a proxy changes the To field or the Request URI, then downstream proxies might not even recognize that a LoST lookup is required and thus would cause the call to fail. I don't disagree with the three abstract states you've defined (unrecognized, recognized but not routed, and routed), but I would prefer that (1) The Service URN were carried in an explicit marking field even if a new one has to be created (say, Requested-Service), and that (2) after routing (LoST) a call looks like any other call to a PSAP URI, but with an explicit marking. I think this would be much more in the spirit of minimal surprise. --Richard Hannes Tschofenig wrote: > Hi all, > > after some discussions on the usage of the Service URN it seems that > most people in ECRIT agreed to move forward with the initially planned > approach. Below, you can find a description of how the Service URN would > be used in various scenarios. > > Are there any objections? > > Ciao > Hannes > > --------------------- > > == End Host Procedures == > > * UA does not recognize the emergency call. > > To: Dial String > Request URI: Dial String > No Route header > > * UA runs LoST and determines the PSAP URI: > > Request URI: Service URN > To: Service URN > Route Header: PSAP URI > > * UA does not run LoST but recognizes the emergency call. > > Request URI: Service URN > To: Service URN > No Route header > > > == Proxy Procedures == > > * Incoming request contains Service URN; Proxy runs LoST > > and determines the PSAP URI > > --- Input: > > Request URI: Service URN > To: Service URN > No Route header > > --- Output: > > Request URI: Service URN > To: Service URN > Route Header: PSAP URI > > * Incoming request contains Dial String; Proxy runs LoST > > and determines the PSAP URI: > > --- Input: > > Request URI: Dial String > To: Dial String > No Route header > > --- Output: > > Request URI: Service URN > To: Dial String > Route Header: PSAP URI > > > > Remark: "Dial String" refers to http://tools.ietf.org/html/rfc4967 > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 10 08:53:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUijd-0007dg-Ho; Mon, 10 Sep 2007 08:51:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUijb-0007cG-Mg; Mon, 10 Sep 2007 08:51:23 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUija-00043O-EC; Mon, 10 Sep 2007 08:51:23 -0400 Received: from [24.154.127.115] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IUijR-0004S7-Qy; Mon, 10 Sep 2007 07:51:14 -0500 From: "Brian Rosen" To: "'Christer Holmberg \(JO/LMF\)'" , "'Hannes Tschofenig'" , "'IETF SIP List'" , "'ECRIT'" References: <46E4F078.4070402@gmx.net> Subject: RE: [Ecrit] Service URN Usage (UA Loose Routing) Date: Mon, 10 Sep 2007 08:51:18 -0400 Message-ID: <020501c7f3a9$495b6ee0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acfze0Gs7n/4Pb2BRh2HaEE//sjZHgAK3L3wAABIN/A= In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > I don't have any objections. I have only clarified how it works in IMS, > and why. It's up to you to decide what/if to do with that information. I think we understand that. It may be that the PSAPs will require one or the other solution in calls placed towards them, but I don't see a big problem dealing with that. As I pointed out, the proposed IMS solution does not even meet the existing specification, let alone anything new. > > Also, in the ECRIT documentation, I think you should indicate that your > solution does not work with MGCs that route the destination number based > on the Request-URI (that is not an IMS specific MGC behavior). That is correct. None of ecrit works with TN based routing. In the U.S. i3 system, it would be required that the MGC arrange a TN to location translation, followed by a LoST query to obtain a PSAP URI and routing per normal SIP standards towards the PSAP. The incoming SIP call will need the Route header in i3 unless we decide to accept the IMS alternative. The current version of the i3 specification does not. > > I do have one question for clarification, though: in the examples there > is only one Route header, pointing towards the PSAP. IF there are > intermediate entities that also need to be in the path, is it assumed > that the one inserting the PSAP Route has information about those, in > order to insert Route headers also for those entities if needed? I would expect that the ESRP could replace the Route header if it needed to. It could indeed put more than one Route header on the call. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 10 08:59:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUipa-0004Oo-3w; Mon, 10 Sep 2007 08:57:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUipX-0004Nz-5g; Mon, 10 Sep 2007 08:57:31 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUipV-0004Ed-Uz; Mon, 10 Sep 2007 08:57:31 -0400 Received: from [24.154.127.115] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IUipO-00059t-4q; Mon, 10 Sep 2007 07:57:22 -0500 From: "Brian Rosen" To: "'Richard Barnes'" , "'Hannes Tschofenig'" References: <46E4F078.4070402@gmx.net> <46E53BA5.4080903@bbn.com> Subject: RE: [Sip] Re: [Ecrit] Service URN Usage (UA Loose Routing) Date: Mon, 10 Sep 2007 08:57:26 -0400 Message-ID: <020d01c7f3aa$24efe580$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfzqEyv8DZjtM+VSpOrYYGiRZz+aAAATpXw In-Reply-To: <46E53BA5.4080903@bbn.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: 'IETF SIP List' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think that if you look, you can find proxies that will break anything we can define. No matter what we specify, there is sure to be a proxy out there that breaks it. For example, there are proxies that strip any header they don't recognize. They aren't supposed to, but they do. It's futile to try and define any new behavior based on what non standard existing proxies will do. In this case, they will have to recognize emergency calls and do the appropriate processing of them. The test function would find these things, of course. Brian > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Monday, September 10, 2007 8:42 AM > To: Hannes Tschofenig > Cc: IETF SIP List; ECRIT > Subject: [Sip] Re: [Ecrit] Service URN Usage (UA Loose Routing) > > Hannes, > > I'm still worried that because we're using the routing fields for > marking, there's a risk that proxies will do things to those headers > that will remove the marking and cause the emergency call to fail. > > For instance, I've heard tell that some proxies like to strip all Route > headers from INVITE messages passing through them. In your example > below, that would cause the call to need another LoST lookup, which may > be impossible if no subsequent proxy supports LoST, or if there's no > proxy-readable location in the INVITE. Moreover, if a proxy changes the > To field or the Request URI, then downstream proxies might not even > recognize that a LoST lookup is required and thus would cause the call > to fail. > > I don't disagree with the three abstract states you've defined > (unrecognized, recognized but not routed, and routed), but I would > prefer that (1) The Service URN were carried in an explicit marking > field even if a new one has to be created (say, Requested-Service), and > that (2) after routing (LoST) a call looks like any other call to a PSAP > URI, but with an explicit marking. I think this would be much more in > the spirit of minimal surprise. > > --Richard > > > > Hannes Tschofenig wrote: > > Hi all, > > > > after some discussions on the usage of the Service URN it seems that > > most people in ECRIT agreed to move forward with the initially planned > > approach. Below, you can find a description of how the Service URN would > > be used in various scenarios. > > > > Are there any objections? > > > > Ciao > > Hannes > > > > --------------------- > > > > == End Host Procedures == > > > > * UA does not recognize the emergency call. > > > > To: Dial String > > Request URI: Dial String > > No Route header > > > > * UA runs LoST and determines the PSAP URI: > > > > Request URI: Service URN > > To: Service URN > > Route Header: PSAP URI > > > > * UA does not run LoST but recognizes the emergency call. > > > > Request URI: Service URN > > To: Service URN > > No Route header > > > > > > == Proxy Procedures == > > > > * Incoming request contains Service URN; Proxy runs LoST > > > > and determines the PSAP URI > > > > --- Input: > > > > Request URI: Service URN > > To: Service URN > > No Route header > > > > --- Output: > > > > Request URI: Service URN > > To: Service URN > > Route Header: PSAP URI > > > > * Incoming request contains Dial String; Proxy runs LoST > > > > and determines the PSAP URI: > > > > --- Input: > > > > Request URI: Dial String > > To: Dial String > > No Route header > > > > --- Output: > > > > Request URI: Service URN > > To: Dial String > > Route Header: PSAP URI > > > > > > > > Remark: "Dial String" refers to http://tools.ietf.org/html/rfc4967 > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 10 09:37:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUjQN-0004ut-0G; Mon, 10 Sep 2007 09:35:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUjQL-0004u0-1R; Mon, 10 Sep 2007 09:35:33 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUjQJ-0005IJ-Q9; Mon, 10 Sep 2007 09:35:33 -0400 Received: from mail.bbn.com ([128.33.1.19]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IUjQJ-0002om-4B; Mon, 10 Sep 2007 09:35:31 -0400 Received: from col-dhcp33-244-152.bbn.com ([128.33.244.152] helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.67) (envelope-from ) id 1IUjQJ-0007tu-6h; Mon, 10 Sep 2007 09:35:31 -0400 Message-ID: <46E54822.8010306@bbn.com> Date: Mon, 10 Sep 2007 09:35:30 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Sip] Re: [Ecrit] Service URN Usage (UA Loose Routing) References: <46E4F078.4070402@gmx.net> <46E53BA5.4080903@bbn.com> <020d01c7f3aa$24efe580$640fa8c0@cis.neustar.com> In-Reply-To: <020d01c7f3aa$24efe580$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: 'IETF SIP List' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > I think that if you look, you can find proxies that will break anything we > can define. ... For example, there are proxies that strip any header > they don't recognize. They aren't supposed to, but they do. Sure, but we should try to look at likely failure modes and mitigate their impact on emergency calls. It's in the interest of VSPs to route calls to the correct destination (so that their service actually works), but it's often not in their interest to route it via the path specified in the Route header fields. So if the PSAP URI were carried in the R-URI/To, and the Service URN were carried in another header (even Route), then even a proxy that stripped out every header it doesn't like or recognize would still get the call to the PSAP (even if the PSAP wouldn't know which service was requested). I thought that this was the point of keeping emergency calling as close as possible to normal calling -- that in spite of whatever pathological things proxies might do, the call would get through. > The test function would find these things, of course. That's true of whatever we define. For that argument to be applicable to a given emergency call, you also need to assume that the UA does tests every time the proxy path between it and the PSAP changes. Of course, this could happen without the UA knowing it, so the UA would have to be frequently testing. --Richard > > Brian > > >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Monday, September 10, 2007 8:42 AM >> To: Hannes Tschofenig >> Cc: IETF SIP List; ECRIT >> Subject: [Sip] Re: [Ecrit] Service URN Usage (UA Loose Routing) >> >> Hannes, >> >> I'm still worried that because we're using the routing fields for >> marking, there's a risk that proxies will do things to those headers >> that will remove the marking and cause the emergency call to fail. >> >> For instance, I've heard tell that some proxies like to strip all Route >> headers from INVITE messages passing through them. In your example >> below, that would cause the call to need another LoST lookup, which may >> be impossible if no subsequent proxy supports LoST, or if there's no >> proxy-readable location in the INVITE. Moreover, if a proxy changes the >> To field or the Request URI, then downstream proxies might not even >> recognize that a LoST lookup is required and thus would cause the call >> to fail. >> >> I don't disagree with the three abstract states you've defined >> (unrecognized, recognized but not routed, and routed), but I would >> prefer that (1) The Service URN were carried in an explicit marking >> field even if a new one has to be created (say, Requested-Service), and >> that (2) after routing (LoST) a call looks like any other call to a PSAP >> URI, but with an explicit marking. I think this would be much more in >> the spirit of minimal surprise. >> >> --Richard >> >> >> >> Hannes Tschofenig wrote: >>> Hi all, >>> >>> after some discussions on the usage of the Service URN it seems that >>> most people in ECRIT agreed to move forward with the initially planned >>> approach. Below, you can find a description of how the Service URN would >>> be used in various scenarios. >>> >>> Are there any objections? >>> >>> Ciao >>> Hannes >>> >>> --------------------- >>> >>> == End Host Procedures == >>> >>> * UA does not recognize the emergency call. >>> >>> To: Dial String >>> Request URI: Dial String >>> No Route header >>> >>> * UA runs LoST and determines the PSAP URI: >>> >>> Request URI: Service URN >>> To: Service URN >>> Route Header: PSAP URI >>> >>> * UA does not run LoST but recognizes the emergency call. >>> >>> Request URI: Service URN >>> To: Service URN >>> No Route header >>> >>> >>> == Proxy Procedures == >>> >>> * Incoming request contains Service URN; Proxy runs LoST >>> >>> and determines the PSAP URI >>> >>> --- Input: >>> >>> Request URI: Service URN >>> To: Service URN >>> No Route header >>> >>> --- Output: >>> >>> Request URI: Service URN >>> To: Service URN >>> Route Header: PSAP URI >>> >>> * Incoming request contains Dial String; Proxy runs LoST >>> >>> and determines the PSAP URI: >>> >>> --- Input: >>> >>> Request URI: Dial String >>> To: Dial String >>> No Route header >>> >>> --- Output: >>> >>> Request URI: Service URN >>> To: Dial String >>> Route Header: PSAP URI >>> >>> >>> >>> Remark: "Dial String" refers to http://tools.ietf.org/html/rfc4967 >>> >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 10 09:59:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUjmH-0007ay-VK; Mon, 10 Sep 2007 09:58:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUjmF-0007Vw-J0; Mon, 10 Sep 2007 09:58:11 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUjmE-00069Y-AO; Mon, 10 Sep 2007 09:58:11 -0400 Received: from [24.154.127.115] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IUjm5-0005jR-KM; Mon, 10 Sep 2007 08:58:01 -0500 From: "Brian Rosen" To: "'Richard Barnes'" References: <46E4F078.4070402@gmx.net> <46E53BA5.4080903@bbn.com> <020d01c7f3aa$24efe580$640fa8c0@cis.neustar.com> <46E54822.8010306@bbn.com> Subject: RE: [Sip] Re: [Ecrit] Service URN Usage (UA Loose Routing) Date: Mon, 10 Sep 2007 09:58:06 -0400 Message-ID: <021e01c7f3b2$9ea28dd0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acfzr3pMXUI7yOFMSdqUIdJ5H7AVlwAAQ2Hg In-Reply-To: <46E54822.8010306@bbn.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Cc: 'IETF SIP List' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Most carriers have pretty closed systems. They only route within their own domain. Some are now doing inter-carrier routing, but generally that is with gateway nodes within the domain which connect to some kind of peering system. It's not really clear how they will modify this for emergency calls. IMS has a separate proxy (E-CSCF) that would handle it. Others may make it a function of their gateway proxies. The Route stripping can happen in a couple of places. The most common is the SBC that protects the network from wayward user devices. The way most SBCs are set up, I think they will have to be changed for any emergency call processing; they often don't pass anything that isn't a TN in the R-URI, and that's where headers not understood in the network are often dropped. I think the SBC issues are pretty straightforward; some changes are going to be needed, and if there is a spec, the spec can be accommodated. Then it depends on how the network is configured. In my experience, the next hop routing proxy does most of the work; from there, it's mostly special processing the nhrp invokes, or the call is on a gateway node next. Most routing proxies don't drop Route headers, but some that I know of don't pay any attention to them. I'd worry a little about those. The SBC can preroute (which may be a good idea anyway), or the nhrp element may need an update. The call is then probably on some kind of gateway element, which also can be an SBC. Again, I don't think any of these drop Route headers, but some may ignore them. Whatever it is, it will need at least some configuration work to get the call out of the carrier domain into the emergency services domain. I guess my bottom line is that the networks are going to need some set of changes to deal with emergency calls at all, and when those changes are done, the whole thing will work. I suspect most of this really is configuration, but if there are code updates needed, I think they will be needed regardless of which solution we choose. Brian > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Monday, September 10, 2007 9:36 AM > To: Brian Rosen > Cc: 'Hannes Tschofenig'; 'IETF SIP List'; 'ECRIT' > Subject: Re: [Sip] Re: [Ecrit] Service URN Usage (UA Loose Routing) > > > I think that if you look, you can find proxies that will break anything > we > > can define. ... For example, there are proxies that strip any header > > they don't recognize. They aren't supposed to, but they do. > > Sure, but we should try to look at likely failure modes and mitigate > their impact on emergency calls. It's in the interest of VSPs to route > calls to the correct destination (so that their service actually works), > but it's often not in their interest to route it via the path specified > in the Route header fields. > > So if the PSAP URI were carried in the R-URI/To, and the Service URN > were carried in another header (even Route), then even a proxy that > stripped out every header it doesn't like or recognize would still get > the call to the PSAP (even if the PSAP wouldn't know which service was > requested). > > I thought that this was the point of keeping emergency calling as close > as possible to normal calling -- that in spite of whatever pathological > things proxies might do, the call would get through. > > > The test function would find these things, of course. > > That's true of whatever we define. For that argument to be applicable > to a given emergency call, you also need to assume that the UA does > tests every time the proxy path between it and the PSAP changes. Of > course, this could happen without the UA knowing it, so the UA would > have to be frequently testing. > > --Richard > > > > > > > > Brian > > > > > >> -----Original Message----- > >> From: Richard Barnes [mailto:rbarnes@bbn.com] > >> Sent: Monday, September 10, 2007 8:42 AM > >> To: Hannes Tschofenig > >> Cc: IETF SIP List; ECRIT > >> Subject: [Sip] Re: [Ecrit] Service URN Usage (UA Loose Routing) > >> > >> Hannes, > >> > >> I'm still worried that because we're using the routing fields for > >> marking, there's a risk that proxies will do things to those headers > >> that will remove the marking and cause the emergency call to fail. > >> > >> For instance, I've heard tell that some proxies like to strip all Route > >> headers from INVITE messages passing through them. In your example > >> below, that would cause the call to need another LoST lookup, which may > >> be impossible if no subsequent proxy supports LoST, or if there's no > >> proxy-readable location in the INVITE. Moreover, if a proxy changes > the > >> To field or the Request URI, then downstream proxies might not even > >> recognize that a LoST lookup is required and thus would cause the call > >> to fail. > >> > >> I don't disagree with the three abstract states you've defined > >> (unrecognized, recognized but not routed, and routed), but I would > >> prefer that (1) The Service URN were carried in an explicit marking > >> field even if a new one has to be created (say, Requested-Service), and > >> that (2) after routing (LoST) a call looks like any other call to a > PSAP > >> URI, but with an explicit marking. I think this would be much more in > >> the spirit of minimal surprise. > >> > >> --Richard > >> > >> > >> > >> Hannes Tschofenig wrote: > >>> Hi all, > >>> > >>> after some discussions on the usage of the Service URN it seems that > >>> most people in ECRIT agreed to move forward with the initially planned > >>> approach. Below, you can find a description of how the Service URN > would > >>> be used in various scenarios. > >>> > >>> Are there any objections? > >>> > >>> Ciao > >>> Hannes > >>> > >>> --------------------- > >>> > >>> == End Host Procedures == > >>> > >>> * UA does not recognize the emergency call. > >>> > >>> To: Dial String > >>> Request URI: Dial String > >>> No Route header > >>> > >>> * UA runs LoST and determines the PSAP URI: > >>> > >>> Request URI: Service URN > >>> To: Service URN > >>> Route Header: PSAP URI > >>> > >>> * UA does not run LoST but recognizes the emergency call. > >>> > >>> Request URI: Service URN > >>> To: Service URN > >>> No Route header > >>> > >>> > >>> == Proxy Procedures == > >>> > >>> * Incoming request contains Service URN; Proxy runs LoST > >>> > >>> and determines the PSAP URI > >>> > >>> --- Input: > >>> > >>> Request URI: Service URN > >>> To: Service URN > >>> No Route header > >>> > >>> --- Output: > >>> > >>> Request URI: Service URN > >>> To: Service URN > >>> Route Header: PSAP URI > >>> > >>> * Incoming request contains Dial String; Proxy runs LoST > >>> > >>> and determines the PSAP URI: > >>> > >>> --- Input: > >>> > >>> Request URI: Dial String > >>> To: Dial String > >>> No Route header > >>> > >>> --- Output: > >>> > >>> Request URI: Service URN > >>> To: Dial String > >>> Route Header: PSAP URI > >>> > >>> > >>> > >>> Remark: "Dial String" refers to http://tools.ietf.org/html/rfc4967 > >>> > >>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/ecrit > >>> > >>> > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > > > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 10 10:44:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkT6-00045t-A8; Mon, 10 Sep 2007 10:42:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkT4-0003rl-2P; Mon, 10 Sep 2007 10:42:26 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IUkT3-0000Kd-65; Mon, 10 Sep 2007 10:42:25 -0400 Received: from dynamic-acs-24-154-127-115.zoominternet.net ([24.154.127.115] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IUkSu-0002uX-7L; Mon, 10 Sep 2007 09:42:16 -0500 From: "Brian Rosen" To: "'Paul Kyzivat'" References: <46E4F078.4070402@gmx.net> <46E53BA5.4080903@bbn.com> <020d01c7f3aa$24efe580$640fa8c0@cis.neustar.com> <46E554BA.2050701@cisco.com> Subject: RE: [Sip] Re: [Ecrit] Service URN Usage (UA Loose Routing) Date: Mon, 10 Sep 2007 10:42:24 -0400 Message-ID: <023501c7f3b8$cd2c8f10$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acfztwyk5VMi+Z4ITbWrzoUTPXzlKgAATJSw In-Reply-To: <46E554BA.2050701@cisco.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: 'IETF SIP List' , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I agree with your sentiment. I don't see how the access network is in the calling path at all unless it's an IMS-like system where that is the agreement. In that case, by definition, the access network has a relationship with the calling network. Normally, the UA's proxy discovery mechanism leads it to its calling network, not anything in the access network. I think if it happened accidently, it would work; no matter who routes it, the PSAP URI leads to the right place. Brian > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, September 10, 2007 10:29 AM > To: Brian Rosen > Cc: 'Richard Barnes'; 'Hannes Tschofenig'; 'IETF SIP List'; 'ECRIT' > Subject: Re: [Sip] Re: [Ecrit] Service URN Usage (UA Loose Routing) > > Brian, > > I agree that there will be implementations that break whatever rules we > make. But does that mean we should make no rules? > > In this case it isn't even a matter of making a new rule - it is an old > one I am talking about. > > But the key here is to ensure that when we develop use cases, examples, > etc. they don't break this rule. If a practical system will require > breaking the rule then IMO another mechanism is needed. > > The case that concerns me most here is when a UA is connected through an > access network that is different from its home network. Then the access > network preemptively decides that a particular R-URI looks like an > emergency number in its domain, and acts accordingly, even though the > R-URI isn't within the domain of the access network. > > The point here of course is that there are no universal standards for > the user part of SIP URIs. So there is no way that a proxy not > responsible for the domain of the URI to decide that the user part is a > dial string at all, and not something else. (Well, user=dialstring *is* > a standard for the user part, but it *explicitly* is intended only for > use within the responsible domain.) > > In such a case, either the UA should be using the domain of the access > network when constructing dial strings, or else the access network > should have a business relationship with the home network that is > sufficient for the access network to claim responsibility for the domain > of the R-URI. > > Paul > > Brian Rosen wrote: > > I think that if you look, you can find proxies that will break anything > we > > can define. No matter what we specify, there is sure to be a proxy out > > there that breaks it. For example, there are proxies that strip any > header > > they don't recognize. They aren't supposed to, but they do. > > > > It's futile to try and define any new behavior based on what non > standard > > existing proxies will do. In this case, they will have to recognize > > emergency calls and do the appropriate processing of them. > > > > The test function would find these things, of course. > > > > Brian > > > > > >> -----Original Message----- > >> From: Richard Barnes [mailto:rbarnes@bbn.com] > >> Sent: Monday, September 10, 2007 8:42 AM > >> To: Hannes Tschofenig > >> Cc: IETF SIP List; ECRIT > >> Subject: [Sip] Re: [Ecrit] Service URN Usage (UA Loose Routing) > >> > >> Hannes, > >> > >> I'm still worried that because we're using the routing fields for > >> marking, there's a risk that proxies will do things to those headers > >> that will remove the marking and cause the emergency call to fail. > >> > >> For instance, I've heard tell that some proxies like to strip all Route > >> headers from INVITE messages passing through them. In your example > >> below, that would cause the call to need another LoST lookup, which may > >> be impossible if no subsequent proxy supports LoST, or if there's no > >> proxy-readable location in the INVITE. Moreover, if a proxy changes > the > >> To field or the Request URI, then downstream proxies might not even > >> recognize that a LoST lookup is required and thus would cause the call > >> to fail. > >> > >> I don't disagree with the three abstract states you've defined > >> (unrecognized, recognized but not routed, and routed), but I would > >> prefer that (1) The Service URN were carried in an explicit marking > >> field even if a new one has to be created (say, Requested-Service), and > >> that (2) after routing (LoST) a call looks like any other call to a > PSAP > >> URI, but with an explicit marking. I think this would be much more in > >> the spirit of minimal surprise. > >> > >> --Richard > >> > >> > >> > >> Hannes Tschofenig wrote: > >>> Hi all, > >>> > >>> after some discussions on the usage of the Service URN it seems that > >>> most people in ECRIT agreed to move forward with the initially planned > >>> approach. Below, you can find a description of how the Service URN > would > >>> be used in various scenarios. > >>> > >>> Are there any objections? > >>> > >>> Ciao > >>> Hannes > >>> > >>> --------------------- > >>> > >>> == End Host Procedures == > >>> > >>> * UA does not recognize the emergency call. > >>> > >>> To: Dial String > >>> Request URI: Dial String > >>> No Route header > >>> > >>> * UA runs LoST and determines the PSAP URI: > >>> > >>> Request URI: Service URN > >>> To: Service URN > >>> Route Header: PSAP URI > >>> > >>> * UA does not run LoST but recognizes the emergency call. > >>> > >>> Request URI: Service URN > >>> To: Service URN > >>> No Route header > >>> > >>> > >>> == Proxy Procedures == > >>> > >>> * Incoming request contains Service URN; Proxy runs LoST > >>> > >>> and determines the PSAP URI > >>> > >>> --- Input: > >>> > >>> Request URI: Service URN > >>> To: Service URN > >>> No Route header > >>> > >>> --- Output: > >>> > >>> Request URI: Service URN > >>> To: Service URN > >>> Route Header: PSAP URI > >>> > >>> * Incoming request contains Dial String; Proxy runs LoST > >>> > >>> and determines the PSAP URI: > >>> > >>> --- Input: > >>> > >>> Request URI: Dial String > >>> To: Dial String > >>> No Route header > >>> > >>> --- Output: > >>> > >>> Request URI: Service URN > >>> To: Dial String > >>> Route Header: PSAP URI > >>> > >>> > >>> > >>> Remark: "Dial String" refers to http://tools.ietf.org/html/rfc4967 > >>> > >>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/ecrit > >>> > >>> > >> > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > > > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 11 06:16:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV2lf-0000gb-Sl; Tue, 11 Sep 2007 06:14:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV2lf-0000gG-6Y for ecrit@ietf.org; Tue, 11 Sep 2007 06:14:51 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IV2le-0007aG-9d for ecrit@ietf.org; Tue, 11 Sep 2007 06:14:50 -0400 Received: (qmail invoked by alias); 11 Sep 2007 10:14:48 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp029) with SMTP; 11 Sep 2007 12:14:48 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19ttlJiVyVtClVrD5Pel+VcjQL3IvFhJsKitcUO/f y7Pg8KDS3trqKc Message-ID: <46E66A98.3080808@gmx.net> Date: Tue, 11 Sep 2007 12:14:48 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Service URN Usage (UA Loose Routing) References: <46E4F078.4070402@gmx.net> <020501c7f3a9$495b6ee0$640fa8c0@cis.neustar.com> In-Reply-To: <020501c7f3a9$495b6ee0$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian, ~snip~ >> Also, in the ECRIT documentation, I think you should indicate that your >> solution does not work with MGCs that route the destination number based >> on the Request-URI (that is not an IMS specific MGC behavior). >> > That is correct. None of ecrit works with TN based routing. In the U.S. i3 > system, it would be required that the MGC arrange a TN to location > translation, followed by a LoST query to obtain a PSAP URI and routing per > normal SIP standards towards the PSAP. > > The incoming SIP call will need the Route header in i3 unless we decide to > accept the IMS alternative. The current version of the i3 specification > does not. > > Do you think we should mention this in the framework document? Ciao hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 11 08:24:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV4lM-0007aR-PQ; Tue, 11 Sep 2007 08:22:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV4lL-0007aL-Qv for ecrit@ietf.org; Tue, 11 Sep 2007 08:22:39 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV4lL-0002XO-Gs for ecrit@ietf.org; Tue, 11 Sep 2007 08:22:39 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IV4lE-0000Xt-56; Tue, 11 Sep 2007 07:22:32 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" References: <46E4F078.4070402@gmx.net> <020501c7f3a9$495b6ee0$640fa8c0@cis.neustar.com> <46E66A98.3080808@gmx.net> Subject: RE: [Ecrit] Service URN Usage (UA Loose Routing) Date: Tue, 11 Sep 2007 08:22:35 -0400 Message-ID: <040001c7f46e$7135f550$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acf0XJbymEyKaxKTRsyxumhCOe6yzwAEbmuw In-Reply-To: <46E66A98.3080808@gmx.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org No, I think TN based routing is national-variant defined, and out of scope for this work. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, September 11, 2007 6:15 AM > To: Brian Rosen > Cc: 'Christer Holmberg (JO/LMF)'; 'ECRIT' > Subject: Re: [Ecrit] Service URN Usage (UA Loose Routing) > > Hi Brian, > > ~snip~ > >> Also, in the ECRIT documentation, I think you should indicate that your > >> solution does not work with MGCs that route the destination number > based > >> on the Request-URI (that is not an IMS specific MGC behavior). > >> > > That is correct. None of ecrit works with TN based routing. In the > U.S. i3 > > system, it would be required that the MGC arrange a TN to location > > translation, followed by a LoST query to obtain a PSAP URI and routing > per > > normal SIP standards towards the PSAP. > > > > The incoming SIP call will need the Route header in i3 unless we decide > to > > accept the IMS alternative. The current version of the i3 specification > > does not. > > > > > > Do you think we should mention this in the framework document? > > Ciao > hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 11 08:30:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV4rX-0005sE-Bq; Tue, 11 Sep 2007 08:29:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV4rV-0005ow-Jy for ecrit@ietf.org; Tue, 11 Sep 2007 08:29:01 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IV4rU-0002hi-Vf for ecrit@ietf.org; Tue, 11 Sep 2007 08:29:01 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 51DD920052; Tue, 11 Sep 2007 14:28:58 +0200 (CEST) X-AuditID: c1b4fb3c-aee7cbb0000007e1-61-46e68a0a829d Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3BADE2059F; Tue, 11 Sep 2007 14:28:58 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Sep 2007 14:28:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Service URN Usage (UA Loose Routing) Date: Tue, 11 Sep 2007 14:28:57 +0200 Message-ID: In-Reply-To: <040001c7f46e$7135f550$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Service URN Usage (UA Loose Routing) Thread-Index: Acf0XJbymEyKaxKTRsyxumhCOe6yzwAEbmuwAAA5rKA= References: <46E4F078.4070402@gmx.net> <020501c7f3a9$495b6ee0$640fa8c0@cis.neustar.com> <46E66A98.3080808@gmx.net> <040001c7f46e$7135f550$640fa8c0@cis.neustar.com> From: "Christer Holmberg (JO/LMF)" To: "Brian Rosen" , "Hannes Tschofenig" X-OriginalArrivalTime: 11 Sep 2007 12:28:57.0808 (UTC) FILETIME=[53381500:01C7F46F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi, I think it should be mentioned. Because, whether it's in the scope or not, I think it is an important thing to note. Regards, Christer =20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: 11. syyskuuta 2007 15:23 > To: 'Hannes Tschofenig' > Cc: Christer Holmberg (JO/LMF); 'ECRIT' > Subject: RE: [Ecrit] Service URN Usage (UA Loose Routing) >=20 > No, I think TN based routing is national-variant defined, and=20 > out of scope for this work. >=20 > Brian >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Tuesday, September 11, 2007 6:15 AM > > To: Brian Rosen > > Cc: 'Christer Holmberg (JO/LMF)'; 'ECRIT' > > Subject: Re: [Ecrit] Service URN Usage (UA Loose Routing) > >=20 > > Hi Brian, > >=20 > > ~snip~ > > >> Also, in the ECRIT documentation, I think you should=20 > indicate that=20 > > >> your solution does not work with MGCs that route the destination=20 > > >> number > > based > > >> on the Request-URI (that is not an IMS specific MGC behavior). > > >> > > > That is correct. None of ecrit works with TN based=20 > routing. In the > > U.S. i3 > > > system, it would be required that the MGC arrange a TN to=20 > location=20 > > > translation, followed by a LoST query to obtain a PSAP URI and=20 > > > routing > > per > > > normal SIP standards towards the PSAP. > > > > > > The incoming SIP call will need the Route header in i3 unless we=20 > > > decide > > to > > > accept the IMS alternative. The current version of the i3=20 > > > specification does not. > > > > > > > >=20 > > Do you think we should mention this in the framework document? > >=20 > > Ciao > > hannes >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 11 08:49:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV59B-0004Ek-6c; Tue, 11 Sep 2007 08:47:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV598-0004Ea-RH for ecrit@ietf.org; Tue, 11 Sep 2007 08:47:15 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV597-0001Zc-IM for ecrit@ietf.org; Tue, 11 Sep 2007 08:47:14 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IV590-00041q-7D; Tue, 11 Sep 2007 07:47:06 -0500 From: "Brian Rosen" To: "'Christer Holmberg \(JO/LMF\)'" , "'Hannes Tschofenig'" References: <46E4F078.4070402@gmx.net> <020501c7f3a9$495b6ee0$640fa8c0@cis.neustar.com> <46E66A98.3080808@gmx.net> <040001c7f46e$7135f550$640fa8c0@cis.neustar.com> Subject: RE: [Ecrit] Service URN Usage (UA Loose Routing) Date: Tue, 11 Sep 2007 08:47:10 -0400 Message-ID: <040501c7f471$dffab5e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acf0XJbymEyKaxKTRsyxumhCOe6yzwAEbmuwAAA5rKAAAG7doA== In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Okay, I can't see any harm. I'll put it in. Something like: There are many legacy telephone networks which will persist long after most systems have been upgraded to IP origination and termination of emergency calls. There will be PSAPs which require new systems to terminate to existing mechanisms for some time. Many of these legacy systems use telephone number based routing. Gateways and conversions between existing systems and newer systems defined by this document will be required. Since existing systems are governed primarily by local government regulations and national standards, the gateway and conversion details will be governed by national standards and thus are out of scope for this document. Brian > -----Original Message----- > From: Christer Holmberg (JO/LMF) [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, September 11, 2007 8:29 AM > To: Brian Rosen; Hannes Tschofenig > Cc: ECRIT > Subject: RE: [Ecrit] Service URN Usage (UA Loose Routing) > > > Hi, > > I think it should be mentioned. Because, whether it's in the scope or > not, I think it is an important thing to note. > > Regards, > > Christer > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: 11. syyskuuta 2007 15:23 > > To: 'Hannes Tschofenig' > > Cc: Christer Holmberg (JO/LMF); 'ECRIT' > > Subject: RE: [Ecrit] Service URN Usage (UA Loose Routing) > > > > No, I think TN based routing is national-variant defined, and > > out of scope for this work. > > > > Brian > > > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: Tuesday, September 11, 2007 6:15 AM > > > To: Brian Rosen > > > Cc: 'Christer Holmberg (JO/LMF)'; 'ECRIT' > > > Subject: Re: [Ecrit] Service URN Usage (UA Loose Routing) > > > > > > Hi Brian, > > > > > > ~snip~ > > > >> Also, in the ECRIT documentation, I think you should > > indicate that > > > >> your solution does not work with MGCs that route the destination > > > >> number > > > based > > > >> on the Request-URI (that is not an IMS specific MGC behavior). > > > >> > > > > That is correct. None of ecrit works with TN based > > routing. In the > > > U.S. i3 > > > > system, it would be required that the MGC arrange a TN to > > location > > > > translation, followed by a LoST query to obtain a PSAP URI and > > > > routing > > > per > > > > normal SIP standards towards the PSAP. > > > > > > > > The incoming SIP call will need the Route header in i3 unless we > > > > decide > > > to > > > > accept the IMS alternative. The current version of the i3 > > > > specification does not. > > > > > > > > > > > > > > Do you think we should mention this in the framework document? > > > > > > Ciao > > > hannes > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 12 11:11:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVTqD-0005Yk-Up; Wed, 12 Sep 2007 11:09:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVTqC-0005YR-V5 for ecrit@ietf.org; Wed, 12 Sep 2007 11:09:20 -0400 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 1IVTqB-0001KX-No for ecrit@ietf.org; Wed, 12 Sep 2007 11:09:20 -0400 X-IronPort-AV: E=Sophos;i="4.20,245,1186383600"; d="scan'208";a="17601697" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 12 Sep 2007 08:09:19 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8CF9Jqa004893; Wed, 12 Sep 2007 08:09:19 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l8CF9Iau022814; Wed, 12 Sep 2007 15:09:18 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <86B76B24-6663-4C46-B25D-69BC961C90D4@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Wed, 12 Sep 2007 08:07:46 -0700 To: ECRIT X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=337; t=1189609759; x=1190473759; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Some=20documents=20from=20DSL=20Forum |Sender:=20; bh=slgXJZjPFKmIPlIOxFX1Pg+pzgsn+UYxaL6zRQazqTE=; b=b3oQ9Ba1AcyJ1nQTdvMI3Hg+EOLwTC+lhriUqcV0PbBXCLMxz8liloIRK+Xj91VRMBxMLDXO p7hpetvn3T5ix0c98elJla+IVyX6Jm1KzM3/Xme9aWnxTxNVvlYzFaEj; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ecrit] Some documents from DSL Forum X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This message was also sent to GEOPRIV but please only reply to one list. In my IETF AD Role I received some documents from DSL Forum that are of relevant to this WG. I have posted them at: http://www.dial911anddie.com/DSLForum/WT-164v2.pdf and http://www.dial911anddie.com/DSLForum/WT-164v2-xls.pdf Thanks, Cullen _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 12 16:31:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVYpu-0003bh-77; Wed, 12 Sep 2007 16:29:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVYps-0003bM-Vg for ecrit@ietf.org; Wed, 12 Sep 2007 16:29:21 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVYps-00075c-CI for ecrit@ietf.org; Wed, 12 Sep 2007 16:29:20 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IVYpr-0002Iz-4H for ecrit@ietf.org; Wed, 12 Sep 2007 16:29:19 -0400 Message-ID: <46E84C1C.8010700@bbn.com> Date: Wed, 12 Sep 2007 16:29:16 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Subject: [Ecrit] Emergency call 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'd like to get back to the topic of emergency call authentication, that is, the question of how a third party (e.g., a proxy) that receives an INVITE can verify that that INVITE is an emergency call. ----- Short version ----- Problem: Proxies that provide special considerations to emergency calls want to ensure that non-emergency calls (i.e., calls that aren't going to a PSAP) don't receive those special considerations. Solution: If proxies trust down-stream proxies to do LoST routing, then they can assume that non-LoST-routed calls are OK. If proxies trust the LoST infrastructure, and if entities that do LoST routing include the location they used for that routing in the INVITE, then any other party can verify that the INVITE is addressed to a PSAP. ----- Long version ----- I'd like to get back to the topic of emergency call authentication, that is, the question of how a third party (e.g., a proxy) that receives an INVITE can verify that that INVITE is an emergency call. Note that what's being authenticated here whether the call is an emergency call or not -- not the identity of either party. The challenge here is to provide assurance to proxies that a call that looks like an emergency call is actually routed to a PSAP. First, some assumptions: A1. Each proxy trusts downstream proxies to do SIP routing A2. Each proxy trusts downstream proxies to do LoST routing A3. Provided that a seeker can query any LoST server he chooses, the LoST infrastructure is trusted to provide accurate mappings. A4. Verification does not need to be a real-time operation For reference, I'll paraphrase Hannes' email on call marking (non-verifiably asserting emergency status). An INVITE message for an emergency call can be of one of three types: 1. Unrecognized (no Service URN or PSAP URI) 2. Recognized, but not routed (Service URN, but no PSAP URI) 3. Recognized and routed (Service URN and PSAP URI) Endpoints or proxies use dial string recognition to upgrade calls from type 1 to type 2, and LoST to upgrade from type 2 to type 3. INVITEs of type 1 and type 2 do not present a fraud risk: 1. If a proxy receives an INVITE of type 1 and doesn't do dial string interpretation (i.e., can't upgrade it to type 2), then it has no idea that the call is an emergency call. Hence, fraud is not an issue, since the call has no chance of getting special consideration. 2. If a proxy receives an INVITE of type 2, or upgrades an INVITE to type 2, then it's aware that the call claims to be an emergency call. So as long as it trusts down-stream proxies to do LoST correctly (A2), the proxy is assured that the call will be delivered to a PSAP. Absent verification, INVITEs of type 3 can be used for fraudulent calls by constructing an INVITE that has the same markings as an emergency call, but is addressed to a URI that is not a PSAP URI. So we need to define a verification procedure for type 3 INVITES, and assure that all type 3 invites have the information required for verification. One can verify that a URI is a PSAP URI by obtaining it as a element in a LoST mapping. Given assumptions (A1, A3), an INVITE addressed to a URI verified in this way must be addressed to a PSAP. More precisely, to verify that an INVITE is addressed to a PSAP: 1. Extract location information and a service URN from the INVITE 2. Do a LoST findService query with that location and URN 3. If the INVITE is addressed to one of the URIs returned in the mapping, then the call is verified. This procedure can be used to verify an INVITE as long as it contains location information with good enough accuracy for routing (a URN is not strictly necessary, since the set of all available URNs can be obtained by the verifier with a listServiceByLocation query). However, we're talking about type 3 INVITEs, ones that have already been LoST-routed. That means that the entity that did the routing had a LoST mapping for this URI, which means that they definitely have a service boundary for the PSAP. If that entity did the lookup to get the mapping, they also know what location was used in the findService query. So as long as entities that upgrade calls to type 3 (i.e., that do LoST routing) always include one of these locations (SB or input) in the INVITE, the INVITE will always contain enough information to verify that the call is addressed to a PSAP. To summarize, under the assumptions above, -- Type 1 and 2 calls cannot be used to fraudulently obtain special services given to emergency calls. -- Entities that do LoST routing MUST include either the location input to LoST or the service boundary of the PSAP. -- Given the above, proxies can always verify whether a call is going to a PSAP or not. Looking at the length of this email, I suppose it should be a separate document. I'll get to work on draft-barnes-ecrit-auth-01... --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 12 17:04:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVZMf-0002nD-0q; Wed, 12 Sep 2007 17:03:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVZMe-0002n2-1s for ecrit@ietf.org; Wed, 12 Sep 2007 17:03:12 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVZMd-0007lP-Oc for ecrit@ietf.org; Wed, 12 Sep 2007 17:03:11 -0400 X-IronPort-AV: E=Sophos;i="4.20,246,1186383600"; d="scan'208";a="216997711" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 12 Sep 2007 14:03:11 -0700 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 l8CL3BOV008479; Wed, 12 Sep 2007 14:03:11 -0700 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 l8CL32F0019756; Wed, 12 Sep 2007 21:03:06 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 14:03:02 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.90.244]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Sep 2007 14:03:02 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 12 Sep 2007 16:03:01 -0500 To: Richard Barnes , ECRIT From: "James M. Polk" Subject: Re: [Ecrit] Emergency call marking In-Reply-To: <46E84C1C.8010700@bbn.com> References: <46E84C1C.8010700@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 12 Sep 2007 21:03:02.0737 (UTC) FILETIME=[4EA47C10:01C7F580] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=717; t=1189630991; x=1190494991; 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]=20Emergency=20call=20marking |Sender:=20; bh=Xbr2PxJF6/zFMI2CHKI/OlIL+oX2zmwWlQRZZYoKUpM=; b=xduYjCZc4Sc3sdYK6dboE8lhZtNZ5zgzIIzpor/DniVs53aRaL78/iokon1UWIeuOgujejSo zZ+8pM0KVK2RZtl8S8tiW+bGv9TU5Z3ZTA++v4U4yko/xkAgwPxa3yWP; 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: d6b246023072368de71562c0ab503126 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 03:29 PM 9/12/2007, Richard Barnes wrote: >Problem: >Proxies that provide special considerations to emergency calls want >to ensure that non-emergency calls (i.e., calls that aren't going to >a PSAP) don't receive those special considerations. > >Solution: shouldn't the simple solution be for said proxy (and all other proxies) to simply not provide special treatment to a non-emergency SIP request? In other words, IF a proxy identifies a SIP request as an emergency request, provide it whatever treatment is afforded emergency request (a local policy decision), ELSE treat as any other SIP request (normal treatment). I don't like the use of the word "verify" in the original email. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 12 17:24:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVZfT-0006xX-SJ; Wed, 12 Sep 2007 17:22:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVZfS-0006rV-Qv for ecrit@ietf.org; Wed, 12 Sep 2007 17:22:38 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVZfR-000217-La for ecrit@ietf.org; Wed, 12 Sep 2007 17:22:38 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IVZfR-0006vD-47; Wed, 12 Sep 2007 17:22:37 -0400 Message-ID: <46E85899.9040701@bbn.com> Date: Wed, 12 Sep 2007 17:22:33 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] Emergency call marking References: <46E84C1C.8010700@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org James, The problem is how the proxy is able to reliably tell which SIP requests are emergency SIP requests. That is, if a proxy is looking at a SIP request, how does it verify that the request is an emergency request. --Richard James M. Polk wrote: > At 03:29 PM 9/12/2007, Richard Barnes wrote: >> Problem: >> Proxies that provide special considerations to emergency calls want to >> ensure that non-emergency calls (i.e., calls that aren't going to a >> PSAP) don't receive those special considerations. >> >> Solution: > > shouldn't the simple solution be for said proxy (and all other proxies) > to simply not provide special treatment to a non-emergency SIP request? > > In other words, IF a proxy identifies a SIP request as an emergency > request, provide it whatever treatment is afforded emergency request (a > local policy decision), ELSE treat as any other SIP request (normal > treatment). > > I don't like the use of the word "verify" in the original email. > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 12 18:01:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVaFQ-0007HZ-MB; Wed, 12 Sep 2007 17:59:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVaFO-0007HS-99 for ecrit@ietf.org; Wed, 12 Sep 2007 17:59:46 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IVaFN-0000Mn-G4 for ecrit@ietf.org; Wed, 12 Sep 2007 17:59:46 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IVaFP-0005UL-L3; Wed, 12 Sep 2007 16:59:48 -0500 From: "Brian Rosen" To: "'Richard Barnes'" , "'ECRIT'" References: <46E84C1C.8010700@bbn.com> Subject: RE: [Ecrit] Emergency call marking Date: Wed, 12 Sep 2007 17:59:41 -0400 Message-ID: <076c01c7f588$3a51b860$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acf1e+G336ysLZdiQ+GR/fXE6p6u8gAC6MVA In-Reply-To: <46E84C1C.8010700@bbn.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think we have to relate this to "location hiding". While the notion that a proxy wants to know that a call purporting to be an emergency call is indeed an emergency call is useful independent of location hiding, I think the location hiding problem interacts with this problem so much that the solutions for both need to be forged at the same time. I do think that there are some problems with downstream LoST routing, but the problem is internal to a carrier (like, they don't allow non telephone number URIs for anything). I guess that means it's not relevant to the discussion, but we might make sure of that. Generally, I think that verification by looking up location via LoST to validate that the Route has a valid PSAP URI is a reasonable way to go, but you can see that if that is the case, and the location in the call is a reference, then the LIS has to give the proxy location that will yield the same URI that the UA got, and then we are into the location hiding problem. Brian > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Wednesday, September 12, 2007 4:29 PM > To: ECRIT > Subject: [Ecrit] Emergency call marking > > I'd like to get back to the topic of emergency call authentication, that > is, the question of how a third party (e.g., a proxy) that receives an > INVITE can verify that that INVITE is an emergency call. > > ----- Short version ----- > > Problem: > Proxies that provide special considerations to emergency calls want to > ensure that non-emergency calls (i.e., calls that aren't going to a > PSAP) don't receive those special considerations. > > Solution: > > If proxies trust down-stream proxies to do LoST routing, then they can > assume that non-LoST-routed calls are OK. > > If proxies trust the LoST infrastructure, and if entities that do LoST > routing include the location they used for that routing in the INVITE, > then any other party can verify that the INVITE is addressed to a PSAP. > > ----- Long version ----- > > I'd like to get back to the topic of emergency call authentication, that > is, the question of how a third party (e.g., a proxy) that receives an > INVITE can verify that that INVITE is an emergency call. Note that > what's being authenticated here whether the call is an emergency call or > not -- not the identity of either party. The challenge here is to > provide assurance to proxies that a call that looks like an emergency > call is actually routed to a PSAP. > > First, some assumptions: > A1. Each proxy trusts downstream proxies to do SIP routing > A2. Each proxy trusts downstream proxies to do LoST routing > A3. Provided that a seeker can query any LoST server he chooses, the > LoST infrastructure is trusted to provide accurate mappings. > A4. Verification does not need to be a real-time operation > > For reference, I'll paraphrase Hannes' email on call marking > (non-verifiably asserting emergency status). An INVITE message for an > emergency call can be of one of three types: > 1. Unrecognized (no Service URN or PSAP URI) > 2. Recognized, but not routed (Service URN, but no PSAP URI) > 3. Recognized and routed (Service URN and PSAP URI) > Endpoints or proxies use dial string recognition to upgrade calls from > type 1 to type 2, and LoST to upgrade from type 2 to type 3. > > INVITEs of type 1 and type 2 do not present a fraud risk: > 1. If a proxy receives an INVITE of type 1 and doesn't do dial string > interpretation (i.e., can't upgrade it to type 2), then it has no idea > that the call is an emergency call. Hence, fraud is not an issue, since > the call has no chance of getting special consideration. > 2. If a proxy receives an INVITE of type 2, or upgrades an INVITE to > type 2, then it's aware that the call claims to be an emergency call. > So as long as it trusts down-stream proxies to do LoST correctly (A2), > the proxy is assured that the call will be delivered to a PSAP. > > Absent verification, INVITEs of type 3 can be used for fraudulent calls > by constructing an INVITE that has the same markings as an emergency > call, but is addressed to a URI that is not a PSAP URI. So we need to > define a verification procedure for type 3 INVITES, and assure that all > type 3 invites have the information required for verification. > > One can verify that a URI is a PSAP URI by obtaining it as a > element in a LoST mapping. Given assumptions (A1, A3), an INVITE > addressed to a URI verified in this way must be addressed to a PSAP. > More precisely, to verify that an INVITE is addressed to a PSAP: > 1. Extract location information and a service URN from the INVITE > 2. Do a LoST findService query with that location and URN > 3. If the INVITE is addressed to one of the URIs returned in the > mapping, then the call is verified. > This procedure can be used to verify an INVITE as long as it contains > location information with good enough accuracy for routing (a URN is not > strictly necessary, since the set of all available URNs can be obtained > by the verifier with a listServiceByLocation query). > > However, we're talking about type 3 INVITEs, ones that have already been > LoST-routed. That means that the entity that did the routing had a LoST > mapping for this URI, which means that they definitely have a service > boundary for the PSAP. If that entity did the lookup to get the > mapping, they also know what location was used in the findService query. > So as long as entities that upgrade calls to type 3 (i.e., that do LoST > routing) always include one of these locations (SB or input) in the > INVITE, the INVITE will always contain enough information to verify that > the call is addressed to a PSAP. > > To summarize, under the assumptions above, > -- Type 1 and 2 calls cannot be used to fraudulently obtain special > services given to emergency calls. > -- Entities that do LoST routing MUST include either the location input > to LoST or the service boundary of the PSAP. > -- Given the above, proxies can always verify whether a call is going to > a PSAP or not. > > > > Looking at the length of this email, I suppose it should be a separate > document. I'll get to work on draft-barnes-ecrit-auth-01... > > --Richard > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 12 19:47:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVbuN-0002xi-NX; Wed, 12 Sep 2007 19:46:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVbuM-0002xM-Go for ecrit@ietf.org; Wed, 12 Sep 2007 19:46:10 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVbuL-0004RF-BM for ecrit@ietf.org; Wed, 12 Sep 2007 19:46:10 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IVbuI-0004NA-5N; Wed, 12 Sep 2007 19:46:06 -0400 Message-ID: <46E87A37.3060003@bbn.com> Date: Wed, 12 Sep 2007 19:45:59 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Emergency call marking References: <46E84C1C.8010700@bbn.com> <076c01c7f588$3a51b860$640fa8c0@cis.neustar.com> In-Reply-To: <076c01c7f588$3a51b860$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian, > I think we have to relate this to "location hiding". That's what I thought, too, but it's not really true: Until LoST routing gets done, there's no fraud risk, and whoever does LoST routing already has to have access to location (SB or input). So the real question is not how to verifiably mark calls, but how to make sure LoST routing gets done in the location hiding use case. And that's a problem whether proxies are worried about verification or not. > I do think that there are some problems with downstream LoST routing, but > the problem is internal to a carrier ... I'd be interested to hear more about the validity of these sorts of assumptions. Do you have more detail here? > Generally, I think that verification by looking up location via LoST to > validate that the Route has a valid PSAP URI is a reasonable way to go, but > you can see that if that is the case, and the location in the call is a > reference, then the LIS has to give the proxy location that will yield the > same URI that the UA got, and then we are into the location hiding problem. Remember that whoever does LoST routing has a mapping, and that means they have a service boundary. So if the UA does the routing, it can insert the SB by value (if it doesn't have its own location), and a proxy can insert a reference to the SB. SBs are public information, so there's no privacy concerns related to these references, and they not affected by location hiding. Note that the proxy could *also* insert a reference to the UA's location that could have arbitrary access controls, and as long as the ref to the SB was there, the verification would work. So while there is still a connection between location hiding and call marking, in that location needs to be available to the entity that does the LoST query, making use of service boundaries in this way largely decouples the two problems. --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 12 22:42:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVeda-0003AR-VD; Wed, 12 Sep 2007 22:41:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVedZ-0003AL-TY for ecrit@ietf.org; Wed, 12 Sep 2007 22:41:01 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVedY-0007sh-Kz for ecrit@ietf.org; Wed, 12 Sep 2007 22:41:01 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IVedq-0006rW-Nz; Wed, 12 Sep 2007 21:41:18 -0500 From: "Brian Rosen" To: "'Richard Barnes'" References: <46E84C1C.8010700@bbn.com> <076c01c7f588$3a51b860$640fa8c0@cis.neustar.com> <46E87A37.3060003@bbn.com> Subject: RE: [Ecrit] Emergency call marking Date: Wed, 12 Sep 2007 22:40:57 -0400 Message-ID: <079201c7f5af$84cd56c0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acf1lyHXF146Hjx6Rgi04HNcA6/agAAFTfQQ In-Reply-To: <46E87A37.3060003@bbn.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hmmm. Well, so, the idea you're pushing is that if you send the SB, anyone can verify the PSAP URI by picking a point in the SB and checking the PSAP URI is the same as that in the Route. Yeah, I guess. You might as well send any point inside the SB and avoid shifting work to the proxy. I think the notion that a UA can generate a reference to the SB is hard. Better to get LoST to give you one. Isn't it easier to just dereference and use that to check the PSAP URI? What does sending the SB do that dereferencing doesn't? This really makes it the location hiding LIS that has to do the work. There isn't any mechanism to send the SB. Brian > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Wednesday, September 12, 2007 7:46 PM > To: Brian Rosen > Cc: 'ECRIT' > Subject: Re: [Ecrit] Emergency call marking > > Hi Brian, > > > I think we have to relate this to "location hiding". > > That's what I thought, too, but it's not really true: Until LoST routing > gets done, there's no fraud risk, and whoever does LoST routing already > has to have access to location (SB or input). So the real question is > not how to verifiably mark calls, but how to make sure LoST routing gets > done in the location hiding use case. And that's a problem whether > proxies are worried about verification or not. > > > I do think that there are some problems with downstream LoST routing, > but > > the problem is internal to a carrier ... > > I'd be interested to hear more about the validity of these sorts of > assumptions. Do you have more detail here? > > > Generally, I think that verification by looking up location via LoST to > > validate that the Route has a valid PSAP URI is a reasonable way to go, > but > > you can see that if that is the case, and the location in the call is a > > reference, then the LIS has to give the proxy location that will yield > the > > same URI that the UA got, and then we are into the location hiding > problem. > > Remember that whoever does LoST routing has a mapping, and that means > they have a service boundary. So if the UA does the routing, it can > insert the SB by value (if it doesn't have its own location), and a > proxy can insert a reference to the SB. SBs are public information, so > there's no privacy concerns related to these references, and they not > affected by location hiding. Note that the proxy could *also* insert a > reference to the UA's location that could have arbitrary access > controls, and as long as the ref to the SB was there, the verification > would work. > > So while there is still a connection between location hiding and call > marking, in that location needs to be available to the entity that does > the LoST query, making use of service boundaries in this way largely > decouples the two problems. > > --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 13 08:29:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnof-0001OT-LD; Thu, 13 Sep 2007 08:29:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVnoe-0001OK-Jn for ecrit@ietf.org; Thu, 13 Sep 2007 08:29:04 -0400 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 1IVnod-00036n-Bq for ecrit@ietf.org; Thu, 13 Sep 2007 08:29:04 -0400 X-IronPort-AV: E=Sophos;i="4.20,249,1186383600"; d="scan'208";a="17792248" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 13 Sep 2007 05:29:03 -0700 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/8.12.11) with ESMTP id l8DCT2tY028061; Thu, 13 Sep 2007 05:29:02 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8DCSZob029305; Thu, 13 Sep 2007 12:29:01 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 08:28:38 -0400 Received: from mlinsnerwxp ([10.82.170.69]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Sep 2007 08:28:37 -0400 From: "Marc Linsner" To: "'Richard Barnes'" Subject: RE: [Ecrit] Emergency call marking Date: Thu, 13 Sep 2007 08:28:37 -0400 Message-ID: <004b01c7f601$9c399c90$220d0d0a@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.3138 Thread-Index: Acf1ly+NWEggNAwdTLKP0eAjTgxTqwAaDmCQ In-Reply-To: <46E87A37.3060003@bbn.com> X-OriginalArrivalTime: 13 Sep 2007 12:28:38.0057 (UTC) FILETIME=[9C45D190:01C7F601] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2802; t=1189686542; x=1190550542; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20Emergency=20call=20marking |Sender:=20; bh=LWsLOz2OjXQb0ps6Vy5aDkNotBlBrloFv7Y6dfGDFv4=; b=xJ9L+XPVpR2mzxI9AWsJ0F+4y/yRz+MobNIem62e3RuBy2cVgQEGGIJOCvcPW8dKnjUrkA6l pdkjj/px1Vh9xk5H58he0U75ZGeLuxrXIwzxdYCTLwB7jrDjFjFgnNHf; Authentication-Results: sj-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Richard, I'm still confused as to the problem you are trying to solve? Is this a real problem, as in a proxy operator has brought us requirements? I'm hanging on the earlier discussion that if a UA does LoST lookup/emergency call routing, then the VoIP SP can't/won't be able to 'verify' that the session is in fact an emergency call. What is the down side of a VoIP SP not recognizing an emergency call? The customer pays for the call? (Isn't per-ding billing on a downward trend?) I'm trying to figure out why we're putting energy into this. Thanks, -Marc- > > I think we have to relate this to "location hiding". > > That's what I thought, too, but it's not really true: Until > LoST routing gets done, there's no fraud risk, and whoever > does LoST routing already has to have access to location (SB > or input). So the real question is not how to verifiably > mark calls, but how to make sure LoST routing gets done in > the location hiding use case. And that's a problem whether > proxies are worried about verification or not. > > > I do think that there are some problems with downstream > LoST routing, > > but the problem is internal to a carrier ... > > I'd be interested to hear more about the validity of these > sorts of assumptions. Do you have more detail here? > > > Generally, I think that verification by looking up location > via LoST > > to validate that the Route has a valid PSAP URI is a > reasonable way to > > go, but you can see that if that is the case, and the > location in the > > call is a reference, then the LIS has to give the proxy > location that > > will yield the same URI that the UA got, and then we are > into the location hiding problem. > > Remember that whoever does LoST routing has a mapping, and > that means they have a service boundary. So if the UA does > the routing, it can insert the SB by value (if it doesn't > have its own location), and a proxy can insert a reference to > the SB. SBs are public information, so there's no privacy > concerns related to these references, and they not affected > by location hiding. Note that the proxy could *also* insert > a reference to the UA's location that could have arbitrary > access controls, and as long as the ref to the SB was there, > the verification would work. > > So while there is still a connection between location hiding > and call marking, in that location needs to be available to > the entity that does the LoST query, making use of service > boundaries in this way largely decouples the two problems. > > --Richard > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 14 09:17:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWB2Z-0002to-RH; Fri, 14 Sep 2007 09:16:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWB2Y-0002td-E8 for ecrit@ietf.org; Fri, 14 Sep 2007 09:16:58 -0400 Received: from fk-out-0910.google.com ([209.85.128.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWB2X-0005Vn-7v for ecrit@ietf.org; Fri, 14 Sep 2007 09:16:58 -0400 Received: by fk-out-0910.google.com with SMTP id z23so757486fkz for ; Fri, 14 Sep 2007 06:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=8kDhk6NoFk+cOE2sKWWx5dADYMADkCABj8wod33Yh6E=; b=iMQ5lfZhkMOyJZMuE4noK9RP/TsAj2eN4+TUio1j6r3x2G/z1f8Xsl9dlhLm+V1orfbI3sedfiFfjYWTDwjXqLzjafTa1x9NRgtq3nQCfGRmsjG9Ig6d2UyHi0+d4YtjIRVpg1RUhnXZqGvuA8eEWaFqUC9NLZphwLpg8jRjohY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=j7lzXSkVd+2vCPtcc6j5ZGaReeITUPJdSyU3QVGvMmAbdac8uG9J58SN0B4k9WLy7nlacR2wg2RblW3Ax85JwaD2EafAsW2puW8UGLFsRK/jbSkjarDmBFFM4w7aEtJ5D6ZID2xTPQFcuO5n0R+SwDSTbfa7PASnzu01m/+BWOA= Received: by 10.82.152.16 with SMTP id z16mr2423589bud.1189775816158; Fri, 14 Sep 2007 06:16:56 -0700 (PDT) Received: by 10.82.182.16 with HTTP; Fri, 14 Sep 2007 06:16:56 -0700 (PDT) Message-ID: Date: Fri, 14 Sep 2007 15:16:56 +0200 From: "Karl Heinz Wolf" To: ecrit@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Ecrit] what happend to ecrit-implementers mailinglist? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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 just noticed that the list ecrit-implementers is not available any more. Why was it deactivated and where to post implemenation-realated topics now? thanks, karl heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 14 18:18:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJUF-00086V-Oz; Fri, 14 Sep 2007 18:18:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWJUD-00086N-Ro for ecrit@ietf.org; Fri, 14 Sep 2007 18:18:06 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IWJUC-0005JJ-Fr for ecrit@ietf.org; Fri, 14 Sep 2007 18:18:05 -0400 X-IronPort-AV: E=Sophos;i="4.20,257,1186383600"; d="scan'208";a="399274421" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 14 Sep 2007 15:18:04 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8EMI3OF004347; Fri, 14 Sep 2007 15:18:03 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8EMHwub001562; Fri, 14 Sep 2007 22:17:59 GMT 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); Fri, 14 Sep 2007 15:17:58 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.113.186]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 15:17:57 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 14 Sep 2007 17:17:52 -0500 To: "Brian Rosen" , "'Richard Barnes'" From: "James M. Polk" Subject: RE: [Ecrit] Emergency call marking In-Reply-To: <079201c7f5af$84cd56c0$640fa8c0@cis.neustar.com> References: <46E84C1C.8010700@bbn.com> <076c01c7f588$3a51b860$640fa8c0@cis.neustar.com> <46E87A37.3060003@bbn.com> <079201c7f5af$84cd56c0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 14 Sep 2007 22:17:57.0899 (UTC) FILETIME=[1ACB45B0:01C7F71D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4402; t=1189808283; x=1190672283; c=relaxed/simple; s=sjdkim1004; 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]=20Emergency=20call=20marking |Sender:=20; bh=lqkSAF5NR8oQn7yK5mlG9kozs1mR+rgJetABH222ACc=; b=dsYETaTGXsgiraytaSzNMzFg030C0krZXT8ePsHvpHreb5nb92mgpuX3PFBrmgFAj1NvCRbi F+eMGuZzOD9kgpyMf2kaLkuYddt+hQ1aA3Ugx1WkvHF1no9w8ahavG5mFSLq6cXaG7rgGas79Y UtQZ9KpmUyKn7fGqFR1N0O+Yk=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Aren't we conflating at least two, if not three issues here? What does this thread have to do with the Subject line "Emergency call marking"? "Marking" is the indication within a SIP request that the request is an emergency (bound) request. I'm confused as to what the words "verification" and "validate" mean in this context - as used by Richard, especially with regard to *any* proxy, not just an ESRP. Not every proxy has to understand emergency calling. The phoneBCP will not become an update to 3261 as mandatory to implement. I'm even more confused what "Emergency call marking" has to do with "location hiding". If my UA generates a static PSAP URI as an R-URI in an INVITE, the request must get to that PSAP (or the ESInet in front of said PSAP) with or without location (civic/geo or a locationURI). If there is an ESInet in front of that PSAP, there is an ESRP at the border. If there is a 911 or 112 dialstring or the service urn sos, the "Emergency call marking" is achieved by the ESRP by seeing this in the request. That's simple to do. Local policy will instruct the ESRP what to do with the request if there is no such marking. At 09:40 PM 9/12/2007, Brian Rosen wrote: >Hmmm. Well, so, the idea you're pushing is that if you send the SB, anyone >can verify the PSAP URI by picking a point in the SB and checking the PSAP >URI is the same as that in the Route. > >Yeah, I guess. You might as well send any point inside the SB and avoid >shifting work to the proxy. > >I think the notion that a UA can generate a reference to the SB is hard. >Better to get LoST to give you one. > >Isn't it easier to just dereference and use that to check the PSAP URI? >What does sending the SB do that dereferencing doesn't? This really makes >it the location hiding LIS that has to do the work. > >There isn't any mechanism to send the SB. > >Brian > > > -----Original Message----- > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > Sent: Wednesday, September 12, 2007 7:46 PM > > To: Brian Rosen > > Cc: 'ECRIT' > > Subject: Re: [Ecrit] Emergency call marking > > > > Hi Brian, > > > > > I think we have to relate this to "location hiding". > > > > That's what I thought, too, but it's not really true: Until LoST routing > > gets done, there's no fraud risk, and whoever does LoST routing already > > has to have access to location (SB or input). So the real question is > > not how to verifiably mark calls, but how to make sure LoST routing gets > > done in the location hiding use case. And that's a problem whether > > proxies are worried about verification or not. > > > > > I do think that there are some problems with downstream LoST routing, > > but > > > the problem is internal to a carrier ... > > > > I'd be interested to hear more about the validity of these sorts of > > assumptions. Do you have more detail here? > > > > > Generally, I think that verification by looking up location via LoST to > > > validate that the Route has a valid PSAP URI is a reasonable way to go, > > but > > > you can see that if that is the case, and the location in the call is a > > > reference, then the LIS has to give the proxy location that will yield > > the > > > same URI that the UA got, and then we are into the location hiding > > problem. > > > > Remember that whoever does LoST routing has a mapping, and that means > > they have a service boundary. So if the UA does the routing, it can > > insert the SB by value (if it doesn't have its own location), and a > > proxy can insert a reference to the SB. SBs are public information, so > > there's no privacy concerns related to these references, and they not > > affected by location hiding. Note that the proxy could *also* insert a > > reference to the UA's location that could have arbitrary access > > controls, and as long as the ref to the SB was there, the verification > > would work. > > > > So while there is still a connection between location hiding and call > > marking, in that location needs to be available to the entity that does > > the LoST query, making use of service boundaries in this way largely > > decouples the two problems. > > > > --Richard > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 15 09:51:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWY3Z-0006lH-7x; Sat, 15 Sep 2007 09:51:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWY3Y-0006l5-8O for ecrit@ietf.org; Sat, 15 Sep 2007 09:51:32 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWY3X-0006E6-D9 for ecrit@ietf.org; Sat, 15 Sep 2007 09:51:32 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IWY3p-0002dY-Uq; Sat, 15 Sep 2007 08:51:50 -0500 From: "Brian Rosen" To: "'James M. Polk'" , "'Richard Barnes'" References: <46E84C1C.8010700@bbn.com> <076c01c7f588$3a51b860$640fa8c0@cis.neustar.com> <46E87A37.3060003@bbn.com> <079201c7f5af$84cd56c0$640fa8c0@cis.neustar.com> Subject: RE: [Ecrit] Emergency call marking Date: Sat, 15 Sep 2007 09:51:28 -0400 Message-ID: <0b6501c7f79f$852391b0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acf3HSPLx0HMTgjkTeKXsKXwQGQYjgAf4jWQ In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Most proxy servers that are used for most VoIP traffic will not permit an arbitrary URI in the Request-URI, and they will police a PSAP URI out. They won't care a whole lot about To:. At the moment, they probably would police out a PSAP URI in a Route header. What we want is to have a marker that stays with the call, all the way to the PSAP. We'll have to get the proxies to watch for that marker and let the call through, but at least some carriers will demand a way to validate the PSAP URI really is a PSAP URI. The sos service URN is a marker. The question is how to preserve the marker as far as you can. With 1-1-2 in the Request URI (as a dial string) it's not an emergency call unless a proxy recognizes it as an emergency call. In lots of systems, that's hard, but its all we got if the endpoint doesn't recognize it. The reason its hard is that you have to know the location of the endpoint to figure out what the dial string(s) to recognize are. Once recognized, you want it marked with the service urn. We've vacillated on where the service urn goes, but I think Jonathan's proposal is best. That was PSAP URI in a Route header and the service urn in the Request URI. The location hiding comes in because of the need to validate the PSAP URI. I think we're all okay with the notion that we can trust the LoST server to only have bona fide PSAP URIs in it. If you can do a query to LoST and get the URI in the Route header, that is sufficient validation. There are other ways to do that, one of which Richard proposed, which let the call through to the URI but require the PSAP to do something that the proxy would recognize as only possible from a bona fide PSAP. That works, but so far, the only thing proposed needed a global emergency services PKI or something that was roughly as trusted as the forest guides that propagated information that could be used to validate the domain. Either is more spec work and burdens elements that don't give a hoot about location hiding. The advantage of the LoST query idea was it was just words in the BCP, and code in the LIS that wants to hide (and the same code in the proxy that wants to validate as it would have for the non-hiding case). So, yeah, we're conflating, but for what I think is good reason. Brian > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Friday, September 14, 2007 6:18 PM > To: Brian Rosen; 'Richard Barnes' > Cc: 'ECRIT' > Subject: RE: [Ecrit] Emergency call marking > > Aren't we conflating at least two, if not three issues here? > > What does this thread have to do with the Subject line "Emergency > call marking"? > > "Marking" is the indication within a SIP request that the request is > an emergency (bound) request. I'm confused as to what the words > "verification" and "validate" mean in this context - as used by > Richard, especially with regard to *any* proxy, not just an ESRP. > > Not every proxy has to understand emergency calling. The phoneBCP > will not become an update to 3261 as mandatory to implement. > > I'm even more confused what "Emergency call marking" has to do with > "location hiding". > > If my UA generates a static PSAP URI as an R-URI in an INVITE, the > request must get to that PSAP (or the ESInet in front of said PSAP) > with or without location (civic/geo or a locationURI). If there is > an ESInet in front of that PSAP, there is an ESRP at the border. If > there is a 911 or 112 dialstring or the service urn sos, the > "Emergency call marking" is achieved by the ESRP by seeing this in > the request. That's simple to do. Local policy will instruct the > ESRP what to do with the request if there is no such marking. > > At 09:40 PM 9/12/2007, Brian Rosen wrote: > >Hmmm. Well, so, the idea you're pushing is that if you send the SB, > anyone > >can verify the PSAP URI by picking a point in the SB and checking the > PSAP > >URI is the same as that in the Route. > > > >Yeah, I guess. You might as well send any point inside the SB and avoid > >shifting work to the proxy. > > > >I think the notion that a UA can generate a reference to the SB is hard. > >Better to get LoST to give you one. > > > >Isn't it easier to just dereference and use that to check the PSAP URI? > >What does sending the SB do that dereferencing doesn't? This really > makes > >it the location hiding LIS that has to do the work. > > > >There isn't any mechanism to send the SB. > > > >Brian > > > > > -----Original Message----- > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > Sent: Wednesday, September 12, 2007 7:46 PM > > > To: Brian Rosen > > > Cc: 'ECRIT' > > > Subject: Re: [Ecrit] Emergency call marking > > > > > > Hi Brian, > > > > > > > I think we have to relate this to "location hiding". > > > > > > That's what I thought, too, but it's not really true: Until LoST > routing > > > gets done, there's no fraud risk, and whoever does LoST routing > already > > > has to have access to location (SB or input). So the real question is > > > not how to verifiably mark calls, but how to make sure LoST routing > gets > > > done in the location hiding use case. And that's a problem whether > > > proxies are worried about verification or not. > > > > > > > I do think that there are some problems with downstream LoST > routing, > > > but > > > > the problem is internal to a carrier ... > > > > > > I'd be interested to hear more about the validity of these sorts of > > > assumptions. Do you have more detail here? > > > > > > > Generally, I think that verification by looking up location via LoST > to > > > > validate that the Route has a valid PSAP URI is a reasonable way to > go, > > > but > > > > you can see that if that is the case, and the location in the call > is a > > > > reference, then the LIS has to give the proxy location that will > yield > > > the > > > > same URI that the UA got, and then we are into the location hiding > > > problem. > > > > > > Remember that whoever does LoST routing has a mapping, and that means > > > they have a service boundary. So if the UA does the routing, it can > > > insert the SB by value (if it doesn't have its own location), and a > > > proxy can insert a reference to the SB. SBs are public information, > so > > > there's no privacy concerns related to these references, and they not > > > affected by location hiding. Note that the proxy could *also* insert > a > > > reference to the UA's location that could have arbitrary access > > > controls, and as long as the ref to the SB was there, the verification > > > would work. > > > > > > So while there is still a connection between location hiding and call > > > marking, in that location needs to be available to the entity that > does > > > the LoST query, making use of service boundaries in this way largely > > > decouples the two problems. > > > > > > --Richard > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 15 15:57:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWdlr-0002tN-C3; Sat, 15 Sep 2007 15:57:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWdlq-0002qi-B6 for ecrit@ietf.org; Sat, 15 Sep 2007 15:57:38 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IWdlp-0008MB-IG for ecrit@ietf.org; Sat, 15 Sep 2007 15:57:38 -0400 Received: (qmail invoked by alias); 15 Sep 2007 19:57:35 -0000 Received: from p54984AA7.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.74.167] by mail.gmx.net (mp055) with SMTP; 15 Sep 2007 21:57:35 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/6jatVGhr6sYDdXhvOc62DW84Pkhds5LTK4CS/1X 1vjKDGVJwIhh+J Message-ID: <46EC392E.7080207@gmx.net> Date: Sat, 15 Sep 2007 21:57:34 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Ecrit] Some documents from DSL Forum References: <86B76B24-6663-4C46-B25D-69BC961C90D4@cisco.com> In-Reply-To: <86B76B24-6663-4C46-B25D-69BC961C90D4@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Cullen, Hi all, I read through the documents. The text in the document can be classified into three types of feedback: -- Protocol specific requirements These are aspects that could be captured in the Phone BCP or are already found in the protocol specific documents itself. I believe we have covered already most of these aspects (but we should double-check it). -- Implementation-specific aspects I am not sure how well we can capture these aspects in our documents. Still, they are fine with me. -- Interactions between different protocols and timing. There are a couple of timing aspects and protocol sequences (e.g., for retrieving location information). I am not so sure about these aspects. Is the timing reasonable? Is the sequence of retrieving location information reasonable and generic enough? I think that the provided documents sound pretty reasonable to me. We need to figure out what aspects are not yet covered in our documents and then we should try to incorporate them. We need to discuss them obviously. Help from members of the DSL forum would be useful. Ciao Hannes PS: The text mentions that when the end host uses GPS then the device has t6 use it instead of fetching location info from the network. In the past a couple of WG members raised some security concerns. Cullen Jennings wrote: > This message was also sent to GEOPRIV but please only reply to one list. > > > In my IETF AD Role I received some documents from DSL Forum that are > of relevant to this WG. I have posted them at: > > http://www.dial911anddie.com/DSLForum/WT-164v2.pdf > > and > > http://www.dial911anddie.com/DSLForum/WT-164v2-xls.pdf > > > Thanks, Cullen > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 17 12:41:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXJf2-0002I7-VY; Mon, 17 Sep 2007 12:41:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXJf2-0002FD-5T for ecrit@ietf.org; Mon, 17 Sep 2007 12:41:24 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXJf1-0002kL-PC for ecrit@ietf.org; Mon, 17 Sep 2007 12:41:24 -0400 X-IronPort-AV: E=Sophos;i="4.20,265,1186383600"; d="scan'208";a="219604654" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 17 Sep 2007 09:41:23 -0700 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/8.12.11) with ESMTP id l8HGfNO8024540; Mon, 17 Sep 2007 09:41:23 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id l8HGfM9l007375; Mon, 17 Sep 2007 16:41:23 GMT In-Reply-To: <46EC392E.7080207@gmx.net> References: <86B76B24-6663-4C46-B25D-69BC961C90D4@cisco.com> <46EC392E.7080207@gmx.net> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <2B0CBA82-C232-43FC-B51F-B034643C2B14@cisco.com> Content-Transfer-Encoding: quoted-printable From: Cullen Jennings Subject: Re: [Ecrit] Some documents from DSL Forum Date: Mon, 17 Sep 2007 09:39:48 -0700 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1638; t=1190047283; x=1190911283; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Ecrit]=20Some=20documents=20from=20DSL=20Forum |Sender:=20; bh=Fc8nJhYpxsAACsQB69wZAvL2+T91TamOidvx0P+FL60=; b=rCcSq4dq4IUwkpbC+7bDdykkb7bxjohXIbRgOgaJMupt+stAccl5761XUHVsaEvUNnTgb54r v6QVPEuVjeroBPaaNV6L5ja03LEsxkdhHrP2M4Kjl3U+E8vclcP9C9+k; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Sounds good. One thing that caught my attentions was in the gaps it =20 mentions Need to understand how long a device would need to wait for LLDP-MED and DHCP INFORM responses, in networks that don=92t support responses to = these protocols. Any advice we can give on that? Would phonebcp be a reasonable place =20 to address that? On Sep 15, 2007, at 12:57 PM, Hannes Tschofenig wrote: > Hi Cullen, > Hi all, > > I read through the documents. > > The text in the document can be classified into three types of =20 > feedback: > > -- Protocol specific requirements > These are aspects that could be captured in the Phone BCP or are =20 > already found in the protocol specific documents itself. > I believe we have covered already most of these aspects (but we =20 > should double-check it). > > -- Implementation-specific aspects > I am not sure how well we can capture these aspects in our =20 > documents. Still, they are fine with me. > > -- Interactions between different protocols and timing. > There are a couple of timing aspects and protocol sequences (e.g., =20 > for retrieving location information). I am not so sure about these =20 > aspects. Is the timing reasonable? Is the sequence of retrieving =20 > location information reasonable and generic enough? > > I think that the provided documents sound pretty reasonable to me. =20 > We need to figure out what aspects are not yet covered in our =20 > documents and then we should try to incorporate them. We need to =20 > discuss them obviously. > > Help from members of the DSL forum would be useful. > > Ciao > Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 17 13:01:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXJyG-0004SS-Lx; Mon, 17 Sep 2007 13:01:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXJyF-0004SE-G4 for ecrit@ietf.org; Mon, 17 Sep 2007 13:01:15 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXJyF-0003f5-1n for ecrit@ietf.org; Mon, 17 Sep 2007 13:01:15 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IXJy4-0001fQ-79; Mon, 17 Sep 2007 12:01:04 -0500 From: "Brian Rosen" To: "'Cullen Jennings'" , "'Hannes Tschofenig'" References: <86B76B24-6663-4C46-B25D-69BC961C90D4@cisco.com><46EC392E.7080207@gmx.net> <2B0CBA82-C232-43FC-B51F-B034643C2B14@cisco.com> Subject: RE: [Ecrit] Some documents from DSL Forum Date: Mon, 17 Sep 2007 13:01:09 -0400 Message-ID: <0cd901c7f94c$5af84800$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acf5SZm0wrdmoaTcRLeDnYzfeW8jggAAq4/Q In-Reply-To: <2B0CBA82-C232-43FC-B51F-B034643C2B14@cisco.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'll put it in phonebcp but I don't know what the numbers should be Brian > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Monday, September 17, 2007 12:40 PM > To: Hannes Tschofenig > Cc: ECRIT > Subject: Re: [Ecrit] Some documents from DSL Forum > > > Sounds good. One thing that caught my attentions was in the gaps it > mentions > > Need to understand how long a device would need to wait for LLDP-MED and > DHCP INFORM responses, in networks that don't support responses to these > protocols. > > Any advice we can give on that? Would phonebcp be a reasonable place > to address that? > > > On Sep 15, 2007, at 12:57 PM, Hannes Tschofenig wrote: > > > Hi Cullen, > > Hi all, > > > > I read through the documents. > > > > The text in the document can be classified into three types of > > feedback: > > > > -- Protocol specific requirements > > These are aspects that could be captured in the Phone BCP or are > > already found in the protocol specific documents itself. > > I believe we have covered already most of these aspects (but we > > should double-check it). > > > > -- Implementation-specific aspects > > I am not sure how well we can capture these aspects in our > > documents. Still, they are fine with me. > > > > -- Interactions between different protocols and timing. > > There are a couple of timing aspects and protocol sequences (e.g., > > for retrieving location information). I am not so sure about these > > aspects. Is the timing reasonable? Is the sequence of retrieving > > location information reasonable and generic enough? > > > > I think that the provided documents sound pretty reasonable to me. > > We need to figure out what aspects are not yet covered in our > > documents and then we should try to incorporate them. We need to > > discuss them obviously. > > > > Help from members of the DSL forum would be useful. > > > > Ciao > > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 17 13:46:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXKfb-0007nf-9Y; Mon, 17 Sep 2007 13:46:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXKfZ-0007nC-Lt for ecrit@ietf.org; Mon, 17 Sep 2007 13:46:01 -0400 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXKfY-0002iD-G6 for ecrit@ietf.org; Mon, 17 Sep 2007 13:46:01 -0400 Received: from 16.140.8.135.in-addr.arpa (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-outbound.avaya.com with ESMTP; 17 Sep 2007 13:45:59 -0400 X-IronPort-AV: i="4.20,265,1186372800"; d="scan'208"; a="62416198:sNHT10396224" 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] Some documents from DSL Forum Date: Mon, 17 Sep 2007 19:45:58 +0200 Message-ID: In-Reply-To: <2B0CBA82-C232-43FC-B51F-B034643C2B14@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Some documents from DSL Forum Thread-Index: Acf5ScdCgV3+FQaaRmi+vzzcWzvMMQACAZTQ References: <86B76B24-6663-4C46-B25D-69BC961C90D4@cisco.com><46EC392E.7080207@gmx.net> <2B0CBA82-C232-43FC-B51F-B034643C2B14@cisco.com> From: "Romascanu, Dan (Dan)" To: "Cullen Jennings" , "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org LLDP has a periodic 'slow protocol' announcement timer which is inherited by LLDP-MED. Its default is at 5 seconds if I am not mistaken. A device is supposed to respond much faster (layer 2 single link protocol) so this timer can be used as a default worst case when facing non-responsive devices. =20 Dan =20 =20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: Monday, September 17, 2007 6:40 PM > To: Hannes Tschofenig > Cc: ECRIT > Subject: Re: [Ecrit] Some documents from DSL Forum >=20 >=20 > Sounds good. One thing that caught my attentions was in the=20 > gaps it mentions >=20 > Need to understand how long a device would need to wait for=20 > LLDP-MED and DHCP INFORM responses, in networks that don't=20 > support responses to these protocols. >=20 > Any advice we can give on that? Would phonebcp be a=20 > reasonable place to address that? >=20 >=20 > On Sep 15, 2007, at 12:57 PM, Hannes Tschofenig wrote: >=20 > > Hi Cullen, > > Hi all, > > > > I read through the documents. > > > > The text in the document can be classified into three types of > > feedback: > > > > -- Protocol specific requirements > > These are aspects that could be captured in the Phone BCP or are=20 > > already found in the protocol specific documents itself. > > I believe we have covered already most of these aspects=20 > (but we should=20 > > double-check it). > > > > -- Implementation-specific aspects > > I am not sure how well we can capture these aspects in our=20 > documents.=20 > > Still, they are fine with me. > > > > -- Interactions between different protocols and timing. > > There are a couple of timing aspects and protocol sequences=20 > (e.g., for=20 > > retrieving location information). I am not so sure about these=20 > > aspects. Is the timing reasonable? Is the sequence of retrieving=20 > > location information reasonable and generic enough? > > > > I think that the provided documents sound pretty reasonable to me. =20 > > We need to figure out what aspects are not yet covered in our=20 > > documents and then we should try to incorporate them. We need to=20 > > discuss them obviously. > > > > Help from members of the DSL forum would be useful. > > > > Ciao > > Hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 18 04:45:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXYga-0000CM-LR; Tue, 18 Sep 2007 04:44:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXYgZ-0000Av-Gl for ecrit@ietf.org; Tue, 18 Sep 2007 04:43:59 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXYgN-0000gT-60 for ecrit@ietf.org; Tue, 18 Sep 2007 04:43:54 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id l8I8hG1T005614Tue, 18 Sep 2007 08:43:16 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1IXYfs-000Ecb-00; Tue, 18 Sep 2007 09:43:16 +0100 Date: Tue, 18 Sep 2007 09:43:16 +0100 From: "Clive D.W. Feather" To: Richard Barnes Subject: Re: [Ecrit] Emergency call marking Message-ID: <20070918084315.GU25548@finch-staff-1.thus.net> References: <46E84C1C.8010700@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46E84C1C.8010700@bbn.com> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Richard Barnes said: > One can verify that a URI is a PSAP URI by obtaining it as a > element in a LoST mapping. Given assumptions (A1, A3), an INVITE > addressed to a URI verified in this way must be addressed to a PSAP. > More precisely, to verify that an INVITE is addressed to a PSAP: > 1. Extract location information and a service URN from the INVITE > 2. Do a LoST findService query with that location and URN > 3. If the INVITE is addressed to one of the URIs returned in the > mapping, then the call is verified. > This procedure can be used to verify an INVITE as long as it contains > location information with good enough accuracy for routing (a URN is not > strictly necessary, since the set of all available URNs can be obtained > by the verifier with a listServiceByLocation query). However, why does this need to be provided with a location? Whatever system is used to convert a location to a PSAP URI must have a list of valid PSAP URIs within it. Therefore why can't that system have a second query interface "is this a valid PSAP URI"? -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 18 05:41:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXZZU-0007Jw-Sr; Tue, 18 Sep 2007 05:40:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXZZT-0007HQ-53 for ecrit@ietf.org; Tue, 18 Sep 2007 05:40:43 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXZZO-0005ut-Il for ecrit@ietf.org; Tue, 18 Sep 2007 05:40:39 -0400 X-SEF-Processed: 5_0_0_910__2007_09_18_04_50_07 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 18 Sep 2007 04:50:07 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Sep 2007 04:40:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Emergency call marking Date: Tue, 18 Sep 2007 04:40:35 -0500 Message-ID: In-Reply-To: <20070918084315.GU25548@finch-staff-1.thus.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Emergency call marking Thread-Index: Acf50OmSNMpvYyh9Qf+UURil1pJhmAABVykg References: <46E84C1C.8010700@bbn.com> <20070918084315.GU25548@finch-staff-1.thus.net> From: "Winterbottom, James" To: "Clive D.W. Feather" , "Richard Barnes" X-OriginalArrivalTime: 18 Sep 2007 09:40:37.0981 (UTC) FILETIME=[F82508D0:01C7F9D7] X-Spam-Score: 1.8 (+) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Clive,=0D=0A=0D=0AI think you are missing some very valuable context her= e.=0D=0A=0D=0ASuppose the access network invests, as it will have to, a gre= at deal of=0D=0Amoney to location enable itself, so it is somewhat reluctan= t to just=0D=0Agive location to end-points. It would rather provide a locat= ion URI with=0D=0Aa series of service URNs and corresponding destination UR= Is that can get=0D=0Alocation information. Service providers would pay the = access provider to=0D=0Aenable their services in the local catchment, not u= nlike IN services=0D=0Atoday.=0D=0A=0D=0AThe issue is to do with how VSPs c= heck the PSAP URI in this case.=0D=0AClearly asking the LIS for the locatio= n will fail, since the VSP won't=0D=0Ahave the necessary credentials. Provi= ding a different interface may=0D=0Asimply result in the LIS, or a system p= retending to be a LIS, saying=0D=0A"yup this is a PSAP URI". The VSP wants = to be sure so it knows whether=0D=0Ato charge its subscriber 1 cent a minut= e for the connection.=0D=0A=0D=0AMy opinion on this remains unchanged, char= ge the subscriber and debate=0D=0Athe issue later. The alternatives are, do= n't charge the subscriber and=0D=0Ahope they are being honest, of build a p= rotocol mechanism, maybe in=0D=0ALoST, to support reverse URI to service UR= N mappings.=0D=0A=0D=0ARichard's proposal is midway between these. It says,= let the VSP look at=0D=0Athe connected identity and if it is a PSAP don't = charge the sub,=0D=0Aotherwise drop the call or charge them.=0D=0A=0D=0AChe= ers=0D=0AJames=20=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A= > From: Clive D.W. Feather [mailto:clive@demon.net]=0D=0A> Sent: Tuesday, 1= 8 September 2007 6:43 PM=0D=0A> To: Richard Barnes=0D=0A> Cc: ECRIT=0D=0A> = Subject: Re: [Ecrit] Emergency call marking=0D=0A>=20=0D=0A> Richard Barnes= said:=0D=0A> > One can verify that a URI is a PSAP URI by obtaining it as = a =0D=0A> > element in a LoST mapping. Given assumptions (A1, A3), an= INVITE=0D=0A> > addressed to a URI verified in this way must be addressed = to a PSAP.=0D=0A> > More precisely, to verify that an INVITE is addressed t= o a PSAP:=0D=0A> > 1. Extract location information and a service URN from t= he INVITE=0D=0A> > 2. Do a LoST findService query with that location and UR= N=0D=0A> > 3. If the INVITE is addressed to one of the URIs returned in the=0D= =0A> > mapping, then the call is verified.=0D=0A> > This procedure can be u= sed to verify an INVITE as long as it=0D=0Acontains=0D=0A> > location infor= mation with good enough accuracy for routing (a URN is=0D=0Anot=0D=0A> > st= rictly necessary, since the set of all available URNs can be=0D=0Aobtained=0D= =0A> > by the verifier with a listServiceByLocation query).=0D=0A>=20=0D=0A= > However, why does this need to be provided with a location=3F=0D=0A>=20=0D= =0A> Whatever system is used to convert a location to a PSAP URI must have=0D= =0Aa=0D=0A> list of valid PSAP URIs within it. Therefore why can't that sys= tem=0D=0Ahave a=0D=0A> second query interface "is this a valid PSAP URI"=3F=0D= =0A>=20=0D=0A> --=0D=0A> Clive D.W. Feather | Work: |= Tel: +44 20 8495=0D=0A> 6138=0D=0A> Internet Expert | Home: | Fax: +44 870 051=0D=0A> 9937=0D=0A> Demon Internet = | WWW: http://www.davros.org | Mobile: +44 7973=0D=0A377646=0D=0A> THUS plc= | |=0D=0A>=20=0D=0A> _______________= ________________________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@iet= f.org=0D=0A> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A------= ---------------------------------------------------------------------------= ---------------=0D=0AThis message is for the designated recipient only and = may=0D=0Acontain privileged, proprietary, or otherwise private information.= =20=0D=0AIf you have received it in error, please notify the sender=0D=0Ai= mmediately and delete the original. Any unauthorized use of=0D=0Athis emai= l is prohibited.=0D=0A-----------------------------------------------------= -------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 18 12:12:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXffS-0004ed-8P; Tue, 18 Sep 2007 12:11:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXffQ-0004eV-N3 for ecrit@ietf.org; Tue, 18 Sep 2007 12:11:16 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXffP-0007rz-CJ for ecrit@ietf.org; Tue, 18 Sep 2007 12:11:16 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id D3D2D2C079; Tue, 18 Sep 2007 12:11:14 -0400 (EDT) X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEfCpyVD4HOw; Tue, 18 Sep 2007 12:11:11 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 1E2192C067; Tue, 18 Sep 2007 12:10:52 -0400 (EDT) In-Reply-To: To: ECRIT Subject: RE: [Ecrit] Some documents from DSL Forum MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Tue, 18 Sep 2007 12:10:50 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 09/18/2007 12:10:50 PM, Serialize complete at 09/18/2007 12:10:50 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad Cc: barbara.stark@att.com X-BeenThere: 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="===============1112892627==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============1112892627== Content-Type: multipart/alternative; boundary="=_alternative 0058E1208525735A_=" This is a multipart message in MIME format. --=_alternative 0058E1208525735A_= Content-Type: text/plain; charset="US-ASCII" Hi, (adding also Barbara Stark, Ed of the DSL document), I also had a go tat the DSL Forum document -- looks pretty good overall. Also noted the "Known Gaps". > Need to understand how long a device would need to wait for > LLDP-MED and DHCP INFORM responses, in networks that don't > support responses to these protocols. Adding some important details to Dan's... In LLDP-MED, a "Fast Start" procedure is used at startup (not present in basic LLDP). In Fast Start. the Endpoint side initiates by transmitting a bust of -MED frames. By default, 4 frames are sent at 1 sec interval. Before that time, the Network Connectivity side (ie the upstream L2 switch) is only transmitting basic LLDP (not -MED extensions). In response to seeing that first -MED frame come in, the Network Connectivity device then immediately begins transmitting -MED frames back, again starting with a burst of 4 frames at 1 sec interval by default. So, as a result the Endpoint will learn its location (from the Location Identification TLVs) almost immediately at startup. In my experience, this is typically measurable in handfuls of ms, certainly well under 1 sec, unless there is frame loss (very rare in practice). The whole Fast Start procedure takes 4 sec max, so that would make a good "didn't work" threshold. Note also that after startup phase, basic LLDP (and -MED by extension) will continue to advertise periodically at 30 sec interval by default (not 5 sec as Dan suggests). Also, due to basic LLDP behaviour, if any TLV information changes the change is immediately advertised, so if there is a change of location the Endpoint gets informed right away. Thus, the location will always stay up to date after that point, with a maximum window of 30 sec. In the DSL document, the sequence flows in Appendix A look basically correct, the sequence of events looks good. However a better value for "Was LLDP-MED successful" would be 4 sec. Also, I do not see a "was it successful" decision for DHCP ("was location in DHCP response" only has a Yes result, and no timeout associated) -- probably helpful to add that. Noting this stuff would also be helpful in the Phone BCP I think. (Brian already said he would do so.) I am not deep on the DHCP part of the question, so perhaps someone else can provide some details there. However, I don't *think* there is any explicit threshold "didn't work" timer we could count on (could well be wrong on that). In my experience, DHCP process takes longer than LLDP-MED. > Need requirements for soft client on a PC or PDA. These applications > will not have the ability to control LLDP or DHCP options, but > should be able to read them, if the underlying OS has requested > these options. Actually, LLDP / LLDP-MED does not necessarily need OS or driver support since it is defined above the MAC layer, though it would be nice of course. PC / PDA apps could build in the LLDP-MED capability directly. (Again, unclear on the DHCP part of this question.) Cheers, Peter Blatherwick (with Editor of LLDP-MED hat on) "Romascanu, Dan (Dan)" 17.09.07 13:45 To: "Cullen Jennings" , "Hannes Tschofenig" cc: ECRIT Subject: RE: [Ecrit] Some documents from DSL Forum LLDP has a periodic 'slow protocol' announcement timer which is inherited by LLDP-MED. Its default is at 5 seconds if I am not mistaken. A device is supposed to respond much faster (layer 2 single link protocol) so this timer can be used as a default worst case when facing non-responsive devices. Dan > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Monday, September 17, 2007 6:40 PM > To: Hannes Tschofenig > Cc: ECRIT > Subject: Re: [Ecrit] Some documents from DSL Forum > > > Sounds good. One thing that caught my attentions was in the > gaps it mentions > > Need to understand how long a device would need to wait for > LLDP-MED and DHCP INFORM responses, in networks that don't > support responses to these protocols. > > Any advice we can give on that? Would phonebcp be a > reasonable place to address that? > > > On Sep 15, 2007, at 12:57 PM, Hannes Tschofenig wrote: > > > Hi Cullen, > > Hi all, > > > > I read through the documents. > > > > The text in the document can be classified into three types of > > feedback: > > > > -- Protocol specific requirements > > These are aspects that could be captured in the Phone BCP or are > > already found in the protocol specific documents itself. > > I believe we have covered already most of these aspects > (but we should > > double-check it). > > > > -- Implementation-specific aspects > > I am not sure how well we can capture these aspects in our > documents. > > Still, they are fine with me. > > > > -- Interactions between different protocols and timing. > > There are a couple of timing aspects and protocol sequences > (e.g., for > > retrieving location information). I am not so sure about these > > aspects. Is the timing reasonable? Is the sequence of retrieving > > location information reasonable and generic enough? > > > > I think that the provided documents sound pretty reasonable to me. > > We need to figure out what aspects are not yet covered in our > > documents and then we should try to incorporate them. We need to > > discuss them obviously. > > > > Help from members of the DSL forum would be useful. > > > > Ciao > > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --=_alternative 0058E1208525735A_= Content-Type: text/html; charset="US-ASCII"
Hi, (adding also Barbara Stark, Ed of the DSL document),

I also had a go tat the DSL Forum document -- looks pretty good overall.  Also noted the "Known Gaps".  

> Need to understand how long a device would need to wait for
> LLDP-MED and DHCP INFORM responses, in networks that don't
> support responses to these protocols.
Adding some important details to Dan's...    
In LLDP-MED, a "Fast Start" procedure is used at startup (not present in basic LLDP).  In Fast Start. the Endpoint side initiates by transmitting a bust of -MED frames.  By default, 4 frames are sent at 1 sec interval.  Before that time, the Network Connectivity side (ie the upstream L2 switch) is only transmitting basic LLDP (not -MED extensions).  In response to seeing that first -MED frame come in, the Network Connectivity device then immediately begins transmitting -MED frames back, again starting with a burst of 4 frames at 1 sec interval by default.  So, as a result the Endpoint will learn its location (from the Location Identification TLVs) almost immediately at startup.  In my experience, this is typically measurable in handfuls of ms, certainly well under 1 sec, unless there is frame loss (very rare in practice).  The whole Fast Start procedure takes 4 sec max, so that would make a good "didn't work" threshold.  

Note also that after startup phase, basic LLDP (and -MED by extension) will continue to advertise periodically at 30 sec interval by default (not 5 sec as Dan suggests).  Also, due to basic LLDP behaviour, if any TLV information changes the change is immediately advertised, so if there is a change of location the Endpoint gets informed right away.  Thus, the location will always stay up to date after that point, with a maximum window of 30 sec.    

In the DSL document, the sequence flows in Appendix A look basically correct, the sequence of events looks good.  However a better value for "Was LLDP-MED successful" would be 4 sec.  Also, I do not see a "was it successful" decision for DHCP ("was location in DHCP response" only has a Yes result, and no timeout associated) -- probably helpful to add that.  

Noting this stuff would also be helpful in the Phone BCP I think.  (Brian already said he would do so.)  

I am not deep on the DHCP part of the question, so perhaps someone else can provide some details there.  However, I don't *think* there is any explicit threshold "didn't work" timer we could count on (could well be wrong on that).  In my experience, DHCP process takes longer than LLDP-MED.  

> Need requirements for soft client on a PC or PDA. These applications
> will not have the ability to control LLDP or DHCP options, but
> should be able to read them, if the underlying OS has requested
> these options.

Actually, LLDP / LLDP-MED does not necessarily need OS or driver support since it is defined above the MAC layer, though it would be nice of course.  PC / PDA apps could build in the LLDP-MED capability directly.  (Again, unclear on the DHCP part of this question.)  

Cheers,
Peter Blatherwick (with Editor of LLDP-MED hat on)




"Romascanu, Dan (Dan)" <dromasca@avaya.com>

17.09.07 13:45

       
        To:        "Cullen Jennings" <fluffy@cisco.com>, "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
        cc:        ECRIT <ecrit@ietf.org>
        Subject:        RE: [Ecrit] Some documents from DSL Forum



LLDP has a periodic 'slow protocol' announcement timer which is
inherited by LLDP-MED. Its default is at 5 seconds if I am not mistaken.
A device is supposed to respond much faster (layer 2 single link
protocol) so this timer can be used as a default  worst case when facing
non-responsive devices.  

Dan





> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: Monday, September 17, 2007 6:40 PM
> To: Hannes Tschofenig
> Cc: ECRIT
> Subject: Re: [Ecrit] Some documents from DSL Forum
>
>
> Sounds good. One thing that caught my attentions was in the
> gaps it mentions
>
> Need to understand how long a device would need to wait for
> LLDP-MED and DHCP INFORM responses, in networks that don't
> support responses to these protocols.
>
> Any advice we can give on that? Would phonebcp be a
> reasonable place to address that?
>
>
> On Sep 15, 2007, at 12:57 PM, Hannes Tschofenig wrote:
>
> > Hi Cullen,
> > Hi all,
> >
> > I read through the documents.
> >
> > The text in the document can be classified into three types of
> > feedback:
> >
> > -- Protocol specific requirements
> > These are aspects that could be captured in the Phone BCP or are
> > already found in the protocol specific documents itself.
> > I believe we have covered already most of these aspects
> (but we should
> > double-check it).
> >
> > -- Implementation-specific aspects
> > I am not sure how well we can capture these aspects in our
> documents.
> > Still, they are fine with me.
> >
> > -- Interactions between different protocols and timing.
> > There are a couple of timing aspects and protocol sequences
> (e.g., for
> > retrieving location information). I am not so sure about these
> > aspects. Is the timing reasonable? Is the sequence of retrieving
> > location information reasonable and generic enough?
> >
> > I think that the provided documents sound pretty reasonable to me.  
> > We need to figure out what aspects are not yet covered in our
> > documents and then we should try to incorporate them. We need to
> > discuss them obviously.
> >
> > Help from members of the DSL forum would be useful.
> >
> > Ciao
> > Hannes
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit
>

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit
--=_alternative 0058E1208525735A_=-- --===============1112892627== 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 --===============1112892627==-- From ecrit-bounces@ietf.org Tue Sep 18 13:27:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXgqz-0001Ib-9C; Tue, 18 Sep 2007 13:27:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXgqv-00011g-U9 for ecrit@ietf.org; Tue, 18 Sep 2007 13:27:13 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXgqp-0004sF-DQ for ecrit@ietf.org; Tue, 18 Sep 2007 13:27:13 -0400 Received: from ([139.76.131.31]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.184789575; Tue, 18 Sep 2007 13:26:30 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 18 Sep 2007 13:26:29 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 18 Sep 2007 13:26:29 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Some documents from DSL Forum Date: Tue, 18 Sep 2007 13:26:27 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA05A7F886@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Some documents from DSL Forum thread-index: Acf6Dp9LxIesQdJmQ6GyuCV32zFlBAABfZjQ References: From: "Stark, Barbara" To: ,"ECRIT" X-OriginalArrivalTime: 18 Sep 2007 17:26:29.0548 (UTC) FILETIME=[0C93AEC0:01C7FA19] X-Spam-Score: 0.0 (/) X-Scan-Signature: 233de1b21593fc0f4cdf285406dca0da Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1979531422==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1979531422== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FA19.0C52F36A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FA19.0C52F36A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Thanks for all the really useful input on LLDP and LLDP-MED. I'll be reflecting this in my next update.=20 I need to better understand the implications of a client running LLDP-MED, separate from the underlying OS. I would need for the client to know whether or not the OS provided that function, before it tried. If one client started doing it, then all the clients might decide they wanted to do it, too, and it might just get out of hand. There is a "known gap" on the DHCP INFORM timer, but not the standard DHCP request. My logic there was that if a device is configured to do DHCP for bootstrap, then it will be completely unable to do anything at a higher layer (including make an emergency call), until it gets a response. I have yet to find a mass market home network setup where auto addressing works to get network connectivity, after DHCP failed. There's usually a 60 second timer to try to get a response to DHCP DISCOVERY, after which the device gives up. It may periodically try DHCP again, but that's outside the scope of this document. I should probably try to fit this failure into my chart, but I ran out of room. =20 As to Hannes request for help from the DSLF, I'm happy to help in any way I can. I'll make sure they get any questions you need for them to answer. Of course, I'm editor of this document, and am tracking all your comments on this list. I'll do my best to be responsive, where I can answer questions directly. I really would like to see as much as possible be in phonebcp, and simply reference it. I have no intention of being redundant, or of going against the recommendations in phonebcp. Barbara =20 ________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Tuesday, September 18, 2007 12:11 PM To: ECRIT Cc: Cullen Jennings; Hannes Tschofenig; Romascanu, Dan (Dan); barbara.stark@att.com Subject: RE: [Ecrit] Some documents from DSL Forum Hi, (adding also Barbara Stark, Ed of the DSL document),=20 I also had a go tat the DSL Forum document -- looks pretty good overall. Also noted the "Known Gaps". =20 > Need to understand how long a device would need to wait for=20 > LLDP-MED and DHCP INFORM responses, in networks that don't=20 > support responses to these protocols. Adding some important details to Dan's... =20 In LLDP-MED, a "Fast Start" procedure is used at startup (not present in basic LLDP). In Fast Start. the Endpoint side initiates by transmitting a bust of -MED frames. By default, 4 frames are sent at 1 sec interval. Before that time, the Network Connectivity side (ie the upstream L2 switch) is only transmitting basic LLDP (not -MED extensions). In response to seeing that first -MED frame come in, the Network Connectivity device then immediately begins transmitting -MED frames back, again starting with a burst of 4 frames at 1 sec interval by default. So, as a result the Endpoint will learn its location (from the Location Identification TLVs) almost immediately at startup. In my experience, this is typically measurable in handfuls of ms, certainly well under 1 sec, unless there is frame loss (very rare in practice). The whole Fast Start procedure takes 4 sec max, so that would make a good "didn't work" threshold. =20 Note also that after startup phase, basic LLDP (and -MED by extension) will continue to advertise periodically at 30 sec interval by default (not 5 sec as Dan suggests). Also, due to basic LLDP behaviour, if any TLV information changes the change is immediately advertised, so if there is a change of location the Endpoint gets informed right away. Thus, the location will always stay up to date after that point, with a maximum window of 30 sec. =20 In the DSL document, the sequence flows in Appendix A look basically correct, the sequence of events looks good. However a better value for "Was LLDP-MED successful" would be 4 sec. Also, I do not see a "was it successful" decision for DHCP ("was location in DHCP response" only has a Yes result, and no timeout associated) -- probably helpful to add that. =20 Noting this stuff would also be helpful in the Phone BCP I think. (Brian already said he would do so.) =20 I am not deep on the DHCP part of the question, so perhaps someone else can provide some details there. However, I don't *think* there is any explicit threshold "didn't work" timer we could count on (could well be wrong on that). In my experience, DHCP process takes longer than LLDP-MED. =20 > Need requirements for soft client on a PC or PDA. These applications=20 > will not have the ability to control LLDP or DHCP options, but=20 > should be able to read them, if the underlying OS has requested=20 > these options.=20 Actually, LLDP / LLDP-MED does not necessarily need OS or driver support since it is defined above the MAC layer, though it would be nice of course. PC / PDA apps could build in the LLDP-MED capability directly. (Again, unclear on the DHCP part of this question.) =20 Cheers,=20 Peter Blatherwick (with Editor of LLDP-MED hat on)=20 "Romascanu, Dan (Dan)" =20 17.09.07 13:45=20 =20 To: "Cullen Jennings" , "Hannes Tschofenig" =20 cc: ECRIT =20 Subject: RE: [Ecrit] Some documents from DSL Forum LLDP has a periodic 'slow protocol' announcement timer which is inherited by LLDP-MED. Its default is at 5 seconds if I am not mistaken. A device is supposed to respond much faster (layer 2 single link protocol) so this timer can be used as a default worst case when facing non-responsive devices. =20 Dan > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: Monday, September 17, 2007 6:40 PM > To: Hannes Tschofenig > Cc: ECRIT > Subject: Re: [Ecrit] Some documents from DSL Forum >=20 >=20 > Sounds good. One thing that caught my attentions was in the=20 > gaps it mentions >=20 > Need to understand how long a device would need to wait for=20 > LLDP-MED and DHCP INFORM responses, in networks that don't=20 > support responses to these protocols. >=20 > Any advice we can give on that? Would phonebcp be a=20 > reasonable place to address that? >=20 >=20 > On Sep 15, 2007, at 12:57 PM, Hannes Tschofenig wrote: >=20 > > Hi Cullen, > > Hi all, > > > > I read through the documents. > > > > The text in the document can be classified into three types of > > feedback: > > > > -- Protocol specific requirements > > These are aspects that could be captured in the Phone BCP or are=20 > > already found in the protocol specific documents itself. > > I believe we have covered already most of these aspects=20 > (but we should=20 > > double-check it). > > > > -- Implementation-specific aspects > > I am not sure how well we can capture these aspects in our=20 > documents.=20 > > Still, they are fine with me. > > > > -- Interactions between different protocols and timing. > > There are a couple of timing aspects and protocol sequences=20 > (e.g., for=20 > > retrieving location information). I am not so sure about these=20 > > aspects. Is the timing reasonable? Is the sequence of retrieving=20 > > location information reasonable and generic enough? > > > > I think that the provided documents sound pretty reasonable to me. =20 > > We need to figure out what aspects are not yet covered in our=20 > > documents and then we should try to incorporate them. We need to=20 > > discuss them obviously. > > > > Help from members of the DSL forum would be useful. > > > > Ciao > > Hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA625 ------_=_NextPart_001_01C7FA19.0C52F36A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Thanks for all the really useful input on LLDP = and=20 LLDP-MED. I'll be reflecting this in my next update. =
I need to better understand the implications of = a client=20 running LLDP-MED, separate from the underlying OS. I would need for the = client=20 to know whether or not the OS provided that function, before it tried. = If one=20 client started doing it, then all the clients might decide they wanted = to do it,=20 too, and it might just get out of hand.
There is a "known gap" on the DHCP INFORM = timer, but not=20 the standard DHCP request. My logic there was that if a device is = configured to=20 do DHCP for bootstrap, then it will be completely unable to do anything = at a=20 higher layer (including make an emergency call), until it gets a = response. I=20 have yet to find a mass market home network setup where auto addressing = works to=20 get network connectivity, after DHCP failed. There's usually a 60 second = timer=20 to try to get a response to DHCP DISCOVERY, after which the device gives = up. It=20 may periodically try DHCP again, but that's outside the scope of this = document.=20 I should probably try to fit this failure into my chart, but I ran out = of=20 room.
 
As to Hannes request for help from the DSLF, = I'm happy to=20 help in any way I can. I'll make sure they get any questions you need = for them=20 to answer. Of course, I'm editor of this document, and am tracking all = your=20 comments on this list. I'll do my best to be responsive, where I can = answer=20 questions directly. I really would like to see as much as = possible be in=20 phonebcp, and simply reference it. I have no intention of being = redundant, or of=20 going against the recommendations in phonebcp.
Barbara
 

From: peter_blatherwick@mitel.com=20 [mailto:peter_blatherwick@mitel.com]
Sent: Tuesday, September = 18,=20 2007 12:11 PM
To: ECRIT
Cc: Cullen Jennings; Hannes=20 Tschofenig; Romascanu, Dan (Dan); = barbara.stark@att.com
Subject: RE:=20 [Ecrit] Some documents from DSL Forum


Hi, (adding also Barbara = Stark, Ed=20 of the DSL document),

I = also had a=20 go tat the DSL Forum document -- looks pretty good overall.  Also = noted the=20 "Known Gaps".  

> Need to = understand how=20 long a device would need to wait for
> LLDP-MED and DHCP INFORM=20 responses, in networks that don't
> support responses to these=20 protocols.

Adding = some important=20 details to Dan's...    
In=20 LLDP-MED, a "Fast Start" procedure is used at startup (not present in = basic=20 LLDP).  In Fast Start. the Endpoint side initiates by transmitting = a bust=20 of -MED frames.  By default, 4 frames are sent at 1 sec interval.=20  Before that time, the Network Connectivity side (ie the upstream = L2=20 switch) is only transmitting basic LLDP (not -MED extensions).  In = response=20 to seeing that first -MED frame come in, the Network Connectivity device = then=20 immediately begins transmitting -MED frames back, again starting with a = burst of=20 4 frames at 1 sec interval by default.  So, as a result the = Endpoint will=20 learn its location (from the Location Identification TLVs) almost = immediately at=20 startup.  In my experience, this is typically measurable in = handfuls of ms,=20 certainly well under 1 sec, unless there is frame loss (very rare in = practice).=20  The whole Fast Start procedure takes 4 sec max, so that would make = a good=20 "didn't work" threshold.  

Note=20 also that after startup phase, basic LLDP (and -MED by extension) will = continue=20 to advertise periodically at 30 sec interval by default (not 5 sec as = Dan=20 suggests).  Also, due to basic LLDP behaviour, if any TLV = information=20 changes the change is immediately advertised, so if there is a change of = location the Endpoint gets informed right away.  Thus, the location = will=20 always stay up to date after that point, with a maximum window of 30 = sec.  =20  

In the DSL = document, the=20 sequence flows in Appendix A look basically correct, the sequence of = events=20 looks good.  However a better value for "Was LLDP-MED successful" = would be=20 4 sec.  Also, I do not see a "was it successful" decision for DHCP = ("was=20 location in DHCP response" only has a Yes result, and no timeout = associated) --=20 probably helpful to add that.  

Noting this stuff would also be helpful in the Phone BCP I = think.=20  (Brian already said he would do so.)  

I am not deep on the DHCP part of the = question, so=20 perhaps someone else can provide some details there.  However, I = don't=20 *think* there is any explicit threshold "didn't work" timer we could = count on=20 (could well be wrong on that).  In my experience, DHCP process = takes longer=20 than LLDP-MED.  

> Need = requirements for=20 soft client on a PC or PDA. These applications
> will not have the ability to control LLDP or DHCP options, = but=20
> should be able to read them, if = the=20 underlying OS has requested
> = these options.=20

Actually, LLDP / = LLDP-MED does=20 not necessarily need OS or driver support since it is defined above the = MAC=20 layer, though it would be nice of course.  PC / PDA apps could = build in the=20 LLDP-MED capability directly.  (Again, unclear on the DHCP part of = this=20 question.)  

Cheers,=20
Peter Blatherwick (with Editor of = LLDP-MED hat=20 on)




"Romascanu, Dan (Dan)"=20 <dromasca@avaya.com>=20

17.09.07 13:45

        =
        To:   =  =20    "Cullen Jennings" <fluffy@cisco.com>, "Hannes=20 Tschofenig" <Hannes.Tschofenig@gmx.net>
        cc:   =  =20    ECRIT <ecrit@ietf.org>
        Subject:       =  RE:=20 [Ecrit] Some documents from DSL=20 Forum



LLDP has = a=20 periodic 'slow protocol' announcement timer which is
inherited by = LLDP-MED.=20 Its default is at 5 seconds if I am not mistaken.
A device is = supposed to=20 respond much faster (layer 2 single link
protocol) so this timer can = be used=20 as a default  worst case when facing
non-responsive devices.=20  

Dan





> -----Original = Message-----
>=20 From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: Monday, = September=20 17, 2007 6:40 PM
> To: Hannes Tschofenig
> Cc: ECRIT
> = Subject: Re: [Ecrit] Some documents from DSL Forum
>
> =
>=20 Sounds good. One thing that caught my attentions was in the
> = gaps it=20 mentions
>
> Need to understand how long a device would = need to=20 wait for
> LLDP-MED and DHCP INFORM responses, in networks that = don't=20
> support responses to these protocols.
>
> Any = advice we=20 can give on that? Would phonebcp be a
> reasonable place to = address=20 that?
>
>
> On Sep 15, 2007, at 12:57 PM, Hannes = Tschofenig=20 wrote:
>
> > Hi Cullen,
> > Hi all,
>=20 >
> > I read through the documents.
> >
> = > The=20 text in the document can be classified into three types of
> >=20 feedback:
> >
> > -- Protocol specific = requirements
>=20 > These are aspects that could be captured in the Phone BCP or are =
>=20 > already found in the protocol specific documents itself.
> = > I=20 believe we have covered already most of these aspects
> (but we = should=20
> > double-check it).
> >
> > --=20 Implementation-specific aspects
> > I am not sure how well we = can=20 capture these aspects in our
> documents.
> > Still, = they are=20 fine with me.
> >
> > -- Interactions between = different=20 protocols and timing.
> > There are a couple of timing aspects = and=20 protocol sequences
> (e.g., for
> > retrieving location = information). I am not so sure about these
> > aspects. Is the = timing=20 reasonable? Is the sequence of retrieving
> > location = information=20 reasonable and generic enough?
> >
> > I think that = the=20 provided documents sound pretty reasonable to me.  
> > We = need to=20 figure out what aspects are not yet covered in our
> > = documents and=20 then we should try to incorporate them. We need to
> > discuss = them=20 obviously.
> >
> > Help from members of the DSL forum = would be=20 useful.
> >
> > Ciao
> > Hannes
> =
>=20 _______________________________________________
> Ecrit mailing=20 list
> Ecrit@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/ecrit
>=20

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

*****

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

 ------_=_NextPart_001_01C7FA19.0C52F36A-- --===============1979531422== 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 --===============1979531422==-- From ecrit-bounces@ietf.org Tue Sep 18 14:17:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXhdR-0003Iv-SO; Tue, 18 Sep 2007 14:17:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXhdQ-0003Gp-ER for ecrit@ietf.org; Tue, 18 Sep 2007 14:17:20 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXhdH-000662-2M for ecrit@ietf.org; Tue, 18 Sep 2007 14:17:20 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id C0CD32C017; Tue, 18 Sep 2007 14:17:00 -0400 (EDT) X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dup2+RBerukf; Tue, 18 Sep 2007 14:16:59 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 974892C057; Tue, 18 Sep 2007 14:16:59 -0400 (EDT) In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA05A7F886@crexc41p> To: "Stark, Barbara" Subject: RE: [Ecrit] Some documents from DSL Forum MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Tue, 18 Sep 2007 14:16:57 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 09/18/2007 02:16:57 PM, Serialize complete at 09/18/2007 02:16:57 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed9477f79f24ff120e9894ad9dc9cb5 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1941205202==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============1941205202== Content-Type: multipart/alternative; boundary="=_alternative 00646D048525735A_=" This is a multipart message in MIME format. --=_alternative 00646D048525735A_= Content-Type: text/plain; charset="US-ASCII" Hi again Barbara, Trying to answer some of your questions back, please see [PB] inline below. -- Peter "Stark, Barbara" 18.09.07 13:26 To: , "ECRIT" cc: "Cullen Jennings" , "Hannes Tschofenig" , "Romascanu, Dan (Dan)" Subject: RE: [Ecrit] Some documents from DSL Forum Thanks for all the really useful input on LLDP and LLDP-MED. I'll be reflecting this in my next update. I need to better understand the implications of a client running LLDP-MED, separate from the underlying OS. I would need for the client to know whether or not the OS provided that function, before it tried. If one client started doing it, then all the clients might decide they wanted to do it, too, and it might just get out of hand. [PB] I agree there are potential issues if multiple applications in a single Endpoint device all decided to start LLDP-MED. (You are referring to these applications as "clients" I believe??) Potentially, the first of those would get immediate response, but others would not see -MED coming back until the next normal advertising cycle. Hence, OS support would be a good thing. I do not see this as a big issue though, since location would only be out of date for a max of the advertising interval (30 sec default), and would be correct thereafter. A bit more serious would be the implication on the Network Connectivity Device side, where it would potentially be receiving multiple sets of advertisements. Not only would there be more traffic (a non-issue in practice, since it is constrained to the link), but if each app was advertising different TLVs then the info from one could continually get overridden with info from the other(s). I would expect multiple apps all wanting to use LLDP-MED in a single device to be rare though, at least at this point. There is a "known gap" on the DHCP INFORM timer, but not the standard DHCP request. My logic there was that if a device is configured to do DHCP for bootstrap, then it will be completely unable to do anything at a higher layer (including make an emergency call), until it gets a response. I have yet to find a mass market home network setup where auto addressing works to get network connectivity, after DHCP failed. There's usually a 60 second timer to try to get a response to DHCP DISCOVERY, after which the device gives up. It may periodically try DHCP again, but that's outside the scope of this document. I should probably try to fit this failure into my chart, but I ran out of room. [PB] Yup, this makes sense now. Yeah, the chart is pretty convoluted and hard to fit anything else into, but still think it would be good to include "No" paths from the "Was successful" decisions to the appropriate handling (which is LIS determination I would think). As to Hannes request for help from the DSLF, I'm happy to help in any way I can. I'll make sure they get any questions you need for them to answer. Of course, I'm editor of this document, and am tracking all your comments on this list. I'll do my best to be responsive, where I can answer questions directly. I really would like to see as much as possible be in phonebcp, and simply reference it. I have no intention of being redundant, or of going against the recommendations in phonebcp. Barbara From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Tuesday, September 18, 2007 12:11 PM To: ECRIT Cc: Cullen Jennings; Hannes Tschofenig; Romascanu, Dan (Dan); barbara.stark@att.com Subject: RE: [Ecrit] Some documents from DSL Forum Hi, (adding also Barbara Stark, Ed of the DSL document), I also had a go tat the DSL Forum document -- looks pretty good overall. Also noted the "Known Gaps". > Need to understand how long a device would need to wait for > LLDP-MED and DHCP INFORM responses, in networks that don't > support responses to these protocols. Adding some important details to Dan's... In LLDP-MED, a "Fast Start" procedure is used at startup (not present in basic LLDP). In Fast Start. the Endpoint side initiates by transmitting a bust of -MED frames. By default, 4 frames are sent at 1 sec interval. Before that time, the Network Connectivity side (ie the upstream L2 switch) is only transmitting basic LLDP (not -MED extensions). In response to seeing that first -MED frame come in, the Network Connectivity device then immediately begins transmitting -MED frames back, again starting with a burst of 4 frames at 1 sec interval by default. So, as a result the Endpoint will learn its location (from the Location Identification TLVs) almost immediately at startup. In my experience, this is typically measurable in handfuls of ms, certainly well under 1 sec, unless there is frame loss (very rare in practice). The whole Fast Start procedure takes 4 sec max, so that would make a good "didn't work" threshold. Note also that after startup phase, basic LLDP (and -MED by extension) will continue to advertise periodically at 30 sec interval by default (not 5 sec as Dan suggests). Also, due to basic LLDP behaviour, if any TLV information changes the change is immediately advertised, so if there is a change of location the Endpoint gets informed right away. Thus, the location will always stay up to date after that point, with a maximum window of 30 sec. In the DSL document, the sequence flows in Appendix A look basically correct, the sequence of events looks good. However a better value for "Was LLDP-MED successful" would be 4 sec. Also, I do not see a "was it successful" decision for DHCP ("was location in DHCP response" only has a Yes result, and no timeout associated) -- probably helpful to add that. Noting this stuff would also be helpful in the Phone BCP I think. (Brian already said he would do so.) I am not deep on the DHCP part of the question, so perhaps someone else can provide some details there. However, I don't *think* there is any explicit threshold "didn't work" timer we could count on (could well be wrong on that). In my experience, DHCP process takes longer than LLDP-MED. > Need requirements for soft client on a PC or PDA. These applications > will not have the ability to control LLDP or DHCP options, but > should be able to read them, if the underlying OS has requested > these options. Actually, LLDP / LLDP-MED does not necessarily need OS or driver support since it is defined above the MAC layer, though it would be nice of course. PC / PDA apps could build in the LLDP-MED capability directly. (Again, unclear on the DHCP part of this question.) Cheers, Peter Blatherwick (with Editor of LLDP-MED hat on) "Romascanu, Dan (Dan)" 17.09.07 13:45 To: "Cullen Jennings" , "Hannes Tschofenig" cc: ECRIT Subject: RE: [Ecrit] Some documents from DSL Forum LLDP has a periodic 'slow protocol' announcement timer which is inherited by LLDP-MED. Its default is at 5 seconds if I am not mistaken. A device is supposed to respond much faster (layer 2 single link protocol) so this timer can be used as a default worst case when facing non-responsive devices. Dan > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Monday, September 17, 2007 6:40 PM > To: Hannes Tschofenig > Cc: ECRIT > Subject: Re: [Ecrit] Some documents from DSL Forum > > > Sounds good. One thing that caught my attentions was in the > gaps it mentions > > Need to understand how long a device would need to wait for > LLDP-MED and DHCP INFORM responses, in networks that don't > support responses to these protocols. > > Any advice we can give on that? Would phonebcp be a > reasonable place to address that? > > > On Sep 15, 2007, at 12:57 PM, Hannes Tschofenig wrote: > > > Hi Cullen, > > Hi all, > > > > I read through the documents. > > > > The text in the document can be classified into three types of > > feedback: > > > > -- Protocol specific requirements > > These are aspects that could be captured in the Phone BCP or are > > already found in the protocol specific documents itself. > > I believe we have covered already most of these aspects > (but we should > > double-check it). > > > > -- Implementation-specific aspects > > I am not sure how well we can capture these aspects in our > documents. > > Still, they are fine with me. > > > > -- Interactions between different protocols and timing. > > There are a couple of timing aspects and protocol sequences > (e.g., for > > retrieving location information). I am not so sure about these > > aspects. Is the timing reasonable? Is the sequence of retrieving > > location information reasonable and generic enough? > > > > I think that the provided documents sound pretty reasonable to me. > > We need to figure out what aspects are not yet covered in our > > documents and then we should try to incorporate them. We need to > > discuss them obviously. > > > > Help from members of the DSL forum would be useful. > > > > Ciao > > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625 --=_alternative 00646D048525735A_= Content-Type: text/html; charset="US-ASCII"
Hi again Barbara,
Trying to answer some of your questions back, please see [PB] inline below.
-- Peter



"Stark, Barbara" <bs7652@att.com>

18.09.07 13:26

       
        To:        <peter_blatherwick@mitel.com>, "ECRIT" <ecrit@ietf.org>
        cc:        "Cullen Jennings" <fluffy@cisco.com>, "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>, "Romascanu, Dan (Dan)" <dromasca@avaya.com>
        Subject:        RE: [Ecrit] Some documents from DSL Forum



Thanks for all the really useful input on LLDP and LLDP-MED. I'll be reflecting this in my next update.
I need to better understand the implications of a client running LLDP-MED, separate from the underlying OS. I would need for the client to know whether or not the OS provided that function, before it tried. If one client started doing it, then all the clients might decide they wanted to do it, too, and it might just get out of hand.

[PB] I agree there are potential issues if multiple applications in a single Endpoint device all decided to start LLDP-MED.  (You are referring to these applications as "clients" I believe??)  Potentially, the first of those would get immediate response, but others would not see -MED coming back until the next normal advertising cycle.  Hence, OS support would be a good thing.  I do not see this as a big issue though, since location would only be out of date for a max of the advertising interval (30 sec default), and would be correct thereafter.  A bit more serious would be the implication on the Network Connectivity Device side, where it would potentially be receiving multiple sets of advertisements.  Not only would there be more traffic (a non-issue in practice, since it is constrained to the link), but if each app was advertising different TLVs then the info from one could continually get overridden with info from the other(s).  I would expect multiple apps all wanting to use LLDP-MED in a single device to be rare though, at least at this point.  

There is a "known gap" on the DHCP INFORM timer, but not the standard DHCP request. My logic there was that if a device is configured to do DHCP for bootstrap, then it will be completely unable to do anything at a higher layer (including make an emergency call), until it gets a response. I have yet to find a mass market home network setup where auto addressing works to get network connectivity, after DHCP failed. There's usually a 60 second timer to try to get a response to DHCP DISCOVERY, after which the device gives up. It may periodically try DHCP again, but that's outside the scope of this document. I should probably try to fit this failure into my chart, but I ran out of room.
 
[PB] Yup, this makes sense now.  Yeah, the chart is pretty convoluted and hard to fit anything else into, but still think it would be good to include "No" paths from the "Was <method x> successful" decisions to the appropriate handling (which is LIS determination I would think).  

As to Hannes request for help from the DSLF, I'm happy to help in any way I can. I'll make sure they get any questions you need for them to answer. Of course, I'm editor of this document, and am tracking all your comments on this list. I'll do my best to be responsive, where I can answer questions directly. I really would like to see as much as possible be in phonebcp, and simply reference it. I have no intention of being redundant, or of going against the recommendations in phonebcp.
Barbara
 

From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Tuesday, September 18, 2007 12:11 PM
To: ECRIT
Cc: Cullen Jennings; Hannes Tschofenig; Romascanu, Dan (Dan); barbara.stark@att.com
Subject: RE: [Ecrit] Some documents from DSL Forum

Hi, (adding also Barbara Stark, Ed of the DSL document),

I also had a go tat the DSL Forum document -- looks pretty good overall.  Also noted the "Known Gaps".  

> Need to understand how long a device would need to wait for
> LLDP-MED and DHCP INFORM responses, in networks that don't
> support responses to these protocols.

Adding some important details to Dan's...    
In LLDP-MED, a "Fast Start" procedure is used at startup (not present in basic LLDP).  In Fast Start. the Endpoint side initiates by transmitting a bust of -MED frames.  By default, 4 frames are sent at 1 sec interval.  Before that time, the Network Connectivity side (ie the upstream L2 switch) is only transmitting basic LLDP (not -MED extensions).  In response to seeing that first -MED frame come in, the Network Connectivity device then immediately begins transmitting -MED frames back, again starting with a burst of 4 frames at 1 sec interval by default.  So, as a result the Endpoint will learn its location (from the Location Identification TLVs) almost immediately at startup.  In my experience, this is typically measurable in handfuls of ms, certainly well under 1 sec, unless there is frame loss (very rare in practice).  The whole Fast Start procedure takes 4 sec max, so that would make a good "didn't work" threshold.  

Note also that after startup phase, basic LLDP (and -MED by extension) will continue to advertise periodically at 30 sec interval by default (not 5 sec as Dan suggests).  Also, due to basic LLDP behaviour, if any TLV information changes the change is immediately advertised, so if there is a change of location the Endpoint gets informed right away.  Thus, the location will always stay up to date after that point, with a maximum window of 30 sec.    

In the DSL document, the sequence flows in Appendix A look basically correct, the sequence of events looks good.  However a better value for "Was LLDP-MED successful" would be 4 sec.  Also, I do not see a "was it successful" decision for DHCP ("was location in DHCP response" only has a Yes result, and no timeout associated) -- probably helpful to add that.  

Noting this stuff would also be helpful in the Phone BCP I think.  (Brian already said he would do so.)  

I am not deep on the DHCP part of the question, so perhaps someone else can provide some details there.  However, I don't *think* there is any explicit threshold "didn't work" timer we could count on (could well be wrong on that).  In my experience, DHCP process takes longer than LLDP-MED.  

> Need requirements for soft client on a PC or PDA. These applications
> will not have the ability to control LLDP or DHCP options, but
> should be able to read them, if the underlying OS has requested
> these options.

Actually, LLDP / LLDP-MED does not necessarily need OS or driver support since it is defined above the MAC layer, though it would be nice of course.  PC / PDA apps could build in the LLDP-MED capability directly.  (Again, unclear on the DHCP part of this question.)  

Cheers,
Peter Blatherwick (with Editor of LLDP-MED hat on)



"Romascanu, Dan (Dan)" <dromasca@avaya.com>

17.09.07 13:45

       
       To:        "Cullen Jennings" <fluffy@cisco.com>, "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
       cc:        ECRIT <ecrit@ietf.org>
       Subject:        RE: [Ecrit] Some documents from DSL Forum




LLDP has a periodic 'slow protocol' announcement timer which is
inherited by LLDP-MED. Its default is at 5 seconds if I am not mistaken.
A device is supposed to respond much faster (layer 2 single link
protocol) so this timer can be used as a default  worst case when facing
non-responsive devices.  

Dan





> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: Monday, September 17, 2007 6:40 PM
> To: Hannes Tschofenig
> Cc: ECRIT
> Subject: Re: [Ecrit] Some documents from DSL Forum
>
>
> Sounds good. One thing that caught my attentions was in the
> gaps it mentions
>
> Need to understand how long a device would need to wait for
> LLDP-MED and DHCP INFORM responses, in networks that don't
> support responses to these protocols.
>
> Any advice we can give on that? Would phonebcp be a
> reasonable place to address that?
>
>
> On Sep 15, 2007, at 12:57 PM, Hannes Tschofenig wrote:
>
> > Hi Cullen,
> > Hi all,
> >
> > I read through the documents.
> >
> > The text in the document can be classified into three types of
> > feedback:
> >
> > -- Protocol specific requirements
> > These are aspects that could be captured in the Phone BCP or are
> > already found in the protocol specific documents itself.
> > I believe we have covered already most of these aspects
> (but we should
> > double-check it).
> >
> > -- Implementation-specific aspects
> > I am not sure how well we can capture these aspects in our
> documents.
> > Still, they are fine with me.
> >
> > -- Interactions between different protocols and timing.
> > There are a couple of timing aspects and protocol sequences
> (e.g., for
> > retrieving location information). I am not so sure about these
> > aspects. Is the timing reasonable? Is the sequence of retrieving
> > location information reasonable and generic enough?
> >
> > I think that the provided documents sound pretty reasonable to me.  
> > We need to figure out what aspects are not yet covered in our
> > documents and then we should try to incorporate them. We need to
> > discuss them obviously.
> >
> > Help from members of the DSL forum would be useful.
> >
> > Ciao
> > Hannes
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit
>

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

*****

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

--=_alternative 00646D048525735A_=-- --===============1941205202== 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 --===============1941205202==-- From ecrit-bounces@ietf.org Tue Sep 18 15:04:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXiMu-0000If-EO; Tue, 18 Sep 2007 15:04:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXiMt-0000HZ-Vn for ecrit@ietf.org; Tue, 18 Sep 2007 15:04:19 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXiMk-0007C1-9a for ecrit@ietf.org; Tue, 18 Sep 2007 15:04:19 -0400 Received: from ([139.76.131.31]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.29749273; Tue, 18 Sep 2007 15:03:38 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 18 Sep 2007 15:03:38 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 18 Sep 2007 15:03:37 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Some documents from DSL Forum Date: Tue, 18 Sep 2007 15:03:35 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA05A7F8D3@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Some documents from DSL Forum thread-index: Acf6IDeVK8AoS8hKQh+2kTyqd6BGCgAAJbEA References: <7582BC68E4994F4ABF0BD4723975C3FA05A7F886@crexc41p> From: "Stark, Barbara" To: X-OriginalArrivalTime: 18 Sep 2007 19:03:37.0757 (UTC) FILETIME=[9E75CCD0:01C7FA26] X-Spam-Score: 0.0 (/) X-Scan-Signature: fd911903d9eb33179d1ec28b0417afe8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1575858949==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1575858949== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FA26.9E4452CE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FA26.9E4452CE Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Thanks again for the LLDP-MED info. I'll feed it to the developer-types, and see what they think. I agree the DHCP failure scenario can be filled out a bit better. I'll have to break my charts apart, but that's ok. If there's no DHCP response after the standard DHCP time-out, most devices do one of 3 things: assign themselves 0.0.0.0 and give up trying to talk externally; do IP auto addressing, see if there's anything to talk to, and then give up trying to talk externally; or have a static assignment to try (my laptop does this, since we have static in the office and DHCP in all other places). With a static assignment, it makes sense to go to the "No" path of "Is DHCP used for IP address config?". I suppose on the off chance that auto addressing succeeded in finding something else (extremely low probability), that it might also try that path. I wouldn't give it much chance of succeeding. Barbara ________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Tuesday, September 18, 2007 2:17 PM To: Stark, Barbara Cc: Romascanu, Dan (Dan); ECRIT; Cullen Jennings; Hannes Tschofenig Subject: RE: [Ecrit] Some documents from DSL Forum Hi again Barbara,=20 Trying to answer some of your questions back, please see [PB] inline below.=20 -- Peter=20 "Stark, Barbara" =20 18.09.07 13:26=20 =20 To: , "ECRIT" =20 cc: "Cullen Jennings" , "Hannes Tschofenig" , "Romascanu, Dan (Dan)" =20 Subject: RE: [Ecrit] Some documents from DSL Forum Thanks for all the really useful input on LLDP and LLDP-MED. I'll be reflecting this in my next update.=20 I need to better understand the implications of a client running LLDP-MED, separate from the underlying OS. I would need for the client to know whether or not the OS provided that function, before it tried. If one client started doing it, then all the clients might decide they wanted to do it, too, and it might just get out of hand.=20 [PB] I agree there are potential issues if multiple applications in a single Endpoint device all decided to start LLDP-MED. (You are referring to these applications as "clients" I believe??) Potentially, the first of those would get immediate response, but others would not see -MED coming back until the next normal advertising cycle. Hence, OS support would be a good thing. I do not see this as a big issue though, since location would only be out of date for a max of the advertising interval (30 sec default), and would be correct thereafter. A bit more serious would be the implication on the Network Connectivity Device side, where it would potentially be receiving multiple sets of advertisements. Not only would there be more traffic (a non-issue in practice, since it is constrained to the link), but if each app was advertising different TLVs then the info from one could continually get overridden with info from the other(s). I would expect multiple apps all wanting to use LLDP-MED in a single device to be rare though, at least at this point. =20 There is a "known gap" on the DHCP INFORM timer, but not the standard DHCP request. My logic there was that if a device is configured to do DHCP for bootstrap, then it will be completely unable to do anything at a higher layer (including make an emergency call), until it gets a response. I have yet to find a mass market home network setup where auto addressing works to get network connectivity, after DHCP failed. There's usually a 60 second timer to try to get a response to DHCP DISCOVERY, after which the device gives up. It may periodically try DHCP again, but that's outside the scope of this document. I should probably try to fit this failure into my chart, but I ran out of room.=20 =20 [PB] Yup, this makes sense now. Yeah, the chart is pretty convoluted and hard to fit anything else into, but still think it would be good to include "No" paths from the "Was successful" decisions to the appropriate handling (which is LIS determination I would think). =20 As to Hannes request for help from the DSLF, I'm happy to help in any way I can. I'll make sure they get any questions you need for them to answer. Of course, I'm editor of this document, and am tracking all your comments on this list. I'll do my best to be responsive, where I can answer questions directly. I really would like to see as much as possible be in phonebcp, and simply reference it. I have no intention of being redundant, or of going against the recommendations in phonebcp.=20 Barbara=20 =20 ________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Tuesday, September 18, 2007 12:11 PM To: ECRIT Cc: Cullen Jennings; Hannes Tschofenig; Romascanu, Dan (Dan); barbara.stark@att.com Subject: RE: [Ecrit] Some documents from DSL Forum Hi, (adding also Barbara Stark, Ed of the DSL document),=20 I also had a go tat the DSL Forum document -- looks pretty good overall. Also noted the "Known Gaps". =20 > Need to understand how long a device would need to wait for=20 > LLDP-MED and DHCP INFORM responses, in networks that don't=20 > support responses to these protocols. Adding some important details to Dan's... =20 In LLDP-MED, a "Fast Start" procedure is used at startup (not present in basic LLDP). In Fast Start. the Endpoint side initiates by transmitting a bust of -MED frames. By default, 4 frames are sent at 1 sec interval. Before that time, the Network Connectivity side (ie the upstream L2 switch) is only transmitting basic LLDP (not -MED extensions). In response to seeing that first -MED frame come in, the Network Connectivity device then immediately begins transmitting -MED frames back, again starting with a burst of 4 frames at 1 sec interval by default. So, as a result the Endpoint will learn its location (from the Location Identification TLVs) almost immediately at startup. In my experience, this is typically measurable in handfuls of ms, certainly well under 1 sec, unless there is frame loss (very rare in practice). The whole Fast Start procedure takes 4 sec max, so that would make a good "didn't work" threshold. =20 Note also that after startup phase, basic LLDP (and -MED by extension) will continue to advertise periodically at 30 sec interval by default (not 5 sec as Dan suggests). Also, due to basic LLDP behaviour, if any TLV information changes the change is immediately advertised, so if there is a change of location the Endpoint gets informed right away. Thus, the location will always stay up to date after that point, with a maximum window of 30 sec. =20 In the DSL document, the sequence flows in Appendix A look basically correct, the sequence of events looks good. However a better value for "Was LLDP-MED successful" would be 4 sec. Also, I do not see a "was it successful" decision for DHCP ("was location in DHCP response" only has a Yes result, and no timeout associated) -- probably helpful to add that. =20 Noting this stuff would also be helpful in the Phone BCP I think. (Brian already said he would do so.) =20 I am not deep on the DHCP part of the question, so perhaps someone else can provide some details there. However, I don't *think* there is any explicit threshold "didn't work" timer we could count on (could well be wrong on that). In my experience, DHCP process takes longer than LLDP-MED. =20 > Need requirements for soft client on a PC or PDA. These applications=20 > will not have the ability to control LLDP or DHCP options, but=20 > should be able to read them, if the underlying OS has requested=20 > these options.=20 Actually, LLDP / LLDP-MED does not necessarily need OS or driver support since it is defined above the MAC layer, though it would be nice of course. PC / PDA apps could build in the LLDP-MED capability directly. (Again, unclear on the DHCP part of this question.) =20 Cheers,=20 Peter Blatherwick (with Editor of LLDP-MED hat on)=20 "Romascanu, Dan (Dan)" =20 17.09.07 13:45=20 =20 To: "Cullen Jennings" , "Hannes Tschofenig" =20 cc: ECRIT =20 Subject: RE: [Ecrit] Some documents from DSL Forum LLDP has a periodic 'slow protocol' announcement timer which is inherited by LLDP-MED. Its default is at 5 seconds if I am not mistaken. A device is supposed to respond much faster (layer 2 single link protocol) so this timer can be used as a default worst case when facing non-responsive devices. =20 Dan > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: Monday, September 17, 2007 6:40 PM > To: Hannes Tschofenig > Cc: ECRIT > Subject: Re: [Ecrit] Some documents from DSL Forum >=20 >=20 > Sounds good. One thing that caught my attentions was in the=20 > gaps it mentions >=20 > Need to understand how long a device would need to wait for=20 > LLDP-MED and DHCP INFORM responses, in networks that don't=20 > support responses to these protocols. >=20 > Any advice we can give on that? Would phonebcp be a=20 > reasonable place to address that? >=20 >=20 > On Sep 15, 2007, at 12:57 PM, Hannes Tschofenig wrote: >=20 > > Hi Cullen, > > Hi all, > > > > I read through the documents. > > > > The text in the document can be classified into three types of > > feedback: > > > > -- Protocol specific requirements > > These are aspects that could be captured in the Phone BCP or are=20 > > already found in the protocol specific documents itself. > > I believe we have covered already most of these aspects=20 > (but we should=20 > > double-check it). > > > > -- Implementation-specific aspects > > I am not sure how well we can capture these aspects in our=20 > documents.=20 > > Still, they are fine with me. > > > > -- Interactions between different protocols and timing. > > There are a couple of timing aspects and protocol sequences=20 > (e.g., for=20 > > retrieving location information). I am not so sure about these=20 > > aspects. Is the timing reasonable? Is the sequence of retrieving=20 > > location information reasonable and generic enough? > > > > I think that the provided documents sound pretty reasonable to me. =20 > > We need to figure out what aspects are not yet covered in our=20 > > documents and then we should try to incorporate them. We need to=20 > > discuss them obviously. > > > > Help from members of the DSL forum would be useful. > > > > Ciao > > Hannes >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit *****=20 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625=20 ------_=_NextPart_001_01C7FA26.9E4452CE Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Thanks again for the LLDP-MED info. I'll feed = it to the=20 developer-types, and see what they think.
I agree the DHCP failure scenario can be filled = out a bit=20 better. I'll have to break my charts apart, but that's ok. If there's no = DHCP=20 response after the standard DHCP time-out, most devices do one of 3 = things:=20 assign themselves 0.0.0.0 and give up trying to talk externally; do IP = auto=20 addressing, see if there's anything to talk to, and then give up trying = to talk=20 externally; or have a static assignment to try (my laptop does this, = since we=20 have static in the office and DHCP in all other places). With a static=20 assignment, it makes sense to go to the "No" path of "Is DHCP used for IP = address=20 config?". I suppose on the off chance that auto addressing = succeeded in=20 finding something else (extremely low probability), that it might also = try that=20 path. I wouldn't give it much chance of succeeding.
Barbara

From: peter_blatherwick@mitel.com=20 [mailto:peter_blatherwick@mitel.com]
Sent: Tuesday, September = 18,=20 2007 2:17 PM
To: Stark, Barbara
Cc: Romascanu, Dan = (Dan);=20 ECRIT; Cullen Jennings; Hannes Tschofenig
Subject: RE: [Ecrit] = Some=20 documents from DSL Forum


Hi again Barbara, =
Trying to answer some of your questions back, = please see=20 [PB] inline below.
-- = Peter=20



"Stark, Barbara"=20 <bs7652@att.com>=20

18.09.07 13:26

        =
        To:   =  =20    <peter_blatherwick@mitel.com>, "ECRIT"=20 <ecrit@ietf.org>
 =20       cc:        "Cullen = Jennings"=20 <fluffy@cisco.com>, "Hannes Tschofenig"=20 <Hannes.Tschofenig@gmx.net>, "Romascanu, Dan (Dan)"=20 <dromasca@avaya.com>
 =20       Subject:        RE: = [Ecrit] Some=20 documents from DSL = Forum



Thanks for all the really useful input on LLDP and = LLDP-MED.=20 I'll be reflecting this in my next update.
I need to better understand the implications of a = client=20 running LLDP-MED, separate from the underlying OS. I would need for the = client=20 to know whether or not the OS provided that function, before it tried. = If one=20 client started doing it, then all the clients might decide they wanted = to do it,=20 too, and it might just get out of hand.

[PB] I agree there are potential issues if multiple = applications in a=20 single Endpoint device all decided to start LLDP-MED.  (You are = referring=20 to these applications as "clients" I believe??)  Potentially, the = first of=20 those would get immediate response, but others would not see -MED coming = back=20 until the next normal advertising cycle.  Hence, OS support would = be a good=20 thing.  I do not see this as a big issue though, since location = would only=20 be out of date for a max of the advertising interval (30 sec default), = and would=20 be correct thereafter.  A bit more serious would be the implication = on the=20 Network Connectivity Device side, where it would potentially be = receiving=20 multiple sets of advertisements.  Not only would there be more = traffic (a=20 non-issue in practice, since it is constrained to the link), but if each = app was=20 advertising different TLVs then the info from one could continually get=20 overridden with info from the other(s).  I would expect multiple = apps all=20 wanting to use LLDP-MED in a single device to be rare though, at least = at this=20 point.  

There is a=20 "known gap" on the DHCP INFORM timer, but not the standard DHCP request. = My=20 logic there was that if a device is configured to do DHCP for bootstrap, = then it=20 will be completely unable to do anything at a higher layer (including = make an=20 emergency call), until it gets a response. I have yet to find a mass = market home=20 network setup where auto addressing works to get network connectivity, = after=20 DHCP failed. There's usually a 60 second timer to try to get a response = to DHCP=20 DISCOVERY, after which the device gives up. It may periodically try DHCP = again,=20 but that's outside the scope of this document. I should probably try to = fit this=20 failure into my chart, but I ran out of room.
 
[PB] Yup, = this makes sense=20 now.  Yeah, the chart is pretty convoluted and hard to fit anything = else=20 into, but still think it would be good to include "No" paths from the = "Was=20 <method x> successful" decisions to the appropriate handling = (which is LIS=20 determination I would think).  

As to Hannes request for help from the DSLF, I'm happy to help = in any way=20 I can. I'll make sure they get any questions you need for them to = answer. Of=20 course, I'm editor of this document, and am tracking all your comments = on this=20 list. I'll do my best to be responsive, where I can answer questions = directly. I=20 really would like to see as much as possible be in phonebcp, and simply=20 reference it. I have no intention of being redundant, or of going = against the=20 recommendations in phonebcp.
Barbara
 

From: peter_blatherwick@mitel.com=20 [mailto:peter_blatherwick@mitel.com]
Sent: Tuesday, September = 18,=20 2007 12:11 PM
To: ECRIT
Cc: Cullen Jennings; Hannes=20 Tschofenig; Romascanu, Dan (Dan); = barbara.stark@att.com
Subject: RE:=20 [Ecrit] Some documents from DSL Forum


Hi, (adding also Barbara Stark, Ed of the = DSL=20 document),

I=20 also had a go tat the DSL Forum document -- looks pretty good overall.=20  Also noted the "Known Gaps".  

> Need to understand how = long a device=20 would need to wait for
> LLDP-MED and DHCP INFORM responses, in = networks=20 that don't
> support responses to these = protocols.

Adding some = important details=20 to Dan's...    
In LLDP-MED, a "Fast Start" procedure is used at startup = (not present=20 in basic LLDP).  In Fast Start. the Endpoint side initiates by = transmitting=20 a bust of -MED frames.  By default, 4 frames are sent at 1 sec = interval.=20  Before that time, the Network Connectivity side (ie the upstream = L2=20 switch) is only transmitting basic LLDP (not -MED extensions).  In = response=20 to seeing that first -MED frame come in, the Network Connectivity device = then=20 immediately begins transmitting -MED frames back, again starting with a = burst of=20 4 frames at 1 sec interval by default.  So, as a result the = Endpoint will=20 learn its location (from the Location Identification TLVs) almost = immediately at=20 startup.  In my experience, this is typically measurable in = handfuls of ms,=20 certainly well under 1 sec, unless there is frame loss (very rare in = practice).=20  The whole Fast Start procedure takes 4 sec max, so that would make = a good=20 "didn't work" threshold.  

Note also that after startup phase, basic = LLDP (and=20 -MED by extension) will continue to advertise periodically at 30 sec = interval by=20 default (not 5 sec as Dan suggests).  Also, due to basic LLDP = behaviour, if=20 any TLV information changes the change is immediately advertised, so if = there is=20 a change of location the Endpoint gets informed right away.  Thus, = the=20 location will always stay up to date after that point, with a maximum = window of=20 30 sec.    

In the DSL document, the sequence flows in Appendix A look = basically=20 correct, the sequence of events looks good.  However a better value = for=20 "Was LLDP-MED successful" would be 4 sec.  Also, I do not see a = "was it=20 successful" decision for DHCP ("was location in DHCP response" only has = a Yes=20 result, and no timeout associated) -- probably helpful to add that. =  =20

Noting this=20 stuff would also be helpful in the Phone BCP I think.  (Brian = already said=20 he would do so.)  

I am not deep on the DHCP part of the question, so perhaps = someone=20 else can provide some details there.  However, I don't *think* = there is any=20 explicit threshold "didn't work" timer we could count on (could well be = wrong on=20 that).  In my experience, DHCP process takes longer than LLDP-MED.=20  

> Need = requirements for soft client on a PC or PDA. These applications
> = will=20 not have the ability to control LLDP or DHCP options, but
> = should be=20 able to read them, if the underlying OS has requested
> these = options.=20

Actually,=20 LLDP / LLDP-MED does not necessarily need OS or driver support since it = is=20 defined above the MAC layer, though it would be nice of course.  PC = / PDA=20 apps could build in the LLDP-MED capability directly.  (Again, = unclear on=20 the DHCP part of this question.)   =

Cheers, =
Peter Blatherwick (with Editor of = LLDP-MED hat=20 on)



"Romascanu, = Dan (Dan)"=20 <dromasca@avaya.com>

17.09.07 13:45=20

      =  =20
      =  To:=20        "Cullen Jennings" = <fluffy@cisco.com>,=20 "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>=20
      =  cc:=20        ECRIT = <ecrit@ietf.org>
  =    =20  Subject:        RE: [Ecrit] Some = documents from=20 DSL Forum




LLDP has a periodic 'slow protocol' announcement timer = which=20 is
inherited by LLDP-MED. Its default is at 5 seconds if I am not=20 mistaken.
A device is supposed to respond much faster (layer 2 single = link
protocol) so this timer can be used as a default  worst = case when=20 facing
non-responsive devices. =  

Dan





>=20 -----Original Message-----
> From: Cullen Jennings=20 [mailto:fluffy@cisco.com]
> Sent: Monday, September 17, 2007 6:40 = PM
> To: Hannes Tschofenig
> Cc: ECRIT
> Subject: Re: = [Ecrit]=20 Some documents from DSL Forum
>
>
> Sounds good. One = thing=20 that caught my attentions was in the
> gaps it mentions
> =
>=20 Need to understand how long a device would need to wait for
> = LLDP-MED=20 and DHCP INFORM responses, in networks that don't
> support = responses to=20 these protocols.
>
> Any advice we can give on that? Would = phonebcp=20 be a
> reasonable place to address that?
>
> =
> On Sep=20 15, 2007, at 12:57 PM, Hannes Tschofenig wrote:
>
> > Hi = Cullen,
> > Hi all,
> >
> > I read through = the=20 documents.
> >
> > The text in the document can be = classified=20 into three types of
> > feedback:
> >
> > -- = Protocol=20 specific requirements
> > These are aspects that could be = captured in=20 the Phone BCP or are
> > already found in the protocol = specific=20 documents itself.
> > I believe we have covered already most of = these=20 aspects
> (but we should
> > double-check it).
>=20 >
> > -- Implementation-specific aspects
> > I am = not sure=20 how well we can capture these aspects in our
> documents. =
> >=20 Still, they are fine with me.
> >
> > -- Interactions = between=20 different protocols and timing.
> > There are a couple of = timing=20 aspects and protocol sequences
> (e.g., for
> > = retrieving=20 location information). I am not so sure about these
> > = aspects. Is=20 the timing reasonable? Is the sequence of retrieving
> > = location=20 information reasonable and generic enough?
> >
> > I = think=20 that the provided documents sound pretty reasonable to me. =  
> >=20 We need to figure out what aspects are not yet covered in our
> = >=20 documents and then we should try to incorporate them. We need to =
> >=20 discuss them obviously.
> >
> > Help from members of = the DSL=20 forum would be useful.
> >
> > Ciao
> >=20 Hannes
>
> = _______________________________________________
>=20 Ecrit mailing list
> Ecrit@ietf.org
>=20 https://www1.ietf.org/mailman/listinfo/ecrit
>=20

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

*****=20

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

*****

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

 ------_=_NextPart_001_01C7FA26.9E4452CE-- --===============1575858949== 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 --===============1575858949==-- From ecrit-bounces@ietf.org Wed Sep 19 17:07:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY6kL-0002U5-2Y; Wed, 19 Sep 2007 17:06:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY6kJ-0002Tt-Qc for ecrit@ietf.org; Wed, 19 Sep 2007 17:06:07 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY6kI-00069c-Vj for ecrit@ietf.org; Wed, 19 Sep 2007 17:06:07 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IY6k5-0003vH-1P; Wed, 19 Sep 2007 16:05:53 -0500 From: "Brian Rosen" To: "'Alexander Mayrhofer'" , "'Hannes Tschofenig'" , "'ECRIT'" , "'James M. Polk'" References: <46B048B1.7050602@gmx.net> <8BC845943058D844ABFC73D2220D4665069ECC4F@nics-mail.sbg.nic.at> Date: Wed, 19 Sep 2007 17:06:03 -0400 Message-ID: <10fd01c7fb00$e4c97c10$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfUGKazZE/NU4F2QwCSWxOCGjc7eAGYi/OACBm8/tA= In-Reply-To: <8BC845943058D844ABFC73D2220D4665069ECC4F@nics-mail.sbg.nic.at> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: Subject: [Ecrit] RE: review of phone-bcp (was: Reviewers of Phone BCP & Framework) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Alexander I'm finishing an update to -framework and -phonebcp today and I resolved most of the comments you provided except as noted below: > - Section 5: The "one-button" thing: How broad is that opinion of PSAPs? > I'm just curious whether that is the opinion of a few, or the vast > majority of PSAP operators agrees on that... This is a very widely held view. It used to be common to have a one button emergency call on early mobiles. The incidence of false calls was very high, and the emergency authorities prevailed on the mobile operators to get rid of that feature. If it takes a sequence, it's okay, but one button is very bad. I don't know any PSAP person who is in favor of one button emergency call features. > > - Section 5: "Home dialstring": I think keeping the home dial string > poses quite some problems, because they are merged into the local dial > plan of the country/region visited. For example, Vienna has a full > 7-digit number block under "911xxxx". From a phone visiting from the US, > any call to any of those 10000 actual numbers would make the user > unwittingly place an emergency call, given that the phone also imports > the local dial plan... (and i suppose it would be much worse with > numbers starting with "112" in the US?) People are used from mobile > networks that their "home" dialstring for emergency calls is > unavailable, so i don't think it's worth to invent new behaviour for IP > phones... The document says home dial string is a MAY, local is a MUST. It's usually easier to integrate the home number in a dial plan, because the plan is usually determined from the home calling system. The counter argument to the one you are making is that the visitor is much more likely to know his home emergency dial string than he is to know the local one, and when people are stressed, they often do the "wrong" thing. > > - Section 6.1: bullet 1) This essentially puts an requirement for > support of TLS and sips on every device able to place emergency calls. > Is that intended, and if yes, is that even possible in a BCP? Yes, it is intended. It's because the call carries location. The BCP does say "Try TLS, but if it fails, retry without it". > > - Section 6.3: Are there any requirements on a proxy if it detects a > "direct" PSAP call (PSAP URI in the Request line), with the service URN > only in the Route: header? No, it would be treated as a normal call. It may route correctly, but we can't guarantee that. I don't understand how you could get the service URN in a Route header unless you had a bad implementation. > > - Section 6.5: I'm really unsure about the requirement of not allowing > the user to send a BYE. Wouldn't that violate the SIP specs? Especially > the "PSAP gets called again" part really should be coordinated with > PSAPs on a broad basis - that sounds really scary to me... The user who > has placed an emergency call by accident will try to hangup again, then > the phone rings again, the user tries to hang up again, and so on... In > the end, he has probably put a nice DoS attack on the PSAP, because 12 > agents are trying to figure why this guy repeatedly calls the PSAP.... > in almost none of the cases, he will reach the same agent... PSAPs have big problems with "abandoned calls". They really would prefer that you tell them you made a mistake. In most jurisdictions, the PSAP will call back when it receives an abandoned call, and in some, it will dispatch a police officer if it can't talk to the caller. In the example you raised, there is only one call, and one call taker. The call stays up through the repeated hang up, pick up cycles. The only time there would be multiple calls would be if he calls, the PSAP releases the call, and he calls again. This would not invoke the mechanism discussed. The mechanism says: don't send a BYE, keep the session active. Signal an alert to the user, and when he picks up, he is still on the original call. > > - Section 6.6 should say that those features are to be disabled only > while a emergency call is in progress... Disabling features on inbound > call poses an interesting challenge: How does the UA identify such > calls? It would be very tempting for SPITters to fake being a PSAP, and > disable all kind of anti-spit measures on the phone, probably even the > option to hang up the SPIT call... I fixed the wording to clarify. There is also text on how to determine which call is a PSAP call. Basically its only detected after a successfully outbound emergency call, it has to be from the domain that answered the call, and it has to occur within some short time period after the original call was completed. There is text that warns about it being a problem. > > Returning a dereferenced location in such test calls could provide a > nice way to use the PSAP as a man-in-the-middle for inappropriate access > to location information - simply put the location URI of another user in > the Request, and use that test mechanism to let the PSAP dereference the > location URI on behalf of the attacker? Smells like a BIG security hole > to me, especially since the PSAP probably has no way to identify which > location URI belongs to which user (only the service provider would be > able to do that). I think that should definitely be addressed in the > Security Considerations section... The security of the reference is the same as the security of the value. Having the reference has to be assumed to be the same as having the value. You don't know for whom the LIS will dereference. There is new text about location hiding for the test. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 19 17:07:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY6kb-0002Vx-JC; Wed, 19 Sep 2007 17:06:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY6ka-0002Vi-5h for ecrit@ietf.org; Wed, 19 Sep 2007 17:06:24 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY6kY-0006ap-TC for ecrit@ietf.org; Wed, 19 Sep 2007 17:06:24 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IY6kL-0003xv-J9; Wed, 19 Sep 2007 16:06:09 -0500 From: "Brian Rosen" To: "'Richard Barnes'" , "'ECRIT'" , "'James M. Polk'" , "'Henning Schulzrinne'" , "'Andrew Newton'" References: <46BC984B.6050207@bbn.com> Date: Wed, 19 Sep 2007 17:06:19 -0400 Message-ID: <10ff01c7fb00$eea793c0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfbbzYr3Pvx2FhhSOGF2+9e0KHUSAfeGmww In-Reply-To: <46BC984B.6050207@bbn.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [Ecrit] RE: Review of phonebcp and framework X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Thank you for your comments on these documents. I will be releasing new versions of both today. I have resolved all of them except as noted below: > * One threat that's not addressed is the one introduced by phonebcp's > recommendations about call termination, namely that if a phone gets a > call from another AOR in the same domain as the PSAP, then it should > drop its current call and take the new one. This policy introduces a > denial of service attack: An attacker can send an INVITE with a spoofed > AoR and force emergency callers to disconnect from PSAPs. How were the > authors thinking about dealing with this? The text is now very specific about when you do that. It only occurs if have an active emergency call, the session timer is running, you hang up, and you get a call back from the domain that answered the original call. That's a very small window from a spoofed domain. > > * References to draft-rosen-iptel-dialstring should be to RFC 4967. > However, I think tel: URIs are appropriate in this case. The reference is fixed. The text now says MUST dial string and SHOULD tel. Tel is not appropriate in this case; it is neither a global number nor a local number. It is in fact a dial string. > >For endpoints with multiple types of network interfaces (such as >an Ethernet jack and a WiFi connection), serious incompatibilities would >ensue unless every network >supported every protocol, or alternatively, every device supported >every protocol. The text says every device supports every protocol. Did you miss that? The text is clearer now in any case. The device supports all, the network supports at least one. >instead of dial strings>Use the "tel:" URI scheme here. RFC 3966 allows for numbers that >are not globally routable. But it's not a telephone number, it is a dial string. We translate it to a URI. As above, the text now says tel SHOULD be accepted. >This section is very incomplete, largely because the relevant >security mechanisms don't exist - they're being worked now by the GEOPRIV >working group. Recommend removing for now; replace with a reference to >draft-barnes-geoprivlo-sec and draft-ietf-ecrit-security-threats. I did that, but it seems like a cop-out. I'd like some more comments from other work group members (and maybe A-Ds, and maybe asking for a security directorate reviewer) on the ability to do that. Note the editors note in the section. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 19 17:07:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY6kc-0002WA-OS; Wed, 19 Sep 2007 17:06:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY6kb-0002Vs-1z for ecrit@ietf.org; Wed, 19 Sep 2007 17:06:25 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY6ka-0006A0-DZ for ecrit@ietf.org; Wed, 19 Sep 2007 17:06:24 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IY6kN-0003xv-7H; Wed, 19 Sep 2007 16:06:11 -0500 From: "Brian Rosen" To: "'Stark, Barbara'" , "'ECRIT'" References: <46B048B1.7050602@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA052D5D2C@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA052D5D5A@crexc41p> Subject: RE: [Ecrit] Review of Framework - substantive comments Date: Wed, 19 Sep 2007 17:06:23 -0400 Message-ID: <110001c7fb00$ef9db390$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfUGLqJayuUOO1nSUSpkkO3NcP5mQASDb6gATMHzDAIb0OuIA== In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA052D5D5A@crexc41p> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 Thank you for your review. There is an update of both -framework and -phonebcp coming out today. > Section 5.3, 3rd paragraph: The sentence "All location objects MUST be > delivered to the PSAP" suggests that a device needs to send all LO's > that it has, even the manual one(s), which doesn't seem consistent with > LoST section 11.1 items 3 ("a client SHOULD NOT send multiple > profiles derived from different baseline profiles")and 6 ("A server uses > the first-listed location profile that it understands and ignores the > others"). Or is the sentence trying to say that "All location objects > that a device and other intermediate proxies include in a message MUST > be delivered to the PSAP"? That would be ok. But I really want to make > sure the device is allowed to decide which one location to send, if it > has several. Please have a look at the text now. There is even a section called "Multiple locations". I think it's now clear that: 1. If you get multiple locations, you pass all of them on 2. If you get one or more locations from the UA, you can add one or more than one, but you route on one of the ones you got from the UA. 3. No matter who routes, they pick one to route on, and mark it. > > Section 5.5, DHCP: After reading this, I'm confused as to whether a > device should use REQUEST or INFORM when it uses means other than DHCP > for getting its IP address. RFC2131 says DHCPINFORM is for "asking only > for local configuration parameters" where the "client already has > externally configured network address". The DHCPREQUEST message seems to > require the server to do all sorts of checking of IP addresses and > leases and such, so that it doesn't really seem appropriate when the > device got its address through other means. I'm happy to be better > educated on this topic, though. Probably needs some more investigation and work. Anyone else care to comment? > > Section 5.5, 3rd from last paragraph: It is not necessary for a device > to support a phonebcp-list protocol towards the WAN if it does a > proprietary protocol to its LAN. The location could be manually > configured. I would expect such manual configuration in corporate campus > environments like the one I'm in. The buildings in this corporate campus > are served by a private intranet. Although I'm in Atlanta, the > Internet-facing server is in Birmingham. Therefore, it would be the > corporation's responsibility to manually configure locations in > routers/servers, as appropriate. I would recommend deleting the sentence > "However, unless another element ... won't be able to acquire its > location." I deleted all of the text that talks about private mechanisms. It now just has the list and devices do all, networks do one. I think you can't get away with static configuring. The number of situations where you have things like laptops with softclients or IM clients roaming into these networks is way too high. You need an LCP. May I recommend DHCP or LLDP for your campus? > > Section 6, Type of Emergency Service: "We support this mechanism by > optionally labeling calls with a service identifier" -- I thought that > labeling with a service identifier was mandatory, but that the use of > more specific (than just "sos") was optional. Am I wrong? I think you are right. There are a bunch of changes in the text now. Let me know if I have made it clear now or not. > > Section 10, disabling of call features: Since I have comments against > some of this text in phonebcp, I would prefer if this list of what must > and should be disabled is in one place only. So, I'd prefer if this said > simply "While in a call, a number of other call features need to be > disabled. This is discussed in [phonebcp]." I fixed this. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 19 17:07:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY6kW-0002VD-8z; Wed, 19 Sep 2007 17:06:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY6kU-0002V1-P0 for ecrit@ietf.org; Wed, 19 Sep 2007 17:06:19 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY6kP-0006aX-Fv for ecrit@ietf.org; Wed, 19 Sep 2007 17:06:18 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IY6kC-0003wm-8b; Wed, 19 Sep 2007 16:06:00 -0500 From: "Brian Rosen" To: , "'ECRIT b'" , "'James M. Polk'" References: <4643F859.9010301@ntt-at.com> Date: Wed, 19 Sep 2007 17:06:10 -0400 Message-ID: <10fe01c7fb00$e91a5fa0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceTiT3NijQWX4y1TBi+Ov7viDiRBBnW5Vzg In-Reply-To: <4643F859.9010301@ntt-at.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Subject: [Ecrit] RE: Review: draft-ietf-ecrit-phonebcp-01.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 Shida Thank you for your review. I will be releasing a new version of -framework and -phonebcp today. I have resolved all of your comments except as noted below: > T2: Section 4.3. > - I don't really see how location determined by network can > be explicitly overridden by the location user enters. Even > if device manages to override location information it obtained > through DHCP, L7-LCP or LLDP-MED, same provider that provided > the location can still insert the location by reference. It is a truism with the PSAP people that whatever the caller SAYS is his location is believed over what the system tells them. If the system says the caller is at 100 Main Street, but the caller insists he is at 250 North Avenue, the responders will be sent to North Avenue and not Main Street. They may question the caller more carefully, but they assume that the caller knows more about the actual situation than the network does. For a carrier, the liability of being wrong ("you say you are on North, I think you are on Main") is too high to accept. The text now says you can send where the network thinks the guy is, but you route on the user's version of location. The example I use for this case is a "Pringles Can" antenna on a WiFi AP. You can put a remote LAN a mile or more away from the carrier's nominal demarc point. The user knows what he has done, the carrier does not. > > - Although not a normative text, "Location must be validated" seems a bit > too strong. I don't have a strong feeling for this but I prefer something > like a should rather than a must.. The PSAPs insist it is a MUST. The text is now somewhat clearer about this than in used to be, but the access network MUST validate before you put a location in the LIS. Validation on locations received from the LIS is optional. > > Question is what if UA doesn't support LoST? I guess it can't really > forward the call to proxy to simply obtain PSAP URI could it? As it > would probably end up making the actual emergency call... The text has been improved in this area, so I may have resolved this completely. Generally, the proxy looks for all possible cases: no dial string recognition, dial string recognition but no LoST, LoST. It fixes the first two one way or another. It routes the third per normal SIP procedures. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 19 17:07:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY6kk-0002bA-UW; Wed, 19 Sep 2007 17:06:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY6kj-0002aS-Uf for ecrit@ietf.org; Wed, 19 Sep 2007 17:06:33 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY6ki-0006bE-Pw for ecrit@ietf.org; Wed, 19 Sep 2007 17:06:33 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IY6kV-0003yq-OX; Wed, 19 Sep 2007 16:06:19 -0500 From: "Brian Rosen" To: "'Stark, Barbara'" , "'ECRIT'" References: <46B048B1.7050602@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA052D5D2C@crexc41p> Subject: RE: [Ecrit] Review of Framework - editorial comments Date: Wed, 19 Sep 2007 17:06:29 -0400 Message-ID: <110101c7fb00$f4b54280$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfUGLqJayuUOO1nSUSpkkO3NcP5mQASDb6gCaJP+lA= In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA052D5D2C@crexc41p> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I fixed all of these but: > 10. Section 9, first sentence "The call-taker must be able..." . Since > some jurisdictions allow calls from uninitialized devices, I don't think > it can be said that this is truly "must". Perhaps "It is highly > desirable for the call-taker to be able to reach..." I did a lot of rework on this text. Take a look at both framework and phonebcp updates coming today and let me know if I have satisfied you on this item. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 19 17:07:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY6l4-0002jB-9Y; Wed, 19 Sep 2007 17:06:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY6l2-0002hQ-52 for ecrit@ietf.org; Wed, 19 Sep 2007 17:06:52 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY6l1-0006Aj-Jw for ecrit@ietf.org; Wed, 19 Sep 2007 17:06:51 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IY6kh-00040H-Vj; Wed, 19 Sep 2007 16:06:38 -0500 From: "Brian Rosen" To: "'Stark, Barbara'" , "'ECRIT'" References: <7582BC68E4994F4ABF0BD4723975C3FA03B0F1F2@crexc41p> Subject: RE: [Ecrit] Phonebcp comments Date: Wed, 19 Sep 2007 17:06:42 -0400 Message-ID: <110201c7fb00$fe54a380$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceBKcW36FqDb+IBQnaOU3mPstkO7B5wkQPA In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA03B0F1F2@crexc41p> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9178bae9f85419fdc08e9f2c86e345d0 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1649602532==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1649602532== Content-Type: multipart/alternative; boundary="----=_NextPart_000_1103_01C7FADF.77430380" This is a multi-part message in MIME format. ------=_NextPart_000_1103_01C7FADF.77430380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 3. Section 4.5 Converting to PIDF-LO - Isn't there an IETF reference for how to do this for a DHCP-delivered location? If there is, I'm not aware, or have forgotten it. 7. Section 6.5 Last paragraph - where did "5 minutes" come from? Is this a recommended default, or is it exactly the right number? If it's a default, what would be a reasonable range for configuration? The text now reads "The suggested timer period is 5 minutes". I've taken flack from several people about hard numbers. My defense is that an implementer needs to know what to do. This case, like several others, the time isn't hard. You need something. 5 minutes is as good as anything. You don't want to configure it. This case isn't a good example, but in some of these, the number could be overridden by local regulation. How a device vendor is supposed to deal with that is beyond me, but that won't stop regulators. I think it's essential to put a stake in the ground and say "here is a value". I've tried to reword the text to be equivocal, as in this case "suggested". 8. Section 6.6 Disabling of features I would prefer to see the first sentence reworded to be more explicit, like "When a calling device and/or service determines an emergency call is being made or is in progress, it SHOULD disable outgoing call features such as:" The text now says ". MUST disable . when an emergency call is established". Do I need to explicitly cover the case of "being established"? 9. Section 6.6 Disabling of features I'm not sure we should disable 3-way calling (which may require use of flash hook). I think there could be a case where someone has called their best friend to ask for help, instead of 9-1-1, and the friend then calls 9-1-1 and bridges the two legs together. If the first leg is lost, then the friend may need to try to re-establish the first leg, because the PSAP may not have the necessary info. I probably need some help to word this correctly. I think if you have a 2 way up, flash, and try to establish a call to 9-1-1, you don't end up with a 3 way call in today's system. In NENA we have an explicit way to set up a 3 way using a bridge at the PSAP. It's for use by a call center (like OnStar). 12. Section 9.1 Testing Mechanism 2nd paragraph, "For the latter, the PSAP SHOULD return location-by-value even if the original location delivered with the test was by-reference." I completely disagree. I believe the appropriate requirement is "For the latter, the PSAP MUST NOT return location-by-value when the original location delivered with the test was by-reference." The point is to see if the PSAP gets the right location for you. The problem you are having is, I assume, location hiding. The text now says that the PSAP uses credentials supplied by the LIS for that purpose. That would let the LIS decide what it returns for testing. 13. Section 9.1 4th paragraph. I'm not comfortable with the potential frequency of testing that these requirements would cause. Is there some way a PSAP can specifically tell an end device to not query this same PSAP uri in a given (in the SIP response) amount of time? The text is now more clear. In -framework, there is text that analyzes what it takes to support a million callers with an update of location per day. It's 12 queries a second. Supporting 10 million NYC callers in 30 days seems reasonable. 14. Section 10.1 1st paragraph, last sentence, "The [L7 LCP] is not limited and TLS SHOULD be used to protect location privacy." It's possible to implement theL7 LCP in an environment and manner so that it is limited. I would prefer for this to read "The [L7 LCP] may not be limited and TLS SHOULD be used to protect location privacy." I actually went the other way on you and changed it to MUST :-(. The "limited" text is gone. There is a generic TLS MUST be used to protect location (but see Section 9.1). Section 9.1 says ED-58/AN-27 https: MUST be specified when attempting to retrieve location (configuration or dereferencing) with HELD. The use of [RFC4507] is RECOMMENDED to minimize the time to establish TLS sessions. ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623 ------=_NextPart_000_1103_01C7FADF.77430380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phonebcp comments

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

If there is, I’m not aware, or have forgotten = it.

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

The text now reads “The suggested timer period = is 5 minutes”.  I’ve taken flack from several people about = hard numbers.  My defense is that an implementer needs to know what to do.  This case, like several others, the time isn’t = hard.  You need something.  5 minutes is as good as anything.  You = don’t want to configure it.  This case isn’t a good example, but in = some of these, the number could be overridden by local regulation.  How = a device vendor is supposed to deal with that is beyond me, but that = won’t stop regulators.  I think it’s essential to put a stake in = the ground and say “here is a value”.  I’ve tried to = reword the text to be equivocal, as in this case = “suggested”.

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

The text now says “… MUST disable … = when an emergency call is established”.   Do I need to = explicitly cover the case of “being = established”?

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

I probably need some help to word this = correctly.  I think if you have a 2 way up, flash, and try to establish a call to = 9-1-1, you don’t end up with a 3 way call in today’s system.  In = NENA we have an explicit way to set up a 3 way using a bridge at the PSAP.  = It’s for use by a call center (like OnStar).  =

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

The point is to see if the PSAP gets the right = location for you.  The problem you are having is, I assume, location = hiding.  The text now says that the PSAP uses credentials supplied by the LIS for = that purpose.  That would let the LIS decide what it returns for = testing.

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

The text is now more clear.  In -framework, there = is text that analyzes what it takes to support a million callers with an = update of location per day.  It’s 12 queries a second.  Supporting = 10 million NYC callers in 30 days seems = reasonable.

14. Section = 10.1
1st paragraph, last sentence, “The [L7 LCP] is not = limited and TLS SHOULD be used to protect location privacy.”
It’s possible to implement theL7 LCP in an environment and manner = so that it is limited. I would prefer for this to read “The [L7 LCP] may = not be limited and TLS SHOULD be used to protect location privacy.”
I actually went the other way on you and changed it to = MUST L.  The “limited” text is gone.  There is a generic TLS MUST be used to protect location (but = see Section 9.1).  Section 9.1 says ED-58/AN-27 https: MUST be specified when attempting to retrieve location (configuration or =

dereferencing) with = HELD.  The use of [RFC4507] is RECOMMENDED to minimize the time to establish TLS = sessions.

 

*****

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

 ------=_NextPart_000_1103_01C7FADF.77430380-- --===============1649602532== 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 --===============1649602532==-- From ecrit-bounces@ietf.org Wed Sep 19 17:10:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY6oB-0007KR-Lm; Wed, 19 Sep 2007 17:10:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY6o8-00074X-11; Wed, 19 Sep 2007 17:10:04 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY6o7-0006gq-MF; Wed, 19 Sep 2007 17:10:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id DF87126E1B; Wed, 19 Sep 2007 21:10:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IY6o5-0001FR-Qd; Wed, 19 Sep 2007 17:10:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 19 Sep 2007 17:10:01 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-framework-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Framework for Emergency Calling using Internet Multimedia Author(s) : B. Rosen, et al. Filename : draft-ietf-ecrit-framework-03.txt Pages : 36 Date : 2007-09-19 The IETF has several efforts targeted at standardizing various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-framework-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-framework-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-09-19170220.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-framework-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-framework-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-19170220.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Wed Sep 19 17:10:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY6o8-00075T-7X; Wed, 19 Sep 2007 17:10:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY6o7-0006vR-2r; Wed, 19 Sep 2007 17:10:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY6o5-0006gl-V3; Wed, 19 Sep 2007 17:10:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id E33A63287E; Wed, 19 Sep 2007 21:10:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IY6o5-0001FT-RA; Wed, 19 Sep 2007 17:10:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 19 Sep 2007 17:10:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Best Current Practice for Communications Services in support of Emergency Calling Author(s) : B. Rosen, J. Polk Filename : draft-ietf-ecrit-phonebcp-02.txt Pages : 38 Date : 2007-09-19 The IETF has several efforts targeted at standardizing various aspects of placing emergency calls. This memo describes best current practice on how devices, networks and services should use such standards to make emergency calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-phonebcp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-phonebcp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-09-19170652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-phonebcp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-phonebcp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-19170652.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Wed Sep 19 17:24:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY71P-0000gx-Sg; Wed, 19 Sep 2007 17:23:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY71N-0000gr-QY for ecrit@ietf.org; Wed, 19 Sep 2007 17:23:45 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IY71H-00075o-Le for ecrit@ietf.org; Wed, 19 Sep 2007 17:23:45 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 19 Sep 2007 17:23:36 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8JLNZri011978; Wed, 19 Sep 2007 17:23:35 -0400 Received: from [68.50.16.73] (che-vpn-cluster-1-186.cisco.com [10.86.240.186]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8JLNOV4013018; Wed, 19 Sep 2007 21:23:24 GMT In-Reply-To: <110201c7fb00$fe54a380$640fa8c0@cis.neustar.com> References: <7582BC68E4994F4ABF0BD4723975C3FA03B0F1F2@crexc41p> <110201c7fb00$fe54a380$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <91D87B6E-657E-4738-AD7A-FDBAEEAFB69B@cisco.com> Content-Transfer-Encoding: quoted-printable From: John Schnizlein Subject: Re: [Ecrit] Phonebcp comments Date: Wed, 19 Sep 2007 17:23:18 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=625; t=1190237015; x=1191101015; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jschnizl@cisco.com; z=From:=20John=20Schnizlein=20 |Subject:=20Re=3A=20[Ecrit]=20Phonebcp=20comments |Sender:=20 |To:=20=22Brian=20Rosen=22=20; bh=5HsZtlK4WDkOuP/6l1zjqa5u0FIgvR9eY+VZ95uNXNs=; b=RjP5Zec1kOHP/l0rp1RREzrh7gu0N0dSrR+3RyDJjrSc4tASDBS2iZHmoIcf4YjEF5FlenZL s/Mb5g9ynvYLfLzdJs8Lrp8ymyMFhr2+2KVIpc0B7X0NTLpt9Tdnk3fW; Authentication-Results: rtp-dkim-2; header.From=jschnizl@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: "'Stark, Barbara'" , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org That is the subject of draft-ietf-geopriv-binary-lci-00, which =20 expired July 1 after the (previous) GeoPriv chair let it languish =20 after the WG adopted it as a WG item. There is a misinterpretation about the resolution parameter in RFC =20 3825 that this draft was written to clarify, but the dispute of the =20 meaning of resolution has not gone away. John On Sep 19, 2007, at 5:06 PM, Brian Rosen wrote: > 3. Section 4.5 > Converting to PIDF-LO =96 Isn=92t there an IETF reference for how to = do =20 > this for a DHCP-delivered location? > > If there is, I=92m not aware, or have forgotten it. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 19 17:26:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY74C-0003kX-T5; Wed, 19 Sep 2007 17:26:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY74B-0003jA-0C for ecrit@ietf.org; Wed, 19 Sep 2007 17:26:39 -0400 Received: from ns7.neustar.com ([156.154.24.88] helo=nc.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY74A-0006re-N6 for ecrit@ietf.org; Wed, 19 Sep 2007 17:26:38 -0400 Received: from ([10.31.13.50]) by chihiron1.nc.neustar.com with ESMTP id 5202942.1507658; Wed, 19 Sep 2007 17:26:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Sep 2007 17:26:19 -0400 Message-ID: <31D151A3D66E404AACBBB0247ACA54A7253F36@STNTEXCH11.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New versions of -framework and -phonebcp Thread-Index: Acf7A7hDC8PHiGR3TgutytDBlGP7+A== From: "Rosen, Brian" To: "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ecrit] New versions of -framework and -phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org There are new versions of -framework and -phonebcp to enjoy. This is a MAJOR rewrite of both documents. They are designed so that you read -framework to understand what is happening, and why, and you read -phonebcp to get the actual normative BCP text. They have exactly the same structure and table of contents (other than the appendix in -phonebcp). =20 -phonebcp is very terse; it has almost no text other than the normative statements. As discussed in Chicago, -phonebcp has a "walk through the call" presentation, plus an appendix that repeats the normative requirements, but sorts them by responsible party (end device, calling network, access network). All of the comments received against the prior versions have been resolved (even Henning's, I did get through all of his this pass). Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 19 17:31:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY78u-0003gy-IR; Wed, 19 Sep 2007 17:31:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY78t-0003g0-Tm for ecrit@ietf.org; Wed, 19 Sep 2007 17:31:31 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IY78t-00076Q-Dq for ecrit@ietf.org; Wed, 19 Sep 2007 17:31:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7235.2 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] Home and local dialstrings Date: Wed, 19 Sep 2007 23:31:47 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D466B1E25@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Home and local dialstrings Thread-Index: AcfUGKazZE/NU4F2QwCSWxOCGjc7eAGYi/OACBm8/tAACCY5bg== References: <46B048B1.7050602@gmx.net><8BC845943058D844ABFC73D2220D4665069ECC4F@nics-mail.sbg.nic.at> <10fd01c7fb00$e4c97c10$640fa8c0@cis.neustar.com> From: "Stastny Richard" To: "Brian Rosen" , "Alexander Mayrhofer" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, Alexander, =20 >The document says home dial string is a MAY, local is a MUST. It's = usually >easier to integrate the home number in a dial plan, because the plan is >usually determined from the home calling system. The counter argument = to >the one you are making is that the visitor is much more likely to know = his >home emergency dial string than he is to know the local one, and when = people >are stressed, they often do the "wrong" thing. I know about the requirements about the local dial string, but I see serious problem here coming up (and not only for emegency numbers, but for all local non-E.164 numbers) =20 In existing mobile systems all UE use the dial plan of the visited network. Home numbers may be accessed in some cases with CAMEL. =20 In SIP and especially in IMS the UE is always talking directly to the home network, so it always uses the home dialing plan. The only way to access local non-E.164 numbers would be a P-CSCF in the visited network (in release 8 and beyond), which may filter out certain numbers, but these would then be not available for dialing in the home dialing plan e.g if you are in the US you may not be=20 able to dial 911xxx. One may use prefixes for this, but none are defined yet. =20 IMO this problem is not resolved yet =20 Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 20 08:16:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYKwK-0001rn-Mj; Thu, 20 Sep 2007 08:15:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYKwJ-0001qM-CY for ecrit@ietf.org; Thu, 20 Sep 2007 08:15:27 -0400 Received: from demumfd002.nsn-inter.net ([217.115.75.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYKwD-00037o-Uc for ecrit@ietf.org; Thu, 20 Sep 2007 08:15:27 -0400 Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id l8KCF7GR028501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Sep 2007 14:15:08 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id l8KCF4xN019927 for ; Thu, 20 Sep 2007 14:15:07 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 14:15:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Sep 2007 14:15:06 +0200 Message-ID: <5FB585F183235B42A9E70095055136FB1E533A@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Japanese Privacy Law & Emergency Services Thread-Index: Acf7f+Ek1NlGUV9YT5mc25qcTvo/AA== From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" To: "ECRIT" X-OriginalArrivalTime: 20 Sep 2007 12:15:06.0819 (UTC) FILETIME=[E1A0F930:01C7FB7F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [Ecrit] Japanese Privacy Law & Emergency Services X-BeenThere: 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="===============0583053614==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0583053614== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FB7F.E191936C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FB7F.E191936C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all,=20 =20 at the last SDO emergency services workshop we learned that there are laws in Japan that allow an emergency caller to indicate that his identity is not transmitted to the PSAP operator. I believe that we have no discussion about this aspect in the Framework/Phone BCP document.=20 =20 Does someone know where these requirements are written down? Can someone give us a reference to the document? We would need it when we talk about this subject in the above-mentioned doc. =20 Ciao Hannes =20 ------_=_NextPart_001_01C7FB7F.E191936C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi = all,=20
 
at the = last SDO=20 emergency services workshop we learned that there are laws in Japan that = allow=20 an emergency caller to indicate that his identity is not transmitted to = the PSAP=20 operator. I believe that we have no discussion about this aspect in the=20 Framework/Phone BCP document.
 
Does = someone know=20 where these requirements are written down? Can someone give us a = reference to=20 the document? We would need it when we talk about this subject in the=20 above-mentioned doc.
 
Ciao
Hannes
 
------_=_NextPart_001_01C7FB7F.E191936C-- --===============0583053614== 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 --===============0583053614==-- From ecrit-bounces@ietf.org Thu Sep 20 11:59:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYOQ5-0003SZ-L4; Thu, 20 Sep 2007 11:58:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYOQ3-0003NE-Vm for ecrit@ietf.org; Thu, 20 Sep 2007 11:58:24 -0400 Received: from demumfd001.nsn-inter.net ([217.115.75.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYOQ3-0002c0-AI for ecrit@ietf.org; Thu, 20 Sep 2007 11:58:23 -0400 Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id l8KFwHkE017460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Sep 2007 17:58:17 +0200 Received: from demuexc023.nsn-intra.net (moody.mchh.siemens.de [10.150.128.36] (may be forged)) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id l8KFwHXh029676; Thu, 20 Sep 2007 17:58:17 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 17:58:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Sep 2007 17:58:16 +0200 Message-ID: <5FB585F183235B42A9E70095055136FB0555CA@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Implementation Related Questions Thread-Index: Acf7kzaQLb9IIWpGSDGQxTPQuwCcjA== From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" To: "ECRIT" X-OriginalArrivalTime: 20 Sep 2007 15:58:17.0214 (UTC) FILETIME=[0EED19E0:01C7FB9F] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Subject: [Ecrit] Implementation Related Questions X-BeenThere: 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="===============1646786941==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1646786941== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FB9F.0EA734A5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FB9F.0EA734A5 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all,=20 =20 at some point in time we had a separate mailing list for implementation specific questions. We had some traffic on that list but not a lot. Recently, the list got deleted as part of an OS upgrade.=20 =20 I think we could also allow implementation-specific questions on the main list as there are probably not too many questions anyway.=20 =20 Ciao Hannes =20 ------_=_NextPart_001_01C7FB9F.0EA734A5 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi = all,=20
 
at = some point in=20 time we had a separate mailing list for implementation specific = questions. We=20 had some traffic on that list but not a lot. Recently, the list got = deleted as=20 part of an OS upgrade.
 
I = think we could=20 also allow implementation-specific questions on the main list as there = are=20 probably not too many questions anyway.
 
Ciao
Hannes
 
------_=_NextPart_001_01C7FB9F.0EA734A5-- --===============1646786941== 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 --===============1646786941==-- From ecrit-bounces@ietf.org Thu Sep 20 11:59:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYORG-0004Qp-BO; Thu, 20 Sep 2007 11:59:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYORE-0004QI-Qe for ecrit@ietf.org; Thu, 20 Sep 2007 11:59:36 -0400 Received: from demumfd002.nsn-inter.net ([217.115.75.234]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYORE-0002eS-3n for ecrit@ietf.org; Thu, 20 Sep 2007 11:59:36 -0400 Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id l8KFwMks016550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Sep 2007 17:58:22 +0200 Received: from demuexc023.nsn-intra.net (moody.mchh.siemens.de [10.150.128.36] (may be forged)) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id l8KFwHXj029676; Thu, 20 Sep 2007 17:58:17 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Sep 2007 17:58:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Phonebcp comments Date: Thu, 20 Sep 2007 17:58:16 +0200 Message-ID: <5FB585F183235B42A9E70095055136FB0555CC@DEMUEXC012.nsn-intra.net> In-Reply-To: <91D87B6E-657E-4738-AD7A-FDBAEEAFB69B@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phonebcp comments Thread-Index: Acf7A6L4QH65ORSDStuoD+iJesJuxQAkK49A References: <7582BC68E4994F4ABF0BD4723975C3FA03B0F1F2@crexc41p><110201c7fb00$fe54a380$640fa8c0@cis.neustar.com> <91D87B6E-657E-4738-AD7A-FDBAEEAFB69B@cisco.com> From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" To: "ext John Schnizlein" , "Brian Rosen" X-OriginalArrivalTime: 20 Sep 2007 15:58:17.0433 (UTC) FILETIME=[0F0E8490:01C7FB9F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "Stark, Barbara" , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi John=20 when RFC 3825 returns a point (without LoRes, LaRes, AltRes) and AT =3D = 1 then this would translate to a point (2d or 3d depending on the = altitude value) in the PIDF-LO (such as described in = http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-08#section-= 5.2.1 . When RFC 3825 returns a point (without LoRes, LaRes, AltRes) and AT =3D = 2 then the encoding described in = http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-08#section-= 3.2 is used.=20 What type of PIDF-LO encoding is used when LoRes, LaRes, AltRes is = provided?=20 Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: ext John Schnizlein [mailto:jschnizl@cisco.com]=20 > Gesendet: Mittwoch, 19. September 2007 23:23 > An: Brian Rosen > Cc: 'Stark, Barbara'; 'ECRIT' > Betreff: Re: [Ecrit] Phonebcp comments >=20 > That is the subject of draft-ietf-geopriv-binary-lci-00, which =20 > expired July 1 after the (previous) GeoPriv chair let it languish =20 > after the WG adopted it as a WG item. >=20 > There is a misinterpretation about the resolution parameter in RFC =20 > 3825 that this draft was written to clarify, but the dispute of the =20 > meaning of resolution has not gone away. >=20 > John >=20 > On Sep 19, 2007, at 5:06 PM, Brian Rosen wrote: >=20 > > 3. Section 4.5 > > Converting to PIDF-LO - Isn't there an IETF reference for=20 > how to do =20 > > this for a DHCP-delivered location? > > > > If there is, I'm not aware, or have forgotten it. >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 20 12:19:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYOi6-0005Mx-8u; Thu, 20 Sep 2007 12:17:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYOi4-0005Kg-PB for ecrit@ietf.org; Thu, 20 Sep 2007 12:17:00 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYOi0-0003P2-AV for ecrit@ietf.org; Thu, 20 Sep 2007 12:16:56 -0400 Received: from [65.170.117.145] ([::ffff:65.170.117.145]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 20 Sep 2007 12:16:55 -0400 id 01588370.46F29CF7.000008C9 In-Reply-To: <91D87B6E-657E-4738-AD7A-FDBAEEAFB69B@cisco.com> References: <7582BC68E4994F4ABF0BD4723975C3FA03B0F1F2@crexc41p> <110201c7fb00$fe54a380$640fa8c0@cis.neustar.com> <91D87B6E-657E-4738-AD7A-FDBAEEAFB69B@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <642CCF3B-00AD-4595-8F35-7B345C4D08EF@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Phonebcp comments Date: Thu, 20 Sep 2007 12:16:54 -0400 To: John Schnizlein X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: "'Stark, Barbara'" , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Sep 19, 2007, at 5:23 PM, John Schnizlein wrote: > That is the subject of draft-ietf-geopriv-binary-lci-00, which > expired July 1 after the (previous) GeoPriv chair let it languish > after the WG adopted it as a WG item. This is a bit incorrect. Despite the fact that the binary-lci-00 draft was a very useful document, the working group did not adopt it. What the working group consented to adopt was a draft that updated 3825. The previous chair simply held to that wish, and did not allow the submittal of binary- lci until it was revised to be an update of 3825. Though they were asked to do so by the previous chair, the authors of binary-lci never revised the document as needed. > There is a misinterpretation about the resolution parameter in RFC > 3825 that this draft was written to clarify, but the dispute of the > meaning of resolution has not gone away. The working group did reach a consensus (though it was very rough) on this matter. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 20 12:54:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPIb-000210-BK; Thu, 20 Sep 2007 12:54:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYPIZ-0001ul-Jv for ecrit@ietf.org; Thu, 20 Sep 2007 12:54:43 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYPIZ-0004zz-3R for ecrit@ietf.org; Thu, 20 Sep 2007 12:54:43 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Sep 2007 12:54:40 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8KGsebl015796; Thu, 20 Sep 2007 12:54:40 -0400 Received: from [68.50.16.73] (che-vpn-cluster-1-186.cisco.com [10.86.240.186]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8KGsYYa018105; Thu, 20 Sep 2007 16:54:34 GMT In-Reply-To: <5FB585F183235B42A9E70095055136FB0555CC@DEMUEXC012.nsn-intra.net> References: <7582BC68E4994F4ABF0BD4723975C3FA03B0F1F2@crexc41p><110201c7fb00$fe54a380$640fa8c0@cis.neustar.com> <91D87B6E-657E-4738-AD7A-FDBAEEAFB69B@cisco.com> <5FB585F183235B42A9E70095055136FB0555CC@DEMUEXC012.nsn-intra.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: John Schnizlein Subject: Re: AW: [Ecrit] Phonebcp comments Date: Thu, 20 Sep 2007 12:54:31 -0400 To: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1672; t=1190307280; x=1191171280; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jschnizl@cisco.com; z=From:=20John=20Schnizlein=20 |Subject:=20Re=3A=20AW=3A=20[Ecrit]=20Phonebcp=20comments |Sender:=20 |To:=20=22Tschofenig, =20Hannes=20(NSN=20-=20DE/Germany=20-=20MiniMD)=22=2 0; bh=n6BxWrBqEC+0jHTo8N+ChFH0t259REtj4NNfuRUDqAI=; b=h2jqBe9j6pWZxxLd5TpBHjQEbRydHGbHPSXZawWXtrcypjshFU8ET54DuLaEltUWfFUHdO7y cMM6PGWVLu/SUdOVPj9MN5mu42eXsXl/vXGNVfqvYBmw/fOYqkiwNJ2i; Authentication-Results: rtp-dkim-1; header.From=jschnizl@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "Stark, Barbara" , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org There is no such thing as an RFC-3825 location "without LoRes, LaRes, =20= AltRes". RFC 3825 is all about a single point of location. What draft-ietf-=20 geopriv-binary-lci-00 clarifies is that the number of significant =20 digits in the decimal-string representation of a PIDF-LO depends on =20 the resolution of the binary values in an RFC-3825 location, if =20 derived from there. John On Sep 20, 2007, at 11:58 AM, Tschofenig, Hannes (NSN - DE/Germany - =20 MiniMD) wrote: > Hi John > > when RFC 3825 returns a point (without LoRes, LaRes, AltRes) and AT =20= > =3D 1 then this would translate to a point (2d or 3d depending on the =20= > altitude value) in the PIDF-LO (such as described in http://=20 > tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-=20 > profile-08#section-5.2.1 . > > When RFC 3825 returns a point (without LoRes, LaRes, AltRes) and =20 > AT =3D 2 then the encoding described in http://tools.ietf.org/html/=20 > draft-ietf-geopriv-pdif-lo-profile-08#section-3.2 is used. > > What type of PIDF-LO encoding is used when LoRes, LaRes, AltRes is =20 > provided? > > Ciao > Hannes > >> -----Urspr=FCngliche Nachricht----- >> Von: ext John Schnizlein [mailto:jschnizl@cisco.com] >> Gesendet: Mittwoch, 19. September 2007 23:23 >> >> That is the subject of draft-ietf-geopriv-binary-lci-00, which >> expired July 1 after the (previous) GeoPriv chair let it languish >> after the WG adopted it as a WG item. >> >> There is a misinterpretation about the resolution parameter in RFC >> 3825 that this draft was written to clarify, but the dispute of the >> meaning of resolution has not gone away. >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 20 15:53:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYS5R-00034j-51; Thu, 20 Sep 2007 15:53:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYS5P-00030b-Ho for ecrit@ietf.org; Thu, 20 Sep 2007 15:53:19 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYS5K-0002dx-Sk for ecrit@ietf.org; Thu, 20 Sep 2007 15:53:15 -0400 X-SEF-Processed: 5_0_0_910__2007_09_20_15_02_46 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 20 Sep 2007 15:02:46 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Sep 2007 14:53:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Ecrit] Phonebcp comments Date: Thu, 20 Sep 2007 14:53:12 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Ecrit] Phonebcp comments Thread-Index: Acf7p2CuMAq8RTsJSZyPhHZJ6xOcKwAGFpJg References: <7582BC68E4994F4ABF0BD4723975C3FA03B0F1F2@crexc41p><110201c7fb00$fe54a380$640fa8c0@cis.neustar.com><91D87B6E-657E-4738-AD7A-FDBAEEAFB69B@cisco.com><5FB585F183235B42A9E70095055136FB0555CC@DEMUEXC012.nsn-intra.net> From: "Winterbottom, James" To: "John Schnizlein" , "Tschofenig, Hannes \(NSN - DE/Germany - MiniMD\)" X-OriginalArrivalTime: 20 Sep 2007 19:53:13.0947 (UTC) FILETIME=[E13BDAB0:01C7FBBF] X-Spam-Score: 1.8 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: "Stark, Barbara" , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I agree with your first point.=0D=0A=0D=0AFor your second point however the= only known implementers of this argue otherwise. Please see the georpiv ar= chives for evidence of this.=0D=0A=0D=0ARegards=0D=0AJames=0D=0A=0D=0A> ---= --Original Message-----=0D=0A> From: John Schnizlein [mailto:jschnizl@cisco= =2Ecom]=0D=0A> Sent: Friday, 21 September 2007 2:55 AM=0D=0A> To: Tschofeni= g,Hannes (NSN - DE/Germany - MiniMD)=0D=0A> Cc: Stark, Barbara; ECRIT=0D=0A= > Subject: Re: AW: [Ecrit] Phonebcp comments=0D=0A>=20=0D=0A> There is no s= uch thing as an RFC-3825 location "without LoRes, LaRes,=0D=0A> AltRes".=0D= =0A>=20=0D=0A> RFC 3825 is all about a single point of location. What draf= t-ietf-=0D=0A> geopriv-binary-lci-00 clarifies is that the number of signif= icant=0D=0A> digits in the decimal-string representation of a PIDF-LO depen= ds on=0D=0A> the resolution of the binary values in an RFC-3825 location, i= f=0D=0A> derived from there.=0D=0A>=20=0D=0A> John=0D=0A>=20=0D=0A> On Sep = 20, 2007, at 11:58 AM, Tschofenig, Hannes (NSN - DE/Germany -=0D=0A> MiniMD= ) wrote:=0D=0A>=20=0D=0A> > Hi John=0D=0A> >=0D=0A> > when RFC 3825 returns= a point (without LoRes, LaRes, AltRes) and AT=0D=0A> > =3D 1 then this wou= ld translate to a point (2d or 3d depending on the=0D=0A> > altitude value)= in the PIDF-LO (such as described in http://=0D=0A> > tools.ietf.org/html/= draft-ietf-geopriv-pdif-lo-=0D=0A> > profile-08#section-5.2.1 .=0D=0A> >=0D= =0A> > When RFC 3825 returns a point (without LoRes, LaRes, AltRes) and=0D= =0A> > AT =3D 2 then the encoding described in http://tools.ietf.org/html/=0D= =0A> > draft-ietf-geopriv-pdif-lo-profile-08#section-3.2 is used.=0D=0A> >=0D= =0A> > What type of PIDF-LO encoding is used when LoRes, LaRes, AltRes is=0D= =0A> > provided=3F=0D=0A> >=0D=0A> > Ciao=0D=0A> > Hannes=0D=0A> >=0D=0A> >= > -----Urspr=FCngliche Nachricht-----=0D=0A> >> Von: ext John Schnizlein [m= ailto:jschnizl@cisco.com]=0D=0A> >> Gesendet: Mittwoch, 19. September 2007 = 23:23=0D=0A> >>=0D=0A> >> That is the subject of draft-ietf-geopriv-binary-= lci-00, which=0D=0A> >> expired July 1 after the (previous) GeoPriv chair l= et it languish=0D=0A> >> after the WG adopted it as a WG item.=0D=0A> >>=0D= =0A> >> There is a misinterpretation about the resolution parameter in RFC=0D= =0A> >> 3825 that this draft was written to clarify, but the dispute of the=0D= =0A> >> meaning of resolution has not gone away.=0D=0A> >>=0D=0A>=20=0D=0A>= _______________________________________________=0D=0A> Ecrit mailing list=0D= =0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0AThis message is for the designated recipient = only and may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 20 16:27:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYSao-0001nt-Bi; Thu, 20 Sep 2007 16:25:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYSam-0001b2-M0 for ecrit@ietf.org; Thu, 20 Sep 2007 16:25:44 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYSaj-0003RG-SR for ecrit@ietf.org; Thu, 20 Sep 2007 16:25:42 -0400 Received: from ([139.76.131.87]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.184991778; Thu, 20 Sep 2007 16:25:21 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 20 Sep 2007 16:25:22 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 20 Sep 2007 16:25:21 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Ecrit] Phonebcp comments Date: Thu, 20 Sep 2007 16:25:20 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA05A7FEB1@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Ecrit] Phonebcp comments thread-index: Acf7pvuijljXVo5YTgOjdlpWiI2bSwAEcfNg References: <7582BC68E4994F4ABF0BD4723975C3FA03B0F1F2@crexc41p><110201c7fb00$fe54a380$640fa8c0@cis.neustar.com> <91D87B6E-657E-4738-AD7A-FDBAEEAFB69B@cisco.com> <5FB585F183235B42A9E70095055136FB0555CC@DEMUEXC012.nsn-intra.net> From: "Stark, Barbara" To: "John Schnizlein" , "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" X-OriginalArrivalTime: 20 Sep 2007 20:25:21.0679 (UTC) FILETIME=[5E4069F0:01C7FBC4] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Let me see if I've got this translation thing right. For Civic: RFC 4776 (DHCP-Civic) and ANSI/TIA-1057 (LLDP-MED) describe within those = docs how their fields map to a PIDF-LO. = draft-ietf-geopriv-revised-civic-lo-05 has an additional paragraph = (3.5.1) for converting from DHCP when the same element is included = multiple times. I don't know enough to know whether this also applies to = LLDP-MED. I suppose it doesn't matter, since it looks like the easiest = thing to do would be to put DHCP and LLDP-MED civic locations through = the same conversion routine. For Geo: RFC 3825 (DHCP-Geo) and ANSI/TIA-1057 (LLDP-MED) have the same fields. = Which means they should be converted through the same rules. I took a = look at OGC 02-023r4 (GML 3.0), and all I can say, is thank goodness = geopriv is doing draft-ietf-geopriv-pdif-lo-profile-08, or I wouldn't = have a clue what to do to get the DHCP/LLDP-MED fields into the "right" = format. If I read that draft correctly, it looks like the procedure = would be to say "Latitude Longitude" if there is no = Altitude, or "Latitude Longitude Altitude" if there = is (and if AT is meters)? But this only works if Datum is WGS-84? And, = as John S. and Hannes have pointed out, there's no mention of what to do = with the "Res" parameters. There is a description of what to do when AT = is floor. It seems like there do need to be rules for what to do with the Res = parameters, and either a reference for how to translate other Media to = WGS-84, rules for it, or a prohibition (in phonebcp?) against it, if = PIDF-LO will only take WGS-84. If it appears from my statements that I'm totally ignorant of Geo = formats, I just want to say that "Yes, I am". But so are most of the SIP = endpoint and router developers that I deal with. And I'm asking them to = be able to code this conversion into their devices. Please, geopriv WG, = take pity on me (and them) and be explicit. I'd really like it if either = pdif-lo-profile-08 had a section that described exactly how to convert = (all fields, and all allowed values of all fields), or if there were a = separate draft that said exactly how to convert. I don't care who did = what to whom in the past. I just want to be given enough info to make = this all work. Barbara -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com]=20 Sent: Thursday, September 20, 2007 12:55 PM To: Tschofenig, Hannes (NSN - DE/Germany - MiniMD) Cc: Brian Rosen; Stark, Barbara; ECRIT Subject: Re: AW: [Ecrit] Phonebcp comments There is no such thing as an RFC-3825 location "without LoRes, LaRes, =20 AltRes". RFC 3825 is all about a single point of location. What draft-ietf-=20 geopriv-binary-lci-00 clarifies is that the number of significant =20 digits in the decimal-string representation of a PIDF-LO depends on =20 the resolution of the binary values in an RFC-3825 location, if =20 derived from there. John On Sep 20, 2007, at 11:58 AM, Tschofenig, Hannes (NSN - DE/Germany - =20 MiniMD) wrote: > Hi John > > when RFC 3825 returns a point (without LoRes, LaRes, AltRes) and AT =20 > =3D 1 then this would translate to a point (2d or 3d depending on the = > altitude value) in the PIDF-LO (such as described in http://=20 > tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-=20 > profile-08#section-5.2.1 . > > When RFC 3825 returns a point (without LoRes, LaRes, AltRes) and =20 > AT =3D 2 then the encoding described in http://tools.ietf.org/html/=20 > draft-ietf-geopriv-pdif-lo-profile-08#section-3.2 is used. > > What type of PIDF-LO encoding is used when LoRes, LaRes, AltRes is =20 > provided? > > Ciao > Hannes > >> -----Urspr=FCngliche Nachricht----- >> Von: ext John Schnizlein [mailto:jschnizl@cisco.com] >> Gesendet: Mittwoch, 19. September 2007 23:23 >> >> That is the subject of draft-ietf-geopriv-binary-lci-00, which >> expired July 1 after the (previous) GeoPriv chair let it languish >> after the WG adopted it as a WG item. >> >> There is a misinterpretation about the resolution parameter in RFC >> 3825 that this draft was written to clarify, but the dispute of the >> meaning of resolution has not gone away. >> ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA623 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 20 17:23:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYTTg-0000t0-PX; Thu, 20 Sep 2007 17:22:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYTTf-0000o1-7R for ecrit@ietf.org; Thu, 20 Sep 2007 17:22:27 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYTTe-0005La-Q6 for ecrit@ietf.org; Thu, 20 Sep 2007 17:22:26 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Sep 2007 17:22:27 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8KLMQFi020650; Thu, 20 Sep 2007 17:22:26 -0400 Received: from [68.50.16.73] (che-vpn-cluster-1-186.cisco.com [10.86.240.186]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8KLMLV4024627; Thu, 20 Sep 2007 21:22:21 GMT In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA05A7FEB1@crexc41p> References: <7582BC68E4994F4ABF0BD4723975C3FA03B0F1F2@crexc41p><110201c7fb00$fe54a380$640fa8c0@cis.neustar.com> <91D87B6E-657E-4738-AD7A-FDBAEEAFB69B@cisco.com> <5FB585F183235B42A9E70095055136FB0555CC@DEMUEXC012.nsn-intra.net> <7582BC68E4994F4ABF0BD4723975C3FA05A7FEB1@crexc41p> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3EF5E9FA-07BF-4252-A609-70DAE72E978F@cisco.com> Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: AW: [Ecrit] Phonebcp comments Date: Thu, 20 Sep 2007 17:22:06 -0400 To: "Stark, Barbara" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=498; t=1190323346; x=1191187346; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jschnizl@cisco.com; z=From:=20John=20Schnizlein=20 |Subject:=20Re=3A=20AW=3A=20[Ecrit]=20Phonebcp=20comments |Sender:=20 |To:=20=22Stark,=20Barbara=22=20; bh=J6vO7m/A/P80NbPgZVvWCg0OwxYuYFDrQSu62KVGgrM=; b=GMQREMeM5Cw8n2yWAF9GQuhXR7GxdjEKRJIZBqMfmgLbhptZ/jPE6xyZY5zvt437SVEVbreW pa1zvEVU6EY/lQuc5G43BSA0KbeWO5iTWwe72wJT+UIHTSu4IHjjR2zD; Authentication-Results: rtp-dkim-1; header.From=jschnizl@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: "Tschofenig, Hannes \(NSN - DE/Germany - MiniMD\)" , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org It seems perfectly clear to me that any more significant digits in the pidf-lo location values than there are in the binary-lci values are pseudo precision. The rule would be the same as from High School chemistry class: don't show any more significant digits in the result of a calculation than were present in the measurements. John On Sep 20, 2007, at 4:25 PM, Stark, Barbara wrote: > It seems like there do need to be rules for what to do with the Res > parameters, _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 21 04:06:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYdUu-0006wz-3g; Fri, 21 Sep 2007 04:04:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYdUt-0006tY-75 for ecrit@ietf.org; Fri, 21 Sep 2007 04:04:23 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYdUk-0003qz-8t for ecrit@ietf.org; Fri, 21 Sep 2007 04:04:14 -0400 Received: (qmail invoked by alias); 21 Sep 2007 08:04:08 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp040) with SMTP; 21 Sep 2007 10:04:08 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+QijoPNzmQqldYkLgBheG3N7GdXSUEtRb7fR//7a qhf5z2pu+luk1k Message-ID: <46F37AFA.4040301@gmx.net> Date: Fri, 21 Sep 2007 10:04:10 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: John Schnizlein Subject: Re: AW: [Ecrit] Phonebcp comments References: <7582BC68E4994F4ABF0BD4723975C3FA03B0F1F2@crexc41p><110201c7fb00$fe54a380$640fa8c0@cis.neustar.com> <91D87B6E-657E-4738-AD7A-FDBAEEAFB69B@cisco.com> <5FB585F183235B42A9E70095055136FB0555CC@DEMUEXC012.nsn-intra.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: "Stark, Barbara" , "Tschofenig, Hannes \(NSN - DE/Germany - MiniMD\)" , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi John, you are not going to tell me that the values of the LoRes, LaRes, and AltRes parameters have absolutely no impact on the PIDF-LO representation. Ciao Hannes John Schnizlein wrote: > There is no such thing as an RFC-3825 location "without LoRes, LaRes, > AltRes". > > RFC 3825 is all about a single point of location. What > draft-ietf-geopriv-binary-lci-00 clarifies is that the number of > significant digits in the decimal-string representation of a PIDF-LO > depends on the resolution of the binary values in an RFC-3825 > location, if derived from there. > > John > > On Sep 20, 2007, at 11:58 AM, Tschofenig, Hannes (NSN - DE/Germany - > MiniMD) wrote: > >> Hi John >> >> when RFC 3825 returns a point (without LoRes, LaRes, AltRes) and AT = >> 1 then this would translate to a point (2d or 3d depending on the >> altitude value) in the PIDF-LO (such as described in >> http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-08#section-5.2.1 >> . >> >> When RFC 3825 returns a point (without LoRes, LaRes, AltRes) and AT >> = 2 then the encoding described in >> http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-08#section-3.2 >> is used. >> >> What type of PIDF-LO encoding is used when LoRes, LaRes, AltRes is >> provided? >> >> Ciao >> Hannes >> >>> -----Ursprüngliche Nachricht----- >>> Von: ext John Schnizlein [mailto:jschnizl@cisco.com] >>> Gesendet: Mittwoch, 19. September 2007 23:23 >>> >>> That is the subject of draft-ietf-geopriv-binary-lci-00, which >>> expired July 1 after the (previous) GeoPriv chair let it languish >>> after the WG adopted it as a WG item. >>> >>> There is a misinterpretation about the resolution parameter in RFC >>> 3825 that this draft was written to clarify, but the dispute of the >>> meaning of resolution has not gone away. >>> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 21 09:04:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYiAW-0003ZP-SL; Fri, 21 Sep 2007 09:03:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYiAU-0003Wj-Gl for ecrit@ietf.org; Fri, 21 Sep 2007 09:03:38 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYiAO-00078M-CZ for ecrit@ietf.org; Fri, 21 Sep 2007 09:03:38 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Sep 2007 09:03:17 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8LD3HN3032734; Fri, 21 Sep 2007 09:03:17 -0400 Received: from [68.50.16.73] (che-vpn-cluster-1-186.cisco.com [10.86.240.186]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8LD3BYa027788; Fri, 21 Sep 2007 13:03:11 GMT In-Reply-To: <46F37AFA.4040301@gmx.net> References: <7582BC68E4994F4ABF0BD4723975C3FA03B0F1F2@crexc41p><110201c7fb00$fe54a380$640fa8c0@cis.neustar.com> <91D87B6E-657E-4738-AD7A-FDBAEEAFB69B@cisco.com> <5FB585F183235B42A9E70095055136FB0555CC@DEMUEXC012.nsn-intra.net> <46F37AFA.4040301@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <8DDBF6AC-A7C3-4BC9-B1C9-140C1E509BA7@cisco.com> Content-Transfer-Encoding: quoted-printable From: John Schnizlein Subject: Re: AW: [Ecrit] Phonebcp comments Date: Fri, 21 Sep 2007 09:03:05 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2559; t=1190379797; x=1191243797; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jschnizl@cisco.com; z=From:=20John=20Schnizlein=20 |Subject:=20Re=3A=20AW=3A=20[Ecrit]=20Phonebcp=20comments |Sender:=20 |To:=20Hannes=20Tschofenig=20; bh=FhOlhTwpD37yps1kQcs8E0yh/K7zNdNXhuUSyrL8VHM=; b=Bk1+pvrh98SrTCJpLz3NOZacxUTvb9qYG/BWdm9UHeJz05nB0Y8SXa58qFBhlEqJWaut3dVU im7jaee5npT6eOC8+RWZft6PKhpuGmeOtjVRHy340xrxcBSBYOfxMWBL; Authentication-Results: rtp-dkim-1; header.From=jschnizl@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: "Stark, Barbara" , "Tschofenig, Hannes \(NSN - DE/Germany - MiniMD\)" , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes, Not only did I not say that "the values of the LoRes, LaRes, and =20 AltRes parameters have absolutely no impact on the PIDF-LO =20 representation", but I said precisely what impact they do have: they =20 determine the number of significant digits that should be included in =20= the corresponding location point values. John On Sep 21, 2007, at 4:04 AM, Hannes Tschofenig wrote: > Hi John, > > you are not going to tell me that the values of the LoRes, LaRes, =20 > and AltRes parameters have absolutely no impact on the PIDF-LO =20 > representation. > > Ciao > Hannes > > John Schnizlein wrote: >> There is no such thing as an RFC-3825 location "without LoRes, =20 >> LaRes, AltRes". >> >> RFC 3825 is all about a single point of location. What draft-ietf-=20= >> geopriv-binary-lci-00 clarifies is that the number of significant =20 >> digits in the decimal-string representation of a PIDF-LO depends =20 >> on the resolution of the binary values in an RFC-3825 location, if =20= >> derived from there. >> >> John >> >> On Sep 20, 2007, at 11:58 AM, Tschofenig, Hannes (NSN - DE/Germany =20= >> - MiniMD) wrote: >> >>> Hi John >>> >>> when RFC 3825 returns a point (without LoRes, LaRes, AltRes) and =20 >>> AT =3D 1 then this would translate to a point (2d or 3d depending =20= >>> on the altitude value) in the PIDF-LO (such as described in =20 >>> http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-=20 >>> profile-08#section-5.2.1 . >>> >>> When RFC 3825 returns a point (without LoRes, LaRes, AltRes) and =20= >>> AT =3D 2 then the encoding described in http://tools.ietf.org/html/=20= >>> draft-ietf-geopriv-pdif-lo-profile-08#section-3.2 is used. >>> >>> What type of PIDF-LO encoding is used when LoRes, LaRes, AltRes =20 >>> is provided? >>> >>> Ciao >>> Hannes >>> >>>> -----Urspr=FCngliche Nachricht----- >>>> Von: ext John Schnizlein [mailto:jschnizl@cisco.com] >>>> Gesendet: Mittwoch, 19. September 2007 23:23 >>>> >>>> That is the subject of draft-ietf-geopriv-binary-lci-00, which >>>> expired July 1 after the (previous) GeoPriv chair let it languish >>>> after the WG adopted it as a WG item. >>>> >>>> There is a misinterpretation about the resolution parameter in RFC >>>> 3825 that this draft was written to clarify, but the dispute of the >>>> meaning of resolution has not gone away. >>>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 21 10:15:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYjGu-00089K-U7; Fri, 21 Sep 2007 10:14:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYjGt-00088T-WA for ecrit@ietf.org; Fri, 21 Sep 2007 10:14:20 -0400 Received: from demumfd002.nsn-inter.net ([217.115.75.234]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYjGt-0004ts-48 for ecrit@ietf.org; Fri, 21 Sep 2007 10:14:19 -0400 Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id l8LEEE8K017385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Sep 2007 16:14:14 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id l8LEEDKt000729; Fri, 21 Sep 2007 16:14:13 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Sep 2007 16:14:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: AW: [Ecrit] Phonebcp comments Date: Fri, 21 Sep 2007 16:14:12 +0200 Message-ID: <5FB585F183235B42A9E70095055136FB1E5458@DEMUEXC012.nsn-intra.net> In-Reply-To: <8DDBF6AC-A7C3-4BC9-B1C9-140C1E509BA7@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Ecrit] Phonebcp comments Thread-Index: Acf8T8n1/px9VWd3ShGqICBzaqEcbAAACZLg References: <7582BC68E4994F4ABF0BD4723975C3FA03B0F1F2@crexc41p><110201c7fb00$fe54a380$640fa8c0@cis.neustar.com> <91D87B6E-657E-4738-AD7A-FDBAEEAFB69B@cisco.com> <5FB585F183235B42A9E70095055136FB0555CC@DEMUEXC012.nsn-intra.net> <46F37AFA.4040301@gmx.net> <8DDBF6AC-A7C3-4BC9-B1C9-140C1E509BA7@cisco.com> From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" To: "ext John Schnizlein" , "Hannes Tschofenig" X-OriginalArrivalTime: 21 Sep 2007 14:14:13.0770 (UTC) FILETIME=[AFF4E6A0:01C7FC59] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: "Stark, Barbara" , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi John,=20 > Hannes, >=20 > Not only did I not say that "the values of the LoRes, LaRes, and =20 > AltRes parameters have absolutely no impact on the PIDF-LO =20 > representation", but I said precisely what impact they do have: they =20 > determine the number of significant digits that should be=20 > included in =20 > the corresponding location point values. But this information about the LoRes, LaRes and AltRes would be lost in = the translation since a PIDF-LO does not carry these parameters. In other words, given the example below can you tell me what the LoRes, = and LaRes values are? What does the indicated point mean? -34.407 150.883 2007-06-22T20:57:29Z Do I totally miss something here? Ciao Hannes > John >=20 > On Sep 21, 2007, at 4:04 AM, Hannes Tschofenig wrote: >=20 > > Hi John, > > > > you are not going to tell me that the values of the LoRes, LaRes, =20 > > and AltRes parameters have absolutely no impact on the PIDF-LO =20 > > representation. > > > > Ciao > > Hannes > > > > John Schnizlein wrote: > >> There is no such thing as an RFC-3825 location "without LoRes, =20 > >> LaRes, AltRes". > >> > >> RFC 3825 is all about a single point of location. What=20 > draft-ietf-=20 > >> geopriv-binary-lci-00 clarifies is that the number of significant =20 > >> digits in the decimal-string representation of a PIDF-LO depends =20 > >> on the resolution of the binary values in an RFC-3825=20 > location, if =20 > >> derived from there. > >> > >> John > >> > >> On Sep 20, 2007, at 11:58 AM, Tschofenig, Hannes (NSN -=20 > DE/Germany =20 > >> - MiniMD) wrote: > >> > >>> Hi John > >>> > >>> when RFC 3825 returns a point (without LoRes, LaRes, AltRes) and =20 > >>> AT =3D 1 then this would translate to a point (2d or 3d depending = > >>> on the altitude value) in the PIDF-LO (such as described in =20 > >>> http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-=20 > >>> profile-08#section-5.2.1 . > >>> > >>> When RFC 3825 returns a point (without LoRes, LaRes,=20 > AltRes) and =20 > >>> AT =3D 2 then the encoding described in = http://tools.ietf.org/html/=20 > >>> draft-ietf-geopriv-pdif-lo-profile-08#section-3.2 is used. > >>> > >>> What type of PIDF-LO encoding is used when LoRes, LaRes, AltRes =20 > >>> is provided? > >>> > >>> Ciao > >>> Hannes > >>> > >>>> -----Urspr=FCngliche Nachricht----- > >>>> Von: ext John Schnizlein [mailto:jschnizl@cisco.com] > >>>> Gesendet: Mittwoch, 19. September 2007 23:23 > >>>> > >>>> That is the subject of draft-ietf-geopriv-binary-lci-00, which > >>>> expired July 1 after the (previous) GeoPriv chair let it languish > >>>> after the WG adopted it as a WG item. > >>>> > >>>> There is a misinterpretation about the resolution=20 > parameter in RFC > >>>> 3825 that this draft was written to clarify, but the=20 > dispute of the > >>>> meaning of resolution has not gone away. > >>>> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 21 10:22:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYjOn-0001sZ-Cx; Fri, 21 Sep 2007 10:22:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYjOm-0001qr-4N for ecrit@ietf.org; Fri, 21 Sep 2007 10:22:28 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IYjOl-00057T-B0 for ecrit@ietf.org; Fri, 21 Sep 2007 10:22:27 -0400 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 l8LEMHpI023049; Fri, 21 Sep 2007 09:22:19 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Sep 2007 09:22:16 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Sep 2007 16:22:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Date: Fri, 21 Sep 2007 16:22:11 +0200 Message-ID: <5D1A7985295922448D5550C94DE29180016F66DC@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Thread-Index: AcfvhjQU/La9ZccESha/Hn4q0K+ovwM0/GGw References: <46CAE441.8080504@gmx.net> <46D1C942.7010501@gmx.net> <46D264F9.6080101@softarmor.com> <46DC67A0.60809@gmx.net> <46DD06A4.2080000@gmx.net> <5FB585F183235B42A9E70095055136FB0555C4@DEMUEXC012.nsn-intra.net> <5D1A7985295922448D5550C94DE2918001636C13@DEEXC1U01.de.lucent.com> <30940889-193E-47AF-B6D4-44856CE09B96@cs.columbia.edu> From: "DRAGE, Keith \(Keith\)" To: "James M. Polk" , "Henning Schulzrinne" X-OriginalArrivalTime: 21 Sep 2007 14:22:13.0391 (UTC) FILETIME=[CDD541F0:01C7FC5A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think this is a case of horses for courses. People have said we should not overload headers, and we seem to have two separate functions - the routing function and the processing treatment function where emergency calls need to be recognised for special handling. Where emergency calls in the network require special processing treatment, then I also consider the RPH header is appropriate. Note that this is not a case of treating emergency calls first, more a matter of making sure that they are not precluded by other heavy traffic. I (now) understand the need to retain the service URN once a candidate PSAP address has been identified. This is a routeing function. I think we need two separate solutions covering each problem. Each solution is inappropriate to cover the other problem. Regards Keith > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > Sent: Wednesday, September 05, 2007 7:29 AM > To: Henning Schulzrinne; DRAGE, Keith (Keith) > Cc: ECRIT > Subject: Re: [Ecrit] Re: [Sip]=20 > draft-rosenberg-sip-ua-loose-route-01.txt >=20 > I believe I agree that the RPH shouldn't be relied upon as=20 > the (or the only) enduring indication a call is an emergency call. >=20 > I think the sos RPH namespace should be used within emergency=20 > networks for resource treatment.=20 > draft-polk-ecrit-local-emergency-rph-namespace-01.txt talks=20 > about this. >=20 > I also think it should be up to the arrangements between the=20 > emergency network to and a service provider, say one with an=20 > IMS architecture, to establish trust to a particular server,=20 > perhaps each E-CSCF within that provider's network, to=20 > appropriate PSAPs. In this scenario, which should be=20 > possible, but not necessarily pushed at this time, the *-CSCF=20 > can add the sos RPH to an emergency SIP request. The SP=20 > would be taking on the charge of making sure the RPH wouldn't=20 > cause harm within their network to the emergency services network. >=20 > At 02:08 PM 9/4/2007, Henning Schulzrinne wrote: > >As for Brian, my preferred solution is the loose-route proposal. > > > >If we want an explicit marking, I think an explicit header would be=20 > >clearest, as in > > > >Service: urn:service:sos.fire > > > >(I don't want this to be conflated with the service=20 > discussion in SIP;=20 > >this has nothing to do with what's been discussed there. I=20 > don't care=20 > >about the header label.) > > > >Resource priority is, in my opinion, not appropriate for marking the=20 > >service requested since such calls may not actually get resource=20 > >priority and since it is unlikely that fire calls will get a=20 > different=20 > >priority from police calls. Conversely, the RPH header is dangerous=20 > >outside carefully controlled environments, since it can be a=20 > DOS tool.=20 > >In particular, RPH requires strong client authentication, which is=20 > >generally not available in emergency calls. Within the > >(trusted) ESN, this isn't a major problem, but letting end users or=20 > >VSPs set that header field is asking for trouble unless=20 > other entities=20 > >can verify that the call is indeed an emergency call. If they can do=20 > >that, then you don't need the header. > > > >Overloading headers just because they are available doesn't=20 > strike me=20 > >as architecturally appropriate. > > > >Henning > > > >On Sep 4, 2007, at 9:06 AM, DRAGE, Keith ((Keith)) wrote: > > > >>(Removing parties from the original list distribution) > >> > >>The situation in 3GPP is that we have so far failed to agree any=20 > >>marking or other carriage of other information (with a significant=20 > >>number of the objections coming from the organisation=20 > Christer works=20 > >>for), not that we have agreed we don't want one. > >> > >>I believe the appropriate way forward on marking for=20 > special handling=20 > >>is actually the Resource-Priority header solution identified by > >> > >>http://www.ietf.org/internet-drafts/draft-polk-ecrit-local- > >>emergency-rph-namespace-01.txt > >> > >>In terms of special handling, this makes a lot of sense for=20 > those SIP=20 > >>entities that already have to implement RFC 4412 for other=20 > regulatory=20 > >>reasons. > >> > >>As already indicated, the 3GPP E-CSCF (the emergency routeing > >>proxy) changes the Request-URI to the PSAP URI, and the original=20 > >>Reuqest-URI is lost. Once we have reached the E-CSCF, is=20 > the original=20 > >>Request-URI (the service URN) still important for any issue=20 > apart from=20 > >>special handling? > >> > >>Regards > >> > >>Keith >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 21 10:35:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYjaJ-00046B-Ck; Fri, 21 Sep 2007 10:34:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYjaI-0003kr-CC for ecrit@ietf.org; Fri, 21 Sep 2007 10:34:22 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IYja6-0002WN-LA for ecrit@ietf.org; Fri, 21 Sep 2007 10:34:12 -0400 Received: (qmail invoked by alias); 21 Sep 2007 14:34:03 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp020) with SMTP; 21 Sep 2007 16:34:03 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19EnUFoNopEDahR8T0tsP1FQIGZjtctxoD0f+V2Dr vYtw0Su9+hLmOI Message-ID: <46F3D65A.3000108@gmx.net> Date: Fri, 21 Sep 2007 16:34:02 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "DRAGE, Keith \(Keith\)" Subject: Re: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt References: <46CAE441.8080504@gmx.net> <46D1C942.7010501@gmx.net> <46D264F9.6080101@softarmor.com> <46DC67A0.60809@gmx.net> <46DD06A4.2080000@gmx.net> <5FB585F183235B42A9E70095055136FB0555C4@DEMUEXC012.nsn-intra.net> <5D1A7985295922448D5550C94DE2918001636C13@DEEXC1U01.de.lucent.com> <30940889-193E-47AF-B6D4-44856CE09B96@cs.columbia.edu> <5D1A7985295922448D5550C94DE29180016F66DC@DEEXC1U01.de.lucent.com> In-Reply-To: <5D1A7985295922448D5550C94DE29180016F66DC@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: 0cff8c3ec906d056784362c06f5f88c1 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Keith, I think in ECRIT we essentially came to the conclusion that we want to use the procedure described in http://www1.ietf.org/mail-archive/web/ecrit/current/msg04297.html I believe Brian has added the description already to the most recently submitted Phone BCP draft, see http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-02.txt For dealing with emergency call marking within a PSAP operator network the RPH header may be fine. I was asked by James whether draft-polk-ecrit-local-emergency-rph-namespace-01.txt can become a working group item of ECRIT and after interacting with our ADs they suggested to postpone such a question to the group after we finished our current items. That's fine with me as well given that our progress Ciao Hannes DRAGE, Keith (Keith) wrote: > I think this is a case of horses for courses. People have said we should > not overload headers, and we seem to have two separate functions - the > routing function and the processing treatment function where emergency > calls need to be recognised for special handling. > > Where emergency calls in the network require special processing > treatment, then I also consider the RPH header is appropriate. > Note that > this is not a case of treating emergency calls first, more a matter of > making sure that they are not precluded by other heavy traffic. > > I (now) understand the need to retain the service URN once a candidate > PSAP address has been identified. This is a routeing function. > > I think we need two separate solutions covering each problem. Each > solution is inappropriate to cover the other problem. > > Regards > > Keith > > >> -----Original Message----- >> From: James M. Polk [mailto:jmpolk@cisco.com] >> Sent: Wednesday, September 05, 2007 7:29 AM >> To: Henning Schulzrinne; DRAGE, Keith (Keith) >> Cc: ECRIT >> Subject: Re: [Ecrit] Re: [Sip] >> draft-rosenberg-sip-ua-loose-route-01.txt >> >> I believe I agree that the RPH shouldn't be relied upon as >> the (or the only) enduring indication a call is an emergency call. >> >> I think the sos RPH namespace should be used within emergency >> networks for resource treatment. >> draft-polk-ecrit-local-emergency-rph-namespace-01.txt talks >> about this. >> >> I also think it should be up to the arrangements between the >> emergency network to and a service provider, say one with an >> IMS architecture, to establish trust to a particular server, >> perhaps each E-CSCF within that provider's network, to >> appropriate PSAPs. In this scenario, which should be >> possible, but not necessarily pushed at this time, the *-CSCF >> can add the sos RPH to an emergency SIP request. The SP >> would be taking on the charge of making sure the RPH wouldn't >> cause harm within their network to the emergency services network. >> >> At 02:08 PM 9/4/2007, Henning Schulzrinne wrote: >> >>> As for Brian, my preferred solution is the loose-route proposal. >>> >>> If we want an explicit marking, I think an explicit header would be >>> clearest, as in >>> >>> Service: urn:service:sos.fire >>> >>> (I don't want this to be conflated with the service >>> >> discussion in SIP; >> >>> this has nothing to do with what's been discussed there. I >>> >> don't care >> >>> about the header label.) >>> >>> Resource priority is, in my opinion, not appropriate for marking the >>> service requested since such calls may not actually get resource >>> priority and since it is unlikely that fire calls will get a >>> >> different >> >>> priority from police calls. Conversely, the RPH header is dangerous >>> outside carefully controlled environments, since it can be a >>> >> DOS tool. >> >>> In particular, RPH requires strong client authentication, which is >>> generally not available in emergency calls. Within the >>> (trusted) ESN, this isn't a major problem, but letting end users or >>> VSPs set that header field is asking for trouble unless >>> >> other entities >> >>> can verify that the call is indeed an emergency call. If they can do >>> that, then you don't need the header. >>> >>> Overloading headers just because they are available doesn't >>> >> strike me >> >>> as architecturally appropriate. >>> >>> Henning >>> >>> On Sep 4, 2007, at 9:06 AM, DRAGE, Keith ((Keith)) wrote: >>> >>> >>>> (Removing parties from the original list distribution) >>>> >>>> The situation in 3GPP is that we have so far failed to agree any >>>> marking or other carriage of other information (with a significant >>>> number of the objections coming from the organisation >>>> >> Christer works >> >>>> for), not that we have agreed we don't want one. >>>> >>>> I believe the appropriate way forward on marking for >>>> >> special handling >> >>>> is actually the Resource-Priority header solution identified by >>>> >>>> http://www.ietf.org/internet-drafts/draft-polk-ecrit-local- >>>> emergency-rph-namespace-01.txt >>>> >>>> In terms of special handling, this makes a lot of sense for >>>> >> those SIP >> >>>> entities that already have to implement RFC 4412 for other >>>> >> regulatory >> >>>> reasons. >>>> >>>> As already indicated, the 3GPP E-CSCF (the emergency routeing >>>> proxy) changes the Request-URI to the PSAP URI, and the original >>>> Reuqest-URI is lost. Once we have reached the E-CSCF, is >>>> >> the original >> >>>> Request-URI (the service URN) still important for any issue >>>> >> apart from >> >>>> special handling? >>>> >>>> Regards >>>> >>>> Keith >>>> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 21 10:37:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYjcy-0001gi-UQ; Fri, 21 Sep 2007 10:37:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYjct-0001XC-Jd for ecrit@ietf.org; Fri, 21 Sep 2007 10:37:03 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYjcn-0002b5-Bi for ecrit@ietf.org; Fri, 21 Sep 2007 10:37:03 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IYjcO-00029l-BG; Fri, 21 Sep 2007 09:36:32 -0500 From: "Brian Rosen" To: "'DRAGE, Keith \(Keith\)'" , "'James M. Polk'" , "'Henning Schulzrinne'" References: <46CAE441.8080504@gmx.net> <46D1C942.7010501@gmx.net><46D264F9.6080101@softarmor.com> <46DC67A0.60809@gmx.net><46DD06A4.2080000@gmx.net><5FB585F183235B42A9E70095055136FB0555C4@DEMUEXC012.nsn-intra.net><5D1A7985295922448D5550C94DE2918001636C13@DEEXC1U01.de.lucent.com><30940889-193E-47AF-B6D4-44856CE09B96@cs.columbia.edu> <5D1A7985295922448D5550C94DE29180016F66DC@DEEXC1U01.de.lucent.com> Subject: RE: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt Date: Fri, 21 Sep 2007 10:36:38 -0400 Message-ID: <146201c7fc5c$d30e77c0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfvhjQU/La9ZccESha/Hn4q0K+ovwM0/GGwAABlI1A= In-Reply-To: <5D1A7985295922448D5550C94DE29180016F66DC@DEEXC1U01.de.lucent.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Keith I am a little worried about policing RPH. If a proxy puts the RPH on, and it stays in one domain until it's given to the PSAP domain (the ESRP in most cases), then it might work. However, if the endpoint asserts it, then we really have a problem with fraud, especially if you take it at face value and say that you have a priority on resources in the network. I'm not really thinking about the monetary value, but the ability to gain priority just by claiming to be an emergency call. It did occur to me that the solution offered by Richard Barnes for validation of a PSAP URI in the presence of location hiding would work here, but I suspect that the damage would be done by the time it was discovered (which is at the exit point from the origination domain). The other ideas we had wouldn't work at all. Brian > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Friday, September 21, 2007 10:22 AM > To: James M. Polk; Henning Schulzrinne > Cc: ECRIT > Subject: RE: [Ecrit] Re: [Sip] draft-rosenberg-sip-ua-loose-route-01.txt > > I think this is a case of horses for courses. People have said we should > not overload headers, and we seem to have two separate functions - the > routing function and the processing treatment function where emergency > calls need to be recognised for special handling. > > Where emergency calls in the network require special processing > treatment, then I also consider the RPH header is appropriate. Note that > this is not a case of treating emergency calls first, more a matter of > making sure that they are not precluded by other heavy traffic. > > I (now) understand the need to retain the service URN once a candidate > PSAP address has been identified. This is a routeing function. > > I think we need two separate solutions covering each problem. Each > solution is inappropriate to cover the other problem. > > Regards > > Keith > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Wednesday, September 05, 2007 7:29 AM > > To: Henning Schulzrinne; DRAGE, Keith (Keith) > > Cc: ECRIT > > Subject: Re: [Ecrit] Re: [Sip] > > draft-rosenberg-sip-ua-loose-route-01.txt > > > > I believe I agree that the RPH shouldn't be relied upon as > > the (or the only) enduring indication a call is an emergency call. > > > > I think the sos RPH namespace should be used within emergency > > networks for resource treatment. > > draft-polk-ecrit-local-emergency-rph-namespace-01.txt talks > > about this. > > > > I also think it should be up to the arrangements between the > > emergency network to and a service provider, say one with an > > IMS architecture, to establish trust to a particular server, > > perhaps each E-CSCF within that provider's network, to > > appropriate PSAPs. In this scenario, which should be > > possible, but not necessarily pushed at this time, the *-CSCF > > can add the sos RPH to an emergency SIP request. The SP > > would be taking on the charge of making sure the RPH wouldn't > > cause harm within their network to the emergency services network. > > > > At 02:08 PM 9/4/2007, Henning Schulzrinne wrote: > > >As for Brian, my preferred solution is the loose-route proposal. > > > > > >If we want an explicit marking, I think an explicit header would be > > >clearest, as in > > > > > >Service: urn:service:sos.fire > > > > > >(I don't want this to be conflated with the service > > discussion in SIP; > > >this has nothing to do with what's been discussed there. I > > don't care > > >about the header label.) > > > > > >Resource priority is, in my opinion, not appropriate for marking the > > >service requested since such calls may not actually get resource > > >priority and since it is unlikely that fire calls will get a > > different > > >priority from police calls. Conversely, the RPH header is dangerous > > >outside carefully controlled environments, since it can be a > > DOS tool. > > >In particular, RPH requires strong client authentication, which is > > >generally not available in emergency calls. Within the > > >(trusted) ESN, this isn't a major problem, but letting end users or > > >VSPs set that header field is asking for trouble unless > > other entities > > >can verify that the call is indeed an emergency call. If they can do > > >that, then you don't need the header. > > > > > >Overloading headers just because they are available doesn't > > strike me > > >as architecturally appropriate. > > > > > >Henning > > > > > >On Sep 4, 2007, at 9:06 AM, DRAGE, Keith ((Keith)) wrote: > > > > > >>(Removing parties from the original list distribution) > > >> > > >>The situation in 3GPP is that we have so far failed to agree any > > >>marking or other carriage of other information (with a significant > > >>number of the objections coming from the organisation > > Christer works > > >>for), not that we have agreed we don't want one. > > >> > > >>I believe the appropriate way forward on marking for > > special handling > > >>is actually the Resource-Priority header solution identified by > > >> > > >>http://www.ietf.org/internet-drafts/draft-polk-ecrit-local- > > >>emergency-rph-namespace-01.txt > > >> > > >>In terms of special handling, this makes a lot of sense for > > those SIP > > >>entities that already have to implement RFC 4412 for other > > regulatory > > >>reasons. > > >> > > >>As already indicated, the 3GPP E-CSCF (the emergency routeing > > >>proxy) changes the Request-URI to the PSAP URI, and the original > > >>Reuqest-URI is lost. Once we have reached the E-CSCF, is > > the original > > >>Request-URI (the service URN) still important for any issue > > apart from > > >>special handling? > > >> > > >>Regards > > >> > > >>Keith > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 21 11:38:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYkZb-0002KE-Mt; Fri, 21 Sep 2007 11:37:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYkZa-0002E0-Pu for ecrit@ietf.org; Fri, 21 Sep 2007 11:37:42 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYkZL-00044v-Rc for ecrit@ietf.org; Fri, 21 Sep 2007 11:37:33 -0400 Received: from ([139.76.131.31]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.185040414; Fri, 21 Sep 2007 11:36:52 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 21 Sep 2007 11:36:52 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 21 Sep 2007 11:36:52 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Ecrit] Phonebcp comments Date: Fri, 21 Sep 2007 11:36:50 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA05C3FFB2@crexc41p> In-Reply-To: <3EF5E9FA-07BF-4252-A609-70DAE72E978F@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Ecrit] Phonebcp comments thread-index: Acf7zHUL9yBuhs2YTH6p7WGmoc6f0wAl1EgQ References: <7582BC68E4994F4ABF0BD4723975C3FA03B0F1F2@crexc41p><110201c7fb00$fe54a380$640fa8c0@cis.neustar.com> <91D87B6E-657E-4738-AD7A-FDBAEEAFB69B@cisco.com> <5FB585F183235B42A9E70095055136FB0555CC@DEMUEXC012.nsn-intra.net> <7582BC68E4994F4ABF0BD4723975C3FA05A7FEB1@crexc41p> <3EF5E9FA-07BF-4252-A609-70DAE72E978F@cisco.com> From: "Stark, Barbara" To: "John Schnizlein" X-OriginalArrivalTime: 21 Sep 2007 15:36:52.0096 (UTC) FILETIME=[3B596800:01C7FC65] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: "Tschofenig, Hannes \(NSN - DE/Germany - MiniMD\)" , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org John, Thanks. I went back and really read through RFC 3825. I see that you're quite right in that it explains very clearly in the Appendix how to apply the Res parameters to Latitude, Longitude, and Altitude. I think that just left my question about the Datum parameter. Should phonebcp restrict this to WGS 84, or should there be a recommended way to express Datum in a PIDF-LO? Are there other conversion issues that need to be addressed? =20 Barbara -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com]=20 Sent: Thursday, September 20, 2007 5:22 PM To: Stark, Barbara Cc: Tschofenig, Hannes (NSN - DE/Germany - MiniMD); Brian Rosen; ECRIT Subject: Re: AW: [Ecrit] Phonebcp comments It seems perfectly clear to me that any more significant digits in =20 the pidf-lo location values than there are in the binary-lci values =20 are pseudo precision. The rule would be the same as from High School chemistry class: don't =20 show any more significant digits in the result of a calculation than =20 were present in the measurements. John On Sep 20, 2007, at 4:25 PM, Stark, Barbara wrote: > It seems like there do need to be rules for what to do with the Res =20 > parameters, ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA625 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 21 12:05:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYl0b-0007ut-23; Fri, 21 Sep 2007 12:05:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYl0a-0007oj-5Q for ecrit@ietf.org; Fri, 21 Sep 2007 12:05:36 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYl0Y-0005KT-TZ for ecrit@ietf.org; Fri, 21 Sep 2007 12:05:36 -0400 X-IronPort-AV: E=Sophos;i="4.20,284,1186383600"; d="scan'208";a="400922828" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 21 Sep 2007 09:05:34 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8LG5YTc010150; Fri, 21 Sep 2007 09:05:34 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8LG5Tj3028496; Fri, 21 Sep 2007 16:05:33 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Sep 2007 12:05:23 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Sep 2007 12:05:22 -0400 From: "Marc Linsner" To: "'Hannes Tschofenig'" Subject: RE: AW: [Ecrit] Phonebcp comments Date: Fri, 21 Sep 2007 12:05:22 -0400 Message-ID: <006f01c7fc69$374f54a0$220d0d0a@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.3138 In-Reply-To: <5FB585F183235B42A9E70095055136FB1E5458@DEMUEXC012.nsn-intra.net> thread-index: Acf8T8n1/px9VWd3ShGqICBzaqEcbAAACZLgAAK0cnA= X-OriginalArrivalTime: 21 Sep 2007 16:05:22.0976 (UTC) FILETIME=[371CFA00:01C7FC69] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1346; t=1190390734; x=1191254734; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20AW=3A=20[Ecrit]=20Phonebcp=20comments |Sender:=20; bh=IR4dstgUkGfV33eNT57CrbFlCEa9UQjGHPfLUZujKwo=; b=qjAy3DYZB8oqC4N3HEjdoIyJqu3mKJaViH8yWZoEPAOMTeomUWs9kQzxoHkxPY2BwdGaxjPk k8wWaLg3YDNJohkgpj2Kc6QTPlLP6rczCeBDkmFR4VwCuXhWHDNW2B2A7c5Q3M4F4thVnquP3s ttakbKUvYrWNX/4e1DOwWRfnc=; Authentication-Results: sj-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes, > In other words, given the example below can you tell me what > the LoRes, and LaRes values are? What does the indicated point mean? > > > xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" > xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" > xmlns:gs="http://www.opengis.net/pidflo/1.0" > xmlns:gml="http://www.opengis.net/gml" > entity="pres:point2d@example.com"> > > > > > xmlns:gml="http://www.opengis.net/gml"> > -34.407 150.883 > > > > > > 2007-06-22T20:57:29Z > > > > > Do I totally miss something here? Significant digits! LoRes and LaRes allow you to determine your values are -34.407 150.883 and not -34.40700000 150.88300000. LoRes and LaRes are determined during the conversion to binary and used in the conversion from binary. That's it. No magic. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 21 12:37:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYlV6-0002EM-7s; Fri, 21 Sep 2007 12:37:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYlV4-0002E0-Gr for ecrit@ietf.org; Fri, 21 Sep 2007 12:37:06 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYlUy-0006l3-CH for ecrit@ietf.org; Fri, 21 Sep 2007 12:37:06 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Sep 2007 12:36:59 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8LGatOO017667; Fri, 21 Sep 2007 12:36:55 -0400 Received: from [68.50.16.73] (che-vpn-cluster-1-186.cisco.com [10.86.240.186]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8LGamYa019719; Fri, 21 Sep 2007 16:36:49 GMT In-Reply-To: <5FB585F183235B42A9E70095055136FB1E5458@DEMUEXC012.nsn-intra.net> References: <7582BC68E4994F4ABF0BD4723975C3FA03B0F1F2@crexc41p><110201c7fb00$fe54a380$640fa8c0@cis.neustar.com> <91D87B6E-657E-4738-AD7A-FDBAEEAFB69B@cisco.com> <5FB585F183235B42A9E70095055136FB0555CC@DEMUEXC012.nsn-intra.net> <46F37AFA.4040301@gmx.net> <8DDBF6AC-A7C3-4BC9-B1C9-140C1E509BA7@cisco.com> <5FB585F183235B42A9E70095055136FB1E5458@DEMUEXC012.nsn-intra.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: AW: AW: [Ecrit] Phonebcp comments Date: Fri, 21 Sep 2007 12:36:46 -0400 To: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2503; t=1190392615; x=1191256615; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jschnizl@cisco.com; z=From:=20John=20Schnizlein=20 |Subject:=20Re=3A=20AW=3A=20AW=3A=20[Ecrit]=20Phonebcp=20comments |Sender:=20 |To:=20=22Tschofenig, =20Hannes=20(NSN=20-=20DE/Germany=20-=20MiniMD)=22=2 0; bh=qTdG3AUWwsnTSWfVecgHTv241JsyNj5CQiJtI5pX95w=; b=QbDr106hM4ttpSqGjG9wEYO4f+33BiJga6blctHKEbYLXvzecaRYrrBy6XUzWj2LsK6+CK/n SbfzPamuKw7aJOGZnKcbJkKYMuDYK7GRin6Dy6ujeAhKBvodKdBg+s69; Authentication-Results: rtp-dkim-1; header.From=jschnizl@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: "Stark, Barbara" , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Sep 21, 2007, at 10:14 AM, Tschofenig, Hannes (NSN - DE/Germany - MiniMD) wrote: > But this information about the LoRes, LaRes and AltRes would be > lost in the translation since a PIDF-LO does not carry these > parameters. The (variable length) decimal string of Latitude and Longitude does carry resolution implicitly in the length of the string, which is its representation of significant digits. Because it is fixed-length binary, the representation of significant digits in the LCI is an explicit parameter. > In other words, given the example below can you tell me what the > LoRes, and LaRes values are? Interesting puzzle. Without all the syntactic sugar, the (Lat, Long) is (-34.407 150.883), which has 3 decimal digits of fraction. Since 2^10 ~= 10^3, the 10 fractional (binary) digits, plus the 9 (integer part) implies LaRes = LoRes = 19. It is true that the (over 3 times) finer grain of binary resolution is lost somewhat in the coarser grain of decimal resolution. Certainly, not all the information is lost, just slightly less than two bits of information. > What does the indicated point mean? GoogleEarth conveniently displays decimal degrees, and from the map, this appears to be the Computer Science building at the University of Wollongong. To see the expressive power of resolution, notice the fewer significant digits in the location (-34.406, 150.88) of the entire campus, and (-34.40691, 150.88299) for a corner office in the NE wing of that building. John > > > xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" > xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" > xmlns:gs="http://www.opengis.net/pidflo/1.0" > xmlns:gml="http://www.opengis.net/gml" > entity="pres:point2d@example.com"> > > > > > xmlns:gml="http://www.opengis.net/gml"> > -34.407 150.883 > > > > > > 2007-06-22T20:57:29Z > > > > > Do I totally miss something here? > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 21 16:41:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYpIW-0007Zq-Mk; Fri, 21 Sep 2007 16:40:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYpIV-0007Tu-Ir for ecrit@ietf.org; Fri, 21 Sep 2007 16:40:23 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IYpIU-0001Q2-SM for ecrit@ietf.org; Fri, 21 Sep 2007 16:40:23 -0400 Received: (qmail invoked by alias); 21 Sep 2007 20:40:21 -0000 Received: from p5498485F.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.72.95] by mail.gmx.net (mp017) with SMTP; 21 Sep 2007 22:40:21 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1//k9AWWFX/N8XI6j13aIM5czbXtEJVOw//124HBj JO91MRExnF2dQY Message-ID: <46F42C34.3090403@gmx.net> Date: Fri, 21 Sep 2007 22:40:20 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Marc Linsner Subject: Re: AW: [Ecrit] Phonebcp comments References: <006f01c7fc69$374f54a0$220d0d0a@amer.cisco.com> In-Reply-To: <006f01c7fc69$374f54a0$220d0d0a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Marc, Hi John, thanks for responding so quickly on this subject. I had a chat with Brian about this topic and he explained me the assumptions that are being made. For me it would have helped to read a bit background on the translation to a PIDF-LO in draft-ietf-geopriv-binary-lci. Ciao Hannes Marc Linsner wrote: > Hannes, > > >> In other words, given the example below can you tell me what >> the LoRes, and LaRes values are? What does the indicated point mean? >> >> >> > xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" >> xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" >> xmlns:gs="http://www.opengis.net/pidflo/1.0" >> xmlns:gml="http://www.opengis.net/gml" >> entity="pres:point2d@example.com"> >> >> >> >> >> > xmlns:gml="http://www.opengis.net/gml"> >> -34.407 150.883 >> >> >> >> >> >> 2007-06-22T20:57:29Z >> >> >> >> >> Do I totally miss something here? >> > > Significant digits! > > LoRes and LaRes allow you to determine your values are -34.407 150.883 and > not -34.40700000 150.88300000. LoRes and LaRes are determined during the > conversion to binary and used in the conversion from binary. That's it. No > magic. > > -Marc- > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 22 04:11:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ04j-0001T2-Mg; Sat, 22 Sep 2007 04:10:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ04i-0001KH-Eg for ecrit@ietf.org; Sat, 22 Sep 2007 04:10:52 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZ04c-00041i-Q3 for ecrit@ietf.org; Sat, 22 Sep 2007 04:10:47 -0400 X-SEF-Processed: 5_0_0_910__2007_09_22_03_20_18 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sat, 22 Sep 2007 03:20:18 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 22 Sep 2007 03:10:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Ecrit] Phonebcp comments Date: Sat, 22 Sep 2007 03:10:42 -0500 Message-ID: In-Reply-To: <006f01c7fc69$374f54a0$220d0d0a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Ecrit] Phonebcp comments Thread-Index: Acf8T8n1/px9VWd3ShGqICBzaqEcbAAACZLgAAK0cnAAJUy/IA== References: <5FB585F183235B42A9E70095055136FB1E5458@DEMUEXC012.nsn-intra.net> <006f01c7fc69$374f54a0$220d0d0a@amer.cisco.com> From: "Winterbottom, James" To: "Marc Linsner" , "Hannes Tschofenig" X-OriginalArrivalTime: 22 Sep 2007 08:10:44.0269 (UTC) FILETIME=[12E4E5D0:01C7FCF0] X-Spam-Score: 1.8 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org And the normative text from section 2.1 of RFC-3825=0D=0A=0D=0A"The example= s in the appendix illustrate that a smaller value in the=0D=0A resolution= field increases the area within which the device is=0D=0A located."=0D=0A=0D= =0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Marc Linsner [mail= to:mlinsner@cisco.com]=0D=0A> Sent: Saturday, 22 September 2007 2:05 AM=0D=0A= > To: 'Hannes Tschofenig'=0D=0A> Cc: 'ECRIT'=0D=0A> Subject: RE: AW: [Ecrit= ] Phonebcp comments=0D=0A>=20=0D=0A> Hannes,=0D=0A>=20=0D=0A> > In other wo= rds, given the example below can you tell me what=0D=0A> > the LoRes, and L= aRes values are=3F What does the indicated point mean=3F=0D=0A> >=0D=0A> > = <=3Fxml version=3D"1.0" encoding=3D"UTF-8"=3F>=0D=0A> > > xmlns:gp=3D"urn:ietf:params= :xml:ns:pidf:geopriv10"=0D=0A> > xmlns:cl=3D"urn:ietf:params:xml:ns:pid= f:geopriv10:civicAddr"=0D=0A> > xmlns:gs=3D"http://www.opengis.net/pidf= lo/1.0"=0D=0A> > xmlns:gml=3D"http://www.opengis.net/gml"=0D=0A> > = entity=3D"pres:point2d@example.com">=0D=0A> > =0D=0A> > =0D=0A> > =0D=0A> > = =0D=0A> > > xmlns:gml=3D"http://www.openg= is.net/gml">=0D=0A> > -34.407 150.883=0D=0A= > > =0D=0A> > =0D=0A= > > =0D=0A> > =0D=0A> > = =0D=0A> > 2007-06-22T20:57:29Z=0D= =0A> > =0D=0A> > =0D=0A> >=0D=0A> >=0D=0A> > Do = I totally miss something here=3F=0D=0A>=20=0D=0A> Significant digits!=0D=0A= >=20=0D=0A> LoRes and LaRes allow you to determine your values are -34.407 = 150.883=0D=0Aand=0D=0A> not -34.40700000 150.88300000. LoRes and LaRes are= determined during=0D=0Athe=0D=0A> conversion to binary and used in the con= version from binary. That's=0D=0Ait.=0D=0A> No=0D=0A> magic.=0D=0A>=20=0D=0A= > -Marc-=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> _____________________________= __________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> h= ttps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A--------------------= ---------------------------------------------------------------------------= -=0D=0AThis message is for the designated recipient only and may=0D=0Aconta= in privileged, proprietary, or otherwise private information. =20=0D=0AIf y= ou have received it in error, please notify the sender=0D=0Aimmediately and= delete the original. Any unauthorized use of=0D=0Athis email is prohibite= d.=0D=0A-------------------------------------------------------------------= -----------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 22 09:24:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ4wx-0005fn-AF; Sat, 22 Sep 2007 09:23:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ4wv-0005eX-Nk for ecrit@ietf.org; Sat, 22 Sep 2007 09:23:09 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IZ4wu-0005hR-C4 for ecrit@ietf.org; Sat, 22 Sep 2007 09:23:09 -0400 Received: (qmail invoked by alias); 22 Sep 2007 13:23:03 -0000 Received: from p54987604.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.118.4] by mail.gmx.net (mp038) with SMTP; 22 Sep 2007 15:23:03 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX180nXRvwvU0pc1gaFa9caChpTEIHDZqO0gIGouLaG pQDJPR7I1FFywn Message-ID: <46F51737.5040101@gmx.net> Date: Sat, 22 Sep 2007 15:23:03 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) 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: b7b9551d71acde901886cc48bfc088a6 Subject: [Ecrit] [Fwd: [Emu] Draft liaison response for IEEE 802.11u EAP method for emergency calls] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org FYI -------- Original Message -------- Subject: [Emu] Draft liaison response for IEEE 802.11u EAP method for emergency calls Date: Sun, 16 Sep 2007 22:26:36 -0700 From: Joseph Salowey (jsalowey) To: CC: Bernard Aboba , ecrit-chairs@tools.ietf.org The EMU working group has a liaison request from IEEE 802.11u on EAP methods for emergency calls. The liaison request can be found on the liaison statement page, https://datatracker.ietf.org/liaison/ (May 2007). We had a presentations and discussion of this topic at the Chicago EMU meeting. Below is a draft response based on the discussion in the meeting. It would be good to have comments on or approval of the text by Monday, October 1, so a revised response can be created to be sent as a response to the IEEE. ============================================================== 802.11u Liaison response for EAP Methods for Emergency Communications We have had discussion of EAP method for Emergency services at the last IETF meeting in Chicago. The following is a summary of working group discussion on this topic. Currently there are no standards track EAP methods that meet the requirements as understood by the EMU working group. There are several possible candidates of existing EAP methods that may meet or be slightly modified to meet some of the 802.11u requirements for emergency services, especially if minimal latency is not the strongest requirement. TTLS (draft-funk-eap-ttls-v0-01.txt) and EAP-FAST (RFC4851) are TLS based methods that can support server only authentication. It was also pointed out that EAP-TLS (draft-simon-emu-rfc2716bis-11.txt) could be modified to create a new EAP method that only requires server side authentication. In order to truly support emergency services these methods would need to forego server certificate validation which negates much of the security they provide by allowing man-in-the-middle attacks. These TLS based methods also require a significant number of round trips that may not be acceptable for emergency communication. There were also several questions raised in the working group during the discussion that might help in furtFrom ecrit-bounces@ietf.org Sat Sep 22 09:24:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ4wx-0005fn-AF; Sat, 22 Sep 2007 09:23:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ4wv-0005eX-Nk for ecrit@ietf.org; Sat, 22 Sep 2007 09:23:09 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IZ4wu-0005hR-C4 for ecrit@ietf.org; Sat, 22 Sep 2007 09:23:09 -0400 Received: (qmail invoked by alias); 22 Sep 2007 13:23:03 -0000 Received: from p54987604.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.118.4] by mail.gmx.net (mp038) with SMTP; 22 Sep 2007 15:23:03 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX180nXRvwvU0pc1gaFa9caChpTEIHDZqO0gIGouLaG pQDJPR7I1FFywn Message-ID: <46F51737.5040101@gmx.net> Date: Sat, 22 Sep 2007 15:23:03 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) 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: b7b9551d71acde901886cc48bfc088a6 Subject: [Ecrit] [Fwd: [Emu] Draft liaison response for IEEE 802.11u EAP method for emergency calls] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org FYI -------- Original Message -------- Subject: [Emu] Draft liaison response for IEEE 802.11u EAP method for emergency calls Date: Sun, 16 Sep 2007 22:26:36 -0700 From: Joseph Salowey (jsalowey) To: CC: Bernard Aboba , ecrit-chairs@tools.ietf.org The EMU working group has a liaison request from IEEE 802.11u on EAP methods for emergency calls. The liaison request can be found on the liaison statement page, https://datatracker.ietf.org/liaison/ (May 2007). We had a presentations and discussion of this topic at the Chicago EMU meeting. Below is a draft response based on the discussion in the meeting. It would be good to have comments on or approval of the text by Monday, October 1, so a revised response can be created to be sent as a response to the IEEE. ============================================================== 802.11u Liaison response for EAP Methods for Emergency Communications We have had discussion of EAP method for Emergency services at the last IETF meeting in Chicago. The following is a summary of working group discussion on this topic. Currently there are no standards track EAP methods that meet the requirements as understood by the EMU working group. There are several possible candidates of existing EAP methods that may meet or be slightly modified to meet some of the 802.11u requirements for emergency services, especially if minimal latency is not the strongest requirement. TTLS (draft-funk-eap-ttls-v0-01.txt) and EAP-FAST (RFC4851) are TLS based methods that can support server only authentication. It was also pointed out that EAP-TLS (draft-simon-emu-rfc2716bis-11.txt) could be modified to create a new EAP method that only requires server side authentication. In order to truly support emergency services these methods would need to forego server certificate validation which negates much of the security they provide by allowing man-in-the-middle attacks. These TLS based methods also require a significant number of round trips that may not be acceptable for emergency communication. There were also several questions raised in the working group during the discussion that might help in further determining the best approach. These are summarized below: 1) It is not clear how to make the tradeoff between security and low-latency. If there is not existing trust relationship there are limits as to what security properties can be provided. What security properties are desirable and what is the tolerance for extra-round trips for the communication? 2) PSK was described as having worse DOS resistance properties that EAP. It seems that in many cases EAP would have worse DOS resistance that PSK, which cases is EAP better? 3) It seems that most public access networks already provide an open access network, why couldn't this network be used for emergency communication? 4) What regulatory requirements are driving the need for encryption? This creates some conflicts because encryption without authentication does not satisfy most useful security requirements. As the 802.11u group is certainly aware, there are other groups within the IETF that are looking at unauthenticated emergency services. In particular, the ECRIT group within the IETF has ongoing work in this area: http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-acces s-00 We encourage IEEE working group members to continue the discussion with the IETF in the EMU and the ECRIT working groups. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 22 09:24:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ4ww-0005ek-0X; Sat, 22 Sep 2007 09:23:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ4wu-0005Or-2h for ecrit@ietf.org; Sat, 22 Sep 2007 09:23:08 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IZ4wi-0003BG-JL for ecrit@ietf.org; Sat, 22 Sep 2007 09:22:57 -0400 Received: (qmail invoked by alias); 22 Sep 2007 13:22:55 -0000 Received: from p54987604.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.118.4] by mail.gmx.net (mp029) with SMTP; 22 Sep 2007 15:22:55 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19HSVAMGhBHoUvbxtO9mQlscJlIfRRfcqXuK7i9vx rFPsQomWga3CCo Message-ID: <46F5172E.3000005@gmx.net> Date: Sat, 22 Sep 2007 15:22:54 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: ecrit-chairs@tools.ietf.org, emu@ietf.org, ECRIT Subject: [Ecrit] Re: Draft liaison response for IEEE 802.11u EAP method for emergency calls X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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 Bernard, thanks for your input. Please find a few more thoughts below: Bernard Aboba wrote: > It is not clear to me whether the requirements do in fact prohibit > server-side authentication. As you note, without server-side > authentication man-in-the-middle attacks are possible; however, even > with server-side authentication, additional requirements may need to > be imposed in order to provide the desired level of security. > I also believe that the reqher determining the best approach. These are summarized below: 1) It is not clear how to make the tradeoff between security and low-latency. If there is not existing trust relationship there are limits as to what security properties can be provided. What security properties are desirable and what is the tolerance for extra-round trips for the communication? 2) PSK was described as having worse DOS resistance properties that EAP. It seems that in many cases EAP would have worse DOS resistance that PSK, which cases is EAP better? 3) It seems that most public access networks already provide an open access network, why couldn't this network be used for emergency communication? 4) What regulatory requirements are driving the need for encryption? This creates some conflicts because encryption without authentication does not satisfy most useful security requirements. As the 802.11u group is certainly aware, there are other groups within the IETF that are looking at unauthenticated emergency services. In particular, the ECRIT group within the IETF has ongoing work in this area: http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-acces s-00 We encourage IEEE working group members to continue the discussion with the IETF in the EMU and the ECRIT working groups. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 22 09:24:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ4ww-0005ek-0X; Sat, 22 Sep 2007 09:23:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ4wu-0005Or-2h for ecrit@ietf.org; Sat, 22 Sep 2007 09:23:08 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IZ4wi-0003BG-JL for ecrit@ietf.org; Sat, 22 Sep 2007 09:22:57 -0400 Received: (qmail invoked by alias); 22 Sep 2007 13:22:55 -0000 Received: from p54987604.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.118.4] by mail.gmx.net (mp029) with SMTP; 22 Sep 2007 15:22:55 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19HSVAMGhBHoUvbxtO9mQlscJlIfRRfcqXuK7i9vx rFPsQomWga3CCo Message-ID: <46F5172E.3000005@gmx.net> Date: Sat, 22 Sep 2007 15:22:54 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: ecrit-chairs@tools.ietf.org, emu@ietf.org, ECRIT Subject: [Ecrit] Re: Draft liaison response for IEEE 802.11u EAP method for emergency calls X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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 Bernard, thanks for your input. Please find a few more thoughts below: Bernard Aboba wrote: > It is not clear to me whether the requirements do in fact prohibit > server-side authentication. As you note, without server-side > authentication man-in-the-middle attacks are possible; however, even > with server-side authentication, additional requirements may need to > be imposed in order to provide the desired level of security. > I also believe that the requirements does not rule out server-side authentication. > Requirement #1 is "No Pre-configured trust relationship". This could > refer to pre-configuration of the server with respect to the expected > client credential (PSK or certificate), or it could refer to > pre-configuration of the client with respect to the server, (such > trust anchors). The text seems focused on the former more than the > latter. Assuming that clients can be pre-configured with trust > anchors, then TLS-based EAP methods could meet the requirement. > I agree that this aspect of no pre-configured trust relationship is quite likely to refer to pre-established shared secrets. > Requirement #2 is "Small" number of messages. While this requirement > clearly excludes long exchanges, it is not clear to me that TLS-based > methods are excluded, particularly if the method is to be implemented > on the AP itself, which potentially would result in lower round-trip > times and eliminate the possibility of AAA-based frame loss. > I doubt that the performance argument counts a lot here given that the exchange is, as you indicated, local. > It may be possible that requirements #1 and #2 are compatible with > proposals involving unauthenticated client access combined with server > authentication. However, due to lack of a pre-configured network > access profile, this scenario presents additional threats that are > worthy of further discussion. > > The presentation refers to the desire to for confidentiality > (presumably at L2, rather than using SRTP). Where confidentiality is > desirable, it will also presumably be important for the client to > determine that it has connected to a legitimate network. Whereby "legitimate network" is already a quite difficult requirement. > > Where a pre-configured network access profile exists, the binding > between a validated server certificate and an advertised SSID is > pre-configured. However, where there is no pre-configured network > access profile, the binding may be difficult to establish without > imposition of additional requirements. > > For example, the server certificate/SSID binding cannot be determined > solely via verification of the server certificate. An attacker could > obtain a valid server certificate for "example.com"; does this entitle > them to advertise an SSID of "Emergency Network" or even "Example"? > Since SSIDs are not globally unique, there is no verifiable mapping > between a Server-Id and an allowed set of SSIDs. In general, a CA has > no way of determining whether a server has the rights to a particular > SSID or not, so that a CA cannot in practice vouch for an RFC 4334 > SSID extension within a server certificate. > > Therefore verification of a binding between the server identity and > the advertised network would only seem to be possible by requiring the > advertised network name to match the Server-Id advertised in the > server certificate. This in turn would require restricting the > allowable SSIDs, or adding another field to the IEEE 802.11 > Beacon/Probe Response. > I don't think it make a lot of sense to bind the certificate to the advertised SSID. WHAT CAN YOU ACCOMPLISH WITH SERVER-SIDE AUTHENTICATION? The important question here, I believe, is what you would do with server-side authentication in such a context given that it has entirely different semantic than the server-side authentication that is typically exercised in EAP exchanges between the peer and the EAP server in the user's home network. I don't think that addressing man-in-the-middle attacks is the main objective. Instead, I could imagine that when something goes wrong then the end user might be able to indicate that he or she was interacting with a specific network.I see this more as a "debugging" tool. When some verification steps fails, for example because the certificate of the server is expired, then in an emergency situation you will just continue rather than dropping the conversation. Additionally, everyone should be able to setup networks and heuirements does not rule out server-side authentication. > Requirement #1 is "No Pre-configured trust relationship". This could > refer to pre-configuration of the server with respect to the expected > client credential (PSK or certificate), or it could refer to > pre-configuration of the client with respect to the server, (such > trust anchors). The text seems focused on the former more than the > latter. Assuming that clients can be pre-configured with trust > anchors, then TLS-based EAP methods could meet the requirement. > I agree that this aspect of no pre-configured trust relationship is quite likely to refer to pre-established shared secrets. > Requirement #2 is "Small" number of messages. While this requirement > clearly excludes long exchanges, it is not clear to me that TLS-based > methods are excluded, particularly if the method is to be implemented > on the AP itself, which potentially would result in lower round-trip > times and eliminate the possibility of AAA-based frame loss. > I doubt that the performance argument counts a lot here given that the exchange is, as you indicated, local. > It may be possible that requirements #1 and #2 are compatible with > proposals involving unauthenticated client access combined with server > authentication. However, due to lack of a pre-configured network > access profile, this scenario presents additional threats that are > worthy of further discussion. > > The presentation refers to the desire to for confidentiality > (presumably at L2, rather than using SRTP). Where confidentiality is > desirable, it will also presumably be important for the client to > determine that it has connected to a legitimate network. Whereby "legitimate network" is already a quite difficult requirement. > > Where a pre-configured network access profile exists, the binding > between a validated server certificate and an advertised SSID is > pre-configured. However, where there is no pre-configured network > access profile, the binding may be difficult to establish without > imposition of additional requirements. > > For example, the server certificate/SSID binding cannot be determined > solely via verification of the server certificate. An attacker could > obtain a valid server certificate for "example.com"; does this entitle > them to advertise an SSID of "Emergency Network" or even "Example"? > Since SSIDs are not globally unique, there is no verifiable mapping > between a Server-Id and an allowed set of SSIDs. In general, a CA has > no way of determining whether a server has the rights to a particular > SSID or not, so that a CA cannot in practice vouch for an RFC 4334 > SSID extension within a server certificate. > > Therefore verification of a binding between the server identity and > the advertised network would only seem to be possible by requiring the > advertised network name to match the Server-Id advertised in the > server certificate. This in turn would require restricting the > allowable SSIDs, or adding another field to the IEEE 802.11 > Beacon/Probe Response. > I don't think it make a lot of sense to bind the certificate to the advertised SSID. WHAT CAN YOU ACCOMPLISH WITH SERVER-SIDE AUTHENTICATION? The important question here, I believe, is what you would do with server-side authentication in such a context given that it has entirely different semantic than the server-side authentication that is typically exercised in EAP exchanges between the peer and the EAP server in the user's home network. I don't think that addressing man-in-the-middle attacks is the main objective. Instead, I could imagine that when something goes wrong then the end user might be able to indicate that he or she was interacting with a specific network.I see this more as a "debugging" tool. When some verification steps fails, for example because the certificate of the server is expired, then in an emergency situation you will just continue rather than dropping the conversation. Additionally, everyone should be able to setup networks and hence the adversary can easily do the same. What would the network of an adversary differentiate from one that is from someone else? WHAT ASSUMPTIONS DO WE MAKE WITH RESPECT TO THE SERVER'S CERTIFICATE AND THE TRUST ANCHORS? Do we assume that persons that setup networks, such as my home network, a coffee shop, the IETF network, have to obtain a certificate for their network from a) from any company that sells certs typically found in web servers b) from a dedicated emergency services provider (Note1) May I re-use existing trust anchors, such as those available with my web browsers, or do end devices need to add new root certs into their certificate store? In case (b) can I assume that the PSAP also uses the same trust anchor so that I could potentially use DTLS-SRTP for end-to-end media security to ensure that I am actually speaking to a real PSAP rather than to an adversary? Ciao Hannes Note 1: Would it be allowed to just skip server-side authentication and to end-up with a unauthenticated Diffie-Helman exchange? One might argue that this does not provide a lot of advantages and we could also skip the EAP exchange entirely but that's not completely true that architectures, such as Wimax, assume that keying material is exported during network attachment and that these keys are used for other protocols. Hence, if one would change then the impact for the other work done before would be too large. > > > > > >> From: "Joseph Salowey (jsalowey)" >> To: >> CC: , "Bernard Aboba" >> >> Subject: Draft liaison response for IEEE 802.11u EAP method for >> emergency calls >> Date: Sun, 16 Sep 2007 22:26:36 -0700 >> >> The EMU working group has a liaison request from IEEE 802.11u on EAP >> methods for emergency calls. The liaison request can be found on the >> liaison statement page, https://datatracker.ietf.org/liaison/ (May >> 2007). We had a presentations and discussion of this topic at the >> Chicago EMU meeting. Below is a draft response based on the discussion >> in the meeting. It would be good to have comments on or approval of the >> text by Monday, October 1, so a revised response can be created to be >> sent as a response to the IEEE. >> >> ============================================================== >> >> 802.11u Liaison response for EAP Methods for Emergency Communications >> >> We have had discussion of EAP method for Emergency services at the last >> IETF meeting in Chicago. The following is a summary of working group >> discussion on this topic. >> >> Currently there are no standards track EAP methods that meet the >> requirements as understood by the EMU working group. There are several >> possible candidates of existing EAP methods that may meet or be slightly >> modified to meet some of the 802.11u requirements for emergency >> services, especially if minimal latency is not the strongest >> requirement. TTLS (draft-funk-eap-ttls-v0-01.txt) and EAP-FAST >> (RFC4851) are TLS based methods that can support server only >> authentication. It was also pointed out that EAP-TLS >> (draft-simon-emu-rfc2716bis-11.txt) could be modified to create a new >> EAP method that only requires server side authentication. In order to >> truly support emergency services these methods would need to forego >> server certificate validation which negates much of the security they >> provide by allowing man-in-the-middle attacks. These TLS based methods >> also require a significant number of round trips that may not be >> acceptable for emergency communication. >> >> There were also several questions raised in the working group during the >> discussion that might help in further determining the best approach. >> These are summarized below: >> >> 1) It is not clear how to make the tradeoff between security and >> low-latency. If there is not existing trust relationship there are >> limits as to what security properties can be provided. What security >> properties are desirable and what is the tolerance for extnce the adversary can easily do the same. What would the network of an adversary differentiate from one that is from someone else? WHAT ASSUMPTIONS DO WE MAKE WITH RESPECT TO THE SERVER'S CERTIFICATE AND THE TRUST ANCHORS? Do we assume that persons that setup networks, such as my home network, a coffee shop, the IETF network, have to obtain a certificate for their network from a) from any company that sells certs typically found in web servers b) from a dedicated emergency services provider (Note1) May I re-use existing trust anchors, such as those available with my web browsers, or do end devices need to add new root certs into their certificate store? In case (b) can I assume that the PSAP also uses the same trust anchor so that I could potentially use DTLS-SRTP for end-to-end media security to ensure that I am actually speaking to a real PSAP rather than to an adversary? Ciao Hannes Note 1: Would it be allowed to just skip server-side authentication and to end-up with a unauthenticated Diffie-Helman exchange? One might argue that this does not provide a lot of advantages and we could also skip the EAP exchange entirely but that's not completely true that architectures, such as Wimax, assume that keying material is exported during network attachment and that these keys are used for other protocols. Hence, if one would change then the impact for the other work done before would be too large. > > > > > >> From: "Joseph Salowey (jsalowey)" >> To: >> CC: , "Bernard Aboba" >> >> Subject: Draft liaison response for IEEE 802.11u EAP method for >> emergency calls >> Date: Sun, 16 Sep 2007 22:26:36 -0700 >> >> The EMU working group has a liaison request from IEEE 802.11u on EAP >> methods for emergency calls. The liaison request can be found on the >> liaison statement page, https://datatracker.ietf.org/liaison/ (May >> 2007). We had a presentations and discussion of this topic at the >> Chicago EMU meeting. Below is a draft response based on the discussion >> in the meeting. It would be good to have comments on or approval of the >> text by Monday, October 1, so a revised response can be created to be >> sent as a response to the IEEE. >> >> ============================================================== >> >> 802.11u Liaison response for EAP Methods for Emergency Communications >> >> We have had discussion of EAP method for Emergency services at the last >> IETF meeting in Chicago. The following is a summary of working group >> discussion on this topic. >> >> Currently there are no standards track EAP methods that meet the >> requirements as understood by the EMU working group. There are several >> possible candidates of existing EAP methods that may meet or be slightly >> modified to meet some of the 802.11u requirements for emergency >> services, especially if minimal latency is not the strongest >> requirement. TTLS (draft-funk-eap-ttls-v0-01.txt) and EAP-FAST >> (RFC4851) are TLS based methods that can support server only >> authentication. It was also pointed out that EAP-TLS >> (draft-simon-emu-rfc2716bis-11.txt) could be modified to create a new >> EAP method that only requires server side authentication. In order to >> truly support emergency services these methods would need to forego >> server certificate validation which negates much of the security they >> provide by allowing man-in-the-middle attacks. These TLS based methods >> also require a significant number of round trips that may not be >> acceptable for emergency communication. >> >> There were also several questions raised in the working group during the >> discussion that might help in further determining the best approach. >> These are summarized below: >> >> 1) It is not clear how to make the tradeoff between security and >> low-latency. If there is not existing trust relationship there are >> limits as to what security properties can be provided. What security >> properties are desirable and what is the tolerance for extra-round trips >> for the communication? >> >> 2) PSK was described as having worse DOS resistance properties that EAP. >> It seems that in many cases EAP would have worse DOS resistance that >> PSK, which cases is EAP better? >> >> 3) It seems that most public access networks already provide an open >> access network, why couldn't this network be used for emergency >> communication? >> >> 4) What regulatory requirements are driving the need for encryption? >> This creates some conflicts because encryption without authentication >> does not satisfy most useful security requirements. >> >> As the 802.11u group is certainly aware, there are other groups within >> the IETF that are looking at unauthenticated emergency services. In >> particular, the ECRIT group within the IETF has ongoing work in this >> area: >> >> http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-acces >> s-00 >> >> We encourage IEEE working group members to continue the discussion with >> the IETF in the EMU and the ECRIT working groups. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ra-round trips >> for the communication? >> >> 2) PSK was described as having worse DOS resistance properties that EAP. >> It seems that in many cases EAP would have worse DOS resistance that >> PSK, which cases is EAP better? >> >> 3) It seems that most public access networks already provide an open >> access network, why couldn't this network be used for emergency >> communication? >> >> 4) What regulatory requirements are driving the need for encryption? >> This creates some conflicts because encryption without authentication >> does not satisfy most useful security requirements. >> >> As the 802.11u group is certainly aware, there are other groups within >> the IETF that are looking at unauthenticated emergency services. In >> particular, the ECRIT group within the IETF has ongoing work in this >> area: >> >> http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-acces >> s-00 >> >> We encourage IEEE working group members to continue the discussion with >> the IETF in the EMU and the ECRIT working groups. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 22 09:24:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ4x1-0005n8-Th; Sat, 22 Sep 2007 09:23:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ4x0-0005n0-3N for ecrit@ietf.org; Sat, 22 Sep 2007 09:23:14 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IZ4wy-0003Bc-Rd for ecrit@ietf.org; Sat, 22 Sep 2007 09:23:13 -0400 Received: (qmail invoked by alias); 22 Sep 2007 13:23:11 -0000 Received: from p54987604.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.118.4] by mail.gmx.net (mp054) with SMTP; 22 Sep 2007 15:23:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18i8ahSatsiqee/5WQBSZ7kkK/kpj2GPM4K19p7d2 wFZSEB3UhO1NdH Message-ID: <46F5173F.1060107@gmx.net> Date: Sat, 22 Sep 2007 15:23:11 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) 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: c54bc2f42d02429833c0ca4b8725abd7 Subject: [Ecrit] [Fwd: [Emu] RE: Draft liaison response for IEEE 802.11u EAP method for emergency calls] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org FYI -------- Original Message -------- Subject: [Emu] RE: Draft liaison response for IEEE 802.11u EAP method for emergency calls Date: Mon, 17 Sep 2007 10:20:25 -0700 From: Bernard Aboba To: jsalowey@cisco.com, emu@ietf.org CC: Bernard_Aboba@hotmail.com, ecrit-chairs@tools.ietf.org It is not clear to me whether the requirements do in fact prohibit server-side authentication. As you note, without server-side authentication man-in-the-middle attacks are possible; however, even with server-side authentication, additional requirements may need to be imposed in order to provide the desired level of security. Requirement #1 is "No Pre-configured trust relationship". This could refer to pre-configuration of the server with respect to the expected client credential (PSK or certificate), or it could refer to pre-configuration of the client with respect to the server, (such trust anchors). The text seems focused on the former more than the latter. Assuming that clients can be pre-configured with trust anchors, then TLS-based EAP methods could meet the requirement. Requirement #2 is "Small" number of messages. While this requirement clearly excludes long exchanges, it is not clear to me that TLS-based methods are excluded, particularly if the method is to be implemented on the AP itself, which potentially would result in lower round-trip times and eliminate the possibility of AAA-based frame loss. It may be possible that requirements #1 and #2 are compatible with proposals involving unauthenticated client access combined with server authentication. However, due to lack of a pre-configured network access profile, this scenario presents additional threats that are worthy of further discussion. The presentation refers to the desire to for confidentiality (presumably at L2, rather than using SRTP). Where confidentiality is desirable, it will also presumably be important for the client to determine that it has connected to a legitimate network. Where a pre-configured network access profile exists, the binding between a validated server certificate and an advertised SSID is pre-configured. However, where there is no pre-configured network access profile, the binding may be difficult to establish without imposition of additional requirements. For example, the server certificate/SSID binding cannot be determined solely via verification of the server certificate. An attacker could obtain a valid server certificate for "example.com"; does this entitle them to advertise an SSID of "Emergency Network" or even "Example"? Since SSIDs are not globally unique, there is no verifiable mapping between a Server-Id and an allowed set of SSIDs. In general, a CA has no way of determining whether a server has the rights to a particular SSID or not, so that a CA cannot in practice vouch for an RFC 4334 SSID extension within a server certificate. Therefore verification of a binding between the server identity and the advertised network would only seem to be possible by requiring the advertised network name to match the Server-Id advertised in the server certificate. This in turn would require restricting the allowable SSIDs, or adding another field to the IEEE 802.11 Beacon/Probe Response. >From: "Joseph Salowey (jsalowey)" >To: >CC: , "Bernard Aboba" > >Subject: Draft liaison response for IEEE 802.11u EAP method for emergency >calls >Date: Sun, 16 Sep 2007 22:26:36 -0700 > >The EMU working group has a liaison request from IEEE 802.11u on EAP >methods for emergency calls. The liaison request can be found on the >liaison statement page, https://datatracker.ietf.org/liaison/ (May >2007). We had a presentations and discussion of this topic at the >Chicago EMU meeting. Below is a draft response based on the discussion >in the meeting. It would be good to have comments on or approval of the >text by Monday, October 1, so a revised response can be created to be >sent as a response to the IEEE. > >============================================================== > >802.11u Liaison response for EAP Methods for Emergency Communications > >We have had discussion of EAP method for Emergency services at the last >IETF meeting in Chicago. The following is a summary of working group >discussion on this topic. > >Currently there are no standards track EAP methods that meet the >requirements as understood by the EMU working group. There are several >possible candidates of existing EAP methods that may meet or be slightly >modified to meet some of the 802.11u requirements for emergency >services, especially if minimal latency is not the strongest >requirement. TTLS (draft-funk-eap-ttls-v0-01.txt) and EAP-FAST >(RFC4851) are TLS based methods that can support server only >authentication. It was also pointed out that EAP-TLS >(draft-simon-emu-rfc2716bis-11.txt) could be modified to create a new >EAP method that only requires server side authentication. In order to >truly support emergency services these methods would need to forego >server certificate validation which negates much of the security they >provide by allowing man-in-the-middle attacks. These TLS based methods >also require a significant number of round trips that may not be >acceptable for emergency communication. > >There were also several questions raised in the working group during the >discussion that might help in further determining the best approach. >These are summarized below: > >1) It is not clear how to make the tradeoff between security and >low-latency. If there is not existing trust relationship there are >limits as to what security properties can be provided. What security >properties are desirable and what is the tolerance for extra-round trips >for the communication? > >2) PSK was described as having worse DOS resistance properties that EAP. >It seems that in many cases EAP would have worse DOS resistance that >PSK, which cases is EAP better? > >3) It seems that most public access networks already provide an open >access network, why couldn't this network be used for emergency >communication? > >4) What regulatory requirements are driving the need for encryption? >This creates some conflicts because encryption without authentication >does not satisfy most useful security requirements. > >As the 802.11u group is certainly aware, there are other groups within >the IETF that are looking at unauthenticated emergency services. In >particular, the ECRIT group within the IETF has ongoing work in this >area: > >http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-acces >s-00 > >We encourage IEEE working group members to continue the discussion with >the IETF in the EMU and the ECRIT working groups. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Sep 23 20:35:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZbte-0007yc-L4; Sun, 23 Sep 2007 20:33:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZbte-0007sa-5v for ecrit@ietf.org; Sun, 23 Sep 2007 20:33:58 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZbtY-0007ac-Cz for ecrit@ietf.org; Sun, 23 Sep 2007 20:33:52 -0400 X-SEF-Processed: 5_0_0_910__2007_09_23_19_43_28 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 23 Sep 2007 19:43:28 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 23 Sep 2007 19:33:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Phonebcp comments - 3825 interpretation Date: Sun, 23 Sep 2007 19:33:49 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phonebcp comments - 3825 interpretation Thread-Index: Acf8bc9KmvdSLfYQQiq0Gs0HNlbKGgBz2vmw References: <7582BC68E4994F4ABF0BD4723975C3FA03B0F1F2@crexc41p><110201c7fb00$fe54a380$640fa8c0@cis.neustar.com> <91D87B6E-657E-4738-AD7A-FDBAEEAFB69B@cisco.com> <5FB585F183235B42A9E70095055136FB0555CC@DEMUEXC012.nsn-intra.net><46F37AFA.4040301@gmx.net><8DDBF6AC-A7C3-4BC9-B1C9-140C1E509BA7@cisco.com><5FB585F183235B42A9E70095055136FB1E5458@DEMUEXC012.nsn-intra.net> From: "Thomson, Martin" To: "John Schnizlein" , "Tschofenig, Hannes \(NSN - DE/Germany - MiniMD\)" X-OriginalArrivalTime: 24 Sep 2007 00:33:51.0710 (UTC) FILETIME=[948FD7E0:01C7FE42] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: "Stark, Barbara" , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1817611408==" Errors-To: ecrit-bounces@ietf.org --===============1817611408== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgc2VlbXMgdGhhdCB0aGlzIGRpc2N1c3Npb24gaGFzIHdhbmRlcmVkIG92ZXIgdGhlIEVDUklU L0dFT1BSSVYgZGl2aWRlLiAgSSBvbmx5IHJlYWQgdGl0bGVzIGluIEVDUklUIHdoZW4gSSdtIGJ1 c3ksIHNvIHRoaXMgZXNjYXBlZCBteSBub3RpY2UuDQoNCkZpcnN0bHksIEdNTCBkb2VzIG5vdCBp bmNsdWRlIG1lbnRpb24gb2Ygc2lnbmlmaWNhbnQgZmlndXJlcyBhbmQgaG93IHRvIGludGVycHJl dCBkaWdpdGFsIHJlcHJlc2VudGF0aW9ucy4gIFRoZXJlZm9yZSwgd2UgY2Fubm90IHJlbHkgb24g dXNpbmcgdGhlIGxlbmd0aCBvZiBhbnkgbnVtYmVyIHRvIGNvbnZleSBhbnkgaW5mb3JtYXRpb24u ICBTb3JyeSwgd2UgY2FuJ3QgcmVseSBvbiBpbXBsaWVkIG1lYW5pbmcuDQoNCkJhc2VkIG9uIHRo aXMgaW50ZXJwcmV0YXRpb24sIGl0IGlzIGltcG9zc2libGUgdG8gcmVwcmVzZW50IGEgcG9pbnQg aW4gc3BhY2UsIGlycmVzcGVjdGl2ZSBvZiBhbnkgcmVxdWlyZW1lbnQgdG8gZG8gc28uICBUaGUg MzgyNSByZXByZXNlbnRhdGlvbiBpcyBhbiBhcmVhIChjLmYuIFNlY3Rpb24gMi4xKTsgc2ltaWxh cmx5LCB0aGUgR01MIHJlcHJlc2VudGF0aW9uIG9mIGEgcG9pbnQgaXMgYWN0dWFsbHkgYW4gYXJl YSB0b28uDQoNCkkgcHJvcG9zZSB0aGF0IHdlIGRvIGF3YXkgd2l0aCBhbnkgaW1wbGllZCBvciBh c3N1bWVkIG1lYW5pbmcuICBTaWduaWZpY2FudCBmaWd1cmVzIGFyZSB1c2VsZXNzIGJlY2F1c2Ug dGhleSByZWx5IG9uIGFuIGFzc3VtcHRpb24uDQoNCkl0IHNlZW1zIHRvIG1lIHRoYXQgaXQgd291 bGQgYmUgYmVzdCB0byByZXNvbHZlIHRoaXMgb24gdGhlIEdFT1BSSVYgbGlzdCBhbmQgc2ltcGx5 IGhhdmUgLXBob25lLWJjcCByZWZlcmVuY2Ugd2hhdCBpcyBwcm9kdWNlZCB0aGVyZS4NCg0KVGhl cmVmb3JlLCBJIHByb3Bvc2UgdGhhdCB0aGUgYW5zd2VyIHRvIHRoZSBvcmlnaW5hbCBxdWVzdGlv biBpcyBpbiBTZWN0aW9uIDMuMiBvZiAobXkpIDM4MjViaXM6DQoNCmh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXRob21zb24tZ2VvcHJpdi0zODI1YmlzLTAwI3NlY3Rpb24tMy4yDQoN Cg0KQ2hlZXJzLA0KTWFydGluDQoNCiJJZiB5b3UgZXZlciBmZWVsIHlvdSBuZWVkIHRvIHdyaXRl IHNvbWV0aGluZyB1c2luZyBzaWdbbmlmaWNhbnRdIGZpZ1t1cmVdcywgeW91IHNob3VsZCBsaWUg ZG93biB1bnRpbCB0aGUgZmVlbGluZyBnb2VzIGF3YXkuICBGaWd1cmUgb3V0IHdoYXQgeW91IGFy ZSB0cnlpbmcgdG8gc2F5LCBhbmQgZmluZCBhIGJldHRlciB3YXkgb2Ygc2F5aW5nIGl0LiBJZiB5 b3UgYXJlIGdvaW5nIHRvIGV4cHJlc3MgdGhlIHVuY2VydGFpbnR5IGF0IGFsbCwgZXhwcmVzcyBp dCBzZXBhcmF0ZWx5IGFuZCBleHBsaWNpdGx5LiINCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBKb2huIFNjaG5pemxlaW4gW21haWx0bzpqc2Nobml6bEBjaXNjby5jb21d DQo+IFNlbnQ6IFNhdHVyZGF5LCAyMiBTZXB0ZW1iZXIgMjAwNyAyOjM3IEFNDQo+IFRvOiBUc2No b2ZlbmlnLEhhbm5lcyAoTlNOIC0gREUvR2VybWFueSAtIE1pbmlNRCkNCj4gQ2M6IFN0YXJrLCBC YXJiYXJhOyBFQ1JJVA0KPiBTdWJqZWN0OiBSZTogQVc6IEFXOiBbRWNyaXRdIFBob25lYmNwIGNv bW1lbnRzDQo+IA0KPiANCj4gT24gU2VwIDIxLCAyMDA3LCBhdCAxMDoxNCBBTSwgVHNjaG9mZW5p ZywgSGFubmVzIChOU04gLSBERS9HZXJtYW55IC0NCj4gTWluaU1EKSB3cm90ZToNCj4gDQo+ID4g QnV0IHRoaXMgaW5mb3JtYXRpb24gYWJvdXQgdGhlIExvUmVzLCBMYVJlcyBhbmQgQWx0UmVzIHdv dWxkIGJlDQo+ID4gbG9zdCBpbiB0aGUgdHJhbnNsYXRpb24gc2luY2UgYSBQSURGLUxPIGRvZXMg bm90IGNhcnJ5IHRoZXNlDQo+ID4gcGFyYW1ldGVycy4NCj4gDQo+IFRoZSAodmFyaWFibGUgbGVu Z3RoKSBkZWNpbWFsIHN0cmluZyBvZiBMYXRpdHVkZSBhbmQgTG9uZ2l0dWRlIGRvZXMNCj4gY2Fy cnkgcmVzb2x1dGlvbiBpbXBsaWNpdGx5IGluIHRoZSBsZW5ndGggb2YgdGhlIHN0cmluZywgd2hp Y2ggaXMgaXRzDQo+IHJlcHJlc2VudGF0aW9uIG9mIHNpZ25pZmljYW50IGRpZ2l0cy4gIEJlY2F1 c2UgaXQgaXMgZml4ZWQtbGVuZ3RoDQo+IGJpbmFyeSwgdGhlIHJlcHJlc2VudGF0aW9uIG9mIHNp Z25pZmljYW50IGRpZ2l0cyBpbiB0aGUgTENJIGlzIGFuDQo+IGV4cGxpY2l0IHBhcmFtZXRlci4N Cj4gDQo+ID4gSW4gb3RoZXIgd29yZHMsIGdpdmVuIHRoZSBleGFtcGxlIGJlbG93IGNhbiB5b3Ug dGVsbCBtZSB3aGF0IHRoZQ0KPiA+IExvUmVzLCBhbmQgTGFSZXMgdmFsdWVzIGFyZT8NCj4gDQo+ IEludGVyZXN0aW5nIHB1enpsZS4gIFdpdGhvdXQgYWxsIHRoZSBzeW50YWN0aWMgc3VnYXIsIHRo ZSAoTGF0LCBMb25nKQ0KPiBpcyAoLTM0LjQwNyAxNTAuODgzKSwgd2hpY2ggaGFzIDMgZGVjaW1h bCBkaWdpdHMgb2YgZnJhY3Rpb24uICBTaW5jZQ0KPiAyXjEwIH49IDEwXjMsIHRoZSAxMCBmcmFj dGlvbmFsIChiaW5hcnkpIGRpZ2l0cywgcGx1cyB0aGUgOSAoaW50ZWdlcg0KPiBwYXJ0KSBpbXBs aWVzIExhUmVzID0gTG9SZXMgPSAxOS4NCj4gDQo+IEl0IGlzIHRydWUgdGhhdCB0aGUgKG92ZXIg MyB0aW1lcykgZmluZXIgZ3JhaW4gb2YgYmluYXJ5IHJlc29sdXRpb24NCj4gaXMgbG9zdCBzb21l d2hhdCBpbiB0aGUgY29hcnNlciBncmFpbiBvZiBkZWNpbWFsIHJlc29sdXRpb24uDQo+IENlcnRh aW5seSwgbm90IGFsbCB0aGUgaW5mb3JtYXRpb24gaXMgbG9zdCwganVzdCBzbGlnaHRseSBsZXNz IHRoYW4NCj4gdHdvIGJpdHMgb2YgaW5mb3JtYXRpb24uDQo+IA0KPiA+IFdoYXQgZG9lcyB0aGUg aW5kaWNhdGVkIHBvaW50IG1lYW4/DQo+IA0KPiBHb29nbGVFYXJ0aCBjb252ZW5pZW50bHkgZGlz cGxheXMgZGVjaW1hbCBkZWdyZWVzLCBhbmQgZnJvbSB0aGUgbWFwLA0KPiB0aGlzIGFwcGVhcnMg dG8gYmUgdGhlIENvbXB1dGVyIFNjaWVuY2UgYnVpbGRpbmcgYXQgdGhlIFVuaXZlcnNpdHkgb2YN Cj4gV29sbG9uZ29uZy4NCj4gDQo+IFRvIHNlZSB0aGUgZXhwcmVzc2l2ZSBwb3dlciBvZiByZXNv bHV0aW9uLCBub3RpY2UgdGhlIGZld2VyDQo+IHNpZ25pZmljYW50IGRpZ2l0cyBpbiB0aGUgbG9j YXRpb24gKC0zNC40MDYsIDE1MC44OCkgb2YgdGhlIGVudGlyZQ0KPiBjYW1wdXMsIGFuZCAoLTM0 LjQwNjkxLCAxNTAuODgyOTkpIGZvciBhIGNvcm5lciBvZmZpY2UgaW4gdGhlIE5FIHdpbmcNCj4g b2YgdGhhdCBidWlsZGluZy4NCj4gDQo+IEpvaG4NCj4gDQo+ID4NCj4gPiAgICA8P3htbCB2ZXJz aW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Pg0KPiA+ICAgIDxwcmVzZW5jZSB4bWxucz0idXJu OmlldGY6cGFyYW1zOnhtbDpuczpwaWRmIg0KPiA+ICAgICB4bWxuczpncD0idXJuOmlldGY6cGFy YW1zOnhtbDpuczpwaWRmOmdlb3ByaXYxMCINCj4gPiAgICAgeG1sbnM6Y2w9InVybjppZXRmOnBh cmFtczp4bWw6bnM6cGlkZjpnZW9wcml2MTA6Y2l2aWNBZGRyIg0KPiA+ICAgICB4bWxuczpncz0i aHR0cDovL3d3dy5vcGVuZ2lzLm5ldC9waWRmbG8vMS4wIg0KPiA+ICAgICB4bWxuczpnbWw9Imh0 dHA6Ly93d3cub3Blbmdpcy5uZXQvZ21sIg0KPiA+ICAgICAgIGVudGl0eT0icHJlczpwb2ludDJk QGV4YW1wbGUuY29tIj4NCj4gPiAgICAgIDx0dXBsZSBpZD0ic2c4OWFiY2QiPg0KPiA+ICAgICAg ICA8c3RhdHVzPg0KPiA+ICAgICAgICAgIDxncDpnZW9wcml2Pg0KPiA+ICAgICAgICAgICAgPGdw OmxvY2F0aW9uLWluZm8+DQo+ID4gICAgICAgICAgICAgIDxnbWw6UG9pbnQgc3JzTmFtZT0idXJu Om9nYzpkZWY6Y3JzOkVQU0c6OjQzMjYiDQo+ID4gICAgICAgICAgICAgICAgICAgeG1sbnM6Z21s PSJodHRwOi8vd3d3Lm9wZW5naXMubmV0L2dtbCI+DQo+ID4gICAgICAgICAgICAgICAgPGdtbDpw b3M+LTM0LjQwNyAxNTAuODgzPC9nbWw6cG9zPg0KPiA+ICAgICAgICAgICAgICA8L2dtbDpQb2lu dD4NCj4gPiAgICAgICAgICAgIDwvZ3A6bG9jYXRpb24taW5mbz4NCj4gPiAgICAgICAgICAgIDxn cDp1c2FnZS1ydWxlcy8+DQo+ID4gICAgICAgICAgPC9ncDpnZW9wcml2Pg0KPiA+ICAgICAgICA8 L3N0YXR1cz4NCj4gPiAgICAgICAgPHRpbWVzdGFtcD4yMDA3LTA2LTIyVDIwOjU3OjI5WjwvdGlt ZXN0YW1wPg0KPiA+ICAgICAgPC90dXBsZT4NCj4gPiAgICA8L3ByZXNlbmNlPg0KPiA+DQo+ID4N Cj4gPiBEbyBJIHRvdGFsbHkgbWlzcyBzb21ldGhpbmcgaGVyZT8NCj4gPg0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRWNyaXQgbWFpbGlu ZyBsaXN0DQo+IEVjcml0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2Vjcml0DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQg bWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0 ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwu ICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ0K --===============1817611408== 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 --===============1817611408==-- From ecrit-bounces@ietf.org Mon Sep 24 00:44:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZflp-00057y-Qa; Mon, 24 Sep 2007 00:42:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZflo-00056v-Sx for ecrit@ietf.org; Mon, 24 Sep 2007 00:42:09 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZflh-0004Q5-6c for ecrit@ietf.org; Mon, 24 Sep 2007 00:42:01 -0400 X-SEF-Processed: 5_0_0_910__2007_09_23_23_51_37 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 23 Sep 2007 23:51:37 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 23 Sep 2007 23:42:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Ecrit] Phonebcp comments Date: Sun, 23 Sep 2007 23:41:57 -0500 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA05C3FFB2@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [Ecrit] Phonebcp comments Thread-Index: Acf7zHUL9yBuhs2YTH6p7WGmoc6f0wAl1EgQAIA7TLA= References: <7582BC68E4994F4ABF0BD4723975C3FA03B0F1F2@crexc41p><110201c7fb00$fe54a380$640fa8c0@cis.neustar.com><91D87B6E-657E-4738-AD7A-FDBAEEAFB69B@cisco.com><5FB585F183235B42A9E70095055136FB0555CC@DEMUEXC012.nsn-intra.net><7582BC68E4994F4ABF0BD4723975C3FA05A7FEB1@crexc41p><3EF5E9FA-07BF-4252-A609-70DAE72E978F@cisco.com> <7582BC68E4994F4ABF0BD4723975C3FA05C3FFB2@crexc41p> From: "Winterbottom, James" To: "Stark, Barbara" , "John Schnizlein" X-OriginalArrivalTime: 24 Sep 2007 04:42:00.0536 (UTC) FILETIME=[3EFE6580:01C7FE65] X-Spam-Score: 1.8 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "Tschofenig, Hannes \(NSN - DE/Germany - MiniMD\)" , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Barbara,=0D=0A=0D=0AThe appendix in RFC3825 shows how to use the resolut= ion to express an=0D=0Aarea, I strongly recommend that you do not use this = encoding to do this=0D=0Aas the results are totally unpredictable.=0D=0A=0D= =0ARegards=0D=0AJames=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: = Stark, Barbara [mailto:bs7652@att.com]=0D=0A> Sent: Saturday, 22 September = 2007 1:37 AM=0D=0A> To: John Schnizlein=0D=0A> Cc: Tschofenig,Hannes (NSN -= DE/Germany - MiniMD); ECRIT=0D=0A> Subject: RE: AW: [Ecrit] Phonebcp comme= nts=0D=0A>=20=0D=0A> John,=0D=0A> Thanks. I went back and really read throu= gh RFC 3825. I see that=0D=0Ayou're=0D=0A> quite right in that it explains = very clearly in the Appendix how to=0D=0A> apply the Res parameters to Lati= tude, Longitude, and Altitude. I think=0D=0A> that just left my question ab= out the Datum parameter. Should phonebcp=0D=0A> restrict this to WGS 84, or= should there be a recommended way to=0D=0Aexpress=0D=0A> Datum in a PIDF-L= O=3F Are there other conversion issues that need to be=0D=0A> addressed=3F=0D= =0A> Barbara=0D=0A>=20=0D=0A> -----Original Message-----=0D=0A> From: John = Schnizlein [mailto:jschnizl@cisco.com]=0D=0A> Sent: Thursday, September 20,= 2007 5:22 PM=0D=0A> To: Stark, Barbara=0D=0A> Cc: Tschofenig, Hannes (NSN = - DE/Germany - MiniMD); Brian Rosen; ECRIT=0D=0A> Subject: Re: AW: [Ecrit] = Phonebcp comments=0D=0A>=20=0D=0A> It seems perfectly clear to me that any = more significant digits in=0D=0A> the pidf-lo location values than there ar= e in the binary-lci values=0D=0A> are pseudo precision.=0D=0A>=20=0D=0A> Th= e rule would be the same as from High School chemistry class: don't=0D=0A> = show any more significant digits in the result of a calculation than=0D=0A>= were present in the measurements.=0D=0A>=20=0D=0A> John=0D=0A>=20=0D=0A> O= n Sep 20, 2007, at 4:25 PM, Stark, Barbara wrote:=0D=0A>=20=0D=0A> > It see= ms like there do need to be rules for what to do with the Res=0D=0A> > para= meters,=0D=0A>=20=0D=0A> *****=0D=0A>=20=0D=0A> The information transmitted= is intended only for the person or entity=0D=0Ato=0D=0A> which it is addre= ssed and may contain confidential, proprietary,=0D=0Aand/or=0D=0A> privileg= ed material. Any review, retransmission, dissemination or=0D=0Aother=0D=0A>= use of, or taking of any action in reliance upon this information by=0D=0A= > persons or entities other than the intended recipient is prohibited.=0D=0A= If=0D=0A> you received this in error, please contact the sender and delete = the=0D=0A> material from all computers. GA625=0D=0A>=20=0D=0A>=20=0D=0A> =0D= =0A> _______________________________________________=0D=0A> Ecrit mailing l= ist=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/ecr= it=0D=0A=0D=0A-------------------------------------------------------------= -----------------------------------=0D=0AThis message is for the designated= recipient only and may=0D=0Acontain privileged, proprietary, or otherwise = private information. =20=0D=0AIf you have received it in error, please noti= fy the sender=0D=0Aimmediately and delete the original. Any unauthorized u= se of=0D=0Athis email is prohibited.=0D=0A---------------------------------= ---------------------------------------------------------------=0D=0A[mf2]=0D= =0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 24 00:59:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZg1U-00037C-0U; Mon, 24 Sep 2007 00:58:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZg1S-000377-ED for ecrit@ietf.org; Mon, 24 Sep 2007 00:58:18 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZg1R-0004hl-4x for ecrit@ietf.org; Mon, 24 Sep 2007 00:58:18 -0400 X-SEF-Processed: 5_0_0_910__2007_09_24_00_07_53 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 24 Sep 2007 00:07:52 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 23 Sep 2007 23:58:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Some documents from DSL Forum Date: Sun, 23 Sep 2007 23:58:14 -0500 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA05A7F8D3@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Some documents from DSL Forum Thread-Index: Acf6IDeVK8AoS8hKQh+2kTyqd6BGCgAAJbEAARApB/A= References: <7582BC68E4994F4ABF0BD4723975C3FA05A7F886@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA05A7F8D3@crexc41p> From: "Dawson, Martin" To: "Stark, Barbara" , X-OriginalArrivalTime: 24 Sep 2007 04:58:15.0783 (UTC) FILETIME=[84494770:01C7FE67] X-Spam-Score: 0.0 (/) X-Scan-Signature: 717d651095a319b49fc3b6c7b72cb4dd Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0239761828==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0239761828== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FE67.83EF3CFE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FE67.83EF3CFE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Barbara,=0D=0A=0D=0A=20=0D=0A=0D=0AApologies for the delay - I just got = the time to take a look. I've been=0D=0Athrough the responses so far and I = haven't seen anything that makes my=0D=0Afollowing observations redundant.=0D= =0A=0D=0A=20=0D=0A=0D=0AMy general comment is that this document implies bu= t perhaps fails to=0D=0Aexplicitly highlight the difference between the lin= k layer and the=0D=0Aso-called L7 approach.=0D=0A=0D=0A=20=0D=0A=0D=0AFigur= e 2 implies, as does the rest of the text I think, that it is the=0D=0Aresi= dential gateway that obtains location information from the=0D=0Aaccess/ISP.= The power of the L7 approach is that the VoIP client can do=0D=0Athis dire= ctly without any dependency on the rest of the CPE. The=0D=0Aintroductory t= ext says "The client-side behavior is expected to be=0D=0Aincluded in all S= IP endpoints, *and* residential gateways (RG), *and*=0D=0Aother home router= s." (emphasis mine). HELD only requires the SIP=0D=0Aendpoint to support th= e client-side capabilities. Assuming the network=0D=0Aalso supports the rec= ommended discovery mechanisms, it isn't even=0D=0Anecessary for the DHCP se= rver to support the LIS address option. While=0D=0Ahaving all devices in th= e residential LAN support the client-side=0D=0Aprotocols is a worthy goal, = I think it would be good for the text to=0D=0Ahighlight that this isn't nec= essary for direct SIP-Client to HELD LIS=0D=0Ainteraction; currently I thin= k it implies that things won't work unless=0D=0Aevery device supports the c= lient-side protocol.=0D=0A=0D=0A=20=0D=0A=0D=0AWith respect to the use of L= LDP-MED and DHCP, there also seems to be an=0D=0Aimplication that the locat= ion information delivered by these methods may=0D=0Ahave been obtained from= the access network by the RG. However, the only=0D=0Aprotocol that I think= could support this is HELD. Again, if the RG is=0D=0Ausing HELD to get thi= s information, then the SIP client should be able=0D=0Ato get it directly w= ithout dependency on the RG. Perhaps the meaning of=0D=0A"client-side behav= ior" needs to be spelt out - particularly in terms of=0D=0Awhat it means fo= r the RG and other home routers. I agree that where the=0D=0Aaccess network= does not support a LIS function, then the RG needs to=0D=0Asupport manual = configuration regardless of whether it's LLDP-MED, DHCP,=0D=0Aor HELD that = the SIP client uses - however, that is "server-side"=0D=0Abehavior.=0D=0A=0D= =0A=20=0D=0A=0D=0AWith respect to the location selection flow chart, has an= y consideration=0D=0Abeen given to the "mobile LAN" scenario that has been = raised a few=0D=0Atimes=3F Perhaps this is written purely from the perspect= ive that DSL=0D=0Aendpoints are not mobile, so this is not an issue=3F It w= ould mean that=0D=0Areliance on a piece of static location data in a link l= ayer device may=0D=0Abe incorrect if the other side of the LAN gateway is a= ctually connected=0D=0Ato a mobile network. DSL, by definition, isn't a mob= ile network but, on=0D=0Athe other hand, if the SIP clients are encoded wit= h this algorithm they=0D=0Amay fail to take advantage of a mobile network L= IS when they do move=0D=0Afrom their DSL attachment to that scenario.=0D=0A=0D= =0A=20=0D=0A=0D=0AI raise the same concern with respect to "GPS" that Hanne= s mentioned.=0D=0AThat is, there are security issues to do with purely targ= et-device=0D=0Agenerated and provided location. This is what location signi= ng is=0D=0Aintended to address. There is growing awareness of this issue (n= ot just=0D=0Alimited to network location - see reference and text below) an= d it may=0D=0Abe a poor strategy on the part of the DSL forum to start from= a baseline=0D=0Athat ignores this problem. For example, getting location f= rom an access=0D=0Aprovider LIS as the priority would ensure that signed lo= cation is=0D=0Aacquired when it is available. In the future, when location-= assertion is=0D=0Aavailable, there will be the option of using the device-a= cquired=0D=0Alocation and still having it signed by a recognized operator. = The other=0D=0Aissue is that, presumably, the format of location provided b= y the DSL=0D=0Anetwork would be civic whereas GPS is going to be geodetic. = While I'm=0D=0Anot sure that there has been any strict policy established w= ith respect=0D=0Ato this, I'd expect that emergency responders would prefer= the civic=0D=0Aform.=0D=0A=0D=0A=20=0D=0A=0D=0AFinally, if the scope is ac= tually restricted to residential mass market=0D=0ACPE, is LLDP-MED actually= a pertinent technology in any case or is it=0D=0Areally an enterprise tech= nology=3F I've also heard 3825 characterized as=0D=0Aenterprise (switched n= etwork LAN) technology.=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D= =0A=0D=0A=20=0D=0A=0D=0Ahttp://sidt.gpsworld.com/gpssidt/article/articleDet= ail.jsp=3Fid=3D436920=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0AThe growing = use of GPS in civil security and monitoring applications=0D=0Abrings with i= t a vulnerability to criminal enterprises suborning GPS for=0D=0Afinancial = gain. For example, asset tracking, identified as the=0D=0Asecond-fastest gr= owing GNSS market segment after mapping, uses=0D=0Ageofencing to raise the = alarm when an asset is not where it is supposed=0D=0Ato be. Geofences can b= e time-dependent and dynamic, so cargo in transit=0D=0Acan be monitored as = well. The successful theft of an intermodal shipping=0D=0Acontainer could p= rovide ample incentive to develop a GPS signal spoofer=0D=0Ato cover crimin= al activity.=0D=0A=0D=0AThe 2001 Volpe Report, Vulnerability Assessment of = the Transportation=0D=0AInfrastructure Relying on GPS, states that "The DOT= should coordinate=0D=0Awith the DoD to ensure that appropriate anti-spoofi= ng technologies are=0D=0Aavailable to civilian applications, should the nee= d arise. It is=0D=0Aimportant to identify observables that may indicate spo= ofing in civil=0D=0Asafety-critical receivers. In addition, DOT should deve= lop independent=0D=0Ainformation to determine the validity and extent of po= ssible civil=0D=0Aspoofing threats."=0D=0A=0D=0AOther examples of illicit g= ain that may encourage spoofing include:=0D=0A=0D=0A*=09the highly regulate= d fisheries industry, where an onboard vessel=0D=0Amonitoring system (VMS) = reports positions in real-time to monitor=0D=0Acompliance with regulations= =2E If a fishing vessel can cover its true=0D=0Aactivity for 30 minutes, it= might land an additional $60,000 worth of=0D=0Afish, crabs, or shrimp.=20=0D= =0A*=09illegal dumping of trash and other hazardous materials,=0D=0Aestimat= ed as a $10-$12 billion industry.=20=0D=0A*=09theft of private data records= =2E More than 150 million records=0D=0Ahave been lost or stolen in the last= 40 months, potentially enabling=0D=0Aidentity theft, credit card fraud, vo= ting fraud, and other exploits.=0D=0AGeo-encryption techniques relying on G= PS can restrict access to=0D=0Aplaintext data based on location, time, and = key access. My own Geocodex=0D=0ALLC is currently commercializing this tech= nology with extensive=0D=0Aanti-spoofing design elements.=20=0D=0A=0D=0AAs = these examples show, there are strong motivations to compromise GPS=0D=0Alo= cation integrity. We have clear financial and ethical reasons to=0D=0Apreve= nt this from happening by securing the location determination=0D=0Aprocess,= in what I call location assurance. In this essay, I describe=0D=0Awhat is= involved in developing an effective spoofer given current "open=0D=0Adoor"= civil signal architectures and show how civil vulnerabilities=0D=0Adiffer = greatly from military vulnerabilities. The Internet and=0D=0Asoftware-defin= ed radio (SDR) architectures play a major role in=0D=0Aadvancing the civil = spoofing threat. Finally, I will look at prospects=0D=0Afor hardening GPS, = Galileo, and Loran signals against spoofing attacks.=0D=0ANavigation signal= s can be hardened and it is not all that difficult -=0D=0Abut it will take = an act of national will to do so.=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A= =20=0D=0A=0D=0A________________________________=0D=0A=0D=0AFrom: Stark, Bar= bara [mailto:bs7652@att.com]=20=0D=0ASent: Wednesday, 19 September 2007 5:0= 4 AM=0D=0ATo: peter_blatherwick@mitel.com=0D=0ACc: ECRIT=0D=0ASubject: RE: = [Ecrit] Some documents from DSL Forum=0D=0A=0D=0A=20=0D=0A=0D=0AThanks agai= n for the LLDP-MED info. I'll feed it to the developer-types,=0D=0Aand see = what they think.=0D=0A=0D=0AI agree the DHCP failure scenario can be filled= out a bit better. I'll=0D=0Ahave to break my charts apart, but that's ok. = If there's no DHCP=0D=0Aresponse after the standard DHCP time-out, most dev= ices do one of 3=0D=0Athings: assign themselves 0.0.0.0 and give up trying = to talk externally;=0D=0Ado IP auto addressing, see if there's anything to = talk to, and then give=0D=0Aup trying to talk externally; or have a static = assignment to try (my=0D=0Alaptop does this, since we have static in the of= fice and DHCP in all=0D=0Aother places). With a static assignment, it makes= sense to go to the=0D=0A"No" path of "Is DHCP used for IP address config=3F= ". I suppose on the off=0D=0Achance that auto addressing succeeded in findi= ng something else=0D=0A(extremely low probability), that it might also try = that path. I=0D=0Awouldn't give it much chance of succeeding.=0D=0A=0D=0ABa= rbara=0D=0A=0D=0A=20=0D=0A=0D=0A________________________________=0D=0A=0D=0A= From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20=0D= =0ASent: Tuesday, September 18, 2007 2:17 PM=0D=0ATo: Stark, Barbara=0D=0AC= c: Romascanu, Dan (Dan); ECRIT; Cullen Jennings; Hannes Tschofenig=0D=0ASub= ject: RE: [Ecrit] Some documents from DSL Forum=0D=0A=0D=0A=0D=0AHi again B= arbara,=20=0D=0ATrying to answer some of your questions back, please see [P= B] inline=0D=0Abelow.=20=0D=0A-- Peter=20=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=20=0D= =0A=0D=0A"Stark, Barbara" =20=0D=0A=0D=0A18.09.07 13:26=20=0D= =0A=0D=0A =20=0D=0A To: , = "ECRIT"=0D=0A=20=0D=0A cc: "Cullen Jennings" = , "Hannes=0D=0ATschofenig" , "= Romascanu, Dan (Dan)"=0D=0A=20=0D=0A Subject: = RE: [Ecrit] Some documents from DSL Forum=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= Thanks for all the really useful input on LLDP and LLDP-MED. I'll be=0D=0Ar= eflecting this in my next update.=20=0D=0AI need to better understand the i= mplications of a client running=0D=0ALLDP-MED, separate from the underlying= OS. I would need for the client=0D=0Ato know whether or not the OS provide= d that function, before it tried.=0D=0AIf one client started doing it, then= all the clients might decide they=0D=0Awanted to do it, too, and it might = just get out of hand.=20=0D=0A=0D=0A[PB] I agree there are potential issues= if multiple applications in a=0D=0Asingle Endpoint device all decided to s= tart LLDP-MED. (You are=0D=0Areferring to these applications as "clients" = I believe=3F=3F) Potentially,=0D=0Athe first of those would get immediate = response, but others would not=0D=0Asee -MED coming back until the next nor= mal advertising cycle. Hence, OS=0D=0Asupport would be a good thing. I do= not see this as a big issue though,=0D=0Asince location would only be out = of date for a max of the advertising=0D=0Ainterval (30 sec default), and wo= uld be correct thereafter. A bit more=0D=0Aserious would be the implicatio= n on the Network Connectivity Device=0D=0Aside, where it would potentially = be receiving multiple sets of=0D=0Aadvertisements. Not only would there be= more traffic (a non-issue in=0D=0Apractice, since it is constrained to the= link), but if each app was=0D=0Aadvertising different TLVs then the info f= rom one could continually get=0D=0Aoverridden with info from the other(s). = I would expect multiple apps=0D=0Aall wanting to use LLDP-MED in a single = device to be rare though, at=0D=0Aleast at this point. =20=0D=0A=0D=0ATher= e is a "known gap" on the DHCP INFORM timer, but not the standard=0D=0ADHCP= request. My logic there was that if a device is configured to do=0D=0ADHCP= for bootstrap, then it will be completely unable to do anything at=0D=0Aa = higher layer (including make an emergency call), until it gets a=0D=0Arespo= nse. I have yet to find a mass market home network setup where auto=0D=0Aad= dressing works to get network connectivity, after DHCP failed. There's=0D=0A= usually a 60 second timer to try to get a response to DHCP DISCOVERY,=0D=0A= after which the device gives up. It may periodically try DHCP again, but=0D= =0Athat's outside the scope of this document. I should probably try to fit=0D= =0Athis failure into my chart, but I ran out of room.=20=0D=0A =20=0D=0A[PB= ] Yup, this makes sense now. Yeah, the chart is pretty convoluted=0D=0Aand= hard to fit anything else into, but still think it would be good to=0D=0Ai= nclude "No" paths from the "Was successful" decisions to the=0D=0A= appropriate handling (which is LIS determination I would think). =20=0D=0A=0D= =0AAs to Hannes request for help from the DSLF, I'm happy to help in any=0D= =0Away I can. I'll make sure they get any questions you need for them to=0D= =0Aanswer. Of course, I'm editor of this document, and am tracking all your=0D= =0Acomments on this list. I'll do my best to be responsive, where I can=0D=0A= answer questions directly. I really would like to see as much as=0D=0Apossi= ble be in phonebcp, and simply reference it. I have no intention of=0D=0Abe= ing redundant, or of going against the recommendations in phonebcp.=20=0D=0A= Barbara=20=0D=0A =20=0D=0A=0D=0A________________________________=0D=0A=0D=0A= From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20=0D= =0ASent: Tuesday, September 18, 2007 12:11 PM=0D=0ATo: ECRIT=0D=0ACc: Culle= n Jennings; Hannes Tschofenig; Romascanu, Dan (Dan);=0D=0Abarbara.stark@att= =2Ecom=0D=0ASubject: RE: [Ecrit] Some documents from DSL Forum=0D=0A=0D=0A=0D= =0AHi, (adding also Barbara Stark, Ed of the DSL document),=20=0D=0A=0D=0AI= also had a go tat the DSL Forum document -- looks pretty good overall.=0D=0A= Also noted the "Known Gaps". =20=0D=0A=0D=0A> Need to understand how long = a device would need to wait for=20=0D=0A> LLDP-MED and DHCP INFORM response= s, in networks that don't=20=0D=0A> support responses to these protocols.=0D= =0A=0D=0AAdding some important details to Dan's... =20=0D=0AIn LLDP-MED,= a "Fast Start" procedure is used at startup (not present in=0D=0Abasic LLD= P). In Fast Start. the Endpoint side initiates by transmitting=0D=0Aa bust= of -MED frames. By default, 4 frames are sent at 1 sec interval.=0D=0ABef= ore that time, the Network Connectivity side (ie the upstream L2=0D=0Aswitc= h) is only transmitting basic LLDP (not -MED extensions). In=0D=0Aresponse= to seeing that first -MED frame come in, the Network=0D=0AConnectivity dev= ice then immediately begins transmitting -MED frames=0D=0Aback, again start= ing with a burst of 4 frames at 1 sec interval by=0D=0Adefault. So, as a r= esult the Endpoint will learn its location (from the=0D=0ALocation Identifi= cation TLVs) almost immediately at startup. In my=0D=0Aexperience, this is= typically measurable in handfuls of ms, certainly=0D=0Awell under 1 sec, u= nless there is frame loss (very rare in practice).=0D=0AThe whole Fast Star= t procedure takes 4 sec max, so that would make a=0D=0Agood "didn't work" t= hreshold. =20=0D=0A=0D=0ANote also that after startup phase, basic LLDP (a= nd -MED by extension)=0D=0Awill continue to advertise periodically at 30 se= c interval by default=0D=0A(not 5 sec as Dan suggests). Also, due to basic= LLDP behaviour, if any=0D=0ATLV information changes the change is immediat= ely advertised, so if=0D=0Athere is a change of location the Endpoint gets = informed right away.=0D=0AThus, the location will always stay up to date af= ter that point, with a=0D=0Amaximum window of 30 sec. =20=0D=0A=0D=0AIn = the DSL document, the sequence flows in Appendix A look basically=0D=0Acorr= ect, the sequence of events looks good. However a better value for=0D=0A"W= as LLDP-MED successful" would be 4 sec. Also, I do not see a "was it=0D=0A= successful" decision for DHCP ("was location in DHCP response" only has=0D=0A= a Yes result, and no timeout associated) -- probably helpful to add=0D=0Ath= at. =20=0D=0A=0D=0ANoting this stuff would also be helpful in the Phone BC= P I think.=0D=0A(Brian already said he would do so.) =20=0D=0A=0D=0AI am n= ot deep on the DHCP part of the question, so perhaps someone else=0D=0Acan = provide some details there. However, I don't *think* there is any=0D=0Aexp= licit threshold "didn't work" timer we could count on (could well be=0D=0Aw= rong on that). In my experience, DHCP process takes longer than=0D=0ALLDP-= MED. =20=0D=0A=0D=0A> Need requirements for soft client on a PC or PDA. Th= ese applications=20=0D=0A> will not have the ability to control LLDP or DHC= P options, but=20=0D=0A> should be able to read them, if the underlying OS = has requested=20=0D=0A> these options.=20=0D=0A=0D=0AActually, LLDP / LLDP-= MED does not necessarily need OS or driver support=0D=0Asince it is defined= above the MAC layer, though it would be nice of=0D=0Acourse. PC / PDA app= s could build in the LLDP-MED capability directly.=0D=0A(Again, unclear on = the DHCP part of this question.) =20=0D=0A=0D=0ACheers,=20=0D=0APeter Blat= herwick (with Editor of LLDP-MED hat on)=20=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A =0D= =0A=0D=0A"Romascanu, Dan (Dan)" =20=0D=0A=0D=0A17.09.07= 13:45=20=0D=0A=0D=0A =20=0D=0A To: "Cullen Jennings" , "Hannes=0D=0ATschofenig" =20=0D= =0A cc: ECRIT =20=0D=0A Subject: = RE: [Ecrit] Some documents from DSL Forum=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= LLDP has a periodic 'slow protocol' announcement timer which is=0D=0Ainheri= ted by LLDP-MED. Its default is at 5 seconds if I am not mistaken.=0D=0AA d= evice is supposed to respond much faster (layer 2 single link=0D=0Aprotocol= ) so this timer can be used as a default worst case when facing=0D=0Anon-r= esponsive devices. =20=0D=0A=0D=0ADan=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A> = -----Original Message-----=0D=0A> From: Cullen Jennings [mailto:fluffy@cisc= o.com]=20=0D=0A> Sent: Monday, September 17, 2007 6:40 PM=0D=0A> To: Hannes= Tschofenig=0D=0A> Cc: ECRIT=0D=0A> Subject: Re: [Ecrit] Some documents fro= m DSL Forum=0D=0A>=20=0D=0A>=20=0D=0A> Sounds good. One thing that caught m= y attentions was in the=20=0D=0A> gaps it mentions=0D=0A>=20=0D=0A> Need to= understand how long a device would need to wait for=20=0D=0A> LLDP-MED and= DHCP INFORM responses, in networks that don't=20=0D=0A> support responses = to these protocols.=0D=0A>=20=0D=0A> Any advice we can give on that=3F Woul= d phonebcp be a=20=0D=0A> reasonable place to address that=3F=0D=0A>=20=0D=0A= >=20=0D=0A> On Sep 15, 2007, at 12:57 PM, Hannes Tschofenig wrote:=0D=0A> =0D= =0A> > Hi Cullen,=0D=0A> > Hi all,=0D=0A> >=0D=0A> > I read through the doc= uments.=0D=0A> >=0D=0A> > The text in the document can be classified into t= hree types of=0D=0A> > feedback:=0D=0A> >=0D=0A> > -- Protocol specific req= uirements=0D=0A> > These are aspects that could be captured in the Phone BC= P or are=20=0D=0A> > already found in the protocol specific documents itsel= f.=0D=0A> > I believe we have covered already most of these aspects=20=0D=0A= > (but we should=20=0D=0A> > double-check it).=0D=0A> >=0D=0A> > -- Impleme= ntation-specific aspects=0D=0A> > I am not sure how well we can capture the= se aspects in our=20=0D=0A> documents.=20=0D=0A> > Still, they are fine wit= h me.=0D=0A> >=0D=0A> > -- Interactions between different protocols and tim= ing.=0D=0A> > There are a couple of timing aspects and protocol sequences =0D= =0A> (e.g., for=20=0D=0A> > retrieving location information). I am not so s= ure about these=20=0D=0A> > aspects. Is the timing reasonable=3F Is the seq= uence of retrieving=20=0D=0A> > location information reasonable and generic= enough=3F=0D=0A> >=0D=0A> > I think that the provided documents sound pret= ty reasonable to me. =20=0D=0A> > We need to figure out what aspects are no= t yet covered in our=20=0D=0A> > documents and then we should try to incorp= orate them. We need to=20=0D=0A> > discuss them obviously.=0D=0A> >=0D=0A> = > Help from members of the DSL forum would be useful.=0D=0A> >=0D=0A> > Cia= o=0D=0A> > Hannes=0D=0A>=20=0D=0A> ________________________________________= _______=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www1= =2Eietf.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A=0D=0A___________________= ____________________________=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D= =0Ahttps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A*****=20=0D=0A=0D= =0AThe information transmitted is intended only for the person or entity to=0D= =0Awhich it is addressed and may contain confidential, proprietary, and/or=0D= =0Aprivileged material. Any review, retransmission, dissemination or other=0D= =0Ause of, or taking of any action in reliance upon this information by=0D=0A= persons or entities other than the intended recipient is prohibited. If=0D=0A= you received this in error, please contact the sender and delete the=0D=0Am= aterial from all computers. GA625=20=0D=0A=0D=0A*****=0D=0A=0D=0AThe inform= ation transmitted is intended only for the person or entity to=0D=0Awhich i= t is addressed and may contain confidential, proprietary, and/or=0D=0Aprivi= leged material. Any review, retransmission, dissemination or other=0D=0Ause= of, or taking of any action in reliance upon this information by=0D=0Apers= ons or entities other than the intended recipient is prohibited. If=0D=0Ayo= u received this in error, please contact the sender and delete the=0D=0Amat= erial from all computers. GA625=0D=0A=0D=0A--------------------------------= ----------------------------------------------------------------=0D=0AThis = message is for the designated recipient only and may=0D=0Acontain privilege= d, proprietary, or otherwise private information. =20=0D=0AIf you have rece= ived it in error, please notify the sender=0D=0Aimmediately and delete the = original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A----= ---------------------------------------------------------------------------= -----------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C7FE67.83EF3CFE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A

Hi Barbara,

=0D=0A=0D= =0A

 =

=0D=0A=0D=0A

Apologies for the delay – I just got=0D=0Athe time to take = a look. I’ve been through the responses so far and I=0D=0Ahaven’= ;t seen anything that makes my following observations redundant.=

=0D=0A=0D=0A

 

=0D=0A=0D=0A

My general comment is that this docume= nt implies=0D=0Abut perhaps fails to explicitly highlight the difference be= tween the link layer=0D=0Aand the so-called L7 approach.<= /font>

=0D=0A=0D=0A

 

=0D=0A=0D=0A

Figure 2 implies, as does the rest of the=0D=0A= text I think, that it is the residential gateway that obtains location=0D=0A= information from the access/ISP. The power of the L7 approach is that the V= oIP=0D=0Aclient can do this directly without any dependency on the rest of = the CPE. The=0D=0Aintroductory text says “The client-side behavior is= expected to be=0D=0Aincluded in all SIP endpoints, *and*=0D=0Aresidential gateways (RG), *and*=0D=0Aother home routers.” (em= phasis mine). HELD only requires the SIP endpoint=0D=0Ato support the clien= t-side capabilities. Assuming the network also supports the=0D=0Arecommende= d discovery mechanisms, it isn’t even necessary for the DHCP=0D=0Aser= ver to support the LIS address option. While having all devices in the=0D=0A= residential LAN support the client-side protocols is a worthy goal, I think= it=0D=0Awould be good for the text to highlight that this isn’t nece= ssary for=0D=0Adirect SIP-Client to HELD LIS interaction; currently I think= it implies that=0D=0Athings won’t work unless every device supports = the client-side protocol.

=0D=0A=0D=0A

 =

=0D=0A=0D=0A

With= respect to the use of LLDP-MED and=0D=0ADHCP, there also seems to be an im= plication that the location information=0D=0Adelivered by these methods may= have been obtained from the access network by=0D=0Athe RG. However, the on= ly protocol that I think could support this is HELD. Again,=0D=0Aif the RG = is using HELD to get this information, then the SIP client should be=0D=0Aa= ble to get it directly without dependency on the RG. Perhaps the meaning of= “client-side=0D=0Abehavior” needs to be spelt out – part= icularly in terms of what it=0D=0Ameans for the RG and other home routers. = I agree that where the access network=0D=0Adoes not support a LIS function,= then the RG needs to support manual=0D=0Aconfiguration regardless of wheth= er it’s LLDP-MED, DHCP, or HELD that the=0D=0ASIP client uses –= however, that is “server-side” behavior.

=0D=0A=0D=0A

<= o:p> 

=0D=0A=0D=0A

With respect to the location selection=0D=0Aflow = chart, has any consideration been given to the “mobile LAN”=0D=0A= scenario that has been raised a few times=3F Perhaps this is written purely= from=0D=0Athe perspective that DSL endpoints are not mobile, so this is no= t an issue=3F It=0D=0Awould mean that reliance on a piece of static locatio= n data in a link layer=0D=0Adevice may be incorrect if the other side of th= e LAN gateway is actually=0D=0Aconnected to a mobile network. DSL, by defin= ition, isn’t a mobile network=0D=0Abut, on the other hand, if the SIP= clients are encoded with this algorithm they=0D=0Amay fail to take advanta= ge of a mobile network LIS when they do move from their=0D=0ADSL attachment= to that scenario.

=0D=0A=0D=0A

 

=0D= =0A=0D=0A

I raise the= same concern with respect to “GPS”=0D=0Athat Hannes mentioned.= That is, there are security issues to do with purely=0D=0Atarget-device ge= nerated and provided location. This is what location signing is=0D=0Aintend= ed to address. There is growing awareness of this issue (not just limited=0D= =0Ato network location - see reference and text below) and it may be a poor=0D= =0Astrategy on the part of the DSL forum to start from a baseline that igno= res=0D=0Athis problem. For example, getting location from an access provide= r LIS as the=0D=0Apriority would ensure that signed location is acquired wh= en it is available. In=0D=0Athe future, when location-assertion is availabl= e, there will be the option of=0D=0Ausing the device-acquired location and = still having it signed by a recognized=0D=0Aoperator. The other issue is th= at, presumably, the format of location provided=0D=0Aby the DSL network wou= ld be civic whereas GPS is going to be geodetic. While I’m=0D=0Anot s= ure that there has been any strict policy established with respect to=0D=0A= this, I’d expect that emergency responders would prefer the civic for= m.

=0D=0A=0D=0A

 

=0D=0A=0D=0A

Finally, if the scope is ac= tually=0D=0Arestricted to residential mass market CPE, is LLDP-MED actually= a pertinent=0D=0Atechnology in any case or is it really an enterprise tech= nology=3F I’ve=0D=0Aalso heard 3825 characterized as enterprise (swit= ched network LAN) technology.

=0D=0A=0D=0A

 <= /font>

=0D=0A=0D=0A

Cheers,

=0D=0A=0D=0A

Martin

=0D=0A=0D=0A=

 

=0D=0A=0D=0A

http://sid= t.gpsworld.com/gpssidt/article/articleDetail.jsp=3Fid=3D436920

=0D=0A=0D=0A

 

=0D=0A=0D= =0A

 

=0D=0A=0D=0A

The growing use=0D=0Aof G= PS in civil security and monitoring applications brings with it a=0D=0Avuln= erability to criminal enterprises suborning GPS for financial gain. For=0D=0A= example, asset tracking, identified as the second-fastest growing GNSS mark= et=0D=0Asegment after mapping, uses geofencing to raise the alarm when an a= sset is not=0D=0Awhere it is supposed to be. Geofences can be time-dependen= t and dynamic, so=0D=0Acargo in transit can be monitored as well. The succe= ssful theft of an=0D=0Aintermodal shipping container could provide ample in= centive to develop a GPS=0D=0Asignal spoofer to cover criminal activity.

=0D=0A=0D=0A

The 200= 1 Volpe Report, Vulnerability=0D=0AAs= sessment of the Transportation Infrastructure Relying on GPS, states=0D=0Athat “The DOT should coordinate with the DoD to ensure= that appropriate=0D=0Aanti-spoofing technologies are available to civilian= applications, should the=0D=0Aneed arise. It is important to identify obse= rvables that may indicate spoofing=0D=0Ain civil safety-critical receivers.= In addition, DOT should develop independent=0D=0Ainformation to determine = the validity and extent of possible civil spoofing=0D=0Athreats.”

=0D=0A=0D=0A

Other examples of il= licit gain that may encourage spoofing include:

=0D=0A=0D= =0A
    =0D=0A
  • the highly=0D= =0A regulated fisheries industry, where an onboard vessel monitoring sy= stem=0D=0A (VMS) reports positions in real-time  to monitor compli= ance with=0D=0A regulations. If a fishing vessel can cover its true act= ivity for 30=0D=0A minutes, it might land an additional $60,000 worth o= f fish, crabs, or=0D=0A shrimp.
    • =0D=0A
  • illegal=0D=0A dumping of trash and other hazardous materials, e= stimated as a=0D=0A $10–$12 billion industry.
    • =0D=0A
  • theft of=0D=0A private data records. More = than 150 million records have been lost or=0D=0A stolen in the last 40 = months, potentially enabling identity theft, credit=0D=0A card fraud, v= oting fraud, and other exploits. Geo-encryption techniques=0D=0A relyin= g on GPS can restrict access to plaintext data based on location,=0D=0A = time, and key access. My own Geocodex LLC is currently commercializing=0D=0A= this technology with extensive anti-spoofing design elements. <= /font>
    • =0D=0A
=0D=0A=0D=0A

As these exampl= es show, there are strong motivations to compromise=0D=0AGPS location integ= rity. We have clear financial and ethical reasons to prevent=0D=0Athis from= happening by securing the location determination process, in what I=0D=0Ac= all location assurance.  In this essay, I describe what is involved in=0D= =0Adeveloping an effective spoofer given current “open door” ci= vil=0D=0Asignal architectures and show how civil vulnerabilities differ gre= atly from=0D=0Amilitary vulnerabilities. The Internet and software-defined = radio (SDR)=0D=0Aarchitectures play a major role in advancing the civil spo= ofing threat. Finally,=0D=0AI will look at prospects for hardening GPS, Gal= ileo, and Loran signals against=0D=0Aspoofing attacks. Navigation signals c= an be hardened and it is not all that=0D=0Adifficult — but it will ta= ke an act of national will to do so.=

=0D=0A=0D=0A

 

=0D=0A=0D=0A

<= o:p> 

=0D=0A=0D=0A

 

=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A

From:=0D=0AStark, Barbara [mailto:bs7652@att.com]
=0D=0A= Sent: Wednesday, 19 Septembe= r 2007=0D=0A5:04 AM
=0D=0ATo:= peter_blatherwick@mitel.com
=0D=0ACc: ECRIT
=0D=0ASubjec= t: RE: [Ecrit] Some=0D=0Adocuments from DSL Forum<= span lang=3DEN-US>

=0D=0A=0D=0A
=0D=0A=0D=0A

 

=0D=0A=0D=0A

Thanks again for the LLDP-ME= D info. I'll=0D=0Afeed it to the developer-types, and see what they think.<= /span>

=0D=0A=0D=0A

I agree the DHCP failure scenario can be=0D=0Afilled ou= t a bit better. I'll have to break my charts apart, but that's ok. If=0D=0A= there's no DHCP response after the standard DHCP time-out, most devices do = one=0D=0Aof 3 things: assign themselves 0.0.0.0 and give up trying to talk = externally;=0D=0Ado IP auto addressing, see if there's anything to talk to,= and then give up=0D=0Atrying to talk externally; or have a static assignme= nt to try (my laptop does=0D=0Athis, since we have static in the office and= DHCP in all other places). With a=0D=0Astatic assignment, it makes sense t= o go to the "No" path of "Is DHCP used for IP address config=3F". I suppose on the of= f chance that auto addressing succeeded=0D=0Ain finding something else (ext= remely low probability), that it might also try=0D=0Athat path. I wouldn't = give it much chance of succeeding.

=0D=0A=0D=0A=

Barbara=

=0D=0A=0D=0A

 

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A

From:=0D=0Apeter_b= latherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
=0D=0ASent: Tuesday, September 18, 2007=0D= =0A2:17 PM
=0D=0ATo: Star= k, Barbara
=0D=0ACc: Roma= scanu, Dan (Dan); ECRIT;=0D=0ACullen Jennings; Hannes Tschofenig
=0D=0A<= b>Subject: RE: [Ecrit] Some=0D=0A= documents from DSL Forum=

=0D=0A=0D=0A


=0D= =0AHi again Barbara,
=0D= =0ATrying=0D=0Ato answer some of your questions back, please = see [PB] inline below.
=0D=0A--=0D=0APeter<= /span>
=0D=0A
=0D=0A
=0D=0A

=0D=0A=0D=0A=0D=0A =0D=0A =0D=0A

 

=0D=0A =0D=0A =0D=0A

"Stark, Barbara"=0D=0A <bs7652@att.com&g= t;

=0D=0A

18.09.0= 7 13:26

=0D=0A =0D=0A =0D=0A

       
=0D=0A &= nbsp;=0D=0A       To:        <peter_= blatherwick@mitel.com>,=0D=0A "ECRIT" <ecrit@ietf.org><= /span>
=0D=0A  =0D=0A       c= c:        "Cullen=0D=0A Jennings" <fluffy= @cisco.com>, "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net= >,=0D=0A "Romascanu, Dan (Dan)" <dromasca@avaya.com>
=0D=0A  =0D=0A       Sub= ject:        RE: [Ecrit] Some=0D=0A documents from DSL= Forum

=0D=0A =0D=0A =0D=0A=0D= =0A=0D=0A


=0D=0A
=0D= =0A
=0D=0AThanks for all= the really useful input on LLDP=0D=0Aand LLDP-MED. I'll be reflecting this= in my next update.
=0D=0AI need to better understand the implications of a client=0D=0Arunning LL= DP-MED, separate from the underlying OS. I would need for the client=0D=0At= o know whether or not the OS provided that function, before it tried. If on= e=0D=0Aclient started doing it, then all the clients might decide they want= ed to do=0D=0Ait, too, and it might just get out of hand. =0D=0A
=0D=0A[PB] I=0D=0Aagree there are potential issues if multip= le applications in a single Endpoint=0D=0Adevice all decided to start LLDP-= MED.  (You are referring to these=0D=0Aapplications as "clients&q= uot; I believe=3F=3F)  Potentially, the first=0D=0Aof those would get = immediate response, but others would not see -MED coming=0D=0Aback until th= e next normal advertising cycle.  Hence, OS support would be=0D=0Aa go= od thing.  I do not see this as a big issue though, since location wou= ld=0D=0Aonly be out of date for a max of the advertising interval (30 sec d= efault), and=0D=0Awould be correct thereafter.  A bit more serious wou= ld be the implication=0D=0Aon the Network Connectivity Device side, where i= t would potentially be=0D=0Areceiving multiple sets of advertisements. &nbs= p;Not only would there be more=0D=0Atraffic (a non-issue in practice, since= it is constrained to the link), but if=0D=0Aeach app was advertising diffe= rent TLVs then the info from one could=0D=0Acontinually get overridden with= info from the other(s).  I would expect=0D=0Amultiple apps all wantin= g to use LLDP-MED in a single device to be rare though,=0D=0Aat least at th= is point.  
=0D=0A
=0D=0AThere is a "known gap" on the DHCP INFORM timer,=0D=0Ab= ut not the standard DHCP request. My logic there was that if a device is=0D= =0Aconfigured to do DHCP for bootstrap, then it will be completely unable t= o do=0D=0Aanything at a higher layer (including make an emergency call), un= til it gets a=0D=0Aresponse. I have yet to find a mass market home network = setup where auto=0D=0Aaddressing works to get network connectivity, after D= HCP failed. There's=0D=0Ausually a 60 second timer to try to get a response= to DHCP DISCOVERY, after=0D=0Awhich the device gives up. It may periodical= ly try DHCP again, but that's=0D=0Aoutside the scope of this document. I sh= ould probably try to fit this failure=0D=0Ainto my chart, but I ran out of = room.
=0D=0A =0D=0A
=0D= =0A[PB]=0D=0AYup, this makes sense now.  Yeah, the chart= is pretty convoluted and hard=0D=0Ato fit anything else into, but still th= ink it would be good to include=0D=0A"No" paths from the "Wa= s <method x> successful"=0D=0Adecisions to the appropriate handl= ing (which is LIS determination I would=0D=0Athink).   <= br>=0D=0A
=0D=0AAs to Hannes request f= or help from the DSLF, I'm happy to=0D=0Ahelp in any way I can. I'll make s= ure they get any questions you need for them=0D=0Ato answer. Of course, I'm= editor of this document, and am tracking all your=0D=0Acomments on this li= st. I'll do my best to be responsive, where I can answer=0D=0Aquestions dir= ectly. I really would like to see as much as possible be in=0D=0Aphonebcp, = and simply reference it. I have no intention of being redundant, or=0D=0Aof= going against the recommendations in phonebcp.
=0D=0ABarbara
=0D=0A  =

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D= =0A
=0D=0A=0D=0A

From:=0D= =0Apeter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
=0D=0ASent: Tuesday, Septe= mber 18, 2007 12:11 PM
=0D=0AT= o: ECRIT
=0D=0ACc:= Cullen Jennings; Hannes Tschofenig; Romascanu, Dan (Dan); barbara.star= k@att.com
=0D=0ASubject:= RE: [Ecrit] Some documents from DSL Forum
=0D=0A
=0D= =0A
=0D=0AHi, (adding also Barbara Stark, Ed of the DSL do= cument),
=0D=0A
=0D=0AI also had a go ta= t the DSL Forum document -- looks pretty good overall.  Also=0D=0Anote= d the "Known Gaps".  
=0D=0A
=0D=0A> Need to understand how = long a device would=0D=0Aneed to wait for
=0D=0A> LLDP-MED and DHCP INFORM responses, in=0D=0Anetwor= ks that don't
=0D=0A> sup= port responses to these protocols.
=0D=0A
=0D=0AAdding some important details to Dan's...    <= /span>
=0D=0AIn LLDP-MED, a "Fast Start&= quot; procedure is used at startup (not present=0D=0Ain basic LLDP).  = In Fast Start. the Endpoint side initiates by=0D=0Atransmitting a bust of -= MED frames.  By default, 4 frames are sent at 1=0D=0Asec interval. &nb= sp;Before that time, the Network Connectivity side (ie the=0D=0Aupstream L2= switch) is only transmitting basic LLDP (not -MED extensions).  In=0D= =0Aresponse to seeing that first -MED frame come in, the Network Connectivi= ty=0D=0Adevice then immediately begins transmitting -MED frames back, again= starting=0D=0Awith a burst of 4 frames at 1 sec interval by default.  = ;So, as a result=0D=0Athe Endpoint will learn its location (from the Locati= on Identification TLVs)=0D=0Aalmost immediately at startup.  In my exp= erience, this is typically=0D=0Ameasurable in handfuls of ms, certainly wel= l under 1 sec, unless there is frame=0D=0Aloss (very rare in practice). &nb= sp;The whole Fast Start procedure takes 4 sec=0D=0Amax, so that would make = a good "didn't work" threshold.  =0D=0A
=0D= =0A
=0D=0ANote also that after startup phase, basic LLDP (= and -MED by extension) will=0D=0Acontinue to advertise periodically at 30 s= ec interval by default (not 5 sec as=0D=0ADan suggests).  Also, due to= basic LLDP behaviour, if any TLV information=0D=0Achanges the change is im= mediately advertised, so if there is a change of=0D=0Alocation the Endpoint= gets informed right away.  Thus, the location will=0D=0Aalways stay u= p to date after that point, with a maximum window of 30 sec.  =0D=0A&n= bsp;
=0D=0A
=0D=0AIn the DSL document, th= e sequence flows in Appendix A look basically correct,=0D=0Athe sequence of= events looks good.  However a better value for "Was=0D=0ALLDP-ME= D successful" would be 4 sec.  Also, I do not see a "was=0D=0A= it successful" decision for DHCP ("was location in DHCP=0D=0Aresp= onse" only has a Yes result, and no timeout associated) -- probably=0D= =0Ahelpful to add that.  
=0D=0A
=0D=0A= Noting this stuff would also be helpful in the Phone BCP I think.  (Br= ian=0D=0Aalready said he would do so.)  
=0D=0A
=0D=0AI am not deep on the DHCP part of the question, so perha= ps someone else can=0D=0Aprovide some details there.  However, I don't= *think* there is any=0D=0Aexplicit threshold "didn't work" timer= we could count on (could well=0D=0Abe wrong on that).  In my experien= ce, DHCP process takes longer than=0D=0ALLDP-MED.  
=0D= =0A
=0D=0A> Need r= equirements for soft client on a PC or=0D=0APDA. These applications =
=0D=0A> will not have the abilit= y to control LLDP or=0D=0ADHCP options, but
=0D=0A> should be able to read them, if the=0D=0Aunderly= ing OS has requested
=0D=0A&= gt; these options.
=0D=0A
=0D=0A= Actually, LLDP / LLDP-MED does not necessarily need OS or driver support si= nce=0D=0Ait is defined above the MAC layer, though it would be nice of cour= se.  PC=0D=0A/ PDA apps could build in the LLDP-MED capability directl= y.  (Again,=0D=0Aunclear on the DHCP part of this question.)  
=0D=0A
=0D=0ACheers,
=0D=0APeter Blatherwick (with Editor of LLDP-MED hat on)
=0D=0A
=0D=0A
=0D=0A

=0D=0A=0D=0A=0D=0A =0D=0A =0D=0A

=  

=0D=0A =0D=0A =0D=0A=

"Romas= canu, Dan=0D=0A (Dan)" <dromasca@avaya.com> <= o:p>

=0D=0A

17.09.07 13:45 =

=0D=0A =0D=0A =0D=0A

=         =0D=0A        To:        "C= ullen=0D=0A Jennings" <fluffy@cisco.com>, "Hannes Tschofen= ig" <Hannes.Tschofenig@gmx.net>=0D=0A =
=0D=0A        cc:        ECRIT=0D= =0A <ecrit@ietf.org> =
=0D=0A &= nbsp;      Subject:        RE: [Ecrit]=0D= =0A Some documents from DSL Forum

=0D=0A =0D=0A =0D=0A=0D=0A=0D=0A


=0D=0A<= br>=0D=0A
=0D=0A
=0D=0ALLDP has a periodic 'slow protocol' announcement=0D= =0Atimer which is
=0D=0Ainher= ited by LLDP-MED. Its default is at 5 seconds=0D=0Aif I am not mistaken.
=0D=0AA device is supposed to r= espond much faster (layer=0D=0A2 single link
=0D=0Aprotocol) so this timer can be used as a default=0D=0A=  worst case when facing
=0D=0Anon-responsive devices.  
=0D=0A
=0D=0ADan
=0D=0A
=0D=0A
=0D=0A
=0D= =0A
=0D=0A
=0D=0A> -----Original Me= ssage-----
=0D=0A> From: C= ullen Jennings [mailto:fluffy@cisco.com]=0D=0A
=0D=0A> Sent: Monday, September 17, 2007 6:40 PM
=0D=0A> To: Hannes Tschofenig
=0D=0A> Cc: ECRIT
=0D=0A> Subject: Re: [Ecrit] Some d= ocuments from DSL=0D=0AForum
=0D=0A>
=0D=0A>
=0D=0A> Sounds good. One thing = that caught my=0D=0Aattentions was in the
=0D=0A> gaps it mentions
=0D=0A>
=0D=0A> LLDP-MED and DHCP IN= FORM responses, in=0D=0Anetworks that don't
=0D=0A> support responses to these protocols.
=0D=0A>
=0D=0A> Any advice we can give on that=3F Would=0D=0A= phonebcp be a
=0D=0A> rea= sonable place to address that=3F
=0D=0A>
=0D=0A>
=0D=0A> On Sep 15, 2007, at= 12:57 PM, Hannes=0D=0ATschofenig wrote:
=0D=0A>
=0D=0A> > Hi Cullen,
=0D=0A&= gt; > Hi all,
=0D=0A> &= gt;
=0D=0A> > I read th= rough the documents.
=0D=0A&g= t; >
=0D=0A> > The t= ext in the document can be=0D=0Aclassified into three types of<= br>=0D=0A> > feedback:
=0D= =0A> >
=0D=0A> > -- Protocol specific requirements
=0D=0A> > These are aspects that = could be captured=0D=0Ain the Phone BCP or are
=0D=0A> > already found in the protocol specific=0D= =0Adocuments itself.
=0D=0A&g= t; > I believe we have covered already most=0D=0Aof these aspects
=0D=0A> (but we should <= /tt>
=0D=0A> > double-check it).
=0D=0A> >
=0D= =0A> > -- Implementation-specific aspe= cts
=0D=0A> > I am not = sure how well we can capture=0D=0Athese aspects in our
=0D=0A= > documents.
=0D=0A> > Still, they are fine with me.
=0D=0A> >
=0D=0A> > -- Interactions between different=0D= =0Aprotocols and timing.
=0D=0A> (e.g., for
=0D=0A> > retrieving locat= ion information). I am=0D=0Anot so sure about these
=0D=0A<= tt>> > aspects. Is the timing reasonable=3F= Is=0D=0Athe sequence of retrieving
=0D=0A> > location information reasonable and=0D=0Ageneric en= ough=3F
=0D=0A> >
=0D=0A> > I think that the p= rovided documents=0D=0Asound pretty reasonable to me.  =0D=0A> > We need to figure out what = aspects are=0D=0Anot yet covered in our
=0D=0A> > documents and then we should try to=0D=0Aincorp= orate them. We need to
=0D=0A> > discuss them obviously.
=0D=0A> >
=0D=0A&= gt; > Help from members of the DSL forum would=0D=0Abe useful.
=0D=0A> >
=0D=0A<= tt>> > Ciao
=0D=0A> > Hannes
=0D=0A>
=0D=0A>= ;=0D=0A_______________________________________________
=0D=0A= > Ecrit mailing list
=0D=0A= > Ecrit@ietf.org
=0D=0A> https://www1.ietf.org/mailman/listinfo/ecr= it
=0D=0A> =0D=0A
=0D=0A___________________________= ____________________
=0D=0AEc= rit mailing list
=0D=0AEcrit@= ietf.org
=0D=0Ahttps://www1.i= etf.org/mailman/listinfo/ecrit

=0D=0A=0D= =0A

*****=0D=0A

=0D=0A=0D=0A

Th= e=0D=0Ainformation transmitted is intended only for the person or entity to= which it=0D=0Ais addressed and may contain confidential, proprietary, and/= or privileged=0D=0Amaterial. Any review, retransmission, dissemination or o= ther use of, or taking=0D=0Aof any action in reliance upon this information= by persons or entities other=0D=0Athan the intended recipient is prohibite= d. If you received this in error,=0D=0Aplease contact the sender and delete= the material from all computers. GA625=0D=0A

=0D= =0A=0D=0A=0D=0A=0D=0A


----------------------------------------------------------= --------------------------------------
=0D=0AThis message is&n= bsp;for the designated recipient only and may=
=0D=0Acontain privileged, proprietary, or otherwise=  private information.  
=0D=0AIf you have&= nbsp;received it in error, please notify the&= nbsp;sender
=0D=0Aimmediately and delete the origina= l.  Any unauthorized use of
=0D=0Athis ema= il is prohibited.
=0D=0A--------------------------------------= ----------------------------------------------------------
=0D=0A[mf2]
=0D=0A=0D=0A

*****

=0D=0A

The information transmitted is intended only for the p= erson or entity to which it is addressed and may contain confidential, prop= rietary, and/or privileged material. Any review, retransmission, disseminat= ion or other use of, or taking of any action in reliance upon this informat= ion by persons or entities other than the intended recipient is prohibited.= If you received this in error, please contact the sender and delete the ma= terial from all computers. GA625

=0D=0A=0D=0A= ------_=_NextPart_001_01C7FE67.83EF3CFE-- --===============0239761828== 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 --===============0239761828==-- From ecrit-bounces@ietf.org Mon Sep 24 05:52:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZkZv-0007tu-6A; Mon, 24 Sep 2007 05:50:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZkZt-0007la-Gz for ecrit@ietf.org; Mon, 24 Sep 2007 05:50:09 -0400 Received: from fk-out-0910.google.com ([209.85.128.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZkZj-0001k0-Af for ecrit@ietf.org; Mon, 24 Sep 2007 05:50:05 -0400 Received: by fk-out-0910.google.com with SMTP id z23so1683234fkz for ; Mon, 24 Sep 2007 02:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=LzzmY+mH1IClqCv/AY0mAvHVRpyqaUJsghIl2LwSaMQ=; b=BelrlbwS6iuMOuqzDo+6BwAGpzVuEsSp5tzyz+focvU3BnvtGx8ZFWf/97mPRID+OtqPTBVQkrNbvlKXfUqZ7RbbH4DXJ2ITkAAOCihEdApIQeDE+lBY8QF+/EmP2guCuLcH2b+X22a1sqnkEIZ0oIR/1vKKbFUHE05aUJBwUc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=XP2aNEYD0S1dV/MtP4Zh15wFoXMfWl/hGRKwS0k9zPikts0WwpULdMGoFPqjW3ukkXjN5KfxV8GYlKJnFCsob68CQAWPdxjyP4+gmTi1695csrYd09L0SPTiCQLVsWHeUra4W9G7xPtgqXuLoAfWVWClFNv9szY9uyhoWOXb2E0= Received: by 10.82.186.5 with SMTP id j5mr3826415buf.1190627348162; Mon, 24 Sep 2007 02:49:08 -0700 (PDT) Received: by 10.82.165.16 with HTTP; Mon, 24 Sep 2007 02:49:08 -0700 (PDT) Message-ID: Date: Mon, 24 Sep 2007 11:49:08 +0200 From: "Karl Heinz Wolf" To: ecrit MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ecrit] multiple location sources X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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, I'm working on a prototype SIP client that should be able to determine its location by DHCP, HELD and LLDP-MED. The PIDF-LO document is included in the SIP INVITE body. I have several questions about what to do when there is more than one location source available. draft-ietf-sip-location-conveyance-08 recommends that there is only one location. Of course, all ways of location determination should give the same location. But how can one verify if the same location was received via HELD and DHCP since a different format is used? Or when one gets two DHCP civic location messages via two different interfaces and some of the CAvalues are the same, but some not (e.g. one has an additional location information, the other has a building CAType). Is this the same location? Or think of the following situation. One gets a DHCP location information via a wired connection (the location of the DHCP server in this building) and a LLDP-MED frame via WLAN of an access point in the next building (the location of the access point is announced). draft-ietf-geopriv-pdif-lo-profile-08 gives some rules for multiple location information, but how can the device know which information is more adequate to get the right order? rfc4776 has a table with a mapping of CATypes and PIDF. When conveying location information in SIP messages, a PIDF document is needed. So, what to do with CATypes that have no mapping to PIDF? LLDP-MED has a "what" element, describing if the location of the client itself, of the DHCP server or of the network element closest to the client is provided. This seems to be useful information, but where to put this in a PIDF document? I'm looking forward to your comments and suggestions. Ciao Karl Heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 24 06:11:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZktr-0004aK-Ua; Mon, 24 Sep 2007 06:10:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZktq-0004UH-Hm for ecrit@ietf.org; Mon, 24 Sep 2007 06:10:46 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZktk-0002Gv-43 for ecrit@ietf.org; Mon, 24 Sep 2007 06:10:46 -0400 X-SEF-Processed: 5_0_0_910__2007_09_24_05_19_59 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 24 Sep 2007 05:19:59 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Sep 2007 05:10:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] multiple location sources Date: Mon, 24 Sep 2007 05:10:19 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] multiple location sources Thread-Index: Acf+kQ95MhtCyGapT3Kl3BG0c3YrEAAANYMg References: From: "Winterbottom, James" To: "Karl Heinz Wolf" , "ecrit" X-OriginalArrivalTime: 24 Sep 2007 10:10:21.0984 (UTC) FILETIME=[1DF8CA00:01C7FE93] X-Spam-Score: 1.8 (+) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0315467220==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0315467220== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FE93.1E033D0D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FE93.1E033D0D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Karl,=0D=0A=0D=0A=20=0D=0A=0D=0APlease see my comments inline.=0D=0A=0D=0A= =20=0D=0A=0D=0ACheers=0D=0A=0D=0AJames=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D= =0A> -----Original Message-----=0D=0A=0D=0A> From: Karl Heinz Wolf [mailto:= khwolf1@gmail.com]=0D=0A=0D=0A> Sent: Monday, 24 September 2007 7:49 PM=0D=0A=0D= =0A> To: ecrit=0D=0A=0D=0A> Subject: [Ecrit] multiple location sources=0D=0A=0D= =0A>=20=0D=0A=0D=0A> Hi,=0D=0A=0D=0A> I'm working on a prototype SIP client= that should be able to determine=0D=0A=0D=0A> its location by DHCP, HELD a= nd LLDP-MED. The PIDF-LO document is=0D=0A=0D=0A> included in the SIP INVIT= E body. I have several questions about what=0D=0A=0D=0A> to do when there i= s more than one location source available.=0D=0A=0D=0A>=20=0D=0A=0D=0A> dra= ft-ietf-sip-location-conveyance-08 recommends that there is only=0D=0A=0D=0A= > one location. Of course, all ways of location determination should=0D=0A=0D= =0A> give the same location. But how can one verify if the same location=0D= =0A=0D=0A> was received via HELD and DHCP since a different format is used=3F=0D= =0A=0D=0A>=20=0D=0A=0D=0A=20=0D=0A=0D=0A[AJW] My first question is why are = you using more than one acquisition=0D=0Aprotocol. My thoughts would be use= one, if it fails, pick a different=0D=0Aone. Never invoke both at the same= time so you have this problem of=0D=0Achoice.=0D=0A=0D=0A=20=0D=0A=0D=0A> = Or when one gets two DHCP civic location messages via two different=0D=0A=0D= =0A> interfaces and some of the CAvalues are the same, but some not (e.g.=0D= =0A=0D=0A> one has an additional location information, the other has a buil= ding=0D=0A=0D=0A> CAType). Is this the same location=3F=0D=0A=0D=0A=20=0D=0A=0D= =0A[AJW] Your device will generally favour one net connection over another.=0D= =0AFor example my PC has both WiFi and wired Ethernet, if I have access to=0D= =0Awired Ethernet it uses that. But regardless your SIP client should use=0D= =0Athe location provided to it over the link it plans to initiate the call=0D= =0Aover.=0D=0A=0D=0A=20=0D=0A=0D=0A>=20=0D=0A=0D=0A> Or think of the follow= ing situation. One gets a DHCP location=0D=0A=0D=0A> information via a wire= d connection (the location of the DHCP server in=0D=0A=0D=0A> this building= ) and a LLDP-MED frame via WLAN of an access point in the=0D=0A=0D=0A> next= building (the location of the access point is announced).=0D=0A=0D=0A> dra= ft-ietf-geopriv-pdif-lo-profile-08 gives some rules for multiple=0D=0A=0D=0A= > location information, but how can the device know which information is=0D= =0A=0D=0A> more adequate to get the right order=3F=0D=0A=0D=0A>=20=0D=0A=0D= =0A=20=0D=0A=0D=0A[AJW] See above, I think this is the same solution.=0D=0A=0D= =0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A> rfc4776 has a table with a mapping of CA= Types and PIDF. When conveying=0D=0A=0D=0A> location information in SIP mes= sages, a PIDF document is needed. So,=0D=0A=0D=0A> what to do with CATypes = that have no mapping to PIDF=3F=0D=0A=0D=0A>=20=0D=0A=0D=0A=20=0D=0A=0D=0A[= AJW] Revised Civic should have taken care of any problems here. If you=0D=0A= have a CAType that is not addressed by revised civic speak now please.=0D=0A=0D= =0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A> LLDP-MED has a "what" element, describin= g if the location of the=0D=0A=0D=0A> client itself, of the DHCP server or = of the network element closest to=0D=0A=0D=0A> the client is provided. This= seems to be useful information, but where=0D=0A=0D=0A> to put this in a PI= DF document=3F=0D=0A=0D=0A>=20=0D=0A=0D=0A[AJW] You can use the Device or P= erson fields in PIDF for this I think.=0D=0AThough we may need to define UR= N for them.=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A> I'm l= ooking forward to your comments and suggestions.=0D=0A=0D=0A>=20=0D=0A=0D=0A= > Ciao=0D=0A=0D=0A> Karl Heinz=0D=0A=0D=0A>=20=0D=0A=0D=0A> _______________= ________________________________=0D=0A=0D=0A> Ecrit mailing list=0D=0A=0D=0A= > Ecrit@ietf.org=0D=0A=0D=0A> https://www1.ietf.org/mailman/listinfo/ecrit=0D= =0A=0D=0A=20=0D=0A=0D=0A---------------------------------------------------= ---------------------------------------------=0D=0AThis message is for the = designated recipient only and may=0D=0Acontain privileged, proprietary, or = otherwise private information. =20=0D=0AIf you have received it in error, p= lease notify the sender=0D=0Aimmediately and delete the original. Any unau= thorized use of=0D=0Athis email is prohibited.=0D=0A-----------------------= -------------------------------------------------------------------------=0D= =0A[mf2]=0D=0A ------_=_NextPart_001_01C7FE93.1E033D0D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A
It's not always desirable to wait for a protocol to = time-out,=20 before launching the next protocol. Specifically, if a device is = configured to=20 do DHCP for IP address configuration, it should launch its DHCP = discovery ASAP,=20 with options, instead of waiting the 4 or 5 seconds for LLDP-MED to time = out.=20 This prevents unnecessary delays in the bootstrap process. It should be = easy=20 enough for the device to use a received LLDP-MED location, even if = it=20 arrives after the DHCP response.
Barbara
 
-------------------- 
 [AJW] My=20 first question is why are you using more than one acquisition protocol. = My=20 thoughts would be use one, if it fails, pick a different one. Never = invoke both=20 at the same time so you have this problem of=20 choice.
 

*****

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

 ------_=_NextPart_001_01C7FEA9.42399D1E-- --===============1771134344== 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 --===============1771134344==-- From ecrit-bounces@ietf.org Mon Sep 24 08:51:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZnPB-0006zt-6u; Mon, 24 Sep 2007 08:51:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZnP9-0006zn-TD for ecrit@ietf.org; Mon, 24 Sep 2007 08:51:15 -0400 Received: from mu-out-0910.google.com ([209.85.134.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZnP3-0006JT-Io for ecrit@ietf.org; Mon, 24 Sep 2007 08:51:15 -0400 Received: by mu-out-0910.google.com with SMTP id w8so2234886mue for ; Mon, 24 Sep 2007 05:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=s1I7am7pFy6tUaG3cGbrEMfSRAK/JccMJRsJbp2rQlw=; b=HTUxgq49/D6Xc71tsuKif019Qgk3zYL1IHyHIIQLGFhQxS0Fnon8F9+/rMQ/On99c9YB6PlNFQPQ46+gUVSH8bJUfX/OxwUEO8Mv7zvaGEtxOwmyiZQ0CXs/UPEirvHKApkVEN5zrSaqfY6gfPjvwZMyx40n/ABWqw/7JfG9/F0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OwSwb1AIryOO4QyeY/WjXdnAZUZs7iilAwtN+i0chO2D1Sbk4cJvP1pirL8R2jm7Y416rC2teTGK37CqHCaIFz3wJl68WppzAmeXQmTc4+CsvDainw9RItJc9bwksfhTBwWlbSMkfxXYmYxi/SaX1YOBji4L9WHbaF9ssXw4dBM= Received: by 10.82.174.20 with SMTP id w20mr6831483bue.1190638239261; Mon, 24 Sep 2007 05:50:39 -0700 (PDT) Received: by 10.82.165.16 with HTTP; Mon, 24 Sep 2007 05:50:39 -0700 (PDT) Message-ID: Date: Mon, 24 Sep 2007 14:50:39 +0200 From: "Karl Heinz Wolf" To: "Hannes Tschofenig" Subject: Re: [Ecrit] multiple location sources In-Reply-To: <46F7912C.6090002@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46F7912C.6090002@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: ecrit X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org hi Hannes thanks for your answer. On 9/24/07, Hannes Tschofenig wrote: > Hi Karl Heinz, > > a quick response below: > > Karl Heinz Wolf wrote: > > Hi, > > I'm working on a prototype SIP client that should be able to determine > > its location by DHCP, HELD and LLDP-MED. The PIDF-LO document is > > included in the SIP INVITE body. I have several questions about what > > to do when there is more than one location source available. > > > > draft-ietf-sip-location-conveyance-08 recommends that there is only > > one location. > > I believe (and I stated it already many times) that the SIP Location > Conveyance document should point to the PIDF-LO profile draft and should > be silent about this issue since it only leads to confusion. Still, that > has not been done .... > > > Of course, all ways of location determination should > > give the same location. But how can one verify if the same location > > was received via HELD and DHCP since a different format is used? > > > There are a couple of issues: > * The encoding is different > * The mapping might lead to a different location (see the recent > discussion in GEOPRIV and some of the mappping attempts in PIDF-LO profile) > * The data might not be in sync between the HELD server and the > information that is returned via DHCP. > > Hence, I agree with you that you might receive location information > describing the same location but looking differently. Depending on the > application (e.g., emergency services) I believe the client should not > attempt to figure out whether the obtained location information is > actually pointing to the same location. > For some other applications you might just show it to the user on a map > and they will easily be able to figure out which one is the most > accurate one. > > Or when one gets two DHCP civic location messages via two different > > interfaces and some of the CAvalues are the same, but some not (e.g. > > one has an additional location information, the other has a building > > CAType). Is this the same location? > > > Typically, it will refer to the same location. However, there is > obviously the chance that the received information is different since > the different interfaces might refer to different link layer > technologies (e.g., Ethernet and UMTS) and hence the location format, > the shapes and the location determination technology could be different. > > > Or think of the following situation. One gets a DHCP location > > information via a wired connection (the location of the DHCP server in > > this building) and a LLDP-MED frame via WLAN of an access point in the > > next building (the location of the access point is announced). > > draft-ietf-geopriv-pdif-lo-profile-08 gives some rules for multiple > > location information, but how can the device know which information is > > more adequate to get the right order? > > > As I mentioned for some applications the best approach is to just put > everything into the PIDF-LO and indicate how the info was obtained > (using the method element). For others it might be useful todo some > todo some ??? I think the rest of the sentence is missing here. > What application are you looking at? Emergency Calls. > > > rfc4776 has a table with a mapping of CATypes and PIDF. When conveying > > location information in SIP messages, a PIDF document is needed. So, > > what to do with CATypes that have no mapping to PIDF? > > > Have you looked at the revised civic document: > http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-revised-civic-lo/ > This document also provides a table of the CATypes and the elements used > in XML > no, I haven't looked at this table, thanks for reminding me of that. > There should be no CAType where no corresponding element exists. > > > LLDP-MED has a "what" element, describing if the location of the > > client itself, of the DHCP server or of the network element closest to > > the client is provided. This seems to be useful information, but where > > to put this in a PIDF document? > > > The "what" element describes to which element the location refers to. In > a PIDF-LO the entity element is actually the place where the identity > information of the element is that the location refers to. I would put > the MAC address of the access point (or whatever it is) in there. > > I believe that this is the right way. Unfortunately, the entity element > expects a URN but I haven't found a URN scheme that is allowed to carry > MAC addresses or IP addresses. James, Henning and myself are still > looking at this issue. > I think there should be a way for the receiver of the location information to distinguish a PIDF-LO document describing the location of the client itself form a PIDF containing the location of a nearby network element. So you would rather collect the date from all methods of location determination on all interfaces? But create a seperate PIDF-LO document for each or put all in one? cheers Karl Heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 24 08:51:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZnPJ-00076O-M6; Mon, 24 Sep 2007 08:51:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZnPI-00075c-Rn for ecrit@ietf.org; Mon, 24 Sep 2007 08:51:24 -0400 Received: from demumfd001.nsn-inter.net ([217.115.75.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZnPC-0006KO-GW for ecrit@ietf.org; Mon, 24 Sep 2007 08:51:24 -0400 Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id l8OCov1r012379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Sep 2007 14:50:57 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id l8OCovOC018379; Mon, 24 Sep 2007 14:50:57 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 14:50:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] multiple location sources Date: Mon, 24 Sep 2007 14:50:55 +0200 Message-ID: <5FB585F183235B42A9E70095055136FB32D02A@DEMUEXC012.nsn-intra.net> In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA05C401AE@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] multiple location sources Thread-Index: Acf+kR+klRErjfWkSgWI8yqwL0OGvQAFUs7AAAC+dGA= References: <7582BC68E4994F4ABF0BD4723975C3FA05C401AE@crexc41p> From: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" To: "ext Stark, Barbara" , "Karl Heinz Wolf" , "ecrit" X-OriginalArrivalTime: 24 Sep 2007 12:50:57.0817 (UTC) FILETIME=[8D603890:01C7FEA9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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 Barbara, that's a very good hint to look at that document.=20 It might, however, matter only to a large extend when Karl Heinz is = focusing on emergency services since a lot of the text is indeed = emergency service specific; isn't it. Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: ext Stark, Barbara [mailto:bs7652@att.com]=20 > Gesendet: Montag, 24. September 2007 14:42 > An: Karl Heinz Wolf; ecrit > Betreff: RE: [Ecrit] multiple location sources >=20 > Some of these are questions I was trying to address in the draft > document liaised from the DSL Forum to IETF=20 > (see=20 > http://www1.ietf.org/mail-archive/web/geopriv/current/msg04297.html > for link to documents), because I hadn't seen them addressed=20 > elsewhere. > I'd be curious to hear if you find the flows in that document at all > useful. I suggest in there that, in the absence of real=20 > intelligence for > selecting one location from multiple, that locations received=20 > from lower > layers should be given preference over locations received from higher > layers. When multiple locations are received using the same protocol, > then the first received should be used. But this is for a particular > physical interface.=20 >=20 > In the case of multiple physical interfaces, I suggest that the device > should keep its location per physical interface. A call that goes out > over a particular interface, should use the location associated with > that interface. >=20 > Again, this is suggested for the case where there is nothing=20 > on which to > base an informed decision. > Barbara >=20 > -----Original Message----- > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com]=20 > Sent: Monday, September 24, 2007 5:49 AM > To: ecrit > Subject: [Ecrit] multiple location sources >=20 > Hi, > I'm working on a prototype SIP client that should be able to determine > its location by DHCP, HELD and LLDP-MED. The PIDF-LO document is > included in the SIP INVITE body. I have several questions about what > to do when there is more than one location source available. >=20 > draft-ietf-sip-location-conveyance-08 recommends that there is only > one location. Of course, all ways of location determination should > give the same location. But how can one verify if the same location > was received via HELD and DHCP since a different format is used? >=20 > Or when one gets two DHCP civic location messages via two different > interfaces and some of the CAvalues are the same, but some not (e.g. > one has an additional location information, the other has a building > CAType). Is this the same location? >=20 > Or think of the following situation. One gets a DHCP location > information via a wired connection (the location of the DHCP server in > this building) and a LLDP-MED frame via WLAN of an access point in the > next building (the location of the access point is announced). > draft-ietf-geopriv-pdif-lo-profile-08 gives some rules for multiple > location information, but how can the device know which information is > more adequate to get the right order? >=20 > rfc4776 has a table with a mapping of CATypes and PIDF. When conveying > location information in SIP messages, a PIDF document is needed. So, > what to do with CATypes that have no mapping to PIDF? >=20 > LLDP-MED has a "what" element, describing if the location of the > client itself, of the DHCP server or of the network element closest to > the client is provided. This seems to be useful information, but where > to put this in a PIDF document? >=20 > I'm looking forward to your comments and suggestions. >=20 > Ciao > Karl Heinz >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 > ***** >=20 > The information transmitted is intended only for the person=20 > or entity to which it is addressed and may contain=20 > confidential, proprietary, and/or privileged material. Any=20 > review, retransmission, dissemination or other use of, or=20 > taking of any action in reliance upon this information by=20 > persons or entities other than the intended recipient is=20 > prohibited. If you received this in error, please contact the=20 > sender and delete the material from all computers. GA621 >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 24 08:58:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZnVy-000613-Jf; Mon, 24 Sep 2007 08:58:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZnVy-00060Z-4Y for ecrit@ietf.org; Mon, 24 Sep 2007 08:58:18 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZnVp-0006UV-Uf for ecrit@ietf.org; Mon, 24 Sep 2007 08:58:16 -0400 Received: from ([139.76.131.79]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.185112957; Mon, 24 Sep 2007 08:57:41 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 24 Sep 2007 08:57:41 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 24 Sep 2007 08:57:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] multiple location sources Date: Mon, 24 Sep 2007 08:57:40 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA05C401BB@crexc41p> In-Reply-To: <5FB585F183235B42A9E70095055136FB32D02A@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] multiple location sources Thread-Index: Acf+kR+klRErjfWkSgWI8yqwL0OGvQAFUs7AAAC+dGAAACxg0A== References: <7582BC68E4994F4ABF0BD4723975C3FA05C401AE@crexc41p> <5FB585F183235B42A9E70095055136FB32D02A@DEMUEXC012.nsn-intra.net> From: "Stark, Barbara" To: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" , "Karl Heinz Wolf" , "ecrit" X-OriginalArrivalTime: 24 Sep 2007 12:57:41.0346 (UTC) FILETIME=[7DE5DC20:01C7FEAA] X-Spam-Score: 0.2 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 True. Fortunately, he responded to you saying that he *is* looking at = emergency services. :-) My guess is, that other applications will either need to have data for = that informed decision that I mention in my email, or they'll decide to = use the same logic as for emergency service location. Barbara=20 -----Original Message----- From: Tschofenig, Hannes (NSN - DE/Germany - MiniMD) = [mailto:hannes.tschofenig@nsn.com]=20 Sent: Monday, September 24, 2007 8:51 AM To: Stark, Barbara; Karl Heinz Wolf; ecrit Subject: AW: [Ecrit] multiple location sources Barbara, that's a very good hint to look at that document.=20 It might, however, matter only to a large extend when Karl Heinz is = focusing on emergency services since a lot of the text is indeed = emergency service specific; isn't it. Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: ext Stark, Barbara [mailto:bs7652@att.com]=20 > Gesendet: Montag, 24. September 2007 14:42 > An: Karl Heinz Wolf; ecrit > Betreff: RE: [Ecrit] multiple location sources >=20 > Some of these are questions I was trying to address in the draft > document liaised from the DSL Forum to IETF=20 > (see=20 > http://www1.ietf.org/mail-archive/web/geopriv/current/msg04297.html > for link to documents), because I hadn't seen them addressed=20 > elsewhere. > I'd be curious to hear if you find the flows in that document at all > useful. I suggest in there that, in the absence of real=20 > intelligence for > selecting one location from multiple, that locations received=20 > from lower > layers should be given preference over locations received from higher > layers. When multiple locations are received using the same protocol, > then the first received should be used. But this is for a particular > physical interface.=20 >=20 > In the case of multiple physical interfaces, I suggest that the device > should keep its location per physical interface. A call that goes out > over a particular interface, should use the location associated with > that interface. >=20 > Again, this is suggested for the case where there is nothing=20 > on which to > base an informed decision. > Barbara >=20 > -----Original Message----- > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com]=20 > Sent: Monday, September 24, 2007 5:49 AM > To: ecrit > Subject: [Ecrit] multiple location sources >=20 > Hi, > I'm working on a prototype SIP client that should be able to determine > its location by DHCP, HELD and LLDP-MED. The PIDF-LO document is > included in the SIP INVITE body. I have several questions about what > to do when there is more than one location source available. >=20 > draft-ietf-sip-location-conveyance-08 recommends that there is only > one location. Of course, all ways of location determination should > give the same location. But how can one verify if the same location > was received via HELD and DHCP since a different format is used? >=20 > Or when one gets two DHCP civic location messages via two different > interfaces and some of the CAvalues are the same, but some not (e.g. > one has an additional location information, the other has a building > CAType). Is this the same location? >=20 > Or think of the following situation. One gets a DHCP location > information via a wired connection (the location of the DHCP server in > this building) and a LLDP-MED frame via WLAN of an access point in the > next building (the location of the access point is announced). > draft-ietf-geopriv-pdif-lo-profile-08 gives some rules for multiple > location information, but how can the device know which information is > more adequate to get the right order? >=20 > rfc4776 has a table with a mapping of CATypes and PIDF. When conveying > location information in SIP messages, a PIDF document is needed. So, > what to do with CATypes that have no mapping to PIDF? >=20 > LLDP-MED has a "what" element, describing if the location of the > client itself, of the DHCP server or of the network element closest to > the client is provided. This seems to be useful information, but where > to put this in a PIDF document? >=20 > I'm looking forward to your comments and suggestions. >=20 > Ciao > Karl Heinz >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 > ***** >=20 > The information transmitted is intended only for the person=20 > or entity to which it is addressed and may contain=20 > confidential, proprietary, and/or privileged material. Any=20 > review, retransmission, dissemination or other use of, or=20 > taking of any action in reliance upon this information by=20 > persons or entities other than the intended recipient is=20 > prohibited. If you received this in error, please contact the=20 > sender and delete the material from all computers. GA621 >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 24 09:13:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZnkf-0006u1-U1; Mon, 24 Sep 2007 09:13:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZnke-0006tb-PY for ecrit@ietf.org; Mon, 24 Sep 2007 09:13:28 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZnkY-0006xR-Pz for ecrit@ietf.org; Mon, 24 Sep 2007 09:13:28 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IZnkP-0001SS-RW; Mon, 24 Sep 2007 08:13:14 -0500 From: "Brian Rosen" To: "'Stark, Barbara'" , "'Tschofenig, Hannes \(NSN - DE/Germany - MiniMD\)'" , "'Karl Heinz Wolf'" , "'ecrit'" References: <7582BC68E4994F4ABF0BD4723975C3FA05C401AE@crexc41p><5FB585F183235B42A9E70095055136FB32D02A@DEMUEXC012.nsn-intra.net> <7582BC68E4994F4ABF0BD4723975C3FA05C401BB@crexc41p> Subject: RE: [Ecrit] multiple location sources Date: Mon, 24 Sep 2007 09:13:18 -0400 Message-ID: <186201c7feac$ae4a8da0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acf+kR+klRErjfWkSgWI8yqwL0OGvQAFUs7AAAC+dGAAACxg0AAAlCSw In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA05C401BB@crexc41p> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I have addressed this in -phonebcp, where it now says: ED-22 Endpoints SHOULD try all LCPs supported by the device in any order = or in parallel. The first one that succeeds in supplying location can be = used. AN-13 Access networks that support more than one LCP MUST reply with the same location information (within the limits of the data format for the specific LCP) for all LCPs it supports.ED-35 If a UA has more than one location available to it, it MUST choose one location to use to route = the call towards the PSAP. SP-15 If a proxy inserts location on behalf of an endpoint, and it has multiple locations available for the endpoint it MUST choose one = location to use to route the call towards the PSAP. SP-16 If a proxy is attempting to assert location but the UA conveyed a location to it, the proxy must use the UA?s location for routing and = MUST convey that location towards the PSAP. It MAY also include what it = believes the location to be. SP-17 All location objects received by a proxy MUST be delivered to the PSAP. ED-36/SP-18 Location objects MUST contain information about the method = by which the location was determined, such as GPS, manually entered, or = based on access network topology included in a PIDF- LO ?method? element. In addition, the source of the location information MUST be included in a PIDF-LO "provided-by" element. ED-37/SP-19 The "used-for-routing" parameter MUST be set to the location that was used to query LoST. > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Monday, September 24, 2007 8:58 AM > To: Tschofenig,Hannes (NSN - DE/Germany - MiniMD); Karl Heinz Wolf; = ecrit > Subject: RE: [Ecrit] multiple location sources >=20 > True. Fortunately, he responded to you saying that he *is* looking at > emergency services. :-) > My guess is, that other applications will either need to have data for > that informed decision that I mention in my email, or they'll decide = to > use the same logic as for emergency service location. > Barbara >=20 > -----Original Message----- > From: Tschofenig, Hannes (NSN - DE/Germany - MiniMD) > [mailto:hannes.tschofenig@nsn.com] > Sent: Monday, September 24, 2007 8:51 AM > To: Stark, Barbara; Karl Heinz Wolf; ecrit > Subject: AW: [Ecrit] multiple location sources >=20 > Barbara, that's a very good hint to look at that document. >=20 > It might, however, matter only to a large extend when Karl Heinz is > focusing on emergency services since a lot of the text is indeed = emergency > service specific; isn't it. >=20 > Ciao > Hannes >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: ext Stark, Barbara [mailto:bs7652@att.com] > > Gesendet: Montag, 24. September 2007 14:42 > > An: Karl Heinz Wolf; ecrit > > Betreff: RE: [Ecrit] multiple location sources > > > > Some of these are questions I was trying to address in the draft > > document liaised from the DSL Forum to IETF > > (see > > http://www1.ietf.org/mail-archive/web/geopriv/current/msg04297.html > > for link to documents), because I hadn't seen them addressed > > elsewhere. > > I'd be curious to hear if you find the flows in that document at all > > useful. I suggest in there that, in the absence of real > > intelligence for > > selecting one location from multiple, that locations received > > from lower > > layers should be given preference over locations received from = higher > > layers. When multiple locations are received using the same = protocol, > > then the first received should be used. But this is for a particular > > physical interface. > > > > In the case of multiple physical interfaces, I suggest that the = device > > should keep its location per physical interface. A call that goes = out > > over a particular interface, should use the location associated with > > that interface. > > > > Again, this is suggested for the case where there is nothing > > on which to > > base an informed decision. > > Barbara > > > > -----Original Message----- > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > Sent: Monday, September 24, 2007 5:49 AM > > To: ecrit > > Subject: [Ecrit] multiple location sources > > > > Hi, > > I'm working on a prototype SIP client that should be able to = determine > > its location by DHCP, HELD and LLDP-MED. The PIDF-LO document is > > included in the SIP INVITE body. I have several questions about what > > to do when there is more than one location source available. > > > > draft-ietf-sip-location-conveyance-08 recommends that there is only > > one location. Of course, all ways of location determination should > > give the same location. But how can one verify if the same location > > was received via HELD and DHCP since a different format is used? > > > > Or when one gets two DHCP civic location messages via two different > > interfaces and some of the CAvalues are the same, but some not (e.g. > > one has an additional location information, the other has a building > > CAType). Is this the same location? > > > > Or think of the following situation. One gets a DHCP location > > information via a wired connection (the location of the DHCP server = in > > this building) and a LLDP-MED frame via WLAN of an access point in = the > > next building (the location of the access point is announced). > > draft-ietf-geopriv-pdif-lo-profile-08 gives some rules for multiple > > location information, but how can the device know which information = is > > more adequate to get the right order? > > > > rfc4776 has a table with a mapping of CATypes and PIDF. When = conveying > > location information in SIP messages, a PIDF document is needed. So, > > what to do with CATypes that have no mapping to PIDF? > > > > LLDP-MED has a "what" element, describing if the location of the > > client itself, of the DHCP server or of the network element closest = to > > the client is provided. This seems to be useful information, but = where > > to put this in a PIDF document? > > > > I'm looking forward to your comments and suggestions. > > > > Ciao > > Karl Heinz > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > ***** > > > > The information transmitted is intended only for the person > > or entity to which it is addressed and may contain > > confidential, proprietary, and/or privileged material. Any > > review, retransmission, dissemination or other use of, or > > taking of any action in reliance upon this information by > > persons or entities other than the intended recipient is > > prohibited. If you received this in error, please contact the > > sender and delete the material from all computers. GA621 > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 24 12:49:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZr7L-00087I-2W; Mon, 24 Sep 2007 12:49:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZr7J-00087D-MJ for ecrit@ietf.org; Mon, 24 Sep 2007 12:49:05 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZr7D-0005bF-DO for ecrit@ietf.org; Mon, 24 Sep 2007 12:49:05 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 1FCF32C046; Mon, 24 Sep 2007 12:48:49 -0400 (EDT) X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDEz+OAQ8qoc; Mon, 24 Sep 2007 12:48:48 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id E97B62C05D; Mon, 24 Sep 2007 12:48:47 -0400 (EDT) In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA05C401B2@crexc41p> To: "Stark, Barbara" Subject: RE: [Ecrit] multiple location sources MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Mon, 24 Sep 2007 12:48:45 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 09/24/2007 12:48:46 PM, Serialize complete at 09/24/2007 12:48:46 PM X-Spam-Score: 1.7 (+) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: ecrit X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0438849924==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============0438849924== Content-Type: multipart/alternative; boundary="=_alternative 005C5AD185257360_=" This is a multipart message in MIME format. --=_alternative 005C5AD185257360_= Content-Type: text/plain; charset="US-ASCII" Hi, I agree that the DSL Forum document makes a very good starting point for orderly acquisition of location at startup, accounting for all 3 methods. I also believe it points to a preference order, if there are multiple answers coming back, which is LLDP-MED --> DHCP --> HELD. Reasoning for this order (my opinion) is that it progresses from "least moving parts" / most reliable (LLDP-MED) to most, and also follows the natural layering of the overall system (L2 --> L2.5 --> L7). In the end, only ONE method should ever be selected, as the sequence diagram shows. Your point below, that the methods can and should progress in parallel is valid. However there are constraints to this, notably: o If LLDP-MED is being used to autoconfigure voice VLAN ID, then the device should wait to see if that stage succeeds before contacting DHCP. Otherwise, the device may get an IP address on the default VLAN, only to have to drop it and try again on the voice VLAN. If it had started to use this address for something already (say for HELD), then ongoing interaction would be dropped and confusion would likely ensue. o Before HELD can work, an IP address is needed. I think these constraints are really just a reflection of the natural layering in the end. IMHO, orderly startup beats the few extra seconds delay incurred in making sure the constraints are not broken. We are only talking about a very few seconds here after all. -- Peter "Stark, Barbara" 24.09.07 08:48 To: "Winterbottom, James" , "Karl Heinz Wolf" , "ecrit" cc: Subject: RE: [Ecrit] multiple location sources It's not always desirable to wait for a protocol to time-out, before launching the next protocol. Specifically, if a device is configured to do DHCP for IP address configuration, it should launch its DHCP discovery ASAP, with options, instead of waiting the 4 or 5 seconds for LLDP-MED to time out. This prevents unnecessary delays in the bootstrap process. It should be easy enough for the device to use a received LLDP-MED location, even if it arrives after the DHCP response. Barbara -------------------- [AJW] My first question is why are you using more than one acquisition protocol. My thoughts would be use one, if it fails, pick a different one. Never invoke both at the same time so you have this problem of choice. ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --=_alternative 005C5AD185257360_= Content-Type: text/html; charset="US-ASCII"
Hi,
I agree that the DSL Forum document makes a very good starting point for orderly acquisition of location at startup, accounting for all 3 methods.  I also believe it points to a preference order, if there are multiple answers coming back, which is LLDP-MED --> DHCP --> HELD.  Reasoning for this order (my opinion) is that it progresses from "least moving parts" / most reliable (LLDP-MED) to most, and also follows the natural layering of the overall system (L2 --> L2.5 --> L7).   In the end, only ONE method should ever be selected, as the sequence diagram shows.  

Your point below, that the methods can and should progress in parallel is valid.  However there are constraints to this, notably:

o If LLDP-MED is being used to autoconfigure voice VLAN ID, then the device should wait to see if that stage succeeds before contacting DHCP.  Otherwise, the device may get an IP address on the default VLAN, only to have to drop it and try again on the voice VLAN.  If it had started to use this address for something already (say for HELD), then ongoing interaction would be dropped and confusion would likely ensue.  

o Before HELD can work, an IP address is needed.  

I think these constraints are really just a reflection of the natural layering in the end.  

IMHO, orderly startup beats the few extra seconds delay incurred in making sure the constraints are not broken.   We are only talking about a very few seconds here after all.  

-- Peter





"Stark, Barbara" <bs7652@att.com>

24.09.07 08:48

       
        To:        "Winterbottom, James" <James.Winterbottom@andrew.com>, "Karl Heinz Wolf" <khwolf1@gmail.com>, "ecrit" <ecrit@ietf.org>
        cc:        
        Subject:        RE: [Ecrit] multiple location sources



It's not always desirable to wait for a protocol to time-out, before launching the next protocol. Specifically, if a device is configured to do DHCP for IP address configuration, it should launch its DHCP discovery ASAP, with options, instead of waiting the 4 or 5 seconds for LLDP-MED to time out. This prevents unnecessary delays in the bootstrap process. It should be easy enough for the device to use a received LLDP-MED location, even if it arrives after the DHCP response.
Barbara
 
--------------------
 [AJW] My first question is why are you using more than one acquisition protocol. My thoughts would be use one, if it fails, pick a different one. Never invoke both at the same time so you have this problem of choice.
 

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

--=_alternative 005C5AD185257360_=-- --===============0438849924== 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 --===============0438849924==-- From ecrit-bounces@ietf.org Mon Sep 24 16:22:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZuRU-0000rf-Iw; Mon, 24 Sep 2007 16:22:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZuRS-0000ra-Rq for ecrit@ietf.org; Mon, 24 Sep 2007 16:22:07 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZuRS-0006Ng-4s for ecrit@ietf.org; Mon, 24 Sep 2007 16:22:06 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IZuRE-0002J7-JF; Mon, 24 Sep 2007 15:21:53 -0500 From: "Brian Rosen" To: , "'Stark, Barbara'" References: <7582BC68E4994F4ABF0BD4723975C3FA05C401B2@crexc41p> Subject: RE: [Ecrit] multiple location sources Date: Mon, 24 Sep 2007 16:22:01 -0400 Message-ID: <194701c7fee8$927a12d0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acf+yufZNfMygQSESvqedbYzdW8mQwAAT6zw In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: d094b18a574860cb9e2fe5fedfbcc179 Cc: 'ecrit' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0325961565==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0325961565== Content-Type: multipart/alternative; boundary="----=_NextPart_000_1948_01C7FEC7.0B6872D0" This is a multi-part message in MIME format. ------=_NextPart_000_1948_01C7FEC7.0B6872D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm not sure how you decided that LLDP-MED has fewer moving parts or is more reliable than DHCP. I think likely it's the other way right now. Certainly, if your are autoconfiguring with LLDP, you will want that to complete before you do DHCP. I don't think we have to say that, but we can if we need to. I agree you need an IP address before you can invoke HELD. I don't think we have to say that. This MIGHT lead to an implied ordering, but I don't think it's even useful to say that. I'm not sure why it matters. Brian _____ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Monday, September 24, 2007 12:49 PM To: Stark, Barbara Cc: ecrit Subject: RE: [Ecrit] multiple location sources Hi, I agree that the DSL Forum document makes a very good starting point for orderly acquisition of location at startup, accounting for all 3 methods. I also believe it points to a preference order, if there are multiple answers coming back, which is LLDP-MED --> DHCP --> HELD. Reasoning for this order (my opinion) is that it progresses from "least moving parts" / most reliable (LLDP-MED) to most, and also follows the natural layering of the overall system (L2 --> L2.5 --> L7). In the end, only ONE method should ever be selected, as the sequence diagram shows. Your point below, that the methods can and should progress in parallel is valid. However there are constraints to this, notably: o If LLDP-MED is being used to autoconfigure voice VLAN ID, then the device should wait to see if that stage succeeds before contacting DHCP. Otherwise, the device may get an IP address on the default VLAN, only to have to drop it and try again on the voice VLAN. If it had started to use this address for something already (say for HELD), then ongoing interaction would be dropped and confusion would likely ensue. o Before HELD can work, an IP address is needed. I think these constraints are really just a reflection of the natural layering in the end. IMHO, orderly startup beats the few extra seconds delay incurred in making sure the constraints are not broken. We are only talking about a very few seconds here after all. -- Peter "Stark, Barbara" 24.09.07 08:48 To: "Winterbottom, James" , "Karl Heinz Wolf" , "ecrit" cc: Subject: RE: [Ecrit] multiple location sources It's not always desirable to wait for a protocol to time-out, before launching the next protocol. Specifically, if a device is configured to do DHCP for IP address configuration, it should launch its DHCP discovery ASAP, with options, instead of waiting the 4 or 5 seconds for LLDP-MED to time out. This prevents unnecessary delays in the bootstrap process. It should be easy enough for the device to use a received LLDP-MED location, even if it arrives after the DHCP response. Barbara -------------------- [AJW] My first question is why are you using more than one acquisition protocol. My thoughts would be use one, if it fails, pick a different one. Never invoke both at the same time so you have this problem of choice. ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623_______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------=_NextPart_000_1948_01C7FEC7.0B6872D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not sure how you decided = that LLDP-MED has fewer moving parts or is more reliable than DHCP.  I = think likely it’s the other way right now.  =

 

Certainly, if your are = autoconfiguring with LLDP, you will want that to complete before you do DHCP.  I = don’t think we have to say that, but we can if we need to.  =

 

I agree you need an IP address = before you can invoke HELD.  I don’t think we have to say = that.

 

This MIGHT lead to an implied = ordering, but I don’t think it’s even useful to say that.  = I’m not sure why it matters.

 

Brian

 

From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Monday, September = 24, 2007 12:49 PM
To: Stark, Barbara
Cc: ecrit
Subject: RE: [Ecrit] = multiple location sources

 


Hi,
I agree that the DSL Forum document makes a very good starting point for = orderly acquisition of location at startup, accounting for all 3 methods. =  I also believe it points to a preference order, if there are multiple answers = coming back, which is LLDP-MED --> DHCP --> HELD.  Reasoning for = this order (my opinion) is that it progresses from "least moving parts" / = most reliable (LLDP-MED) to most, and also follows the natural layering of = the overall system (L2 --> L2.5 --> L7).   In the end, only ONE = method should ever be selected, as the sequence diagram shows. =  

Your point below, that the methods can and should progress in parallel is = valid.  However there are constraints to this, notably:

o If LLDP-MED is being used to autoconfigure voice VLAN ID, then the = device should wait to see if that stage succeeds before contacting DHCP. =  Otherwise, the device may get an IP address on the default VLAN, only to have to = drop it and try again on the voice VLAN.  If it had started to use this = address for something already (say for HELD), then ongoing interaction would be = dropped and confusion would likely ensue.  

o Before HELD can work, an IP address is needed.  

I think these constraints are really just a reflection of the natural = layering in the end.  

IMHO, orderly startup beats the few extra seconds delay incurred in making = sure the constraints are not broken.   We are only talking about a very few = seconds here after all.  

-- Peter




 

"Stark, = Barbara" <bs7652@att.com>

24.09.07 08:48

       
        To:       =  "Winterbottom, James" <James.Winterbottom@andrew.com>, "Karl Heinz Wolf" <khwolf1@gmail.com>, "ecrit" = <ecrit@ietf.org>
        cc:         =
        Subject:        RE: [Ecrit] = multiple location sources




It's not always desirable to wait for a = protocol to time-out, before launching the next protocol. Specifically, if a = device is configured to do DHCP for IP address configuration, it should launch its = DHCP discovery ASAP, with options, instead of waiting the 4 or 5 seconds for LLDP-MED to time out. This prevents unnecessary delays in the bootstrap process. It should be easy enough for the device to use a received = LLDP-MED location, even if it arrives after the DHCP response.
Barbara
 
--------------------
 [AJW] My first question is why are you using more than one acquisition = protocol. My thoughts would be use one, if it fails, pick a different one. Never = invoke both at the same time so you have this problem of choice.
 

*****

The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or entities = other than the intended recipient is prohibited. If you received this in error, = please contact the sender and delete the material from all computers. = GA623______________________________________________= _
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

------=_NextPart_000_1948_01C7FEC7.0B6872D0-- --===============0325961565== 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 --===============0325961565==-- From ecrit-bounces@ietf.org Mon Sep 24 16:31:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZuZp-0001NM-Am; Mon, 24 Sep 2007 16:30:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZuZn-0001Md-74; Mon, 24 Sep 2007 16:30:43 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZuZm-0006z0-1W; Mon, 24 Sep 2007 16:30:42 -0400 X-IronPort-AV: E=Sophos;i="4.20,292,1186383600"; d="scan'208";a="224242437" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Sep 2007 13:30:34 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8OKUY6N028989; Mon, 24 Sep 2007 13:30:34 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8OKTwXP026273; Mon, 24 Sep 2007 20:30:31 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 16:30:26 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 16:30:25 -0400 From: "Marc Linsner" To: "'Peterson, Jon'" , Date: Mon, 24 Sep 2007 16:30:23 -0400 Message-ID: <014c01c7fee9$bd1df280$220d0d0a@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.3138 thread-index: Acf+6bTkOE94jmf/SkKVHY8MeqatKw== X-OriginalArrivalTime: 24 Sep 2007 20:30:26.0492 (UTC) FILETIME=[BD962FC0:01C7FEE9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7259; t=1190665834; x=1191529834; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20PROTO=20write-up=20for=20draft-ietf-ecrit-dhc-lost-discovery- 02.txt |Sender:=20; bh=AICzxIH+Fy+42p4Mbhkce5N8uprNyp6Ci+cKxaf0p9g=; b=mS65h2eGOrvvwzjriR44XIbnYX8tha7AstaG9fGPqaW1B71B5guuqwORj6R2SliO+c7wN7GO nFMPTvjrYuK2jIvwfczIeYLmS0aOhetOyJ/KmrUCSTIue4iqPEtDWZzr; Authentication-Results: sj-dkim-4; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: 'ECRIT' Subject: [Ecrit] PROTO write-up for draft-ietf-ecrit-dhc-lost-discovery-02.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 PROTO WRITEUP for draft-ietf-ecrit-dhc-lost-discovery-02.txt ============================================================ (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Document Shepherd is Marc Linsner (marc.linsner@cisco.com). The document is ready for publications and I have reviewed the document personally. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The DHCP-basedFrom ecrit-bounces@ietf.org Mon Sep 24 16:31:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZuZp-0001NM-Am; Mon, 24 Sep 2007 16:30:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZuZn-0001Md-74; Mon, 24 Sep 2007 16:30:43 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZuZm-0006z0-1W; Mon, 24 Sep 2007 16:30:42 -0400 X-IronPort-AV: E=Sophos;i="4.20,292,1186383600"; d="scan'208";a="224242437" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Sep 2007 13:30:34 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8OKUY6N028989; Mon, 24 Sep 2007 13:30:34 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8OKTwXP026273; Mon, 24 Sep 2007 20:30:31 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 16:30:26 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 16:30:25 -0400 From: "Marc Linsner" To: "'Peterson, Jon'" , Date: Mon, 24 Sep 2007 16:30:23 -0400 Message-ID: <014c01c7fee9$bd1df280$220d0d0a@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.3138 thread-index: Acf+6bTkOE94jmf/SkKVHY8MeqatKw== X-OriginalArrivalTime: 24 Sep 2007 20:30:26.0492 (UTC) FILETIME=[BD962FC0:01C7FEE9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7259; t=1190665834; x=1191529834; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20PROTO=20write-up=20for=20draft-ietf-ecrit-dhc-lost-discovery- 02.txt |Sender:=20; bh=AICzxIH+Fy+42p4Mbhkce5N8uprNyp6Ci+cKxaf0p9g=; b=mS65h2eGOrvvwzjriR44XIbnYX8tha7AstaG9fGPqaW1B71B5guuqwORj6R2SliO+c7wN7GO nFMPTvjrYuK2jIvwfczIeYLmS0aOhetOyJ/KmrUCSTIue4iqPEtDWZzr; Authentication-Results: sj-dkim-4; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: 'ECRIT' Subject: [Ecrit] PROTO write-up for draft-ietf-ecrit-dhc-lost-discovery-02.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 PROTO WRITEUP for draft-ietf-ecrit-dhc-lost-discovery-02.txt ============================================================ (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Document Shepherd is Marc Linsner (marc.linsner@cisco.com). The document is ready for publications and I have reviewed the document personally. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The DHCP-based LoST discovery is part of the LoST specification. It provides a possibility for the end host to learn LoST servers that are closer to the client. Such a LoST server placement provides benefits in disaster situations with intermittent network connectivity regarding the resiliency of emergency service communication. The document has been reviewed by ECRIT and DHC working group members. The document experienced two WGLCs (scheduled together with the LoST specification) on the ECRIT and the DHC WG. The two WGLCs were posted on 14 February 2007 and on 15 August 2007. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? There are no concerns with the document. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There are no concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus behind this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document does not contain nits. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has references split into normative and informative references. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Doe LoST discovery is part of the LoST specification. It provides a possibility for the end host to learn LoST servers that are closer to the client. Such a LoST server placement provides benefits in disaster situations with intermittent network connectivity regarding the resiliency of emergency service communication. The document has been reviewed by ECRIT and DHC working group members. The document experienced two WGLCs (scheduled together with the LoST specification) on the ECRIT and the DHC WG. The two WGLCs were posted on 14 February 2007 and on 15 August 2007. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? There are no concerns with the document. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There are no concerns. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus behind this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document does not contain nits. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has references split into normative and informative references. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? An IANA consideration section exists and is consistent with the rest of the document. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no such sections in the document. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. Document Announcement Write-Up for draft-ietf-ecrit-dhc-lost-discovery-02 Technical Summary The Location-to-Service Translation Protocol (LoST) describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere but a placement closer to the end host, e.g., in the access network, is desirable. Such a LoST server placement provides benefits in disaster situations with intermittent network connectivity regarding the resiliency of emergency service communication. This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). Working Group Summary There is consensus in the WG to publish this document. Document Quality Although the LoST specification has been implemented there are no implementations known for the DHCP-based discovery procedure. From a deployment point of view it is likely that the DNS-based discovery procedure will be available before this document will see a deployment. Personnel Marc Linsner is the document shepherd for this document. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 24 16:31:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZua2-0001WQ-SG; Mon, 24 Sep 2007 16:30:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZua1-0001VH-Ay; Mon, 24 Sep 2007 16:30:57 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZuZv-0004rH-2w; Mon, 24 Sep 2007 16:30:57 -0400 X-IronPort-AV: E=Sophos;i="4.20,292,1186372800"; d="scan'208";a="71989440" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 24 Sep 2007 16:30:34 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8OKUXvn021097; Mon, 24 Sep 2007 16:30:33 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8OKUOZ4009953; Mon, 24 Sep 2007 20:30:31 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 16:30:29 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 16:30:26 -0400 From: "Marc Linsner" To: "'Peterson, Jon'" , Date: Mon, 24 Sep 2007 16:30:23 -0400 Message-ID: <014d01c7fee9$be708a30$220d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outls it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? An IANA consideration section exists and is consistent with the rest of the document. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no such sections in the document. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. Document Announcement Write-Up for draft-ietf-ecrit-dhc-lost-discovery-02 Technical Summary The Location-to-Service Translation Protocol (LoST) describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere but a placement closer to the end host, e.g., in the access network, is desirable. Such a LoST server placement provides benefits in disaster situations with intermittent network connectivity regarding the resiliency of emergency service communication. This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). Working Group Summary There is consensus in the WG to publish this document. Document Quality Although the LoST specification has been implemented there are no implementations known for the DHCP-based discovery procedure. From a deployment point of view it is likely that the DNS-based discovery procedure will be available before this document will see a deployment. Personnel Marc Linsner is the document shepherd for this document. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 24 16:31:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZua2-0001WQ-SG; Mon, 24 Sep 2007 16:30:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZua1-0001VH-Ay; Mon, 24 Sep 2007 16:30:57 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZuZv-0004rH-2w; Mon, 24 Sep 2007 16:30:57 -0400 X-IronPort-AV: E=Sophos;i="4.20,292,1186372800"; d="scan'208";a="71989440" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 24 Sep 2007 16:30:34 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8OKUXvn021097; Mon, 24 Sep 2007 16:30:33 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8OKUOZ4009953; Mon, 24 Sep 2007 20:30:31 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 16:30:29 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Sep 2007 16:30:26 -0400 From: "Marc Linsner" To: "'Peterson, Jon'" , Date: Mon, 24 Sep 2007 16:30:23 -0400 Message-ID: <014d01c7fee9$be708a30$220d0d0a@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.3138 thread-index: Acf+6KRxid4zWBQyQZOlEnQaXZwdIg== X-OriginalArrivalTime: 24 Sep 2007 20:30:28.0711 (UTC) FILETIME=[BEE8C770:01C7FEE9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8411; t=1190665833; x=1191529833; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20PROTO=20write-up=20for=20draft-ietf-ecrit-lost-06.txt |Sender:=20 |To:=20=22'Peterson, =20Jon'=22=20, =20; bh=oFBz8303mMnD8BmXXTT3iwPOuLBPRaszwXk8VgZN45c=; b=B+coHvQTR6ZDQCDj8NEDEucEBON2QLYfXIL09ZLIL5kICpf9K1iatQtDzsHlKpUq/9Ln8wZz jqw7MOI7uTySO13i/DT1X8aLytcpe1acl4V4Jd1I5UhcSorw3KXTAeer; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: 'ECRIT' Subject: [Ecrit] PROTO write-up for draft-ietf-ecrit-lost-06.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 PROTO WRITEUP for draft-ietf-ecrit-lost-06.txt ============================================== (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Document Shepherd is Marc Linsner (marc.linsner@cisco.com). The document is ready for publication and I have reviewed the document personally. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The LoST specification has experienced extensive review, including reviews by other SDOs. The work has been presented to other organizations working in the area of emergency services at different meetings, including two emergency services workshops (see http://www.emergency-services-coordination.info/) and other smaller information sharing events with the 3GPP and the IEEE. The protocol is also an important building block in the NENA i3 architecture and reviews have been provided by NENA members. Two WGLCs were issued, on 14 February 2007 and on 15 August 2007. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? There are no concerns with the document. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. A few working group members raised issues with the usage of the Relax NG schema (instead of an XML schema). Tool support for XML scook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 thread-index: Acf+6KRxid4zWBQyQZOlEnQaXZwdIg== X-OriginalArrivalTime: 24 Sep 2007 20:30:28.0711 (UTC) FILETIME=[BEE8C770:01C7FEE9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8411; t=1190665833; x=1191529833; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20PROTO=20write-up=20for=20draft-ietf-ecrit-lost-06.txt |Sender:=20 |To:=20=22'Peterson, =20Jon'=22=20, =20; bh=oFBz8303mMnD8BmXXTT3iwPOuLBPRaszwXk8VgZN45c=; b=B+coHvQTR6ZDQCDj8NEDEucEBON2QLYfXIL09ZLIL5kICpf9K1iatQtDzsHlKpUq/9Ln8wZz jqw7MOI7uTySO13i/DT1X8aLytcpe1acl4V4Jd1I5UhcSorw3KXTAeer; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: 'ECRIT' Subject: [Ecrit] PROTO write-up for draft-ietf-ecrit-lost-06.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 PROTO WRITEUP for draft-ietf-ecrit-lost-06.txt ============================================== (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Document Shepherd is Marc Linsner (marc.linsner@cisco.com). The document is ready for publication and I have reviewed the document personally. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The LoST specification has experienced extensive review, including reviews by other SDOs. The work has been presented to other organizations working in the area of emergency services at different meetings, including two emergency services workshops (see http://www.emergency-services-coordination.info/) and other smaller information sharing events with the 3GPP and the IEEE. The protocol is also an important building block in the NENA i3 architecture and reviews have been provided by NENA members. Two WGLCs were issued, on 14 February 2007 and on 15 August 2007. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? There are no concerns with the document. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. A few working group members raised issues with the usage of the Relax NG schema (instead of an XML schema). Tool support for XML schemas is better than with Relax NG. Two IPR claims have recently been announced. Active participants in the working group are authors of patent filings, but not the authors of this document. One WG participant raised the following concern, "the timing of the disclosure doesn't appear to meet the spirit of Section 6.2 of RFC 3979, possibly opening us up to the ramifications of Section 7 (whatever those may be)." (see: http://www1.ietf.org/mail-archive/web/ecrit/current/msg04191.html) (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is solid consensus behind this document. Section 19 extensively lists the reviewers. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document does not contain nits. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has references split into a normative and informative references. There are no downrefs. There are, however, references to documents that were published outside the IETF, namely reference [11] and [12]. These documents refer to XML-based location formats developed by the OGC. A few other dependencies to unfinished documents exist: * draft-ietf-ecrit-service-urn-06: This document is in 'Approved-announcement to be sent' state. * draft-ietf-geopriv-revised-civic-lo-05: This document is in 'Publication Requested' state. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? An IANA consideration section exists and is consistent with the rest of the document. The document was sent to the URI review team in February 2007. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etchemas is better than with Relax NG. Two IPR claims have recently been announced. Active participants in the working group are authors of patent filings, but not the authors of this document. One WG participant raised the following concern, "the timing of the disclosure doesn't appear to meet the spirit of Section 6.2 of RFC 3979, possibly opening us up to the ramifications of Section 7 (whatever those may be)." (see: http://www1.ietf.org/mail-archive/web/ecrit/current/msg04191.html) (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is solid consensus behind this document. Section 19 extensively lists the reviewers. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document does not contain nits. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has references split into a normative and informative references. There are no downrefs. There are, however, references to documents that were published outside the IETF, namely reference [11] and [12]. These documents refer to XML-based location formats developed by the OGC. A few other dependencies to unfinished documents exist: * draft-ietf-ecrit-service-urn-06: This document is in 'Approved-announcement to be sent' state. * draft-ietf-geopriv-revised-civic-lo-05: This document is in 'Publication Requested' state. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? An IANA consideration section exists and is consistent with the rest of the document. The document was sent to the URI review team in February 2007. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Yes. The schema and the instance document have been validated. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. Document Announcement Write-Up for draft-ietf-ecrit-lost-06.txt Technical Summary This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate PSAP for emergency services. Working Group Summary There is consensus in the WG to publish this document. Document Quality The LoST protocol has been implemented during the development of the specification. Two public implementations are available and other company-internal implementations have been reported to the chairs. Tests have been performed between two public implementations and useful feedback was provided to the working group. The LoST specification has experienced extensive review, including reviews by other SDOs. The protocol is an important building block in the NENA i3 architecture. Two WGLCs were issued, on 14 February 2007 and on 15 August 2007. Personnel Marc Linsner is the document shepherd for this document. The document was sent to the URI review team in February 2007. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ., validate correctly in an automated checker? Yes. The schema and the instance document have been validated. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. Document Announcement Write-Up for draft-ietf-ecrit-lost-06.txt Technical Summary This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate PSAP for emergency services. Working Group Summary There is consensus in the WG to publish this document. Document Quality The LoST protocol has been implemented during the development of the specification. Two public implementations are available and other company-internal implementations have been reported to the chairs. Tests have been performed between two public implementations and useful feedback was provided to the working group. The LoST specification has experienced extensive review, including reviews by other SDOs. The protocol is an important building block in the NENA i3 architecture. Two WGLCs were issued, on 14 February 2007 and on 15 August 2007. Personnel Marc Linsner is the document shepherd for this document. The document was sent to the URI review team in February 2007. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 24 16:35:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZueY-0007aG-8a; Mon, 24 Sep 2007 16:35:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZueW-0007ZH-1g for ecrit@ietf.org; Mon, 24 Sep 2007 16:35:36 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZueP-00050O-Ml for ecrit@ietf.org; Mon, 24 Sep 2007 16:35:36 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 7A9B12C062; Mon, 24 Sep 2007 16:35:21 -0400 (EDT) X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4y-ZIiTJLSci; Mon, 24 Sep 2007 16:35:20 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 4070B2C05E; Mon, 24 Sep 2007 16:35:20 -0400 (EDT) In-Reply-To: <194701c7fee8$927a12d0$640fa8c0@cis.neustar.com> To: "Brian Rosen" Subject: RE: [Ecrit] multiple location sources MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Mon, 24 Sep 2007 16:35:16 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 09/24/2007 04:35:17 PM, Serialize complete at 09/24/2007 04:35:17 PM X-Spam-Score: 1.7 (+) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: 'ecrit' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0987395133==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============0987395133== Content-Type: multipart/alternative; boundary="=_alternative 0071180385257360_=" This is a multipart message in MIME format. --=_alternative 0071180385257360_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 PiBJ4oCZbSBub3Qgc3VyZSBob3cgeW91IGRlY2lkZWQgdGhhdCBMTERQLU1FRCBoYXMgZmV3ZXIg bW92aW5nIHBhcnRzIG9yIGlzIA0KbW9yZSByZWxpYWJsZSB0aGFuIERIQ1ANCkxMRFAgaXMgcnVu bmluZyBhdCB0aGUgb3RoZXIgZW5kIG9mIHRoZSBwaHlzaWNhbCB3aXJlIHRoZSBkZXZpY2UgaW4g DQpxdWVzdGlvbiBpcyBwbHVnZ2VkIGludG8uICAoSW4gdGhlIGNhc2Ugb2Ygd2lyZWxlc3MsIGl0 IGlzIGxpa2VseSBhdCB0aGUgDQphY2Nlc3MgcG9pbnQsIG9yIGp1c3QgYmVoaW5kIGl0LikgIElu IHRoYXQgc2Vuc2UsIHRoZXJlIGFyZSBvbmx5IDIgbW92aW5nIA0KcGFydHMgdGhhdCBoYXZlIHRv IGJlIG9wZXJhdGluZyBjb3JyZWN0bHkgLS0gdGhlIHBob25lIGl0c2VsZiwgYW5kIHRoZSBMMiAN CmFjY2VzcyBzd2l0Y2ggaXQgaXMgcGx1Z2dlZCBpbnRvLiAgRXZlbiB3aXRoIERIQ1AgdGhlcmUg aXMgYXQgbGVhc3QgdGhlIA0KbmV0d29yayBpbmZyYXN0cnVjdHVyZSwgYSBzZXJ2ZXIgc29tZXdo ZXJlLCBhbmQgb2Z0ZW4gREhDUCByZWxheSB0byBzZXQgdXAgDQp0byBnZXQgaXQgYWxsIHdvcmtp bmcuICBIRUxEIGhhcyBhIGJ1bmNoIG1vcmUgbWVjaGFuaWNzIHRoYXQgYWxsIG11c3QgYmUgDQp3 b3JraW5nIGNvcnJlY3RseSBvbiB0b3Agb2YgdGhhdC4gDQoNCj4gTUlHSFQgbGVhZCB0byBhbiBp bXBsaWVkIG9yZGVyaW5nLCBidXQgSSBkb27igJl0IHRoaW5rIGl04oCZcyBldmVuIHVzZWZ1bCB0 byANCnNheSB0aGF0LiAgSeKAmW0gbm90IHN1cmUgd2h5IGl0IG1hdHRlcnMuDQpJIHRlcm1zIG9m IHRoZSBwaG9uZSBiY3AsIHlvdSBhcmUgcHJvYmFibHkgcmlnaHQsIHNpbmNlIG90aGVyIE1VU1Rz IG1ha2UgDQpzdXJlIHRoYXQgdGhlcmUgaXMgYWx3YXlzIGV4YWN0bHkgb25lIGFuc3dlciBhbnl3 YXkuICBIb3dldmVyLCBkZXZpY2UgDQpkZXZlbG9wZXJzIHdpbGwgY2VydGFpbmx5IGNhcmUgLS0g Z2V0dGluZyBzdGFydHVwIHNlcXVlbmNlIHJpZ2h0IGlzIA0KaW1wb3J0YW50IGFuZCB3aWxsIG5v dCBiZSBpbW1lZGlhdGVseSBvYnZpb3VzIHRvIG1hbnkgbm90IGRlZXAgaW4gdGhlIA0KZGV0YWls cyBvZiBlYWNoIHBpZWNlLiAgVGhlIERTTCBGb3J1bSBkb2MgaXMgcmVhbGx5IGhlbHBmdWwgIGZy b20gdGhhdCANCnBlcnNwZWN0aXZlLiANCg0KLS0gUGV0ZXINCg0KDQoNCg0KDQoNCg0KIkJyaWFu IFJvc2VuIiA8YnJAYnJpYW5yb3Nlbi5uZXQ+DQoyNC4wOS4wNyAxNjoyMg0KIA0KICAgICAgICBU bzogICAgIDxwZXRlcl9ibGF0aGVyd2lja0BtaXRlbC5jb20+LCAiJ1N0YXJrLCBCYXJiYXJhJyIg DQo8YnM3NjUyQGF0dC5jb20+DQogICAgICAgIGNjOiAgICAgIidlY3JpdCciIDxlY3JpdEBpZXRm Lm9yZz4NCiAgICAgICAgU3ViamVjdDogICAgICAgIFJFOiBbRWNyaXRdIG11bHRpcGxlIGxvY2F0 aW9uIHNvdXJjZXMNCg0KDQpJ4oCZbSBub3Qgc3VyZSBob3cgeW91IGRlY2lkZWQgdGhhdCBMTERQ LU1FRCBoYXMgZmV3ZXIgbW92aW5nIHBhcnRzIG9yIGlzIA0KbW9yZSByZWxpYWJsZSB0aGFuIERI Q1AuICBJIHRoaW5rIGxpa2VseSBpdOKAmXMgdGhlIG90aGVyIHdheSByaWdodCBub3cuIA0KIA0K Q2VydGFpbmx5LCBpZiB5b3VyIGFyZSBhdXRvY29uZmlndXJpbmcgd2l0aCBMTERQLCB5b3Ugd2ls bCB3YW50IHRoYXQgdG8gDQpjb21wbGV0ZSBiZWZvcmUgeW91IGRvIERIQ1AuICBJIGRvbuKAmXQg dGhpbmsgd2UgaGF2ZSB0byBzYXkgdGhhdCwgYnV0IHdlIA0KY2FuIGlmIHdlIG5lZWQgdG8uIA0K IA0KSSBhZ3JlZSB5b3UgbmVlZCBhbiBJUCBhZGRyZXNzIGJlZm9yZSB5b3UgY2FuIGludm9rZSBI RUxELiAgSSBkb27igJl0IHRoaW5rIA0Kd2UgaGF2ZSB0byBzYXkgdGhhdC4NCiANClRoaXMgTUlH SFQgbGVhZCB0byBhbiBpbXBsaWVkIG9yZGVyaW5nLCBidXQgSSBkb27igJl0IHRoaW5rIGl04oCZ cyBldmVuIHVzZWZ1bCANCnRvIHNheSB0aGF0LiAgSeKAmW0gbm90IHN1cmUgd2h5IGl0IG1hdHRl cnMuDQogDQpCcmlhbg0KIA0KDQpGcm9tOiBwZXRlcl9ibGF0aGVyd2lja0BtaXRlbC5jb20gW21h aWx0bzpwZXRlcl9ibGF0aGVyd2lja0BtaXRlbC5jb21dIA0KU2VudDogTW9uZGF5LCBTZXB0ZW1i ZXIgMjQsIDIwMDcgMTI6NDkgUE0NClRvOiBTdGFyaywgQmFyYmFyYQ0KQ2M6IGVjcml0DQpTdWJq ZWN0OiBSRTogW0Vjcml0XSBtdWx0aXBsZSBsb2NhdGlvbiBzb3VyY2VzDQogDQoNCkhpLCANCkkg YWdyZWUgdGhhdCB0aGUgRFNMIEZvcnVtIGRvY3VtZW50IG1ha2VzIGEgdmVyeSBnb29kIHN0YXJ0 aW5nIHBvaW50IGZvciANCm9yZGVybHkgYWNxdWlzaXRpb24gb2YgbG9jYXRpb24gYXQgc3RhcnR1 cCwgYWNjb3VudGluZyBmb3IgYWxsIDMgbWV0aG9kcy4gDQpJIGFsc28gYmVsaWV2ZSBpdCBwb2lu dHMgdG8gYSBwcmVmZXJlbmNlIG9yZGVyLCBpZiB0aGVyZSBhcmUgbXVsdGlwbGUgDQphbnN3ZXJz IGNvbWluZyBiYWNrLCB3aGljaCBpcyBMTERQLU1FRCAtLT4gREhDUCAtLT4gSEVMRC4gIFJlYXNv bmluZyBmb3IgDQp0aGlzIG9yZGVyIChteSBvcGluaW9uKSBpcyB0aGF0IGl0IHByb2dyZXNzZXMg ZnJvbSAibGVhc3QgbW92aW5nIHBhcnRzIiAvIA0KbW9zdCByZWxpYWJsZSAoTExEUC1NRUQpIHRv IG1vc3QsIGFuZCBhbHNvIGZvbGxvd3MgdGhlIG5hdHVyYWwgbGF5ZXJpbmcgb2YgDQp0aGUgb3Zl cmFsbCBzeXN0ZW0gKEwyIC0tPiBMMi41IC0tPiBMNykuICAgSW4gdGhlIGVuZCwgb25seSBPTkUg bWV0aG9kIA0Kc2hvdWxkIGV2ZXIgYmUgc2VsZWN0ZWQsIGFzIHRoZSBzZXF1ZW5jZSBkaWFncmFt IHNob3dzLiAgIA0KDQpZb3VyIHBvaW50IGJlbG93LCB0aGF0IHRoZSBtZXRob2RzIGNhbiBhbmQg c2hvdWxkIHByb2dyZXNzIGluIHBhcmFsbGVsIGlzIA0KdmFsaWQuICBIb3dldmVyIHRoZXJlIGFy ZSBjb25zdHJhaW50cyB0byB0aGlzLCBub3RhYmx5OiANCg0KbyBJZiBMTERQLU1FRCBpcyBiZWlu ZyB1c2VkIHRvIGF1dG9jb25maWd1cmUgdm9pY2UgVkxBTiBJRCwgdGhlbiB0aGUgDQpkZXZpY2Ug c2hvdWxkIHdhaXQgdG8gc2VlIGlmIHRoYXQgc3RhZ2Ugc3VjY2VlZHMgYmVmb3JlIGNvbnRhY3Rp bmcgREhDUC4gDQpPdGhlcndpc2UsIHRoZSBkZXZpY2UgbWF5IGdldCBhbiBJUCBhZGRyZXNzIG9u IHRoZSBkZWZhdWx0IFZMQU4sIG9ubHkgdG8gDQpoYXZlIHRvIGRyb3AgaXQgYW5kIHRyeSBhZ2Fp biBvbiB0aGUgdm9pY2UgVkxBTi4gIElmIGl0IGhhZCBzdGFydGVkIHRvIHVzZSANCnRoaXMgYWRk cmVzcyBmb3Igc29tZXRoaW5nIGFscmVhZHkgKHNheSBmb3IgSEVMRCksIHRoZW4gb25nb2luZyAN CmludGVyYWN0aW9uIHdvdWxkIGJlIGRyb3BwZWQgYW5kIGNvbmZ1c2lvbiB3b3VsZCBsaWtlbHkg ZW5zdWUuICAgDQoNCm8gQmVmb3JlIEhFTEQgY2FuIHdvcmssIGFuIElQIGFkZHJlc3MgaXMgbmVl ZGVkLiAgIA0KDQpJIHRoaW5rIHRoZXNlIGNvbnN0cmFpbnRzIGFyZSByZWFsbHkganVzdCBhIHJl ZmxlY3Rpb24gb2YgdGhlIG5hdHVyYWwgDQpsYXllcmluZyBpbiB0aGUgZW5kLiAgIA0KDQpJTUhP LCBvcmRlcmx5IHN0YXJ0dXAgYmVhdHMgdGhlIGZldyBleHRyYSBzZWNvbmRzIGRlbGF5IGluY3Vy cmVkIGluIG1ha2luZyANCnN1cmUgdGhlIGNvbnN0cmFpbnRzIGFyZSBub3QgYnJva2VuLiAgIFdl IGFyZSBvbmx5IHRhbGtpbmcgYWJvdXQgYSB2ZXJ5IA0KZmV3IHNlY29uZHMgaGVyZSBhZnRlciBh bGwuICAgDQoNCi0tIFBldGVyIA0KDQoNCg0KDQoNCiANCiJTdGFyaywgQmFyYmFyYSIgPGJzNzY1 MkBhdHQuY29tPiANCjI0LjA5LjA3IDA4OjQ4IA0KICAgICAgICANCiAgICAgICAgVG86ICAgICAg ICAiV2ludGVyYm90dG9tLCBKYW1lcyIgPEphbWVzLldpbnRlcmJvdHRvbUBhbmRyZXcuY29tPiwg DQoiS2FybCBIZWlueiBXb2xmIiA8a2h3b2xmMUBnbWFpbC5jb20+LCAiZWNyaXQiIDxlY3JpdEBp ZXRmLm9yZz4gDQogICAgICAgIGNjOiAgICAgICAgIA0KICAgICAgICBTdWJqZWN0OiAgICAgICAg UkU6IFtFY3JpdF0gbXVsdGlwbGUgbG9jYXRpb24gc291cmNlcw0KDQoNCg0KSXQncyBub3QgYWx3 YXlzIGRlc2lyYWJsZSB0byB3YWl0IGZvciBhIHByb3RvY29sIHRvIHRpbWUtb3V0LCBiZWZvcmUg DQpsYXVuY2hpbmcgdGhlIG5leHQgcHJvdG9jb2wuIFNwZWNpZmljYWxseSwgaWYgYSBkZXZpY2Ug aXMgY29uZmlndXJlZCB0byBkbyANCkRIQ1AgZm9yIElQIGFkZHJlc3MgY29uZmlndXJhdGlvbiwg aXQgc2hvdWxkIGxhdW5jaCBpdHMgREhDUCBkaXNjb3ZlcnkgDQpBU0FQLCB3aXRoIG9wdGlvbnMs IGluc3RlYWQgb2Ygd2FpdGluZyB0aGUgNCBvciA1IHNlY29uZHMgZm9yIExMRFAtTUVEIHRvIA0K dGltZSBvdXQuIFRoaXMgcHJldmVudHMgdW5uZWNlc3NhcnkgZGVsYXlzIGluIHRoZSBib290c3Ry YXAgcHJvY2Vzcy4gSXQgDQpzaG91bGQgYmUgZWFzeSBlbm91Z2ggZm9yIHRoZSBkZXZpY2UgdG8g dXNlIGEgcmVjZWl2ZWQgTExEUC1NRUQgbG9jYXRpb24sIA0KZXZlbiBpZiBpdCBhcnJpdmVzIGFm dGVyIHRoZSBESENQIHJlc3BvbnNlLiANCkJhcmJhcmEgDQogIA0KLS0tLS0tLS0tLS0tLS0tLS0t LS0gDQogW0FKV10gTXkgZmlyc3QgcXVlc3Rpb24gaXMgd2h5IGFyZSB5b3UgdXNpbmcgbW9yZSB0 aGFuIG9uZSBhY3F1aXNpdGlvbiANCnByb3RvY29sLiBNeSB0aG91Z2h0cyB3b3VsZCBiZSB1c2Ug b25lLCBpZiBpdCBmYWlscywgcGljayBhIGRpZmZlcmVudCBvbmUuIA0KTmV2ZXIgaW52b2tlIGJv dGggYXQgdGhlIHNhbWUgdGltZSBzbyB5b3UgaGF2ZSB0aGlzIHByb2JsZW0gb2YgY2hvaWNlLiAN CiANCioqKioqIA0KVGhlIGluZm9ybWF0aW9uIHRyYW5zbWl0dGVkIGlzIGludGVuZGVkIG9ubHkg Zm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHRvIA0Kd2hpY2ggaXQgaXMgYWRkcmVzc2VkIGFuZCBt YXkgY29udGFpbiBjb25maWRlbnRpYWwsIHByb3ByaWV0YXJ5LCBhbmQvb3IgDQpwcml2aWxlZ2Vk IG1hdGVyaWFsLiBBbnkgcmV2aWV3LCByZXRyYW5zbWlzc2lvbiwgZGlzc2VtaW5hdGlvbiBvciBv dGhlciANCnVzZSBvZiwgb3IgdGFraW5nIG9mIGFueSBhY3Rpb24gaW4gcmVsaWFuY2UgdXBvbiB0 aGlzIGluZm9ybWF0aW9uIGJ5IA0KcGVyc29ucyBvciBlbnRpdGllcyBvdGhlciB0aGFuIHRoZSBp bnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgDQp5b3UgcmVjZWl2ZWQgdGhpcyBp biBlcnJvciwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoZSANCm1hdGVy aWFsIGZyb20gYWxsIGNvbXB1dGVycy4gR0E2MjMNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpFY3JpdCBtYWlsaW5nIGxpc3QNCkVjcml0QGlldGYub3Jn DQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQo= --=_alternative 0071180385257360_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgPC9mb250Pjxmb250IHNp emU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5J4oCZbQ0Kbm90IHN1cmUgaG93IHlvdSBkZWNp ZGVkIHRoYXQgTExEUC1NRUQgaGFzIGZld2VyIG1vdmluZyBwYXJ0cyBvciBpcyBtb3JlDQpyZWxp YWJsZSB0aGFuIERIQ1A8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PkxMRFAgaXMgcnVubmluZyBhdCB0aGUgb3RoZXIgZW5kIG9mDQp0aGUgcGh5c2ljYWwgd2lyZSB0 aGUgZGV2aWNlIGluIHF1ZXN0aW9uIGlzIHBsdWdnZWQgaW50by4gJm5ic3A7KEluIHRoZQ0KY2Fz ZSBvZiB3aXJlbGVzcywgaXQgaXMgbGlrZWx5IGF0IHRoZSBhY2Nlc3MgcG9pbnQsIG9yIGp1c3Qg YmVoaW5kIGl0LikNCiZuYnNwO0luIHRoYXQgc2Vuc2UsIHRoZXJlIGFyZSBvbmx5IDIgbW92aW5n IHBhcnRzIHRoYXQgaGF2ZSB0byBiZSBvcGVyYXRpbmcNCmNvcnJlY3RseSAtLSB0aGUgcGhvbmUg aXRzZWxmLCBhbmQgdGhlIEwyIGFjY2VzcyBzd2l0Y2ggaXQgaXMgcGx1Z2dlZCBpbnRvLg0KJm5i c3A7RXZlbiB3aXRoIERIQ1AgdGhlcmUgaXMgYXQgbGVhc3QgdGhlIG5ldHdvcmsgaW5mcmFzdHJ1 Y3R1cmUsIGEgc2VydmVyDQpzb21ld2hlcmUsIGFuZCBvZnRlbiBESENQIHJlbGF5IHRvIHNldCB1 cCB0byBnZXQgaXQgYWxsIHdvcmtpbmcuICZuYnNwO0hFTEQNCmhhcyBhIGJ1bmNoIG1vcmUgbWVj aGFuaWNzIHRoYXQgYWxsIG11c3QgYmUgd29ya2luZyBjb3JyZWN0bHkgb24gdG9wIG9mDQp0aGF0 LiAmbmJzcDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PiZndDsgPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5NSUdIVA0K bGVhZCB0byBhbiBpbXBsaWVkIG9yZGVyaW5nLCBidXQgSSBkb27igJl0IHRoaW5rIGl04oCZcyBl dmVuIHVzZWZ1bCB0byBzYXkNCnRoYXQuICZuYnNwO0nigJltIG5vdCBzdXJlIHdoeSBpdCBtYXR0 ZXJzLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSB0ZXJtcyBv ZiB0aGUgcGhvbmUgYmNwLCB5b3UgYXJlIHByb2JhYmx5DQpyaWdodCwgc2luY2Ugb3RoZXIgTVVT VHMgbWFrZSBzdXJlIHRoYXQgdGhlcmUgaXMgYWx3YXlzIGV4YWN0bHkgb25lIGFuc3dlcg0KYW55 d2F5LiAmbmJzcDtIb3dldmVyLCBkZXZpY2UgZGV2ZWxvcGVycyB3aWxsIGNlcnRhaW5seSBjYXJl IC0tIGdldHRpbmcNCnN0YXJ0dXAgc2VxdWVuY2UgcmlnaHQgaXMgaW1wb3J0YW50IGFuZCB3aWxs IG5vdCBiZSBpbW1lZGlhdGVseSBvYnZpb3VzDQp0byBtYW55IG5vdCBkZWVwIGluIHRoZSBkZXRh aWxzIG9mIGVhY2ggcGllY2UuICZuYnNwO1RoZSBEU0wgRm9ydW0gZG9jDQppcyA8aT5yZWFsbHkg aGVscGZ1bDwvaT4gJm5ic3A7ZnJvbSB0aGF0IHBlcnNwZWN0aXZlLiAmbmJzcDs8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi0tIFBldGVyPC9mb250Pg0K PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ PGI+JnF1b3Q7QnJpYW4gUm9zZW4mcXVvdDsgJmx0O2JyQGJyaWFucm9zZW4ubmV0Jmd0OzwvYj48 L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjQuMDkuMDcgMTY6MjI8 L2ZvbnQ+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVG86DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm bHQ7cGV0ZXJfYmxhdGhlcndpY2tAbWl0ZWwuY29tJmd0OywNCiZxdW90OydTdGFyaywgQmFyYmFy YScmcXVvdDsgJmx0O2JzNzY1MkBhdHQuY29tJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNjOg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7J2Vjcml0JyZxdW90OyAmbHQ7ZWNyaXRAaWV0Zi5v cmcmZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgU3ViamVjdDoNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O1JFOiBbRWNyaXRdIG11bHRpcGxlIGxvY2F0aW9uIHNvdXJjZXM8L2ZvbnQ+PC90YWJsZT4NCjxi cj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+SeKAmW0g bm90IHN1cmUgaG93IHlvdSBkZWNpZGVkDQp0aGF0IExMRFAtTUVEIGhhcyBmZXdlciBtb3Zpbmcg cGFydHMgb3IgaXMgbW9yZSByZWxpYWJsZSB0aGFuIERIQ1AuICZuYnNwO0kNCnRoaW5rIGxpa2Vs eSBpdOKAmXMgdGhlIG90aGVyIHdheSByaWdodCBub3cuICZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj5DZXJ0YWlubHksIGlmIHlvdXIgYXJlIGF1 dG9jb25maWd1cmluZw0Kd2l0aCBMTERQLCB5b3Ugd2lsbCB3YW50IHRoYXQgdG8gY29tcGxldGUg YmVmb3JlIHlvdSBkbyBESENQLiAmbmJzcDtJIGRvbuKAmXQNCnRoaW5rIHdlIGhhdmUgdG8gc2F5 IHRoYXQsIGJ1dCB3ZSBjYW4gaWYgd2UgbmVlZCB0by4gJm5ic3A7PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPkkgYWdyZWUgeW91IG5lZWQgYW4gSVAgYWRk cmVzcw0KYmVmb3JlIHlvdSBjYW4gaW52b2tlIEhFTEQuICZuYnNwO0kgZG9u4oCZdCB0aGluayB3 ZSBoYXZlIHRvIHNheSB0aGF0LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBm YWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZh Y2U9IkFyaWFsIj5UaGlzIE1JR0hUIGxlYWQgdG8gYW4gaW1wbGllZA0Kb3JkZXJpbmcsIGJ1dCBJ IGRvbuKAmXQgdGhpbmsgaXTigJlzIGV2ZW4gdXNlZnVsIHRvIHNheSB0aGF0LiAmbmJzcDtJ4oCZ bQ0Kbm90IHN1cmUgd2h5IGl0IG1hdHRlcnMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xv cj1ibHVlIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9y PWJsdWUgZmFjZT0iQXJpYWwiPkJyaWFuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1i bHVlIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8ZGl2IGFsaWduPWNlbnRlcj4NCjxicj4N Cjxocj48L2Rpdj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwvYj4g cGV0ZXJfYmxhdGhlcndpY2tAbWl0ZWwuY29tDQpbbWFpbHRvOnBldGVyX2JsYXRoZXJ3aWNrQG1p dGVsLmNvbV0gPGI+PGJyPg0KU2VudDo8L2I+IE1vbmRheSwgU2VwdGVtYmVyIDI0LCAyMDA3IDEy OjQ5IFBNPGI+PGJyPg0KVG86PC9iPiBTdGFyaywgQmFyYmFyYTxiPjxicj4NCkNjOjwvYj4gZWNy aXQ8Yj48YnI+DQpTdWJqZWN0OjwvYj4gUkU6IFtFY3JpdF0gbXVsdGlwbGUgbG9jYXRpb24gc291 cmNlczwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkhpLDwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpJIGFncmVlIHRoYXQgdGhlIERTTCBGb3J1bSBk b2N1bWVudCBtYWtlcyBhIHZlcnkgZ29vZCBzdGFydGluZyBwb2ludCBmb3INCm9yZGVybHkgYWNx dWlzaXRpb24gb2YgbG9jYXRpb24gYXQgc3RhcnR1cCwgYWNjb3VudGluZyBmb3IgYWxsIDMgbWV0 aG9kcy4NCiZuYnNwO0kgYWxzbyBiZWxpZXZlIGl0IHBvaW50cyB0byBhIHByZWZlcmVuY2Ugb3Jk ZXIsIGlmIHRoZXJlIGFyZSBtdWx0aXBsZQ0KYW5zd2VycyBjb21pbmcgYmFjaywgd2hpY2ggaXMg TExEUC1NRUQgLS0mZ3Q7IERIQ1AgLS0mZ3Q7IEhFTEQuICZuYnNwO1JlYXNvbmluZw0KZm9yIHRo aXMgb3JkZXIgKG15IG9waW5pb24pIGlzIHRoYXQgaXQgcHJvZ3Jlc3NlcyBmcm9tICZxdW90O2xl YXN0IG1vdmluZw0KcGFydHMmcXVvdDsgLyBtb3N0IHJlbGlhYmxlIChMTERQLU1FRCkgdG8gbW9z dCwgYW5kIGFsc28gZm9sbG93cyB0aGUgbmF0dXJhbA0KbGF5ZXJpbmcgb2YgdGhlIG92ZXJhbGwg c3lzdGVtIChMMiAtLSZndDsgTDIuNSAtLSZndDsgTDcpLiAmbmJzcDsgSW4gdGhlDQplbmQsIG9u bHkgT05FIG1ldGhvZCBzaG91bGQgZXZlciBiZSBzZWxlY3RlZCwgYXMgdGhlIHNlcXVlbmNlIGRp YWdyYW0gc2hvd3MuDQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K WW91ciBwb2ludCBiZWxvdywgdGhhdCB0aGUgbWV0aG9kcyBjYW4gYW5kIHNob3VsZCBwcm9ncmVz cyBpbiBwYXJhbGxlbA0KaXMgdmFsaWQuICZuYnNwO0hvd2V2ZXIgdGhlcmUgYXJlIGNvbnN0cmFp bnRzIHRvIHRoaXMsIG5vdGFibHk6IDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N Cm8gSWYgTExEUC1NRUQgaXMgYmVpbmcgdXNlZCB0byBhdXRvY29uZmlndXJlIHZvaWNlIFZMQU4g SUQsIHRoZW4gdGhlIGRldmljZQ0Kc2hvdWxkIHdhaXQgdG8gc2VlIGlmIHRoYXQgc3RhZ2Ugc3Vj Y2VlZHMgYmVmb3JlIGNvbnRhY3RpbmcgREhDUC4gJm5ic3A7T3RoZXJ3aXNlLA0KdGhlIGRldmlj ZSBtYXkgZ2V0IGFuIElQIGFkZHJlc3Mgb24gdGhlIGRlZmF1bHQgVkxBTiwgb25seSB0byBoYXZl IHRvIGRyb3ANCml0IGFuZCB0cnkgYWdhaW4gb24gdGhlIHZvaWNlIFZMQU4uICZuYnNwO0lmIGl0 IGhhZCBzdGFydGVkIHRvIHVzZSB0aGlzDQphZGRyZXNzIGZvciBzb21ldGhpbmcgYWxyZWFkeSAo c2F5IGZvciBIRUxEKSwgdGhlbiBvbmdvaW5nIGludGVyYWN0aW9uDQp3b3VsZCBiZSBkcm9wcGVk IGFuZCBjb25mdXNpb24gd291bGQgbGlrZWx5IGVuc3VlLiAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPjxicj4NCm8gQmVmb3JlIEhFTEQgY2FuIHdvcmssIGFuIElQIGFkZHJl c3MgaXMgbmVlZGVkLiAmbmJzcDsgPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K SSB0aGluayB0aGVzZSBjb25zdHJhaW50cyBhcmUgcmVhbGx5IGp1c3QgYSByZWZsZWN0aW9uIG9m IHRoZSBuYXR1cmFsIGxheWVyaW5nDQppbiB0aGUgZW5kLiAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KSU1ITywgb3JkZXJseSBzdGFydHVwIGJlYXRzIHRoZSBmZXcg ZXh0cmEgc2Vjb25kcyBkZWxheSBpbmN1cnJlZCBpbiBtYWtpbmcNCnN1cmUgdGhlIGNvbnN0cmFp bnRzIGFyZSBub3QgYnJva2VuLiAmbmJzcDsgV2UgYXJlIG9ubHkgdGFsa2luZyBhYm91dCBhDQp2 ZXJ5IGZldyBzZWNvbmRzIGhlcmUgYWZ0ZXIgYWxsLiAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPjxicj4NCi0tIFBldGVyIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8cD4NCjx0YWJs ZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MCU+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPHRkIHdpZHRoPTIzJT48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7U3RhcmssIEJhcmJhcmEmcXVvdDsN CiZsdDticzc2NTJAYXR0LmNvbSZndDs8L2I+PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPiA8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ MjQuMDkuMDcgMDg6NDg8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ DQo8L2ZvbnQ+DQo8dGQgd2lkdGg9NzUlPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RvOiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmcXVvdDtXaW50ZXJib3R0b20sDQpKYW1lcyZxdW90OyAmbHQ7SmFtZXMuV2lu dGVyYm90dG9tQGFuZHJldy5jb20mZ3Q7LCAmcXVvdDtLYXJsIEhlaW56IFdvbGYmcXVvdDsNCiZs dDtraHdvbGYxQGdtYWlsLmNvbSZndDssICZxdW90O2Vjcml0JnF1b3Q7ICZsdDtlY3JpdEBpZXRm Lm9yZyZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtjYzogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U3ViamVjdDogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UkU6IFtFY3JpdF0NCm11bHRpcGxlIGxvY2F0aW9uIHNv dXJjZXM8L2ZvbnQ+PC90YWJsZT4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQXJp YWwiPjxicj4NCkl0J3Mgbm90IGFsd2F5cyBkZXNpcmFibGUgdG8gd2FpdCBmb3IgYSBwcm90b2Nv bCB0byB0aW1lLW91dCwgYmVmb3JlIGxhdW5jaGluZw0KdGhlIG5leHQgcHJvdG9jb2wuIFNwZWNp ZmljYWxseSwgaWYgYSBkZXZpY2UgaXMgY29uZmlndXJlZCB0byBkbyBESENQIGZvcg0KSVAgYWRk cmVzcyBjb25maWd1cmF0aW9uLCBpdCBzaG91bGQgbGF1bmNoIGl0cyBESENQIGRpc2NvdmVyeSBB U0FQLCB3aXRoDQpvcHRpb25zLCBpbnN0ZWFkIG9mIHdhaXRpbmcgdGhlIDQgb3IgNSBzZWNvbmRz IGZvciBMTERQLU1FRCB0byB0aW1lIG91dC4NClRoaXMgcHJldmVudHMgdW5uZWNlc3NhcnkgZGVs YXlzIGluIHRoZSBib290c3RyYXAgcHJvY2Vzcy4gSXQgc2hvdWxkIGJlDQplYXN5IGVub3VnaCBm b3IgdGhlIGRldmljZSB0byB1c2UgYSByZWNlaXZlZCBMTERQLU1FRCBsb2NhdGlvbiwgZXZlbiBp Zg0KaXQgYXJyaXZlcyBhZnRlciB0aGUgREhDUCByZXNwb25zZS48L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUg ZmFjZT0iQXJpYWwiPjxicj4NCkJhcmJhcmE8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+IDxicj4NCiAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUg ZmFjZT0iQXJpYWwiPjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tIDwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiBbQUpXXSBNeSBmaXJzdCBxdWVzdGlvbiBpcyB3 aHkgYXJlIHlvdSB1c2luZyBtb3JlIHRoYW4gb25lIGFjcXVpc2l0aW9uDQpwcm90b2NvbC4gTXkg dGhvdWdodHMgd291bGQgYmUgdXNlIG9uZSwgaWYgaXQgZmFpbHMsIHBpY2sgYSBkaWZmZXJlbnQg b25lLg0KTmV2ZXIgaW52b2tlIGJvdGggYXQgdGhlIHNhbWUgdGltZSBzbyB5b3UgaGF2ZSB0aGlz IHByb2JsZW0gb2YgY2hvaWNlLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj4NCjxicj4NCiAmbmJzcDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgZmFjZT0iVGFob21h Ij4qKioqKjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9u dD4NCjxwPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPlRoZSBpbmZvcm1hdGlvbiB0cmFuc21p dHRlZCBpcyBpbnRlbmRlZCBvbmx5DQpmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgdG8gd2hpY2gg aXQgaXMgYWRkcmVzc2VkIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwsDQpwcm9wcmlldGFy eSwgYW5kL29yIHByaXZpbGVnZWQgbWF0ZXJpYWwuIEFueSByZXZpZXcsIHJldHJhbnNtaXNzaW9u LCBkaXNzZW1pbmF0aW9uDQpvciBvdGhlciB1c2Ugb2YsIG9yIHRha2luZyBvZiBhbnkgYWN0aW9u IGluIHJlbGlhbmNlIHVwb24gdGhpcyBpbmZvcm1hdGlvbg0KYnkgcGVyc29ucyBvciBlbnRpdGll cyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4NCklmIHlv dSByZWNlaXZlZCB0aGlzIGluIGVycm9yLCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBk ZWxldGUgdGhlDQptYXRlcmlhbCBmcm9tIGFsbCBjb21wdXRlcnMuIEdBNjIzPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpFY3JpdCBtYWlsaW5nIGxpc3Q8YnI+DQpFY3JpdEBpZXRm Lm9yZzxicj4NCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0PC9m b250Pg0KPHA+DQo= --=_alternative 0071180385257360_=-- --===============0987395133== 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 --===============0987395133==-- From ecrit-bounces@ietf.org Mon Sep 24 16:40:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZujG-0006xs-Jx; Mon, 24 Sep 2007 16:40:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZujF-0006xB-Jy for ecrit@ietf.org; Mon, 24 Sep 2007 16:40:29 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IZujE-0007CZ-CM for ecrit@ietf.org; Mon, 24 Sep 2007 16:40:29 -0400 Received: (qmail invoked by alias); 24 Sep 2007 20:40:26 -0000 Received: from p54986D53.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.109.83] by mail.gmx.net (mp037) with SMTP; 24 Sep 2007 22:40:26 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19NF6Q3YeNNByB80pb1BEoDxxkZGujY1XOR/iakE7 rlyJpZ8MTLF0/w Message-ID: <46F820BA.8070406@gmx.net> Date: Mon, 24 Sep 2007 22:40:26 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "'Peterson, Jon'" , iesg-secretary@ietf.org References: <014d01c7fee9$be708a30$220d0d0a@amer.cisco.com> In-Reply-To: <014d01c7fee9$be708a30$220d0d0a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: 'ECRIT' Subject: [Ecrit] PROTO write-up for draft-ietf-ecrit-mapping-arch-02.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 PROTO WRITEUP for draft-ietf-ecrit-mapping-arch-02 ================================================== (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Document Shepherd is Hannes Tschofenig (Hannes.Tschofenig@gmx.net). The document is ready for publications and I have reviewed the document personally. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The LoST mapping architecture document describes how the LoST protocol can be used to deploy a globally distributed architecture for mapping location information to URIs of Public Safety Answering Points (PSAPs). This document has been subject to reviews together with the LoST specification. There are no concerns with the document. The WGLC was posted on 16 August 2007. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? There are no concerns with the document. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There are no concerns. No IPR has been disclosed with regard to this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is consensus behind this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The document does not contain nits. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The document has references split into normative and informative references. There are no downward references. (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? An IANA consideration section exists but is not needed since this document does not require actions by IANA. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no such sections in the document. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. Document Announcement Write-Up for draft-ietf-ecrit-mapping-arch-02 Technical Summary The Location-to-URL mapping architecture document describes an architecture for a global, scalable, resilient and administratively distributed system for mapping geographic location information to URLs, using the Location-to-Service (LoST) protocol. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. Working Group Summary There is consensus in the WG to publish this document. Document Quality The LoST protocol has been implemented and the interaction between LoST nodes, as described in this document, has been tested. Personnel Hannes Tschofenig is the document shepherd for this document. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 24 16:44:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZumT-0000eq-H8; Mon, 24 Sep 2007 16:43:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZumS-0000cq-8J for ecrit@ietf.org; Mon, 24 Sep 2007 16:43:48 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZumL-0005BE-Kq for ecrit@ietf.org; Mon, 24 Sep 2007 16:43:48 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IZulx-0005ku-Si; Mon, 24 Sep 2007 15:43:18 -0500 From: "Brian Rosen" To: References: <194701c7fee8$927a12d0$640fa8c0@cis.neustar.com> Subject: RE: [Ecrit] multiple location sources Date: Mon, 24 Sep 2007 16:43:25 -0400 Message-ID: <19aa01c7feeb$90c88ae0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acf+6mvvfdfiVsj+SRWgXWkwKUNklAAAMBSg In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 04ebe73024b6be81174765e91aced811 Cc: 'ecrit' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0219474132==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0219474132== Content-Type: multipart/alternative; boundary="----=_NextPart_000_19AB_01C7FECA.09B6EAE0" This is a multi-part message in MIME format. ------=_NextPart_000_19AB_01C7FECA.09B6EAE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I understand the "moving parts" now. Clearly, DHCP is much more mature and likely to work today than LLDP-MED is. I think the emergency call documentation is not the place to educate device developers of how startup sequences involving LLDP, DHCP and HTTP based protocols could best be done. Brian _____ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Monday, September 24, 2007 4:35 PM To: Brian Rosen Cc: 'Stark, Barbara'; 'ecrit' Subject: RE: [Ecrit] multiple location sources > I'm not sure how you decided that LLDP-MED has fewer moving parts or is more reliable than DHCP LLDP is running at the other end of the physical wire the device in question is plugged into. (In the case of wireless, it is likely at the access point, or just behind it.) In that sense, there are only 2 moving parts that have to be operating correctly -- the phone itself, and the L2 access switch it is plugged into. Even with DHCP there is at least the network infrastructure, a server somewhere, and often DHCP relay to set up to get it all working. HELD has a bunch more mechanics that all must be working correctly on top of that. > MIGHT lead to an implied ordering, but I don't think it's even useful to say that. I'm not sure why it matters. I terms of the phone bcp, you are probably right, since other MUSTs make sure that there is always exactly one answer anyway. However, device developers will certainly care -- getting startup sequence right is important and will not be immediately obvious to many not deep in the details of each piece. The DSL Forum doc is really helpful from that perspective. -- Peter "Brian Rosen" 24.09.07 16:22 To: , "'Stark, Barbara'" cc: "'ecrit'" Subject: RE: [Ecrit] multiple location sources I'm not sure how you decided that LLDP-MED has fewer moving parts or is more reliable than DHCP. I think likely it's the other way right now. Certainly, if your are autoconfiguring with LLDP, you will want that to complete before you do DHCP. I don't think we have to say that, but we can if we need to. I agree you need an IP address before you can invoke HELD. I don't think we have to say that. This MIGHT lead to an implied ordering, but I don't think it's even useful to say that. I'm not sure why it matters. Brian _____ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Monday, September 24, 2007 12:49 PM To: Stark, Barbara Cc: ecrit Subject: RE: [Ecrit] multiple location sources Hi, I agree that the DSL Forum document makes a very good starting point for orderly acquisition of location at startup, accounting for all 3 methods. I also believe it points to a preference order, if there are multiple answers coming back, which is LLDP-MED --> DHCP --> HELD. Reasoning for this order (my opinion) is that it progresses from "least moving parts" / most reliable (LLDP-MED) to most, and also follows the natural layering of the overall system (L2 --> L2.5 --> L7). In the end, only ONE method should ever be selected, as the sequence diagram shows. Your point below, that the methods can and should progress in parallel is valid. However there are constraints to this, notably: o If LLDP-MED is being used to autoconfigure voice VLAN ID, then the device should wait to see if that stage succeeds before contacting DHCP. Otherwise, the device may get an IP address on the default VLAN, only to have to drop it and try again on the voice VLAN. If it had started to use this address for something already (say for HELD), then ongoing interaction would be dropped and confusion would likely ensue. o Before HELD can work, an IP address is needed. I think these constraints are really just a reflection of the natural layering in the end. IMHO, orderly startup beats the few extra seconds delay incurred in making sure the constraints are not broken. We are only talking about a very few seconds here after all. -- Peter "Stark, Barbara" 24.09.07 08:48 To: "Winterbottom, James" , "Karl Heinz Wolf" , "ecrit" cc: Subject: RE: [Ecrit] multiple location sources It's not always desirable to wait for a protocol to time-out, before launching the next protocol. Specifically, if a device is configured to do DHCP for IP address configuration, it should launch its DHCP discovery ASAP, with options, instead of waiting the 4 or 5 seconds for LLDP-MED to time out. This prevents unnecessary delays in the bootstrap process. It should be easy enough for the device to use a received LLDP-MED location, even if it arrives after the DHCP response. Barbara -------------------- [AJW] My first question is why are you using more than one acquisition protocol. My thoughts would be use one, if it fails, pick a different one. Never invoke both at the same time so you have this problem of choice. ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623_______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------=_NextPart_000_19AB_01C7FECA.09B6EAE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I understand the “moving = parts” now.  Clearly, DHCP is much more mature and likely to work today than LLDP-MED = is.

 

I think the emergency call = documentation is not the place to educate device developers of how startup sequences involving LLDP, DHCP and HTTP based protocols could best be = done.

 

Brian

 

From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Monday, September = 24, 2007 4:35 PM
To: Brian Rosen
Cc: 'Stark, Barbara'; = 'ecrit'
Subject: RE: [Ecrit] = multiple location sources

 


> I’m not = sure how you decided that LLDP-MED has fewer moving parts or is more reliable than = DHCP
LLDP is running at the other end of the physical wire the device in question = is plugged into.  (In the case of wireless, it is likely at the access = point, or just behind it.)  In that sense, there are only 2 moving parts = that have to be operating correctly -- the phone itself, and the L2 access = switch it is plugged into.  Even with DHCP there is at least the network infrastructure, a server somewhere, and often DHCP relay to set up to = get it all working.  HELD has a bunch more mechanics that all must be = working correctly on top of that.  

> MIGHT lead to an implied ordering, but I = don’t think it’s even useful to say that.  I’m not sure why = it matters.
I terms of the phone bcp, you are probably right, since other MUSTs make = sure that there is always exactly one answer anyway.  However, device developers will certainly care -- getting startup sequence right is = important and will not be immediately obvious to many not deep in the details of = each piece.  The DSL Forum doc is really helpful  from that perspective.   =

-- Peter




 

"Brian Rosen" <br@brianrosen.net>

24.09.07 16:22

       
        To:       =  <peter_blatherwick@mitel.com>, "'Stark, Barbara'" <bs7652@att.com>
        cc:       =  "'ecrit'" <ecrit@ietf.org>
        Subject:        RE: [Ecrit] = multiple location sources




I’m not sure how you decided that = LLDP-MED has fewer moving parts or is more reliable than DHCP.  I think likely = it’s the other way right now.  
 
Certainly, if your are autoconfiguring with LLDP, you = will want that to complete before you do DHCP.  I don’t think we = have to say that, but we can if we need to.  
 
I agree you need an IP address before you can invoke = HELD.  I don’t think we have to say that.
 
This MIGHT lead to an implied ordering, but I = don’t think it’s even useful to say that.  I’m not sure why it = matters.
 
Brian
 

 


From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] =
Sent: Monday, September 24, 2007 12:49 PM
To: Stark, Barbara
Cc: ecrit
Subject: RE: [Ecrit] multiple location sources =
 

Hi,
I agree that the DSL Forum document makes a very good starting point for orderly acquisition of location at startup, accounting for all 3 = methods.  I also believe it points to a preference order, if there are multiple = answers coming back, which is LLDP-MED --> DHCP --> HELD.  Reasoning = for this order (my opinion) is that it progresses from "least moving parts" / most reliable (LLDP-MED) to most, and also follows the = natural layering of the overall system (L2 --> L2.5 --> L7).   In the = end, only ONE method should ever be selected, as the sequence diagram shows. =  

Your point below, that the methods can and should progress in parallel = is valid.  However there are constraints to this, notably: =

o If LLDP-MED is being used to autoconfigure voice VLAN ID, then the = device should wait to see if that stage succeeds before contacting DHCP. =  Otherwise, the device may get an IP address on the default VLAN, only to have to = drop it and try again on the voice VLAN.  If it had started to use this = address for something already (say for HELD), then ongoing interaction would be = dropped and confusion would likely ensue.  

o Before HELD can work, an IP address is needed.   =

I think these constraints are really just a reflection of the natural = layering in the end.  

IMHO, orderly startup beats the few extra seconds delay incurred in = making sure the constraints are not broken.   We are only talking about a very = few seconds here after all.  

-- Peter


 

"Stark, = Barbara" <bs7652@att.com>

24.09.07 08:48

       
       To:       =  "Winterbottom, James" <James.Winterbottom@andrew.com>, "Karl Heinz Wolf" <khwolf1@gmail.com>, "ecrit" <ecrit@ietf.org>
       cc:       =  
       Subject:        RE: = [Ecrit] multiple location sources





It's not always desirable to wait for a protocol to time-out, before = launching the next protocol. Specifically, if a device is configured to do DHCP = for IP address configuration, it should launch its DHCP discovery ASAP, with = options, instead of waiting the 4 or 5 seconds for LLDP-MED to time out. This = prevents unnecessary delays in the bootstrap process. It should be easy enough = for the device to use a received LLDP-MED location, even if it arrives after the = DHCP response.
Barbara
 
--------------------
[AJW] My first question is why are you using more than one acquisition protocol. My thoughts would be use one, if it fails, pick a different = one. Never invoke both at the same time so you have this problem of = choice.
 

*****

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

------=_NextPart_000_19AB_01C7FECA.09B6EAE0-- --===============0219474132== 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 --===============0219474132==-- From ecrit-bounces@ietf.org Mon Sep 24 18:19:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZwEv-0005mJ-MH; Mon, 24 Sep 2007 18:17:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZwEu-0005lw-Le for ecrit@ietf.org; Mon, 24 Sep 2007 18:17:16 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IZwEt-0000sg-Te for ecrit@ietf.org; Mon, 24 Sep 2007 18:17:16 -0400 Received: (qmail invoked by alias); 24 Sep 2007 22:17:14 -0000 Received: from p54986D53.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.109.83] by mail.gmx.net (mp042) with SMTP; 25 Sep 2007 00:17:14 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/3U+ho0S33K/CX6+tpJVqGRqccIBWnE93XpPN4kS q8tpVeOXlI0yWn Message-ID: <46F8376A.8060305@gmx.net> Date: Tue, 25 Sep 2007 00:17:14 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ECRIT , dime@ietf.org, keyprov@ietf.org, "nsis@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Ecrit] [Fwd: Deployment of the Internet-Draft Submission Tool] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org FYI -------- Original Message -------- Subject: Deployment of the Internet-Draft Submission Tool Date: Wed, 19 Sep 2007 15:32:20 -0400 From: IETF Secretariat Reply-To: idst-developers@ietf.org To: IETF Announcement list CC: wgchairs@ietf.org The IETF Secretariat is pleased to announce the deployment of the Internet-Draft Submission Tool (IDST)-Phase I. The IDST is a Web-based application that will allow an IETF participant to submit an Internet-Draft online, obtain approval to post the draft (if necessary), and make the draft immediately available to the community on the IETF Web site without the assistance of the Secretariat (in most cases). The URL for the IDST is: https://datatracker.ietf.org/idst/upload.cgi The URL for instructions for using the IDST is: http://www.ietf.org/idsubmit_instructions.html Although it will still be possible to submit your drafts by e-mail (i.e., by sending them to internet-drafts@ietf.org), the tool is available for use effective immediately, and we encourage you to submit your drafts via the tool starting today. If you have any questions about using the tool or wish to report a bug, then please send a message to idst-developers@ietf.org. Enjoy!! The IETF Secretariat _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Sep 24 18:35:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZwW4-0007Xf-U1; Mon, 24 Sep 2007 18:35:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZwW3-0007XE-Kj for ecrit@ietf.org; Mon, 24 Sep 2007 18:34:59 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZwVu-0007kk-TI for ecrit@ietf.org; Mon, 24 Sep 2007 18:34:59 -0400 X-SEF-Processed: 5_0_0_910__2007_09_24_17_44_13 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 24 Sep 2007 17:44:12 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Sep 2007 17:34:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] multiple location sources Date: Mon, 24 Sep 2007 17:34:32 -0500 Message-ID: In-Reply-To: <19aa01c7feeb$90c88ae0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] multiple location sources Thread-Index: Acf+6mvvfdfiVsj+SRWgXWkwKUNklAAAMBSgAAPrzUA= References: <194701c7fee8$927a12d0$640fa8c0@cis.neustar.com> <19aa01c7feeb$90c88ae0$640fa8c0@cis.neustar.com> From: "Thomson, Martin" To: "Brian Rosen" , X-OriginalArrivalTime: 24 Sep 2007 22:34:34.0686 (UTC) FILETIME=[150E65E0:01C7FEFB] X-Spam-Score: 1.7 (+) X-Scan-Signature: 680445c3afe8c9e96925f2dfef141924 Cc: ecrit X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1268444467==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1268444467== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FEFB.151BAEA5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FEFB.151BAEA5 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW4gaW1wb3J0YW50IGNhdmVhdCB0byBkb2N1bWVudCBpcyB0aGF0IExMRFAtTUVEIGRvZXNu4oCZ dCBhbHdheXMgcHJvdmlkZSB0aGUgaG9zdCBsb2NhdGlvbi4gIEFuIDgwMi4xMSBBUCBtaWdodCBv bmx5IGJlIGFibGUgdG8gcHJvdmlkZSBpdHMgb3duIGxvY2F0aW9uLCB3aGljaCwgaWYgaXQgaXMg aW4gdGhlIG5leHQgYnVpbGRpbmcsIGlzbuKAmXQgbXVjaCB1c2UuDQoNCiANCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCg0KRnJvbTogQnJpYW4gUm9zZW4gW21haWx0bzpickBi cmlhbnJvc2VuLm5ldF0gDQpTZW50OiBUdWVzZGF5LCAyNSBTZXB0ZW1iZXIgMjAwNyA2OjQzIEFN DQpUbzogcGV0ZXJfYmxhdGhlcndpY2tAbWl0ZWwuY29tDQpDYzogJ2Vjcml0Jw0KU3ViamVjdDog UkU6IFtFY3JpdF0gbXVsdGlwbGUgbG9jYXRpb24gc291cmNlcw0KDQogDQoNCkkgdW5kZXJzdGFu ZCB0aGUg4oCcbW92aW5nIHBhcnRz4oCdIG5vdy4gIENsZWFybHksIERIQ1AgaXMgbXVjaCBtb3Jl IG1hdHVyZSBhbmQgbGlrZWx5IHRvIHdvcmsgdG9kYXkgdGhhbiBMTERQLU1FRCBpcy4NCg0KIA0K DQpJIHRoaW5rIHRoZSBlbWVyZ2VuY3kgY2FsbCBkb2N1bWVudGF0aW9uIGlzIG5vdCB0aGUgcGxh Y2UgdG8gZWR1Y2F0ZSBkZXZpY2UgZGV2ZWxvcGVycyBvZiBob3cgc3RhcnR1cCBzZXF1ZW5jZXMg aW52b2x2aW5nIExMRFAsIERIQ1AgYW5kIEhUVFAgYmFzZWQgcHJvdG9jb2xzIGNvdWxkIGJlc3Qg YmUgZG9uZS4NCg0KIA0KDQpCcmlhbg0KDQogDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNCkZyb206IHBldGVyX2JsYXRoZXJ3aWNrQG1pdGVsLmNvbSBbbWFpbHRvOnBldGVy X2JsYXRoZXJ3aWNrQG1pdGVsLmNvbV0gDQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAyNCwgMjAw NyA0OjM1IFBNDQpUbzogQnJpYW4gUm9zZW4NCkNjOiAnU3RhcmssIEJhcmJhcmEnOyAnZWNyaXQn DQpTdWJqZWN0OiBSRTogW0Vjcml0XSBtdWx0aXBsZSBsb2NhdGlvbiBzb3VyY2VzDQoNCiANCg0K DQo+IEnigJltIG5vdCBzdXJlIGhvdyB5b3UgZGVjaWRlZCB0aGF0IExMRFAtTUVEIGhhcyBmZXdl ciBtb3ZpbmcgcGFydHMgb3IgaXMgbW9yZSByZWxpYWJsZSB0aGFuIERIQ1AgDQpMTERQIGlzIHJ1 bm5pbmcgYXQgdGhlIG90aGVyIGVuZCBvZiB0aGUgcGh5c2ljYWwgd2lyZSB0aGUgZGV2aWNlIGlu IHF1ZXN0aW9uIGlzIHBsdWdnZWQgaW50by4gIChJbiB0aGUgY2FzZSBvZiB3aXJlbGVzcywgaXQg aXMgbGlrZWx5IGF0IHRoZSBhY2Nlc3MgcG9pbnQsIG9yIGp1c3QgYmVoaW5kIGl0LikgIEluIHRo YXQgc2Vuc2UsIHRoZXJlIGFyZSBvbmx5IDIgbW92aW5nIHBhcnRzIHRoYXQgaGF2ZSB0byBiZSBv cGVyYXRpbmcgY29ycmVjdGx5IC0tIHRoZSBwaG9uZSBpdHNlbGYsIGFuZCB0aGUgTDIgYWNjZXNz IHN3aXRjaCBpdCBpcyBwbHVnZ2VkIGludG8uICBFdmVuIHdpdGggREhDUCB0aGVyZSBpcyBhdCBs ZWFzdCB0aGUgbmV0d29yayBpbmZyYXN0cnVjdHVyZSwgYSBzZXJ2ZXIgc29tZXdoZXJlLCBhbmQg b2Z0ZW4gREhDUCByZWxheSB0byBzZXQgdXAgdG8gZ2V0IGl0IGFsbCB3b3JraW5nLiAgSEVMRCBo YXMgYSBidW5jaCBtb3JlIG1lY2hhbmljcyB0aGF0IGFsbCBtdXN0IGJlIHdvcmtpbmcgY29ycmVj dGx5IG9uIHRvcCBvZiB0aGF0LiAgIA0KDQo+IE1JR0hUIGxlYWQgdG8gYW4gaW1wbGllZCBvcmRl cmluZywgYnV0IEkgZG9u4oCZdCB0aGluayBpdOKAmXMgZXZlbiB1c2VmdWwgdG8gc2F5IHRoYXQu ICBJ4oCZbSBub3Qgc3VyZSB3aHkgaXQgbWF0dGVycy4gDQpJIHRlcm1zIG9mIHRoZSBwaG9uZSBi Y3AsIHlvdSBhcmUgcHJvYmFibHkgcmlnaHQsIHNpbmNlIG90aGVyIE1VU1RzIG1ha2Ugc3VyZSB0 aGF0IHRoZXJlIGlzIGFsd2F5cyBleGFjdGx5IG9uZSBhbnN3ZXIgYW55d2F5LiAgSG93ZXZlciwg ZGV2aWNlIGRldmVsb3BlcnMgd2lsbCBjZXJ0YWlubHkgY2FyZSAtLSBnZXR0aW5nIHN0YXJ0dXAg c2VxdWVuY2UgcmlnaHQgaXMgaW1wb3J0YW50IGFuZCB3aWxsIG5vdCBiZSBpbW1lZGlhdGVseSBv YnZpb3VzIHRvIG1hbnkgbm90IGRlZXAgaW4gdGhlIGRldGFpbHMgb2YgZWFjaCBwaWVjZS4gIFRo ZSBEU0wgRm9ydW0gZG9jIGlzIHJlYWxseSBoZWxwZnVsICBmcm9tIHRoYXQgcGVyc3BlY3RpdmUu ICAgDQoNCi0tIFBldGVyIA0KDQoNCg0KDQoNCiANCg0KIkJyaWFuIFJvc2VuIiA8YnJAYnJpYW5y b3Nlbi5uZXQ+IA0KDQoyNC4wOS4wNyAxNjoyMiANCg0KICAgICAgICANCiAgICAgICAgVG86ICAg ICAgICA8cGV0ZXJfYmxhdGhlcndpY2tAbWl0ZWwuY29tPiwgIidTdGFyaywgQmFyYmFyYSciIDxi czc2NTJAYXR0LmNvbT4gDQogICAgICAgIGNjOiAgICAgICAgIidlY3JpdCciIDxlY3JpdEBpZXRm Lm9yZz4gDQogICAgICAgIFN1YmplY3Q6ICAgICAgICBSRTogW0Vjcml0XSBtdWx0aXBsZSBsb2Nh dGlvbiBzb3VyY2VzDQoNCg0KDQoNCknigJltIG5vdCBzdXJlIGhvdyB5b3UgZGVjaWRlZCB0aGF0 IExMRFAtTUVEIGhhcyBmZXdlciBtb3ZpbmcgcGFydHMgb3IgaXMgbW9yZSByZWxpYWJsZSB0aGFu IERIQ1AuICBJIHRoaW5rIGxpa2VseSBpdOKAmXMgdGhlIG90aGVyIHdheSByaWdodCBub3cuICAg DQogIA0KQ2VydGFpbmx5LCBpZiB5b3VyIGFyZSBhdXRvY29uZmlndXJpbmcgd2l0aCBMTERQLCB5 b3Ugd2lsbCB3YW50IHRoYXQgdG8gY29tcGxldGUgYmVmb3JlIHlvdSBkbyBESENQLiAgSSBkb27i gJl0IHRoaW5rIHdlIGhhdmUgdG8gc2F5IHRoYXQsIGJ1dCB3ZSBjYW4gaWYgd2UgbmVlZCB0by4g ICANCiAgDQpJIGFncmVlIHlvdSBuZWVkIGFuIElQIGFkZHJlc3MgYmVmb3JlIHlvdSBjYW4gaW52 b2tlIEhFTEQuICBJIGRvbuKAmXQgdGhpbmsgd2UgaGF2ZSB0byBzYXkgdGhhdC4gDQogIA0KVGhp cyBNSUdIVCBsZWFkIHRvIGFuIGltcGxpZWQgb3JkZXJpbmcsIGJ1dCBJIGRvbuKAmXQgdGhpbmsg aXTigJlzIGV2ZW4gdXNlZnVsIHRvIHNheSB0aGF0LiAgSeKAmW0gbm90IHN1cmUgd2h5IGl0IG1h dHRlcnMuIA0KICANCkJyaWFuIA0KICANCg0KIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQoNCkZyb206IHBldGVyX2JsYXRoZXJ3aWNrQG1pdGVsLmNvbSBbbWFpbHRvOnBl dGVyX2JsYXRoZXJ3aWNrQG1pdGVsLmNvbV0gDQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAyNCwg MjAwNyAxMjo0OSBQTQ0KVG86IFN0YXJrLCBCYXJiYXJhDQpDYzogZWNyaXQNClN1YmplY3Q6IFJF OiBbRWNyaXRdIG11bHRpcGxlIGxvY2F0aW9uIHNvdXJjZXMgDQogIA0KDQpIaSwgDQpJIGFncmVl IHRoYXQgdGhlIERTTCBGb3J1bSBkb2N1bWVudCBtYWtlcyBhIHZlcnkgZ29vZCBzdGFydGluZyBw b2ludCBmb3Igb3JkZXJseSBhY3F1aXNpdGlvbiBvZiBsb2NhdGlvbiBhdCBzdGFydHVwLCBhY2Nv dW50aW5nIGZvciBhbGwgMyBtZXRob2RzLiAgSSBhbHNvIGJlbGlldmUgaXQgcG9pbnRzIHRvIGEg cHJlZmVyZW5jZSBvcmRlciwgaWYgdGhlcmUgYXJlIG11bHRpcGxlIGFuc3dlcnMgY29taW5nIGJh Y2ssIHdoaWNoIGlzIExMRFAtTUVEIC0tPiBESENQIC0tPiBIRUxELiAgUmVhc29uaW5nIGZvciB0 aGlzIG9yZGVyIChteSBvcGluaW9uKSBpcyB0aGF0IGl0IHByb2dyZXNzZXMgZnJvbSAibGVhc3Qg bW92aW5nIHBhcnRzIiAvIG1vc3QgcmVsaWFibGUgKExMRFAtTUVEKSB0byBtb3N0LCBhbmQgYWxz byBmb2xsb3dzIHRoZSBuYXR1cmFsIGxheWVyaW5nIG9mIHRoZSBvdmVyYWxsIHN5c3RlbSAoTDIg LS0+IEwyLjUgLS0+IEw3KS4gICBJbiB0aGUgZW5kLCBvbmx5IE9ORSBtZXRob2Qgc2hvdWxkIGV2 ZXIgYmUgc2VsZWN0ZWQsIGFzIHRoZSBzZXF1ZW5jZSBkaWFncmFtIHNob3dzLiAgIA0KDQpZb3Vy IHBvaW50IGJlbG93LCB0aGF0IHRoZSBtZXRob2RzIGNhbiBhbmQgc2hvdWxkIHByb2dyZXNzIGlu IHBhcmFsbGVsIGlzIHZhbGlkLiAgSG93ZXZlciB0aGVyZSBhcmUgY29uc3RyYWludHMgdG8gdGhp cywgbm90YWJseTogDQoNCm8gSWYgTExEUC1NRUQgaXMgYmVpbmcgdXNlZCB0byBhdXRvY29uZmln dXJlIHZvaWNlIFZMQU4gSUQsIHRoZW4gdGhlIGRldmljZSBzaG91bGQgd2FpdCB0byBzZWUgaWYg dGhhdCBzdGFnZSBzdWNjZWVkcyBiZWZvcmUgY29udGFjdGluZyBESENQLiAgT3RoZXJ3aXNlLCB0 aGUgZGV2aWNlIG1heSBnZXQgYW4gSVAgYWRkcmVzcyBvbiB0aGUgZGVmYXVsdCBWTEFOLCBvbmx5 IHRvIGhhdmUgdG8gZHJvcCBpdCBhbmQgdHJ5IGFnYWluIG9uIHRoZSB2b2ljZSBWTEFOLiAgSWYg aXQgaGFkIHN0YXJ0ZWQgdG8gdXNlIHRoaXMgYWRkcmVzcyBmb3Igc29tZXRoaW5nIGFscmVhZHkg KHNheSBmb3IgSEVMRCksIHRoZW4gb25nb2luZyBpbnRlcmFjdGlvbiB3b3VsZCBiZSBkcm9wcGVk IGFuZCBjb25mdXNpb24gd291bGQgbGlrZWx5IGVuc3VlLiAgIA0KDQpvIEJlZm9yZSBIRUxEIGNh biB3b3JrLCBhbiBJUCBhZGRyZXNzIGlzIG5lZWRlZC4gICANCg0KSSB0aGluayB0aGVzZSBjb25z dHJhaW50cyBhcmUgcmVhbGx5IGp1c3QgYSByZWZsZWN0aW9uIG9mIHRoZSBuYXR1cmFsIGxheWVy aW5nIGluIHRoZSBlbmQuICAgDQoNCklNSE8sIG9yZGVybHkgc3RhcnR1cCBiZWF0cyB0aGUgZmV3 IGV4dHJhIHNlY29uZHMgZGVsYXkgaW5jdXJyZWQgaW4gbWFraW5nIHN1cmUgdGhlIGNvbnN0cmFp bnRzIGFyZSBub3QgYnJva2VuLiAgIFdlIGFyZSBvbmx5IHRhbGtpbmcgYWJvdXQgYSB2ZXJ5IGZl dyBzZWNvbmRzIGhlcmUgYWZ0ZXIgYWxsLiAgIA0KDQotLSBQZXRlciANCg0KDQoNCiAgDQoNCiJT dGFyaywgQmFyYmFyYSIgPGJzNzY1MkBhdHQuY29tPiANCg0KMjQuMDkuMDcgMDg6NDggDQoNCiAg ICAgICAgDQogICAgICAgVG86ICAgICAgICAiV2ludGVyYm90dG9tLCBKYW1lcyIgPEphbWVzLldp bnRlcmJvdHRvbUBhbmRyZXcuY29tPiwgIkthcmwgSGVpbnogV29sZiIgPGtod29sZjFAZ21haWwu Y29tPiwgImVjcml0IiA8ZWNyaXRAaWV0Zi5vcmc+IA0KICAgICAgIGNjOiAgICAgICAgIA0KICAg ICAgIFN1YmplY3Q6ICAgICAgICBSRTogW0Vjcml0XSBtdWx0aXBsZSBsb2NhdGlvbiBzb3VyY2Vz DQoNCg0KDQoNCg0KSXQncyBub3QgYWx3YXlzIGRlc2lyYWJsZSB0byB3YWl0IGZvciBhIHByb3Rv Y29sIHRvIHRpbWUtb3V0LCBiZWZvcmUgbGF1bmNoaW5nIHRoZSBuZXh0IHByb3RvY29sLiBTcGVj aWZpY2FsbHksIGlmIGEgZGV2aWNlIGlzIGNvbmZpZ3VyZWQgdG8gZG8gREhDUCBmb3IgSVAgYWRk cmVzcyBjb25maWd1cmF0aW9uLCBpdCBzaG91bGQgbGF1bmNoIGl0cyBESENQIGRpc2NvdmVyeSBB U0FQLCB3aXRoIG9wdGlvbnMsIGluc3RlYWQgb2Ygd2FpdGluZyB0aGUgNCBvciA1IHNlY29uZHMg Zm9yIExMRFAtTUVEIHRvIHRpbWUgb3V0LiBUaGlzIHByZXZlbnRzIHVubmVjZXNzYXJ5IGRlbGF5 cyBpbiB0aGUgYm9vdHN0cmFwIHByb2Nlc3MuIEl0IHNob3VsZCBiZSBlYXN5IGVub3VnaCBmb3Ig dGhlIGRldmljZSB0byB1c2UgYSByZWNlaXZlZCBMTERQLU1FRCBsb2NhdGlvbiwgZXZlbiBpZiBp dCBhcnJpdmVzIGFmdGVyIHRoZSBESENQIHJlc3BvbnNlLiANCkJhcmJhcmEgDQogDQotLS0tLS0t LS0tLS0tLS0tLS0tLSANCltBSlddIE15IGZpcnN0IHF1ZXN0aW9uIGlzIHdoeSBhcmUgeW91IHVz aW5nIG1vcmUgdGhhbiBvbmUgYWNxdWlzaXRpb24gcHJvdG9jb2wuIE15IHRob3VnaHRzIHdvdWxk IGJlIHVzZSBvbmUsIGlmIGl0IGZhaWxzLCBwaWNrIGEgZGlmZmVyZW50IG9uZS4gTmV2ZXIgaW52 b2tlIGJvdGggYXQgdGhlIHNhbWUgdGltZSBzbyB5b3UgaGF2ZSB0aGlzIHByb2JsZW0gb2YgY2hv aWNlLiANCiAgDQoNCioqKioqIA0KDQpUaGUgaW5mb3JtYXRpb24gdHJhbnNtaXR0ZWQgaXMgaW50 ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVz c2VkIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwsIHByb3ByaWV0YXJ5LCBhbmQvb3IgcHJp dmlsZWdlZCBtYXRlcmlhbC4gQW55IHJldmlldywgcmV0cmFuc21pc3Npb24sIGRpc3NlbWluYXRp b24gb3Igb3RoZXIgdXNlIG9mLCBvciB0YWtpbmcgb2YgYW55IGFjdGlvbiBpbiByZWxpYW5jZSB1 cG9uIHRoaXMgaW5mb3JtYXRpb24gYnkgcGVyc29ucyBvciBlbnRpdGllcyBvdGhlciB0aGFuIHRo ZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmVkIHRoaXMg aW4gZXJyb3IsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGUgbWF0ZXJp YWwgZnJvbSBhbGwgY29tcHV0ZXJzLiBHQTYyM19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpFY3JpdCBtYWlsaW5nIGxpc3QNCkVjcml0QGlldGYub3JnDQpo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdCANCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBk ZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJv cHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2 ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlh dGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0 aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClttZjJdDQo= ------_=_NextPart_001_01C7FEFB.151BAEA5 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6c3QxPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQoNCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDExIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYg IW1zb10+DQo8c3R5bGU+DQp2XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoq IHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1 bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+ DQo8IVtlbmRpZl0tLT48bzpTbWFydFRhZ1R5cGUNCiBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFz LW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyIgbmFtZT0iUGVyc29uTmFtZSIvPg0KPCEt LVtpZiAhbXNvXT4NCjxzdHlsZT4NCnN0MVw6KntiZWhhdmlvcjp1cmwoI2RlZmF1bHQjaWVvb3Vp KSB9DQo8L3N0eWxlPg0KPCFbZW5kaWZdLS0+DQo8c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZp bml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe2NvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcA0KCXttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnNwYW4uRW1haWxTdHls ZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OkFyaWFsOw0KCWNv bG9yOmJsdWU7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRl eHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6bWFyb29u Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29y YXRpb246bm9uZSBub25lO30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LlNlY3Rpb24xDQoJ e3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVT IGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bWFyb29uIGZhY2U9QXJpYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjptYXJvb24n PkFuIGltcG9ydGFudCBjYXZlYXQgdG8gZG9jdW1lbnQgaXMgdGhhdA0KTExEUC1NRUQgZG9lc27i gJl0IGFsd2F5cyBwcm92aWRlIHRoZSBob3N0IGxvY2F0aW9uLsKgIEFuIDgwMi4xMSBBUCBtaWdo dA0Kb25seSBiZSBhYmxlIHRvIHByb3ZpZGUgaXRzIG93biBsb2NhdGlvbiwgd2hpY2gsIGlmIGl0 IGlzIGluIHRoZSBuZXh0IGJ1aWxkaW5nLA0KaXNu4oCZdCBtdWNoIHVzZS48bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9y PW1hcm9vbiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1m YW1pbHk6QXJpYWw7Y29sb3I6bWFyb29uJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPg0KDQo8ZGl2Pg0KDQo8ZGl2IGNsYXNzPU1z b05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48Zm9udCBzaXpl PTMNCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQn Pg0KDQo8aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXIgdGFiaW5kZXg9LTE+DQoN Cjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48Zm9udCBzaXpl PTIgZmFjZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWls eTpUYWhvbWE7Zm9udC13ZWlnaHQ6Ym9sZCc+RnJvbTo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBz aXplPTINCmZhY2U9VGFob21hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OlRhaG9tYSc+IEJyaWFuIFJvc2VuDQpbbWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0XSA8YnI+ DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U2VudDo8L3NwYW4+PC9iPiBUdWVz ZGF5LCAyNSBTZXB0ZW1iZXIgMjAwNw0KNjo0MyBBTTxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250 LXdlaWdodDpib2xkJz5Ubzo8L3NwYW4+PC9iPiBwZXRlcl9ibGF0aGVyd2lja0BtaXRlbC5jb208 YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+Q2M6PC9zcGFuPjwvYj4gJ2Vj cml0Jzxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5TdWJqZWN0Ojwvc3Bh bj48L2I+IFJFOiBbRWNyaXRdIG11bHRpcGxlDQpsb2NhdGlvbiBzb3VyY2VzPC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBz aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIu MHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOg0KMTEuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsdWUnPkkgdW5kZXJzdGFu ZCB0aGUg4oCcbW92aW5nDQpwYXJ0c+KAnSBub3cuJm5ic3A7IENsZWFybHksIERIQ1AgaXMgbXVj aCBtb3JlIG1hdHVyZSBhbmQgbGlrZWx5IHRvIHdvcmsNCnRvZGF5IHRoYW4gTExEUC1NRUQgaXMu PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250 IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEx LjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJs dWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTEuMHB0O2ZvbnQtZmFtaWx5 OkFyaWFsO2NvbG9yOmJsdWUnPkkgdGhpbmsgdGhlIGVtZXJnZW5jeSBjYWxsIGRvY3VtZW50YXRp b24NCmlzIG5vdCB0aGUgcGxhY2UgdG8gZWR1Y2F0ZSBkZXZpY2UgZGV2ZWxvcGVycyBvZiBob3cg c3RhcnR1cCBzZXF1ZW5jZXMNCmludm9sdmluZyBMTERQLCBESENQIGFuZCBIVFRQIGJhc2VkIHBy b3RvY29scyBjb3VsZCBiZXN0IGJlIGRvbmUuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjExLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpi bHVlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOg0KMTEuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsdWUnPkJyaWFuPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9 MiBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjExLjBwdDtm b250LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPg0KDQo8ZGl2Pg0KDQo8ZGl2IGNsYXNz PU1zb05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48Zm9udCBz aXplPTMNCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4w cHQnPg0KDQo8aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXIgdGFiaW5kZXg9LTE+ DQoNCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48Zm9udCBz aXplPTIgZmFjZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZh bWlseTpUYWhvbWE7Zm9udC13ZWlnaHQ6Ym9sZCc+RnJvbTo8L3NwYW4+PC9mb250PjwvYj48Zm9u dCBzaXplPTINCmZhY2U9VGFob21hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OlRhaG9tYSc+DQpwZXRlcl9ibGF0aGVyd2lja0BtaXRlbC5jb20gW21haWx0bzpwZXRl cl9ibGF0aGVyd2lja0BtaXRlbC5jb21dIDxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdo dDpib2xkJz5TZW50Ojwvc3Bhbj48L2I+IE1vbmRheSwgU2VwdGVtYmVyIDI0LCAyMDA3DQo0OjM1 IFBNPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlRvOjwvc3Bhbj48L2I+ IEJyaWFuIFJvc2VuPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPkNjOjwv c3Bhbj48L2I+ICdTdGFyaywgQmFyYmFyYSc7ICdlY3JpdCc8YnI+DQo8Yj48c3BhbiBzdHlsZT0n Zm9udC13ZWlnaHQ6Ym9sZCc+U3ViamVjdDo8L3NwYW4+PC9iPiBSRTogW0Vjcml0XSBtdWx0aXBs ZSBsb2NhdGlvbg0Kc291cmNlczwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQoNCjwvZGl2 Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9t OjEyLjBwdCc+PGZvbnQgc2l6ZT0zDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTIuMHB0Jz48YnI+DQo8L3NwYW4+PC9mb250Pjxmb250IHNpemU9MiBmYWNl PUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWwn PiZndDsgPGZvbnQgY29sb3I9Ymx1ZT48c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZSc+SeKAmW0gbm90 IHN1cmUgaG93DQp5b3UgZGVjaWRlZCB0aGF0IExMRFAtTUVEIGhhcyBmZXdlciBtb3ZpbmcgcGFy dHMgb3IgaXMgbW9yZSByZWxpYWJsZSB0aGFuIERIQ1A8L3NwYW4+PC9mb250Pjwvc3Bhbj48L2Zv bnQ+DQo8YnI+DQo8Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpBcmlhbCc+TExEUA0KaXMgcnVubmluZyBhdCB0aGUgb3RoZXIg ZW5kIG9mIHRoZSBwaHlzaWNhbCB3aXJlIHRoZSBkZXZpY2UgaW4gcXVlc3Rpb24gaXMNCnBsdWdn ZWQgaW50by4gJm5ic3A7KEluIHRoZSBjYXNlIG9mIHdpcmVsZXNzLCBpdCBpcyBsaWtlbHkgYXQg dGhlIGFjY2VzcyBwb2ludCwNCm9yIGp1c3QgYmVoaW5kIGl0LikgJm5ic3A7SW4gdGhhdCBzZW5z ZSwgdGhlcmUgYXJlIG9ubHkgMiBtb3ZpbmcgcGFydHMgdGhhdA0KaGF2ZSB0byBiZSBvcGVyYXRp bmcgY29ycmVjdGx5IC0tIHRoZSBwaG9uZSBpdHNlbGYsIGFuZCB0aGUgTDIgYWNjZXNzIHN3aXRj aCBpdA0KaXMgcGx1Z2dlZCBpbnRvLiAmbmJzcDtFdmVuIHdpdGggREhDUCB0aGVyZSBpcyBhdCBs ZWFzdCB0aGUgbmV0d29yaw0KaW5mcmFzdHJ1Y3R1cmUsIGEgc2VydmVyIHNvbWV3aGVyZSwgYW5k IG9mdGVuIERIQ1AgcmVsYXkgdG8gc2V0IHVwIHRvIGdldCBpdA0KYWxsIHdvcmtpbmcuICZuYnNw O0hFTEQgaGFzIGEgYnVuY2ggbW9yZSBtZWNoYW5pY3MgdGhhdCBhbGwgbXVzdCBiZSB3b3JraW5n DQpjb3JyZWN0bHkgb24gdG9wIG9mIHRoYXQuICZuYnNwOzwvc3Bhbj48L2ZvbnQ+IDxicj4NCjxi cj4NCjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OkFyaWFsJz4mZ3Q7IDxmb250DQpjb2xvcj1ibHVlPjxzcGFuIHN0eWxlPSdj b2xvcjpibHVlJz5NSUdIVCBsZWFkIHRvIGFuIGltcGxpZWQgb3JkZXJpbmcsIGJ1dCBJDQpkb27i gJl0IHRoaW5rIGl04oCZcyBldmVuIHVzZWZ1bCB0byBzYXkgdGhhdC4gJm5ic3A7SeKAmW0gbm90 IHN1cmUNCndoeSBpdCBtYXR0ZXJzLjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD4gPGJyPg0K PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6QXJpYWwnPkkNCnRlcm1zIG9mIHRoZSBwaG9uZSBiY3AsIHlvdSBhcmUgcHJvYmFi bHkgcmlnaHQsIHNpbmNlIG90aGVyIE1VU1RzIG1ha2Ugc3VyZQ0KdGhhdCB0aGVyZSBpcyBhbHdh eXMgZXhhY3RseSBvbmUgYW5zd2VyIGFueXdheS4gJm5ic3A7SG93ZXZlciwgZGV2aWNlDQpkZXZl bG9wZXJzIHdpbGwgY2VydGFpbmx5IGNhcmUgLS0gZ2V0dGluZyBzdGFydHVwIHNlcXVlbmNlIHJp Z2h0IGlzIGltcG9ydGFudA0KYW5kIHdpbGwgbm90IGJlIGltbWVkaWF0ZWx5IG9idmlvdXMgdG8g bWFueSBub3QgZGVlcCBpbiB0aGUgZGV0YWlscyBvZiBlYWNoDQpwaWVjZS4gJm5ic3A7VGhlIERT TCBGb3J1bSBkb2MgaXMgPGk+PHNwYW4gc3R5bGU9J2ZvbnQtc3R5bGU6aXRhbGljJz5yZWFsbHkN CmhlbHBmdWw8L3NwYW4+PC9pPiAmbmJzcDtmcm9tIHRoYXQgcGVyc3BlY3RpdmUuICZuYnNwOzwv c3Bhbj48L2ZvbnQ+IDxicj4NCjxicj4NCjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsJz4tLQ0KUGV0ZXI8L3NwYW4+ PC9mb250PiA8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCg0KPHRhYmxl IGNsYXNzPU1zb05vcm1hbFRhYmxlIGJvcmRlcj0wIGNlbGxwYWRkaW5nPTAgd2lkdGg9IjEwMCUi DQogc3R5bGU9J3dpZHRoOjEwMC4wJSc+DQogPHRyPg0KICA8dGQgdmFsaWduPXRvcCBzdHlsZT0n cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCc+DQogIDxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0KICBzdHlsZT0nZm9udC1z aXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCiAgPC90ZD4N CiAgPHRkIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQn Pg0KICA8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PGZvbnQgc2l6ZT0xIGZhY2U9QXJpYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDsNCiAgZm9udC1mYW1pbHk6QXJpYWw7Zm9udC13ZWlnaHQ6 Ym9sZCc+JnF1b3Q7QnJpYW4gUm9zZW4mcXVvdDsNCiAgJmx0O2JyQGJyaWFucm9zZW4ubmV0Jmd0 Ozwvc3Bhbj48L2ZvbnQ+PC9iPiA8bzpwPjwvbzpwPjwvcD4NCiAgPHA+PGZvbnQgc2l6ZT0xIGZh Y2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpBcmlhbCc+ MjQuMDkuMDcNCiAgMTY6MjI8L3NwYW4+PC9mb250PiA8bzpwPjwvbzpwPjwvcD4NCiAgPC90ZD4N CiAgPHRkIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQn Pg0KICA8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0xIGZhY2U9QXJpYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZTo3LjVwdDsNCiAgZm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyA8L3NwYW4+PC9mb250Pjxicj4NCiAgPGZvbnQgc2l6ZT0xIGZhY2U9QXJp YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpBcmlhbCc+Jm5ic3A7 DQogICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRvOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KICAmbmJz cDsmbHQ7cGV0ZXJfYmxhdGhlcndpY2tAbWl0ZWwuY29tJmd0OywgJnF1b3Q7J1N0YXJrLCBCYXJi YXJhJyZxdW90Ow0KICAmbHQ7YnM3NjUyQGF0dC5jb20mZ3Q7PC9zcGFuPjwvZm9udD4gPGJyPg0K ICA8Zm9udCBzaXplPTEgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2Zv bnQtZmFtaWx5OkFyaWFsJz4mbmJzcDsNCiAgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY2M6ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90OydlY3JpdCcmcXVvdDsNCiAgJmx0O2Vjcml0QGll dGYub3JnJmd0Ozwvc3Bhbj48L2ZvbnQ+IDxicj4NCiAgPGZvbnQgc2l6ZT0xIGZhY2U9QXJpYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpBcmlhbCc+Jm5ic3A7DQog ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFN1YmplY3Q6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O1JFOiBbRWNyaXRdIG11bHRpcGxlDQogIGxvY2F0aW9uIHNvdXJjZXM8L3NwYW4+PC9mb250Pjxv OnA+PC9vOnA+PC9wPg0KICA8L3RkPg0KIDwvdHI+DQo8L3RhYmxlPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToNCjEyLjBwdCc+PGJyPg0KPGJyPg0KPGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBz aXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Ow0KZm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+SeKAmW0gbm90IHN1cmUgaG93IHlvdSBk ZWNpZGVkIHRoYXQgTExEUC1NRUQNCmhhcyBmZXdlciBtb3ZpbmcgcGFydHMgb3IgaXMgbW9yZSBy ZWxpYWJsZSB0aGFuIERIQ1AuICZuYnNwO0kgdGhpbmsgbGlrZWx5DQppdOKAmXMgdGhlIG90aGVy IHdheSByaWdodCBub3cuICZuYnNwOzwvc3Bhbj48L2ZvbnQ+IDxicj4NCjxmb250IHNpemU9MiBj b2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6DQpBcmlhbDtjb2xvcjpibHVlJz4mbmJzcDs8L3NwYW4+PC9mb250PiA8YnI+DQo8Zm9u dCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7Y29sb3I6Ymx1ZSc+Q2VydGFpbmx5LCBpZiB5b3VyIGFy ZSBhdXRvY29uZmlndXJpbmcgd2l0aCBMTERQLCB5b3Ugd2lsbA0Kd2FudCB0aGF0IHRvIGNvbXBs ZXRlIGJlZm9yZSB5b3UgZG8gREhDUC4gJm5ic3A7SSBkb27igJl0IHRoaW5rIHdlIGhhdmUgdG8N CnNheSB0aGF0LCBidXQgd2UgY2FuIGlmIHdlIG5lZWQgdG8uICZuYnNwOzwvc3Bhbj48L2ZvbnQ+ IDxicj4NCjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDtjb2xvcjpibHVlJz4mbmJzcDs8L3Nw YW4+PC9mb250PiA8YnI+DQo8Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7Y29sb3I6Ymx1ZSc+ SSBhZ3JlZSB5b3UgbmVlZCBhbiBJUCBhZGRyZXNzIGJlZm9yZSB5b3UgY2FuIGludm9rZSBIRUxE Lg0KJm5ic3A7SSBkb27igJl0IHRoaW5rIHdlIGhhdmUgdG8gc2F5IHRoYXQuPC9zcGFuPjwvZm9u dD4gPGJyPg0KPGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToNCkFyaWFsO2NvbG9yOmJsdWUnPiZuYnNwOzwv c3Bhbj48L2ZvbnQ+IDxicj4NCjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDtjb2xvcjpibHVl Jz5UaGlzIE1JR0hUIGxlYWQgdG8gYW4gaW1wbGllZCBvcmRlcmluZywgYnV0IEkgZG9u4oCZdA0K dGhpbmsgaXTigJlzIGV2ZW4gdXNlZnVsIHRvIHNheSB0aGF0LiAmbmJzcDtJ4oCZbSBub3Qgc3Vy ZSB3aHkgaXQNCm1hdHRlcnMuPC9zcGFuPjwvZm9udD4gPGJyPg0KPGZvbnQgc2l6ZT0yIGNvbG9y PWJsdWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToNCkFyaWFsO2NvbG9yOmJsdWUnPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+IDxicj4NCjxmb250IHNp emU9MiBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6DQpBcmlhbDtjb2xvcjpibHVlJz5Ccmlhbjwvc3Bhbj48L2ZvbnQ+IDxicj4N Cjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDtjb2xvcjpibHVlJz4mbmJzcDs8L3NwYW4+PC9m b250PiA8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBz dHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxmb250IHNpemU9Mw0KZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxl PSd0ZXh0LWFsaWduOmNlbnRlcic+PGZvbnQgc2l6ZT0zDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz4NCg0KPGhyIHNpemU9MiB3aWR0aD0iMTAw JSIgYWxpZ249Y2VudGVyPg0KDQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48Zm9udCBzaXplPTMNCmZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxicj4NCjwvc3Bh bj48L2ZvbnQ+PGI+PGZvbnQgc2l6ZT0yIGZhY2U9VGFob21hPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6VGFob21hO2ZvbnQtd2VpZ2h0OmJvbGQnPkZyb206PC9z cGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0yDQpmYWNlPVRhaG9tYT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWEnPg0KcGV0ZXJfYmxhdGhlcndpY2tAbWl0 ZWwuY29tIFttYWlsdG86cGV0ZXJfYmxhdGhlcndpY2tAbWl0ZWwuY29tXSA8Yj48c3Bhbg0Kc3R5 bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPjxicj4NClNlbnQ6PC9zcGFuPjwvYj4gTW9uZGF5LCBTZXB0 ZW1iZXIgMjQsIDIwMDcgMTI6NDkgUE08Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6DQpib2xk Jz48YnI+DQpUbzo8L3NwYW4+PC9iPiBTdGFyaywgQmFyYmFyYTxiPjxzcGFuIHN0eWxlPSdmb250 LXdlaWdodDpib2xkJz48YnI+DQpDYzo8L3NwYW4+PC9iPiBlY3JpdDxiPjxzcGFuIHN0eWxlPSdm b250LXdlaWdodDpib2xkJz48YnI+DQpTdWJqZWN0Ojwvc3Bhbj48L2I+IFJFOiBbRWNyaXRdIG11 bHRpcGxlIGxvY2F0aW9uIHNvdXJjZXM8L3NwYW4+PC9mb250PiA8YnI+DQombmJzcDsgPGJyPg0K PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6QXJpYWwnPjxicj4NCkhpLDwvc3Bhbj48L2ZvbnQ+IDxmb250IHNpemU9MiBmYWNl PUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwn Pjxicj4NCkkgYWdyZWUgdGhhdCB0aGUgRFNMIEZvcnVtIGRvY3VtZW50IG1ha2VzIGEgdmVyeSBn b29kIHN0YXJ0aW5nIHBvaW50IGZvciBvcmRlcmx5DQphY3F1aXNpdGlvbiBvZiBsb2NhdGlvbiBh dCBzdGFydHVwLCBhY2NvdW50aW5nIGZvciBhbGwgMyBtZXRob2RzLiAmbmJzcDtJIGFsc28NCmJl bGlldmUgaXQgcG9pbnRzIHRvIGEgcHJlZmVyZW5jZSBvcmRlciwgaWYgdGhlcmUgYXJlIG11bHRp cGxlIGFuc3dlcnMgY29taW5nDQpiYWNrLCB3aGljaCBpcyBMTERQLU1FRCAtLSZndDsgREhDUCAt LSZndDsgSEVMRC4gJm5ic3A7UmVhc29uaW5nIGZvciB0aGlzIG9yZGVyDQoobXkgb3Bpbmlvbikg aXMgdGhhdCBpdCBwcm9ncmVzc2VzIGZyb20gJnF1b3Q7bGVhc3QgbW92aW5nIHBhcnRzJnF1b3Q7 IC8gbW9zdA0KcmVsaWFibGUgKExMRFAtTUVEKSB0byBtb3N0LCBhbmQgYWxzbyBmb2xsb3dzIHRo ZSBuYXR1cmFsIGxheWVyaW5nIG9mIHRoZQ0Kb3ZlcmFsbCBzeXN0ZW0gKEwyIC0tJmd0OyBMMi41 IC0tJmd0OyBMNykuICZuYnNwOyBJbiB0aGUgZW5kLCBvbmx5IE9ORSBtZXRob2QNCnNob3VsZCBl dmVyIGJlIHNlbGVjdGVkLCBhcyB0aGUgc2VxdWVuY2UgZGlhZ3JhbSBzaG93cy4gJm5ic3A7PC9z cGFuPjwvZm9udD4gPGJyPg0KPGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwnPjxicj4NCllvdXIgcG9pbnQgYmVsb3cs IHRoYXQgdGhlIG1ldGhvZHMgY2FuIGFuZCBzaG91bGQgcHJvZ3Jlc3MgaW4gcGFyYWxsZWwgaXMN CnZhbGlkLiAmbmJzcDtIb3dldmVyIHRoZXJlIGFyZSBjb25zdHJhaW50cyB0byB0aGlzLCBub3Rh Ymx5OiA8L3NwYW4+PC9mb250Pjxicj4NCjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsJz48YnI+DQpvIElmIExMRFAt TUVEIGlzIGJlaW5nIHVzZWQgdG8gYXV0b2NvbmZpZ3VyZSB2b2ljZSBWTEFOIElELCB0aGVuIHRo ZSBkZXZpY2UNCnNob3VsZCB3YWl0IHRvIHNlZSBpZiB0aGF0IHN0YWdlIHN1Y2NlZWRzIGJlZm9y ZSBjb250YWN0aW5nIERIQ1AuDQombmJzcDtPdGhlcndpc2UsIHRoZSBkZXZpY2UgbWF5IGdldCBh biBJUCBhZGRyZXNzIG9uIHRoZSBkZWZhdWx0IFZMQU4sIG9ubHkgdG8NCmhhdmUgdG8gZHJvcCBp dCBhbmQgdHJ5IGFnYWluIG9uIHRoZSB2b2ljZSBWTEFOLiAmbmJzcDtJZiBpdCBoYWQgc3RhcnRl ZCB0byB1c2UNCnRoaXMgYWRkcmVzcyBmb3Igc29tZXRoaW5nIGFscmVhZHkgKHNheSBmb3IgSEVM RCksIHRoZW4gb25nb2luZyBpbnRlcmFjdGlvbg0Kd291bGQgYmUgZHJvcHBlZCBhbmQgY29uZnVz aW9uIHdvdWxkIGxpa2VseSBlbnN1ZS4gJm5ic3A7PC9zcGFuPjwvZm9udD4gPGJyPg0KPGZvbnQg c2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6QXJpYWwnPjxicj4NCm8gQmVmb3JlIEhFTEQgY2FuIHdvcmssIGFuIElQIGFkZHJlc3MgaXMg bmVlZGVkLiAmbmJzcDsgPC9zcGFuPjwvZm9udD48YnI+DQo8Zm9udCBzaXplPTIgZmFjZT1Bcmlh bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbCc+PGJyPg0K SSB0aGluayB0aGVzZSBjb25zdHJhaW50cyBhcmUgcmVhbGx5IGp1c3QgYSByZWZsZWN0aW9uIG9m IHRoZSBuYXR1cmFsIGxheWVyaW5nDQppbiB0aGUgZW5kLiAmbmJzcDs8L3NwYW4+PC9mb250PiA8 YnI+DQo8Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpBcmlhbCc+PGJyPg0KSU1ITywgb3JkZXJseSBzdGFydHVwIGJlYXRzIHRo ZSBmZXcgZXh0cmEgc2Vjb25kcyBkZWxheSBpbmN1cnJlZCBpbiBtYWtpbmcgc3VyZQ0KdGhlIGNv bnN0cmFpbnRzIGFyZSBub3QgYnJva2VuLiAmbmJzcDsgV2UgYXJlIG9ubHkgdGFsa2luZyBhYm91 dCBhIHZlcnkgZmV3DQpzZWNvbmRzIGhlcmUgYWZ0ZXIgYWxsLiAmbmJzcDs8L3NwYW4+PC9mb250 PiA8YnI+DQo8Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpBcmlhbCc+PGJyPg0KLS0gUGV0ZXIgPC9zcGFuPjwvZm9udD48YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCg0KPHRhYmxlIGNsYXNzPU1zb05vcm1hbFRhYmxlIGJv cmRlcj0wIGNlbGxwYWRkaW5nPTAgd2lkdGg9IjEwMCUiDQogc3R5bGU9J3dpZHRoOjEwMC4wJSc+ DQogPHRyPg0KICA8dGQgd2lkdGg9IjAlIiB2YWxpZ249dG9wIHN0eWxlPSd3aWR0aDowJTtwYWRk aW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Jz4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250 IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuDQogIHN0eWxlPSdmb250LXNpemU6 MTIuMHB0Jz4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCiAgPC90ZD4NCiAg PHRkIHdpZHRoPSIyMyUiIHZhbGlnbj10b3Agc3R5bGU9J3dpZHRoOjIzLjAlO3BhZGRpbmc6Ljc1 cHQgLjc1cHQgLjc1cHQgLjc1cHQnPg0KICA8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PGZvbnQgc2l6 ZT0xIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDsNCiAgZm9udC1mYW1p bHk6QXJpYWw7Zm9udC13ZWlnaHQ6Ym9sZCc+JnF1b3Q7U3RhcmssIEJhcmJhcmEmcXVvdDsNCiAg Jmx0O2JzNzY1MkBhdHQuY29tJmd0Ozwvc3Bhbj48L2ZvbnQ+PC9iPiA8bzpwPjwvbzpwPjwvcD4N CiAgPHA+PGZvbnQgc2l6ZT0xIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVw dDtmb250LWZhbWlseTpBcmlhbCc+MjQuMDkuMDcNCiAgMDg6NDg8L3NwYW4+PC9mb250PiA8bzpw PjwvbzpwPjwvcD4NCiAgPC90ZD4NCiAgPHRkIHdpZHRoPSI3NSUiIHZhbGlnbj10b3Agc3R5bGU9 J3dpZHRoOjc1LjAlO3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQnPg0KICA8cCBjbGFz cz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0xIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZTo3LjVwdDsNCiAgZm9udC1mYW1pbHk6QXJpYWwnPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyA8YnI+DQogICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RvOiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmcXVvdDs8c3QxOlBlcnNvbk5hbWUNCiAgdzpzdD0ib24iPldpbnRlcmJvdHRv bSwgSmFtZXM8L3N0MTpQZXJzb25OYW1lPiZxdW90Ow0KICAmbHQ7SmFtZXMuV2ludGVyYm90dG9t QGFuZHJldy5jb20mZ3Q7LCAmcXVvdDtLYXJsIEhlaW56IFdvbGYmcXVvdDsNCiAgJmx0O2tod29s ZjFAZ21haWwuY29tJmd0OywgJnF1b3Q7ZWNyaXQmcXVvdDsgJmx0O2Vjcml0QGlldGYub3JnJmd0 Ozwvc3Bhbj48L2ZvbnQ+DQogIDxmb250IHNpemU9MSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6QXJpYWwnPjxicj4NCiAgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Y2M6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48L2ZvbnQ+ IDxmb250DQogIHNpemU9MSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6QXJpYWwnPjxicj4NCiAgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U3Vi amVjdDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UkU6IFtFY3JpdF0NCiAgbXVsdGlwbGUg bG9jYXRpb24gc291cmNlczwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQogIDwvdGQ+DQog PC90cj4NCjwvdGFibGU+DQoNCjxwPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+ PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz48YnI+DQpJdCdz IG5vdCBhbHdheXMgZGVzaXJhYmxlIHRvIHdhaXQgZm9yIGEgcHJvdG9jb2wgdG8gdGltZS1vdXQs IGJlZm9yZSBsYXVuY2hpbmcgdGhlDQpuZXh0IHByb3RvY29sLiBTcGVjaWZpY2FsbHksIGlmIGEg ZGV2aWNlIGlzIGNvbmZpZ3VyZWQgdG8gZG8gREhDUCBmb3IgSVANCmFkZHJlc3MgY29uZmlndXJh dGlvbiwgaXQgc2hvdWxkIGxhdW5jaCBpdHMgREhDUCBkaXNjb3ZlcnkgQVNBUCwgd2l0aCBvcHRp b25zLA0KaW5zdGVhZCBvZiB3YWl0aW5nIHRoZSA0IG9yIDUgc2Vjb25kcyBmb3IgTExEUC1NRUQg dG8gdGltZSBvdXQuIFRoaXMgcHJldmVudHMNCnVubmVjZXNzYXJ5IGRlbGF5cyBpbiB0aGUgYm9v dHN0cmFwIHByb2Nlc3MuIEl0IHNob3VsZCBiZSBlYXN5IGVub3VnaCBmb3IgdGhlDQpkZXZpY2Ug dG8gdXNlIGEgcmVjZWl2ZWQgTExEUC1NRUQgbG9jYXRpb24sIGV2ZW4gaWYgaXQgYXJyaXZlcyBh ZnRlciB0aGUgREhDUA0KcmVzcG9uc2UuPC9zcGFuPjwvZm9udD4gPGZvbnQgc2l6ZT0yIGNvbG9y PWJsdWUgZmFjZT1BcmlhbD48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6QXJpYWw7Y29sb3I6Ymx1ZSc+PGJyPg0KQmFyYmFyYTwvc3Bhbj48L2ZvbnQ+IDxicj4NCiZu YnNwOzxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz48YnI+DQotLS0tLS0t LS0tLS0tLS0tLS0tLSA8L3NwYW4+PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPjxicj4NCltBSlddIE15IGZpcnN0IHF1ZXN0aW9uIGlzIHdoeSBhcmUgeW91IHVzaW5nIG1v cmUgdGhhbiBvbmUgYWNxdWlzaXRpb24gcHJvdG9jb2wuDQpNeSB0aG91Z2h0cyB3b3VsZCBiZSB1 c2Ugb25lLCBpZiBpdCBmYWlscywgcGljayBhIGRpZmZlcmVudCBvbmUuIE5ldmVyIGludm9rZQ0K Ym90aCBhdCB0aGUgc2FtZSB0aW1lIHNvIHlvdSBoYXZlIHRoaXMgcHJvYmxlbSBvZiBjaG9pY2Uu PC9zcGFuPjwvZm9udD4gPGJyPg0KJm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KDQo8cD48Zm9udCBz aXplPTIgZmFjZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6VGFob21hJz4qKioqKjwvc3Bhbj48L2ZvbnQ+DQo8bzpwPjwvbzpwPjwvcD4NCg0KPHA+PGZv bnQgc2l6ZT0yIGZhY2U9VGFob21hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OlRhaG9tYSc+VGhlDQppbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBpcyBpbnRlbmRlZCBv bmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB0byB3aGljaCBpdA0KaXMgYWRkcmVzc2VkIGFu ZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwsIHByb3ByaWV0YXJ5LCBhbmQvb3IgcHJpdmlsZWdl ZA0KbWF0ZXJpYWwuIEFueSByZXZpZXcsIHJldHJhbnNtaXNzaW9uLCBkaXNzZW1pbmF0aW9uIG9y IG90aGVyIHVzZSBvZiwgb3IgdGFraW5nDQpvZiBhbnkgYWN0aW9uIGluIHJlbGlhbmNlIHVwb24g dGhpcyBpbmZvcm1hdGlvbiBieSBwZXJzb25zIG9yIGVudGl0aWVzIG90aGVyDQp0aGFuIHRoZSBp bnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmVkIHRoaXMgaW4g ZXJyb3IsDQpwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhlIG1hdGVyaWFs IGZyb20gYWxsIGNvbXB1dGVycy4gR0E2MjM8L3NwYW4+PC9mb250Pjxmb250DQpzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KRWNyaXQgbWFpbGluZyBsaXN0PGJyPg0KRWNyaXRAaWV0Zi5vcmc8YnI+DQpo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdDwvc3Bhbj48L2ZvbnQ+ IDxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8YnI+PGJy Pjx0YWJsZSBiZ2NvbG9yPXdoaXRlIHN0eWxlPSJjb2xvcjpibGFjayI+PHRyPjx0ZD48YnI+LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KVGhpcyZuYnNwO21lc3Nh Z2UmbmJzcDtpcyZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO2Rlc2lnbmF0ZWQmbmJzcDtyZWNpcGll bnQmbmJzcDtvbmx5Jm5ic3A7YW5kJm5ic3A7bWF5PGJyPg0KY29udGFpbiZuYnNwO3ByaXZpbGVn ZWQsJm5ic3A7cHJvcHJpZXRhcnksJm5ic3A7b3ImbmJzcDtvdGhlcndpc2UmbmJzcDtwcml2YXRl Jm5ic3A7aW5mb3JtYXRpb24uJm5ic3A7Jm5ic3A7PGJyPg0KSWYmbmJzcDt5b3UmbmJzcDtoYXZl Jm5ic3A7cmVjZWl2ZWQmbmJzcDtpdCZuYnNwO2luJm5ic3A7ZXJyb3IsJm5ic3A7cGxlYXNlJm5i c3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7c2VuZGVyPGJyPg0KaW1tZWRpYXRlbHkmbmJzcDthbmQm bmJzcDtkZWxldGUmbmJzcDt0aGUmbmJzcDtvcmlnaW5hbC4mbmJzcDsmbmJzcDtBbnkmbmJzcDt1 bmF1dGhvcml6ZWQmbmJzcDt1c2UmbmJzcDtvZjxicj4NCnRoaXMmbmJzcDtlbWFpbCZuYnNwO2lz Jm5ic3A7cHJvaGliaXRlZC48YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08YnI+DQpbbWYyXTwvdGQ+PC90cj48L3RhYmxlPjwvYm9keT4NCg0KPC9odG1sPg0K ------_=_NextPart_001_01C7FEFB.151BAEA5-- --===============1268444467== 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 --===============1268444467==-- From ecrit-bounces@ietf.org Mon Sep 24 19:05:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZwyr-0006tr-Sr; Mon, 24 Sep 2007 19:04:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZwyp-0006tI-FD for ecrit@ietf.org; Mon, 24 Sep 2007 19:04:43 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IZwyo-0002c7-Lk for ecrit@ietf.org; Mon, 24 Sep 2007 19:04:43 -0400 X-SEF-Processed: 5_0_0_910__2007_09_24_18_14_18 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 24 Sep 2007 18:14:18 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Sep 2007 18:04:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] multiple location sources Date: Mon, 24 Sep 2007 18:04:37 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] multiple location sources Thread-Index: Acf+6pE1j/1pK6jXSbGGqIV+5WLYXgAFEEIg References: <194701c7fee8$927a12d0$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: , "Brian Rosen" X-OriginalArrivalTime: 24 Sep 2007 23:04:40.0510 (UTC) FILETIME=[496945E0:01C7FEFF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bcdb6f0ba9636bf286b7e28ccb8bd9b Cc: ecrit X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0836019265==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0836019265== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FEFF.49680ECA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FEFF.49680ECA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Peter,=0D=0A=0D=0A=20=0D=0A=0D=0AI would point out that a HELD-based LIS ac= tually requires fewer things=0D=0Ato be up and running than the SIP client = would in order to initiate the=0D=0Aemergency call in the first place. So I= am not sure that the=0D=0Amachinations argument really carries a lot of we= ight.=20=0D=0A=0D=0A=20=0D=0A=0D=0ACheers=0D=0A=0D=0AJames=0D=0A=0D=0A=20=0D= =0A=0D=0A________________________________=0D=0A=0D=0AFrom: peter_blatherwic= k@mitel.com [mailto:peter_blatherwick@mitel.com]=20=0D=0ASent: Tuesday, 25 = September 2007 6:35 AM=0D=0ATo: Brian Rosen=0D=0ACc: 'ecrit'=0D=0ASubject: = RE: [Ecrit] multiple location sources=0D=0A=0D=0A=20=0D=0A=0D=0A=0D=0A> I'm= not sure how you decided that LLDP-MED has fewer moving parts or=0D=0Ais m= ore reliable than DHCP=20=0D=0ALLDP is running at the other end of the phys= ical wire the device in=0D=0Aquestion is plugged into. (In the case of wir= eless, it is likely at the=0D=0Aaccess point, or just behind it.) In that = sense, there are only 2=0D=0Amoving parts that have to be operating correct= ly -- the phone itself,=0D=0Aand the L2 access switch it is plugged into. = Even with DHCP there is at=0D=0Aleast the network infrastructure, a server = somewhere, and often DHCP=0D=0Arelay to set up to get it all working. HELD= has a bunch more mechanics=0D=0Athat all must be working correctly on top = of that. =20=0D=0A=0D=0A> MIGHT lead to an implied ordering, but I don't t= hink it's even useful=0D=0Ato say that. I'm not sure why it matters.=20=0D= =0AI terms of the phone bcp, you are probably right, since other MUSTs make=0D= =0Asure that there is always exactly one answer anyway. However, device=0D= =0Adevelopers will certainly care -- getting startup sequence right is=0D=0A= important and will not be immediately obvious to many not deep in the=0D=0A= details of each piece. The DSL Forum doc is really helpful from that=0D=0A= perspective. =20=0D=0A=0D=0A-- Peter=20=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A=20=0D=0A=0D=0A"Brian Rosen" =20=0D=0A=0D=0A24.09.07 = 16:22=20=0D=0A=0D=0A =20=0D=0A To: , "'Stark, Barbara'"=0D=0A=20=0D=0A cc: = "'ecrit'" =20=0D=0A Subject: RE: [Ecrit] = multiple location sources=0D=0A=0D=0A=0D=0A=0D=0A=0D=0AI'm not sure how you= decided that LLDP-MED has fewer moving parts or is=0D=0Amore reliable than= DHCP. I think likely it's the other way right now.=0D=0A=0D=0A =20=0D=0AC= ertainly, if your are autoconfiguring with LLDP, you will want that to=0D=0A= complete before you do DHCP. I don't think we have to say that, but we=0D=0A= can if we need to. =20=0D=0A =20=0D=0AI agree you need an IP address befor= e you can invoke HELD. I don't=0D=0Athink we have to say that.=20=0D=0A =0D= =0AThis MIGHT lead to an implied ordering, but I don't think it's even=0D=0A= useful to say that. I'm not sure why it matters.=20=0D=0A =20=0D=0ABrian =0D= =0A =20=0D=0A=0D=0A=20=0D=0A=0D=0A________________________________=0D=0A=0D= =0A=0D=0AFrom: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.= com]=20=0D=0ASent: Monday, September 24, 2007 12:49 PM=0D=0ATo: Stark, Barb= ara=0D=0ACc: ecrit=0D=0ASubject: RE: [Ecrit] multiple location sources=20=0D= =0A =20=0D=0A=0D=0AHi,=20=0D=0AI agree that the DSL Forum document makes a = very good starting point for=0D=0Aorderly acquisition of location at startu= p, accounting for all 3=0D=0Amethods. I also believe it points to a prefer= ence order, if there are=0D=0Amultiple answers coming back, which is LLDP-M= ED --> DHCP --> HELD.=0D=0AReasoning for this order (my opinion) is that it= progresses from "least=0D=0Amoving parts" / most reliable (LLDP-MED) to mo= st, and also follows the=0D=0Anatural layering of the overall system (L2 --= > L2.5 --> L7). In the=0D=0Aend, only ONE method should ever be selected,= as the sequence diagram=0D=0Ashows. =20=0D=0A=0D=0AYour point below, that= the methods can and should progress in parallel=0D=0Ais valid. However th= ere are constraints to this, notably:=20=0D=0A=0D=0Ao If LLDP-MED is being = used to autoconfigure voice VLAN ID, then the=0D=0Adevice should wait to se= e if that stage succeeds before contacting DHCP.=0D=0AOtherwise, the device= may get an IP address on the default VLAN, only to=0D=0Ahave to drop it an= d try again on the voice VLAN. If it had started to=0D=0Ause this address = for something already (say for HELD), then ongoing=0D=0Ainteraction would b= e dropped and confusion would likely ensue. =20=0D=0A=0D=0Ao Before HELD c= an work, an IP address is needed. =20=0D=0A=0D=0AI think these constraints= are really just a reflection of the natural=0D=0Alayering in the end. =0D= =0A=0D=0AIMHO, orderly startup beats the few extra seconds delay incurred i= n=0D=0Amaking sure the constraints are not broken. We are only talking ab= out=0D=0Aa very few seconds here after all. =20=0D=0A=0D=0A-- Peter=20=0D=0A=0D= =0A=0D=0A=0D=0A=0D=0A =20=0D=0A=0D=0A"Stark, Barbara" =20=0D= =0A=0D=0A24.09.07 08:48=20=0D=0A=0D=0A =20=0D=0A To: "Wi= nterbottom, James" ,=0D=0A"Karl Heinz Wolf" = , "ecrit" =20=0D=0A cc: =0D= =0A Subject: RE: [Ecrit] multiple location sources=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A=0D=0AIt's not always desirable to wait for a protocol to ti= me-out, before=0D=0Alaunching the next protocol. Specifically, if a device = is configured to=0D=0Ado DHCP for IP address configuration, it should launc= h its DHCP=0D=0Adiscovery ASAP, with options, instead of waiting the 4 or 5= seconds for=0D=0ALLDP-MED to time out. This prevents unnecessary delays in= the bootstrap=0D=0Aprocess. It should be easy enough for the device to use= a received=0D=0ALLDP-MED location, even if it arrives after the DHCP respo= nse.=20=0D=0ABarbara=20=0D=0A=20=0D=0A--------------------=20=0D=0A[AJW] My= first question is why are you using more than one acquisition=0D=0Aprotoco= l. My thoughts would be use one, if it fails, pick a different=0D=0Aone. Ne= ver invoke both at the same time so you have this problem of=0D=0Achoice. =0D= =0A =20=0D=0A=0D=0A*****=20=0D=0A=0D=0AThe information transmitted is inten= ded only for the person or entity to=0D=0Awhich it is addressed and may con= tain confidential, proprietary, and/or=0D=0Aprivileged material. Any review= , retransmission, dissemination or other=0D=0Ause of, or taking of any acti= on in reliance upon this information by=0D=0Apersons or entities other than= the intended recipient is prohibited. If=0D=0Ayou received this in error, = please contact the sender and delete the=0D=0Amaterial from all computers.=0D= =0AGA623_______________________________________________=0D=0AEcrit mailing = list=0D=0AEcrit@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/listinfo/ecrit =0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C7FEFF.49680ECA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= =0D=0A= =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A

Peter,

=0D= =0A=0D=0A

 =

=0D=0A=0D=0A

I would point out that a HELD-based LIS actually=0D=0Arequi= res fewer things to be up and running than the SIP client would in order=0D= =0Ato initiate the emergency call in the first place. So I am not sure that= the=0D=0Amachinations argument really carries a lot of weight. =

=0D=0A=0D=0A

 

=0D=0A=0D=0A

Cheers

=0D= =0A=0D=0A

James<= /o:p>

=0D=0A=0D=0A

 

=0D=0A=0D=0A
=0D=0A=0D= =0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A

From:=0D=0Apeter_blatherwick@mitel.com [mailto:peter_b= latherwick@mitel.com]
=0D=0ASent: Tuesday, 25 September 2007=0D=0A6:35 AM
=0D=0ATo: Brian Rosen
=0D=0ACc: 'ecrit'
=0D=0ASubject: RE: [Ecrit] multiple=0D=0Alocation sources

=0D=0A=0D=0A
=0D=0A=0D= =0A

 

=0D=0A=0D=0A=


=0D=0A> I’m not sure how you=0D=0Adecided that LLDP-MED has fewer moving par= ts or is more reliable than DHCP=0D=0A
=0D=0ALLDP=0D=0Ais running at the other end of the physical wire the device in q= uestion is=0D=0Aplugged into.  (In the case of wireless, it is likely = at the access point,=0D=0Aor just behind it.)  In that sense, there ar= e only 2 moving parts that=0D=0Ahave to be operating correctly -- the phone= itself, and the L2 access switch it=0D=0Ais plugged into.  Even with = DHCP there is at least the network=0D=0Ainfrastructure, a server somewhere,= and often DHCP relay to set up to get it=0D=0Aall working.  HELD has = a bunch more mechanics that all must be working=0D=0Acorrectly on top of th= at.  
=0D=0A
=0D=0A>=0D=0AMIGHT lead to an implied ordering= , but I don’t=0D=0Athink it’s even useful to say that.  I&= #8217;m not sure why it matters.=0D=0A
=0D=0AI=0D=0Aterms of the phone bcp, you are probably right, since other MUSTs m= ake sure=0D=0Athat there is always exactly one answer anyway.  However= , device=0D=0Adevelopers will certainly care -- getting startup sequence ri= ght is important=0D=0Aand will not be immediately obvious to many not deep = in the details of each=0D=0Apiece.  The DSL Forum doc is really=0D=0Ahelpful  from that pers= pective.  
=0D=0A
=0D=0A--=0D=0APet= er
=0D=0A
=0D=0A
=0D=0A
=0D=0A
=0D=0A

=0D=0A=0D=0A=0D=0A =0D=0A =0D=0A =0D=0A= =0D=0A
=0D=0A

=  

=0D=0A 		=0D=0A

<= b>"Brian Rosen"=0D=0A <= br@brianrosen.net>

=0D=0A

24.09.07 16:22

=0D=0A 		=0D=0A

       
=0D=0A=  =0D=0A       To:       =  <peter_blatherwick@mitel.com>,=0D=0A "'Stark, Barbara'&qu= ot; <bs7652@att.com>
=0D=0A  =0D= =0A       cc:        "'ecrit'"= ;=0D=0A <ecrit@ietf.org>
=0D=0A &nbs= p;=0D=0A       Subject:        RE: [Ecr= it] multiple=0D=0A location sources

=0D=0A =0D=0A
=0D=0A=0D=0A


=0D=0A=
=0D=0A
=0D=0A= I’= ;m not sure how you decided that LLDP-MED has=0D=0Afewer moving parts or is= more reliable than DHCP.  I think likely it’s the=0D=0Aother wa= y right now.  
=0D=0A 
=0D=0A= Certain= ly, if your are autoconfiguring with LLDP, you will=0D=0Awant that to compl= ete before you do DHCP.  I don’t think we have to say=0D=0Athat,= but we can if we need to.  
=0D=0A 
=0D=0AI agree you need an IP address before you can invoke HELD.=0D=0A&nbs= p;I don’t think we have to say that.
=0D=0A 
=0D=0AThis MIGHT lead to an implied ordering, but I don’t t= hink=0D=0Ait’s even useful to say that.  I’m not sure why = it matters.
=0D=0A = ;
=0D=0ABrian
=0D=0A  =

=0D=0A=0D=0A

 

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D= =0A


=0D=0A= From:=0D=0A= peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
=0D=0ASent: Monday, September = 24, 2007 12:49 PM
=0D=0ATo: Stark, Barbara
=0D=0ACc: ecrit
=0D=0ASubject:= RE: [Ecrit] multiple location sources
=0D=0A  <= br>=0D=0A
=0D=0AHi,
=0D= =0AI agree that the DSL Forum document makes a very good starting point for= orderly=0D=0Aacquisition of location at startup, accounting for all 3 meth= ods.  I also=0D=0Abelieve it points to a preference order, if there ar= e multiple answers coming=0D=0Aback, which is LLDP-MED --> DHCP --> H= ELD.  Reasoning for this order=0D=0A(my opinion) is that it progresses= from "least moving parts" / most=0D=0Areliable (LLDP-MED) to mos= t, and also follows the natural layering of the=0D=0Aoverall system (L2 --&= gt; L2.5 --> L7).   In the end, only ONE method=0D=0Ashould ever be= selected, as the sequence diagram shows.  
=0D=0A
=0D=0AYour point below, that the methods can and should pro= gress in parallel is=0D=0Avalid.  However there are constraints to thi= s, notably:
=0D=0A
=0D=0Ao If LLDP-MED i= s being used to autoconfigure voice VLAN ID, then the device=0D=0Ashould wa= it to see if that stage succeeds before contacting DHCP.  Otherwise,=0D= =0Athe device may get an IP address on the default VLAN, only to have to dr= op it=0D=0Aand try again on the voice VLAN.  If it had started to use = this address=0D=0Afor something already (say for HELD), then ongoing intera= ction would be dropped=0D=0Aand confusion would likely ensue.  =
=0D=0A
=0D=0Ao Before HELD can work, an IP add= ress is needed.  
=0D=0A
=0D=0AI th= ink these constraints are really just a reflection of the natural layering=0D= =0Ain the end.  
=0D=0A
=0D=0AIMHO,= orderly startup beats the few extra seconds delay incurred in making sure=0D= =0Athe constraints are not broken.   We are only talking about a very = few=0D=0Aseconds here after all.  
=0D=0A
=0D=0A-- Peter
=0D=0A
=0D=0A
=0D=0A=

=0D=0A=0D=0A=0D=0A =0D=0A =0D= =0A =0D=0A =0D=0A =0D=0A
=0D=0A =

 

=0D=0A 		=0D=0A

"Stark, Barbara"=0D=0A <bs7652@att.com>

=0D=0A

24.09.07 08:48

=0D=0A 		=0D=0A

       
=0D=0A        To:       &nbs= p;"Winterbottom,=0D=0A James" <James.Winterbottom@andrew.com&= gt;, "Karl Heinz=0D=0A Wolf" <khwolf1@gmail.com>, "ec= rit"=0D=0A <ecrit@ietf.org> =0D=0A        cc:        =
=0D=0A        Subject:=        RE: [Ecrit]=0D=0A multiple location sources

=0D=0A
=0D=0A=0D=0A=


=0D=0A
=0D=0A
=0D=0A
=0D=0AIt's not always desirable to wait for a protocol to time-out,= before launching=0D=0Athe next protocol. Specifically, if a device is conf= igured to do DHCP for IP=0D=0Aaddress configuration, it should launch its D= HCP discovery ASAP, with options,=0D=0Ainstead of waiting the 4 or 5 second= s for LLDP-MED to time out. This prevents=0D=0Aunnecessary delays in the bo= otstrap process. It should be easy enough for the=0D=0Adevice to use a rece= ived LLDP-MED location, even if it arrives after the DHCP=0D=0Aresponse.
=0D=0ABarbara
=0D=0A 
=0D=0A-------------= -------
=0D=0A[AJW] My first quest= ion is why are you using more than one acquisition=0D=0Aprotocol. My though= ts would be use one, if it fails, pick a different one.=0D=0ANever invoke b= oth at the same time so you have this problem of choice.=0D=0A=
=0D=0A 

=0D=0A=0D=0A

*****=0D= =0A

=0D=0A=0D=0A

The=0D=0Ainformation transmitted is i= ntended only for the person or entity to which it=0D=0Ais addressed and may= contain confidential, proprietary, and/or privileged=0D=0Amaterial. Any re= view, retransmission, dissemination or other use of, or taking=0D=0Aof any = action in reliance upon this information by persons or entities other=0D=0A= than the intended recipient is prohibited. If you received this in error, p= lease=0D=0Acontact the sender and delete the material from all computers. G= A623________________________________= _______________
=0D=0AEcrit mailing list
=0D=0AEcrit@ietf.org
=0D=0A= https://www1.ietf.org/mailman/listinfo/ecrit

=0D= =0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A


----------------------------------------= --------------------------------------------------------
=0D=0AThis = ;message is for the designated recipient only=  and may
=0D=0Acontain privileged, proprietary, = ;or otherwise private information.  
=0D=0AIf&n= bsp;you have received it in error, please&nbs= p;notify the sender
=0D=0Aimmediately and delete&nbs= p;the original.  Any unauthorized use of
=0D= =0Athis email is prohibited.
=0D=0A----------------------= --------------------------------------------------------------------------<= br>=0D=0A[mf2]
=0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01C7FEFF.49680ECA-- --===============0836019265== 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 --===============0836019265==-- From ecrit-bounces@ietf.org Tue Sep 25 12:41:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaDS6-0004wu-Qw; Tue, 25 Sep 2007 12:40:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaDS4-0004uO-3d for ecrit@ietf.org; Tue, 25 Sep 2007 12:40:00 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaDS2-0002Gq-9c for ecrit@ietf.org; Tue, 25 Sep 2007 12:40:00 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IaDRo-00005D-Ue; Tue, 25 Sep 2007 11:39:46 -0500 From: "Brian Rosen" To: "'Thomson, Martin'" , References: <194701c7fee8$927a12d0$640fa8c0@cis.neustar.com> <19aa01c7feeb$90c88ae0$640fa8c0@cis.neustar.com> Subject: RE: [Ecrit] multiple location sources Date: Tue, 25 Sep 2007 12:39:51 -0400 Message-ID: <1ba801c7ff92$b3b8cf90$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Acf+6mvvfdfiVsj+SRWgXWkwKUNklAAAMBSgAAPrzUAABKJNcA== In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: f1e116c42859d8542c08251690b5b182 Cc: 'ecrit' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2057990543==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============2057990543== Content-Type: multipart/alternative; boundary="----=_NextPart_000_1BA9_01C7FF71.2CA72F90" This is a multi-part message in MIME format. ------=_NextPart_000_1BA9_01C7FF71.2CA72F90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit That's often all you can get. There are only three cases: 1. The user measures its own location, no LCP needed 2. The location of the clients of the AP are reported as the location of the AP 3. There is triangulation between APs and clients to get a more accurate location Case 2 is going to be the norm for a while. The ability to triangulate is around, but not widely deployed. Brian _____ From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] Sent: Monday, September 24, 2007 6:35 PM To: Brian Rosen; peter_blatherwick@mitel.com Cc: ecrit Subject: RE: [Ecrit] multiple location sources An important caveat to document is that LLDP-MED doesn't always provide the host location. An 802.11 AP might only be able to provide its own location, which, if it is in the next building, isn't much use. _____ From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, 25 September 2007 6:43 AM To: peter_blatherwick@mitel.com Cc: 'ecrit' Subject: RE: [Ecrit] multiple location sources I understand the "moving parts" now. Clearly, DHCP is much more mature and likely to work today than LLDP-MED is. I think the emergency call documentation is not the place to educate device developers of how startup sequences involving LLDP, DHCP and HTTP based protocols could best be done. Brian _____ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Monday, September 24, 2007 4:35 PM To: Brian Rosen Cc: 'Stark, Barbara'; 'ecrit' Subject: RE: [Ecrit] multiple location sources > I'm not sure how you decided that LLDP-MED has fewer moving parts or is more reliable than DHCP LLDP is running at the other end of the physical wire the device in question is plugged into. (In the case of wireless, it is likely at the access point, or just behind it.) In that sense, there are only 2 moving parts that have to be operating correctly -- the phone itself, and the L2 access switch it is plugged into. Even with DHCP there is at least the network infrastructure, a server somewhere, and often DHCP relay to set up to get it all working. HELD has a bunch more mechanics that all must be working correctly on top of that. > MIGHT lead to an implied ordering, but I don't think it's even useful to say that. I'm not sure why it matters. I terms of the phone bcp, you are probably right, since other MUSTs make sure that there is always exactly one answer anyway. However, device developers will certainly care -- getting startup sequence right is important and will not be immediately obvious to many not deep in the details of each piece. The DSL Forum doc is really helpful from that perspective. -- Peter "Brian Rosen" 24.09.07 16:22 To: , "'Stark, Barbara'" cc: "'ecrit'" Subject: RE: [Ecrit] multiple location sources I'm not sure how you decided that LLDP-MED has fewer moving parts or is more reliable than DHCP. I think likely it's the other way right now. Certainly, if your are autoconfiguring with LLDP, you will want that to complete before you do DHCP. I don't think we have to say that, but we can if we need to. I agree you need an IP address before you can invoke HELD. I don't think we have to say that. This MIGHT lead to an implied ordering, but I don't think it's even useful to say that. I'm not sure why it matters. Brian _____ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Monday, September 24, 2007 12:49 PM To: Stark, Barbara Cc: ecrit Subject: RE: [Ecrit] multiple location sources Hi, I agree that the DSL Forum document makes a very good starting point for orderly acquisition of location at startup, accounting for all 3 methods. I also believe it points to a preference order, if there are multiple answers coming back, which is LLDP-MED --> DHCP --> HELD. Reasoning for this order (my opinion) is that it progresses from "least moving parts" / most reliable (LLDP-MED) to most, and also follows the natural layering of the overall system (L2 --> L2.5 --> L7). In the end, only ONE method should ever be selected, as the sequence diagram shows. Your point below, that the methods can and should progress in parallel is valid. However there are constraints to this, notably: o If LLDP-MED is being used to autoconfigure voice VLAN ID, then the device should wait to see if that stage succeeds before contacting DHCP. Otherwise, the device may get an IP address on the default VLAN, only to have to drop it and try again on the voice VLAN. If it had started to use this address for something already (say for HELD), then ongoing interaction would be dropped and confusion would likely ensue. o Before HELD can work, an IP address is needed. I think these constraints are really just a reflection of the natural layering in the end. IMHO, orderly startup beats the few extra seconds delay incurred in making sure the constraints are not broken. We are only talking about a very few seconds here after all. -- Peter "Stark, Barbara" 24.09.07 08:48 To: "Winterbottom, James" , "Karl Heinz Wolf" , "ecrit" cc: Subject: RE: [Ecrit] multiple location sources It's not always desirable to wait for a protocol to time-out, before launching the next protocol. Specifically, if a device is configured to do DHCP for IP address configuration, it should launch its DHCP discovery ASAP, with options, instead of waiting the 4 or 5 seconds for LLDP-MED to time out. This prevents unnecessary delays in the bootstrap process. It should be easy enough for the device to use a received LLDP-MED location, even if it arrives after the DHCP response. Barbara -------------------- [AJW] My first question is why are you using more than one acquisition protocol. My thoughts would be use one, if it fails, pick a different one. Never invoke both at the same time so you have this problem of choice. ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623_______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] ------=_NextPart_000_1BA9_01C7FF71.2CA72F90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That’s often all you can = get.

 

There are only three = cases:

  1. The user measures its own location, no LCP = needed
  2. The location of the clients of the AP are reported as the location of = the AP
  3. There is triangulation between APs and clients to get a more accurate = location

 

Case 2 is going to be the norm for = a while.

 

The ability to triangulate is = around, but not widely deployed.

 

Brian

 

From: = Thomson, Martin [mailto:Martin.Thomson@andrew.com]
Sent: Monday, September = 24, 2007 6:35 PM
To: Brian Rosen; peter_blatherwick@mitel.com
Cc: ecrit
Subject: RE: [Ecrit] = multiple location sources

 

An important caveat to document = is that LLDP-MED doesn’t always provide the host location.  An 802.11 = AP might only be able to provide its own location, which, if it is in the = next building, isn’t much use.

 

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: Tuesday, 25 = September 2007 6:43 AM
To: = peter_blatherwick@mitel.com
Cc: 'ecrit'
Subject: RE: [Ecrit] = multiple location sources

 

I understand the “moving parts” now.  Clearly, DHCP is much more mature and likely to = work today than LLDP-MED is.

 

I think the emergency call = documentation is not the place to educate device developers of how startup sequences involving LLDP, DHCP and HTTP based protocols could best be = done.

 

Brian

 

From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Monday, September = 24, 2007 4:35 PM
To: Brian Rosen
Cc: 'Stark, Barbara'; = 'ecrit'
Subject: RE: [Ecrit] = multiple location sources

 


> I’m not = sure how you decided that LLDP-MED has fewer moving parts or is more reliable = than DHCP
LLDP is running at the other end of the physical wire the device in question = is plugged into.  (In the case of wireless, it is likely at the access = point, or just behind it.)  In that sense, there are only 2 moving parts = that have to be operating correctly -- the phone itself, and the L2 access = switch it is plugged into.  Even with DHCP there is at least the network infrastructure, a server somewhere, and often DHCP relay to set up to = get it all working.  HELD has a bunch more mechanics that all must be = working correctly on top of that.  

> MIGHT lead to an implied = ordering, but I don’t think it’s even useful to say that.  I’m = not sure why it matters.
I terms of the phone bcp, you are probably right, since other MUSTs make = sure that there is always exactly one answer anyway.  However, device developers will certainly care -- getting startup sequence right is = important and will not be immediately obvious to many not deep in the details of = each piece.  The DSL Forum doc is really helpful  from that perspective.   =

-- Peter


 

"Brian Rosen" <br@brianrosen.net>

24.09.07 16:22

       
        To:        <peter_blatherwick@mitel.com>, "'Stark, = Barbara'" <bs7652@att.com>
        cc:       =  "'ecrit'" <ecrit@ietf.org>
        Subject:        RE: [Ecrit] = multiple location sources




I’m not sure how you decided that = LLDP-MED has fewer moving parts or is more reliable than DHCP.  I think = likely it’s the other way right now.  
 
Certainly, if your are autoconfiguring with LLDP, you = will want that to complete before you do DHCP.  I don’t think we have = to say that, but we can if we need to.  
 
I agree you need an IP address before you can invoke = HELD.  I don’t think we have to say that.
 
This MIGHT lead to an implied ordering, but I = don’t think it’s even useful to say that.  I’m not sure why = it matters.
 
Brian
 

 


From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] =
Sent: Monday, September 24, 2007 12:49 PM
To: Stark, Barbara
Cc: ecrit
Subject: RE: [Ecrit] multiple location sources =
 

Hi,
I agree that the DSL Forum document makes a very good starting point for orderly acquisition of location at startup, accounting for all 3 = methods.  I also believe it points to a preference order, if there are = multiple answers coming back, which is LLDP-MED --> DHCP --> HELD. =  Reasoning for this order (my opinion) is that it progresses from "least = moving parts" / most reliable (LLDP-MED) to most, and also follows the = natural layering of the overall system (L2 --> L2.5 --> L7).   In the = end, only ONE method should ever be selected, as the sequence diagram shows. =  

Your point below, that the methods can and should progress in parallel = is valid.  However there are constraints to this, notably: =

o If LLDP-MED is being used to autoconfigure voice VLAN ID, then the = device should wait to see if that stage succeeds before contacting DHCP.  Otherwise, the device may get an IP address on the default VLAN, = only to have to drop it and try again on the voice VLAN.  If it had started = to use this address for something already (say for HELD), then ongoing = interaction would be dropped and confusion would likely ensue.   =

o Before HELD can work, an IP address is needed.   =

I think these constraints are really just a reflection of the natural = layering in the end.  

IMHO, orderly startup beats the few extra seconds delay incurred in = making sure the constraints are not broken.   We are only talking about a very = few seconds here after all.  

-- Peter

 

"Stark, Barbara" <bs7652@att.com>

24.09.07 08:48

       
       To:       =  "Winterbottom, James" <James.Winterbottom@andrew.com>, "Karl Heinz Wolf" <khwolf1@gmail.com>, "ecrit" = <ecrit@ietf.org>
       cc:       =  
       Subject:        RE: = [Ecrit] multiple location sources





It's not always desirable to wait for a protocol to time-out, before = launching the next protocol. Specifically, if a device is configured to do DHCP = for IP address configuration, it should launch its DHCP discovery ASAP, with = options, instead of waiting the 4 or 5 seconds for LLDP-MED to time out. This = prevents unnecessary delays in the bootstrap process. It should be easy enough = for the device to use a received LLDP-MED location, even if it arrives after the = DHCP response.
Barbara
 
--------------------
[AJW] My first question is why are you using more than one acquisition protocol. My thoughts would be use one, if it fails, pick a different = one. Never invoke both at the same time so you have this problem of = choice.
 

*****

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

 


= -------------------------------------------------------------------------= -----------------------
= This message is for the designated recipien= t only and may
= contain privileged, proprietary, or otherwise pr= ivate information.  
= If you have received it in error, plea= se notify the sender
= immediately and delete the original.  Any&n= bsp;unauthorized use of
this email is prohibited.
= -------------------------------------------------------------------------= -----------------------
[mf2]

 

------=_NextPart_000_1BA9_01C7FF71.2CA72F90-- --===============2057990543== 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 --===============2057990543==-- From ecrit-bounces@ietf.org Tue Sep 25 18:25:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaIpp-0001na-Sj; Tue, 25 Sep 2007 18:24:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaIpp-0001nN-9a for ecrit@ietf.org; Tue, 25 Sep 2007 18:24:53 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaIpi-0004Ha-NG for ecrit@ietf.org; Tue, 25 Sep 2007 18:24:53 -0400 X-SEF-Processed: 5_0_0_910__2007_09_25_17_34_11 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 25 Sep 2007 17:34:09 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Sep 2007 17:24:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] multiple location sources Date: Tue, 25 Sep 2007 17:24:28 -0500 Message-ID: In-Reply-To: <1ba801c7ff92$b3b8cf90$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] multiple location sources Thread-Index: Acf+6mvvfdfiVsj+SRWgXWkwKUNklAAAMBSgAAPrzUAABKJNcAAtJWiw References: <194701c7fee8$927a12d0$640fa8c0@cis.neustar.com> <19aa01c7feeb$90c88ae0$640fa8c0@cis.neustar.com> <1ba801c7ff92$b3b8cf90$640fa8c0@cis.neustar.com> From: "Thomson, Martin" To: "Brian Rosen" , X-OriginalArrivalTime: 25 Sep 2007 22:24:30.0950 (UTC) FILETIME=[D79D5860:01C7FFC2] X-Spam-Score: 0.0 (/) X-Scan-Signature: e4e7b084ad5ab70bec6636d1707b49c1 Cc: ecrit X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0683104275==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0683104275== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FFC2.D7A155D8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FFC2.D7A155D8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VW5jZXJ0YWludHkgYmVjb21lcyB1c2VmdWwgaW5mb3JtYXRpb24gaGVyZS4gIEl0IGlzIGltcG9y dGFudCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHRoZSBsb2NhdGlvbiBvZiB0aGUgQVAsIHdoaWNo IGlzIGtub3duIHRvIGEgY2VydGFpbiBwcmVjaXNpb24sIGFuZCB0aGUgbG9jYXRpb24gb2YgdGhl IGhvc3QuICBJZiB5b3UgYXJlIHVzaW5nIHRoZSBsb2NhdGlvbiBvZiB0aGUgQVAgdG8gZGV0ZXJt aW5lIHRoZSBsb2NhdGlvbiBvZiB0aGUgaG9zdCwgdGhlbiB0aGUgbG9jYXRpb24gb2YgdGhlIGhv c3QgaXMgdGhlIGNvdmVyYWdlIGFyZWEgb2YgdGhlIEFQLiAgVGhlcmVmb3JlLCB0aGVyZSBpcyBh IGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgdHdvLg0KDQogDQoNClRoYXQgaXMsIGlmIHRoZSBBUCBs b2NhdGlvbiBpcyBrbm93biBhcyAoeCwgeSkgd2l0aCByZWxhdGl2ZWx5IGhpZ2ggcHJlY2lzaW9u LCB0aGVuIHRoZSBsb2NhdGlvbiBvZiB0aGUgaG9zdCBpcyAoeCwgeSkgZ2l2ZSBvciB0YWtlIHRo ZSBlZmZlY3RpdmUgcmFuZ2Ugb2YgdGhlIEFQLiAgVGhlcmVmb3JlLCB0aGUgbG9jYXRpb24gb2Yg dGhlIEFQIGFuZCB0aGUgbG9jYXRpb24gb2YgYSBob3N0IGRpZmZlci4NCg0KIA0KDQpCdXQgdGhl biwgdGhhdCBkb2VzbuKAmXQgd29yayB2ZXJ5IHdlbGwgd2l0aCBMQ0kuDQoNCiANCg0KQ2FzZSAz IHdvdWxkIGJlIG5pY2UsIGJ1dCBJIGRvdWJ0IHRoYXQgaXQgd2lsbCBldmVyIGFjY291bnQgZm9y IDEwMCUgb2YgY2FzZXMuDQoNCiANCg0KVGEsDQoNCk1hcnRpbg0KDQogDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNCkZyb206IEJyaWFuIFJvc2VuIFttYWlsdG86YnJAYnJp YW5yb3Nlbi5uZXRdIA0KU2VudDogV2VkbmVzZGF5LCAyNiBTZXB0ZW1iZXIgMjAwNyAyOjQwIEFN DQpUbzogVGhvbXNvbiwgTWFydGluOyBwZXRlcl9ibGF0aGVyd2lja0BtaXRlbC5jb20NCkNjOiAn ZWNyaXQnDQpTdWJqZWN0OiBSRTogW0Vjcml0XSBtdWx0aXBsZSBsb2NhdGlvbiBzb3VyY2VzDQoN CiANCg0KVGhhdOKAmXMgb2Z0ZW4gYWxsIHlvdSBjYW4gZ2V0Lg0KDQogDQoNClRoZXJlIGFyZSBv bmx5IHRocmVlIGNhc2VzOg0KDQoxLglUaGUgdXNlciBtZWFzdXJlcyBpdHMgb3duIGxvY2F0aW9u LCBubyBMQ1AgbmVlZGVkDQoyLglUaGUgbG9jYXRpb24gb2YgdGhlIGNsaWVudHMgb2YgdGhlIEFQ IGFyZSByZXBvcnRlZCBhcyB0aGUgbG9jYXRpb24gb2YgdGhlIEFQDQozLglUaGVyZSBpcyB0cmlh bmd1bGF0aW9uIGJldHdlZW4gQVBzIGFuZCBjbGllbnRzIHRvIGdldCBhIG1vcmUgYWNjdXJhdGUg bG9jYXRpb24NCg0KIA0KDQpDYXNlIDIgaXMgZ29pbmcgdG8gYmUgdGhlIG5vcm0gZm9yIGEgd2hp bGUuDQoNCiANCg0KVGhlIGFiaWxpdHkgdG8gdHJpYW5ndWxhdGUgaXMgYXJvdW5kLCBidXQgbm90 IHdpZGVseSBkZXBsb3llZC4NCg0KIA0KDQpCcmlhbg0KDQogDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCkZyb206IFRob21zb24sIE1hcnRpbiBbbWFpbHRvOk1hcnRpbi5U aG9tc29uQGFuZHJldy5jb21dIA0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMjQsIDIwMDcgNjoz NSBQTQ0KVG86IEJyaWFuIFJvc2VuOyBwZXRlcl9ibGF0aGVyd2lja0BtaXRlbC5jb20NCkNjOiBl Y3JpdA0KU3ViamVjdDogUkU6IFtFY3JpdF0gbXVsdGlwbGUgbG9jYXRpb24gc291cmNlcw0KDQog DQoNCkFuIGltcG9ydGFudCBjYXZlYXQgdG8gZG9jdW1lbnQgaXMgdGhhdCBMTERQLU1FRCBkb2Vz buKAmXQgYWx3YXlzIHByb3ZpZGUgdGhlIGhvc3QgbG9jYXRpb24uICBBbiA4MDIuMTEgQVAgbWln aHQgb25seSBiZSBhYmxlIHRvIHByb3ZpZGUgaXRzIG93biBsb2NhdGlvbiwgd2hpY2gsIGlmIGl0 IGlzIGluIHRoZSBuZXh0IGJ1aWxkaW5nLCBpc27igJl0IG11Y2ggdXNlLg0KDQogDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkZyb206IEJyaWFuIFJvc2VuIFttYWlsdG86 YnJAYnJpYW5yb3Nlbi5uZXRdIA0KU2VudDogVHVlc2RheSwgMjUgU2VwdGVtYmVyIDIwMDcgNjo0 MyBBTQ0KVG86IHBldGVyX2JsYXRoZXJ3aWNrQG1pdGVsLmNvbQ0KQ2M6ICdlY3JpdCcNClN1Ympl Y3Q6IFJFOiBbRWNyaXRdIG11bHRpcGxlIGxvY2F0aW9uIHNvdXJjZXMNCg0KIA0KDQpJIHVuZGVy c3RhbmQgdGhlIOKAnG1vdmluZyBwYXJ0c+KAnSBub3cuICBDbGVhcmx5LCBESENQIGlzIG11Y2gg bW9yZSBtYXR1cmUgYW5kIGxpa2VseSB0byB3b3JrIHRvZGF5IHRoYW4gTExEUC1NRUQgaXMuDQoN CiANCg0KSSB0aGluayB0aGUgZW1lcmdlbmN5IGNhbGwgZG9jdW1lbnRhdGlvbiBpcyBub3QgdGhl IHBsYWNlIHRvIGVkdWNhdGUgZGV2aWNlIGRldmVsb3BlcnMgb2YgaG93IHN0YXJ0dXAgc2VxdWVu Y2VzIGludm9sdmluZyBMTERQLCBESENQIGFuZCBIVFRQIGJhc2VkIHByb3RvY29scyBjb3VsZCBi ZXN0IGJlIGRvbmUuDQoNCiANCg0KQnJpYW4NCg0KIA0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQpGcm9tOiBwZXRlcl9ibGF0aGVyd2lja0BtaXRlbC5jb20gW21haWx0bzpw ZXRlcl9ibGF0aGVyd2lja0BtaXRlbC5jb21dIA0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMjQs IDIwMDcgNDozNSBQTQ0KVG86IEJyaWFuIFJvc2VuDQpDYzogJ1N0YXJrLCBCYXJiYXJhJzsgJ2Vj cml0Jw0KU3ViamVjdDogUkU6IFtFY3JpdF0gbXVsdGlwbGUgbG9jYXRpb24gc291cmNlcw0KDQog DQoNCg0KPiBJ4oCZbSBub3Qgc3VyZSBob3cgeW91IGRlY2lkZWQgdGhhdCBMTERQLU1FRCBoYXMg ZmV3ZXIgbW92aW5nIHBhcnRzIG9yIGlzIG1vcmUgcmVsaWFibGUgdGhhbiBESENQIA0KTExEUCBp cyBydW5uaW5nIGF0IHRoZSBvdGhlciBlbmQgb2YgdGhlIHBoeXNpY2FsIHdpcmUgdGhlIGRldmlj ZSBpbiBxdWVzdGlvbiBpcyBwbHVnZ2VkIGludG8uICAoSW4gdGhlIGNhc2Ugb2Ygd2lyZWxlc3Ms IGl0IGlzIGxpa2VseSBhdCB0aGUgYWNjZXNzIHBvaW50LCBvciBqdXN0IGJlaGluZCBpdC4pICBJ biB0aGF0IHNlbnNlLCB0aGVyZSBhcmUgb25seSAyIG1vdmluZyBwYXJ0cyB0aGF0IGhhdmUgdG8g YmUgb3BlcmF0aW5nIGNvcnJlY3RseSAtLSB0aGUgcGhvbmUgaXRzZWxmLCBhbmQgdGhlIEwyIGFj Y2VzcyBzd2l0Y2ggaXQgaXMgcGx1Z2dlZCBpbnRvLiAgRXZlbiB3aXRoIERIQ1AgdGhlcmUgaXMg YXQgbGVhc3QgdGhlIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUsIGEgc2VydmVyIHNvbWV3aGVyZSwg YW5kIG9mdGVuIERIQ1AgcmVsYXkgdG8gc2V0IHVwIHRvIGdldCBpdCBhbGwgd29ya2luZy4gIEhF TEQgaGFzIGEgYnVuY2ggbW9yZSBtZWNoYW5pY3MgdGhhdCBhbGwgbXVzdCBiZSB3b3JraW5nIGNv cnJlY3RseSBvbiB0b3Agb2YgdGhhdC4gICANCg0KPiBNSUdIVCBsZWFkIHRvIGFuIGltcGxpZWQg b3JkZXJpbmcsIGJ1dCBJIGRvbuKAmXQgdGhpbmsgaXTigJlzIGV2ZW4gdXNlZnVsIHRvIHNheSB0 aGF0LiAgSeKAmW0gbm90IHN1cmUgd2h5IGl0IG1hdHRlcnMuIA0KSSB0ZXJtcyBvZiB0aGUgcGhv bmUgYmNwLCB5b3UgYXJlIHByb2JhYmx5IHJpZ2h0LCBzaW5jZSBvdGhlciBNVVNUcyBtYWtlIHN1 cmUgdGhhdCB0aGVyZSBpcyBhbHdheXMgZXhhY3RseSBvbmUgYW5zd2VyIGFueXdheS4gIEhvd2V2 ZXIsIGRldmljZSBkZXZlbG9wZXJzIHdpbGwgY2VydGFpbmx5IGNhcmUgLS0gZ2V0dGluZyBzdGFy dHVwIHNlcXVlbmNlIHJpZ2h0IGlzIGltcG9ydGFudCBhbmQgd2lsbCBub3QgYmUgaW1tZWRpYXRl bHkgb2J2aW91cyB0byBtYW55IG5vdCBkZWVwIGluIHRoZSBkZXRhaWxzIG9mIGVhY2ggcGllY2Uu ICBUaGUgRFNMIEZvcnVtIGRvYyBpcyByZWFsbHkgaGVscGZ1bCAgZnJvbSB0aGF0IHBlcnNwZWN0 aXZlLiAgIA0KDQotLSBQZXRlciANCg0KDQoNCiANCg0KIkJyaWFuIFJvc2VuIiA8YnJAYnJpYW5y b3Nlbi5uZXQ+IA0KDQoyNC4wOS4wNyAxNjoyMiANCg0KICAgICAgICANCiAgICAgICAgVG86ICAg ICAgICA8cGV0ZXJfYmxhdGhlcndpY2tAbWl0ZWwuY29tPiwgIidTdGFyaywgQmFyYmFyYSciIDxi czc2NTJAYXR0LmNvbT4gDQogICAgICAgIGNjOiAgICAgICAgIidlY3JpdCciIDxlY3JpdEBpZXRm Lm9yZz4gDQogICAgICAgIFN1YmplY3Q6ICAgICAgICBSRTogW0Vjcml0XSBtdWx0aXBsZSBsb2Nh dGlvbiBzb3VyY2VzDQoNCg0KDQoNCknigJltIG5vdCBzdXJlIGhvdyB5b3UgZGVjaWRlZCB0aGF0 IExMRFAtTUVEIGhhcyBmZXdlciBtb3ZpbmcgcGFydHMgb3IgaXMgbW9yZSByZWxpYWJsZSB0aGFu IERIQ1AuICBJIHRoaW5rIGxpa2VseSBpdOKAmXMgdGhlIG90aGVyIHdheSByaWdodCBub3cuICAg DQogIA0KQ2VydGFpbmx5LCBpZiB5b3VyIGFyZSBhdXRvY29uZmlndXJpbmcgd2l0aCBMTERQLCB5 b3Ugd2lsbCB3YW50IHRoYXQgdG8gY29tcGxldGUgYmVmb3JlIHlvdSBkbyBESENQLiAgSSBkb27i gJl0IHRoaW5rIHdlIGhhdmUgdG8gc2F5IHRoYXQsIGJ1dCB3ZSBjYW4gaWYgd2UgbmVlZCB0by4g ICANCiAgDQpJIGFncmVlIHlvdSBuZWVkIGFuIElQIGFkZHJlc3MgYmVmb3JlIHlvdSBjYW4gaW52 b2tlIEhFTEQuICBJIGRvbuKAmXQgdGhpbmsgd2UgaGF2ZSB0byBzYXkgdGhhdC4gDQogIA0KVGhp cyBNSUdIVCBsZWFkIHRvIGFuIGltcGxpZWQgb3JkZXJpbmcsIGJ1dCBJIGRvbuKAmXQgdGhpbmsg aXTigJlzIGV2ZW4gdXNlZnVsIHRvIHNheSB0aGF0LiAgSeKAmW0gbm90IHN1cmUgd2h5IGl0IG1h dHRlcnMuIA0KICANCkJyaWFuIA0KICANCg0KIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQoNCkZyb206IHBldGVyX2JsYXRoZXJ3aWNrQG1pdGVsLmNvbSBbbWFpbHRvOnBl dGVyX2JsYXRoZXJ3aWNrQG1pdGVsLmNvbV0gDQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAyNCwg MjAwNyAxMjo0OSBQTQ0KVG86IFN0YXJrLCBCYXJiYXJhDQpDYzogZWNyaXQNClN1YmplY3Q6IFJF OiBbRWNyaXRdIG11bHRpcGxlIGxvY2F0aW9uIHNvdXJjZXMgDQogIA0KDQpIaSwgDQpJIGFncmVl IHRoYXQgdGhlIERTTCBGb3J1bSBkb2N1bWVudCBtYWtlcyBhIHZlcnkgZ29vZCBzdGFydGluZyBw b2ludCBmb3Igb3JkZXJseSBhY3F1aXNpdGlvbiBvZiBsb2NhdGlvbiBhdCBzdGFydHVwLCBhY2Nv dW50aW5nIGZvciBhbGwgMyBtZXRob2RzLiAgSSBhbHNvIGJlbGlldmUgaXQgcG9pbnRzIHRvIGEg cHJlZmVyZW5jZSBvcmRlciwgaWYgdGhlcmUgYXJlIG11bHRpcGxlIGFuc3dlcnMgY29taW5nIGJh Y2ssIHdoaWNoIGlzIExMRFAtTUVEIC0tPiBESENQIC0tPiBIRUxELiAgUmVhc29uaW5nIGZvciB0 aGlzIG9yZGVyIChteSBvcGluaW9uKSBpcyB0aGF0IGl0IHByb2dyZXNzZXMgZnJvbSAibGVhc3Qg bW92aW5nIHBhcnRzIiAvIG1vc3QgcmVsaWFibGUgKExMRFAtTUVEKSB0byBtb3N0LCBhbmQgYWxz byBmb2xsb3dzIHRoZSBuYXR1cmFsIGxheWVyaW5nIG9mIHRoZSBvdmVyYWxsIHN5c3RlbSAoTDIg LS0+IEwyLjUgLS0+IEw3KS4gICBJbiB0aGUgZW5kLCBvbmx5IE9ORSBtZXRob2Qgc2hvdWxkIGV2 ZXIgYmUgc2VsZWN0ZWQsIGFzIHRoZSBzZXF1ZW5jZSBkaWFncmFtIHNob3dzLiAgIA0KDQpZb3Vy IHBvaW50IGJlbG93LCB0aGF0IHRoZSBtZXRob2RzIGNhbiBhbmQgc2hvdWxkIHByb2dyZXNzIGlu IHBhcmFsbGVsIGlzIHZhbGlkLiAgSG93ZXZlciB0aGVyZSBhcmUgY29uc3RyYWludHMgdG8gdGhp cywgbm90YWJseTogDQoNCm8gSWYgTExEUC1NRUQgaXMgYmVpbmcgdXNlZCB0byBhdXRvY29uZmln dXJlIHZvaWNlIFZMQU4gSUQsIHRoZW4gdGhlIGRldmljZSBzaG91bGQgd2FpdCB0byBzZWUgaWYg dGhhdCBzdGFnZSBzdWNjZWVkcyBiZWZvcmUgY29udGFjdGluZyBESENQLiAgT3RoZXJ3aXNlLCB0 aGUgZGV2aWNlIG1heSBnZXQgYW4gSVAgYWRkcmVzcyBvbiB0aGUgZGVmYXVsdCBWTEFOLCBvbmx5 IHRvIGhhdmUgdG8gZHJvcCBpdCBhbmQgdHJ5IGFnYWluIG9uIHRoZSB2b2ljZSBWTEFOLiAgSWYg aXQgaGFkIHN0YXJ0ZWQgdG8gdXNlIHRoaXMgYWRkcmVzcyBmb3Igc29tZXRoaW5nIGFscmVhZHkg KHNheSBmb3IgSEVMRCksIHRoZW4gb25nb2luZyBpbnRlcmFjdGlvbiB3b3VsZCBiZSBkcm9wcGVk IGFuZCBjb25mdXNpb24gd291bGQgbGlrZWx5IGVuc3VlLiAgIA0KDQpvIEJlZm9yZSBIRUxEIGNh biB3b3JrLCBhbiBJUCBhZGRyZXNzIGlzIG5lZWRlZC4gICANCg0KSSB0aGluayB0aGVzZSBjb25z dHJhaW50cyBhcmUgcmVhbGx5IGp1c3QgYSByZWZsZWN0aW9uIG9mIHRoZSBuYXR1cmFsIGxheWVy aW5nIGluIHRoZSBlbmQuICAgDQoNCklNSE8sIG9yZGVybHkgc3RhcnR1cCBiZWF0cyB0aGUgZmV3 IGV4dHJhIHNlY29uZHMgZGVsYXkgaW5jdXJyZWQgaW4gbWFraW5nIHN1cmUgdGhlIGNvbnN0cmFp bnRzIGFyZSBub3QgYnJva2VuLiAgIFdlIGFyZSBvbmx5IHRhbGtpbmcgYWJvdXQgYSB2ZXJ5IGZl dyBzZWNvbmRzIGhlcmUgYWZ0ZXIgYWxsLiAgIA0KDQotLSBQZXRlciANCg0KICANCg0KIlN0YXJr LCBCYXJiYXJhIiA8YnM3NjUyQGF0dC5jb20+IA0KDQoyNC4wOS4wNyAwODo0OCANCg0KICAgICAg ICANCiAgICAgICBUbzogICAgICAgICJXaW50ZXJib3R0b20sIEphbWVzIiA8SmFtZXMuV2ludGVy Ym90dG9tQGFuZHJldy5jb20+LCAiS2FybCBIZWlueiBXb2xmIiA8a2h3b2xmMUBnbWFpbC5jb20+ LCAiZWNyaXQiIDxlY3JpdEBpZXRmLm9yZz4gDQogICAgICAgY2M6ICAgICAgICAgDQogICAgICAg U3ViamVjdDogICAgICAgIFJFOiBbRWNyaXRdIG11bHRpcGxlIGxvY2F0aW9uIHNvdXJjZXMNCg0K DQoNCg0KDQpJdCdzIG5vdCBhbHdheXMgZGVzaXJhYmxlIHRvIHdhaXQgZm9yIGEgcHJvdG9jb2wg dG8gdGltZS1vdXQsIGJlZm9yZSBsYXVuY2hpbmcgdGhlIG5leHQgcHJvdG9jb2wuIFNwZWNpZmlj YWxseSwgaWYgYSBkZXZpY2UgaXMgY29uZmlndXJlZCB0byBkbyBESENQIGZvciBJUCBhZGRyZXNz IGNvbmZpZ3VyYXRpb24sIGl0IHNob3VsZCBsYXVuY2ggaXRzIERIQ1AgZGlzY292ZXJ5IEFTQVAs IHdpdGggb3B0aW9ucywgaW5zdGVhZCBvZiB3YWl0aW5nIHRoZSA0IG9yIDUgc2Vjb25kcyBmb3Ig TExEUC1NRUQgdG8gdGltZSBvdXQuIFRoaXMgcHJldmVudHMgdW5uZWNlc3NhcnkgZGVsYXlzIGlu IHRoZSBib290c3RyYXAgcHJvY2Vzcy4gSXQgc2hvdWxkIGJlIGVhc3kgZW5vdWdoIGZvciB0aGUg ZGV2aWNlIHRvIHVzZSBhIHJlY2VpdmVkIExMRFAtTUVEIGxvY2F0aW9uLCBldmVuIGlmIGl0IGFy cml2ZXMgYWZ0ZXIgdGhlIERIQ1AgcmVzcG9uc2UuIA0KQmFyYmFyYSANCiANCi0tLS0tLS0tLS0t LS0tLS0tLS0tIA0KW0FKV10gTXkgZmlyc3QgcXVlc3Rpb24gaXMgd2h5IGFyZSB5b3UgdXNpbmcg bW9yZSB0aGFuIG9uZSBhY3F1aXNpdGlvbiBwcm90b2NvbC4gTXkgdGhvdWdodHMgd291bGQgYmUg dXNlIG9uZSwgaWYgaXQgZmFpbHMsIHBpY2sgYSBkaWZmZXJlbnQgb25lLiBOZXZlciBpbnZva2Ug Ym90aCBhdCB0aGUgc2FtZSB0aW1lIHNvIHlvdSBoYXZlIHRoaXMgcHJvYmxlbSBvZiBjaG9pY2Uu IA0KICANCg0KKioqKiogDQoNClRoZSBpbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBpcyBpbnRlbmRl ZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQg YW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCwgcHJvcHJpZXRhcnksIGFuZC9vciBwcml2aWxl Z2VkIG1hdGVyaWFsLiBBbnkgcmV2aWV3LCByZXRyYW5zbWlzc2lvbiwgZGlzc2VtaW5hdGlvbiBv ciBvdGhlciB1c2Ugb2YsIG9yIHRha2luZyBvZiBhbnkgYWN0aW9uIGluIHJlbGlhbmNlIHVwb24g dGhpcyBpbmZvcm1hdGlvbiBieSBwZXJzb25zIG9yIGVudGl0aWVzIG90aGVyIHRoYW4gdGhlIGlu dGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZWQgdGhpcyBpbiBl cnJvciwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoZSBtYXRlcmlhbCBm cm9tIGFsbCBjb21wdXRlcnMuIEdBNjIzX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkVjcml0IG1haWxpbmcgbGlzdA0KRWNyaXRAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0IA0KDQogDQoNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRo ZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwg cHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3Ug aGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1l ZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9m DQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClttZjJdDQoNCiANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBv bmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lz ZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBv cmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0 ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJdDQo= ------_=_NextPart_001_01C7FFC2.D7A155D8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6c3QxPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQoNCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDExIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjwhLS1baWYg IW1zb10+DQo8c3R5bGU+DQp2XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoq IHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1 bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+ DQo8IVtlbmRpZl0tLT48bzpTbWFydFRhZ1R5cGUNCiBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFz LW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyIgbmFtZT0iUGVyc29uTmFtZSIvPg0KPCEt LVtpZiAhbXNvXT4NCjxzdHlsZT4NCnN0MVw6KntiZWhhdmlvcjp1cmwoI2RlZmF1bHQjaWVvb3Vp KSB9DQo8L3N0eWxlPg0KPCFbZW5kaWZdLS0+DQo8c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZp bml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe2NvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcA0KCXttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnNwYW4uRW1haWxTdHls ZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OkFyaWFsOw0KCWNv bG9yOmJsdWU7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRl eHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6bWFyb29uOw0KCWZv bnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246 bm9uZSBub25lO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OkFyaWFsOw0KCWNvbG9yOmJsdWU7DQoJZm9udC13ZWlnaHQ6bm9ybWFs Ow0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6QXJpYWw7DQoJY29sb3I6bWFyb29uOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250 LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCkBwYWdlIFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBw dCA5MC4wcHQ7fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KIC8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCiBAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyOTI4MzY1NTk7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi0xMzQ3OTI2MTkwO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjIx MjM2NDc2MzA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz OjI3MzgzMjgyNCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2 NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7 bXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVs LXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0 Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2 ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsOA0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVs LXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFy Z2luLWJvdHRvbTowY207fQ0KLS0+DQo8L3N0eWxlPg0KPCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQogPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVT IGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bWFyb29uIGZhY2U9QXJpYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjptYXJvb24n PlVuY2VydGFpbnR5IGJlY29tZXMgdXNlZnVsIGluZm9ybWF0aW9uDQpoZXJlLiDCoEl0IGlzIGlt cG9ydGFudCB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHRoZSBsb2NhdGlvbiBvZiB0aGUgQVAsIHdo aWNoIGlzDQprbm93biB0byBhIGNlcnRhaW4gcHJlY2lzaW9uLCBhbmQgdGhlIGxvY2F0aW9uIG9m IHRoZSBob3N0LsKgIElmIHlvdSBhcmUgdXNpbmcNCnRoZSBsb2NhdGlvbiBvZiB0aGUgQVAgdG8g ZGV0ZXJtaW5lIHRoZSBsb2NhdGlvbiBvZiB0aGUgaG9zdCwgdGhlbiB0aGUgbG9jYXRpb24NCm9m IHRoZSBob3N0IGlzIHRoZSBjb3ZlcmFnZSBhcmVhIG9mIHRoZSBBUC7CoCBUaGVyZWZvcmUsIHRo ZXJlIGlzIGEgZGlmZmVyZW5jZQ0KYmV0d2VlbiB0aGUgdHdvLjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bWFyb29u IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpB cmlhbDtjb2xvcjptYXJvb24nPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bWFyb29uIGZhY2U9QXJpYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpt YXJvb24nPlRoYXQgaXMsIGlmIHRoZSBBUCBsb2NhdGlvbiBpcyBrbm93biBhcyAoeCwNCnkpIHdp dGggcmVsYXRpdmVseSBoaWdoIHByZWNpc2lvbiwgdGhlbiB0aGUgbG9jYXRpb24gb2YgdGhlIGhv c3QgaXMgKHgsIHkpIGdpdmUNCm9yIHRha2UgdGhlIGVmZmVjdGl2ZSByYW5nZSBvZiB0aGUgQVAu wqAgVGhlcmVmb3JlLCB0aGUgbG9jYXRpb24gb2YgdGhlIEFQIGFuZA0KdGhlIGxvY2F0aW9uIG9m IGEgaG9zdCBkaWZmZXIuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1tYXJvb24gZmFjZT1BcmlhbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm1hcm9vbic+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MiBjb2xvcj1tYXJvb24gZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl Og0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm1hcm9vbic+QnV0IHRoZW4sIHRoYXQg ZG9lc27igJl0IHdvcmsgdmVyeQ0Kd2VsbCB3aXRoIExDSS48bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW1hcm9vbiBm YWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJp YWw7Y29sb3I6bWFyb29uJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW1hcm9vbiBmYWNlPUFyaWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bWFy b29uJz5DYXNlIDMgd291bGQgYmUgbmljZSwgYnV0IEkgZG91YnQgdGhhdA0KaXQgd2lsbCBldmVy IGFjY291bnQgZm9yIDEwMCUgb2YgY2FzZXMuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1tYXJvb24gZmFjZT1Bcmlh bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9y Om1hcm9vbic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1tYXJvb24gZmFjZT1BcmlhbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm1hcm9vbic+VGEs PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250 IHNpemU9MiBjb2xvcj1tYXJvb24gZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0K MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm1hcm9vbic+TWFydGluPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xv cj1tYXJvb24gZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQt ZmFtaWx5OkFyaWFsO2NvbG9yOm1hcm9vbic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcD4NCg0KPGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz4NCg0KPGRpdj4NCg0KPGRpdiBjbGFzcz1N c29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PGZvbnQgc2l6 ZT0zDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0 Jz4NCg0KPGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyIHRhYmluZGV4PS0xPg0K DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PGZvbnQgc2l6 ZT0yIGZhY2U9VGFob21hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1p bHk6VGFob21hO2ZvbnQtd2VpZ2h0OmJvbGQnPkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZvbnQg c2l6ZT0yDQpmYWNlPVRhaG9tYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpUYWhvbWEnPiBCcmlhbiBSb3Nlbg0KW21haWx0bzpickBicmlhbnJvc2VuLm5ldF0gPGJy Pg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlNlbnQ6PC9zcGFuPjwvYj4gV2Vk bmVzZGF5LCAyNiBTZXB0ZW1iZXIgMjAwNw0KMjo0MCBBTTxicj4NCjxiPjxzcGFuIHN0eWxlPSdm b250LXdlaWdodDpib2xkJz5Ubzo8L3NwYW4+PC9iPiBUaG9tc29uLCBNYXJ0aW47DQpwZXRlcl9i bGF0aGVyd2lja0BtaXRlbC5jb208YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9s ZCc+Q2M6PC9zcGFuPjwvYj4gJ2Vjcml0Jzxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdo dDpib2xkJz5TdWJqZWN0Ojwvc3Bhbj48L2I+IFJFOiBbRWNyaXRdIG11bHRpcGxlDQpsb2NhdGlv biBzb3VyY2VzPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1B cmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTEuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2Nv bG9yOmJsdWUnPlRoYXTigJlzIG9mdGVuIGFsbCB5b3UgY2FuIGdldC48bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJs dWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTEuMHB0O2ZvbnQtZmFtaWx5 OkFyaWFsO2NvbG9yOmJsdWUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6DQoxMS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1 ZSc+VGhlcmUgYXJlIG9ubHkgdGhyZWUgY2FzZXM6PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCg0KPG9sIHN0eWxlPSdtYXJnaW4tdG9wOjBjbScgc3RhcnQ9MSB0eXBlPTE+DQogPGxpIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nY29sb3I6Ymx1ZTttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyc+ PGZvbnQgc2l6ZT0yDQogICAgIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTpBcmlhbCc+VGhlDQogICAgIHVzZXIgbWVhc3VyZXMg aXRzIG93biBsb2NhdGlvbiwgbm8gTENQIG5lZWRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L2xpPg0KIDxsaSBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J2NvbG9yOmJsdWU7bXNvLWxpc3Q6bDEg bGV2ZWwxIGxmbzMnPjxmb250IHNpemU9Mg0KICAgICBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwnPlRoZQ0KICAgICBs b2NhdGlvbiBvZiB0aGUgY2xpZW50cyBvZiB0aGUgQVAgYXJlIHJlcG9ydGVkIGFzIHRoZSBsb2Nh dGlvbiBvZiB0aGUgQVA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9saT4NCiA8bGkgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdjb2xvcjpibHVlO21zby1saXN0OmwxIGxldmVsMSBsZm8zJz48Zm9u dCBzaXplPTINCiAgICAgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsJz5UaGVyZQ0KICAgICBpcyB0cmlhbmd1bGF0aW9u IGJldHdlZW4gQVBzIGFuZCBjbGllbnRzIHRvIGdldCBhIG1vcmUgYWNjdXJhdGUgbG9jYXRpb248 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9saT4NCjwvb2w+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6DQoxMS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBj b2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjExLjBwdDtmb250 LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz5DYXNlIDIgaXMgZ29pbmcgdG8gYmUgdGhlIG5vcm0g Zm9yIGENCndoaWxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6DQoxMS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNp emU9MiBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjExLjBw dDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz5UaGUgYWJpbGl0eSB0byB0cmlhbmd1bGF0 ZSBpcyBhcm91bmQsIGJ1dA0Kbm90IHdpZGVseSBkZXBsb3llZC48bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUg ZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTEuMHB0O2ZvbnQtZmFtaWx5OkFy aWFsO2NvbG9yOmJsdWUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6DQoxMS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+ QnJpYW48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl Og0KMTEuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsdWUnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+DQoNCjxkaXY+DQoN CjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50 ZXInPjxmb250IHNpemU9Mw0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEyLjBwdCc+DQoNCjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlciB0 YWJpbmRleD0tMT4NCg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxiPjxmb250IHNpemU9MiBmYWNlPVRhaG9tYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDsNCmZvbnQtZmFtaWx5OlRhaG9tYTtmb250LXdlaWdodDpib2xkJz5Gcm9tOjwvc3Bhbj48L2Zv bnQ+PC9iPjxmb250IHNpemU9Mg0KZmFjZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6VGFob21hJz4gVGhvbXNvbiwgTWFydGluDQpbbWFpbHRvOk1hcnRp bi5UaG9tc29uQGFuZHJldy5jb21dIDxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpi b2xkJz5TZW50Ojwvc3Bhbj48L2I+IE1vbmRheSwgU2VwdGVtYmVyIDI0LCAyMDA3DQo2OjM1IFBN PGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlRvOjwvc3Bhbj48L2I+IEJy aWFuIFJvc2VuOw0KcGV0ZXJfYmxhdGhlcndpY2tAbWl0ZWwuY29tPGJyPg0KPGI+PHNwYW4gc3R5 bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPkNjOjwvc3Bhbj48L2I+IGVjcml0PGJyPg0KPGI+PHNwYW4g c3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlN1YmplY3Q6PC9zcGFuPjwvYj4gUkU6IFtFY3JpdF0g bXVsdGlwbGUNCmxvY2F0aW9uIHNvdXJjZXM8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0K DQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIg Y29sb3I9bWFyb29uIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtm b250LWZhbWlseTpBcmlhbDtjb2xvcjptYXJvb24nPkFuIGltcG9ydGFudCBjYXZlYXQgdG8gZG9j dW1lbnQgaXMgdGhhdCBMTERQLU1FRA0KZG9lc27igJl0IGFsd2F5cyBwcm92aWRlIHRoZSBob3N0 IGxvY2F0aW9uLiZuYnNwOyBBbiA4MDIuMTEgQVAgbWlnaHQgb25seQ0KYmUgYWJsZSB0byBwcm92 aWRlIGl0cyBvd24gbG9jYXRpb24sIHdoaWNoLCBpZiBpdCBpcyBpbiB0aGUgbmV4dCBidWlsZGlu ZywNCmlzbuKAmXQgbXVjaCB1c2UuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1tYXJvb24gZmFjZT1BcmlhbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm1hcm9v bic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPGRpdiBzdHlsZT0nYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0Jz4NCg0KPGRpdj4NCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0 eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PGZvbnQgc2l6ZT0zDQpmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz4NCg0KPGhyIHNpemU9MiB3aWR0aD0i MTAwJSIgYWxpZ249Y2VudGVyIHRhYmluZGV4PS0xPg0KDQo8L3NwYW4+PC9mb250PjwvZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PGZvbnQgc2l6ZT0yIGZhY2U9VGFob21hPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6VGFob21hO2ZvbnQtd2VpZ2h0OmJv bGQnPkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0yDQpmYWNlPVRhaG9tYT48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWEnPiBCcmlhbiBSb3Nl bg0KW21haWx0bzpickBicmlhbnJvc2VuLm5ldF0gPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQt d2VpZ2h0OmJvbGQnPlNlbnQ6PC9zcGFuPjwvYj4gVHVlc2RheSwgMjUgU2VwdGVtYmVyIDIwMDcN CjY6NDMgQU08YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+VG86PC9zcGFu PjwvYj4gcGV0ZXJfYmxhdGhlcndpY2tAbWl0ZWwuY29tPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2Zv bnQtd2VpZ2h0OmJvbGQnPkNjOjwvc3Bhbj48L2I+ICdlY3JpdCc8YnI+DQo8Yj48c3BhbiBzdHls ZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U3ViamVjdDo8L3NwYW4+PC9iPiBSRTogW0Vjcml0XSBtdWx0 aXBsZQ0KbG9jYXRpb24gc291cmNlczwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQoNCjwv ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xv cj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjExLjBwdDtmb250LWZh bWlseTpBcmlhbDtjb2xvcjpibHVlJz5JIHVuZGVyc3RhbmQgdGhlIOKAnG1vdmluZw0KcGFydHPi gJ0gbm93LiZuYnNwOyBDbGVhcmx5LCBESENQIGlzIG11Y2ggbW9yZSBtYXR1cmUgYW5kIGxpa2Vs eSB0byB3b3JrDQp0b2RheSB0aGFuIExMRFAtTUVEIGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNl PUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7 Y29sb3I6Ymx1ZSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToNCjExLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz5JIHRo aW5rIHRoZSBlbWVyZ2VuY3kgY2FsbCBkb2N1bWVudGF0aW9uIGlzDQpub3QgdGhlIHBsYWNlIHRv IGVkdWNhdGUgZGV2aWNlIGRldmVsb3BlcnMgb2YgaG93IHN0YXJ0dXAgc2VxdWVuY2VzIGludm9s dmluZw0KTExEUCwgREhDUCBhbmQgSFRUUCBiYXNlZCBwcm90b2NvbHMgY291bGQgYmVzdCBiZSBk b25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 DQoxMS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xv cj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjExLjBwdDtmb250LWZh bWlseTpBcmlhbDtjb2xvcjpibHVlJz5CcmlhbjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMS4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6 Ymx1ZSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPGRpdiBzdHlsZT0n Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDQuMHB0Jz4NCg0KPGRpdj4NCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVy IHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PGZvbnQgc2l6ZT0zDQpmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz4NCg0KPGhyIHNpemU9MiB3aWR0 aD0iMTAwJSIgYWxpZ249Y2VudGVyIHRhYmluZGV4PS0xPg0KDQo8L3NwYW4+PC9mb250PjwvZGl2 Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PGZvbnQgc2l6ZT0yIGZhY2U9VGFob21hPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6VGFob21hO2ZvbnQtd2VpZ2h0 OmJvbGQnPkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0yDQpmYWNlPVRhaG9tYT48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWEnPg0KcGV0ZXJf YmxhdGhlcndpY2tAbWl0ZWwuY29tIFttYWlsdG86cGV0ZXJfYmxhdGhlcndpY2tAbWl0ZWwuY29t XSA8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U2VudDo8L3NwYW4+PC9i PiBNb25kYXksIFNlcHRlbWJlciAyNCwgMjAwNw0KNDozNSBQTTxicj4NCjxiPjxzcGFuIHN0eWxl PSdmb250LXdlaWdodDpib2xkJz5Ubzo8L3NwYW4+PC9iPiBCcmlhbiBSb3Nlbjxicj4NCjxiPjxz cGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5DYzo8L3NwYW4+PC9iPiAnU3RhcmssIEJhcmJh cmEnOyAnZWNyaXQnPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlN1Ympl Y3Q6PC9zcGFuPjwvYj4gUkU6IFtFY3JpdF0gbXVsdGlwbGUNCmxvY2F0aW9uIHNvdXJjZXM8L3Nw YW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxmb250IHNpemU9Mw0K ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PGJy Pg0KPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToNCkFyaWFsJz4mZ3Q7IDxmb250IGNvbG9yPWJsdWU+ PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWUnPknigJltIG5vdCBzdXJlIGhvdw0KeW91IGRlY2lkZWQg dGhhdCBMTERQLU1FRCBoYXMgZmV3ZXIgbW92aW5nIHBhcnRzIG9yIGlzIG1vcmUgcmVsaWFibGUg dGhhbiBESENQPC9zcGFuPjwvZm9udD48L3NwYW4+PC9mb250Pg0KPGJyPg0KPGZvbnQgc2l6ZT0y IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJp YWwnPkxMRFANCmlzIHJ1bm5pbmcgYXQgdGhlIG90aGVyIGVuZCBvZiB0aGUgcGh5c2ljYWwgd2ly ZSB0aGUgZGV2aWNlIGluIHF1ZXN0aW9uIGlzDQpwbHVnZ2VkIGludG8uICZuYnNwOyhJbiB0aGUg Y2FzZSBvZiB3aXJlbGVzcywgaXQgaXMgbGlrZWx5IGF0IHRoZSBhY2Nlc3MgcG9pbnQsDQpvciBq dXN0IGJlaGluZCBpdC4pICZuYnNwO0luIHRoYXQgc2Vuc2UsIHRoZXJlIGFyZSBvbmx5IDIgbW92 aW5nIHBhcnRzIHRoYXQNCmhhdmUgdG8gYmUgb3BlcmF0aW5nIGNvcnJlY3RseSAtLSB0aGUgcGhv bmUgaXRzZWxmLCBhbmQgdGhlIEwyIGFjY2VzcyBzd2l0Y2ggaXQNCmlzIHBsdWdnZWQgaW50by4g Jm5ic3A7RXZlbiB3aXRoIERIQ1AgdGhlcmUgaXMgYXQgbGVhc3QgdGhlIG5ldHdvcmsNCmluZnJh c3RydWN0dXJlLCBhIHNlcnZlciBzb21ld2hlcmUsIGFuZCBvZnRlbiBESENQIHJlbGF5IHRvIHNl dCB1cCB0byBnZXQgaXQNCmFsbCB3b3JraW5nLiAmbmJzcDtIRUxEIGhhcyBhIGJ1bmNoIG1vcmUg bWVjaGFuaWNzIHRoYXQgYWxsIG11c3QgYmUgd29ya2luZw0KY29ycmVjdGx5IG9uIHRvcCBvZiB0 aGF0LiAmbmJzcDs8L3NwYW4+PC9mb250PiA8YnI+DQo8YnI+DQo8Zm9udCBzaXplPTIgZmFjZT1B cmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbCc+Jmd0 OyA8Zm9udA0KY29sb3I9Ymx1ZT48c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZSc+TUlHSFQgbGVhZCB0 byBhbiBpbXBsaWVkIG9yZGVyaW5nLCBidXQgSQ0KZG9u4oCZdCB0aGluayBpdOKAmXMgZXZlbiB1 c2VmdWwgdG8gc2F5IHRoYXQuICZuYnNwO0nigJltIG5vdCBzdXJlDQp3aHkgaXQgbWF0dGVycy48 L3NwYW4+PC9mb250Pjwvc3Bhbj48L2ZvbnQ+IDxicj4NCjxmb250IHNpemU9MiBmYWNlPUFyaWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsJz5JDQp0ZXJt cyBvZiB0aGUgcGhvbmUgYmNwLCB5b3UgYXJlIHByb2JhYmx5IHJpZ2h0LCBzaW5jZSBvdGhlciBN VVNUcyBtYWtlIHN1cmUNCnRoYXQgdGhlcmUgaXMgYWx3YXlzIGV4YWN0bHkgb25lIGFuc3dlciBh bnl3YXkuICZuYnNwO0hvd2V2ZXIsIGRldmljZQ0KZGV2ZWxvcGVycyB3aWxsIGNlcnRhaW5seSBj YXJlIC0tIGdldHRpbmcgc3RhcnR1cCBzZXF1ZW5jZSByaWdodCBpcyBpbXBvcnRhbnQNCmFuZCB3 aWxsIG5vdCBiZSBpbW1lZGlhdGVseSBvYnZpb3VzIHRvIG1hbnkgbm90IGRlZXAgaW4gdGhlIGRl dGFpbHMgb2YgZWFjaA0KcGllY2UuICZuYnNwO1RoZSBEU0wgRm9ydW0gZG9jIGlzIDxpPjxzcGFu IHN0eWxlPSdmb250LXN0eWxlOml0YWxpYyc+cmVhbGx5DQpoZWxwZnVsPC9zcGFuPjwvaT4gJm5i c3A7ZnJvbSB0aGF0IHBlcnNwZWN0aXZlLiAmbmJzcDs8L3NwYW4+PC9mb250PiA8YnI+DQo8YnI+ DQo8Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpBcmlhbCc+LS0NClBldGVyPC9zcGFuPjwvZm9udD4gPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQoNCjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MCBjZWxs cGFkZGluZz0wIHdpZHRoPSIxMDAlIg0KIHN0eWxlPSd3aWR0aDoxMDAuMCUnPg0KIDx0cj4NCiAg PHRkIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQnPg0K ICA8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4NCiAgc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQogIDwvdGQ+DQogIDx0ZCB2YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOi43 NXB0IC43NXB0IC43NXB0IC43NXB0Jz4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxmb250IHNp emU9MSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7DQogIGZvbnQtZmFt aWx5OkFyaWFsO2ZvbnQtd2VpZ2h0OmJvbGQnPiZxdW90O0JyaWFuIFJvc2VuJnF1b3Q7DQogICZs dDtickBicmlhbnJvc2VuLm5ldCZndDs8L3NwYW4+PC9mb250PjwvYj4gPG86cD48L286cD48L3A+ DQogIDxwPjxmb250IHNpemU9MSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41 cHQ7Zm9udC1mYW1pbHk6QXJpYWwnPjI0LjA5LjA3DQogIDE2OjIyPC9zcGFuPjwvZm9udD4gPG86 cD48L286cD48L3A+DQogIDwvdGQ+DQogIDx0ZCB2YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOi43 NXB0IC43NXB0IC43NXB0IC43NXB0Jz4NCiAgPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9 MSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7DQogIGZvbnQtZmFtaWx5 OkFyaWFsJz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPC9zcGFuPjwvZm9udD48YnI+DQog IDxmb250IHNpemU9MSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9u dC1mYW1pbHk6QXJpYWwnPiZuYnNwOw0KICAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUbzogJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiAgJm5ic3A7Jmx0O3BldGVyX2JsYXRoZXJ3aWNrQG1pdGVsLmNvbSZn dDssICZxdW90OydTdGFyaywgQmFyYmFyYScmcXVvdDsNCiAgJmx0O2JzNzY1MkBhdHQuY29tJmd0 Ozwvc3Bhbj48L2ZvbnQ+IDxicj4NCiAgPGZvbnQgc2l6ZT0xIGZhY2U9QXJpYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpBcmlhbCc+Jm5ic3A7DQogICZuYnNwOyAm bmJzcDsgJm5ic3A7IGNjOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmcXVvdDsnZWNyaXQn JnF1b3Q7DQogICZsdDtlY3JpdEBpZXRmLm9yZyZndDs8L3NwYW4+PC9mb250PiA8YnI+DQogIDxm b250IHNpemU9MSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6QXJpYWwnPiZuYnNwOw0KICAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTdWJqZWN0OiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSRTogW0Vjcml0XSBtdWx0aXBsZQ0KICBsb2NhdGlvbiBz b3VyY2VzPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCiAgPC90ZD4NCiA8L3RyPg0KPC90 YWJsZT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPjxicj4NCjxicj4NCjxicj4N Cjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsdWUnPkni gJltIG5vdCBzdXJlIGhvdyB5b3UgZGVjaWRlZCB0aGF0IExMRFAtTUVEDQpoYXMgZmV3ZXIgbW92 aW5nIHBhcnRzIG9yIGlzIG1vcmUgcmVsaWFibGUgdGhhbiBESENQLiAmbmJzcDtJIHRoaW5rIGxp a2VseQ0KaXTigJlzIHRoZSBvdGhlciB3YXkgcmlnaHQgbm93LiAmbmJzcDs8L3NwYW4+PC9mb250 PiA8YnI+DQo8Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7Y29sb3I6Ymx1ZSc+Jm5ic3A7PC9z cGFuPjwvZm9udD4gPGJyPg0KPGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToNCkFyaWFsO2NvbG9yOmJsdWUn PkNlcnRhaW5seSwgaWYgeW91ciBhcmUgYXV0b2NvbmZpZ3VyaW5nIHdpdGggTExEUCwgeW91IHdp bGwNCndhbnQgdGhhdCB0byBjb21wbGV0ZSBiZWZvcmUgeW91IGRvIERIQ1AuICZuYnNwO0kgZG9u 4oCZdCB0aGluayB3ZSBoYXZlIHRvDQpzYXkgdGhhdCwgYnV0IHdlIGNhbiBpZiB3ZSBuZWVkIHRv LiAmbmJzcDs8L3NwYW4+PC9mb250PiA8YnI+DQo8Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNl PUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7 Y29sb3I6Ymx1ZSc+Jm5ic3A7PC9zcGFuPjwvZm9udD4gPGJyPg0KPGZvbnQgc2l6ZT0yIGNvbG9y PWJsdWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToNCkFyaWFsO2NvbG9yOmJsdWUnPkkgYWdyZWUgeW91IG5lZWQgYW4gSVAgYWRkcmVzcyBiZWZv cmUgeW91IGNhbiBpbnZva2UgSEVMRC4NCiZuYnNwO0kgZG9u4oCZdCB0aGluayB3ZSBoYXZlIHRv IHNheSB0aGF0Ljwvc3Bhbj48L2ZvbnQ+IDxicj4NCjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZh Y2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlh bDtjb2xvcjpibHVlJz4mbmJzcDs8L3NwYW4+PC9mb250PiA8YnI+DQo8Zm9udCBzaXplPTIgY29s b3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5Og0KQXJpYWw7Y29sb3I6Ymx1ZSc+VGhpcyBNSUdIVCBsZWFkIHRvIGFuIGltcGxpZWQgb3Jk ZXJpbmcsIGJ1dCBJIGRvbuKAmXQNCnRoaW5rIGl04oCZcyBldmVuIHVzZWZ1bCB0byBzYXkgdGhh dC4gJm5ic3A7SeKAmW0gbm90IHN1cmUgd2h5IGl0DQptYXR0ZXJzLjwvc3Bhbj48L2ZvbnQ+IDxi cj4NCjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6DQpBcmlhbDtjb2xvcjpibHVlJz4mbmJzcDs8L3NwYW4+ PC9mb250PiA8YnI+DQo8Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7Y29sb3I6Ymx1ZSc+QnJp YW48L3NwYW4+PC9mb250PiA8YnI+DQo8Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KQXJpYWw7Y29sb3I6 Ymx1ZSc+Jm5ic3A7PC9zcGFuPjwvZm9udD4gPG86cD48L286cD48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48Zm9udCBzaXpl PTMNCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxkaXYgY2xhc3M9TXNvTm9y bWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxmb250IHNpemU9Mw0K ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+DQoN CjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlcj4NCg0KPC9zcGFuPjwvZm9udD48 L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+ PGZvbnQgc2l6ZT0zDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTIuMHB0Jz48YnI+DQo8L3NwYW4+PC9mb250PjxiPjxmb250IHNpemU9MiBmYWNlPVRhaG9t YT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OlRhaG9tYTtmb250 LXdlaWdodDpib2xkJz5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9Mg0KZmFjZT1U YWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6VGFob21hJz4N CnBldGVyX2JsYXRoZXJ3aWNrQG1pdGVsLmNvbSBbbWFpbHRvOnBldGVyX2JsYXRoZXJ3aWNrQG1p dGVsLmNvbV0gPGI+PHNwYW4NCnN0eWxlPSdmb250LXdlaWdodDpib2xkJz48YnI+DQpTZW50Ojwv c3Bhbj48L2I+IE1vbmRheSwgU2VwdGVtYmVyIDI0LCAyMDA3IDEyOjQ5IFBNPGI+PHNwYW4gc3R5 bGU9J2ZvbnQtd2VpZ2h0Og0KYm9sZCc+PGJyPg0KVG86PC9zcGFuPjwvYj4gU3RhcmssIEJhcmJh cmE8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+PGJyPg0KQ2M6PC9zcGFuPjwvYj4g ZWNyaXQ8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+PGJyPg0KU3ViamVjdDo8L3Nw YW4+PC9iPiBSRTogW0Vjcml0XSBtdWx0aXBsZSBsb2NhdGlvbiBzb3VyY2VzPC9zcGFuPjwvZm9u dD4gPGJyPg0KJm5ic3A7IDxicj4NCjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsJz48YnI+DQpIaSw8L3NwYW4+PC9m b250PiA8Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDsNCmZvbnQtZmFtaWx5OkFyaWFsJz48YnI+DQpJIGFncmVlIHRoYXQgdGhlIERTTCBGb3J1bSBk b2N1bWVudCBtYWtlcyBhIHZlcnkgZ29vZCBzdGFydGluZyBwb2ludCBmb3INCm9yZGVybHkgYWNx dWlzaXRpb24gb2YgbG9jYXRpb24gYXQgc3RhcnR1cCwgYWNjb3VudGluZyBmb3IgYWxsIDMgbWV0 aG9kcy4NCiZuYnNwO0kgYWxzbyBiZWxpZXZlIGl0IHBvaW50cyB0byBhIHByZWZlcmVuY2Ugb3Jk ZXIsIGlmIHRoZXJlIGFyZSBtdWx0aXBsZQ0KYW5zd2VycyBjb21pbmcgYmFjaywgd2hpY2ggaXMg TExEUC1NRUQgLS0mZ3Q7IERIQ1AgLS0mZ3Q7IEhFTEQuICZuYnNwO1JlYXNvbmluZw0KZm9yIHRo aXMgb3JkZXIgKG15IG9waW5pb24pIGlzIHRoYXQgaXQgcHJvZ3Jlc3NlcyBmcm9tICZxdW90O2xl YXN0IG1vdmluZw0KcGFydHMmcXVvdDsgLyBtb3N0IHJlbGlhYmxlIChMTERQLU1FRCkgdG8gbW9z dCwgYW5kIGFsc28gZm9sbG93cyB0aGUgbmF0dXJhbA0KbGF5ZXJpbmcgb2YgdGhlIG92ZXJhbGwg c3lzdGVtIChMMiAtLSZndDsgTDIuNSAtLSZndDsgTDcpLiAmbmJzcDsgSW4gdGhlIGVuZCwNCm9u bHkgT05FIG1ldGhvZCBzaG91bGQgZXZlciBiZSBzZWxlY3RlZCwgYXMgdGhlIHNlcXVlbmNlIGRp YWdyYW0gc2hvd3MuICZuYnNwOzwvc3Bhbj48L2ZvbnQ+DQo8YnI+DQo8Zm9udCBzaXplPTIgZmFj ZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbCc+ PGJyPg0KWW91ciBwb2ludCBiZWxvdywgdGhhdCB0aGUgbWV0aG9kcyBjYW4gYW5kIHNob3VsZCBw cm9ncmVzcyBpbiBwYXJhbGxlbCBpcw0KdmFsaWQuICZuYnNwO0hvd2V2ZXIgdGhlcmUgYXJlIGNv bnN0cmFpbnRzIHRvIHRoaXMsIG5vdGFibHk6IDwvc3Bhbj48L2ZvbnQ+PGJyPg0KPGZvbnQgc2l6 ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWwnPjxicj4NCm8gSWYgTExEUC1NRUQgaXMgYmVpbmcgdXNlZCB0byBhdXRvY29uZmlndXJl IHZvaWNlIFZMQU4gSUQsIHRoZW4gdGhlIGRldmljZQ0Kc2hvdWxkIHdhaXQgdG8gc2VlIGlmIHRo YXQgc3RhZ2Ugc3VjY2VlZHMgYmVmb3JlIGNvbnRhY3RpbmcgREhDUC4NCiZuYnNwO090aGVyd2lz ZSwgdGhlIGRldmljZSBtYXkgZ2V0IGFuIElQIGFkZHJlc3Mgb24gdGhlIGRlZmF1bHQgVkxBTiwg b25seSB0bw0KaGF2ZSB0byBkcm9wIGl0IGFuZCB0cnkgYWdhaW4gb24gdGhlIHZvaWNlIFZMQU4u ICZuYnNwO0lmIGl0IGhhZCBzdGFydGVkIHRvIHVzZQ0KdGhpcyBhZGRyZXNzIGZvciBzb21ldGhp bmcgYWxyZWFkeSAoc2F5IGZvciBIRUxEKSwgdGhlbiBvbmdvaW5nIGludGVyYWN0aW9uDQp3b3Vs ZCBiZSBkcm9wcGVkIGFuZCBjb25mdXNpb24gd291bGQgbGlrZWx5IGVuc3VlLiAmbmJzcDs8L3Nw YW4+PC9mb250PiA8YnI+DQo8Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbCc+PGJyPg0KbyBCZWZvcmUgSEVMRCBjYW4g d29yaywgYW4gSVAgYWRkcmVzcyBpcyBuZWVkZWQuICZuYnNwOyA8L3NwYW4+PC9mb250Pjxicj4N Cjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OkFyaWFsJz48YnI+DQpJIHRoaW5rIHRoZXNlIGNvbnN0cmFpbnRzIGFyZSByZWFs bHkganVzdCBhIHJlZmxlY3Rpb24gb2YgdGhlIG5hdHVyYWwgbGF5ZXJpbmcNCmluIHRoZSBlbmQu ICZuYnNwOzwvc3Bhbj48L2ZvbnQ+IDxicj4NCjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsJz48YnI+DQpJTUhPLCBv cmRlcmx5IHN0YXJ0dXAgYmVhdHMgdGhlIGZldyBleHRyYSBzZWNvbmRzIGRlbGF5IGluY3VycmVk IGluIG1ha2luZyBzdXJlDQp0aGUgY29uc3RyYWludHMgYXJlIG5vdCBicm9rZW4uICZuYnNwOyBX ZSBhcmUgb25seSB0YWxraW5nIGFib3V0IGEgdmVyeSBmZXcNCnNlY29uZHMgaGVyZSBhZnRlciBh bGwuICZuYnNwOzwvc3Bhbj48L2ZvbnQ+IDxicj4NCjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsJz48YnI+DQotLSBQ ZXRlciA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KDQo8dGFibGUgY2xhc3M9TXNvTm9y bWFsVGFibGUgYm9yZGVyPTAgY2VsbHBhZGRpbmc9MCB3aWR0aD0iMTAwJSINCiBzdHlsZT0nd2lk dGg6MTAwLjAlJz4NCiA8dHI+DQogIDx0ZCB3aWR0aD0iMCUiIHZhbGlnbj10b3Agc3R5bGU9J3dp ZHRoOjAlO3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQnPg0KICA8cCBjbGFzcz1Nc29O b3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4NCiAgc3R5bGU9 J2ZvbnQtc2l6ZToxMi4wcHQnPiZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K ICA8L3RkPg0KICA8dGQgd2lkdGg9IjIzJSIgdmFsaWduPXRvcCBzdHlsZT0nd2lkdGg6MjMuMCU7 cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCc+DQogIDxwIGNsYXNzPU1zb05vcm1hbD48 Yj48Zm9udCBzaXplPTEgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0Ow0K ICBmb250LWZhbWlseTpBcmlhbDtmb250LXdlaWdodDpib2xkJz4mcXVvdDtTdGFyaywgQmFyYmFy YSZxdW90Ow0KICAmbHQ7YnM3NjUyQGF0dC5jb20mZ3Q7PC9zcGFuPjwvZm9udD48L2I+IDxvOnA+ PC9vOnA+PC9wPg0KICA8cD48Zm9udCBzaXplPTEgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OkFyaWFsJz4yNC4wOS4wNw0KICAwODo0ODwvc3Bhbj48 L2ZvbnQ+IDxvOnA+PC9vOnA+PC9wPg0KICA8L3RkPg0KICA8dGQgd2lkdGg9Ijc1JSIgdmFsaWdu PXRvcCBzdHlsZT0nd2lkdGg6NzUuMCU7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCc+ DQogIDxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTEgZmFjZT1BcmlhbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjcuNXB0Ow0KICBmb250LWZhbWlseTpBcmlhbCc+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IDxicj4NCiAgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VG86ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZxdW90OzxzdDE6UGVyc29uTmFtZQ0KICB3OnN0PSJvbiI+ V2ludGVyYm90dG9tLCBKYW1lczwvc3QxOlBlcnNvbk5hbWU+JnF1b3Q7DQogICZsdDtKYW1lcy5X aW50ZXJib3R0b21AYW5kcmV3LmNvbSZndDssICZxdW90O0thcmwgSGVpbnogV29sZiZxdW90Ow0K ICAmbHQ7a2h3b2xmMUBnbWFpbC5jb20mZ3Q7LCAmcXVvdDtlY3JpdCZxdW90OyAmbHQ7ZWNyaXRA aWV0Zi5vcmcmZ3Q7PC9zcGFuPjwvZm9udD4NCiAgPGZvbnQgc2l6ZT0xIGZhY2U9QXJpYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTpBcmlhbCc+PGJyPg0KICAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjYzogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9z cGFuPjwvZm9udD4gPGZvbnQNCiAgc2l6ZT0xIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZTo3LjVwdDtmb250LWZhbWlseTpBcmlhbCc+PGJyPg0KICAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtTdWJqZWN0OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSRTogW0Vjcml0XQ0K ICBtdWx0aXBsZSBsb2NhdGlvbiBzb3VyY2VzPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4N CiAgPC90ZD4NCiA8L3RyPg0KPC90YWJsZT4NCg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxicj4NCjxicj4NCjxi cj4NCjwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsdWUn Pjxicj4NCkl0J3Mgbm90IGFsd2F5cyBkZXNpcmFibGUgdG8gd2FpdCBmb3IgYSBwcm90b2NvbCB0 byB0aW1lLW91dCwgYmVmb3JlIGxhdW5jaGluZw0KdGhlIG5leHQgcHJvdG9jb2wuIFNwZWNpZmlj YWxseSwgaWYgYSBkZXZpY2UgaXMgY29uZmlndXJlZCB0byBkbyBESENQIGZvciBJUA0KYWRkcmVz cyBjb25maWd1cmF0aW9uLCBpdCBzaG91bGQgbGF1bmNoIGl0cyBESENQIGRpc2NvdmVyeSBBU0FQ LCB3aXRoIG9wdGlvbnMsDQppbnN0ZWFkIG9mIHdhaXRpbmcgdGhlIDQgb3IgNSBzZWNvbmRzIGZv ciBMTERQLU1FRCB0byB0aW1lIG91dC4gVGhpcyBwcmV2ZW50cw0KdW5uZWNlc3NhcnkgZGVsYXlz IGluIHRoZSBib290c3RyYXAgcHJvY2Vzcy4gSXQgc2hvdWxkIGJlIGVhc3kgZW5vdWdoIGZvciB0 aGUNCmRldmljZSB0byB1c2UgYSByZWNlaXZlZCBMTERQLU1FRCBsb2NhdGlvbiwgZXZlbiBpZiBp dCBhcnJpdmVzIGFmdGVyIHRoZSBESENQDQpyZXNwb25zZS48L3NwYW4+PC9mb250PiA8Zm9udCBz aXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz48YnI+DQpCYXJiYXJhPC9zcGFuPjwvZm9u dD4gPGJyPg0KJm5ic3A7PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsdWUnPjxi cj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tIDwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNvdXJpZXIgTmV3Ij48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+PGJyPg0KW0FKV10gTXkgZmlyc3QgcXVlc3Rpb24gaXMgd2h5IGFyZSB5 b3UgdXNpbmcgbW9yZSB0aGFuIG9uZSBhY3F1aXNpdGlvbg0KcHJvdG9jb2wuIE15IHRob3VnaHRz IHdvdWxkIGJlIHVzZSBvbmUsIGlmIGl0IGZhaWxzLCBwaWNrIGEgZGlmZmVyZW50IG9uZS4NCk5l dmVyIGludm9rZSBib3RoIGF0IHRoZSBzYW1lIHRpbWUgc28geW91IGhhdmUgdGhpcyBwcm9ibGVt IG9mIGNob2ljZS48L3NwYW4+PC9mb250Pg0KPGJyPg0KJm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0K DQo8cD48Zm9udCBzaXplPTIgZmFjZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6VGFob21hJz4qKioqKjwvc3Bhbj48L2ZvbnQ+DQo8bzpwPjwvbzpwPjwv cD4NCg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9VGFob21hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OlRhaG9tYSc+VGhlDQppbmZvcm1hdGlvbiB0cmFuc21pdHRlZCBp cyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uIG9yIGVudGl0eSB0byB3aGljaCBpdA0KaXMg YWRkcmVzc2VkIGFuZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwsIHByb3ByaWV0YXJ5LCBhbmQv b3IgcHJpdmlsZWdlZA0KbWF0ZXJpYWwuIEFueSByZXZpZXcsIHJldHJhbnNtaXNzaW9uLCBkaXNz ZW1pbmF0aW9uIG9yIG90aGVyIHVzZSBvZiwgb3IgdGFraW5nDQpvZiBhbnkgYWN0aW9uIGluIHJl bGlhbmNlIHVwb24gdGhpcyBpbmZvcm1hdGlvbiBieSBwZXJzb25zIG9yIGVudGl0aWVzIG90aGVy DQp0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2Vp dmVkIHRoaXMgaW4gZXJyb3IsDQpwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhlIG1hdGVyaWFsIGZyb20gYWxsIGNvbXB1dGVycy4gR0E2MjM8L3NwYW4+PC9mb250Pjxmb250 DQpzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KRWNyaXQgbWFpbGluZyBsaXN0PGJyPg0KRWNyaXRAaWV0 Zi5vcmc8YnI+DQpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdDwv c3Bhbj48L2ZvbnQ+IDxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxmb250IHNpemU9Mw0K ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHRhYmxlIGNsYXNzPU1zb05vcm1h bFRhYmxlIGJvcmRlcj0wIGNlbGxwYWRkaW5nPTAgYmdjb2xvcj13aGl0ZQ0KIHN0eWxlPSdiYWNr Z3JvdW5kOndoaXRlJz4NCiA8dHI+DQogIDx0ZCBzdHlsZT0ncGFkZGluZzouNzVwdCAuNzVwdCAu NzVwdCAuNzVwdCc+DQogIDxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgY29sb3I9Ymxh Y2sgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bhbg0KICBzdHlsZT0nZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayc+PGJyPg0KICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08YnI+DQogIFRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aXMmbmJzcDtmb3ImbmJzcDt0aGUm bmJzcDtkZXNpZ25hdGVkJm5ic3A7cmVjaXBpZW50Jm5ic3A7b25seSZuYnNwO2FuZCZuYnNwO21h eTxicj4NCiAgY29udGFpbiZuYnNwO3ByaXZpbGVnZWQsJm5ic3A7cHJvcHJpZXRhcnksJm5ic3A7 b3ImbmJzcDtvdGhlcndpc2UmbmJzcDtwcml2YXRlJm5ic3A7aW5mb3JtYXRpb24uJm5ic3A7Jm5i c3A7PGJyPg0KICBJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO2l0Jm5i c3A7aW4mbmJzcDtlcnJvciwmbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtz ZW5kZXI8YnI+DQogIGltbWVkaWF0ZWx5Jm5ic3A7YW5kJm5ic3A7ZGVsZXRlJm5ic3A7dGhlJm5i c3A7b3JpZ2luYWwuJm5ic3A7Jm5ic3A7QW55Jm5ic3A7dW5hdXRob3JpemVkJm5ic3A7dXNlJm5i c3A7b2Y8YnI+DQogIHRoaXMmbmJzcDtlbWFpbCZuYnNwO2lzJm5ic3A7cHJvaGliaXRlZC48YnI+ DQogIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiAgW21mMl08 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KICA8L3RkPg0KIDwvdHI+DQo8L3RhYmxlPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPGJyPjxicj48dGFi bGUgYmdjb2xvcj13aGl0ZSBzdHlsZT0iY29sb3I6YmxhY2siPjx0cj48dGQ+PGJyPi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NClRoaXMmbmJzcDttZXNzYWdlJm5i c3A7aXMmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDtkZXNpZ25hdGVkJm5ic3A7cmVjaXBpZW50Jm5i c3A7b25seSZuYnNwO2FuZCZuYnNwO21heTxicj4NCmNvbnRhaW4mbmJzcDtwcml2aWxlZ2VkLCZu YnNwO3Byb3ByaWV0YXJ5LCZuYnNwO29yJm5ic3A7b3RoZXJ3aXNlJm5ic3A7cHJpdmF0ZSZuYnNw O2luZm9ybWF0aW9uLiZuYnNwOyZuYnNwOzxicj4NCklmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNw O3JlY2VpdmVkJm5ic3A7aXQmbmJzcDtpbiZuYnNwO2Vycm9yLCZuYnNwO3BsZWFzZSZuYnNwO25v dGlmeSZuYnNwO3RoZSZuYnNwO3NlbmRlcjxicj4NCmltbWVkaWF0ZWx5Jm5ic3A7YW5kJm5ic3A7 ZGVsZXRlJm5ic3A7dGhlJm5ic3A7b3JpZ2luYWwuJm5ic3A7Jm5ic3A7QW55Jm5ic3A7dW5hdXRo b3JpemVkJm5ic3A7dXNlJm5ic3A7b2Y8YnI+DQp0aGlzJm5ic3A7ZW1haWwmbmJzcDtpcyZuYnNw O3Byb2hpYml0ZWQuPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPg0KW21mMl08L3RkPjwvdHI+PC90YWJsZT48L2JvZHk+DQoNCjwvaHRtbD4NCg== ------_=_NextPart_001_01C7FFC2.D7A155D8-- --===============0683104275== 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 --===============0683104275==-- From ecrit-bounces@ietf.org Tue Sep 25 18:40:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaJ4u-0006Z8-SN; Tue, 25 Sep 2007 18:40:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaJ4t-0006V4-Me for ecrit@ietf.org; Tue, 25 Sep 2007 18:40:27 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaJ4s-0008Oy-R5 for ecrit@ietf.org; Tue, 25 Sep 2007 18:40:27 -0400 X-SEF-Processed: 5_0_0_910__2007_09_25_17_50_05 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 25 Sep 2007 17:50:03 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Sep 2007 17:40:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] multiple location sources Date: Tue, 25 Sep 2007 17:35:44 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] multiple location sources Thread-Index: Acf+6mvvfdfiVsj+SRWgXWkwKUNklAAAMBSgAAPrzUAABKJNcAAtJWiwAACNF7A= References: <194701c7fee8$927a12d0$640fa8c0@cis.neustar.com><19aa01c7feeb$90c88ae0$640fa8c0@cis.neustar.com><1ba801c7ff92$b3b8cf90$640fa8c0@cis.neustar.com> From: "Dawson, Martin" To: "Thomson, Martin" , "Brian Rosen" , X-OriginalArrivalTime: 25 Sep 2007 22:40:24.0979 (UTC) FILETIME=[10429E30:01C7FFC5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a9672ae1970aa20cd94e880017fa9b4 Cc: ecrit X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1322402027==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1322402027== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FFC4.6D9EEF0C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FFC4.6D9EEF0C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable But, then, the progenitors of 3825 have always said that it wasn't for=0D=0A= wireless - it is aimed at enterprise wired Ethernet switched LANs. Since=0D= =0ALLDP-MED has the same encoding, the same restrictions apply.=0D=0A=0D=0A= =20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A________= ________________________=0D=0A=0D=0AFrom: Thomson, Martin [mailto:Martin.Th= omson@andrew.com]=20=0D=0ASent: Wednesday, 26 September 2007 8:24 AM=0D=0AT= o: Brian Rosen; peter_blatherwick@mitel.com=0D=0ACc: ecrit=0D=0ASubject: RE= : [Ecrit] multiple location sources=0D=0A=0D=0A=20=0D=0A=0D=0AUncertainty b= ecomes useful information here. It is important to=0D=0Adistinguish betwee= n the location of the AP, which is known to a certain=0D=0Aprecision, and t= he location of the host. If you are using the location=0D=0Aof the AP to d= etermine the location of the host, then the location of=0D=0Athe host is th= e coverage area of the AP. Therefore, there is a=0D=0Adifference between t= he two.=0D=0A=0D=0A=20=0D=0A=0D=0AThat is, if the AP location is known as (= x, y) with relatively high=0D=0Aprecision, then the location of the host is= (x, y) give or take the=0D=0Aeffective range of the AP. Therefore, the lo= cation of the AP and the=0D=0Alocation of a host differ.=0D=0A=0D=0A=20=0D=0A=0D= =0ABut then, that doesn't work very well with LCI.=0D=0A=0D=0A=20=0D=0A=0D=0A= Case 3 would be nice, but I doubt that it will ever account for 100% of=0D=0A= cases.=0D=0A=0D=0A=20=0D=0A=0D=0ATa,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D= =0A________________________________=0D=0A=0D=0AFrom: Brian Rosen [mailto:br= @brianrosen.net]=20=0D=0ASent: Wednesday, 26 September 2007 2:40 AM=0D=0ATo= : Thomson, Martin; peter_blatherwick@mitel.com=0D=0ACc: 'ecrit'=0D=0ASubjec= t: RE: [Ecrit] multiple location sources=0D=0A=0D=0A=20=0D=0A=0D=0AThat's o= ften all you can get.=0D=0A=0D=0A=20=0D=0A=0D=0AThere are only three cases:=0D= =0A=0D=0A1.=09The user measures its own location, no LCP needed=0D=0A2.=09T= he location of the clients of the AP are reported as the=0D=0Alocation of t= he AP=0D=0A3.=09There is triangulation between APs and clients to get a mor= e=0D=0Aaccurate location=0D=0A=0D=0A=20=0D=0A=0D=0ACase 2 is going to be th= e norm for a while.=0D=0A=0D=0A=20=0D=0A=0D=0AThe ability to triangulate is= around, but not widely deployed.=0D=0A=0D=0A=20=0D=0A=0D=0ABrian=0D=0A=0D=0A= =20=0D=0A=0D=0A________________________________=0D=0A=0D=0AFrom: Thomson, M= artin [mailto:Martin.Thomson@andrew.com]=20=0D=0ASent: Monday, September 24= , 2007 6:35 PM=0D=0ATo: Brian Rosen; peter_blatherwick@mitel.com=0D=0ACc: e= crit=0D=0ASubject: RE: [Ecrit] multiple location sources=0D=0A=0D=0A=20=0D=0A=0D= =0AAn important caveat to document is that LLDP-MED doesn't always provide=0D= =0Athe host location. An 802.11 AP might only be able to provide its own=0D= =0Alocation, which, if it is in the next building, isn't much use.=0D=0A=0D= =0A=20=0D=0A=0D=0A________________________________=0D=0A=0D=0AFrom: Brian R= osen [mailto:br@brianrosen.net]=20=0D=0ASent: Tuesday, 25 September 2007 6:= 43 AM=0D=0ATo: peter_blatherwick@mitel.com=0D=0ACc: 'ecrit'=0D=0ASubject: R= E: [Ecrit] multiple location sources=0D=0A=0D=0A=20=0D=0A=0D=0AI understand= the "moving parts" now. Clearly, DHCP is much more mature=0D=0Aand likely= to work today than LLDP-MED is.=0D=0A=0D=0A=20=0D=0A=0D=0AI think the emer= gency call documentation is not the place to educate=0D=0Adevice developers= of how startup sequences involving LLDP, DHCP and HTTP=0D=0Abased protocol= s could best be done.=0D=0A=0D=0A=20=0D=0A=0D=0ABrian=0D=0A=0D=0A=20=0D=0A=0D= =0A________________________________=0D=0A=0D=0AFrom: peter_blatherwick@mite= l.com [mailto:peter_blatherwick@mitel.com]=20=0D=0ASent: Monday, September = 24, 2007 4:35 PM=0D=0ATo: Brian Rosen=0D=0ACc: 'Stark, Barbara'; 'ecrit'=0D= =0ASubject: RE: [Ecrit] multiple location sources=0D=0A=0D=0A=20=0D=0A=0D=0A=0D= =0A> I'm not sure how you decided that LLDP-MED has fewer moving parts or=0D= =0Ais more reliable than DHCP=20=0D=0ALLDP is running at the other end of t= he physical wire the device in=0D=0Aquestion is plugged into. (In the case= of wireless, it is likely at the=0D=0Aaccess point, or just behind it.) I= n that sense, there are only 2=0D=0Amoving parts that have to be operating = correctly -- the phone itself,=0D=0Aand the L2 access switch it is plugged = into. Even with DHCP there is at=0D=0Aleast the network infrastructure, a = server somewhere, and often DHCP=0D=0Arelay to set up to get it all working= =2E HELD has a bunch more mechanics=0D=0Athat all must be working correctl= y on top of that. =20=0D=0A=0D=0A> MIGHT lead to an implied ordering, but = I don't think it's even useful=0D=0Ato say that. I'm not sure why it matte= rs.=20=0D=0AI terms of the phone bcp, you are probably right, since other M= USTs make=0D=0Asure that there is always exactly one answer anyway. Howeve= r, device=0D=0Adevelopers will certainly care -- getting startup sequence r= ight is=0D=0Aimportant and will not be immediately obvious to many not deep= in the=0D=0Adetails of each piece. The DSL Forum doc is really helpful f= rom that=0D=0Aperspective. =20=0D=0A=0D=0A-- Peter=20=0D=0A=0D=0A=20=0D=0A=0D= =0A"Brian Rosen" =20=0D=0A=0D=0A24.09.07 16:22=20=0D=0A=0D= =0A =20=0D=0A To: , "'Star= k, Barbara'"=0D=0A=20=0D=0A cc: "'ecrit'" =20=0D=0A Subject: RE: [Ecrit] multiple location= sources=0D=0A=0D=0A=0D=0A=0D=0A=0D=0AI'm not sure how you decided that LLD= P-MED has fewer moving parts or is=0D=0Amore reliable than DHCP. I think l= ikely it's the other way right now.=0D=0A=0D=0A =20=0D=0ACertainly, if your= are autoconfiguring with LLDP, you will want that to=0D=0Acomplete before = you do DHCP. I don't think we have to say that, but we=0D=0Acan if we need= to. =20=0D=0A =20=0D=0AI agree you need an IP address before you can invo= ke HELD. I don't=0D=0Athink we have to say that.=20=0D=0A =20=0D=0AThis MI= GHT lead to an implied ordering, but I don't think it's even=0D=0Auseful to= say that. I'm not sure why it matters.=20=0D=0A =20=0D=0ABrian=20=0D=0A =0D= =0A=0D=0A=20=0D=0A=0D=0A________________________________=0D=0A=0D=0A=0D=0AF= rom: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20=0D= =0ASent: Monday, September 24, 2007 12:49 PM=0D=0ATo: Stark, Barbara=0D=0AC= c: ecrit=0D=0ASubject: RE: [Ecrit] multiple location sources=20=0D=0A =20=0D= =0A=0D=0AHi,=20=0D=0AI agree that the DSL Forum document makes a very good = starting point for=0D=0Aorderly acquisition of location at startup, account= ing for all 3=0D=0Amethods. I also believe it points to a preference order= , if there are=0D=0Amultiple answers coming back, which is LLDP-MED --> DHC= P --> HELD.=0D=0AReasoning for this order (my opinion) is that it progresse= s from "least=0D=0Amoving parts" / most reliable (LLDP-MED) to most, and al= so follows the=0D=0Anatural layering of the overall system (L2 --> L2.5 -->= L7). In the=0D=0Aend, only ONE method should ever be selected, as the se= quence diagram=0D=0Ashows. =20=0D=0A=0D=0AYour point below, that the metho= ds can and should progress in parallel=0D=0Ais valid. However there are co= nstraints to this, notably:=20=0D=0A=0D=0Ao If LLDP-MED is being used to au= toconfigure voice VLAN ID, then the=0D=0Adevice should wait to see if that = stage succeeds before contacting DHCP.=0D=0AOtherwise, the device may get a= n IP address on the default VLAN, only to=0D=0Ahave to drop it and try agai= n on the voice VLAN. If it had started to=0D=0Ause this address for someth= ing already (say for HELD), then ongoing=0D=0Ainteraction would be dropped = and confusion would likely ensue. =20=0D=0A=0D=0Ao Before HELD can work, a= n IP address is needed. =20=0D=0A=0D=0AI think these constraints are reall= y just a reflection of the natural=0D=0Alayering in the end. =20=0D=0A=0D=0A= IMHO, orderly startup beats the few extra seconds delay incurred in=0D=0Ama= king sure the constraints are not broken. We are only talking about=0D=0A= a very few seconds here after all. =20=0D=0A=0D=0A-- Peter=20=0D=0A=0D=0A = =20=0D=0A=0D=0A"Stark, Barbara" =20=0D=0A=0D=0A24.09.07 08:= 48=20=0D=0A=0D=0A =20=0D=0A To: "Winterbottom, James" ,=0D=0A"Karl Heinz Wolf" , = "ecrit" =20=0D=0A cc: =20=0D=0A Subject:= RE: [Ecrit] multiple location sources=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0AIt's not always desirable to wait for a protocol to time-out, before=0D=0A= launching the next protocol. Specifically, if a device is configured to=0D=0A= do DHCP for IP address configuration, it should launch its DHCP=0D=0Adiscov= ery ASAP, with options, instead of waiting the 4 or 5 seconds for=0D=0ALLDP= -MED to time out. This prevents unnecessary delays in the bootstrap=0D=0Apr= ocess. It should be easy enough for the device to use a received=0D=0ALLDP-= MED location, even if it arrives after the DHCP response.=20=0D=0ABarbara =0D= =0A=20=0D=0A--------------------=20=0D=0A[AJW] My first question is why are= you using more than one acquisition=0D=0Aprotocol. My thoughts would be us= e one, if it fails, pick a different=0D=0Aone. Never invoke both at the sam= e time so you have this problem of=0D=0Achoice.=20=0D=0A =20=0D=0A=0D=0A***= **=20=0D=0A=0D=0AThe information transmitted is intended only for the perso= n or entity to=0D=0Awhich it is addressed and may contain confidential, pro= prietary, and/or=0D=0Aprivileged material. Any review, retransmission, diss= emination or other=0D=0Ause of, or taking of any action in reliance upon th= is information by=0D=0Apersons or entities other than the intended recipien= t is prohibited. If=0D=0Ayou received this in error, please contact the sen= der and delete the=0D=0Amaterial from all computers.=0D=0AGA623____________= ___________________________________=0D=0AEcrit mailing list=0D=0AEcrit@ietf= =2Eorg=0D=0Ahttps://www1.ietf.org/mailman/listinfo/ecrit=20=0D=0A=0D=0A=20=0D= =0A=0D=0A=0D=0A------------------------------------------------------------= ------------=0D=0A------------------------=0D=0AThis message is for the des= ignated recipient only and may=0D=0Acontain privileged, proprietary, or oth= erwise private information. =20=0D=0AIf you have received it in error, plea= se notify the sender=0D=0Aimmediately and delete the original. Any unautho= rized use of=0D=0Athis email is prohibited.=0D=0A--------------------------= ----------------------------------------------=0D=0A-----------------------= -=0D=0A[mf2]=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A=0D=0A---------------= ---------------------------------------------------------=0D=0A------------= ------------=0D=0AThis message is for the designated recipient only and may=0D= =0Acontain privileged, proprietary, or otherwise private information. =20=0D= =0AIf you have received it in error, please notify the sender=0D=0Aimmediat= ely and delete the original. Any unauthorized use of=0D=0Athis email is pr= ohibited.=0D=0A------------------------------------------------------------= ------------=0D=0A------------------------=0D=0A[mf2]=0D=0A=0D=0A=20=0D=0A=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0AThis message is for the designated recipient = only and may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C7FFC4.6D9EEF0C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=
=0D=0A=0D=0A

But, then, the progenitors of 3825 have=0D=0Aalways said that= it wasn’t for wireless – it is aimed at enterprise wired=0D=0A= Ethernet switched LANs. Since LLDP-MED has the same encoding, the same=0D=0A= restrictions apply.

=0D=0A=0D=0A

 

=0D= =0A=0D=0A

Cheers,

=0D=0A=0D=0A

Martin

=0D=0A=0D=0A

 =

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D= =0A

From:=0D=0AThomson, Martin [mailto:Martin.= Thomson@andrew.com]
=0D=0ASent: Wednesday, 26 September 2007=0D=0A8:24 AM
=0D=0ATo: Brian Rosen;=0D=0Apeter_blatherwick@mitel= =2Ecom
=0D=0ACc: ecrit=0D=0ASubject: RE: [Ecrit] = multiple=0D=0Alocation sources<= /span>

=0D=0A=0D=0A
=0D=0A=0D=0A

 = ;

=0D=0A=0D=0A

Uncertainty becomes=0D=0Auseful informatio= n here.  It is important to distinguish between the=0D=0Alocation of t= he AP, which is known to a certain precision, and the location of=0D=0Athe = host.  If you are using the location of the AP to determine the=0D=0Al= ocation of the host, then the location of the host is the coverage area of = the=0D=0AAP.  Therefore, there is a difference between the two.

=0D=0A=0D=0A

 

=0D=0A=0D=0A=

That i= s, if the AP=0D=0Alocation is known as (x, y) with relatively high precisio= n, then the location=0D=0Aof the host is (x, y) give or take the effective = range of the AP. =0D=0ATherefore, the location of the AP and the locat= ion of a host differ.

=0D=0A=0D=0A

 =

=0D=0A=0D=0A

But then, that doesn’t=0D=0Awork very well = with LCI.

=0D=0A=0D=0A

 

=0D=0A=0D=0A

Case 3 would be nice,=0D=0Abut I doubt that it will ever accou= nt for 100% of cases.

=0D=0A=0D=0A

 =

=0D=0A=0D=0A

Ta,

=0D=0A=0D=0A

Martin

=0D=0A=0D=0A

 

=0D=0A=0D= =0A
=0D=0A=0D=0A
=0D=0A=0D=0A
= =0D=0A=0D=0A
=0D=0A=0D=0A
=0D= =0A=0D=0A

F= rom:=0D=0ABrian Rosen [mailto:br@= brianrosen.net]
=0D=0ASent:<= /b> Wednesday, 26 September 2007=0D=0A2:40 AM
=0D=0ATo: Thomson, Martin;=0D=0Apeter_blatherwick@mite= l.com
=0D=0ACc: 'ecrit'=0D=0ASubject: RE: [Ecrit]= multiple=0D=0Alocation sources=

=0D=0A=0D=0A
=0D=0A=0D=0A

 

=0D=0A=0D=0A

That’s often all you can=0D= =0Aget.

=0D=0A=0D=0A

 

=0D= =0A=0D=0A

There are only three=0D=0Acases:

=0D=0A=0D=0A<= ol style=3D'margin-top:0cm' start=3D1 type=3D1>=0D=0A
  • The user measures its own location, no LCP needed
    • =0D=0A
  • The location of the clients of the AP are reported as the location=0D=0A = of the AP
    • =0D=0A
  • There is triangulation between APs and clients to get a more=0D= =0A accurate location
    • =0D=0A=0D=0A=0D= =0A

    =  

    =0D=0A=0D=0A

    Case 2 is going to be the=0D=0Anorm for a = while.

    =0D=0A=0D=0A

     

    =0D= =0A=0D=0A

    The ability to=0D=0Atriangulate is around, but not widely deployed.

    =0D=0A=0D=0A

     

    =0D=0A=0D=0ABrian=

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A=
    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D=0A=0D= =0A

    From:=0D=0AThomson, Martin [mailto:Martin.= Thomson@andrew.com]
    =0D=0ASent: Monday, September 24, 2007=0D=0A6:35 PM
    =0D=0ATo: Brian Rosen;=0D=0Apeter_blatherwick@mitel.= com
    =0D=0ACc: ecrit
    =0D= =0ASubject: RE: [Ecrit] mult= iple location=0D=0Asources

    =0D=0A=0D=0A
    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    An important caveat to=0D=0Adocume= nt is that LLDP-MED doesn’t always provide the host location.  A= n=0D=0A802.11 AP might only be able to provide its own location, which, if = it is in=0D=0Athe next building, isn’t much use.

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A
    =0D=0A=0D= =0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A

    From:=0D=0ABrian Rosen [mailto:br@brianrosen.net]
    =0D= =0ASent: Tuesday, 25 Septemb= er 2007=0D=0A6:43 AM
    =0D=0ATo: peter_blatherwick@mitel.com
    =0D=0ACc: 'ecrit'
    =0D=0ASub= ject: RE: [Ecrit] multiple=0D=0Alocation sources

    =0D=0A=0D=0A
    =0D=0A=0D=0A

     

    =0D=0A=0D=0A=

    I unders= tand the “moving=0D=0Aparts” now.  Clearly, DHCP is much m= ore mature and likely to work today=0D=0Athan LLDP-MED is.

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    I think the emergenc= y=0D=0Acall documentation is not the place to educate device developers of = how startup=0D=0Asequences involving LLDP, DHCP and HTTP based protocols co= uld best be done.

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A

    Brian

    =0D=0A=0D=0A

     

    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A=
    =0D=0A=0D=0A
    =0D=0A=0D=0A

    From:=0D=0Apeter_= blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
    =0D=0ASent: Monday, September 24, 2007=0D= =0A4:35 PM
    =0D=0ATo: Bria= n Rosen
    =0D=0ACc: 'Stark,= Barbara'; 'ecrit'
    =0D=0ASubject:     RE: [Ecrit] multiple=0D=0Alocation sources

    =0D=0A=0D=0A
    =0D=0A=0D=0A

     

    =0D=0A=0D=0A


    =0D=0A    > I’m not sure=0D=0Ahow you decided that LLDP-MED has fewer = moving parts or is more reliable than=0D=0ADHCP=
    =0D=0A    LLDP is running= at the other end of the physical wire the=0D=0Adevice in question is plugg= ed into.  (In the case of wireless, it is=0D=0Alikely at the access po= int, or just behind it.)  In that sense, there are=0D=0Aonly 2 moving = parts that have to be operating correctly -- the phone itself,=0D=0Aand the= L2 access switch it is plugged into.  Even with DHCP there is at=0D=0A= least the network infrastructure, a server somewhere, and often DHCP relay = to=0D=0Aset up to get it all working.  HELD has a bunch more mechanics= that all=0D=0Amust be working correctly on top of that.  =0D=0A
    =0D=0A
    =0D=0A    > MIGHT lead to=0D=0Aan i= mplied ordering, but I don’t think it’s even useful to say that= =2E  I’m=0D=0Anot sure why it matters.
    =0D=0A    I terms of th= e phone bcp, you are probably right, since=0D=0Aother MUSTs make sure that = there is always exactly one answer anyway.=0D=0A However, device devel= opers will certainly care -- getting startup=0D=0Asequence right is importa= nt and will not be immediately obvious to many not=0D=0Adeep in the details= of each piece.  The DSL Forum doc is really helpful  from that=0D=0Aperspective.  = ;
    =0D=0A
    =0D=0A    -- Peter

    =0D= =0A=0D=0A=0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A
    =0D=0A

     

    =0D=0A     		=0D=0A

    "Brian Rosen"=0D=0A <br@brianrosen.net&= gt;

    =0D=0A

    24.09.07=0D=0A 16:22

    =0D=0A     		=0D=0A

    &nb= sp;      
    =0D=0A  =0D=0A   =     To:      =0D=0A  <peter_blatherwick@m= itel.com>, "'Stark, Barbara'"=0D=0A <bs7652@att.com>
    =0D=0A  =0D=0A       cc:   &n= bsp;    "'ecrit'"=0D=0A <ecrit@ietf.org><= /font>
    =0D=0A  =0D=0A       Subject:   &n= bsp;    RE: [Ecrit] multiple=0D=0A location sources

    =0D=0A
    =0D=0A=0D=0A


    =0D=0A
    =0D=0A
    =0D=0A    I’m not sure how you=0D=0Ad= ecided that LLDP-MED has fewer moving parts or is more reliable than DHCP.=0D= =0A I think likely it’s the other way right now.  
    =0D=0A 
    =0D=0ACertainly, if your are auto= configuring=0D=0Awith LLDP, you will want that to complete before you do DH= CP.  I don’t=0D=0Athink we have to say that, but we can if we ne= ed to.  
    =0D=0A     
    =0D=0A    I agree= you need an IP address before you=0D=0Acan invoke HELD.  I don’= t think we have to say that.
    =0D=0A=  <= span lang=3DEN-US>
    =0D=0AThis MIGHT lead to an implied ordering,=0D=0Abut I don’t thin= k it’s even useful to say that.  I’m not sure why it=0D=0A= matters.
    =0D=0A     
    =0D= =0A    Brian
    =0D=0A     

    =0D= =0A=0D=0A

     

    =0D=0A=0D=0A
    =0D=0A=0D= =0A
    =0D=0A=0D=0A    =0D=0A=0D=0A


    =0D=0A    = From:=0D=0Apeter_blatherwick@mite= l.com [mailto:peter_blatherwick@mitel.com]
    =0D=0ASent:     Monday, September 24, 2007 12:49 PM<= span style=3D'font-weight:=0D=0Abold'>
    =0D=0ATo:     Stark, Barba= ra
    =0D=0ACc:     ecrit
    =0D=0ASubject:     RE: [Ecrit] mult= iple location sources
    =0D=0A = ;
    =0D=0A
    =0D=0AHi,
    =0D=0AI agree that the DSL F= orum document makes a very good starting point for=0D=0Aorderly acquisition= of location at startup, accounting for all 3 methods.=0D=0A I also be= lieve it points to a preference order, if there are multiple=0D=0Aanswers c= oming back, which is LLDP-MED --> DHCP --> HELD.  Reasoning=0D=0A= for this order (my opinion) is that it progresses from "least moving=0D= =0Aparts" / most reliable (LLDP-MED) to most, and also follows the nat= ural=0D=0Alayering of the overall system (L2 --> L2.5 --> L7).  = In the end,=0D=0Aonly ONE method should ever be selected, as the sequence = diagram shows.  
    =0D=0A
    =0D=0AYour point below, that the methods can and = should progress in parallel is=0D=0Avalid.  However there are constrai= nts to this, notably:
    =0D=0A
    =0D=0Ao If LLDP-MED is being used to autoconfigur= e voice VLAN ID, then the device=0D=0Ashould wait to see if that stage succ= eeds before contacting DHCP.=0D=0A Otherwise, the device may get an IP= address on the default VLAN, only to=0D=0Ahave to drop it and try again on= the voice VLAN.  If it had started to use=0D=0Athis address for somet= hing already (say for HELD), then ongoing interaction=0D=0Awould be dropped= and confusion would likely ensue.  
    =0D=0A
    =0D=0Ao Before HELD can work= , an IP address is needed.       =0D=0A
    =0D=0AI think these constraints ar= e really just a reflection of the natural layering=0D=0Ain the end.  <= /span>
    =0D=0A    =0D=0AIMHO, orderly startup beats the few extra seconds delay incurred in= making sure=0D=0Athe constraints are not broken.   We are only talkin= g about a very few=0D=0Aseconds here after all.  
    =0D=0A
    =0D=0A-- Peter

    =0D=0A=0D=0A=0D=0A =0D=0A =0D=0A =0D=0A= =0D=0A =0D= =0A
    =0D=0A

    &= nbsp;

    =0D=0A     		=0D=0A <= p class=3DMsoNormal>"Stark, Barbara&quo= t; <bs7652@att.com>=0D=0A

    =0D=0A <= p>24.09.07=0D=0A 08:48

    =0D=0A     		=0D=0A

          &n= bsp;
    =0D=0A        To:        = "Winterbottom, James"=0D=0A <James.Winterbottom@andrew.com>, "Karl Heinz Wol= f"=0D=0A <khwolf1@gmail.com>, "ecrit" <ecrit@ietf.= org>    =0D=0A
    =0D=0A        cc: =        
    =0D=0A   &nbs= p;    Subject:        RE: [Ecrit]=0D=0A mult= iple location sources

    =0D=0A
    =0D=0A=0D=0A


    =0D=0A
    =0D=0A
    =0D=0A    <= /font>
    =0D=0AIt's not alwa= ys desirable to wait for a protocol to time-out, before launching=0D=0Athe = next protocol. Specifically, if a device is configured to do DHCP for IP=0D= =0Aaddress configuration, it should launch its DHCP discovery ASAP, with op= tions,=0D=0Ainstead of waiting the 4 or 5 seconds for LLDP-MED to time out.= This prevents=0D=0Aunnecessary delays in the bootstrap process. It should = be easy enough for the=0D=0Adevice to use a received LLDP-MED location, eve= n if it arrives after the DHCP=0D=0Aresponse.
    =0D=0ABa= rbara
    =0D=0A 
    =0D=0A--------------------
    =0D=0A[AJW] My first question = is why are you using more than one acquisition=0D=0Aprotocol. My thoughts w= ould be use one, if it fails, pick a different one.=0D=0ANever invoke both = at the same time so you have this problem of choice.
    =0D=0A 

    =0D=0A=0D=0A

    ***** =

    =0D=0A=0D=0A

    The information transmitted is = intended only for the person=0D=0Aor entity to which it is addressed and ma= y contain confidential, proprietary,=0D=0Aand/or privileged material. Any r= eview, retransmission, dissemination or other=0D=0Ause of, or taking of any= action in reliance upon this information by persons or=0D=0Aentities other= than the intended recipient is prohibited. If you received this=0D=0Ain er= ror, please contact the sender and delete the material from all computers.=0D= =0AGA623_______________= ________________________________
    =0D=0AEcrit mailing list
    =0D=0AEcrit= @ietf.org
    =0D=0Ahttps://www1.ietf.org/mailman/listinfo/ecrit

    =0D=0A=0D=0A
    =0D=0A=0D=0A<= /div>=0D=0A=0D=0A

     

    =0D=0A=0D=0A=0D=0A =0D=0A =0D=0A =0D=0A
    =0D=0A


    =0D=0A = ---------------------------------------------------------------------------= ---------------------
    =0D=0A This message is for th= e designated recipient only and may
    =0D=0A con= tain privileged, proprietary, or otherwise private=  information.  
    =0D=0A If you have receiv= ed it in error, please notify the sender=
    =0D=0A immediately and delete the original. &= nbsp;Any unauthorized use of
    =0D=0A this email = ;is prohibited.
    =0D=0A -------------------------------------------= -----------------------------------------------------
    =0D=0A [mf2]=

    =0D=0A
    =0D=0A=0D=0A=

     

    =0D= =0A=0D=0A
    =0D=0A=0D=0A
    =0D=0A=0D=0A

     

    =0D= =0A=0D=0A=0D=0A =0D=0A =0D=0A =0D= =0A
    =0D=0A


    =0D=0A -------------------------------------------------= -----------------------------------------------
    =0D=0A This messag= e is for the designated recipient only a= nd may
    =0D=0A contain privileged, proprietary, or&n= bsp;otherwise private information.  
    =0D=0A If = ;you have received it in error, please n= otify the sender
    =0D=0A immediately and delete = ;the original.  Any unauthorized use of
    =0D= =0A this email is prohibited.
    =0D=0A ------------------= ---------------------------------------------------------------------------= ---
    =0D=0A [mf2]

    =0D=0A
    =0D=0A=0D=0A

     

    =0D=0A=0D=0A
    =0D=0A=0D=0A


    -------------------------------------------------= -----------------------------------------------
    =0D=0AThis message&= nbsp;is for the designated recipient only and=  may
    =0D=0Acontain privileged, proprietary, or = otherwise private information.  
    =0D=0AIf you&n= bsp;have received it in error, please notify&= nbsp;the sender
    =0D=0Aimmediately and delete the&nbs= p;original.  Any unauthorized use of
    =0D=0Athis=  email is prohibited.
    =0D=0A-----------------------------= -------------------------------------------------------------------
    =0D=0A= [mf2]
    =0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01C7FFC4.6D9EEF0C-- --===============1322402027== 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 --===============1322402027==-- From ecrit-bounces@ietf.org Tue Sep 25 19:26:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaJmt-0003b2-5Q; Tue, 25 Sep 2007 19:25:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaJmr-0003a1-OI for ecrit@ietf.org; Tue, 25 Sep 2007 19:25:53 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaJml-00063V-Jx for ecrit@ietf.org; Tue, 25 Sep 2007 19:25:53 -0400 X-IronPort-AV: E=Sophos;i="4.20,297,1186372800"; d="scan'208";a="72119811" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 25 Sep 2007 19:25:32 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8PNPWuS014708; Tue, 25 Sep 2007 19:25:32 -0400 Received: from [68.50.16.73] (che-vpn-cluster-1-193.cisco.com [10.86.240.193]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8PNPL1V006823; Tue, 25 Sep 2007 23:25:23 GMT In-Reply-To: References: <194701c7fee8$927a12d0$640fa8c0@cis.neustar.com><19aa01c7feeb$90c88ae0$640fa8c0@cis.neustar.com><1ba801c7ff92$b3b8cf90$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <62FC3EA6-98C3-4D88-8A77-1C6724C12FE2@cisco.com> Content-Transfer-Encoding: quoted-printable From: John Schnizlein Subject: Re: [Ecrit] multiple location sources Date: Tue, 25 Sep 2007 19:23:46 -0400 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2952; t=1190762732; x=1191626732; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jschnizl@cisco.com; z=From:=20John=20Schnizlein=20 |Subject:=20Re=3A=20[Ecrit]=20multiple=20location=20sources |Sender:=20 |To:=20=22Dawson,=20Martin=22=20; bh=UuWUCGAOYCJgOQ3tJ010caIonRrLwWc6N5oZMUg/i+Q=; b=tAR9fl3th/KDHYizQGvwyZjTPsc5YXP0KZ2km/+9wCuleG+3yBFdd2ZoylDWO7sAYTSi/DPI 9vGR5IAeD27aFlmeHZxe2mcBxrNGqv6JanwxbXx3CT88UBA31F+UHmNj; Authentication-Results: rtp-dkim-2; header.From=jschnizl@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ecrit , "Thomson, Martin" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org What RFC 3825 actually says about the wireless-LAN access point is as =20= follows: Wireless hosts can utilize this option to gain knowledge of the location of the radio access point used during host configuration, but would need some more exotic mechanisms, maybe GPS, or maybe a future DHCP option, which includes a list of geo-locations like that defined here, containing the locations of the radio access points that are close to the client. The range of the radio in the access point, or the accuracy of =20 triangulation (or other means) would determine the resolution of the =20 LCI provided. John P.S. Why are we rehashing settled issues from years ago here? On Sep 25, 2007, at 6:35 PM, Dawson, Martin wrote: > But, then, the progenitors of 3825 have always said that it wasn=92t =20= > for wireless =96 it is aimed at enterprise wired Ethernet switched =20 > LANs. Since LLDP-MED has the same encoding, the same restrictions =20 > apply. > > > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] >> Uncertainty becomes useful information here. It is important to =20 >> distinguish between the location of the AP, which is known to a =20 >> certain precision, and the location of the host. If you are using =20= >> the location of the AP to determine the location of the host, then =20= >> the location of the host is the coverage area of the AP. =20 >> Therefore, there is a difference between the two. >> >> That is, if the AP location is known as (x, y) with relatively =20 >> high precision, then the location of the host is (x, y) give or =20 >> take the effective range of the AP. Therefore, the location of =20 >> the AP and the location of a host differ. >> >> But then, that doesn=92t work very well with LCI. >> >> Case 3 would be nice, but I doubt that it will ever account for =20 >> 100% of cases. >> >> From: Brian Rosen [mailto:br@brianrosen.net] >>> That=92s often all you can get. >>> >>> There are only three cases: >>> >>> The user measures its own location, no LCP needed >>> The location of the clients of the AP are reported as the =20 >>> location of the AP >>> There is triangulation between APs and clients to get a more =20 >>> accurate location >>> Case 2 is going to be the norm for a while. >>> >>> The ability to triangulate is around, but not widely deployed. >>> >>> Brian >>> >>> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] >>> >>>> An important caveat to document is that LLDP-MED doesn=92t always =20= >>>> provide the host location. An 802.11 AP might only be able to =20 >>>> provide its own location, which, if it is in the next building, =20 >>>> isn=92t much use. >>>> >>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>>> I understand the =93moving parts=94 now. Clearly, DHCP is much =20= >>>>> more mature and likely to work today than LLDP-MED is. >>>> ... _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 25 19:32:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaJt1-000864-MD; Tue, 25 Sep 2007 19:32:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaJt1-00085s-2u for ecrit@ietf.org; Tue, 25 Sep 2007 19:32:15 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaJsu-0006Ce-Tr for ecrit@ietf.org; Tue, 25 Sep 2007 19:32:15 -0400 X-SEF-Processed: 5_0_0_910__2007_09_25_18_41_32 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 25 Sep 2007 18:41:32 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Sep 2007 18:31:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] multiple location sources Date: Tue, 25 Sep 2007 18:30:51 -0500 Message-ID: In-Reply-To: <62FC3EA6-98C3-4D88-8A77-1C6724C12FE2@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] multiple location sources Thread-Index: Acf/y16ALi3St7N6RbixC/jBG3yGDwAAEqqA References: <194701c7fee8$927a12d0$640fa8c0@cis.neustar.com><19aa01c7feeb$90c88ae0$640fa8c0@cis.neustar.com><1ba801c7ff92$b3b8cf90$640fa8c0@cis.neustar.com> <62FC3EA6-98C3-4D88-8A77-1C6724C12FE2@cisco.com> From: "Dawson, Martin" To: "John Schnizlein" X-OriginalArrivalTime: 25 Sep 2007 23:31:53.0400 (UTC) FILETIME=[411A4380:01C7FFCC] X-Spam-Score: 1.8 (+) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ecrit , "Thomson, Martin" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Huh=3F Well - the thread got onto LLDP-MED. Why are you changing the=0D=0Ac= haracterization of 3825=3F We got repeatedly told that the encoding was=0D=0A= only ever intended to convey the location of a *point* - that's why the=0D=0A= inadequacies of using significant digits for uncertainty wasn't an=0D=0Aiss= ue. Now you're saying it can be used to convey the "range" of the=0D=0Aacce= ss point=3F It can't - that was the whole point of the discussion=0D=0A"yea= rs ago".=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message---= --=0D=0AFrom: John Schnizlein [mailto:jschnizl@cisco.com]=20=0D=0ASent: Wed= nesday, 26 September 2007 9:24 AM=0D=0ATo: Dawson, Martin=0D=0ACc: Thomson,= Martin; Brian Rosen; peter_blatherwick@mitel.com; ecrit=0D=0ASubject: Re: = [Ecrit] multiple location sources=0D=0A=0D=0AWhat RFC 3825 actually says ab= out the wireless-LAN access point is as =20=0D=0Afollows:=0D=0A=0D=0A Wi= reless hosts can utilize this option to gain knowledge of the=0D=0A loca= tion of the radio access point used during host configuration,=0D=0A but= would need some more exotic mechanisms, maybe GPS, or maybe a=0D=0A fut= ure DHCP option, which includes a list of geo-locations like that=0D=0A = defined here, containing the locations of the radio access points=0D=0A = that are close to the client.=0D=0A=0D=0AThe range of the radio in the acce= ss point, or the accuracy of =20=0D=0Atriangulation (or other means) would = determine the resolution of the =20=0D=0ALCI provided.=0D=0A=0D=0AJohn=0D=0A=0D= =0AP.S. Why are we rehashing settled issues from years ago here=3F=0D=0A=0D= =0AOn Sep 25, 2007, at 6:35 PM, Dawson, Martin wrote:=0D=0A> But, then, the= progenitors of 3825 have always said that it wasn't =20=0D=0A> for wireles= s - it is aimed at enterprise wired Ethernet switched =20=0D=0A> LANs. Sinc= e LLDP-MED has the same encoding, the same restrictions =20=0D=0A> apply.=0D= =0A>=0D=0A>=0D=0A>=0D=0A> From: Thomson, Martin [mailto:Martin.Thomson@andr= ew.com]=0D=0A>> Uncertainty becomes useful information here. It is importa= nt to =20=0D=0A>> distinguish between the location of the AP, which is know= n to a =20=0D=0A>> certain precision, and the location of the host. If you= are using =20=0D=0A>> the location of the AP to determine the location of = the host, then =20=0D=0A>> the location of the host is the coverage area of= the AP. =20=0D=0A>> Therefore, there is a difference between the two.=0D=0A= >>=0D=0A>> That is, if the AP location is known as (x, y) with relatively =0D= =0A>> high precision, then the location of the host is (x, y) give or =20=0D= =0A>> take the effective range of the AP. Therefore, the location of =20=0D= =0A>> the AP and the location of a host differ.=0D=0A>>=0D=0A>> But then, t= hat doesn't work very well with LCI.=0D=0A>>=0D=0A>> Case 3 would be nice, = but I doubt that it will ever account for =20=0D=0A>> 100% of cases.=0D=0A>= >=0D=0A>> From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A>>> That's ofte= n all you can get.=0D=0A>>>=0D=0A>>> There are only three cases:=0D=0A>>>=0D= =0A>>> The user measures its own location, no LCP needed=0D=0A>>> The locat= ion of the clients of the AP are reported as the =20=0D=0A>>> location of t= he AP=0D=0A>>> There is triangulation between APs and clients to get a more= =20=0D=0A>>> accurate location=0D=0A>>> Case 2 is going to be the norm for= a while.=0D=0A>>>=0D=0A>>> The ability to triangulate is around, but not w= idely deployed.=0D=0A>>>=0D=0A>>> Brian=0D=0A>>>=0D=0A>>> From: Thomson, Ma= rtin [mailto:Martin.Thomson@andrew.com]=0D=0A>>>=0D=0A>>>> An important cav= eat to document is that LLDP-MED doesn't always =20=0D=0A>>>> provide the h= ost location. An 802.11 AP might only be able to =20=0D=0A>>>> provide its= own location, which, if it is in the next building, =20=0D=0A>>>> isn't mu= ch use.=0D=0A>>>>=0D=0A>>>> From: Brian Rosen [mailto:br@brianrosen.net]=0D= =0A>>>>> I understand the "moving parts" now. Clearly, DHCP is much =20=0D= =0A>>>>> more mature and likely to work today than LLDP-MED is.=0D=0A>>>> = =2E..=0D=0A=0D=0A----------------------------------------------------------= --------------------------------------=0D=0AThis message is for the designa= ted recipient only and may=0D=0Acontain privileged, proprietary, or otherwi= se private information. =20=0D=0AIf you have received it in error, please n= otify the sender=0D=0Aimmediately and delete the original. Any unauthorize= d use of=0D=0Athis email is prohibited.=0D=0A------------------------------= ------------------------------------------------------------------=0D=0A[mf= 2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 25 19:49:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaK9r-0002fE-TX; Tue, 25 Sep 2007 19:49:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaK9q-0002VL-3A for ecrit@ietf.org; Tue, 25 Sep 2007 19:49:38 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaK9i-0006Wb-K3 for ecrit@ietf.org; Tue, 25 Sep 2007 19:49:38 -0400 X-IronPort-AV: E=Sophos;i="4.20,297,1186372800"; d="scan'208";a="72120618" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 25 Sep 2007 19:49:26 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8PNnUoi019449; Tue, 25 Sep 2007 19:49:30 -0400 Received: from [68.50.16.73] (che-vpn-cluster-1-193.cisco.com [10.86.240.193]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8PNnT1V012192; Tue, 25 Sep 2007 23:49:29 GMT In-Reply-To: References: <194701c7fee8$927a12d0$640fa8c0@cis.neustar.com><19aa01c7feeb$90c88ae0$640fa8c0@cis.neustar.com><1ba801c7ff92$b3b8cf90$640fa8c0@cis.neustar.com> <62FC3EA6-98C3-4D88-8A77-1C6724C12FE2@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <54495F5D-750C-4C22-9644-B082DB01AC31@cisco.com> Content-Transfer-Encoding: 7bit From: John Schnizlein Subject: Re: [Ecrit] multiple location sources Date: Tue, 25 Sep 2007 19:47:54 -0400 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3821; t=1190764170; x=1191628170; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jschnizl@cisco.com; z=From:=20John=20Schnizlein=20 |Subject:=20Re=3A=20[Ecrit]=20multiple=20location=20sources |Sender:=20 |To:=20=22Dawson,=20Martin=22=20; bh=mijX9eU0R4qAQGKpQMlrdQ1eOopen4VBRqZnDAVGAOw=; b=xKZw2uI1yoy1LmfJAG3mz0I+gncu5GOtJqghS4WCP0NRG3RUPgvWdT/kCQksj7NVDwL38oR1 VMv2HOYHDRej8lzQQwI0oqajTGevdb1iAOf9zr1EZaUT5L0BMvWWgMqP; Authentication-Results: rtp-dkim-2; header.From=jschnizl@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ecrit , "Thomson, Martin" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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 quoted RFC 3825. Who is "changing the characterization of 3825"? Despite mistaken interpretations that were aired in the GeoPriv WG, the meaning of resolution has been clear (significant binary digits) all along. John On Sep 25, 2007, at 7:30 PM, Dawson, Martin wrote: > Huh? Well - the thread got onto LLDP-MED. Why are you changing the > characterization of 3825? We got repeatedly told that the encoding was > only ever intended to convey the location of a *point* - that's why > the > inadequacies of using significant digits for uncertainty wasn't an > issue. Now you're saying it can be used to convey the "range" of the > access point? It can't - that was the whole point of the discussion > "years ago". > > Cheers, > Martin > > From: John Schnizlein [mailto:jschnizl@cisco.com] >> >> What RFC 3825 actually says about the wireless-LAN access point is as >> follows: >> >> Wireless hosts can utilize this option to gain knowledge of the >> location of the radio access point used during host >> configuration, >> but would need some more exotic mechanisms, maybe GPS, or maybe a >> future DHCP option, which includes a list of geo-locations >> like that >> defined here, containing the locations of the radio access points >> that are close to the client. >> >> The range of the radio in the access point, or the accuracy of >> triangulation (or other means) would determine the resolution of the >> LCI provided. >> >> John >> >> P.S. Why are we rehashing settled issues from years ago here? >> >> On Sep 25, 2007, at 6:35 PM, Dawson, Martin wrote: >>> But, then, the progenitors of 3825 have always said that it wasn't >>> for wireless - it is aimed at enterprise wired Ethernet switched >>> LANs. Since LLDP-MED has the same encoding, the same restrictions >>> apply. >>> >>> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] >>>> Uncertainty becomes useful information here. It is important to >>>> distinguish between the location of the AP, which is known to a >>>> certain precision, and the location of the host. If you are using >>>> the location of the AP to determine the location of the host, then >>>> the location of the host is the coverage area of the AP. >>>> Therefore, there is a difference between the two. >>>> >>>> That is, if the AP location is known as (x, y) with relatively >>>> high precision, then the location of the host is (x, y) give or >>>> take the effective range of the AP. Therefore, the location of >>>> the AP and the location of a host differ. >>>> >>>> But then, that doesn't work very well with LCI. >>>> >>>> Case 3 would be nice, but I doubt that it will ever account for >>>> 100% of cases. >>>> >>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>>> That's often all you can get. >>>>> >>>>> There are only three cases: >>>>> >>>>> The user measures its own location, no LCP needed >>>>> The location of the clients of the AP are reported as the >>>>> location of the AP >>>>> There is triangulation between APs and clients to get a more >>>>> accurate location >>>>> Case 2 is going to be the norm for a while. >>>>> >>>>> The ability to triangulate is around, but not widely deployed. >>>>> >>>>> Brian >>>>> >>>>> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] >>>>> >>>>>> An important caveat to document is that LLDP-MED doesn't always >>>>>> provide the host location. An 802.11 AP might only be able to >>>>>> provide its own location, which, if it is in the next building, >>>>>> isn't much use. >>>>>> >>>>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>>>>> I understand the "moving parts" now. Clearly, DHCP is much >>>>>>> more mature and likely to work today than LLDP-MED is. >>>>>> ... > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 25 20:01:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaKKq-00034P-6n; Tue, 25 Sep 2007 20:01:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaKKp-00031H-Nl for ecrit@ietf.org; Tue, 25 Sep 2007 20:00:59 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaKKl-0006oC-Hy for ecrit@ietf.org; Tue, 25 Sep 2007 20:00:59 -0400 X-SEF-Processed: 5_0_0_910__2007_09_25_19_10_33 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 25 Sep 2007 19:10:33 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Sep 2007 19:00:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] multiple location sources Date: Tue, 25 Sep 2007 19:00:34 -0500 Message-ID: In-Reply-To: <54495F5D-750C-4C22-9644-B082DB01AC31@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] multiple location sources Thread-Index: Acf/zrefCHfsiwfjQty9EsSvIT0+hAAAQIbg References: <194701c7fee8$927a12d0$640fa8c0@cis.neustar.com><19aa01c7feeb$90c88ae0$640fa8c0@cis.neustar.com><1ba801c7ff92$b3b8cf90$640fa8c0@cis.neustar.com> <62FC3EA6-98C3-4D88-8A77-1C6724C12FE2@cisco.com> <54495F5D-750C-4C22-9644-B082DB01AC31@cisco.com> From: "Dawson, Martin" To: "John Schnizlein" X-OriginalArrivalTime: 26 Sep 2007 00:00:54.0277 (UTC) FILETIME=[4EBF0350:01C7FFD0] X-Spam-Score: 1.8 (+) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ecrit , "Thomson, Martin" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Yes - you quoted 3825 - which didn't say it could provide the area of=0D=0A= coverage of the access point - and then you went on to say that=0D=0Aresolu= tion could be used to express the range of the access point.=0D=0A=0D=0ATo = give you the benefit of the doubt - are you or are you not=0D=0Amaintaining= that you can represent any arbitrary access point location=0D=0Aand range = with just resolution=3F=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Orig= inal Message-----=0D=0AFrom: John Schnizlein [mailto:jschnizl@cisco.com] =0D= =0ASent: Wednesday, 26 September 2007 9:48 AM=0D=0ATo: Dawson, Martin=0D=0A= Cc: Thomson, Martin; Brian Rosen; peter_blatherwick@mitel.com; ecrit=0D=0AS= ubject: Re: [Ecrit] multiple location sources=0D=0A=0D=0AI quoted RFC 3825.= Who is "changing the characterization of 3825"=3F=0D=0A=0D=0ADespite mist= aken interpretations that were aired in the GeoPriv WG, =20=0D=0Athe meanin= g of resolution has been clear (significant binary digits) =20=0D=0Aall alo= ng.=0D=0A=0D=0AJohn=0D=0A=0D=0AOn Sep 25, 2007, at 7:30 PM, Dawson, Martin = wrote:=0D=0A=0D=0A> Huh=3F Well - the thread got onto LLDP-MED. Why are you= changing the=0D=0A> characterization of 3825=3F We got repeatedly told tha= t the encoding was=0D=0A> only ever intended to convey the location of a *p= oint* - that's why =20=0D=0A> the=0D=0A> inadequacies of using significant = digits for uncertainty wasn't an=0D=0A> issue. Now you're saying it can be = used to convey the "range" of the=0D=0A> access point=3F It can't - that wa= s the whole point of the discussion=0D=0A> "years ago".=0D=0A>=0D=0A> Cheer= s,=0D=0A> Martin=0D=0A>=0D=0A> From: John Schnizlein [mailto:jschnizl@cisco= =2Ecom]=0D=0A>>=0D=0A>> What RFC 3825 actually says about the wireless-LAN = access point is as=0D=0A>> follows:=0D=0A>>=0D=0A>> Wireless hosts can = utilize this option to gain knowledge of the=0D=0A>> location of the ra= dio access point used during host =20=0D=0A>> configuration,=0D=0A>> bu= t would need some more exotic mechanisms, maybe GPS, or maybe a=0D=0A>> = future DHCP option, which includes a list of geo-locations =20=0D=0A>> lik= e that=0D=0A>> defined here, containing the locations of the radio acce= ss points=0D=0A>> that are close to the client.=0D=0A>>=0D=0A>> The ran= ge of the radio in the access point, or the accuracy of=0D=0A>> triangulati= on (or other means) would determine the resolution of the=0D=0A>> LCI provi= ded.=0D=0A>>=0D=0A>> John=0D=0A>>=0D=0A>> P.S. Why are we rehashing settled= issues from years ago here=3F=0D=0A>>=0D=0A>> On Sep 25, 2007, at 6:35 PM,= Dawson, Martin wrote:=0D=0A>>> But, then, the progenitors of 3825 have alw= ays said that it wasn't=0D=0A>>> for wireless - it is aimed at enterprise w= ired Ethernet switched=0D=0A>>> LANs. Since LLDP-MED has the same encoding,= the same restrictions=0D=0A>>> apply.=0D=0A>>>=0D=0A>>> From: Thomson, Mar= tin [mailto:Martin.Thomson@andrew.com]=0D=0A>>>> Uncertainty becomes useful= information here. It is important to=0D=0A>>>> distinguish between the lo= cation of the AP, which is known to a=0D=0A>>>> certain precision, and the = location of the host. If you are using=0D=0A>>>> the location of the AP to= determine the location of the host, then=0D=0A>>>> the location of the hos= t is the coverage area of the AP.=0D=0A>>>> Therefore, there is a differenc= e between the two.=0D=0A>>>>=0D=0A>>>> That is, if the AP location is known= as (x, y) with relatively=0D=0A>>>> high precision, then the location of t= he host is (x, y) give or=0D=0A>>>> take the effective range of the AP. Th= erefore, the location of=0D=0A>>>> the AP and the location of a host differ= =2E=0D=0A>>>>=0D=0A>>>> But then, that doesn't work very well with LCI.=0D=0A= >>>>=0D=0A>>>> Case 3 would be nice, but I doubt that it will ever account = for=0D=0A>>>> 100% of cases.=0D=0A>>>>=0D=0A>>>> From: Brian Rosen [mailto:= br@brianrosen.net]=0D=0A>>>>> That's often all you can get.=0D=0A>>>>>=0D=0A= >>>>> There are only three cases:=0D=0A>>>>>=0D=0A>>>>> The user measures i= ts own location, no LCP needed=0D=0A>>>>> The location of the clients of th= e AP are reported as the=0D=0A>>>>> location of the AP=0D=0A>>>>> There is = triangulation between APs and clients to get a more=0D=0A>>>>> accurate loc= ation=0D=0A>>>>> Case 2 is going to be the norm for a while.=0D=0A>>>>>=0D=0A= >>>>> The ability to triangulate is around, but not widely deployed.=0D=0A>= >>>>=0D=0A>>>>> Brian=0D=0A>>>>>=0D=0A>>>>> From: Thomson, Martin [mailto:M= artin.Thomson@andrew.com]=0D=0A>>>>>=0D=0A>>>>>> An important caveat to doc= ument is that LLDP-MED doesn't always=0D=0A>>>>>> provide the host location= =2E An 802.11 AP might only be able to=0D=0A>>>>>> provide its own locatio= n, which, if it is in the next building,=0D=0A>>>>>> isn't much use.=0D=0A>= >>>>>=0D=0A>>>>>> From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A>>>>>>>= I understand the "moving parts" now. Clearly, DHCP is much=0D=0A>>>>>>> m= ore mature and likely to work today than LLDP-MED is.=0D=0A>>>>>> ...=0D=0A= >=0D=0A=0D=0A--------------------------------------------------------------= ----------------------------------=0D=0AThis message is for the designated = recipient only and may=0D=0Acontain privileged, proprietary, or otherwise p= rivate information. =20=0D=0AIf you have received it in error, please notif= y the sender=0D=0Aimmediately and delete the original. Any unauthorized us= e of=0D=0Athis email is prohibited.=0D=0A----------------------------------= --------------------------------------------------------------=0D=0A[mf2]=0D= =0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 25 20:23:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaKfv-0004cW-11; Tue, 25 Sep 2007 20:22:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaKft-0004au-Pw for ecrit@ietf.org; Tue, 25 Sep 2007 20:22:45 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaKft-0002uq-4c for ecrit@ietf.org; Tue, 25 Sep 2007 20:22:45 -0400 X-SEF-Processed: 5_0_0_910__2007_09_25_19_32_23 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 25 Sep 2007 19:32:23 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Sep 2007 19:22:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] multiple location sources Date: Tue, 25 Sep 2007 19:22:41 -0500 Message-ID: In-Reply-To: <54495F5D-750C-4C22-9644-B082DB01AC31@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] multiple location sources Thread-Index: Acf/zteuU47s/jV7QmSWXE43Hej2vQAA9Osg References: <194701c7fee8$927a12d0$640fa8c0@cis.neustar.com><19aa01c7feeb$90c88ae0$640fa8c0@cis.neustar.com><1ba801c7ff92$b3b8cf90$640fa8c0@cis.neustar.com><62FC3EA6-98C3-4D88-8A77-1C6724C12FE2@cisco.com> <54495F5D-750C-4C22-9644-B082DB01AC31@cisco.com> From: "Winterbottom, James" To: "John Schnizlein" , "Dawson, Martin" X-OriginalArrivalTime: 26 Sep 2007 00:22:44.0517 (UTC) FILETIME=[5BB5C550:01C7FFD3] X-Spam-Score: 1.8 (+) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ecrit , "Thomson, Martin" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org John,=0D=0A=0D=0A3825 states normative section 2.1,=0D=0A=0D=0A"The example= s in the appendix illustrate that a smaller value in the=0D=0A resolution= field increases the area within which the device is=0D=0A located."=0D=0A=0D= =0AAnd this is clearly what is reflected in the examples. That is, it tries=0D= =0Ato use significant digit to express uncertainty. Whether you believe it=0D= =0Aor not, that it what it is doing. It is flawed.=0D=0A=0D=0AYou cannot us= e the LCI encoding to express a range of values without=0D=0Acontradicting = what you stated earlier. Either it is a point, and 3825 is=0D=0Asimply wron= g, or you are trying to express an area using significant=0D=0Adigits, and = you have the error situation.=0D=0A=0D=0AWhich is it=3F=0D=0A=0D=0ACheers=0D= =0AJames=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> F= rom: John Schnizlein [mailto:jschnizl@cisco.com]=0D=0A> Sent: Wednesday, 26= September 2007 9:48 AM=0D=0A> To: Dawson, Martin=0D=0A> Cc: ecrit; Thomson= , Martin=0D=0A> Subject: Re: [Ecrit] multiple location sources=0D=0A>=20=0D= =0A> I quoted RFC 3825. Who is "changing the characterization of 3825"=3F=0D= =0A>=20=0D=0A> Despite mistaken interpretations that were aired in the GeoP= riv WG,=0D=0A> the meaning of resolution has been clear (significant binary= digits)=0D=0A> all along.=0D=0A>=20=0D=0A> John=0D=0A>=20=0D=0A> On Sep 25= , 2007, at 7:30 PM, Dawson, Martin wrote:=0D=0A>=20=0D=0A> > Huh=3F Well - = the thread got onto LLDP-MED. Why are you changing the=0D=0A> > characteriz= ation of 3825=3F We got repeatedly told that the encoding=0D=0Awas=0D=0A> >= only ever intended to convey the location of a *point* - that's why=0D=0A>= > the=0D=0A> > inadequacies of using significant digits for uncertainty wa= sn't an=0D=0A> > issue. Now you're saying it can be used to convey the "ran= ge" of the=0D=0A> > access point=3F It can't - that was the whole point of = the discussion=0D=0A> > "years ago".=0D=0A> >=0D=0A> > Cheers,=0D=0A> > Mar= tin=0D=0A> >=0D=0A> > From: John Schnizlein [mailto:jschnizl@cisco.com]=0D=0A= > >>=0D=0A> >> What RFC 3825 actually says about the wireless-LAN access po= int is=0D=0Aas=0D=0A> >> follows:=0D=0A> >>=0D=0A> >> Wireless hosts ca= n utilize this option to gain knowledge of the=0D=0A> >> location of th= e radio access point used during host=0D=0A> >> configuration,=0D=0A> >> = but would need some more exotic mechanisms, maybe GPS, or maybe=0D=0Aa=0D= =0A> >> future DHCP option, which includes a list of geo-locations=0D=0A= > >> like that=0D=0A> >> defined here, containing the locations of the = radio access=0D=0Apoints=0D=0A> >> that are close to the client.=0D=0A>= >>=0D=0A> >> The range of the radio in the access point, or the accuracy o= f=0D=0A> >> triangulation (or other means) would determine the resolution o= f=0D=0Athe=0D=0A> >> LCI provided.=0D=0A> >>=0D=0A> >> John=0D=0A> >>=0D=0A= > >> P.S. Why are we rehashing settled issues from years ago here=3F=0D=0A>= >>=0D=0A> >> On Sep 25, 2007, at 6:35 PM, Dawson, Martin wrote:=0D=0A> >>>= But, then, the progenitors of 3825 have always said that it wasn't=0D=0A> = >>> for wireless - it is aimed at enterprise wired Ethernet switched=0D=0A>= >>> LANs. Since LLDP-MED has the same encoding, the same restrictions=0D=0A= > >>> apply.=0D=0A> >>>=0D=0A> >>> From: Thomson, Martin [mailto:Martin.Tho= mson@andrew.com]=0D=0A> >>>> Uncertainty becomes useful information here. = It is important to=0D=0A> >>>> distinguish between the location of the AP, = which is known to a=0D=0A> >>>> certain precision, and the location of the = host. If you are=0D=0Ausing=0D=0A> >>>> the location of the AP to determin= e the location of the host,=0D=0Athen=0D=0A> >>>> the location of the host = is the coverage area of the AP.=0D=0A> >>>> Therefore, there is a differenc= e between the two.=0D=0A> >>>>=0D=0A> >>>> That is, if the AP location is k= nown as (x, y) with relatively=0D=0A> >>>> high precision, then the locatio= n of the host is (x, y) give or=0D=0A> >>>> take the effective range of the= AP. Therefore, the location of=0D=0A> >>>> the AP and the location of a h= ost differ.=0D=0A> >>>>=0D=0A> >>>> But then, that doesn't work very well w= ith LCI.=0D=0A> >>>>=0D=0A> >>>> Case 3 would be nice, but I doubt that it = will ever account for=0D=0A> >>>> 100% of cases.=0D=0A> >>>>=0D=0A> >>>> Fr= om: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> >>>>> That's often all yo= u can get.=0D=0A> >>>>>=0D=0A> >>>>> There are only three cases:=0D=0A> >>>= >>=0D=0A> >>>>> The user measures its own location, no LCP needed=0D=0A> >>= >>> The location of the clients of the AP are reported as the=0D=0A> >>>>> = location of the AP=0D=0A> >>>>> There is triangulation between APs and clie= nts to get a more=0D=0A> >>>>> accurate location=0D=0A> >>>>> Case 2 is goi= ng to be the norm for a while.=0D=0A> >>>>>=0D=0A> >>>>> The ability to tri= angulate is around, but not widely deployed.=0D=0A> >>>>>=0D=0A> >>>>> Bria= n=0D=0A> >>>>>=0D=0A> >>>>> From: Thomson, Martin [mailto:Martin.Thomson@an= drew.com]=0D=0A> >>>>>=0D=0A> >>>>>> An important caveat to document is tha= t LLDP-MED doesn't always=0D=0A> >>>>>> provide the host location. An 802.= 11 AP might only be able to=0D=0A> >>>>>> provide its own location, which, = if it is in the next building,=0D=0A> >>>>>> isn't much use.=0D=0A> >>>>>>=0D= =0A> >>>>>> From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> >>>>>>> I u= nderstand the "moving parts" now. Clearly, DHCP is much=0D=0A> >>>>>>> mor= e mature and likely to work today than LLDP-MED is.=0D=0A> >>>>>> ...=0D=0A= > >=0D=0A>=20=0D=0A> _______________________________________________=0D=0A>= Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mail= man/listinfo/ecrit=0D=0A=0D=0A---------------------------------------------= ---------------------------------------------------=0D=0AThis message is fo= r the designated recipient only and may=0D=0Acontain privileged, proprietar= y, or otherwise private information. =20=0D=0AIf you have received it in er= ror, please notify the sender=0D=0Aimmediately and delete the original. An= y unauthorized use of=0D=0Athis email is prohibited.=0D=0A-----------------= ---------------------------------------------------------------------------= ----=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Sep 25 23:35:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaNev-0006wp-Ba; Tue, 25 Sep 2007 23:33:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaNeu-0006wi-Pw for ecrit@ietf.org; Tue, 25 Sep 2007 23:33:56 -0400 Received: from sea-mimesweep-1.telecomsys.com ([206.173.41.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaNen-00076M-Hv for ecrit@ietf.org; Tue, 25 Sep 2007 23:33:51 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Tue, 25 Sep 2007 20:34:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [ECRIT] wg Status Update - as of 9/25/07 Date: Tue, 25 Sep 2007 20:34:05 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657508493B4B@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ECRIT] wg Status Update - as of 9/25/07 Thread-Index: Acf/7hanEIzVNJ6+Scu7yC4v+Lsdbg== From: "Roger Marshall" To: "ECRIT" , "Hannes Tschofenig" , "Marc Linsner" X-Spam-Score: 0.0 (/) X-Scan-Signature: 47dfdcb76bc7cdf600c30037ff1750ed Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1039742622==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1039742622== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7FFEE.1EB1B2F6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7FFEE.1EB1B2F6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ECRIT WG Status Update - Sept 2007 =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 Upcoming IETF Meeting =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The next ECRIT (IETF70) meeting is scheduled for Dec 2-7, Vancouver B.C. See: http://www3.ietf.org/meetings/70-IETF.html Other information: There is a new Web-based tool that can be used now to submit a new draft, see: http://www1.ietf.org/mail-archive/web/ecrit/current/msg04384.html The meeting minutes from the last IETF69 are here: http://www3.ietf.org/proceedings/07jul/minutes/ecrit.txt In addition, there is some progress on some of the wg related documents. Prior status reports are posted to the ECRIT WG status site. See: http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/EcritStatusUp date Document Status =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In the RFC Editor's Queue =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 Requirements for Emergency Context Resolution with Internet Technologies ------------------------------------------------------------------------ Draft is moving through the "RFC Ed Queue" - seems close to being published: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-13.txt A Uniform Resource Name (URN) for Services ------------------------------------------ Draft has moved to the "RFC Ed Queue" as of 8/21/07: http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service-ur n-07.txt=20 Security Threats and Requirements for Emergency Call Marking and Mapping ------------------------------------------------------------------------ The new (-05) Draft version has moved to the "RFC Ed Queue" as of 9/12/07. http://www.ietf.org/internet-drafts/draft-ietf-ecrit-security-threats-05 .txt PROTO Documents =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The document shepherding process is described in: http://tools.ietf.org/id/draft-ietf-proto-wgchair-doc-shepherding-07.txt LoST: A Location-to-Service Translation Protocol ------------------------------------------------ PROTO writeup has been sent to the Area Directors and the IESG to complete the work. http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-06.txt Location-to-URL Mapping Architecture and Framework -------------------------------------------------- PROTO WRITEUP has been sent to the Area Directors and the IESG to complete work. http://www.ietf.org/internet-drafts/draft-ietf-ecrit-mapping-arch-02.txt A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service=20 Translation Protocol (LoST) Discovery Procedure ---------------------------------------------------------------------- PROTO WRITEUP has been sent to the Area Directors and the IESG to complete work. http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery- 02.txt Other WG Drafts =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The (two) remaining ECRIT WG Drafts, below, have been updated. Framework for Emergency Calling using Internet Multimedia --------------------------------------------------------- New Draft version published as of 9/19/07. Needs additional WG review. http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-03.txt Best Current Practice for Communications Services in support of Emergency Calling ------------------------------------------------------------------------ --------- New Draft version published as of 9/19/07. Needs additional WG review. http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-02.txt Individual Drafts =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Location Hiding: Problem Statement and Requirements --------------------------------------------------- An updated draft has been produced, see:=20 http://tools.ietf.org/wg/ecrit/draft-schulzrinne-ecrit-location-hiding-r equirements-01.txt Last action on this was: "Initiate discussion after the main WG items have been progressed." Action: ECRIT chairs to determine level of effort, since other items now progressed. Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices ------------------------------------------------------------------------ -------------- Initial draft version has been submitted. http://tools.ietf.org/wg/ecrit/draft-schulzrinne-ecrit-unauthenticated-a ccess-00.txt There is a IEEE liaison msg. which references the above draft, see: http://www1.ietf.org/mail-archive/web/ecrit/current/msg04361.html Emergency Call Marking ---------------------- >From last report, it was stated: "The initially assumed solution, http://tools.ietf.org/wg/sip/draft-rosenberg-sip-ua-loose-route-01.txt, was not accepted at the IETF meeting." Some discussion has taken place entitled "UA Loose Routing", see: http://www1.ietf.org/mail-archive/web/ecrit/current/msg04308.html And "call marking", see: http://www1.ietf.org/mail-archive/web/ecrit/current/msg04310.html Which Richard reintroduced, and which there appears to be no common resolution for yet, see Brian's response on probable action by most proxies, see: http://www1.ietf.org/mail-archive/web/ecrit/current/msg04319.html Proxy Authentication of the Emergency Status of SIP Calls --------------------------------------------------------- >From last report, it was stated,=20 "A lot of the discussions in the last few weeks focused on http://tools.ietf.org/wg/ecrit/draft-barnes-ecrit-auth-00.txt Action Item: Summary needs to be compiled." Action: Need to determine next steps. Overview of the IETF Emergency Services Architecture ---------------------------------------------------- Restated from the last report: "The following document gives an overview of the emergency services=20 architecture: http://tools.ietf.org/wg/ecrit/draft-tschofenig-ecrit-architecture-overv iew-00.txt It is meant to be read by members from other SDOs and regulators." DSL Forum Documents ------------------- The following referenced document were made available from the DSL Forum. An initial review was made by Hannes Tschofenig, see: http://www1.ietf.org/mail-archive/web/ecrit/current/msg04320.html Additional comments have been logged to the list, see: http://www1.ietf.org/mail-archive/web/ecrit/current/mail3.html Alignment between IETF and 3GPP Emergency Services Architecture --------------------------------------------------------------- >From the last report, "[Hannes]... has the action item to schedule a conference=20 call within the IETF ECRIT WG and subsequently between IETF ECRIT=20 and the 3GPP to discuss a possible alignment." 3rd SDO Emergency Services Workshop ----------------------------------- The next workshop (ESW03-07) is scheduled for a 3 day meeting (October 30st -=20 November 1st) in Brussels/Belgium (3 day mtg.). Meeting information can be found here: http://www.emergency-services-coordination.info/2007Nov/ A first version of the agenda is also available: https://lists.cs.columbia.edu/pipermail/es-coordination/2007-August/0000 50.html Tuesday, October 30: -------- Tutorials about IETF, 3GPP and NENA architectures u2010 meeting the standards Wednesday, October 31: ---------- Policy Panel Status Updates * IETF (GEOPRIV, ECRIT, SIP) * DSL Forum * IEEE * ATIS-ESIF * NENA * ETSI EMTEL * 3GPP * 3GPP2 * ETSI TISPAN * FCC * Open Mobile Alliance (OMA) * TIA * US Department of Transportation * OCG * EU Commission * Wimax Forum * WiFi Forum/Alliance * APCO Project 41 * COMCAST * NIST Thursday, November 1: --------- Status Updates (con't) Authority-to-Citizen Communication Requirements What's available now _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit Roger Marshall=20 The information contained in this message may be privileged and/or confiden= tial. If you are not the intended recipient, or responsible for delivering = this message to the intended recipient, any review, forwarding, disseminati= on, distribution or copying of this communication or any attachment(s) is s= trictly prohibited. If you have received this message in error, please so n= otify the sender immediately, and delete it and all attachments from your c= omputer and network. ------_=_NextPart_001_01C7FFEE.1EB1B2F6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [ECRIT] wg Status Update - as of 9/25/07

    ECRIT WG Status Update - Sept 2007
    =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


    Upcoming IETF Meeting
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    The next ECRIT (IETF70) meeting is s= cheduled for Dec 2-7, Vancouver B.C. See:
    http://www3.ietf.org/meetings/70= -IETF.html


    Other information:

    There is a new Web-based tool that c= an be used now to submit a new draft, see:
    http://www1= .ietf.org/mail-archive/web/ecrit/current/msg04384.html

    The meeting minutes from the last IE= TF69 are here:
    http://www3.ietf.org= /proceedings/07jul/minutes/ecrit.txt
    In addition, there is some progress= on some of the wg related documents.

    Prior status reports are posted to t= he ECRIT WG status site. See: http://www.tschofenig.priv.at/twiki/bin/view/E= mergencyServices/EcritStatusUpdate


    Document Status
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

    In the RFC Editor's Queue
    =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

    Requirements for Emergency Context R= esolution with Internet Technologies
    -----------------------------------= -------------------------------------
    Draft is moving through the "R= FC Ed Queue" - seems close to being published:
    http= ://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-13.txt=


    A Uniform Resource Name (URN) for Se= rvices
    -----------------------------------= -------
    Draft has moved to the "RFC Ed= Queue" as of 8/21/07:
    http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service-u= rn-07.txt


    Security Threats and Requirements fo= r Emergency Call Marking and Mapping
    -----------------------------------= -------------------------------------
    The new (-05) Draft version has mov= ed to the "RFC Ed Queue" as of 9/12/07.
    = http://www.ietf.org/internet-drafts/draft-ietf-ecrit-security-threats-05.tx= t


    PROTO Documents
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

    The document shepherding process is = described in:
    http= ://tools.ietf.org/id/draft-ietf-proto-wgchair-doc-shepherding-07.txt=


    LoST: A Location-to-Service Translat= ion Protocol
    -----------------------------------= -------------
    PROTO writeup has been sent to the = Area Directors and the IESG to complete the work.
    http://www.i= etf.org/internet-drafts/draft-ietf-ecrit-lost-06.txt


    Location-to-URL Mapping Architecture= and Framework
    -----------------------------------= ---------------
    PROTO WRITEUP has been sent to the = Area Directors and the IESG to complete work.
    http= ://www.ietf.org/internet-drafts/draft-ietf-ecrit-mapping-arch-02.txt=


    A Dynamic Host Configuration Protoco= l (DHCP) based Location-to-ServiceTranslation Protocol (LoST) Discovery P= rocedure
    -----------------------------------= -----------------------------------
    PROTO WRITEUP has been sent to the = Area Directors and the IESG to complete work.
    Other WG Drafts
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

    The (two) remaining ECRIT WG Drafts,= below, have been updated.

    Framework for Emergency Calling usin= g Internet Multimedia
    -----------------------------------= ----------------------
    New Draft version published as of 9= /19/07.  Needs additional WG review.
    http://= www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-03.txt


    Best Current Practice for Communicat= ions Services in support of Emergency Calling
    -----------------------------------= ----------------------------------------------
    New Draft version published as of 9= /19/07.  Needs additional WG review.
    http://w= ww.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-02.txt



    Individual Drafts
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

    Location Hiding: Problem Statement a= nd Requirements
    -----------------------------------= ----------------
    An updated draft has been produced,= see:
    http://tools.ietf.org/wg/ecrit/draft-schulzrinne-ecrit-locati= on-hiding-requirements-01.txt

    Last action on this was: "Initi= ate discussion after the main WG items have been progressed."

    Action: ECRIT chairs to determine le= vel of effort, since other items now progressed.


    Extensions to the Emergency Services= Architecture for dealing with Unauthenticated and Unauthorized Devices
    -----------------------------------= ---------------------------------------------------
    Initial draft version has been subm= itted.
    http://tools.ietf.org/wg/ecrit/draft-schulzrinne-ecrit-unauthentica= ted-access-00.txt

    There is a IEEE liaison msg. which r= eferences the above draft, see:
    http://www1= .ietf.org/mail-archive/web/ecrit/current/msg04361.html


    Emergency Call Marking
    ----------------------
    From last report, it was stated:
    "The initially assumed solutio= n,
    http:/= /tools.ietf.org/wg/sip/draft-rosenberg-sip-ua-loose-route-01.txt= ,
    was not accepted at the IETF meetin= g."

    Some discussion has taken place enti= tled "UA Loose Routing", see:
    http://www1= .ietf.org/mail-archive/web/ecrit/current/msg04308.html

    And "call marking", see:
    http://www1= .ietf.org/mail-archive/web/ecrit/current/msg04310.html
    Which Richard reintroduced, and whi= ch there appears to be no common resolution for yet, see Brian's response o= n probable action by most proxies, see:

    http://www1.= ietf.org/mail-archive/web/ecrit/current/msg04319.html


    Proxy Authentication of the Emergenc= y Status of SIP Calls
    -----------------------------------= ----------------------
    From last report, it was stated,
    "A lot of the discussions in t= he last few weeks focused on
    http://tools.ie= tf.org/wg/ecrit/draft-barnes-ecrit-auth-00.txt
    Action Item: Summary needs to be co= mpiled."

    Action: Need to determine next steps= .


    Overview of the IETF Emergency Servi= ces Architecture
    -----------------------------------= -----------------
    Restated from the last report:
    "The following document gives = an overview of the emergency services
    architecture:
    http://tools.ietf.org/wg/ecrit/draft-tschofenig-ecrit-architecture-ov= erview-00.txt

    It is meant to be read by members fr= om other SDOs and regulators."


    DSL Forum Documents
    -------------------

    The following referenced document we= re made available from the DSL Forum.  An initial review was made by H= annes Tschofenig, see:

    http://www1.= ietf.org/mail-archive/web/ecrit/current/msg04320.html

    Additional comments have been logged= to the list, see:
    http://www1.ie= tf.org/mail-archive/web/ecrit/current/mail3.html


    Alignment between IETF and 3GPP Emer= gency Services Architecture
    -----------------------------------= ----------------------------
    From the last report,
    "[Hannes]... has the action it= em to schedule a conference
    call within the IETF ECRIT WG and s= ubsequently between IETF ECRIT
    and the 3GPP to discuss a possible = alignment."


    3rd SDO Emergency Services Workshop<= /FONT>
    -----------------------------------=

    The next workshop (ESW03-07) is sche= duled for a 3 day meeting (October 30st -
    November 1st) in Brussels/Belgium (= 3 day mtg.).

    Meeting information can be found her= e:
    http://www.emergency= -services-coordination.info/2007Nov/

    A first version of the agenda is als= o available:
    https://lists.cs.columbia.edu/pipermail/es-coordination/2007-August/0000= 50.html

    Tuesday, October 30:
    --------

    Tutorials about IETF, 3GPP and NENA architectures
    u2010 meeting the standards

    Wednesday, October 31:
    ----------

    Policy Panel
    Status Updates
            *  IETF (GEOPRIV, ECRIT, SI= P)
            * DSL Forum
            * IEEE
            * ATIS-ESIF
            * NENA
            * ETSI EMTEL
            * 3GPP
            * 3GPP2
            * ETSI TISPAN
            * FCC
            * Open Mobile Alliance (OMA)
            * TIA
            * US Department of Transportation
            * OCG
            * EU Commission
            * Wimax Forum
            * WiFi Forum/Alliance
            * APCO Project 41
            * COMCAST
            * NIST

    Thursday, November 1:
    ---------

    Status Updates (con't)

    Authority-to-Citizen Communication
            Requirements
            What's available now




    ____________________________________= ___________
    Ecrit mailing list
    Ecrit@ietf.org
    https://www1.ietf.org/mailman/li= stinfo/ecrit

    Roger Marshall

     

    The information cont= ained in this message may be privileged and/or confidential. If you are not= the intended recipient, or responsible for delivering this message to the = intended recipient, any review, forwarding, dissemination, distribution or = copying of this communication or any attachment(s) is strictly prohibited. = If you have received this message in error, please so notify the sender imm= ediately, and delete it and all attachments from your computer and network.=

     

    ------_=_NextPart_001_01C7FFEE.1EB1B2F6-- --===============1039742622== 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 --===============1039742622==-- From ecrit-bounces@ietf.org Wed Sep 26 03:22:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaRE1-0006OE-Ld; Wed, 26 Sep 2007 03:22:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaRDz-0005zn-Bt for ecrit@ietf.org; Wed, 26 Sep 2007 03:22:23 -0400 Received: from demumfd001.nsn-inter.net ([217.115.75.233]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaRDx-0005iz-UW for ecrit@ietf.org; Wed, 26 Sep 2007 03:22:23 -0400 Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id l8Q7MGSn021274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Sep 2007 09:22:16 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id l8Q7MF6C030940; Wed, 26 Sep 2007 09:22:16 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 09:22:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: [ECRIT] wg Status Update - as of 9/25/07 Date: Wed, 26 Sep 2007 09:22:15 +0200 Message-ID: <5FB585F183235B42A9E70095055136FB32D2A5@DEMUEXC012.nsn-intra.net> In-Reply-To: <8C837214C95C864C9F34F3635C2A657508493B4B@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ECRIT] wg Status Update - as of 9/25/07 Thread-Index: Acf/7hanEIzVNJ6+Scu7yC4v+LsdbgAHzaQQ References: <8C837214C95C864C9F34F3635C2A657508493B4B@SEA-EXCHVS-2.telecomsys.com> From: "Tschofenig, Hannes (NSN - DE/Munich)" To: "ext Roger Marshall" , "ECRIT" , "Hannes Tschofenig" , "Marc Linsner" X-OriginalArrivalTime: 26 Sep 2007 07:22:16.0181 (UTC) FILETIME=[F730E250:01C8000D] X-Spam-Score: 0.0 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Roger,=20 =20 thanks a lot for the detailed status update. A minor issue on the emergency call marking. I believe we agreed on the approach described in this mail: http://www1.ietf.org/mail-archive/web/sip/current/msg20511.html Brian indicated that the resolution can also be found in the latest phone BCP draft version.=20 A related topic that is still under discussion is the question on how to prevent fraud in the context of location hiding.=20 Ciao Hannes ________________________________ Von: ext Roger Marshall [mailto:RMarshall@telecomsys.com]=20 Gesendet: Mittwoch, 26. September 2007 05:34 An: ECRIT; Hannes Tschofenig; Marc Linsner Betreff: [ECRIT] wg Status Update - as of 9/25/07 =09 =09 ECRIT WG Status Update - Sept 2007=20 = =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=20 Upcoming IETF Meeting=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 The next ECRIT (IETF70) meeting is scheduled for Dec 2-7, Vancouver B.C. See:=20 http://www3.ietf.org/meetings/70-IETF.html =20 Other information:=20 There is a new Web-based tool that can be used now to submit a new draft, see:=20 =09 http://www1.ietf.org/mail-archive/web/ecrit/current/msg04384.html =20 The meeting minutes from the last IETF69 are here:=20 http://www3.ietf.org/proceedings/07jul/minutes/ecrit.txt =20 In addition, there is some progress on some of the wg related documents.=20 Prior status reports are posted to the ECRIT WG status site. See: http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/EcritStatusUp date =20 Document Status=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 In the RFC Editor's Queue=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =20 Requirements for Emergency Context Resolution with Internet Technologies=20 =09 ------------------------------------------------------------------------ Draft is moving through the "RFC Ed Queue" - seems close to being published:=20 =09 http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-13.txt =20 A Uniform Resource Name (URN) for Services=20 ------------------------------------------=20 Draft has moved to the "RFC Ed Queue" as of 8/21/07:=20 =09 http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service-ur n-07.txt =20 Security Threats and Requirements for Emergency Call Marking and Mapping=20 =09 ------------------------------------------------------------------------ The new (-05) Draft version has moved to the "RFC Ed Queue" as of 9/12/07.=20 =09 http://www.ietf.org/internet-drafts/draft-ietf-ecrit-security-threats-05 .txt =20 PROTO Documents=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 The document shepherding process is described in:=20 =09 http://tools.ietf.org/id/draft-ietf-proto-wgchair-doc-shepherding-07.txt =20 LoST: A Location-to-Service Translation Protocol=20 ------------------------------------------------=20 PROTO writeup has been sent to the Area Directors and the IESG to complete the work.=20 http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-06.txt =20 Location-to-URL Mapping Architecture and Framework=20 --------------------------------------------------=20 PROTO WRITEUP has been sent to the Area Directors and the IESG to complete work.=20 =09 http://www.ietf.org/internet-drafts/draft-ietf-ecrit-mapping-arch-02.txt =20 A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure=20 =09 ----------------------------------------------------------------------=20 PROTO WRITEUP has been sent to the Area Directors and the IESG to complete work.=20 =09 http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery- 02.txt =20 Other WG Drafts=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 The (two) remaining ECRIT WG Drafts, below, have been updated.=20 Framework for Emergency Calling using Internet Multimedia=20 ---------------------------------------------------------=20 New Draft version published as of 9/19/07. Needs additional WG review.=20 =09 http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-03.txt Best Current Practice for Communications Services in support of Emergency Calling=20 =09 ------------------------------------------------------------------------ ---------=20 New Draft version published as of 9/19/07. Needs additional WG review.=20 =09 http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-02.txt =20 Individual Drafts=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Location Hiding: Problem Statement and Requirements=20 ---------------------------------------------------=20 An updated draft has been produced, see:=20 =09 http://tools.ietf.org/wg/ecrit/draft-schulzrinne-ecrit-location-hiding-r equirements-01.txt =20 Last action on this was: "Initiate discussion after the main WG items have been progressed."=20 Action: ECRIT chairs to determine level of effort, since other items now progressed.=20 Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices=20 =09 ------------------------------------------------------------------------ --------------=20 Initial draft version has been submitted.=20 =09 http://tools.ietf.org/wg/ecrit/draft-schulzrinne-ecrit-unauthenticated-a ccess-00.txt =20 There is a IEEE liaison msg. which references the above draft, see:=20 =09 http://www1.ietf.org/mail-archive/web/ecrit/current/msg04361.html =20 Emergency Call Marking=20 ----------------------=20 From last report, it was stated:=20 "The initially assumed solution,=20 =09 http://tools.ietf.org/wg/sip/draft-rosenberg-sip-ua-loose-route-01.txt ,=20 was not accepted at the IETF meeting."=20 Some discussion has taken place entitled "UA Loose Routing", see:=20 =09 http://www1.ietf.org/mail-archive/web/ecrit/current/msg04308.html =20 And "call marking", see:=20 =09 http://www1.ietf.org/mail-archive/web/ecrit/current/msg04310.html =20 Which Richard reintroduced, and which there appears to be no common resolution for yet, see Brian's response on probable action by most proxies, see: =09 http://www1.ietf.org/mail-archive/web/ecrit/current/msg04319.html =20 Proxy Authentication of the Emergency Status of SIP Calls=20 ---------------------------------------------------------=20 From last report, it was stated,=20 "A lot of the discussions in the last few weeks focused on=20 http://tools.ietf.org/wg/ecrit/draft-barnes-ecrit-auth-00.txt =20 Action Item: Summary needs to be compiled."=20 Action: Need to determine next steps.=20 Overview of the IETF Emergency Services Architecture=20 ----------------------------------------------------=20 Restated from the last report:=20 "The following document gives an overview of the emergency services=20 architecture:=20 =09 http://tools.ietf.org/wg/ecrit/draft-tschofenig-ecrit-architecture-overv iew-00.txt =20 It is meant to be read by members from other SDOs and regulators."=20 DSL Forum Documents=20 -------------------=20 The following referenced document were made available from the DSL Forum. An initial review was made by Hannes Tschofenig, see: =09 http://www1.ietf.org/mail-archive/web/ecrit/current/msg04320.html =20 Additional comments have been logged to the list, see:=20 http://www1.ietf.org/mail-archive/web/ecrit/current/mail3.html =20 Alignment between IETF and 3GPP Emergency Services Architecture=20 ---------------------------------------------------------------=20 From the last report,=20 "[Hannes]... has the action item to schedule a conference=20 call within the IETF ECRIT WG and subsequently between IETF ECRIT=20 and the 3GPP to discuss a possible alignment."=20 3rd SDO Emergency Services Workshop=20 -----------------------------------=20 The next workshop (ESW03-07) is scheduled for a 3 day meeting (October 30st -=20 November 1st) in Brussels/Belgium (3 day mtg.).=20 Meeting information can be found here:=20 http://www.emergency-services-coordination.info/2007Nov/ =20 A first version of the agenda is also available:=20 =09 https://lists.cs.columbia.edu/pipermail/es-coordination/2007-August/0000 50.html =20 Tuesday, October 30: -------- =09 Tutorials about IETF, 3GPP and NENA architectures =09 u2010 meeting the standards =09 Wednesday, October 31: ---------- =09 Policy Panel =09 Status Updates * IETF (GEOPRIV, ECRIT, SIP) * DSL Forum * IEEE * ATIS-ESIF * NENA * ETSI EMTEL * 3GPP * 3GPP2 * ETSI TISPAN * FCC * Open Mobile Alliance (OMA) * TIA * US Department of Transportation * OCG * EU Commission * Wimax Forum * WiFi Forum/Alliance * APCO Project 41 * COMCAST * NIST =09 Thursday, November 1: --------- =09 Status Updates (con't) =09 Authority-to-Citizen Communication Requirements What's available now=20 _______________________________________________=20 Ecrit mailing list=20 Ecrit@ietf.org=20 https://www1.ietf.org/mailman/listinfo/ecrit =20 Roger Marshall=20 =20 The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 26 08:23:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaVu2-0002oi-DR; Wed, 26 Sep 2007 08:22:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaVtz-0002lE-4f for ecrit@ietf.org; Wed, 26 Sep 2007 08:22:03 -0400 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 1IaVtq-0000RI-2y for ecrit@ietf.org; Wed, 26 Sep 2007 08:22:03 -0400 X-IronPort-AV: E=Sophos;i="4.20,301,1186383600"; d="scan'208,217";a="20058539" Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-1.cisco.com with ESMTP; 26 Sep 2007 05:21:48 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l8QCLmtV026030; Wed, 26 Sep 2007 05:21:48 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8QCLRWY003928; Wed, 26 Sep 2007 12:21:39 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 08:21:30 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 08:21:29 -0400 From: "Marc Linsner" To: "'Roger Marshall'" , "'ECRIT'" , "'Hannes Tschofenig'" Subject: RE: [ECRIT] wg Status Update - as of 9/25/07 Date: Wed, 26 Sep 2007 08:21:28 -0400 Message-ID: <00a001c80037$c43ca850$220d0d0a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <8C837214C95C864C9F34F3635C2A657508493B4B@SEA-EXCHVS-2.telecomsys.com> Thread-Index: Acf/7hanEIzVNJ6+Scu7yC4v+LsdbgASXyLA X-OriginalArrivalTime: 26 Sep 2007 12:21:30.0517 (UTC) FILETIME=[C4CF2450:01C80037] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2843; t=1190809308; x=1191673308; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[ECRIT]=20wg=20Status=20Update=20-=20as=20of=209/25/0 7 |Sender:=20; bh=6tVoZdzeduOHZLINXD2ilCvmhJKsLGp3yGQwJQsgCno=; b=auGOxVA05e2nUIGfwliEq9DZBGloqtVifHaqjUjVBaBpffiNvUfANQDabcYl4Xdh/+hPMmb0 AQ7F8ifeaekqRYbbofcLW+2SsyHMfb6xCtVlfWn5AK7Fi+X2gxBnw24f; Authentication-Results: sj-dkim-7; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0253125760==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0253125760== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A1_01C80016.3D2FEA50" This is a multi-part message in MIME format. ------=_NextPart_000_00A1_01C80016.3D2FEA50 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Roger, Thanks for the update. PROTO Documents =============== The document shepherding process is described in: http://tools.ietf.org/id/draft-ietf-proto-wgchair-doc-shepherding-07.txt Just a small nit....I believe this draft is now RFC4858. -Marc- ------=_NextPart_000_00A1_01C80016.3D2FEA50 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable [ECRIT] wg Status Update - as of 9/25/07
    Roger,
     
    Thanks for the update.
     
     

    PROTO Documents =
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

    The document shepherding = process is=20 described in:
    http://tools.ietf.org/id/draft-ietf-proto-wgchair-doc-shepherdin= g-07.txt    =20


     
    Just a small nit....I believe this draft is now=20 RFC4858.
     
    -Marc- 
    ------=_NextPart_000_00A1_01C80016.3D2FEA50-- --===============0253125760== 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 --===============0253125760==-- From ecrit-bounces@ietf.org Wed Sep 26 09:38:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaX4x-0008SJ-AO; Wed, 26 Sep 2007 09:37:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaX4w-0008S9-43 for ecrit@ietf.org; Wed, 26 Sep 2007 09:37:26 -0400 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaX4p-0002AZ-PY for ecrit@ietf.org; Wed, 26 Sep 2007 09:37:26 -0400 Received: by nf-out-0910.google.com with SMTP id d21so1634037nfb for ; Wed, 26 Sep 2007 06:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=QFdZyAYdBCFge5ZJ5mmlGYbRjQgoZNk3TUkJEkTxPKk=; b=L1W4UcG7w+eCXWjKIffIKBgDf2KhqTB4FpiXORD6c2cmq3ctRIWpRmmtfzU7BvOoIcohVQSHqerY/G/nrW9D9TCtU6dnLkyzmBb8MxLD++HJ0rdS7ZadRDmrGApiEgwixKX6002oiNZYIWJJb+QJLjW1e5fwrxZtLJFIbNk/7Oo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=twAkn/pGZHN7ApxKcx6E8Hj2WIM5ZGIyuiVqfn+4P/aP8ISLjvFWMC26MnMgEUlmZqimv/AQQXZ2gV+ehk/DV2xJ4d/czIXUCVkshqzkM+PLIQKqFKTfTdGoWo3ebuYa6NKGRqo3vkVTrhU09h0ia2KcgrS7+l2e0vNrywJ9zqA= Received: by 10.82.114.3 with SMTP id m3mr1513377buc.1190813827527; Wed, 26 Sep 2007 06:37:07 -0700 (PDT) Received: by 10.82.165.16 with HTTP; Wed, 26 Sep 2007 06:37:07 -0700 (PDT) Message-ID: Date: Wed, 26 Sep 2007 15:37:07 +0200 From: "Karl Heinz Wolf" To: "Stark, Barbara" Subject: Re: [Ecrit] multiple location sources In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA05C401AE@crexc41p> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7582BC68E4994F4ABF0BD4723975C3FA05C401AE@crexc41p> X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: ecrit X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Thank you Barbara, for these useful documents from the DSL forum. I haven't read everything, but just two small comments so far: In Appendix A, Flow A, there is a line missing. "Was location in DHCP response" has no "No" branching. It should connect to "Determine LIS", I would suggest. Concerning Manual Configuration of Location Information: you use manual configuration only in case no other location determination was successful. This is different to draft-ietf-geopriv-pdif-lo-profile-08, I think. If I understand Section 3.3. correctly, a separate PIDF document would be created containing the manual configuration even if automatic configuration was successful. karl heinz On 9/24/07, Stark, Barbara wrote: > Some of these are questions I was trying to address in the draft > document liaised from the DSL Forum to IETF > (see http://www1.ietf.org/mail-archive/web/geopriv/current/msg04297.html > for link to documents), because I hadn't seen them addressed elsewhere. > I'd be curious to hear if you find the flows in that document at all > useful. I suggest in there that, in the absence of real intelligence for > selecting one location from multiple, that locations received from lower > layers should be given preference over locations received from higher > layers. When multiple locations are received using the same protocol, > then the first received should be used. But this is for a particular > physical interface. > > In the case of multiple physical interfaces, I suggest that the device > should keep its location per physical interface. A call that goes out > over a particular interface, should use the location associated with > that interface. > > Again, this is suggested for the case where there is nothing on which to > base an informed decision. > Barbara > > -----Original Message----- > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > Sent: Monday, September 24, 2007 5:49 AM > To: ecrit > Subject: [Ecrit] multiple location sources > > Hi, > I'm working on a prototype SIP client that should be able to determine > its location by DHCP, HELD and LLDP-MED. The PIDF-LO document is > included in the SIP INVITE body. I have several questions about what > to do when there is more than one location source available. > > draft-ietf-sip-location-conveyance-08 recommends that there is only > one location. Of course, all ways of location determination should > give the same location. But how can one verify if the same location > was received via HELD and DHCP since a different format is used? > > Or when one gets two DHCP civic location messages via two different > interfaces and some of the CAvalues are the same, but some not (e.g. > one has an additional location information, the other has a building > CAType). Is this the same location? > > Or think of the following situation. One gets a DHCP location > information via a wired connection (the location of the DHCP server in > this building) and a LLDP-MED frame via WLAN of an access point in the > next building (the location of the access point is announced). > draft-ietf-geopriv-pdif-lo-profile-08 gives some rules for multiple > location information, but how can the device know which information is > more adequate to get the right order? > > rfc4776 has a table with a mapping of CATypes and PIDF. When conveying > location information in SIP messages, a PIDF document is needed. So, > what to do with CATypes that have no mapping to PIDF? > > LLDP-MED has a "what" element, describing if the location of the > client itself, of the DHCP server or of the network element closest to > the client is provided. This seems to be useful information, but where > to put this in a PIDF document? > > I'm looking forward to your comments and suggestions. > > Ciao > Karl Heinz > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > ***** > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 26 09:50:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXHW-0001AN-Pq; Wed, 26 Sep 2007 09:50:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXHW-0001AF-Fo for ecrit@ietf.org; Wed, 26 Sep 2007 09:50:26 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaXHQ-0002Rw-7X for ecrit@ietf.org; Wed, 26 Sep 2007 09:50:26 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IaXHB-0000TL-P1; Wed, 26 Sep 2007 08:50:06 -0500 From: "Brian Rosen" To: "'Karl Heinz Wolf'" , "'Stark, Barbara'" References: <7582BC68E4994F4ABF0BD4723975C3FA05C401AE@crexc41p> Subject: RE: [Ecrit] multiple location sources Date: Wed, 26 Sep 2007 09:50:10 -0400 Message-ID: <01a101c80044$2994e8a0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcgAQn58Z1wcYtysRTyWRBvQuJbXyQAAFcIA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: 'ecrit' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Concerning manual location: If a subscriber says he is at "X" and the carrier thinks the demark point is "Y", you better route the call on and send "X". You probably want to send "Y" also. That mirrors what PSAPs do. Brian > -----Original Message----- > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > Sent: Wednesday, September 26, 2007 9:37 AM > To: Stark, Barbara > Cc: ecrit > Subject: Re: [Ecrit] multiple location sources > > Thank you Barbara, for these useful documents from the DSL forum. > I haven't read everything, but just two small comments so far: > > In Appendix A, Flow A, there is a line missing. "Was location in DHCP > response" has no "No" branching. It should connect to "Determine LIS", > I would suggest. > > Concerning Manual Configuration of Location Information: you use > manual configuration only in case no other location determination was > successful. This is different to > draft-ietf-geopriv-pdif-lo-profile-08, I think. If I understand > Section 3.3. correctly, a separate PIDF document would be created > containing the manual configuration even if automatic configuration > was successful. > > karl heinz > > > On 9/24/07, Stark, Barbara wrote: > > Some of these are questions I was trying to address in the draft > > document liaised from the DSL Forum to IETF > > (see http://www1.ietf.org/mail-archive/web/geopriv/current/msg04297.html > > for link to documents), because I hadn't seen them addressed elsewhere. > > I'd be curious to hear if you find the flows in that document at all > > useful. I suggest in there that, in the absence of real intelligence for > > selecting one location from multiple, that locations received from lower > > layers should be given preference over locations received from higher > > layers. When multiple locations are received using the same protocol, > > then the first received should be used. But this is for a particular > > physical interface. > > > > In the case of multiple physical interfaces, I suggest that the device > > should keep its location per physical interface. A call that goes out > > over a particular interface, should use the location associated with > > that interface. > > > > Again, this is suggested for the case where there is nothing on which to > > base an informed decision. > > Barbara > > > > -----Original Message----- > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > Sent: Monday, September 24, 2007 5:49 AM > > To: ecrit > > Subject: [Ecrit] multiple location sources > > > > Hi, > > I'm working on a prototype SIP client that should be able to determine > > its location by DHCP, HELD and LLDP-MED. The PIDF-LO document is > > included in the SIP INVITE body. I have several questions about what > > to do when there is more than one location source available. > > > > draft-ietf-sip-location-conveyance-08 recommends that there is only > > one location. Of course, all ways of location determination should > > give the same location. But how can one verify if the same location > > was received via HELD and DHCP since a different format is used? > > > > Or when one gets two DHCP civic location messages via two different > > interfaces and some of the CAvalues are the same, but some not (e.g. > > one has an additional location information, the other has a building > > CAType). Is this the same location? > > > > Or think of the following situation. One gets a DHCP location > > information via a wired connection (the location of the DHCP server in > > this building) and a LLDP-MED frame via WLAN of an access point in the > > next building (the location of the access point is announced). > > draft-ietf-geopriv-pdif-lo-profile-08 gives some rules for multiple > > location information, but how can the device know which information is > > more adequate to get the right order? > > > > rfc4776 has a table with a mapping of CATypes and PIDF. When conveying > > location information in SIP messages, a PIDF document is needed. So, > > what to do with CATypes that have no mapping to PIDF? > > > > LLDP-MED has a "what" element, describing if the location of the > > client itself, of the DHCP server or of the network element closest to > > the client is provided. This seems to be useful information, but where > > to put this in a PIDF document? > > > > I'm looking forward to your comments and suggestions. > > > > Ciao > > Karl Heinz > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > ***** > > > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential, proprietary, and/or > privileged material. Any review, retransmission, dissemination or other > use of, or taking of any action in reliance upon this information by > persons or entities other than the intended recipient is prohibited. If > you received this in error, please contact the sender and delete the > material from all computers. GA621 > > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 26 10:02:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXS9-0007rW-AS; Wed, 26 Sep 2007 10:01:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXS7-0007qU-Ca for ecrit@ietf.org; Wed, 26 Sep 2007 10:01:23 -0400 Received: from bellwecs2.srvr.bell.ca ([207.236.237.114]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IaXS6-0007zf-H8 for ecrit@ietf.org; Wed, 26 Sep 2007 10:01:23 -0400 Received: (qmail 7750 invoked from network); 26 Sep 2007 14:01:20 -0000 Received: from g.caron@bell.ca by bellwecs2.srvr.bell.ca with EntrustECS-Server-7.4; 26 Sep 2007 14:01:20 -0000 Received: from bellwfep3.bellnexxia.net (HELO bellwfep3-srv.bellnexxia.net) (207.236.237.109) by bellwecs2.srvr.bell.ca with SMTP; 26 Sep 2007 14:01:19 -0000 Received: from toroondc550.bell.corp.bce.ca ([142.182.84.162]) by bellwfep3-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20070926135842.KBOP1679.bellwfep3-srv.bellnexxia.net@toroondc550.bell.corp.bce.ca>; Wed, 26 Sep 2007 09:58:42 -0400 Received: from toroondc912.bell.corp.bce.ca ([142.182.89.15]) by toroondc550.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 10:01:10 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] multiple location sources Date: Wed, 26 Sep 2007 10:01:09 -0400 Message-ID: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30B54BBFA@toroondc912> In-Reply-To: <01a101c80044$2994e8a0$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] multiple location sources Thread-Index: AcgAQn58Z1wcYtysRTyWRBvQuJbXyQAAFcIAAACA+1A= References: <7582BC68E4994F4ABF0BD4723975C3FA05C401AE@crexc41p> <01a101c80044$2994e8a0$640fa8c0@cis.neustar.com> From: To: , , X-OriginalArrivalTime: 26 Sep 2007 14:01:10.0804 (UTC) FILETIME=[B1568540:01C80045] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 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 disagree in the context of ES. The reverse should be done (route on Y and maybe send X as long as there = is a mechanism to help the PSAP interpreting this situation) and let the = call taker confirm the information through interaction with the caller. = This is how it works today. Guy Caron -----Message d'origine----- De=A0: Brian Rosen [mailto:br@brianrosen.net]=20 Envoy=E9=A0: 26 septembre 2007 09:50 =C0=A0: 'Karl Heinz Wolf'; 'Stark, Barbara' Cc=A0: 'ecrit' Objet=A0: RE: [Ecrit] multiple location sources Concerning manual location: If a subscriber says he is at "X" and the carrier thinks the demark = point is "Y", you better route the call on and send "X". You probably want to = send "Y" also. That mirrors what PSAPs do. =20 Brian > -----Original Message----- > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > Sent: Wednesday, September 26, 2007 9:37 AM > To: Stark, Barbara > Cc: ecrit > Subject: Re: [Ecrit] multiple location sources >=20 > Thank you Barbara, for these useful documents from the DSL forum. > I haven't read everything, but just two small comments so far: >=20 > In Appendix A, Flow A, there is a line missing. "Was location in DHCP > response" has no "No" branching. It should connect to "Determine LIS", > I would suggest. >=20 > Concerning Manual Configuration of Location Information: you use > manual configuration only in case no other location determination was > successful. This is different to > draft-ietf-geopriv-pdif-lo-profile-08, I think. If I understand > Section 3.3. correctly, a separate PIDF document would be created > containing the manual configuration even if automatic configuration > was successful. >=20 > karl heinz >=20 >=20 > On 9/24/07, Stark, Barbara wrote: > > Some of these are questions I was trying to address in the draft > > document liaised from the DSL Forum to IETF > > (see = http://www1.ietf.org/mail-archive/web/geopriv/current/msg04297.html > > for link to documents), because I hadn't seen them addressed = elsewhere. > > I'd be curious to hear if you find the flows in that document at all > > useful. I suggest in there that, in the absence of real intelligence = for > > selecting one location from multiple, that locations received from = lower > > layers should be given preference over locations received from = higher > > layers. When multiple locations are received using the same = protocol, > > then the first received should be used. But this is for a particular > > physical interface. > > > > In the case of multiple physical interfaces, I suggest that the = device > > should keep its location per physical interface. A call that goes = out > > over a particular interface, should use the location associated with > > that interface. > > > > Again, this is suggested for the case where there is nothing on = which to > > base an informed decision. > > Barbara > > > > -----Original Message----- > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > Sent: Monday, September 24, 2007 5:49 AM > > To: ecrit > > Subject: [Ecrit] multiple location sources > > > > Hi, > > I'm working on a prototype SIP client that should be able to = determine > > its location by DHCP, HELD and LLDP-MED. The PIDF-LO document is > > included in the SIP INVITE body. I have several questions about what > > to do when there is more than one location source available. > > > > draft-ietf-sip-location-conveyance-08 recommends that there is only > > one location. Of course, all ways of location determination should > > give the same location. But how can one verify if the same location > > was received via HELD and DHCP since a different format is used? > > > > Or when one gets two DHCP civic location messages via two different > > interfaces and some of the CAvalues are the same, but some not (e.g. > > one has an additional location information, the other has a building > > CAType). Is this the same location? > > > > Or think of the following situation. One gets a DHCP location > > information via a wired connection (the location of the DHCP server = in > > this building) and a LLDP-MED frame via WLAN of an access point in = the > > next building (the location of the access point is announced). > > draft-ietf-geopriv-pdif-lo-profile-08 gives some rules for multiple > > location information, but how can the device know which information = is > > more adequate to get the right order? > > > > rfc4776 has a table with a mapping of CATypes and PIDF. When = conveying > > location information in SIP messages, a PIDF document is needed. So, > > what to do with CATypes that have no mapping to PIDF? > > > > LLDP-MED has a "what" element, describing if the location of the > > client itself, of the DHCP server or of the network element closest = to > > the client is provided. This seems to be useful information, but = where > > to put this in a PIDF document? > > > > I'm looking forward to your comments and suggestions. > > > > Ciao > > Karl Heinz > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > ***** > > > > The information transmitted is intended only for the person or = entity to > which it is addressed and may contain confidential, proprietary, = and/or > privileged material. Any review, retransmission, dissemination or = other > use of, or taking of any action in reliance upon this information by > persons or entities other than the intended recipient is prohibited. = If > you received this in error, please contact the sender and delete the > material from all computers. GA621 > > > > > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 26 10:23:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXms-0002ow-41; Wed, 26 Sep 2007 10:22:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaXmq-0002mG-Dp for ecrit@ietf.org; Wed, 26 Sep 2007 10:22:48 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaXmp-0000Dc-E7 for ecrit@ietf.org; Wed, 26 Sep 2007 10:22:48 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IaXmg-00061D-5B; Wed, 26 Sep 2007 09:22:38 -0500 From: "Brian Rosen" To: , , References: <7582BC68E4994F4ABF0BD4723975C3FA05C401AE@crexc41p> <01a101c80044$2994e8a0$640fa8c0@cis.neustar.com> <2E62ACF8ADDB4D4F89093CBFDF2FBAF30B54BBFA@toroondc912> Subject: RE: [Ecrit] multiple location sources Date: Wed, 26 Sep 2007 10:22:43 -0400 Message-ID: <01ad01c80048$b5855a80$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30B54BBFA@toroondc912> Thread-Index: AcgAQn58Z1wcYtysRTyWRBvQuJbXyQAAFcIAAACA+1AAAGXl0A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d 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 Well, in the sense that today, there is no way for a subscriber to tell = a carrier that the location is X and not Y, you are correct. Imagine the following scenario: I have a family compound. It has 4 houses in 30 acres. We pay for a = single high speed Internet connection, and order 4 VoIP "lines", one for each = house with a LAN between the houses. To the carrier, there is one demarc = point, and one address for all four "lines". I come to you and say "If anyone calls from Line 1, the location is X1, line 2 is X2, ... I know someone = who has a set-up like this now. What will you do? If you behave like you do today, you will always send = Y and that=92s it. I won't speak for Canadians, but in the U.S, if you got a request like = that and a 9-1-1 call was sent to Y, you would likely not have a problem. However, if the subscriber told you again, and the next 9-1-1 call was = sent to Y, you would be in serious trouble (this happened recently, although = it was a simple data entry problem and not a = subscriber-knows-more-than-carrier problem). =20 You must have a manual method, and if the subscriber insists he is at X, = you MUST route on X. A difference between demarc and actual location is way = too easy to be significant these days. In the PSAP itself, the way this plays out is that you say you are at X, = and the ALI says you are at Y. The response goes to X. Always. The PSAP = never gets in trouble sending people to X. If they sent response only to Y, = it could be very bad news. If the caller actually was at Y, and they send responders to X, there would be no problem as long as the tape showed = they asked the guy the right questions. If the caller was an X and they send response to Y, they would be in big trouble. You always believe the = caller. You may question him carefully (which is why sending Y is a good idea), = but you respond to X. Brian > -----Original Message----- > From: g.caron@bell.ca [mailto:g.caron@bell.ca] > Sent: Wednesday, September 26, 2007 10:01 AM > To: br@brianrosen.net; khwolf1@gmail.com; bs7652@att.com > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] multiple location sources >=20 > I disagree in the context of ES. >=20 > The reverse should be done (route on Y and maybe send X as long as = there > is a mechanism to help the PSAP interpreting this situation) and let = the > call taker confirm the information through interaction with the = caller. > This is how it works today. >=20 > Guy Caron > -----Message d'origine----- > De=A0: Brian Rosen [mailto:br@brianrosen.net] > Envoy=E9=A0: 26 septembre 2007 09:50 > =C0=A0: 'Karl Heinz Wolf'; 'Stark, Barbara' > Cc=A0: 'ecrit' > Objet=A0: RE: [Ecrit] multiple location sources >=20 > Concerning manual location: >=20 > If a subscriber says he is at "X" and the carrier thinks the demark = point > is > "Y", you better route the call on and send "X". You probably want to = send > "Y" also. That mirrors what PSAPs do. >=20 > Brian >=20 > > -----Original Message----- > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > Sent: Wednesday, September 26, 2007 9:37 AM > > To: Stark, Barbara > > Cc: ecrit > > Subject: Re: [Ecrit] multiple location sources > > > > Thank you Barbara, for these useful documents from the DSL forum. > > I haven't read everything, but just two small comments so far: > > > > In Appendix A, Flow A, there is a line missing. "Was location in = DHCP > > response" has no "No" branching. It should connect to "Determine = LIS", > > I would suggest. > > > > Concerning Manual Configuration of Location Information: you use > > manual configuration only in case no other location determination = was > > successful. This is different to > > draft-ietf-geopriv-pdif-lo-profile-08, I think. If I understand > > Section 3.3. correctly, a separate PIDF document would be created > > containing the manual configuration even if automatic configuration > > was successful. > > > > karl heinz > > > > > > On 9/24/07, Stark, Barbara wrote: > > > Some of these are questions I was trying to address in the draft > > > document liaised from the DSL Forum to IETF > > > (see http://www1.ietf.org/mail- > archive/web/geopriv/current/msg04297.html > > > for link to documents), because I hadn't seen them addressed > elsewhere. > > > I'd be curious to hear if you find the flows in that document at = all > > > useful. I suggest in there that, in the absence of real = intelligence > for > > > selecting one location from multiple, that locations received from > lower > > > layers should be given preference over locations received from = higher > > > layers. When multiple locations are received using the same = protocol, > > > then the first received should be used. But this is for a = particular > > > physical interface. > > > > > > In the case of multiple physical interfaces, I suggest that the = device > > > should keep its location per physical interface. A call that goes = out > > > over a particular interface, should use the location associated = with > > > that interface. > > > > > > Again, this is suggested for the case where there is nothing on = which > to > > > base an informed decision. > > > Barbara > > > > > > -----Original Message----- > > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > > Sent: Monday, September 24, 2007 5:49 AM > > > To: ecrit > > > Subject: [Ecrit] multiple location sources > > > > > > Hi, > > > I'm working on a prototype SIP client that should be able to = determine > > > its location by DHCP, HELD and LLDP-MED. The PIDF-LO document is > > > included in the SIP INVITE body. I have several questions about = what > > > to do when there is more than one location source available. > > > > > > draft-ietf-sip-location-conveyance-08 recommends that there is = only > > > one location. Of course, all ways of location determination should > > > give the same location. But how can one verify if the same = location > > > was received via HELD and DHCP since a different format is used? > > > > > > Or when one gets two DHCP civic location messages via two = different > > > interfaces and some of the CAvalues are the same, but some not = (e.g. > > > one has an additional location information, the other has a = building > > > CAType). Is this the same location? > > > > > > Or think of the following situation. One gets a DHCP location > > > information via a wired connection (the location of the DHCP = server in > > > this building) and a LLDP-MED frame via WLAN of an access point in = the > > > next building (the location of the access point is announced). > > > draft-ietf-geopriv-pdif-lo-profile-08 gives some rules for = multiple > > > location information, but how can the device know which = information is > > > more adequate to get the right order? > > > > > > rfc4776 has a table with a mapping of CATypes and PIDF. When = conveying > > > location information in SIP messages, a PIDF document is needed. = So, > > > what to do with CATypes that have no mapping to PIDF? > > > > > > LLDP-MED has a "what" element, describing if the location of the > > > client itself, of the DHCP server or of the network element = closest to > > > the client is provided. This seems to be useful information, but = where > > > to put this in a PIDF document? > > > > > > I'm looking forward to your comments and suggestions. > > > > > > Ciao > > > Karl Heinz > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > ***** > > > > > > The information transmitted is intended only for the person or = entity > to > > which it is addressed and may contain confidential, proprietary, = and/or > > privileged material. Any review, retransmission, dissemination or = other > > use of, or taking of any action in reliance upon this information by > > persons or entities other than the intended recipient is prohibited. = If > > you received this in error, please contact the sender and delete the > > material from all computers. GA621 > > > > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 26 10:54:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaYHO-0006Ig-8D; Wed, 26 Sep 2007 10:54:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaYHM-00064k-HO for ecrit@ietf.org; Wed, 26 Sep 2007 10:54:20 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaYH7-00047I-JH for ecrit@ietf.org; Wed, 26 Sep 2007 10:54:11 -0400 Received: from ([139.76.131.31]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.30249478; Wed, 26 Sep 2007 10:53:29 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 26 Sep 2007 10:53:29 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 26 Sep 2007 10:53:29 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929 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] multiple location sources Date: Wed, 26 Sep 2007 10:53:28 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA05C406DF@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] multiple location sources thread-index: AcgAQnP1P/UqNEIoQwOiggsEsvn85wAAml7Q References: <7582BC68E4994F4ABF0BD4723975C3FA05C401AE@crexc41p> From: "Stark, Barbara" To: "Karl Heinz Wolf" X-OriginalArrivalTime: 26 Sep 2007 14:53:29.0430 (UTC) FILETIME=[001AD760:01C8004D] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: ecrit X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Karl Heinz, Thanks for your feedback. I'll fix the DHCP response "No" branch in my next version. As for the manual configuration comment -- I didn't read pidf-lo-profile-08 Section 3.3 as recommending that the manual config necessarily be included. It's a good question, though, and I think you've done a great job at starting discussion on this on the list. Barbara=20 -----Original Message----- From: Karl Heinz Wolf [mailto:khwolf1@gmail.com]=20 Sent: Wednesday, September 26, 2007 9:37 AM To: Stark, Barbara Cc: ecrit Subject: Re: [Ecrit] multiple location sources Thank you Barbara, for these useful documents from the DSL forum. I haven't read everything, but just two small comments so far: In Appendix A, Flow A, there is a line missing. "Was location in DHCP response" has no "No" branching. It should connect to "Determine LIS", I would suggest. Concerning Manual Configuration of Location Information: you use manual configuration only in case no other location determination was successful. This is different to draft-ietf-geopriv-pdif-lo-profile-08, I think. If I understand Section 3.3. correctly, a separate PIDF document would be created containing the manual configuration even if automatic configuration was successful. karl heinz On 9/24/07, Stark, Barbara wrote: > Some of these are questions I was trying to address in the draft > document liaised from the DSL Forum to IETF > (see http://www1.ietf.org/mail-archive/web/geopriv/current/msg04297.html > for link to documents), because I hadn't seen them addressed elsewhere. > I'd be curious to hear if you find the flows in that document at all > useful. I suggest in there that, in the absence of real intelligence for > selecting one location from multiple, that locations received from lower > layers should be given preference over locations received from higher > layers. When multiple locations are received using the same protocol, > then the first received should be used. But this is for a particular > physical interface. > > In the case of multiple physical interfaces, I suggest that the device > should keep its location per physical interface. A call that goes out > over a particular interface, should use the location associated with > that interface. > > Again, this is suggested for the case where there is nothing on which to > base an informed decision. > Barbara > > -----Original Message----- > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > Sent: Monday, September 24, 2007 5:49 AM > To: ecrit > Subject: [Ecrit] multiple location sources > > Hi, > I'm working on a prototype SIP client that should be able to determine > its location by DHCP, HELD and LLDP-MED. The PIDF-LO document is > included in the SIP INVITE body. I have several questions about what > to do when there is more than one location source available. > > draft-ietf-sip-location-conveyance-08 recommends that there is only > one location. Of course, all ways of location determination should > give the same location. But how can one verify if the same location > was received via HELD and DHCP since a different format is used? > > Or when one gets two DHCP civic location messages via two different > interfaces and some of the CAvalues are the same, but some not (e.g. > one has an additional location information, the other has a building > CAType). Is this the same location? > > Or think of the following situation. One gets a DHCP location > information via a wired connection (the location of the DHCP server in > this building) and a LLDP-MED frame via WLAN of an access point in the > next building (the location of the access point is announced). > draft-ietf-geopriv-pdif-lo-profile-08 gives some rules for multiple > location information, but how can the device know which information is > more adequate to get the right order? > > rfc4776 has a table with a mapping of CATypes and PIDF. When conveying > location information in SIP messages, a PIDF document is needed. So, > what to do with CATypes that have no mapping to PIDF? > > LLDP-MED has a "what" element, describing if the location of the > client itself, of the DHCP server or of the network element closest to > the client is provided. This seems to be useful information, but where > to put this in a PIDF document? > > I'm looking forward to your comments and suggestions. > > Ciao > Karl Heinz > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > ***** > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 > > > ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA625 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 26 11:08:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaYUy-0000sD-ED; Wed, 26 Sep 2007 11:08:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaYUx-0000s8-RV for ecrit@ietf.org; Wed, 26 Sep 2007 11:08:23 -0400 Received: from bellwecs2.srvr.bell.ca ([207.236.237.114]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IaYUw-0004TI-Fv for ecrit@ietf.org; Wed, 26 Sep 2007 11:08:23 -0400 Received: (qmail 25897 invoked from network); 26 Sep 2007 15:07:46 -0000 Received: from bellwfep4.bellnexxia.net (HELO bellwfep4-srv.bellnexxia.net) (207.236.237.110) by bellwecs2.srvr.bell.ca with SMTP; 26 Sep 2007 15:07:46 -0000 Received: from toroondc550.bell.corp.bce.ca ([142.182.84.162]) by bellwfep4-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20070926150746.GITI1989.bellwfep4-srv.bellnexxia.net@toroondc550.bell.corp.bce.ca>; Wed, 26 Sep 2007 11:07:46 -0400 Received: from toroondc912.bell.corp.bce.ca ([142.182.89.15]) by toroondc550.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 11:07:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] multiple location sources Date: Wed, 26 Sep 2007 11:07:42 -0400 Message-ID: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30B54BC2F@toroondc912> In-Reply-To: <01ad01c80048$b5855a80$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] multiple location sources Thread-Index: AcgAQn58Z1wcYtysRTyWRBvQuJbXyQAAFcIAAACA+1AAAGXl0AABTGeA References: <7582BC68E4994F4ABF0BD4723975C3FA05C401AE@crexc41p> <01a101c80044$2994e8a0$640fa8c0@cis.neustar.com> <2E62ACF8ADDB4D4F89093CBFDF2FBAF30B54BBFA@toroondc912> <01ad01c80048$b5855a80$640fa8c0@cis.neustar.com> From: To: , , X-OriginalArrivalTime: 26 Sep 2007 15:07:44.0497 (UTC) FILETIME=[FDC3B610:01C8004E] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac 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 Your scenario seems to imply that the each "line" is fixed (non-nomadic) = and always associated with one location Xx. What happens when "line" 1 = is moved to location X2? Worst, what happens when "line" 1 is used = completely outside of the family compound? Also, location Y in your scenario is not wrong, it's imprecise (your = family compound has a single civic address with multiple dwellings). = This can be resolved through interaction between caller and callee. BTW, there are ways today for subscribers to notify carriers of = situations like you describe. Manual input is dangerous in ES. Guy Caron -----Message d'origine----- De=A0: Brian Rosen [mailto:br@brianrosen.net]=20 Envoy=E9=A0: 26 septembre 2007 10:23 =C0=A0: Caron, Guy (A162859); khwolf1@gmail.com; bs7652@att.com Cc=A0: ecrit@ietf.org Objet=A0: RE: [Ecrit] multiple location sources Well, in the sense that today, there is no way for a subscriber to tell = a carrier that the location is X and not Y, you are correct. Imagine the following scenario: I have a family compound. It has 4 houses in 30 acres. We pay for a = single high speed Internet connection, and order 4 VoIP "lines", one for each = house with a LAN between the houses. To the carrier, there is one demarc = point, and one address for all four "lines". I come to you and say "If anyone calls from Line 1, the location is X1, line 2 is X2, ... I know someone = who has a set-up like this now. What will you do? If you behave like you do today, you will always send = Y and that's it. I won't speak for Canadians, but in the U.S, if you got a request like = that and a 9-1-1 call was sent to Y, you would likely not have a problem. However, if the subscriber told you again, and the next 9-1-1 call was = sent to Y, you would be in serious trouble (this happened recently, although = it was a simple data entry problem and not a = subscriber-knows-more-than-carrier problem). =20 You must have a manual method, and if the subscriber insists he is at X, = you MUST route on X. A difference between demarc and actual location is way = too easy to be significant these days. In the PSAP itself, the way this plays out is that you say you are at X, = and the ALI says you are at Y. The response goes to X. Always. The PSAP = never gets in trouble sending people to X. If they sent response only to Y, = it could be very bad news. If the caller actually was at Y, and they send responders to X, there would be no problem as long as the tape showed = they asked the guy the right questions. If the caller was an X and they send response to Y, they would be in big trouble. You always believe the = caller. You may question him carefully (which is why sending Y is a good idea), = but you respond to X. Brian > -----Original Message----- > From: g.caron@bell.ca [mailto:g.caron@bell.ca] > Sent: Wednesday, September 26, 2007 10:01 AM > To: br@brianrosen.net; khwolf1@gmail.com; bs7652@att.com > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] multiple location sources >=20 > I disagree in the context of ES. >=20 > The reverse should be done (route on Y and maybe send X as long as = there > is a mechanism to help the PSAP interpreting this situation) and let = the > call taker confirm the information through interaction with the = caller. > This is how it works today. >=20 > Guy Caron > -----Message d'origine----- > De=A0: Brian Rosen [mailto:br@brianrosen.net] > Envoy=E9=A0: 26 septembre 2007 09:50 > =C0=A0: 'Karl Heinz Wolf'; 'Stark, Barbara' > Cc=A0: 'ecrit' > Objet=A0: RE: [Ecrit] multiple location sources >=20 > Concerning manual location: >=20 > If a subscriber says he is at "X" and the carrier thinks the demark = point > is > "Y", you better route the call on and send "X". You probably want to = send > "Y" also. That mirrors what PSAPs do. >=20 > Brian >=20 > > -----Original Message----- > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > Sent: Wednesday, September 26, 2007 9:37 AM > > To: Stark, Barbara > > Cc: ecrit > > Subject: Re: [Ecrit] multiple location sources > > > > Thank you Barbara, for these useful documents from the DSL forum. > > I haven't read everything, but just two small comments so far: > > > > In Appendix A, Flow A, there is a line missing. "Was location in = DHCP > > response" has no "No" branching. It should connect to "Determine = LIS", > > I would suggest. > > > > Concerning Manual Configuration of Location Information: you use > > manual configuration only in case no other location determination = was > > successful. This is different to > > draft-ietf-geopriv-pdif-lo-profile-08, I think. If I understand > > Section 3.3. correctly, a separate PIDF document would be created > > containing the manual configuration even if automatic configuration > > was successful. > > > > karl heinz > > > > > > On 9/24/07, Stark, Barbara wrote: > > > Some of these are questions I was trying to address in the draft > > > document liaised from the DSL Forum to IETF > > > (see http://www1.ietf.org/mail- > archive/web/geopriv/current/msg04297.html > > > for link to documents), because I hadn't seen them addressed > elsewhere. > > > I'd be curious to hear if you find the flows in that document at = all > > > useful. I suggest in there that, in the absence of real = intelligence > for > > > selecting one location from multiple, that locations received from > lower > > > layers should be given preference over locations received from = higher > > > layers. When multiple locations are received using the same = protocol, > > > then the first received should be used. But this is for a = particular > > > physical interface. > > > > > > In the case of multiple physical interfaces, I suggest that the = device > > > should keep its location per physical interface. A call that goes = out > > > over a particular interface, should use the location associated = with > > > that interface. > > > > > > Again, this is suggested for the case where there is nothing on = which > to > > > base an informed decision. > > > Barbara > > > > > > -----Original Message----- > > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > > Sent: Monday, September 24, 2007 5:49 AM > > > To: ecrit > > > Subject: [Ecrit] multiple location sources > > > > > > Hi, > > > I'm working on a prototype SIP client that should be able to = determine > > > its location by DHCP, HELD and LLDP-MED. The PIDF-LO document is > > > included in the SIP INVITE body. I have several questions about = what > > > to do when there is more than one location source available. > > > > > > draft-ietf-sip-location-conveyance-08 recommends that there is = only > > > one location. Of course, all ways of location determination should > > > give the same location. But how can one verify if the same = location > > > was received via HELD and DHCP since a different format is used? > > > > > > Or when one gets two DHCP civic location messages via two = different > > > interfaces and some of the CAvalues are the same, but some not = (e.g. > > > one has an additional location information, the other has a = building > > > CAType). Is this the same location? > > > > > > Or think of the following situation. One gets a DHCP location > > > information via a wired connection (the location of the DHCP = server in > > > this building) and a LLDP-MED frame via WLAN of an access point in = the > > > next building (the location of the access point is announced). > > > draft-ietf-geopriv-pdif-lo-profile-08 gives some rules for = multiple > > > location information, but how can the device know which = information is > > > more adequate to get the right order? > > > > > > rfc4776 has a table with a mapping of CATypes and PIDF. When = conveying > > > location information in SIP messages, a PIDF document is needed. = So, > > > what to do with CATypes that have no mapping to PIDF? > > > > > > LLDP-MED has a "what" element, describing if the location of the > > > client itself, of the DHCP server or of the network element = closest to > > > the client is provided. This seems to be useful information, but = where > > > to put this in a PIDF document? > > > > > > I'm looking forward to your comments and suggestions. > > > > > > Ciao > > > Karl Heinz > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > ***** > > > > > > The information transmitted is intended only for the person or = entity > to > > which it is addressed and may contain confidential, proprietary, = and/or > > privileged material. Any review, retransmission, dissemination or = other > > use of, or taking of any action in reliance upon this information by > > persons or entities other than the intended recipient is prohibited. = If > > you received this in error, please contact the sender and delete the > > material from all computers. GA621 > > > > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 26 11:16:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaYcQ-0000HA-ME; Wed, 26 Sep 2007 11:16:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaYcQ-0000H3-6k for ecrit@ietf.org; Wed, 26 Sep 2007 11:16:06 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaYcJ-0004mA-Uz for ecrit@ietf.org; Wed, 26 Sep 2007 11:16:06 -0400 X-SEF-Processed: 5_0_0_910__2007_09_26_10_25_24 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 26 Sep 2007 10:25:23 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Sep 2007 10:15:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] multiple location sources Date: Wed, 26 Sep 2007 10:15:16 -0500 Message-ID: In-Reply-To: <01ad01c80048$b5855a80$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] multiple location sources Thread-Index: AcgAQn58Z1wcYtysRTyWRBvQuJbXyQAAFcIAAACA+1AAAGXl0AACKYsg References: <7582BC68E4994F4ABF0BD4723975C3FA05C401AE@crexc41p><01a101c80044$2994e8a0$640fa8c0@cis.neustar.com><2E62ACF8ADDB4D4F89093CBFDF2FBAF30B54BBFA@toroondc912> <01ad01c80048$b5855a80$640fa8c0@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , , , X-OriginalArrivalTime: 26 Sep 2007 15:15:44.0107 (UTC) FILETIME=[1BA263B0:01C80050] X-Spam-Score: 1.8 (+) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 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 with Guy on this one.=0D=0A=0D=0APicture this - somebody has manually c= onfigured a location in the VoIP client on their PDA. They did it out of cu= riosity when they first got it and never really understood what it was for.= They forgot about it shortly afterwards.=0D=0A=0D=0AWhen they eventually m= ake a 911 call, they are in a completely different city. The call gets rout= ed to the wrong PSAP.=0D=0A=0D=0AYou should believe the network location fi= rst because the network has responsibility to maintain location information= and users do not. The FCC recognizes this - which is why they say that use= r provided location is not going to be suitable for VoIP in the long term.=0D= =0A=0D=0AIf you've got such an extensive "campus" that dispatch really make= s a difference, then you should have a LIS. The network location will ensur= e routing is done correctly. If the PSAP is really going to get both locati= ons then the network (less granular) location will still correlate with the= user provided (more granular) location and will still be useful to the ope= rator.=0D=0A=0D=0AI don't think you can meaningfully suggest that a user "c= onfigured" location is semantically equivalent to a location provided verba= lly in the course of the call. It's not the same thing.=0D=0A=0D=0ACheers,=0D= =0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Brian Rosen [mai= lto:br@brianrosen.net]=20=0D=0ASent: Thursday, 27 September 2007 12:23 AM=0D= =0ATo: g.caron@bell.ca; khwolf1@gmail.com; bs7652@att.com=0D=0ACc: ecrit@ie= tf.org=0D=0ASubject: RE: [Ecrit] multiple location sources=0D=0A=0D=0AWell,= in the sense that today, there is no way for a subscriber to tell a=0D=0Ac= arrier that the location is X and not Y, you are correct.=0D=0A=0D=0AImagin= e the following scenario:=0D=0AI have a family compound. It has 4 houses i= n 30 acres. We pay for a single=0D=0Ahigh speed Internet connection, and o= rder 4 VoIP "lines", one for each house=0D=0Awith a LAN between the houses.= To the carrier, there is one demarc point,=0D=0Aand one address for all f= our "lines". I come to you and say "If anyone=0D=0Acalls from Line 1, the = location is X1, line 2 is X2, ... I know someone who=0D=0Ahas a set-up lik= e this now.=0D=0A=0D=0AWhat will you do=3F If you behave like you do today= , you will always send Y=0D=0Aand that's it.=0D=0A=0D=0AI won't speak for C= anadians, but in the U.S, if you got a request like that=0D=0Aand a 9-1-1 c= all was sent to Y, you would likely not have a problem.=0D=0AHowever, if th= e subscriber told you again, and the next 9-1-1 call was sent=0D=0Ato Y, yo= u would be in serious trouble (this happened recently, although it=0D=0Awas= a simple data entry problem and not a subscriber-knows-more-than-carrier=0D= =0Aproblem). =20=0D=0A=0D=0AYou must have a manual method, and if the subsc= riber insists he is at X, you=0D=0AMUST route on X. A difference between d= emarc and actual location is way too=0D=0Aeasy to be significant these days= =2E=0D=0A=0D=0AIn the PSAP itself, the way this plays out is that you say y= ou are at X, and=0D=0Athe ALI says you are at Y. The response goes to X. = Always. The PSAP never=0D=0Agets in trouble sending people to X. If they = sent response only to Y, it=0D=0Acould be very bad news. If the caller act= ually was at Y, and they send=0D=0Aresponders to X, there would be no probl= em as long as the tape showed they=0D=0Aasked the guy the right questions. = If the caller was an X and they send=0D=0Aresponse to Y, they would be in = big trouble. You always believe the caller.=0D=0AYou may question him care= fully (which is why sending Y is a good idea), but=0D=0Ayou respond to X.=0D= =0A=0D=0ABrian=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D= =0A> From: g.caron@bell.ca [mailto:g.caron@bell.ca]=0D=0A> Sent: Wednesday,= September 26, 2007 10:01 AM=0D=0A> To: br@brianrosen.net; khwolf1@gmail.co= m; bs7652@att.com=0D=0A> Cc: ecrit@ietf.org=0D=0A> Subject: RE: [Ecrit] mul= tiple location sources=0D=0A>=20=0D=0A> I disagree in the context of ES.=0D= =0A>=20=0D=0A> The reverse should be done (route on Y and maybe send X as l= ong as there=0D=0A> is a mechanism to help the PSAP interpreting this situa= tion) and let the=0D=0A> call taker confirm the information through interac= tion with the caller.=0D=0A> This is how it works today.=0D=0A>=20=0D=0A> G= uy Caron=0D=0A> -----Message d'origine-----=0D=0A> De=A0: Brian Rosen [mail= to:br@brianrosen.net]=0D=0A> Envoy=E9=A0: 26 septembre 2007 09:50=0D=0A> =C0= =A0: 'Karl Heinz Wolf'; 'Stark, Barbara'=0D=0A> Cc=A0: 'ecrit'=0D=0A> Objet= =A0: RE: [Ecrit] multiple location sources=0D=0A>=20=0D=0A> Concerning manu= al location:=0D=0A>=20=0D=0A> If a subscriber says he is at "X" and the car= rier thinks the demark point=0D=0A> is=0D=0A> "Y", you better route the cal= l on and send "X". You probably want to send=0D=0A> "Y" also. That mirror= s what PSAPs do.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A> > -----Original Me= ssage-----=0D=0A> > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com]=0D=0A>= > Sent: Wednesday, September 26, 2007 9:37 AM=0D=0A> > To: Stark, Barbara=0D= =0A> > Cc: ecrit=0D=0A> > Subject: Re: [Ecrit] multiple location sources=0D= =0A> >=0D=0A> > Thank you Barbara, for these useful documents from the DSL = forum.=0D=0A> > I haven't read everything, but just two small comments so f= ar:=0D=0A> >=0D=0A> > In Appendix A, Flow A, there is a line missing. "Was = location in DHCP=0D=0A> > response" has no "No" branching. It should connec= t to "Determine LIS",=0D=0A> > I would suggest.=0D=0A> >=0D=0A> > Concernin= g Manual Configuration of Location Information: you use=0D=0A> > manual con= figuration only in case no other location determination was=0D=0A> > succes= sful. This is different to=0D=0A> > draft-ietf-geopriv-pdif-lo-profile-08, = I think. If I understand=0D=0A> > Section 3.3. correctly, a separate PIDF d= ocument would be created=0D=0A> > containing the manual configuration even = if automatic configuration=0D=0A> > was successful.=0D=0A> >=0D=0A> > karl = heinz=0D=0A> >=0D=0A> >=0D=0A> > On 9/24/07, Stark, Barbara wrote:=0D=0A> > > Some of these are questions I was trying to address in = the draft=0D=0A> > > document liaised from the DSL Forum to IETF=0D=0A> > >= (see http://www1.ietf.org/mail-=0D=0A> archive/web/geopriv/current/msg0429= 7.html=0D=0A> > > for link to documents), because I hadn't seen them addres= sed=0D=0A> elsewhere.=0D=0A> > > I'd be curious to hear if you find the flo= ws in that document at all=0D=0A> > > useful. I suggest in there that, in t= he absence of real intelligence=0D=0A> for=0D=0A> > > selecting one locatio= n from multiple, that locations received from=0D=0A> lower=0D=0A> > > layer= s should be given preference over locations received from higher=0D=0A> > >= layers. When multiple locations are received using the same protocol,=0D=0A= > > > then the first received should be used. But this is for a particular=0D= =0A> > > physical interface.=0D=0A> > >=0D=0A> > > In the case of multiple = physical interfaces, I suggest that the device=0D=0A> > > should keep its l= ocation per physical interface. A call that goes out=0D=0A> > > over a part= icular interface, should use the location associated with=0D=0A> > > that i= nterface.=0D=0A> > >=0D=0A> > > Again, this is suggested for the case where= there is nothing on which=0D=0A> to=0D=0A> > > base an informed decision.=0D= =0A> > > Barbara=0D=0A> > >=0D=0A> > > -----Original Message-----=0D=0A> > = > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com]=0D=0A> > > Sent: Monday,= September 24, 2007 5:49 AM=0D=0A> > > To: ecrit=0D=0A> > > Subject: [Ecrit= ] multiple location sources=0D=0A> > >=0D=0A> > > Hi,=0D=0A> > > I'm workin= g on a prototype SIP client that should be able to determine=0D=0A> > > its= location by DHCP, HELD and LLDP-MED. The PIDF-LO document is=0D=0A> > > in= cluded in the SIP INVITE body. I have several questions about what=0D=0A> >= > to do when there is more than one location source available.=0D=0A> > >=0D= =0A> > > draft-ietf-sip-location-conveyance-08 recommends that there is onl= y=0D=0A> > > one location. Of course, all ways of location determination sh= ould=0D=0A> > > give the same location. But how can one verify if the same = location=0D=0A> > > was received via HELD and DHCP since a different format= is used=3F=0D=0A> > >=0D=0A> > > Or when one gets two DHCP civic location = messages via two different=0D=0A> > > interfaces and some of the CAvalues a= re the same, but some not (e.g.=0D=0A> > > one has an additional location i= nformation, the other has a building=0D=0A> > > CAType). Is this the same l= ocation=3F=0D=0A> > >=0D=0A> > > Or think of the following situation. One g= ets a DHCP location=0D=0A> > > information via a wired connection (the loca= tion of the DHCP server in=0D=0A> > > this building) and a LLDP-MED frame v= ia WLAN of an access point in the=0D=0A> > > next building (the location of= the access point is announced).=0D=0A> > > draft-ietf-geopriv-pdif-lo-prof= ile-08 gives some rules for multiple=0D=0A> > > location information, but h= ow can the device know which information is=0D=0A> > > more adequate to get= the right order=3F=0D=0A> > >=0D=0A> > > rfc4776 has a table with a mappin= g of CATypes and PIDF. When conveying=0D=0A> > > location information in SI= P messages, a PIDF document is needed. So,=0D=0A> > > what to do with CATyp= es that have no mapping to PIDF=3F=0D=0A> > >=0D=0A> > > LLDP-MED has a "wh= at" element, describing if the location of the=0D=0A> > > client itself, of= the DHCP server or of the network element closest to=0D=0A> > > the client= is provided. This seems to be useful information, but where=0D=0A> > > to = put this in a PIDF document=3F=0D=0A> > >=0D=0A> > > I'm looking forward to= your comments and suggestions.=0D=0A> > >=0D=0A> > > Ciao=0D=0A> > > Karl = Heinz=0D=0A> > >=0D=0A> > > _______________________________________________=0D= =0A> > > Ecrit mailing list=0D=0A> > > Ecrit@ietf.org=0D=0A> > > https://ww= w1.ietf.org/mailman/listinfo/ecrit=0D=0A> > >=0D=0A> > > *****=0D=0A> > >=0D= =0A> > > The information transmitted is intended only for the person or ent= ity=0D=0A> to=0D=0A> > which it is addressed and may contain confidential, = proprietary, and/or=0D=0A> > privileged material. Any review, retransmissio= n, dissemination or other=0D=0A> > use of, or taking of any action in relia= nce upon this information by=0D=0A> > persons or entities other than the in= tended recipient is prohibited. If=0D=0A> > you received this in error, ple= ase contact the sender and delete the=0D=0A> > material from all computers.= GA621=0D=0A> > >=0D=0A> > >=0D=0A> > >=0D=0A> >=0D=0A> > _________________= ______________________________=0D=0A> > Ecrit mailing list=0D=0A> > Ecrit@i= etf.org=0D=0A> > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A= >=20=0D=0A> _______________________________________________=0D=0A> Ecrit ma= iling list=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mailman/listi= nfo/ecrit=0D=0A=0D=0A=0D=0A_______________________________________________=0D= =0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www1.ietf.org/mailma= n/listinfo/ecrit=0D=0A=0D=0A-----------------------------------------------= -------------------------------------------------=0D=0AThis message is for = the designated recipient only and may=0D=0Acontain privileged, proprietary,= or otherwise private information. =20=0D=0AIf you have received it in erro= r, please notify the sender=0D=0Aimmediately and delete the original. Any = unauthorized use of=0D=0Athis email is prohibited.=0D=0A-------------------= ---------------------------------------------------------------------------= --=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 26 11:34:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaYtr-0008U4-M9; Wed, 26 Sep 2007 11:34:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaYtq-0008Rn-0Z for ecrit@ietf.org; Wed, 26 Sep 2007 11:34:06 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaYto-0002G5-Nn for ecrit@ietf.org; Wed, 26 Sep 2007 11:34:05 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IaYte-0005dU-TW; Wed, 26 Sep 2007 10:33:55 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , , , References: <7582BC68E4994F4ABF0BD4723975C3FA05C401AE@crexc41p><01a101c80044$2994e8a0$640fa8c0@cis.neustar.com><2E62ACF8ADDB4D4F89093CBFDF2FBAF30B54BBFA@toroondc912> <01ad01c80048$b5855a80$640fa8c0@cis.neustar.com> Subject: RE: [Ecrit] multiple location sources Date: Wed, 26 Sep 2007 11:34:00 -0400 Message-ID: <01d801c80052$ab281c30$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcgAQn58Z1wcYtysRTyWRBvQuJbXyQAAFcIAAACA+1AAAGXl0AACKYsgAACj6RA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think that the carrier will never be in trouble if I screw up, = especially if they send what they think the location should be. I think they will = be seriously hosed if they are wrong and I am right. I don't think this should be particularly easy. I think it should be possible. I know that it MUST be possible for the subscriber to tell = the carrier what address to report, regardless of what the carrier thinks = the location is. In the situation I've described, if the endpoint put a location on the = call (local LIS), what do you do if the network thinks it's wrong? -phonebcp says you use the one from the endpoint. That is indistinguishable from manual configuration from the network point of view. I am not suggesting that user configuration and verbal communication are = the same. I'm suggesting that when there is a conflict between what the = user asserts and what the network asserts, the emergency system uses the = user's answer, always. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Wednesday, September 26, 2007 11:15 AM > To: Brian Rosen; g.caron@bell.ca; khwolf1@gmail.com; bs7652@att.com > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] multiple location sources >=20 > I'm with Guy on this one. >=20 > Picture this - somebody has manually configured a location in the VoIP > client on their PDA. They did it out of curiosity when they first got = it > and never really understood what it was for. They forgot about it = shortly > afterwards. >=20 > When they eventually make a 911 call, they are in a completely = different > city. The call gets routed to the wrong PSAP. >=20 > You should believe the network location first because the network has > responsibility to maintain location information and users do not. The = FCC > recognizes this - which is why they say that user provided location is = not > going to be suitable for VoIP in the long term. >=20 > If you've got such an extensive "campus" that dispatch really makes a > difference, then you should have a LIS. The network location will = ensure > routing is done correctly. If the PSAP is really going to get both > locations then the network (less granular) location will still = correlate > with the user provided (more granular) location and will still be = useful > to the operator. >=20 > I don't think you can meaningfully suggest that a user "configured" > location is semantically equivalent to a location provided verbally in = the > course of the call. It's not the same thing. >=20 > Cheers, > Martin >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, 27 September 2007 12:23 AM > To: g.caron@bell.ca; khwolf1@gmail.com; bs7652@att.com > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] multiple location sources >=20 > Well, in the sense that today, there is no way for a subscriber to = tell a > carrier that the location is X and not Y, you are correct. >=20 > Imagine the following scenario: > I have a family compound. It has 4 houses in 30 acres. We pay for a > single > high speed Internet connection, and order 4 VoIP "lines", one for each > house > with a LAN between the houses. To the carrier, there is one demarc = point, > and one address for all four "lines". I come to you and say "If = anyone > calls from Line 1, the location is X1, line 2 is X2, ... I know = someone > who > has a set-up like this now. >=20 > What will you do? If you behave like you do today, you will always = send Y > and that's it. >=20 > I won't speak for Canadians, but in the U.S, if you got a request like > that > and a 9-1-1 call was sent to Y, you would likely not have a problem. > However, if the subscriber told you again, and the next 9-1-1 call was > sent > to Y, you would be in serious trouble (this happened recently, = although it > was a simple data entry problem and not a subscriber-knows-more-than- > carrier > problem). >=20 > You must have a manual method, and if the subscriber insists he is at = X, > you > MUST route on X. A difference between demarc and actual location is = way > too > easy to be significant these days. >=20 > In the PSAP itself, the way this plays out is that you say you are at = X, > and > the ALI says you are at Y. The response goes to X. Always. The PSAP > never > gets in trouble sending people to X. If they sent response only to Y, = it > could be very bad news. If the caller actually was at Y, and they = send > responders to X, there would be no problem as long as the tape showed = they > asked the guy the right questions. If the caller was an X and they = send > response to Y, they would be in big trouble. You always believe the > caller. > You may question him carefully (which is why sending Y is a good = idea), > but > you respond to X. >=20 > Brian >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: g.caron@bell.ca [mailto:g.caron@bell.ca] > > Sent: Wednesday, September 26, 2007 10:01 AM > > To: br@brianrosen.net; khwolf1@gmail.com; bs7652@att.com > > Cc: ecrit@ietf.org > > Subject: RE: [Ecrit] multiple location sources > > > > I disagree in the context of ES. > > > > The reverse should be done (route on Y and maybe send X as long as = there > > is a mechanism to help the PSAP interpreting this situation) and let = the > > call taker confirm the information through interaction with the = caller. > > This is how it works today. > > > > Guy Caron > > -----Message d'origine----- > > De=A0: Brian Rosen [mailto:br@brianrosen.net] > > Envoy=E9=A0: 26 septembre 2007 09:50 > > =C0=A0: 'Karl Heinz Wolf'; 'Stark, Barbara' > > Cc=A0: 'ecrit' > > Objet=A0: RE: [Ecrit] multiple location sources > > > > Concerning manual location: > > > > If a subscriber says he is at "X" and the carrier thinks the demark > point > > is > > "Y", you better route the call on and send "X". You probably want = to > send > > "Y" also. That mirrors what PSAPs do. > > > > Brian > > > > > -----Original Message----- > > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > > Sent: Wednesday, September 26, 2007 9:37 AM > > > To: Stark, Barbara > > > Cc: ecrit > > > Subject: Re: [Ecrit] multiple location sources > > > > > > Thank you Barbara, for these useful documents from the DSL forum. > > > I haven't read everything, but just two small comments so far: > > > > > > In Appendix A, Flow A, there is a line missing. "Was location in = DHCP > > > response" has no "No" branching. It should connect to "Determine = LIS", > > > I would suggest. > > > > > > Concerning Manual Configuration of Location Information: you use > > > manual configuration only in case no other location determination = was > > > successful. This is different to > > > draft-ietf-geopriv-pdif-lo-profile-08, I think. If I understand > > > Section 3.3. correctly, a separate PIDF document would be created > > > containing the manual configuration even if automatic = configuration > > > was successful. > > > > > > karl heinz > > > > > > > > > On 9/24/07, Stark, Barbara wrote: > > > > Some of these are questions I was trying to address in the draft > > > > document liaised from the DSL Forum to IETF > > > > (see http://www1.ietf.org/mail- > > archive/web/geopriv/current/msg04297.html > > > > for link to documents), because I hadn't seen them addressed > > elsewhere. > > > > I'd be curious to hear if you find the flows in that document at = all > > > > useful. I suggest in there that, in the absence of real = intelligence > > for > > > > selecting one location from multiple, that locations received = from > > lower > > > > layers should be given preference over locations received from > higher > > > > layers. When multiple locations are received using the same > protocol, > > > > then the first received should be used. But this is for a = particular > > > > physical interface. > > > > > > > > In the case of multiple physical interfaces, I suggest that the > device > > > > should keep its location per physical interface. A call that = goes > out > > > > over a particular interface, should use the location associated = with > > > > that interface. > > > > > > > > Again, this is suggested for the case where there is nothing on > which > > to > > > > base an informed decision. > > > > Barbara > > > > > > > > -----Original Message----- > > > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > > > Sent: Monday, September 24, 2007 5:49 AM > > > > To: ecrit > > > > Subject: [Ecrit] multiple location sources > > > > > > > > Hi, > > > > I'm working on a prototype SIP client that should be able to > determine > > > > its location by DHCP, HELD and LLDP-MED. The PIDF-LO document is > > > > included in the SIP INVITE body. I have several questions about = what > > > > to do when there is more than one location source available. > > > > > > > > draft-ietf-sip-location-conveyance-08 recommends that there is = only > > > > one location. Of course, all ways of location determination = should > > > > give the same location. But how can one verify if the same = location > > > > was received via HELD and DHCP since a different format is used? > > > > > > > > Or when one gets two DHCP civic location messages via two = different > > > > interfaces and some of the CAvalues are the same, but some not = (e.g. > > > > one has an additional location information, the other has a = building > > > > CAType). Is this the same location? > > > > > > > > Or think of the following situation. One gets a DHCP location > > > > information via a wired connection (the location of the DHCP = server > in > > > > this building) and a LLDP-MED frame via WLAN of an access point = in > the > > > > next building (the location of the access point is announced). > > > > draft-ietf-geopriv-pdif-lo-profile-08 gives some rules for = multiple > > > > location information, but how can the device know which = information > is > > > > more adequate to get the right order? > > > > > > > > rfc4776 has a table with a mapping of CATypes and PIDF. When > conveying > > > > location information in SIP messages, a PIDF document is needed. = So, > > > > what to do with CATypes that have no mapping to PIDF? > > > > > > > > LLDP-MED has a "what" element, describing if the location of the > > > > client itself, of the DHCP server or of the network element = closest > to > > > > the client is provided. This seems to be useful information, but > where > > > > to put this in a PIDF document? > > > > > > > > I'm looking forward to your comments and suggestions. > > > > > > > > Ciao > > > > Karl Heinz > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > ***** > > > > > > > > The information transmitted is intended only for the person or > entity > > to > > > which it is addressed and may contain confidential, proprietary, > and/or > > > privileged material. Any review, retransmission, dissemination or > other > > > use of, or taking of any action in reliance upon this information = by > > > persons or entities other than the intended recipient is = prohibited. > If > > > you received this in error, please contact the sender and delete = the > > > material from all computers. GA621 > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 > = -------------------------------------------------------------------------= - > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > = -------------------------------------------------------------------------= - > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 26 12:01:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaZJQ-0007Od-9l; Wed, 26 Sep 2007 12:00:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaZJB-0006oK-J7 for ecrit@ietf.org; Wed, 26 Sep 2007 12:00:17 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IaZJ7-00030g-2H for ecrit@ietf.org; Wed, 26 Sep 2007 12:00:14 -0400 X-SEF-Processed: 5_0_0_910__2007_09_26_11_09_52 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 26 Sep 2007 11:09:51 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Sep 2007 11:00:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] multiple location sources Date: Wed, 26 Sep 2007 10:59:26 -0500 Message-ID: In-Reply-To: <01d801c80052$ab281c30$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] multiple location sources Thread-Index: AcgAQn58Z1wcYtysRTyWRBvQuJbXyQAAFcIAAACA+1AAAGXl0AACKYsgAACj6RAAAFVEIA== References: <7582BC68E4994F4ABF0BD4723975C3FA05C401AE@crexc41p><01a101c80044$2994e8a0$640fa8c0@cis.neustar.com><2E62ACF8ADDB4D4F89093CBFDF2FBAF30B54BBFA@toroondc912> <01ad01c80048$b5855a80$640fa8c0@cis.neustar.com> <01d801c80052$ab281c30$640fa8c0@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , , , X-OriginalArrivalTime: 26 Sep 2007 16:00:12.0181 (UTC) FILETIME=[51EE2C50:01C80056] X-Spam-Score: 1.8 (+) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 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 below=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Brian Rosen [mailto:= br@brianrosen.net]=20=0D=0ASent: Thursday, 27 September 2007 1:34 AM=0D=0AT= o: Dawson, Martin; g.caron@bell.ca; khwolf1@gmail.com; bs7652@att.com=0D=0A= Cc: ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] multiple location sources=0D=0A=0D= =0AI think that the carrier will never be in trouble if I screw up, especia= lly=0D=0Aif they send what they think the location should be. I think they= will be=0D=0Aseriously hosed if they are wrong and I am right.=0D=0A=0D=0A= [[MCD]] I wasn't saying anything about liability - I'm talking about relia= bility. I believe the network provided location will be more reliable than = user configured location. I'm talking about the best solution, not the "lea= st liability" solution. Network operators already have responsibility for g= etting location information correct - nothing has changed there.=0D=0A=0D=0A= I don't think this should be particularly easy. I think it should be=0D=0A= possible. I know that it MUST be possible for the subscriber to tell the=0D= =0Acarrier what address to report, regardless of what the carrier thinks th= e=0D=0Alocation is.=0D=0A=0D=0A[[MCD]] You're talking about something that = doesn't happen today. You agree that a location provided verbally in the ac= tual course of the call is not the same as a user configured location. I do= n't know what empirical data you're basing your assertion on that this is b= etter.=0D=0A=0D=0AIn the situation I've described, if the endpoint put a lo= cation on the call=0D=0A(local LIS), what do you do if the network thinks i= t's wrong=3F -phonebcp=0D=0Asays you use the one from the endpoint. That = is indistinguishable from=0D=0Amanual configuration from the network point = of view.=0D=0A=0D=0A[[MCD]] The current functionality does not offer much s= cope for sophistication on this point. If the device acquires location by v= alue, it could choose to replace the proffered location with its own. If it= does it by reference, it doesn't have an opportunity to compare anyway. If= it decides to just use its own without asking the network, then the networ= k doesn't get a chance to express an opinion anyway. Until we have location= signing, there won't be a definitive way to know for sure that we're deali= ng with a genuine network determined location. Callers could choose to deli= berately lie about their location for whatever purpose that served them.=0D= =0A=0D=0AWhen the routing engine can genuinely tell the difference, then I = think it should be a matter of jurisdictional policy as to which location t= akes precedence for routing. Routing rules (and LoST implementation) are wi= thin the remit of the jurisdiction. I don't think phonebcp has authority ov= er jurisdictions to decide that policy (nor does it need to have).=20=0D=0A=0D= =0AI am not suggesting that user configuration and verbal communication are= the=0D=0Asame. I'm suggesting that when there is a conflict between what = the user=0D=0Aasserts and what the network asserts, the emergency system us= es the user's=0D=0Aanswer, always.=0D=0A[[MCD]] Yes - we disagree on that.=0D= =0A=0D=0ABrian=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Dawson,= Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> Sent: Wednesday, September= 26, 2007 11:15 AM=0D=0A> To: Brian Rosen; g.caron@bell.ca; khwolf1@gmail.c= om; bs7652@att.com=0D=0A> Cc: ecrit@ietf.org=0D=0A> Subject: RE: [Ecrit] mu= ltiple location sources=0D=0A>=20=0D=0A> I'm with Guy on this one.=0D=0A> =0D= =0A> Picture this - somebody has manually configured a location in the VoIP=0D= =0A> client on their PDA. They did it out of curiosity when they first got = it=0D=0A> and never really understood what it was for. They forgot about it= shortly=0D=0A> afterwards.=0D=0A>=20=0D=0A> When they eventually make a 91= 1 call, they are in a completely different=0D=0A> city. The call gets route= d to the wrong PSAP.=0D=0A>=20=0D=0A> You should believe the network locati= on first because the network has=0D=0A> responsibility to maintain location= information and users do not. The FCC=0D=0A> recognizes this - which is wh= y they say that user provided location is not=0D=0A> going to be suitable f= or VoIP in the long term.=0D=0A>=20=0D=0A> If you've got such an extensive = "campus" that dispatch really makes a=0D=0A> difference, then you should ha= ve a LIS. The network location will ensure=0D=0A> routing is done correctly= =2E If the PSAP is really going to get both=0D=0A> locations then the netwo= rk (less granular) location will still correlate=0D=0A> with the user provi= ded (more granular) location and will still be useful=0D=0A> to the operato= r.=0D=0A>=20=0D=0A> I don't think you can meaningfully suggest that a user = "configured"=0D=0A> location is semantically equivalent to a location provi= ded verbally in the=0D=0A> course of the call. It's not the same thing.=0D=0A= >=20=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=20=0D=0A> -----Original Message---= --=0D=0A> From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> Sent: Thursda= y, 27 September 2007 12:23 AM=0D=0A> To: g.caron@bell.ca; khwolf1@gmail.com= ; bs7652@att.com=0D=0A> Cc: ecrit@ietf.org=0D=0A> Subject: RE: [Ecrit] mult= iple location sources=0D=0A>=20=0D=0A> Well, in the sense that today, there= is no way for a subscriber to tell a=0D=0A> carrier that the location is X= and not Y, you are correct.=0D=0A>=20=0D=0A> Imagine the following scenari= o:=0D=0A> I have a family compound. It has 4 houses in 30 acres. We pay f= or a=0D=0A> single=0D=0A> high speed Internet connection, and order 4 VoIP = "lines", one for each=0D=0A> house=0D=0A> with a LAN between the houses. T= o the carrier, there is one demarc point,=0D=0A> and one address for all fo= ur "lines". I come to you and say "If anyone=0D=0A> calls from Line 1, the= location is X1, line 2 is X2, ... I know someone=0D=0A> who=0D=0A> has a = set-up like this now.=0D=0A>=20=0D=0A> What will you do=3F If you behave l= ike you do today, you will always send Y=0D=0A> and that's it.=0D=0A>=20=0D= =0A> I won't speak for Canadians, but in the U.S, if you got a request like=0D= =0A> that=0D=0A> and a 9-1-1 call was sent to Y, you would likely not have = a problem.=0D=0A> However, if the subscriber told you again, and the next 9= -1-1 call was=0D=0A> sent=0D=0A> to Y, you would be in serious trouble (thi= s happened recently, although it=0D=0A> was a simple data entry problem and= not a subscriber-knows-more-than-=0D=0A> carrier=0D=0A> problem).=0D=0A> =0D= =0A> You must have a manual method, and if the subscriber insists he is at = X,=0D=0A> you=0D=0A> MUST route on X. A difference between demarc and actu= al location is way=0D=0A> too=0D=0A> easy to be significant these days.=0D=0A= >=20=0D=0A> In the PSAP itself, the way this plays out is that you say you = are at X,=0D=0A> and=0D=0A> the ALI says you are at Y. The response goes t= o X. Always. The PSAP=0D=0A> never=0D=0A> gets in trouble sending people = to X. If they sent response only to Y, it=0D=0A> could be very bad news. = If the caller actually was at Y, and they send=0D=0A> responders to X, ther= e would be no problem as long as the tape showed they=0D=0A> asked the guy = the right questions. If the caller was an X and they send=0D=0A> response = to Y, they would be in big trouble. You always believe the=0D=0A> caller.=0D= =0A> You may question him carefully (which is why sending Y is a good idea)= ,=0D=0A> but=0D=0A> you respond to X.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A= >=20=0D=0A>=20=0D=0A>=20=0D=0A> > -----Original Message-----=0D=0A> > From:= g.caron@bell.ca [mailto:g.caron@bell.ca]=0D=0A> > Sent: Wednesday, Septemb= er 26, 2007 10:01 AM=0D=0A> > To: br@brianrosen.net; khwolf1@gmail.com; bs7= 652@att.com=0D=0A> > Cc: ecrit@ietf.org=0D=0A> > Subject: RE: [Ecrit] multi= ple location sources=0D=0A> >=0D=0A> > I disagree in the context of ES.=0D=0A= > >=0D=0A> > The reverse should be done (route on Y and maybe send X as lon= g as there=0D=0A> > is a mechanism to help the PSAP interpreting this situa= tion) and let the=0D=0A> > call taker confirm the information through inter= action with the caller.=0D=0A> > This is how it works today.=0D=0A> >=0D=0A= > > Guy Caron=0D=0A> > -----Message d'origine-----=0D=0A> > De=A0: Brian Ro= sen [mailto:br@brianrosen.net]=0D=0A> > Envoy=E9=A0: 26 septembre 2007 09:5= 0=0D=0A> > =C0=A0: 'Karl Heinz Wolf'; 'Stark, Barbara'=0D=0A> > Cc=A0: 'ecr= it'=0D=0A> > Objet=A0: RE: [Ecrit] multiple location sources=0D=0A> >=0D=0A= > > Concerning manual location:=0D=0A> >=0D=0A> > If a subscriber says he i= s at "X" and the carrier thinks the demark=0D=0A> point=0D=0A> > is=0D=0A> = > "Y", you better route the call on and send "X". You probably want to=0D=0A= > send=0D=0A> > "Y" also. That mirrors what PSAPs do.=0D=0A> >=0D=0A> > Br= ian=0D=0A> >=0D=0A> > > -----Original Message-----=0D=0A> > > From: Karl He= inz Wolf [mailto:khwolf1@gmail.com]=0D=0A> > > Sent: Wednesday, September 2= 6, 2007 9:37 AM=0D=0A> > > To: Stark, Barbara=0D=0A> > > Cc: ecrit=0D=0A> >= > Subject: Re: [Ecrit] multiple location sources=0D=0A> > >=0D=0A> > > Tha= nk you Barbara, for these useful documents from the DSL forum.=0D=0A> > > I= haven't read everything, but just two small comments so far:=0D=0A> > >=0D= =0A> > > In Appendix A, Flow A, there is a line missing. "Was location in D= HCP=0D=0A> > > response" has no "No" branching. It should connect to "Deter= mine LIS",=0D=0A> > > I would suggest.=0D=0A> > >=0D=0A> > > Concerning Man= ual Configuration of Location Information: you use=0D=0A> > > manual config= uration only in case no other location determination was=0D=0A> > > success= ful. This is different to=0D=0A> > > draft-ietf-geopriv-pdif-lo-profile-08,= I think. If I understand=0D=0A> > > Section 3.3. correctly, a separate PID= F document would be created=0D=0A> > > containing the manual configuration = even if automatic configuration=0D=0A> > > was successful.=0D=0A> > >=0D=0A= > > > karl heinz=0D=0A> > >=0D=0A> > >=0D=0A> > > On 9/24/07, Stark, Barbar= a wrote:=0D=0A> > > > Some of these are questions I was tr= ying to address in the draft=0D=0A> > > > document liaised from the DSL For= um to IETF=0D=0A> > > > (see http://www1.ietf.org/mail-=0D=0A> > archive/we= b/geopriv/current/msg04297.html=0D=0A> > > > for link to documents), becaus= e I hadn't seen them addressed=0D=0A> > elsewhere.=0D=0A> > > > I'd be curi= ous to hear if you find the flows in that document at all=0D=0A> > > > usef= ul. I suggest in there that, in the absence of real intelligence=0D=0A> > f= or=0D=0A> > > > selecting one location from multiple, that locations receiv= ed from=0D=0A> > lower=0D=0A> > > > layers should be given preference over = locations received from=0D=0A> higher=0D=0A> > > > layers. When multiple lo= cations are received using the same=0D=0A> protocol,=0D=0A> > > > then the = first received should be used. But this is for a particular=0D=0A> > > > ph= ysical interface.=0D=0A> > > >=0D=0A> > > > In the case of multiple physica= l interfaces, I suggest that the=0D=0A> device=0D=0A> > > > should keep its= location per physical interface. A call that goes=0D=0A> out=0D=0A> > > > = over a particular interface, should use the location associated with=0D=0A>= > > > that interface.=0D=0A> > > >=0D=0A> > > > Again, this is suggested f= or the case where there is nothing on=0D=0A> which=0D=0A> > to=0D=0A> > > >= base an informed decision.=0D=0A> > > > Barbara=0D=0A> > > >=0D=0A> > > > = -----Original Message-----=0D=0A> > > > From: Karl Heinz Wolf [mailto:khwol= f1@gmail.com]=0D=0A> > > > Sent: Monday, September 24, 2007 5:49 AM=0D=0A> = > > > To: ecrit=0D=0A> > > > Subject: [Ecrit] multiple location sources=0D=0A= > > > >=0D=0A> > > > Hi,=0D=0A> > > > I'm working on a prototype SIP client= that should be able to=0D=0A> determine=0D=0A> > > > its location by DHCP,= HELD and LLDP-MED. The PIDF-LO document is=0D=0A> > > > included in the SI= P INVITE body. I have several questions about what=0D=0A> > > > to do when = there is more than one location source available.=0D=0A> > > >=0D=0A> > > >= draft-ietf-sip-location-conveyance-08 recommends that there is only=0D=0A>= > > > one location. Of course, all ways of location determination should=0D= =0A> > > > give the same location. But how can one verify if the same locat= ion=0D=0A> > > > was received via HELD and DHCP since a different format is= used=3F=0D=0A> > > >=0D=0A> > > > Or when one gets two DHCP civic location= messages via two different=0D=0A> > > > interfaces and some of the CAvalue= s are the same, but some not (e.g.=0D=0A> > > > one has an additional locat= ion information, the other has a building=0D=0A> > > > CAType). Is this the= same location=3F=0D=0A> > > >=0D=0A> > > > Or think of the following situa= tion. One gets a DHCP location=0D=0A> > > > information via a wired connect= ion (the location of the DHCP server=0D=0A> in=0D=0A> > > > this building) = and a LLDP-MED frame via WLAN of an access point in=0D=0A> the=0D=0A> > > >= next building (the location of the access point is announced).=0D=0A> > > = > draft-ietf-geopriv-pdif-lo-profile-08 gives some rules for multiple=0D=0A= > > > > location information, but how can the device know which information=0D= =0A> is=0D=0A> > > > more adequate to get the right order=3F=0D=0A> > > >=0D= =0A> > > > rfc4776 has a table with a mapping of CATypes and PIDF. When=0D=0A= > conveying=0D=0A> > > > location information in SIP messages, a PIDF docum= ent is needed. So,=0D=0A> > > > what to do with CATypes that have no mappin= g to PIDF=3F=0D=0A> > > >=0D=0A> > > > LLDP-MED has a "what" element, descr= ibing if the location of the=0D=0A> > > > client itself, of the DHCP server= or of the network element closest=0D=0A> to=0D=0A> > > > the client is pro= vided. This seems to be useful information, but=0D=0A> where=0D=0A> > > > t= o put this in a PIDF document=3F=0D=0A> > > >=0D=0A> > > > I'm looking forw= ard to your comments and suggestions.=0D=0A> > > >=0D=0A> > > > Ciao=0D=0A>= > > > Karl Heinz=0D=0A> > > >=0D=0A> > > > _______________________________= ________________=0D=0A> > > > Ecrit mailing list=0D=0A> > > > Ecrit@ietf.or= g=0D=0A> > > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > > >=0D= =0A> > > > *****=0D=0A> > > >=0D=0A> > > > The information transmitted is i= ntended only for the person or=0D=0A> entity=0D=0A> > to=0D=0A> > > which i= t is addressed and may contain confidential, proprietary,=0D=0A> and/or=0D=0A= > > > privileged material. Any review, retransmission, dissemination or=0D=0A= > other=0D=0A> > > use of, or taking of any action in reliance upon this in= formation by=0D=0A> > > persons or entities other than the intended recipie= nt is prohibited.=0D=0A> If=0D=0A> > > you received this in error, please c= ontact the sender and delete the=0D=0A> > > material from all computers. GA= 621=0D=0A> > > >=0D=0A> > > >=0D=0A> > > >=0D=0A> > >=0D=0A> > > __________= _____________________________________=0D=0A> > > Ecrit mailing list=0D=0A> = > > Ecrit@ietf.org=0D=0A> > > https://www1.ietf.org/mailman/listinfo/ecrit=0D= =0A> >=0D=0A> >=0D=0A> > _______________________________________________=0D= =0A> > Ecrit mailing list=0D=0A> > Ecrit@ietf.org=0D=0A> > https://www1.iet= f.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A>=20=0D=0A> ___________________= ____________________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.or= g=0D=0A> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A> ----= ----------------------------------------------------------------------=0D=0A= > ----------------------=0D=0A> This message is for the designated recipien= t only and may=0D=0A> contain privileged, proprietary, or otherwise private= information.=0D=0A> If you have received it in error, please notify the se= nder=0D=0A> immediately and delete the original. Any unauthorized use of=0D= =0A> this email is prohibited.=0D=0A> -------------------------------------= -------------------------------------=0D=0A> ----------------------=0D=0A> = [mf2]=0D=0A=0D=0A=0D=0A----------------------------------------------------= --------------------------------------------=0D=0AThis message is for the d= esignated recipient only and may=0D=0Acontain privileged, proprietary, or o= therwise private information. =20=0D=0AIf you have received it in error, pl= ease notify the sender=0D=0Aimmediately and delete the original. Any unaut= horized use of=0D=0Athis email is prohibited.=0D=0A------------------------= ------------------------------------------------------------------------=0D= =0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 26 13:13:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaaRK-0003h3-Gt; Wed, 26 Sep 2007 13:12:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaaRJ-0003gY-1z for ecrit@ietf.org; Wed, 26 Sep 2007 13:12:45 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaaRA-0000OH-OE for ecrit@ietf.org; Wed, 26 Sep 2007 13:12:43 -0400 Received: from ([139.76.131.79]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.185327484; Wed, 26 Sep 2007 13:12:04 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 26 Sep 2007 13:12:04 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 26 Sep 2007 13:12:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] multiple location sources Date: Wed, 26 Sep 2007 13:12:01 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA05C40758@crexc41p> In-Reply-To: <01ad01c80048$b5855a80$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] multiple location sources Thread-Index: AcgAQn58Z1wcYtysRTyWRBvQuJbXyQAAFcIAAACA+1AAAGXl0AAEVz6g References: <7582BC68E4994F4ABF0BD4723975C3FA05C401AE@crexc41p> <01a101c80044$2994e8a0$640fa8c0@cis.neustar.com> <2E62ACF8ADDB4D4F89093CBFDF2FBAF30B54BBFA@toroondc912> <01ad01c80048$b5855a80$640fa8c0@cis.neustar.com> From: "Stark, Barbara" To: "Brian Rosen" , , X-OriginalArrivalTime: 26 Sep 2007 17:12:03.0712 (UTC) FILETIME=[5BCD9800:01C80060] X-Spam-Score: 0.2 (/) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think this is a perfect example as to why manual config is not a good = idea in an end device, but does need to be supported in home and = business routers. I think it's pretty safe to assume that a person, P1, living at X1 (in = Brian's 30 acre compound) will quickly learn that he can take the = telephone, T1, with him to gossip at X2, and everything works perfectly. = P1 can make calls on line 1 (L1), and receive them, no matter where T1 = happens to be! No way is P1 going to be updating location info, = everytime he leaves the house with T1. Imagine his joy when he discovers = that T1 not only works at X1-4, but it also works at the Wi-Fi enabled = barber shop, in town. Fortunately, he can leave T1' and T1'' at X1, so = his kids (P1'-P1''''') can still use L1, as well. VoIP is a wonderful = thing. On the other hand, that router serving the 4 homes will be relatively = static in location, and I think it would be a good idea to support = manual config, partly for the scenario Brian describes. What I really wish we could seriously discuss, is desired default = behaviors. I think we have to accept that a) Manual configuration of all sorts of devices (end devices and = intermediary devices) will exist, no matter how hard regulators frown or = smile -- I mean, let's be realistic: No way is the Canadian government = going to fine me or throw me in jail, when I take my US laptop to Quebec = City, and it's subscribed to a Sierra Leone provider, and has a soft = client that I downloaded off the Internet that lets me manually = configure my location. There's nothing they can really do to keep = Canadian citizens from having configurable devices, either, if the = Canadian citizens so choose. Unless they intend to cut the Canadian = Internet off from the rest of the world, and close their borders... b) There will exist devices where end users can set the logic of = location determination and acquisition. They can add protocols, remove = protocols, re-order protocols, enter 20 different manual locations with = rules as to which to use where, etc. Regulators can't prevent the = existence of these devices, or control the end users. c) The vast majority of people won't want to use manual configuration of = location, especially in end devices. In cases where they find a manual = config capability in a device, odds are they'll put bad info in it by = playing with it and then forgetting about it. The info they enter might = not even be valid. With those assumptions, I think the right *default* behavior is: 1) If you're an end device making an emergency call, and you have a = network-provided location and a manual location, use the = network-provided (understanding that there will always exist = configurable and custom devices that deviate from the recommended = default); I'd rather not even send the manual, by default. (Again, = configure it if you don't like the default.) But I could be swayed to = include the manual, as described in Section 3.3 of = sip-location-conveyance-08 -- it probably won't hurt. But only if the = manual location was valid (i.e., had been validated). It would be hard = to convince me that manual should be used for routing and put first in = the list of locations, as a recommended default. 2) Default server behavior will be to send clients the = network-determined location, if they get one. Again, if that's not the = desired behavior, then configure the thing. I think routers should be = more configurable that end devices in this regard. We need to set the default behaviors to meet the needs of the greater = majority of people. Let the others jump through a few hoops to get = things to work the way they want. We can't create rules that will meet = 100% of needs. Above all, be realistic -- devices with manual config = will exist. Just create reasonable rules and defaults so that lots of = people don't feel obliged to go out of their way to get devices that = don't abide by recommended behavior. Avoid rules that encourage lots of = people to lie to get what they want. Barbara -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, September 26, 2007 10:23 AM To: g.caron@bell.ca; khwolf1@gmail.com; Stark, Barbara Cc: ecrit@ietf.org Subject: RE: [Ecrit] multiple location sources Well, in the sense that today, there is no way for a subscriber to tell = a carrier that the location is X and not Y, you are correct. Imagine the following scenario: I have a family compound. It has 4 houses in 30 acres. We pay for a = single high speed Internet connection, and order 4 VoIP "lines", one for each = house with a LAN between the houses. To the carrier, there is one demarc = point, and one address for all four "lines". I come to you and say "If anyone calls from Line 1, the location is X1, line 2 is X2, ... I know someone = who has a set-up like this now. What will you do? If you behave like you do today, you will always send = Y and that's it. I won't speak for Canadians, but in the U.S, if you got a request like = that and a 9-1-1 call was sent to Y, you would likely not have a problem. However, if the subscriber told you again, and the next 9-1-1 call was = sent to Y, you would be in serious trouble (this happened recently, although = it was a simple data entry problem and not a = subscriber-knows-more-than-carrier problem). =20 You must have a manual method, and if the subscriber insists he is at X, = you MUST route on X. A difference between demarc and actual location is way = too easy to be significant these days. In the PSAP itself, the way this plays out is that you say you are at X, = and the ALI says you are at Y. The response goes to X. Always. The PSAP = never gets in trouble sending people to X. If they sent response only to Y, = it could be very bad news. If the caller actually was at Y, and they send responders to X, there would be no problem as long as the tape showed = they asked the guy the right questions. If the caller was an X and they send response to Y, they would be in big trouble. You always believe the = caller. You may question him carefully (which is why sending Y is a good idea), = but you respond to X. Brian > -----Original Message----- > From: g.caron@bell.ca [mailto:g.caron@bell.ca] > Sent: Wednesday, September 26, 2007 10:01 AM > To: br@brianrosen.net; khwolf1@gmail.com; bs7652@att.com > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] multiple location sources >=20 > I disagree in the context of ES. >=20 > The reverse should be done (route on Y and maybe send X as long as = there > is a mechanism to help the PSAP interpreting this situation) and let = the > call taker confirm the information through interaction with the = caller. > This is how it works today. >=20 > Guy Caron > -----Message d'origine----- > De=A0: Brian Rosen [mailto:br@brianrosen.net] > Envoy=E9=A0: 26 septembre 2007 09:50 > =C0=A0: 'Karl Heinz Wolf'; 'Stark, Barbara' > Cc=A0: 'ecrit' > Objet=A0: RE: [Ecrit] multiple location sources >=20 > Concerning manual location: >=20 > If a subscriber says he is at "X" and the carrier thinks the demark = point > is > "Y", you better route the call on and send "X". You probably want to = send > "Y" also. That mirrors what PSAPs do. >=20 > Brian >=20 > > -----Original Message----- > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > Sent: Wednesday, September 26, 2007 9:37 AM > > To: Stark, Barbara > > Cc: ecrit > > Subject: Re: [Ecrit] multiple location sources > > > > Thank you Barbara, for these useful documents from the DSL forum. > > I haven't read everything, but just two small comments so far: > > > > In Appendix A, Flow A, there is a line missing. "Was location in = DHCP > > response" has no "No" branching. It should connect to "Determine = LIS", > > I would suggest. > > > > Concerning Manual Configuration of Location Information: you use > > manual configuration only in case no other location determination = was > > successful. This is different to > > draft-ietf-geopriv-pdif-lo-profile-08, I think. If I understand > > Section 3.3. correctly, a separate PIDF document would be created > > containing the manual configuration even if automatic configuration > > was successful. > > > > karl heinz > > > > > > On 9/24/07, Stark, Barbara wrote: > > > Some of these are questions I was trying to address in the draft > > > document liaised from the DSL Forum to IETF > > > (see http://www1.ietf.org/mail- > archive/web/geopriv/current/msg04297.html > > > for link to documents), because I hadn't seen them addressed > elsewhere. > > > I'd be curious to hear if you find the flows in that document at = all > > > useful. I suggest in there that, in the absence of real = intelligence > for > > > selecting one location from multiple, that locations received from > lower > > > layers should be given preference over locations received from = higher > > > layers. When multiple locations are received using the same = protocol, > > > then the first received should be used. But this is for a = particular > > > physical interface. > > > > > > In the case of multiple physical interfaces, I suggest that the = device > > > should keep its location per physical interface. A call that goes = out > > > over a particular interface, should use the location associated = with > > > that interface. > > > > > > Again, this is suggested for the case where there is nothing on = which > to > > > base an informed decision. > > > Barbara > > > > > > -----Original Message----- > > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > > Sent: Monday, September 24, 2007 5:49 AM > > > To: ecrit > > > Subject: [Ecrit] multiple location sources > > > > > > Hi, > > > I'm working on a prototype SIP client that should be able to = determine > > > its location by DHCP, HELD and LLDP-MED. The PIDF-LO document is > > > included in the SIP INVITE body. I have several questions about = what > > > to do when there is more than one location source available. > > > > > > draft-ietf-sip-location-conveyance-08 recommends that there is = only > > > one location. Of course, all ways of location determination should > > > give the same location. But how can one verify if the same = location > > > was received via HELD and DHCP since a different format is used? > > > > > > Or when one gets two DHCP civic location messages via two = different > > > interfaces and some of the CAvalues are the same, but some not = (e.g. > > > one has an additional location information, the other has a = building > > > CAType). Is this the same location? > > > > > > Or think of the following situation. One gets a DHCP location > > > information via a wired connection (the location of the DHCP = server in > > > this building) and a LLDP-MED frame via WLAN of an access point in = the > > > next building (the location of the access point is announced). > > > draft-ietf-geopriv-pdif-lo-profile-08 gives some rules for = multiple > > > location information, but how can the device know which = information is > > > more adequate to get the right order? > > > > > > rfc4776 has a table with a mapping of CATypes and PIDF. When = conveying > > > location information in SIP messages, a PIDF document is needed. = So, > > > what to do with CATypes that have no mapping to PIDF? > > > > > > LLDP-MED has a "what" element, describing if the location of the > > > client itself, of the DHCP server or of the network element = closest to > > > the client is provided. This seems to be useful information, but = where > > > to put this in a PIDF document? > > > > > > I'm looking forward to your comments and suggestions. > > > > > > Ciao > > > Karl Heinz > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > ***** > > > > > > The information transmitted is intended only for the person or = entity > to > > which it is addressed and may contain confidential, proprietary, = and/or > > privileged material. Any review, retransmission, dissemination or = other > > use of, or taking of any action in reliance upon this information by > > persons or entities other than the intended recipient is prohibited. = If > > you received this in error, please contact the sender and delete the > > material from all computers. GA621 > > > > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Sep 26 14:17:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabQr-0000Eb-OS; Wed, 26 Sep 2007 14:16:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IabQq-0000E1-77 for ecrit@ietf.org; Wed, 26 Sep 2007 14:16:20 -0400 Received: from bellwecs2.bellnexxia.net ([207.236.237.114] helo=bellwecs2.srvr.bell.ca) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IabQo-0000ac-LB for ecrit@ietf.org; Wed, 26 Sep 2007 14:16:20 -0400 Received: (qmail 27188 invoked from network); 26 Sep 2007 18:16:18 -0000 Received: from g.caron@bell.ca by bellwecs2.srvr.bell.ca with EntrustECS-Server-7.4; 26 Sep 2007 18:16:18 -0000 Received: from bellwfep4.bellnexxia.net (HELO bellwfep4-srv.bellnexxia.net) (207.236.237.110) by bellwecs2.srvr.bell.ca with SMTP; 26 Sep 2007 18:16:17 -0000 Received: from TOROONDC918.bell.corp.bce.ca ([142.182.89.79]) by bellwfep4-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20070926181616.JFXS1989.bellwfep4-srv.bellnexxia.net@TOROONDC918.bell.corp.bce.ca>; Wed, 26 Sep 2007 14:16:16 -0400 Received: from toroondc912.bell.corp.bce.ca ([142.182.89.15]) by TOROONDC918.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Sep 2007 14:16:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] multiple location sources Date: Wed, 26 Sep 2007 14:16:11 -0400 Message-ID: <2E62ACF8ADDB4D4F89093CBFDF2FBAF30B54BC85@toroondc912> In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA05C40758@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] multiple location sources Thread-Index: AcgAQn58Z1wcYtysRTyWRBvQuJbXyQAAFcIAAACA+1AAAGXl0AAEVz6gAAI83gA= References: <7582BC68E4994F4ABF0BD4723975C3FA05C401AE@crexc41p> <01a101c80044$2994e8a0$640fa8c0@cis.neustar.com> <2E62ACF8ADDB4D4F89093CBFDF2FBAF30B54BBFA@toroondc912> <01ad01c80048$b5855a80$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA05C40758@crexc41p> From: To: , , X-OriginalArrivalTime: 26 Sep 2007 18:16:12.0208 (UTC) FILETIME=[51AF7B00:01C80069] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b 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 First, please don't make this a country-specific topic because it is = not. Second, forget about regulation. It is not the basis of my = position. I agree default behaviour for ES is required at the endpoint. IMO, use = of manual input location should be at the very bottom of the decision = tree. And even then, I'm not convinced this is a better default solution = than sending the call to a 3rd party if manual entry is only what you = have (acting as if no location was available). See the rest of my comments inline. Guy Caron -----Message d'origine----- De=A0: Stark, Barbara [mailto:bs7652@att.com]=20 Envoy=E9=A0: 26 septembre 2007 13:12 =C0=A0: Brian Rosen; Caron, Guy (A162859); khwolf1@gmail.com Cc=A0: ecrit@ietf.org Objet=A0: RE: [Ecrit] multiple location sources I think this is a perfect example as to why manual config is not a good = idea in an end device, but does need to be supported in home and = business routers. I think it's pretty safe to assume that a person, P1, living at X1 (in = Brian's 30 acre compound) will quickly learn that he can take the = telephone, T1, with him to gossip at X2, and everything works perfectly. = P1 can make calls on line 1 (L1), and receive them, no matter where T1 = happens to be! No way is P1 going to be updating location info, = everytime he leaves the house with T1. Imagine his joy when he discovers = that T1 not only works at X1-4, but it also works at the Wi-Fi enabled = barber shop, in town. Fortunately, he can leave T1' and T1'' at X1, so = his kids (P1'-P1''''') can still use L1, as well. VoIP is a wonderful = thing. On the other hand, that router serving the 4 homes will be relatively = static in location, and I think it would be a good idea to support = manual config, partly for the scenario Brian describes. [GC] Nope. You just reduced the impreciseness of the location but did = not cover the scenario I described in my previous mail. What I really wish we could seriously discuss, is desired default = behaviors. I think we have to accept that a) Manual configuration of all sorts of devices (end devices and = intermediary devices) will exist, no matter how hard regulators frown or = smile -- I mean, let's be realistic: No way is the Canadian government = going to fine me or throw me in jail, when I take my US laptop to Quebec = City, and it's subscribed to a Sierra Leone provider, and has a soft = client that I downloaded off the Internet that lets me manually = configure my location. There's nothing they can really do to keep = Canadian citizens from having configurable devices, either, if the = Canadian citizens so choose. Unless they intend to cut the Canadian = Internet off from the rest of the world, and close their borders... [GC] Who's talking about regulators? I'm not. What I'm saying is that = you can't rely on information inputted statically by users. This is bad = in ES context. You need a safeguard solution to validate the information = provided. This is done today, and will continue to be done as per PSAP = operation's procedures with VoIP, through interaction with the caller. = The scenario you described is exactly what you don't want to happen with = ES. If you are in Quebec City, your device is better choosing the = network-provided location to route if you dial 9-1-1. That is what you = want. Not doing so will indeed not send you to jail but may increase the = risks of a visit to the cemetery. b) There will exist devices where end users can set the logic of = location determination and acquisition. They can add protocols, remove = protocols, re-order protocols, enter 20 different manual locations with = rules as to which to use where, etc. Regulators can't prevent the = existence of these devices, or control the end users. [GC] Again, please forget about regulation. It is not the basis of my = position. What you describe may happen and I don't mind how this would = work in non-ES situations however, for ES we need less relax = rules/behaviours. c) The vast majority of people won't want to use manual configuration of = location, especially in end devices. In cases where they find a manual = config capability in a device, odds are they'll put bad info in it by = playing with it and then forgetting about it. The info they enter might = not even be valid. [GC] Agreed. However, if the capability of manually inputted location = exists at the endpoint with a relatively intuitive GUI, this will happen = and maybe more than we can think now.=20 With those assumptions, I think the right *default* behavior is: 1) If you're an end device making an emergency call, and you have a = network-provided location and a manual location, use the = network-provided (understanding that there will always exist = configurable and custom devices that deviate from the recommended = default); I'd rather not even send the manual, by default. (Again, = configure it if you don't like the default.) But I could be swayed to = include the manual, as described in Section 3.3 of = sip-location-conveyance-08 -- it probably won't hurt. But only if the = manual location was valid (i.e., had been validated). It would be hard = to convince me that manual should be used for routing and put first in = the list of locations, as a recommended default. [GC] Maybe there should be a timeout on those manual locations so they = are not persistent? This in conjunction with an ES flag on a per = location basis would seem like a reasonable solution. That is, the user = manually enters a location and decides if this information is to be used = for ES by setting a checkbox. If yes, the checkbox remain until the = timeout expires (24 hours?). It's not perfect but a good compromise. 2) Default server behavior will be to send clients the = network-determined location, if they get one. Again, if that's not the = desired behavior, then configure the thing. I think routers should be = more configurable that end devices in this regard. [GC] Routers are nomadic too. Bolt it to the house and I'm fine with = that. We need to set the default behaviors to meet the needs of the greater = majority of people. Let the others jump through a few hoops to get = things to work the way they want. We can't create rules that will meet = 100% of needs. Above all, be realistic -- devices with manual config = will exist. Just create reasonable rules and defaults so that lots of = people don't feel obliged to go out of their way to get devices that = don't abide by recommended behavior. Avoid rules that encourage lots of = people to lie to get what they want. [GC] Manual config will exist, no argument here. I just prefer this = information not to be used for ES. Barbara -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, September 26, 2007 10:23 AM To: g.caron@bell.ca; khwolf1@gmail.com; Stark, Barbara Cc: ecrit@ietf.org Subject: RE: [Ecrit] multiple location sources Well, in the sense that today, there is no way for a subscriber to tell = a carrier that the location is X and not Y, you are correct. Imagine the following scenario: I have a family compound. It has 4 houses in 30 acres. We pay for a = single high speed Internet connection, and order 4 VoIP "lines", one for each = house with a LAN between the houses. To the carrier, there is one demarc = point, and one address for all four "lines". I come to you and say "If anyone calls from Line 1, the location is X1, line 2 is X2, ... I know someone = who has a set-up like this now. What will you do? If you behave like you do today, you will always send = Y and that's it. I won't speak for Canadians, but in the U.S, if you got a request like = that and a 9-1-1 call was sent to Y, you would likely not have a problem. However, if the subscriber told you again, and the next 9-1-1 call was = sent to Y, you would be in serious trouble (this happened recently, although = it was a simple data entry problem and not a = subscriber-knows-more-than-carrier problem). =20 You must have a manual method, and if the subscriber insists he is at X, = you MUST route on X. A difference between demarc and actual location is way = too easy to be significant these days. In the PSAP itself, the way this plays out is that you say you are at X, = and the ALI says you are at Y. The response goes to X. Always. The PSAP = never gets in trouble sending people to X. If they sent response only to Y, = it could be very bad news. If the caller actually was at Y, and they send responders to X, there would be no problem as long as the tape showed = they asked the guy the right questions. If the caller was an X and they send response to Y, they would be in big trouble. You always believe the = caller. You may question him carefully (which is why sending Y is a good idea), = but you respond to X. Brian > -----Original Message----- > From: g.caron@bell.ca [mailto:g.caron@bell.ca] > Sent: Wednesday, September 26, 2007 10:01 AM > To: br@brianrosen.net; khwolf1@gmail.com; bs7652@att.com > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] multiple location sources >=20 > I disagree in the context of ES. >=20 > The reverse should be done (route on Y and maybe send X as long as = there > is a mechanism to help the PSAP interpreting this situation) and let = the > call taker confirm the information through interaction with the = caller. > This is how it works today. >=20 > Guy Caron > -----Message d'origine----- > De=A0: Brian Rosen [mailto:br@brianrosen.net] > Envoy=E9=A0: 26 septembre 2007 09:50 > =C0=A0: 'Karl Heinz Wolf'; 'Stark, Barbara' > Cc=A0: 'ecrit' > Objet=A0: RE: [Ecrit] multiple location sources >=20 > Concerning manual location: >=20 > If a subscriber says he is at "X" and the carrier thinks the demark = point > is > "Y", you better route the call on and send "X". You probably want to = send > "Y" also. That mirrors what PSAPs do. >=20 > Brian >=20 > > -----Original Message----- > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > Sent: Wednesday, September 26, 2007 9:37 AM > > To: Stark, Barbara > > Cc: ecrit > > Subject: Re: [Ecrit] multiple location sources > > > > Thank you Barbara, for these useful documents from the DSL forum. > > I haven't read everything, but just two small comments so far: > > > > In Appendix A, Flow A, there is a line missing. "Was location in = DHCP > > response" has no "No" branching. It should connect to "Determine = LIS", > > I would suggest. > > > > Concerning Manual Configuration of Location Information: you use > > manual configuration only in case no other location determination = was > > successful. This is different to > > draft-ietf-geopriv-pdif-lo-profile-08, I think. If I understand > > Section 3.3. correctly, a separate PIDF document would be created > > containing the manual configuration even if automatic configuration > > was successful. > > > > karl heinz > > > > > > On 9/24/07, Stark, Barbara wrote: > > > Some of these are questions I was trying to address in the draft > > > document liaised from the DSL Forum to IETF > > > (see http://www1.ietf.org/mail- > archive/web/geopriv/current/msg04297.html > > > for link to documents), because I hadn't seen them addressed > elsewhere. > > > I'd be curious to hear if you find the flows in that document at = all > > > useful. I suggest in there that, in the absence of real = intelligence > for > > > selecting one location from multiple, that locations received from > lower > > > layers should be given preference over locations received from = higher > > > layers. When multiple locations are received using the same = protocol, > > > then the first received should be used. But this is for a = particular > > > physical interface. > > > > > > In the case of multiple physical interfaces, I suggest that the = device > > > should keep its location per physical interface. A call that goes = out > > > over a particular interface, should use the location associated = with > > > that interface. > > > > > > Again, this is suggested for the case where there is nothing on = which > to > > > base an informed decision. > > > Barbara > > > > > > -----Original Message----- > > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > > Sent: Monday, September 24, 2007 5:49 AM > > > To: ecrit > > > Subject: [Ecrit] multiple location sources > > > > > > Hi, > > > I'm working on a prototype SIP client that should be able to = determine > > > its location by DHCP, HELD and LLDP-MED. The PIDF-LO document is > > > included in the SIP INVITE body. I have several questions about = what > > > to do when there is more than one location source available. > > > > > > draft-ietf-sip-location-conveyance-08 recommends that there is = only > > > one location. Of course, all ways of location determination should > > > give the same location. But how can one verify if the same = location > > > was received via HELD and DHCP since a different format is used? > > > > > > Or when one gets two DHCP civic location messages via two = different > > > interfaces and some of the CAvalues are the same, but some not = (e.g. > > > one has an additional location information, the other has a = building > > > CAType). Is this the same location? > > > > > > Or think of the following situation. One gets a DHCP location > > > information via a wired connection (the location of the DHCP = server in > > > this building) and a LLDP-MED frame via WLAN of an access point in = the > > > next building (the location of the access point is announced). > > > draft-ietf-geopriv-pdif-lo-profile-08 gives some rules for = multiple > > > location information, but how can the device know which = information is > > > more adequate to get the right order? > > > > > > rfc4776 has a table with a mapping of CATypes and PIDF. When = conveying > > > location information in SIP messages, a PIDF document is needed. = So, > > > what to do with CATypes that have no mapping to PIDF? > > > > > > LLDP-MED has a "what" element, describing if the location of the > > > client itself, of the DHCP server or of the network element = closest to > > > the client is provided. This seems to be useful information, but = where > > > to put this in a PIDF document? > > > > > > I'm looking forward to your comments and suggestions. > > > > > > Ciao > > > Karl Heinz > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > ***** > > > > > > The information transmitted is intended only for the person or = entity > to > > which it is addressed and may contain confidential, proprietary, = and/or > > privileged material. Any review, retransmission, dissemination or = other > > use of, or taking of any action in reliance upon this information by > > persons or entities other than the intended recipient is prohibited. = If > > you received this in error, please contact the sender and delete the > > material from all computers. GA621 > > > > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 27 09:20:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IatHg-0005Mp-SJ; Thu, 27 Sep 2007 09:20:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IatHf-0005Lo-AH for ecrit@ietf.org; Thu, 27 Sep 2007 09:20:03 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IatHY-0005oq-7B for ecrit@ietf.org; Thu, 27 Sep 2007 09:20:03 -0400 Received: by ug-out-1314.google.com with SMTP id u2so4342364uge for ; Thu, 27 Sep 2007 06:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=pa/2x+Y2b216kcAAgWR6PVy9ekYsa4Aj2uXbvYWn/4A=; b=T+R5jGBng+V2sOha/aFNbW4kvK9BfVLkJhK+eV5gua+b+U6feiqppq4lVPhmJxhEUN9M4wheZTJTwjjACfUNDsZy9PebkhQ0cX21bHJHk3EQqOiPbf+NBDDLzpKpzc2AAFuZzxY8HlIiOaAc0cgYpfDY1LyzP64jAnLWMzbU4qk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WeiEfHgA+B7rZONRotHZxn3qFFZlRdhdtxhdkqswaCzYRV2UcE9qeFk/wkt6Zh12ZW97ID4/3mmXjJsi+QUyJIZh5l6I6QREvVVSr7Kiv+SrTm+sK7POfBhE/nSOpbHdJUKt44ZWQ2VQM6rURSk12ZLsjKESIUkSgE1r5NW8U5M= Received: by 10.66.221.17 with SMTP id t17mr3568191ugg.1190899175160; Thu, 27 Sep 2007 06:19:35 -0700 (PDT) Received: by 10.86.91.5 with HTTP; Thu, 27 Sep 2007 06:19:35 -0700 (PDT) Message-ID: Date: Thu, 27 Sep 2007 15:19:35 +0200 From: "Karl Heinz Wolf" To: "Stark, Barbara" Subject: Re: [Ecrit] multiple location sources In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA05C406DF@crexc41p> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7582BC68E4994F4ABF0BD4723975C3FA05C401AE@crexc41p> <7582BC68E4994F4ABF0BD4723975C3FA05C406DF@crexc41p> X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: ecrit X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Barbara, I have read your requirements document now, and I'd like to post a few comments. First I want to say that this is a good document that clarifies things. Thank you, Barbara. Client.manual 1: why not geo? Client.sequence.general.7: what about unplugging a cable, should the knowledge of successful means also not be stored? also Client.sequence.general.7: "Do we have a rule for LLDP-MED?": I believe yes, every LLDP frame has a Time To Live TTL TLV (type 3), which is mandatory for LLDP according to IEEE Std. chapter 9.5.4. Client.sequence.L7.1: which sequence? The sequence of LIS servers? Server.Protocol.15: why should manually configured and GPS locations just be sent using HELD? Why not with the other protocols, too? Besides, according to your document, the server may even not support HELD. That confuses me a bit. karl heinz On 9/26/07, Stark, Barbara wrote: > Karl Heinz, > Thanks for your feedback. I'll fix the DHCP response "No" branch in my > next version. > > As for the manual configuration comment -- > I didn't read pidf-lo-profile-08 Section 3.3 as recommending that the > manual config necessarily be included. It's a good question, though, and > I think you've done a great job at starting discussion on this on the > list. > Barbara > > -----Original Message----- > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > Sent: Wednesday, September 26, 2007 9:37 AM > To: Stark, Barbara > Cc: ecrit > Subject: Re: [Ecrit] multiple location sources > > Thank you Barbara, for these useful documents from the DSL forum. > I haven't read everything, but just two small comments so far: > > In Appendix A, Flow A, there is a line missing. "Was location in DHCP > response" has no "No" branching. It should connect to "Determine LIS", > I would suggest. > > Concerning Manual Configuration of Location Information: you use > manual configuration only in case no other location determination was > successful. This is different to > draft-ietf-geopriv-pdif-lo-profile-08, I think. If I understand > Section 3.3. correctly, a separate PIDF document would be created > containing the manual configuration even if automatic configuration > was successful. > > karl heinz > > > On 9/24/07, Stark, Barbara wrote: > > Some of these are questions I was trying to address in the draft > > document liaised from the DSL Forum to IETF > > (see > http://www1.ietf.org/mail-archive/web/geopriv/current/msg04297.html > > for link to documents), because I hadn't seen them addressed > elsewhere. > > I'd be curious to hear if you find the flows in that document at all > > useful. I suggest in there that, in the absence of real intelligence > for > > selecting one location from multiple, that locations received from > lower > > layers should be given preference over locations received from higher > > layers. When multiple locations are received using the same protocol, > > then the first received should be used. But this is for a particular > > physical interface. > > > > In the case of multiple physical interfaces, I suggest that the device > > should keep its location per physical interface. A call that goes out > > over a particular interface, should use the location associated with > > that interface. > > > > Again, this is suggested for the case where there is nothing on which > to > > base an informed decision. > > Barbara > > > > -----Original Message----- > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > Sent: Monday, September 24, 2007 5:49 AM > > To: ecrit > > Subject: [Ecrit] multiple location sources > > > > Hi, > > I'm working on a prototype SIP client that should be able to determine > > its location by DHCP, HELD and LLDP-MED. The PIDF-LO document is > > included in the SIP INVITE body. I have several questions about what > > to do when there is more than one location source available. > > > > draft-ietf-sip-location-conveyance-08 recommends that there is only > > one location. Of course, all ways of location determination should > > give the same location. But how can one verify if the same location > > was received via HELD and DHCP since a different format is used? > > > > Or when one gets two DHCP civic location messages via two different > > interfaces and some of the CAvalues are the same, but some not (e.g. > > one has an additional location information, the other has a building > > CAType). Is this the same location? > > > > Or think of the following situation. One gets a DHCP location > > information via a wired connection (the location of the DHCP server in > > this building) and a LLDP-MED frame via WLAN of an access point in the > > next building (the location of the access point is announced). > > draft-ietf-geopriv-pdif-lo-profile-08 gives some rules for multiple > > location information, but how can the device know which information is > > more adequate to get the right order? > > > > rfc4776 has a table with a mapping of CATypes and PIDF. When conveying > > location information in SIP messages, a PIDF document is needed. So, > > what to do with CATypes that have no mapping to PIDF? > > > > LLDP-MED has a "what" element, describing if the location of the > > client itself, of the DHCP server or of the network element closest to > > the client is provided. This seems to be useful information, but where > > to put this in a PIDF document? > > > > I'm looking forward to your comments and suggestions. > > > > Ciao > > Karl Heinz > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > ***** > > > > The information transmitted is intended only for the person or entity > to which it is addressed and may contain confidential, proprietary, > and/or privileged material. Any review, retransmission, dissemination or > other use of, or taking of any action in reliance upon this information > by persons or entities other than the intended recipient is prohibited. > If you received this in error, please contact the sender and delete the > material from all computers. GA621 > > > > > > > > ***** > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625 > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 27 15:43:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IazFX-0000eU-PP; Thu, 27 Sep 2007 15:42:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IazFV-0000VX-BA for ecrit@ietf.org; Thu, 27 Sep 2007 15:42:13 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IazFU-0004eZ-4z for ecrit@ietf.org; Thu, 27 Sep 2007 15:42:13 -0400 X-IronPort-AV: E=Sophos;i="4.21,204,1188792000"; d="scan'208";a="133201508" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 27 Sep 2007 15:42:07 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8RJgBVg015715; Thu, 27 Sep 2007 15:42:11 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l8RJfcPe023320; Thu, 27 Sep 2007 19:42:04 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 15:41:55 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.20.158]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 15:41:54 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 27 Sep 2007 14:41:54 -0500 To: "Roger Marshall" From: "James M. Polk" Subject: Re: [ECRIT] wg Status Update - as of 9/25/07 In-Reply-To: <8C837214C95C864C9F34F3635C2A657508493B4B@SEA-EXCHVS-2.tele comsys.com> References: <8C837214C95C864C9F34F3635C2A657508493B4B@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 27 Sep 2007 19:41:55.0054 (UTC) FILETIME=[757940E0:01C8013E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11700; t=1190922131; x=1191786131; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[ECRIT]=20wg=20Status=20Update=20-=20as=20of=209/25/0 7 |Sender:=20 |To:=20=22Roger=20Marshall=22=20; bh=0A/9LYikKF5NFt2Mu2M227yhVVH7AdPqs6pj8kTaDCw=; b=E7BMpk33ZHfdwbeFM11s/v7/FCYiwtntqqlYqDxkn1ZxRluxB08/7AfZoTzJdHlN+kE8AF/G tcpe98MzaUOJWfcwXBRMJa4VQHSd0aWyWmDbHYdP5n9z9Zn4eZBNHjBP; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: be922d419820e291bde1362184dc32fd Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Roger I've asked the chairs to ask the WG for WG comments on http://www.ietf.org/internet-drafts/draft-polk-ecrit-local-emergency-rph-namespace-01.txt becoming a WG item. This occurred both in a 8/2/07 email, and on a 9/7/07 call discussing the phoneBCP that you, Hannes and Marc were on. The comments on that call indicated the chairs should ask the WG to adopt this ID, and Hannes said he would, but has not to date (and I don't know why). Given that Hannes made me present this ID for ~20 minutes in Chicago, on 30 minutes notice to build the preso (during the meeting), I do not believe this ID should be ignored when giving this type of WG update, do you? I'm sure this was just an oversight.... ;-) James At 10:34 PM 9/25/2007, Roger Marshall wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C7FFEE.1EB1B2F6" > > >ECRIT WG Status Update - Sept 2007 >================================== > >Upcoming IETF Meeting >===================== > >The next ECRIT (IETF70) meeting is scheduled for Dec 2-7, Vancouver B.C. See: >http://www3.ietf.org/meetings/70-IETF.html > > >Other information: > >There is a new Web-based tool that can be used now to submit a new >draft, see: >http://www1.ietf.org/mail-archive/web/ecrit/current/msg04384.html > > >The meeting minutes from the last IETF69 are here: >http://www3.ietf.org/proceedings/07jul/minutes/ecrit.txt > >In addition, there is some progress on some of the wg related documents. > >Prior status reports are posted to the ECRIT WG status site. See: >http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/EcritStatusUpdate > >Document Status >=============== > >In the RFC Editor's Queue >========================= > >Requirements for Emergency Context Resolution with Internet Technologies >------------------------------------------------------------------------ >Draft is moving through the "RFC Ed Queue" - seems close to being published: >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-13.txt > > >A Uniform Resource Name (URN) for Services >------------------------------------------ >Draft has moved to the "RFC Ed Queue" as of 8/21/07: >http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service-urn-07.txt > > >Security Threats and Requirements for Emergency Call Marking and Mapping >------------------------------------------------------------------------ >The new (-05) Draft version has moved to the "RFC Ed Queue" as of 9/12/07. >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-security-threats-05.txt > > >PROTO Documents >=============== > >The document shepherding process is described in: >http://tools.ietf.org/id/draft-ietf-proto-wgchair-doc-shepherding-07.txt > > >LoST: A Location-to-Service Translation Protocol >------------------------------------------------ >PROTO writeup has been sent to the Area Directors and the IESG to >complete the work. >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-06.txt > > >Location-to-URL Mapping Architecture and Framework >-------------------------------------------------- >PROTO WRITEUP has been sent to the Area Directors and the IESG to >complete work. >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-mapping-arch-02.txt > > >A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service >Translation Protocol (LoST) Discovery Procedure >---------------------------------------------------------------------- >PROTO WRITEUP has been sent to the Area Directors and the IESG to >complete work. >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-02.txt > > >Other WG Drafts >=============== > >The (two) remaining ECRIT WG Drafts, below, have been updated. > >Framework for Emergency Calling using Internet Multimedia >--------------------------------------------------------- >New Draft version published as of 9/19/07. Needs additional WG review. >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-03.txt > > >Best Current Practice for Communications Services in support of >Emergency Calling >--------------------------------------------------------------------------------- > >New Draft version published as of 9/19/07. Needs additional WG review. >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-02.txt > > > >Individual Drafts >================= > >Location Hiding: Problem Statement and Requirements >--------------------------------------------------- >An updated draft has been produced, see: >http://tools.ietf.org/wg/ecrit/draft-schulzrinne-ecrit-location-hiding-requirements-01.txt > > >Last action on this was: "Initiate discussion after the main WG >items have been progressed." > >Action: ECRIT chairs to determine level of effort, since other items >now progressed. > >Extensions to the Emergency Services Architecture for dealing with >Unauthenticated and Unauthorized Devices >-------------------------------------------------------------------------------------- > >Initial draft version has been submitted. >http://tools.ietf.org/wg/ecrit/draft-schulzrinne-ecrit-unauthenticated-access-00.txt > > >There is a IEEE liaison msg. which references the above draft, see: >http://www1.ietf.org/mail-archive/web/ecrit/current/msg04361.html > > >Emergency Call Marking >---------------------- > From last report, it was stated: >"The initially assumed solution, >http://tools.ietf.org/wg/sip/draft-rosenberg-sip-ua-loose-route-01.txt, > >was not accepted at the IETF meeting." > >Some discussion has taken place entitled "UA Loose Routing", see: >http://www1.ietf.org/mail-archive/web/ecrit/current/msg04308.html > > >And "call marking", see: >http://www1.ietf.org/mail-archive/web/ecrit/current/msg04310.html > >Which Richard reintroduced, and which there appears to be no common >resolution for yet, see Brian's response on probable action by most >proxies, see: > >http://www1.ietf.org/mail-archive/web/ecrit/current/msg04319.html > > >Proxy Authentication of the Emergency Status of SIP Calls >--------------------------------------------------------- > From last report, it was stated, >"A lot of the discussions in the last few weeks focused on >http://tools.ietf.org/wg/ecrit/draft-barnes-ecrit-auth-00.txt > >Action Item: Summary needs to be compiled." > >Action: Need to determine next steps. > >Overview of the IETF Emergency Services Architecture >---------------------------------------------------- >Restated from the last report: >"The following document gives an overview of the emergency services >architecture: >http://tools.ietf.org/wg/ecrit/draft-tschofenig-ecrit-architecture-overview-00.txt > > >It is meant to be read by members from other SDOs and regulators." > >DSL Forum Documents >------------------- > >The following referenced document were made available from the DSL >Forum. An initial review was made by Hannes Tschofenig, see: > >http://www1.ietf.org/mail-archive/web/ecrit/current/msg04320.html > > >Additional comments have been logged to the list, see: >http://www1.ietf.org/mail-archive/web/ecrit/current/mail3.html > > >Alignment between IETF and 3GPP Emergency Services Architecture >--------------------------------------------------------------- > From the last report, >"[Hannes]... has the action item to schedule a conference >call within the IETF ECRIT WG and subsequently between IETF ECRIT >and the 3GPP to discuss a possible alignment." > >3rd SDO Emergency Services Workshop >----------------------------------- > >The next workshop (ESW03-07) is scheduled for a 3 day meeting (October 30st - >November 1st) in Brussels/Belgium (3 day mtg.). > >Meeting information can be found here: >http://www.emergency-services-coordination.info/2007Nov/ > > >A first version of the agenda is also available: >https://lists.cs.columbia.edu/pipermail/es-coordination/2007-August/000050.html > > >Tuesday, October 30: >-------- > >Tutorials about IETF, 3GPP and NENA architectures > >u2010 meeting the standards > >Wednesday, October 31: >---------- > >Policy Panel > >Status Updates > * IETF (GEOPRIV, ECRIT, SIP) > * DSL Forum > * IEEE > * ATIS-ESIF > * NENA > * ETSI EMTEL > * 3GPP > * 3GPP2 > * ETSI TISPAN > * FCC > * Open Mobile Alliance (OMA) > * TIA > * US Department of Transportation > * OCG > * EU Commission > * Wimax Forum > * WiFi Forum/Alliance > * APCO Project 41 > * COMCAST > * NIST > >Thursday, November 1: >--------- > >Status Updates (con't) > >Authority-to-Citizen Communication > Requirements > What's available now > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > > >Roger Marshall > > > >The information contained in this message may be privileged and/or >confidential. If you are not the intended recipient, or responsible >for delivering this message to the intended recipient, any review, >forwarding, dissemination, distribution or copying of this >communication or any attachment(s) is strictly prohibited. If you >have received this message in error, please so notify the sender >immediately, and delete it and all attachments from your computer and network. > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 27 16:37:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib061-00080d-Ab; Thu, 27 Sep 2007 16:36:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib060-0007ie-3Y for ecrit@ietf.org; Thu, 27 Sep 2007 16:36:28 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ib05s-0001nK-Gn for ecrit@ietf.org; Thu, 27 Sep 2007 16:36:22 -0400 Received: (qmail 7497 invoked by uid 0); 27 Sep 2007 20:36:03 -0000 Received: from 90.187.16.242 by www138.gmx.net with HTTP; Thu, 27 Sep 2007 22:36:03 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" Date: Thu, 27 Sep 2007 22:36:03 +0200 From: "Hannes Tschofenig" In-Reply-To: Message-ID: <20070927203603.101040@gmx.net> MIME-Version: 1.0 References: <8C837214C95C864C9F34F3635C2A657508493B4B@SEA-EXCHVS-2.telecomsys.com> Subject: Re: [ECRIT] wg Status Update - as of 9/25/07 To: "James M. Polk" , RMarshall@telecomsys.com X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1/6tu4e7uP6UoRqGxcJNIRY3m9OBxEaYaLBrfeCDT dj0pvjb2KpkELtjpj3P3W0n3odTCpUHoDf7A== Content-Transfer-Encoding: 7bit X-GMX-UID: XGGVdTVpeWUkV4EFq25nc4YjL0tsZo3j X-Spam-Score: 0.0 (/) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 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 James, regarding your draft: I have asked our ADs whether they are OK with adding that document to the charter (if the WG agrees). Our ADs, however, insisted on finishing the current documents first before we add any new items. I agree that this is a useful approach. I posted that in a mail to the mailing list somewhere; I need to find the mail and then I should also add it to the status update. Ciao Hannes -------- Original-Nachricht -------- > Datum: Thu, 27 Sep 2007 14:41:54 -0500 > Von: "James M. Polk" > An: "Roger Marshall" > CC: "ECRIT" , "Hannes Tschofenig" , "Marc Linsner" > Betreff: Re: [ECRIT] wg Status Update - as of 9/25/07 > Roger > > I've asked the chairs to ask the WG for WG comments on > http://www.ietf.org/internet-drafts/draft-polk-ecrit-local-emergency-rph-namespace-01.txt > becoming a WG item. This occurred both in a 8/2/07 email, and on a > 9/7/07 call discussing the phoneBCP that you, Hannes and Marc were > on. The comments on that call indicated the chairs should ask the WG > to adopt this ID, and Hannes said he would, but has not to date (and > I don't know why). > > Given that Hannes made me present this ID for ~20 minutes in Chicago, > on 30 minutes notice to build the preso (during the meeting), I do > not believe this ID should be ignored when giving this type of WG > update, do you? > > I'm sure this was just an oversight.... ;-) > > James > > At 10:34 PM 9/25/2007, Roger Marshall wrote: > >Content-class: urn:content-classes:message > >Content-Type: multipart/alternative; > > boundary="----_=_NextPart_001_01C7FFEE.1EB1B2F6" > > > > > >ECRIT WG Status Update - Sept 2007 > >================================== > > > >Upcoming IETF Meeting > >===================== > > > >The next ECRIT (IETF70) meeting is scheduled for Dec 2-7, Vancouver B.C. > See: > >http://www3.ietf.org/meetings/70-IETF.html > > > > > >Other information: > > > >There is a new Web-based tool that can be used now to submit a new > >draft, see: > >http://www1.ietf.org/mail-archive/web/ecrit/current/msg04384.html > > > > > >The meeting minutes from the last IETF69 are here: > >http://www3.ietf.org/proceedings/07jul/minutes/ecrit.txt > > > >In addition, there is some progress on some of the wg related documents. > > > >Prior status reports are posted to the ECRIT WG status site. See: > >http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/EcritStatusUpdate > > > >Document Status > >=============== > > > >In the RFC Editor's Queue > >========================= > > > >Requirements for Emergency Context Resolution with Internet Technologies > >------------------------------------------------------------------------ > >Draft is moving through the "RFC Ed Queue" - seems close to being > published: > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-13.txt > > > > > >A Uniform Resource Name (URN) for Services > >------------------------------------------ > >Draft has moved to the "RFC Ed Queue" as of 8/21/07: > >http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service-urn-07.txt > > > > > >Security Threats and Requirements for Emergency Call Marking and Mapping > >------------------------------------------------------------------------ > >The new (-05) Draft version has moved to the "RFC Ed Queue" as of > 9/12/07. > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-security-threats-05.txt > > > > > >PROTO Documents > >=============== > > > >The document shepherding process is described in: > >http://tools.ietf.org/id/draft-ietf-proto-wgchair-doc-shepherding-07.txt > > > > > >LoST: A Location-to-Service Translation Protocol > >------------------------------------------------ > >PROTO writeup has been sent to the Area Directors and the IESG to > >complete the work. > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-06.txt > > > > > >Location-to-URL Mapping Architecture and Framework > >-------------------------------------------------- > >PROTO WRITEUP has been sent to the Area Directors and the IESG to > >complete work. > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-mapping-arch-02.txt > > > > > >A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service > >Translation Protocol (LoST) Discovery Procedure > >---------------------------------------------------------------------- > >PROTO WRITEUP has been sent to the Area Directors and the IESG to > >complete work. > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-02.txt > > > > > >Other WG Drafts > >=============== > > > >The (two) remaining ECRIT WG Drafts, below, have been updated. > > > >Framework for Emergency Calling using Internet Multimedia > >--------------------------------------------------------- > >New Draft version published as of 9/19/07. Needs additional WG review. > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-03.txt > > > > > >Best Current Practice for Communications Services in support of > >Emergency Calling > >--------------------------------------------------------------------------------- > > > >New Draft version published as of 9/19/07. Needs additional WG review. > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-02.txt > > > > > > > >Individual Drafts > >================= > > > >Location Hiding: Problem Statement and Requirements > >--------------------------------------------------- > >An updated draft has been produced, see: > >http://tools.ietf.org/wg/ecrit/draft-schulzrinne-ecrit-location-hiding-requirements-01.txt > > > > > >Last action on this was: "Initiate discussion after the main WG > >items have been progressed." > > > >Action: ECRIT chairs to determine level of effort, since other items > >now progressed. > > > >Extensions to the Emergency Services Architecture for dealing with > >Unauthenticated and Unauthorized Devices > >-------------------------------------------------------------------------------------- > > > >Initial draft version has been submitted. > >http://tools.ietf.org/wg/ecrit/draft-schulzrinne-ecrit-unauthenticated-access-00.txt > > > > > >There is a IEEE liaison msg. which references the above draft, see: > >http://www1.ietf.org/mail-archive/web/ecrit/current/msg04361.html > > > > > >Emergency Call Marking > >---------------------- > > From last report, it was stated: > >"The initially assumed solution, > >http://tools.ietf.org/wg/sip/draft-rosenberg-sip-ua-loose-route-01.txt, > > > >was not accepted at the IETF meeting." > > > >Some discussion has taken place entitled "UA Loose Routing", see: > >http://www1.ietf.org/mail-archive/web/ecrit/current/msg04308.html > > > > > >And "call marking", see: > >http://www1.ietf.org/mail-archive/web/ecrit/current/msg04310.html > > > >Which Richard reintroduced, and which there appears to be no common > >resolution for yet, see Brian's response on probable action by most > >proxies, see: > > > >http://www1.ietf.org/mail-archive/web/ecrit/current/msg04319.html > > > > > >Proxy Authentication of the Emergency Status of SIP Calls > >--------------------------------------------------------- > > From last report, it was stated, > >"A lot of the discussions in the last few weeks focused on > >http://tools.ietf.org/wg/ecrit/draft-barnes-ecrit-auth-00.txt > > > >Action Item: Summary needs to be compiled." > > > >Action: Need to determine next steps. > > > >Overview of the IETF Emergency Services Architecture > >---------------------------------------------------- > >Restated from the last report: > >"The following document gives an overview of the emergency services > >architecture: > >http://tools.ietf.org/wg/ecrit/draft-tschofenig-ecrit-architecture-overview-00.txt > > > > > >It is meant to be read by members from other SDOs and regulators." > > > >DSL Forum Documents > >------------------- > > > >The following referenced document were made available from the DSL > >Forum. An initial review was made by Hannes Tschofenig, see: > > > >http://www1.ietf.org/mail-archive/web/ecrit/current/msg04320.html > > > > > >Additional comments have been logged to the list, see: > >http://www1.ietf.org/mail-archive/web/ecrit/current/mail3.html > > > > > >Alignment between IETF and 3GPP Emergency Services Architecture > >--------------------------------------------------------------- > > From the last report, > >"[Hannes]... has the action item to schedule a conference > >call within the IETF ECRIT WG and subsequently between IETF ECRIT > >and the 3GPP to discuss a possible alignment." > > > >3rd SDO Emergency Services Workshop > >----------------------------------- > > > >The next workshop (ESW03-07) is scheduled for a 3 day meeting (October > 30st - > >November 1st) in Brussels/Belgium (3 day mtg.). > > > >Meeting information can be found here: > >http://www.emergency-services-coordination.info/2007Nov/ > > > > > >A first version of the agenda is also available: > >https://lists.cs.columbia.edu/pipermail/es-coordination/2007-August/000050.html > > > > > >Tuesday, October 30: > >-------- > > > >Tutorials about IETF, 3GPP and NENA architectures > > > >u2010 meeting the standards > > > >Wednesday, October 31: > >---------- > > > >Policy Panel > > > >Status Updates > > * IETF (GEOPRIV, ECRIT, SIP) > > * DSL Forum > > * IEEE > > * ATIS-ESIF > > * NENA > > * ETSI EMTEL > > * 3GPP > > * 3GPP2 > > * ETSI TISPAN > > * FCC > > * Open Mobile Alliance (OMA) > > * TIA > > * US Department of Transportation > > * OCG > > * EU Commission > > * Wimax Forum > > * WiFi Forum/Alliance > > * APCO Project 41 > > * COMCAST > > * NIST > > > >Thursday, November 1: > >--------- > > > >Status Updates (con't) > > > >Authority-to-Citizen Communication > > Requirements > > What's available now > > > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit > > > > > >Roger Marshall > > > > > > > >The information contained in this message may be privileged and/or > >confidential. If you are not the intended recipient, or responsible > >for delivering this message to the intended recipient, any review, > >forwarding, dissemination, distribution or copying of this > >communication or any attachment(s) is strictly prohibited. If you > >have received this message in error, please so notify the sender > >immediately, and delete it and all attachments from your computer and > network. > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Sep 27 18:26:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib1oY-0004lw-Dd; Thu, 27 Sep 2007 18:26:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib1oV-0004GY-K1 for ecrit@ietf.org; Thu, 27 Sep 2007 18:26:31 -0400 Received: from sea-mimesweep-1.telecomsys.com ([206.173.41.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ib1oQ-0000Lm-Pg for ecrit@ietf.org; Thu, 27 Sep 2007 18:26:28 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Thu, 27 Sep 2007 15:26:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ECRIT] wg Status Update - as of 9/25/07 Date: Thu, 27 Sep 2007 15:26:57 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575084F60E7@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ECRIT] wg Status Update - as of 9/25/07 Thread-Index: AcgBPpVqGqTJQR9GQ4eHLq1LkJf0SgAAFNBQ References: <8C837214C95C864C9F34F3635C2A657508493B4B@SEA-EXCHVS-2.telecomsys.com> From: "Roger Marshall" To: "James M. Polk" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8df1ceff7d5e1ba4a25ab9834397277b Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org James: Yes, indeed an oversight on my part. This was not the only omission however, so I apologize to both you and Steve Norreys for leaving out the status of the following two drafts. The following information should be appended to the prior ecrit wg status report, sent on 9/25/07: Individual Drafts (continued) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 IANA Registering a SIP Resource Priority Header Namespace for Local Emergency Communications ------------------------------------------------------------------------ ----- -------------- Has been requested of the chair(s) to become a wg draft.=20 http://www.ietf.org/internet-drafts/draft-polk-ecrit-local-emergency-rph -namespace-01.txt Action: Chairs to ask the workgroup. Requirements for Authority-to-Individuals Communication for Emergency Situations --------------------------------------------------------------------- ---------- Steve Norreys gave a presentation last year on this, and subsequently during IETF69, facilitated a lunch-time BOF meeting on 7/23/07. http://www.ietf.org/internet-drafts/draft-norreys-ecrit-authority2indivi duals-requirements-00.txt Some review and comments took place around 7/05, see: http://www1.ietf.org/mail-archive/web/ecrit/current/mail15.html The meeting minutes from the meeting are available, see: http://www1.ietf.org/mail-archive/web/ecrit/current/msg04196.html Action: Per the minutes, it was mentioned that consideration is needed, in order to make sure that any work here should'nt impede progress of the other ecrit work. Any questions, omissions, etc., please reply to the list. -roger marshall. > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > Sent: Thursday, September 27, 2007 12:42 PM > To: Roger Marshall > Cc: ECRIT; Hannes Tschofenig; Marc Linsner > Subject: Re: [ECRIT] wg Status Update - as of 9/25/07 >=20 > Roger >=20 > I've asked the chairs to ask the WG for WG comments on=20 > http://www.ietf.org/internet-drafts/draft-polk-ecrit-local-eme > rgency-rph-namespace-01.txt > becoming a WG item. This occurred both in a 8/2/07 email, and on a > 9/7/07 call discussing the phoneBCP that you, Hannes and Marc=20 > were on. The comments on that call indicated the chairs=20 > should ask the WG to adopt this ID, and Hannes said he would,=20 > but has not to date (and I don't know why). >=20 > Given that Hannes made me present this ID for ~20 minutes in=20 > Chicago, on 30 minutes notice to build the preso (during the=20 > meeting), I do not believe this ID should be ignored when=20 > giving this type of WG update, do you? >=20 > I'm sure this was just an oversight.... ;-) >=20 > James >=20 > At 10:34 PM 9/25/2007, Roger Marshall wrote: > >Content-class: urn:content-classes:message > >Content-Type: multipart/alternative; > > boundary=3D"----_=3D_NextPart_001_01C7FFEE.1EB1B2F6" > > > > > >ECRIT WG Status Update - Sept 2007 > = >=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 > > > >Upcoming IETF Meeting > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >The next ECRIT (IETF70) meeting is scheduled for Dec 2-7,=20 > Vancouver B.C. See: > >http://www3.ietf. > org/meetin > >gs/70-IETF.html > > > > > >Other information: > > > >There is a new Web-based tool that can be used now to submit a new=20 > >draft, see: > > .html>http > >://www1.ietf.org/mail-archive/web/ecrit/current/msg04384.html > > > > > >The meeting minutes from the last IETF69 are here: > >htt > p://www3.i > >etf.org/proceedings/07jul/minutes/ecrit.txt > > > >In addition, there is some progress on some of the wg=20 > related documents. > > > >Prior status reports are posted to the ECRIT WG status site. See:=20 > > critStatus > >Update>http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServ > ices/Ecrit > >StatusUpdate > > > >Document Status > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >In the RFC Editor's Queue > = >=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 > > > >Requirements for Emergency Context Resolution with Internet=20 > >Technologies > >------------------------------------------------------------- > ---------- > >- Draft is moving through the "RFC Ed Queue" - seems close to being=20 > >published: > > ments-13.t > >xt>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requi > rements-13 > >.txt > > > > > >A Uniform Resource Name (URN) for Services > >------------------------------------------ > >Draft has moved to the "RFC Ed Queue" as of 8/21/07: > > t-service- > >urn-07.txt>http://www.cs.columbia.edu/sip/draft/service/draft > -ietf-ecri > >t-service-urn-07.txt > > > > > >Security Threats and Requirements for Emergency Call Marking and=20 > >Mapping > >------------------------------------------------------------- > ---------- > >- The new (-05) Draft version has moved to the "RFC Ed Queue" as of=20 > >9/12/07. > > y-threats- > >05.txt>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-s > ecurity-th > >reats-05.txt > > > > > >PROTO Documents > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >The document shepherding process is described in: > > rding-07.t > >xt>http://tools.ietf.org/id/draft-ietf-proto-wgchair-doc-shep > herding-07 > >.txt > > > > > >LoST: A Location-to-Service Translation Protocol > >------------------------------------------------ > >PROTO writeup has been sent to the Area Directors and the IESG to=20 > >complete the work. > > .txt>http: > >//www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-06.txt > > > > > >Location-to-URL Mapping Architecture and Framework > >-------------------------------------------------- > >PROTO WRITEUP has been sent to the Area Directors and the IESG to=20 > >complete work. > > -arch-02.t > >xt>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-mappi > ng-arch-02 > >.txt > > > > > >A Dynamic Host Configuration Protocol (DHCP) based=20 > Location-to-Service=20 > >Translation Protocol (LoST) Discovery Procedure > >------------------------------------------------------------- > --------- > >PROTO WRITEUP has been sent to the Area Directors and the IESG to=20 > >complete work. > > t-discover > >y-02.txt>http://www.ietf.org/internet-drafts/draft-ietf-ecrit > -dhc-lost- > >discovery-02.txt > > > > > >Other WG Drafts > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >The (two) remaining ECRIT WG Drafts, below, have been updated. > > > >Framework for Emergency Calling using Internet Multimedia > >--------------------------------------------------------- > >New Draft version published as of 9/19/07. Needs additional=20 > WG review. > > rk-03.txt> > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-03.txt > > > > > >Best Current Practice for Communications Services in support of=20 > >Emergency Calling > >------------------------------------------------------------- > ---------- > >---------- > > > >New Draft version published as of 9/19/07. Needs additional=20 > WG review. > > p-02.txt>h > >ttp://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-02.txt > > > > > > > >Individual Drafts > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >Location Hiding: Problem Statement and Requirements > >--------------------------------------------------- > >An updated draft has been produced, see: > > ion-hiding > >-requirements-01.txt>http://tools.ietf.org/wg/ecrit/draft-sch > ulzrinne-e > >crit-location-hiding-requirements-01.txt > > > > > >Last action on this was: "Initiate discussion after the main=20 > WG items=20 > >have been progressed." > > > >Action: ECRIT chairs to determine level of effort, since other items=20 > >now progressed. > > > >Extensions to the Emergency Services Architecture for dealing with=20 > >Unauthenticated and Unauthorized Devices > >------------------------------------------------------------- > ---------- > >--------------- > > > >Initial draft version has been submitted. > > henticated > >-access-00.txt>http://tools.ietf.org/wg/ecrit/draft-schulzrin > ne-ecrit-u > >nauthenticated-access-00.txt > > > > > >There is a IEEE liaison msg. which references the above draft, see: > > .html>http > >://www1.ietf.org/mail-archive/web/ecrit/current/msg04361.html > > > > > >Emergency Call Marking > >---------------------- > > From last report, it was stated: > >"The initially assumed solution, > > ute-01.txt > >>http://tools.ietf.org/wg/sip/draft-rosenberg-sip-ua-loose-ro > ute-01.txt > >, > > > >was not accepted at the IETF meeting." > > > >Some discussion has taken place entitled "UA Loose Routing", see: > > .html>http > >://www1.ietf.org/mail-archive/web/ecrit/current/msg04308.html > > > > > >And "call marking", see: > > .html>http > >://www1.ietf.org/mail-archive/web/ecrit/current/msg04310.html > > > >Which Richard reintroduced, and which there appears to be no common=20 > >resolution for yet, see Brian's response on probable action by most=20 > >proxies, see: > > > > .html>http > >://www1.ietf.org/mail-archive/web/ecrit/current/msg04319.html > > > > > >Proxy Authentication of the Emergency Status of SIP Calls > >--------------------------------------------------------- > > From last report, it was stated, > >"A lot of the discussions in the last few weeks focused on=20 > > t>http://t > >ools.ietf.org/wg/ecrit/draft-barnes-ecrit-auth-00.txt > > > >Action Item: Summary needs to be compiled." > > > >Action: Need to determine next steps. > > > >Overview of the IETF Emergency Services Architecture > >---------------------------------------------------- > >Restated from the last report: > >"The following document gives an overview of the emergency services > >architecture: > > ecture-ove > >rview-00.txt>http://tools.ietf.org/wg/ecrit/draft-tschofenig- > ecrit-arch > >itecture-overview-00.txt > > > > > >It is meant to be read by members from other SDOs and regulators." > > > >DSL Forum Documents > >------------------- > > > >The following referenced document were made available from the DSL=20 > >Forum. An initial review was made by Hannes Tschofenig, see: > > > > .html>http > >://www1.ietf.org/mail-archive/web/ecrit/current/msg04320.html > > > > > >Additional comments have been logged to the list, see: > > ml>http:// > >www1.ietf.org/mail-archive/web/ecrit/current/mail3.html > > > > > >Alignment between IETF and 3GPP Emergency Services Architecture > >--------------------------------------------------------------- > > From the last report, > >"[Hannes]... has the action item to schedule a conference=20 > call within=20 > >the IETF ECRIT WG and subsequently between IETF ECRIT and=20 > the 3GPP to=20 > >discuss a possible alignment." > > > >3rd SDO Emergency Services Workshop > >----------------------------------- > > > >The next workshop (ESW03-07) is scheduled for a 3 day=20 > meeting (October=20 > >30st - November 1st) in Brussels/Belgium (3 day mtg.). > > > >Meeting information can be found here: > >htt > p://www.em > >ergency-services-coordination.info/2007Nov/ > > > > > >A first version of the agenda is also available: > > -August/00 > >0050.html>https://lists.cs.columbia.edu/pipermail/es-coordina > tion/2007- > >August/000050.html > > > > > >Tuesday, October 30: > >-------- > > > >Tutorials about IETF, 3GPP and NENA architectures > > > >u2010 meeting the standards > > > >Wednesday, October 31: > >---------- > > > >Policy Panel > > > >Status Updates > > * IETF (GEOPRIV, ECRIT, SIP) > > * DSL Forum > > * IEEE > > * ATIS-ESIF > > * NENA > > * ETSI EMTEL > > * 3GPP > > * 3GPP2 > > * ETSI TISPAN > > * FCC > > * Open Mobile Alliance (OMA) > > * TIA > > * US Department of Transportation > > * OCG > > * EU Commission > > * Wimax Forum > > * WiFi Forum/Alliance > > * APCO Project 41 > > * COMCAST > > * NIST > > > >Thursday, November 1: > >--------- > > > >Status Updates (con't) > > > >Authority-to-Citizen Communication > > Requirements > > What's available now > > > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ie > tf.org/mai > >lman/listinfo/ecrit > > > > > >Roger Marshall > > > > > > > >The information contained in this message may be privileged and/or=20 > >confidential. If you are not the intended recipient, or=20 > responsible for=20 > >delivering this message to the intended recipient, any review,=20 > >forwarding, dissemination, distribution or copying of this=20 > >communication or any attachment(s) is strictly prohibited.=20 > If you have=20 > >received this message in error, please so notify the sender=20 > >immediately, and delete it and all attachments from your=20 > computer and network. > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Sep 28 01:16:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib8CZ-0008Mf-RQ; Fri, 28 Sep 2007 01:15:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib8CX-0008L6-JQ for ecrit@ietf.org; Fri, 28 Sep 2007 01:15:45 -0400 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 1Ib8CW-000205-14 for ecrit@ietf.org; Fri, 28 Sep 2007 01:15:45 -0400 X-IronPort-AV: E=Sophos;i="4.21,207,1188802800"; d="scan'208";a="529127588" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 27 Sep 2007 22:15:42 -0700 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/8.12.11) with ESMTP id l8S5FhU2030492; Thu, 27 Sep 2007 22:15:43 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8S5FdTm025557; Fri, 28 Sep 2007 05:15:39 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 22:15:38 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.86.168]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 22:15:38 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 28 Sep 2007 00:15:37 -0500 To: "Hannes Tschofenig" , RMarshall@telecomsys.com From: "James M. Polk" Subject: Re: [ECRIT] wg Status Update - as of 9/25/07 In-Reply-To: <20070927203603.101040@gmx.net> References: <8C837214C95C864C9F34F3635C2A657508493B4B@SEA-EXCHVS-2.telecomsys.com> <20070927203603.101040@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 28 Sep 2007 05:15:38.0369 (UTC) FILETIME=[9B5E4710:01C8018E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13926; t=1190956543; x=1191820543; 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]=20wg=20Status=20Update=20-=20as=20of=209/25/0 7 |Sender:=20; bh=1ZsHKR2Vn6NBL59pr5YuwXfVbjMCj5y9BgQs95A8LCM=; b=WpEheZpEJ+6vj7bz/WDgTCRXILE8yPHw1HcUG9hhJqrE706MSOW00pfKuA7FdzeFpivf3UQH +UR89tLmTPFtf6FkdjJT5yC5PmEeXfotplyzOMwjMW8X57gNswUMK7lI; 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: 4d9ae72af46718088458d214998cc683 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Sorry Hannes I must have missed that note to the list James At 03:36 PM 9/27/2007, Hannes Tschofenig wrote: >Hi James, > >regarding your draft: I have asked our ADs whether they are OK with >adding that document to the charter (if the WG agrees). Our ADs, >however, insisted on finishing the current documents first before we >add any new items. I agree that this is a useful approach. > >I posted that in a mail to the mailing list somewhere; I need to >find the mail and then I should also add it to the status update. > >Ciao >Hannes > >-------- Original-Nachricht -------- > > Datum: Thu, 27 Sep 2007 14:41:54 -0500 > > Von: "James M. Polk" > > An: "Roger Marshall" > > CC: "ECRIT" , "Hannes Tschofenig" > , "Marc Linsner" > > Betreff: Re: [ECRIT] wg Status Update - as of 9/25/07 > > > Roger > > > > I've asked the chairs to ask the WG for WG comments on > > > http://www.ietf.org/internet-drafts/draft-polk-ecrit-local-emergency-rph-namespace-01.txt > > becoming a WG item. This occurred both in a 8/2/07 email, and on a > > 9/7/07 call discussing the phoneBCP that you, Hannes and Marc were > > on. The comments on that call indicated the chairs should ask the WG > > to adopt this ID, and Hannes said he would, but has not to date (and > > I don't know why). > > > > Given that Hannes made me present this ID for ~20 minutes in Chicago, > > on 30 minutes notice to build the preso (during the meeting), I do > > not believe this ID should be ignored when giving this type of WG > > update, do you? > > > > I'm sure this was just an oversight.... ;-) > > > > James > > > > At 10:34 PM 9/25/2007, Roger Marshall wrote: > > >Content-class: urn:content-classes:message > > >Content-Type: multipart/alternative; > > > boundary="----_=_NextPart_001_01C7FFEE.1EB1B2F6" > > > > > > > > >ECRIT WG Status Update - Sept 2007 > > >================================== > > > > > >Upcoming IETF Meeting > > >===================== > > > > > >The next ECRIT (IETF70) meeting is scheduled for Dec 2-7, Vancouver B.C. > > See: > > >http://www3.ietf.org/ > meetings/70-IETF.html > > > > > > > > >Other information: > > > > > >There is a new Web-based tool that can be used now to submit a new > > >draft, see: > > > l>http://www1.ietf.org/mail-archive/web/ecrit/current/msg04384.html > > > > > > > > >The meeting minutes from the last IETF69 are here: > > >http:// > www3.ietf.org/proceedings/07jul/minutes/ecrit.txt > > > > > >In addition, there is some progress on some of the wg related documents. > > > > > >Prior status reports are posted to the ECRIT WG status site. See: > > > StatusUpdate>http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/EcritStatusUpdate > > > > > >Document Status > > >=============== > > > > > >In the RFC Editor's Queue > > >========================= > > > > > >Requirements for Emergency Context Resolution with Internet Technologies > > >------------------------------------------------------------------------ > > >Draft is moving through the "RFC Ed Queue" - seems close to being > > published: > > > s-13.txt>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-13.txt > > > > > > > > >A Uniform Resource Name (URN) for Services > > >------------------------------------------ > > >Draft has moved to the "RFC Ed Queue" as of 8/21/07: > > > rvice-urn-07.txt>http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service-urn-07.txt > > > > > > > > >Security Threats and Requirements for Emergency Call Marking and Mapping > > >------------------------------------------------------------------------ > > >The new (-05) Draft version has moved to the "RFC Ed Queue" as of > > 9/12/07. > > > reats-05.txt>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-security-threats-05.txt > > > > > > > > >PROTO Documents > > >=============== > > > > > >The document shepherding process is described in: > > > g-07.txt>http://tools.ietf.org/id/draft-ietf-proto-wgchair-doc-shepherding-07.txt > > > > > > > > >LoST: A Location-to-Service Translation Protocol > > >------------------------------------------------ > > >PROTO writeup has been sent to the Area Directors and the IESG to > > >complete the work. > > > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-06.txt > > > > > > > > >Location-to-URL Mapping Architecture and Framework > > >-------------------------------------------------- > > >PROTO WRITEUP has been sent to the Area Directors and the IESG to > > >complete work. > > > h-02.txt>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-mapping-arch-02.txt > > > > > > > > >A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service > > >Translation Protocol (LoST) Discovery Procedure > > >---------------------------------------------------------------------- > > >PROTO WRITEUP has been sent to the Area Directors and the IESG to > > >complete work. > > > scovery-02.txt>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-02.txt > > > > > > > > >Other WG Drafts > > >=============== > > > > > >The (two) remaining ECRIT WG Drafts, below, have been updated. > > > > > >Framework for Emergency Calling using Internet Multimedia > > >--------------------------------------------------------- > > >New Draft version published as of 9/19/07. Needs additional WG review. > > > 3.txt>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-03.txt > > > > > > > > >Best Current Practice for Communications Services in support of > > >Emergency Calling > > >----------------------------------------------------------------- > ---------------- > > > > > >New Draft version published as of 9/19/07. Needs additional WG review. > > > .txt>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-02.txt > > > > > > > > > > > >Individual Drafts > > >================= > > > > > >Location Hiding: Problem Statement and Requirements > > >--------------------------------------------------- > > >An updated draft has been produced, see: > > > hiding-requirements-01.txt>http://tools.ietf.org/wg/ecrit/draft-schulzrinne-ecrit-location-hiding-requirements-01.txt > > > > > > > > >Last action on this was: "Initiate discussion after the main WG > > >items have been progressed." > > > > > >Action: ECRIT chairs to determine level of effort, since other items > > >now progressed. > > > > > >Extensions to the Emergency Services Architecture for dealing with > > >Unauthenticated and Unauthorized Devices > > >----------------------------------------------------------------- > --------------------- > > > > > >Initial draft version has been submitted. > > > icated-access-00.txt>http://tools.ietf.org/wg/ecrit/draft-schulzrinne-ecrit-unauthenticated-access-00.txt > > > > > > > > >There is a IEEE liaison msg. which references the above draft, see: > > > l>http://www1.ietf.org/mail-archive/web/ecrit/current/msg04361.html > > > > > > > > >Emergency Call Marking > > >---------------------- > > > From last report, it was stated: > > >"The initially assumed solution, > > > 01.txt>http://tools.ietf.org/wg/sip/draft-rosenberg-sip-ua-loose-route-01.txt, > > > > > >was not accepted at the IETF meeting." > > > > > >Some discussion has taken place entitled "UA Loose Routing", see: > > > l>http://www1.ietf.org/mail-archive/web/ecrit/current/msg04308.html > > > > > > > > >And "call marking", see: > > > l>http://www1.ietf.org/mail-archive/web/ecrit/current/msg04310.html > > > > > >Which Richard reintroduced, and which there appears to be no common > > >resolution for yet, see Brian's response on probable action by most > > >proxies, see: > > > > > > l>http://www1.ietf.org/mail-archive/web/ecrit/current/msg04319.html > > > > > > > > >Proxy Authentication of the Emergency Status of SIP Calls > > >--------------------------------------------------------- > > > From last report, it was stated, > > >"A lot of the discussions in the last few weeks focused on > > >ht > tp://tools.ietf.org/wg/ecrit/draft-barnes-ecrit-auth-00.txt > > > > > >Action Item: Summary needs to be compiled." > > > > > >Action: Need to determine next steps. > > > > > >Overview of the IETF Emergency Services Architecture > > >---------------------------------------------------- > > >Restated from the last report: > > >"The following document gives an overview of the emergency services > > >architecture: > > > re-overview-00.txt>http://tools.ietf.org/wg/ecrit/draft-tschofenig-ecrit-architecture-overview-00.txt > > > > > > > > >It is meant to be read by members from other SDOs and regulators." > > > > > >DSL Forum Documents > > >------------------- > > > > > >The following referenced document were made available from the DSL > > >Forum. An initial review was made by Hannes Tschofenig, see: > > > > > > l>http://www1.ietf.org/mail-archive/web/ecrit/current/msg04320.html > > > > > > > > >Additional comments have been logged to the list, see: > > >h > ttp://www1.ietf.org/mail-archive/web/ecrit/current/mail3.html > > > > > > > > >Alignment between IETF and 3GPP Emergency Services Architecture > > >--------------------------------------------------------------- > > > From the last report, > > >"[Hannes]... has the action item to schedule a conference > > >call within the IETF ECRIT WG and subsequently between IETF ECRIT > > >and the 3GPP to discuss a possible alignment." > > > > > >3rd SDO Emergency Services Workshop > > >----------------------------------- > > > > > >The next workshop (ESW03-07) is scheduled for a 3 day meeting (October > > 30st - > > >November 1st) in Brussels/Belgium (3 day mtg.). > > > > > >Meeting information can be found here: > > >http:// > www.emergency-services-coordination.info/2007Nov/ > > > > > > > > >A first version of the agenda is also available: > > > ust/000050.html>https://lists.cs.columbia.edu/pipermail/es-coordination/2007-August/000050.html > > > > > > > > >Tuesday, October 30: > > >-------- > > > > > >Tutorials about IETF, 3GPP and NENA architectures > > > > > >u2010 meeting the standards > > > > > >Wednesday, October 31: > > >---------- > > > > > >Policy Panel > > > > > >Status Updates > > > * IETF (GEOPRIV, ECRIT, SIP) > > > * DSL Forum > > > * IEEE > > > * ATIS-ESIF > > > * NENA > > > * ETSI EMTEL > > > * 3GPP > > > * 3GPP2 > > > * ETSI TISPAN > > > * FCC > > > * Open Mobile Alliance (OMA) > > > * TIA > > > * US Department of Transportation > > > * OCG > > > * EU Commission > > > * Wimax Forum > > > * WiFi Forum/Alliance > > > * APCO Project 41 > > > * COMCAST > > > * NIST > > > > > >Thursday, November 1: > > >--------- > > > > > >Status Updates (con't) > > > > > >Authority-to-Citizen Communication > > > Requirements > > > What's available now > > > > > > > > > > > >_______________________________________________ > > >Ecrit mailing list > > >Ecrit@ietf.org > > >https://www1.ietf.o > rg/mailman/listinfo/ecrit > > > > > > > > >Roger Marshall > > > > > > > > > > > >The information contained in this message may be privileged and/or > > >confidential. If you are not the intended recipient, or responsible > > >for delivering this message to the intended recipient, any review, > > >forwarding, dissemination, distribution or copying of this > > >communication or any attachment(s) is strictly prohibited. If you > > >have received this message in error, please so notify the sender > > >immediately, and delete it and all attachments from your computer and > > network. > > > > > > > > >_______________________________________________ > > >Ecrit mailing list > > >Ecrit@ietf.org > > >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Sep 29 22:52:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibosf-00043x-EX; Sat, 29 Sep 2007 22:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibosc-00043n-Ri; Sat, 29 Sep 2007 22:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ibosb-0006EJ-ON; Sat, 29 Sep 2007 22:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 9BF1826E8C; Sun, 30 Sep 2007 02:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ibosb-0005EG-9a; Sat, 29 Sep 2007 22:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sat, 29 Sep 2007 22:50:01 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-mapping-arch-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Location-to-URL Mapping Architecture and Framework Author(s) : H. Schulzrinne Filename : draft-ietf-ecrit-mapping-arch-03.txt Pages : 16 Date : 2007-09-29 This document describes an architecture for a global, scalable, resilient and administratively distributed system for mapping geographic location information to URLs, using the Location-to- Service (LoST) protocol. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-mapping-arch-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-mapping-arch-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-mapping-arch-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-09-29224927.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-mapping-arch-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-mapping-arch-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-29224927.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Sat Sep 29 23:01:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibp3R-0007L9-RI; Sat, 29 Sep 2007 23:01:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibp3Q-0007L4-SQ for ecrit@ietf.org; Sat, 29 Sep 2007 23:01:12 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ibp3I-0006Pj-FO for ecrit@ietf.org; Sat, 29 Sep 2007 23:01:12 -0400 Received: from [192.168.0.41] (pool-70-21-185-251.nwrk.east.verizon.net [70.21.185.251]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l8U30mvk019965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sat, 29 Sep 2007 23:00:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A5B5004-1E83-456D-A627-36BE265BE8DF@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Sat, 29 Sep 2007 23:00:51 -0400 To: ECRIT X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Ecrit] Re: New Version Notification for draft-ietf-ecrit-mapping-arch-03 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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 only an ID nit fix. On Sep 29, 2007, at 10:49 PM, IETF I-D Submission Tool wrote: > > A new version of I-D, draft-ietf-ecrit-mapping-arch-03.txt has been > successfuly submitted by Henning Schulzrinne and posted to the IETF > repository. > > Filename: draft-ietf-ecrit-mapping-arch > Revision: 03 > Title: Location-to-URL Mapping Architecture and Framework > Creation_date: 2007-09-29 > WG ID: ecrit > Number_of_pages: 16 > > Abstract: > This document describes an architecture for a global, scalable, > resilient and administratively distributed system for mapping > geographic location information to URLs, using the Location-to- > Service (LoST) protocol. The architecture generalizes well-known > approaches found in hierarchical lookup systems such as DNS. > > > > The IETF Secretariat. > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Sep 30 06:32:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibw3z-0003WN-UA; Sun, 30 Sep 2007 06:30:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ibw3x-0003PY-AQ for ecrit@ietf.org; Sun, 30 Sep 2007 06:30:13 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ibw3s-0007NW-Ko for ecrit@ietf.org; Sun, 30 Sep 2007 06:30:09 -0400 Received: (qmail invoked by alias); 30 Sep 2007 10:30:06 -0000 Received: from 1.106.113.82.net.de.o2.com (EHLO [10.68.253.41]) [82.113.106.1] by mail.gmx.net (mp054) with SMTP; 30 Sep 2007 12:30:06 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+zOsIr5ayzXn5aFzekzjI4GyLtXPIxoyJoYNzrKP 5Fwbt55KFaE5hK Message-ID: <46FF7AAB.6080202@gmx.net> Date: Sun, 30 Sep 2007 12:30:03 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) 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: 93238566e09e6e262849b4f805833007 Subject: [Ecrit] ECRIT Framework & Phone BCP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 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, it would be important to finish our main documents as soon as possible. Brian has done a significant review of them and I believe their quality has been improved a lot. We, however, need a few reviewers who could confirm that the documents are getting ready for WGLC (or an indication where we would need todo more work in order to get them closer to WGLC). I definitely expect all the authors to send their opinion to the list. Could someone else read through the documents? Deadline for the review: 2 weeks from now Ciao Hannes PS: I know that there is the DSL Forum liaison document that suggests further refinements of the Phone BCP document. I had a chat with Barbara and she will interact with Brian (also at the upcoming emergency services workshop) to identify the relevant parts that could be improved in the Phone BCP. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit