From Hannes.Tschofenig@gmx.net Sun Mar 1 11:38:49 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71AF328C15E for ; Sun, 1 Mar 2009 11:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6klUmhmEpjUv for ; Sun, 1 Mar 2009 11:38:49 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6275028C14F for ; Sun, 1 Mar 2009 11:38:47 -0800 (PST) Received: (qmail invoked by alias); 01 Mar 2009 19:39:08 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp054) with SMTP; 01 Mar 2009 20:39:08 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX193Lfon6yx3vRRZxAIoStRLKjUXsxwqagQvfoMho1 GX/SxWvgFufJxR From: "Hannes Tschofenig" To: "'ECRIT'" , "'KEYPROV'" , Date: Sun, 1 Mar 2009 21:40:04 +0200 Message-ID: <00ab01c99aa5$88024020$0201a8c0@nsnintra.net> 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.3350 Thread-index: AcmYSIQ2rlgWDFaARwS44XtqzrJYLwCXO13g X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: [Ecrit] FW: Initial Version I-D Submission Deadline Extended to March 4, 2009 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 19:38:49 -0000 FYI; more time in case you work on new documents. Ciao Hannes >-----Original Message----- >From: wgchairs-bounces@ietf.org >[mailto:wgchairs-bounces@ietf.org] On Behalf Of Alexa Morris >Sent: 26 February, 2009 21:28 >To: ietf-announce@ietf.org; ietf@ietf.org; wgchairs@ietf.org >Subject: Initial Version I-D Submission Deadline Extended to >March 4, 2009 > >The IESG has extended the deadline for initial version (00) >submissions of Internet Drafts by 2 days (48 hours). The new >deadline is March 4, 2009 at 1700 Pacific (March 5, 2009 at >0100 UTC / GMT) and the extension is for IETF 74 only. The >deadline has been extended due to the copyright legend text >alternative being recently finalized, approved and implemented. > >Please note that the date for updated I-D versions has NOT >been extended, and is still March 9, 2009. > >Regards, >Alexa > >----------- >Alexa Morris / Executive Director / IETF >48377 Fremont Blvd., Suite 117, Fremont, CA 94538 >Phone: +1.510.492.4089 / Fax: +1.510.492.4001 >Email: amorris@amsl.com > >Managed by Association Management Solutions (AMS) Forum >Management, Meeting and Event Planning www.amsl.com > > From James.Winterbottom@andrew.com Sun Mar 1 21:20:15 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABF133A68AA for ; Sun, 1 Mar 2009 21:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyy+IUp7ms5s for ; Sun, 1 Mar 2009 21:20:02 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 4BC453A6B19 for ; Sun, 1 Mar 2009 21:20:02 -0800 (PST) X-SEF-Processed: 5_0_0_910__2009_03_01_23_24_03 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 01 Mar 2009 23:24:03 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Mar 2009 23:04:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99AF4.5A6FC511" Date: Sun, 1 Mar 2009 23:04:22 -0600 Message-ID: In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC53749E3B@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwKeEe+gADZBfMABQDsYoAA26fDAAJM+RGA= References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net> <1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC53749E3B@NASANEXMB04.na.qualcomm.com> From: "Winterbottom, James" To: "Edge, Stephen" , "Brian Rosen" , "ECRIT" X-OriginalArrivalTime: 02 Mar 2009 05:04:24.0433 (UTC) FILETIME=[5AE38E10:01C99AF4] Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 05:20:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99AF4.5A6FC511 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stephen,=0D=0A=0D=0A=20=0D=0A=0D=0AI have the distinct impression that w= e are never going to agree on this=0D=0Asubject, I would however like to po= int out some statements in text below=0D=0Athat are either misleading, or a= t least able to be interpreted in an=0D=0Aalternative manner than that whic= h is provided.=0D=0A=0D=0A=20=0D=0A=0D=0APlease 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-----Or= iginal Message-----=0D=0AFrom: Edge, Stephen [mailto:sedge@qualcomm.com] =0D= =0ASent: Friday, 27 February 2009 4:38 PM=0D=0ATo: Winterbottom, James; Bri= an Rosen; ECRIT=0D=0ASubject: RE: [Ecrit] Comments on Framework Draft=0D=0A=0D= =0A=20=0D=0A=0D=0AHi James=0D=0A=0D=0A=20=0D=0A=0D=0AThanks for these furth= er comments and for this oft repeated example -=0D=0Anamely use of a 3GPP o= r 3GPP2 IP access network to reach a=0D=0Anon-3GPP/3GPP2 VSP. This is alway= s being thrown up as a reason that the=0D=0A3GPP/3GPP2 solution cannot even= fully address its own calling scenarios.=0D=0AIt is however incomplete for= the following reasons.=0D=0A=0D=0A=20=0D=0A=0D=0A[AJW] Let's agree to disa= gree on this point, it is a stated requirement=0D=0Ain TS23.167 (requiremen= t 2 under section 4.1) that "Emergency services=0D=0Aare independent from t= he IP-CAN with respect to the detection and=0D=0Arouting of emergency sessi= ons. The emergency services shall be possible=0D=0Aover at least a cellular= access network, a fixed broadband access,=0D=0AI-WLAN access and a nomadic= access."=0D=0A=0D=0AI think, therefore that the solution is actually perfe= ctly valid, the=0D=0A3GPP network is the IPCAN and it must allow independen= t detection and=0D=0Arouting of the emergency call. This requirement falls = short of what some=0D=0Alegislative bodies are now considering the duty of = the IPCAN to be, but=0D=0Ait is still a good start.=0D=0A=0D=0A=20=0D=0A=0D= =0AFirst of all, I doubt that in this example either the Ecrit or=0D=0A3GPP= /3GPP2 solution would actually be possible now since neither are=0D=0Afully= defined or fully implemented yet. Perhaps the VSP would provide=0D=0Asome = rudimentary E911 capability though probably not to the right PSAP.=0D=0ASo = the example is more hypothetical for future implementation in which=0D=0Aca= se either solution might be considered.=0D=0A=0D=0A=20=0D=0A=0D=0A[AJW] Thi= s is true for ECRIT in that LoST servers are not widely=0D=0Adeployed and p= ublically available. However there are certainly NENA i2=0D=0Adeployments b= eing tested (not sure if they are actually live yet) where=0D=0Athe origin= ating call includes a PIDF-LO in the body with the call, and=0D=0Athe VSP i= n conjunction with a VPC can route the emergency call to the=0D=0Acorrect P= SAP. I fully expect this to happen in cases where the Internet=0D=0Apipe is= 3G so let's agree that this is not hypothetical.=20=0D=0A=0D=0A=20=0D=0A=0D= =0AI am aware of two countries that are currently in the process or about=0D= =0Ato begin the process of legislating Internet access providers to make=0D= =0Alocation available for the purpose of routing emergency Internet calls.=0D= =0AIt will be interesting to see what impact this legislation has on 3G=0D=0A= data only devices and associated network operators, presumably they will=0D= =0Aneed to comply with the Internet access provider legislation or stop=0D=0A= providing, I think that it is more likely that they will comply.=0D=0A=0D=0A= =20=0D=0A=0D=0AMaybe you are aware that CDMA EvDO providers will be obligat= ed by the=0D=0AFCC in the US to provide E911 capability assuming they are u= sing=0D=0Alicensed spectrum. So in this example, and in a few more years wh= en the=0D=0A3GPP/3GPP2 solution has been fully defined and implemented, the= device=0D=0Ain question would be able to access the CDMA EvDO network, ass= uming it=0D=0Arecognized the dialed emergency number and supported the 3GPP= /3GPP2=0D=0Asolution, and make an IP based E911 call directly via the servi= ng EvDO=0D=0Anetwork and not via its normal VSP.=0D=0A=0D=0A=20=0D=0A=0D=0A= [AJW] Martin, Brian and possibly Richard have already described a=0D=0Aseri= ous flaw in this line of thinking. Namely that if I have a 3G=0D=0AInternet= router, any device behind that router has absolutely no=0D=0Avisibility th= at it needs to talk to a different VSP, the solution you=0D=0Aare proposing= almost suggests therefore that the wireless router=0D=0Arequires E-CSCF fu= nctionality in it and that it can detect when a device=0D=0Ain the home net= work is making an emergency call. This is very intrusive=0D=0Aand certainly= not backward compatible with the legacy devices already=0D=0Adeployed.=20=0D= =0A=0D=0A=20=0D=0A=0D=0A If it did not recognize the dialed emergency numbe= r or chose to use the=0D=0Anormal VSP anyway but still supported the 3GPP/3= GPP2 solution, then the=0D=0AVSP (e.g. based on receiving some access netwo= rk related information=0D=0Afrom the device in the SIP INVITE such as an Ev= DO cell ID and possibly=0D=0Abased on subscription information if needed to= imply 3GPP/3GPP2=0D=0Acapability for the device) could send an error respo= nse back to the=0D=0Adevice (a SIP 380 response with an emergency indicatio= n) that would=0D=0Acause the device to redirect the call to the EvDO servin= g network. If=0D=0Athe device did not support the 3GPP/3GPP2 solution, this= would not work=0D=0A- but it seems unreasonable to treat non-support of a = solution as a=0D=0Aweakness since almost every solution is susceptible to t= his.=0D=0A=0D=0A=20=0D=0A=0D=0A[AJW] Any device behind a home 3G router wil= l have no visibility of the=0D=0Aconnected cell-id. Cell-ID is also of almo= st no use to anyone but the=0D=0Aoperator of the access network, so includi= ng this in a call to a VSP=0D=0Athat knows nothing about EVDO, let along a = specific access provider=0D=0Aseems almost as big a stretch as universal SU= PL roaming. Why not simply=0D=0Amake the location available to the caller u= sing the mechanisms described=0D=0Ain GeoPriv=3F Once this is done you have= ECRIT, i2, or i3 and they will=0D=0Ajust work!=20=0D=0A=0D=0A=20=0D=0A=0D=0A= The above would not prevent the VSP from employing the Ecrit solution=0D=0A= for other types of access not supporting the 3GPP/3GPP2 solution and the=0D= =0Aincremental cost to the VSP of supporting the 3GPP/3GPP2 solution (by=0D= =0Ameans of the 380 response) ought to be small.=0D=0A=0D=0A=20=0D=0A=0D=0A= [AJW] The argument again is that device may not know about the=0D=0Aunderly= ing dependency between access and service and in a number of=0D=0Acircumsta= nces it absolutely will not know. The device might be able to=0D=0Alearn th= e address of the local ES-Proxy, but if you are going to employ=0D=0Athat s= olution why not just employ an option to discover the LIS and the=0D=0ALoST= server=3F=0D=0A=0D=0A=20=0D=0A=0D=0AThe one case I have omitted but which = I assume you may specifically have=0D=0Ain mind is where the device only su= pports IP data access and acts as a=0D=0Arouter on behalf of another end de= vice (e.g. a laptop). In that case, I=0D=0Athink both solutions would be se= verely handicapped. The Ecrit solution=0D=0Awould have a hard time obtainin= g location (unless the end device already=0D=0Ahad an accurate location fix= which it included in the SIP INVITE) and in=0D=0Arouting to a PSTN capable= PSAP (particularly one in another country).=20=0D=0A=0D=0A=20=0D=0A=0D=0A[= AJW] Let's agree to disagree on this point. The 3GPP access behind the=0D=0A= router is the Internet access provider and will likely have to provide=0D=0A= location to the device. We have got pretty good LIS discovery mechanisms=0D= =0Adescribed in Geopriv that address most major concerns, so actually I=0D=0A= believe that ECRIT and NENA i2 will work quite well.=0D=0A=0D=0A=20=0D=0A=0D= =0AThe 3GPP/3GPP2 solution - assuming the VSP supported it - might find=0D=0A= location easier (e.g. if the router or end device supported SUPL since=0D=0A= that would allow location for dispatch subsequent to call routing), but=0D=0A= would find PSTN PSAP routing just as hard.=0D=0A=0D=0A=20=0D=0A=0D=0AThe pa= rts of the Ecrit solution that appear unsuitable for cellular=0D=0Anetworks= I have already elaborated on - e.g. endpoint oriented location=0D=0Aand ro= uting, no explicit cellular location capability, no explicit=0D=0Asupport f= or PSAPs accessed over the PSTN.=0D=0A=0D=0A=20=0D=0A=0D=0A[AJW] I think yo= u will find that the WiMAX forum disagrees you with on a=0D=0Anumber of the= se points. And I have absolutely no doubt that with the 1.5=0D=0Aversion of= WiMAX I can support a fully mobile IP network using the ECRIT=0D=0Aemergen= cy calling architecture.=20=0D=0A=0D=0A=20=0D=0A=0D=0AI am not sure that I = understand what you mean by "no explicit cellular=0D=0Alocation capability"= , perhaps you can explain. Certainly using a=0D=0Aprotocol such as HELD I c= an an awful lot and it all remains local so it=0D=0Adoesn't require a world= in a database to support roaming such as is=0D=0Arequired in some protocol= s that we will not mention here...;)=0D=0A=0D=0A=20=0D=0A=0D=0A (the NENA i= 2 solution is not a global standard and seems impractical=0D=0Awhere a PSAP= is very remote from the VSP), no consideration for handover=0D=0Ato or fro= m circuit mode access (which will remain the norm for many=0D=0Ayears) or e= ven to/from other IP access networks.=0D=0A=0D=0A=20=0D=0A=0D=0A[AJW] You a= re right that NENA i2 is not a global standard, but it is=0D=0Abeing tailor= ed for deployment in at least 3 countries at I am aware of,=0D=0Aand forms = the basis for discussion in a number of others.=0D=0A=0D=0A=20=0D=0A=0D=0AI= agree that circuit mode devices will be around for a many years to=0D=0Aco= me, I am less convinced that they will remain the norm, and with data=0D=0A= only devices increasing in popularity I see the need to hand-over in the=0D= =0Away you describe as unnecessary. Indeed I see it as a technological=0D=0A= mismatch, equivalent to being able to hand-over my GSM call to a CDMA=0D=0A= network; Without a special, purpose-built device I can't do it. Delivery=0D= =0Aof calls from VoIP to circuit switched PSTN and vice versa is common=0D=0A= place today from any number of voice service providers and this is the=0D=0A= mode of operation we should be discussing. =20=0D=0A=0D=0A=20=0D=0A=0D=0A =0D= =0A=0D=0A=20=0D=0A=0D=0AKind Regards=0D=0A=0D=0A=20=0D=0A=0D=0AStephen=0D=0A=0D= =0A=20=0D=0A=0D=0A---------------------------------------------------------= ---------------------------------------=0D=0AThis message is for the design= ated recipient only and may=0D=0Acontain privileged, proprietary, or otherw= ise private information. =20=0D=0AIf you have received it in error, please = notify the sender=0D=0Aimmediately and delete the original. Any unauthoriz= ed use of=0D=0Athis email is prohibited.=0D=0A-----------------------------= -------------------------------------------------------------------=0D=0A[m= f2]=0D=0A ------_=_NextPart_001_01C99AF4.5A6FC511 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

<= font size=3D2 face=3D"Courier New">H= i Stephen,

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

= =  

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

I ha= ve the distinct impression that we are never going to agree on this=0D=0Asu= bject, I would however like to point out some statements in text below that=0D= =0Aare either misleading, or at least able to be interpreted in an alternat= ive=0D=0Amanner than that which is provided.

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

 

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

Please inline.

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

 

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

Cheers

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

James

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

 

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

 

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

-----Original Message-----
=0D=0AFrom: Edge, Stephen [mai= lto:sedge@qualcomm.com]
=0D=0ASent: Friday, 27 February 2009 4:38 PM=0D=0ATo: Winterbottom, James; Brian Rosen; ECRIT
=0D=0ASubject: RE: [E= crit] Comments on Framework Draft

=0D=0A=0D=0A<= p class=3DMsoPlainText> 

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

Hi James

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

 

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

Thanks for these further comments and for this oft repeated exam= ple -=0D=0Anamely use of a 3GPP or 3GPP2 IP access network to reach a non-3= GPP/3GPP2 VSP.=0D=0AThis is always being thrown up as a reason that the 3GP= P/3GPP2 solution cannot=0D=0Aeven fully address its own calling scenarios. = It is however incomplete for the=0D=0Afollowing reasons.<= /font>

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

 

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

[AJW] Let’s agree to=0D=0Adisagree on this point, it is a s= tated requirement in TS23.167 (requirement 2=0D=0Aunder section 4.1) that <= /span>= 220;Emergency services are independent from the IP-CAN=0D=0Awith respect to= the detection and routing of emergency sessions. The emergency=0D=0Aservic= es shall be possible over at least a cellular access network, a fixed=0D=0A= broadband access, I-WLAN access and a nomadic access.”<= font=0D=0Acolor=3Dblue>=

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

I think, therefore that=0D=0Athe solution is actually perfectly= valid, the 3GPP network is the IPCAN and it=0D=0Amust allow independent de= tection and routing of the emergency call. This=0D=0Arequirement falls shor= t of what some legislative bodies are now considering the=0D=0Aduty of the = IPCAN to be, but it is still a good start.

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

 

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

First of all, I doubt that in this example either = the Ecrit or=0D=0A3GPP/3GPP2 solution would actually be possible now since = neither are fully=0D=0Adefined or fully implemented yet. Perhaps the VSP wo= uld provide some=0D=0Arudimentary E911 capability though probably not to th= e right PSAP. So the=0D=0Aexample is more hypothetical for future implement= ation in which case either solution=0D=0Amight be considered.

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

 

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

[AJW] This is tru= e for=0D=0AECRIT in that LoST servers are not widely deployed and publicall= y available.=0D=0AHowever there are certainly NENA i2 deployments being tes= ted (not sure if they=0D=0Aare actually live yet) where the  originati= ng call includes a PIDF-LO in=0D=0Athe body with the call, and the VSP in c= onjunction with a VPC can route the=0D=0Aemergency call to the correct PSAP= =2E I fully expect this to happen in cases=0D=0Awhere the Internet pipe is = 3G so let’s agree that this is not hypothetical.=0D=0A

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

 

=0D=0A=0D=0A<= span=0D=0Astyle=3D'font-size:10.0pt;color:blue;font-weight:bold'>I am aware= of two=0D=0Acountries that are currently in the process or about to begin = the process of=0D=0Alegislating Internet access providers to make location = available for the=0D=0Apurpose of routing emergency Internet calls. It will= be interesting to see what=0D=0Aimpact this legislation has on 3G data onl= y devices and associated network=0D=0Aoperators, presumably they will need = to comply with the Internet access=0D=0Aprovider legislation or stop provid= ing, I think that it is more likely that=0D=0Athey will comply.<= /span>

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

 <= /span>

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

Maybe you are aware th= at CDMA EvDO providers will be obligated by the=0D=0AFCC in the US=0D=0Ato provide E911 capability assuming they are using licensed spect= rum. So in=0D=0Athis example, and in a few more years when the 3GPP/3GPP2 s= olution has been=0D=0Afully defined and implemented, the device in question= would be able to access=0D=0Athe CDMA EvDO network, assuming it recognized= the dialed emergency number and=0D=0Asupported the 3GPP/3GPP2 solution, an= d make an IP based E911 call directly via=0D=0Athe serving EvDO network and= not via its normal VSP.

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

 

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

[AJW] Martin, Brian and=0D= =0Apossibly Richard have already described a serious flaw in this line of=0D= =0Athinking. Namely that if I have a 3G Internet router, any device behind = that=0D=0Arouter has absolutely no visibility that it needs to talk to a di= fferent VSP,=0D=0Athe solution you are proposing almost suggests therefore = that the wireless=0D=0Arouter requires E-CSCF functionality in it and that = it can detect when a device=0D=0Ain the home network is making an emergency= call. This is very intrusive and=0D=0Acertainly not backward compatible wi= th the legacy devices already deployed.

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

 

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

 If it did not recognize the dialed emergency= number or chose to=0D=0Ause the normal VSP anyway but still supported the = 3GPP/3GPP2 solution, then the=0D=0AVSP (e.g. based on receiving some access= network related information from the=0D=0Adevice in the SIP INVITE such as= an EvDO cell ID and possibly based on=0D=0Asubscription information if nee= ded to imply 3GPP/3GPP2 capability for the=0D=0Adevice) could send an error= response back to the device (a SIP 380 response=0D=0Awith an emergency ind= ication) that would cause the device to redirect the call=0D=0Ato the EvDO = serving network. If the device did not support the 3GPP/3GPP2=0D=0Asolution= , this would not work - but it seems unreasonable to treat non-support=0D=0A= of a solution as a weakness since almost every solution is susceptible to t= his.

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

&= nbsp;

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

[AJW] Any device behind a=0D=0Ahome 3G rou= ter will have no visibility of the connected cell-id. Cell-ID is also=0D=0A= of almost no use to anyone but the operator of the access network, so inclu= ding=0D=0Athis in a call to a VSP that knows nothing about EVDO, let along = a specific=0D=0Aaccess provider seems almost as big a stretch as universal = SUPL roaming. Why=0D=0Anot simply make the location available to the caller= using the mechanisms=0D=0Adescribed in GeoPriv=3F Once this is done you ha= ve ECRIT, i2, or i3 and they will=0D=0Ajust work! =

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

 =

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

The above would not prevent the VSP= from employing the Ecrit solution=0D=0Afor other types of access not suppo= rting the 3GPP/3GPP2 solution and the=0D=0Aincremental cost to the VSP of s= upporting the 3GPP/3GPP2 solution (by means of=0D=0Athe 380 response) ought= to be small.

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

 

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

<= b>[AJW] The argument again=0D=0Ais = that device may not know about the underlying dependency between access and=0D= =0Aservice and in a number of circumstances it absolutely will not know. Th= e=0D=0Adevice might be able to learn the address of the local ES-Proxy, but= if you are=0D=0Agoing to employ that solution why not just employ an optio= n to discover the LIS=0D=0Aand the LoST server=3F<= /b>

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

 <= /p>=0D=0A=0D=0A

= The one case I have omitted but whic= h I assume you may specifically=0D=0Ahave in mind is where the device only = supports IP data access and acts as a=0D=0Arouter on behalf of another end = device (e.g. a laptop). In that case, I think=0D=0Aboth solutions would be = severely handicapped. The Ecrit solution would have a=0D=0Ahard time obtain= ing location (unless the end device already had an accurate location=0D=0Af= ix which it included in the SIP INVITE) and in routing to a PSTN capable PS= AP=0D=0A(particularly one in another country). =0D=0A=0D=0A

 

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

[AJW] Let’s agree to=0D=0Adisagree on this point. The 3GPP access be= hind the router is the Internet=0D=0Aaccess provider and will likely have t= o provide location to the device. We have=0D=0Agot pretty good LIS discover= y mechanisms described in Geopriv that address most=0D=0Amajor concerns, so= actually I believe that ECRIT and NENA i2 will work quite=0D=0Awell.<= /o:p>

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

 

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

The 3GPP/3GPP2 so= lution - assuming the VSP supported it - might find=0D=0Alocation easier (e= =2Eg. if the router or end device supported SUPL since that=0D=0Awould allo= w location for dispatch subsequent to call routing), but would find=0D=0APS= TN PSAP routing just as hard.

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

 

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

The parts of the Ecrit solution that appear unsuitable for cellu= lar=0D=0Anetworks I have already elaborated on - e.g. endpoint oriented loc= ation and=0D=0Arouting, no explicit cellular location capability, no explic= it support for=0D=0APSAPs accessed over the PSTN.<= /p>=0D=0A=0D=0A

=  

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

[AJW] I think you will=0D=0Afind that the WiMAX forum disagrees you with o= n a number of these points. And I=0D=0Ahave absolutely no doubt that with t= he 1.5 version of WiMAX I can support a=0D=0Afully mobile IP network using = the ECRIT emergency calling architecture.

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

 

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

I am not sure that I=0D=0Aunder= stand what you mean by “no explicit cellular location capability̶= 1;,=0D=0Aperhaps you can explain. Certainly using a protocol such as HELD I= can an awful=0D=0Alot and it all remains local so it doesn’t require= a world in a database to=0D=0Asupport roaming such as is required in some = protocols that we will not mention=0D=0Ahere…;)

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

 

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

 (the NENA i2 solution is n= ot a global standard and seems=0D=0Aimpractical where a PSAP is very remote= from the VSP), no consideration for=0D=0Ahandover to or from circuit mode = access (which will remain the norm for many=0D=0Ayears) or even to/from oth= er IP access networks.

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

 

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

[AJW] You are right that=0D= =0ANENA i2 is not a global standard, but it is being tailored for deploymen= t in at=0D=0Aleast 3 countries at I am aware of, and forms the basis for di= scussion in a=0D=0Anumber of others.

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

=  

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

I agree that circuit mode=0D=0Adevice= s will be around for a many years to come, I am less convinced that they=0D= =0Awill remain the norm, and with data only devices increasing in popularit= y I see=0D=0Athe need to hand-over in the way you describe as unnecessary. = Indeed I see it=0D=0Aas a technological mismatch, equivalent to being able = to hand-over my GSM call=0D=0Ato a CDMA network; Without a special, purpose= -built device I can’t do it.=0D=0ADelivery of calls from VoIP to circ= uit switched PSTN and vice versa is common=0D=0Aplace today from any number= of voice service providers and this is the mode of=0D=0Aoperation we shoul= d be discussing.  

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

 

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

 

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

 

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

Kind Regards

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

 

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

Stephen

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

 

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


----------------------= --------------------------------------------------------------------------<= br>=0D=0AThis message is for the designated r= ecipient only and may
=0D=0Acontain privileged, = ;proprietary, or otherwise private information. &n= bsp;
=0D=0AIf you have received it in erro= r, please notify the sender
=0D=0Aimmediately a= nd delete the original.  Any unauthorized&nbs= p;use of
=0D=0Athis email is prohibited.
=0D=0A--= ---------------------------------------------------------------------------= -------------------
=0D=0A[mf2]=0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01C99AF4.5A6FC511-- From br@brianrosen.net Mon Mar 2 08:23:11 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40D4A3A6887 for ; Mon, 2 Mar 2009 08:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=0.980, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inICQU36qGyG for ; Mon, 2 Mar 2009 08:23:09 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id DF8063A690F for ; Mon, 2 Mar 2009 08:22:50 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LeAv3-0006ys-2j; Mon, 02 Mar 2009 10:23:05 -0600 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Edge, Stephen'" , "'ECRIT'" References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net> <1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC53749E3B@NASANEXMB04.na.qualcomm.com> In-Reply-To: Date: Mon, 2 Mar 2009 11:23:03 -0500 Message-ID: <019501c99b53$2b0b1ff0$81215fd0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwKeEe+gADZBfMABQDsYoAA26fDAAJM+RGAAG+ZlYA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 16:23:11 -0000 I=92m also certain we=92re not going to converge, but let me step up a = level and observe that there is a fundamental flaw with the current cellular = emergency call architecture: The assumption that the access network always = provides emergency calling services, which is also related to the assumption that = the home and visited networks have a contractual relationship. =20 This is flawed even for 3GPP IMS networks that are fixed. They assume "nomadic" services that are provided by the home network, including emergency calling, and where there may not be a relationship between the access network and the calling network. It's also true of services that = a cellular network does not provide, but does provide the raw packet = access. AOL/MSN/Yahoo Instant Messaging for example, or Skype. The ecrit architecture does not make this assumption. =20 When the home network provides emergency services, then you may have to = get location from the access network, and send it via the home network. The device is the customer of both the access network and the calling = network, which is why the ecrit architecture works, and the current IMS = architecture does not. Brian From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 Sent: Monday, March 02, 2009 12:04 AM To: Edge, Stephen; Brian Rosen; ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Hi Stephen, I have the distinct impression that we are never going to agree on this subject, I would however like to point out some statements in text below that are either misleading, or at least able to be interpreted in an alternative manner than that which is provided. Please inline. Cheers James -----Original Message----- From: Edge, Stephen [mailto:sedge@qualcomm.com]=20 Sent: Friday, 27 February 2009 4:38 PM To: Winterbottom, James; Brian Rosen; ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Hi James Thanks for these further comments and for this oft repeated example - = namely use of a 3GPP or 3GPP2 IP access network to reach a non-3GPP/3GPP2 VSP. = This is always being thrown up as a reason that the 3GPP/3GPP2 solution = cannot even fully address its own calling scenarios. It is however incomplete = for the following reasons. [AJW] Let=92s agree to disagree on this point, it is a stated = requirement in TS23.167 (requirement 2 under section 4.1) that =93Emergency services = are independent from the IP-CAN with respect to the detection and routing of emergency sessions. The emergency services shall be possible over at = least a cellular access network, a fixed broadband access, I-WLAN access and a nomadic access.=94 I think, therefore that the solution is actually perfectly valid, the = 3GPP network is the IPCAN and it must allow independent detection and routing = of the emergency call. This requirement falls short of what some = legislative bodies are now considering the duty of the IPCAN to be, but it is still = a good start. First of all, I doubt that in this example either the Ecrit or = 3GPP/3GPP2 solution would actually be possible now since neither are fully defined = or fully implemented yet. Perhaps the VSP would provide some rudimentary = E911 capability though probably not to the right PSAP. So the example is more hypothetical for future implementation in which case either solution = might be considered. [AJW] This is true for ECRIT in that LoST servers are not widely = deployed and publically available. However there are certainly NENA i2 = deployments being tested (not sure if they are actually live yet) where the=A0 = originating call includes a PIDF-LO in the body with the call, and the VSP in conjunction with a VPC can route the emergency call to the correct PSAP. = I fully expect this to happen in cases where the Internet pipe is 3G so = let=92s agree that this is not hypothetical.=20 I am aware of two countries that are currently in the process or about = to begin the process of legislating Internet access providers to make = location available for the purpose of routing emergency Internet calls. It will = be interesting to see what impact this legislation has on 3G data only = devices and associated network operators, presumably they will need to comply = with the Internet access provider legislation or stop providing, I think that = it is more likely that they will comply. Maybe you are aware that CDMA EvDO providers will be obligated by the = FCC in the US to provide E911 capability assuming they are using licensed = spectrum. So in this example, and in a few more years when the 3GPP/3GPP2 solution = has been fully defined and implemented, the device in question would be able = to access the CDMA EvDO network, assuming it recognized the dialed = emergency number and supported the 3GPP/3GPP2 solution, and make an IP based E911 = call directly via the serving EvDO network and not via its normal VSP. [AJW] Martin, Brian and possibly Richard have already described a = serious flaw in this line of thinking. Namely that if I have a 3G Internet = router, any device behind that router has absolutely no visibility that it needs = to talk to a different VSP, the solution you are proposing almost suggests therefore that the wireless router requires E-CSCF functionality in it = and that it can detect when a device in the home network is making an = emergency call. This is very intrusive and certainly not backward compatible with = the legacy devices already deployed.=20 =A0If it did not recognize the dialed emergency number or chose to use = the normal VSP anyway but still supported the 3GPP/3GPP2 solution, then the = VSP (e.g. based on receiving some access network related information from = the device in the SIP INVITE such as an EvDO cell ID and possibly based on subscription information if needed to imply 3GPP/3GPP2 capability for = the device) could send an error response back to the device (a SIP 380 = response with an emergency indication) that would cause the device to redirect = the call to the EvDO serving network. If the device did not support the 3GPP/3GPP2 solution, this would not work - but it seems unreasonable to treat non-support of a solution as a weakness since almost every = solution is susceptible to this. [AJW] Any device behind a home 3G router will have no visibility of the connected cell-id. Cell-ID is also of almost no use to anyone but the operator of the access network, so including this in a call to a VSP = that knows nothing about EVDO, let along a specific access provider seems = almost as big a stretch as universal SUPL roaming. Why not simply make the = location available to the caller using the mechanisms described in GeoPriv? Once = this is done you have ECRIT, i2, or i3 and they will just work!=20 The above would not prevent the VSP from employing the Ecrit solution = for other types of access not supporting the 3GPP/3GPP2 solution and the incremental cost to the VSP of supporting the 3GPP/3GPP2 solution (by = means of the 380 response) ought to be small. [AJW] The argument again is that device may not know about the = underlying dependency between access and service and in a number of circumstances = it absolutely will not know. The device might be able to learn the address = of the local ES-Proxy, but if you are going to employ that solution why not just employ an option to discover the LIS and the LoST server? The one case I have omitted but which I assume you may specifically have = in mind is where the device only supports IP data access and acts as a = router on behalf of another end device (e.g. a laptop). In that case, I think = both solutions would be severely handicapped. The Ecrit solution would have a hard time obtaining location (unless the end device already had an = accurate location fix which it included in the SIP INVITE) and in routing to a = PSTN capable PSAP (particularly one in another country).=20 [AJW] Let=92s agree to disagree on this point. The 3GPP access behind = the router is the Internet access provider and will likely have to provide location to the device. We have got pretty good LIS discovery mechanisms described in Geopriv that address most major concerns, so actually I = believe that ECRIT and NENA i2 will work quite well. The 3GPP/3GPP2 solution - assuming the VSP supported it - might find location easier (e.g. if the router or end device supported SUPL since = that would allow location for dispatch subsequent to call routing), but would find PSTN PSAP routing just as hard. The parts of the Ecrit solution that appear unsuitable for cellular = networks I have already elaborated on - e.g. endpoint oriented location and = routing, no explicit cellular location capability, no explicit support for PSAPs accessed over the PSTN. [AJW] I think you will find that the WiMAX forum disagrees you with on a number of these points. And I have absolutely no doubt that with the 1.5 version of WiMAX I can support a fully mobile IP network using the ECRIT emergency calling architecture.=20 I am not sure that I understand what you mean by =93no explicit cellular location capability=94, perhaps you can explain. Certainly using a = protocol such as HELD I can an awful lot and it all remains local so it doesn=92t require a world in a database to support roaming such as is required in = some protocols that we will not mention here=85;) =A0(the NENA i2 solution is not a global standard and seems impractical = where a PSAP is very remote from the VSP), no consideration for handover to or from circuit mode access (which will remain the norm for many years) or = even to/from other IP access networks. [AJW] You are right that NENA i2 is not a global standard, but it is = being tailored for deployment in at least 3 countries at I am aware of, and = forms the basis for discussion in a number of others. I agree that circuit mode devices will be around for a many years to = come, I am less convinced that they will remain the norm, and with data only = devices increasing in popularity I see the need to hand-over in the way you = describe as unnecessary. Indeed I see it as a technological mismatch, equivalent = to being able to hand-over my GSM call to a CDMA network; Without a = special, purpose-built device I can=92t do it. Delivery of calls from VoIP to = circuit switched PSTN and vice versa is common place today from any number of = voice service providers and this is the mode of operation we should be = discussing. =A0 Kind Regards Stephen -------------------------------------------------------------------------= --- -------------------- This=A0message=A0is=A0for=A0the=A0designated=A0recipient=A0only=A0and=A0m= ay contain=A0privileged,=A0proprietary,=A0or=A0otherwise=A0private=A0informa= tion.=A0=A0 If=A0you=A0have=A0received=A0it=A0in=A0error,=A0please=A0notify=A0the=A0s= ender immediately=A0and=A0delete=A0the=A0original.=A0=A0Any=A0unauthorized=A0us= e=A0of this=A0email=A0is=A0prohibited. -------------------------------------------------------------------------= --- -------------------- [mf2] From john.elwell@siemens.com Tue Mar 3 06:43:38 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A3023A6929 for ; Tue, 3 Mar 2009 06:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUhXMKVzKCeI for ; Tue, 3 Mar 2009 06:43:36 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 6116C3A6948 for ; Tue, 3 Mar 2009 06:43:36 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KFX00255Q9DGU@siemenscomms.co.uk> for ecrit@ietf.org; Tue, 03 Mar 2009 14:44:02 +0000 (GMT) Date: Tue, 03 Mar 2009 14:43:53 +0000 From: "Elwell, John" In-reply-to: <53275.24.154.127.233.1235780998.squirrel@www.brianrosen.net> To: Brian Rosen , ecrit@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0019841D0@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Ecrit] Comments on phonebcp-07 Thread-Index: AcmZO7wrCJSl+7uKRxu/R6D9XpQw8QCzHAqA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <53275.24.154.127.233.1235780998.squirrel@www.brianrosen.net> Subject: Re: [Ecrit] Comments on phonebcp-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 14:43:38 -0000 Brian, Thanks for your responses. See below.=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Brian Rosen > Sent: 28 February 2009 00:30 > To: ecrit@ietf.org > Subject: Re: [Ecrit] Comments on phonebcp-07 >=20 > Thank you for your comments. Sorry this took so long. I am=20 > temporarily > unable to create an actual "Reply all" to your email, so this is > cut/pasted from a non-IETF archive (the archives are screwed=20 > up, there is > no mail from Feb 2 to Feb 27). The changes are now in=20 > -framework-08 and > -phonebcp-08 >=20 > Enterprise =3D access network operator. They must meet the AN=20 > requirements. > I'll point that out. Enterprises could run their own LoST=20 > server which > would deliver the right things (dial string, URI, ...). I've=20 > added text > on both enterprise as access network provider and potential=20 > LoST and PSAP > provider in -framework, and mentioned enterprise as a possible access > network provider in -phonebcp >=20 > 1. ED-6 vs ED-9 is the difference between discovery with a=20 > home country > code and provisioning of actual dial string. We haven't described > discovery, so I'll have to delete ED-6 >=20 > 2. I'll Reword SP-8 to say that Service providers may=20 > provision endpoints > with home dial strings (see ED-9) >=20 > 3. Changes in the list clarifies this, but ED-18 says do it, and ED-21 > specifies protocol support to do it. I added a reference to=20 > -21 in -18. >=20 > 4. We discussed this on the interim conference call. The=20 > resolution will > be to remove the requirement and have something non normative in > -framework. >=20 > 5. I'll downgrade the sip-sips reference to Informational. =20 > Could refer to > the 3.1 text. [JRE] It still doesn't make sense to me for a normative statement to refer to 3.1 of sip-sips when that section does not contain any normative language. All we are doing is saying that TLS MUST be used, and this doesn't seem to require any reference to sip-sips. So I would suggest removing the reference to sip-sips entirely. In addition (apologies if this has already been discussed), by mandating TLS we effectively are saying that you can't make an emergency call if you can't use TLS! I doubt if that is really the intent. Should it not say something like "An end device MUST use TLS, if available, when attempting to establish an emergency call."? >=20 > 6. Don't know how to define a requirement which assumes the=20 > presence of a > B2BUA. I propose to leave as is [JRE] Let me put it a different way. I don't think this is necessarily achievable by the end device (UA). If the registrar does not support GRUU, the UA may not have any means of obtaining a globally routable contact URI. Perhaps the second "MUST" should be "SHOULD", with some rationale why it might not always be possible. In any case, a locally routable contact URI is acceptable if a B2BUA maps it to a globally routable contact URI.=20 >=20 > 7. I'll fix the text for MUST and delete "normal" >=20 > 8. An actual problem. Calls out for a way to mark the Route as the > emergency route. Two solutions were discussed. One is to use the sos > parameter. The other is to say that the Geolocation header=20 > must not have > a "used for routing" parameter unless the LoST routing was=20 > completed. I > think I will recommend the second. [JRE] OK - but I didn't see this in 08. >=20 > 9. Rework to make it a SHOULD noting the issue. =20 > Unauthenticaed devices > usually are allowed to make calls, but not always. I'll add text. >=20 > 10. If the device is no longer registered, then the Contact can't be > valid. I can insert text to this effect. =20 [JRE] I didn't see this in 08. > Don't know how to=20 > handle B2BUAs > that munge Contact headers. I can at least call out the problem in > -framework. [JRE] That should be good enough. >=20 > 11. Tried to make the requirement minimal (no Replaces, for=20 > example), but > I think you need referred by. I'll think some more about=20 > that. I'll add > text that says device implementers should consider the effect=20 > of emergency > call transfer on a stressed user; generally, the device should do the > transfer. [JRE] I didn't see anything in 08. For a device, the requirement is to support receipt of REFER with method=3DINVITE, I believe, and to handle the Referred-By header field in such a request. If so, this should be stated clearly. >=20 > 12. Don't understand the problem. The situation described is=20 > AFTER a call > session is established, but before it is terminated. LoST=20 > resolution is > complete. [JRE] What I meant is how can the UA determine that the new call originated at a PSAP. If the device did a LoST query, then a From or PAI URI matching the result of the LoST query might be one mechanism. But if the device didn't do a LoST query, or if the call comes from a different PSAP (e.g., because the original call was forwarded or transferred) that might not help. >=20 > 13. a) If a call arrives while an emergency call is up, we=20 > don't want a > call waiting tone, alert or other prompt, we don't want the=20 > emergency call > put on hold and we don't want the incoming call to be answered. [JRE] Thanks for the clarification, but this does not alter the fact that call waiting is not an outgoing call feature. It would be better to say what we mean, e.g., MUST disable features that will interrupt an ongoing emergency call, such as call waiting... > b) Although some features can be applied to incoming calls,=20 > they are also > applicable to outgoing calls, which is what we want here; we=20 > don't want > the emergency call put on hold, put into a client-side conference, ... [JRE] This too could be covered by the form of words I suggested above. > c) I'll add a definition of "flash hold" to -framework. Of =20 > course "flash > hold" does involve a proxy, where normal SIP hold does not. =20 > You don't > want Hold (that is, disconnect the media to or from the PSAP). [JRE] Flash hold as you now describe it in the framework is a PSTN feature, so how does it relate to a SIP device? >=20 > 14. Call waiting on an incoming call is the same as on an=20 > outgoing call: > you don't alert to another call, you don't offer hold and switch. The > PSAP callback stays up. Yes, 486 or voicemail is=20 > appropriate. Indeed the > recognition of the callback is difficult, and I hope we will=20 > charter an > item. I think the domain recognition is a reasonable first=20 > step, and I > recognize it won't always work. When it doesn't, callback=20 > won't get the > feature suppression. Not a good thing, but not fatal. [JRE] That is one way of interpreting the text of ED-72, but the way I interpreted it is this. If I am engaged in a (non-PSAP) call and a callback from a PSAP arrives, the callback is not allowed to use call waiting to interrupt the existing call. That seems wrong. So there are two situations: i) during an ordinary call when a callback from a PSAP arrives, and ii) during a call that is a callback from a PSAP (which really should be treated no differently from a call to a PSAP). >=20 > 15. I may be misinterpreting your concern, but I think the=20 > B2BUA that maps > Contact doesn't alter the caller's domain as seen by the=20 > called party. If > the call arrives directed TO the Contact or AoR given out in=20 > the original > emergency call, and it's FROM the same domain that answered=20 > the call, then > it should be treated as a call back. [JRE] I didn't express my concern correctly. How does the end device determine the domain of the PSAP that answers the call? We don't yet have response identity defined in SIP. We could get the PSAP to send a request (e.g., UPDATE) in the reverse direction and use PAI in that request or RFC 4916 to change the From URI. >=20 > 16. I don't really care much what error message we use. I=20 > can change it > to 404 if there are no objections. ".test" is not registered. We > probably should do that, but not in this document. It's not really > required that we register it, as it's a subdomain of a=20 > registered domain.=20 > i need to get a document started to register a couple of things not > dissimilar to this, so I'll put it in that [JRE] The point is, an entity that does not support phonebcp would presumably return a 404, no matter what we say in phonebcp. So I think 404 is correct. >=20 > 17. The response certainly should be using TLS, but it might=20 > not work.=20 > I'll add text. [JRE] "The test response SHOULD be protected with TLS. If the body cannot be protected, the location SHOULD NOT be included in the response.." Although the first hop from the responding node might be TLS, it is not known that all upstream hops are TLS. John >=20 > 18. I will delete the sentence referencing 4916. >=20 > Brian >=20 > ------ original message contents ------- > Some WGLC comments on this. Apologies for not raising them=20 > before, but I > have not participated in this WG until recently. >=20 > General comment: > It is not clear if and how this applies to enterprise networks. > Enterprise networks are mentioned in a couple requirements involving > intermediate range wireless connections, but that is all. Particular > requirements of enterprise networks, which might include their own > "PSAPs" in some situations, for example, and different dial strings in > some circumstances, do not seem to be addressed. So perhaps=20 > it should be > made clear that it does not address special requirements of enterprise > networks. >=20 > Detailed comments: >=20 > 1. "ED-6/SP-5 Devices MUST be able to be configured with the home > country > from which the home dial string(s) can be determined." > And later: > "ED-9 Endpoints SHOULD be able to have home dial strings provisioned > by configuration." > I can't figure out exactly why we need two separate requirements here. >=20 > 2. "SP-8 Service providers MAY provide home dial strings by > configuration" > It is not clear to whom or to what home dial strings are provided, and > how this relates to requirements ED-6/SP-5 and ED-9. >=20 > 3. "ED-18/INT-9 Endpoints SHOULD attempt to configure their own > location." > And later: > "ED-21/INT-12 Devices MUST support both the DHCP location options > [RFC4776], [RFC3825] and HELD" > There appears to be some inconsistency here. If there are=20 > circumstances > in which a device does not need to attempt to configure its=20 > own location > (because it is only SHOULD strength), why are support for=20 > DHCP and HELD > mandated? >=20 > 4. "ED-59 Best Current Practice for SIP user agents [RFC4504]=20 > including > handling of audio, video and real-time text [RFC4103] SHOULD be > applied." > Is it permissible for a Standards Track to make a SHOULD statement > involving an informational RFC? I believe not. Furthermore, RFC 4504 > refers back to ECRIT work, which makes it rather circular. >=20 > 5. "ED-60/SP-31 TLS MUST be specified when attempting to signal an > emergency call with SIP per [I-D.ietf-sip-sips]. IPSEC=20 > [RFC3986] is > an acceptable alternative." > I think we need to be more specific about what aspect of=20 > sip-sips we are > referring to. For example, are we talking about 3.1 "Models for using > TLS in SIP"? That section doesn't seem to include any normative > statements, so why is it a normative reference. The normative part of > sip-sips seems to relate to the SIPS URI scheme, which presumably we > don't want to use. >=20 > 6. " A Contact header MUST be present which MUST be globally > routable, for example a GRUU [I-D.ietf-sip-gruu], and be valid > for several minutes following the termination of the call to > permit an immediate call-back to the specific device which > placed the emergency call." > As a requirement for a user agent, I don't think this is necessary in > situations where there is a B2BUA that maps a local contact URI to a > globally routable contact URI. >=20 > 7. "ED-58 Initial INVITES MUST provide an Offer [RFC3264]." > And later: > "A normal SDP offer SHOULD be included in the INVITE. If voice > is supported the offer MUST include the G.711 codec, see > Section 14." > This seems contradictory (MUST and SHOULD). Also what is "normal"? >=20 > 8. "A proxy that processes such a call looks for > the presence of a SIP Route header field with a URI of a PSAP. > Absence of such a Route header indicates the UAC was=20 > unable to invoke > LoST and the proxy MUST perform the LoST mapping and insert a Route > header field with the URI obtained." > How does the proxy determine whether a URI is indeed a PSAP=20 > URI? Does it > need to examine the Geolocation header field to see if the=20 > location has > been used for routing? >=20 > 9. "Either a P-Asserted-Identity [RFC3325] or an Identity header > [RFC4474], or both, MUST be included to identify the sender." > A proxy cannot do this unless it has authenticated the UA or unless it > violates the rules of RFC 3325 or RFC 4474. I think we need some > commentary on whether unauthenticated UAs are allowed to make=20 > emergency > calls, and if so, how to get around this problem of providing PAI or > Identity. >=20 > 10. "SP-36 Call backs to the Contact: header URI recieved within 30 > minutes of an emergency call must reach the device=20 > regardless of call > features or services that would normally cause the call to=20 > be routed > to some other entity." > a) What if the device is no longer registered? > c) Also, what if there are downstream B2BUAs that map contact=20 > URIs? Will > they necessarily cache that mapping after the original call has > finished? If not, I don't see how a callback to the contact URI can > work. >=20 > 11. "ED-67/SP-38 During the course of an emergency call, devices and > proxies MUST support REFER transactions and the Referred-by: header > [RFC3515]." > a)This is a very broad requirement. I can see the need for supporting > REFER with SIP/SIPS URI and with method=3DINVITE. Is there a = requirement > beyond this? > b) A UA can support REFER by consulting its user whether to=20 > go ahead and > reference. The user may decline. Or UA policy might prevent certain > dereferences. Does anything need to be said about this? >=20 > 12. "If in the interval, an incoming call is received from > the domain of the PSAP, the device MUST drop the old call and alert > for the (new) incoming call." > Can the device necessarily determine this? For example, if the device > just submitted a dial string, or submitted a service URN without > performing a LoST query, or if the call gets retargeted to a different > PSAP domain? >=20 > 13. "ED-70/SP-39 User Agents and proxies MUST disable outgoing call > features such as > o Call Waiting > o Call Transfer > o Three Way Call > o Flash hold > o Outbound Call Blocking" > a) I don't see how Call Waiting can be considered an outgoing call > feature. Some explanation is needed. > b) I don't see call transfer, three way call (presumably 3-way > conference) and hold as "outgoing call features" particularly=20 > - you can > use these "features" with incoming calls too. > c) "Flash hold" seems to be a north American term - use a more generic > term or describe what this means. > d) If "flash hold" means "hold", proxies have no influence over it. > Also, if hold means "stop sending and rendering media", a=20 > device can do > that simply by preventing the user turning down the microphone or > speaker volume. Is this what it means? Removing any control=20 > over volume > seems unwise. >=20 > 14. " ED-72/SP-41 The User Agent and Proxies SHOULD disable the > following > incoming call features on call backs from the PSAP: > o Call Waiting" > a) Disabling call waiting will generally result in rejecting=20 > an incoming > call with a 486, or forwarding, e.g., to voicemail. Is this=20 > really what > is required? > b) How does a UA or proxy determine that the callback is from a PSAP > (see earlier comment, and also next comment)? >=20 > 15. "ED-73 Call backs SHOULD be determined by retaining the domain of > the > PSAP which answers an outgoing emergency call and instantiating a > timer which starts when the call is terminated. If a call is > received from the same domain and within the timer period, sent to > the Contact: or AoR used in the emergency call, it should=20 > be assumed > to be a call back. The suggested timer period is 5 minutes." > Suppose there is a B2BUA on the path that maps contact URIs.=20 > Every call > the UA makes through that B2BUA will have a contact URI with=20 > the domain > of that B2BUA, so every call within the time period concerned would be > treated as coming from a PSAP. >=20 > 16. "ED-81 INVITE requests to a service URN ending in ".test"=20 > indicates > a > request for an automated test. For example, > "urn:service.sos.fire.test". As in standard SIP, a 200=20 > (OK) response > indicates that the address was recognized and a 404 (Not=20 > found) that > it was not. A 486 (Busy Here) MUST be returned if the test service > is busy, and a 488 (Not Acceptable Here) MUST be returned=20 > if the PSAP > does not support the test mechanism." > This seems to be the wrong semantics for 488, since in this case there > is nothing wrong with the session description. Wouldn't 404 be more > appropriate, since the .test URN is not recognised? > Also, where is ".test" registered? >=20 > 17. "ED-82 In its response to the test, the PSAP MAY include=20 > a text body > (text/plain) indicating the identity of the PSAP, the requested > service, and the location reported with the call. For the latter, > the PSAP SHOULD return location-by-value even if the original > location delivered with the test was by-reference." > Isn't there a security issue with this, particularly for the=20 > case where > SIPS has not been used? There is no discussion in Security > Considerations. >=20 > 18. "The response MAY > include the connected identity of the PSAP per [RFC4916]." > RFC 4916 makes no provision for responses. >=20 > John > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From bernard_aboba@hotmail.com Tue Mar 3 09:09:52 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B70B3A6911 for ; Tue, 3 Mar 2009 09:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.321 X-Spam-Level: X-Spam-Status: No, score=-1.321 tagged_above=-999 required=5 tests=[AWL=-1.137, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5AUp+XkEVM7 for ; Tue, 3 Mar 2009 09:09:51 -0800 (PST) Received: from blu0-omc1-s18.blu0.hotmail.com (blu0-omc1-s18.blu0.hotmail.com [65.55.116.29]) by core3.amsl.com (Postfix) with ESMTP id 8EECB3A679C for ; Tue, 3 Mar 2009 09:09:51 -0800 (PST) Received: from BLU137-W20 ([65.55.116.8]) by blu0-omc1-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Mar 2009 09:10:18 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_9fe06693-430b-4f13-8695-917625816d91_" X-Originating-IP: [131.107.0.80] From: Bernard Aboba To: , , Date: Tue, 3 Mar 2009 09:10:18 -0800 Importance: Normal In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0019841D0@GBNTHT12009MSX.gb002.siemens.net> References: <53275.24.154.127.233.1235780998.squirrel@www.brianrosen.net> <0D5F89FAC29E2C41B98A6A762007F5D0019841D0@GBNTHT12009MSX.gb002.siemens.net> MIME-Version: 1.0 X-OriginalArrivalTime: 03 Mar 2009 17:10:18.0609 (UTC) FILETIME=[ED9D2610:01C99C22] Subject: Re: [Ecrit] Comments on phonebcp-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 17:09:52 -0000 --_9fe06693-430b-4f13-8695-917625816d91_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > In addition (apologies if this has already been discussed)=2C by mandatin= g > TLS we effectively are saying that you can't make an emergency call if > you can't use TLS! I doubt if that is really the intent. Should it not > say something like "An end device MUST use TLS=2C if available=2C when > attempting to establish an emergency call."? =20 This change makes sense. If taken literally=2C a TLS mandate would=20 result in the failure of many emergency calls with serious consequences for the callers. =20 =20 --_9fe06693-430b-4f13-8695-917625816d91_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B In addition (apologies if this has already been discussed)=2C by man= dating
>=3B TLS we effectively are saying that you can't make an emerg= ency call if
>=3B you can't use TLS! I doubt if that is really the int= ent. Should it not
>=3B say something like "An end device MUST use TLS= =2C if available=2C when
>=3B attempting to establish an emergency cal= l."?
 =3B
This change makes sense. =3B If taken literally=2C =3Ba TLS mandate= would
result in the failure of many emergency calls with serious consequences
for the callers. =3B  =3B
 =3B
= --_9fe06693-430b-4f13-8695-917625816d91_-- From khwolf1@gmail.com Tue Mar 3 13:59:02 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DF013A69A0 for ; Tue, 3 Mar 2009 13:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2wn9+V7o5jz for ; Tue, 3 Mar 2009 13:59:01 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 0B30128C18D for ; Tue, 3 Mar 2009 13:58:29 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so2651843yxm.49 for ; Tue, 03 Mar 2009 13:58:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1xG28hsMOjtJ9hZmdNAJbZ2WQGADxV2T0PNQJhqYgNc=; b=CkwrXDKkU6kDr6BFNl7JCY4MkZMQTGqx6Lpx0zEPJCwb/p2wkhlzzoP/i0eQbIgcQt lJUiIMs8EmJawdd7KhaU6VxKfoFYX/M+WaTMZUQdoxYT/YDI2oAMh1F3y23/4BvdYcYS zogsqbu47+bNeeUU4PiIPKDWDBEvJZRmYyFGI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jOIQ6mK+GvnIrNHJsHEewR4si8GpwsTLsci8NZWDr+r4vR9wqpqX5q7IejOkFofyCZ inTbKIFCEC0EnKy5n4YooCtxwCoMNc56gyFqOitb1+v8Qm+LXMWywJ9fXHEep+rC/n6R 6wv+F1p3iAV0HT2JcmRKQuyDIa2ZAvuX8Xa3Q= MIME-Version: 1.0 Received: by 10.220.44.197 with SMTP id b5mr2600265vcf.114.1236117537347; Tue, 03 Mar 2009 13:58:57 -0800 (PST) In-Reply-To: <53275.24.154.127.233.1235780998.squirrel@www.brianrosen.net> References: <53275.24.154.127.233.1235780998.squirrel@www.brianrosen.net> Date: Tue, 3 Mar 2009 16:58:57 -0500 Message-ID: From: Karl Heinz Wolf To: Brian Rosen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments on phonebcp-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 21:59:02 -0000 Brian, just one comment on the now deleted ED-6: > 1. ED-6 vs ED-9 is the difference between discovery with a home country > code and provisioning of actual dial string. =A0We haven't described > discovery, so I'll have to delete ED-6 > I thought LoST would be the way to discover dial strings for the home country. A mapping request with just the home country as location information would be the discovery, wouldn't it? karl heinz From br@brianrosen.net Tue Mar 3 14:24:56 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECE743A6973 for ; Tue, 3 Mar 2009 14:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJkrgAQY35v2 for ; Tue, 3 Mar 2009 14:24:56 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 40B593A679C for ; Tue, 3 Mar 2009 14:24:56 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Led30-00012D-V9; Tue, 03 Mar 2009 16:25:11 -0600 From: "Brian Rosen" To: "'Karl Heinz Wolf'" References: <53275.24.154.127.233.1235780998.squirrel@www.brianrosen.net> In-Reply-To: Date: Tue, 3 Mar 2009 17:25:13 -0500 Message-ID: <00e901c99c4e$ee6bbcb0$cb433610$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmcS0KQmg5tv23HRcKoklz/ioD6cgAA2jdA Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments on phonebcp-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 22:24:57 -0000 Hmmmm. That works. Either I forgot about it, or we never actually discussed it. I'll put it back and put some text in -framework about it: You MAY provision home country The device could discover home dial strings knowing home country via = LoST. Sorry about that. ED-6 will come back. Brian -----Original Message----- From: Karl Heinz Wolf [mailto:khwolf1@gmail.com]=20 Sent: Tuesday, March 03, 2009 4:59 PM To: Brian Rosen Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments on phonebcp-07 Brian, just one comment on the now deleted ED-6: > 1. ED-6 vs ED-9 is the difference between discovery with a home = country > code and provisioning of actual dial string. =A0We haven't described > discovery, so I'll have to delete ED-6 > I thought LoST would be the way to discover dial strings for the home country. A mapping request with just the home country as location information would be the discovery, wouldn't it? karl heinz From br@brianrosen.net Tue Mar 3 14:25:27 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D5033A6A96 for ; Tue, 3 Mar 2009 14:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFceG9wE8Wbe for ; Tue, 3 Mar 2009 14:25:18 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 70F993A6973 for ; Tue, 3 Mar 2009 14:25:18 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Led3N-00013A-O9; Tue, 03 Mar 2009 16:25:34 -0600 From: "Brian Rosen" To: "'Bernard Aboba'" , , References: <53275.24.154.127.233.1235780998.squirrel@www.brianrosen.net> <0D5F89FAC29E2C41B98A6A762007F5D0019841D0@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: Date: Tue, 3 Mar 2009 17:25:36 -0500 Message-ID: <00ea01c99c4e$fc177e30$f4467a90$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EB_01C99C25.13417630" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmcIupFRYeqRgtgR1aFHzcpYY2c+gALANqA Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Comments on phonebcp-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 22:25:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00EB_01C99C25.13417630 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please read the document: ED-61/SP-32 If TLS session establishment fails, the call MUST be retried without TLS. From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Tuesday, March 03, 2009 12:10 PM To: john.elwell@siemens.com; br@brianrosen.net; ecrit@ietf.org Subject: RE: [Ecrit] Comments on phonebcp-07 > In addition (apologies if this has already been discussed), by mandating > TLS we effectively are saying that you can't make an emergency call if > you can't use TLS! I doubt if that is really the intent. Should it not > say something like "An end device MUST use TLS, if available, when > attempting to establish an emergency call."? This change makes sense. If taken literally, a TLS mandate would result in the failure of many emergency calls with serious consequences for the callers. ------=_NextPart_000_00EB_01C99C25.13417630 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please read the document:

 

   ED-61/SP-32 If TLS session establishment = fails, the call MUST be

   retried without TLS.

 

From:= Bernard = Aboba [mailto:bernard_aboba@hotmail.com]
Sent: Tuesday, March 03, 2009 12:10 PM
To: john.elwell@siemens.com; br@brianrosen.net; = ecrit@ietf.org
Subject: RE: [Ecrit] Comments on = phonebcp-07

 

> In addition (apologies if this has already been discussed), by = mandating
> TLS we effectively are saying that you can't make an emergency call = if
> you can't use TLS! I doubt if that is really the intent. Should it = not
> say something like "An end device MUST use TLS, if available, = when
> attempting to establish an emergency call."?
 
This change makes sense.  If taken literally, a TLS mandate = would
result in the failure of many emergency calls with serious = consequences
for the callers.   
 

------=_NextPart_000_00EB_01C99C25.13417630-- From khwolf1@gmail.com Tue Mar 3 14:27:29 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EC003A68C3 for ; Tue, 3 Mar 2009 14:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxsoHefQo10Q for ; Tue, 3 Mar 2009 14:27:28 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by core3.amsl.com (Postfix) with ESMTP id 692993A679C for ; Tue, 3 Mar 2009 14:27:28 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so2080629ana.4 for ; Tue, 03 Mar 2009 14:27:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oROEn39yFEJR1WjGiLKGLvjo2ftNSPqCFocAV6lke/A=; b=PkMQZmeElF42x1Ggo3nGtmrbwS+QujdFrOZnpQq7dFQmQ1bsoufYLqpVt5bbMefYux Ru0cY55Qro1v+Epu75aaCrFpIBdSzC+41cAZqunQOkqJkgKlg6xPyj1EnvKXZZ70/Zt3 jrrhIlhEUJ+W9TBWk18evQndkhYHel1UGHH/Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=L+Hh2NpUUeln/Eb184RuNeQGEMZlnW5ndmplPJDHneCpOyHzQ/tm2j20hDULZtaxTJ UGTxDzpeP1HTsAUliPqfXwtQT0xk3rwgL/Zyx/vBKPr1cXj6J1hVaGCzxtEUxMIZcW1v Q1A7AKnqFHFUIJv/yNVp8Uewmvihj9I1mo+ow= MIME-Version: 1.0 Received: by 10.220.86.203 with SMTP id t11mr2604732vcl.108.1236119275425; Tue, 03 Mar 2009 14:27:55 -0800 (PST) In-Reply-To: <053501c998ff$1d90a170$2ab5b70a@nsnintra.net> References: <053501c998ff$1d90a170$2ab5b70a@nsnintra.net> Date: Tue, 3 Mar 2009 17:27:55 -0500 Message-ID: From: Karl Heinz Wolf To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ECRIT Subject: Re: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 22:27:29 -0000 I just submitted an updated version of the draft based on the comments by Henning: http://www.ietf.org/internet-drafts/draft-wolf-ecrit-lost-servicelistboundary-01.txt Comments and feedback is appreciated. Karl Heinz On Fri, Feb 27, 2009 at 12:16 PM, Hannes Tschofenig wrote: > Hi all, > > Karl Heinz prepared some nice slides for our "virtual interim meeting" to > describe the ServiceListBoundary concept, see > http://tools.ietf.org/wg/ecrit/trac/attachment/wiki/WikiStart/draft-wolf-ecr > it-lost-servicelistboundary.ppt > > We had a couple of folks saying that this is a useful extension to LoST. > > Marc and I would need a few more folks who support the idea and are willing > to review the document. Please drop us a note. > > Ciao > Hannes & Marc > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From jmpolk@cisco.com Tue Mar 3 19:59:39 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65C3E3A6929 for ; Tue, 3 Mar 2009 19:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JD-beKKsGzEo for ; Tue, 3 Mar 2009 19:59:38 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7E7C53A684C for ; Tue, 3 Mar 2009 19:59:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,298,1233532800"; d="scan'208";a="260791655" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 04 Mar 2009 04:00:06 +0000 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 n24406wE029380 for ; Tue, 3 Mar 2009 20:00:06 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n24406qA010309 for ; Wed, 4 Mar 2009 04:00:06 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, 3 Mar 2009 20:00:06 -0800 Received: from jmpolk-wxp01.cisco.com ([10.89.23.137]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Mar 2009 20:00:05 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 03 Mar 2009 22:00:04 -0600 To: "'ECRIT'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 04 Mar 2009 04:00:05.0966 (UTC) FILETIME=[B3E3B6E0:01C99C7D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2147; t=1236139206; x=1237003206; 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:=20FYI=20--=20ID=20rev-02=20that=20redirects=20Eme rgency=20call=20in=20IMS |Sender:=20; bh=F4dsFC4vJw+6WVqQitWUBwnZh4FpO+XcgPYtkMmIfmo=; b=r1y4JEOsxfU4+1NrP/Rl3Q/MtBxXjJwDfOH1jZDvtMAHLnGDZ5Lmh4/C2g Rze9BS6Z2eZtWz7XeJxG0qxAWjgEMshe91PnZ16gFpUtiUHBUWP6IBkMQaev CnOifwy0VgrG26EdzaKp8WVsPa+qJci2P6otnXXM6HTUKkDad+0mA=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Ecrit] FYI -- ID rev-02 that redirects Emergency call in IMS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 03:59:39 -0000 I'm just the messenger here... as I just noticed this abstract involving redirection of emergency calling in IMS, and thought this WG might be interested, given that this isn't into ECRIT, but into SIP... >From: Internet-Drafts@ietf.org >To: i-d-announce@ietf.org >Subject: I-D ACTION:draft-bakker-sipping-3gpp-ims-xml-body-handling-02.txt >Date: Tue, 3 Mar 2009 15:45:01 -0800 (PST) >X-BeenThere: i-d-announce@ietf.org >X-Mailman-Version: 2.1.9 > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : Specification of 3GPP IM CN Subsystem XML > body handling > Author(s) : J. Bakker > Filename : > draft-bakker-sipping-3gpp-ims-xml-body-handling-02.txt > Pages : 7 > Date : 2009-3-2 > >This document registers new disposition-types for the Content- > Disposition header field that apply to the application/3gpp-ims+xml > body used by 3GPP. The applicability of these content-disposition > values are limited to 3GPP IMS. The application/3gpp-ims+xml body > has the following two distinct uses: (1) for redirecting the > emergency session to use a different domain (e.g. using a Circuit > Switched call), and (2) for delivering user profile specific > information from the SIP registrar to an Application Server. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-bakker-sipping-3gpp-ims-xml-body-handling-02.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From sedge@qualcomm.com Tue Mar 3 21:31:29 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 382073A6783 for ; Tue, 3 Mar 2009 21:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.17 X-Spam-Level: X-Spam-Status: No, score=-103.17 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nZeZlx4rXbC for ; Tue, 3 Mar 2009 21:31:26 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 42D4C3A6A00 for ; Tue, 3 Mar 2009 21:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1236144714; x=1267680714; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" br@brianrosen.net"=20|CC:=20"Thomson, =20Martin"=20,=0D=0A=20=20=20 =20=20=20=20=20Richard=20Barnes=0D=0A=09 ,=20ECRIT=20|Date:=20Tue,=203=20Mar=20200 9=2021:31:40=20-0800|Subject:=20RE:=20[Ecrit]=20Comments =20on=20Framework=20Draft|Thread-Topic:=20[Ecrit]=20Comme nts=20on=20Framework=20Draft|Thread-Index:=20AcmY6xBP94ju pkzETj+iA0b5U69mvgDj/Ibw|Message-ID:=20<1288E74A73964940B 132A0B9EA8D8ABC5374A0D6@NASANEXMB04.na.qualcomm.com> |References:=20<1288E74A73964940B132A0B9EA8D8ABC535F0305@ NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c 60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEX MB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com>=0D=0A=20 =20=20=20<1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANE XMB04.na.qualcomm.com>=0D=0A=20=20=20=20=0D=0A=20=20 =20=20<1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB 04.na.qualcomm.com>=0D=0A=20<64147.24.154.127.233.1235746 352.squirrel@www.brianrosen.net>|In-Reply-To:=20<64147.24 .154.127.233.1235746352.squirrel@www.brianrosen.net> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5542"=3B=20a=3D"15943471"; bh=dlRGQRfScqWNvvGj9uiAhp4UlRj6zTdl6OBrYWFLDwI=; b=A+qCazsRdZHqLM7QS0Cnj0K8KohcabncNVJnNa5Lh1ut76XK1FVNjudT tRnx0PzuFkYIYqxdH0ZDfV9WiyklhdeZG1kxl5fU69JXommxJOpJQN3RZ tl8CzlD71fdyqQMdO14zB7wqKM+c00xzlB4/FX3JAF3OIs7JScqYGS4ux 8=; X-IronPort-AV: E=McAfee;i="5300,2777,5542"; a="15943471" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Mar 2009 21:31:49 -0800 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n245VmhE019477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Mar 2009 21:31:48 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n245VlBv028365 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Mar 2009 21:31:47 -0800 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Tue, 3 Mar 2009 21:31:46 -0800 From: "Edge, Stephen" To: "br@brianrosen.net" Date: Tue, 3 Mar 2009 21:31:40 -0800 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmY6xBP94jupkzETj+iA0b5U69mvgDj/Ibw Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5374A0D6@NASANEXMB04.na.qualcomm.com> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com> <64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net> In-Reply-To: <64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 05:31:29 -0000 Brian Thanks for these well considered responses. Below I am providing on an item= by item basis, and taking into account your responses, a few more reasons = why the current Ecrit solution is unsuitable - or, if you prefer, less suit= able than the 3GPP/3GPP2 solution - for cellular networks. 1. Access to PSTN capable PSAPs Assuming that the best available solution for this currently is the ongoing= NENA i2 standard (as you comment), then there are problems with providing = location for dispatch (initial and updated location). For example, the late= st i2.5 draft I have (December 2008) says that the VPC to LIS v3 interface = is being deprecated (thus not available), although this is the interface th= at the VPC would use to query location from the LIS. Also I don't see any i= nclusion of accurate positioning support - e.g. using A-GPS. Further, inter= working with the circuit mode side for UA access (as opposed to PSAP access= ) seems to be out of scope. So at best, this standard is incomplete (i.e. n= ot yet suitable for cellular networks). However, I agree that there is some= overlap between i2.5 and the 3GPP/3GPP2 solution. 2. Handover between different IP access networks including different types = of access network One of the issues here would be change of LIS across different networks whi= le avoiding impacts to both IP and PSTN capable PSAPs (i.e. handover must b= e transparent to PSAPs within the limitations imposed by SIP or some J-STD-= 036 type of circuit mode solution). The problem gets more difficult when ha= ndover to/from circuit mode access networks is considered. So far, 3GPP/3GP= P2 has not yet agreed on a solution although there are proposals and we exp= ect some resolution soon. On the Ecrit and NENA sides, I see much less prog= ress. 3. Handover to/from circuit mode networks We agree here at least on the out of scope aspect. I suppose I can accept t= hat it is not customary to point this out in IETF standards. But I hope you= can see that this is an issue for cellular networks most of which will hav= e extensive circuit mode coverage for a long time to come. 4. Location for cellular access (and the requirement to support LCPs that w= ill be useless for cellular access) The issue is not so much the LCP itself but the capability to support accur= ate positioning - e.g. using A-GPS, AFLT, OTDOA, enhanced cell ID etc. None= of those methods seem to be supported as part of DHCP or HELD right now. S= o some modification of the LCP related requirements or of the LCPs seems ne= eded. 5. Endpoint based location and routing for cellular access (issues here are= network and device loading as well as device impacts and problems with PST= N capable PSAPs) Endpoint based location when spread over millions (billions, planet-wide) o= f terminals will consume significant network and terminal resources. A typi= cal terminal is generally idle and interacts with the network very sparingl= y to update the network with its current location (e.g. current cluster of = potential serving cells). Performing network assisted periodic location fix= es and LoST queries would add significantly to network load. Performing per= iodic location fixes in the terminal (e.g. using GPS) and estimating when a= PSAP boundary may have been crossed would add to terminal load (e.g. thus = battery drain). Optimizations would be possible of course - e.g. based on o= bserving nearby cell IDs - but they will add to terminal complexity and tes= ting costs. I agree that the Ecrit solution does allow for proxies to do th= is but here the solution also becomes incomplete because there seem no deta= ils of how this would work - e.g. what location solutions would then be use= d. 6. Support of unauthenticated users and users who can be authenticated but = are not permitted access/VSP service except for emergency calls I think the Ecrit solution and you both assume that this has already been r= esolved somehow at the access level and therefore the various procedures in= Ecrit can still be used. Maybe that is valid. However, there are still pro= blems that are not covered in the Ecrit drafts but need to be resolved incl= uding (a) obtaining IP access (e.g. via a WLAN, cellular network, cable lin= k) when not a valid subscriber, (b) obtaining access to the VSP and (c) ens= uring only emergency related services are provided (e.g. and not free Inter= net and location access). These and additional problems (e.g. UA identifica= tion) would have to be solved, maybe on a per access basis, and then ensure= d to be compatible with the rest of the Ecrit solution. A significant part = of the 3GPP/3GPP2 solution is concerned with this aspect and it has delayed= completion of the solution for the more normal case of valid subscriber ac= cess due to such compatibility issues. Kind Regards Stephen -----Original Message----- From: br@brianrosen.net [mailto:br@brianrosen.net] Sent: Friday, February 27, 2009 6:53 AM To: Edge, Stephen Cc: Thomson, Martin; Richard Barnes; ECRIT Subject: Re: [Ecrit] Comments on Framework Draft Stephen Like any standards organization, the IETF restricts it's scope. Generally, the scope is "the Internet", although we very often describe solutions that are explicitly designed for private IP networks as well as the Internet. We don't write standards for circuit switched networks, and it should be no surprise that the ecrit solution does not cater to CS solutions. Nevertheless, we often try to make sure that our solutions harmonize reasonably well with existing solutions. Indeed, the ecrit solution clains global applicability to the Internet in general, and most private IP networks that can be interconnected to the Internet or to other IP networks via gateways. Looking at your list of problem areas: > - access to PSTN capable PSAPs This is out of scope for IETF. NENA has active work on this subject. It seems straightforward to interwork ecrit compatible devices and networks to existing CS connected PSAPs. As you know, CS interconnects are very nation-specific, so the NENA work may not have general applicability. However, it shows that it is possible to interwork. The NENA i2 work is also designed to take ecrit compatible devices and VSP networks, and interwork them to the existing network. The VSP would direct the call to the VPC, which would provide the services it does now, using the device provided location for routing. This is important for smooth transition from existing PSAPs and VSPs to "next generation" PSAPs and VSPs. > - handover between different IP access networks including different > types of access network In the ecrit solution, the access network the call is initiated on provides all the facilities needed for the device to initiate an emergency call. The call starts traversing it's normal call path, and eventually routes to the ESRP. Handoffs between IP networks should be transparent to this process, although we probably haven't done all the work we need to do for handoffs where the IP address as seen by the terminating network changes. This would generally be true of all current SIP based work. > - handover to/from circuit mode networks This would be out of scope for IETF. It's as applicable to a simple SIP call as it is a SIP emergency call, and there are no statements in any SIP documents on that subject. > - location for cellular access (and the requirement to support LCPs tha= t > will be useless for cellular access) Location for cellular access networks has been considered carefully. Since cellular is a mobile network, the access network would pass the device a Location-By-Reference URI, using either DHCP or HELD. Either protocol is suitable for cellular networks. As we have pointed out several times, cellular networks support raw data packet services upon which many different kinds of networks can be constructed. My usual example is a large recreational vehicle traveling down a road with a cellular data card plugged into a router to which a wired (Ethernet) phone is connected. That phone must be able to make an emergency call, and it will get location from DHCP or HELD (or LLDP-MED). It is not aware of the cellular network, and doesn't know any cellular specific protocols. Cellular networks will have to support IETF location configuration protocols unless they actively prohibit examples like this, or they implement interworking between cellular-specific location protocols and DHCP or HELD in the data card. The ecrit standards permit proxy insertion of location, but, as above, we don't think that works in all cases. > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) The "load" of using DHCP or HELD to get location and querying LoST is pretty modest. The standards permit proxies to do this if the devices don't. As above, interwork functions to CS connected PSAPs is very feasible, and as above, cellular networks will have to support access to local LoST servers for devices that are connected to cellular networks and are ecrit compliant. > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls This is covered in the standards. None of the processes are dependent on authentication, although where it is possible, it's desirable so as to minimize fraudulent emergency calls Mechanisms for specific network authentication mechanisms are out of scope, and, like SIP basic calling, are not usually mentioned in IETF documents. Stephen, we've tried pretty hard to make sure this works for 3G/4G mobile networks. It's true that it doesn't do it the way 3GPP currently thinks it ought to work, but we claim they haven't thought through all the issues. While it would work, there are opportunities for improvement. We would be willing to do that if we could get the cooperation of 3GPP, which we have tried, and failed, to do. So, I think the documents do not need any qualification statements. Brian > Martin > > The 3GPP/3GPP2 solution has a defined restricted applicability (mainly to > 3GPP/3GPP2 access networks where the serving network also acts as the VSP= ) > and the specifications for it cover in detail all possible scenarios > consistent with these restrictions so far as we are aware. > > The Ecrit solution seems to claim global applicability to all types of IP > access (and the more that is said about this from Ecrit participants the > more this gets emphasized) but does not cover in detail all possible > scenarios (in some cases does not cover in any detail) which means that a= t > best the solution is incomplete and at worst intrinsically inapplicable t= o > some unstated set of scenarios. > > The missing, incomplete and problematic cases include the following: > > - access to PSTN capable PSAPs > - handover between different IP access networks including different > types of access network > - handover to/from circuit mode networks > - location for cellular access (and the requirement to support LCPs tha= t > will be useless for cellular access) > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls > > Stating that some of these cases are out of scope or referencing an > incomplete and possibly questionable specification from some other > national SDO will not help the user who encounters such problems. But it > would certainly help network operators and implementers to acknowledge > their existence in one form or another because that would allow better > planning of deployments and would help focus attention on finding > solutions (whether in IETF or elsewhere) for the missing cases. > > Please note that despite these drawbacks, I will acknowledge that Ecrit > does have a valuable solution that covers many scenarios not covered by > 3GPP/3GPP2. It would be the delineation of these supported scenarios (or > equivalently unsupported scenarios) in some applicability statement that > would be particularly useful right now. > > Kind Regards > > Stephen > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Thursday, February 26, 2009 9:45 PM > To: Edge, Stephen; Richard Barnes > Cc: ECRIT > Subject: RE: [Ecrit] Comments on Framework Draft > > There's benefit in knowing the limitations of a framework, and every > architecture makes certain assumptions. Let's examine them though... > > The IETF might occasionally make the assumption that the standards it > develops are for Internet devices. That assumption probably need not be > stated explicitly. > > The ECRIT architecture relies on implementations of the protocols that it > references. That is not extraordinary. A reliance on implementation of > these protocols by endpoints, routing intermediaries and PSAPs should not > need to be explained. > > So the assumptions are: > - the Internet > - solutions are implemented and deployed > - the end device is a key component > > Only that last element is particularly novel ... or not that much really. > It's a design choice. Unless you were thinking of trunking the voice > elsewhere. > > Of course, you're suggesting that the design choice was made in ignorance > of all the constraints. You're suggesting that - as a result - the choic= e > is flawed and the solution is not going to work for cellular services. W= e > disagree. The solution is a basis for emergency calling in _any_ IP > network. > > Cheers, > Martin > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Edge, Stephen >> Sent: Friday, 27 February 2009 3:30 PM >> To: Richard Barnes >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Richard >> >> Thanks for the comments. Your statement below that "SIP emergency >> calling works if all parties behave as specified in these (IETF Ecrit) >> documents" to some degree highlights the problems we are raising. The >> documents do contain a number of implicit and explicit restrictions - >> like IP capable PSAPs, global IP access (no islands of circuit mode >> access for example), universal support of this solution by all access >> providers and VSPs (not much good if some opt for another solution) and >> end system oriented location and routing capability - which together >> make them unsuitable (we believe) for cellular wireless networks. If >> these restrictions and assumptions were all made explicit upfront, it >> would to a large degree (and possibly completely) address our concerns. >> >> You are right in assuming another set of specifications for the 3GPP >> and 3GPP2 solution. The applicability of this solution is explicitly >> defined in TS 23.167 (or more exactly in an already agreed CR in >> contribution S2-090752 which will become part of 23.167 in a few more >> weeks) to cover the following access types: GPRS (UTRAN WCDMA), I-WLAN, >> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN >> (LTE). So there is a restriction and arbitrary internet access is not >> covered (yet) as I have stated before. >> >> Kind Regards >> >> Stephen >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Wednesday, February 25, 2009 6:30 PM >> To: Edge, Stephen >> Cc: Brian Rosen; 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Stephen, >> >> I'm a little confused by the scope of what you're asking. The >> framework >> and phonebcp documents exist in order to describe the ECRIT solution: >> They say, in effect, "SIP emergency calling works if all parties behave >> as specified in these documents." >> >> As I understand what you're saying (and I'm by no means an expert in >> 3GPP), 3GPP specifies that one or more elements of this system behave >> differently. This simply means that 3GPP networks aren't complying >> with >> these specs. Just like there's no disclaimer in RFC 791 (IPv4) that >> says "this doesn't work on X.25 networks", it's not clear to me that an >> analogous disclaimer is called for here. >> >> I presume there are similar documents describing how emergency calling >> works in 3GPP networks. Do they include notes saying that the 3GPP >> solution doesn't work in the broader Internet? >> >> --Richard >> >> >> >> >> >> Edge, Stephen wrote: >> > Brian >> > >> > First of all apologies for the likely lateness of this reply - I >> actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest but >> it seems unlikely that my VPN, Outlook server and WiFi access >> capability will cooperate together to get it sent until I return to the >> office mid-next week. >> > >> > Anyhow thanks for your comments. There have actually been a number of >> conference calls between IETF and 3GPP participants over the last >> couple of years at which common features like support of IP emergency >> calls were discussed and these could have been good forum for >> participants on either side to have raised the kinds of issues you >> elaborate on below. Given that seems not so far to have happened, it >> could still be possible in future such calls. >> > >> > But the issues we are raising are not directly to do with further >> aligning the 2 solutions or with the lack of this in the past. We are >> simply pointing out that the solutions are currently different and that >> from a cellular wireless perspective, the Ecrit solution is not seen as >> suitable in all respects (for support of IP emergency calls originating >> from such access types). That is not just our point of view. 3GPP2 sent >> a liaison to Ecrit some months ago pointing out the same issues. >> > >> > So we are proposing that the Ecrit framework and phoneBCP spec.s >> include a statement acknowledging this - e.g. by referencing the >> alternative 3GPP/3GPP2 solution and indicating the IP access types for >> which the Ecrit solution will work without limitation (or equivalently >> the access types where limitations are not ruled out). >> > >> > We are not proposing further modification and extension of the Ecrit >> solution - just pointing out that this would be needed (as with the >> 3GPP/3GPP2 solution) to fully cover all types of access. >> > >> > Kind Regards >> > >> > Stephen >> > -----Original Message----- >> > From: Brian Rosen [mailto:br@brianrosen.net] >> > Sent: Wednesday, February 18, 2009 8:07 PM >> > To: Edge, Stephen; 'ECRIT' >> > Subject: RE: [Ecrit] Comments on Framework Draft >> > >> > I have bit my tongue on this one for a long time. >> > >> > Stephen, with respect, please go talk to 3GPP management and ask them >> why >> > there has been no participation in the ecrit effort despite multiple >> YEARS >> > of begging them to get involved. To put it frankly, 3GPP is quite >> willing >> > to bully IETF into doing its work on its schedule, but cannot be >> bothered to >> > get work done it knows it will eventually have to do when the IETF >> asks it >> > to do so. >> > >> > 3GPP understands the mess that is being created by not participating. >> They >> > know full well that when they finally get around to dealing with PS >> > terminated emergency calls, that there will be a lot of resistance to >> > changing fully specified and implemented standards to more closely >> align >> > with 3GPP standards. I expect you will have several interworking >> functions >> > to define and build. >> > >> > So, politely, please go away, we're finishing work we dearly wanted >> you all >> > to be involved with for years, but you refused to do anything. It's >> too >> > late for this rev. >> > >> > Now, having said that, there are quite a few people who have >> participated in >> > the IETF work who are IMS aware and I believe that despite your >> fears, >> > everything you need is in the specs. The mechanisms we have defined >> provide >> > the ability for the network to insert location, recognize and mark >> emergency >> > calls, and route on behalf of endpoints. An E-CSCF could quite >> > straightforwardly provide a SIP call towards an ecrit compatible >> PSAP. The >> > only not-quite-nice interwork would be from SUPL to HELD (or SIP), >> but it's >> > pretty easy to do that. I'll also note that we have tried to get OMA >> and >> > IETF to cooperate on location protocols, but we have been >> spectacularly >> > unsuccessful at that effort also. >> > >> > Brian >> > >> > >> > >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf >> >> Of Edge, Stephen >> >> Sent: Thursday, February 05, 2009 2:50 AM >> >> To: 'ECRIT' >> >> Subject: [Ecrit] Comments on Framework Draft >> >> >> >> All >> >> >> >> draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative >> >> description of how terminals and networks should support emergency >> >> calls made over IP capable facilities to IP capable PSAPs. It >> appears >> >> intended to cover all types of access network - including fixed >> line, >> >> WiFi and cellular (e.g. examples involving each can be found >> throughout >> >> the draft). >> >> >> >> When we evaluated this with respect to support of wireless cellular >> >> access and WiFi access associated with a cellular operator (e.g. >> WLAN >> >> or Femto cells integrated into a cellular network), we found that >> >> certain portions of the draft exhibited one or more of the following >> >> characteristics: >> >> >> >> (A) Inconsistent with already standardized wireless solutions >> >> >> >> (B) Inconsistent with essential wireless requirements and >> >> conventions >> >> >> >> (C) Already part of wireless standards or potentially part of >> >> future standards >> >> >> >> (A) refers to all portions of the draft framework that differ from >> the >> >> requirements and procedures currently standardized for wireless >> >> emergency access by 3GPP, 3GPP2 and OMA. This is a plain difference >> of >> >> solution and could be resolved through support of both solutions by >> >> terminals (with each solution being used according to the type of >> >> access network and VSP) or could be resolved by supporting only one >> >> solution and accessing only the types of network supporting that >> >> solution. To acknowledge this category, the framework document could >> >> reference the applicable wireless standards and point out that these >> >> are valid alternatives for wireless cellular based access. >> >> >> >> (B) refers to portions of the draft that would be unsuitable for >> >> wireless networks even if no alternative solution existed together >> with >> >> other portions missing from the draft that would be needed to fully >> >> support wireless networks. Examples of the former include: (a) >> emphasis >> >> on endpoint derivation of location, performance of Lost query and >> >> receipt of local dial strings; (b) restriction of LCPs to protocols >> >> that require terminal initiation (not allowing for network >> initiation >> >> as far as we can tell) and that include two LCPs (DHCP and LLDP) >> that >> >> are not applicable to (not defined for) cellular access; and (c) the >> >> requirement that a terminal or at least a LIS will update the PSAP >> >> whenever location changes. (a) is impractical due to network and >> >> terminal loading consequences and failure to support non-IP capable >> >> PSAPs; (b) makes location verification and updated location >> provision >> >> to PSAPs difficult or impossible; while (c) is also incompatible >> with >> >> support of existing non-IP capable PSAPs besides increasing terminal >> >> load and possibly interfering with optimum maintenance of the RF >> >> connection (e.g. if a terminal has to tune away from the serving >> base >> >> station or WLAN periodically to make location measurements). >> Examples >> >> of the latter include (d) absence of support for access to non-IP >> >> capable PSAPs as already mentioned (e.g. to support E911 phase 2 in >> the >> >> US); (e) no support for handover from the IP to the circuit domain >> when >> >> a terminal loses (e.g. moves out of) RF coverage in the IP domain; >> and >> >> (f) no allowance for limited access modes wherein a terminal may >> access >> >> a network only to place an emergency call with ensuing restrictions >> on >> >> (for example) location acquisition, PSAP callback and caller >> >> verification and identification to the PSAP. To resolve this >> category >> >> either significant changes to the framework document could be made >> or a >> >> disclaimer/applicability statement could be added stating that >> support >> >> of cellular wireless networks and their associated WLAN and Femto >> >> access points is not covered. >> >> >> >> Category (C) comprises concepts and capabilities in the draft that >> are >> >> either already part of the standardized solution for wireless >> networks >> >> or that might be added at a later time. Examples of the former >> include >> >> LoST, SIP location conveyance, general use of SIP, location for >> routing >> >> versus for dispatch, cellular positioning methods. Examples of the >> >> latter include use of location references and dereferencing and >> >> possible interworking between the current wireless network solutions >> >> (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. >> The >> >> presence of this category could be acknowledged by following the >> >> disclaimer for (B) with a statement that certain portions of the >> >> solution are expected to be incorporated into wireless networks now >> >> and/or in the future. >> >> >> >> We hope that these comments will be seen to be a useful addition to >> >> this review in the sense of enabling a more precise scoping for the >> >> framework document and we are willing to assist in providing wording >> >> for any disclaimer/applicability statement that the Ecrit working >> group >> >> may now deem fit to include. >> >> >> >> Kind Regards >> >> >> >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs >> (Qualcomm >> >> 3GPP2 TSG-X and TSG-C participant) >> >> >> >> PS this being sent on 2/4/09 at 11:50pm PST >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www.ietf.org/mailman/listinfo/ecrit >> > >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------------------= ----------------------- > 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://www.ietf.org/mailman/listinfo/ecrit > From john.elwell@siemens.com Tue Mar 3 23:59:46 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2A13A67F1 for ; Tue, 3 Mar 2009 23:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixcVvLnxVPAh for ; Tue, 3 Mar 2009 23:59:45 -0800 (PST) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 652FA3A67C0 for ; Tue, 3 Mar 2009 23:59:45 -0800 (PST) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KFZ00G8D1R9MO@siemenscomms.co.uk> for ecrit@ietf.org; Wed, 04 Mar 2009 07:49:57 +0000 (GMT) Date: Wed, 04 Mar 2009 07:49:56 +0000 From: "Elwell, John" In-reply-to: <00ea01c99c4e$fc177e30$f4467a90$@net> To: Brian Rosen , Bernard Aboba , ecrit@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0019843C6@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C99C9D.CFD34B53" Thread-Topic: [Ecrit] Comments on phonebcp-07 Thread-Index: AcmcIupFRYeqRgtgR1aFHzcpYY2c+gALANqAABMg0vA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <53275.24.154.127.233.1235780998.squirrel@www.brianrosen.net> <0D5F89FAC29E2C41B98A6A762007F5D0019841D0@GBNTHT12009MSX.gb002.siemens.net> <00ea01c99c4e$fc177e30$f4467a90$@net> Subject: Re: [Ecrit] Comments on phonebcp-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 07:59:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99C9D.CFD34B53 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Brian, =20 Concerning ED-60, I guess it depends how one interprets "TLS MUST be specified", which is rather a strange way of formulating a normative statement. For example, if when following RFC 3263 procedures TLS is not identified as a possibility, what does one do? It is not a case that TLS establishment fails, it simply isn't available. I still prefer the wording I proposed before: "An end device MUST use TLS, if available, when attempting to establish an emergency call". =20 I now notice a concern with ED-47, where it says that TLS MUST be used to protect the location. It does also refer to 9.1, where ED-61 resides, so there is a get-out for fallback to an alternative transport. However, I could interpret this in two ways. One way is to send the location unprotected. I believe this is the intention. But it could also be interpreted that you MUST NOT send location if signalling is not protected by TLS. Do you think some clarification is needed here too? =20 John =20 =20 ________________________________ From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: 03 March 2009 22:26 To: 'Bernard Aboba'; Elwell, John; ecrit@ietf.org Subject: RE: [Ecrit] Comments on phonebcp-07 =09 =09 Please read the document: =20 ED-61/SP-32 If TLS session establishment fails, the call MUST be retried without TLS. =20 From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Tuesday, March 03, 2009 12:10 PM To: john.elwell@siemens.com; br@brianrosen.net; ecrit@ietf.org Subject: RE: [Ecrit] Comments on phonebcp-07 =20 > In addition (apologies if this has already been discussed), by mandating > TLS we effectively are saying that you can't make an emergency call if > you can't use TLS! I doubt if that is really the intent. Should it not > say something like "An end device MUST use TLS, if available, when > attempting to establish an emergency call."? =20 This change makes sense. If taken literally, a TLS mandate would=20 result in the failure of many emergency calls with serious consequences for the callers. =20 =20 ------_=_NextPart_001_01C99C9D.CFD34B53 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Brian,
 
Concerning ED-60, I guess it depends how one interprets = "TLS MUST=20 be specified", which is rather a strange way of formulating a normative=20 statement. For example, if when following RFC 3263 procedures TLS is not = identified as a possibility, what does one do? It is not a case that TLS = establishment fails, it simply isn't available. I still prefer the = wording I=20 proposed before: "An end device MUST use TLS, if available, when = attempting to=20 establish an emergency call".
 
I now notice a concern with ED-47, = where it says=20 that TLS MUST be used to protect the location. It does also refer to = 9.1, where=20 ED-61 resides, so there is a get-out for fallback to an alternative = transport.=20 However, I could interpret this in two ways. One way is = to send=20 the location unprotected. I believe this is the intention. But it could = also be=20 interpreted that you MUST NOT send location if signalling is not = protected by=20 TLS. Do you think some clarification is needed here = too?
 
John
 
 

From: Brian Rosen = [mailto:br@brianrosen.net]=20
Sent: 03 March 2009 22:26
To: 'Bernard Aboba'; = Elwell,=20 John; ecrit@ietf.org
Subject: RE: [Ecrit] Comments on=20 phonebcp-07

Please=20 read the document:

 

  =20 ED-61/SP-32 If TLS session establishment fails, the call MUST=20 be

  =20 retried without TLS.

 

From: Bernard = Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: Tuesday, March 03, = 2009=20 12:10 PM
To: john.elwell@siemens.com; br@brianrosen.net;=20 ecrit@ietf.org
Subject: RE: [Ecrit] Comments on=20 phonebcp-07

 

> In = addition=20 (apologies if this has already been discussed), by mandating
> = TLS we=20 effectively are saying that you can't make an emergency call = if
> you=20 can't use TLS! I doubt if that is really the intent. Should it = not
> say=20 something like "An end device MUST use TLS, if available, when
> = attempting to establish an emergency call."?
 
This change = makes=20 sense.  If taken literally, a TLS mandate would
result = in the=20 failure of many emergency calls with serious consequences
for the=20 callers.   =20
 

------_=_NextPart_001_01C99C9D.CFD34B53-- From sedge@qualcomm.com Wed Mar 4 18:19:57 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E565D28C20B for ; Wed, 4 Mar 2009 18:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-wRMgMZA0gW for ; Wed, 4 Mar 2009 18:19:55 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 4093B28C14E for ; Wed, 4 Mar 2009 18:19:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1236219624; x=1267755624; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" Stark,=20Barbara"=20,=20"br@brianrosen.ne t"=20|CC:=20ECRIT=20 |Date:=20Wed,=204=20Mar=202009=2018:20:14=20-0800 |Subject:=20RE:=20[Ecrit]=20Comments=20on=20Framework=20D raft|Thread-Topic:=20[Ecrit]=20Comments=20on=20Framework =20Draft|Thread-Index:=20AcmY6xMaVsPKQOa6Rj2puYM6nfd6RAAC FkpAARDTCVA=3D|Message-ID:=20<1288E74A73964940B132A0B9EA8 D8ABC5374A196@NASANEXMB04.na.qualcomm.com>|References:=20 <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na. qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E7 4A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcom m.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9 EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A 73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm. com>=0D=0A=20<64147.24.154.127.233.1235746352.squirrel@ww w.brianrosen.net>=0D=0A=20<7582BC68E4994F4ABF0BD4723975C3 FA0D39534E@crexc41p>|In-Reply-To:=20<7582BC68E4994F4ABF0B D4723975C3FA0D39534E@crexc41p>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5543"=3B=20a=3D"15994771"; bh=KpuAVLABlt4Z/Lc0IoTo9TeVaJe8Drb1INsayxeR4/g=; b=eb1EbL1ewFFfvoMEsbDix8tKYQQlC6ZeAyoyIwbY7kS3VHH7zVEcJf7i T1+vNRj3Auew286mVUhy9nbnCa18eCSFUu5tvLA2kSkvmosSMeNySnolg RKEMkiBcmRYNMpJI55BImo0lDRqFgb+k7PnyInMqxKLUTRnHHF33CdCev k=; X-IronPort-AV: E=McAfee;i="5300,2777,5543"; a="15994771" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Mar 2009 18:20:24 -0800 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n252KNOG001342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Mar 2009 18:20:23 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n252KGdV007099 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Mar 2009 18:20:16 -0800 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Wed, 4 Mar 2009 18:20:15 -0800 From: "Edge, Stephen" To: "Stark, Barbara" , "br@brianrosen.net" Date: Wed, 4 Mar 2009 18:20:14 -0800 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmY6xMaVsPKQOa6Rj2puYM6nfd6RAACFkpAARDTCVA= Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5374A196@NASANEXMB04.na.qualcomm.com> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com> <64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net> <7582BC68E4994F4ABF0BD4723975C3FA0D39534E@crexc41p> In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0D39534E@crexc41p> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 02:19:58 -0000 Barbara and others Thanks for the comments. When I look at the PhoneBCP I see that both HELD and DHCP are mandatory for= the device whereas at least one of these is mandatory for the AN. While I = can also see that SUPL is not ruled out (though it is not mentioned or refe= renced), it appears to have been displaced by the HELD and DHCP requirement= s. On the other hand, many cellular networks have already deployed or are i= n the process of deploying SUPL and I am not aware of any that have deploye= d an accurate location capability using HELD or DHCP. So I would like to kn= ow how you see the current requirements as being suitable - after all, they= imply at the very least additional development and deployment on the part = of network and device vendors and network operators, whereas if SUPL was on= e of the defined LCPs, that additional development and deployment might be = mostly avoided. This question would not be applicable with some additional = scope limitation and so I had not previously raised it. But it is certainly= applicable in the context of the global scope that is being claimed by som= e responders. Kind Regards Stephen -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Friday, February 27, 2009 8:28 AM To: br@brianrosen.net; Edge, Stephen Cc: ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Thank you Brian. This is well said [except you left out the fact that ecrit also allows for devices to get their location through other mechanisms, such as GPS, SUPL, or other methods, and doesn't insist that the location be configured through DHCP or HELD]. I agree 100% that additional qualifications are unnecessary. Service providers, vendors, national bodies dealing with emergency services, and regulators aren't stupid. Please trust us to figure out for ourselves when/where/how to apply a "standard". There is no need to try to artificially limit or define scope, or to state the obvious (e.g., the architecture applies where it applies, and doesn't apply where it doesn't apply). We understand the role and scope of the IETF, and the role and scope of 3GPP and 3GPP2. And all the other SDOs (and national bodies and regulatory agencies). SDOs need to offer architectures that apply within the area of applicability for that SDO, and are useful to potential implementers, and leave it to the SPs, national bodies and regulators to decide which architectures and standards to use or to mandate within the scope of their network or jurisdiction. Again, we aren't stupid. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of br@brianrosen.net Sent: Friday, February 27, 2009 9:53 AM To: Edge, Stephen Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft Stephen Like any standards organization, the IETF restricts it's scope. Generally, the scope is "the Internet", although we very often describe solutions that are explicitly designed for private IP networks as well as the Internet. We don't write standards for circuit switched networks, and it should be no surprise that the ecrit solution does not cater to CS solutions. Nevertheless, we often try to make sure that our solutions harmonize reasonably well with existing solutions. Indeed, the ecrit solution clains global applicability to the Internet in general, and most private IP networks that can be interconnected to the Internet or to other IP networks via gateways. Looking at your list of problem areas: > - access to PSTN capable PSAPs This is out of scope for IETF. NENA has active work on this subject. It seems straightforward to interwork ecrit compatible devices and networks to existing CS connected PSAPs. As you know, CS interconnects are very nation-specific, so the NENA work may not have general applicability. However, it shows that it is possible to interwork. The NENA i2 work is also designed to take ecrit compatible devices and VSP networks, and interwork them to the existing network. The VSP would direct the call to the VPC, which would provide the services it does now, using the device provided location for routing. This is important for smooth transition from existing PSAPs and VSPs to "next generation" PSAPs and VSPs. > - handover between different IP access networks including different > types of access network In the ecrit solution, the access network the call is initiated on provides all the facilities needed for the device to initiate an emergency call. The call starts traversing it's normal call path, and eventually routes to the ESRP. Handoffs between IP networks should be transparent to this process, although we probably haven't done all the work we need to do for handoffs where the IP address as seen by the terminating network changes. This would generally be true of all current SIP based work. > - handover to/from circuit mode networks This would be out of scope for IETF. It's as applicable to a simple SIP call as it is a SIP emergency call, and there are no statements in any SIP documents on that subject. > - location for cellular access (and the requirement to support LCPs that > will be useless for cellular access) Location for cellular access networks has been considered carefully. Since cellular is a mobile network, the access network would pass the device a Location-By-Reference URI, using either DHCP or HELD. Either protocol is suitable for cellular networks. As we have pointed out several times, cellular networks support raw data packet services upon which many different kinds of networks can be constructed. My usual example is a large recreational vehicle traveling down a road with a cellular data card plugged into a router to which a wired (Ethernet) phone is connected. That phone must be able to make an emergency call, and it will get location from DHCP or HELD (or LLDP-MED). It is not aware of the cellular network, and doesn't know any cellular specific protocols. Cellular networks will have to support IETF location configuration protocols unless they actively prohibit examples like this, or they implement interworking between cellular-specific location protocols and DHCP or HELD in the data card. The ecrit standards permit proxy insertion of location, but, as above, we don't think that works in all cases. > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) The "load" of using DHCP or HELD to get location and querying LoST is pretty modest. The standards permit proxies to do this if the devices don't. As above, interwork functions to CS connected PSAPs is very feasible, and as above, cellular networks will have to support access to local LoST servers for devices that are connected to cellular networks and are ecrit compliant. > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls This is covered in the standards. None of the processes are dependent on authentication, although where it is possible, it's desirable so as to minimize fraudulent emergency calls Mechanisms for specific network authentication mechanisms are out of scope, and, like SIP basic calling, are not usually mentioned in IETF documents. Stephen, we've tried pretty hard to make sure this works for 3G/4G mobile networks. It's true that it doesn't do it the way 3GPP currently thinks it ought to work, but we claim they haven't thought through all the issues. While it would work, there are opportunities for improvement. We would be willing to do that if we could get the cooperation of 3GPP, which we have tried, and failed, to do. So, I think the documents do not need any qualification statements. Brian > Martin > > The 3GPP/3GPP2 solution has a defined restricted applicability (mainly to > 3GPP/3GPP2 access networks where the serving network also acts as the VSP) > and the specifications for it cover in detail all possible scenarios > consistent with these restrictions so far as we are aware. > > The Ecrit solution seems to claim global applicability to all types of IP > access (and the more that is said about this from Ecrit participants the > more this gets emphasized) but does not cover in detail all possible > scenarios (in some cases does not cover in any detail) which means that at > best the solution is incomplete and at worst intrinsically inapplicable to > some unstated set of scenarios. > > The missing, incomplete and problematic cases include the following: > > - access to PSTN capable PSAPs > - handover between different IP access networks including different > types of access network > - handover to/from circuit mode networks > - location for cellular access (and the requirement to support LCPs that > will be useless for cellular access) > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls > > Stating that some of these cases are out of scope or referencing an > incomplete and possibly questionable specification from some other > national SDO will not help the user who encounters such problems. But it > would certainly help network operators and implementers to acknowledge > their existence in one form or another because that would allow better > planning of deployments and would help focus attention on finding > solutions (whether in IETF or elsewhere) for the missing cases. > > Please note that despite these drawbacks, I will acknowledge that Ecrit > does have a valuable solution that covers many scenarios not covered by > 3GPP/3GPP2. It would be the delineation of these supported scenarios (or > equivalently unsupported scenarios) in some applicability statement that > would be particularly useful right now. > > Kind Regards > > Stephen > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Thursday, February 26, 2009 9:45 PM > To: Edge, Stephen; Richard Barnes > Cc: ECRIT > Subject: RE: [Ecrit] Comments on Framework Draft > > There's benefit in knowing the limitations of a framework, and every > architecture makes certain assumptions. Let's examine them though... > > The IETF might occasionally make the assumption that the standards it > develops are for Internet devices. That assumption probably need not be > stated explicitly. > > The ECRIT architecture relies on implementations of the protocols that it > references. That is not extraordinary. A reliance on implementation of > these protocols by endpoints, routing intermediaries and PSAPs should not > need to be explained. > > So the assumptions are: > - the Internet > - solutions are implemented and deployed > - the end device is a key component > > Only that last element is particularly novel ... or not that much really. > It's a design choice. Unless you were thinking of trunking the voice > elsewhere. > > Of course, you're suggesting that the design choice was made in ignorance > of all the constraints. You're suggesting that - as a result - the choice > is flawed and the solution is not going to work for cellular services. We > disagree. The solution is a basis for emergency calling in _any_ IP > network. > > Cheers, > Martin > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Edge, Stephen >> Sent: Friday, 27 February 2009 3:30 PM >> To: Richard Barnes >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Richard >> >> Thanks for the comments. Your statement below that "SIP emergency >> calling works if all parties behave as specified in these (IETF Ecrit) >> documents" to some degree highlights the problems we are raising. The >> documents do contain a number of implicit and explicit restrictions - >> like IP capable PSAPs, global IP access (no islands of circuit mode >> access for example), universal support of this solution by all access >> providers and VSPs (not much good if some opt for another solution) and >> end system oriented location and routing capability - which together >> make them unsuitable (we believe) for cellular wireless networks. If >> these restrictions and assumptions were all made explicit upfront, it >> would to a large degree (and possibly completely) address our concerns. >> >> You are right in assuming another set of specifications for the 3GPP >> and 3GPP2 solution. The applicability of this solution is explicitly >> defined in TS 23.167 (or more exactly in an already agreed CR in >> contribution S2-090752 which will become part of 23.167 in a few more >> weeks) to cover the following access types: GPRS (UTRAN WCDMA), I-WLAN, >> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN >> (LTE). So there is a restriction and arbitrary internet access is not >> covered (yet) as I have stated before. >> >> Kind Regards >> >> Stephen >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Wednesday, February 25, 2009 6:30 PM >> To: Edge, Stephen >> Cc: Brian Rosen; 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Stephen, >> >> I'm a little confused by the scope of what you're asking. The >> framework >> and phonebcp documents exist in order to describe the ECRIT solution: >> They say, in effect, "SIP emergency calling works if all parties behave >> as specified in these documents." >> >> As I understand what you're saying (and I'm by no means an expert in >> 3GPP), 3GPP specifies that one or more elements of this system behave >> differently. This simply means that 3GPP networks aren't complying >> with >> these specs. Just like there's no disclaimer in RFC 791 (IPv4) that >> says "this doesn't work on X.25 networks", it's not clear to me that an >> analogous disclaimer is called for here. >> >> I presume there are similar documents describing how emergency calling >> works in 3GPP networks. Do they include notes saying that the 3GPP >> solution doesn't work in the broader Internet? >> >> --Richard >> >> >> >> >> >> Edge, Stephen wrote: >> > Brian >> > >> > First of all apologies for the likely lateness of this reply - I >> actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest but >> it seems unlikely that my VPN, Outlook server and WiFi access >> capability will cooperate together to get it sent until I return to the >> office mid-next week. >> > >> > Anyhow thanks for your comments. There have actually been a number of >> conference calls between IETF and 3GPP participants over the last >> couple of years at which common features like support of IP emergency >> calls were discussed and these could have been good forum for >> participants on either side to have raised the kinds of issues you >> elaborate on below. Given that seems not so far to have happened, it >> could still be possible in future such calls. >> > >> > But the issues we are raising are not directly to do with further >> aligning the 2 solutions or with the lack of this in the past. We are >> simply pointing out that the solutions are currently different and that >> from a cellular wireless perspective, the Ecrit solution is not seen as >> suitable in all respects (for support of IP emergency calls originating >> from such access types). That is not just our point of view. 3GPP2 sent >> a liaison to Ecrit some months ago pointing out the same issues. >> > >> > So we are proposing that the Ecrit framework and phoneBCP spec.s >> include a statement acknowledging this - e.g. by referencing the >> alternative 3GPP/3GPP2 solution and indicating the IP access types for >> which the Ecrit solution will work without limitation (or equivalently >> the access types where limitations are not ruled out). >> > >> > We are not proposing further modification and extension of the Ecrit >> solution - just pointing out that this would be needed (as with the >> 3GPP/3GPP2 solution) to fully cover all types of access. >> > >> > Kind Regards >> > >> > Stephen >> > -----Original Message----- >> > From: Brian Rosen [mailto:br@brianrosen.net] >> > Sent: Wednesday, February 18, 2009 8:07 PM >> > To: Edge, Stephen; 'ECRIT' >> > Subject: RE: [Ecrit] Comments on Framework Draft >> > >> > I have bit my tongue on this one for a long time. >> > >> > Stephen, with respect, please go talk to 3GPP management and ask them >> why >> > there has been no participation in the ecrit effort despite multiple >> YEARS >> > of begging them to get involved. To put it frankly, 3GPP is quite >> willing >> > to bully IETF into doing its work on its schedule, but cannot be >> bothered to >> > get work done it knows it will eventually have to do when the IETF >> asks it >> > to do so. >> > >> > 3GPP understands the mess that is being created by not participating. >> They >> > know full well that when they finally get around to dealing with PS >> > terminated emergency calls, that there will be a lot of resistance to >> > changing fully specified and implemented standards to more closely >> align >> > with 3GPP standards. I expect you will have several interworking >> functions >> > to define and build. >> > >> > So, politely, please go away, we're finishing work we dearly wanted >> you all >> > to be involved with for years, but you refused to do anything. It's >> too >> > late for this rev. >> > >> > Now, having said that, there are quite a few people who have >> participated in >> > the IETF work who are IMS aware and I believe that despite your >> fears, >> > everything you need is in the specs. The mechanisms we have defined >> provide >> > the ability for the network to insert location, recognize and mark >> emergency >> > calls, and route on behalf of endpoints. An E-CSCF could quite >> > straightforwardly provide a SIP call towards an ecrit compatible >> PSAP. The >> > only not-quite-nice interwork would be from SUPL to HELD (or SIP), >> but it's >> > pretty easy to do that. I'll also note that we have tried to get OMA >> and >> > IETF to cooperate on location protocols, but we have been >> spectacularly >> > unsuccessful at that effort also. >> > >> > Brian >> > >> > >> > >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf >> >> Of Edge, Stephen >> >> Sent: Thursday, February 05, 2009 2:50 AM >> >> To: 'ECRIT' >> >> Subject: [Ecrit] Comments on Framework Draft >> >> >> >> All >> >> >> >> draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative >> >> description of how terminals and networks should support emergency >> >> calls made over IP capable facilities to IP capable PSAPs. It >> appears >> >> intended to cover all types of access network - including fixed >> line, >> >> WiFi and cellular (e.g. examples involving each can be found >> throughout >> >> the draft). >> >> >> >> When we evaluated this with respect to support of wireless cellular >> >> access and WiFi access associated with a cellular operator (e.g. >> WLAN >> >> or Femto cells integrated into a cellular network), we found that >> >> certain portions of the draft exhibited one or more of the following >> >> characteristics: >> >> >> >> (A) Inconsistent with already standardized wireless solutions >> >> >> >> (B) Inconsistent with essential wireless requirements and >> >> conventions >> >> >> >> (C) Already part of wireless standards or potentially part of >> >> future standards >> >> >> >> (A) refers to all portions of the draft framework that differ from >> the >> >> requirements and procedures currently standardized for wireless >> >> emergency access by 3GPP, 3GPP2 and OMA. This is a plain difference >> of >> >> solution and could be resolved through support of both solutions by >> >> terminals (with each solution being used according to the type of >> >> access network and VSP) or could be resolved by supporting only one >> >> solution and accessing only the types of network supporting that >> >> solution. To acknowledge this category, the framework document could >> >> reference the applicable wireless standards and point out that these >> >> are valid alternatives for wireless cellular based access. >> >> >> >> (B) refers to portions of the draft that would be unsuitable for >> >> wireless networks even if no alternative solution existed together >> with >> >> other portions missing from the draft that would be needed to fully >> >> support wireless networks. Examples of the former include: (a) >> emphasis >> >> on endpoint derivation of location, performance of Lost query and >> >> receipt of local dial strings; (b) restriction of LCPs to protocols >> >> that require terminal initiation (not allowing for network >> initiation >> >> as far as we can tell) and that include two LCPs (DHCP and LLDP) >> that >> >> are not applicable to (not defined for) cellular access; and (c) the >> >> requirement that a terminal or at least a LIS will update the PSAP >> >> whenever location changes. (a) is impractical due to network and >> >> terminal loading consequences and failure to support non-IP capable >> >> PSAPs; (b) makes location verification and updated location >> provision >> >> to PSAPs difficult or impossible; while (c) is also incompatible >> with >> >> support of existing non-IP capable PSAPs besides increasing terminal >> >> load and possibly interfering with optimum maintenance of the RF >> >> connection (e.g. if a terminal has to tune away from the serving >> base >> >> station or WLAN periodically to make location measurements). >> Examples >> >> of the latter include (d) absence of support for access to non-IP >> >> capable PSAPs as already mentioned (e.g. to support E911 phase 2 in >> the >> >> US); (e) no support for handover from the IP to the circuit domain >> when >> >> a terminal loses (e.g. moves out of) RF coverage in the IP domain; >> and >> >> (f) no allowance for limited access modes wherein a terminal may >> access >> >> a network only to place an emergency call with ensuing restrictions >> on >> >> (for example) location acquisition, PSAP callback and caller >> >> verification and identification to the PSAP. To resolve this >> category >> >> either significant changes to the framework document could be made >> or a >> >> disclaimer/applicability statement could be added stating that >> support >> >> of cellular wireless networks and their associated WLAN and Femto >> >> access points is not covered. >> >> >> >> Category (C) comprises concepts and capabilities in the draft that >> are >> >> either already part of the standardized solution for wireless >> networks >> >> or that might be added at a later time. Examples of the former >> include >> >> LoST, SIP location conveyance, general use of SIP, location for >> routing >> >> versus for dispatch, cellular positioning methods. Examples of the >> >> latter include use of location references and dereferencing and >> >> possible interworking between the current wireless network solutions >> >> (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. >> The >> >> presence of this category could be acknowledged by following the >> >> disclaimer for (B) with a statement that certain portions of the >> >> solution are expected to be incorporated into wireless networks now >> >> and/or in the future. >> >> >> >> We hope that these comments will be seen to be a useful addition to >> >> this review in the sense of enabling a more precise scoping for the >> >> framework document and we are willing to assist in providing wording >> >> for any disclaimer/applicability statement that the Ecrit working >> group >> >> may now deem fit to include. >> >> >> >> Kind Regards >> >> >> >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs >> (Qualcomm >> >> 3GPP2 TSG-X and TSG-C participant) >> >> >> >> PS this being sent on 2/4/09 at 11:50pm PST >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www.ietf.org/mailman/listinfo/ecrit >> > >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------ ------------------------ > 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://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to wh= ich it is addressed and may contain confidential, proprietary, and/or privi= leged material. Any review, retransmission, dissemination or other use of, = or taking of any action in reliance upon this information by persons or ent= ities other than the intended recipient is prohibited. If you received this= in error, please contact the sender and delete the material from all compu= ters. GA621 From James.Winterbottom@andrew.com Wed Mar 4 19:01:07 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D167928C44F for ; Wed, 4 Mar 2009 19:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRSxwowMyHaA for ; Wed, 4 Mar 2009 19:01:05 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 0D55628C42E for ; Wed, 4 Mar 2009 19:01:04 -0800 (PST) X-SEF-Processed: 5_0_0_910__2009_03_04_21_21_15 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 04 Mar 2009 21:21:15 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 21:01:32 -0600 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, 4 Mar 2009 21:01:30 -0600 Message-ID: In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5374A196@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmY6xMaVsPKQOa6Rj2puYM6nfd6RAACFkpAARDTCVAAAJ6vQA== References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com><64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net><7582BC68E4994F4ABF0BD4723975C3FA0D39534E@crexc41p> <1288E74A73964940B132A0B9EA8D8ABC5374A196@NASANEXMB04.na.qualcomm.com> From: "Winterbottom, James" To: "Edge, Stephen" , "Stark, Barbara" , X-OriginalArrivalTime: 05 Mar 2009 03:01:32.0628 (UTC) FILETIME=[B030A140:01C99D3E] Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 03:01:07 -0000 Hi Stephen,=0D=0A=0D=0ASUPL has one very huge disadvantage, it mandates the= use of a home SLP.=0D=0ASUPL roaming between carriers is basically unimple= mentable. The=0D=0Amechanisms required to support an H-SLP determining the = V-SLP address=0D=0Aare deliberately left out of scope by OMA, and large num= bers of=0D=0Acompanies are busily putting IPR on the ways in which this can= occur.=0D=0AThere are no large-scale deployments of RLP that I am aware of= , and this=0D=0Ais a clear indicator of how bad the currently proposed arch= itecture is.=0D=0A=0D=0AAll this means that for SUPL to be deployable on a = large scale any H-SLP=0D=0Asimply has to have the entire world in a databas= e. This is abundantly=0D=0Aevident when you look at systems like the global= Nokia solution. I think=0D=0Athat this is mammoth task to maintain for gen= eral cell coverage, on a=0D=0Aglobal basis when you include W-LAN and femto= -cells it is quite simply=0D=0Aridiculous.=0D=0A=0D=0AThe result is that SU= PL is next to useless as a solution for anything=0D=0Aother than providing = basic-cell location or assistance data for GPS. It=0D=0Ais not local in the= same sense that an LCP is. All of the other=0D=0Adetermination mechanisms = that you described in your previous email=0D=0Asimply don't work in SUPL to= any reasonable degree, and I would argue=0D=0Adon't work at all once the d= evice in a foreign network.=0D=0A=0D=0ACheers=0D=0AJames=20=0D=0A=0D=0A=0D=0A=0D= =0A-----Original Message-----=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecr= it-bounces@ietf.org] On Behalf=0D=0AOf Edge, Stephen=0D=0ASent: Thursday, 5= March 2009 1:20 PM=0D=0ATo: Stark, Barbara; br@brianrosen.net=0D=0ACc: ECR= IT=0D=0ASubject: Re: [Ecrit] Comments on Framework Draft=0D=0A=0D=0ABarbara= and others=0D=0A=0D=0AThanks for the comments.=0D=0A=0D=0AWhen I look at t= he PhoneBCP I see that both HELD and DHCP are mandatory=0D=0Afor the device= whereas at least one of these is mandatory for the AN.=0D=0AWhile I can al= so see that SUPL is not ruled out (though it is not=0D=0Amentioned or refer= enced), it appears to have been displaced by the HELD=0D=0Aand DHCP require= ments. On the other hand, many cellular networks have=0D=0Aalready deployed= or are in the process of deploying SUPL and I am not=0D=0Aaware of any tha= t have deployed an accurate location capability using=0D=0AHELD or DHCP. So= I would like to know how you see the current=0D=0Arequirements as being su= itable - after all, they imply at the very least=0D=0Aadditional developmen= t and deployment on the part of network and device=0D=0Avendors and network= operators, whereas if SUPL was one of the defined=0D=0ALCPs, that addition= al development and deployment might be mostly=0D=0Aavoided. This question w= ould not be applicable with some additional=0D=0Ascope limitation and so I = had not previously raised it. But it is=0D=0Acertainly applicable in=20=0D=0A= the context of the global scope that is being claimed by some=0D=0Arespond= ers.=0D=0A=0D=0AKind Regards=0D=0A=0D=0AStephen=0D=0A-----Original Message-= ----=0D=0AFrom: Stark, Barbara [mailto:bs7652@att.com]=0D=0ASent: Friday, F= ebruary 27, 2009 8:28 AM=0D=0ATo: br@brianrosen.net; Edge, Stephen=0D=0ACc:= ECRIT=0D=0ASubject: RE: [Ecrit] Comments on Framework Draft=0D=0A=0D=0ATha= nk you Brian. This is well said [except you left out the fact that=0D=0Aecr= it also allows for devices to get their location through other=0D=0Amechani= sms, such as GPS, SUPL, or other methods, and doesn't insist that=0D=0Athe = location be configured through DHCP or HELD].=0D=0A=0D=0AI agree 100% that = additional qualifications are unnecessary. Service=0D=0Aproviders, vendors,= national bodies dealing with emergency services, and=0D=0Aregulators aren'= t stupid. Please trust us to figure out for ourselves=0D=0Awhen/where/how t= o apply a "standard". There is no need to try to=0D=0Aartificially limit or= define scope, or to state the obvious (e.g., the=0D=0Aarchitecture applies= where it applies, and doesn't apply where it=0D=0Adoesn't apply). We under= stand the role and scope of the IETF, and the=0D=0Arole and scope of 3GPP a= nd 3GPP2. And all the other SDOs (and national=0D=0Abodies and regulatory a= gencies). SDOs need to offer architectures that=0D=0Aapply within the area = of applicability for that SDO, and are useful to=0D=0Apotential implementer= s, and leave it to the SPs, national bodies and=0D=0Aregulators to decide w= hich architectures and standards to use or to=0D=0Amandate within the scope= of their network or jurisdiction. Again, we=0D=0Aaren't stupid.=0D=0ABarba= ra=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: ecrit-bounces@ietf.org = [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0AOf br@brianrosen.net=0D=0ASe= nt: Friday, February 27, 2009 9:53 AM=0D=0ATo: Edge, Stephen=0D=0ACc: ECRIT=0D= =0ASubject: Re: [Ecrit] Comments on Framework Draft=0D=0A=0D=0AStephen=0D=0A=0D= =0ALike any standards organization, the IETF restricts it's scope.=0D=0AGen= erally, the scope is "the Internet", although we very often describe=0D=0As= olutions that are explicitly designed for private IP networks as well=0D=0A= as=0D=0Athe Internet. We don't write standards for circuit switched networ= ks,=0D=0Aand=0D=0Ait should be no surprise that the ecrit solution does not= cater to CS=0D=0Asolutions. Nevertheless, we often try to make sure that = our solutions=0D=0Aharmonize reasonably well with existing solutions.=0D=0A=0D= =0AIndeed, the ecrit solution clains global applicability to the Internet=0D= =0Ain=0D=0Ageneral, and most private IP networks that can be interconnected= to the=0D=0AInternet or to other IP networks via gateways. Looking at you= r list of=0D=0Aproblem areas:=0D=0A> - access to PSTN capable PSAPs=0D=0A= This is out of scope for IETF. NENA has active work on this subject.=0D=0A= It=0D=0Aseems straightforward to interwork ecrit compatible devices and net= works=0D=0Ato existing CS connected PSAPs. As you know, CS interconnects a= re very=0D=0Anation-specific, so the NENA work may not have general applica= bility.=0D=0AHowever, it shows that it is possible to interwork. The NENA = i2 work is=0D=0Aalso designed to take ecrit compatible devices and VSP netw= orks, and=0D=0Ainterwork them to the existing network. The VSP would direc= t the call=0D=0Ato=0D=0Athe VPC, which would provide the services it does n= ow, using the device=0D=0Aprovided location for routing. This is important= for smooth transition=0D=0Afrom existing PSAPs and VSPs to "next generatio= n" PSAPs and VSPs.=0D=0A> - handover between different IP access networks= including different=0D=0A> types of access network=0D=0AIn the ecrit solut= ion, the access network the call is initiated on=0D=0Aprovides all the faci= lities needed for the device to initiate an=0D=0Aemergency=0D=0Acall. The= call starts traversing it's normal call path, and eventually=0D=0Aroutes t= o the ESRP. Handoffs between IP networks should be transparent=0D=0Ato=0D=0A= this process, although we probably haven't done all the work we need to=0D=0A= do=0D=0Afor handoffs where the IP address as seen by the terminating networ= k=0D=0Achanges. This would generally be true of all current SIP based work= =2E=0D=0A> - handover to/from circuit mode networks=0D=0AThis would be ou= t of scope for IETF. It's as applicable to a simple SIP=0D=0Acall as it is= a SIP emergency call, and there are no statements in any=0D=0ASIP=0D=0Adoc= uments on that subject.=0D=0A> - location for cellular access (and the re= quirement to support LCPs=0D=0Athat=0D=0A> will be useless for cellular acc= ess)=0D=0ALocation for cellular access networks has been considered careful= ly.=0D=0ASince cellular is a mobile network, the access network would pass = the=0D=0Adevice a Location-By-Reference URI, using either DHCP or HELD. Ei= ther=0D=0Aprotocol is suitable for cellular networks. As we have pointed o= ut=0D=0Aseveral times, cellular networks support raw data packet services u= pon=0D=0Awhich many different kinds of networks can be constructed. My usu= al=0D=0Aexample is a large recreational vehicle traveling down a road with = a=0D=0Acellular data card plugged into a router to which a wired (Ethernet)=0D= =0Aphone=0D=0Ais connected. That phone must be able to make an emergency c= all, and it=0D=0Awill get location from DHCP or HELD (or LLDP-MED). It is = not aware of=0D=0Athe=0D=0Acellular network, and doesn't know any cellular = specific protocols.=0D=0ACellular networks will have to support IETF locati= on configuration=0D=0Aprotocols unless they actively prohibit examples like= this, or they=0D=0Aimplement interworking between cellular-specific locati= on protocols and=0D=0ADHCP or HELD in the data card. The ecrit standards p= ermit proxy=0D=0Ainsertion=0D=0Aof location, but, as above, we don't think = that works in all cases.=0D=0A> - endpoint based location and routing for= cellular access (issues=0D=0Ahere=0D=0A> are network and device loading as= well as device impacts and problems=0D=0A> with PSTN capable PSAPs)=0D=0AT= he "load" of using DHCP or HELD to get location and querying LoST is=0D=0Ap= retty modest. The standards permit proxies to do this if the devices=0D=0A= don't. As above, interwork functions to CS connected PSAPs is very=0D=0Afe= asible, and as above, cellular networks will have to support access to=0D=0A= local LoST servers for devices that are connected to cellular networks=0D=0A= and=0D=0Aare ecrit compliant.=0D=0A> - support of unauthenticated users a= nd users who can be=0D=0Aauthenticated=0D=0A> but are not permitted access/= VSP service except for emergency calls=0D=0AThis is covered in the standard= s. None of the processes are dependent=0D=0Aon=0D=0Aauthentication, althou= gh where it is possible, it's desirable so as to=0D=0Aminimize fraudulent e= mergency calls=0D=0AMechanisms for specific network authentication mechanis= ms are out of=0D=0Ascope, and, like SIP basic calling, are not usually ment= ioned in IETF=0D=0Adocuments.=0D=0A=0D=0AStephen, we've tried pretty hard t= o make sure this works for 3G/4G=0D=0Amobile=0D=0Anetworks. It's true that= it doesn't do it the way 3GPP currently thinks=0D=0Ait ought to work, but = we claim they haven't thought through all the=0D=0Aissues. While it would = work, there are opportunities for improvement.=0D=0AWe=0D=0Awould be willin= g to do that if we could get the cooperation of 3GPP,=0D=0Awhich=0D=0Awe ha= ve tried, and failed, to do.=0D=0A=0D=0ASo, I think the documents do not ne= ed any qualification statements.=0D=0A=0D=0ABrian=0D=0A=0D=0A> Martin=0D=0A= >=0D=0A> The 3GPP/3GPP2 solution has a defined restricted applicability (ma= inly=0D=0Ato=0D=0A> 3GPP/3GPP2 access networks where the serving network al= so acts as the=0D=0AVSP)=0D=0A> and the specifications for it cover in deta= il all possible scenarios=0D=0A> consistent with these restrictions so far = as we are aware.=0D=0A>=0D=0A> The Ecrit solution seems to claim global app= licability to all types of=0D=0AIP=0D=0A> access (and the more that is said= about this from Ecrit participants=0D=0Athe=0D=0A> more this gets emphasiz= ed) but does not cover in detail all possible=0D=0A> scenarios (in some cas= es does not cover in any detail) which means=0D=0Athat at=0D=0A> best the s= olution is incomplete and at worst intrinsically=0D=0Ainapplicable to=0D=0A= > some unstated set of scenarios.=0D=0A>=0D=0A> The missing, incomplete and= problematic cases include the following:=0D=0A>=0D=0A> - access to PSTN = capable PSAPs=0D=0A> - handover between different IP access networks incl= uding different=0D=0A> types of access network=0D=0A> - handover to/from = circuit mode networks=0D=0A> - location for cellular access (and the requ= irement to support LCPs=0D=0Athat=0D=0A> will be useless for cellular acces= s)=0D=0A> - endpoint based location and routing for cellular access (issu= es=0D=0Ahere=0D=0A> are network and device loading as well as device impact= s and problems=0D=0A> with PSTN capable PSAPs)=0D=0A> - support of unauth= enticated users and users who can be=0D=0Aauthenticated=0D=0A> but are not = permitted access/VSP service except for emergency calls=0D=0A>=0D=0A> Stati= ng that some of these cases are out of scope or referencing an=0D=0A> incom= plete and possibly questionable specification from some other=0D=0A> nation= al SDO will not help the user who encounters such problems. But=0D=0Ait=0D=0A= > would certainly help network operators and implementers to acknowledge=0D= =0A> their existence in one form or another because that would allow better=0D= =0A> planning of deployments and would help focus attention on finding=0D=0A= > solutions (whether in IETF or elsewhere) for the missing cases.=0D=0A>=0D= =0A> Please note that despite these drawbacks, I will acknowledge that=0D=0A= Ecrit=0D=0A> does have a valuable solution that covers many scenarios not c= overed=0D=0Aby=0D=0A> 3GPP/3GPP2. It would be the delineation of these supp= orted scenarios=0D=0A(or=0D=0A> equivalently unsupported scenarios) in some= applicability statement=0D=0Athat=0D=0A> would be particularly useful righ= t now.=0D=0A>=0D=0A> Kind Regards=0D=0A>=0D=0A> Stephen=0D=0A> -----Origina= l Message-----=0D=0A> From: Thomson, Martin [mailto:Martin.Thomson@andrew.c= om]=0D=0A> Sent: Thursday, February 26, 2009 9:45 PM=0D=0A> To: Edge, Steph= en; Richard Barnes=0D=0A> Cc: ECRIT=0D=0A> Subject: RE: [Ecrit] Comments on= Framework Draft=0D=0A>=0D=0A> There's benefit in knowing the limitations o= f a framework, and every=0D=0A> architecture makes certain assumptions. Le= t's examine them though...=0D=0A>=0D=0A> The IETF might occasionally make t= he assumption that the standards it=0D=0A> develops are for Internet device= s. That assumption probably need not=0D=0Abe=0D=0A> stated explicitly.=0D=0A= >=0D=0A> The ECRIT architecture relies on implementations of the protocols = that=0D=0Ait=0D=0A> references. That is not extraordinary. A reliance on = implementation=0D=0Aof=0D=0A> these protocols by endpoints, routing interme= diaries and PSAPs should=0D=0Anot=0D=0A> need to be explained.=0D=0A>=0D=0A= > So the assumptions are:=0D=0A> - the Internet=0D=0A> - solutions are im= plemented and deployed=0D=0A> - the end device is a key component=0D=0A>=0D= =0A> Only that last element is particularly novel ... or not that much=0D=0A= really.=0D=0A> It's a design choice. Unless you were thinking of trunkin= g the=0D=0Avoice=0D=0A> elsewhere.=0D=0A>=0D=0A> Of course, you're suggesti= ng that the design choice was made in=0D=0Aignorance=0D=0A> of all the cons= traints. You're suggesting that - as a result - the=0D=0Achoice=0D=0A> is = flawed and the solution is not going to work for cellular services.=0D=0AWe=0D= =0A> disagree. The solution is a basis for emergency calling in _any_ IP=0D= =0A> network.=0D=0A>=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=0D=0A>=0D=0A>> ---= --Original Message-----=0D=0A>> From: ecrit-bounces@ietf.org [mailto:ecrit-= bounces@ietf.org] On=0D=0ABehalf=0D=0A>> Of Edge, Stephen=0D=0A>> Sent: Fri= day, 27 February 2009 3:30 PM=0D=0A>> To: Richard Barnes=0D=0A>> Cc: 'ECRIT= '=0D=0A>> Subject: Re: [Ecrit] Comments on Framework Draft=0D=0A>>=0D=0A>> = Hi Richard=0D=0A>>=0D=0A>> Thanks for the comments. Your statement below th= at "SIP emergency=0D=0A>> calling works if all parties behave as specified = in these (IETF=0D=0AEcrit)=0D=0A>> documents" to some degree highlights the= problems we are raising. The=0D=0A>> documents do contain a number of impl= icit and explicit restrictions -=0D=0A>> like IP capable PSAPs, global IP a= ccess (no islands of circuit mode=0D=0A>> access for example), universal su= pport of this solution by all access=0D=0A>> providers and VSPs (not much g= ood if some opt for another solution)=0D=0Aand=0D=0A>> end system oriented = location and routing capability - which together=0D=0A>> make them unsuitab= le (we believe) for cellular wireless networks. If=0D=0A>> these restrictio= ns and assumptions were all made explicit upfront, it=0D=0A>> would to a la= rge degree (and possibly completely) address our=0D=0Aconcerns.=0D=0A>>=0D=0A= >> You are right in assuming another set of specifications for the 3GPP=0D=0A= >> and 3GPP2 solution. The applicability of this solution is explicitly=0D=0A= >> defined in TS 23.167 (or more exactly in an already agreed CR in=0D=0A>>= contribution S2-090752 which will become part of 23.167 in a few more=0D=0A= >> weeks) to cover the following access types: GPRS (UTRAN WCDMA),=0D=0AI-W= LAN,=0D=0A>> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UT= RAN=0D=0A>> (LTE). So there is a restriction and arbitrary internet access = is not=0D=0A>> covered (yet) as I have stated before.=0D=0A>>=0D=0A>> Kind = Regards=0D=0A>>=0D=0A>> Stephen=0D=0A>> -----Original Message-----=0D=0A>> = From: Richard Barnes [mailto:rbarnes@bbn.com]=0D=0A>> Sent: Wednesday, Febr= uary 25, 2009 6:30 PM=0D=0A>> To: Edge, Stephen=0D=0A>> Cc: Brian Rosen; 'E= CRIT'=0D=0A>> Subject: Re: [Ecrit] Comments on Framework Draft=0D=0A>>=0D=0A= >> Hi Stephen,=0D=0A>>=0D=0A>> I'm a little confused by the scope of what y= ou're asking. The=0D=0A>> framework=0D=0A>> and phonebcp documents exist i= n order to describe the ECRIT solution:=0D=0A>> They say, in effect, "SIP e= mergency calling works if all parties=0D=0Abehave=0D=0A>> as specified in t= hese documents."=0D=0A>>=0D=0A>> As I understand what you're saying (and I'= m by no means an expert in=0D=0A>> 3GPP), 3GPP specifies that one or more e= lements of this system behave=0D=0A>> differently. This simply means that = 3GPP networks aren't complying=0D=0A>> with=0D=0A>> these specs. Just like= there's no disclaimer in RFC 791 (IPv4) that=0D=0A>> says "this doesn't wo= rk on X.25 networks", it's not clear to me that=0D=0Aan=0D=0A>> analogous d= isclaimer is called for here.=0D=0A>>=0D=0A>> I presume there are similar d= ocuments describing how emergency=0D=0Acalling=0D=0A>> works in 3GPP networ= ks. Do they include notes saying that the 3GPP=0D=0A>> solution doesn't wo= rk in the broader Internet=3F=0D=0A>>=0D=0A>> --Richard=0D=0A>>=0D=0A>>=0D=0A= >>=0D=0A>>=0D=0A>>=0D=0A>> Edge, Stephen wrote:=0D=0A>> > Brian=0D=0A>> >=0D= =0A>> > First of all apologies for the likely lateness of this reply - I=0D= =0A>> actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest=0D= =0Abut=0D=0A>> it seems unlikely that my VPN, Outlook server and WiFi acces= s=0D=0A>> capability will cooperate together to get it sent until I return = to=0D=0Athe=0D=0A>> office mid-next week.=0D=0A>> >=0D=0A>> > Anyhow thanks= for your comments. There have actually been a number=0D=0Aof=0D=0A>> confe= rence calls between IETF and 3GPP participants over the last=0D=0A>> couple= of years at which common features like support of IP emergency=0D=0A>> cal= ls were discussed and these could have been good forum for=0D=0A>> particip= ants on either side to have raised the kinds of issues you=0D=0A>> elaborat= e on below. Given that seems not so far to have happened, it=0D=0A>> could = still be possible in future such calls.=0D=0A>> >=0D=0A>> > But the issues = we are raising are not directly to do with further=0D=0A>> aligning the 2 s= olutions or with the lack of this in the past. We are=0D=0A>> simply pointi= ng out that the solutions are currently different and=0D=0Athat=0D=0A>> fro= m a cellular wireless perspective, the Ecrit solution is not seen=0D=0Aas=0D= =0A>> suitable in all respects (for support of IP emergency calls=0D=0Aorig= inating=0D=0A>> from such access types). That is not just our point of view= =2E 3GPP2=0D=0Asent=0D=0A>> a liaison to Ecrit some months ago pointing out= the same issues.=0D=0A>> >=0D=0A>> > So we are proposing that the Ecrit fr= amework and phoneBCP spec.s=0D=0A>> include a statement acknowledging this = - e.g. by referencing the=0D=0A>> alternative 3GPP/3GPP2 solution and indic= ating the IP access types=0D=0Afor=0D=0A>> which the Ecrit solution will wo= rk without limitation (or=0D=0Aequivalently=0D=0A>> the access types where = limitations are not ruled out).=0D=0A>> >=0D=0A>> > We are not proposing fu= rther modification and extension of the=0D=0AEcrit=0D=0A>> solution - just = pointing out that this would be needed (as with the=0D=0A>> 3GPP/3GPP2 solu= tion) to fully cover all types of access.=0D=0A>> >=0D=0A>> > Kind Regards=0D= =0A>> >=0D=0A>> > Stephen=0D=0A>> > -----Original Message-----=0D=0A>> > Fr= om: Brian Rosen [mailto:br@brianrosen.net]=0D=0A>> > Sent: Wednesday, Febru= ary 18, 2009 8:07 PM=0D=0A>> > To: Edge, Stephen; 'ECRIT'=0D=0A>> > Subject= : RE: [Ecrit] Comments on Framework Draft=0D=0A>> >=0D=0A>> > I have bit my= tongue on this one for a long time.=0D=0A>> >=0D=0A>> > Stephen, with resp= ect, please go talk to 3GPP management and ask=0D=0Athem=0D=0A>> why=0D=0A>= > > there has been no participation in the ecrit effort despite=0D=0Amultip= le=0D=0A>> YEARS=0D=0A>> > of begging them to get involved. To put it fran= kly, 3GPP is quite=0D=0A>> willing=0D=0A>> > to bully IETF into doing its w= ork on its schedule, but cannot be=0D=0A>> bothered to=0D=0A>> > get work d= one it knows it will eventually have to do when the IETF=0D=0A>> asks it=0D= =0A>> > to do so.=0D=0A>> >=0D=0A>> > 3GPP understands the mess that is bei= ng created by not=0D=0Aparticipating.=0D=0A>> They=0D=0A>> > know full well= that when they finally get around to dealing with PS=0D=0A>> > terminated = emergency calls, that there will be a lot of resistance=0D=0Ato=0D=0A>> > c= hanging fully specified and implemented standards to more closely=0D=0A>> a= lign=0D=0A>> > with 3GPP standards. I expect you will have several interwo= rking=0D=0A>> functions=0D=0A>> > to define and build.=0D=0A>> >=0D=0A>> > = So, politely, please go away, we're finishing work we dearly wanted=0D=0A>>= you all=0D=0A>> > to be involved with for years, but you refused to do any= thing.=0D=0AIt's=0D=0A>> too=0D=0A>> > late for this rev.=0D=0A>> >=0D=0A>>= > Now, having said that, there are quite a few people who have=0D=0A>> par= ticipated in=0D=0A>> > the IETF work who are IMS aware and I believe that d= espite your=0D=0A>> fears,=0D=0A>> > everything you need is in the specs. = The mechanisms we have=0D=0Adefined=0D=0A>> provide=0D=0A>> > the ability f= or the network to insert location, recognize and mark=0D=0A>> emergency=0D=0A= >> > calls, and route on behalf of endpoints. An E-CSCF could quite=0D=0A>= > > straightforwardly provide a SIP call towards an ecrit compatible=0D=0A>= > PSAP. The=0D=0A>> > only not-quite-nice interwork would be from SUPL to = HELD (or SIP),=0D=0A>> but it's=0D=0A>> > pretty easy to do that. I'll als= o note that we have tried to get=0D=0AOMA=0D=0A>> and=0D=0A>> > IETF to coo= perate on location protocols, but we have been=0D=0A>> spectacularly=0D=0A>= > > unsuccessful at that effort also.=0D=0A>> >=0D=0A>> > Brian=0D=0A>> >=0D= =0A>> >=0D=0A>> >=0D=0A>> >> -----Original Message-----=0D=0A>> >> From: ec= rit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=0D=0A>> Behalf=0D=0A= >> >> Of Edge, Stephen=0D=0A>> >> Sent: Thursday, February 05, 2009 2:50 AM=0D= =0A>> >> To: 'ECRIT'=0D=0A>> >> Subject: [Ecrit] Comments on Framework Draf= t=0D=0A>> >>=0D=0A>> >> All=0D=0A>> >>=0D=0A>> >> draft-ietf-ecrit-framewor= k-07 is (as we see it) a mostly=0D=0Ainformative=0D=0A>> >> description of = how terminals and networks should support emergency=0D=0A>> >> calls made o= ver IP capable facilities to IP capable PSAPs. It=0D=0A>> appears=0D=0A>> >= > intended to cover all types of access network - including fixed=0D=0A>> l= ine,=0D=0A>> >> WiFi and cellular (e.g. examples involving each can be foun= d=0D=0A>> throughout=0D=0A>> >> the draft).=0D=0A>> >>=0D=0A>> >> When we e= valuated this with respect to support of wireless=0D=0Acellular=0D=0A>> >> = access and WiFi access associated with a cellular operator (e.g.=0D=0A>> WL= AN=0D=0A>> >> or Femto cells integrated into a cellular network), we found = that=0D=0A>> >> certain portions of the draft exhibited one or more of the=0D= =0Afollowing=0D=0A>> >> characteristics:=0D=0A>> >>=0D=0A>> >> (A) Inco= nsistent with already standardized wireless solutions=0D=0A>> >>=0D=0A>> >>= (B) Inconsistent with essential wireless requirements and=0D=0A>> >> c= onventions=0D=0A>> >>=0D=0A>> >> (C) Already part of wireless standards= or potentially part of=0D=0A>> >> future standards=0D=0A>> >>=0D=0A>> >> (= A) refers to all portions of the draft framework that differ from=0D=0A>> t= he=0D=0A>> >> requirements and procedures currently standardized for wirele= ss=0D=0A>> >> emergency access by 3GPP, 3GPP2 and OMA. This is a plain=0D=0A= difference=0D=0A>> of=0D=0A>> >> solution and could be resolved through sup= port of both solutions=0D=0Aby=0D=0A>> >> terminals (with each solution bei= ng used according to the type of=0D=0A>> >> access network and VSP) or coul= d be resolved by supporting only=0D=0Aone=0D=0A>> >> solution and accessing= only the types of network supporting that=0D=0A>> >> solution. To acknowle= dge this category, the framework document=0D=0Acould=0D=0A>> >> reference t= he applicable wireless standards and point out that=0D=0Athese=0D=0A>> >> a= re valid alternatives for wireless cellular based access.=0D=0A>> >>=0D=0A>= > >> (B) refers to portions of the draft that would be unsuitable for=0D=0A= >> >> wireless networks even if no alternative solution existed together=0D= =0A>> with=0D=0A>> >> other portions missing from the draft that would be n= eeded to=0D=0Afully=0D=0A>> >> support wireless networks. Examples of the f= ormer include: (a)=0D=0A>> emphasis=0D=0A>> >> on endpoint derivation of lo= cation, performance of Lost query and=0D=0A>> >> receipt of local dial stri= ngs; (b) restriction of LCPs to=0D=0Aprotocols=0D=0A>> >> that require term= inal initiation (not allowing for network=0D=0A>> initiation=0D=0A>> >> as = far as we can tell) and that include two LCPs (DHCP and LLDP)=0D=0A>> that=0D= =0A>> >> are not applicable to (not defined for) cellular access; and (c)=0D= =0Athe=0D=0A>> >> requirement that a terminal or at least a LIS will update= the PSAP=0D=0A>> >> whenever location changes. (a) is impractical due to n= etwork and=0D=0A>> >> terminal loading consequences and failure to support = non-IP=0D=0Acapable=0D=0A>> >> PSAPs; (b) makes location verification and u= pdated location=0D=0A>> provision=0D=0A>> >> to PSAPs difficult or impossib= le; while (c) is also incompatible=0D=0A>> with=0D=0A>> >> support of exist= ing non-IP capable PSAPs besides increasing=0D=0Aterminal=0D=0A>> >> load a= nd possibly interfering with optimum maintenance of the RF=0D=0A>> >> conne= ction (e.g. if a terminal has to tune away from the serving=0D=0A>> base=0D= =0A>> >> station or WLAN periodically to make location measurements).=0D=0A= >> Examples=0D=0A>> >> of the latter include (d) absence of support for acc= ess to non-IP=0D=0A>> >> capable PSAPs as already mentioned (e.g. to suppor= t E911 phase 2=0D=0Ain=0D=0A>> the=0D=0A>> >> US); (e) no support for hando= ver from the IP to the circuit domain=0D=0A>> when=0D=0A>> >> a terminal lo= ses (e.g. moves out of) RF coverage in the IP domain;=0D=0A>> and=0D=0A>> >= > (f) no allowance for limited access modes wherein a terminal may=0D=0A>> = access=0D=0A>> >> a network only to place an emergency call with ensuing=0D= =0Arestrictions=0D=0A>> on=0D=0A>> >> (for example) location acquisition, P= SAP callback and caller=0D=0A>> >> verification and identification to the P= SAP. To resolve this=0D=0A>> category=0D=0A>> >> either significant changes= to the framework document could be made=0D=0A>> or a=0D=0A>> >> disclaimer= /applicability statement could be added stating that=0D=0A>> support=0D=0A>= > >> of cellular wireless networks and their associated WLAN and Femto=0D=0A= >> >> access points is not covered.=0D=0A>> >>=0D=0A>> >> Category (C) comp= rises concepts and capabilities in the draft that=0D=0A>> are=0D=0A>> >> ei= ther already part of the standardized solution for wireless=0D=0A>> network= s=0D=0A>> >> or that might be added at a later time. Examples of the former=0D= =0A>> include=0D=0A>> >> LoST, SIP location conveyance, general use of SIP,= location for=0D=0A>> routing=0D=0A>> >> versus for dispatch, cellular posi= tioning methods. Examples of the=0D=0A>> >> latter include use of location = references and dereferencing and=0D=0A>> >> possible interworking between t= he current wireless network=0D=0Asolutions=0D=0A>> >> (in 3GPP, 3GPP2 and O= MA) and the solution described in this draft.=0D=0A>> The=0D=0A>> >> presen= ce of this category could be acknowledged by following the=0D=0A>> >> discl= aimer for (B) with a statement that certain portions of the=0D=0A>> >> solu= tion are expected to be incorporated into wireless networks=0D=0Anow=0D=0A>= > >> and/or in the future.=0D=0A>> >>=0D=0A>> >> We hope that these comment= s will be seen to be a useful addition=0D=0Ato=0D=0A>> >> this review in th= e sense of enabling a more precise scoping for=0D=0Athe=0D=0A>> >> framewor= k document and we are willing to assist in providing=0D=0Awording=0D=0A>> >= > for any disclaimer/applicability statement that the Ecrit working=0D=0A>>= group=0D=0A>> >> may now deem fit to include.=0D=0A>> >>=0D=0A>> >> Kind R= egards=0D=0A>> >>=0D=0A>> >> Stephen Edge (Qualcomm 3GPP SA2 participant), = Kirk Burroughs=0D=0A>> (Qualcomm=0D=0A>> >> 3GPP2 TSG-X and TSG-C participa= nt)=0D=0A>> >>=0D=0A>> >> PS this being sent on 2/4/09 at 11:50pm PST=0D=0A= >> >>=0D=0A>> >> _______________________________________________=0D=0A>> >>= Ecrit mailing list=0D=0A>> >> Ecrit@ietf.org=0D=0A>> >> https://www.ietf.o= rg/mailman/listinfo/ecrit=0D=0A>> >=0D=0A>> > _____________________________= __________________=0D=0A>> > Ecrit mailing list=0D=0A>> > Ecrit@ietf.org=0D= =0A>> > https://www.ietf.org/mailman/listinfo/ecrit=0D=0A>> >=0D=0A>> _____= __________________________________________=0D=0A>> Ecrit mailing list=0D=0A= >> Ecrit@ietf.org=0D=0A>> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A= >=0D=0A>=0D=0A-------------------------------------------------------------= -----------=0D=0A------------------------=0D=0A> This message is for the de= signated recipient only and may=0D=0A> contain privileged, proprietary, or = otherwise private information.=0D=0A> If you have received it in error, ple= ase notify the sender=0D=0A> immediately and delete the original. Any unau= thorized use of=0D=0A> this email is prohibited.=0D=0A>=0D=0A--------------= ----------------------------------------------------------=0D=0A-----------= -------------=0D=0A> [mf2]=0D=0A> _________________________________________= ______=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www.i= etf.org/mailman/listinfo/ecrit=0D=0A>=0D=0A=0D=0A__________________________= _____________________=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttp= s://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A*****=0D=0A=0D=0AThe inf= ormation transmitted is intended only for the person or entity to=0D=0Awhic= h it is addressed and may contain confidential, proprietary, and/or=0D=0Apr= ivileged material. Any review, retransmission, dissemination or other=0D=0A= use of, or taking of any action in reliance upon this information by=0D=0Ap= ersons 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. GA621=0D=0A=0D=0A=0D=0A________________________= _______________________=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Aht= tps://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A----------------------= --------------------------------------------------------------------------=0D= =0AThis message is for the designated recipient only and may=0D=0Acontain p= rivileged, proprietary, or otherwise private information. =20=0D=0AIf you h= ave received it in error, please notify the sender=0D=0Aimmediately and del= ete the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0A[mf2]=0D=0A From sedge@qualcomm.com Wed Mar 4 19:54:31 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 161AC28C1F0 for ; Wed, 4 Mar 2009 19:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.266 X-Spam-Level: X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3i7TkixVtVL for ; Wed, 4 Mar 2009 19:54:28 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 3966628C1DF for ; Wed, 4 Mar 2009 19:54:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1236225297; x=1267761297; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" Winterbottom,=20James"=20, =0D=0A=20=20=20=20=20=20=20=20"Stark,=20Barbara"=0D=0A=09 ,=0D=0A=20=20=20=20=20=20=20=20"br@brianr osen.net"=20|CC:=20ECRIT=20|Date:=20Wed,=204=20Mar=202009=2019:54:51=20-0800 |Subject:=20RE:=20[Ecrit]=20Comments=20on=20Framework=20D raft|Thread-Topic:=20[Ecrit]=20Comments=20on=20Framework =20Draft|Thread-Index:=20AcmY6xMaVsPKQOa6Rj2puYM6nfd6RAAC FkpAARDTCVAAAJ6vQAACazkA|Message-ID:=20<1288E74A73964940B 132A0B9EA8D8ABC5374A197@NASANEXMB04.na.qualcomm.com> |References:=20<1288E74A73964940B132A0B9EA8D8ABC535F0305@ NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c 60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEX MB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A7 3964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.c om><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB 04.na.qualcomm.com><64147.24.154.127.233.1235746352.squir rel@www.brianrosen.net><7582BC68E4994F4ABF0BD4723975C3FA0 D39534E@crexc41p>=0D=0A=20<1288E74A73964940B132A0B9EA8D8A BC5374A196@NASANEXMB04.na.qualcomm.com>=0D=0A=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5543"=3B=20a=3D"15996513"; bh=0xW3IhbZhYPDK9pikPBb5GvnvqWXTcKnxiRDfzkElm0=; b=L+6TENgnUnbn0yHWE5kGGkdxLjsuZpzysB4dWDYoCQdUI1ki4VUUbRQx kb/MFxRRHZcbinZJ+SKz8YT25kabmqEcrOz+Stwb16SaoAOYDDyB6E0GX gR8PHL4jxz/lcL7fbXtGTJ2qnZTaWqRZ/1ABb0+u/scjY4eZl6cKi/w7X o=; X-IronPort-AV: E=McAfee;i="5300,2777,5543"; a="15996513" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Mar 2009 19:54:57 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n253suOJ028396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Mar 2009 19:54:56 -0800 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n253suhp009101 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Mar 2009 19:54:56 -0800 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Wed, 4 Mar 2009 19:54:55 -0800 From: "Edge, Stephen" To: "Winterbottom, James" , "Stark, Barbara" , "br@brianrosen.net" Date: Wed, 4 Mar 2009 19:54:51 -0800 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmY6xMaVsPKQOa6Rj2puYM6nfd6RAACFkpAARDTCVAAAJ6vQAACazkA Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5374A197@NASANEXMB04.na.qualcomm.com> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com><64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net><7582BC68E4994F4ABF0BD4723975C3FA0D39534E@crexc41p> <1288E74A73964940B132A0B9EA8D8ABC5374A196@NASANEXMB04.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 03:54:31 -0000 Hi James Thanks for these comments. I assume you recall that SUPL would use an E-SLP located in the serving 3GP= P/3GPP2 network in case of combined access and VSP support. There are then = no roaming or global database issues as all location is supported within th= e serving network. Recall that you are claiming that the current Ecrit solu= tion minus SUPL is suitable for this case which will be by far the most com= mon one for emergency calls made via cellular networks. So I still ask you = to justify why mandating support for DHCP and HELD and not including SUPL i= s a suitable solution. For other scenarios not involving cellular access or where the cellular car= rier is used only as an ISP, SUPL can still be suitable. For example, it is= not true that a worldwide detailed database would be needed (e.g. containi= ng the cell IDs of networks). A-GPS and A-GNSS can work quite well using fa= irly coarse location information (e.g. country or network identification) t= o seed assistance data and such coarse location information can be obtained= by a number of means (e.g. IP address, country/network portions of a cell = ID, previous location estimate). Kind Regards Stephen -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Wednesday, March 04, 2009 7:02 PM To: Edge, Stephen; Stark, Barbara; br@brianrosen.net Cc: ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Hi Stephen, SUPL has one very huge disadvantage, it mandates the use of a home SLP. SUPL roaming between carriers is basically unimplementable. The mechanisms required to support an H-SLP determining the V-SLP address are deliberately left out of scope by OMA, and large numbers of companies are busily putting IPR on the ways in which this can occur. There are no large-scale deployments of RLP that I am aware of, and this is a clear indicator of how bad the currently proposed architecture is. All this means that for SUPL to be deployable on a large scale any H-SLP simply has to have the entire world in a database. This is abundantly evident when you look at systems like the global Nokia solution. I think that this is mammoth task to maintain for general cell coverage, on a global basis when you include W-LAN and femto-cells it is quite simply ridiculous. The result is that SUPL is next to useless as a solution for anything other than providing basic-cell location or assistance data for GPS. It is not local in the same sense that an LCP is. All of the other determination mechanisms that you described in your previous email simply don't work in SUPL to any reasonable degree, and I would argue don't work at all once the device in a foreign network. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Edge, Stephen Sent: Thursday, 5 March 2009 1:20 PM To: Stark, Barbara; br@brianrosen.net Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft Barbara and others Thanks for the comments. When I look at the PhoneBCP I see that both HELD and DHCP are mandatory for the device whereas at least one of these is mandatory for the AN. While I can also see that SUPL is not ruled out (though it is not mentioned or referenced), it appears to have been displaced by the HELD and DHCP requirements. On the other hand, many cellular networks have already deployed or are in the process of deploying SUPL and I am not aware of any that have deployed an accurate location capability using HELD or DHCP. So I would like to know how you see the current requirements as being suitable - after all, they imply at the very least additional development and deployment on the part of network and device vendors and network operators, whereas if SUPL was one of the defined LCPs, that additional development and deployment might be mostly avoided. This question would not be applicable with some additional scope limitation and so I had not previously raised it. But it is certainly applicable in the context of the global scope that is being claimed by some responders. Kind Regards Stephen -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Friday, February 27, 2009 8:28 AM To: br@brianrosen.net; Edge, Stephen Cc: ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Thank you Brian. This is well said [except you left out the fact that ecrit also allows for devices to get their location through other mechanisms, such as GPS, SUPL, or other methods, and doesn't insist that the location be configured through DHCP or HELD]. I agree 100% that additional qualifications are unnecessary. Service providers, vendors, national bodies dealing with emergency services, and regulators aren't stupid. Please trust us to figure out for ourselves when/where/how to apply a "standard". There is no need to try to artificially limit or define scope, or to state the obvious (e.g., the architecture applies where it applies, and doesn't apply where it doesn't apply). We understand the role and scope of the IETF, and the role and scope of 3GPP and 3GPP2. And all the other SDOs (and national bodies and regulatory agencies). SDOs need to offer architectures that apply within the area of applicability for that SDO, and are useful to potential implementers, and leave it to the SPs, national bodies and regulators to decide which architectures and standards to use or to mandate within the scope of their network or jurisdiction. Again, we aren't stupid. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of br@brianrosen.net Sent: Friday, February 27, 2009 9:53 AM To: Edge, Stephen Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft Stephen Like any standards organization, the IETF restricts it's scope. Generally, the scope is "the Internet", although we very often describe solutions that are explicitly designed for private IP networks as well as the Internet. We don't write standards for circuit switched networks, and it should be no surprise that the ecrit solution does not cater to CS solutions. Nevertheless, we often try to make sure that our solutions harmonize reasonably well with existing solutions. Indeed, the ecrit solution clains global applicability to the Internet in general, and most private IP networks that can be interconnected to the Internet or to other IP networks via gateways. Looking at your list of problem areas: > - access to PSTN capable PSAPs This is out of scope for IETF. NENA has active work on this subject. It seems straightforward to interwork ecrit compatible devices and networks to existing CS connected PSAPs. As you know, CS interconnects are very nation-specific, so the NENA work may not have general applicability. However, it shows that it is possible to interwork. The NENA i2 work is also designed to take ecrit compatible devices and VSP networks, and interwork them to the existing network. The VSP would direct the call to the VPC, which would provide the services it does now, using the device provided location for routing. This is important for smooth transition from existing PSAPs and VSPs to "next generation" PSAPs and VSPs. > - handover between different IP access networks including different > types of access network In the ecrit solution, the access network the call is initiated on provides all the facilities needed for the device to initiate an emergency call. The call starts traversing it's normal call path, and eventually routes to the ESRP. Handoffs between IP networks should be transparent to this process, although we probably haven't done all the work we need to do for handoffs where the IP address as seen by the terminating network changes. This would generally be true of all current SIP based work. > - handover to/from circuit mode networks This would be out of scope for IETF. It's as applicable to a simple SIP call as it is a SIP emergency call, and there are no statements in any SIP documents on that subject. > - location for cellular access (and the requirement to support LCPs that > will be useless for cellular access) Location for cellular access networks has been considered carefully. Since cellular is a mobile network, the access network would pass the device a Location-By-Reference URI, using either DHCP or HELD. Either protocol is suitable for cellular networks. As we have pointed out several times, cellular networks support raw data packet services upon which many different kinds of networks can be constructed. My usual example is a large recreational vehicle traveling down a road with a cellular data card plugged into a router to which a wired (Ethernet) phone is connected. That phone must be able to make an emergency call, and it will get location from DHCP or HELD (or LLDP-MED). It is not aware of the cellular network, and doesn't know any cellular specific protocols. Cellular networks will have to support IETF location configuration protocols unless they actively prohibit examples like this, or they implement interworking between cellular-specific location protocols and DHCP or HELD in the data card. The ecrit standards permit proxy insertion of location, but, as above, we don't think that works in all cases. > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) The "load" of using DHCP or HELD to get location and querying LoST is pretty modest. The standards permit proxies to do this if the devices don't. As above, interwork functions to CS connected PSAPs is very feasible, and as above, cellular networks will have to support access to local LoST servers for devices that are connected to cellular networks and are ecrit compliant. > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls This is covered in the standards. None of the processes are dependent on authentication, although where it is possible, it's desirable so as to minimize fraudulent emergency calls Mechanisms for specific network authentication mechanisms are out of scope, and, like SIP basic calling, are not usually mentioned in IETF documents. Stephen, we've tried pretty hard to make sure this works for 3G/4G mobile networks. It's true that it doesn't do it the way 3GPP currently thinks it ought to work, but we claim they haven't thought through all the issues. While it would work, there are opportunities for improvement. We would be willing to do that if we could get the cooperation of 3GPP, which we have tried, and failed, to do. So, I think the documents do not need any qualification statements. Brian > Martin > > The 3GPP/3GPP2 solution has a defined restricted applicability (mainly to > 3GPP/3GPP2 access networks where the serving network also acts as the VSP) > and the specifications for it cover in detail all possible scenarios > consistent with these restrictions so far as we are aware. > > The Ecrit solution seems to claim global applicability to all types of IP > access (and the more that is said about this from Ecrit participants the > more this gets emphasized) but does not cover in detail all possible > scenarios (in some cases does not cover in any detail) which means that at > best the solution is incomplete and at worst intrinsically inapplicable to > some unstated set of scenarios. > > The missing, incomplete and problematic cases include the following: > > - access to PSTN capable PSAPs > - handover between different IP access networks including different > types of access network > - handover to/from circuit mode networks > - location for cellular access (and the requirement to support LCPs that > will be useless for cellular access) > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls > > Stating that some of these cases are out of scope or referencing an > incomplete and possibly questionable specification from some other > national SDO will not help the user who encounters such problems. But it > would certainly help network operators and implementers to acknowledge > their existence in one form or another because that would allow better > planning of deployments and would help focus attention on finding > solutions (whether in IETF or elsewhere) for the missing cases. > > Please note that despite these drawbacks, I will acknowledge that Ecrit > does have a valuable solution that covers many scenarios not covered by > 3GPP/3GPP2. It would be the delineation of these supported scenarios (or > equivalently unsupported scenarios) in some applicability statement that > would be particularly useful right now. > > Kind Regards > > Stephen > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Thursday, February 26, 2009 9:45 PM > To: Edge, Stephen; Richard Barnes > Cc: ECRIT > Subject: RE: [Ecrit] Comments on Framework Draft > > There's benefit in knowing the limitations of a framework, and every > architecture makes certain assumptions. Let's examine them though... > > The IETF might occasionally make the assumption that the standards it > develops are for Internet devices. That assumption probably need not be > stated explicitly. > > The ECRIT architecture relies on implementations of the protocols that it > references. That is not extraordinary. A reliance on implementation of > these protocols by endpoints, routing intermediaries and PSAPs should not > need to be explained. > > So the assumptions are: > - the Internet > - solutions are implemented and deployed > - the end device is a key component > > Only that last element is particularly novel ... or not that much really. > It's a design choice. Unless you were thinking of trunking the voice > elsewhere. > > Of course, you're suggesting that the design choice was made in ignorance > of all the constraints. You're suggesting that - as a result - the choice > is flawed and the solution is not going to work for cellular services. We > disagree. The solution is a basis for emergency calling in _any_ IP > network. > > Cheers, > Martin > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Edge, Stephen >> Sent: Friday, 27 February 2009 3:30 PM >> To: Richard Barnes >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Richard >> >> Thanks for the comments. Your statement below that "SIP emergency >> calling works if all parties behave as specified in these (IETF Ecrit) >> documents" to some degree highlights the problems we are raising. The >> documents do contain a number of implicit and explicit restrictions - >> like IP capable PSAPs, global IP access (no islands of circuit mode >> access for example), universal support of this solution by all access >> providers and VSPs (not much good if some opt for another solution) and >> end system oriented location and routing capability - which together >> make them unsuitable (we believe) for cellular wireless networks. If >> these restrictions and assumptions were all made explicit upfront, it >> would to a large degree (and possibly completely) address our concerns. >> >> You are right in assuming another set of specifications for the 3GPP >> and 3GPP2 solution. The applicability of this solution is explicitly >> defined in TS 23.167 (or more exactly in an already agreed CR in >> contribution S2-090752 which will become part of 23.167 in a few more >> weeks) to cover the following access types: GPRS (UTRAN WCDMA), I-WLAN, >> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN >> (LTE). So there is a restriction and arbitrary internet access is not >> covered (yet) as I have stated before. >> >> Kind Regards >> >> Stephen >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Wednesday, February 25, 2009 6:30 PM >> To: Edge, Stephen >> Cc: Brian Rosen; 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Stephen, >> >> I'm a little confused by the scope of what you're asking. The >> framework >> and phonebcp documents exist in order to describe the ECRIT solution: >> They say, in effect, "SIP emergency calling works if all parties behave >> as specified in these documents." >> >> As I understand what you're saying (and I'm by no means an expert in >> 3GPP), 3GPP specifies that one or more elements of this system behave >> differently. This simply means that 3GPP networks aren't complying >> with >> these specs. Just like there's no disclaimer in RFC 791 (IPv4) that >> says "this doesn't work on X.25 networks", it's not clear to me that an >> analogous disclaimer is called for here. >> >> I presume there are similar documents describing how emergency calling >> works in 3GPP networks. Do they include notes saying that the 3GPP >> solution doesn't work in the broader Internet? >> >> --Richard >> >> >> >> >> >> Edge, Stephen wrote: >> > Brian >> > >> > First of all apologies for the likely lateness of this reply - I >> actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest but >> it seems unlikely that my VPN, Outlook server and WiFi access >> capability will cooperate together to get it sent until I return to the >> office mid-next week. >> > >> > Anyhow thanks for your comments. There have actually been a number of >> conference calls between IETF and 3GPP participants over the last >> couple of years at which common features like support of IP emergency >> calls were discussed and these could have been good forum for >> participants on either side to have raised the kinds of issues you >> elaborate on below. Given that seems not so far to have happened, it >> could still be possible in future such calls. >> > >> > But the issues we are raising are not directly to do with further >> aligning the 2 solutions or with the lack of this in the past. We are >> simply pointing out that the solutions are currently different and that >> from a cellular wireless perspective, the Ecrit solution is not seen as >> suitable in all respects (for support of IP emergency calls originating >> from such access types). That is not just our point of view. 3GPP2 sent >> a liaison to Ecrit some months ago pointing out the same issues. >> > >> > So we are proposing that the Ecrit framework and phoneBCP spec.s >> include a statement acknowledging this - e.g. by referencing the >> alternative 3GPP/3GPP2 solution and indicating the IP access types for >> which the Ecrit solution will work without limitation (or equivalently >> the access types where limitations are not ruled out). >> > >> > We are not proposing further modification and extension of the Ecrit >> solution - just pointing out that this would be needed (as with the >> 3GPP/3GPP2 solution) to fully cover all types of access. >> > >> > Kind Regards >> > >> > Stephen >> > -----Original Message----- >> > From: Brian Rosen [mailto:br@brianrosen.net] >> > Sent: Wednesday, February 18, 2009 8:07 PM >> > To: Edge, Stephen; 'ECRIT' >> > Subject: RE: [Ecrit] Comments on Framework Draft >> > >> > I have bit my tongue on this one for a long time. >> > >> > Stephen, with respect, please go talk to 3GPP management and ask them >> why >> > there has been no participation in the ecrit effort despite multiple >> YEARS >> > of begging them to get involved. To put it frankly, 3GPP is quite >> willing >> > to bully IETF into doing its work on its schedule, but cannot be >> bothered to >> > get work done it knows it will eventually have to do when the IETF >> asks it >> > to do so. >> > >> > 3GPP understands the mess that is being created by not participating. >> They >> > know full well that when they finally get around to dealing with PS >> > terminated emergency calls, that there will be a lot of resistance to >> > changing fully specified and implemented standards to more closely >> align >> > with 3GPP standards. I expect you will have several interworking >> functions >> > to define and build. >> > >> > So, politely, please go away, we're finishing work we dearly wanted >> you all >> > to be involved with for years, but you refused to do anything. It's >> too >> > late for this rev. >> > >> > Now, having said that, there are quite a few people who have >> participated in >> > the IETF work who are IMS aware and I believe that despite your >> fears, >> > everything you need is in the specs. The mechanisms we have defined >> provide >> > the ability for the network to insert location, recognize and mark >> emergency >> > calls, and route on behalf of endpoints. An E-CSCF could quite >> > straightforwardly provide a SIP call towards an ecrit compatible >> PSAP. The >> > only not-quite-nice interwork would be from SUPL to HELD (or SIP), >> but it's >> > pretty easy to do that. I'll also note that we have tried to get OMA >> and >> > IETF to cooperate on location protocols, but we have been >> spectacularly >> > unsuccessful at that effort also. >> > >> > Brian >> > >> > >> > >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf >> >> Of Edge, Stephen >> >> Sent: Thursday, February 05, 2009 2:50 AM >> >> To: 'ECRIT' >> >> Subject: [Ecrit] Comments on Framework Draft >> >> >> >> All >> >> >> >> draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative >> >> description of how terminals and networks should support emergency >> >> calls made over IP capable facilities to IP capable PSAPs. It >> appears >> >> intended to cover all types of access network - including fixed >> line, >> >> WiFi and cellular (e.g. examples involving each can be found >> throughout >> >> the draft). >> >> >> >> When we evaluated this with respect to support of wireless cellular >> >> access and WiFi access associated with a cellular operator (e.g. >> WLAN >> >> or Femto cells integrated into a cellular network), we found that >> >> certain portions of the draft exhibited one or more of the following >> >> characteristics: >> >> >> >> (A) Inconsistent with already standardized wireless solutions >> >> >> >> (B) Inconsistent with essential wireless requirements and >> >> conventions >> >> >> >> (C) Already part of wireless standards or potentially part of >> >> future standards >> >> >> >> (A) refers to all portions of the draft framework that differ from >> the >> >> requirements and procedures currently standardized for wireless >> >> emergency access by 3GPP, 3GPP2 and OMA. This is a plain difference >> of >> >> solution and could be resolved through support of both solutions by >> >> terminals (with each solution being used according to the type of >> >> access network and VSP) or could be resolved by supporting only one >> >> solution and accessing only the types of network supporting that >> >> solution. To acknowledge this category, the framework document could >> >> reference the applicable wireless standards and point out that these >> >> are valid alternatives for wireless cellular based access. >> >> >> >> (B) refers to portions of the draft that would be unsuitable for >> >> wireless networks even if no alternative solution existed together >> with >> >> other portions missing from the draft that would be needed to fully >> >> support wireless networks. Examples of the former include: (a) >> emphasis >> >> on endpoint derivation of location, performance of Lost query and >> >> receipt of local dial strings; (b) restriction of LCPs to protocols >> >> that require terminal initiation (not allowing for network >> initiation >> >> as far as we can tell) and that include two LCPs (DHCP and LLDP) >> that >> >> are not applicable to (not defined for) cellular access; and (c) the >> >> requirement that a terminal or at least a LIS will update the PSAP >> >> whenever location changes. (a) is impractical due to network and >> >> terminal loading consequences and failure to support non-IP capable >> >> PSAPs; (b) makes location verification and updated location >> provision >> >> to PSAPs difficult or impossible; while (c) is also incompatible >> with >> >> support of existing non-IP capable PSAPs besides increasing terminal >> >> load and possibly interfering with optimum maintenance of the RF >> >> connection (e.g. if a terminal has to tune away from the serving >> base >> >> station or WLAN periodically to make location measurements). >> Examples >> >> of the latter include (d) absence of support for access to non-IP >> >> capable PSAPs as already mentioned (e.g. to support E911 phase 2 in >> the >> >> US); (e) no support for handover from the IP to the circuit domain >> when >> >> a terminal loses (e.g. moves out of) RF coverage in the IP domain; >> and >> >> (f) no allowance for limited access modes wherein a terminal may >> access >> >> a network only to place an emergency call with ensuing restrictions >> on >> >> (for example) location acquisition, PSAP callback and caller >> >> verification and identification to the PSAP. To resolve this >> category >> >> either significant changes to the framework document could be made >> or a >> >> disclaimer/applicability statement could be added stating that >> support >> >> of cellular wireless networks and their associated WLAN and Femto >> >> access points is not covered. >> >> >> >> Category (C) comprises concepts and capabilities in the draft that >> are >> >> either already part of the standardized solution for wireless >> networks >> >> or that might be added at a later time. Examples of the former >> include >> >> LoST, SIP location conveyance, general use of SIP, location for >> routing >> >> versus for dispatch, cellular positioning methods. Examples of the >> >> latter include use of location references and dereferencing and >> >> possible interworking between the current wireless network solutions >> >> (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. >> The >> >> presence of this category could be acknowledged by following the >> >> disclaimer for (B) with a statement that certain portions of the >> >> solution are expected to be incorporated into wireless networks now >> >> and/or in the future. >> >> >> >> We hope that these comments will be seen to be a useful addition to >> >> this review in the sense of enabling a more precise scoping for the >> >> framework document and we are willing to assist in providing wording >> >> for any disclaimer/applicability statement that the Ecrit working >> group >> >> may now deem fit to include. >> >> >> >> Kind Regards >> >> >> >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs >> (Qualcomm >> >> 3GPP2 TSG-X and TSG-C participant) >> >> >> >> PS this being sent on 2/4/09 at 11:50pm PST >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www.ietf.org/mailman/listinfo/ecrit >> > >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------ ------------------------ > 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://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.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://www.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] From Gabor.Bajko@nokia.com Wed Mar 4 22:07:07 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61B613A6A6C for ; Wed, 4 Mar 2009 22:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYUgttrHLFa3 for ; Wed, 4 Mar 2009 22:06:54 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id EFD233A6A33 for ; Wed, 4 Mar 2009 22:06:51 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n25670SM016128; Thu, 5 Mar 2009 08:07:03 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 08:07:02 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 08:06:58 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Thu, 5 Mar 2009 07:06:58 +0100 From: To: , , Date: Thu, 5 Mar 2009 07:06:56 +0100 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmY6xMaVsPKQOa6Rj2puYM6nfd6RAACFkpAARDTCVAABsfxQA== Message-ID: References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com> <64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net> <7582BC68E4994F4ABF0BD4723975C3FA0D39534E@crexc41p> <1288E74A73964940B132A0B9EA8D8ABC5374A196@NASANEXMB04.na.qualcomm.com> In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5374A196@NASANEXMB04.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Mar 2009 06:06:58.0080 (UTC) FILETIME=[9779E200:01C99D58] X-Nokia-AV: Clean Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 06:07:07 -0000 Stephen, Thanks for pointing out these issues. If you look at the previous versions = of phoneBCP, you'll also see LLDP (which was developed for fixed environmen= t, like switches) on the list of mandatory LCPs. It took 2 years (!) to tak= e that out from there, so in that sense there is some progress towards writ= ing a more realistic set of requirements. When it was requested to add SUPPL to the list, or to at least mention that= SUPPL is the one which is currently mostly used for positioning (what an i= mpertinent request it was to add to a document intended to describe BEST Cu= rrent Practices, the protocols which are currently in use), the argument ag= ainst it was that SUPPL requires the existence of a subscription, while the= internet is subscription free. Meanwhile people refused to take a look at the applicability of a DHCP base= d positioning method in today's world, where everything tends to be mobile. An HTTP based protocol like HELD has the potential to offer solution for ma= ny, but not all of the use cases, as it can deliver location related measur= ement information to location servers. The cases when HELD does not work is= when positioning is done using network based positioning methods involving= control plane, like U-TDOA or AFLT. But then again, these are the position= ing technologies which are currently used in indoor environments where (A-)= GPS does not work. Perhaps this is the reason why they are not mentioned in= a Best Current Practice document ... - Gabor >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf O= f >ext Edge, Stephen >Sent: Wednesday, March 04, 2009 6:20 PM >To: Stark, Barbara; br@brianrosen.net >Cc: ECRIT >Subject: Re: [Ecrit] Comments on Framework Draft > >Barbara and others > >Thanks for the comments. > >When I look at the PhoneBCP I see that both HELD and DHCP are mandatory >for the device whereas at least one of these is mandatory for the AN. >While I can also see that SUPL is not ruled out (though it is not >mentioned or referenced), it appears to have been displaced by the HELD >and DHCP requirements. On the other hand, many cellular networks have >already deployed or are in the process of deploying SUPL and I am not >aware of any that have deployed an accurate location capability using >HELD or DHCP. So I would like to know how you see the current >requirements as being suitable - after all, they imply at the very least >additional development and deployment on the part of network and device >vendors and network operators, whereas if SUPL was one of the defined >LCPs, that additional development and deployment might be mostly avoided= . >This question would not be applicable with some additional scope >limitation and so I had not previously raised it. But it is certainly >applicable in > the context of the global scope that is being claimed by some >responders. > >Kind Regards > >Stephen >-----Original Message----- >From: Stark, Barbara [mailto:bs7652@att.com] >Sent: Friday, February 27, 2009 8:28 AM >To: br@brianrosen.net; Edge, Stephen >Cc: ECRIT >Subject: RE: [Ecrit] Comments on Framework Draft > >Thank you Brian. This is well said [except you left out the fact that >ecrit also allows for devices to get their location through other >mechanisms, such as GPS, SUPL, or other methods, and doesn't insist that >the location be configured through DHCP or HELD]. > >I agree 100% that additional qualifications are unnecessary. Service >providers, vendors, national bodies dealing with emergency services, and >regulators aren't stupid. Please trust us to figure out for ourselves >when/where/how to apply a "standard". There is no need to try to >artificially limit or define scope, or to state the obvious (e.g., the >architecture applies where it applies, and doesn't apply where it >doesn't apply). We understand the role and scope of the IETF, and the >role and scope of 3GPP and 3GPP2. And all the other SDOs (and national >bodies and regulatory agencies). SDOs need to offer architectures that >apply within the area of applicability for that SDO, and are useful to >potential implementers, and leave it to the SPs, national bodies and >regulators to decide which architectures and standards to use or to >mandate within the scope of their network or jurisdiction. Again, we >aren't stupid. >Barbara > >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >Of br@brianrosen.net >Sent: Friday, February 27, 2009 9:53 AM >To: Edge, Stephen >Cc: ECRIT >Subject: Re: [Ecrit] Comments on Framework Draft > >Stephen > >Like any standards organization, the IETF restricts it's scope. >Generally, the scope is "the Internet", although we very often describe >solutions that are explicitly designed for private IP networks as well >as >the Internet. We don't write standards for circuit switched networks, >and >it should be no surprise that the ecrit solution does not cater to CS >solutions. Nevertheless, we often try to make sure that our solutions >harmonize reasonably well with existing solutions. > >Indeed, the ecrit solution clains global applicability to the Internet >in >general, and most private IP networks that can be interconnected to the >Internet or to other IP networks via gateways. Looking at your list of >problem areas: >> - access to PSTN capable PSAPs >This is out of scope for IETF. NENA has active work on this subject. >It >seems straightforward to interwork ecrit compatible devices and networks >to existing CS connected PSAPs. As you know, CS interconnects are very >nation-specific, so the NENA work may not have general applicability. >However, it shows that it is possible to interwork. The NENA i2 work is >also designed to take ecrit compatible devices and VSP networks, and >interwork them to the existing network. The VSP would direct the call >to >the VPC, which would provide the services it does now, using the device >provided location for routing. This is important for smooth transition >from existing PSAPs and VSPs to "next generation" PSAPs and VSPs. >> - handover between different IP access networks including different >> types of access network >In the ecrit solution, the access network the call is initiated on >provides all the facilities needed for the device to initiate an >emergency >call. The call starts traversing it's normal call path, and eventually >routes to the ESRP. Handoffs between IP networks should be transparent >to >this process, although we probably haven't done all the work we need to >do >for handoffs where the IP address as seen by the terminating network >changes. This would generally be true of all current SIP based work. >> - handover to/from circuit mode networks >This would be out of scope for IETF. It's as applicable to a simple SIP >call as it is a SIP emergency call, and there are no statements in any >SIP >documents on that subject. >> - location for cellular access (and the requirement to support LCPs >that >> will be useless for cellular access) >Location for cellular access networks has been considered carefully. >Since cellular is a mobile network, the access network would pass the >device a Location-By-Reference URI, using either DHCP or HELD. Either >protocol is suitable for cellular networks. As we have pointed out >several times, cellular networks support raw data packet services upon >which many different kinds of networks can be constructed. My usual >example is a large recreational vehicle traveling down a road with a >cellular data card plugged into a router to which a wired (Ethernet) >phone >is connected. That phone must be able to make an emergency call, and it >will get location from DHCP or HELD (or LLDP-MED). It is not aware of >the >cellular network, and doesn't know any cellular specific protocols. >Cellular networks will have to support IETF location configuration >protocols unless they actively prohibit examples like this, or they >implement interworking between cellular-specific location protocols and >DHCP or HELD in the data card. The ecrit standards permit proxy >insertion >of location, but, as above, we don't think that works in all cases. >> - endpoint based location and routing for cellular access (issues >here >> are network and device loading as well as device impacts and problems >> with PSTN capable PSAPs) >The "load" of using DHCP or HELD to get location and querying LoST is >pretty modest. The standards permit proxies to do this if the devices >don't. As above, interwork functions to CS connected PSAPs is very >feasible, and as above, cellular networks will have to support access to >local LoST servers for devices that are connected to cellular networks >and >are ecrit compliant. >> - support of unauthenticated users and users who can be >authenticated >> but are not permitted access/VSP service except for emergency calls >This is covered in the standards. None of the processes are dependent >on >authentication, although where it is possible, it's desirable so as to >minimize fraudulent emergency calls >Mechanisms for specific network authentication mechanisms are out of >scope, and, like SIP basic calling, are not usually mentioned in IETF >documents. > >Stephen, we've tried pretty hard to make sure this works for 3G/4G >mobile >networks. It's true that it doesn't do it the way 3GPP currently thinks >it ought to work, but we claim they haven't thought through all the >issues. While it would work, there are opportunities for improvement. >We >would be willing to do that if we could get the cooperation of 3GPP, >which >we have tried, and failed, to do. > >So, I think the documents do not need any qualification statements. > >Brian > >> Martin >> >> The 3GPP/3GPP2 solution has a defined restricted applicability (mainly >to >> 3GPP/3GPP2 access networks where the serving network also acts as the >VSP) >> and the specifications for it cover in detail all possible scenarios >> consistent with these restrictions so far as we are aware. >> >> The Ecrit solution seems to claim global applicability to all types of >IP >> access (and the more that is said about this from Ecrit participants >the >> more this gets emphasized) but does not cover in detail all possible >> scenarios (in some cases does not cover in any detail) which means >that at >> best the solution is incomplete and at worst intrinsically >inapplicable to >> some unstated set of scenarios. >> >> The missing, incomplete and problematic cases include the following: >> >> - access to PSTN capable PSAPs >> - handover between different IP access networks including different >> types of access network >> - handover to/from circuit mode networks >> - location for cellular access (and the requirement to support LCPs >that >> will be useless for cellular access) >> - endpoint based location and routing for cellular access (issues >here >> are network and device loading as well as device impacts and problems >> with PSTN capable PSAPs) >> - support of unauthenticated users and users who can be >authenticated >> but are not permitted access/VSP service except for emergency calls >> >> Stating that some of these cases are out of scope or referencing an >> incomplete and possibly questionable specification from some other >> national SDO will not help the user who encounters such problems. But >it >> would certainly help network operators and implementers to acknowledge >> their existence in one form or another because that would allow better >> planning of deployments and would help focus attention on finding >> solutions (whether in IETF or elsewhere) for the missing cases. >> >> Please note that despite these drawbacks, I will acknowledge that >Ecrit >> does have a valuable solution that covers many scenarios not covered >by >> 3GPP/3GPP2. It would be the delineation of these supported scenarios >(or >> equivalently unsupported scenarios) in some applicability statement >that >> would be particularly useful right now. >> >> Kind Regards >> >> Stephen >> -----Original Message----- >> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] >> Sent: Thursday, February 26, 2009 9:45 PM >> To: Edge, Stephen; Richard Barnes >> Cc: ECRIT >> Subject: RE: [Ecrit] Comments on Framework Draft >> >> There's benefit in knowing the limitations of a framework, and every >> architecture makes certain assumptions. Let's examine them though... >> >> The IETF might occasionally make the assumption that the standards it >> develops are for Internet devices. That assumption probably need not >be >> stated explicitly. >> >> The ECRIT architecture relies on implementations of the protocols that >it >> references. That is not extraordinary. A reliance on implementation >of >> these protocols by endpoints, routing intermediaries and PSAPs should >not >> need to be explained. >> >> So the assumptions are: >> - the Internet >> - solutions are implemented and deployed >> - the end device is a key component >> >> Only that last element is particularly novel ... or not that much >really. >> It's a design choice. Unless you were thinking of trunking the >voice >> elsewhere. >> >> Of course, you're suggesting that the design choice was made in >ignorance >> of all the constraints. You're suggesting that - as a result - the >choice >> is flawed and the solution is not going to work for cellular services. >We >> disagree. The solution is a basis for emergency calling in _any_ IP >> network. >> >> Cheers, >> Martin >> >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >Behalf >>> Of Edge, Stephen >>> Sent: Friday, 27 February 2009 3:30 PM >>> To: Richard Barnes >>> Cc: 'ECRIT' >>> Subject: Re: [Ecrit] Comments on Framework Draft >>> >>> Hi Richard >>> >>> Thanks for the comments. Your statement below that "SIP emergency >>> calling works if all parties behave as specified in these (IETF >Ecrit) >>> documents" to some degree highlights the problems we are raising. The >>> documents do contain a number of implicit and explicit restrictions - >>> like IP capable PSAPs, global IP access (no islands of circuit mode >>> access for example), universal support of this solution by all access >>> providers and VSPs (not much good if some opt for another solution) >and >>> end system oriented location and routing capability - which together >>> make them unsuitable (we believe) for cellular wireless networks. If >>> these restrictions and assumptions were all made explicit upfront, it >>> would to a large degree (and possibly completely) address our >concerns. >>> >>> You are right in assuming another set of specifications for the 3GPP >>> and 3GPP2 solution. The applicability of this solution is explicitly >>> defined in TS 23.167 (or more exactly in an already agreed CR in >>> contribution S2-090752 which will become part of 23.167 in a few more >>> weeks) to cover the following access types: GPRS (UTRAN WCDMA), >I-WLAN, >>> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN >>> (LTE). So there is a restriction and arbitrary internet access is not >>> covered (yet) as I have stated before. >>> >>> Kind Regards >>> >>> Stephen >>> -----Original Message----- >>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>> Sent: Wednesday, February 25, 2009 6:30 PM >>> To: Edge, Stephen >>> Cc: Brian Rosen; 'ECRIT' >>> Subject: Re: [Ecrit] Comments on Framework Draft >>> >>> Hi Stephen, >>> >>> I'm a little confused by the scope of what you're asking. The >>> framework >>> and phonebcp documents exist in order to describe the ECRIT solution: >>> They say, in effect, "SIP emergency calling works if all parties >behave >>> as specified in these documents." >>> >>> As I understand what you're saying (and I'm by no means an expert in >>> 3GPP), 3GPP specifies that one or more elements of this system behave >>> differently. This simply means that 3GPP networks aren't complying >>> with >>> these specs. Just like there's no disclaimer in RFC 791 (IPv4) that >>> says "this doesn't work on X.25 networks", it's not clear to me that >an >>> analogous disclaimer is called for here. >>> >>> I presume there are similar documents describing how emergency >calling >>> works in 3GPP networks. Do they include notes saying that the 3GPP >>> solution doesn't work in the broader Internet? >>> >>> --Richard >>> >>> >>> >>> >>> >>> Edge, Stephen wrote: >>> > Brian >>> > >>> > First of all apologies for the likely lateness of this reply - I >>> actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest >but >>> it seems unlikely that my VPN, Outlook server and WiFi access >>> capability will cooperate together to get it sent until I return to >the >>> office mid-next week. >>> > >>> > Anyhow thanks for your comments. There have actually been a number >of >>> conference calls between IETF and 3GPP participants over the last >>> couple of years at which common features like support of IP emergency >>> calls were discussed and these could have been good forum for >>> participants on either side to have raised the kinds of issues you >>> elaborate on below. Given that seems not so far to have happened, it >>> could still be possible in future such calls. >>> > >>> > But the issues we are raising are not directly to do with further >>> aligning the 2 solutions or with the lack of this in the past. We are >>> simply pointing out that the solutions are currently different and >that >>> from a cellular wireless perspective, the Ecrit solution is not seen >as >>> suitable in all respects (for support of IP emergency calls >originating >>> from such access types). That is not just our point of view. 3GPP2 >sent >>> a liaison to Ecrit some months ago pointing out the same issues. >>> > >>> > So we are proposing that the Ecrit framework and phoneBCP spec.s >>> include a statement acknowledging this - e.g. by referencing the >>> alternative 3GPP/3GPP2 solution and indicating the IP access types >for >>> which the Ecrit solution will work without limitation (or >equivalently >>> the access types where limitations are not ruled out). >>> > >>> > We are not proposing further modification and extension of the >Ecrit >>> solution - just pointing out that this would be needed (as with the >>> 3GPP/3GPP2 solution) to fully cover all types of access. >>> > >>> > Kind Regards >>> > >>> > Stephen >>> > -----Original Message----- >>> > From: Brian Rosen [mailto:br@brianrosen.net] >>> > Sent: Wednesday, February 18, 2009 8:07 PM >>> > To: Edge, Stephen; 'ECRIT' >>> > Subject: RE: [Ecrit] Comments on Framework Draft >>> > >>> > I have bit my tongue on this one for a long time. >>> > >>> > Stephen, with respect, please go talk to 3GPP management and ask >them >>> why >>> > there has been no participation in the ecrit effort despite >multiple >>> YEARS >>> > of begging them to get involved. To put it frankly, 3GPP is quite >>> willing >>> > to bully IETF into doing its work on its schedule, but cannot be >>> bothered to >>> > get work done it knows it will eventually have to do when the IETF >>> asks it >>> > to do so. >>> > >>> > 3GPP understands the mess that is being created by not >participating. >>> They >>> > know full well that when they finally get around to dealing with PS >>> > terminated emergency calls, that there will be a lot of resistance >to >>> > changing fully specified and implemented standards to more closely >>> align >>> > with 3GPP standards. I expect you will have several interworking >>> functions >>> > to define and build. >>> > >>> > So, politely, please go away, we're finishing work we dearly wanted >>> you all >>> > to be involved with for years, but you refused to do anything. >It's >>> too >>> > late for this rev. >>> > >>> > Now, having said that, there are quite a few people who have >>> participated in >>> > the IETF work who are IMS aware and I believe that despite your >>> fears, >>> > everything you need is in the specs. The mechanisms we have >defined >>> provide >>> > the ability for the network to insert location, recognize and mark >>> emergency >>> > calls, and route on behalf of endpoints. An E-CSCF could quite >>> > straightforwardly provide a SIP call towards an ecrit compatible >>> PSAP. The >>> > only not-quite-nice interwork would be from SUPL to HELD (or SIP), >>> but it's >>> > pretty easy to do that. I'll also note that we have tried to get >OMA >>> and >>> > IETF to cooperate on location protocols, but we have been >>> spectacularly >>> > unsuccessful at that effort also. >>> > >>> > Brian >>> > >>> > >>> > >>> >> -----Original Message----- >>> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>> Behalf >>> >> Of Edge, Stephen >>> >> Sent: Thursday, February 05, 2009 2:50 AM >>> >> To: 'ECRIT' >>> >> Subject: [Ecrit] Comments on Framework Draft >>> >> >>> >> All >>> >> >>> >> draft-ietf-ecrit-framework-07 is (as we see it) a mostly >informative >>> >> description of how terminals and networks should support emergency >>> >> calls made over IP capable facilities to IP capable PSAPs. It >>> appears >>> >> intended to cover all types of access network - including fixed >>> line, >>> >> WiFi and cellular (e.g. examples involving each can be found >>> throughout >>> >> the draft). >>> >> >>> >> When we evaluated this with respect to support of wireless >cellular >>> >> access and WiFi access associated with a cellular operator (e.g. >>> WLAN >>> >> or Femto cells integrated into a cellular network), we found that >>> >> certain portions of the draft exhibited one or more of the >following >>> >> characteristics: >>> >> >>> >> (A) Inconsistent with already standardized wireless solutions >>> >> >>> >> (B) Inconsistent with essential wireless requirements and >>> >> conventions >>> >> >>> >> (C) Already part of wireless standards or potentially part of >>> >> future standards >>> >> >>> >> (A) refers to all portions of the draft framework that differ from >>> the >>> >> requirements and procedures currently standardized for wireless >>> >> emergency access by 3GPP, 3GPP2 and OMA. This is a plain >difference >>> of >>> >> solution and could be resolved through support of both solutions >by >>> >> terminals (with each solution being used according to the type of >>> >> access network and VSP) or could be resolved by supporting only >one >>> >> solution and accessing only the types of network supporting that >>> >> solution. To acknowledge this category, the framework document >could >>> >> reference the applicable wireless standards and point out that >these >>> >> are valid alternatives for wireless cellular based access. >>> >> >>> >> (B) refers to portions of the draft that would be unsuitable for >>> >> wireless networks even if no alternative solution existed together >>> with >>> >> other portions missing from the draft that would be needed to >fully >>> >> support wireless networks. Examples of the former include: (a) >>> emphasis >>> >> on endpoint derivation of location, performance of Lost query and >>> >> receipt of local dial strings; (b) restriction of LCPs to >protocols >>> >> that require terminal initiation (not allowing for network >>> initiation >>> >> as far as we can tell) and that include two LCPs (DHCP and LLDP) >>> that >>> >> are not applicable to (not defined for) cellular access; and (c) >the >>> >> requirement that a terminal or at least a LIS will update the PSAP >>> >> whenever location changes. (a) is impractical due to network and >>> >> terminal loading consequences and failure to support non-IP >capable >>> >> PSAPs; (b) makes location verification and updated location >>> provision >>> >> to PSAPs difficult or impossible; while (c) is also incompatible >>> with >>> >> support of existing non-IP capable PSAPs besides increasing >terminal >>> >> load and possibly interfering with optimum maintenance of the RF >>> >> connection (e.g. if a terminal has to tune away from the serving >>> base >>> >> station or WLAN periodically to make location measurements). >>> Examples >>> >> of the latter include (d) absence of support for access to non-IP >>> >> capable PSAPs as already mentioned (e.g. to support E911 phase 2 >in >>> the >>> >> US); (e) no support for handover from the IP to the circuit domain >>> when >>> >> a terminal loses (e.g. moves out of) RF coverage in the IP domain; >>> and >>> >> (f) no allowance for limited access modes wherein a terminal may >>> access >>> >> a network only to place an emergency call with ensuing >restrictions >>> on >>> >> (for example) location acquisition, PSAP callback and caller >>> >> verification and identification to the PSAP. To resolve this >>> category >>> >> either significant changes to the framework document could be made >>> or a >>> >> disclaimer/applicability statement could be added stating that >>> support >>> >> of cellular wireless networks and their associated WLAN and Femto >>> >> access points is not covered. >>> >> >>> >> Category (C) comprises concepts and capabilities in the draft that >>> are >>> >> either already part of the standardized solution for wireless >>> networks >>> >> or that might be added at a later time. Examples of the former >>> include >>> >> LoST, SIP location conveyance, general use of SIP, location for >>> routing >>> >> versus for dispatch, cellular positioning methods. Examples of the >>> >> latter include use of location references and dereferencing and >>> >> possible interworking between the current wireless network >solutions >>> >> (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. >>> The >>> >> presence of this category could be acknowledged by following the >>> >> disclaimer for (B) with a statement that certain portions of the >>> >> solution are expected to be incorporated into wireless networks >now >>> >> and/or in the future. >>> >> >>> >> We hope that these comments will be seen to be a useful addition >to >>> >> this review in the sense of enabling a more precise scoping for >the >>> >> framework document and we are willing to assist in providing >wording >>> >> for any disclaimer/applicability statement that the Ecrit working >>> group >>> >> may now deem fit to include. >>> >> >>> >> Kind Regards >>> >> >>> >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs >>> (Qualcomm >>> >> 3GPP2 TSG-X and TSG-C participant) >>> >> >>> >> PS this being sent on 2/4/09 at 11:50pm PST >>> >> >>> >> _______________________________________________ >>> >> Ecrit mailing list >>> >> Ecrit@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/ecrit >>> > >>> > _______________________________________________ >>> > Ecrit mailing list >>> > Ecrit@ietf.org >>> > https://www.ietf.org/mailman/listinfo/ecrit >>> > >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >------------------------------------------------------------------------ >------------------------ >> 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://www.ietf.org/mailman/listinfo/ecrit >> > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.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://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@andrew.com Wed Mar 4 23:59:33 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 007FF28C106 for ; Wed, 4 Mar 2009 23:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVCxi5zYHOAV for ; Wed, 4 Mar 2009 23:59:30 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 1C2493A686A for ; Wed, 4 Mar 2009 23:59:29 -0800 (PST) X-SEF-Processed: 5_0_0_910__2009_03_05_02_04_19 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 05 Mar 2009 02:04:18 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 01:44:36 -0600 Received: from 10.86.20.51 ([10.86.20.51]) by AHQEX1.andrew.com ([10.86.20.21]) with Microsoft Exchange Server HTTP-DAV ; Thu, 5 Mar 2009 07:44:33 +0000 References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com> <64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net> <7582BC68E4994F4ABF0BD4723975C3FA0D39534E@crexc41p> <1288E74A73964940B132A0B9EA8D8ABC5374A196@NASANEXMB04.na.qualcomm.com> Message-ID: <96AD1EFB-0104-4B64-A94B-7A1877F8ADC6@andrew.com> From: "Winterbottom, James" To: In-Reply-To: Content-Type: text/plain; format=flowed; delsp=yes; charset="us-ascii" thread-index: AcmdZjoOuohgihUhTAGl+xIzZYDEkg== Thread-Topic: [Ecrit] Comments on Framework Draft Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (iPhone Mail 5H11) Date: Thu, 5 Mar 2009 18:44:15 +1100 X-OriginalArrivalTime: 05 Mar 2009 07:44:36.0407 (UTC) FILETIME=[3B4FA470:01C99D66] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 07:59:33 -0000 Gabor, You absolutey and totally wrong about HELD and control-plane. If anything, native HELD is best suited to control-plane location. Indeed in WiMAX it is the only means to invoke control-plane location. Cheers James Sent from my iPhone On 05/03/2009, at 5:07 PM, "Gabor.Bajko@nokia.com" wrote: > Stephen, > > Thanks for pointing out these issues. If you look at the previous > versions of phoneBCP, you'll also see LLDP (which was developed for > fixed environment, like switches) on the list of mandatory LCPs. It > took 2 years (!) to take that out from there, so in that sense there > is some progress towards writing a more realistic set of requirements. > > When it was requested to add SUPPL to the list, or to at least > mention that SUPPL is the one which is currently mostly used for > positioning (what an impertinent request it was to add to a document > intended to describe BEST Current Practices, the protocols which are > currently in use), the argument against it was that SUPPL requires > the existence of a subscription, while the internet is subscription > free. > > Meanwhile people refused to take a look at the applicability of a > DHCP based positioning method in today's world, where everything > tends to be mobile. > > An HTTP based protocol like HELD has the potential to offer solution > for many, but not all of the use cases, as it can deliver location > related measurement information to location servers. The cases when > HELD does not work is when positioning is done using network based > positioning methods involving control plane, like U-TDOA or AFLT. > But then again, these are the positioning technologies which are > currently used in indoor environments where (A-)GPS does not work. > Perhaps this is the reason why they are not mentioned in a Best > Current Practice document ... > > - Gabor > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf Of >> ext Edge, Stephen >> Sent: Wednesday, March 04, 2009 6:20 PM >> To: Stark, Barbara; br@brianrosen.net >> Cc: ECRIT >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Barbara and others >> >> Thanks for the comments. >> >> When I look at the PhoneBCP I see that both HELD and DHCP are >> mandatory >> for the device whereas at least one of these is mandatory for the AN. >> While I can also see that SUPL is not ruled out (though it is not >> mentioned or referenced), it appears to have been displaced by the >> HELD >> and DHCP requirements. On the other hand, many cellular networks have >> already deployed or are in the process of deploying SUPL and I am not >> aware of any that have deployed an accurate location capability using >> HELD or DHCP. So I would like to know how you see the current >> requirements as being suitable - after all, they imply at the very >> least >> additional development and deployment on the part of network and >> device >> vendors and network operators, whereas if SUPL was one of the defined >> LCPs, that additional development and deployment might be mostly >> avoided. >> This question would not be applicable with some additional scope >> limitation and so I had not previously raised it. But it is certainly >> applicable in >> the context of the global scope that is being claimed by some >> responders. >> >> Kind Regards >> >> Stephen >> -----Original Message----- >> From: Stark, Barbara [mailto:bs7652@att.com] >> Sent: Friday, February 27, 2009 8:28 AM >> To: br@brianrosen.net; Edge, Stephen >> Cc: ECRIT >> Subject: RE: [Ecrit] Comments on Framework Draft >> >> Thank you Brian. This is well said [except you left out the fact that >> ecrit also allows for devices to get their location through other >> mechanisms, such as GPS, SUPL, or other methods, and doesn't insist >> that >> the location be configured through DHCP or HELD]. >> >> I agree 100% that additional qualifications are unnecessary. Service >> providers, vendors, national bodies dealing with emergency >> services, and >> regulators aren't stupid. Please trust us to figure out for ourselves >> when/where/how to apply a "standard". There is no need to try to >> artificially limit or define scope, or to state the obvious (e.g., >> the >> architecture applies where it applies, and doesn't apply where it >> doesn't apply). We understand the role and scope of the IETF, and the >> role and scope of 3GPP and 3GPP2. And all the other SDOs (and >> national >> bodies and regulatory agencies). SDOs need to offer architectures >> that >> apply within the area of applicability for that SDO, and are useful >> to >> potential implementers, and leave it to the SPs, national bodies and >> regulators to decide which architectures and standards to use or to >> mandate within the scope of their network or jurisdiction. Again, we >> aren't stupid. >> Barbara >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf >> Of br@brianrosen.net >> Sent: Friday, February 27, 2009 9:53 AM >> To: Edge, Stephen >> Cc: ECRIT >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Stephen >> >> Like any standards organization, the IETF restricts it's scope. >> Generally, the scope is "the Internet", although we very often >> describe >> solutions that are explicitly designed for private IP networks as >> well >> as >> the Internet. We don't write standards for circuit switched >> networks, >> and >> it should be no surprise that the ecrit solution does not cater to CS >> solutions. Nevertheless, we often try to make sure that our >> solutions >> harmonize reasonably well with existing solutions. >> >> Indeed, the ecrit solution clains global applicability to the >> Internet >> in >> general, and most private IP networks that can be interconnected to >> the >> Internet or to other IP networks via gateways. Looking at your >> list of >> problem areas: >>> - access to PSTN capable PSAPs >> This is out of scope for IETF. NENA has active work on this subject. >> It >> seems straightforward to interwork ecrit compatible devices and >> networks >> to existing CS connected PSAPs. As you know, CS interconnects are >> very >> nation-specific, so the NENA work may not have general applicability. >> However, it shows that it is possible to interwork. The NENA i2 >> work is >> also designed to take ecrit compatible devices and VSP networks, and >> interwork them to the existing network. The VSP would direct the >> call >> to >> the VPC, which would provide the services it does now, using the >> device >> provided location for routing. This is important for smooth >> transition >> from existing PSAPs and VSPs to "next generation" PSAPs and VSPs. >>> - handover between different IP access networks including different >>> types of access network >> In the ecrit solution, the access network the call is initiated on >> provides all the facilities needed for the device to initiate an >> emergency >> call. The call starts traversing it's normal call path, and >> eventually >> routes to the ESRP. Handoffs between IP networks should be >> transparent >> to >> this process, although we probably haven't done all the work we >> need to >> do >> for handoffs where the IP address as seen by the terminating network >> changes. This would generally be true of all current SIP based work. >>> - handover to/from circuit mode networks >> This would be out of scope for IETF. It's as applicable to a >> simple SIP >> call as it is a SIP emergency call, and there are no statements in >> any >> SIP >> documents on that subject. >>> - location for cellular access (and the requirement to support LCPs >> that >>> will be useless for cellular access) >> Location for cellular access networks has been considered carefully. >> Since cellular is a mobile network, the access network would pass the >> device a Location-By-Reference URI, using either DHCP or HELD. >> Either >> protocol is suitable for cellular networks. As we have pointed out >> several times, cellular networks support raw data packet services >> upon >> which many different kinds of networks can be constructed. My usual >> example is a large recreational vehicle traveling down a road with a >> cellular data card plugged into a router to which a wired (Ethernet) >> phone >> is connected. That phone must be able to make an emergency call, >> and it >> will get location from DHCP or HELD (or LLDP-MED). It is not aware >> of >> the >> cellular network, and doesn't know any cellular specific protocols. >> Cellular networks will have to support IETF location configuration >> protocols unless they actively prohibit examples like this, or they >> implement interworking between cellular-specific location protocols >> and >> DHCP or HELD in the data card. The ecrit standards permit proxy >> insertion >> of location, but, as above, we don't think that works in all cases. >>> - endpoint based location and routing for cellular access (issues >> here >>> are network and device loading as well as device impacts and >>> problems >>> with PSTN capable PSAPs) >> The "load" of using DHCP or HELD to get location and querying LoST is >> pretty modest. The standards permit proxies to do this if the >> devices >> don't. As above, interwork functions to CS connected PSAPs is very >> feasible, and as above, cellular networks will have to support >> access to >> local LoST servers for devices that are connected to cellular >> networks >> and >> are ecrit compliant. >>> - support of unauthenticated users and users who can be >> authenticated >>> but are not permitted access/VSP service except for emergency calls >> This is covered in the standards. None of the processes are >> dependent >> on >> authentication, although where it is possible, it's desirable so as >> to >> minimize fraudulent emergency calls >> Mechanisms for specific network authentication mechanisms are out of >> scope, and, like SIP basic calling, are not usually mentioned in IETF >> documents. >> >> Stephen, we've tried pretty hard to make sure this works for 3G/4G >> mobile >> networks. It's true that it doesn't do it the way 3GPP currently >> thinks >> it ought to work, but we claim they haven't thought through all the >> issues. While it would work, there are opportunities for >> improvement. >> We >> would be willing to do that if we could get the cooperation of 3GPP, >> which >> we have tried, and failed, to do. >> >> So, I think the documents do not need any qualification statements. >> >> Brian >> >>> Martin >>> >>> The 3GPP/3GPP2 solution has a defined restricted applicability >>> (mainly >> to >>> 3GPP/3GPP2 access networks where the serving network also acts as >>> the >> VSP) >>> and the specifications for it cover in detail all possible scenarios >>> consistent with these restrictions so far as we are aware. >>> >>> The Ecrit solution seems to claim global applicability to all >>> types of >> IP >>> access (and the more that is said about this from Ecrit participants >> the >>> more this gets emphasized) but does not cover in detail all possible >>> scenarios (in some cases does not cover in any detail) which means >> that at >>> best the solution is incomplete and at worst intrinsically >> inapplicable to >>> some unstated set of scenarios. >>> >>> The missing, incomplete and problematic cases include the following: >>> >>> - access to PSTN capable PSAPs >>> - handover between different IP access networks including different >>> types of access network >>> - handover to/from circuit mode networks >>> - location for cellular access (and the requirement to support LCPs >> that >>> will be useless for cellular access) >>> - endpoint based location and routing for cellular access (issues >> here >>> are network and device loading as well as device impacts and >>> problems >>> with PSTN capable PSAPs) >>> - support of unauthenticated users and users who can be >> authenticated >>> but are not permitted access/VSP service except for emergency calls >>> >>> Stating that some of these cases are out of scope or referencing an >>> incomplete and possibly questionable specification from some other >>> national SDO will not help the user who encounters such problems. >>> But >> it >>> would certainly help network operators and implementers to >>> acknowledge >>> their existence in one form or another because that would allow >>> better >>> planning of deployments and would help focus attention on finding >>> solutions (whether in IETF or elsewhere) for the missing cases. >>> >>> Please note that despite these drawbacks, I will acknowledge that >> Ecrit >>> does have a valuable solution that covers many scenarios not covered >> by >>> 3GPP/3GPP2. It would be the delineation of these supported scenarios >> (or >>> equivalently unsupported scenarios) in some applicability statement >> that >>> would be particularly useful right now. >>> >>> Kind Regards >>> >>> Stephen >>> -----Original Message----- >>> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] >>> Sent: Thursday, February 26, 2009 9:45 PM >>> To: Edge, Stephen; Richard Barnes >>> Cc: ECRIT >>> Subject: RE: [Ecrit] Comments on Framework Draft >>> >>> There's benefit in knowing the limitations of a framework, and every >>> architecture makes certain assumptions. Let's examine them >>> though... >>> >>> The IETF might occasionally make the assumption that the standards >>> it >>> develops are for Internet devices. That assumption probably need >>> not >> be >>> stated explicitly. >>> >>> The ECRIT architecture relies on implementations of the protocols >>> that >> it >>> references. That is not extraordinary. A reliance on >>> implementation >> of >>> these protocols by endpoints, routing intermediaries and PSAPs >>> should >> not >>> need to be explained. >>> >>> So the assumptions are: >>> - the Internet >>> - solutions are implemented and deployed >>> - the end device is a key component >>> >>> Only that last element is particularly novel ... or not that much >> really. >>> It's a design choice. Unless you were thinking of trunking the >> voice >>> elsewhere. >>> >>> Of course, you're suggesting that the design choice was made in >> ignorance >>> of all the constraints. You're suggesting that - as a result - the >> choice >>> is flawed and the solution is not going to work for cellular >>> services. >> We >>> disagree. The solution is a basis for emergency calling in _any_ IP >>> network. >>> >>> Cheers, >>> Martin >>> >>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf >>>> Of Edge, Stephen >>>> Sent: Friday, 27 February 2009 3:30 PM >>>> To: Richard Barnes >>>> Cc: 'ECRIT' >>>> Subject: Re: [Ecrit] Comments on Framework Draft >>>> >>>> Hi Richard >>>> >>>> Thanks for the comments. Your statement below that "SIP emergency >>>> calling works if all parties behave as specified in these (IETF >> Ecrit) >>>> documents" to some degree highlights the problems we are raising. >>>> The >>>> documents do contain a number of implicit and explicit >>>> restrictions - >>>> like IP capable PSAPs, global IP access (no islands of circuit mode >>>> access for example), universal support of this solution by all >>>> access >>>> providers and VSPs (not much good if some opt for another solution) >> and >>>> end system oriented location and routing capability - which >>>> together >>>> make them unsuitable (we believe) for cellular wireless networks. >>>> If >>>> these restrictions and assumptions were all made explicit >>>> upfront, it >>>> would to a large degree (and possibly completely) address our >> concerns. >>>> >>>> You are right in assuming another set of specifications for the >>>> 3GPP >>>> and 3GPP2 solution. The applicability of this solution is >>>> explicitly >>>> defined in TS 23.167 (or more exactly in an already agreed CR in >>>> contribution S2-090752 which will become part of 23.167 in a few >>>> more >>>> weeks) to cover the following access types: GPRS (UTRAN WCDMA), >> I-WLAN, >>>> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN >>>> (LTE). So there is a restriction and arbitrary internet access is >>>> not >>>> covered (yet) as I have stated before. >>>> >>>> Kind Regards >>>> >>>> Stephen >>>> -----Original Message----- >>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>> Sent: Wednesday, February 25, 2009 6:30 PM >>>> To: Edge, Stephen >>>> Cc: Brian Rosen; 'ECRIT' >>>> Subject: Re: [Ecrit] Comments on Framework Draft >>>> >>>> Hi Stephen, >>>> >>>> I'm a little confused by the scope of what you're asking. The >>>> framework >>>> and phonebcp documents exist in order to describe the ECRIT >>>> solution: >>>> They say, in effect, "SIP emergency calling works if all parties >> behave >>>> as specified in these documents." >>>> >>>> As I understand what you're saying (and I'm by no means an expert >>>> in >>>> 3GPP), 3GPP specifies that one or more elements of this system >>>> behave >>>> differently. This simply means that 3GPP networks aren't complying >>>> with >>>> these specs. Just like there's no disclaimer in RFC 791 (IPv4) >>>> that >>>> says "this doesn't work on X.25 networks", it's not clear to me >>>> that >> an >>>> analogous disclaimer is called for here. >>>> >>>> I presume there are similar documents describing how emergency >> calling >>>> works in 3GPP networks. Do they include notes saying that the 3GPP >>>> solution doesn't work in the broader Internet? >>>> >>>> --Richard >>>> >>>> >>>> >>>> >>>> >>>> Edge, Stephen wrote: >>>>> Brian >>>>> >>>>> First of all apologies for the likely lateness of this reply - I >>>> actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest >> but >>>> it seems unlikely that my VPN, Outlook server and WiFi access >>>> capability will cooperate together to get it sent until I return to >> the >>>> office mid-next week. >>>>> >>>>> Anyhow thanks for your comments. There have actually been a number >> of >>>> conference calls between IETF and 3GPP participants over the last >>>> couple of years at which common features like support of IP >>>> emergency >>>> calls were discussed and these could have been good forum for >>>> participants on either side to have raised the kinds of issues you >>>> elaborate on below. Given that seems not so far to have happened, >>>> it >>>> could still be possible in future such calls. >>>>> >>>>> But the issues we are raising are not directly to do with further >>>> aligning the 2 solutions or with the lack of this in the past. We >>>> are >>>> simply pointing out that the solutions are currently different and >> that >>>> from a cellular wireless perspective, the Ecrit solution is not >>>> seen >> as >>>> suitable in all respects (for support of IP emergency calls >> originating >>>> from such access types). That is not just our point of view. 3GPP2 >> sent >>>> a liaison to Ecrit some months ago pointing out the same issues. >>>>> >>>>> So we are proposing that the Ecrit framework and phoneBCP spec.s >>>> include a statement acknowledging this - e.g. by referencing the >>>> alternative 3GPP/3GPP2 solution and indicating the IP access types >> for >>>> which the Ecrit solution will work without limitation (or >> equivalently >>>> the access types where limitations are not ruled out). >>>>> >>>>> We are not proposing further modification and extension of the >> Ecrit >>>> solution - just pointing out that this would be needed (as with the >>>> 3GPP/3GPP2 solution) to fully cover all types of access. >>>>> >>>>> Kind Regards >>>>> >>>>> Stephen >>>>> -----Original Message----- >>>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>>> Sent: Wednesday, February 18, 2009 8:07 PM >>>>> To: Edge, Stephen; 'ECRIT' >>>>> Subject: RE: [Ecrit] Comments on Framework Draft >>>>> >>>>> I have bit my tongue on this one for a long time. >>>>> >>>>> Stephen, with respect, please go talk to 3GPP management and ask >> them >>>> why >>>>> there has been no participation in the ecrit effort despite >> multiple >>>> YEARS >>>>> of begging them to get involved. To put it frankly, 3GPP is quite >>>> willing >>>>> to bully IETF into doing its work on its schedule, but cannot be >>>> bothered to >>>>> get work done it knows it will eventually have to do when the IETF >>>> asks it >>>>> to do so. >>>>> >>>>> 3GPP understands the mess that is being created by not >> participating. >>>> They >>>>> know full well that when they finally get around to dealing with >>>>> PS >>>>> terminated emergency calls, that there will be a lot of resistance >> to >>>>> changing fully specified and implemented standards to more closely >>>> align >>>>> with 3GPP standards. I expect you will have several interworking >>>> functions >>>>> to define and build. >>>>> >>>>> So, politely, please go away, we're finishing work we dearly >>>>> wanted >>>> you all >>>>> to be involved with for years, but you refused to do anything. >> It's >>>> too >>>>> late for this rev. >>>>> >>>>> Now, having said that, there are quite a few people who have >>>> participated in >>>>> the IETF work who are IMS aware and I believe that despite your >>>> fears, >>>>> everything you need is in the specs. The mechanisms we have >> defined >>>> provide >>>>> the ability for the network to insert location, recognize and mark >>>> emergency >>>>> calls, and route on behalf of endpoints. An E-CSCF could quite >>>>> straightforwardly provide a SIP call towards an ecrit compatible >>>> PSAP. The >>>>> only not-quite-nice interwork would be from SUPL to HELD (or SIP), >>>> but it's >>>>> pretty easy to do that. I'll also note that we have tried to get >> OMA >>>> and >>>>> IETF to cooperate on location protocols, but we have been >>>> spectacularly >>>>> unsuccessful at that effort also. >>>>> >>>>> Brian >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>> Behalf >>>>>> Of Edge, Stephen >>>>>> Sent: Thursday, February 05, 2009 2:50 AM >>>>>> To: 'ECRIT' >>>>>> Subject: [Ecrit] Comments on Framework Draft >>>>>> >>>>>> All >>>>>> >>>>>> draft-ietf-ecrit-framework-07 is (as we see it) a mostly >> informative >>>>>> description of how terminals and networks should support >>>>>> emergency >>>>>> calls made over IP capable facilities to IP capable PSAPs. It >>>> appears >>>>>> intended to cover all types of access network - including fixed >>>> line, >>>>>> WiFi and cellular (e.g. examples involving each can be found >>>> throughout >>>>>> the draft). >>>>>> >>>>>> When we evaluated this with respect to support of wireless >> cellular >>>>>> access and WiFi access associated with a cellular operator (e.g. >>>> WLAN >>>>>> or Femto cells integrated into a cellular network), we found that >>>>>> certain portions of the draft exhibited one or more of the >> following >>>>>> characteristics: >>>>>> >>>>>> (A) Inconsistent with already standardized wireless solutions >>>>>> >>>>>> (B) Inconsistent with essential wireless requirements and >>>>>> conventions >>>>>> >>>>>> (C) Already part of wireless standards or potentially part of >>>>>> future standards >>>>>> >>>>>> (A) refers to all portions of the draft framework that differ >>>>>> from >>>> the >>>>>> requirements and procedures currently standardized for wireless >>>>>> emergency access by 3GPP, 3GPP2 and OMA. This is a plain >> difference >>>> of >>>>>> solution and could be resolved through support of both solutions >> by >>>>>> terminals (with each solution being used according to the type of >>>>>> access network and VSP) or could be resolved by supporting only >> one >>>>>> solution and accessing only the types of network supporting that >>>>>> solution. To acknowledge this category, the framework document >> could >>>>>> reference the applicable wireless standards and point out that >> these >>>>>> are valid alternatives for wireless cellular based access. >>>>>> >>>>>> (B) refers to portions of the draft that would be unsuitable for >>>>>> wireless networks even if no alternative solution existed >>>>>> together >>>> with >>>>>> other portions missing from the draft that would be needed to >> fully >>>>>> support wireless networks. Examples of the former include: (a) >>>> emphasis >>>>>> on endpoint derivation of location, performance of Lost query and >>>>>> receipt of local dial strings; (b) restriction of LCPs to >> protocols >>>>>> that require terminal initiation (not allowing for network >>>> initiation >>>>>> as far as we can tell) and that include two LCPs (DHCP and LLDP) >>>> that >>>>>> are not applicable to (not defined for) cellular access; and (c) >> the >>>>>> requirement that a terminal or at least a LIS will update the >>>>>> PSAP >>>>>> whenever location changes. (a) is impractical due to network and >>>>>> terminal loading consequences and failure to support non-IP >> capable >>>>>> PSAPs; (b) makes location verification and updated location >>>> provision >>>>>> to PSAPs difficult or impossible; while (c) is also incompatible >>>> with >>>>>> support of existing non-IP capable PSAPs besides increasing >> terminal >>>>>> load and possibly interfering with optimum maintenance of the RF >>>>>> connection (e.g. if a terminal has to tune away from the serving >>>> base >>>>>> station or WLAN periodically to make location measurements). >>>> Examples >>>>>> of the latter include (d) absence of support for access to non-IP >>>>>> capable PSAPs as already mentioned (e.g. to support E911 phase 2 >> in >>>> the >>>>>> US); (e) no support for handover from the IP to the circuit >>>>>> domain >>>> when >>>>>> a terminal loses (e.g. moves out of) RF coverage in the IP >>>>>> domain; >>>> and >>>>>> (f) no allowance for limited access modes wherein a terminal may >>>> access >>>>>> a network only to place an emergency call with ensuing >> restrictions >>>> on >>>>>> (for example) location acquisition, PSAP callback and caller >>>>>> verification and identification to the PSAP. To resolve this >>>> category >>>>>> either significant changes to the framework document could be >>>>>> made >>>> or a >>>>>> disclaimer/applicability statement could be added stating that >>>> support >>>>>> of cellular wireless networks and their associated WLAN and Femto >>>>>> access points is not covered. >>>>>> >>>>>> Category (C) comprises concepts and capabilities in the draft >>>>>> that >>>> are >>>>>> either already part of the standardized solution for wireless >>>> networks >>>>>> or that might be added at a later time. Examples of the former >>>> include >>>>>> LoST, SIP location conveyance, general use of SIP, location for >>>> routing >>>>>> versus for dispatch, cellular positioning methods. Examples of >>>>>> the >>>>>> latter include use of location references and dereferencing and >>>>>> possible interworking between the current wireless network >> solutions >>>>>> (in 3GPP, 3GPP2 and OMA) and the solution described in this >>>>>> draft. >>>> The >>>>>> presence of this category could be acknowledged by following the >>>>>> disclaimer for (B) with a statement that certain portions of the >>>>>> solution are expected to be incorporated into wireless networks >> now >>>>>> and/or in the future. >>>>>> >>>>>> We hope that these comments will be seen to be a useful addition >> to >>>>>> this review in the sense of enabling a more precise scoping for >> the >>>>>> framework document and we are willing to assist in providing >> wording >>>>>> for any disclaimer/applicability statement that the Ecrit working >>>> group >>>>>> may now deem fit to include. >>>>>> >>>>>> Kind Regards >>>>>> >>>>>> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs >>>> (Qualcomm >>>>>> 3GPP2 TSG-X and TSG-C participant) >>>>>> >>>>>> PS this being sent on 2/4/09 at 11:50pm PST >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >> --- >> --------------------------------------------------------------------- >> ------------------------ >>> 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://www.ietf.org/mailman/listinfo/ecrit >>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.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://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.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] From Gabor.Bajko@nokia.com Thu Mar 5 00:25:48 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A312B28C17B for ; Thu, 5 Mar 2009 00:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNqgwCzaq6yK for ; Thu, 5 Mar 2009 00:25:45 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id B9BF83A684D for ; Thu, 5 Mar 2009 00:25:44 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n258Pvrq018310; Thu, 5 Mar 2009 10:25:57 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 10:25:56 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 10:25:56 +0200 Received: from nok-am1mhub-08.mgdnok.nokia.com (65.54.30.15) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 5 Mar 2009 09:25:56 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-08.mgdnok.nokia.com ([65.54.30.15]) with mapi; Thu, 5 Mar 2009 09:25:55 +0100 From: To: Date: Thu, 5 Mar 2009 09:25:53 +0100 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmdZjoOuohgihUhTAGl+xIzZYDEkgABM/qQ Message-ID: References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com> <64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net> <7582BC68E4994F4ABF0BD4723975C3FA0D39534E@crexc41p> <1288E74A73964940B132A0B9EA8D8ABC5374A196@NASANEXMB04.na.qualcomm.com> <96AD1EFB-0104-4B64-A94B-7A1877F8ADC6@andrew.com> In-Reply-To: <96AD1EFB-0104-4B64-A94B-7A1877F8ADC6@andrew.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Mar 2009 08:25:56.0454 (UTC) FILETIME=[0188C860:01C99D6C] X-Nokia-AV: Clean Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 08:25:48 -0000 Oh, I forgot about the abundance of deployed wimax networks. Huge mistake, = indeed. - gabor >-----Original Message----- >From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] >Sent: Wednesday, March 04, 2009 11:44 PM >To: Bajko Gabor (Nokia-CIC/MtView) >Cc: sedge@qualcomm.com; bs7652@att.com; br@brianrosen.net; ecrit@ietf.or= g >Subject: Re: [Ecrit] Comments on Framework Draft > >Gabor, > >You absolutey and totally wrong about HELD and control-plane. If >anything, native HELD is best suited to control-plane location. Indeed >in WiMAX it is the only means to invoke control-plane location. > >Cheers James > >Sent from my iPhone > >On 05/03/2009, at 5:07 PM, "Gabor.Bajko@nokia.com" > wrote: > >> Stephen, >> >> Thanks for pointing out these issues. If you look at the previous >> versions of phoneBCP, you'll also see LLDP (which was developed for >> fixed environment, like switches) on the list of mandatory LCPs. It >> took 2 years (!) to take that out from there, so in that sense there >> is some progress towards writing a more realistic set of requirements. >> >> When it was requested to add SUPPL to the list, or to at least >> mention that SUPPL is the one which is currently mostly used for >> positioning (what an impertinent request it was to add to a document >> intended to describe BEST Current Practices, the protocols which are >> currently in use), the argument against it was that SUPPL requires >> the existence of a subscription, while the internet is subscription >> free. >> >> Meanwhile people refused to take a look at the applicability of a >> DHCP based positioning method in today's world, where everything >> tends to be mobile. >> >> An HTTP based protocol like HELD has the potential to offer solution >> for many, but not all of the use cases, as it can deliver location >> related measurement information to location servers. The cases when >> HELD does not work is when positioning is done using network based >> positioning methods involving control plane, like U-TDOA or AFLT. >> But then again, these are the positioning technologies which are >> currently used in indoor environments where (A-)GPS does not work. >> Perhaps this is the reason why they are not mentioned in a Best >> Current Practice document ... >> >> - Gabor >> >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>> Behalf Of >>> ext Edge, Stephen >>> Sent: Wednesday, March 04, 2009 6:20 PM >>> To: Stark, Barbara; br@brianrosen.net >>> Cc: ECRIT >>> Subject: Re: [Ecrit] Comments on Framework Draft >>> >>> Barbara and others >>> >>> Thanks for the comments. >>> >>> When I look at the PhoneBCP I see that both HELD and DHCP are >>> mandatory >>> for the device whereas at least one of these is mandatory for the AN. >>> While I can also see that SUPL is not ruled out (though it is not >>> mentioned or referenced), it appears to have been displaced by the >>> HELD >>> and DHCP requirements. On the other hand, many cellular networks have >>> already deployed or are in the process of deploying SUPL and I am not >>> aware of any that have deployed an accurate location capability using >>> HELD or DHCP. So I would like to know how you see the current >>> requirements as being suitable - after all, they imply at the very >>> least >>> additional development and deployment on the part of network and >>> device >>> vendors and network operators, whereas if SUPL was one of the defined >>> LCPs, that additional development and deployment might be mostly >>> avoided. >>> This question would not be applicable with some additional scope >>> limitation and so I had not previously raised it. But it is certainly >>> applicable in >>> the context of the global scope that is being claimed by some >>> responders. >>> >>> Kind Regards >>> >>> Stephen >>> -----Original Message----- >>> From: Stark, Barbara [mailto:bs7652@att.com] >>> Sent: Friday, February 27, 2009 8:28 AM >>> To: br@brianrosen.net; Edge, Stephen >>> Cc: ECRIT >>> Subject: RE: [Ecrit] Comments on Framework Draft >>> >>> Thank you Brian. This is well said [except you left out the fact that >>> ecrit also allows for devices to get their location through other >>> mechanisms, such as GPS, SUPL, or other methods, and doesn't insist >>> that >>> the location be configured through DHCP or HELD]. >>> >>> I agree 100% that additional qualifications are unnecessary. Service >>> providers, vendors, national bodies dealing with emergency >>> services, and >>> regulators aren't stupid. Please trust us to figure out for ourselves >>> when/where/how to apply a "standard". There is no need to try to >>> artificially limit or define scope, or to state the obvious (e.g., >>> the >>> architecture applies where it applies, and doesn't apply where it >>> doesn't apply). We understand the role and scope of the IETF, and the >>> role and scope of 3GPP and 3GPP2. And all the other SDOs (and >>> national >>> bodies and regulatory agencies). SDOs need to offer architectures >>> that >>> apply within the area of applicability for that SDO, and are useful >>> to >>> potential implementers, and leave it to the SPs, national bodies and >>> regulators to decide which architectures and standards to use or to >>> mandate within the scope of their network or jurisdiction. Again, we >>> aren't stupid. >>> Barbara >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>> Behalf >>> Of br@brianrosen.net >>> Sent: Friday, February 27, 2009 9:53 AM >>> To: Edge, Stephen >>> Cc: ECRIT >>> Subject: Re: [Ecrit] Comments on Framework Draft >>> >>> Stephen >>> >>> Like any standards organization, the IETF restricts it's scope. >>> Generally, the scope is "the Internet", although we very often >>> describe >>> solutions that are explicitly designed for private IP networks as >>> well >>> as >>> the Internet. We don't write standards for circuit switched >>> networks, >>> and >>> it should be no surprise that the ecrit solution does not cater to CS >>> solutions. Nevertheless, we often try to make sure that our >>> solutions >>> harmonize reasonably well with existing solutions. >>> >>> Indeed, the ecrit solution clains global applicability to the >>> Internet >>> in >>> general, and most private IP networks that can be interconnected to >>> the >>> Internet or to other IP networks via gateways. Looking at your >>> list of >>> problem areas: >>>> - access to PSTN capable PSAPs >>> This is out of scope for IETF. NENA has active work on this subject. >>> It >>> seems straightforward to interwork ecrit compatible devices and >>> networks >>> to existing CS connected PSAPs. As you know, CS interconnects are >>> very >>> nation-specific, so the NENA work may not have general applicability. >>> However, it shows that it is possible to interwork. The NENA i2 >>> work is >>> also designed to take ecrit compatible devices and VSP networks, and >>> interwork them to the existing network. The VSP would direct the >>> call >>> to >>> the VPC, which would provide the services it does now, using the >>> device >>> provided location for routing. This is important for smooth >>> transition >>> from existing PSAPs and VSPs to "next generation" PSAPs and VSPs. >>>> - handover between different IP access networks including different >>>> types of access network >>> In the ecrit solution, the access network the call is initiated on >>> provides all the facilities needed for the device to initiate an >>> emergency >>> call. The call starts traversing it's normal call path, and >>> eventually >>> routes to the ESRP. Handoffs between IP networks should be >>> transparent >>> to >>> this process, although we probably haven't done all the work we >>> need to >>> do >>> for handoffs where the IP address as seen by the terminating network >>> changes. This would generally be true of all current SIP based work. >>>> - handover to/from circuit mode networks >>> This would be out of scope for IETF. It's as applicable to a >>> simple SIP >>> call as it is a SIP emergency call, and there are no statements in >>> any >>> SIP >>> documents on that subject. >>>> - location for cellular access (and the requirement to support LCPs >>> that >>>> will be useless for cellular access) >>> Location for cellular access networks has been considered carefully. >>> Since cellular is a mobile network, the access network would pass the >>> device a Location-By-Reference URI, using either DHCP or HELD. >>> Either >>> protocol is suitable for cellular networks. As we have pointed out >>> several times, cellular networks support raw data packet services >>> upon >>> which many different kinds of networks can be constructed. My usual >>> example is a large recreational vehicle traveling down a road with a >>> cellular data card plugged into a router to which a wired (Ethernet) >>> phone >>> is connected. That phone must be able to make an emergency call, >>> and it >>> will get location from DHCP or HELD (or LLDP-MED). It is not aware >>> of >>> the >>> cellular network, and doesn't know any cellular specific protocols. >>> Cellular networks will have to support IETF location configuration >>> protocols unless they actively prohibit examples like this, or they >>> implement interworking between cellular-specific location protocols >>> and >>> DHCP or HELD in the data card. The ecrit standards permit proxy >>> insertion >>> of location, but, as above, we don't think that works in all cases. >>>> - endpoint based location and routing for cellular access (issues >>> here >>>> are network and device loading as well as device impacts and >>>> problems >>>> with PSTN capable PSAPs) >>> The "load" of using DHCP or HELD to get location and querying LoST is >>> pretty modest. The standards permit proxies to do this if the >>> devices >>> don't. As above, interwork functions to CS connected PSAPs is very >>> feasible, and as above, cellular networks will have to support >>> access to >>> local LoST servers for devices that are connected to cellular >>> networks >>> and >>> are ecrit compliant. >>>> - support of unauthenticated users and users who can be >>> authenticated >>>> but are not permitted access/VSP service except for emergency calls >>> This is covered in the standards. None of the processes are >>> dependent >>> on >>> authentication, although where it is possible, it's desirable so as >>> to >>> minimize fraudulent emergency calls >>> Mechanisms for specific network authentication mechanisms are out of >>> scope, and, like SIP basic calling, are not usually mentioned in IETF >>> documents. >>> >>> Stephen, we've tried pretty hard to make sure this works for 3G/4G >>> mobile >>> networks. It's true that it doesn't do it the way 3GPP currently >>> thinks >>> it ought to work, but we claim they haven't thought through all the >>> issues. While it would work, there are opportunities for >>> improvement. >>> We >>> would be willing to do that if we could get the cooperation of 3GPP, >>> which >>> we have tried, and failed, to do. >>> >>> So, I think the documents do not need any qualification statements. >>> >>> Brian >>> >>>> Martin >>>> >>>> The 3GPP/3GPP2 solution has a defined restricted applicability >>>> (mainly >>> to >>>> 3GPP/3GPP2 access networks where the serving network also acts as >>>> the >>> VSP) >>>> and the specifications for it cover in detail all possible scenarios >>>> consistent with these restrictions so far as we are aware. >>>> >>>> The Ecrit solution seems to claim global applicability to all >>>> types of >>> IP >>>> access (and the more that is said about this from Ecrit participants >>> the >>>> more this gets emphasized) but does not cover in detail all possible >>>> scenarios (in some cases does not cover in any detail) which means >>> that at >>>> best the solution is incomplete and at worst intrinsically >>> inapplicable to >>>> some unstated set of scenarios. >>>> >>>> The missing, incomplete and problematic cases include the following: >>>> >>>> - access to PSTN capable PSAPs >>>> - handover between different IP access networks including different >>>> types of access network >>>> - handover to/from circuit mode networks >>>> - location for cellular access (and the requirement to support LCPs >>> that >>>> will be useless for cellular access) >>>> - endpoint based location and routing for cellular access (issues >>> here >>>> are network and device loading as well as device impacts and >>>> problems >>>> with PSTN capable PSAPs) >>>> - support of unauthenticated users and users who can be >>> authenticated >>>> but are not permitted access/VSP service except for emergency calls >>>> >>>> Stating that some of these cases are out of scope or referencing an >>>> incomplete and possibly questionable specification from some other >>>> national SDO will not help the user who encounters such problems. >>>> But >>> it >>>> would certainly help network operators and implementers to >>>> acknowledge >>>> their existence in one form or another because that would allow >>>> better >>>> planning of deployments and would help focus attention on finding >>>> solutions (whether in IETF or elsewhere) for the missing cases. >>>> >>>> Please note that despite these drawbacks, I will acknowledge that >>> Ecrit >>>> does have a valuable solution that covers many scenarios not covered >>> by >>>> 3GPP/3GPP2. It would be the delineation of these supported scenarios >>> (or >>>> equivalently unsupported scenarios) in some applicability statement >>> that >>>> would be particularly useful right now. >>>> >>>> Kind Regards >>>> >>>> Stephen >>>> -----Original Message----- >>>> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] >>>> Sent: Thursday, February 26, 2009 9:45 PM >>>> To: Edge, Stephen; Richard Barnes >>>> Cc: ECRIT >>>> Subject: RE: [Ecrit] Comments on Framework Draft >>>> >>>> There's benefit in knowing the limitations of a framework, and every >>>> architecture makes certain assumptions. Let's examine them >>>> though... >>>> >>>> The IETF might occasionally make the assumption that the standards >>>> it >>>> develops are for Internet devices. That assumption probably need >>>> not >>> be >>>> stated explicitly. >>>> >>>> The ECRIT architecture relies on implementations of the protocols >>>> that >>> it >>>> references. That is not extraordinary. A reliance on >>>> implementation >>> of >>>> these protocols by endpoints, routing intermediaries and PSAPs >>>> should >>> not >>>> need to be explained. >>>> >>>> So the assumptions are: >>>> - the Internet >>>> - solutions are implemented and deployed >>>> - the end device is a key component >>>> >>>> Only that last element is particularly novel ... or not that much >>> really. >>>> It's a design choice. Unless you were thinking of trunking the >>> voice >>>> elsewhere. >>>> >>>> Of course, you're suggesting that the design choice was made in >>> ignorance >>>> of all the constraints. You're suggesting that - as a result - the >>> choice >>>> is flawed and the solution is not going to work for cellular >>>> services. >>> We >>>> disagree. The solution is a basis for emergency calling in _any_ IP >>>> network. >>>> >>>> Cheers, >>>> Martin >>>> >>>> >>>>> -----Original Message----- >>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>> Behalf >>>>> Of Edge, Stephen >>>>> Sent: Friday, 27 February 2009 3:30 PM >>>>> To: Richard Barnes >>>>> Cc: 'ECRIT' >>>>> Subject: Re: [Ecrit] Comments on Framework Draft >>>>> >>>>> Hi Richard >>>>> >>>>> Thanks for the comments. Your statement below that "SIP emergency >>>>> calling works if all parties behave as specified in these (IETF >>> Ecrit) >>>>> documents" to some degree highlights the problems we are raising. >>>>> The >>>>> documents do contain a number of implicit and explicit >>>>> restrictions - >>>>> like IP capable PSAPs, global IP access (no islands of circuit mode >>>>> access for example), universal support of this solution by all >>>>> access >>>>> providers and VSPs (not much good if some opt for another solution) >>> and >>>>> end system oriented location and routing capability - which >>>>> together >>>>> make them unsuitable (we believe) for cellular wireless networks. >>>>> If >>>>> these restrictions and assumptions were all made explicit >>>>> upfront, it >>>>> would to a large degree (and possibly completely) address our >>> concerns. >>>>> >>>>> You are right in assuming another set of specifications for the >>>>> 3GPP >>>>> and 3GPP2 solution. The applicability of this solution is >>>>> explicitly >>>>> defined in TS 23.167 (or more exactly in an already agreed CR in >>>>> contribution S2-090752 which will become part of 23.167 in a few >>>>> more >>>>> weeks) to cover the following access types: GPRS (UTRAN WCDMA), >>> I-WLAN, >>>>> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN >>>>> (LTE). So there is a restriction and arbitrary internet access is >>>>> not >>>>> covered (yet) as I have stated before. >>>>> >>>>> Kind Regards >>>>> >>>>> Stephen >>>>> -----Original Message----- >>>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>>> Sent: Wednesday, February 25, 2009 6:30 PM >>>>> To: Edge, Stephen >>>>> Cc: Brian Rosen; 'ECRIT' >>>>> Subject: Re: [Ecrit] Comments on Framework Draft >>>>> >>>>> Hi Stephen, >>>>> >>>>> I'm a little confused by the scope of what you're asking. The >>>>> framework >>>>> and phonebcp documents exist in order to describe the ECRIT >>>>> solution: >>>>> They say, in effect, "SIP emergency calling works if all parties >>> behave >>>>> as specified in these documents." >>>>> >>>>> As I understand what you're saying (and I'm by no means an expert >>>>> in >>>>> 3GPP), 3GPP specifies that one or more elements of this system >>>>> behave >>>>> differently. This simply means that 3GPP networks aren't complying >>>>> with >>>>> these specs. Just like there's no disclaimer in RFC 791 (IPv4) >>>>> that >>>>> says "this doesn't work on X.25 networks", it's not clear to me >>>>> that >>> an >>>>> analogous disclaimer is called for here. >>>>> >>>>> I presume there are similar documents describing how emergency >>> calling >>>>> works in 3GPP networks. Do they include notes saying that the 3GPP >>>>> solution doesn't work in the broader Internet? >>>>> >>>>> --Richard >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Edge, Stephen wrote: >>>>>> Brian >>>>>> >>>>>> First of all apologies for the likely lateness of this reply - I >>>>> actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest >>> but >>>>> it seems unlikely that my VPN, Outlook server and WiFi access >>>>> capability will cooperate together to get it sent until I return to >>> the >>>>> office mid-next week. >>>>>> >>>>>> Anyhow thanks for your comments. There have actually been a number >>> of >>>>> conference calls between IETF and 3GPP participants over the last >>>>> couple of years at which common features like support of IP >>>>> emergency >>>>> calls were discussed and these could have been good forum for >>>>> participants on either side to have raised the kinds of issues you >>>>> elaborate on below. Given that seems not so far to have happened, >>>>> it >>>>> could still be possible in future such calls. >>>>>> >>>>>> But the issues we are raising are not directly to do with further >>>>> aligning the 2 solutions or with the lack of this in the past. We >>>>> are >>>>> simply pointing out that the solutions are currently different and >>> that >>>>> from a cellular wireless perspective, the Ecrit solution is not >>>>> seen >>> as >>>>> suitable in all respects (for support of IP emergency calls >>> originating >>>>> from such access types). That is not just our point of view. 3GPP2 >>> sent >>>>> a liaison to Ecrit some months ago pointing out the same issues. >>>>>> >>>>>> So we are proposing that the Ecrit framework and phoneBCP spec.s >>>>> include a statement acknowledging this - e.g. by referencing the >>>>> alternative 3GPP/3GPP2 solution and indicating the IP access types >>> for >>>>> which the Ecrit solution will work without limitation (or >>> equivalently >>>>> the access types where limitations are not ruled out). >>>>>> >>>>>> We are not proposing further modification and extension of the >>> Ecrit >>>>> solution - just pointing out that this would be needed (as with the >>>>> 3GPP/3GPP2 solution) to fully cover all types of access. >>>>>> >>>>>> Kind Regards >>>>>> >>>>>> Stephen >>>>>> -----Original Message----- >>>>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>>>> Sent: Wednesday, February 18, 2009 8:07 PM >>>>>> To: Edge, Stephen; 'ECRIT' >>>>>> Subject: RE: [Ecrit] Comments on Framework Draft >>>>>> >>>>>> I have bit my tongue on this one for a long time. >>>>>> >>>>>> Stephen, with respect, please go talk to 3GPP management and ask >>> them >>>>> why >>>>>> there has been no participation in the ecrit effort despite >>> multiple >>>>> YEARS >>>>>> of begging them to get involved. To put it frankly, 3GPP is quite >>>>> willing >>>>>> to bully IETF into doing its work on its schedule, but cannot be >>>>> bothered to >>>>>> get work done it knows it will eventually have to do when the IETF >>>>> asks it >>>>>> to do so. >>>>>> >>>>>> 3GPP understands the mess that is being created by not >>> participating. >>>>> They >>>>>> know full well that when they finally get around to dealing with >>>>>> PS >>>>>> terminated emergency calls, that there will be a lot of resistance >>> to >>>>>> changing fully specified and implemented standards to more closely >>>>> align >>>>>> with 3GPP standards. I expect you will have several interworking >>>>> functions >>>>>> to define and build. >>>>>> >>>>>> So, politely, please go away, we're finishing work we dearly >>>>>> wanted >>>>> you all >>>>>> to be involved with for years, but you refused to do anything. >>> It's >>>>> too >>>>>> late for this rev. >>>>>> >>>>>> Now, having said that, there are quite a few people who have >>>>> participated in >>>>>> the IETF work who are IMS aware and I believe that despite your >>>>> fears, >>>>>> everything you need is in the specs. The mechanisms we have >>> defined >>>>> provide >>>>>> the ability for the network to insert location, recognize and mark >>>>> emergency >>>>>> calls, and route on behalf of endpoints. An E-CSCF could quite >>>>>> straightforwardly provide a SIP call towards an ecrit compatible >>>>> PSAP. The >>>>>> only not-quite-nice interwork would be from SUPL to HELD (or SIP), >>>>> but it's >>>>>> pretty easy to do that. I'll also note that we have tried to get >>> OMA >>>>> and >>>>>> IETF to cooperate on location protocols, but we have been >>>>> spectacularly >>>>>> unsuccessful at that effort also. >>>>>> >>>>>> Brian >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>>>> Behalf >>>>>>> Of Edge, Stephen >>>>>>> Sent: Thursday, February 05, 2009 2:50 AM >>>>>>> To: 'ECRIT' >>>>>>> Subject: [Ecrit] Comments on Framework Draft >>>>>>> >>>>>>> All >>>>>>> >>>>>>> draft-ietf-ecrit-framework-07 is (as we see it) a mostly >>> informative >>>>>>> description of how terminals and networks should support >>>>>>> emergency >>>>>>> calls made over IP capable facilities to IP capable PSAPs. It >>>>> appears >>>>>>> intended to cover all types of access network - including fixed >>>>> line, >>>>>>> WiFi and cellular (e.g. examples involving each can be found >>>>> throughout >>>>>>> the draft). >>>>>>> >>>>>>> When we evaluated this with respect to support of wireless >>> cellular >>>>>>> access and WiFi access associated with a cellular operator (e.g. >>>>> WLAN >>>>>>> or Femto cells integrated into a cellular network), we found that >>>>>>> certain portions of the draft exhibited one or more of the >>> following >>>>>>> characteristics: >>>>>>> >>>>>>> (A) Inconsistent with already standardized wireless solutions >>>>>>> >>>>>>> (B) Inconsistent with essential wireless requirements and >>>>>>> conventions >>>>>>> >>>>>>> (C) Already part of wireless standards or potentially part of >>>>>>> future standards >>>>>>> >>>>>>> (A) refers to all portions of the draft framework that differ >>>>>>> from >>>>> the >>>>>>> requirements and procedures currently standardized for wireless >>>>>>> emergency access by 3GPP, 3GPP2 and OMA. This is a plain >>> difference >>>>> of >>>>>>> solution and could be resolved through support of both solutions >>> by >>>>>>> terminals (with each solution being used according to the type of >>>>>>> access network and VSP) or could be resolved by supporting only >>> one >>>>>>> solution and accessing only the types of network supporting that >>>>>>> solution. To acknowledge this category, the framework document >>> could >>>>>>> reference the applicable wireless standards and point out that >>> these >>>>>>> are valid alternatives for wireless cellular based access. >>>>>>> >>>>>>> (B) refers to portions of the draft that would be unsuitable for >>>>>>> wireless networks even if no alternative solution existed >>>>>>> together >>>>> with >>>>>>> other portions missing from the draft that would be needed to >>> fully >>>>>>> support wireless networks. Examples of the former include: (a) >>>>> emphasis >>>>>>> on endpoint derivation of location, performance of Lost query and >>>>>>> receipt of local dial strings; (b) restriction of LCPs to >>> protocols >>>>>>> that require terminal initiation (not allowing for network >>>>> initiation >>>>>>> as far as we can tell) and that include two LCPs (DHCP and LLDP) >>>>> that >>>>>>> are not applicable to (not defined for) cellular access; and (c) >>> the >>>>>>> requirement that a terminal or at least a LIS will update the >>>>>>> PSAP >>>>>>> whenever location changes. (a) is impractical due to network and >>>>>>> terminal loading consequences and failure to support non-IP >>> capable >>>>>>> PSAPs; (b) makes location verification and updated location >>>>> provision >>>>>>> to PSAPs difficult or impossible; while (c) is also incompatible >>>>> with >>>>>>> support of existing non-IP capable PSAPs besides increasing >>> terminal >>>>>>> load and possibly interfering with optimum maintenance of the RF >>>>>>> connection (e.g. if a terminal has to tune away from the serving >>>>> base >>>>>>> station or WLAN periodically to make location measurements). >>>>> Examples >>>>>>> of the latter include (d) absence of support for access to non-IP >>>>>>> capable PSAPs as already mentioned (e.g. to support E911 phase 2 >>> in >>>>> the >>>>>>> US); (e) no support for handover from the IP to the circuit >>>>>>> domain >>>>> when >>>>>>> a terminal loses (e.g. moves out of) RF coverage in the IP >>>>>>> domain; >>>>> and >>>>>>> (f) no allowance for limited access modes wherein a terminal may >>>>> access >>>>>>> a network only to place an emergency call with ensuing >>> restrictions >>>>> on >>>>>>> (for example) location acquisition, PSAP callback and caller >>>>>>> verification and identification to the PSAP. To resolve this >>>>> category >>>>>>> either significant changes to the framework document could be >>>>>>> made >>>>> or a >>>>>>> disclaimer/applicability statement could be added stating that >>>>> support >>>>>>> of cellular wireless networks and their associated WLAN and Femto >>>>>>> access points is not covered. >>>>>>> >>>>>>> Category (C) comprises concepts and capabilities in the draft >>>>>>> that >>>>> are >>>>>>> either already part of the standardized solution for wireless >>>>> networks >>>>>>> or that might be added at a later time. Examples of the former >>>>> include >>>>>>> LoST, SIP location conveyance, general use of SIP, location for >>>>> routing >>>>>>> versus for dispatch, cellular positioning methods. Examples of >>>>>>> the >>>>>>> latter include use of location references and dereferencing and >>>>>>> possible interworking between the current wireless network >>> solutions >>>>>>> (in 3GPP, 3GPP2 and OMA) and the solution described in this >>>>>>> draft. >>>>> The >>>>>>> presence of this category could be acknowledged by following the >>>>>>> disclaimer for (B) with a statement that certain portions of the >>>>>>> solution are expected to be incorporated into wireless networks >>> now >>>>>>> and/or in the future. >>>>>>> >>>>>>> We hope that these comments will be seen to be a useful addition >>> to >>>>>>> this review in the sense of enabling a more precise scoping for >>> the >>>>>>> framework document and we are willing to assist in providing >>> wording >>>>>>> for any disclaimer/applicability statement that the Ecrit working >>>>> group >>>>>>> may now deem fit to include. >>>>>>> >>>>>>> Kind Regards >>>>>>> >>>>>>> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs >>>>> (Qualcomm >>>>>>> 3GPP2 TSG-X and TSG-C participant) >>>>>>> >>>>>>> PS this being sent on 2/4/09 at 11:50pm PST >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>> --- >>> --------------------------------------------------------------------- >>> ------------------------ >>>> 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://www.ietf.org/mailman/listinfo/ecrit >>>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.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://www.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.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] From James.Winterbottom@andrew.com Thu Mar 5 01:59:02 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84EC728C324 for ; Thu, 5 Mar 2009 01:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvin9FxVTSBO for ; Thu, 5 Mar 2009 01:59:00 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id A96E73A6974 for ; Thu, 5 Mar 2009 01:58:59 -0800 (PST) X-SEF-Processed: 5_0_0_910__2009_03_05_04_19_11 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 05 Mar 2009 04:19:10 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 03:59:28 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Mar 2009 03:55:09 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmdZjoOuohgihUhTAGl+xIzZYDEkgABM/qQAANbgBk= References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com> <64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net> <7582BC68E4994F4ABF0BD4723975C3FA0D39534E@crexc41p> <1288E74A73964940B132A0B9EA8D8ABC5374A196@NASANEXMB04.na.qualcomm.com> <96AD1EFB-0104-4B64-A94B-7A1877F8ADC6@andrew.com> From: "Winterbottom, James" To: X-OriginalArrivalTime: 05 Mar 2009 09:59:28.0270 (UTC) FILETIME=[126FF2E0:01C99D79] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 09:59:02 -0000 There are certainly more WiMAX networks deployed at this point than LTE net= works... ;P=0D=0A=0D=0ABut that aside, the experimental HELD location netwo= rks we have deployed at the last 3 or so IETF meetings have all been contro= l-plane and not user-plane from a location determination perspective.=0D=0A=0D= =0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A=0D=0A-----Original Message-----=0D=0A= From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]=0D=0ASent: Thu 3= /5/2009 2:25 AM=0D=0ATo: Winterbottom, James=0D=0ACc: sedge@qualcomm.com; b= s7652@att.com; br@brianrosen.net; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] = Comments on Framework Draft=0D=0A=20=0D=0AOh, I forgot about the abundance = of deployed wimax networks. Huge mistake, indeed.=0D=0A=0D=0A- gabor=0D=0A=0D= =0A >-----Original Message-----=0D=0A >From: ext Winterbottom, James [mai= lto:James.Winterbottom@andrew.com]=0D=0A >Sent: Wednesday, March 04, 2009 = 11:44 PM=0D=0A >To: Bajko Gabor (Nokia-CIC/MtView)=0D=0A >Cc: sedge@qualc= omm.com; bs7652@att.com; br@brianrosen.net; ecrit@ietf.org=0D=0A >Subject:= Re: [Ecrit] Comments on Framework Draft=0D=0A >=0D=0A >Gabor,=0D=0A >=0D= =0A >You absolutey and totally wrong about HELD and control-plane. If=0D=0A= >anything, native HELD is best suited to control-plane location. Indeed=0D= =0A >in WiMAX it is the only means to invoke control-plane location.=0D=0A= >=0D=0A >Cheers James=0D=0A >=0D=0A >Sent from my iPhone=0D=0A >=0D=0A= >On 05/03/2009, at 5:07 PM, "Gabor.Bajko@nokia.com" > wrote:=0D=0A >=0D=0A >> Stephen,=0D=0A >>=0D=0A >> Thanks = for pointing out these issues. If you look at the previous=0D=0A >> versio= ns of phoneBCP, you'll also see LLDP (which was developed for=0D=0A >> fix= ed environment, like switches) on the list of mandatory LCPs. It=0D=0A >> = took 2 years (!) to take that out from there, so in that sense there=0D=0A = >> is some progress towards writing a more realistic set of requirements.=0D= =0A >>=0D=0A >> When it was requested to add SUPPL to the list, or to at = least=0D=0A >> mention that SUPPL is the one which is currently mostly use= d for=0D=0A >> positioning (what an impertinent request it was to add to a= document=0D=0A >> intended to describe BEST Current Practices, the protoc= ols which are=0D=0A >> currently in use), the argument against it was that= SUPPL requires=0D=0A >> the existence of a subscription, while the intern= et is subscription=0D=0A >> free.=0D=0A >>=0D=0A >> Meanwhile people ref= used to take a look at the applicability of a=0D=0A >> DHCP based position= ing method in today's world, where everything=0D=0A >> tends to be mobile.=0D= =0A >>=0D=0A >> An HTTP based protocol like HELD has the potential to off= er solution=0D=0A >> for many, but not all of the use cases, as it can del= iver location=0D=0A >> related measurement information to location servers= =2E The cases when=0D=0A >> HELD does not work is when positioning is done= using network based=0D=0A >> positioning methods involving control plane,= like U-TDOA or AFLT.=0D=0A >> But then again, these are the positioning t= echnologies which are=0D=0A >> currently used in indoor environments where= (A-)GPS does not work.=0D=0A >> Perhaps this is the reason why they are n= ot mentioned in a Best=0D=0A >> Current Practice document ...=0D=0A >>=0D= =0A >> - Gabor=0D=0A >>=0D=0A >>=0D=0A >>> -----Original Message-----=0D= =0A >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=0D= =0A >>> Behalf Of=0D=0A >>> ext Edge, Stephen=0D=0A >>> Sent: Wednesday,= March 04, 2009 6:20 PM=0D=0A >>> To: Stark, Barbara; br@brianrosen.net=0D= =0A >>> Cc: ECRIT=0D=0A >>> Subject: Re: [Ecrit] Comments on Framework Dr= aft=0D=0A >>>=0D=0A >>> Barbara and others=0D=0A >>>=0D=0A >>> Thanks f= or the comments.=0D=0A >>>=0D=0A >>> When I look at the PhoneBCP I see th= at both HELD and DHCP are=0D=0A >>> mandatory=0D=0A >>> for the device wh= ereas at least one of these is mandatory for the AN.=0D=0A >>> While I can= also see that SUPL is not ruled out (though it is not=0D=0A >>> mentioned= or referenced), it appears to have been displaced by the=0D=0A >>> HELD=0D= =0A >>> and DHCP requirements. On the other hand, many cellular networks h= ave=0D=0A >>> already deployed or are in the process of deploying SUPL and= I am not=0D=0A >>> aware of any that have deployed an accurate location c= apability using=0D=0A >>> HELD or DHCP. So I would like to know how you se= e the current=0D=0A >>> requirements as being suitable - after all, they i= mply at the very=0D=0A >>> least=0D=0A >>> additional development and dep= loyment on the part of network and=0D=0A >>> device=0D=0A >>> vendors and= network operators, whereas if SUPL was one of the defined=0D=0A >>> LCPs,= that additional development and deployment might be mostly=0D=0A >>> avoi= ded.=0D=0A >>> This question would not be applicable with some additional = scope=0D=0A >>> limitation and so I had not previously raised it. But it i= s certainly=0D=0A >>> applicable in=0D=0A >>> the context of the global s= cope that is being claimed by some=0D=0A >>> responders.=0D=0A >>>=0D=0A = >>> Kind Regards=0D=0A >>>=0D=0A >>> Stephen=0D=0A >>> -----Original Me= ssage-----=0D=0A >>> From: Stark, Barbara [mailto:bs7652@att.com]=0D=0A >= >> Sent: Friday, February 27, 2009 8:28 AM=0D=0A >>> To: br@brianrosen.net= ; Edge, Stephen=0D=0A >>> Cc: ECRIT=0D=0A >>> Subject: RE: [Ecrit] Commen= ts on Framework Draft=0D=0A >>>=0D=0A >>> Thank you Brian. This is well s= aid [except you left out the fact that=0D=0A >>> ecrit also allows for dev= ices to get their location through other=0D=0A >>> mechanisms, such as GPS= , SUPL, or other methods, and doesn't insist=0D=0A >>> that=0D=0A >>> the= location be configured through DHCP or HELD].=0D=0A >>>=0D=0A >>> I agre= e 100% that additional qualifications are unnecessary. Service=0D=0A >>> p= roviders, vendors, national bodies dealing with emergency=0D=0A >>> servic= es, and=0D=0A >>> regulators aren't stupid. Please trust us to figure out = for ourselves=0D=0A >>> when/where/how to apply a "standard". There is no = need to try to=0D=0A >>> artificially limit or define scope, or to state t= he obvious (e.g.,=0D=0A >>> the=0D=0A >>> architecture applies where it a= pplies, and doesn't apply where it=0D=0A >>> doesn't apply). We understand= the role and scope of the IETF, and the=0D=0A >>> role and scope of 3GPP = and 3GPP2. And all the other SDOs (and=0D=0A >>> national=0D=0A >>> bodie= s and regulatory agencies). SDOs need to offer architectures=0D=0A >>> tha= t=0D=0A >>> apply within the area of applicability for that SDO, and are u= seful=0D=0A >>> to=0D=0A >>> potential implementers, and leave it to the = SPs, national bodies and=0D=0A >>> regulators to decide which architecture= s and standards to use or to=0D=0A >>> mandate within the scope of their n= etwork or jurisdiction. Again, we=0D=0A >>> aren't stupid.=0D=0A >>> Barb= ara=0D=0A >>>=0D=0A >>> -----Original Message-----=0D=0A >>> From: ecrit= -bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=0D=0A >>> Behalf=0D=0A= >>> Of br@brianrosen.net=0D=0A >>> Sent: Friday, February 27, 2009 9:53 = AM=0D=0A >>> To: Edge, Stephen=0D=0A >>> Cc: ECRIT=0D=0A >>> Subject: Re= : [Ecrit] Comments on Framework Draft=0D=0A >>>=0D=0A >>> Stephen=0D=0A = >>>=0D=0A >>> Like any standards organization, the IETF restricts it's sco= pe.=0D=0A >>> Generally, the scope is "the Internet", although we very oft= en=0D=0A >>> describe=0D=0A >>> solutions that are explicitly designed fo= r private IP networks as=0D=0A >>> well=0D=0A >>> as=0D=0A >>> the Inter= net. We don't write standards for circuit switched=0D=0A >>> networks,=0D= =0A >>> and=0D=0A >>> it should be no surprise that the ecrit solution do= es not cater to CS=0D=0A >>> solutions. Nevertheless, we often try to mak= e sure that our=0D=0A >>> solutions=0D=0A >>> harmonize reasonably well w= ith existing solutions.=0D=0A >>>=0D=0A >>> Indeed, the ecrit solution cl= ains global applicability to the=0D=0A >>> Internet=0D=0A >>> in=0D=0A >= >> general, and most private IP networks that can be interconnected to=0D=0A= >>> the=0D=0A >>> Internet or to other IP networks via gateways. Lookin= g at your=0D=0A >>> list of=0D=0A >>> problem areas:=0D=0A >>>> - acces= s to PSTN capable PSAPs=0D=0A >>> This is out of scope for IETF. NENA has= active work on this subject.=0D=0A >>> It=0D=0A >>> seems straightforwar= d to interwork ecrit compatible devices and=0D=0A >>> networks=0D=0A >>> = to existing CS connected PSAPs. As you know, CS interconnects are=0D=0A >= >> very=0D=0A >>> nation-specific, so the NENA work may not have general a= pplicability.=0D=0A >>> However, it shows that it is possible to interwork= =2E The NENA i2=0D=0A >>> work is=0D=0A >>> also designed to take ecrit = compatible devices and VSP networks, and=0D=0A >>> interwork them to the e= xisting network. The VSP would direct the=0D=0A >>> call=0D=0A >>> to=0D= =0A >>> the VPC, which would provide the services it does now, using the=0D= =0A >>> device=0D=0A >>> provided location for routing. This is importan= t for smooth=0D=0A >>> transition=0D=0A >>> from existing PSAPs and VSPs = to "next generation" PSAPs and VSPs.=0D=0A >>>> - handover between differ= ent IP access networks including different=0D=0A >>>> types of access netw= ork=0D=0A >>> In the ecrit solution, the access network the call is initia= ted on=0D=0A >>> provides all the facilities needed for the device to init= iate an=0D=0A >>> emergency=0D=0A >>> call. The call starts traversing = it's normal call path, and=0D=0A >>> eventually=0D=0A >>> routes to the E= SRP. Handoffs between IP networks should be=0D=0A >>> transparent=0D=0A = >>> to=0D=0A >>> this process, although we probably haven't done all the w= ork we=0D=0A >>> need to=0D=0A >>> do=0D=0A >>> for handoffs where the I= P address as seen by the terminating network=0D=0A >>> changes. This woul= d generally be true of all current SIP based work.=0D=0A >>>> - handover = to/from circuit mode networks=0D=0A >>> This would be out of scope for IET= F. It's as applicable to a=0D=0A >>> simple SIP=0D=0A >>> call as it is = a SIP emergency call, and there are no statements in=0D=0A >>> any=0D=0A = >>> SIP=0D=0A >>> documents on that subject.=0D=0A >>>> - location for c= ellular access (and the requirement to support LCPs=0D=0A >>> that=0D=0A = >>>> will be useless for cellular access)=0D=0A >>> Location for cellular = access networks has been considered carefully.=0D=0A >>> Since cellular is= a mobile network, the access network would pass the=0D=0A >>> device a Lo= cation-By-Reference URI, using either DHCP or HELD.=0D=0A >>> Either=0D=0A= >>> protocol is suitable for cellular networks. As we have pointed out=0D= =0A >>> several times, cellular networks support raw data packet services=0D= =0A >>> upon=0D=0A >>> which many different kinds of networks can be cons= tructed. My usual=0D=0A >>> example is a large recreational vehicle trave= ling down a road with a=0D=0A >>> cellular data card plugged into a router= to which a wired (Ethernet)=0D=0A >>> phone=0D=0A >>> is connected. Tha= t phone must be able to make an emergency call,=0D=0A >>> and it=0D=0A >>= > will get location from DHCP or HELD (or LLDP-MED). It is not aware=0D=0A= >>> of=0D=0A >>> the=0D=0A >>> cellular network, and doesn't know any c= ellular specific protocols.=0D=0A >>> Cellular networks will have to suppo= rt IETF location configuration=0D=0A >>> protocols unless they actively pr= ohibit examples like this, or they=0D=0A >>> implement interworking betwee= n cellular-specific location protocols=0D=0A >>> and=0D=0A >>> DHCP or HE= LD in the data card. The ecrit standards permit proxy=0D=0A >>> insertion=0D= =0A >>> of location, but, as above, we don't think that works in all cases= =2E=0D=0A >>>> - endpoint based location and routing for cellular access = (issues=0D=0A >>> here=0D=0A >>>> are network and device loading as well = as device impacts and=0D=0A >>>> problems=0D=0A >>>> with PSTN capable PS= APs)=0D=0A >>> The "load" of using DHCP or HELD to get location and queryi= ng LoST is=0D=0A >>> pretty modest. The standards permit proxies to do th= is if the=0D=0A >>> devices=0D=0A >>> don't. As above, interwork functio= ns to CS connected PSAPs is very=0D=0A >>> feasible, and as above, cellula= r networks will have to support=0D=0A >>> access to=0D=0A >>> local LoST = servers for devices that are connected to cellular=0D=0A >>> networks=0D=0A= >>> and=0D=0A >>> are ecrit compliant.=0D=0A >>>> - support of unauthe= nticated users and users who can be=0D=0A >>> authenticated=0D=0A >>>> bu= t are not permitted access/VSP service except for emergency calls=0D=0A >>= > This is covered in the standards. None of the processes are=0D=0A >>> d= ependent=0D=0A >>> on=0D=0A >>> authentication, although where it is poss= ible, it's desirable so as=0D=0A >>> to=0D=0A >>> minimize fraudulent eme= rgency calls=0D=0A >>> Mechanisms for specific network authentication mech= anisms are out of=0D=0A >>> scope, and, like SIP basic calling, are not us= ually mentioned in IETF=0D=0A >>> documents.=0D=0A >>>=0D=0A >>> Stephen= , we've tried pretty hard to make sure this works for 3G/4G=0D=0A >>> mobi= le=0D=0A >>> networks. It's true that it doesn't do it the way 3GPP curre= ntly=0D=0A >>> thinks=0D=0A >>> it ought to work, but we claim they haven= 't thought through all the=0D=0A >>> issues. While it would work, there a= re opportunities for=0D=0A >>> improvement.=0D=0A >>> We=0D=0A >>> would= be willing to do that if we could get the cooperation of 3GPP,=0D=0A >>> = which=0D=0A >>> we have tried, and failed, to do.=0D=0A >>>=0D=0A >>> So= , I think the documents do not need any qualification statements.=0D=0A >>= >=0D=0A >>> Brian=0D=0A >>>=0D=0A >>>> Martin=0D=0A >>>>=0D=0A >>>> Th= e 3GPP/3GPP2 solution has a defined restricted applicability=0D=0A >>>> (m= ainly=0D=0A >>> to=0D=0A >>>> 3GPP/3GPP2 access networks where the servin= g network also acts as=0D=0A >>>> the=0D=0A >>> VSP)=0D=0A >>>> and the = specifications for it cover in detail all possible scenarios=0D=0A >>>> co= nsistent with these restrictions so far as we are aware.=0D=0A >>>>=0D=0A = >>>> The Ecrit solution seems to claim global applicability to all=0D=0A = >>>> types of=0D=0A >>> IP=0D=0A >>>> access (and the more that is said a= bout this from Ecrit participants=0D=0A >>> the=0D=0A >>>> more this gets= emphasized) but does not cover in detail all possible=0D=0A >>>> scenario= s (in some cases does not cover in any detail) which means=0D=0A >>> that = at=0D=0A >>>> best the solution is incomplete and at worst intrinsically=0D= =0A >>> inapplicable to=0D=0A >>>> some unstated set of scenarios.=0D=0A = >>>>=0D=0A >>>> The missing, incomplete and problematic cases include the= following:=0D=0A >>>>=0D=0A >>>> - access to PSTN capable PSAPs=0D=0A = >>>> - handover between different IP access networks including different=0D= =0A >>>> types of access network=0D=0A >>>> - handover to/from circuit m= ode networks=0D=0A >>>> - location for cellular access (and the requireme= nt to support LCPs=0D=0A >>> that=0D=0A >>>> will be useless for cellular= access)=0D=0A >>>> - endpoint based location and routing for cellular ac= cess (issues=0D=0A >>> here=0D=0A >>>> are network and device loading as = well as device impacts and=0D=0A >>>> problems=0D=0A >>>> with PSTN capab= le PSAPs)=0D=0A >>>> - support of unauthenticated users and users who can= be=0D=0A >>> authenticated=0D=0A >>>> but are not permitted access/VSP s= ervice except for emergency calls=0D=0A >>>>=0D=0A >>>> Stating that some= of these cases are out of scope or referencing an=0D=0A >>>> incomplete a= nd possibly questionable specification from some other=0D=0A >>>> national= SDO will not help the user who encounters such problems.=0D=0A >>>> But=0D= =0A >>> it=0D=0A >>>> would certainly help network operators and implemen= ters to=0D=0A >>>> acknowledge=0D=0A >>>> their existence in one form or = another because that would allow=0D=0A >>>> better=0D=0A >>>> planning of= deployments and would help focus attention on finding=0D=0A >>>> solution= s (whether in IETF or elsewhere) for the missing cases.=0D=0A >>>>=0D=0A = >>>> Please note that despite these drawbacks, I will acknowledge that=0D=0A= >>> Ecrit=0D=0A >>>> does have a valuable solution that covers many scen= arios not covered=0D=0A >>> by=0D=0A >>>> 3GPP/3GPP2. It would be the del= ineation of these supported scenarios=0D=0A >>> (or=0D=0A >>>> equivalent= ly unsupported scenarios) in some applicability statement=0D=0A >>> that=0D= =0A >>>> would be particularly useful right now.=0D=0A >>>>=0D=0A >>>> K= ind Regards=0D=0A >>>>=0D=0A >>>> Stephen=0D=0A >>>> -----Original Messa= ge-----=0D=0A >>>> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com= ]=0D=0A >>>> Sent: Thursday, February 26, 2009 9:45 PM=0D=0A >>>> To: Edg= e, Stephen; Richard Barnes=0D=0A >>>> Cc: ECRIT=0D=0A >>>> Subject: RE: [= Ecrit] Comments on Framework Draft=0D=0A >>>>=0D=0A >>>> There's benefit = in knowing the limitations of a framework, and every=0D=0A >>>> architectu= re makes certain assumptions. Let's examine them=0D=0A >>>> though...=0D=0A= >>>>=0D=0A >>>> The IETF might occasionally make the assumption that the= standards=0D=0A >>>> it=0D=0A >>>> develops are for Internet devices. T= hat assumption probably need=0D=0A >>>> not=0D=0A >>> be=0D=0A >>>> stat= ed explicitly.=0D=0A >>>>=0D=0A >>>> The ECRIT architecture relies on imp= lementations of the protocols=0D=0A >>>> that=0D=0A >>> it=0D=0A >>>> re= ferences. That is not extraordinary. A reliance on=0D=0A >>>> implementa= tion=0D=0A >>> of=0D=0A >>>> these protocols by endpoints, routing interm= ediaries and PSAPs=0D=0A >>>> should=0D=0A >>> not=0D=0A >>>> need to be= explained.=0D=0A >>>>=0D=0A >>>> So the assumptions are:=0D=0A >>>> - t= he Internet=0D=0A >>>> - solutions are implemented and deployed=0D=0A >>>= > - the end device is a key component=0D=0A >>>>=0D=0A >>>> Only that las= t element is particularly novel ... or not that much=0D=0A >>> really.=0D=0A= >>>> It's a design choice. Unless you were thinking of trunking the=0D=0A= >>> voice=0D=0A >>>> elsewhere.=0D=0A >>>>=0D=0A >>>> Of course, you'r= e suggesting that the design choice was made in=0D=0A >>> ignorance=0D=0A = >>>> of all the constraints. You're suggesting that - as a result - the=0D= =0A >>> choice=0D=0A >>>> is flawed and the solution is not going to work= for cellular=0D=0A >>>> services.=0D=0A >>> We=0D=0A >>>> disagree. Th= e solution is a basis for emergency calling in _any_ IP=0D=0A >>>> network= =2E=0D=0A >>>>=0D=0A >>>> Cheers,=0D=0A >>>> Martin=0D=0A >>>>=0D=0A >= >>>=0D=0A >>>>> -----Original Message-----=0D=0A >>>>> From: ecrit-bounce= s@ietf.org [mailto:ecrit-bounces@ietf.org] On=0D=0A >>> Behalf=0D=0A >>>>= > Of Edge, Stephen=0D=0A >>>>> Sent: Friday, 27 February 2009 3:30 PM=0D=0A= >>>>> To: Richard Barnes=0D=0A >>>>> Cc: 'ECRIT'=0D=0A >>>>> Subject: R= e: [Ecrit] Comments on Framework Draft=0D=0A >>>>>=0D=0A >>>>> Hi Richard=0D= =0A >>>>>=0D=0A >>>>> Thanks for the comments. Your statement below that = "SIP emergency=0D=0A >>>>> calling works if all parties behave as specifie= d in these (IETF=0D=0A >>> Ecrit)=0D=0A >>>>> documents" to some degree h= ighlights the problems we are raising.=0D=0A >>>>> The=0D=0A >>>>> docume= nts do contain a number of implicit and explicit=0D=0A >>>>> restrictions = -=0D=0A >>>>> like IP capable PSAPs, global IP access (no islands of circu= it mode=0D=0A >>>>> access for example), universal support of this solutio= n by all=0D=0A >>>>> access=0D=0A >>>>> providers and VSPs (not much good= if some opt for another solution)=0D=0A >>> and=0D=0A >>>>> end system o= riented location and routing capability - which=0D=0A >>>>> together=0D=0A= >>>>> make them unsuitable (we believe) for cellular wireless networks.=0D= =0A >>>>> If=0D=0A >>>>> these restrictions and assumptions were all made= explicit=0D=0A >>>>> upfront, it=0D=0A >>>>> would to a large degree (an= d possibly completely) address our=0D=0A >>> concerns.=0D=0A >>>>>=0D=0A = >>>>> You are right in assuming another set of specifications for the=0D=0A= >>>>> 3GPP=0D=0A >>>>> and 3GPP2 solution. The applicability of this sol= ution is=0D=0A >>>>> explicitly=0D=0A >>>>> defined in TS 23.167 (or more= exactly in an already agreed CR in=0D=0A >>>>> contribution S2-090752 whi= ch will become part of 23.167 in a few=0D=0A >>>>> more=0D=0A >>>>> weeks= ) to cover the following access types: GPRS (UTRAN WCDMA),=0D=0A >>> I-WLA= N,=0D=0A >>>>> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E= -UTRAN=0D=0A >>>>> (LTE). So there is a restriction and arbitrary internet= access is=0D=0A >>>>> not=0D=0A >>>>> covered (yet) as I have stated bef= ore.=0D=0A >>>>>=0D=0A >>>>> Kind Regards=0D=0A >>>>>=0D=0A >>>>> Steph= en=0D=0A >>>>> -----Original Message-----=0D=0A >>>>> From: Richard Barne= s [mailto:rbarnes@bbn.com]=0D=0A >>>>> Sent: Wednesday, February 25, 2009 = 6:30 PM=0D=0A >>>>> To: Edge, Stephen=0D=0A >>>>> Cc: Brian Rosen; 'ECRIT= '=0D=0A >>>>> Subject: Re: [Ecrit] Comments on Framework Draft=0D=0A >>>>= >=0D=0A >>>>> Hi Stephen,=0D=0A >>>>>=0D=0A >>>>> I'm a little confused = by the scope of what you're asking. The=0D=0A >>>>> framework=0D=0A >>>>= > and phonebcp documents exist in order to describe the ECRIT=0D=0A >>>>> = solution:=0D=0A >>>>> They say, in effect, "SIP emergency calling works if= all parties=0D=0A >>> behave=0D=0A >>>>> as specified in these documents= =2E"=0D=0A >>>>>=0D=0A >>>>> As I understand what you're saying (and I'm = by no means an expert=0D=0A >>>>> in=0D=0A >>>>> 3GPP), 3GPP specifies th= at one or more elements of this system=0D=0A >>>>> behave=0D=0A >>>>> dif= ferently. This simply means that 3GPP networks aren't complying=0D=0A >>>= >> with=0D=0A >>>>> these specs. Just like there's no disclaimer in RFC 7= 91 (IPv4)=0D=0A >>>>> that=0D=0A >>>>> says "this doesn't work on X.25 ne= tworks", it's not clear to me=0D=0A >>>>> that=0D=0A >>> an=0D=0A >>>>> = analogous disclaimer is called for here.=0D=0A >>>>>=0D=0A >>>>> I presum= e there are similar documents describing how emergency=0D=0A >>> calling=0D= =0A >>>>> works in 3GPP networks. Do they include notes saying that the 3= GPP=0D=0A >>>>> solution doesn't work in the broader Internet=3F=0D=0A >>= >>>=0D=0A >>>>> --Richard=0D=0A >>>>>=0D=0A >>>>>=0D=0A >>>>>=0D=0A >>= >>>=0D=0A >>>>>=0D=0A >>>>> Edge, Stephen wrote:=0D=0A >>>>>> Brian=0D=0A= >>>>>>=0D=0A >>>>>> First of all apologies for the likely lateness of th= is reply - I=0D=0A >>>>> actually wrote it on 19 February in a 3GPP SA2 me= eting in Budapest=0D=0A >>> but=0D=0A >>>>> it seems unlikely that my VPN= , Outlook server and WiFi access=0D=0A >>>>> capability will cooperate tog= ether to get it sent until I return to=0D=0A >>> the=0D=0A >>>>> office m= id-next week.=0D=0A >>>>>>=0D=0A >>>>>> Anyhow thanks for your comments. = There have actually been a number=0D=0A >>> of=0D=0A >>>>> conference cal= ls between IETF and 3GPP participants over the last=0D=0A >>>>> couple of = years at which common features like support of IP=0D=0A >>>>> emergency=0D= =0A >>>>> calls were discussed and these could have been good forum for=0D= =0A >>>>> participants on either side to have raised the kinds of issues y= ou=0D=0A >>>>> elaborate on below. Given that seems not so far to have hap= pened,=0D=0A >>>>> it=0D=0A >>>>> could still be possible in future such = calls.=0D=0A >>>>>>=0D=0A >>>>>> But the issues we are raising are not di= rectly to do with further=0D=0A >>>>> aligning the 2 solutions or with the= lack of this in the past. We=0D=0A >>>>> are=0D=0A >>>>> simply pointing= out that the solutions are currently different and=0D=0A >>> that=0D=0A = >>>>> from a cellular wireless perspective, the Ecrit solution is not=0D=0A= >>>>> seen=0D=0A >>> as=0D=0A >>>>> suitable in all respects (for suppo= rt of IP emergency calls=0D=0A >>> originating=0D=0A >>>>> from such acce= ss types). That is not just our point of view. 3GPP2=0D=0A >>> sent=0D=0A = >>>>> a liaison to Ecrit some months ago pointing out the same issues.=0D=0A= >>>>>>=0D=0A >>>>>> So we are proposing that the Ecrit framework and pho= neBCP spec.s=0D=0A >>>>> include a statement acknowledging this - e.g. by = referencing the=0D=0A >>>>> alternative 3GPP/3GPP2 solution and indicating= the IP access types=0D=0A >>> for=0D=0A >>>>> which the Ecrit solution w= ill work without limitation (or=0D=0A >>> equivalently=0D=0A >>>>> the ac= cess types where limitations are not ruled out).=0D=0A >>>>>>=0D=0A >>>>>= > We are not proposing further modification and extension of the=0D=0A >>>= Ecrit=0D=0A >>>>> solution - just pointing out that this would be needed = (as with the=0D=0A >>>>> 3GPP/3GPP2 solution) to fully cover all types of = access.=0D=0A >>>>>>=0D=0A >>>>>> Kind Regards=0D=0A >>>>>>=0D=0A >>>>>= > Stephen=0D=0A >>>>>> -----Original Message-----=0D=0A >>>>>> From: Bria= n Rosen [mailto:br@brianrosen.net]=0D=0A >>>>>> Sent: Wednesday, February = 18, 2009 8:07 PM=0D=0A >>>>>> To: Edge, Stephen; 'ECRIT'=0D=0A >>>>>> Sub= ject: RE: [Ecrit] Comments on Framework Draft=0D=0A >>>>>>=0D=0A >>>>>> I= have bit my tongue on this one for a long time.=0D=0A >>>>>>=0D=0A >>>>>= > Stephen, with respect, please go talk to 3GPP management and ask=0D=0A >= >> them=0D=0A >>>>> why=0D=0A >>>>>> there has been no participation in t= he ecrit effort despite=0D=0A >>> multiple=0D=0A >>>>> YEARS=0D=0A >>>>>= > of begging them to get involved. To put it frankly, 3GPP is quite=0D=0A = >>>>> willing=0D=0A >>>>>> to bully IETF into doing its work on its sched= ule, but cannot be=0D=0A >>>>> bothered to=0D=0A >>>>>> get work done it = knows it will eventually have to do when the IETF=0D=0A >>>>> asks it=0D=0A= >>>>>> to do so.=0D=0A >>>>>>=0D=0A >>>>>> 3GPP understands the mess th= at is being created by not=0D=0A >>> participating.=0D=0A >>>>> They=0D=0A= >>>>>> know full well that when they finally get around to dealing with=0D= =0A >>>>>> PS=0D=0A >>>>>> terminated emergency calls, that there will be= a lot of resistance=0D=0A >>> to=0D=0A >>>>>> changing fully specified a= nd implemented standards to more closely=0D=0A >>>>> align=0D=0A >>>>>> w= ith 3GPP standards. I expect you will have several interworking=0D=0A >>>= >> functions=0D=0A >>>>>> to define and build.=0D=0A >>>>>>=0D=0A >>>>>>= So, politely, please go away, we're finishing work we dearly=0D=0A >>>>>>= wanted=0D=0A >>>>> you all=0D=0A >>>>>> to be involved with for years, b= ut you refused to do anything.=0D=0A >>> It's=0D=0A >>>>> too=0D=0A >>>>= >> late for this rev.=0D=0A >>>>>>=0D=0A >>>>>> Now, having said that, th= ere are quite a few people who have=0D=0A >>>>> participated in=0D=0A >>>= >>> the IETF work who are IMS aware and I believe that despite your=0D=0A = >>>>> fears,=0D=0A >>>>>> everything you need is in the specs. The mechan= isms we have=0D=0A >>> defined=0D=0A >>>>> provide=0D=0A >>>>>> the abil= ity for the network to insert location, recognize and mark=0D=0A >>>>> eme= rgency=0D=0A >>>>>> calls, and route on behalf of endpoints. An E-CSCF co= uld quite=0D=0A >>>>>> straightforwardly provide a SIP call towards an ecr= it compatible=0D=0A >>>>> PSAP. The=0D=0A >>>>>> only not-quite-nice int= erwork would be from SUPL to HELD (or SIP),=0D=0A >>>>> but it's=0D=0A >>= >>>> pretty easy to do that. I'll also note that we have tried to get=0D=0A= >>> OMA=0D=0A >>>>> and=0D=0A >>>>>> IETF to cooperate on location prot= ocols, but we have been=0D=0A >>>>> spectacularly=0D=0A >>>>>> unsuccessf= ul at that effort also.=0D=0A >>>>>>=0D=0A >>>>>> Brian=0D=0A >>>>>>=0D=0A= >>>>>>=0D=0A >>>>>>=0D=0A >>>>>>> -----Original Message-----=0D=0A >>>= >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=0D=0A = >>>>> Behalf=0D=0A >>>>>>> Of Edge, Stephen=0D=0A >>>>>>> Sent: Thursday= , February 05, 2009 2:50 AM=0D=0A >>>>>>> To: 'ECRIT'=0D=0A >>>>>>> Subje= ct: [Ecrit] Comments on Framework Draft=0D=0A >>>>>>>=0D=0A >>>>>>> All=0D= =0A >>>>>>>=0D=0A >>>>>>> draft-ietf-ecrit-framework-07 is (as we see it)= a mostly=0D=0A >>> informative=0D=0A >>>>>>> description of how terminal= s and networks should support=0D=0A >>>>>>> emergency=0D=0A >>>>>>> calls= made over IP capable facilities to IP capable PSAPs. It=0D=0A >>>>> appea= rs=0D=0A >>>>>>> intended to cover all types of access network - including= fixed=0D=0A >>>>> line,=0D=0A >>>>>>> WiFi and cellular (e.g. examples i= nvolving each can be found=0D=0A >>>>> throughout=0D=0A >>>>>>> the draft= ).=0D=0A >>>>>>>=0D=0A >>>>>>> When we evaluated this with respect to sup= port of wireless=0D=0A >>> cellular=0D=0A >>>>>>> access and WiFi access = associated with a cellular operator (e.g.=0D=0A >>>>> WLAN=0D=0A >>>>>>> = or Femto cells integrated into a cellular network), we found that=0D=0A >>= >>>>> certain portions of the draft exhibited one or more of the=0D=0A >>>= following=0D=0A >>>>>>> characteristics:=0D=0A >>>>>>>=0D=0A >>>>>>> = (A) Inconsistent with already standardized wireless solutions=0D=0A >>>>>= >>=0D=0A >>>>>>> (B) Inconsistent with essential wireless requirements = and=0D=0A >>>>>>> conventions=0D=0A >>>>>>>=0D=0A >>>>>>> (C) Already= part of wireless standards or potentially part of=0D=0A >>>>>>> future st= andards=0D=0A >>>>>>>=0D=0A >>>>>>> (A) refers to all portions of the dra= ft framework that differ=0D=0A >>>>>>> from=0D=0A >>>>> the=0D=0A >>>>>>= > requirements and procedures currently standardized for wireless=0D=0A >>= >>>>> emergency access by 3GPP, 3GPP2 and OMA. This is a plain=0D=0A >>> d= ifference=0D=0A >>>>> of=0D=0A >>>>>>> solution and could be resolved thr= ough support of both solutions=0D=0A >>> by=0D=0A >>>>>>> terminals (with= each solution being used according to the type of=0D=0A >>>>>>> access ne= twork and VSP) or could be resolved by supporting only=0D=0A >>> one=0D=0A= >>>>>>> solution and accessing only the types of network supporting that=0D= =0A >>>>>>> solution. To acknowledge this category, the framework document=0D= =0A >>> could=0D=0A >>>>>>> reference the applicable wireless standards a= nd point out that=0D=0A >>> these=0D=0A >>>>>>> are valid alternatives fo= r wireless cellular based access.=0D=0A >>>>>>>=0D=0A >>>>>>> (B) refers = to portions of the draft that would be unsuitable for=0D=0A >>>>>>> wirele= ss networks even if no alternative solution existed=0D=0A >>>>>>> together=0D= =0A >>>>> with=0D=0A >>>>>>> other portions missing from the draft that w= ould be needed to=0D=0A >>> fully=0D=0A >>>>>>> support wireless networks= =2E Examples of the former include: (a)=0D=0A >>>>> emphasis=0D=0A >>>>>>= > on endpoint derivation of location, performance of Lost query and=0D=0A = >>>>>>> receipt of local dial strings; (b) restriction of LCPs to=0D=0A >>= > protocols=0D=0A >>>>>>> that require terminal initiation (not allowing f= or network=0D=0A >>>>> initiation=0D=0A >>>>>>> as far as we can tell) an= d that include two LCPs (DHCP and LLDP)=0D=0A >>>>> that=0D=0A >>>>>>> ar= e not applicable to (not defined for) cellular access; and (c)=0D=0A >>> t= he=0D=0A >>>>>>> requirement that a terminal or at least a LIS will update= the=0D=0A >>>>>>> PSAP=0D=0A >>>>>>> whenever location changes. (a) is i= mpractical due to network and=0D=0A >>>>>>> terminal loading consequences = and failure to support non-IP=0D=0A >>> capable=0D=0A >>>>>>> PSAPs; (b) = makes location verification and updated location=0D=0A >>>>> provision=0D=0A= >>>>>>> to PSAPs difficult or impossible; while (c) is also incompatible=0D= =0A >>>>> with=0D=0A >>>>>>> support of existing non-IP capable PSAPs bes= ides increasing=0D=0A >>> terminal=0D=0A >>>>>>> load and possibly interf= ering with optimum maintenance of the RF=0D=0A >>>>>>> connection (e.g. if= a terminal has to tune away from the serving=0D=0A >>>>> base=0D=0A >>>>= >>> station or WLAN periodically to make location measurements).=0D=0A >>>= >> Examples=0D=0A >>>>>>> of the latter include (d) absence of support for= access to non-IP=0D=0A >>>>>>> capable PSAPs as already mentioned (e.g. t= o support E911 phase 2=0D=0A >>> in=0D=0A >>>>> the=0D=0A >>>>>>> US); (= e) no support for handover from the IP to the circuit=0D=0A >>>>>>> domain=0D= =0A >>>>> when=0D=0A >>>>>>> a terminal loses (e.g. moves out of) RF cove= rage in the IP=0D=0A >>>>>>> domain;=0D=0A >>>>> and=0D=0A >>>>>>> (f) n= o allowance for limited access modes wherein a terminal may=0D=0A >>>>> ac= cess=0D=0A >>>>>>> a network only to place an emergency call with ensuing=0D= =0A >>> restrictions=0D=0A >>>>> on=0D=0A >>>>>>> (for example) location= acquisition, PSAP callback and caller=0D=0A >>>>>>> verification and iden= tification to the PSAP. To resolve this=0D=0A >>>>> category=0D=0A >>>>>>= > either significant changes to the framework document could be=0D=0A >>>>= >>> made=0D=0A >>>>> or a=0D=0A >>>>>>> disclaimer/applicability statemen= t could be added stating that=0D=0A >>>>> support=0D=0A >>>>>>> of cellul= ar wireless networks and their associated WLAN and Femto=0D=0A >>>>>>> acc= ess points is not covered.=0D=0A >>>>>>>=0D=0A >>>>>>> Category (C) compr= ises concepts and capabilities in the draft=0D=0A >>>>>>> that=0D=0A >>>>= > are=0D=0A >>>>>>> either already part of the standardized solution for w= ireless=0D=0A >>>>> networks=0D=0A >>>>>>> or that might be added at a la= ter time. Examples of the former=0D=0A >>>>> include=0D=0A >>>>>>> LoST, = SIP location conveyance, general use of SIP, location for=0D=0A >>>>> rout= ing=0D=0A >>>>>>> versus for dispatch, cellular positioning methods. Examp= les of=0D=0A >>>>>>> the=0D=0A >>>>>>> latter include use of location ref= erences and dereferencing and=0D=0A >>>>>>> possible interworking between = the current wireless network=0D=0A >>> solutions=0D=0A >>>>>>> (in 3GPP, = 3GPP2 and OMA) and the solution described in this=0D=0A >>>>>>> draft.=0D=0A= >>>>> The=0D=0A >>>>>>> presence of this category could be acknowledged = by following the=0D=0A >>>>>>> disclaimer for (B) with a statement that ce= rtain portions of the=0D=0A >>>>>>> solution are expected to be incorporat= ed into wireless networks=0D=0A >>> now=0D=0A >>>>>>> and/or in the futur= e.=0D=0A >>>>>>>=0D=0A >>>>>>> We hope that these comments will be seen t= o be a useful addition=0D=0A >>> to=0D=0A >>>>>>> this review in the sens= e of enabling a more precise scoping for=0D=0A >>> the=0D=0A >>>>>>> fram= ework document and we are willing to assist in providing=0D=0A >>> wording=0D= =0A >>>>>>> for any disclaimer/applicability statement that the Ecrit work= ing=0D=0A >>>>> group=0D=0A >>>>>>> may now deem fit to include.=0D=0A >= >>>>>>=0D=0A >>>>>>> Kind Regards=0D=0A >>>>>>>=0D=0A >>>>>>> Stephen Ed= ge (Qualcomm 3GPP SA2 participant), Kirk Burroughs=0D=0A >>>>> (Qualcomm=0D= =0A >>>>>>> 3GPP2 TSG-X and TSG-C participant)=0D=0A >>>>>>>=0D=0A >>>>>= >> PS this being sent on 2/4/09 at 11:50pm PST=0D=0A >>>>>>>=0D=0A >>>>>= >> _______________________________________________=0D=0A >>>>>>> Ecrit mai= ling list=0D=0A >>>>>>> Ecrit@ietf.org=0D=0A >>>>>>> https://www.ietf.org= /mailman/listinfo/ecrit=0D=0A >>>>>>=0D=0A >>>>>> _______________________= ________________________=0D=0A >>>>>> Ecrit mailing list=0D=0A >>>>>> Ecr= it@ietf.org=0D=0A >>>>>> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A= >>>>>>=0D=0A >>>>> _______________________________________________=0D=0A= >>>>> Ecrit mailing list=0D=0A >>>>> Ecrit@ietf.org=0D=0A >>>>> https:/= /www.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, propriet= ary, or otherwise private information.=0D=0A >>>> If you have received it = in error, please notify the sender=0D=0A >>>> immediately and delete the o= riginal. 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 >= >>> Ecrit mailing list=0D=0A >>>> Ecrit@ietf.org=0D=0A >>>> https://www.i= etf.org/mailman/listinfo/ecrit=0D=0A >>>>=0D=0A >>>=0D=0A >>> __________= _____________________________________=0D=0A >>> Ecrit mailing list=0D=0A = >>> Ecrit@ietf.org=0D=0A >>> https://www.ietf.org/mailman/listinfo/ecrit=0D= =0A >>>=0D=0A >>> *****=0D=0A >>>=0D=0A >>> The information transmitted= is intended only for the person or=0D=0A >>> entity 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 information by=0D=0A >>> persons or entities other than the intended = recipient is=0D=0A >>> prohibited. If=0D=0A >>> you received this in erro= r, please contact the sender and delete the=0D=0A >>> material from all co= mputers. GA621=0D=0A >>>=0D=0A >>>=0D=0A >>> ___________________________= ____________________=0D=0A >>> Ecrit mailing list=0D=0A >>> Ecrit@ietf.or= g=0D=0A >>> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A >> ________= _______________________________________=0D=0A >> Ecrit mailing list=0D=0A = >> Ecrit@ietf.org=0D=0A >> https://www.ietf.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 privileged, proprieta= ry, or otherwise private information.=0D=0A >If you have received it in er= ror, 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---------------= ---------------------------------------------------------------------------= ------=0D=0AThis message is for the designated recipient only and may=0D=0A= contain privileged, proprietary, or otherwise private information. =20=0D=0A= If you have received it in error, please notify the sender=0D=0Aimmediately= and delete the original. Any unauthorized use of=0D=0Athis email is prohi= bited.=0D=0A---------------------------------------------------------------= ---------------------------------=0D=0A[mf2]=0D=0A From James.Winterbottom@andrew.com Wed Mar 4 19:55:44 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0857528C1DE for ; Wed, 4 Mar 2009 19:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFkgLnerp-cK for ; Wed, 4 Mar 2009 19:55:10 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id B09C528C1CB for ; Wed, 4 Mar 2009 19:55:09 -0800 (PST) X-SEF-Processed: 5_0_0_910__2009_03_04_22_15_19 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 04 Mar 2009 22:15:16 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 21:55:33 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99D46.3B82EB7F" Date: Wed, 4 Mar 2009 21:55:31 -0600 Message-ID: In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5374A0D6@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmY6xBP94jupkzETj+iA0b5U69mvgDj/IbwAAQz+pA= References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com><64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net> <1288E74A73964940B132A0B9EA8D8ABC5374A0D6@NASANEXMB04.na.qualcomm.com> From: "Winterbottom, James" To: "Edge, Stephen" , X-OriginalArrivalTime: 05 Mar 2009 03:55:33.0742 (UTC) FILETIME=[3C0B60E0:01C99D46] X-Mailman-Approved-At: Thu, 05 Mar 2009 05:35:55 -0800 Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 03:55:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99D46.3B82EB7F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stephen,=0D=0A=0D=0A=20=0D=0A=0D=0AA few errors and clarifications.=0D=0A=0D= =0A=20=0D=0A=0D=0ACheers=0D=0A=0D=0AJames=0D=0A=0D=0A=20=0D=0A=0D=0A-----Or= iginal Message-----=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces= @ietf.org] On Behalf=0D=0AOf Edge, Stephen=0D=0ASent: Wednesday, 4 March 20= 09 4:32 PM=0D=0ATo: br@brianrosen.net=0D=0ACc: ECRIT=0D=0ASubject: Re: [Ecr= it] Comments on Framework Draft=0D=0A=0D=0A=20=0D=0A=0D=0ABrian=0D=0A=0D=0A= =20=0D=0A=0D=0AThanks for these well considered responses. Below I am provi= ding on an=0D=0Aitem by item basis, and taking into account your responses,= a few more=0D=0Areasons why the current Ecrit solution is unsuitable - or,= if you=0D=0Aprefer, less suitable than the 3GPP/3GPP2 solution - for cellu= lar=0D=0Anetworks.=0D=0A=0D=0A=20=0D=0A=0D=0A1. Access to PSTN capable PSAP= s=0D=0A=0D=0AAssuming that the best available solution for this currently i= s the=0D=0Aongoing NENA i2 standard (as you comment), then there are proble= ms with=0D=0Aproviding location for dispatch (initial and updated location)= =2E For=0D=0Aexample, the latest i2.5 draft I have (December 2008) says tha= t the VPC=0D=0Ato LIS v3 interface is being deprecated (thus not available)= , although=0D=0Athis is the interface that the VPC would use to query locat= ion from the=0D=0ALIS.=20=0D=0A=0D=0A=20=0D=0A=0D=0A[AJW] The V3 interface = is not being deprecated, what is being deprecated=0D=0Ais the old V3 schema= and the rationale for that is that it makes more=0D=0Asense to re-use HELD=0D= =0A(http://tools.ietf.org/html/draft-winterbottom-geopriv-deref-protocol-03=0D= =0A) an SIP for dereference protocols rather than reinventing the wheel.=0D= =0A=0D=0A=20=0D=0A=0D=0AAlso I don't see any inclusion of accurate position= ing support - e.g.=0D=0Ausing A-GPS. Further, interworking with the circuit= mode side for UA=0D=0Aaccess (as opposed to PSAP access) seems to be out o= f scope. So at best,=0D=0Athis standard is incomplete (i.e. not yet suitabl= e for cellular=0D=0Anetworks). However, I agree that there is some overlap = between i2.5 and=0D=0Athe 3GPP/3GPP2 solution.=0D=0A=0D=0A=20=0D=0A=0D=0A[A= JW] i2 does not preclude the measurements being provided by the Target=0D=0A= device, or being requested of the Target device by the LIS. There are a=0D=0A= slew of contributions that show how this can easily be done using HELD.=0D=0A=0D= =0A=20=0D=0A=0D=0A2. Handover between different IP access networks includin= g different=0D=0Atypes of access network=0D=0A=0D=0AOne of the issues here = would be change of LIS across different networks=0D=0Awhile avoiding impact= s to both IP and PSTN capable PSAPs (i.e. handover=0D=0Amust be transparent= to PSAPs within the limitations imposed by SIP or=0D=0Asome J-STD-036 type= of circuit mode solution). The problem gets more=0D=0Adifficult when hando= ver to/from circuit mode access networks is=0D=0Aconsidered. So far, 3GPP/3= GPP2 has not yet agreed on a solution although=0D=0Athere are proposals and= we expect some resolution soon. On the Ecrit and=0D=0ANENA sides, I see mu= ch less progress.=0D=0A=0D=0A=20=0D=0A=0D=0A3. Handover to/from circuit mod= e networks=0D=0A=0D=0AWe agree here at least on the out of scope aspect. I = suppose I can=0D=0Aaccept that it is not customary to point this out in IET= F standards. But=0D=0AI hope you can see that this is an issue for cellular= networks most of=0D=0Awhich will have extensive circuit mode coverage for = a long time to come.=0D=0A=0D=0A=20=0D=0A=0D=0A4. Location for cellular acc= ess (and the requirement to support LCPs=0D=0Athat will be useless for cell= ular access)=0D=0A=0D=0AThe issue is not so much the LCP itself but the cap= ability to support=0D=0Aaccurate positioning - e.g. using A-GPS, AFLT, OTDO= A, enhanced cell ID=0D=0Aetc. None of those methods seem to be supported as= part of DHCP or HELD=0D=0Aright now. So some modification of the LCP relat= ed requirements or of=0D=0Athe LCPs seems needed.=0D=0A=0D=0A=20=0D=0A=0D=0A= [AJW] I will stress that a number of these methods are network=0D=0Adetermi= nation methods and are dependent on the location node accessing=0D=0Athese = measurements from directly from the RAN. In such cases anyone of=0D=0Athe L= CPs described is just as capable of obtaining these as any specific=0D=0A3G= location node. For example, a device could launch a HELD request to=0D=0At= he LIS, and the LIS could request timing advance measurements from the=0D=0A= network, or use SRI/PSL to contact and SMLC. The determination=0D=0Aprocedu= res are transparent and are equally applicable to an LCP as they=0D=0Aare t= o 3GPP specific procedures.=0D=0A=0D=0A=20=0D=0A=0D=0ALet's take a bit of a= look at Target provided measurements. If my=0D=0AHELD-enable device were t= o include let's say relative delay measurements=0D=0Ato the LIS in an acces= s network, then the LIS can easily use these,=0D=0Asince the LIS knows the = locations of all the associated basestations.=0D=0ANow let's compare this t= o 3GPP user-plane, where the SET would provide=0D=0Athis information back t= o a home-SLP, if the SET is roaming what use are=0D=0Athese measurements=3F= There are two options for using them, neither of=0D=0Awhich is overly sati= sfactory. The H-SLP can have a database containing=0D=0Aevery single base s= tation on earth, and can attempt to use them in that=0D=0Afashion, certainl= y some vendors are taking that approach, but it is=0D=0Ahardly workable in = the long term. Or, the H-SLP can find the SLP in the=0D=0Avisited network a= nd ask it to do the work for it. Certainly SUPL defines=0D=0Aa protocol to = support the quest procedures for this, but is very=0D=0Aconveniently puts o= ut of scope how the H-SLP determines the correct=0D=0AV-SLP to contact. Ind= eed once you move to W-LAN this problem becomes=0D=0Aintractable.=0D=0A=0D=0A= =20=0D=0A=0D=0ADevice provided network measurements are only relevant in th= at access=0D=0Anetwork and this point is sadly missed by the 3GPP adopted u= ser-plane=0D=0Asolution.=20=0D=0A=0D=0A=20=0D=0A=0D=0A To see how some of p= lan to address you concerns of LCP provided=0D=0Ameasurements please see:=0D= =0A=0D=0A* draft-thomson-geopriv-held-measurements=0D=0A=20=0D=0A=0D=0A* = draft-thomson-geopriv-held-grip=0D=0A=20=0D=0A=0D=0A* draft-thomson-geop= riv-held-capabilities=0D=0A=20=0D=0A=0D=0A* =20=0D=0A=0D=0A=20=0D=0A=0D=0A= =20=0D=0A=0D=0A5. Endpoint based location and routing for cellular access (= issues here=0D=0Aare network and device loading as well as device impacts a= nd problems=0D=0Awith PSTN capable PSAPs)=0D=0A=0D=0AEndpoint based locatio= n when spread over millions (billions,=0D=0Aplanet-wide) of terminals will = consume significant network and terminal=0D=0Aresources.=0D=0A=0D=0A=20=0D=0A=0D= =0A[AJW] Perhaps, but using an LCP this is local traffic, in contrast with=0D= =0ASUPL ALL communication goes back to the H-SLP and this can be a long way=0D= =0Aaway when the device is roaming.=0D=0A=0D=0A=20=0D=0A=0D=0AA typical ter= minal is generally idle and interacts with the network very=0D=0Asparingly = to update the network with its current location (e.g. current=0D=0Acluster = of potential serving cells).=20=0D=0A=0D=0A=20=0D=0A=0D=0A[AJW] A location = URI means that unless the device changes access=0D=0Anetworks that it does = not need to perform this update at all. When the=0D=0Adevice does change ac= cess networks, it acquires a new location URI.=0D=0A=0D=0A=20=0D=0A=0D=0APe= rforming network assisted periodic location fixes and LoST queries=0D=0Awou= ld add significantly to network load. Performing periodic location=0D=0Afix= es in the terminal (e.g. using GPS) and estimating when a PSAP=0D=0Aboundar= y may have been crossed would add to terminal load (e.g. thus=0D=0Abattery = drain).=20=0D=0A=0D=0A=20=0D=0A=0D=0A[AJW] In the mobile case I would perfo= rm these operations at call time,=0D=0Aand I certainly wouldn't do a GPS fi= x as a rough location fix will be=0D=0Aquite adequate for purposes of obtai= ning a routing URI. In this case I=0D=0Acould send a HELD request the LIS w= ith a responseTime=3DemergencyRouting.=0D=0AThe LIS can invoke techniques f= or enhanced cell etc is that falls into=0D=0Acriteria set by the local juri= sdiction, the device can then do the lost=0D=0Alookup using eh resulting lo= cation. It is certainly no less efficient=0D=0Afor the device to do these o= perations than it is for the network to do=0D=0Athem on behalf of the devic= e, and it may be more efficient because these=0D=0Aare local services. Ulti= mately the bandwidth is the same or less using=0D=0Athe ECRIT proposal for = call routing.=0D=0A=0D=0A=20=0D=0A=0D=0AOptimizations would be possible of = course - e.g. based on observing=0D=0Anearby cell IDs - but they will add t= o terminal complexity and testing=0D=0Acosts. I agree that the Ecrit soluti= on does allow for proxies to do this=0D=0Abut here the solution also become= s incomplete because there seem no=0D=0Adetails of how this would work - e.= g. what location solutions would then=0D=0Abe used.=0D=0A=0D=0A=20=0D=0A=0D= =0A[AJW] I am sorry I don't understand this comment. If we look at almost=0D= =0Aany cellular technology that I am aware of the device is already aware=0D= =0Aof neighbouring cells, it has to be as part of the general hand-over=0D=0A= procedures. In GSM this information is included in signal strength=0D=0Ainf= ormation already passed from the handset to the network. In WiMAX=0D=0Athis= is done using relative delay measurements. Pick your network type,=0D=0Ath= ere are equivalents. Nothing special needs to be done to the device to=0D=0A= use them. Any network that supports a control-plane location=0D=0Aarchitect= ure provides native messaging for getting access to these=0D=0Ameasurements= =2E This is handled in the LIS and is totally transparent to=0D=0Athe devic= e, the device see normal network procedures taking place.=0D=0A=0D=0A=20=0D= =0A=0D=0APerhaps I have misunderstood what you were trying to say.=0D=0A=0D= =0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A6. Support of unauthenticated users and us= ers who can be authenticated=0D=0Abut are not permitted access/VSP service = except for emergency calls=0D=0A=0D=0AI think the Ecrit solution and you bo= th assume that this has already=0D=0Abeen resolved somehow at the access le= vel and therefore the various=0D=0Aprocedures in Ecrit can still be used. M= aybe that is valid. However,=0D=0Athere are still problems that are not cov= ered in the Ecrit drafts but=0D=0Aneed to be resolved including (a) obtaini= ng IP access (e.g. via a WLAN,=0D=0Acellular network, cable link) when not = a valid subscriber, (b) obtaining=0D=0Aaccess to the VSP and (c) ensuring o= nly emergency related services are=0D=0Aprovided (e.g. and not free Interne= t and location access). These and=0D=0Aadditional problems (e.g. UA identif= ication) would have to be solved,=0D=0Amaybe on a per access basis, and the= n ensured to be compatible with the=0D=0Arest of the Ecrit solution. A sign= ificant part of the 3GPP/3GPP2=0D=0Asolution is concerned with this aspect = and it has delayed completion of=0D=0Athe solution for the more normal case= of valid subscriber access due to=0D=0Asuch compatibility issues.=0D=0A=0D= =0A=20=0D=0A=0D=0A[AJW] Unauthenticated access is an interesting animal, an= d as you point=0D=0Aout in an IP world this has several different levels on= which it=0D=0Aoperates. There are a few points on this that should be cons= idered=0D=0Ahowever, and fist and foremost perhaps is the growing number of=0D= =0Acountries at that are disabling this functionality!=0D=0A=0D=0A=20=0D=0A=0D= =0AAnother point of interest is that in cellular this is already=0D=0Atechn= ologically challenged when it comes to this function; devices that=0D=0Ause= different physical characteristic from the carrier network cannot be=0D=0A= accommodated by this service even if they both have 3GPP cores.=0D=0A=0D=0A= =20=0D=0A=0D=0APrivate IP networks are very common, almost very house has o= ne, and a=0D=0Avery large number have wireless LANs. Conversely there are v= ery few=0D=0Aprivate cellular networks. So I am not sure that a direct comp= arison can=0D=0Abe made here, certainly I don't intend to let just anyone o= n to private=0D=0Ahome LAN just because they claim they want to make an eme= rgency call, it=0D=0Ais tantamount to my simply placing a T-200 phone on my= letterbox along=0D=0Awith a sign that says emergency only.=0D=0A=0D=0A=20=0D= =0A=0D=0AThere are thoughts on how to address some of these issues in ECRIT= , and=0D=0Ayou will have to forgive me but I haven't had time to address th= em in a=0D=0Adraft yet, I do hope to in the not too distant future.=0D=0A=0D= =0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0AKind Regards=0D=0A=0D=0A =0D= =0A=0D=0AStephen=0D=0A=0D=0A-----Original Message-----=0D=0A=0D=0AFrom: br@= brianrosen.net [mailto:br@brianrosen.net]=0D=0A=0D=0ASent: Friday, February= 27, 2009 6:53 AM=0D=0A=0D=0ATo: Edge, Stephen=0D=0A=0D=0ACc: Thomson, Mart= in; Richard Barnes; ECRIT=0D=0A=0D=0ASubject: Re: [Ecrit] Comments on Frame= work Draft=0D=0A=0D=0A=20=0D=0A=0D=0AStephen=0D=0A=0D=0A=20=0D=0A=0D=0ALike= any standards organization, the IETF restricts it's scope.=0D=0A=0D=0AGene= rally, the scope is "the Internet", although we very often describe=0D=0A=0D= =0Asolutions that are explicitly designed for private IP networks as well=0D= =0Aas=0D=0A=0D=0Athe Internet. We don't write standards for circuit switch= ed networks,=0D=0Aand=0D=0A=0D=0Ait should be no surprise that the ecrit so= lution does not cater to CS=0D=0A=0D=0Asolutions. Nevertheless, we often t= ry to make sure that our solutions=0D=0A=0D=0Aharmonize reasonably well wit= h existing solutions.=0D=0A=0D=0A=20=0D=0A=0D=0AIndeed, the ecrit solution = clains global applicability to the Internet=0D=0Ain=0D=0A=0D=0Ageneral, and= most private IP networks that can be interconnected to the=0D=0A=0D=0AInte= rnet or to other IP networks via gateways. Looking at your list of=0D=0A=0D= =0Aproblem areas:=0D=0A=0D=0A> - access to PSTN capable PSAPs=0D=0A=0D=0A= This is out of scope for IETF. NENA has active work on this subject.=0D=0A= It=0D=0A=0D=0Aseems straightforward to interwork ecrit compatible devices a= nd networks=0D=0A=0D=0Ato existing CS connected PSAPs. As you know, CS int= erconnects are very=0D=0A=0D=0Anation-specific, so the NENA work may not ha= ve general applicability.=0D=0A=0D=0AHowever, it shows that it is possible = to interwork. The NENA i2 work is=0D=0A=0D=0Aalso designed to take ecrit c= ompatible devices and VSP networks, and=0D=0A=0D=0Ainterwork them to the ex= isting network. The VSP would direct the call=0D=0Ato=0D=0A=0D=0Athe VPC, = which would provide the services it does now, using the device=0D=0A=0D=0Ap= rovided location for routing. This is important for smooth transition=0D=0A=0D= =0Afrom existing PSAPs and VSPs to "next generation" PSAPs and VSPs.=0D=0A=0D= =0A> - handover between different IP access networks including different=0D= =0A=0D=0A> types of access network=0D=0A=0D=0AIn the ecrit solution, the ac= cess network the call is initiated on=0D=0A=0D=0Aprovides all the facilitie= s needed for the device to initiate an=0D=0Aemergency=0D=0A=0D=0Acall. Th= e call starts traversing it's normal call path, and eventually=0D=0A=0D=0Ar= outes to the ESRP. Handoffs between IP networks should be transparent=0D=0A= to=0D=0A=0D=0Athis process, although we probably haven't done all the work = we need to=0D=0Ado=0D=0A=0D=0Afor handoffs where the IP address as seen by = the terminating network=0D=0A=0D=0Achanges. This would generally be true o= f all current SIP based work.=0D=0A=0D=0A> - handover to/from circuit mod= e networks=0D=0A=0D=0AThis would be out of scope for IETF. It's as applica= ble to a simple SIP=0D=0A=0D=0Acall as it is a SIP emergency call, and ther= e are no statements in any=0D=0ASIP=0D=0A=0D=0Adocuments on that subject.=0D= =0A=0D=0A> - location for cellular access (and the requirement to support= LCPs=0D=0Athat=0D=0A=0D=0A> will be useless for cellular access)=0D=0A=0D=0A= Location for cellular access networks has been considered carefully.=0D=0A=0D= =0ASince cellular is a mobile network, the access network would pass the=0D= =0A=0D=0Adevice a Location-By-Reference URI, using either DHCP or HELD. Ei= ther=0D=0A=0D=0Aprotocol is suitable for cellular networks. As we have poi= nted out=0D=0A=0D=0Aseveral times, cellular networks support raw data packe= t services upon=0D=0A=0D=0Awhich many different kinds of networks can be co= nstructed. My usual=0D=0A=0D=0Aexample is a large recreational vehicle tra= veling down a road with a=0D=0A=0D=0Acellular data card plugged into a rout= er to which a wired (Ethernet)=0D=0Aphone=0D=0A=0D=0Ais connected. That ph= one must be able to make an emergency call, and it=0D=0A=0D=0Awill get loca= tion from DHCP or HELD (or LLDP-MED). It is not aware of=0D=0Athe=0D=0A=0D= =0Acellular network, and doesn't know any cellular specific protocols.=0D=0A=0D= =0ACellular networks will have to support IETF location configuration=0D=0A=0D= =0Aprotocols unless they actively prohibit examples like this, or they=0D=0A=0D= =0Aimplement interworking between cellular-specific location protocols and=0D= =0A=0D=0ADHCP or HELD in the data card. The ecrit standards permit proxy=0D= =0Ainsertion=0D=0A=0D=0Aof location, but, as above, we don't think that wor= ks in all cases.=0D=0A=0D=0A> - endpoint based location and routing for c= ellular access (issues=0D=0Ahere=0D=0A=0D=0A> are network and device loadin= g as well as device impacts and problems=0D=0A=0D=0A> with PSTN capable PSA= Ps)=0D=0A=0D=0AThe "load" of using DHCP or HELD to get location and queryin= g LoST is=0D=0A=0D=0Apretty modest. The standards permit proxies to do thi= s if the devices=0D=0A=0D=0Adon't. As above, interwork functions to CS con= nected PSAPs is very=0D=0A=0D=0Afeasible, and as above, cellular networks w= ill have to support access to=0D=0A=0D=0Alocal LoST servers for devices tha= t are connected to cellular networks=0D=0Aand=0D=0A=0D=0Aare ecrit complian= t.=0D=0A=0D=0A> - support of unauthenticated users and users who can be=0D= =0Aauthenticated=0D=0A=0D=0A> but are not permitted access/VSP service exce= pt for emergency calls=0D=0A=0D=0AThis is covered in the standards. None o= f the processes are dependent=0D=0Aon=0D=0A=0D=0Aauthentication, although w= here it is possible, it's desirable so as to=0D=0A=0D=0Aminimize fraudulent= emergency calls=0D=0A=0D=0AMechanisms for specific network authentication = mechanisms are out of=0D=0A=0D=0Ascope, and, like SIP basic calling, are no= t usually mentioned in IETF=0D=0A=0D=0Adocuments.=0D=0A=0D=0A=20=0D=0A=0D=0A= Stephen, we've tried pretty hard to make sure this works for 3G/4G=0D=0Amob= ile=0D=0A=0D=0Anetworks. It's true that it doesn't do it the way 3GPP curr= ently thinks=0D=0A=0D=0Ait ought to work, but we claim they haven't thought= through all the=0D=0A=0D=0Aissues. While it would work, there are opportu= nities for improvement.=0D=0AWe=0D=0A=0D=0Awould be willing to do that if w= e could get the cooperation of 3GPP,=0D=0Awhich=0D=0A=0D=0Awe have tried, a= nd failed, to do.=0D=0A=0D=0A=20=0D=0A=0D=0ASo, I think the documents do no= t need any qualification statements.=0D=0A=0D=0A=20=0D=0A=0D=0ABrian=0D=0A=0D= =0A=20=0D=0A=0D=0A> Martin=0D=0A=0D=0A>=20=0D=0A=0D=0A> The 3GPP/3GPP2 solu= tion has a defined restricted applicability (mainly=0D=0Ato=0D=0A=0D=0A> 3G= PP/3GPP2 access networks where the serving network also acts as the=0D=0AVS= P)=0D=0A=0D=0A> and the specifications for it cover in detail all possible = scenarios=0D=0A=0D=0A> consistent with these restrictions so far as we are = aware.=0D=0A=0D=0A>=20=0D=0A=0D=0A> The Ecrit solution seems to claim globa= l applicability to all types of=0D=0AIP=0D=0A=0D=0A> access (and the more t= hat is said about this from Ecrit participants=0D=0Athe=0D=0A=0D=0A> more t= his gets emphasized) but does not cover in detail all possible=0D=0A=0D=0A>= scenarios (in some cases does not cover in any detail) which means=0D=0Ath= at at=0D=0A=0D=0A> best the solution is incomplete and at worst intrinsical= ly=0D=0Ainapplicable to=0D=0A=0D=0A> some unstated set of scenarios.=0D=0A=0D= =0A>=20=0D=0A=0D=0A> The missing, incomplete and problematic cases include = the following:=0D=0A=0D=0A>=20=0D=0A=0D=0A> - access to PSTN capable PSAP= s=0D=0A=0D=0A> - handover between different IP access networks including = different=0D=0A=0D=0A> types of access network=0D=0A=0D=0A> - handover to= /from circuit mode networks=0D=0A=0D=0A> - location for cellular access (= and the requirement to support LCPs=0D=0Athat=0D=0A=0D=0A> will be useless = for cellular access)=0D=0A=0D=0A> - endpoint based location and routing f= or cellular access (issues=0D=0Ahere=0D=0A=0D=0A> are network and device lo= ading as well as device impacts and problems=0D=0A=0D=0A> with PSTN capable= PSAPs)=0D=0A=0D=0A> - support of unauthenticated users and users who can= be=0D=0Aauthenticated=0D=0A=0D=0A> but are not permitted access/VSP servic= e except for emergency calls=0D=0A=0D=0A>=20=0D=0A=0D=0A> Stating that some= of these cases are out of scope or referencing an=0D=0A=0D=0A> incomplete = and possibly questionable specification from some other=0D=0A=0D=0A> nation= al SDO will not help the user who encounters such problems. But=0D=0Ait=0D=0A=0D= =0A> would certainly help network operators and implementers to acknowledge=0D= =0A=0D=0A> their existence in one form or another because that would allow = better=0D=0A=0D=0A> planning of deployments and would help focus attention = on finding=0D=0A=0D=0A> solutions (whether in IETF or elsewhere) for the mi= ssing cases.=0D=0A=0D=0A>=20=0D=0A=0D=0A> Please note that despite these dr= awbacks, I will acknowledge that=0D=0AEcrit=0D=0A=0D=0A> does have a valuab= le solution that covers many scenarios not covered=0D=0Aby=0D=0A=0D=0A> 3GP= P/3GPP2. It would be the delineation of these supported scenarios=0D=0A(or=0D= =0A=0D=0A> equivalently unsupported scenarios) in some applicability statem= ent=0D=0Athat=0D=0A=0D=0A> would be particularly useful right now.=0D=0A=0D= =0A>=20=0D=0A=0D=0A> Kind Regards=0D=0A=0D=0A>=20=0D=0A=0D=0A> Stephen=0D=0A=0D= =0A> -----Original Message-----=0D=0A=0D=0A> From: Thomson, Martin [mailto:= Martin.Thomson@andrew.com]=0D=0A=0D=0A> Sent: Thursday, February 26, 2009 9= :45 PM=0D=0A=0D=0A> To: Edge, Stephen; Richard Barnes=0D=0A=0D=0A> Cc: ECRI= T=0D=0A=0D=0A> Subject: RE: [Ecrit] Comments on Framework Draft=0D=0A=0D=0A= >=20=0D=0A=0D=0A> There's benefit in knowing the limitations of a framework= , and every=0D=0A=0D=0A> architecture makes certain assumptions. Let's exa= mine them though...=0D=0A=0D=0A>=20=0D=0A=0D=0A> The IETF might occasionall= y make the assumption that the standards it=0D=0A=0D=0A> develops are for I= nternet devices. That assumption probably need not=0D=0Abe=0D=0A=0D=0A> st= ated explicitly.=0D=0A=0D=0A>=20=0D=0A=0D=0A> The ECRIT architecture relies= on implementations of the protocols that=0D=0Ait=0D=0A=0D=0A> references. = That is not extraordinary. A reliance on implementation=0D=0Aof=0D=0A=0D=0A= > these protocols by endpoints, routing intermediaries and PSAPs should=0D=0A= not=0D=0A=0D=0A> need to be explained.=0D=0A=0D=0A>=20=0D=0A=0D=0A> So the = assumptions are:=0D=0A=0D=0A> - the Internet=0D=0A=0D=0A> - solutions are= implemented and deployed=0D=0A=0D=0A> - the end device is a key component=0D= =0A=0D=0A>=20=0D=0A=0D=0A> Only that last element is particularly novel ...= or not that much=0D=0Areally.=0D=0A=0D=0A> It's a design choice. Unless= you were thinking of trunking the=0D=0Avoice=0D=0A=0D=0A> elsewhere.=0D=0A=0D= =0A>=20=0D=0A=0D=0A> Of course, you're suggesting that the design choice wa= s made in=0D=0Aignorance=0D=0A=0D=0A> of all the constraints. You're sugge= sting that - as a result - the=0D=0Achoice=0D=0A=0D=0A> is flawed and the s= olution is not going to work for cellular services.=0D=0AWe=0D=0A=0D=0A> di= sagree. The solution is a basis for emergency calling in _any_ IP=0D=0A=0D= =0A> network.=0D=0A=0D=0A>=20=0D=0A=0D=0A> Cheers,=0D=0A=0D=0A> Martin=0D=0A=0D= =0A>=20=0D=0A=0D=0A>=20=0D=0A=0D=0A>> -----Original Message-----=0D=0A=0D=0A= >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=0D=0ABeh= alf=0D=0A=0D=0A>> Of Edge, Stephen=0D=0A=0D=0A>> Sent: Friday, 27 February = 2009 3:30 PM=0D=0A=0D=0A>> To: Richard Barnes=0D=0A=0D=0A>> Cc: 'ECRIT'=0D=0A=0D= =0A>> Subject: Re: [Ecrit] Comments on Framework Draft=0D=0A=0D=0A>>=20=0D=0A=0D= =0A>> Hi Richard=0D=0A=0D=0A>>=20=0D=0A=0D=0A>> Thanks for the comments. Yo= ur statement below that "SIP emergency=0D=0A=0D=0A>> calling works if all p= arties behave as specified in these (IETF=0D=0AEcrit)=0D=0A=0D=0A>> documen= ts" to some degree highlights the problems we are raising. The=0D=0A=0D=0A>= > documents do contain a number of implicit and explicit restrictions -=0D=0A=0D= =0A>> like IP capable PSAPs, global IP access (no islands of circuit mode=0D= =0A=0D=0A>> access for example), universal support of this solution by all = access=0D=0A=0D=0A>> providers and VSPs (not much good if some opt for anot= her solution)=0D=0Aand=0D=0A=0D=0A>> end system oriented location and routi= ng capability - which together=0D=0A=0D=0A>> make them unsuitable (we belie= ve) for cellular wireless networks. If=0D=0A=0D=0A>> these restrictions and= assumptions were all made explicit upfront, it=0D=0A=0D=0A>> would to a la= rge degree (and possibly completely) address our=0D=0Aconcerns.=0D=0A=0D=0A= >>=20=0D=0A=0D=0A>> You are right in assuming another set of specifications= for the 3GPP=0D=0A=0D=0A>> and 3GPP2 solution. The applicability of this s= olution is explicitly=0D=0A=0D=0A>> defined in TS 23.167 (or more exactly i= n an already agreed CR in=0D=0A=0D=0A>> contribution S2-090752 which will b= ecome part of 23.167 in a few more=0D=0A=0D=0A>> weeks) to cover the follow= ing access types: GPRS (UTRAN WCDMA),=0D=0AI-WLAN,=0D=0A=0D=0A>> Fixed Broa= dband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN=0D=0A=0D=0A>> (LTE)= =2E So there is a restriction and arbitrary internet access is not=0D=0A=0D= =0A>> covered (yet) as I have stated before.=0D=0A=0D=0A>>=20=0D=0A=0D=0A>>= Kind Regards=0D=0A=0D=0A>>=20=0D=0A=0D=0A>> Stephen=0D=0A=0D=0A>> -----Ori= ginal Message-----=0D=0A=0D=0A>> From: Richard Barnes [mailto:rbarnes@bbn.c= om]=0D=0A=0D=0A>> Sent: Wednesday, February 25, 2009 6:30 PM=0D=0A=0D=0A>> = To: Edge, Stephen=0D=0A=0D=0A>> Cc: Brian Rosen; 'ECRIT'=0D=0A=0D=0A>> Subj= ect: Re: [Ecrit] Comments on Framework Draft=0D=0A=0D=0A>>=20=0D=0A=0D=0A>>= Hi Stephen,=0D=0A=0D=0A>>=20=0D=0A=0D=0A>> I'm a little confused by the sc= ope of what you're asking. The=0D=0A=0D=0A>> framework=0D=0A=0D=0A>> and p= honebcp documents exist in order to describe the ECRIT solution:=0D=0A=0D=0A= >> They say, in effect, "SIP emergency calling works if all parties=0D=0Abe= have=0D=0A=0D=0A>> as specified in these documents."=0D=0A=0D=0A>>=20=0D=0A=0D= =0A>> As I understand what you're saying (and I'm by no means an expert in=0D= =0A=0D=0A>> 3GPP), 3GPP specifies that one or more elements of this system = behave=0D=0A=0D=0A>> differently. This simply means that 3GPP networks are= n't complying=0D=0A=0D=0A>> with=0D=0A=0D=0A>> these specs. Just like ther= e's no disclaimer in RFC 791 (IPv4) that=0D=0A=0D=0A>> says "this doesn't w= ork on X.25 networks", it's not clear to me that=0D=0Aan=0D=0A=0D=0A>> anal= ogous disclaimer is called for here.=0D=0A=0D=0A>>=20=0D=0A=0D=0A>> I presu= me there are similar documents describing how emergency=0D=0Acalling=0D=0A=0D= =0A>> works in 3GPP networks. Do they include notes saying that the 3GPP=0D= =0A=0D=0A>> solution doesn't work in the broader Internet=3F=0D=0A=0D=0A>> =0D= =0A=0D=0A>> --Richard=0D=0A=0D=0A>>=20=0D=0A=0D=0A>>=20=0D=0A=0D=0A>>=20=0D= =0A=0D=0A>>=20=0D=0A=0D=0A>>=20=0D=0A=0D=0A>> Edge, Stephen wrote:=0D=0A=0D= =0A>> > Brian=0D=0A=0D=0A>> >=0D=0A=0D=0A>> > First of all apologies for th= e likely lateness of this reply - I=0D=0A=0D=0A>> actually wrote it on 19 F= ebruary in a 3GPP SA2 meeting in Budapest=0D=0Abut=0D=0A=0D=0A>> it seems u= nlikely that my VPN, Outlook server and WiFi access=0D=0A=0D=0A>> capabilit= y will cooperate together to get it sent until I return to=0D=0Athe=0D=0A=0D= =0A>> office mid-next week.=0D=0A=0D=0A>> >=0D=0A=0D=0A>> > Anyhow thanks f= or your comments. There have actually been a number=0D=0Aof=0D=0A=0D=0A>> c= onference calls between IETF and 3GPP participants over the last=0D=0A=0D=0A= >> couple of years at which common features like support of IP emergency=0D= =0A=0D=0A>> calls were discussed and these could have been good forum for=0D= =0A=0D=0A>> participants on either side to have raised the kinds of issues = you=0D=0A=0D=0A>> elaborate on below. Given that seems not so far to have h= appened, it=0D=0A=0D=0A>> could still be possible in future such calls.=0D=0A=0D= =0A>> >=0D=0A=0D=0A>> > But the issues we are raising are not directly to d= o with further=0D=0A=0D=0A>> aligning the 2 solutions or with the lack of t= his in the past. We are=0D=0A=0D=0A>> simply pointing out that the solution= s are currently different and=0D=0Athat=0D=0A=0D=0A>> from a cellular wirel= ess perspective, the Ecrit solution is not seen=0D=0Aas=0D=0A=0D=0A>> suita= ble in all respects (for support of IP emergency calls=0D=0Aoriginating=0D=0A=0D= =0A>> from such access types). That is not just our point of view. 3GPP2=0D= =0Asent=0D=0A=0D=0A>> a liaison to Ecrit some months ago pointing out the s= ame issues.=0D=0A=0D=0A>> >=0D=0A=0D=0A>> > So we are proposing that the Ec= rit framework and phoneBCP spec.s=0D=0A=0D=0A>> include a statement acknowl= edging this - e.g. by referencing the=0D=0A=0D=0A>> alternative 3GPP/3GPP2 = solution and indicating the IP access types=0D=0Afor=0D=0A=0D=0A>> which th= e Ecrit solution will work without limitation (or=0D=0Aequivalently=0D=0A=0D= =0A>> the access types where limitations are not ruled out).=0D=0A=0D=0A>> = >=0D=0A=0D=0A>> > We are not proposing further modification and extension o= f the=0D=0AEcrit=0D=0A=0D=0A>> solution - just pointing out that this would= be needed (as with the=0D=0A=0D=0A>> 3GPP/3GPP2 solution) to fully cover a= ll types of access.=0D=0A=0D=0A>> >=0D=0A=0D=0A>> > Kind Regards=0D=0A=0D=0A= >> >=0D=0A=0D=0A>> > Stephen=0D=0A=0D=0A>> > -----Original Message-----=0D=0A=0D= =0A>> > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A=0D=0A>> > Sent: = Wednesday, February 18, 2009 8:07 PM=0D=0A=0D=0A>> > To: Edge, Stephen; 'EC= RIT'=0D=0A=0D=0A>> > Subject: RE: [Ecrit] Comments on Framework Draft=0D=0A=0D= =0A>> >=0D=0A=0D=0A>> > I have bit my tongue on this one for a long time.=0D= =0A=0D=0A>> >=0D=0A=0D=0A>> > Stephen, with respect, please go talk to 3GPP= management and ask=0D=0Athem=0D=0A=0D=0A>> why=0D=0A=0D=0A>> > there has b= een no participation in the ecrit effort despite=0D=0Amultiple=0D=0A=0D=0A>= > YEARS=0D=0A=0D=0A>> > of begging them to get involved. To put it frankly= , 3GPP is quite=0D=0A=0D=0A>> willing=0D=0A=0D=0A>> > to bully IETF into do= ing its work on its schedule, but cannot be=0D=0A=0D=0A>> bothered to=0D=0A=0D= =0A>> > get work done it knows it will eventually have to do when the IETF=0D= =0A=0D=0A>> asks it=0D=0A=0D=0A>> > to do so.=0D=0A=0D=0A>> >=0D=0A=0D=0A>>= > 3GPP understands the mess that is being created by not=0D=0Aparticipatin= g.=0D=0A=0D=0A>> They=0D=0A=0D=0A>> > know full well that when they finally= get around to dealing with PS=0D=0A=0D=0A>> > terminated emergency calls, = that there will be a lot of resistance=0D=0Ato=0D=0A=0D=0A>> > changing ful= ly specified and implemented standards to more closely=0D=0A=0D=0A>> align=0D= =0A=0D=0A>> > with 3GPP standards. I expect you will have several interwor= king=0D=0A=0D=0A>> functions=0D=0A=0D=0A>> > to define and build.=0D=0A=0D=0A= >> >=0D=0A=0D=0A>> > So, politely, please go away, we're finishing work we = dearly wanted=0D=0A=0D=0A>> you all=0D=0A=0D=0A>> > to be involved with for= years, but you refused to do anything.=0D=0AIt's=0D=0A=0D=0A>> too=0D=0A=0D= =0A>> > late for this rev.=0D=0A=0D=0A>> >=0D=0A=0D=0A>> > Now, having said= that, there are quite a few people who have=0D=0A=0D=0A>> participated in=0D= =0A=0D=0A>> > the IETF work who are IMS aware and I believe that despite yo= ur=0D=0A=0D=0A>> fears,=0D=0A=0D=0A>> > everything you need is in the specs= =2E The mechanisms we have=0D=0Adefined=0D=0A=0D=0A>> provide=0D=0A=0D=0A>= > > the ability for the network to insert location, recognize and mark=0D=0A=0D= =0A>> emergency=0D=0A=0D=0A>> > calls, and route on behalf of endpoints. A= n E-CSCF could quite=0D=0A=0D=0A>> > straightforwardly provide a SIP call t= owards an ecrit compatible=0D=0A=0D=0A>> PSAP. The=0D=0A=0D=0A>> > only no= t-quite-nice interwork would be from SUPL to HELD (or SIP),=0D=0A=0D=0A>> b= ut it's=0D=0A=0D=0A>> > pretty easy to do that. I'll also note that we hav= e tried to get=0D=0AOMA=0D=0A=0D=0A>> and=0D=0A=0D=0A>> > IETF to cooperate= on location protocols, but we have been=0D=0A=0D=0A>> spectacularly=0D=0A=0D= =0A>> > unsuccessful at that effort also.=0D=0A=0D=0A>> >=0D=0A=0D=0A>> > B= rian=0D=0A=0D=0A>> >=0D=0A=0D=0A>> >=0D=0A=0D=0A>> >=0D=0A=0D=0A>> >> -----= Original Message-----=0D=0A=0D=0A>> >> From: ecrit-bounces@ietf.org [mailto= :ecrit-bounces@ietf.org] On=0D=0A=0D=0A>> Behalf=0D=0A=0D=0A>> >> Of Edge, = Stephen=0D=0A=0D=0A>> >> Sent: Thursday, February 05, 2009 2:50 AM=0D=0A=0D= =0A>> >> To: 'ECRIT'=0D=0A=0D=0A>> >> Subject: [Ecrit] Comments on Framewor= k Draft=0D=0A=0D=0A>> >>=0D=0A=0D=0A>> >> All=0D=0A=0D=0A>> >>=0D=0A=0D=0A>= > >> draft-ietf-ecrit-framework-07 is (as we see it) a mostly=0D=0Ainformat= ive=0D=0A=0D=0A>> >> description of how terminals and networks should suppo= rt emergency=0D=0A=0D=0A>> >> calls made over IP capable facilities to IP c= apable PSAPs. It=0D=0A=0D=0A>> appears=0D=0A=0D=0A>> >> intended to cover a= ll types of access network - including fixed=0D=0A=0D=0A>> line,=0D=0A=0D=0A= >> >> WiFi and cellular (e.g. examples involving each can be found=0D=0A=0D= =0A>> throughout=0D=0A=0D=0A>> >> the draft).=0D=0A=0D=0A>> >>=0D=0A=0D=0A>= > >> When we evaluated this with respect to support of wireless=0D=0Acellul= ar=0D=0A=0D=0A>> >> access and WiFi access associated with a cellular opera= tor (e.g.=0D=0A=0D=0A>> WLAN=0D=0A=0D=0A>> >> or Femto cells integrated int= o a cellular network), we found that=0D=0A=0D=0A>> >> certain portions of t= he draft exhibited one or more of the=0D=0Afollowing=0D=0A=0D=0A>> >> chara= cteristics:=0D=0A=0D=0A>> >>=0D=0A=0D=0A>> >> (A) Inconsistent with alr= eady standardized wireless solutions=0D=0A=0D=0A>> >>=0D=0A=0D=0A>> >> = (B) Inconsistent with essential wireless requirements and=0D=0A=0D=0A>> >> = conventions=0D=0A=0D=0A>> >>=0D=0A=0D=0A>> >> (C) Already part of wirel= ess standards or potentially part of=0D=0A=0D=0A>> >> future standards=0D=0A=0D= =0A>> >>=0D=0A=0D=0A>> >> (A) refers to all portions of the draft framework= that differ from=0D=0A=0D=0A>> the=0D=0A=0D=0A>> >> requirements and proce= dures currently standardized for wireless=0D=0A=0D=0A>> >> emergency access= by 3GPP, 3GPP2 and OMA. This is a plain=0D=0Adifference=0D=0A=0D=0A>> of=0D= =0A=0D=0A>> >> solution and could be resolved through support of both solut= ions=0D=0Aby=0D=0A=0D=0A>> >> terminals (with each solution being used acco= rding to the type of=0D=0A=0D=0A>> >> access network and VSP) or could be r= esolved by supporting only=0D=0Aone=0D=0A=0D=0A>> >> solution and accessing= only the types of network supporting that=0D=0A=0D=0A>> >> solution. To ac= knowledge this category, the framework document=0D=0Acould=0D=0A=0D=0A>> >>= reference the applicable wireless standards and point out that=0D=0Athese=0D= =0A=0D=0A>> >> are valid alternatives for wireless cellular based access.=0D= =0A=0D=0A>> >>=0D=0A=0D=0A>> >> (B) refers to portions of the draft that wo= uld be unsuitable for=0D=0A=0D=0A>> >> wireless networks even if no alterna= tive solution existed together=0D=0A=0D=0A>> with=0D=0A=0D=0A>> >> other po= rtions missing from the draft that would be needed to=0D=0Afully=0D=0A=0D=0A= >> >> support wireless networks. Examples of the former include: (a)=0D=0A=0D= =0A>> emphasis=0D=0A=0D=0A>> >> on endpoint derivation of location, perform= ance of Lost query and=0D=0A=0D=0A>> >> receipt of local dial strings; (b) = restriction of LCPs to=0D=0Aprotocols=0D=0A=0D=0A>> >> that require termina= l initiation (not allowing for network=0D=0A=0D=0A>> initiation=0D=0A=0D=0A= >> >> as far as we can tell) and that include two LCPs (DHCP and LLDP)=0D=0A=0D= =0A>> that=0D=0A=0D=0A>> >> are not applicable to (not defined for) cellula= r access; and (c)=0D=0Athe=0D=0A=0D=0A>> >> requirement that a terminal or = at least a LIS will update the PSAP=0D=0A=0D=0A>> >> whenever location chan= ges. (a) is impractical due to network and=0D=0A=0D=0A>> >> terminal loadin= g consequences and failure to support non-IP=0D=0Acapable=0D=0A=0D=0A>> >> = PSAPs; (b) makes location verification and updated location=0D=0A=0D=0A>> p= rovision=0D=0A=0D=0A>> >> to PSAPs difficult or impossible; while (c) is al= so incompatible=0D=0A=0D=0A>> with=0D=0A=0D=0A>> >> support of existing non= -IP capable PSAPs besides increasing=0D=0Aterminal=0D=0A=0D=0A>> >> load an= d possibly interfering with optimum maintenance of the RF=0D=0A=0D=0A>> >> = connection (e.g. if a terminal has to tune away from the serving=0D=0A=0D=0A= >> base=0D=0A=0D=0A>> >> station or WLAN periodically to make location meas= urements).=0D=0A=0D=0A>> Examples=0D=0A=0D=0A>> >> of the latter include (d= ) absence of support for access to non-IP=0D=0A=0D=0A>> >> capable PSAPs as= already mentioned (e.g. to support E911 phase 2=0D=0Ain=0D=0A=0D=0A>> the=0D= =0A=0D=0A>> >> US); (e) no support for handover from the IP to the circuit = domain=0D=0A=0D=0A>> when=0D=0A=0D=0A>> >> a terminal loses (e.g. moves out= of) RF coverage in the IP domain;=0D=0A=0D=0A>> and=0D=0A=0D=0A>> >> (f) n= o allowance for limited access modes wherein a terminal may=0D=0A=0D=0A>> a= ccess=0D=0A=0D=0A>> >> a network only to place an emergency call with ensui= ng=0D=0Arestrictions=0D=0A=0D=0A>> on=0D=0A=0D=0A>> >> (for example) locati= on acquisition, PSAP callback and caller=0D=0A=0D=0A>> >> verification and = identification to the PSAP. To resolve this=0D=0A=0D=0A>> category=0D=0A=0D= =0A>> >> either significant changes to the framework document could be made=0D= =0A=0D=0A>> or a=0D=0A=0D=0A>> >> disclaimer/applicability statement could = be added stating that=0D=0A=0D=0A>> support=0D=0A=0D=0A>> >> of cellular wi= reless networks and their associated WLAN and Femto=0D=0A=0D=0A>> >> access= points is not covered.=0D=0A=0D=0A>> >>=0D=0A=0D=0A>> >> Category (C) comp= rises concepts and capabilities in the draft that=0D=0A=0D=0A>> are=0D=0A=0D= =0A>> >> either already part of the standardized solution for wireless=0D=0A=0D= =0A>> networks=0D=0A=0D=0A>> >> or that might be added at a later time. Exa= mples of the former=0D=0A=0D=0A>> include=0D=0A=0D=0A>> >> LoST, SIP locati= on conveyance, general use of SIP, location for=0D=0A=0D=0A>> routing=0D=0A=0D= =0A>> >> versus for dispatch, cellular positioning methods. Examples of the=0D= =0A=0D=0A>> >> latter include use of location references and dereferencing = and=0D=0A=0D=0A>> >> possible interworking between the current wireless net= work=0D=0Asolutions=0D=0A=0D=0A>> >> (in 3GPP, 3GPP2 and OMA) and the solut= ion described in this draft.=0D=0A=0D=0A>> The=0D=0A=0D=0A>> >> presence of= this category could be acknowledged by following the=0D=0A=0D=0A>> >> disc= laimer for (B) with a statement that certain portions of the=0D=0A=0D=0A>> = >> solution are expected to be incorporated into wireless networks=0D=0Anow=0D= =0A=0D=0A>> >> and/or in the future.=0D=0A=0D=0A>> >>=0D=0A=0D=0A>> >> We h= ope that these comments will be seen to be a useful addition=0D=0Ato=0D=0A=0D= =0A>> >> this review in the sense of enabling a more precise scoping for=0D= =0Athe=0D=0A=0D=0A>> >> framework document and we are willing to assist in = providing=0D=0Awording=0D=0A=0D=0A>> >> for any disclaimer/applicability st= atement that the Ecrit working=0D=0A=0D=0A>> group=0D=0A=0D=0A>> >> may now= deem fit to include.=0D=0A=0D=0A>> >>=0D=0A=0D=0A>> >> Kind Regards=0D=0A=0D= =0A>> >>=0D=0A=0D=0A>> >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kir= k Burroughs=0D=0A=0D=0A>> (Qualcomm=0D=0A=0D=0A>> >> 3GPP2 TSG-X and TSG-C = participant)=0D=0A=0D=0A>> >>=0D=0A=0D=0A>> >> PS this being sent on 2/4/0= 9 at 11:50pm PST=0D=0A=0D=0A>> >>=0D=0A=0D=0A>> >> ________________________= _______________________=0D=0A=0D=0A>> >> Ecrit mailing list=0D=0A=0D=0A>> >= > Ecrit@ietf.org=0D=0A=0D=0A>> >> https://www.ietf.org/mailman/listinfo/ecr= it=0D=0A=0D=0A>> >=0D=0A=0D=0A>> > ________________________________________= _______=0D=0A=0D=0A>> > Ecrit mailing list=0D=0A=0D=0A>> > Ecrit@ietf.org=0D= =0A=0D=0A>> > https://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A>> >=0D= =0A=0D=0A>> _______________________________________________=0D=0A=0D=0A>> E= crit mailing list=0D=0A=0D=0A>> Ecrit@ietf.org=0D=0A=0D=0A>> https://www.ie= tf.org/mailman/listinfo/ecrit=0D=0A=0D=0A>=20=0D=0A=0D=0A>=0D=0A-----------= -------------------------------------------------------------=0D=0A--------= ----------------=0D=0A=0D=0A> This message is for the designated recipient = only and may=0D=0A=0D=0A> contain privileged, proprietary, or otherwise pri= vate information.=0D=0A=0D=0A> If you have received it in error, please not= ify the sender=0D=0A=0D=0A> immediately and delete the original. Any unaut= horized use of=0D=0A=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> Ecrit mailing list=0D=0A=0D=0A> = Ecrit@ietf.org=0D=0A=0D=0A> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D= =0A>=20=0D=0A=0D=0A=20=0D=0A=0D=0A_________________________________________= ______=0D=0A=0D=0AEcrit mailing list=0D=0A=0D=0AEcrit@ietf.org=0D=0A=0D=0Ah= ttps://www.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, 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 ------_=_NextPart_001_01C99D46.3B82EB7F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A<= head>=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

Hi Stephen,

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

 

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

A few errors and clarifications.

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

 

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

Cheers

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

James

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

 

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

-----Original Message-----
=0D=0AFrom: ecrit-bounces@= ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Edge,=0D=0AStephen=0D=0ASent: Wednesday, 4 March 2009 4:32 PM
=0D=0ATo: br@brianrosen.net=
=0D=0ACc: ECRIT
=0D=0ASubject: Re: [Ecrit] Comments on Framework Dra= ft

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

&nb= sp;

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

Brian

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

 <= /span>

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

Thanks for these well = considered responses. Below I am providing on an=0D=0Aitem by item basis, a= nd taking into account your responses, a few more reasons=0D=0Awhy the curr= ent Ecrit solution is unsuitable - or, if you prefer, less suitable=0D=0Ath= an the 3GPP/3GPP2 solution - for cellular networks.

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

1. Access to PSTN capable PSAPs

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

Assuming that the= best available solution for this currently is the ongoing=0D=0ANENA i2 sta= ndard (as you comment), then there are problems with providing=0D=0Alocatio= n for dispatch (initial and updated location). For example, the latest=0D=0A= i2.5 draft I have (December 2008) says that the VPC to LIS v3 interface is=0D= =0Abeing deprecated (thus not available), although this is the interface th= at the=0D=0AVPC would use to query location from the LIS.

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

 

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

[AJW] The V3= interface is not being=0D=0Adeprecated, what is being deprecated is the ol= d V3 schema and the rationale for=0D=0Athat is that it makes more sense to = re-use HELD (http://tools.ietf.org/html/draft-winterbottom-ge= opriv-deref-protocol-03)=0D=0Aan SIP for dereference protocols rather t= han reinventing the wheel.

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

 

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

Also I don't see any inclusion of accurate positioning supp= ort - e.g.=0D=0Ausing A-GPS. Further, interworking with the circuit mode si= de for UA access (as=0D=0Aopposed to PSAP access) seems to be out of scope.= So at best, this standard is=0D=0Aincomplete (i.e. not yet suitable for ce= llular networks). However, I agree that=0D=0Athere is some overlap between = i2.5 and the 3GPP/3GPP2 solution.

=0D=0A=0D=0A<= p class=3DMsoPlainText> 

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

[AJW] i2 does not=0D=0Apreclude the measurements being provid= ed by the Target device, or being=0D=0Arequested of the Target device by th= e LIS. There are a slew of contributions=0D=0Athat show how this can easily= be done using HELD.

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

 

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

2. Handover between different IP access networks including different=0D= =0Atypes of access network

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

One of the issues here would be change of LIS across differ= ent networks=0D=0Awhile avoiding impacts to both IP and PSTN capable PSAPs = (i.e. handover must be=0D=0Atransparent to PSAPs within the limitations imp= osed by SIP or some J-STD-036=0D=0Atype of circuit mode solution). The prob= lem gets more difficult when handover=0D=0Ato/from circuit mode access netw= orks is considered. So far, 3GPP/3GPP2 has not=0D=0Ayet agreed on a solutio= n although there are proposals and we expect some=0D=0Aresolution soon. On = the Ecrit and NENA sides, I see much less progress.

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

3. Handover to/from circuit mode netwo= rks

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

We agre= e here at least on the out of scope aspect. I suppose I can=0D=0Aaccept tha= t it is not customary to point this out in IETF standards. But I hope=0D=0A= you can see that this is an issue for cellular networks most of which will = have=0D=0Aextensive circuit mode coverage for a long time to come.

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

 

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

4. Location for cellula= r access (and the requirement to support LCPs=0D=0Athat will be useless for= cellular access)

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

The issue is not so much the LCP itself but the capability to suppor= t=0D=0Aaccurate positioning - e.g. using A-GPS, AFLT, OTDOA, enhanced cell = ID etc. None=0D=0Aof those methods seem to be supported as part of DHCP or = HELD right now. So=0D=0Asome modification of the LCP related requirements o= r of the LCPs seems needed.

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

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

[AJW] I will stress that=0D=0Aa number of these methods are network d= etermination methods and are dependent=0D=0Aon the location node accessing = these measurements from directly from the RAN.=0D=0AIn such cases anyone of= the LCPs described is just as capable of obtaining=0D=0Athese as any speci= fic 3G location node. For example, a device could launch a=0D=0AHELD reques= t to the LIS, and the LIS could request timing advance measurements=0D=0Afr= om the network, or use SRI/PSL to contact and SMLC. The determination=0D=0A= procedures are transparent and are equally applicable to an LCP as they are= to=0D=0A3GPP specific procedures.

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

 

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

= Let’s take a bit of=0D=0Aa = look at Target provided measurements. If my HELD-enable device were to=0D=0A= include let’s say relative delay measurements to the LIS in an access=0D= =0Anetwork, then the LIS can easily use these, since the LIS knows the loca= tions=0D=0Aof all the associated basestations. Now let’s compare this= to 3GPP=0D=0Auser-plane, where the SET would provide this information back= to a home-SLP, if=0D=0Athe SET is roaming what use are these measurements=3F= There are two options for=0D=0Ausing them, neither of which is overly sati= sfactory. The H-SLP can have a=0D=0Adatabase containing every single base s= tation on earth, and can attempt to use=0D=0Athem in that fashion, certainl= y some vendors are taking that approach, but it=0D=0Ais hardly workable in = the long term. Or, the H-SLP can find the SLP in the visited=0D=0Anetwork a= nd ask it to do the work for it. Certainly SUPL defines a protocol to=0D=0A= support the quest procedures for this, but is very conveniently puts out of=0D= =0Ascope how the H-SLP determines the correct V-SLP to contact. Indeed once= you=0D=0Amove to W-LAN this problem becomes intractable.=

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

 

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

Device prov= ided network=0D=0Ameasurements are only relevant in that access network and= this point is sadly=0D=0Amissed by the 3GPP adopted user-plane solution. <= o:p>

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

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

 To see how some of=0D=0Aplan to address you concerns of LCP pro= vided measurements please see:

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

R= 26;         =0D= =0Adraft-thomson-geopriv-held-measurements

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

•      &nb= sp;  =0D=0Adraft-thomson-geopriv-held-grip<= /b>

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

•      &= nbsp;  =0D=0Adraft-thomson-geopriv-held-capabilities

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

= •   &nb= sp;     =0D=0A<= ![endif]> 

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

 

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

 

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

5. Endpoint based location = and routing for cellular access (issues here=0D=0Aare network and device lo= ading as well as device impacts and problems with PSTN=0D=0Acapable PSAPs)<= o:p>

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

Endpoint base= d location when spread over millions (billions,=0D=0Aplanet-wide) of termin= als will consume significant network and terminal=0D=0Aresources.

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

 

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

[AJW] P= erhaps, but using an LCP this=0D=0Ais local traffic, in contrast with SUPL = ALL communication goes back to the=0D=0AH-SLP and this can be a long way aw= ay when the device is roaming.

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

 

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

A typical terminal is generally idle and interacts with= the network=0D=0Avery sparingly to update the network with its current loc= ation (e.g. current=0D=0Acluster of potential serving cells).

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

 

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

[AJW] A = location URI means that=0D=0Aunless the device changes access networks that= it does not need to perform this=0D=0Aupdate at all. When the device does = change access networks, it acquires a new=0D=0Alocation URI.

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

 

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

Performing network assiste= d periodic location fixes and LoST queries=0D=0Awould add significantly to = network load. Performing periodic location fixes in=0D=0Athe terminal (e.g.= using GPS) and estimating when a PSAP boundary may have been=0D=0Acrossed = would add to terminal load (e.g. thus battery drain).

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

 =

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

[AJW] In the mob= ile case I would=0D=0Aperform these operations at call time, and I certainl= y wouldn’t do a GPS=0D=0Afix as a rough location fix will be quite ad= equate for purposes of obtaining a=0D=0Arouting URI. In this case I could s= end a HELD request the LIS with a=0D=0AresponseTime=3DemergencyRouting. The= LIS can invoke techniques for enhanced cell=0D=0Aetc is that falls into cr= iteria set by the local jurisdiction, the device can=0D=0Athen do the lost = lookup using eh resulting location. It is certainly no less=0D=0Aefficient = for the device to do these operations than it is for the network to=0D=0Ado= them on behalf of the device, and it may be more efficient because these a= re=0D=0Alocal services. Ultimately the bandwidth is the same or less using = the ECRIT proposal=0D=0Afor call routing.

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

 

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

Optimizations would be possible of course - e.g. b= ased on observing=0D=0Anearby cell IDs - but they will add to terminal comp= lexity and testing costs. I=0D=0Aagree that the Ecrit solution does allow f= or proxies to do this but here the=0D=0Asolution also becomes incomplete be= cause there seem no details of how this=0D=0Awould work - e.g. what locatio= n solutions would then be used.

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

 

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

[AJW] I am sorry I don’t=0D=0Aund= erstand this comment. If we look at almost any cellular technology that I a= m=0D=0Aaware of the device is already aware of neighbouring cells, it has t= o be as=0D=0Apart of the general hand-over procedures. In GSM this informat= ion is included=0D=0Ain signal strength information already passed from the= handset to the network. In=0D=0AWiMAX this is done using relative delay me= asurements. Pick your network type,=0D=0Athere are equivalents. Nothing spe= cial needs to be done to the device to use=0D=0Athem. Any network that supp= orts a control-plane location architecture provides=0D=0Anative messaging f= or getting access to these measurements. This is handled in=0D=0Athe LIS an= d is totally transparent to the device, the device see normal network=0D=0A= procedures taking place.

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

 

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

Perhaps I have misunder= stood what you=0D=0Awere trying to say.

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

 

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

 

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

6. Support of unauthenticated users and users who can = be authenticated=0D=0Abut are not permitted access/VSP service except for e= mergency calls

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

I think the Ecrit solution and you both assume that this has already=0D= =0Abeen resolved somehow at the access level and therefore the various proc= edures=0D=0Ain Ecrit can still be used. Maybe that is valid. However, there= are still=0D=0Aproblems that are not covered in the Ecrit drafts but need = to be resolved=0D=0Aincluding (a) obtaining IP access (e.g. via a WLAN, cel= lular network, cable=0D=0Alink) when not a valid subscriber, (b) obtaining = access to the VSP and (c)=0D=0Aensuring only emergency related services are= provided (e.g. and not free=0D=0AInternet and location access). These and = additional problems (e.g. UA=0D=0Aidentification) would have to be solved, = maybe on a per access basis, and then=0D=0Aensured to be compatible with th= e rest of the Ecrit solution. A significant=0D=0Apart of the 3GPP/3GPP2 sol= ution is concerned with this aspect and it has=0D=0Adelayed completion of t= he solution for the more normal case of valid subscriber=0D=0Aaccess due to= such compatibility issues.

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

 

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

[AJW] Unauthenticated access is an interest= ing=0D=0Aanimal, and as you point out in an IP world this has several diffe= rent levels=0D=0Aon which it operates. There are a few points on this that = should be considered=0D=0Ahowever, and fist and foremost perhaps is the gro= wing number of countries at=0D=0Athat are disabling this functionality!

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

 

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

Another point of interest is that in=0D=0Acellu= lar this is already technologically challenged when it comes to this=0D=0Af= unction; devices that use different physical characteristic from the carrie= r=0D=0Anetwork cannot be accommodated by this service even if they both hav= e 3GPP=0D=0Acores.

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

 

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

Private IP networks are very co= mmon,=0D=0Aalmost very house has one, and a very large number have wireless= LANs. Conversely=0D=0Athere are very few private cellular networks. So I a= m not sure that a direct=0D=0Acomparison can be made here, certainly I don&= #8217;t intend to let just anyone=0D=0Aon to private home LAN just because = they claim they want to make an emergency call,=0D=0Ait is tantamount to my= simply placing a T-200 phone on my letterbox along with=0D=0Aa sign that s= ays emergency only.

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

 

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

There are thoughts on how to ad= dress=0D=0Asome of these issues in ECRIT, and you will have to forgive me b= ut I haven’t=0D=0Ahad time to address them in a draft yet, I do hope = to in the not too distant=0D=0Afuture.

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

 =

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

 =

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

 

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

Kind Regards

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

 

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

Stephen

=0D=0A=0D=0A-----Original Message-----=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>From: br@brianrosen.net [mailto:br@br= ianrosen.net]

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

Sent: Friday, February 27, 2009 6:53 AM

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

To: Edge, Stephen

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

Cc: Thomson, Martin; Richard=0D=0ABarnes; ECRIT

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

Subject: Re: [Ecrit] Comments on Framework Draft

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

 

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

Stephen

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

 

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

Like any standards organiz= ation, the IETF restricts it's scope.

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

Generally, the scope is "the Internet", = although we very=0D=0Aoften describe

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

solutions that are explicitly designed for private = IP networks as well=0D=0Aas

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

the Internet.  We don't write standards for circuit s= witched=0D=0Anetworks, and

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

it should be no surprise that the ecrit solution does not c= ater to CS

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

= = solutions.  Nevertheless, we often try to make sure that our=0D=0Asolu= tions

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

harmo= nize reasonably well with existing solutions.

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

 

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

Indeed, the ecrit solution clains global applicabi= lity to the Internet=0D=0Ain

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

general, and most private IP networks that can be interco= nnected to the

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

Internet or to other IP networks via gateways.  Looking at your=0D= =0Alist of

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

= = problem areas:

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

>   - access to PSTN capable PSAPs

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

seems straightforward to interw= ork ecrit compatible devices and=0D=0Anetworks

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

to existing CS connected PSAPs.  As y= ou know, CS interconnects are=0D=0Avery

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

nation-specific, so the NENA work may not have gen= eral applicability.

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

However, it shows that it is possible to interwork.  The NENA = i2=0D=0Awork is

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

also designed to take ecrit compatible devices and VSP networks, and

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

interwork the= m to the existing network.  The VSP would direct the=0D=0Acall to=

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

the VPC, which = would provide the services it does now, using the device<= /font>

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

provided location for routing= =2E  This is important for smooth=0D=0Atransition

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

from existing PSAPs and VSPs to= "next generation" PSAPs and=0D=0AVSPs.<= /p>=0D=0A=0D=0A

= >   - handover between = different IP access networks=0D=0Aincluding different

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

> types of access network

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

In the ecrit s= olution, the access network the call is initiated on

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

provides all the facilities neede= d for the device to initiate an=0D=0Aemergency

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

call.   The call starts traversi= ng it's normal call path, and=0D=0Aeventually

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

routes to the ESRP.  Handoffs between= IP networks should be=0D=0Atransparent to

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

this process, although we probably haven't done al= l the work we need to=0D=0Ado

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

for handoffs where the IP address as seen by the termina= ting network

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

changes.  This would generally be true of all current SIP based=0D=0A= work.

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

>&= nbsp;  - handover to/from circuit mode networks

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

This would be out of scope for IE= TF.  It's as applicable to a=0D=0Asimple SIP<= /p>=0D=0A=0D=0A

= call as it is a SIP emergency call, = and there are no statements in any=0D=0ASIP

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

documents on that subject.

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

>   - locatio= n for cellular access (and the requirement to=0D=0Asupport LCPs that

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

> will be usel= ess for cellular access)

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

Location for cellular access networks has been considered carefu= lly.

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

Since = cellular is a mobile network, the access network would pass the<= /span>

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

device a Location-By-R= eference URI, using either DHCP or HELD. =0D=0AEither

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

protocol is suitable for ce= llular networks.  As we have pointed=0D=0Aout=

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

several times, cellular networks su= pport raw data packet services upon

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

which many different kinds of networks can be const= ructed.  My=0D=0Ausual

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

example is a large recreational vehicle traveling down a r= oad with a

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

= = cellular data card plugged into a router to which a wired (Ethernet)=0D=0Ap= hone

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

is con= nected.  That phone must be able to make an emergency call,=0D=0Aand i= t

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

will get = location from DHCP or HELD (or LLDP-MED).  It is not=0D=0Aaware of the=

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

cellular n= etwork, and doesn't know any cellular specific protocols.=

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

Cellular networks will have = to support IETF location configuration

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

protocols unless they actively prohibit examples l= ike this, or they

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

implement interworking between cellular-specific location protocols = and

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

DHCP or= HELD in the data card.  The ecrit standards permit proxy=0D=0Ainserti= on

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

of locat= ion, but, as above, we don't think that works in all cases.

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

>   - endpoin= t based location and routing for cellular=0D=0Aaccess (issues here

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

> are network an= d device loading as well as device impacts and=0D=0Aproblems

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

> with PSTN capable PS= APs)

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

The &q= uot;load" of using DHCP or HELD to get location and querying=0D=0ALoST= is

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

pretty = modest.  The standards permit proxies to do this if the=0D=0Adevices

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

don't.  = As above, interwork functions to CS connected PSAPs is=0D=0Avery=

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

feasible, and as above= , cellular networks will have to support access=0D=0Ato

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

local LoST servers for devices= that are connected to cellular networks=0D=0Aand<= /p>=0D=0A=0D=0A

= are ecrit compliant.

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

>   - support= of unauthenticated users and users who can=0D=0Abe authenticated

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

> but are not permi= tted access/VSP service except for emergency=0D=0Acalls

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

This is covered in the standar= ds.  None of the processes are=0D=0Adependent on

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

authentication, although where i= t is possible, it's desirable so as to

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

minimize fraudulent emergency calls

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

Mechanisms for specific n= etwork authentication mechanisms are out of

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

scope, and, like SIP basic calling, are no= t usually mentioned in IETF

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

documents.

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

 

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

Stephen, we've tried pretty hard to make sure this works for 3G/= 4G=0D=0Amobile

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

networks.  It's true that it doesn't do it the way 3GPP currently=0D= =0Athinks

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

<= font size=3D2 face=3D"Courier New">i= t ought to work, but we claim they haven't thought through all the

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

issues.  While= it would work, there are opportunities for=0D=0Aimprovement.  We=

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

would be willin= g to do that if we could get the cooperation of 3GPP,=0D=0Awhich=

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

we have tried, and fai= led, to do.

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

 

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

So,= I think the documents do not need any qualification statements.=

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

 

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

Brian

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

 =

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

> Martin

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

= > 3GPP/3GPP2 access networks wher= e the serving network also acts as=0D=0Athe VSP)=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>> and the specifications for it co= ver in detail all possible=0D=0Ascenarios

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

> consistent with these restrictions so far as = we are aware.

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

> 

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

> The Ecrit solution seems to claim global applicability to all=0D=0A= types of IP

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

> access (and the more that is said about this from Ecrit=0D=0Aparticip= ants the

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

&g= t; more this gets emphasized) but does not cover in detail all=0D=0Apossibl= e

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

> scen= arios (in some cases does not cover in any detail) which means=0D=0Athat at=

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

> best = the solution is incomplete and at worst intrinsically=0D=0Ainapplicable to<= o:p>

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

> some uns= tated set of scenarios.

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

> 

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

> The missing, incomplete and problematic cases include the=0D= =0Afollowing:

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

> 

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

>   - access to PSTN capable PSAPs=

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

>   - handover between= different IP access networks=0D=0Aincluding different

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

> types of access network

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

> &nb= sp; - handover to/from circuit mode networks

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

>   - location for cellular a= ccess (and the requirement to=0D=0Asupport LCPs that

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

> will be useless for cellular= access)

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

&g= t;   - endpoint based location and routing for cellular=0D=0Aacce= ss (issues here

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

> are network and device loading as well as device impacts and=0D=0A= problems

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

&g= t; with PSTN capable PSAPs)

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

>   - support of unauthenticated users and us= ers who can=0D=0Abe authenticated

=0D=0A=0D=0A<= p class=3DMsoPlainText>> but are not permitted access/VSP service except= for emergency=0D=0Acalls

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

> 

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

> Stating that some of these cases are out of scope or refere= ncing=0D=0Aan

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

> incomplete and possibly questionable specification from some other<= o:p>

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

> national= SDO will not help the user who encounters such problems.=0D=0ABut it<= /o:p>

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

> would certa= inly help network operators and implementers to=0D=0Aacknowledge=

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

> their existence i= n one form or another because that would allow=0D=0Abetter

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

> planning of deployment= s and would help focus attention on finding

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

> solutions (whether in IETF or elsewhe= re) for the missing cases.

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

> 

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

> Please note that despite these drawbacks, I will ackno= wledge that=0D=0AEcrit

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

> does have a valuable solution that covers many scenarios no= t=0D=0Acovered by

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

> 3GPP/3GPP2. It would be the delineation of these supported=0D=0A= scenarios (or

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

> equivalently unsupported scenarios) in some applicability=0D=0Astat= ement that

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

= = > would be particularly useful right now.

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

> 

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

> Kind Regards=

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

> =

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

> Stephen

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

> -----Original Message-----

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

> From: Thomson, Martin=0D=0A[mailto:Mar= tin.Thomson@andrew.com]

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

> Sent: Thursday, February 26, 2009 9:45 PM=

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

> To: Edge, Stephen; Rich= ard Barnes

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

= = > Cc: ECRIT

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

> Subject: RE: [Ecrit] Comments on Framework Draft=

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

> =

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

> There's benefit in know= ing the limitations of a framework, and=0D=0Aevery=

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

> architecture makes certain ass= umptions.  Let's examine them=0D=0Athough...<= /p>=0D=0A=0D=0A

= > <= /p>=0D=0A=0D=0A

= > The IETF might occasionally mak= e the assumption that the standards=0D=0Ait

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

> develops are for Internet devices.&nb= sp; That assumption probably=0D=0Aneed not be

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

> stated explicitly.<= /font>

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

> <= /font>

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

> The ECRIT architecture r= elies on implementations of the protocols=0D=0Athat it

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

> references.  That is = not extraordinary.  A reliance on=0D=0Aimplementation of

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

> these protocols by = endpoints, routing intermediaries and PSAPs=0D=0Ashould not

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

> need to be explained.=

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

>&= nbsp;

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

> So th= e assumptions are:

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

>  - the Internet

=0D=0A=0D=0A<= p class=3DMsoPlainText>>  - solutions are implemented and deployed<= o:p>

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

>  - = the end device is a key component

=0D=0A=0D=0A<= p class=3DMsoPlainText>> 

=0D=0A=0D=0A<= p class=3DMsoPlainText>> Only that last element is particularly novel ..= =2E or not that much=0D=0Areally.

=0D=0A=0D=0A<= p class=3DMsoPlainText>>   It's a design choice.  Unless = you were thinking=0D=0Aof trunking the voice

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

> elsewhere.=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>> =0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>> Of course, you're suggesting tha= t the design choice was made in=0D=0Aignorance

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

> of all the constraints.  You're = suggesting that - as a result=0D=0A- the choice=0D=0A=0D=0A

> is flawed and the solution is not= going to work for cellular=0D=0Aservices.  We

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

= > network.

=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

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

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

>&= gt; From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=0D=0AOn Be= half

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

>&g= t; Of Edge, Stephen

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

>> Sent: Friday, 27 February 2009 3:30 PM

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

>> To: Richard Barnes

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

>> Cc: = 'ECRIT'

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

>= ;> Subject: Re: [Ecrit] Comments on Framework Draft

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

>> 

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

>> Hi Richard

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

>> = ;

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

>> Thank= s for the comments. Your statement below that "SIP=0D=0Aemergency=

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

>> callin= g works if all parties behave as specified in these=0D=0A(IETF Ecrit)<= /o:p>

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

>> documen= ts" to some degree highlights the problems we are=0D=0Araising. The

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

>> docu= ments do contain a number of implicit and explicit=0D=0Arestrictions -=

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

>> like I= P capable PSAPs, global IP access (no islands of circuit=0D=0Amode

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

>> access for= example), universal support of this solution by all=0D=0Aaccess=

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

>> providers and= VSPs (not much good if some opt for another=0D=0Asolution) and<= /span>

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

>> end system or= iented location and routing capability - which=0D=0Atogether

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

>> make them unsuit= able (we believe) for cellular wireless=0D=0Anetworks. If=

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

>> these restrictions = and assumptions were all made explicit=0D=0Aupfront, it

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

>> would to a large degr= ee (and possibly completely) address our=0D=0Aconcerns.

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

>> 

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

>> You are right in = assuming another set of specifications for=0D=0Athe 3GPP<= /font>

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

>> and 3GPP2 solution. = The applicability of this solution is=0D=0Aexplicitly

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

>> defined in TS 23.167 (o= r more exactly in an already agreed CR=0D=0Ain

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

>> contribution S2-090752 which will= become part of 23.167 in a=0D=0Afew more

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

>> weeks) to cover the following access type= s: GPRS (UTRAN=0D=0AWCDMA), I-WLAN,

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

>> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN = (WCDMA) and EPS=0D=0AE-UTRAN

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

>> (LTE). So there is a restriction and arbitrary i= nternet access=0D=0Ais not

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

>> covered (yet) as I have stated before.<= /span>

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

>> 

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

>> Kind Rega= rds

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

>>= ; 

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

>= ;> Stephen

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

>> -----Original Message-----

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

>> From: Richard Barnes [mailto:rbarnes@bbn.= com]

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

>&g= t; Sent: Wednesday, February 25, 2009 6:30 PM

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

>> To: Edge, Stephen

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

>> Cc: Brian Rosen; = 'ECRIT'

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

>= ;> Subject: Re: [Ecrit] Comments on Framework Draft

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

>> 

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

>> Hi Stephen,

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

>>&nbs= p;

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

>> I'm = a little confused by the scope of what you're=0D=0Aasking.  The

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

>> framewor= k

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

>> = and phonebcp documents exist in order to describe the ECRIT=0D=0Asolution:<= o:p>

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

>> They= say, in effect, "SIP emergency calling works if all=0D=0Aparties beha= ve

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

>>= as specified in these documents."

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

>> 

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

>> As I understand what you're saying (and I= 'm by no means an=0D=0Aexpert in

=0D=0A=0D=0A>> 3GPP), 3GPP specifies that one or more eleme= nts of this system=0D=0Abehave

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

>> differently.  This simply means that 3GPP= networks aren't=0D=0Acomplying

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

>> with

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

>> these specs.  Just like there's no di= sclaimer in RFC 791=0D=0A(IPv4) that

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

>> says "this doesn't work on X.25 netwo= rks", it's not=0D=0Aclear to me that an

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

>> analogous disclaimer is called fo= r here.

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

>= ;> 

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

>> I presume there are similar documents describing how emergency=0D= =0Acalling

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

= = >> works in 3GPP networks.  Do they include notes saying=0D=0Ath= at the 3GPP

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

>> solution doesn't work in the broader Internet=3F

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

>> 

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

>> --Richard=

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

>>&n= bsp;

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

>>=  

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

>><= o:p> 

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

>&= gt; 

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

<= font size=3D2 face=3D"Courier New">&= gt;> 

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

>> Edge, Stephen wrote:

=0D=0A=0D=0A>> > Brian

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

>> >

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

>> > First of all apologies for the likel= y lateness of this=0D=0Areply - I

=0D=0A=0D=0A<= p class=3DMsoPlainText>>> actually wrote it on 19 February in a 3GPP = SA2 meeting in Budapest but

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

>> it seems unlikely that my VPN, Outlook server and WiFi = access

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

>= > capability will cooperate together to get it sent until I=0D=0Areturn = to the

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

>= > office mid-next week.

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

>> >

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

>> > Anyhow thanks for your comments. There hav= e actually been=0D=0Aa number of

=0D=0A=0D=0A>> conference calls between IETF and 3GPP parti= cipants over the=0D=0Alast

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

>> couple of years at which common features like supp= ort of IP=0D=0Aemergency

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

>> calls were discussed and these could have been good for= um for

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

>= > participants on either side to have raised the kinds of issues=0D=0Ayo= u

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

>> = elaborate on below. Given that seems not so far to have happened,=0D=0Ait

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

>> coul= d still be possible in future such calls.

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

>> >

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

>> > But the issues we are raising are no= t directly to do with=0D=0Afurther

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

>> aligning the 2 solutions or with the lack = of this in the past.=0D=0AWe are

=0D=0A=0D=0A>> simply pointing out that the solutions are c= urrently different=0D=0Aand that

=0D=0A=0D=0A>> from a cellular wireless perspective, the Ec= rit solution is=0D=0Anot seen as

=0D=0A=0D=0A>> suitable in all respects (for support of IP = emergency calls=0D=0Aoriginating

=0D=0A=0D=0A>> from such access types). That is not just ou= r point of view.=0D=0A3GPP2 sent

=0D=0A=0D=0A>> a liaison to Ecrit some months ago pointing = out the same=0D=0Aissues.

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

>> >

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

>> > So we are proposing that the Ecrit framework and p= honeBCP=0D=0Aspec.s

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

>> include a statement acknowledging this - e.g. by referenci= ng=0D=0Athe

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

>> alternative 3GPP/3GPP2 solution and indicating the IP access=0D=0A= types for

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

<= font size=3D2 face=3D"Courier New">&= gt;> which the Ecrit solution will work without limitation (or=0D=0Aequi= valently

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

&g= t;> the access types where limitations are not ruled out).

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

>> >=

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

>> > We are n= ot proposing further modification and extension=0D=0Aof the Ecrit

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

>> solution - ju= st pointing out that this would be needed (as=0D=0Awith the

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

>> 3GPP/3GPP2 soluti= on) to fully cover all types of access.

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

>> >

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

>> > Kind Regards

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

>> > Stephen

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

>> > -----Ori= ginal Message-----

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

>> > From: Brian Rosen [mailto:br@brianrosen.net]

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

>> > Sent:= Wednesday, February 18, 2009 8:07 PM

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

>> > To: Edge, Stephen; 'ECRIT'

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

>> > Subject:= RE: [Ecrit] Comments on Framework Draft

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

>> >

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

>> > I have bit my tongue on this one for= a long time.

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

>> >

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

>> > Stephen, with respect, please go talk to 3GPP managem= ent=0D=0Aand ask them

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

>> why

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

>> > there has been no participation in the ecrit effor= t=0D=0Adespite multiple

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

>> YEARS

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

>> > of begging them to get involved.  To put it f= rankly,=0D=0A3GPP is quite

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

>> willing

=0D=0A=0D=0A>> > to bully IETF into doing its work on it= s schedule, but=0D=0Acannot be

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

>> bothered to

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

>> > get work done it knows it will event= ually have to do when=0D=0Athe IETF

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

>> asks it

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

>> > to do so.=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>>> >

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

>> They=

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

>> > know full well= that when they finally get around to=0D=0Adealing with PS

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

>> > terminated em= ergency calls, that there will be a lot of=0D=0Aresistance to

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

>> > changing f= ully specified and implemented standards to=0D=0Amore closely

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

>> align

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

>> > with 3GP= P standards.  I expect you will have several=0D=0Ainterworking

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

>> functions=

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

>> &= gt; to define and build.

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

>> >

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

>> > So, politely, please go away, we're finishing work= we=0D=0Adearly wanted

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

>> you all

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

>> > to be involved with for years, but you refus= ed to do=0D=0Aanything.  It's

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

>> too

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

>> > late for this rev.<= /font>

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

>> >

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

>> > Now, having = said that, there are quite a few people who=0D=0Ahave

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

>> participated in

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

>> > the = IETF work who are IMS aware and I believe that=0D=0Adespite your=

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

>> fears,

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

>> > eve= rything you need is in the specs.  The mechanisms=0D=0Awe have defined=

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

>> p= rovide

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

>= > > the ability for the network to insert location, recognize=0D=0Aan= d mark

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

>= > emergency

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

>> > calls, and route on behalf of endpoints.  An E-CSCF=0D= =0Acould quite

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

>> > straightforwardly provide a SIP call towards an ecrit=0D=0A= compatible

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

= = >> PSAP.  The

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

>> > only not-quite-nice interwork would be from SUPL t= o HELD=0D=0A(or SIP),

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

>> but it's

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

>> > pretty easy to do that.  I'll also not= e that we have=0D=0Atried to get OMA

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

>> and

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

>> > IETF to cooperate on location protoco= ls, but we have been

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

>> spectacularly

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

>> > unsuccessful at that effort also.

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

>> >=

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

>> > B= rian

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

>&g= t; >

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

>= ;> >

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

= = >> >

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

>> >> -----Original Message-----=0D=0A=0D=0A

>> >> From: ecrit-bounces@= ietf.org=0D=0A[mailto:ecrit-bounces@ietf.org] On=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>>> Behalf

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

>> >> Of Edge, Steph= en

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

>>= >> Sent: Thursday, February 05, 2009 2:50 AM

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

>> >&g= t; Subject: [Ecrit] Comments on Framework Draft=0D=0A=0D=0A

>> >>

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

>> >> All

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

>> >>=

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

>> >&g= t; draft-ietf-ecrit-framework-07 is (as we see it) a=0D=0Amostly informativ= e

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

>> = >> description of how terminals and networks should=0D=0Asupport emer= gency

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

>&= gt; >> calls made over IP capable facilities to IP capable=0D=0APSAPs= =2E It

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

>= > appears

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

>> >> intended to cover all types of access network -=0D=0Ain= cluding fixed

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

>> line,

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

>> >> WiFi and cellular (e.g. examples involving each ca= n=0D=0Abe found

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

>> throughout

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

>> >> the draft).

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

>> >>

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

>> >> When we evaluated this with resp= ect to support of=0D=0Awireless cellular

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

>> >> access and WiFi access associate= d with a cellular=0D=0Aoperator (e.g.

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

>> WLAN

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

>> >> or Femto cells integrated into a= cellular network),=0D=0Awe found that

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

>> >> certain portions of the draft ex= hibited one or more=0D=0Aof the following

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

>> >> characteristics:

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

>> >>

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

>> >>&n= bsp;    (A) Inconsistent with already=0D=0Astandardized wire= less solutions

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

>> >>

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

>> >>     (B) Inconsistent with=0D= =0Aessential wireless requirements and

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

>> >> conventions

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

>> >>

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

>> >> &= nbsp;   (C) Already part of wireless=0D=0Astandards or potentiall= y part of

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

<= font size=3D2 face=3D"Courier New">&= gt;> >> future standards

=0D=0A=0D=0A<= p class=3DMsoPlainText>>> >>

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

>> >> (A) refers to all portions of th= e draft framework=0D=0Athat differ from

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

>> the

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

>> >> requirements and procedures curr= ently standardized=0D=0Afor wireless

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

>> >> emergency access by 3GPP, 3GPP2 a= nd OMA. This is a=0D=0Aplain difference

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

>> of

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

>> >> solution and could be resolved th= rough support of=0D=0Aboth solutions by

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

>> >> terminals (with each solution be= ing used according to=0D=0Athe type of

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

>> >> access network and VSP) or could= be resolved by supporting=0D=0Aonly one

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

>> >> solution and accessing only the = types of network=0D=0Asupporting that

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

>> >> solution. To acknowledge this ca= tegory, the framework=0D=0Adocument could

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

>> >> reference the applicable wireles= s standards and point=0D=0Aout that these

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

>> >> are valid alternatives for wirel= ess cellular based=0D=0Aaccess.

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

>> >>

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

>> >> (B) refers to portions of the dr= aft that would be=0D=0Aunsuitable for

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

>> >> wireless networks even if no alt= ernative solution=0D=0Aexisted together

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

>> with

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

>> >> other portions missing from the = draft that would be=0D=0Aneeded to fully

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

>> >> support wireless networks. Examp= les of the former=0D=0Ainclude: (a)

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

>> emphasis

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

>> >> on endpoint derivation of locati= on, performance of=0D=0ALost query and

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

>> >> receipt of local dial strings; (= b) restriction of=0D=0ALCPs to protocols

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

>> >> that require terminal initiation= (not allowing for=0D=0Anetwork

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

>> initiation

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

>> >> as far as we can tell) and that = include two LCPs=0D=0A(DHCP and LLDP)

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

>> that

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

>> >> are not applicable to (not defin= ed for) cellular=0D=0Aaccess; and (c) the

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

>> >> requirement that a terminal or a= t least a LIS will=0D=0Aupdate the PSAP

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

>> >> whenever location changes. (a) i= s impractical due to=0D=0Anetwork and

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

>> >> terminal loading consequences an= d failure to support=0D=0Anon-IP capable

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

>> >> PSAPs; (b) makes location verifi= cation and updated=0D=0Alocation

=0D=0A=0D=0A>> provision

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

>> >> to PSAPs difficult or impossible= ; while (c) is also=0D=0Aincompatible

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

>> with

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

>> >> support of existing non-IP capab= le PSAPs besides=0D=0Aincreasing terminal

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

>> >> load and possibly interfering wi= th optimum=0D=0Amaintenance of the RF

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

>> >> connection (e.g. if a terminal h= as to tune away from=0D=0Athe serving

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

>> base

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

>> >> station or WLAN periodically to = make location=0D=0Ameasurements).

=0D=0A=0D=0A<= p class=3DMsoPlainText>>> Examples

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

>> >> of the latter include (d) absenc= e of support for=0D=0Aaccess to non-IP

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

>> >> capable PSAPs as already mention= ed (e.g. to support=0D=0AE911 phase 2 in

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

>> the

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

>> >> US); (e) no support for handover= from the IP to the=0D=0Acircuit domain

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

>> when

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

>> >> a terminal loses (e.g. moves out= of) RF coverage in=0D=0Athe IP domain;

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

>> and

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

>> >> (f) no allowance for limited acc= ess modes wherein a=0D=0Aterminal may

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

>> access

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

>> >> a network only to place an emerg= ency call with=0D=0Aensuing restrictions

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

>> on

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

>> >> (for example) location acquisitio= n, PSAP callback and=0D=0Acaller

=0D=0A=0D=0A>> >> verification and identification to = the PSAP. To=0D=0Aresolve this

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

>> category

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

>> >> either significant changes to th= e framework document=0D=0Acould be made

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

>> or a

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

>> >> disclaimer/applicability stateme= nt could be added=0D=0Astating that

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

>> support

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

>> >> of cellular wireless networks an= d their associated=0D=0AWLAN and Femto

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

>> >> access points is not covered.

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

>> >= >

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

>&g= t; >> Category (C) comprises concepts and capabilis in=0D=0Athe draft= that

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

>&= gt; are

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

>= ;> >> either already part of the standardized solution for=0D=0Awi= reless

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

>= > networks

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

>> >> or that might be added at a later time. Examples of=0D= =0Athe former

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

>> include

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

>> >> LoST, SIP location conveyance, general use of SIP= ,=0D=0Alocation for

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

>> routing

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

>> >> versus for dispatch, cellular positioning meth= ods.=0D=0AExamples of the

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

>> >> latter include use of location references and = dereferencing=0D=0Aand

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

>> >> possible interworking between the current wire= less=0D=0Anetwork solutions

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

>> >> (in 3GPP, 3GPP2 and OMA) and the solutio= n described=0D=0Ain this draft.

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

>> The

=0D=0A=0D=0A<= p class=3DMsoPlainText>>> >> presence of this category could be= acknowledged by=0D=0Afollowing the

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

>> >> disclaimer for (B) with a stateme= nt that certain=0D=0Aportions of the

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

>> >> solution are expected to be incor= porated into=0D=0Awireless networks now

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

>> >> and/or in the future.=

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

>> >>=

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

>> >&g= t; We hope that these comments will be seen to be a=0D=0Auseful addition to=

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

>> &= gt;> this review in the sense of enabling a more precise=0D=0Ascoping fo= r the

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

>&= gt; >> framework document and we are willing to assist in=0D=0Aprovid= ing wording

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

>> >> for any disclaimer/applicability statement that the=0D=0A= Ecrit working

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

>> group

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

>> >> may now deem fit to include.

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

>> >>

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

>> >> Kind Re= gards

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

>&= gt; >>

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

>> >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk=0D=0A= Burroughs

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

<= font size=3D2 face=3D"Courier New">&= gt;> (Qualcomm

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

>> >> 3GPP2 TSG-X and TSG-C participant)

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

>> >>

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

>> >> P= S  this being sent on 2/4/09 at 11:50pm PST=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>>> >>

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

>> >> ____________= ___________________________________

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

>> >> Ecrit mailing list

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

>> >> Ecrit@i= etf.org

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

>= ;> >> https://www.ietf.org/mailman/listinfo/ecrit

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

>> >

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

>> > __________= _____________________________________

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

>> > Ecrit mailing list=

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

>> > Ecrit@ietf.org=

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

>> &= gt; https://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A

>> >=

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

>> __________________________= _____________________

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

>> Ecrit mailing list

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

>> Ecrit@ietf.org=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>>> https://www.ietf.org/mailman= /listinfo/ecrit

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

> 

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

>=0D=0A------------------------------------------------------------= ------------------------------------

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

> This message is for the designated recipient o= nly and may

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

> contain privileged, proprietary, or otherwise private information.

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

> If you h= ave received it in error, please notify the sender=

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

> immediately and delete the ori= ginal.  Any unauthorized use of

=0D=0A=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=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>> Ecrit@ietf.org=

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

> https://www.ietf.org/ma= ilman/listinfo/ecrit

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

> 

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

 

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

_______________________________________________

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

Ecrit@ietf.org<= /span>

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

https://www.ietf.org/m= ailman/listinfo/ecrit

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

 

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


----------= ---------------------------------------------------------------------------= -----------
=0D=0AThis message is for the desig= nated recipient only and may
=0D=0Acontain priv= ileged, proprietary, or otherwise private informat= ion.  
=0D=0AIf you have received it = in error, please notify the sender
=0D=0Aimmedi= ately and delete the original.  Any unau= thorized use of
=0D=0Athis email is prohibited.=
=0D=0A-----------------------------------------------------------------= -------------------------------
=0D=0A[mf2]
=0D=0A=0D= =0A=0D=0A ------_=_NextPart_001_01C99D46.3B82EB7F-- From James.Winterbottom@andrew.com Wed Mar 4 20:12:59 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2392928C1CB for ; Wed, 4 Mar 2009 20:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.274 X-Spam-Level: X-Spam-Status: No, score=-1.274 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id houlO59WJr+J for ; Wed, 4 Mar 2009 20:12:54 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 8900428C197 for ; Wed, 4 Mar 2009 20:12:44 -0800 (PST) X-SEF-Processed: 5_0_0_910__2009_03_04_22_32_54 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 04 Mar 2009 22:32:51 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 22:13:08 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99D48.B0271445" Date: Wed, 4 Mar 2009 22:13:06 -0600 Message-ID: In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5374A197@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmY6xMaVsPKQOa6Rj2puYM6nfd6RAACFkpAARDTCVAAAJ6vQAACazkAAAEGgtA= References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com><64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net><7582BC68E4994F4ABF0BD4723975C3FA0D39534E@crexc41p> <1288E74A73964940B132A0B9EA8D8ABC5374A196@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5374A197@NASANEXMB04.na.qualcomm.com> From: "Winterbottom, James" To: "Edge, Stephen" , "Stark, Barbara" , X-OriginalArrivalTime: 05 Mar 2009 04:13:08.0457 (UTC) FILETIME=[B0B41D90:01C99D48] X-Mailman-Approved-At: Thu, 05 Mar 2009 05:35:55 -0800 Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 04:12:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99D48.B0271445 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stephen,=0D=0A=0D=0A=20=0D=0A=0D=0AThankyou for you comments.=0D=0A=0D=0A= A few in response inline.=0D=0A=0D=0A=20=0D=0A=0D=0ACheers=0D=0A=0D=0AJames=0D= =0A=0D=0A=20=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Edge, Stephen= [mailto:sedge@qualcomm.com]=20=0D=0ASent: Thursday, 5 March 2009 2:55 PM=0D= =0ATo: Winterbottom, James; Stark, Barbara; br@brianrosen.net=0D=0ACc: ECRI= T=0D=0ASubject: RE: [Ecrit] Comments on Framework Draft=0D=0A=0D=0A=20=0D=0A=0D= =0AHi James=0D=0A=0D=0A=20=0D=0A=0D=0AThanks for these comments.=0D=0A=0D=0A= =20=0D=0A=0D=0AI assume you recall that SUPL would use an E-SLP located in = the serving=0D=0A3GPP/3GPP2 network in case of combined access and VSP supp= ort. There are=0D=0Athen no roaming or global database issues as all locati= on is supported=0D=0Awithin the serving network.=20=0D=0A=0D=0A=20=0D=0A=0D= =0A[AJW] You are quite correct, the E-SLP is the node that would be used.=0D= =0AJust to point out though that there are no SETs currently that support=0D= =0Athe large number of E-SLP certificates required to make this solution=0D= =0Aworkable, since the SET is not allowed to respond to an SLP that it=0D=0A= cannot authenticate. I certainly think it remains to be seen is the=0D=0Acu= rrently proposed E-SLP trust model is workable on a large scale.=0D=0A=0D=0A= =20=0D=0A=0D=0ARecall that you are claiming that the current Ecrit solution= minus SUPL=0D=0Ais suitable for this case which will be by far the most co= mmon one for=0D=0Aemergency calls made via cellular networks. So I still as= k you to=0D=0Ajustify why mandating support for DHCP and HELD and not inclu= ding SUPL=0D=0Ais a suitable solution.=0D=0A=0D=0A=20=0D=0A=0D=0A[AJW] Ther= e are no SUPL 2.0 deployments at this stage, and SUPL 1.0 is=0D=0Anot suita= ble for emergency services. So nobody is making SUPL emergency=0D=0Acalls a= t this stage. I do however know of i2 and i3/ECRIT trials that=0D=0Aare cur= rently in progress where devices are obtaining location=0D=0Ainformation fr= om a LIS.=0D=0A=0D=0A=20=0D=0A=0D=0AFor other scenarios not involving cellu= lar access or where the cellular=0D=0Acarrier is used only as an ISP, SUPL = can still be suitable. For example,=0D=0Ait is not true that a worldwide de= tailed database would be needed (e.g.=0D=0Acontaining the cell IDs of netwo= rks). A-GPS and A-GNSS can work quite=0D=0Awell using fairly coarse locatio= n information (e.g. country or network=0D=0Aidentification) to seed assista= nce data and such coarse location=0D=0Ainformation can be obtained by a num= ber of means (e.g. IP address,=0D=0Acountry/network portions of a cell ID, = previous location estimate).=0D=0A=0D=0A=20=0D=0A=0D=0A[AJW] This can work = outside quite well I agree, although I am not aware=0D=0Aof devices being a= ble to converge on a location fast enough so that it=0D=0Acan be used at ca= ll time to assist with routing. I think that you will=0D=0Aalso agree that = using coarse-level assistance data to requires=0D=0Asignificantly more powe= r usage by the mobile than it were simply=0D=0Aprovided with acquisition as= sistance. This latter information cannot be=0D=0Aprovided without a finer-g= rained seed location as a reference point.=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D= =0A=0D=0A=20=0D=0A=0D=0AKind Regards=0D=0A=0D=0A=20=0D=0A=0D=0AStephen=0D=0A=0D= =0A-----Original Message-----=0D=0A=0D=0AFrom: Winterbottom, James [mailto:= James.Winterbottom@andrew.com]=0D=0A=0D=0ASent: Wednesday, March 04, 2009 7= :02 PM=0D=0A=0D=0ATo: Edge, Stephen; Stark, Barbara; br@brianrosen.net=0D=0A=0D= =0ACc: ECRIT=0D=0A=0D=0ASubject: RE: [Ecrit] Comments on Framework Draft=0D= =0A=0D=0A=20=0D=0A=0D=0AHi Stephen,=0D=0A=0D=0A=20=0D=0A=0D=0ASUPL has one = very huge disadvantage, it mandates the use of a home SLP.=0D=0A=0D=0ASUPL = roaming between carriers is basically unimplementable. The=0D=0A=0D=0Amecha= nisms required to support an H-SLP determining the V-SLP address=0D=0A=0D=0A= are deliberately left out of scope by OMA, and large numbers of=0D=0A=0D=0A= companies are busily putting IPR on the ways in which this can occur.=0D=0A=0D= =0AThere are no large-scale deployments of RLP that I am aware of, and this=0D= =0A=0D=0Ais a clear indicator of how bad the currently proposed architectur= e is.=0D=0A=0D=0A=20=0D=0A=0D=0AAll this means that for SUPL to be deployab= le on a large scale any H-SLP=0D=0A=0D=0Asimply has to have the entire worl= d in a database. This is abundantly=0D=0A=0D=0Aevident when you look at sys= tems like the global Nokia solution. I think=0D=0A=0D=0Athat this is mammot= h task to maintain for general cell coverage, on a=0D=0A=0D=0Aglobal basis = when you include W-LAN and femto-cells it is quite simply=0D=0A=0D=0Aridicu= lous.=0D=0A=0D=0A=20=0D=0A=0D=0AThe result is that SUPL is next to useless = as a solution for anything=0D=0A=0D=0Aother than providing basic-cell locat= ion or assistance data for GPS. It=0D=0A=0D=0Ais not local in the same sens= e that an LCP is. All of the other=0D=0A=0D=0Adetermination mechanisms that= you described in your previous email=0D=0A=0D=0Asimply don't work in SUPL = to any reasonable degree, and I would argue=0D=0A=0D=0Adon't work at all on= ce the device in a foreign network.=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=20=0D=0A=0D=0A-----Origi= nal Message-----=0D=0A=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-boun= ces@ietf.org] On Behalf=0D=0A=0D=0AOf Edge, Stephen=0D=0A=0D=0ASent: Thursd= ay, 5 March 2009 1:20 PM=0D=0A=0D=0ATo: Stark, Barbara; br@brianrosen.net=0D= =0A=0D=0ACc: ECRIT=0D=0A=0D=0ASubject: Re: [Ecrit] Comments on Framework Dr= aft=0D=0A=0D=0A=20=0D=0A=0D=0ABarbara and others=0D=0A=0D=0A=20=0D=0A=0D=0A= Thanks for the comments.=0D=0A=0D=0A=20=0D=0A=0D=0AWhen I look at the Phone= BCP I see that both HELD and DHCP are mandatory=0D=0A=0D=0Afor the device w= hereas at least one of these is mandatory for the AN.=0D=0A=0D=0AWhile I ca= n also see that SUPL is not ruled out (though it is not=0D=0A=0D=0Amentione= d or referenced), it appears to have been displaced by the HELD=0D=0A=0D=0A= and DHCP requirements. On the other hand, many cellular networks have=0D=0A=0D= =0Aalready deployed or are in the process of deploying SUPL and I am not=0D= =0A=0D=0Aaware of any that have deployed an accurate location capability us= ing=0D=0A=0D=0AHELD or DHCP. So I would like to know how you see the curren= t=0D=0A=0D=0Arequirements as being suitable - after all, they imply at the = very least=0D=0A=0D=0Aadditional development and deployment on the part of = network and device=0D=0A=0D=0Avendors and network operators, whereas if SUP= L was one of the defined=0D=0A=0D=0ALCPs, that additional development and d= eployment might be mostly=0D=0A=0D=0Aavoided. This question would not be ap= plicable with some additional=0D=0A=0D=0Ascope limitation and so I had not = previously raised it. But it is=0D=0A=0D=0Acertainly applicable in=0D=0A=0D= =0A the context of the global scope that is being claimed by some=0D=0A=0D=0A= responders.=0D=0A=0D=0A=20=0D=0A=0D=0AKind Regards=0D=0A=0D=0A=20=0D=0A=0D=0A= Stephen=0D=0A=0D=0A-----Original Message-----=0D=0A=0D=0AFrom: Stark, Barba= ra [mailto:bs7652@att.com]=0D=0A=0D=0ASent: Friday, February 27, 2009 8:28 = AM=0D=0A=0D=0ATo: br@brianrosen.net; Edge, Stephen=0D=0A=0D=0ACc: ECRIT=0D=0A=0D= =0ASubject: RE: [Ecrit] Comments on Framework Draft=0D=0A=0D=0A=20=0D=0A=0D= =0AThank you Brian. This is well said [except you left out the fact that=0D= =0A=0D=0Aecrit also allows for devices to get their location through other=0D= =0A=0D=0Amechanisms, such as GPS, SUPL, or other methods, and doesn't insis= t that=0D=0A=0D=0Athe location be configured through DHCP or HELD].=0D=0A=0D= =0A=20=0D=0A=0D=0AI agree 100% that additional qualifications are unnecessa= ry. Service=0D=0A=0D=0Aproviders, vendors, national bodies dealing with eme= rgency services, and=0D=0A=0D=0Aregulators aren't stupid. Please trust us t= o figure out for ourselves=0D=0A=0D=0Awhen/where/how to apply a "standard".= There is no need to try to=0D=0A=0D=0Aartificially limit or define scope, = or to state the obvious (e.g., the=0D=0A=0D=0Aarchitecture applies where it= applies, and doesn't apply where it=0D=0A=0D=0Adoesn't apply). We understa= nd the role and scope of the IETF, and the=0D=0A=0D=0Arole and scope of 3GP= P and 3GPP2. And all the other SDOs (and national=0D=0A=0D=0Abodies and reg= ulatory agencies). SDOs need to offer architectures that=0D=0A=0D=0Aapply w= ithin the area of applicability for that SDO, and are useful to=0D=0A=0D=0A= potential implementers, and leave it to the SPs, national bodies and=0D=0A=0D= =0Aregulators to decide which architectures and standards to use or to=0D=0A=0D= =0Amandate within the scope of their network or jurisdiction. Again, we=0D=0A=0D= =0Aaren't stupid.=0D=0A=0D=0ABarbara=0D=0A=0D=0A=20=0D=0A=0D=0A-----Origina= l Message-----=0D=0A=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounce= s@ietf.org] On Behalf=0D=0A=0D=0AOf br@brianrosen.net=0D=0A=0D=0ASent: Frid= ay, February 27, 2009 9:53 AM=0D=0A=0D=0ATo: Edge, Stephen=0D=0A=0D=0ACc: E= CRIT=0D=0A=0D=0ASubject: Re: [Ecrit] Comments on Framework Draft=0D=0A=0D=0A= =20=0D=0A=0D=0AStephen=0D=0A=0D=0A=20=0D=0A=0D=0ALike any standards organiz= ation, the IETF restricts it's scope.=0D=0A=0D=0AGenerally, the scope is "t= he Internet", although we very often describe=0D=0A=0D=0Asolutions that are= explicitly designed for private IP networks as well=0D=0A=0D=0Aas=0D=0A=0D= =0Athe Internet. We don't write standards for circuit switched networks,=0D= =0A=0D=0Aand=0D=0A=0D=0Ait should be no surprise that the ecrit solution do= es not cater to CS=0D=0A=0D=0Asolutions. Nevertheless, we often try to mak= e sure that our solutions=0D=0A=0D=0Aharmonize reasonably well with existin= g solutions.=0D=0A=0D=0A=20=0D=0A=0D=0AIndeed, the ecrit solution clains gl= obal applicability to the Internet=0D=0A=0D=0Ain=0D=0A=0D=0Ageneral, and mo= st private IP networks that can be interconnected to the=0D=0A=0D=0AInterne= t or to other IP networks via gateways. Looking at your list of=0D=0A=0D=0A= problem areas:=0D=0A=0D=0A> - access to PSTN capable PSAPs=0D=0A=0D=0AThi= s is out of scope for IETF. NENA has active work on this subject.=0D=0A=0D= =0AIt=0D=0A=0D=0Aseems straightforward to interwork ecrit compatible device= s and networks=0D=0A=0D=0Ato existing CS connected PSAPs. As you know, CS = interconnects are very=0D=0A=0D=0Anation-specific, so the NENA work may not= have general applicability.=0D=0A=0D=0AHowever, it shows that it is possib= le to interwork. The NENA i2 work is=0D=0A=0D=0Aalso designed to take ecri= t compatible devices and VSP networks, and=0D=0A=0D=0Ainterwork them to the= existing network. The VSP would direct the call=0D=0A=0D=0Ato=0D=0A=0D=0A= the VPC, which would provide the services it does now, using the device=0D=0A=0D= =0Aprovided location for routing. This is important for smooth transition=0D= =0A=0D=0Afrom existing PSAPs and VSPs to "next generation" PSAPs and VSPs.=0D= =0A=0D=0A> - handover between different IP access networks including diff= erent=0D=0A=0D=0A> types of access network=0D=0A=0D=0AIn the ecrit solution= , the access network the call is initiated on=0D=0A=0D=0Aprovides all the f= acilities needed for the device to initiate an=0D=0A=0D=0Aemergency=0D=0A=0D= =0Acall. The call starts traversing it's normal call path, and eventually=0D= =0A=0D=0Aroutes to the ESRP. Handoffs between IP networks should be transp= arent=0D=0A=0D=0Ato=0D=0A=0D=0Athis process, although we probably haven't d= one all the work we need to=0D=0A=0D=0Ado=0D=0A=0D=0Afor handoffs where the= IP address as seen by the terminating network=0D=0A=0D=0Achanges. This wo= uld generally be true of all current SIP based work.=0D=0A=0D=0A> - hando= ver to/from circuit mode networks=0D=0A=0D=0AThis would be out of scope for= IETF. It's as applicable to a simple SIP=0D=0A=0D=0Acall as it is a SIP e= mergency call, and there are no statements in any=0D=0A=0D=0ASIP=0D=0A=0D=0A= documents on that subject.=0D=0A=0D=0A> - location for cellular access (a= nd the requirement to support LCPs=0D=0A=0D=0Athat=0D=0A=0D=0A> will be use= less for cellular access)=0D=0A=0D=0ALocation for cellular access networks = has been considered carefully.=0D=0A=0D=0ASince cellular is a mobile networ= k, the access network would pass the=0D=0A=0D=0Adevice a Location-By-Refere= nce URI, using either DHCP or HELD. Either=0D=0A=0D=0Aprotocol is suitable= for cellular networks. As we have pointed out=0D=0A=0D=0Aseveral times, c= ellular networks support raw data packet services upon=0D=0A=0D=0Awhich man= y different kinds of networks can be constructed. My usual=0D=0A=0D=0Aexam= ple is a large recreational vehicle traveling down a road with a=0D=0A=0D=0A= cellular data card plugged into a router to which a wired (Ethernet)=0D=0A=0D= =0Aphone=0D=0A=0D=0Ais connected. That phone must be able to make an emerg= ency call, and it=0D=0A=0D=0Awill get location from DHCP or HELD (or LLDP-M= ED). It is not aware of=0D=0A=0D=0Athe=0D=0A=0D=0Acellular network, and do= esn't know any cellular specific protocols.=0D=0A=0D=0ACellular networks wi= ll have to support IETF location configuration=0D=0A=0D=0Aprotocols unless = they actively prohibit examples like this, or they=0D=0A=0D=0Aimplement int= erworking between cellular-specific location protocols and=0D=0A=0D=0ADHCP = or HELD in the data card. The ecrit standards permit proxy=0D=0A=0D=0Ainse= rtion=0D=0A=0D=0Aof location, but, as above, we don't think that works in a= ll cases.=0D=0A=0D=0A> - endpoint based location and routing for cellular= access (issues=0D=0A=0D=0Ahere=0D=0A=0D=0A> are network and device loading= as well as device impacts and problems=0D=0A=0D=0A> with PSTN capable PSAP= s)=0D=0A=0D=0AThe "load" of using DHCP or HELD to get location and querying= LoST is=0D=0A=0D=0Apretty modest. The standards permit proxies to do this= if the devices=0D=0A=0D=0Adon't. As above, interwork functions to CS conn= ected PSAPs is very=0D=0A=0D=0Afeasible, and as above, cellular networks wi= ll have to support access to=0D=0A=0D=0Alocal LoST servers for devices that= are connected to cellular networks=0D=0A=0D=0Aand=0D=0A=0D=0Aare ecrit com= pliant.=0D=0A=0D=0A> - support of unauthenticated users and users who can= be=0D=0A=0D=0Aauthenticated=0D=0A=0D=0A> but are not permitted access/VSP = service except for emergency calls=0D=0A=0D=0AThis is covered in the standa= rds. None of the processes are dependent=0D=0A=0D=0Aon=0D=0A=0D=0Aauthenti= cation, although where it is possible, it's desirable so as to=0D=0A=0D=0Am= inimize fraudulent emergency calls=0D=0A=0D=0AMechanisms for specific netwo= rk authentication mechanisms are out of=0D=0A=0D=0Ascope, and, like SIP bas= ic calling, are not usually mentioned in IETF=0D=0A=0D=0Adocuments.=0D=0A=0D= =0A=20=0D=0A=0D=0AStephen, we've tried pretty hard to make sure this works = for 3G/4G=0D=0A=0D=0Amobile=0D=0A=0D=0Anetworks. It's true that it doesn't= do it the way 3GPP currently thinks=0D=0A=0D=0Ait ought to work, but we cl= aim they haven't thought through all the=0D=0A=0D=0Aissues. While it would= work, there are opportunities for improvement.=0D=0A=0D=0AWe=0D=0A=0D=0Awo= uld be willing to do that if we could get the cooperation of 3GPP,=0D=0A=0D= =0Awhich=0D=0A=0D=0Awe have tried, and failed, to do.=0D=0A=0D=0A=20=0D=0A=0D= =0ASo, I think the documents do not need any qualification statements.=0D=0A=0D= =0A=20=0D=0A=0D=0ABrian=0D=0A=0D=0A=20=0D=0A=0D=0A> Martin=0D=0A=0D=0A>=20=0D= =0A=0D=0A> The 3GPP/3GPP2 solution has a defined restricted applicability (= mainly=0D=0A=0D=0Ato=0D=0A=0D=0A> 3GPP/3GPP2 access networks where the serv= ing network also acts as the=0D=0A=0D=0AVSP)=0D=0A=0D=0A> and the specifica= tions for it cover in detail all possible scenarios=0D=0A=0D=0A> consistent= with these restrictions so far as we are aware.=0D=0A=0D=0A>=20=0D=0A=0D=0A= > The Ecrit solution seems to claim global applicability to all types of=0D= =0A=0D=0AIP=0D=0A=0D=0A> access (and the more that is said about this from = Ecrit participants=0D=0A=0D=0Athe=0D=0A=0D=0A> more this gets emphasized) b= ut does not cover in detail all possible=0D=0A=0D=0A> scenarios (in some ca= ses does not cover in any detail) which means=0D=0A=0D=0Athat at=0D=0A=0D=0A= > best the solution is incomplete and at worst intrinsically=0D=0A=0D=0Aina= pplicable to=0D=0A=0D=0A> some unstated set of scenarios.=0D=0A=0D=0A>=20=0D= =0A=0D=0A> The missing, incomplete and problematic cases include the follow= ing:=0D=0A=0D=0A>=20=0D=0A=0D=0A> - access to PSTN capable PSAPs=0D=0A=0D= =0A> - handover between different IP access networks including different=0D= =0A=0D=0A> types of access network=0D=0A=0D=0A> - handover to/from circui= t mode networks=0D=0A=0D=0A> - location for cellular access (and the requ= irement to support LCPs=0D=0A=0D=0Athat=0D=0A=0D=0A> will be useless for ce= llular access)=0D=0A=0D=0A> - endpoint based location and routing for cel= lular access (issues=0D=0A=0D=0Ahere=0D=0A=0D=0A> are network and device lo= ading as well as device impacts and problems=0D=0A=0D=0A> with PSTN capable= PSAPs)=0D=0A=0D=0A> - support of unauthenticated users and users who can= be=0D=0A=0D=0Aauthenticated=0D=0A=0D=0A> but are not permitted access/VSP = service except for emergency calls=0D=0A=0D=0A>=20=0D=0A=0D=0A> Stating tha= t some of these cases are out of scope or referencing an=0D=0A=0D=0A> incom= plete and possibly questionable specification from some other=0D=0A=0D=0A> = national SDO will not help the user who encounters such problems. But=0D=0A=0D= =0Ait=0D=0A=0D=0A> would certainly help network operators and implementers = to acknowledge=0D=0A=0D=0A> their existence in one form or another because = that would allow better=0D=0A=0D=0A> planning of deployments and would help= focus attention on finding=0D=0A=0D=0A> solutions (whether in IETF or else= where) for the missing cases.=0D=0A=0D=0A>=20=0D=0A=0D=0A> Please note that= despite these drawbacks, I will acknowledge that=0D=0A=0D=0AEcrit=0D=0A=0D= =0A> does have a valuable solution that covers many scenarios not covered=0D= =0A=0D=0Aby=0D=0A=0D=0A> 3GPP/3GPP2. It would be the delineation of these s= upported scenarios=0D=0A=0D=0A(or=0D=0A=0D=0A> equivalently unsupported sce= narios) in some applicability statement=0D=0A=0D=0Athat=0D=0A=0D=0A> would = be particularly useful right now.=0D=0A=0D=0A>=20=0D=0A=0D=0A> Kind Regards=0D= =0A=0D=0A>=20=0D=0A=0D=0A> Stephen=0D=0A=0D=0A> -----Original Message-----=0D= =0A=0D=0A> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=0D=0A=0D= =0A> Sent: Thursday, February 26, 2009 9:45 PM=0D=0A=0D=0A> To: Edge, Steph= en; Richard Barnes=0D=0A=0D=0A> Cc: ECRIT=0D=0A=0D=0A> Subject: RE: [Ecrit]= Comments on Framework Draft=0D=0A=0D=0A>=20=0D=0A=0D=0A> There's benefit i= n knowing the limitations of a framework, and every=0D=0A=0D=0A> architectu= re makes certain assumptions. Let's examine them though...=0D=0A=0D=0A> =0D= =0A=0D=0A> The IETF might occasionally make the assumption that the standar= ds it=0D=0A=0D=0A> develops are for Internet devices. That assumption prob= ably need not=0D=0A=0D=0Abe=0D=0A=0D=0A> stated explicitly.=0D=0A=0D=0A> =0D= =0A=0D=0A> The ECRIT architecture relies on implementations of the protocol= s that=0D=0A=0D=0Ait=0D=0A=0D=0A> references. That is not extraordinary. = A reliance on implementation=0D=0A=0D=0Aof=0D=0A=0D=0A> these protocols by = endpoints, routing intermediaries and PSAPs should=0D=0A=0D=0Anot=0D=0A=0D=0A= > need to be explained.=0D=0A=0D=0A>=20=0D=0A=0D=0A> So the assumptions are= :=0D=0A=0D=0A> - the Internet=0D=0A=0D=0A> - solutions are implemented an= d deployed=0D=0A=0D=0A> - the end device is a key component=0D=0A=0D=0A> =0D= =0A=0D=0A> Only that last element is particularly novel ... or not that muc= h=0D=0A=0D=0Areally.=0D=0A=0D=0A> It's a design choice. Unless you were = thinking of trunking the=0D=0A=0D=0Avoice=0D=0A=0D=0A> elsewhere.=0D=0A=0D=0A= >=20=0D=0A=0D=0A> Of course, you're suggesting that the design choice was m= ade in=0D=0A=0D=0Aignorance=0D=0A=0D=0A> of all the constraints. You're su= ggesting that - as a result - the=0D=0A=0D=0Achoice=0D=0A=0D=0A> is flawed = and the solution is not going to work for cellular services.=0D=0A=0D=0AWe=0D= =0A=0D=0A> disagree. The solution is a basis for emergency calling in _any= _ IP=0D=0A=0D=0A> network.=0D=0A=0D=0A>=20=0D=0A=0D=0A> Cheers,=0D=0A=0D=0A= > Martin=0D=0A=0D=0A>=20=0D=0A=0D=0A>=20=0D=0A=0D=0A>> -----Original Messag= e-----=0D=0A=0D=0A>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@iet= f.org] On=0D=0A=0D=0ABehalf=0D=0A=0D=0A>> Of Edge, Stephen=0D=0A=0D=0A>> Se= nt: Friday, 27 February 2009 3:30 PM=0D=0A=0D=0A>> To: Richard Barnes=0D=0A=0D= =0A>> Cc: 'ECRIT'=0D=0A=0D=0A>> Subject: Re: [Ecrit] Comments on Framework = Draft=0D=0A=0D=0A>>=20=0D=0A=0D=0A>> Hi Richard=0D=0A=0D=0A>>=20=0D=0A=0D=0A= >> Thanks for the comments. Your statement below that "SIP emergency=0D=0A=0D= =0A>> calling works if all parties behave as specified in these (IETF=0D=0A=0D= =0AEcrit)=0D=0A=0D=0A>> documents" to some degree highlights the problems w= e are raising. The=0D=0A=0D=0A>> documents do contain a number of implicit = and explicit restrictions -=0D=0A=0D=0A>> like IP capable PSAPs, global IP = access (no islands of circuit mode=0D=0A=0D=0A>> access for example), unive= rsal support of this solution by all access=0D=0A=0D=0A>> providers and VSP= s (not much good if some opt for another solution)=0D=0A=0D=0Aand=0D=0A=0D=0A= >> end system oriented location and routing capability - which together=0D=0A=0D= =0A>> make them unsuitable (we believe) for cellular wireless networks. If=0D= =0A=0D=0A>> these restrictions and assumptions were all made explicit upfro= nt, it=0D=0A=0D=0A>> would to a large degree (and possibly completely) addr= ess our=0D=0A=0D=0Aconcerns.=0D=0A=0D=0A>>=20=0D=0A=0D=0A>> You are right i= n assuming another set of specifications for the 3GPP=0D=0A=0D=0A>> and 3GP= P2 solution. The applicability of this solution is explicitly=0D=0A=0D=0A>>= defined in TS 23.167 (or more exactly in an already agreed CR in=0D=0A=0D=0A= >> contribution S2-090752 which will become part of 23.167 in a few more=0D= =0A=0D=0A>> weeks) to cover the following access types: GPRS (UTRAN WCDMA),=0D= =0A=0D=0AI-WLAN,=0D=0A=0D=0A>> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (W= CDMA) and EPS E-UTRAN=0D=0A=0D=0A>> (LTE). So there is a restriction and ar= bitrary internet access is not=0D=0A=0D=0A>> covered (yet) as I have stated= before.=0D=0A=0D=0A>>=20=0D=0A=0D=0A>> Kind Regards=0D=0A=0D=0A>>=20=0D=0A=0D= =0A>> Stephen=0D=0A=0D=0A>> -----Original Message-----=0D=0A=0D=0A>> From: = Richard Barnes [mailto:rbarnes@bbn.com]=0D=0A=0D=0A>> Sent: Wednesday, Febr= uary 25, 2009 6:30 PM=0D=0A=0D=0A>> To: Edge, Stephen=0D=0A=0D=0A>> Cc: Bri= an Rosen; 'ECRIT'=0D=0A=0D=0A>> Subject: Re: [Ecrit] Comments on Framework = Draft=0D=0A=0D=0A>>=20=0D=0A=0D=0A>> Hi Stephen,=0D=0A=0D=0A>>=20=0D=0A=0D=0A= >> I'm a little confused by the scope of what you're asking. The=0D=0A=0D=0A= >> framework=0D=0A=0D=0A>> and phonebcp documents exist in order to describ= e the ECRIT solution:=0D=0A=0D=0A>> They say, in effect, "SIP emergency cal= ling works if all parties=0D=0A=0D=0Abehave=0D=0A=0D=0A>> as specified in t= hese documents."=0D=0A=0D=0A>>=20=0D=0A=0D=0A>> As I understand what you're= saying (and I'm by no means an expert in=0D=0A=0D=0A>> 3GPP), 3GPP specifi= es that one or more elements of this system behave=0D=0A=0D=0A>> differentl= y. This simply means that 3GPP networks aren't complying=0D=0A=0D=0A>> wit= h=0D=0A=0D=0A>> these specs. Just like there's no disclaimer in RFC 791 (I= Pv4) that=0D=0A=0D=0A>> says "this doesn't work on X.25 networks", it's not= clear to me that=0D=0A=0D=0Aan=0D=0A=0D=0A>> analogous disclaimer is calle= d for here.=0D=0A=0D=0A>>=20=0D=0A=0D=0A>> I presume there are similar docu= ments describing how emergency=0D=0A=0D=0Acalling=0D=0A=0D=0A>> works in 3G= PP networks. Do they include notes saying that the 3GPP=0D=0A=0D=0A>> solu= tion doesn't work in the broader Internet=3F=0D=0A=0D=0A>>=20=0D=0A=0D=0A>>= --Richard=0D=0A=0D=0A>>=20=0D=0A=0D=0A>>=20=0D=0A=0D=0A>>=20=0D=0A=0D=0A>>= =20=0D=0A=0D=0A>>=20=0D=0A=0D=0A>> Edge, Stephen wrote:=0D=0A=0D=0A>> > Bri= an=0D=0A=0D=0A>> >=0D=0A=0D=0A>> > First of all apologies for the likely la= teness of this reply - I=0D=0A=0D=0A>> actually wrote it on 19 February in = a 3GPP SA2 meeting in Budapest=0D=0A=0D=0Abut=0D=0A=0D=0A>> it seems unlike= ly that my VPN, Outlook server and WiFi access=0D=0A=0D=0A>> capability wil= l cooperate together to get it sent until I return to=0D=0A=0D=0Athe=0D=0A=0D= =0A>> office mid-next week.=0D=0A=0D=0A>> >=0D=0A=0D=0A>> > Anyhow thanks f= or your comments. There have actually been a number=0D=0A=0D=0Aof=0D=0A=0D=0A= >> conference calls between IETF and 3GPP participants over the last=0D=0A=0D= =0A>> couple of years at which common features like support of IP emergency=0D= =0A=0D=0A>> calls were discussed and these could have been good forum for=0D= =0A=0D=0A>> participants on either side to have raised the kinds of issues = you=0D=0A=0D=0A>> elaborate on below. Given that seems not so far to have h= appened, it=0D=0A=0D=0A>> could still be possible in future such calls.=0D=0A=0D= =0A>> >=0D=0A=0D=0A>> > But the issues we are raising are not directly to d= o with further=0D=0A=0D=0A>> aligning the 2 solutions or with the lack of t= his in the past. We are=0D=0A=0D=0A>> simply pointing out that the solution= s are currently different and=0D=0A=0D=0Athat=0D=0A=0D=0A>> from a cellular= wireless perspective, the Ecrit solution is not seen=0D=0A=0D=0Aas=0D=0A=0D= =0A>> suitable in all respects (for support of IP emergency calls=0D=0A=0D=0A= originating=0D=0A=0D=0A>> from such access types). That is not just our poi= nt of view. 3GPP2=0D=0A=0D=0Asent=0D=0A=0D=0A>> a liaison to Ecrit some mon= ths ago pointing out the same issues.=0D=0A=0D=0A>> >=0D=0A=0D=0A>> > So we= are proposing that the Ecrit framework and phoneBCP spec.s=0D=0A=0D=0A>> i= nclude a statement acknowledging this - e.g. by referencing the=0D=0A=0D=0A= >> alternative 3GPP/3GPP2 solution and indicating the IP access types=0D=0A=0D= =0Afor=0D=0A=0D=0A>> which the Ecrit solution will work without limitation = (or=0D=0A=0D=0Aequivalently=0D=0A=0D=0A>> the access types where limitation= s are not ruled out).=0D=0A=0D=0A>> >=0D=0A=0D=0A>> > We are not proposing = further modification and extension of the=0D=0A=0D=0AEcrit=0D=0A=0D=0A>> so= lution - just pointing out that this would be needed (as with the=0D=0A=0D=0A= >> 3GPP/3GPP2 solution) to fully cover all types of access.=0D=0A=0D=0A>> >=0D= =0A=0D=0A>> > Kind Regards=0D=0A=0D=0A>> >=0D=0A=0D=0A>> > Stephen=0D=0A=0D= =0A>> > -----Original Message-----=0D=0A=0D=0A>> > From: Brian Rosen [mailt= o:br@brianrosen.net]=0D=0A=0D=0A>> > Sent: Wednesday, February 18, 2009 8:0= 7 PM=0D=0A=0D=0A>> > To: Edge, Stephen; 'ECRIT'=0D=0A=0D=0A>> > Subject: RE= : [Ecrit] Comments on Framework Draft=0D=0A=0D=0A>> >=0D=0A=0D=0A>> > I hav= e bit my tongue on this one for a long time.=0D=0A=0D=0A>> >=0D=0A=0D=0A>> = > Stephen, with respect, please go talk to 3GPP management and ask=0D=0A=0D= =0Athem=0D=0A=0D=0A>> why=0D=0A=0D=0A>> > there has been no participation i= n the ecrit effort despite=0D=0A=0D=0Amultiple=0D=0A=0D=0A>> YEARS=0D=0A=0D= =0A>> > of begging them to get involved. To put it frankly, 3GPP is quite=0D= =0A=0D=0A>> willing=0D=0A=0D=0A>> > to bully IETF into doing its work on it= s schedule, but cannot be=0D=0A=0D=0A>> bothered to=0D=0A=0D=0A>> > get wor= k done it knows it will eventually have to do when the IETF=0D=0A=0D=0A>> a= sks it=0D=0A=0D=0A>> > to do so.=0D=0A=0D=0A>> >=0D=0A=0D=0A>> > 3GPP under= stands the mess that is being created by not=0D=0A=0D=0Aparticipating.=0D=0A=0D= =0A>> They=0D=0A=0D=0A>> > know full well that when they finally get around= to dealing with PS=0D=0A=0D=0A>> > terminated emergency calls, that there = will be a lot of resistance=0D=0A=0D=0Ato=0D=0A=0D=0A>> > changing fully sp= ecified and implemented standards to more closely=0D=0A=0D=0A>> align=0D=0A=0D= =0A>> > with 3GPP standards. I expect you will have several interworking=0D= =0A=0D=0A>> functions=0D=0A=0D=0A>> > to define and build.=0D=0A=0D=0A>> >=0D= =0A=0D=0A>> > So, politely, please go away, we're finishing work we dearly = wanted=0D=0A=0D=0A>> you all=0D=0A=0D=0A>> > to be involved with for years,= but you refused to do anything.=0D=0A=0D=0AIt's=0D=0A=0D=0A>> too=0D=0A=0D= =0A>> > late for this rev.=0D=0A=0D=0A>> >=0D=0A=0D=0A>> > Now, having said= that, there are quite a few people who have=0D=0A=0D=0A>> participated in=0D= =0A=0D=0A>> > the IETF work who are IMS aware and I believe that despite yo= ur=0D=0A=0D=0A>> fears,=0D=0A=0D=0A>> > everything you need is in the specs= =2E The mechanisms we have=0D=0A=0D=0Adefined=0D=0A=0D=0A>> provide=0D=0A=0D= =0A>> > the ability for the network to insert location, recognize and mark=0D= =0A=0D=0A>> emergency=0D=0A=0D=0A>> > calls, and route on behalf of endpoin= ts. An E-CSCF could quite=0D=0A=0D=0A>> > straightforwardly provide a SIP = call towards an ecrit compatible=0D=0A=0D=0A>> PSAP. The=0D=0A=0D=0A>> > o= nly not-quite-nice interwork would be from SUPL to HELD (or SIP),=0D=0A=0D=0A= >> but it's=0D=0A=0D=0A>> > pretty easy to do that. I'll also note that we= have tried to get=0D=0A=0D=0AOMA=0D=0A=0D=0A>> and=0D=0A=0D=0A>> > IETF to= cooperate on location protocols, but we have been=0D=0A=0D=0A>> spectacula= rly=0D=0A=0D=0A>> > unsuccessful at that effort also.=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>>= >> -----Original Message-----=0D=0A=0D=0A>> >> From: ecrit-bounces@ietf.or= g [mailto:ecrit-bounces@ietf.org] On=0D=0A=0D=0A>> Behalf=0D=0A=0D=0A>> >> = Of Edge, Stephen=0D=0A=0D=0A>> >> Sent: Thursday, February 05, 2009 2:50 AM=0D= =0A=0D=0A>> >> To: 'ECRIT'=0D=0A=0D=0A>> >> Subject: [Ecrit] Comments on Fr= amework Draft=0D=0A=0D=0A>> >>=0D=0A=0D=0A>> >> All=0D=0A=0D=0A>> >>=0D=0A=0D= =0A>> >> draft-ietf-ecrit-framework-07 is (as we see it) a mostly=0D=0A=0D=0A= informative=0D=0A=0D=0A>> >> description of how terminals and networks shou= ld support emergency=0D=0A=0D=0A>> >> calls made over IP capable facilities= to IP capable PSAPs. It=0D=0A=0D=0A>> appears=0D=0A=0D=0A>> >> intended to= cover all types of access network - including fixed=0D=0A=0D=0A>> line,=0D= =0A=0D=0A>> >> WiFi and cellular (e.g. examples involving each can be found=0D= =0A=0D=0A>> throughout=0D=0A=0D=0A>> >> the draft).=0D=0A=0D=0A>> >>=0D=0A=0D= =0A>> >> When we evaluated this with respect to support of wireless=0D=0A=0D= =0Acellular=0D=0A=0D=0A>> >> access and WiFi access associated with a cellu= lar operator (e.g.=0D=0A=0D=0A>> WLAN=0D=0A=0D=0A>> >> or Femto cells integ= rated into a cellular network), we found that=0D=0A=0D=0A>> >> certain port= ions of the draft exhibited one or more of the=0D=0A=0D=0Afollowing=0D=0A=0D= =0A>> >> characteristics:=0D=0A=0D=0A>> >>=0D=0A=0D=0A>> >> (A) Inconsi= stent with already standardized wireless solutions=0D=0A=0D=0A>> >>=0D=0A=0D= =0A>> >> (B) Inconsistent with essential wireless requirements and=0D=0A=0D= =0A>> >> conventions=0D=0A=0D=0A>> >>=0D=0A=0D=0A>> >> (C) Already part= of wireless standards or potentially part of=0D=0A=0D=0A>> >> future stand= ards=0D=0A=0D=0A>> >>=0D=0A=0D=0A>> >> (A) refers to all portions of the dr= aft framework that differ from=0D=0A=0D=0A>> the=0D=0A=0D=0A>> >> requireme= nts and procedures currently standardized for wireless=0D=0A=0D=0A>> >> eme= rgency access by 3GPP, 3GPP2 and OMA. This is a plain=0D=0A=0D=0Adifference=0D= =0A=0D=0A>> of=0D=0A=0D=0A>> >> solution and could be resolved through supp= ort of both solutions=0D=0A=0D=0Aby=0D=0A=0D=0A>> >> terminals (with each s= olution being used according to the type of=0D=0A=0D=0A>> >> access network= and VSP) or could be resolved by supporting only=0D=0A=0D=0Aone=0D=0A=0D=0A= >> >> solution and accessing only the types of network supporting that=0D=0A=0D= =0A>> >> solution. To acknowledge this category, the framework document=0D=0A=0D= =0Acould=0D=0A=0D=0A>> >> reference the applicable wireless standards and p= oint out that=0D=0A=0D=0Athese=0D=0A=0D=0A>> >> are valid alternatives for = wireless cellular based access.=0D=0A=0D=0A>> >>=0D=0A=0D=0A>> >> (B) refer= s to portions of the draft that would be unsuitable for=0D=0A=0D=0A>> >> wi= reless networks even if no alternative solution existed together=0D=0A=0D=0A= >> with=0D=0A=0D=0A>> >> other portions missing from the draft that would b= e needed to=0D=0A=0D=0Afully=0D=0A=0D=0A>> >> support wireless networks. Ex= amples of the former include: (a)=0D=0A=0D=0A>> emphasis=0D=0A=0D=0A>> >> o= n endpoint derivation of location, performance of Lost query and=0D=0A=0D=0A= >> >> receipt of local dial strings; (b) restriction of LCPs to=0D=0A=0D=0A= protocols=0D=0A=0D=0A>> >> that require terminal initiation (not allowing f= or network=0D=0A=0D=0A>> initiation=0D=0A=0D=0A>> >> as far as we can tell)= and that include two LCPs (DHCP and LLDP)=0D=0A=0D=0A>> that=0D=0A=0D=0A>>= >> are not applicable to (not defined for) cellular access; and (c)=0D=0A=0D= =0Athe=0D=0A=0D=0A>> >> requirement that a terminal or at least a LIS will = update the PSAP=0D=0A=0D=0A>> >> whenever location changes. (a) is impracti= cal due to network and=0D=0A=0D=0A>> >> terminal loading consequences and f= ailure to support non-IP=0D=0A=0D=0Acapable=0D=0A=0D=0A>> >> PSAPs; (b) mak= es location verification and updated location=0D=0A=0D=0A>> provision=0D=0A=0D= =0A>> >> to PSAPs difficult or impossible; while (c) is also incompatible=0D= =0A=0D=0A>> with=0D=0A=0D=0A>> >> support of existing non-IP capable PSAPs = besides increasing=0D=0A=0D=0Aterminal=0D=0A=0D=0A>> >> load and possibly i= nterfering with optimum maintenance of the RF=0D=0A=0D=0A>> >> connection (= e.g. if a terminal has to tune away from the serving=0D=0A=0D=0A>> base=0D=0A=0D= =0A>> >> station or WLAN periodically to make location measurements).=0D=0A=0D= =0A>> Examples=0D=0A=0D=0A>> >> of the latter include (d) absence of suppor= t for access to non-IP=0D=0A=0D=0A>> >> capable PSAPs as already mentioned = (e.g. to support E911 phase 2=0D=0A=0D=0Ain=0D=0A=0D=0A>> the=0D=0A=0D=0A>>= >> US); (e) no support for handover from the IP to the circuit domain=0D=0A=0D= =0A>> when=0D=0A=0D=0A>> >> a terminal loses (e.g. moves out of) RF coverag= e in the IP domain;=0D=0A=0D=0A>> and=0D=0A=0D=0A>> >> (f) no allowance for= limited access modes wherein a terminal may=0D=0A=0D=0A>> access=0D=0A=0D=0A= >> >> a network only to place an emergency call with ensuing=0D=0A=0D=0Ares= trictions=0D=0A=0D=0A>> on=0D=0A=0D=0A>> >> (for example) location acquisit= ion, PSAP callback and caller=0D=0A=0D=0A>> >> verification and identificat= ion to the PSAP. To resolve this=0D=0A=0D=0A>> category=0D=0A=0D=0A>> >> ei= ther significant changes to the framework document could be made=0D=0A=0D=0A= >> or a=0D=0A=0D=0A>> >> disclaimer/applicability statement could be added = stating that=0D=0A=0D=0A>> support=0D=0A=0D=0A>> >> of cellular wireless ne= tworks and their associated WLAN and Femto=0D=0A=0D=0A>> >> access points i= s not covered.=0D=0A=0D=0A>> >>=0D=0A=0D=0A>> >> Category (C) comprises con= cepts and capabilities in the draft that=0D=0A=0D=0A>> are=0D=0A=0D=0A>> >>= either already part of the standardized solution for wireless=0D=0A=0D=0A>= > networks=0D=0A=0D=0A>> >> or that might be added at a later time. Example= s of the former=0D=0A=0D=0A>> include=0D=0A=0D=0A>> >> LoST, SIP location c= onveyance, general use of SIP, location for=0D=0A=0D=0A>> routing=0D=0A=0D=0A= >> >> versus for dispatch, cellular positioning methods. Examples of the=0D= =0A=0D=0A>> >> latter include use of location references and dereferencing = and=0D=0A=0D=0A>> >> possible interworking between the current wireless net= work=0D=0A=0D=0Asolutions=0D=0A=0D=0A>> >> (in 3GPP, 3GPP2 and OMA) and the= solution described in this draft.=0D=0A=0D=0A>> The=0D=0A=0D=0A>> >> prese= nce of this category could be acknowledged by following the=0D=0A=0D=0A>> >= > disclaimer for (B) with a statement that certain portions of the=0D=0A=0D= =0A>> >> solution are expected to be incorporated into wireless networks=0D= =0A=0D=0Anow=0D=0A=0D=0A>> >> and/or in the future.=0D=0A=0D=0A>> >>=0D=0A=0D= =0A>> >> We hope that these comments will be seen to be a useful addition=0D= =0A=0D=0Ato=0D=0A=0D=0A>> >> this review in the sense of enabling a more pr= ecise scoping for=0D=0A=0D=0Athe=0D=0A=0D=0A>> >> framework document and we= are willing to assist in providing=0D=0A=0D=0Awording=0D=0A=0D=0A>> >> for= any disclaimer/applicability statement that the Ecrit working=0D=0A=0D=0A>= > group=0D=0A=0D=0A>> >> may now deem fit to include.=0D=0A=0D=0A>> >>=0D=0A=0D= =0A>> >> Kind Regards=0D=0A=0D=0A>> >>=0D=0A=0D=0A>> >> Stephen Edge (Qualc= omm 3GPP SA2 participant), Kirk Burroughs=0D=0A=0D=0A>> (Qualcomm=0D=0A=0D=0A= >> >> 3GPP2 TSG-X and TSG-C participant)=0D=0A=0D=0A>> >>=0D=0A=0D=0A>> >> = PS this being sent on 2/4/09 at 11:50pm PST=0D=0A=0D=0A>> >>=0D=0A=0D=0A>>= >> _______________________________________________=0D=0A=0D=0A>> >> Ecrit = mailing list=0D=0A=0D=0A>> >> Ecrit@ietf.org=0D=0A=0D=0A>> >> https://www.i= etf.org/mailman/listinfo/ecrit=0D=0A=0D=0A>> >=0D=0A=0D=0A>> > ____________= ___________________________________=0D=0A=0D=0A>> > Ecrit mailing list=0D=0A=0D= =0A>> > Ecrit@ietf.org=0D=0A=0D=0A>> > https://www.ietf.org/mailman/listinf= o/ecrit=0D=0A=0D=0A>> >=0D=0A=0D=0A>> _____________________________________= __________=0D=0A=0D=0A>> Ecrit mailing list=0D=0A=0D=0A>> Ecrit@ietf.org=0D= =0A=0D=0A>> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A>=20=0D=0A=0D= =0A>=20=0D=0A=0D=0A--------------------------------------------------------= ----------------=0D=0A=0D=0A------------------------=0D=0A=0D=0A> This mess= age is for the designated recipient only and may=0D=0A=0D=0A> contain privi= leged, proprietary, or otherwise private information.=0D=0A=0D=0A> If you h= ave received it in error, please notify the sender=0D=0A=0D=0A> immediately= and delete the original. Any unauthorized use of=0D=0A=0D=0A> this email = is prohibited.=0D=0A=0D=0A>=20=0D=0A=0D=0A---------------------------------= ---------------------------------------=0D=0A=0D=0A------------------------=0D= =0A=0D=0A> [mf2]=0D=0A=0D=0A> _____________________________________________= __=0D=0A=0D=0A> Ecrit mailing list=0D=0A=0D=0A> Ecrit@ietf.org=0D=0A=0D=0A>= https://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A>=20=0D=0A=0D=0A =0D= =0A=0D=0A_______________________________________________=0D=0A=0D=0AEcrit m= ailing list=0D=0A=0D=0AEcrit@ietf.org=0D=0A=0D=0Ahttps://www.ietf.org/mailm= an/listinfo/ecrit=0D=0A=0D=0A=20=0D=0A=0D=0A*****=0D=0A=0D=0A=20=0D=0A=0D=0A= The information transmitted is intended only for the person or entity to=0D= =0A=0D=0Awhich it is addressed and may contain confidential, proprietary, a= nd/or=0D=0A=0D=0Aprivileged material. Any review, retransmission, dissemina= tion or other=0D=0A=0D=0Ause of, or taking of any action in reliance upon t= his information by=0D=0A=0D=0Apersons or entities other than the intended r= ecipient is prohibited. If=0D=0A=0D=0Ayou received this in error, please co= ntact the sender and delete the=0D=0A=0D=0Amaterial from all computers. GA6= 21=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A_______________________________= ________________=0D=0A=0D=0AEcrit mailing list=0D=0A=0D=0AEcrit@ietf.org=0D= =0A=0D=0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A=20=0D=0A=0D= =0A------------------------------------------------------------------------=0D= =0A------------------------=0D=0A=0D=0AThis message is for the designated r= ecipient only and may=0D=0A=0D=0Acontain privileged, proprietary, or otherw= ise private information.=0D=0A=0D=0AIf you have received it in error, pleas= e notify the sender=0D=0A=0D=0Aimmediately and delete the original. Any un= authorized use of=0D=0A=0D=0Athis email is prohibited.=0D=0A=0D=0A---------= ---------------------------------------------------------------=0D=0A------= ------------------=0D=0A=0D=0A[mf2]=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0AThis message is for the designated recipient onl= y and may=0D=0Acontain privileged, proprietary, or otherwise private inform= ation. =20=0D=0AIf you have received it in error, please notify the sender=0D= =0Aimmediately and delete the original. Any unauthorized use of=0D=0Athis = email is prohibited.=0D=0A-------------------------------------------------= -----------------------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C99D48.B0271445 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=0D= =0A


-------= ---------------------------------------------------------------------------= --------------
=0D=0AThis message is for the de= signated recipient only and may
=0D=0Acontain p= rivileged, proprietary, or otherwise private infor= mation.  
=0D=0AIf you have received it&nb= sp;in error, please notify the sender
=0D=0Aimm= ediately and delete the original.  Any u= nauthorized use of
=0D=0Athis email is prohibit= ed.
=0D=0A--------------------------------------------------------------= ----------------------------------
=0D=0A[mf2]
=0D= =0A=0D=0A=0D=0A ------_=_NextPart_001_01C99D48.B0271445-- From root@core3.amsl.com Thu Mar 5 06:15:01 2009 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B9F0228C255; Thu, 5 Mar 2009 06:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090305141501.B9F0228C255@core3.amsl.com> Date: Thu, 5 Mar 2009 06:15:01 -0800 (PST) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-mapping-arch-04.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 14:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Location-to-URL Mapping Architecture and Framework Author(s) : H. Schulzrinne Filename : draft-ietf-ecrit-mapping-arch-04.txt Pages : 18 Date : 2009-03-05 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-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-mapping-arch-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-05060938.I-D@ietf.org> --NextPart-- From Gabor.Bajko@nokia.com Thu Mar 5 14:13:50 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3260228C14F for ; Thu, 5 Mar 2009 14:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9NooGeYivo7 for ; Thu, 5 Mar 2009 14:13:47 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 5B17C3A659C for ; Thu, 5 Mar 2009 14:13:46 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n25ME5vn012281; Fri, 6 Mar 2009 00:14:09 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 00:14:06 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 00:14:06 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Thu, 5 Mar 2009 23:14:06 +0100 From: To: Date: Thu, 5 Mar 2009 23:14:04 +0100 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmdZjoOuohgihUhTAGl+xIzZYDEkgABM/qQAANbgBkAGD/o4A== Message-ID: References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com> <64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net> <7582BC68E4994F4ABF0BD4723975C3FA0D39534E@crexc41p> <1288E74A73964940B132A0B9EA8D8ABC5374A196@NASANEXMB04.na.qualcomm.com> <96AD1EFB-0104-4B64-A94B-7A1877F8ADC6@andrew.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Mar 2009 22:14:06.0604 (UTC) FILETIME=[B32BF4C0:01C99DDF] X-Nokia-AV: Clean Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 22:13:50 -0000 Who talked about LTE? The point is, that cellular networks provide connectivity to internet, and = they'll be around for many years to come. And in those networks A-GPS combined with U-TDOA/AFLT is the positioning te= chnology in use today, which is unlikely to be replaced in the near future = as there is no better alternative around. I always found it unprofessional = to not even mention these, but instead mandate dhcp, which has a very limit= ed applicability. - gabor >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf O= f >ext Winterbottom, James >Sent: Thursday, March 05, 2009 1:55 AM >To: Bajko Gabor (Nokia-CIC/MtView) >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] Comments on Framework Draft > >There are certainly more WiMAX networks deployed at this point than LTE >networks... ;P > >But that aside, the experimental HELD location networks we have deployed >at the last 3 or so IETF meetings have all been control-plane and not >user-plane from a location determination perspective. > >Cheers >James > > > >-----Original Message----- >From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] >Sent: Thu 3/5/2009 2:25 AM >To: Winterbottom, James >Cc: sedge@qualcomm.com; bs7652@att.com; br@brianrosen.net; ecrit@ietf.or= g >Subject: RE: [Ecrit] Comments on Framework Draft > >Oh, I forgot about the abundance of deployed wimax networks. Huge >mistake, indeed. > >- gabor > > >-----Original Message----- > >From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] > >Sent: Wednesday, March 04, 2009 11:44 PM > >To: Bajko Gabor (Nokia-CIC/MtView) > >Cc: sedge@qualcomm.com; bs7652@att.com; br@brianrosen.net; >ecrit@ietf.org > >Subject: Re: [Ecrit] Comments on Framework Draft > > > >Gabor, > > > >You absolutey and totally wrong about HELD and control-plane. If > >anything, native HELD is best suited to control-plane location. Indee= d > >in WiMAX it is the only means to invoke control-plane location. > > > >Cheers James > > > >Sent from my iPhone > > > >On 05/03/2009, at 5:07 PM, "Gabor.Bajko@nokia.com" > > > wrote: > > > >> Stephen, > >> > >> Thanks for pointing out these issues. If you look at the previous > >> versions of phoneBCP, you'll also see LLDP (which was developed for > >> fixed environment, like switches) on the list of mandatory LCPs. It > >> took 2 years (!) to take that out from there, so in that sense ther= e > >> is some progress towards writing a more realistic set of >requirements. > >> > >> When it was requested to add SUPPL to the list, or to at least > >> mention that SUPPL is the one which is currently mostly used for > >> positioning (what an impertinent request it was to add to a documen= t > >> intended to describe BEST Current Practices, the protocols which ar= e > >> currently in use), the argument against it was that SUPPL requires > >> the existence of a subscription, while the internet is subscription > >> free. > >> > >> Meanwhile people refused to take a look at the applicability of a > >> DHCP based positioning method in today's world, where everything > >> tends to be mobile. > >> > >> An HTTP based protocol like HELD has the potential to offer solutio= n > >> for many, but not all of the use cases, as it can deliver location > >> related measurement information to location servers. The cases when > >> HELD does not work is when positioning is done using network based > >> positioning methods involving control plane, like U-TDOA or AFLT. > >> But then again, these are the positioning technologies which are > >> currently used in indoor environments where (A-)GPS does not work. > >> Perhaps this is the reason why they are not mentioned in a Best > >> Current Practice document ... > >> > >> - Gabor > >> > >> > >>> -----Original Message----- > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>> Behalf Of > >>> ext Edge, Stephen > >>> Sent: Wednesday, March 04, 2009 6:20 PM > >>> To: Stark, Barbara; br@brianrosen.net > >>> Cc: ECRIT > >>> Subject: Re: [Ecrit] Comments on Framework Draft > >>> > >>> Barbara and others > >>> > >>> Thanks for the comments. > >>> > >>> When I look at the PhoneBCP I see that both HELD and DHCP are > >>> mandatory > >>> for the device whereas at least one of these is mandatory for the >AN. > >>> While I can also see that SUPL is not ruled out (though it is not > >>> mentioned or referenced), it appears to have been displaced by the > >>> HELD > >>> and DHCP requirements. On the other hand, many cellular networks >have > >>> already deployed or are in the process of deploying SUPL and I am >not > >>> aware of any that have deployed an accurate location capability >using > >>> HELD or DHCP. So I would like to know how you see the current > >>> requirements as being suitable - after all, they imply at the very > >>> least > >>> additional development and deployment on the part of network and > >>> device > >>> vendors and network operators, whereas if SUPL was one of the >defined > >>> LCPs, that additional development and deployment might be mostly > >>> avoided. > >>> This question would not be applicable with some additional scope > >>> limitation and so I had not previously raised it. But it is >certainly > >>> applicable in > >>> the context of the global scope that is being claimed by some > >>> responders. > >>> > >>> Kind Regards > >>> > >>> Stephen > >>> -----Original Message----- > >>> From: Stark, Barbara [mailto:bs7652@att.com] > >>> Sent: Friday, February 27, 2009 8:28 AM > >>> To: br@brianrosen.net; Edge, Stephen > >>> Cc: ECRIT > >>> Subject: RE: [Ecrit] Comments on Framework Draft > >>> > >>> Thank you Brian. This is well said [except you left out the fact >that > >>> ecrit also allows for devices to get their location through other > >>> mechanisms, such as GPS, SUPL, or other methods, and doesn't insis= t > >>> that > >>> the location be configured through DHCP or HELD]. > >>> > >>> I agree 100% that additional qualifications are unnecessary. >Service > >>> providers, vendors, national bodies dealing with emergency > >>> services, and > >>> regulators aren't stupid. Please trust us to figure out for >ourselves > >>> when/where/how to apply a "standard". There is no need to try to > >>> artificially limit or define scope, or to state the obvious (e.g., > >>> the > >>> architecture applies where it applies, and doesn't apply where it > >>> doesn't apply). We understand the role and scope of the IETF, and >the > >>> role and scope of 3GPP and 3GPP2. And all the other SDOs (and > >>> national > >>> bodies and regulatory agencies). SDOs need to offer architectures > >>> that > >>> apply within the area of applicability for that SDO, and are usefu= l > >>> to > >>> potential implementers, and leave it to the SPs, national bodies >and > >>> regulators to decide which architectures and standards to use or t= o > >>> mandate within the scope of their network or jurisdiction. Again, >we > >>> aren't stupid. > >>> Barbara > >>> > >>> -----Original Message----- > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>> Behalf > >>> Of br@brianrosen.net > >>> Sent: Friday, February 27, 2009 9:53 AM > >>> To: Edge, Stephen > >>> Cc: ECRIT > >>> Subject: Re: [Ecrit] Comments on Framework Draft > >>> > >>> Stephen > >>> > >>> Like any standards organization, the IETF restricts it's scope. > >>> Generally, the scope is "the Internet", although we very often > >>> describe > >>> solutions that are explicitly designed for private IP networks as > >>> well > >>> as > >>> the Internet. We don't write standards for circuit switched > >>> networks, > >>> and > >>> it should be no surprise that the ecrit solution does not cater to >CS > >>> solutions. Nevertheless, we often try to make sure that our > >>> solutions > >>> harmonize reasonably well with existing solutions. > >>> > >>> Indeed, the ecrit solution clains global applicability to the > >>> Internet > >>> in > >>> general, and most private IP networks that can be interconnected t= o > >>> the > >>> Internet or to other IP networks via gateways. Looking at your > >>> list of > >>> problem areas: > >>>> - access to PSTN capable PSAPs > >>> This is out of scope for IETF. NENA has active work on this >subject. > >>> It > >>> seems straightforward to interwork ecrit compatible devices and > >>> networks > >>> to existing CS connected PSAPs. As you know, CS interconnects are > >>> very > >>> nation-specific, so the NENA work may not have general >applicability. > >>> However, it shows that it is possible to interwork. The NENA i2 > >>> work is > >>> also designed to take ecrit compatible devices and VSP networks, >and > >>> interwork them to the existing network. The VSP would direct the > >>> call > >>> to > >>> the VPC, which would provide the services it does now, using the > >>> device > >>> provided location for routing. This is important for smooth > >>> transition > >>> from existing PSAPs and VSPs to "next generation" PSAPs and VSPs. > >>>> - handover between different IP access networks including >different > >>>> types of access network > >>> In the ecrit solution, the access network the call is initiated on > >>> provides all the facilities needed for the device to initiate an > >>> emergency > >>> call. The call starts traversing it's normal call path, and > >>> eventually > >>> routes to the ESRP. Handoffs between IP networks should be > >>> transparent > >>> to > >>> this process, although we probably haven't done all the work we > >>> need to > >>> do > >>> for handoffs where the IP address as seen by the terminating >network > >>> changes. This would generally be true of all current SIP based >work. > >>>> - handover to/from circuit mode networks > >>> This would be out of scope for IETF. It's as applicable to a > >>> simple SIP > >>> call as it is a SIP emergency call, and there are no statements in > >>> any > >>> SIP > >>> documents on that subject. > >>>> - location for cellular access (and the requirement to support >LCPs > >>> that > >>>> will be useless for cellular access) > >>> Location for cellular access networks has been considered >carefully. > >>> Since cellular is a mobile network, the access network would pass >the > >>> device a Location-By-Reference URI, using either DHCP or HELD. > >>> Either > >>> protocol is suitable for cellular networks. As we have pointed ou= t > >>> several times, cellular networks support raw data packet services > >>> upon > >>> which many different kinds of networks can be constructed. My >usual > >>> example is a large recreational vehicle traveling down a road with >a > >>> cellular data card plugged into a router to which a wired >(Ethernet) > >>> phone > >>> is connected. That phone must be able to make an emergency call, > >>> and it > >>> will get location from DHCP or HELD (or LLDP-MED). It is not awar= e > >>> of > >>> the > >>> cellular network, and doesn't know any cellular specific protocols= . > >>> Cellular networks will have to support IETF location configuration > >>> protocols unless they actively prohibit examples like this, or the= y > >>> implement interworking between cellular-specific location protocol= s > >>> and > >>> DHCP or HELD in the data card. The ecrit standards permit proxy > >>> insertion > >>> of location, but, as above, we don't think that works in all cases= . > >>>> - endpoint based location and routing for cellular access (issue= s > >>> here > >>>> are network and device loading as well as device impacts and > >>>> problems > >>>> with PSTN capable PSAPs) > >>> The "load" of using DHCP or HELD to get location and querying LoST >is > >>> pretty modest. The standards permit proxies to do this if the > >>> devices > >>> don't. As above, interwork functions to CS connected PSAPs is ver= y > >>> feasible, and as above, cellular networks will have to support > >>> access to > >>> local LoST servers for devices that are connected to cellular > >>> networks > >>> and > >>> are ecrit compliant. > >>>> - support of unauthenticated users and users who can be > >>> authenticated > >>>> but are not permitted access/VSP service except for emergency >calls > >>> This is covered in the standards. None of the processes are > >>> dependent > >>> on > >>> authentication, although where it is possible, it's desirable so a= s > >>> to > >>> minimize fraudulent emergency calls > >>> Mechanisms for specific network authentication mechanisms are out >of > >>> scope, and, like SIP basic calling, are not usually mentioned in >IETF > >>> documents. > >>> > >>> Stephen, we've tried pretty hard to make sure this works for 3G/4G > >>> mobile > >>> networks. It's true that it doesn't do it the way 3GPP currently > >>> thinks > >>> it ought to work, but we claim they haven't thought through all th= e > >>> issues. While it would work, there are opportunities for > >>> improvement. > >>> We > >>> would be willing to do that if we could get the cooperation of >3GPP, > >>> which > >>> we have tried, and failed, to do. > >>> > >>> So, I think the documents do not need any qualification statements= . > >>> > >>> Brian > >>> > >>>> Martin > >>>> > >>>> The 3GPP/3GPP2 solution has a defined restricted applicability > >>>> (mainly > >>> to > >>>> 3GPP/3GPP2 access networks where the serving network also acts as > >>>> the > >>> VSP) > >>>> and the specifications for it cover in detail all possible >scenarios > >>>> consistent with these restrictions so far as we are aware. > >>>> > >>>> The Ecrit solution seems to claim global applicability to all > >>>> types of > >>> IP > >>>> access (and the more that is said about this from Ecrit >participants > >>> the > >>>> more this gets emphasized) but does not cover in detail all >possible > >>>> scenarios (in some cases does not cover in any detail) which mean= s > >>> that at > >>>> best the solution is incomplete and at worst intrinsically > >>> inapplicable to > >>>> some unstated set of scenarios. > >>>> > >>>> The missing, incomplete and problematic cases include the >following: > >>>> > >>>> - access to PSTN capable PSAPs > >>>> - handover between different IP access networks including >different > >>>> types of access network > >>>> - handover to/from circuit mode networks > >>>> - location for cellular access (and the requirement to support >LCPs > >>> that > >>>> will be useless for cellular access) > >>>> - endpoint based location and routing for cellular access (issue= s > >>> here > >>>> are network and device loading as well as device impacts and > >>>> problems > >>>> with PSTN capable PSAPs) > >>>> - support of unauthenticated users and users who can be > >>> authenticated > >>>> but are not permitted access/VSP service except for emergency >calls > >>>> > >>>> Stating that some of these cases are out of scope or referencing >an > >>>> incomplete and possibly questionable specification from some othe= r > >>>> national SDO will not help the user who encounters such problems. > >>>> But > >>> it > >>>> would certainly help network operators and implementers to > >>>> acknowledge > >>>> their existence in one form or another because that would allow > >>>> better > >>>> planning of deployments and would help focus attention on finding > >>>> solutions (whether in IETF or elsewhere) for the missing cases. > >>>> > >>>> Please note that despite these drawbacks, I will acknowledge that > >>> Ecrit > >>>> does have a valuable solution that covers many scenarios not >covered > >>> by > >>>> 3GPP/3GPP2. It would be the delineation of these supported >scenarios > >>> (or > >>>> equivalently unsupported scenarios) in some applicability >statement > >>> that > >>>> would be particularly useful right now. > >>>> > >>>> Kind Regards > >>>> > >>>> Stephen > >>>> -----Original Message----- > >>>> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > >>>> Sent: Thursday, February 26, 2009 9:45 PM > >>>> To: Edge, Stephen; Richard Barnes > >>>> Cc: ECRIT > >>>> Subject: RE: [Ecrit] Comments on Framework Draft > >>>> > >>>> There's benefit in knowing the limitations of a framework, and >every > >>>> architecture makes certain assumptions. Let's examine them > >>>> though... > >>>> > >>>> The IETF might occasionally make the assumption that the standard= s > >>>> it > >>>> develops are for Internet devices. That assumption probably need > >>>> not > >>> be > >>>> stated explicitly. > >>>> > >>>> The ECRIT architecture relies on implementations of the protocols > >>>> that > >>> it > >>>> references. That is not extraordinary. A reliance on > >>>> implementation > >>> of > >>>> these protocols by endpoints, routing intermediaries and PSAPs > >>>> should > >>> not > >>>> need to be explained. > >>>> > >>>> So the assumptions are: > >>>> - the Internet > >>>> - solutions are implemented and deployed > >>>> - the end device is a key component > >>>> > >>>> Only that last element is particularly novel ... or not that much > >>> really. > >>>> It's a design choice. Unless you were thinking of trunking the > >>> voice > >>>> elsewhere. > >>>> > >>>> Of course, you're suggesting that the design choice was made in > >>> ignorance > >>>> of all the constraints. You're suggesting that - as a result - >the > >>> choice > >>>> is flawed and the solution is not going to work for cellular > >>>> services. > >>> We > >>>> disagree. The solution is a basis for emergency calling in _any_ >IP > >>>> network. > >>>> > >>>> Cheers, > >>>> Martin > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>> Behalf > >>>>> Of Edge, Stephen > >>>>> Sent: Friday, 27 February 2009 3:30 PM > >>>>> To: Richard Barnes > >>>>> Cc: 'ECRIT' > >>>>> Subject: Re: [Ecrit] Comments on Framework Draft > >>>>> > >>>>> Hi Richard > >>>>> > >>>>> Thanks for the comments. Your statement below that "SIP emergenc= y > >>>>> calling works if all parties behave as specified in these (IETF > >>> Ecrit) > >>>>> documents" to some degree highlights the problems we are raising= . > >>>>> The > >>>>> documents do contain a number of implicit and explicit > >>>>> restrictions - > >>>>> like IP capable PSAPs, global IP access (no islands of circuit >mode > >>>>> access for example), universal support of this solution by all > >>>>> access > >>>>> providers and VSPs (not much good if some opt for another >solution) > >>> and > >>>>> end system oriented location and routing capability - which > >>>>> together > >>>>> make them unsuitable (we believe) for cellular wireless networks= . > >>>>> If > >>>>> these restrictions and assumptions were all made explicit > >>>>> upfront, it > >>>>> would to a large degree (and possibly completely) address our > >>> concerns. > >>>>> > >>>>> You are right in assuming another set of specifications for the > >>>>> 3GPP > >>>>> and 3GPP2 solution. The applicability of this solution is > >>>>> explicitly > >>>>> defined in TS 23.167 (or more exactly in an already agreed CR in > >>>>> contribution S2-090752 which will become part of 23.167 in a few > >>>>> more > >>>>> weeks) to cover the following access types: GPRS (UTRAN WCDMA), > >>> I-WLAN, > >>>>> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRA= N > >>>>> (LTE). So there is a restriction and arbitrary internet access i= s > >>>>> not > >>>>> covered (yet) as I have stated before. > >>>>> > >>>>> Kind Regards > >>>>> > >>>>> Stephen > >>>>> -----Original Message----- > >>>>> From: Richard Barnes [mailto:rbarnes@bbn.com] > >>>>> Sent: Wednesday, February 25, 2009 6:30 PM > >>>>> To: Edge, Stephen > >>>>> Cc: Brian Rosen; 'ECRIT' > >>>>> Subject: Re: [Ecrit] Comments on Framework Draft > >>>>> > >>>>> Hi Stephen, > >>>>> > >>>>> I'm a little confused by the scope of what you're asking. The > >>>>> framework > >>>>> and phonebcp documents exist in order to describe the ECRIT > >>>>> solution: > >>>>> They say, in effect, "SIP emergency calling works if all parties > >>> behave > >>>>> as specified in these documents." > >>>>> > >>>>> As I understand what you're saying (and I'm by no means an exper= t > >>>>> in > >>>>> 3GPP), 3GPP specifies that one or more elements of this system > >>>>> behave > >>>>> differently. This simply means that 3GPP networks aren't >complying > >>>>> with > >>>>> these specs. Just like there's no disclaimer in RFC 791 (IPv4) > >>>>> that > >>>>> says "this doesn't work on X.25 networks", it's not clear to me > >>>>> that > >>> an > >>>>> analogous disclaimer is called for here. > >>>>> > >>>>> I presume there are similar documents describing how emergency > >>> calling > >>>>> works in 3GPP networks. Do they include notes saying that the >3GPP > >>>>> solution doesn't work in the broader Internet? > >>>>> > >>>>> --Richard > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Edge, Stephen wrote: > >>>>>> Brian > >>>>>> > >>>>>> First of all apologies for the likely lateness of this reply - = I > >>>>> actually wrote it on 19 February in a 3GPP SA2 meeting in >Budapest > >>> but > >>>>> it seems unlikely that my VPN, Outlook server and WiFi access > >>>>> capability will cooperate together to get it sent until I return >to > >>> the > >>>>> office mid-next week. > >>>>>> > >>>>>> Anyhow thanks for your comments. There have actually been a >number > >>> of > >>>>> conference calls between IETF and 3GPP participants over the las= t > >>>>> couple of years at which common features like support of IP > >>>>> emergency > >>>>> calls were discussed and these could have been good forum for > >>>>> participants on either side to have raised the kinds of issues >you > >>>>> elaborate on below. Given that seems not so far to have happened= , > >>>>> it > >>>>> could still be possible in future such calls. > >>>>>> > >>>>>> But the issues we are raising are not directly to do with >further > >>>>> aligning the 2 solutions or with the lack of this in the past. W= e > >>>>> are > >>>>> simply pointing out that the solutions are currently different >and > >>> that > >>>>> from a cellular wireless perspective, the Ecrit solution is not > >>>>> seen > >>> as > >>>>> suitable in all respects (for support of IP emergency calls > >>> originating > >>>>> from such access types). That is not just our point of view. >3GPP2 > >>> sent > >>>>> a liaison to Ecrit some months ago pointing out the same issues. > >>>>>> > >>>>>> So we are proposing that the Ecrit framework and phoneBCP spec.= s > >>>>> include a statement acknowledging this - e.g. by referencing the > >>>>> alternative 3GPP/3GPP2 solution and indicating the IP access >types > >>> for > >>>>> which the Ecrit solution will work without limitation (or > >>> equivalently > >>>>> the access types where limitations are not ruled out). > >>>>>> > >>>>>> We are not proposing further modification and extension of the > >>> Ecrit > >>>>> solution - just pointing out that this would be needed (as with >the > >>>>> 3GPP/3GPP2 solution) to fully cover all types of access. > >>>>>> > >>>>>> Kind Regards > >>>>>> > >>>>>> Stephen > >>>>>> -----Original Message----- > >>>>>> From: Brian Rosen [mailto:br@brianrosen.net] > >>>>>> Sent: Wednesday, February 18, 2009 8:07 PM > >>>>>> To: Edge, Stephen; 'ECRIT' > >>>>>> Subject: RE: [Ecrit] Comments on Framework Draft > >>>>>> > >>>>>> I have bit my tongue on this one for a long time. > >>>>>> > >>>>>> Stephen, with respect, please go talk to 3GPP management and as= k > >>> them > >>>>> why > >>>>>> there has been no participation in the ecrit effort despite > >>> multiple > >>>>> YEARS > >>>>>> of begging them to get involved. To put it frankly, 3GPP is >quite > >>>>> willing > >>>>>> to bully IETF into doing its work on its schedule, but cannot b= e > >>>>> bothered to > >>>>>> get work done it knows it will eventually have to do when the >IETF > >>>>> asks it > >>>>>> to do so. > >>>>>> > >>>>>> 3GPP understands the mess that is being created by not > >>> participating. > >>>>> They > >>>>>> know full well that when they finally get around to dealing wit= h > >>>>>> PS > >>>>>> terminated emergency calls, that there will be a lot of >resistance > >>> to > >>>>>> changing fully specified and implemented standards to more >closely > >>>>> align > >>>>>> with 3GPP standards. I expect you will have several >interworking > >>>>> functions > >>>>>> to define and build. > >>>>>> > >>>>>> So, politely, please go away, we're finishing work we dearly > >>>>>> wanted > >>>>> you all > >>>>>> to be involved with for years, but you refused to do anything. > >>> It's > >>>>> too > >>>>>> late for this rev. > >>>>>> > >>>>>> Now, having said that, there are quite a few people who have > >>>>> participated in > >>>>>> the IETF work who are IMS aware and I believe that despite your > >>>>> fears, > >>>>>> everything you need is in the specs. The mechanisms we have > >>> defined > >>>>> provide > >>>>>> the ability for the network to insert location, recognize and >mark > >>>>> emergency > >>>>>> calls, and route on behalf of endpoints. An E-CSCF could quite > >>>>>> straightforwardly provide a SIP call towards an ecrit compatibl= e > >>>>> PSAP. The > >>>>>> only not-quite-nice interwork would be from SUPL to HELD (or >SIP), > >>>>> but it's > >>>>>> pretty easy to do that. I'll also note that we have tried to >get > >>> OMA > >>>>> and > >>>>>> IETF to cooperate on location protocols, but we have been > >>>>> spectacularly > >>>>>> unsuccessful at that effort also. > >>>>>> > >>>>>> Brian > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] O= n > >>>>> Behalf > >>>>>>> Of Edge, Stephen > >>>>>>> Sent: Thursday, February 05, 2009 2:50 AM > >>>>>>> To: 'ECRIT' > >>>>>>> Subject: [Ecrit] Comments on Framework Draft > >>>>>>> > >>>>>>> All > >>>>>>> > >>>>>>> draft-ietf-ecrit-framework-07 is (as we see it) a mostly > >>> informative > >>>>>>> description of how terminals and networks should support > >>>>>>> emergency > >>>>>>> calls made over IP capable facilities to IP capable PSAPs. It > >>>>> appears > >>>>>>> intended to cover all types of access network - including fixe= d > >>>>> line, > >>>>>>> WiFi and cellular (e.g. examples involving each can be found > >>>>> throughout > >>>>>>> the draft). > >>>>>>> > >>>>>>> When we evaluated this with respect to support of wireless > >>> cellular > >>>>>>> access and WiFi access associated with a cellular operator >(e.g. > >>>>> WLAN > >>>>>>> or Femto cells integrated into a cellular network), we found >that > >>>>>>> certain portions of the draft exhibited one or more of the > >>> following > >>>>>>> characteristics: > >>>>>>> > >>>>>>> (A) Inconsistent with already standardized wireless >solutions > >>>>>>> > >>>>>>> (B) Inconsistent with essential wireless requirements and > >>>>>>> conventions > >>>>>>> > >>>>>>> (C) Already part of wireless standards or potentially part >of > >>>>>>> future standards > >>>>>>> > >>>>>>> (A) refers to all portions of the draft framework that differ > >>>>>>> from > >>>>> the > >>>>>>> requirements and procedures currently standardized for wireles= s > >>>>>>> emergency access by 3GPP, 3GPP2 and OMA. This is a plain > >>> difference > >>>>> of > >>>>>>> solution and could be resolved through support of both >solutions > >>> by > >>>>>>> terminals (with each solution being used according to the type >of > >>>>>>> access network and VSP) or could be resolved by supporting onl= y > >>> one > >>>>>>> solution and accessing only the types of network supporting >that > >>>>>>> solution. To acknowledge this category, the framework document > >>> could > >>>>>>> reference the applicable wireless standards and point out that > >>> these > >>>>>>> are valid alternatives for wireless cellular based access. > >>>>>>> > >>>>>>> (B) refers to portions of the draft that would be unsuitable >for > >>>>>>> wireless networks even if no alternative solution existed > >>>>>>> together > >>>>> with > >>>>>>> other portions missing from the draft that would be needed to > >>> fully > >>>>>>> support wireless networks. Examples of the former include: (a) > >>>>> emphasis > >>>>>>> on endpoint derivation of location, performance of Lost query >and > >>>>>>> receipt of local dial strings; (b) restriction of LCPs to > >>> protocols > >>>>>>> that require terminal initiation (not allowing for network > >>>>> initiation > >>>>>>> as far as we can tell) and that include two LCPs (DHCP and >LLDP) > >>>>> that > >>>>>>> are not applicable to (not defined for) cellular access; and >(c) > >>> the > >>>>>>> requirement that a terminal or at least a LIS will update the > >>>>>>> PSAP > >>>>>>> whenever location changes. (a) is impractical due to network >and > >>>>>>> terminal loading consequences and failure to support non-IP > >>> capable > >>>>>>> PSAPs; (b) makes location verification and updated location > >>>>> provision > >>>>>>> to PSAPs difficult or impossible; while (c) is also >incompatible > >>>>> with > >>>>>>> support of existing non-IP capable PSAPs besides increasing > >>> terminal > >>>>>>> load and possibly interfering with optimum maintenance of the >RF > >>>>>>> connection (e.g. if a terminal has to tune away from the >serving > >>>>> base > >>>>>>> station or WLAN periodically to make location measurements). > >>>>> Examples > >>>>>>> of the latter include (d) absence of support for access to non= - >IP > >>>>>>> capable PSAPs as already mentioned (e.g. to support E911 phase >2 > >>> in > >>>>> the > >>>>>>> US); (e) no support for handover from the IP to the circuit > >>>>>>> domain > >>>>> when > >>>>>>> a terminal loses (e.g. moves out of) RF coverage in the IP > >>>>>>> domain; > >>>>> and > >>>>>>> (f) no allowance for limited access modes wherein a terminal >may > >>>>> access > >>>>>>> a network only to place an emergency call with ensuing > >>> restrictions > >>>>> on > >>>>>>> (for example) location acquisition, PSAP callback and caller > >>>>>>> verification and identification to the PSAP. To resolve this > >>>>> category > >>>>>>> either significant changes to the framework document could be > >>>>>>> made > >>>>> or a > >>>>>>> disclaimer/applicability statement could be added stating that > >>>>> support > >>>>>>> of cellular wireless networks and their associated WLAN and >Femto > >>>>>>> access points is not covered. > >>>>>>> > >>>>>>> Category (C) comprises concepts and capabilities in the draft > >>>>>>> that > >>>>> are > >>>>>>> either already part of the standardized solution for wireless > >>>>> networks > >>>>>>> or that might be added at a later time. Examples of the former > >>>>> include > >>>>>>> LoST, SIP location conveyance, general use of SIP, location fo= r > >>>>> routing > >>>>>>> versus for dispatch, cellular positioning methods. Examples of > >>>>>>> the > >>>>>>> latter include use of location references and dereferencing an= d > >>>>>>> possible interworking between the current wireless network > >>> solutions > >>>>>>> (in 3GPP, 3GPP2 and OMA) and the solution described in this > >>>>>>> draft. > >>>>> The > >>>>>>> presence of this category could be acknowledged by following >the > >>>>>>> disclaimer for (B) with a statement that certain portions of >the > >>>>>>> solution are expected to be incorporated into wireless network= s > >>> now > >>>>>>> and/or in the future. > >>>>>>> > >>>>>>> We hope that these comments will be seen to be a useful >addition > >>> to > >>>>>>> this review in the sense of enabling a more precise scoping fo= r > >>> the > >>>>>>> framework document and we are willing to assist in providing > >>> wording > >>>>>>> for any disclaimer/applicability statement that the Ecrit >working > >>>>> group > >>>>>>> may now deem fit to include. > >>>>>>> > >>>>>>> Kind Regards > >>>>>>> > >>>>>>> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs > >>>>> (Qualcomm > >>>>>>> 3GPP2 TSG-X and TSG-C participant) > >>>>>>> > >>>>>>> PS this being sent on 2/4/09 at 11:50pm PST > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Ecrit mailing list > >>>>>>> Ecrit@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Ecrit mailing list > >>>>>> Ecrit@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>>>> > >>>>> _______________________________________________ > >>>>> Ecrit mailing list > >>>>> Ecrit@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>> > >>>> > >>> --- > >>> ------------------------------------------------------------------= - >-- > >>> ------------------------ > >>>> 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://www.ietf.org/mailman/listinfo/ecrit > >>>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.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://www.ietf.org/mailman/listinfo/ecrit > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.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] > > > >------------------------------------------------------------------------= - >----------------------- >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://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@andrew.com Thu Mar 5 14:33:44 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBDB13A67D7 for ; Thu, 5 Mar 2009 14:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.303 X-Spam-Level: X-Spam-Status: No, score=-1.303 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOW7o5hkqAH9 for ; Thu, 5 Mar 2009 14:33:42 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id C67883A6821 for ; Thu, 5 Mar 2009 14:33:41 -0800 (PST) X-SEF-Processed: 5_0_0_910__2009_03_05_16_38_16 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 05 Mar 2009 16:38:16 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 16:18:32 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Mar 2009 16:18:30 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmdZjoOuohgihUhTAGl+xIzZYDEkgABM/qQAANbgBkAGD/o4AABnA1g References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com><64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net><7582BC68E4994F4ABF0BD4723975C3FA0D39534E@crexc41p><1288E74A73964940B132A0B9EA8D8ABC5374A196@NASANEXMB04.na.qualcomm.com><96AD1EFB-0104-4B64-A94B-7A1877F8ADC6@andrew.com> From: "Winterbottom, James" To: X-OriginalArrivalTime: 05 Mar 2009 22:18:32.0686 (UTC) FILETIME=[51C4D8E0:01C99DE0] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 22:33:45 -0000 Hi Gabor,=0D=0A=0D=0AYou are confusing issues.=0D=0AA-GPS, U-TDOA and AFLT = are all location determination techniques.=0D=0AAnd while DHCP can be used = to assist with location determination, when=0D=0Ayou refer to it as an LCP,= it is a location acquisition protocol, that=0D=0Ais, it is being used to h= and the determined location to the Target=0D=0Adevice requesting it.=0D=0A=0D= =0AA-GPS, U-TDOA and AFLT say nothing about how the location is provided=0D= =0Afrom the GMLC/MPC to the Target.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A= -----Original Message-----=0D=0AFrom: Gabor.Bajko@nokia.com [mailto:Gabor.B= ajko@nokia.com]=20=0D=0ASent: Friday, 6 March 2009 9:14 AM=0D=0ATo: Winterb= ottom, James=0D=0ACc: ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Comments on = Framework Draft=0D=0A=0D=0AWho talked about LTE=3F=0D=0AThe point is, that = cellular networks provide connectivity to internet,=0D=0Aand they'll be aro= und for many years to come.=0D=0AAnd in those networks A-GPS combined with = U-TDOA/AFLT is the positioning=0D=0Atechnology in use today, which is unlik= ely to be replaced in the near=0D=0Afuture as there is no better alternativ= e around. I always found it=0D=0Aunprofessional to not even mention these, = but instead mandate dhcp,=0D=0Awhich has a very limited applicability.=0D=0A=0D= =0A- gabor=0D=0A=0D=0A=0D=0A >-----Original Message-----=0D=0A >From: ecr= it-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=0D=0ABehalf Of=0D=0A= >ext Winterbottom, James=0D=0A >Sent: Thursday, March 05, 2009 1:55 AM=0D= =0A >To: Bajko Gabor (Nokia-CIC/MtView)=0D=0A >Cc: ecrit@ietf.org=0D=0A = >Subject: Re: [Ecrit] Comments on Framework Draft=0D=0A >=0D=0A >There ar= e certainly more WiMAX networks deployed at this point than=0D=0ALTE=0D=0A = >networks... ;P=0D=0A >=0D=0A >But that aside, the experimental HELD loc= ation networks we have=0D=0Adeployed=0D=0A >at the last 3 or so IETF meeti= ngs have all been control-plane and not=0D=0A >user-plane from a location = determination perspective.=0D=0A >=0D=0A >Cheers=0D=0A >James=0D=0A >=0D= =0A >=0D=0A >=0D=0A >-----Original Message-----=0D=0A >From: Gabor.Bajk= o@nokia.com [mailto:Gabor.Bajko@nokia.com]=0D=0A >Sent: Thu 3/5/2009 2:25 = AM=0D=0A >To: Winterbottom, James=0D=0A >Cc: sedge@qualcomm.com; bs7652@a= tt.com; br@brianrosen.net;=0D=0Aecrit@ietf.org=0D=0A >Subject: RE: [Ecrit]= Comments on Framework Draft=0D=0A >=0D=0A >Oh, I forgot about the abunda= nce of deployed wimax networks. Huge=0D=0A >mistake, indeed.=0D=0A >=0D=0A= >- gabor=0D=0A >=0D=0A > >-----Original Message-----=0D=0A > >From: = ext Winterbottom, James=0D=0A[mailto:James.Winterbottom@andrew.com]=0D=0A = > >Sent: Wednesday, March 04, 2009 11:44 PM=0D=0A > >To: Bajko Gabor (No= kia-CIC/MtView)=0D=0A > >Cc: sedge@qualcomm.com; bs7652@att.com; br@brian= rosen.net;=0D=0A >ecrit@ietf.org=0D=0A > >Subject: Re: [Ecrit] Comments = on Framework Draft=0D=0A > >=0D=0A > >Gabor,=0D=0A > >=0D=0A > >You= absolutey and totally wrong about HELD and control-plane. If=0D=0A > >an= ything, native HELD is best suited to control-plane location.=0D=0AIndeed=0D= =0A > >in WiMAX it is the only means to invoke control-plane location.=0D= =0A > >=0D=0A > >Cheers James=0D=0A > >=0D=0A > >Sent from my iPhon= e=0D=0A > >=0D=0A > >On 05/03/2009, at 5:07 PM, "Gabor.Bajko@nokia.com"=0D= =0A > > > wrote:=0D=0A > >=0D=0A > >> = Stephen,=0D=0A > >>=0D=0A > >> Thanks for pointing out these issues. If= you look at the=0D=0Aprevious=0D=0A > >> versions of phoneBCP, you'll al= so see LLDP (which was developed=0D=0Afor=0D=0A > >> fixed environment, l= ike switches) on the list of mandatory LCPs.=0D=0AIt=0D=0A > >> took 2 ye= ars (!) to take that out from there, so in that sense=0D=0Athere=0D=0A > = >> is some progress towards writing a more realistic set of=0D=0A >require= ments.=0D=0A > >>=0D=0A > >> When it was requested to add SUPPL to the = list, or to at least=0D=0A > >> mention that SUPPL is the one which is cu= rrently mostly used for=0D=0A > >> positioning (what an impertinent reque= st it was to add to a=0D=0Adocument=0D=0A > >> intended to describe BEST = Current Practices, the protocols which=0D=0Aare=0D=0A > >> currently in u= se), the argument against it was that SUPPL=0D=0Arequires=0D=0A > >> the = existence of a subscription, while the internet is=0D=0Asubscription=0D=0A = > >> free.=0D=0A > >>=0D=0A > >> Meanwhile people refused to take a l= ook at the applicability of=0D=0Aa=0D=0A > >> DHCP based positioning meth= od in today's world, where everything=0D=0A > >> tends to be mobile.=0D=0A= > >>=0D=0A > >> An HTTP based protocol like HELD has the potential to = offer=0D=0Asolution=0D=0A > >> for many, but not all of the use cases, as= it can deliver=0D=0Alocation=0D=0A > >> related measurement information = to location servers. The cases=0D=0Awhen=0D=0A > >> HELD does not work is= when positioning is done using network=0D=0Abased=0D=0A > >> positioning= methods involving control plane, like U-TDOA or=0D=0AAFLT.=0D=0A > >> Bu= t then again, these are the positioning technologies which are=0D=0A > >>= currently used in indoor environments where (A-)GPS does not=0D=0Awork.=0D= =0A > >> Perhaps this is the reason why they are not mentioned in a Best=0D= =0A > >> Current Practice document ...=0D=0A > >>=0D=0A > >> - Gabor=0D= =0A > >>=0D=0A > >>=0D=0A > >>> -----Original Message-----=0D=0A > = >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=0D=0A = > >>> Behalf Of=0D=0A > >>> ext Edge, Stephen=0D=0A > >>> Sent: Wednes= day, March 04, 2009 6:20 PM=0D=0A > >>> To: Stark, Barbara; br@brianrosen= =2Enet=0D=0A > >>> Cc: ECRIT=0D=0A > >>> Subject: Re: [Ecrit] Comments = on Framework Draft=0D=0A > >>>=0D=0A > >>> Barbara and others=0D=0A > = >>>=0D=0A > >>> Thanks for the comments.=0D=0A > >>>=0D=0A > >>> Whe= n I look at the PhoneBCP I see that both HELD and DHCP are=0D=0A > >>> ma= ndatory=0D=0A > >>> for the device whereas at least one of these is manda= tory for=0D=0Athe=0D=0A >AN.=0D=0A > >>> While I can also see that SUPL = is not ruled out (though it is=0D=0Anot=0D=0A > >>> mentioned or referenc= ed), it appears to have been displaced by=0D=0Athe=0D=0A > >>> HELD=0D=0A= > >>> and DHCP requirements. On the other hand, many cellular=0D=0Anetwo= rks=0D=0A >have=0D=0A > >>> already deployed or are in the process of de= ploying SUPL and I=0D=0Aam=0D=0A >not=0D=0A > >>> aware of any that have= deployed an accurate location capability=0D=0A >using=0D=0A > >>> HELD = or DHCP. So I would like to know how you see the current=0D=0A > >>> requ= irements as being suitable - after all, they imply at the=0D=0Avery=0D=0A = > >>> least=0D=0A > >>> additional development and deployment on the par= t of network=0D=0Aand=0D=0A > >>> device=0D=0A > >>> vendors and networ= k operators, whereas if SUPL was one of the=0D=0A >defined=0D=0A > >>> L= CPs, that additional development and deployment might be=0D=0Amostly=0D=0A = > >>> avoided.=0D=0A > >>> This question would not be applicable with s= ome additional=0D=0Ascope=0D=0A > >>> limitation and so I had not previou= sly raised it. But it is=0D=0A >certainly=0D=0A > >>> applicable in=0D=0A= > >>> the context of the global scope that is being claimed by some=0D=0A= > >>> responders.=0D=0A > >>>=0D=0A > >>> Kind Regards=0D=0A > >>>=0D= =0A > >>> Stephen=0D=0A > >>> -----Original Message-----=0D=0A > >>> = From: Stark, Barbara [mailto:bs7652@att.com]=0D=0A > >>> Sent: Friday, Fe= bruary 27, 2009 8:28 AM=0D=0A > >>> To: br@brianrosen.net; Edge, Stephen=0D= =0A > >>> Cc: ECRIT=0D=0A > >>> Subject: RE: [Ecrit] Comments on Framew= ork Draft=0D=0A > >>>=0D=0A > >>> Thank you Brian. This is well said [e= xcept you left out the=0D=0Afact=0D=0A >that=0D=0A > >>> ecrit also allo= ws for devices to get their location through=0D=0Aother=0D=0A > >>> mecha= nisms, such as GPS, SUPL, or other methods, and doesn't=0D=0Ainsist=0D=0A = > >>> that=0D=0A > >>> the location be configured through DHCP or HELD].=0D= =0A > >>>=0D=0A > >>> I agree 100% that additional qualifications are u= nnecessary.=0D=0A >Service=0D=0A > >>> providers, vendors, national bodi= es dealing with emergency=0D=0A > >>> services, and=0D=0A > >>> regulat= ors aren't stupid. Please trust us to figure out for=0D=0A >ourselves=0D=0A= > >>> when/where/how to apply a "standard". There is no need to try=0D=0A= to=0D=0A > >>> artificially limit or define scope, or to state the obviou= s=0D=0A(e.g.,=0D=0A > >>> the=0D=0A > >>> architecture applies where it= applies, and doesn't apply where=0D=0Ait=0D=0A > >>> doesn't apply). We = understand the role and scope of the IETF,=0D=0Aand=0D=0A >the=0D=0A > >= >> role and scope of 3GPP and 3GPP2. And all the other SDOs (and=0D=0A > = >>> national=0D=0A > >>> bodies and regulatory agencies). SDOs need to of= fer=0D=0Aarchitectures=0D=0A > >>> that=0D=0A > >>> apply within the ar= ea of applicability for that SDO, and are=0D=0Auseful=0D=0A > >>> to=0D=0A= > >>> potential implementers, and leave it to the SPs, national=0D=0Abod= ies=0D=0A >and=0D=0A > >>> regulators to decide which architectures and = standards to use=0D=0Aor to=0D=0A > >>> mandate within the scope of their= network or jurisdiction.=0D=0AAgain,=0D=0A >we=0D=0A > >>> aren't stupi= d.=0D=0A > >>> Barbara=0D=0A > >>>=0D=0A > >>> -----Original Message-= ----=0D=0A > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.= org] On=0D=0A > >>> Behalf=0D=0A > >>> Of br@brianrosen.net=0D=0A > >= >> Sent: Friday, February 27, 2009 9:53 AM=0D=0A > >>> To: Edge, Stephen=0D= =0A > >>> Cc: ECRIT=0D=0A > >>> Subject: Re: [Ecrit] Comments on Framew= ork Draft=0D=0A > >>>=0D=0A > >>> Stephen=0D=0A > >>>=0D=0A > >>> L= ike any standards organization, the IETF restricts it's scope.=0D=0A > >>= > Generally, the scope is "the Internet", although we very often=0D=0A > = >>> describe=0D=0A > >>> solutions that are explicitly designed for priva= te IP networks=0D=0Aas=0D=0A > >>> well=0D=0A > >>> as=0D=0A > >>> th= e Internet. We don't write standards for circuit switched=0D=0A > >>> ne= tworks,=0D=0A > >>> and=0D=0A > >>> it should be no surprise that the e= crit solution does not cater=0D=0Ato=0D=0A >CS=0D=0A > >>> solutions. N= evertheless, we often try to make sure that our=0D=0A > >>> solutions=0D=0A= > >>> harmonize reasonably well with existing solutions.=0D=0A > >>>=0D= =0A > >>> Indeed, the ecrit solution clains global applicability to the=0D= =0A > >>> Internet=0D=0A > >>> in=0D=0A > >>> general, and most priva= te IP networks that can be=0D=0Ainterconnected to=0D=0A > >>> the=0D=0A = > >>> Internet or to other IP networks via gateways. Looking at your=0D=0A= > >>> list of=0D=0A > >>> problem areas:=0D=0A > >>>> - access to P= STN capable PSAPs=0D=0A > >>> This is out of scope for IETF. NENA has ac= tive work on this=0D=0A >subject.=0D=0A > >>> It=0D=0A > >>> seems str= aightforward to interwork ecrit compatible devices and=0D=0A > >>> networ= ks=0D=0A > >>> to existing CS connected PSAPs. As you know, CS interconn= ects=0D=0Aare=0D=0A > >>> very=0D=0A > >>> nation-specific, so the NENA= work may not have general=0D=0A >applicability.=0D=0A > >>> However, it= shows that it is possible to interwork. The NENA=0D=0Ai2=0D=0A > >>> wo= rk is=0D=0A > >>> also designed to take ecrit compatible devices and VSP=0D= =0Anetworks,=0D=0A >and=0D=0A > >>> interwork them to the existing netwo= rk. The VSP would direct=0D=0Athe=0D=0A > >>> call=0D=0A > >>> to=0D=0A= > >>> the VPC, which would provide the services it does now, using=0D=0A= the=0D=0A > >>> device=0D=0A > >>> provided location for routing. This= is important for smooth=0D=0A > >>> transition=0D=0A > >>> from existi= ng PSAPs and VSPs to "next generation" PSAPs and=0D=0AVSPs.=0D=0A > >>>> = - handover between different IP access networks including=0D=0A >differen= t=0D=0A > >>>> types of access network=0D=0A > >>> In the ecrit solutio= n, the access network the call is initiated=0D=0Aon=0D=0A > >>> provides = all the facilities needed for the device to initiate=0D=0Aan=0D=0A > >>> = emergency=0D=0A > >>> call. The call starts traversing it's normal call= path, and=0D=0A > >>> eventually=0D=0A > >>> routes to the ESRP. Hand= offs between IP networks should be=0D=0A > >>> transparent=0D=0A > >>> = to=0D=0A > >>> this process, although we probably haven't done all the wo= rk we=0D=0A > >>> need to=0D=0A > >>> do=0D=0A > >>> for handoffs whe= re the IP address as seen by the terminating=0D=0A >network=0D=0A > >>> = changes. This would generally be true of all current SIP based=0D=0A >wor= k.=0D=0A > >>>> - handover to/from circuit mode networks=0D=0A > >>> T= his would be out of scope for IETF. It's as applicable to a=0D=0A > >>> = simple SIP=0D=0A > >>> call as it is a SIP emergency call, and there are = no statements=0D=0Ain=0D=0A > >>> any=0D=0A > >>> SIP=0D=0A > >>> doc= uments on that subject.=0D=0A > >>>> - location for cellular access (and= the requirement to=0D=0Asupport=0D=0A >LCPs=0D=0A > >>> that=0D=0A > = >>>> will be useless for cellular access)=0D=0A > >>> Location for cellul= ar access networks has been considered=0D=0A >carefully.=0D=0A > >>> Sin= ce cellular is a mobile network, the access network would=0D=0Apass=0D=0A = >the=0D=0A > >>> device a Location-By-Reference URI, using either DHCP or= HELD.=0D=0A > >>> Either=0D=0A > >>> protocol is suitable for cellular= networks. As we have pointed=0D=0Aout=0D=0A > >>> several times, cellul= ar networks support raw data packet=0D=0Aservices=0D=0A > >>> upon=0D=0A = > >>> which many different kinds of networks can be constructed. My=0D=0A= >usual=0D=0A > >>> example is a large recreational vehicle traveling do= wn a road=0D=0Awith=0D=0A >a=0D=0A > >>> cellular data card plugged into= a router to which a wired=0D=0A >(Ethernet)=0D=0A > >>> phone=0D=0A > = >>> is connected. That phone must be able to make an emergency=0D=0Acall,=0D= =0A > >>> and it=0D=0A > >>> will get location from DHCP or HELD (or LL= DP-MED). It is not=0D=0Aaware=0D=0A > >>> of=0D=0A > >>> the=0D=0A > = >>> cellular network, and doesn't know any cellular specific=0D=0Aprotocol= s.=0D=0A > >>> Cellular networks will have to support IETF location=0D=0A= configuration=0D=0A > >>> protocols unless they actively prohibit example= s like this, or=0D=0Athey=0D=0A > >>> implement interworking between cell= ular-specific location=0D=0Aprotocols=0D=0A > >>> and=0D=0A > >>> DHCP = or HELD in the data card. The ecrit standards permit=0D=0Aproxy=0D=0A > = >>> insertion=0D=0A > >>> of location, but, as above, we don't think that= works in all=0D=0Acases.=0D=0A > >>>> - endpoint based location and rou= ting for cellular access=0D=0A(issues=0D=0A > >>> here=0D=0A > >>>> are= network and device loading as well as device impacts and=0D=0A > >>>> pr= oblems=0D=0A > >>>> with PSTN capable PSAPs)=0D=0A > >>> The "load" of = using DHCP or HELD to get location and querying=0D=0ALoST=0D=0A >is=0D=0A = > >>> pretty modest. The standards permit proxies to do this if the=0D=0A= > >>> devices=0D=0A > >>> don't. As above, interwork functions to CS = connected PSAPs is=0D=0Avery=0D=0A > >>> feasible, and as above, cellular= networks will have to support=0D=0A > >>> access to=0D=0A > >>> local = LoST servers for devices that are connected to cellular=0D=0A > >>> netwo= rks=0D=0A > >>> and=0D=0A > >>> are ecrit compliant.=0D=0A > >>>> - = support of unauthenticated users and users who can be=0D=0A > >>> authent= icated=0D=0A > >>>> but are not permitted access/VSP service except for e= mergency=0D=0A >calls=0D=0A > >>> This is covered in the standards. Non= e of the processes are=0D=0A > >>> dependent=0D=0A > >>> on=0D=0A > >= >> authentication, although where it is possible, it's desirable=0D=0Aso as=0D= =0A > >>> to=0D=0A > >>> minimize fraudulent emergency calls=0D=0A > = >>> Mechanisms for specific network authentication mechanisms are=0D=0Aout=0D= =0A >of=0D=0A > >>> scope, and, like SIP basic calling, are not usually = mentioned=0D=0Ain=0D=0A >IETF=0D=0A > >>> documents.=0D=0A > >>>=0D=0A= > >>> Stephen, we've tried pretty hard to make sure this works for=0D=0A= 3G/4G=0D=0A > >>> mobile=0D=0A > >>> networks. It's true that it doesn= 't do it the way 3GPP=0D=0Acurrently=0D=0A > >>> thinks=0D=0A > >>> it = ought to work, but we claim they haven't thought through all=0D=0Athe=0D=0A= > >>> issues. While it would work, there are opportunities for=0D=0A >= >>> improvement.=0D=0A > >>> We=0D=0A > >>> would be willing to do th= at if we could get the cooperation of=0D=0A >3GPP,=0D=0A > >>> which=0D=0A= > >>> we have tried, and failed, to do.=0D=0A > >>>=0D=0A > >>> So, = I think the documents do not need any qualification=0D=0Astatements.=0D=0A = > >>>=0D=0A > >>> Brian=0D=0A > >>>=0D=0A > >>>> Martin=0D=0A > >= >>>=0D=0A > >>>> The 3GPP/3GPP2 solution has a defined restricted applica= bility=0D=0A > >>>> (mainly=0D=0A > >>> to=0D=0A > >>>> 3GPP/3GPP2 ac= cess networks where the serving network also acts=0D=0Aas=0D=0A > >>>> th= e=0D=0A > >>> VSP)=0D=0A > >>>> and the specifications for it cover in = detail all possible=0D=0A >scenarios=0D=0A > >>>> consistent with these = restrictions so far as we are aware.=0D=0A > >>>>=0D=0A > >>>> The Ecri= t solution seems to claim global applicability to all=0D=0A > >>>> types = of=0D=0A > >>> IP=0D=0A > >>>> access (and the more that is said about = this from Ecrit=0D=0A >participants=0D=0A > >>> the=0D=0A > >>>> more = this gets emphasized) but does not cover in detail all=0D=0A >possible=0D=0A= > >>>> scenarios (in some cases does not cover in any detail) which=0D=0A= means=0D=0A > >>> that at=0D=0A > >>>> best the solution is incomplete = and at worst intrinsically=0D=0A > >>> inapplicable to=0D=0A > >>>> som= e unstated set of scenarios.=0D=0A > >>>>=0D=0A > >>>> The missing, inc= omplete and problematic cases include the=0D=0A >following:=0D=0A > >>>>=0D= =0A > >>>> - access to PSTN capable PSAPs=0D=0A > >>>> - handover bet= ween different IP access networks including=0D=0A >different=0D=0A > >>>= > types of access network=0D=0A > >>>> - handover to/from circuit mode n= etworks=0D=0A > >>>> - location for cellular access (and the requirement= to=0D=0Asupport=0D=0A >LCPs=0D=0A > >>> that=0D=0A > >>>> will be use= less for cellular access)=0D=0A > >>>> - endpoint based location and rou= ting for cellular access=0D=0A(issues=0D=0A > >>> here=0D=0A > >>>> are= network and device loading as well as device impacts and=0D=0A > >>>> pr= oblems=0D=0A > >>>> with PSTN capable PSAPs)=0D=0A > >>>> - support of= unauthenticated users and users who can be=0D=0A > >>> authenticated=0D=0A= > >>>> but are not permitted access/VSP service except for emergency=0D=0A= >calls=0D=0A > >>>>=0D=0A > >>>> Stating that some of these cases are= out of scope or=0D=0Areferencing=0D=0A >an=0D=0A > >>>> incomplete and = possibly questionable specification from some=0D=0Aother=0D=0A > >>>> nat= ional SDO will not help the user who encounters such=0D=0Aproblems.=0D=0A = > >>>> But=0D=0A > >>> it=0D=0A > >>>> would certainly help network op= erators and implementers to=0D=0A > >>>> acknowledge=0D=0A > >>>> their= existence in one form or another because that would=0D=0Aallow=0D=0A > >= >>> better=0D=0A > >>>> planning of deployments and would help focus atte= ntion on=0D=0Afinding=0D=0A > >>>> solutions (whether in IETF or elsewher= e) for the missing=0D=0Acases.=0D=0A > >>>>=0D=0A > >>>> Please note th= at despite these drawbacks, I will acknowledge=0D=0Athat=0D=0A > >>> Ecri= t=0D=0A > >>>> does have a valuable solution that covers many scenarios n= ot=0D=0A >covered=0D=0A > >>> by=0D=0A > >>>> 3GPP/3GPP2. It would be = the delineation of these supported=0D=0A >scenarios=0D=0A > >>> (or=0D=0A= > >>>> equivalently unsupported scenarios) in some applicability=0D=0A = >statement=0D=0A > >>> that=0D=0A > >>>> would be particularly useful r= ight now.=0D=0A > >>>>=0D=0A > >>>> Kind Regards=0D=0A > >>>>=0D=0A = > >>>> Stephen=0D=0A > >>>> -----Original Message-----=0D=0A > >>>> Fr= om: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=0D=0A > >>>> Sent:= Thursday, February 26, 2009 9:45 PM=0D=0A > >>>> To: Edge, Stephen; Rich= ard Barnes=0D=0A > >>>> Cc: ECRIT=0D=0A > >>>> Subject: RE: [Ecrit] Com= ments on Framework Draft=0D=0A > >>>>=0D=0A > >>>> There's benefit in k= nowing the limitations of a framework, and=0D=0A >every=0D=0A > >>>> arc= hitecture makes certain assumptions. Let's examine them=0D=0A > >>>> tho= ugh...=0D=0A > >>>>=0D=0A > >>>> The IETF might occasionally make the a= ssumption that the=0D=0Astandards=0D=0A > >>>> it=0D=0A > >>>> develops= are for Internet devices. That assumption probably=0D=0Aneed=0D=0A > >>= >> not=0D=0A > >>> be=0D=0A > >>>> stated explicitly.=0D=0A > >>>>=0D= =0A > >>>> The ECRIT architecture relies on implementations of the=0D=0Ap= rotocols=0D=0A > >>>> that=0D=0A > >>> it=0D=0A > >>>> references. T= hat is not extraordinary. A reliance on=0D=0A > >>>> implementation=0D=0A= > >>> of=0D=0A > >>>> these protocols by endpoints, routing intermedia= ries and PSAPs=0D=0A > >>>> should=0D=0A > >>> not=0D=0A > >>>> need = to be explained.=0D=0A > >>>>=0D=0A > >>>> So the assumptions are:=0D=0A= > >>>> - the Internet=0D=0A > >>>> - solutions are implemented and dep= loyed=0D=0A > >>>> - the end device is a key component=0D=0A > >>>>=0D=0A= > >>>> Only that last element is particularly novel ... or not that=0D=0A= much=0D=0A > >>> really.=0D=0A > >>>> It's a design choice. Unless yo= u were thinking of trunking=0D=0Athe=0D=0A > >>> voice=0D=0A > >>>> els= ewhere.=0D=0A > >>>>=0D=0A > >>>> Of course, you're suggesting that the= design choice was made=0D=0Ain=0D=0A > >>> ignorance=0D=0A > >>>> of a= ll the constraints. You're suggesting that - as a result=0D=0A-=0D=0A >th= e=0D=0A > >>> choice=0D=0A > >>>> is flawed and the solution is not goi= ng to work for cellular=0D=0A > >>>> services.=0D=0A > >>> We=0D=0A > = >>>> disagree. The solution is a basis for emergency calling in=0D=0A_any= _=0D=0A >IP=0D=0A > >>>> network.=0D=0A > >>>>=0D=0A > >>>> Cheers,=0D= =0A > >>>> Martin=0D=0A > >>>>=0D=0A > >>>>=0D=0A > >>>>> -----Orig= inal Message-----=0D=0A > >>>>> From: ecrit-bounces@ietf.org [mailto:ecri= t-bounces@ietf.org]=0D=0AOn=0D=0A > >>> Behalf=0D=0A > >>>>> Of Edge, S= tephen=0D=0A > >>>>> Sent: Friday, 27 February 2009 3:30 PM=0D=0A > >>>= >> To: Richard Barnes=0D=0A > >>>>> Cc: 'ECRIT'=0D=0A > >>>>> Subject: = Re: [Ecrit] Comments on Framework Draft=0D=0A > >>>>>=0D=0A > >>>>> Hi = Richard=0D=0A > >>>>>=0D=0A > >>>>> Thanks for the comments. Your state= ment below that "SIP=0D=0Aemergency=0D=0A > >>>>> calling works if all pa= rties behave as specified in these=0D=0A(IETF=0D=0A > >>> Ecrit)=0D=0A >= >>>>> documents" to some degree highlights the problems we are=0D=0Araisi= ng.=0D=0A > >>>>> The=0D=0A > >>>>> documents do contain a number of im= plicit and explicit=0D=0A > >>>>> restrictions -=0D=0A > >>>>> like IP = capable PSAPs, global IP access (no islands of=0D=0Acircuit=0D=0A >mode=0D= =0A > >>>>> access for example), universal support of this solution by=0D= =0Aall=0D=0A > >>>>> access=0D=0A > >>>>> providers and VSPs (not much = good if some opt for another=0D=0A >solution)=0D=0A > >>> and=0D=0A > = >>>>> end system oriented location and routing capability - which=0D=0A > = >>>>> together=0D=0A > >>>>> make them unsuitable (we believe) for cellu= lar wireless=0D=0Anetworks.=0D=0A > >>>>> If=0D=0A > >>>>> these restri= ctions and assumptions were all made explicit=0D=0A > >>>>> upfront, it=0D= =0A > >>>>> would to a large degree (and possibly completely) address our=0D= =0A > >>> concerns.=0D=0A > >>>>>=0D=0A > >>>>> You are right in assu= ming another set of specifications for=0D=0Athe=0D=0A > >>>>> 3GPP=0D=0A = > >>>>> and 3GPP2 solution. The applicability of this solution is=0D=0A = > >>>>> explicitly=0D=0A > >>>>> defined in TS 23.167 (or more exactly i= n an already agreed CR=0D=0Ain=0D=0A > >>>>> contribution S2-090752 which= will become part of 23.167 in a=0D=0Afew=0D=0A > >>>>> more=0D=0A > >>= >>> weeks) to cover the following access types: GPRS (UTRAN=0D=0AWCDMA),=0D= =0A > >>> I-WLAN,=0D=0A > >>>>> Fixed Broadband, CDMA2000 HRPD, EPS UTR= AN (WCDMA) and EPS=0D=0AE-UTRAN=0D=0A > >>>>> (LTE). So there is a restri= ction and arbitrary internet=0D=0Aaccess is=0D=0A > >>>>> not=0D=0A > >= >>>> covered (yet) as I have stated before.=0D=0A > >>>>>=0D=0A > >>>>>= Kind Regards=0D=0A > >>>>>=0D=0A > >>>>> Stephen=0D=0A > >>>>> -----= Original Message-----=0D=0A > >>>>> From: Richard Barnes [mailto:rbarnes@= bbn.com]=0D=0A > >>>>> Sent: Wednesday, February 25, 2009 6:30 PM=0D=0A = > >>>>> To: Edge, Stephen=0D=0A > >>>>> Cc: Brian Rosen; 'ECRIT'=0D=0A = > >>>>> Subject: Re: [Ecrit] Comments on Framework Draft=0D=0A > >>>>>=0D= =0A > >>>>> Hi Stephen,=0D=0A > >>>>>=0D=0A > >>>>> I'm a little conf= used by the scope of what you're asking.=0D=0AThe=0D=0A > >>>>> framework=0D= =0A > >>>>> and phonebcp documents exist in order to describe the ECRIT=0D= =0A > >>>>> solution:=0D=0A > >>>>> They say, in effect, "SIP emergency= calling works if all=0D=0Aparties=0D=0A > >>> behave=0D=0A > >>>>> as = specified in these documents."=0D=0A > >>>>>=0D=0A > >>>>> As I underst= and what you're saying (and I'm by no means an=0D=0Aexpert=0D=0A > >>>>> = in=0D=0A > >>>>> 3GPP), 3GPP specifies that one or more elements of this=0D= =0Asystem=0D=0A > >>>>> behave=0D=0A > >>>>> differently. This simply = means that 3GPP networks aren't=0D=0A >complying=0D=0A > >>>>> with=0D=0A= > >>>>> these specs. Just like there's no disclaimer in RFC 791=0D=0A(I= Pv4)=0D=0A > >>>>> that=0D=0A > >>>>> says "this doesn't work on X.25 n= etworks", it's not clear to=0D=0Ame=0D=0A > >>>>> that=0D=0A > >>> an=0D= =0A > >>>>> analogous disclaimer is called for here.=0D=0A > >>>>>=0D=0A= > >>>>> I presume there are similar documents describing how=0D=0Aemerge= ncy=0D=0A > >>> calling=0D=0A > >>>>> works in 3GPP networks. Do they = include notes saying that=0D=0Athe=0D=0A >3GPP=0D=0A > >>>>> solution do= esn't work in the broader Internet=3F=0D=0A > >>>>>=0D=0A > >>>>> --Ric= hard=0D=0A > >>>>>=0D=0A > >>>>>=0D=0A > >>>>>=0D=0A > >>>>>=0D=0A = > >>>>>=0D=0A > >>>>> Edge, Stephen wrote:=0D=0A > >>>>>> Brian=0D=0A= > >>>>>>=0D=0A > >>>>>> First of all apologies for the likely lateness= of this reply=0D=0A- I=0D=0A > >>>>> actually wrote it on 19 February in= a 3GPP SA2 meeting in=0D=0A >Budapest=0D=0A > >>> but=0D=0A > >>>>> i= t seems unlikely that my VPN, Outlook server and WiFi access=0D=0A > >>>>= > capability will cooperate together to get it sent until I=0D=0Areturn=0D=0A= >to=0D=0A > >>> the=0D=0A > >>>>> office mid-next week.=0D=0A > >>>= >>>=0D=0A > >>>>>> Anyhow thanks for your comments. There have actually b= een a=0D=0A >number=0D=0A > >>> of=0D=0A > >>>>> conference calls betw= een IETF and 3GPP participants over the=0D=0Alast=0D=0A > >>>>> couple of= years at which common features like support of IP=0D=0A > >>>>> emergenc= y=0D=0A > >>>>> calls were discussed and these could have been good forum= for=0D=0A > >>>>> participants on either side to have raised the kinds o= f=0D=0Aissues=0D=0A >you=0D=0A > >>>>> elaborate on below. Given that se= ems not so far to have=0D=0Ahappened,=0D=0A > >>>>> it=0D=0A > >>>>> co= uld still be possible in future such calls.=0D=0A > >>>>>>=0D=0A > >>>>= >> But the issues we are raising are not directly to do with=0D=0A >furthe= r=0D=0A > >>>>> aligning the 2 solutions or with the lack of this in the=0D= =0Apast. We=0D=0A > >>>>> are=0D=0A > >>>>> simply pointing out that th= e solutions are currently=0D=0Adifferent=0D=0A >and=0D=0A > >>> that=0D=0A= > >>>>> from a cellular wireless perspective, the Ecrit solution is=0D=0A= not=0D=0A > >>>>> seen=0D=0A > >>> as=0D=0A > >>>>> suitable in all r= espects (for support of IP emergency calls=0D=0A > >>> originating=0D=0A = > >>>>> from such access types). That is not just our point of view.=0D=0A= >3GPP2=0D=0A > >>> sent=0D=0A > >>>>> a liaison to Ecrit some months = ago pointing out the same=0D=0Aissues.=0D=0A > >>>>>>=0D=0A > >>>>>> So= we are proposing that the Ecrit framework and phoneBCP=0D=0Aspec.s=0D=0A = > >>>>> include a statement acknowledging this - e.g. by referencing=0D=0A= the=0D=0A > >>>>> alternative 3GPP/3GPP2 solution and indicating the IP a= ccess=0D=0A >types=0D=0A > >>> for=0D=0A > >>>>> which the Ecrit solut= ion will work without limitation (or=0D=0A > >>> equivalently=0D=0A > >= >>>> the access types where limitations are not ruled out).=0D=0A > >>>>>= >=0D=0A > >>>>>> We are not proposing further modification and extension = of=0D=0Athe=0D=0A > >>> Ecrit=0D=0A > >>>>> solution - just pointing ou= t that this would be needed (as=0D=0Awith=0D=0A >the=0D=0A > >>>>> 3GPP/= 3GPP2 solution) to fully cover all types of access.=0D=0A > >>>>>>=0D=0A = > >>>>>> Kind Regards=0D=0A > >>>>>>=0D=0A > >>>>>> Stephen=0D=0A > = >>>>>> -----Original Message-----=0D=0A > >>>>>> From: Brian Rosen [mail= to:br@brianrosen.net]=0D=0A > >>>>>> Sent: Wednesday, February 18, 2009 8= :07 PM=0D=0A > >>>>>> To: Edge, Stephen; 'ECRIT'=0D=0A > >>>>>> Subject= : RE: [Ecrit] Comments on Framework Draft=0D=0A > >>>>>>=0D=0A > >>>>>>= I have bit my tongue on this one for a long time.=0D=0A > >>>>>>=0D=0A = > >>>>>> Stephen, with respect, please go talk to 3GPP management and=0D=0A= ask=0D=0A > >>> them=0D=0A > >>>>> why=0D=0A > >>>>>> there has been = no participation in the ecrit effort despite=0D=0A > >>> multiple=0D=0A = > >>>>> YEARS=0D=0A > >>>>>> of begging them to get involved. To put it= frankly, 3GPP is=0D=0A >quite=0D=0A > >>>>> willing=0D=0A > >>>>>> to= bully IETF into doing its work on its schedule, but=0D=0Acannot be=0D=0A = > >>>>> bothered to=0D=0A > >>>>>> get work done it knows it will eventu= ally have to do when=0D=0Athe=0D=0A >IETF=0D=0A > >>>>> asks it=0D=0A >= >>>>>> to do so.=0D=0A > >>>>>>=0D=0A > >>>>>> 3GPP understands the m= ess that is being created by not=0D=0A > >>> participating.=0D=0A > >>>= >> They=0D=0A > >>>>>> know full well that when they finally get around t= o dealing=0D=0Awith=0D=0A > >>>>>> PS=0D=0A > >>>>>> terminated emergen= cy calls, that there will be a lot of=0D=0A >resistance=0D=0A > >>> to=0D= =0A > >>>>>> changing fully specified and implemented standards to more=0D= =0A >closely=0D=0A > >>>>> align=0D=0A > >>>>>> with 3GPP standards. = I expect you will have several=0D=0A >interworking=0D=0A > >>>>> functio= ns=0D=0A > >>>>>> to define and build.=0D=0A > >>>>>>=0D=0A > >>>>>> = So, politely, please go away, we're finishing work we dearly=0D=0A > >>>>= >> wanted=0D=0A > >>>>> you all=0D=0A > >>>>>> to be involved with for = years, but you refused to do=0D=0Aanything.=0D=0A > >>> It's=0D=0A > >>= >>> too=0D=0A > >>>>>> late for this rev.=0D=0A > >>>>>>=0D=0A > >>>>= >> Now, having said that, there are quite a few people who have=0D=0A > >= >>>> participated in=0D=0A > >>>>>> the IETF work who are IMS aware and I= believe that despite=0D=0Ayour=0D=0A > >>>>> fears,=0D=0A > >>>>>> eve= rything you need is in the specs. The mechanisms we have=0D=0A > >>> def= ined=0D=0A > >>>>> provide=0D=0A > >>>>>> the ability for the network t= o insert location, recognize=0D=0Aand=0D=0A >mark=0D=0A > >>>>> emergenc= y=0D=0A > >>>>>> calls, and route on behalf of endpoints. An E-CSCF coul= d=0D=0Aquite=0D=0A > >>>>>> straightforwardly provide a SIP call towards = an ecrit=0D=0Acompatible=0D=0A > >>>>> PSAP. The=0D=0A > >>>>>> only n= ot-quite-nice interwork would be from SUPL to HELD (or=0D=0A >SIP),=0D=0A = > >>>>> but it's=0D=0A > >>>>>> pretty easy to do that. I'll also note= that we have tried=0D=0Ato=0D=0A >get=0D=0A > >>> OMA=0D=0A > >>>>> a= nd=0D=0A > >>>>>> IETF to cooperate on location protocols, but we have be= en=0D=0A > >>>>> spectacularly=0D=0A > >>>>>> unsuccessful at that effo= rt also.=0D=0A > >>>>>>=0D=0A > >>>>>> Brian=0D=0A > >>>>>>=0D=0A > = >>>>>>=0D=0A > >>>>>>=0D=0A > >>>>>>> -----Original Message-----=0D=0A= > >>>>>>> From: ecrit-bounces@ietf.org=0D=0A[mailto:ecrit-bounces@ietf.o= rg] On=0D=0A > >>>>> Behalf=0D=0A > >>>>>>> Of Edge, Stephen=0D=0A > = >>>>>>> Sent: Thursday, February 05, 2009 2:50 AM=0D=0A > >>>>>>> To: 'EC= RIT'=0D=0A > >>>>>>> Subject: [Ecrit] Comments on Framework Draft=0D=0A = > >>>>>>>=0D=0A > >>>>>>> All=0D=0A > >>>>>>>=0D=0A > >>>>>>> draft-= ietf-ecrit-framework-07 is (as we see it) a mostly=0D=0A > >>> informativ= e=0D=0A > >>>>>>> description of how terminals and networks should suppor= t=0D=0A > >>>>>>> emergency=0D=0A > >>>>>>> calls made over IP capable = facilities to IP capable PSAPs.=0D=0AIt=0D=0A > >>>>> appears=0D=0A > >= >>>>>> intended to cover all types of access network - including=0D=0Afixed=0D= =0A > >>>>> line,=0D=0A > >>>>>>> WiFi and cellular (e.g. examples invo= lving each can be=0D=0Afound=0D=0A > >>>>> throughout=0D=0A > >>>>>>> t= he draft).=0D=0A > >>>>>>>=0D=0A > >>>>>>> When we evaluated this with = respect to support of wireless=0D=0A > >>> cellular=0D=0A > >>>>>>> acc= ess and WiFi access associated with a cellular operator=0D=0A >(e.g.=0D=0A= > >>>>> WLAN=0D=0A > >>>>>>> or Femto cells integrated into a cellular= network), we=0D=0Afound=0D=0A >that=0D=0A > >>>>>>> certain portions of= the draft exhibited one or more of the=0D=0A > >>> following=0D=0A > >= >>>>>> characteristics:=0D=0A > >>>>>>>=0D=0A > >>>>>>> (A) Inconsis= tent with already standardized wireless=0D=0A >solutions=0D=0A > >>>>>>>=0D= =0A > >>>>>>> (B) Inconsistent with essential wireless requirements=0D= =0Aand=0D=0A > >>>>>>> conventions=0D=0A > >>>>>>>=0D=0A > >>>>>>> = (C) Already part of wireless standards or potentially=0D=0Apart=0D=0A >of=0D= =0A > >>>>>>> future standards=0D=0A > >>>>>>>=0D=0A > >>>>>>> (A) re= fers to all portions of the draft framework that=0D=0Adiffer=0D=0A > >>>>= >>> from=0D=0A > >>>>> the=0D=0A > >>>>>>> requirements and procedures = currently standardized for=0D=0Awireless=0D=0A > >>>>>>> emergency access= by 3GPP, 3GPP2 and OMA. This is a plain=0D=0A > >>> difference=0D=0A > = >>>>> of=0D=0A > >>>>>>> solution and could be resolved through support = of both=0D=0A >solutions=0D=0A > >>> by=0D=0A > >>>>>>> terminals (wit= h each solution being used according to the=0D=0Atype=0D=0A >of=0D=0A > = >>>>>>> access network and VSP) or could be resolved by supporting=0D=0Aonl= y=0D=0A > >>> one=0D=0A > >>>>>>> solution and accessing only the types= of network supporting=0D=0A >that=0D=0A > >>>>>>> solution. To acknowle= dge this category, the framework=0D=0Adocument=0D=0A > >>> could=0D=0A >= >>>>>>> reference the applicable wireless standards and point out=0D=0Ath= at=0D=0A > >>> these=0D=0A > >>>>>>> are valid alternatives for wireles= s cellular based access.=0D=0A > >>>>>>>=0D=0A > >>>>>>> (B) refers to = portions of the draft that would be=0D=0Aunsuitable=0D=0A >for=0D=0A > >= >>>>>> wireless networks even if no alternative solution existed=0D=0A > = >>>>>>> together=0D=0A > >>>>> with=0D=0A > >>>>>>> other portions miss= ing from the draft that would be needed=0D=0Ato=0D=0A > >>> fully=0D=0A = > >>>>>>> support wireless networks. Examples of the former include:=0D=0A= (a)=0D=0A > >>>>> emphasis=0D=0A > >>>>>>> on endpoint derivation of lo= cation, performance of Lost=0D=0Aquery=0D=0A >and=0D=0A > >>>>>>> receip= t of local dial strings; (b) restriction of LCPs to=0D=0A > >>> protocols=0D= =0A > >>>>>>> that require terminal initiation (not allowing for network=0D= =0A > >>>>> initiation=0D=0A > >>>>>>> as far as we can tell) and that = include two LCPs (DHCP and=0D=0A >LLDP)=0D=0A > >>>>> that=0D=0A > >>>= >>>> are not applicable to (not defined for) cellular access;=0D=0Aand=0D=0A= >(c)=0D=0A > >>> the=0D=0A > >>>>>>> requirement that a terminal or a= t least a LIS will update=0D=0Athe=0D=0A > >>>>>>> PSAP=0D=0A > >>>>>>>= whenever location changes. (a) is impractical due to=0D=0Anetwork=0D=0A >= and=0D=0A > >>>>>>> terminal loading consequences and failure to support = non-IP=0D=0A > >>> capable=0D=0A > >>>>>>> PSAPs; (b) makes location ve= rification and updated location=0D=0A > >>>>> provision=0D=0A > >>>>>>>= to PSAPs difficult or impossible; while (c) is also=0D=0A >incompatible=0D= =0A > >>>>> with=0D=0A > >>>>>>> support of existing non-IP capable PSA= Ps besides increasing=0D=0A > >>> terminal=0D=0A > >>>>>>> load and pos= sibly interfering with optimum maintenance of=0D=0Athe=0D=0A >RF=0D=0A > = >>>>>>> connection (e.g. if a terminal has to tune away from the=0D=0A >s= erving=0D=0A > >>>>> base=0D=0A > >>>>>>> station or WLAN periodically = to make location=0D=0Ameasurements).=0D=0A > >>>>> Examples=0D=0A > >>>= >>>> of the latter include (d) absence of support for access to=0D=0Anon-=0D= =0A >IP=0D=0A > >>>>>>> capable PSAPs as already mentioned (e.g. to supp= ort E911=0D=0Aphase=0D=0A >2=0D=0A > >>> in=0D=0A > >>>>> the=0D=0A >= >>>>>>> US); (e) no support for handover from the IP to the circuit=0D=0A= > >>>>>>> domain=0D=0A > >>>>> when=0D=0A > >>>>>>> a terminal loses= (e.g. moves out of) RF coverage in the IP=0D=0A > >>>>>>> domain;=0D=0A = > >>>>> and=0D=0A > >>>>>>> (f) no allowance for limited access modes w= herein a=0D=0Aterminal=0D=0A >may=0D=0A > >>>>> access=0D=0A > >>>>>>>= a network only to place an emergency call with ensuing=0D=0A > >>> restr= ictions=0D=0A > >>>>> on=0D=0A > >>>>>>> (for example) location acquisi= tion, PSAP callback and=0D=0Acaller=0D=0A > >>>>>>> verification and iden= tification to the PSAP. To resolve=0D=0Athis=0D=0A > >>>>> category=0D=0A= > >>>>>>> either significant changes to the framework document could=0D=0A= be=0D=0A > >>>>>>> made=0D=0A > >>>>> or a=0D=0A > >>>>>>> disclaimer= /applicability statement could be added stating=0D=0Athat=0D=0A > >>>>> s= upport=0D=0A > >>>>>>> of cellular wireless networks and their associated= WLAN and=0D=0A >Femto=0D=0A > >>>>>>> access points is not covered.=0D=0A= > >>>>>>>=0D=0A > >>>>>>> Category (C) comprises concepts and capabili= ties in the=0D=0Adraft=0D=0A > >>>>>>> that=0D=0A > >>>>> are=0D=0A > = >>>>>>> either already part of the standardized solution for=0D=0Awireless=0D= =0A > >>>>> networks=0D=0A > >>>>>>> or that might be added at a later = time. Examples of the=0D=0Aformer=0D=0A > >>>>> include=0D=0A > >>>>>>>= LoST, SIP location conveyance, general use of SIP, location=0D=0Afor=0D=0A= > >>>>> routing=0D=0A > >>>>>>> versus for dispatch, cellular position= ing methods. Examples=0D=0Aof=0D=0A > >>>>>>> the=0D=0A > >>>>>>> latte= r include use of location references and dereferencing=0D=0Aand=0D=0A > >= >>>>>> possible interworking between the current wireless network=0D=0A > = >>> solutions=0D=0A > >>>>>>> (in 3GPP, 3GPP2 and OMA) and the solution = described in this=0D=0A > >>>>>>> draft.=0D=0A > >>>>> The=0D=0A > >>= >>>>> presence of this category could be acknowledged by=0D=0Afollowing=0D=0A= >the=0D=0A > >>>>>>> disclaimer for (B) with a statement that certain p= ortions=0D=0Aof=0D=0A >the=0D=0A > >>>>>>> solution are expected to be i= ncorporated into wireless=0D=0Anetworks=0D=0A > >>> now=0D=0A > >>>>>>>= and/or in the future.=0D=0A > >>>>>>>=0D=0A > >>>>>>> We hope that the= se comments will be seen to be a useful=0D=0A >addition=0D=0A > >>> to=0D= =0A > >>>>>>> this review in the sense of enabling a more precise scoping=0D= =0Afor=0D=0A > >>> the=0D=0A > >>>>>>> framework document and we are wi= lling to assist in=0D=0Aproviding=0D=0A > >>> wording=0D=0A > >>>>>>> f= or any disclaimer/applicability statement that the Ecrit=0D=0A >working=0D= =0A > >>>>> group=0D=0A > >>>>>>> may now deem fit to include.=0D=0A >= >>>>>>>=0D=0A > >>>>>>> Kind Regards=0D=0A > >>>>>>>=0D=0A > >>>>>>= > Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk=0D=0ABurroughs=0D=0A = > >>>>> (Qualcomm=0D=0A > >>>>>>> 3GPP2 TSG-X and TSG-C participant)=0D=0A= > >>>>>>>=0D=0A > >>>>>>> PS this being sent on 2/4/09 at 11:50pm PST=0D= =0A > >>>>>>>=0D=0A > >>>>>>> _________________________________________= ______=0D=0A > >>>>>>> Ecrit mailing list=0D=0A > >>>>>>> Ecrit@ietf.or= g=0D=0A > >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A > >= >>>>>=0D=0A > >>>>>> _______________________________________________=0D=0A= > >>>>>> Ecrit mailing list=0D=0A > >>>>>> Ecrit@ietf.org=0D=0A > >>= >>>> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A > >>>>>>=0D=0A > = >>>>> _______________________________________________=0D=0A > >>>>> Ecri= t mailing list=0D=0A > >>>>> Ecrit@ietf.org=0D=0A > >>>>> https://www.i= etf.org/mailman/listinfo/ecrit=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, proprietary, or otherwise private=0D=0Ainformation.=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 > >>> ------------------------=0D=0A > >>>> [mf2= ]=0D=0A > >>>> _______________________________________________=0D=0A > = >>>> Ecrit mailing list=0D=0A > >>>> Ecrit@ietf.org=0D=0A > >>>> https:= //www.ietf.org/mailman/listinfo/ecrit=0D=0A > >>>>=0D=0A > >>>=0D=0A >= >>> _______________________________________________=0D=0A > >>> Ecrit m= ailing list=0D=0A > >>> Ecrit@ietf.org=0D=0A > >>> https://www.ietf.org= /mailman/listinfo/ecrit=0D=0A > >>>=0D=0A > >>> *****=0D=0A > >>>=0D=0A= > >>> The information transmitted is intended only for the person or=0D=0A= > >>> entity to=0D=0A > >>> which it is addressed and may contain conf= idential,=0D=0Aproprietary,=0D=0A > >>> and/or=0D=0A > >>> privileged m= aterial. Any review, retransmission, dissemination=0D=0Aor=0D=0A > >>> ot= her=0D=0A > >>> use of, or taking of any action in reliance upon this=0D=0A= information=0D=0A >by=0D=0A > >>> persons or entities other than the int= ended recipient is=0D=0A > >>> prohibited. If=0D=0A > >>> you received = this in error, please contact the sender and=0D=0Adelete=0D=0A >the=0D=0A = > >>> material from all computers. GA621=0D=0A > >>>=0D=0A > >>>=0D=0A= > >>> _______________________________________________=0D=0A > >>> Ecri= t mailing list=0D=0A > >>> Ecrit@ietf.org=0D=0A > >>> https://www.ietf.= org/mailman/listinfo/ecrit=0D=0A > >> ___________________________________= ____________=0D=0A > >> Ecrit mailing list=0D=0A > >> Ecrit@ietf.org=0D= =0A > >> https://www.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 rece= ived it in error, please notify the sender=0D=0A > >immediately and delet= e the original. Any unauthorized use of=0D=0A > >this email is prohibite= d.=0D=0A >=0D=0A>---------------------------------------------------------= -------------=0D=0A >---=0D=0A > >-----------------------=0D=0A > >[mf= 2]=0D=0A >=0D=0A >=0D=0A >=0D=0A=20=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 >im= mediately and delete the original. Any unauthorized use of=0D=0A >this em= ail is prohibited.=0D=0A=20=0D=0A>-----------------------------------------= ------------------------------=0D=0A--=0D=0A >-----------------------=0D=0A= >[mf2]=0D=0A >=0D=0A >_______________________________________________=0D= =0A >Ecrit mailing list=0D=0A >Ecrit@ietf.org=0D=0A >https://www.ietf.or= g/mailman/listinfo/ecrit=0D=0A=0D=0A---------------------------------------= ---------------------------------------------------------=0D=0AThis message= is for the designated recipient only and may=0D=0Acontain privileged, prop= rietary, or otherwise private information. =20=0D=0AIf you have received it= in error, please notify the sender=0D=0Aimmediately and delete the origina= l. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A-----------= ---------------------------------------------------------------------------= ----------=0D=0A[mf2]=0D=0A From sedge@qualcomm.com Thu Mar 5 19:08:53 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CDB63A657C for ; Thu, 5 Mar 2009 19:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.399 X-Spam-Level: X-Spam-Status: No, score=-105.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzig4r+Q++Et for ; Thu, 5 Mar 2009 19:08:50 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 4121B3A67F7 for ; Thu, 5 Mar 2009 19:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1236308960; x=1267844960; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" Winterbottom,=20James"=20, =0D=0A=20=20=20=20=20=20=20=20"Stark,=20Barbara"=0D=0A=09 ,=0D=0A=20=20=20=20=20=20=20=20"br@brianr osen.net"=20|CC:=20ECRIT=20|Date:=20Thu,=205=20Mar=202009=2019:09:10=20-0800 |Subject:=20RE:=20[Ecrit]=20Comments=20on=20Framework=20D raft|Thread-Topic:=20[Ecrit]=20Comments=20on=20Framework =20Draft|Thread-Index:=20AcmY6xMaVsPKQOa6Rj2puYM6nfd6RAAC FkpAARDTCVAAAJ6vQAACazkAAAEGgtAALy6v8A=3D=3D|Message-ID: =20<1288E74A73964940B132A0B9EA8D8ABC5374A25E@NASANEXMB04. na.qualcomm.com>|References:=20<1288E74A73964940B132A0B9E A8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff $fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC 53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bb n.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB 04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53 749E4B@NASANEXMB04.na.qualcomm.com><64147.24.154.127.233. 1235746352.squirrel@www.brianrosen.net><7582BC68E4994F4AB F0BD4723975C3FA0D39534E@crexc41p>=0D=0A=20<1288E74A739649 40B132A0B9EA8D8ABC5374A196@NASANEXMB04.na.qualcomm.com> =0D=0A=20=0D=0A=20<1288E74A73964940B132A0B9EA8D8ABC537 4A197@NASANEXMB04.na.qualcomm.com>=0D=0A=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5544"=3B=20a=3D"16033359"; bh=ASD6XD012PZdkDV++/PGDzjyYLJIvVRp2zkckz8d8Pg=; b=MWIFJoM2G2hLVaSA5tqi0ZqeMRIQcRSDmFx17YdpY4w3JTjM/jNFLWC1 VBot9Jh3GQAJQbkHyBeDD78+RZx76fUKygaxotXurbGad2/5BHlFljw/W HIfqczklTyWaUGaCmk3W3fgrkbq1Mgw62+y/+tn1mnUDv0nA+JgNTtguE c=; X-IronPort-AV: E=McAfee;i="5300,2777,5544"; a="16033359" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Mar 2009 19:09:20 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2639Jxo010063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Mar 2009 19:09:20 -0800 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2639F97010408 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Mar 2009 19:09:17 -0800 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub01.na.qualcomm.com ([10.46.93.121]) with mapi; Thu, 5 Mar 2009 19:09:14 -0800 From: "Edge, Stephen" To: "Winterbottom, James" , "Stark, Barbara" , "br@brianrosen.net" Date: Thu, 5 Mar 2009 19:09:10 -0800 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmY6xMaVsPKQOa6Rj2puYM6nfd6RAACFkpAARDTCVAAAJ6vQAACazkAAAEGgtAALy6v8A== Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5374A25E@NASANEXMB04.na.qualcomm.com> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com><64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net><7582BC68E4994F4ABF0BD4723975C3FA0D39534E@crexc41p> <1288E74A73964940B132A0B9EA8D8ABC5374A196@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5374A197@NASANEXMB04.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 03:08:53 -0000 Hi James Thanks for the further responses for which I have added some more of my own= below. Please note in particular that SUPL 1.0 is widely deployed and can = be used (and is being used by one carrier) for emergency call support for h= ome users and that SUPL 2.0 while not yet deployed is entering its IOP phas= e that will validate both the standard and particular server and terminal i= mplementations (later this year) after which we expect that deployments wil= l swiftly follow. Echoing what Gabor has said, would you say that this is not a current pract= ice? And if so, where is the LCP suitable for IP emergency calls that is be= ing used more widely by cellular carriers? Kind Regards Stephen ________________________________________ From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Wednesday, March 04, 2009 8:13 PM To: Edge, Stephen; Stark, Barbara; br@brianrosen.net Cc: ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Hi Stephen, Thankyou for you comments. A few in response inline. Cheers James -----Original Message----- From: Edge, Stephen [mailto:sedge@qualcomm.com] Sent: Thursday, 5 March 2009 2:55 PM To: Winterbottom, James; Stark, Barbara; br@brianrosen.net Cc: ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Hi James Thanks for these comments. I assume you recall that SUPL would use an E-SLP located in the serving 3GP= P/3GPP2 network in case of combined access and VSP support. There are then = no roaming or global database issues as all location is supported within th= e serving network. [AJW] You are quite correct, the E-SLP is the node that would be used. Just= to point out though that there are no SETs currently that support the larg= e number of E-SLP certificates required to make this solution workable, sin= ce the SET is not allowed to respond to an SLP that it cannot authenticate.= I certainly think it remains to be seen is the currently proposed E-SLP tr= ust model is workable on a large scale. [SE] SUPL 2.0 is not yet deployed so naturally there are no SETs commercial= ly available yet with this capability. But IOP testing is planned to occur = shortly and then may be seen to be workable. Recall that you are claiming that the current Ecrit solution minus SUPL is = suitable for this case which will be by far the most common one for emergen= cy calls made via cellular networks. So I still ask you to justify why mand= ating support for DHCP and HELD and not including SUPL is a suitable soluti= on. [AJW] There are no SUPL 2.0 deployments at this stage, and SUPL 1.0 is not = suitable for emergency services. So nobody is making SUPL emergency calls a= t this stage. I do however know of i2 and i3/ECRIT trials that are currentl= y in progress where devices are obtaining location information from a LIS. [SE] Actually there is one Asian WCDMA carrier using SUPL 1.0 to obtain loc= ation for emergency calls from home users in the circuit domain. This is no= t a trial but for real. Furthermore, a number of 3GPP and 3GPP2 carriers ar= e planning for SUPL 2.0 deployment. For other scenarios not involving cellular access or where the cellular car= rier is used only as an ISP, SUPL can still be suitable. For example, it is= not true that a worldwide detailed database would be needed (e.g. containi= ng the cell IDs of networks). A-GPS and A-GNSS can work quite well using fa= irly coarse location information (e.g. country or network identification) t= o seed assistance data and such coarse location information can be obtained= by a number of means (e.g. IP address, country/network portions of a cell = ID, previous location estimate). [AJW] This can work outside quite well I agree, although I am not aware of = devices being able to converge on a location fast enough so that it can be = used at call time to assist with routing. I think that you will also agree = that using coarse-level assistance data to requires significantly more powe= r usage by the mobile than it were simply provided with acquisition assista= nce. This latter information cannot be provided without a finer-grained see= d location as a reference point. [SE] yes you are right that with the present versions of the 3GPP/3GPP2 sol= ution and SUPL any location would most probably be used for dispatch and no= t routing. The mobile power use should not be factor given the rarity and i= mportance of an emergency call - which means location should be obtainable = in most outdoor scenarios and some indoor ones. Note that with a coarse loc= ation estimate with a possible error of say <=3D1500 miles and an approxima= te time estimate with an error of say <=3D3 seconds, it is possible to dete= rmine satellites in view and a small Doppler search window that will improv= e satellite acquisition well beyond what can be achieved in standalone mode= or where time is completely unknown. Kind Regards Stephen -----Original Message----- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Wednesday, March 04, 2009 7:02 PM To: Edge, Stephen; Stark, Barbara; br@brianrosen.net Cc: ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Hi Stephen, SUPL has one very huge disadvantage, it mandates the use of a home SLP. SUPL roaming between carriers is basically unimplementable. The mechanisms required to support an H-SLP determining the V-SLP address are deliberately left out of scope by OMA, and large numbers of companies are busily putting IPR on the ways in which this can occur. There are no large-scale deployments of RLP that I am aware of, and this is a clear indicator of how bad the currently proposed architecture is. All this means that for SUPL to be deployable on a large scale any H-SLP simply has to have the entire world in a database. This is abundantly evident when you look at systems like the global Nokia solution. I think that this is mammoth task to maintain for general cell coverage, on a global basis when you include W-LAN and femto-cells it is quite simply ridiculous. The result is that SUPL is next to useless as a solution for anything other than providing basic-cell location or assistance data for GPS. It is not local in the same sense that an LCP is. All of the other determination mechanisms that you described in your previous email simply don't work in SUPL to any reasonable degree, and I would argue don't work at all once the device in a foreign network. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Edge, Stephen Sent: Thursday, 5 March 2009 1:20 PM To: Stark, Barbara; br@brianrosen.net Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft Barbara and others Thanks for the comments. When I look at the PhoneBCP I see that both HELD and DHCP are mandatory for the device whereas at least one of these is mandatory for the AN. While I can also see that SUPL is not ruled out (though it is not mentioned or referenced), it appears to have been displaced by the HELD and DHCP requirements. On the other hand, many cellular networks have already deployed or are in the process of deploying SUPL and I am not aware of any that have deployed an accurate location capability using HELD or DHCP. So I would like to know how you see the current requirements as being suitable - after all, they imply at the very least additional development and deployment on the part of network and device vendors and network operators, whereas if SUPL was one of the defined LCPs, that additional development and deployment might be mostly avoided. This question would not be applicable with some additional scope limitation and so I had not previously raised it. But it is certainly applicable in the context of the global scope that is being claimed by some responders. Kind Regards Stephen -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Friday, February 27, 2009 8:28 AM To: br@brianrosen.net; Edge, Stephen Cc: ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Thank you Brian. This is well said [except you left out the fact that ecrit also allows for devices to get their location through other mechanisms, such as GPS, SUPL, or other methods, and doesn't insist that the location be configured through DHCP or HELD]. I agree 100% that additional qualifications are unnecessary. Service providers, vendors, national bodies dealing with emergency services, and regulators aren't stupid. Please trust us to figure out for ourselves when/where/how to apply a "standard". There is no need to try to artificially limit or define scope, or to state the obvious (e.g., the architecture applies where it applies, and doesn't apply where it doesn't apply). We understand the role and scope of the IETF, and the role and scope of 3GPP and 3GPP2. And all the other SDOs (and national bodies and regulatory agencies). SDOs need to offer architectures that apply within the area of applicability for that SDO, and are useful to potential implementers, and leave it to the SPs, national bodies and regulators to decide which architectures and standards to use or to mandate within the scope of their network or jurisdiction. Again, we aren't stupid. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of br@brianrosen.net Sent: Friday, February 27, 2009 9:53 AM To: Edge, Stephen Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft Stephen Like any standards organization, the IETF restricts it's scope. Generally, the scope is "the Internet", although we very often describe solutions that are explicitly designed for private IP networks as well as the Internet. We don't write standards for circuit switched networks, and it should be no surprise that the ecrit solution does not cater to CS solutions. Nevertheless, we often try to make sure that our solutions harmonize reasonably well with existing solutions. Indeed, the ecrit solution clains global applicability to the Internet in general, and most private IP networks that can be interconnected to the Internet or to other IP networks via gateways. Looking at your list of problem areas: > - access to PSTN capable PSAPs This is out of scope for IETF. NENA has active work on this subject. It seems straightforward to interwork ecrit compatible devices and networks to existing CS connected PSAPs. As you know, CS interconnects are very nation-specific, so the NENA work may not have general applicability. However, it shows that it is possible to interwork. The NENA i2 work is also designed to take ecrit compatible devices and VSP networks, and interwork them to the existing network. The VSP would direct the call to the VPC, which would provide the services it does now, using the device provided location for routing. This is important for smooth transition from existing PSAPs and VSPs to "next generation" PSAPs and VSPs. > - handover between different IP access networks including different > types of access network In the ecrit solution, the access network the call is initiated on provides all the facilities needed for the device to initiate an emergency call. The call starts traversing it's normal call path, and eventually routes to the ESRP. Handoffs between IP networks should be transparent to this process, although we probably haven't done all the work we need to do for handoffs where the IP address as seen by the terminating network changes. This would generally be true of all current SIP based work. > - handover to/from circuit mode networks This would be out of scope for IETF. It's as applicable to a simple SIP call as it is a SIP emergency call, and there are no statements in any SIP documents on that subject. > - location for cellular access (and the requirement to support LCPs that > will be useless for cellular access) Location for cellular access networks has been considered carefully. Since cellular is a mobile network, the access network would pass the device a Location-By-Reference URI, using either DHCP or HELD. Either protocol is suitable for cellular networks. As we have pointed out several times, cellular networks support raw data packet services upon which many different kinds of networks can be constructed. My usual example is a large recreational vehicle traveling down a road with a cellular data card plugged into a router to which a wired (Ethernet) phone is connected. That phone must be able to make an emergency call, and it will get location from DHCP or HELD (or LLDP-MED). It is not aware of the cellular network, and doesn't know any cellular specific protocols. Cellular networks will have to support IETF location configuration protocols unless they actively prohibit examples like this, or they implement interworking between cellular-specific location protocols and DHCP or HELD in the data card. The ecrit standards permit proxy insertion of location, but, as above, we don't think that works in all cases. > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) The "load" of using DHCP or HELD to get location and querying LoST is pretty modest. The standards permit proxies to do this if the devices don't. As above, interwork functions to CS connected PSAPs is very feasible, and as above, cellular networks will have to support access to local LoST servers for devices that are connected to cellular networks and are ecrit compliant. > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls This is covered in the standards. None of the processes are dependent on authentication, although where it is possible, it's desirable so as to minimize fraudulent emergency calls Mechanisms for specific network authentication mechanisms are out of scope, and, like SIP basic calling, are not usually mentioned in IETF documents. Stephen, we've tried pretty hard to make sure this works for 3G/4G mobile networks. It's true that it doesn't do it the way 3GPP currently thinks it ought to work, but we claim they haven't thought through all the issues. While it would work, there are opportunities for improvement. We would be willing to do that if we could get the cooperation of 3GPP, which we have tried, and failed, to do. So, I think the documents do not need any qualification statements. Brian > Martin > > The 3GPP/3GPP2 solution has a defined restricted applicability (mainly to > 3GPP/3GPP2 access networks where the serving network also acts as the VSP) > and the specifications for it cover in detail all possible scenarios > consistent with these restrictions so far as we are aware. > > The Ecrit solution seems to claim global applicability to all types of IP > access (and the more that is said about this from Ecrit participants the > more this gets emphasized) but does not cover in detail all possible > scenarios (in some cases does not cover in any detail) which means that at > best the solution is incomplete and at worst intrinsically inapplicable to > some unstated set of scenarios. > > The missing, incomplete and problematic cases include the following: > > - access to PSTN capable PSAPs > - handover between different IP access networks including different > types of access network > - handover to/from circuit mode networks > - location for cellular access (and the requirement to support LCPs that > will be useless for cellular access) > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls > > Stating that some of these cases are out of scope or referencing an > incomplete and possibly questionable specification from some other > national SDO will not help the user who encounters such problems. But it > would certainly help network operators and implementers to acknowledge > their existence in one form or another because that would allow better > planning of deployments and would help focus attention on finding > solutions (whether in IETF or elsewhere) for the missing cases. > > Please note that despite these drawbacks, I will acknowledge that Ecrit > does have a valuable solution that covers many scenarios not covered by > 3GPP/3GPP2. It would be the delineation of these supported scenarios (or > equivalently unsupported scenarios) in some applicability statement that > would be particularly useful right now. > > Kind Regards > > Stephen > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Thursday, February 26, 2009 9:45 PM > To: Edge, Stephen; Richard Barnes > Cc: ECRIT > Subject: RE: [Ecrit] Comments on Framework Draft > > There's benefit in knowing the limitations of a framework, and every > architecture makes certain assumptions. Let's examine them though... > > The IETF might occasionally make the assumption that the standards it > develops are for Internet devices. That assumption probably need not be > stated explicitly. > > The ECRIT architecture relies on implementations of the protocols that it > references. That is not extraordinary. A reliance on implementation of > these protocols by endpoints, routing intermediaries and PSAPs should not > need to be explained. > > So the assumptions are: > - the Internet > - solutions are implemented and deployed > - the end device is a key component > > Only that last element is particularly novel ... or not that much really. > It's a design choice. Unless you were thinking of trunking the voice > elsewhere. > > Of course, you're suggesting that the design choice was made in ignorance > of all the constraints. You're suggesting that - as a result - the choice > is flawed and the solution is not going to work for cellular services. We > disagree. The solution is a basis for emergency calling in _any_ IP > network. > > Cheers, > Martin > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Edge, Stephen >> Sent: Friday, 27 February 2009 3:30 PM >> To: Richard Barnes >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Richard >> >> Thanks for the comments. Your statement below that "SIP emergency >> calling works if all parties behave as specified in these (IETF Ecrit) >> documents" to some degree highlights the problems we are raising. The >> documents do contain a number of implicit and explicit restrictions - >> like IP capable PSAPs, global IP access (no islands of circuit mode >> access for example), universal support of this solution by all access >> providers and VSPs (not much good if some opt for another solution) and >> end system oriented location and routing capability - which together >> make them unsuitable (we believe) for cellular wireless networks. If >> these restrictions and assumptions were all made explicit upfront, it >> would to a large degree (and possibly completely) address our concerns. >> >> You are right in assuming another set of specifications for the 3GPP >> and 3GPP2 solution. The applicability of this solution is explicitly >> defined in TS 23.167 (or more exactly in an already agreed CR in >> contribution S2-090752 which will become part of 23.167 in a few more >> weeks) to cover the following access types: GPRS (UTRAN WCDMA), I-WLAN, >> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN >> (LTE). So there is a restriction and arbitrary internet access is not >> covered (yet) as I have stated before. >> >> Kind Regards >> >> Stephen >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Wednesday, February 25, 2009 6:30 PM >> To: Edge, Stephen >> Cc: Brian Rosen; 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Stephen, >> >> I'm a little confused by the scope of what you're asking. The >> framework >> and phonebcp documents exist in order to describe the ECRIT solution: >> They say, in effect, "SIP emergency calling works if all parties behave >> as specified in these documents." >> >> As I understand what you're saying (and I'm by no means an expert in >> 3GPP), 3GPP specifies that one or more elements of this system behave >> differently. This simply means that 3GPP networks aren't complying >> with >> these specs. Just like there's no disclaimer in RFC 791 (IPv4) that >> says "this doesn't work on X.25 networks", it's not clear to me that an >> analogous disclaimer is called for here. >> >> I presume there are similar documents describing how emergency calling >> works in 3GPP networks. Do they include notes saying that the 3GPP >> solution doesn't work in the broader Internet? >> >> --Richard >> >> >> >> >> >> Edge, Stephen wrote: >> > Brian >> > >> > First of all apologies for the likely lateness of this reply - I >> actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest but >> it seems unlikely that my VPN, Outlook server and WiFi access >> capability will cooperate together to get it sent until I return to the >> office mid-next week. >> > >> > Anyhow thanks for your comments. There have actually been a number of >> conference calls between IETF and 3GPP participants over the last >> couple of years at which common features like support of IP emergency >> calls were discussed and these could have been good forum for >> participants on either side to have raised the kinds of issues you >> elaborate on below. Given that seems not so far to have happened, it >> could still be possible in future such calls. >> > >> > But the issues we are raising are not directly to do with further >> aligning the 2 solutions or with the lack of this in the past. We are >> simply pointing out that the solutions are currently different and that >> from a cellular wireless perspective, the Ecrit solution is not seen as >> suitable in all respects (for support of IP emergency calls originating >> from such access types). That is not just our point of view. 3GPP2 sent >> a liaison to Ecrit some months ago pointing out the same issues. >> > >> > So we are proposing that the Ecrit framework and phoneBCP spec.s >> include a statement acknowledging this - e.g. by referencing the >> alternative 3GPP/3GPP2 solution and indicating the IP access types for >> which the Ecrit solution will work without limitation (or equivalently >> the access types where limitations are not ruled out). >> > >> > We are not proposing further modification and extension of the Ecrit >> solution - just pointing out that this would be needed (as with the >> 3GPP/3GPP2 solution) to fully cover all types of access. >> > >> > Kind Regards >> > >> > Stephen >> > -----Original Message----- >> > From: Brian Rosen [mailto:br@brianrosen.net] >> > Sent: Wednesday, February 18, 2009 8:07 PM >> > To: Edge, Stephen; 'ECRIT' >> > Subject: RE: [Ecrit] Comments on Framework Draft >> > >> > I have bit my tongue on this one for a long time. >> > >> > Stephen, with respect, please go talk to 3GPP management and ask them >> why >> > there has been no participation in the ecrit effort despite multiple >> YEARS >> > of begging them to get involved. To put it frankly, 3GPP is quite >> willing >> > to bully IETF into doing its work on its schedule, but cannot be >> bothered to >> > get work done it knows it will eventually have to do when the IETF >> asks it >> > to do so. >> > >> > 3GPP understands the mess that is being created by not participating. >> They >> > know full well that when they finally get around to dealing with PS >> > terminated emergency calls, that there will be a lot of resistance to >> > changing fully specified and implemented standards to more closely >> align >> > with 3GPP standards. I expect you will have several interworking >> functions >> > to define and build. >> > >> > So, politely, please go away, we're finishing work we dearly wanted >> you all >> > to be involved with for years, but you refused to do anything. It's >> too >> > late for this rev. >> > >> > Now, having said that, there are quite a few people who have >> participated in >> > the IETF work who are IMS aware and I believe that despite your >> fears, >> > everything you need is in the specs. The mechanisms we have defined >> provide >> > the ability for the network to insert location, recognize and mark >> emergency >> > calls, and route on behalf of endpoints. An E-CSCF could quite >> > straightforwardly provide a SIP call towards an ecrit compatible >> PSAP. The >> > only not-quite-nice interwork would be from SUPL to HELD (or SIP), >> but it's >> > pretty easy to do that. I'll also note that we have tried to get OMA >> and >> > IETF to cooperate on location protocols, but we have been >> spectacularly >> > unsuccessful at that effort also. >> > >> > Brian >> > >> > >> > >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf >> >> Of Edge, Stephen >> >> Sent: Thursday, February 05, 2009 2:50 AM >> >> To: 'ECRIT' >> >> Subject: [Ecrit] Comments on Framework Draft >> >> >> >> All >> >> >> >> draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative >> >> description of how terminals and networks should support emergency >> >> calls made over IP capable facilities to IP capable PSAPs. It >> appears >> >> intended to cover all types of access network - including fixed >> line, >> >> WiFi and cellular (e.g. examples involving each can be found >> throughout >> >> the draft). >> >> >> >> When we evaluated this with respect to support of wireless cellular >> >> access and WiFi access associated with a cellular operator (e.g. >> WLAN >> >> or Femto cells integrated into a cellular network), we found that >> >> certain portions of the draft exhibited one or more of the following >> >> characteristics: >> >> >> >> (A) Inconsistent with already standardized wireless solutions >> >> >> >> (B) Inconsistent with essential wireless requirements and >> >> conventions >> >> >> >> (C) Already part of wireless standards or potentially part of >> >> future standards >> >> >> >> (A) refers to all portions of the draft framework that differ from >> the >> >> requirements and procedures currently standardized for wireless >> >> emergency access by 3GPP, 3GPP2 and OMA. This is a plain difference >> of >> >> solution and could be resolved through support of both solutions by >> >> terminals (with each solution being used according to the type of >> >> access network and VSP) or could be resolved by supporting only one >> >> solution and accessing only the types of network supporting that >> >> solution. To acknowledge this category, the framework document could >> >> reference the applicable wireless standards and point out that these >> >> are valid alternatives for wireless cellular based access. >> >> >> >> (B) refers to portions of the draft that would be unsuitable for >> >> wireless networks even if no alternative solution existed together >> with >> >> other portions missing from the draft that would be needed to fully >> >> support wireless networks. Examples of the former include: (a) >> emphasis >> >> on endpoint derivation of location, performance of Lost query and >> >> receipt of local dial strings; (b) restriction of LCPs to protocols >> >> that require terminal initiation (not allowing for network >> initiation >> >> as far as we can tell) and that include two LCPs (DHCP and LLDP) >> that >> >> are not applicable to (not defined for) cellular access; and (c) the >> >> requirement that a terminal or at least a LIS will update the PSAP >> >> whenever location changes. (a) is impractical due to network and >> >> terminal loading consequences and failure to support non-IP capable >> >> PSAPs; (b) makes location verification and updated location >> provision >> >> to PSAPs difficult or impossible; while (c) is also incompatible >> with >> >> support of existing non-IP capable PSAPs besides increasing terminal >> >> load and possibly interfering with optimum maintenance of the RF >> >> connection (e.g. if a terminal has to tune away from the serving >> base >> >> station or WLAN periodically to make location measurements). >> Examples >> >> of the latter include (d) absence of support for access to non-IP >> >> capable PSAPs as already mentioned (e.g. to support E911 phase 2 in >> the >> >> US); (e) no support for handover from the IP to the circuit domain >> when >> >> a terminal loses (e.g. moves out of) RF coverage in the IP domain; >> and >> >> (f) no allowance for limited access modes wherein a terminal may >> access >> >> a network only to place an emergency call with ensuing restrictions >> on >> >> (for example) location acquisition, PSAP callback and caller >> >> verification and identification to the PSAP. To resolve this >> category >> >> either significant changes to the framework document could be made >> or a >> >> disclaimer/applicability statement could be added stating that >> support >> >> of cellular wireless networks and their associated WLAN and Femto >> >> access points is not covered. >> >> >> >> Category (C) comprises concepts and capabilities in the draft that >> are >> >> either already part of the standardized solution for wireless >> networks >> >> or that might be added at a later time. Examples of the former >> include >> >> LoST, SIP location conveyance, general use of SIP, location for >> routing >> >> versus for dispatch, cellular positioning methods. Examples of the >> >> latter include use of location references and dereferencing and >> >> possible interworking between the current wireless network solutions >> >> (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. >> The >> >> presence of this category could be acknowledged by following the >> >> disclaimer for (B) with a statement that certain portions of the >> >> solution are expected to be incorporated into wireless networks now >> >> and/or in the future. >> >> >> >> We hope that these comments will be seen to be a useful addition to >> >> this review in the sense of enabling a more precise scoping for the >> >> framework document and we are willing to assist in providing wording >> >> for any disclaimer/applicability statement that the Ecrit working >> group >> >> may now deem fit to include. >> >> >> >> Kind Regards >> >> >> >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs >> (Qualcomm >> >> 3GPP2 TSG-X and TSG-C participant) >> >> >> >> PS this being sent on 2/4/09 at 11:50pm PST >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www.ietf.org/mailman/listinfo/ecrit >> > >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------ ------------------------ > 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://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.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://www.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] ---------------------------------------------------------------------------= --------------------- 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] From Martin.Dawson@andrew.com Thu Mar 5 19:47:01 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6F5A3A67B1 for ; Thu, 5 Mar 2009 19:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uaHg8p0w+MG for ; Thu, 5 Mar 2009 19:46:58 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 879733A63D3 for ; Thu, 5 Mar 2009 19:46:58 -0800 (PST) X-SEF-Processed: 5_0_0_910__2009_03_05_22_07_11 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 05 Mar 2009 22:07:11 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 21:47:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Mar 2009 21:47:25 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmdZjoOuohgihUhTAGl+xIzZYDEkgABM/qQAANbgBkAGD/o4AAM3GZg References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com><64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net><7582BC68E4994F4ABF0BD4723975C3FA0D39534E@crexc41p><1288E74A73964940B132A0B9EA8D8ABC5374A196@NASANEXMB04.na.qualcomm.com><96AD1EFB-0104-4B64-A94B-7A1877F8ADC6@andrew.com> From: "Dawson, Martin" To: , "Winterbottom, James" X-OriginalArrivalTime: 06 Mar 2009 03:47:27.0864 (UTC) FILETIME=[44DA0780:01C99E0E] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 03:47:01 -0000 Gabor,=0D=0A=0D=0AI believe your first point was that HELD isn't suited to = control plane.=0D=0APrior to your sarcasm about the state of WiMAX deployme= nt, James' point=0D=0Awas simply that HELD is very well suited to control p= lane implementation=0D=0Aand the WiMAX specification is evidence of that.=0D= =0A=0D=0AA HELD-capable LIS is associated with the access network and can a= vail=0D=0Aitself of any measurements that the access network has available.= It's=0D=0Acontrol plane because it doesn't rely on the measurements coming= via the=0D=0Adevice (i.e. user plane). HELD allows for measurements obtain= ed via the=0D=0Acontrol plane and those from the device (user plane).=0D=0A=0D= =0AYour criticism certainly applies to SUPL - but not to HELD.=0D=0A=0D=0AS= UPL does not fit in with the ECRIT model because it is not a service=0D=0Aw= hich can be discovered and used in the network and, also, it cannot=0D=0Ade= liver location by reference and nor can it deliver location in civic=0D=0Aa= ddress form.=0D=0A=0D=0AYou can make SUPL work for emergency calls with a g= reat deal of trouble.=0D=0AOMA added emergency service support in SUPL 2.0.= The "E-SLP" that=0D=0AStephen previously referred to being the case in poi= nt. However, the=0D=0Amodel of use is for the SLP to initiate the location = procedure with the=0D=0ASET. It is an NI-LR mode query originated from the = E-SLP and it is up to=0D=0Athe SET to deal with the fact that it is getting= an unsolicited SUPL=0D=0AINIT message from a previously unknown SLP.=0D=0A=0D= =0AApart from the obvious fact that an arbitrary VoIP service can't know=0D= =0Aanything about E-SLPs in an arbitrary access network, or the fact that=0D= =0Athe ECRIT model doesn't require a VSP to be involved at all, there is=0D= =0Athe simple fact that having the location platform initiate the location=0D= =0Aprocedure is actually the opposite of what ECRIT describes for the=0D=0A= emergency procedure. Nothing to do with a lack of professionalism I'm=0D=0A= afraid.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message----= -=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Beha= lf=0D=0AOf Gabor.Bajko@nokia.com=0D=0ASent: Friday, 6 March 2009 9:14 AM=0D= =0ATo: Winterbottom, James=0D=0ACc: ecrit@ietf.org=0D=0ASubject: Re: [Ecrit= ] Comments on Framework Draft=0D=0A=0D=0AWho talked about LTE=3F=0D=0AThe p= oint is, that cellular networks provide connectivity to internet,=0D=0Aand = they'll be around for many years to come.=0D=0AAnd in those networks A-GPS = combined with U-TDOA/AFLT is the positioning=0D=0Atechnology in use today, = which is unlikely to be replaced in the near=0D=0Afuture as there is no bet= ter alternative around. I always found it=0D=0Aunprofessional to not even m= ention these, but instead mandate dhcp,=0D=0Awhich has a very limited appli= cability.=0D=0A=0D=0A- gabor=0D=0A=0D=0A=0D=0A >-----Original Message-----=0D= =0A >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=0D=0A= Behalf Of=0D=0A >ext Winterbottom, James=0D=0A >Sent: Thursday, March 05,= 2009 1:55 AM=0D=0A >To: Bajko Gabor (Nokia-CIC/MtView)=0D=0A >Cc: ecrit@= ietf.org=0D=0A >Subject: Re: [Ecrit] Comments on Framework Draft=0D=0A >=0D= =0A >There are certainly more WiMAX networks deployed at this point than=0D= =0ALTE=0D=0A >networks... ;P=0D=0A >=0D=0A >But that aside, the experime= ntal HELD location networks we have=0D=0Adeployed=0D=0A >at the last 3 or = so IETF meetings have all been control-plane and not=0D=0A >user-plane fro= m a location determination perspective.=0D=0A >=0D=0A >Cheers=0D=0A >Jam= es=0D=0A >=0D=0A >=0D=0A >=0D=0A >-----Original Message-----=0D=0A >Fr= om: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]=0D=0A >Sent: Thu = 3/5/2009 2:25 AM=0D=0A >To: Winterbottom, James=0D=0A >Cc: sedge@qualcomm= =2Ecom; bs7652@att.com; br@brianrosen.net;=0D=0Aecrit@ietf.org=0D=0A >Subj= ect: RE: [Ecrit] Comments on Framework Draft=0D=0A >=0D=0A >Oh, I forgot = about the abundance of deployed wimax networks. Huge=0D=0A >mistake, indee= d.=0D=0A >=0D=0A >- gabor=0D=0A >=0D=0A > >-----Original Message-----=0D= =0A > >From: ext Winterbottom, James=0D=0A[mailto:James.Winterbottom@andr= ew.com]=0D=0A > >Sent: Wednesday, March 04, 2009 11:44 PM=0D=0A > >To: = Bajko Gabor (Nokia-CIC/MtView)=0D=0A > >Cc: sedge@qualcomm.com; bs7652@at= t.com; br@brianrosen.net;=0D=0A >ecrit@ietf.org=0D=0A > >Subject: Re: [E= crit] Comments on Framework Draft=0D=0A > >=0D=0A > >Gabor,=0D=0A > >=0D= =0A > >You absolutey and totally wrong about HELD and control-plane. If=0D= =0A > >anything, native HELD is best suited to control-plane location.=0D= =0AIndeed=0D=0A > >in WiMAX it is the only means to invoke control-plane = location.=0D=0A > >=0D=0A > >Cheers James=0D=0A > >=0D=0A > >Sent f= rom my iPhone=0D=0A > >=0D=0A > >On 05/03/2009, at 5:07 PM, "Gabor.Bajk= o@nokia.com"=0D=0A > > > wrote:=0D=0A > = >=0D=0A > >> Stephen,=0D=0A > >>=0D=0A > >> Thanks for pointing out t= hese issues. If you look at the=0D=0Aprevious=0D=0A > >> versions of phon= eBCP, you'll also see LLDP (which was developed=0D=0Afor=0D=0A > >> fixed= environment, like switches) on the list of mandatory LCPs.=0D=0AIt=0D=0A = > >> took 2 years (!) to take that out from there, so in that sense=0D=0At= here=0D=0A > >> is some progress towards writing a more realistic set of=0D= =0A >requirements.=0D=0A > >>=0D=0A > >> When it was requested to add = SUPPL to the list, or to at least=0D=0A > >> mention that SUPPL is the on= e which is currently mostly used for=0D=0A > >> positioning (what an impe= rtinent request it was to add to a=0D=0Adocument=0D=0A > >> intended to d= escribe BEST Current Practices, the protocols which=0D=0Aare=0D=0A > >> c= urrently in use), the argument against it was that SUPPL=0D=0Arequires=0D=0A= > >> the existence of a subscription, while the internet is=0D=0Asubscri= ption=0D=0A > >> free.=0D=0A > >>=0D=0A > >> Meanwhile people refused= to take a look at the applicability of=0D=0Aa=0D=0A > >> DHCP based posi= tioning method in today's world, where everything=0D=0A > >> tends to be = mobile.=0D=0A > >>=0D=0A > >> An HTTP based protocol like HELD has the = potential to offer=0D=0Asolution=0D=0A > >> for many, but not all of the = use cases, as it can deliver=0D=0Alocation=0D=0A > >> related measurement= information to location servers. The cases=0D=0Awhen=0D=0A > >> HELD doe= s not work is when positioning is done using network=0D=0Abased=0D=0A > >= > positioning methods involving control plane, like U-TDOA or=0D=0AAFLT.=0D= =0A > >> But then again, these are the positioning technologies which are=0D= =0A > >> currently used in indoor environments where (A-)GPS does not=0D=0A= work.=0D=0A > >> Perhaps this is the reason why they are not mentioned in= a Best=0D=0A > >> Current Practice document ...=0D=0A > >>=0D=0A > >= > - Gabor=0D=0A > >>=0D=0A > >>=0D=0A > >>> -----Original Message----= -=0D=0A > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On=0D=0A > >>> Behalf Of=0D=0A > >>> ext Edge, Stephen=0D=0A > >>> = Sent: Wednesday, March 04, 2009 6:20 PM=0D=0A > >>> To: Stark, Barbara; b= r@brianrosen.net=0D=0A > >>> Cc: ECRIT=0D=0A > >>> Subject: Re: [Ecrit]= Comments on Framework Draft=0D=0A > >>>=0D=0A > >>> Barbara and others=0D= =0A > >>>=0D=0A > >>> Thanks for the comments.=0D=0A > >>>=0D=0A > = >>> When I look at the PhoneBCP I see that both HELD and DHCP are=0D=0A > = >>> mandatory=0D=0A > >>> for the device whereas at least one of these i= s mandatory for=0D=0Athe=0D=0A >AN.=0D=0A > >>> While I can also see tha= t SUPL is not ruled out (though it is=0D=0Anot=0D=0A > >>> mentioned or r= eferenced), it appears to have been displaced by=0D=0Athe=0D=0A > >>> HEL= D=0D=0A > >>> and DHCP requirements. On the other hand, many cellular=0D=0A= networks=0D=0A >have=0D=0A > >>> already deployed or are in the process = of deploying SUPL and I=0D=0Aam=0D=0A >not=0D=0A > >>> aware of any that= have deployed an accurate location capability=0D=0A >using=0D=0A > >>> = HELD or DHCP. So I would like to know how you see the current=0D=0A > >>>= requirements as being suitable - after all, they imply at the=0D=0Avery=0D= =0A > >>> least=0D=0A > >>> additional development and deployment on th= e part of network=0D=0Aand=0D=0A > >>> device=0D=0A > >>> vendors and n= etwork operators, whereas if SUPL was one of the=0D=0A >defined=0D=0A > = >>> LCPs, that additional development and deployment might be=0D=0Amostly=0D= =0A > >>> avoided.=0D=0A > >>> This question would not be applicable wi= th some additional=0D=0Ascope=0D=0A > >>> limitation and so I had not pre= viously raised it. But it is=0D=0A >certainly=0D=0A > >>> applicable in=0D= =0A > >>> the context of the global scope that is being claimed by some=0D= =0A > >>> responders.=0D=0A > >>>=0D=0A > >>> Kind Regards=0D=0A > = >>>=0D=0A > >>> Stephen=0D=0A > >>> -----Original Message-----=0D=0A >= >>> From: Stark, Barbara [mailto:bs7652@att.com]=0D=0A > >>> Sent: Frid= ay, February 27, 2009 8:28 AM=0D=0A > >>> To: br@brianrosen.net; Edge, St= ephen=0D=0A > >>> Cc: ECRIT=0D=0A > >>> Subject: RE: [Ecrit] Comments o= n Framework Draft=0D=0A > >>>=0D=0A > >>> Thank you Brian. This is well= said [except you left out the=0D=0Afact=0D=0A >that=0D=0A > >>> ecrit a= lso allows for devices to get their location through=0D=0Aother=0D=0A > >= >> mechanisms, such as GPS, SUPL, or other methods, and doesn't=0D=0Ainsist=0D= =0A > >>> that=0D=0A > >>> the location be configured through DHCP or H= ELD].=0D=0A > >>>=0D=0A > >>> I agree 100% that additional qualificatio= ns are unnecessary.=0D=0A >Service=0D=0A > >>> providers, vendors, natio= nal bodies dealing with emergency=0D=0A > >>> services, and=0D=0A > >>>= regulators aren't stupid. Please trust us to figure out for=0D=0A >oursel= ves=0D=0A > >>> when/where/how to apply a "standard". There is no need to= try=0D=0Ato=0D=0A > >>> artificially limit or define scope, or to state = the obvious=0D=0A(e.g.,=0D=0A > >>> the=0D=0A > >>> architecture applie= s where it applies, and doesn't apply where=0D=0Ait=0D=0A > >>> doesn't a= pply). We understand the role and scope of the IETF,=0D=0Aand=0D=0A >the=0D= =0A > >>> role and scope of 3GPP and 3GPP2. And all the other SDOs (and=0D= =0A > >>> national=0D=0A > >>> bodies and regulatory agencies). SDOs ne= ed to offer=0D=0Aarchitectures=0D=0A > >>> that=0D=0A > >>> apply withi= n the area of applicability for that SDO, and are=0D=0Auseful=0D=0A > >>>= to=0D=0A > >>> potential implementers, and leave it to the SPs, national=0D= =0Abodies=0D=0A >and=0D=0A > >>> regulators to decide which architecture= s and standards to use=0D=0Aor to=0D=0A > >>> mandate within the scope of= their network or jurisdiction.=0D=0AAgain,=0D=0A >we=0D=0A > >>> aren't= stupid.=0D=0A > >>> Barbara=0D=0A > >>>=0D=0A > >>> -----Original Me= ssage-----=0D=0A > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces= @ietf.org] On=0D=0A > >>> Behalf=0D=0A > >>> Of br@brianrosen.net=0D=0A= > >>> Sent: Friday, February 27, 2009 9:53 AM=0D=0A > >>> To: Edge, St= ephen=0D=0A > >>> Cc: ECRIT=0D=0A > >>> Subject: Re: [Ecrit] Comments o= n Framework Draft=0D=0A > >>>=0D=0A > >>> Stephen=0D=0A > >>>=0D=0A = > >>> Like any standards organization, the IETF restricts it's scope.=0D=0A= > >>> Generally, the scope is "the Internet", although we very often=0D=0A= > >>> describe=0D=0A > >>> solutions that are explicitly designed for = private IP networks=0D=0Aas=0D=0A > >>> well=0D=0A > >>> as=0D=0A > >= >> the Internet. We don't write standards for circuit switched=0D=0A > >= >> networks,=0D=0A > >>> and=0D=0A > >>> it should be no surprise that = the ecrit solution does not cater=0D=0Ato=0D=0A >CS=0D=0A > >>> solution= s. Nevertheless, we often try to make sure that our=0D=0A > >>> solution= s=0D=0A > >>> harmonize reasonably well with existing solutions.=0D=0A >= >>>=0D=0A > >>> Indeed, the ecrit solution clains global applicability = to the=0D=0A > >>> Internet=0D=0A > >>> in=0D=0A > >>> general, and m= ost private IP networks that can be=0D=0Ainterconnected to=0D=0A > >>> th= e=0D=0A > >>> Internet or to other IP networks via gateways. Looking at = your=0D=0A > >>> list of=0D=0A > >>> problem areas:=0D=0A > >>>> - a= ccess to PSTN capable PSAPs=0D=0A > >>> This is out of scope for IETF. N= ENA has active work on this=0D=0A >subject.=0D=0A > >>> It=0D=0A > >>>= seems straightforward to interwork ecrit compatible devices and=0D=0A > = >>> networks=0D=0A > >>> to existing CS connected PSAPs. As you know, CS= interconnects=0D=0Aare=0D=0A > >>> very=0D=0A > >>> nation-specific, s= o the NENA work may not have general=0D=0A >applicability.=0D=0A > >>> H= owever, it shows that it is possible to interwork. The NENA=0D=0Ai2=0D=0A = > >>> work is=0D=0A > >>> also designed to take ecrit compatible device= s and VSP=0D=0Anetworks,=0D=0A >and=0D=0A > >>> interwork them to the ex= isting network. The VSP would direct=0D=0Athe=0D=0A > >>> call=0D=0A > = >>> to=0D=0A > >>> the VPC, which would provide the services it does now= , using=0D=0Athe=0D=0A > >>> device=0D=0A > >>> provided location for r= outing. This is important for smooth=0D=0A > >>> transition=0D=0A > >>= > from existing PSAPs and VSPs to "next generation" PSAPs and=0D=0AVSPs.=0D= =0A > >>>> - handover between different IP access networks including=0D=0A= >different=0D=0A > >>>> types of access network=0D=0A > >>> In the ec= rit solution, the access network the call is initiated=0D=0Aon=0D=0A > >>= > provides all the facilities needed for the device to initiate=0D=0Aan=0D=0A= > >>> emergency=0D=0A > >>> call. The call starts traversing it's no= rmal call path, and=0D=0A > >>> eventually=0D=0A > >>> routes to the ES= RP. Handoffs between IP networks should be=0D=0A > >>> transparent=0D=0A= > >>> to=0D=0A > >>> this process, although we probably haven't done a= ll the work we=0D=0A > >>> need to=0D=0A > >>> do=0D=0A > >>> for han= doffs where the IP address as seen by the terminating=0D=0A >network=0D=0A= > >>> changes. This would generally be true of all current SIP based=0D= =0A >work.=0D=0A > >>>> - handover to/from circuit mode networks=0D=0A = > >>> This would be out of scope for IETF. It's as applicable to a=0D=0A= > >>> simple SIP=0D=0A > >>> call as it is a SIP emergency call, and t= here are no statements=0D=0Ain=0D=0A > >>> any=0D=0A > >>> SIP=0D=0A >= >>> documents on that subject.=0D=0A > >>>> - location for cellular ac= cess (and the requirement to=0D=0Asupport=0D=0A >LCPs=0D=0A > >>> that=0D= =0A > >>>> will be useless for cellular access)=0D=0A > >>> Location fo= r cellular access networks has been considered=0D=0A >carefully.=0D=0A > = >>> Since cellular is a mobile network, the access network would=0D=0Apass=0D= =0A >the=0D=0A > >>> device a Location-By-Reference URI, using either DH= CP or HELD.=0D=0A > >>> Either=0D=0A > >>> protocol is suitable for cel= lular networks. As we have pointed=0D=0Aout=0D=0A > >>> several times, c= ellular networks support raw data packet=0D=0Aservices=0D=0A > >>> upon=0D= =0A > >>> which many different kinds of networks can be constructed. My=0D= =0A >usual=0D=0A > >>> example is a large recreational vehicle traveling= down a road=0D=0Awith=0D=0A >a=0D=0A > >>> cellular data card plugged i= nto a router to which a wired=0D=0A >(Ethernet)=0D=0A > >>> phone=0D=0A = > >>> is connected. That phone must be able to make an emergency=0D=0Aca= ll,=0D=0A > >>> and it=0D=0A > >>> will get location from DHCP or HELD = (or LLDP-MED). It is not=0D=0Aaware=0D=0A > >>> of=0D=0A > >>> the=0D=0A= > >>> cellular network, and doesn't know any cellular specific=0D=0Aprot= ocols.=0D=0A > >>> Cellular networks will have to support IETF location=0D= =0Aconfiguration=0D=0A > >>> protocols unless they actively prohibit exam= ples like this, or=0D=0Athey=0D=0A > >>> implement interworking between c= ellular-specific location=0D=0Aprotocols=0D=0A > >>> and=0D=0A > >>> DH= CP or HELD in the data card. The ecrit standards permit=0D=0Aproxy=0D=0A = > >>> insertion=0D=0A > >>> of location, but, as above, we don't think t= hat works in all=0D=0Acases.=0D=0A > >>>> - endpoint based location and = routing for cellular access=0D=0A(issues=0D=0A > >>> here=0D=0A > >>>> = are network and device loading as well as device impacts and=0D=0A > >>>>= problems=0D=0A > >>>> with PSTN capable PSAPs)=0D=0A > >>> The "load" = of using DHCP or HELD to get location and querying=0D=0ALoST=0D=0A >is=0D=0A= > >>> pretty modest. The standards permit proxies to do this if the=0D=0A= > >>> devices=0D=0A > >>> don't. As above, interwork functions to CS = connected PSAPs is=0D=0Avery=0D=0A > >>> feasible, and as above, cellular= networks will have to support=0D=0A > >>> access to=0D=0A > >>> local = LoST servers for devices that are connected to cellular=0D=0A > >>> netwo= rks=0D=0A > >>> and=0D=0A > >>> are ecrit compliant.=0D=0A > >>>> - = support of unauthenticated users and users who can be=0D=0A > >>> authent= icated=0D=0A > >>>> but are not permitted access/VSP service except for e= mergency=0D=0A >calls=0D=0A > >>> This is covered in the standards. Non= e of the processes are=0D=0A > >>> dependent=0D=0A > >>> on=0D=0A > >= >> authentication, although where it is possible, it's desirable=0D=0Aso as=0D= =0A > >>> to=0D=0A > >>> minimize fraudulent emergency calls=0D=0A > = >>> Mechanisms for specific network authentication mechanisms are=0D=0Aout=0D= =0A >of=0D=0A > >>> scope, and, like SIP basic calling, are not usually = mentioned=0D=0Ain=0D=0A >IETF=0D=0A > >>> documents.=0D=0A > >>>=0D=0A= > >>> Stephen, we've tried pretty hard to make sure this works for=0D=0A= 3G/4G=0D=0A > >>> mobile=0D=0A > >>> networks. It's true that it doesn= 't do it the way 3GPP=0D=0Acurrently=0D=0A > >>> thinks=0D=0A > >>> it = ought to work, but we claim they haven't thought through all=0D=0Athe=0D=0A= > >>> issues. While it would work, there are opportunities for=0D=0A >= >>> improvement.=0D=0A > >>> We=0D=0A > >>> would be willing to do th= at if we could get the cooperation of=0D=0A >3GPP,=0D=0A > >>> which=0D=0A= > >>> we have tried, and failed, to do.=0D=0A > >>>=0D=0A > >>> So, = I think the documents do not need any qualification=0D=0Astatements.=0D=0A = > >>>=0D=0A > >>> Brian=0D=0A > >>>=0D=0A > >>>> Martin=0D=0A > >= >>>=0D=0A > >>>> The 3GPP/3GPP2 solution has a defined restricted applica= bility=0D=0A > >>>> (mainly=0D=0A > >>> to=0D=0A > >>>> 3GPP/3GPP2 ac= cess networks where the serving network also acts=0D=0Aas=0D=0A > >>>> th= e=0D=0A > >>> VSP)=0D=0A > >>>> and the specifications for it cover in = detail all possible=0D=0A >scenarios=0D=0A > >>>> consistent with these = restrictions so far as we are aware.=0D=0A > >>>>=0D=0A > >>>> The Ecri= t solution seems to claim global applicability to all=0D=0A > >>>> types = of=0D=0A > >>> IP=0D=0A > >>>> access (and the more that is said about = this from Ecrit=0D=0A >participants=0D=0A > >>> the=0D=0A > >>>> more = this gets emphasized) but does not cover in detail all=0D=0A >possible=0D=0A= > >>>> scenarios (in some cases does not cover in any detail) which=0D=0A= means=0D=0A > >>> that at=0D=0A > >>>> best the solution is incomplete = and at worst intrinsically=0D=0A > >>> inapplicable to=0D=0A > >>>> som= e unstated set of scenarios.=0D=0A > >>>>=0D=0A > >>>> The missing, inc= omplete and problematic cases include the=0D=0A >following:=0D=0A > >>>>=0D= =0A > >>>> - access to PSTN capable PSAPs=0D=0A > >>>> - handover bet= ween different IP access networks including=0D=0A >different=0D=0A > >>>= > types of access network=0D=0A > >>>> - handover to/from circuit mode n= etworks=0D=0A > >>>> - location for cellular access (and the requirement= to=0D=0Asupport=0D=0A >LCPs=0D=0A > >>> that=0D=0A > >>>> will be use= less for cellular access)=0D=0A > >>>> - endpoint based location and rou= ting for cellular access=0D=0A(issues=0D=0A > >>> here=0D=0A > >>>> are= network and device loading as well as device impacts and=0D=0A > >>>> pr= oblems=0D=0A > >>>> with PSTN capable PSAPs)=0D=0A > >>>> - support of= unauthenticated users and users who can be=0D=0A > >>> authenticated=0D=0A= > >>>> but are not permitted access/VSP service except for emergency=0D=0A= >calls=0D=0A > >>>>=0D=0A > >>>> Stating that some of these cases are= out of scope or=0D=0Areferencing=0D=0A >an=0D=0A > >>>> incomplete and = possibly questionable specification from some=0D=0Aother=0D=0A > >>>> nat= ional SDO will not help the user who encounters such=0D=0Aproblems.=0D=0A = > >>>> But=0D=0A > >>> it=0D=0A > >>>> would certainly help network op= erators and implementers to=0D=0A > >>>> acknowledge=0D=0A > >>>> their= existence in one form or another because that would=0D=0Aallow=0D=0A > >= >>> better=0D=0A > >>>> planning of deployments and would help focus atte= ntion on=0D=0Afinding=0D=0A > >>>> solutions (whether in IETF or elsewher= e) for the missing=0D=0Acases.=0D=0A > >>>>=0D=0A > >>>> Please note th= at despite these drawbacks, I will acknowledge=0D=0Athat=0D=0A > >>> Ecri= t=0D=0A > >>>> does have a valuable solution that covers many scenarios n= ot=0D=0A >covered=0D=0A > >>> by=0D=0A > >>>> 3GPP/3GPP2. It would be = the delineation of these supported=0D=0A >scenarios=0D=0A > >>> (or=0D=0A= > >>>> equivalently unsupported scenarios) in some applicability=0D=0A = >statement=0D=0A > >>> that=0D=0A > >>>> would be particularly useful r= ight now.=0D=0A > >>>>=0D=0A > >>>> Kind Regards=0D=0A > >>>>=0D=0A = > >>>> Stephen=0D=0A > >>>> -----Original Message-----=0D=0A > >>>> Fr= om: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=0D=0A > >>>> Sent:= Thursday, February 26, 2009 9:45 PM=0D=0A > >>>> To: Edge, Stephen; Rich= ard Barnes=0D=0A > >>>> Cc: ECRIT=0D=0A > >>>> Subject: RE: [Ecrit] Com= ments on Framework Draft=0D=0A > >>>>=0D=0A > >>>> There's benefit in k= nowing the limitations of a framework, and=0D=0A >every=0D=0A > >>>> arc= hitecture makes certain assumptions. Let's examine them=0D=0A > >>>> tho= ugh...=0D=0A > >>>>=0D=0A > >>>> The IETF might occasionally make the a= ssumption that the=0D=0Astandards=0D=0A > >>>> it=0D=0A > >>>> develops= are for Internet devices. That assumption probably=0D=0Aneed=0D=0A > >>= >> not=0D=0A > >>> be=0D=0A > >>>> stated explicitly.=0D=0A > >>>>=0D= =0A > >>>> The ECRIT architecture relies on implementations of the=0D=0Ap= rotocols=0D=0A > >>>> that=0D=0A > >>> it=0D=0A > >>>> references. T= hat is not extraordinary. A reliance on=0D=0A > >>>> implementation=0D=0A= > >>> of=0D=0A > >>>> these protocols by endpoints, routing intermedia= ries and PSAPs=0D=0A > >>>> should=0D=0A > >>> not=0D=0A > >>>> need = to be explained.=0D=0A > >>>>=0D=0A > >>>> So the assumptions are:=0D=0A= > >>>> - the Internet=0D=0A > >>>> - solutions are implemented and dep= loyed=0D=0A > >>>> - the end device is a key component=0D=0A > >>>>=0D=0A= > >>>> Only that last element is particularly novel ... or not that=0D=0A= much=0D=0A > >>> really.=0D=0A > >>>> It's a design choice. Unless yo= u were thinking of trunking=0D=0Athe=0D=0A > >>> voice=0D=0A > >>>> els= ewhere.=0D=0A > >>>>=0D=0A > >>>> Of course, you're suggesting that the= design choice was made=0D=0Ain=0D=0A > >>> ignorance=0D=0A > >>>> of a= ll the constraints. You're suggesting that - as a result=0D=0A-=0D=0A >th= e=0D=0A > >>> choice=0D=0A > >>>> is flawed and the solution is not goi= ng to work for cellular=0D=0A > >>>> services.=0D=0A > >>> We=0D=0A > = >>>> disagree. The solution is a basis for emergency calling in=0D=0A_any= _=0D=0A >IP=0D=0A > >>>> network.=0D=0A > >>>>=0D=0A > >>>> Cheers,=0D= =0A > >>>> Martin=0D=0A > >>>>=0D=0A > >>>>=0D=0A > >>>>> -----Orig= inal Message-----=0D=0A > >>>>> From: ecrit-bounces@ietf.org [mailto:ecri= t-bounces@ietf.org]=0D=0AOn=0D=0A > >>> Behalf=0D=0A > >>>>> Of Edge, S= tephen=0D=0A > >>>>> Sent: Friday, 27 February 2009 3:30 PM=0D=0A > >>>= >> To: Richard Barnes=0D=0A > >>>>> Cc: 'ECRIT'=0D=0A > >>>>> Subject: = Re: [Ecrit] Comments on Framework Draft=0D=0A > >>>>>=0D=0A > >>>>> Hi = Richard=0D=0A > >>>>>=0D=0A > >>>>> Thanks for the comments. Your state= ment below that "SIP=0D=0Aemergency=0D=0A > >>>>> calling works if all pa= rties behave as specified in these=0D=0A(IETF=0D=0A > >>> Ecrit)=0D=0A >= >>>>> documents" to some degree highlights the problems we are=0D=0Araisi= ng.=0D=0A > >>>>> The=0D=0A > >>>>> documents do contain a number of im= plicit and explicit=0D=0A > >>>>> restrictions -=0D=0A > >>>>> like IP = capable PSAPs, global IP access (no islands of=0D=0Acircuit=0D=0A >mode=0D= =0A > >>>>> access for example), universal support of this solution by=0D= =0Aall=0D=0A > >>>>> access=0D=0A > >>>>> providers and VSPs (not much = good if some opt for another=0D=0A >solution)=0D=0A > >>> and=0D=0A > = >>>>> end system oriented location and routing capability - which=0D=0A > = >>>>> together=0D=0A > >>>>> make them unsuitable (we believe) for cellu= lar wireless=0D=0Anetworks.=0D=0A > >>>>> If=0D=0A > >>>>> these restri= ctions and assumptions were all made explicit=0D=0A > >>>>> upfront, it=0D= =0A > >>>>> would to a large degree (and possibly completely) address our=0D= =0A > >>> concerns.=0D=0A > >>>>>=0D=0A > >>>>> You are right in assu= ming another set of specifications for=0D=0Athe=0D=0A > >>>>> 3GPP=0D=0A = > >>>>> and 3GPP2 solution. The applicability of this solution is=0D=0A = > >>>>> explicitly=0D=0A > >>>>> defined in TS 23.167 (or more exactly i= n an already agreed CR=0D=0Ain=0D=0A > >>>>> contribution S2-090752 which= will become part of 23.167 in a=0D=0Afew=0D=0A > >>>>> more=0D=0A > >>= >>> weeks) to cover the following access types: GPRS (UTRAN=0D=0AWCDMA),=0D= =0A > >>> I-WLAN,=0D=0A > >>>>> Fixed Broadband, CDMA2000 HRPD, EPS UTR= AN (WCDMA) and EPS=0D=0AE-UTRAN=0D=0A > >>>>> (LTE). So there is a restri= ction and arbitrary internet=0D=0Aaccess is=0D=0A > >>>>> not=0D=0A > >= >>>> covered (yet) as I have stated before.=0D=0A > >>>>>=0D=0A > >>>>>= Kind Regards=0D=0A > >>>>>=0D=0A > >>>>> Stephen=0D=0A > >>>>> -----= Original Message-----=0D=0A > >>>>> From: Richard Barnes [mailto:rbarnes@= bbn.com]=0D=0A > >>>>> Sent: Wednesday, February 25, 2009 6:30 PM=0D=0A = > >>>>> To: Edge, Stephen=0D=0A > >>>>> Cc: Brian Rosen; 'ECRIT'=0D=0A = > >>>>> Subject: Re: [Ecrit] Comments on Framework Draft=0D=0A > >>>>>=0D= =0A > >>>>> Hi Stephen,=0D=0A > >>>>>=0D=0A > >>>>> I'm a little conf= used by the scope of what you're asking.=0D=0AThe=0D=0A > >>>>> framework=0D= =0A > >>>>> and phonebcp documents exist in order to describe the ECRIT=0D= =0A > >>>>> solution:=0D=0A > >>>>> They say, in effect, "SIP emergency= calling works if all=0D=0Aparties=0D=0A > >>> behave=0D=0A > >>>>> as = specified in these documents."=0D=0A > >>>>>=0D=0A > >>>>> As I underst= and what you're saying (and I'm by no means an=0D=0Aexpert=0D=0A > >>>>> = in=0D=0A > >>>>> 3GPP), 3GPP specifies that one or more elements of this=0D= =0Asystem=0D=0A > >>>>> behave=0D=0A > >>>>> differently. This simply = means that 3GPP networks aren't=0D=0A >complying=0D=0A > >>>>> with=0D=0A= > >>>>> these specs. Just like there's no disclaimer in RFC 791=0D=0A(I= Pv4)=0D=0A > >>>>> that=0D=0A > >>>>> says "this doesn't work on X.25 n= etworks", it's not clear to=0D=0Ame=0D=0A > >>>>> that=0D=0A > >>> an=0D= =0A > >>>>> analogous disclaimer is called for here.=0D=0A > >>>>>=0D=0A= > >>>>> I presume there are similar documents describing how=0D=0Aemerge= ncy=0D=0A > >>> calling=0D=0A > >>>>> works in 3GPP networks. Do they = include notes saying that=0D=0Athe=0D=0A >3GPP=0D=0A > >>>>> solution do= esn't work in the broader Internet=3F=0D=0A > >>>>>=0D=0A > >>>>> --Ric= hard=0D=0A > >>>>>=0D=0A > >>>>>=0D=0A > >>>>>=0D=0A > >>>>>=0D=0A = > >>>>>=0D=0A > >>>>> Edge, Stephen wrote:=0D=0A > >>>>>> Brian=0D=0A= > >>>>>>=0D=0A > >>>>>> First of all apologies for the likely lateness= of this reply=0D=0A- I=0D=0A > >>>>> actually wrote it on 19 February in= a 3GPP SA2 meeting in=0D=0A >Budapest=0D=0A > >>> but=0D=0A > >>>>> i= t seems unlikely that my VPN, Outlook server and WiFi access=0D=0A > >>>>= > capability will cooperate together to get it sent until I=0D=0Areturn=0D=0A= >to=0D=0A > >>> the=0D=0A > >>>>> office mid-next week.=0D=0A > >>>= >>>=0D=0A > >>>>>> Anyhow thanks for your comments. There have actually b= een a=0D=0A >number=0D=0A > >>> of=0D=0A > >>>>> conference calls betw= een IETF and 3GPP participants over the=0D=0Alast=0D=0A > >>>>> couple of= years at which common features like support of IP=0D=0A > >>>>> emergenc= y=0D=0A > >>>>> calls were discussed and these could have been good forum= for=0D=0A > >>>>> participants on either side to have raised the kinds o= f=0D=0Aissues=0D=0A >you=0D=0A > >>>>> elaborate on below. Given that se= ems not so far to have=0D=0Ahappened,=0D=0A > >>>>> it=0D=0A > >>>>> co= uld still be possible in future such calls.=0D=0A > >>>>>>=0D=0A > >>>>= >> But the issues we are raising are not directly to do with=0D=0A >furthe= r=0D=0A > >>>>> aligning the 2 solutions or with the lack of this in the=0D= =0Apast. We=0D=0A > >>>>> are=0D=0A > >>>>> simply pointing out that th= e solutions are currently=0D=0Adifferent=0D=0A >and=0D=0A > >>> that=0D=0A= > >>>>> from a cellular wireless perspective, the Ecrit solution is=0D=0A= not=0D=0A > >>>>> seen=0D=0A > >>> as=0D=0A > >>>>> suitable in all r= espects (for support of IP emergency calls=0D=0A > >>> originating=0D=0A = > >>>>> from such access types). That is not just our point of view.=0D=0A= >3GPP2=0D=0A > >>> sent=0D=0A > >>>>> a liaison to Ecrit some months = ago pointing out the same=0D=0Aissues.=0D=0A > >>>>>>=0D=0A > >>>>>> So= we are proposing that the Ecrit framework and phoneBCP=0D=0Aspec.s=0D=0A = > >>>>> include a statement acknowledging this - e.g. by referencing=0D=0A= the=0D=0A > >>>>> alternative 3GPP/3GPP2 solution and indicating the IP a= ccess=0D=0A >types=0D=0A > >>> for=0D=0A > >>>>> which the Ecrit solut= ion will work without limitation (or=0D=0A > >>> equivalently=0D=0A > >= >>>> the access types where limitations are not ruled out).=0D=0A > >>>>>= >=0D=0A > >>>>>> We are not proposing further modification and extension = of=0D=0Athe=0D=0A > >>> Ecrit=0D=0A > >>>>> solution - just pointing ou= t that this would be needed (as=0D=0Awith=0D=0A >the=0D=0A > >>>>> 3GPP/= 3GPP2 solution) to fully cover all types of access.=0D=0A > >>>>>>=0D=0A = > >>>>>> Kind Regards=0D=0A > >>>>>>=0D=0A > >>>>>> Stephen=0D=0A > = >>>>>> -----Original Message-----=0D=0A > >>>>>> From: Brian Rosen [mail= to:br@brianrosen.net]=0D=0A > >>>>>> Sent: Wednesday, February 18, 2009 8= :07 PM=0D=0A > >>>>>> To: Edge, Stephen; 'ECRIT'=0D=0A > >>>>>> Subject= : RE: [Ecrit] Comments on Framework Draft=0D=0A > >>>>>>=0D=0A > >>>>>>= I have bit my tongue on this one for a long time.=0D=0A > >>>>>>=0D=0A = > >>>>>> Stephen, with respect, please go talk to 3GPP management and=0D=0A= ask=0D=0A > >>> them=0D=0A > >>>>> why=0D=0A > >>>>>> there has been = no participation in the ecrit effort despite=0D=0A > >>> multiple=0D=0A = > >>>>> YEARS=0D=0A > >>>>>> of begging them to get involved. To put it= frankly, 3GPP is=0D=0A >quite=0D=0A > >>>>> willing=0D=0A > >>>>>> to= bully IETF into doing its work on its schedule, but=0D=0Acannot be=0D=0A = > >>>>> bothered to=0D=0A > >>>>>> get work done it knows it will eventu= ally have to do when=0D=0Athe=0D=0A >IETF=0D=0A > >>>>> asks it=0D=0A >= >>>>>> to do so.=0D=0A > >>>>>>=0D=0A > >>>>>> 3GPP understands the m= ess that is being created by not=0D=0A > >>> participating.=0D=0A > >>>= >> They=0D=0A > >>>>>> know full well that when they finally get around t= o dealing=0D=0Awith=0D=0A > >>>>>> PS=0D=0A > >>>>>> terminated emergen= cy calls, that there will be a lot of=0D=0A >resistance=0D=0A > >>> to=0D= =0A > >>>>>> changing fully specified and implemented standards to more=0D= =0A >closely=0D=0A > >>>>> align=0D=0A > >>>>>> with 3GPP standards. = I expect you will have several=0D=0A >interworking=0D=0A > >>>>> functio= ns=0D=0A > >>>>>> to define and build.=0D=0A > >>>>>>=0D=0A > >>>>>> = So, politely, please go away, we're finishing work we dearly=0D=0A > >>>>= >> wanted=0D=0A > >>>>> you all=0D=0A > >>>>>> to be involved with for = years, but you refused to do=0D=0Aanything.=0D=0A > >>> It's=0D=0A > >>= >>> too=0D=0A > >>>>>> late for this rev.=0D=0A > >>>>>>=0D=0A > >>>>= >> Now, having said that, there are quite a few people who have=0D=0A > >= >>>> participated in=0D=0A > >>>>>> the IETF work who are IMS aware and I= believe that despite=0D=0Ayour=0D=0A > >>>>> fears,=0D=0A > >>>>>> eve= rything you need is in the specs. The mechanisms we have=0D=0A > >>> def= ined=0D=0A > >>>>> provide=0D=0A > >>>>>> the ability for the network t= o insert location, recognize=0D=0Aand=0D=0A >mark=0D=0A > >>>>> emergenc= y=0D=0A > >>>>>> calls, and route on behalf of endpoints. An E-CSCF coul= d=0D=0Aquite=0D=0A > >>>>>> straightforwardly provide a SIP call towards = an ecrit=0D=0Acompatible=0D=0A > >>>>> PSAP. The=0D=0A > >>>>>> only n= ot-quite-nice interwork would be from SUPL to HELD (or=0D=0A >SIP),=0D=0A = > >>>>> but it's=0D=0A > >>>>>> pretty easy to do that. I'll also note= that we have tried=0D=0Ato=0D=0A >get=0D=0A > >>> OMA=0D=0A > >>>>> a= nd=0D=0A > >>>>>> IETF to cooperate on location protocols, but we have be= en=0D=0A > >>>>> spectacularly=0D=0A > >>>>>> unsuccessful at that effo= rt also.=0D=0A > >>>>>>=0D=0A > >>>>>> Brian=0D=0A > >>>>>>=0D=0A > = >>>>>>=0D=0A > >>>>>>=0D=0A > >>>>>>> -----Original Message-----=0D=0A= > >>>>>>> From: ecrit-bounces@ietf.org=0D=0A[mailto:ecrit-bounces@ietf.o= rg] On=0D=0A > >>>>> Behalf=0D=0A > >>>>>>> Of Edge, Stephen=0D=0A > = >>>>>>> Sent: Thursday, February 05, 2009 2:50 AM=0D=0A > >>>>>>> To: 'EC= RIT'=0D=0A > >>>>>>> Subject: [Ecrit] Comments on Framework Draft=0D=0A = > >>>>>>>=0D=0A > >>>>>>> All=0D=0A > >>>>>>>=0D=0A > >>>>>>> draft-= ietf-ecrit-framework-07 is (as we see it) a mostly=0D=0A > >>> informativ= e=0D=0A > >>>>>>> description of how terminals and networks should suppor= t=0D=0A > >>>>>>> emergency=0D=0A > >>>>>>> calls made over IP capable = facilities to IP capable PSAPs.=0D=0AIt=0D=0A > >>>>> appears=0D=0A > >= >>>>>> intended to cover all types of access network - including=0D=0Afixed=0D= =0A > >>>>> line,=0D=0A > >>>>>>> WiFi and cellular (e.g. examples invo= lving each can be=0D=0Afound=0D=0A > >>>>> throughout=0D=0A > >>>>>>> t= he draft).=0D=0A > >>>>>>>=0D=0A > >>>>>>> When we evaluated this with = respect to support of wireless=0D=0A > >>> cellular=0D=0A > >>>>>>> acc= ess and WiFi access associated with a cellular operator=0D=0A >(e.g.=0D=0A= > >>>>> WLAN=0D=0A > >>>>>>> or Femto cells integrated into a cellular= network), we=0D=0Afound=0D=0A >that=0D=0A > >>>>>>> certain portions of= the draft exhibited one or more of the=0D=0A > >>> following=0D=0A > >= >>>>>> characteristics:=0D=0A > >>>>>>>=0D=0A > >>>>>>> (A) Inconsis= tent with already standardized wireless=0D=0A >solutions=0D=0A > >>>>>>>=0D= =0A > >>>>>>> (B) Inconsistent with essential wireless requirements=0D= =0Aand=0D=0A > >>>>>>> conventions=0D=0A > >>>>>>>=0D=0A > >>>>>>> = (C) Already part of wireless standards or potentially=0D=0Apart=0D=0A >of=0D= =0A > >>>>>>> future standards=0D=0A > >>>>>>>=0D=0A > >>>>>>> (A) re= fers to all portions of the draft framework that=0D=0Adiffer=0D=0A > >>>>= >>> from=0D=0A > >>>>> the=0D=0A > >>>>>>> requirements and procedures = currently standardized for=0D=0Awireless=0D=0A > >>>>>>> emergency access= by 3GPP, 3GPP2 and OMA. This is a plain=0D=0A > >>> difference=0D=0A > = >>>>> of=0D=0A > >>>>>>> solution and could be resolved through support = of both=0D=0A >solutions=0D=0A > >>> by=0D=0A > >>>>>>> terminals (wit= h each solution being used according to the=0D=0Atype=0D=0A >of=0D=0A > = >>>>>>> access network and VSP) or could be resolved by supporting=0D=0Aonl= y=0D=0A > >>> one=0D=0A > >>>>>>> solution and accessing only the types= of network supporting=0D=0A >that=0D=0A > >>>>>>> solution. To acknowle= dge this category, the framework=0D=0Adocument=0D=0A > >>> could=0D=0A >= >>>>>>> reference the applicable wireless standards and point out=0D=0Ath= at=0D=0A > >>> these=0D=0A > >>>>>>> are valid alternatives for wireles= s cellular based access.=0D=0A > >>>>>>>=0D=0A > >>>>>>> (B) refers to = portions of the draft that would be=0D=0Aunsuitable=0D=0A >for=0D=0A > >= >>>>>> wireless networks even if no alternative solution existed=0D=0A > = >>>>>>> together=0D=0A > >>>>> with=0D=0A > >>>>>>> other portions miss= ing from the draft that would be needed=0D=0Ato=0D=0A > >>> fully=0D=0A = > >>>>>>> support wireless networks. Examples of the former include:=0D=0A= (a)=0D=0A > >>>>> emphasis=0D=0A > >>>>>>> on endpoint derivation of lo= cation, performance of Lost=0D=0Aquery=0D=0A >and=0D=0A > >>>>>>> receip= t of local dial strings; (b) restriction of LCPs to=0D=0A > >>> protocols=0D= =0A > >>>>>>> that require terminal initiation (not allowing for network=0D= =0A > >>>>> initiation=0D=0A > >>>>>>> as far as we can tell) and that = include two LCPs (DHCP and=0D=0A >LLDP)=0D=0A > >>>>> that=0D=0A > >>>= >>>> are not applicable to (not defined for) cellular access;=0D=0Aand=0D=0A= >(c)=0D=0A > >>> the=0D=0A > >>>>>>> requirement that a terminal or a= t least a LIS will update=0D=0Athe=0D=0A > >>>>>>> PSAP=0D=0A > >>>>>>>= whenever location changes. (a) is impractical due to=0D=0Anetwork=0D=0A >= and=0D=0A > >>>>>>> terminal loading consequences and failure to support = non-IP=0D=0A > >>> capable=0D=0A > >>>>>>> PSAPs; (b) makes location ve= rification and updated location=0D=0A > >>>>> provision=0D=0A > >>>>>>>= to PSAPs difficult or impossible; while (c) is also=0D=0A >incompatible=0D= =0A > >>>>> with=0D=0A > >>>>>>> support of existing non-IP capable PSA= Ps besides increasing=0D=0A > >>> terminal=0D=0A > >>>>>>> load and pos= sibly interfering with optimum maintenance of=0D=0Athe=0D=0A >RF=0D=0A > = >>>>>>> connection (e.g. if a terminal has to tune away from the=0D=0A >s= erving=0D=0A > >>>>> base=0D=0A > >>>>>>> station or WLAN periodically = to make location=0D=0Ameasurements).=0D=0A > >>>>> Examples=0D=0A > >>>= >>>> of the latter include (d) absence of support for access to=0D=0Anon-=0D= =0A >IP=0D=0A > >>>>>>> capable PSAPs as already mentioned (e.g. to supp= ort E911=0D=0Aphase=0D=0A >2=0D=0A > >>> in=0D=0A > >>>>> the=0D=0A >= >>>>>>> US); (e) no support for handover from the IP to the circuit=0D=0A= > >>>>>>> domain=0D=0A > >>>>> when=0D=0A > >>>>>>> a terminal loses= (e.g. moves out of) RF coverage in the IP=0D=0A > >>>>>>> domain;=0D=0A = > >>>>> and=0D=0A > >>>>>>> (f) no allowance for limited access modes w= herein a=0D=0Aterminal=0D=0A >may=0D=0A > >>>>> access=0D=0A > >>>>>>>= a network only to place an emergency call with ensuing=0D=0A > >>> restr= ictions=0D=0A > >>>>> on=0D=0A > >>>>>>> (for example) location acquisi= tion, PSAP callback and=0D=0Acaller=0D=0A > >>>>>>> verification and iden= tification to the PSAP. To resolve=0D=0Athis=0D=0A > >>>>> category=0D=0A= > >>>>>>> either significant changes to the framework document could=0D=0A= be=0D=0A > >>>>>>> made=0D=0A > >>>>> or a=0D=0A > >>>>>>> disclaimer= /applicability statement could be added stating=0D=0Athat=0D=0A > >>>>> s= upport=0D=0A > >>>>>>> of cellular wireless networks and their associated= WLAN and=0D=0A >Femto=0D=0A > >>>>>>> access points is not covered.=0D=0A= > >>>>>>>=0D=0A > >>>>>>> Category (C) comprises concepts and capabili= ties in the=0D=0Adraft=0D=0A > >>>>>>> that=0D=0A > >>>>> are=0D=0A > = >>>>>>> either already part of the standardized solution for=0D=0Awireless=0D= =0A > >>>>> networks=0D=0A > >>>>>>> or that might be added at a later = time. Examples of the=0D=0Aformer=0D=0A > >>>>> include=0D=0A > >>>>>>>= LoST, SIP location conveyance, general use of SIP, location=0D=0Afor=0D=0A= > >>>>> routing=0D=0A > >>>>>>> versus for dispatch, cellular position= ing methods. Examples=0D=0Aof=0D=0A > >>>>>>> the=0D=0A > >>>>>>> latte= r include use of location references and dereferencing=0D=0Aand=0D=0A > >= >>>>>> possible interworking between the current wireless network=0D=0A > = >>> solutions=0D=0A > >>>>>>> (in 3GPP, 3GPP2 and OMA) and the solution = described in this=0D=0A > >>>>>>> draft.=0D=0A > >>>>> The=0D=0A > >>= >>>>> presence of this category could be acknowledged by=0D=0Afollowing=0D=0A= >the=0D=0A > >>>>>>> disclaimer for (B) with a statement that certain p= ortions=0D=0Aof=0D=0A >the=0D=0A > >>>>>>> solution are expected to be i= ncorporated into wireless=0D=0Anetworks=0D=0A > >>> now=0D=0A > >>>>>>>= and/or in the future.=0D=0A > >>>>>>>=0D=0A > >>>>>>> We hope that the= se comments will be seen to be a useful=0D=0A >addition=0D=0A > >>> to=0D= =0A > >>>>>>> this review in the sense of enabling a more precise scoping=0D= =0Afor=0D=0A > >>> the=0D=0A > >>>>>>> framework document and we are wi= lling to assist in=0D=0Aproviding=0D=0A > >>> wording=0D=0A > >>>>>>> f= or any disclaimer/applicability statement that the Ecrit=0D=0A >working=0D= =0A > >>>>> group=0D=0A > >>>>>>> may now deem fit to include.=0D=0A >= >>>>>>>=0D=0A > >>>>>>> Kind Regards=0D=0A > >>>>>>>=0D=0A > >>>>>>= > Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk=0D=0ABurroughs=0D=0A = > >>>>> (Qualcomm=0D=0A > >>>>>>> 3GPP2 TSG-X and TSG-C participant)=0D=0A= > >>>>>>>=0D=0A > >>>>>>> PS this being sent on 2/4/09 at 11:50pm PST=0D= =0A > >>>>>>>=0D=0A > >>>>>>> _________________________________________= ______=0D=0A > >>>>>>> Ecrit mailing list=0D=0A > >>>>>>> Ecrit@ietf.or= g=0D=0A > >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A > >= >>>>>=0D=0A > >>>>>> _______________________________________________=0D=0A= > >>>>>> Ecrit mailing list=0D=0A > >>>>>> Ecrit@ietf.org=0D=0A > >>= >>>> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A > >>>>>>=0D=0A > = >>>>> _______________________________________________=0D=0A > >>>>> Ecri= t mailing list=0D=0A > >>>>> Ecrit@ietf.org=0D=0A > >>>>> https://www.i= etf.org/mailman/listinfo/ecrit=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, proprietary, or otherwise private=0D=0Ainformation.=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 > >>> ------------------------=0D=0A > >>>> [mf2= ]=0D=0A > >>>> _______________________________________________=0D=0A > = >>>> Ecrit mailing list=0D=0A > >>>> Ecrit@ietf.org=0D=0A > >>>> https:= //www.ietf.org/mailman/listinfo/ecrit=0D=0A > >>>>=0D=0A > >>>=0D=0A >= >>> _______________________________________________=0D=0A > >>> Ecrit m= ailing list=0D=0A > >>> Ecrit@ietf.org=0D=0A > >>> https://www.ietf.org= /mailman/listinfo/ecrit=0D=0A > >>>=0D=0A > >>> *****=0D=0A > >>>=0D=0A= > >>> The information transmitted is intended only for the person or=0D=0A= > >>> entity to=0D=0A > >>> which it is addressed and may contain conf= idential,=0D=0Aproprietary,=0D=0A > >>> and/or=0D=0A > >>> privileged m= aterial. Any review, retransmission, dissemination=0D=0Aor=0D=0A > >>> ot= her=0D=0A > >>> use of, or taking of any action in reliance upon this=0D=0A= information=0D=0A >by=0D=0A > >>> persons or entities other than the int= ended recipient is=0D=0A > >>> prohibited. If=0D=0A > >>> you received = this in error, please contact the sender and=0D=0Adelete=0D=0A >the=0D=0A = > >>> material from all computers. GA621=0D=0A > >>>=0D=0A > >>>=0D=0A= > >>> _______________________________________________=0D=0A > >>> Ecri= t mailing list=0D=0A > >>> Ecrit@ietf.org=0D=0A > >>> https://www.ietf.= org/mailman/listinfo/ecrit=0D=0A > >> ___________________________________= ____________=0D=0A > >> Ecrit mailing list=0D=0A > >> Ecrit@ietf.org=0D= =0A > >> https://www.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 rece= ived it in error, please notify the sender=0D=0A > >immediately and delet= e the original. Any unauthorized use of=0D=0A > >this email is prohibite= d.=0D=0A >=0D=0A>---------------------------------------------------------= -------------=0D=0A >---=0D=0A > >-----------------------=0D=0A > >[mf= 2]=0D=0A >=0D=0A >=0D=0A >=0D=0A=20=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 >im= mediately and delete the original. Any unauthorized use of=0D=0A >this em= ail is prohibited.=0D=0A=20=0D=0A>-----------------------------------------= ------------------------------=0D=0A--=0D=0A >-----------------------=0D=0A= >[mf2]=0D=0A >=0D=0A >_______________________________________________=0D= =0A >Ecrit mailing list=0D=0A >Ecrit@ietf.org=0D=0A >https://www.ietf.or= g/mailman/listinfo/ecrit=0D=0A_____________________________________________= __=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/ma= ilman/listinfo/ecrit=0D=0A=0D=0A-------------------------------------------= -----------------------------------------------------=0D=0AThis message is = for the designated recipient only and may=0D=0Acontain privileged, propriet= ary, or otherwise private information. =20=0D=0AIf you have received it in = error, please notify the sender=0D=0Aimmediately and delete the original. = Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A---------------= ---------------------------------------------------------------------------= ------=0D=0A[mf2]=0D=0A From Martin.Dawson@andrew.com Thu Mar 5 22:55:58 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 549013A68E7 for ; Thu, 5 Mar 2009 22:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lG9+w8IRt-i for ; Thu, 5 Mar 2009 22:55:55 -0800 (PST) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id CCCC43A68A4 for ; Thu, 5 Mar 2009 22:55:54 -0800 (PST) X-SEF-Processed: 5_0_0_910__2009_03_06_01_16_08 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); Fri, 06 Mar 2009 01:16:07 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Mar 2009 00:56:23 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Mar 2009 00:56:21 -0600 Message-ID: In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5374A0D6@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmY6xBP94jupkzETj+iA0b5U69mvgDj/IbwAGceYlA= References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com><64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net> <1288E74A73964940B132A0B9EA8D8ABC5374A0D6@NASANEXMB04.na.qualcomm.com> From: "Dawson, Martin" To: "Edge, Stephen" , X-OriginalArrivalTime: 06 Mar 2009 06:56:23.0983 (UTC) FILETIME=[A9B483F0:01C99E28] Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 06:55:58 -0000 There must be a word for the situation where everybody is talking about=0D=0A= something but everybody knows the real subject is something else and=0D=0Aw= hat that real subject is. Suggestions welcome.=0D=0A=0D=0AAnyway, working o= n the basis that this whole thing isn't just about=0D=0Agetting a "sound bi= te" added to the framework document that can be=0D=0Amisappropriated for ye= ars to come to confuse the cellular industry into=0D=0Athinking ECRIT is no= t relevant to them, let's look at each of Stephen's=0D=0Atopic areas below.=0D= =0A=0D=0AA fundamental tenet of the argument is that, somehow, cellular is=0D= =0A"special" and should be left to its "special" devices compared to every=0D= =0Aother Internet access technology. This, after all, is why we have IMS.=0D= =0AIt might have seemed reasonable ten years ago to define the core service=0D= =0Aarchitecture to accompany the new "Packet Service" mode of networking.=0D= =0AIn these days of Web 2.0, AJAX, Ruby on Rails, Flash, Silverlight, SOA,=0D= =0AAzure... etc. against which IMS seems very.... "stodgy" it is reasonable=0D= =0Ato ask the question why such a monolithic and cellular-legacy service=0D= =0Amodel is required. Nevertheless - 3GPP is entitled to do what 3GPP does.=0D= =0AActually I'm pretty sure you won't find references to IMS in Web 2.0=0D=0A= texts saying "of course cellular operators also use IMS as an=0D=0Aapplicat= ion framework."=0D=0A=0D=0ANow - how specific are the "special" cases that = are outlined below to=0D=0Acellular=3F:=0D=0A=0D=0A1. Access to PSTN capabl= e PSAPs=0D=0ANot specific to cellular. If a jurisdiction has PSTN capable P= SAPs then=0D=0AVoIP calls originating from any form of access have to deal = with that=0D=0Afact. The answer is fairly obvious - there has to be a media= gateway=0D=0Abehind the PSAP URI. And it might not just be a PSTN PSAP, th= ere could=0D=0Abe dedicated circuits to selective routers or, even, CAMA tr= unks=0D=0Ainvolved. The manner in which this is done really does need to be= spelt=0D=0Aout by the jurisdiction; it can't be otherwise even if there ar= e fairly=0D=0Acommon conventions. NENA looks after stating how this is done= for the=0D=0AUS. It's not up to 3GPP nor the IETF to tell jurisdictions ho= w emergency=0D=0Acalls that originate on Internet access get bridged into t= he legacy PSAP=0D=0Ainfrastructure. No more so than it was 3GPP's job to pr= escribe that E2+=0D=0Ahad to be the PSAP/ALI to GMLC interface protocol use= d for CS E9-1-1=0D=0Acalls.=0D=0A=0D=0A2. Handover between different IP acc= ess networks=0D=0ANot specific to cellular. There can be handover between W= iFi and=0D=0AEthernet, WiFi and WiMAX and so forth. Now - what we're really= talking=0D=0Aabout here is a more fundamental capability related to mobile= IP. 3GPP=0D=0Adefinitely has a very nice role to play in prescribing how t= his=0D=0Aaccess-mobility occurs across the access technologies that 3GPP de= fines=0D=0Aand supports. Since the ECRIT emergency model concerns itself fr= om the=0D=0AIP layer up, it is quite possible for it to work very transpare= ntly to=0D=0Asuch mobility occurring beneath the surface. And, of course, a= ny such=0D=0Anicely integrated access technologies would offer a nicely int= egrated=0D=0ALIS solution to ensure that the location service remains conti= guous and=0D=0Aconsistent. It seems to me that it's quite bad engineering t= o couple the=0D=0Amanner in which this is done to a specific IP service suc= h as emergency=0D=0Acalling. Can't help it if 3GPP do that - but it doesn't= obviate the=0D=0Aoption of ECRIT being applied in the more elegant way.=0D= =0A=0D=0A3. Handover to/from circuit mode networks=0D=0AI'll give you this = one... to an extent. Obviously the IETF doesn't think=0D=0Athis is in the l= east bit relevant to them. On the other, in theory, a=0D=0AVoIP connection = established on any form of IP access could be handed=0D=0Aover to some othe= r form of circuit access - e.g. DSL to ISDN. The issue,=0D=0Aof course, is = just how realistic these scenarios are. If you accept that=0D=0Athe PSTN is= going to go away (and I certainly do) then you also=0D=0Aacknowledge that = this is a transitional issue. You can argue that the=0D=0APSTN is still goi= ng to be around for years to come (and I also agree=0D=0Awith that) but tha= t doesn't mean you have to create a specific mechanism=0D=0Ato handover bet= ween circuit and packet for emergency services.=0D=0A=0D=0AI'm interested i= n just what it is that 3GPP have defined for this. I=0D=0Alook at the curre= nt 23.167 specification and, I admit, it doesn't leap=0D=0Aout at me. The s= tage 2 description has always struck me as kind of=0D=0Avague. The diagram = concerning location information handling, for=0D=0Aexample, has the dotted = boxes with non-prescriptive steps saying=0D=0A"procedure to obtain location= " done here. It always kind of reminds me=0D=0Aof that old cartoon with the= engineers looking at the complex flow chart=0D=0Awith the "a miracle happe= ns here" box in the middle. I'm thinking of a=0D=0Acall originated on IP. L= et's say the E-CSCF invokes the E-SLP to do a=0D=0ASUPL NI-LR (assuming one= manifestation of the dotted box in the diagram)=0D=0Aand the resultant loc= ation is used to determine the correct MGCF route=0D=0Ato deliver the call.= Perhaps the PSAP supports an MLP interface to the=0D=0ALRF and can ask it = for location updates - kicking off a SUPL NI-LR=0D=0Aagain. Now - the devic= e "roams" to a bit of the network that can only=0D=0Asupport circuit servic= e=3F What exactly happens=3F Does it initiate another=0D=0Acall via the MSC= =3F How does that interact with the existing emergency=0D=0Aservice semanti= cs in the MSC=3F Obviously it wants to initiate a whole new=0D=0Acall - and= initiate control plane location determination so it can=0D=0Areport an ini= tial location to the GMLC. Is that GMLC the same node as=0D=0Athe LRF=3F Ho= w does it deal with the fact that it's now got two pieces of=0D=0Astate for= what in theory is the same call=3F Or is it - given the MSC=0D=0Acan't kno= w about the PS call in progress=3F What has 3GPP actually defined=0D=0Afor = this=3F=0D=0A=0D=0AI am certainly interested in the mechanics of how this i= s all=0D=0Aaccomplished and done reliably. ITRW (the one you and I live in)= 3G=0D=0Aoperators commonly force emergency calls onto the GERAN just becau= se=0D=0Athat's lower risk since GSM emergency calling is well established a= nd=0D=0Athings like UTDOA infrastructure are available on that access. This= is=0D=0Aquite the opposite tendency of looking to have seamless real time=0D= =0Amigration between access technologies on emergency calls (let alone=0D=0A= seamless migration between PS and CS!). What carriers are planning to do=0D= =0Athis with emergency calls if you can say=3F=0D=0A=0D=0A4. Location for c= ellular access.=0D=0ACertainly not specific to cellular access. Every techn= ology has a need=0D=0Afor accurate location determination. Wired technologi= es also, most=0D=0Aappropriately, need the location to be provided in civic= address form;=0D=0Asomething that the nominated LCPs are very good at. You= 're partly=0D=0Aconfusing the role of the LCP protocol with that of the ser= ver. You can=0D=0Asend a very simple HELD request to a LIS to ask for locat= ion; it's=0D=0Aincredibly simple to do; that's why HELD client implementati= ons keep=0D=0Apopping up from different sources. The complex stuff happens = on the=0D=0Aserver side. A LIS receiving such a request can invoke all mann= er of=0D=0Acontrol plane mechanisms (for the confused - "control plane" is = not an=0D=0Aantonym of "IP"; it just means interaction occurs between netwo= rk=0D=0Aelements and not over the traffic channel with the device). For exa= mple,=0D=0Athe LIS might do UTDOA. Now, I suspect you realize this and care= fully=0D=0Achose examples of technologies that involve measurements taken b= y the=0D=0Adevice. Fortunately this is not precluded by HELD either; I beli= eve=0D=0AJames has already pointed you at the material for this.=0D=0A=0D=0A= Finally, since "cellular (=3D3GPP)" is clearly your one true interest=0D=0A= here, the good news is that cellular networks already have terrific=0D=0Ain= frastructure and control plane mechanisms in place for location=0D=0Adeterm= ination. This includes the UE peer signalling for AGPS, OTDOA and=0D=0Aso f= orth. All a LIS in a 3GPP network has to do is provide the semantics=0D=0Ao= f the LCP to the device and emergency network clients and to invoke=0D=0Ath= at existing control plane infrastructure at the back end. It's=0D=0Acertain= ly a lower cost and more robust alternative than building SUPL=0D=0Ainfrast= ructure in parallel to that control plane capability which=0D=0Aalready exi= sts to support CS emergency calls anyway.=0D=0A=0D=0A5. Endpoint based loca= tion and routing=0D=0ANothing cellular specific about this one. Same thing = applies to WiFi and=0D=0AWiMAX and wired technologies too. The old "network= loading" furphy is=0D=0Aoften rolled out for these sorts of discussions; p= resumably it's=0D=0Aattractive because it sounds "technical" but doesn't re= ally warrant=0D=0Aproper quantification and justification. Gosh "billions" = of devices -=0D=0Ahow can we even consider having so many devices doing... = "stuff"=3F It=0D=0Adoes prompt me to ask the question "what part of the ter= m 'broadband'=0D=0Adon't you understand=3F" I'm going to take a wild stab a= nd suggest that a=0D=0Adevice being used to make an emergency call probably= isn't "idle".=0D=0AFurther, with respect to the general IETF location serv= ice model, I'm=0D=0Agoing to suggest that a device that wants to ask for it= s location isn't=0D=0Aidle either. Even further, I'm going to suggest that = a LIS servicing a=0D=0Alocation dereference can have enough integration wit= h the access network=0D=0Ato have the device paged and for location procedu= res to proceed (i.e.=0D=0Ajust like a control plane MT-LR or a SUPL NI-LR -= though the latter is=0D=0Aan ill-defined proposition with respect to arbit= rary access types).=0D=0A=0D=0AActually your commentary on this section str= ongly suggests to me that=0D=0Ayou don't actually understand how an ECRIT e= mergency call procedure=0D=0Aworks. You've certainly tried to characterize = all this LoST and PSAP=0D=0Aboundary stuff that's going on as a big deal. I= t isn't and there's=0D=0Acertainly no more going on from either a device or= network perspective=0D=0Athan there would be to provide the same functiona= lity via a control=0D=0Aplane or SUPL approach. If you'd like an offline ov= erview of how an=0D=0AECRIT emergency call is made, let me know; it would b= e my pleasure.=0D=0A=0D=0A6. Support of unauthenticated users=0D=0ADefinite= ly not a cellular specific issue; every access technology has to=0D=0Aask i= tself about this. Actually every regulator in every jurisdiction=0D=0Ahas t= o ask themselves about this too - and hopefully they can avoid the=0D=0Amis= take of thinking one form of public access technology is "special"=0D=0Acom= pared to others as well. That would mitigate the risk of them coming=0D=0Au= p with inconsistent and confusing legislation.=0D=0A=0D=0AECRIT is based on= IP - so the key first step to getting an=0D=0AECRIT-compliant emergency ca= ll underway is for the device to have IP=0D=0Aaccess. In 3GPP parlance, you= 'd say it needs to have a network context.=0D=0AA good example of providing= ECRIT-compliant emergency calling to=0D=0Aunauthenticated devices is WiFi = hotspots. Hotspots typically provide=0D=0Afree layer 2 connectivity and an = IP context in the first instance.=0D=0ADevice traffic is "port-trapped" to = the Hotspots' web site (and maybe a=0D=0Asmattering of public Internet webs= ites as well). The firewall isn't=0D=0Aopened up until the user "authentica= tes"; the valid token very often=0D=0Ataking the form of a credit card numb= er and expiry date. So -what would=0D=0Aa Hotspot need to do to provide "un= authenticated" emergency access=3F All=0D=0Ait needs to do is to ensure tha= t unauthenticated devices, in addition to=0D=0Ahaving access to the portal = web page, also have access to a LIS, a LoST=0D=0Aserver and to the PSAP URI= (s) which service the location of that=0D=0Ahotspot. That's it; sure there'= s no emergency call proxy via a third=0D=0Aparty VSP - but that's not neces= sary (I'm actually against it anyway)=0D=0Abut it could be accommodated wit= h some tweaks on the approach described.=0D=0A=0D=0ANow - what would a 3GPP= network need to do to support an ECRIT-compliant=0D=0Aunauthenticated emer= gency calling facility=3F You could probably describe=0D=0Ait better than m= e - but I dare say it would involve allowing the device=0D=0Ato establish a= n emergency IP context (something which I believe is=0D=0Arequired by 23.16= 7 anyway - otherwise how would the UE be able to tell=0D=0Athe P-CSCF it wa= nts to do an emergency call=3F). Having permitted the=0D=0Acreation of the = emergency context, the 3GPP network would similarly just=0D=0Aneed to const= rain the device's access to the LIS, LoST, and the PSAP=0D=0AURI(s) for the= corresponding location. Obviously 3GPP have decided to=0D=0Adefine a diffe= rent way of doing things and that's par for the course.=0D=0AIt's 3GPP's pr= erogative to continue to act as if there is something=0D=0Aspecial about ce= llular and that there's good reason for it to look=0D=0Adifferent to both I= P devices and the emergency network. It's not true -=0D=0Abut that's never = stopped the silo thinking before. And that puts me in=0D=0Amind of that sce= ne from Python's Holy Grail movie. 3GPP guarding the=0D=0Abridge to "cellul= ar land" - "None shall pass..." - It'll end much the=0D=0Asame way as well.=0D= =0A=0D=0ACheers,=0D=0AMartin=0D=0A-----Original Message-----=0D=0AFrom: ecr= it-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0AOf Edge,= Stephen=0D=0ASent: Wednesday, 4 March 2009 4:32 PM=0D=0ATo: br@brianrosen.= net=0D=0ACc: ECRIT=0D=0ASubject: Re: [Ecrit] Comments on Framework Draft=0D= =0A=0D=0ABrian=0D=0A=0D=0AThanks for these well considered responses. Below= I am providing on an=0D=0Aitem by item basis, and taking into account your= responses, a few more=0D=0Areasons why the current Ecrit solution is unsui= table - or, if you=0D=0Aprefer, less suitable than the 3GPP/3GPP2 solution = - for cellular=0D=0Anetworks.=0D=0A=0D=0A1. Access to PSTN capable PSAPs=0D= =0AAssuming that the best available solution for this currently is the=0D=0A= ongoing NENA i2 standard (as you comment), then there are problems with=0D=0A= providing location for dispatch (initial and updated location). For=0D=0Aex= ample, the latest i2.5 draft I have (December 2008) says that the VPC=0D=0A= to LIS v3 interface is being deprecated (thus not available), although=0D=0A= this is the interface that the VPC would use to query location from the=0D=0A= LIS. Also I don't see any inclusion of accurate positioning support -=0D=0A= e.g. using A-GPS. Further, interworking with the circuit mode side for=0D=0A= UA access (as opposed to PSAP access) seems to be out of scope. So at=0D=0A= best, this standard is incomplete (i.e. not yet suitable for cellular=0D=0A= networks). However, I agree that there is some overlap between i2.5 and=0D=0A= the 3GPP/3GPP2 solution.=0D=0A=0D=0A2. Handover between different IP access= networks including different=0D=0Atypes of access network=0D=0AOne of the = issues here would be change of LIS across different networks=0D=0Awhile avo= iding impacts to both IP and PSTN capable PSAPs (i.e. handover=0D=0Amust be= transparent to PSAPs within the limitations imposed by SIP or=0D=0Asome J-= STD-036 type of circuit mode solution). The problem gets more=0D=0Adifficul= t when handover to/from circuit mode access networks is=0D=0Aconsidered. So= far, 3GPP/3GPP2 has not yet agreed on a solution although=0D=0Athere are p= roposals and we expect some resolution soon. On the Ecrit and=0D=0ANENA sid= es, I see much less progress.=0D=0A=0D=0A3. Handover to/from circuit mode n= etworks=0D=0AWe agree here at least on the out of scope aspect. I suppose I= can=0D=0Aaccept that it is not customary to point this out in IETF standar= ds. But=0D=0AI hope you can see that this is an issue for cellular networks= most of=0D=0Awhich will have extensive circuit mode coverage for a long ti= me to come.=0D=0A=0D=0A4. Location for cellular access (and the requirement= to support LCPs=0D=0Athat will be useless for cellular access)=0D=0AThe is= sue is not so much the LCP itself but the capability to support=0D=0Aaccura= te positioning - e.g. using A-GPS, AFLT, OTDOA, enhanced cell ID=0D=0Aetc. = None of those methods seem to be supported as part of DHCP or HELD=0D=0Arig= ht now. So some modification of the LCP related requirements or of=0D=0Athe= LCPs seems needed.=0D=0A=0D=0A5. Endpoint based location and routing for c= ellular access (issues here=0D=0Aare network and device loading as well as = device impacts and problems=0D=0Awith PSTN capable PSAPs)=0D=0AEndpoint bas= ed location when spread over millions (billions,=0D=0Aplanet-wide) of termi= nals will consume significant network and terminal=0D=0Aresources. A typica= l terminal is generally idle and interacts with the=0D=0Anetwork very spari= ngly to update the network with its current location=0D=0A(e.g. current clu= ster of potential serving cells). Performing network=0D=0Aassisted periodic= location fixes and LoST queries would add=0D=0Asignificantly to network lo= ad. Performing periodic location fixes in the=0D=0Aterminal (e.g. using GPS= ) and estimating when a PSAP boundary may have=0D=0Abeen crossed would add = to terminal load (e.g. thus battery drain).=0D=0AOptimizations would be pos= sible of course - e.g. based on observing=0D=0Anearby cell IDs - but they w= ill add to terminal complexity and testing=0D=0Acosts. I agree that the Ecr= it solution does allow for proxies to do this=0D=0Abut here the solution al= so becomes incomplete because there seem no=0D=0Adetails of how this would = work - e.g. what location solutions would then=0D=0Abe used.=0D=0A=0D=0A6. = Support of unauthenticated users and users who can be authenticated=0D=0Abu= t are not permitted access/VSP service except for emergency calls=0D=0AI th= ink the Ecrit solution and you both assume that this has already=0D=0Abeen = resolved somehow at the access level and therefore the various=0D=0Aprocedu= res in Ecrit can still be used. Maybe that is valid. However,=0D=0Athere ar= e still problems that are not covered in the Ecrit drafts but=0D=0Aneed to = be resolved including (a) obtaining IP access (e.g. via a WLAN,=0D=0Acellul= ar network, cable link) when not a valid subscriber, (b) obtaining=0D=0Aacc= ess to the VSP and (c) ensuring only emergency related services are=0D=0Apr= ovided (e.g. and not free Internet and location access). These and=0D=0Aadd= itional problems (e.g. UA identification) would have to be solved,=0D=0Amay= be on a per access basis, and then ensured to be compatible with the=0D=0Ar= est of the Ecrit solution. A significant part of the 3GPP/3GPP2=0D=0Asoluti= on is concerned with this aspect and it has delayed completion of=0D=0Athe = solution for the more normal case of valid subscriber access due to=0D=0Asu= ch compatibility issues.=0D=0A=0D=0AKind Regards=0D=0A=0D=0AStephen=0D=0A--= ---Original Message-----=0D=0AFrom: br@brianrosen.net [mailto:br@brianrosen= =2Enet]=0D=0ASent: Friday, February 27, 2009 6:53 AM=0D=0ATo: Edge, Stephen=0D= =0ACc: Thomson, Martin; Richard Barnes; ECRIT=0D=0ASubject: Re: [Ecrit] Com= ments on Framework Draft=0D=0A=0D=0AStephen=0D=0A=0D=0ALike any standards o= rganization, the IETF restricts it's scope.=0D=0AGenerally, the scope is "t= he Internet", although we very often describe=0D=0Asolutions that are expli= citly designed for private IP networks as well=0D=0Aas=0D=0Athe Internet. = We don't write standards for circuit switched networks,=0D=0Aand=0D=0Ait sh= ould be no surprise that the ecrit solution does not cater to CS=0D=0Asolut= ions. Nevertheless, we often try to make sure that our solutions=0D=0Aharm= onize reasonably well with existing solutions.=0D=0A=0D=0AIndeed, the ecrit= solution clains global applicability to the Internet=0D=0Ain=0D=0Ageneral,= and most private IP networks that can be interconnected to the=0D=0AIntern= et or to other IP networks via gateways. Looking at your list of=0D=0Aprob= lem areas:=0D=0A> - access to PSTN capable PSAPs=0D=0AThis is out of scop= e for IETF. NENA has active work on this subject.=0D=0AIt=0D=0Aseems strai= ghtforward to interwork ecrit compatible devices and networks=0D=0Ato exist= ing CS connected PSAPs. As you know, CS interconnects are very=0D=0Anation= -specific, so the NENA work may not have general applicability.=0D=0AHoweve= r, it shows that it is possible to interwork. The NENA i2 work is=0D=0Aals= o designed to take ecrit compatible devices and VSP networks, and=0D=0Ainte= rwork them to the existing network. The VSP would direct the call=0D=0Ato=0D= =0Athe VPC, which would provide the services it does now, using the device=0D= =0Aprovided location for routing. This is important for smooth transition=0D= =0Afrom existing PSAPs and VSPs to "next generation" PSAPs and VSPs.=0D=0A>= - handover between different IP access networks including different=0D=0A= > types of access network=0D=0AIn the ecrit solution, the access network th= e call is initiated on=0D=0Aprovides all the facilities needed for the devi= ce to initiate an=0D=0Aemergency=0D=0Acall. The call starts traversing it= 's normal call path, and eventually=0D=0Aroutes to the ESRP. Handoffs betw= een IP networks should be transparent=0D=0Ato=0D=0Athis process, although w= e probably haven't done all the work we need to=0D=0Ado=0D=0Afor handoffs w= here the IP address as seen by the terminating network=0D=0Achanges. This = would generally be true of all current SIP based work.=0D=0A> - handover = to/from circuit mode networks=0D=0AThis would be out of scope for IETF. It= 's as applicable to a simple SIP=0D=0Acall as it is a SIP emergency call, a= nd there are no statements in any=0D=0ASIP=0D=0Adocuments on that subject.=0D= =0A> - location for cellular access (and the requirement to support LCPs=0D= =0Athat=0D=0A> will be useless for cellular access)=0D=0ALocation for cellu= lar access networks has been considered carefully.=0D=0ASince cellular is a= mobile network, the access network would pass the=0D=0Adevice a Location-B= y-Reference URI, using either DHCP or HELD. Either=0D=0Aprotocol is suitab= le for cellular networks. As we have pointed out=0D=0Aseveral times, cellu= lar networks support raw data packet services upon=0D=0Awhich many differen= t kinds of networks can be constructed. My usual=0D=0Aexample is a large r= ecreational vehicle traveling down a road with a=0D=0Acellular data card pl= ugged into a router to which a wired (Ethernet)=0D=0Aphone=0D=0Ais connecte= d. That phone must be able to make an emergency call, and it=0D=0Awill get= location from DHCP or HELD (or LLDP-MED). It is not aware of=0D=0Athe=0D=0A= cellular network, and doesn't know any cellular specific protocols.=0D=0ACe= llular networks will have to support IETF location configuration=0D=0Aproto= cols unless they actively prohibit examples like this, or they=0D=0Aimpleme= nt interworking between cellular-specific location protocols and=0D=0ADHCP = or HELD in the data card. The ecrit standards permit proxy=0D=0Ainsertion=0D= =0Aof location, but, as above, we don't think that works in all cases.=0D=0A= > - endpoint based location and routing for cellular access (issues=0D=0A= here=0D=0A> are network and device loading as well as device impacts and pr= oblems=0D=0A> with PSTN capable PSAPs)=0D=0AThe "load" of using DHCP or HEL= D to get location and querying LoST is=0D=0Apretty modest. The standards p= ermit proxies to do this if the devices=0D=0Adon't. As above, interwork fu= nctions to CS connected PSAPs is very=0D=0Afeasible, and as above, cellular= networks will have to support access to=0D=0Alocal LoST servers for device= s that are connected to cellular networks=0D=0Aand=0D=0Aare ecrit compliant= =2E=0D=0A> - support of unauthenticated users and users who can be=0D=0Aa= uthenticated=0D=0A> but are not permitted access/VSP service except for eme= rgency calls=0D=0AThis is covered in the standards. None of the processes = are dependent=0D=0Aon=0D=0Aauthentication, although where it is possible, i= t's desirable so as to=0D=0Aminimize fraudulent emergency calls=0D=0AMechan= isms for specific network authentication mechanisms are out of=0D=0Ascope, = and, like SIP basic calling, are not usually mentioned in IETF=0D=0Adocumen= ts.=0D=0A=0D=0AStephen, we've tried pretty hard to make sure this works for= 3G/4G=0D=0Amobile=0D=0Anetworks. It's true that it doesn't do it the way = 3GPP currently thinks=0D=0Ait ought to work, but we claim they haven't thou= ght through all the=0D=0Aissues. While it would work, there are opportunit= ies for improvement.=0D=0AWe=0D=0Awould be willing to do that if we could g= et the cooperation of 3GPP,=0D=0Awhich=0D=0Awe have tried, and failed, to d= o.=0D=0A=0D=0ASo, I think the documents do not need any qualification state= ments.=0D=0A=0D=0ABrian=0D=0A=0D=0A> Martin=0D=0A>=0D=0A> The 3GPP/3GPP2 so= lution has a defined restricted applicability (mainly=0D=0Ato=0D=0A> 3GPP/3= GPP2 access networks where the serving network also acts as the=0D=0AVSP)=0D= =0A> and the specifications for it cover in detail all possible scenarios=0D= =0A> consistent with these restrictions so far as we are aware.=0D=0A>=0D=0A= > The Ecrit solution seems to claim global applicability to all types of=0D= =0AIP=0D=0A> access (and the more that is said about this from Ecrit partic= ipants=0D=0Athe=0D=0A> more this gets emphasized) but does not cover in det= ail all possible=0D=0A> scenarios (in some cases does not cover in any deta= il) which means=0D=0Athat at=0D=0A> best the solution is incomplete and at = worst intrinsically=0D=0Ainapplicable to=0D=0A> some unstated set of scenar= ios.=0D=0A>=0D=0A> The missing, incomplete and problematic cases include th= e following:=0D=0A>=0D=0A> - access to PSTN capable PSAPs=0D=0A> - hand= over between different IP access networks including different=0D=0A> types = of access network=0D=0A> - handover to/from circuit mode networks=0D=0A> = - location for cellular access (and the requirement to support LCPs=0D=0A= that=0D=0A> will be useless for cellular access)=0D=0A> - endpoint based = location and routing for cellular access (issues=0D=0Ahere=0D=0A> are netwo= rk and device loading as well as device impacts and problems=0D=0A> with PS= TN capable PSAPs)=0D=0A> - support of unauthenticated users and users who= can be=0D=0Aauthenticated=0D=0A> but are not permitted access/VSP service = except for emergency calls=0D=0A>=0D=0A> Stating that some of these cases a= re out of scope or referencing an=0D=0A> incomplete and possibly questionab= le specification from some other=0D=0A> national SDO will not help the user= who encounters such problems. But=0D=0Ait=0D=0A> would certainly help netw= ork operators and implementers to acknowledge=0D=0A> their existence in one= form or another because that would allow better=0D=0A> planning of deploym= ents and would help focus attention on finding=0D=0A> solutions (whether in= IETF or elsewhere) for the missing cases.=0D=0A>=0D=0A> Please note that d= espite these drawbacks, I will acknowledge that=0D=0AEcrit=0D=0A> does have= a valuable solution that covers many scenarios not covered=0D=0Aby=0D=0A> = 3GPP/3GPP2. It would be the delineation of these supported scenarios=0D=0A(= or=0D=0A> equivalently unsupported scenarios) in some applicability stateme= nt=0D=0Athat=0D=0A> would be particularly useful right now.=0D=0A>=0D=0A> K= ind Regards=0D=0A>=0D=0A> Stephen=0D=0A> -----Original Message-----=0D=0A> = From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=0D=0A> Sent: Thurs= day, February 26, 2009 9:45 PM=0D=0A> To: Edge, Stephen; Richard Barnes=0D=0A= > Cc: ECRIT=0D=0A> Subject: RE: [Ecrit] Comments on Framework Draft=0D=0A>=0D= =0A> There's benefit in knowing the limitations of a framework, and every=0D= =0A> architecture makes certain assumptions. Let's examine them though...=0D= =0A>=0D=0A> The IETF might occasionally make the assumption that the standa= rds it=0D=0A> develops are for Internet devices. That assumption probably = need not=0D=0Abe=0D=0A> stated explicitly.=0D=0A>=0D=0A> The ECRIT architec= ture relies on implementations of the protocols that=0D=0Ait=0D=0A> referen= ces. That is not extraordinary. A reliance on implementation=0D=0Aof=0D=0A= > these protocols by endpoints, routing intermediaries and PSAPs should=0D=0A= not=0D=0A> need to be explained.=0D=0A>=0D=0A> So the assumptions are:=0D=0A= > - the Internet=0D=0A> - solutions are implemented and deployed=0D=0A> = - the end device is a key component=0D=0A>=0D=0A> Only that last element is= particularly novel ... or not that much=0D=0Areally.=0D=0A> It's a desig= n choice. Unless you were thinking of trunking the=0D=0Avoice=0D=0A> elsew= here.=0D=0A>=0D=0A> Of course, you're suggesting that the design choice was= made in=0D=0Aignorance=0D=0A> of all the constraints. You're suggesting t= hat - as a result - the=0D=0Achoice=0D=0A> is flawed and the solution is no= t going to work for cellular services.=0D=0AWe=0D=0A> disagree. The soluti= on is a basis for emergency calling in _any_ IP=0D=0A> network.=0D=0A>=0D=0A= > Cheers,=0D=0A> Martin=0D=0A>=0D=0A>=0D=0A>> -----Original Message-----=0D= =0A>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=0D=0A= Behalf=0D=0A>> Of Edge, Stephen=0D=0A>> Sent: Friday, 27 February 2009 3:30= PM=0D=0A>> To: Richard Barnes=0D=0A>> Cc: 'ECRIT'=0D=0A>> Subject: Re: [Ec= rit] Comments on Framework Draft=0D=0A>>=0D=0A>> Hi Richard=0D=0A>>=0D=0A>>= Thanks for the comments. Your statement below that "SIP emergency=0D=0A>> = calling works if all parties behave as specified in these (IETF=0D=0AEcrit)=0D= =0A>> documents" to some degree highlights the problems we are raising. The=0D= =0A>> documents do contain a number of implicit and explicit restrictions -=0D= =0A>> like IP capable PSAPs, global IP access (no islands of circuit mode=0D= =0A>> access for example), universal support of this solution by all access=0D= =0A>> providers and VSPs (not much good if some opt for another solution)=0D= =0Aand=0D=0A>> end system oriented location and routing capability - which = together=0D=0A>> make them unsuitable (we believe) for cellular wireless ne= tworks. If=0D=0A>> these restrictions and assumptions were all made explici= t upfront, it=0D=0A>> would to a large degree (and possibly completely) add= ress our=0D=0Aconcerns.=0D=0A>>=0D=0A>> You are right in assuming another s= et of specifications for the 3GPP=0D=0A>> and 3GPP2 solution. The applicabi= lity of this solution is explicitly=0D=0A>> defined in TS 23.167 (or more e= xactly in an already agreed CR in=0D=0A>> contribution S2-090752 which will= become part of 23.167 in a few more=0D=0A>> weeks) to cover the following = access types: GPRS (UTRAN WCDMA),=0D=0AI-WLAN,=0D=0A>> Fixed Broadband, CDM= A2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN=0D=0A>> (LTE). So there is a = restriction and arbitrary internet access is not=0D=0A>> covered (yet) as I= have stated before.=0D=0A>>=0D=0A>> Kind Regards=0D=0A>>=0D=0A>> Stephen=0D= =0A>> -----Original Message-----=0D=0A>> From: Richard Barnes [mailto:rbarn= es@bbn.com]=0D=0A>> Sent: Wednesday, February 25, 2009 6:30 PM=0D=0A>> To: = Edge, Stephen=0D=0A>> Cc: Brian Rosen; 'ECRIT'=0D=0A>> Subject: Re: [Ecrit]= Comments on Framework Draft=0D=0A>>=0D=0A>> Hi Stephen,=0D=0A>>=0D=0A>> I'= m a little confused by the scope of what you're asking. The=0D=0A>> framew= ork=0D=0A>> and phonebcp documents exist in order to describe the ECRIT sol= ution:=0D=0A>> They say, in effect, "SIP emergency calling works if all par= ties=0D=0Abehave=0D=0A>> as specified in these documents."=0D=0A>>=0D=0A>> = As I understand what you're saying (and I'm by no means an expert in=0D=0A>= > 3GPP), 3GPP specifies that one or more elements of this system behave=0D=0A= >> differently. This simply means that 3GPP networks aren't complying=0D=0A= >> with=0D=0A>> these specs. Just like there's no disclaimer in RFC 791 (I= Pv4) that=0D=0A>> says "this doesn't work on X.25 networks", it's not clear= to me that=0D=0Aan=0D=0A>> analogous disclaimer is called for here.=0D=0A>= >=0D=0A>> I presume there are similar documents describing how emergency=0D= =0Acalling=0D=0A>> works in 3GPP networks. Do they include notes saying th= at the 3GPP=0D=0A>> solution doesn't work in the broader Internet=3F=0D=0A>= >=0D=0A>> --Richard=0D=0A>>=0D=0A>>=0D=0A>>=0D=0A>>=0D=0A>>=0D=0A>> Edge, S= tephen wrote:=0D=0A>> > Brian=0D=0A>> >=0D=0A>> > First of all apologies fo= r the likely lateness of this reply - I=0D=0A>> actually wrote it on 19 Feb= ruary in a 3GPP SA2 meeting in Budapest=0D=0Abut=0D=0A>> it seems unlikely = that my VPN, Outlook server and WiFi access=0D=0A>> capability will coopera= te together to get it sent until I return to=0D=0Athe=0D=0A>> office mid-ne= xt week.=0D=0A>> >=0D=0A>> > Anyhow thanks for your comments. There have ac= tually been a number=0D=0Aof=0D=0A>> conference calls between IETF and 3GPP= participants over the last=0D=0A>> couple of years at which common feature= s like support of IP emergency=0D=0A>> calls were discussed and these could= have been good forum for=0D=0A>> participants on either side to have raise= d the kinds of issues you=0D=0A>> elaborate on below. Given that seems not = so far to have happened, it=0D=0A>> could still be possible in future such = calls.=0D=0A>> >=0D=0A>> > But the issues we are raising are not directly t= o do with further=0D=0A>> aligning the 2 solutions or with the lack of this= in the past. We are=0D=0A>> simply pointing out that the solutions are cur= rently different and=0D=0Athat=0D=0A>> from a cellular wireless perspective= , the Ecrit solution is not seen=0D=0Aas=0D=0A>> suitable in all respects (= for support of IP emergency calls=0D=0Aoriginating=0D=0A>> from such access= types). That is not just our point of view. 3GPP2=0D=0Asent=0D=0A>> a liai= son to Ecrit some months ago pointing out the same issues.=0D=0A>> >=0D=0A>= > > So we are proposing that the Ecrit framework and phoneBCP spec.s=0D=0A>= > include a statement acknowledging this - e.g. by referencing the=0D=0A>> = alternative 3GPP/3GPP2 solution and indicating the IP access types=0D=0Afor=0D= =0A>> which the Ecrit solution will work without limitation (or=0D=0Aequiva= lently=0D=0A>> the access types where limitations are not ruled out).=0D=0A= >> >=0D=0A>> > We are not proposing further modification and extension of t= he=0D=0AEcrit=0D=0A>> solution - just pointing out that this would be neede= d (as with the=0D=0A>> 3GPP/3GPP2 solution) to fully cover all types of acc= ess.=0D=0A>> >=0D=0A>> > Kind Regards=0D=0A>> >=0D=0A>> > Stephen=0D=0A>> >= -----Original Message-----=0D=0A>> > From: Brian Rosen [mailto:br@brianros= en.net]=0D=0A>> > Sent: Wednesday, February 18, 2009 8:07 PM=0D=0A>> > To: = Edge, Stephen; 'ECRIT'=0D=0A>> > Subject: RE: [Ecrit] Comments on Framework= Draft=0D=0A>> >=0D=0A>> > I have bit my tongue on this one for a long time= =2E=0D=0A>> >=0D=0A>> > Stephen, with respect, please go talk to 3GPP manag= ement and ask=0D=0Athem=0D=0A>> why=0D=0A>> > there has been no participati= on in the ecrit effort despite=0D=0Amultiple=0D=0A>> YEARS=0D=0A>> > of beg= ging them to get involved. To put it frankly, 3GPP is quite=0D=0A>> willin= g=0D=0A>> > to bully IETF into doing its work on its schedule, but cannot b= e=0D=0A>> bothered to=0D=0A>> > get work done it knows it will eventually h= ave to do when the IETF=0D=0A>> asks it=0D=0A>> > to do so.=0D=0A>> >=0D=0A= >> > 3GPP understands the mess that is being created by not=0D=0Aparticipat= ing.=0D=0A>> They=0D=0A>> > know full well that when they finally get aroun= d to dealing with PS=0D=0A>> > terminated emergency calls, that there will = be a lot of resistance=0D=0Ato=0D=0A>> > changing fully specified and imple= mented standards to more closely=0D=0A>> align=0D=0A>> > with 3GPP standard= s. I expect you will have several interworking=0D=0A>> functions=0D=0A>> >= to define and build.=0D=0A>> >=0D=0A>> > So, politely, please go away, we'= re finishing work we dearly wanted=0D=0A>> you all=0D=0A>> > to be involved= with for years, but you refused to do anything.=0D=0AIt's=0D=0A>> too=0D=0A= >> > late for this rev.=0D=0A>> >=0D=0A>> > Now, having said that, there ar= e quite a few people who have=0D=0A>> participated in=0D=0A>> > the IETF wo= rk who are IMS aware and I believe that despite your=0D=0A>> fears,=0D=0A>>= > everything you need is in the specs. The mechanisms we have=0D=0Adefine= d=0D=0A>> provide=0D=0A>> > the ability for the network to insert location,= recognize and mark=0D=0A>> emergency=0D=0A>> > calls, and route on behalf = of endpoints. An E-CSCF could quite=0D=0A>> > straightforwardly provide a = SIP call towards an ecrit compatible=0D=0A>> PSAP. The=0D=0A>> > only not-= quite-nice interwork would be from SUPL to HELD (or SIP),=0D=0A>> but it's=0D= =0A>> > pretty easy to do that. I'll also note that we have tried to get=0D= =0AOMA=0D=0A>> and=0D=0A>> > IETF to cooperate on location protocols, but w= e have been=0D=0A>> spectacularly=0D=0A>> > unsuccessful at that effort als= o.=0D=0A>> >=0D=0A>> > Brian=0D=0A>> >=0D=0A>> >=0D=0A>> >=0D=0A>> >> -----= Original Message-----=0D=0A>> >> From: ecrit-bounces@ietf.org [mailto:ecrit= -bounces@ietf.org] On=0D=0A>> Behalf=0D=0A>> >> Of Edge, Stephen=0D=0A>> >>= Sent: Thursday, February 05, 2009 2:50 AM=0D=0A>> >> To: 'ECRIT'=0D=0A>> >= > Subject: [Ecrit] Comments on Framework Draft=0D=0A>> >>=0D=0A>> >> All=0D= =0A>> >>=0D=0A>> >> draft-ietf-ecrit-framework-07 is (as we see it) a mostl= y=0D=0Ainformative=0D=0A>> >> description of how terminals and networks sho= uld support emergency=0D=0A>> >> calls made over IP capable facilities to I= P capable PSAPs. It=0D=0A>> appears=0D=0A>> >> intended to cover all types = of access network - including fixed=0D=0A>> line,=0D=0A>> >> WiFi and cellu= lar (e.g. examples involving each can be found=0D=0A>> throughout=0D=0A>> >= > the draft).=0D=0A>> >>=0D=0A>> >> When we evaluated this with respect to = support of wireless=0D=0Acellular=0D=0A>> >> access and WiFi access associa= ted with a cellular operator (e.g.=0D=0A>> WLAN=0D=0A>> >> or Femto cells i= ntegrated into a cellular network), we found that=0D=0A>> >> certain portio= ns of the draft exhibited one or more of the=0D=0Afollowing=0D=0A>> >> char= acteristics:=0D=0A>> >>=0D=0A>> >> (A) Inconsistent with already standa= rdized wireless solutions=0D=0A>> >>=0D=0A>> >> (B) Inconsistent with e= ssential wireless requirements and=0D=0A>> >> conventions=0D=0A>> >>=0D=0A>= > >> (C) Already part of wireless standards or potentially part of=0D=0A= >> >> future standards=0D=0A>> >>=0D=0A>> >> (A) refers to all portions of = the draft framework that differ from=0D=0A>> the=0D=0A>> >> requirements an= d procedures currently standardized for wireless=0D=0A>> >> emergency acces= s by 3GPP, 3GPP2 and OMA. This is a plain=0D=0Adifference=0D=0A>> of=0D=0A>= > >> solution and could be resolved through support of both solutions=0D=0A= by=0D=0A>> >> terminals (with each solution being used according to the typ= e of=0D=0A>> >> access network and VSP) or could be resolved by supporting = only=0D=0Aone=0D=0A>> >> solution and accessing only the types of network s= upporting that=0D=0A>> >> solution. To acknowledge this category, the frame= work document=0D=0Acould=0D=0A>> >> reference the applicable wireless stand= ards and point out that=0D=0Athese=0D=0A>> >> are valid alternatives for wi= reless cellular based access.=0D=0A>> >>=0D=0A>> >> (B) refers to portions = of the draft that would be unsuitable for=0D=0A>> >> wireless networks even= if no alternative solution existed together=0D=0A>> with=0D=0A>> >> other = portions missing from the draft that would be needed to=0D=0Afully=0D=0A>> = >> support wireless networks. Examples of the former include: (a)=0D=0A>> e= mphasis=0D=0A>> >> on endpoint derivation of location, performance of Lost = query and=0D=0A>> >> receipt of local dial strings; (b) restriction of LCPs= to=0D=0Aprotocols=0D=0A>> >> that require terminal initiation (not allowin= g for network=0D=0A>> initiation=0D=0A>> >> as far as we can tell) and that= include two LCPs (DHCP and LLDP)=0D=0A>> that=0D=0A>> >> are not applicabl= e to (not defined for) cellular access; and (c)=0D=0Athe=0D=0A>> >> require= ment that a terminal or at least a LIS will update the PSAP=0D=0A>> >> when= ever location changes. (a) is impractical due to network and=0D=0A>> >> ter= minal loading consequences and failure to support non-IP=0D=0Acapable=0D=0A= >> >> PSAPs; (b) makes location verification and updated location=0D=0A>> p= rovision=0D=0A>> >> to PSAPs difficult or impossible; while (c) is also inc= ompatible=0D=0A>> with=0D=0A>> >> support of existing non-IP capable PSAPs = besides increasing=0D=0Aterminal=0D=0A>> >> load and possibly interfering w= ith optimum maintenance of the RF=0D=0A>> >> connection (e.g. if a terminal= has to tune away from the serving=0D=0A>> base=0D=0A>> >> station or WLAN = periodically to make location measurements).=0D=0A>> Examples=0D=0A>> >> of= the latter include (d) absence of support for access to non-IP=0D=0A>> >> = capable PSAPs as already mentioned (e.g. to support E911 phase 2=0D=0Ain=0D= =0A>> the=0D=0A>> >> US); (e) no support for handover from the IP to the ci= rcuit domain=0D=0A>> when=0D=0A>> >> a terminal loses (e.g. moves out of) R= F coverage in the IP domain;=0D=0A>> and=0D=0A>> >> (f) no allowance for li= mited access modes wherein a terminal may=0D=0A>> access=0D=0A>> >> a netwo= rk only to place an emergency call with ensuing=0D=0Arestrictions=0D=0A>> o= n=0D=0A>> >> (for example) location acquisition, PSAP callback and caller=0D= =0A>> >> verification and identification to the PSAP. To resolve this=0D=0A= >> category=0D=0A>> >> either significant changes to the framework document= could be made=0D=0A>> or a=0D=0A>> >> disclaimer/applicability statement c= ould be added stating that=0D=0A>> support=0D=0A>> >> of cellular wireless = networks and their associated WLAN and Femto=0D=0A>> >> access points is no= t covered.=0D=0A>> >>=0D=0A>> >> Category (C) comprises concepts and capabi= lities in the draft that=0D=0A>> are=0D=0A>> >> either already part of the = standardized solution for wireless=0D=0A>> networks=0D=0A>> >> or that migh= t be added at a later time. Examples of the former=0D=0A>> include=0D=0A>> = >> LoST, SIP location conveyance, general use of SIP, location for=0D=0A>> = routing=0D=0A>> >> versus for dispatch, cellular positioning methods. Examp= les of the=0D=0A>> >> latter include use of location references and derefer= encing and=0D=0A>> >> possible interworking between the current wireless ne= twork=0D=0Asolutions=0D=0A>> >> (in 3GPP, 3GPP2 and OMA) and the solution d= escribed in this draft.=0D=0A>> The=0D=0A>> >> presence of this category co= uld be acknowledged by following the=0D=0A>> >> disclaimer for (B) with a s= tatement that certain portions of the=0D=0A>> >> solution are expected to b= e incorporated into wireless networks=0D=0Anow=0D=0A>> >> and/or in the fut= ure.=0D=0A>> >>=0D=0A>> >> We hope that these comments will be seen to be a= useful addition=0D=0Ato=0D=0A>> >> this review in the sense of enabling a = more precise scoping for=0D=0Athe=0D=0A>> >> framework document and we are = willing to assist in providing=0D=0Awording=0D=0A>> >> for any disclaimer/a= pplicability statement that the Ecrit working=0D=0A>> group=0D=0A>> >> may = now deem fit to include.=0D=0A>> >>=0D=0A>> >> Kind Regards=0D=0A>> >>=0D=0A= >> >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs=0D=0A>> = (Qualcomm=0D=0A>> >> 3GPP2 TSG-X and TSG-C participant)=0D=0A>> >>=0D=0A>> = >> PS this being sent on 2/4/09 at 11:50pm PST=0D=0A>> >>=0D=0A>> >> _____= __________________________________________=0D=0A>> >> Ecrit mailing list=0D= =0A>> >> Ecrit@ietf.org=0D=0A>> >> https://www.ietf.org/mailman/listinfo/ec= rit=0D=0A>> >=0D=0A>> > _______________________________________________=0D=0A= >> > Ecrit mailing list=0D=0A>> > Ecrit@ietf.org=0D=0A>> > https://www.ietf= =2Eorg/mailman/listinfo/ecrit=0D=0A>> >=0D=0A>> ___________________________= ____________________=0D=0A>> Ecrit mailing list=0D=0A>> Ecrit@ietf.org=0D=0A= >> https://www.ietf.org/mailman/listinfo/ecrit=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 infor= mation.=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> t= his email is prohibited.=0D=0A>=0D=0A--------------------------------------= ----------------------------------=0D=0A------------------------=0D=0A> [mf= 2]=0D=0A> _______________________________________________=0D=0A> Ecrit mail= ing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www.ietf.org/mailman/listinfo= /ecrit=0D=0A>=0D=0A=0D=0A_______________________________________________=0D= =0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman= /listinfo/ecrit=0D=0A=0D=0A------------------------------------------------= ------------------------------------------------=0D=0AThis message is for t= he 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=0Aimmediately and delete the original. Any u= nauthorized use of=0D=0Athis email is prohibited.=0D=0A--------------------= ---------------------------------------------------------------------------= -=0D=0A[mf2]=0D=0A From sedge@qualcomm.com Thu Mar 5 23:18:30 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52A8C3A68E7 for ; Thu, 5 Mar 2009 23:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.508 X-Spam-Level: X-Spam-Status: No, score=-105.508 tagged_above=-999 required=5 tests=[AWL=1.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ie0HQuur4rPt for ; Thu, 5 Mar 2009 23:18:28 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 68E1A3A6932 for ; Thu, 5 Mar 2009 23:18:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1236323939; x=1267859939; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" Winterbottom,=20James"=20, =0D=0A=20=20=20=20=20=20=20=20Brian=20Rosen=0D=0A=09,=20ECRIT=20|Date:=20Thu, =205=20Mar=202009=2023:18:43=20-0800|Subject:=20RE:=20[Ec rit]=20Comments=20on=20Framework=20Draft|Thread-Topic:=20 [Ecrit]=20Comments=20on=20Framework=20Draft|Thread-Index: =20AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwKeEe+gADZBfMABQDsYoAA26f DAAJM+RGAA0IcHYA=3D=3D|Message-ID:=20<1288E74A73964940B13 2A0B9EA8D8ABC5374A271@NASANEXMB04.na.qualcomm.com> |References:=20<1288E74A73964940B132A0B9EA8D8ABC535F0305@ NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c 60$@net>=0D=0A=20<1288E74A73964940B132A0B9EA8D8ABC53749D4 8@NASANEXMB04.na.qualcomm.com>=0D=0A=20=0D=0A=20<1288E 74A73964940B132A0B9EA8D8ABC53749E3B@NASANEXMB04.na.qualco mm.com>=0D=0A=20|In-Reply-To:=20|Accept-Language: =20en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5544"=3B=20a=3D"16037302"; bh=vdaS2T0rG3XsdXHBUZGg42MLx94icXENWsTEZljLbh0=; b=wqxKZiVr+C8d02fnZM4CGnWkbhyZqh7yHWgNKm6mXPqPawaJN+PZ7exr JvASk6BNrbTlZKRCOzcQMUsHIOQ3GW37jGbEyiDVvIiO4gYjZcm1uWuym xwRphgnjaVx3H4UQlbZWYmrK2cxXA3RNpqK1xf14+qtxQJX+1CLcryFN3 g=; X-IronPort-AV: E=McAfee;i="5300,2777,5544"; a="16037302" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Mar 2009 23:18:46 -0800 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n267IjeA018002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Mar 2009 23:18:46 -0800 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n267IidS010440 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Mar 2009 23:18:45 -0800 (PST) Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub01.na.qualcomm.com ([10.46.93.121]) with mapi; Thu, 5 Mar 2009 23:18:44 -0800 From: "Edge, Stephen" To: "Winterbottom, James" , Brian Rosen , ECRIT Date: Thu, 5 Mar 2009 23:18:43 -0800 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwKeEe+gADZBfMABQDsYoAA26fDAAJM+RGAA0IcHYA== Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5374A271@NASANEXMB04.na.qualcomm.com> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net> <1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC53749E3B@NASANEXMB04.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 07:18:30 -0000 Hi James Thanks for the comments and sorry for the delay in responding. I was having= a hard time deciding whether and how to respond to your detailed comments = on this particular scenario. But this is rather a corner case from a 3GPP/3GPP2 operator perspective. Th= e vast majority of devices that access cellular networks should in the futu= re have 3GPP/3GPP2 IMS capability if they support VoIP and will thus likely= support the 3GPP/3GPP2 VoIP emergency solution. The case of a non-3GPP/3GP= P2 VoIP capable terminal accessing a VSP via a separate 3GPP/3GGP2 data car= d, modem or router should account for only a small fraction of all users. S= o 3GPP/3GPP2 has designed a solution for the normal case and has not yet ad= dressed this more abnormal one. To address the latter, some extension of th= e 3GPP/3GPP2 solution would be needed which I was attempting to arrive at b= elow - but not successfully since you do raise some good points. So to avoi= d more ado, I will concede the 3GPP/3GPP2 solution in its current form is n= ot suitable for this particular case and that Ecrit is more suitable. That, however, does not change our original contention because for the vast= majority of cases where the device is fully 3GPP/3GPP2 capable, the 3GPP/3= GPP2 VoIP emergency call solution should work fine whereas the Ecrit soluti= on suffers from all the disadvantages I mentioned before. In other words, supporting a more abnormal cellular user case (though I wou= ld agree not a trivial or invalid one) does not by itself turn a solution i= nto one suitable for the normal case. To become suitable for the normal cas= e, Ecrit too would need some extensions.=20 Kind Regards Stephen ________________________________________ From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 Sent: Sunday, March 01, 2009 9:04 PM To: Edge, Stephen; Brian Rosen; ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Hi Stephen, I have the distinct impression that we are never going to agree on this sub= ject, I would however like to point out some statements in text below that = are either misleading, or at least able to be interpreted in an alternative= manner than that which is provided. Please inline. Cheers James -----Original Message----- From: Edge, Stephen [mailto:sedge@qualcomm.com]=20 Sent: Friday, 27 February 2009 4:38 PM To: Winterbottom, James; Brian Rosen; ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Hi James Thanks for these further comments and for this oft repeated example - namel= y use of a 3GPP or 3GPP2 IP access network to reach a non-3GPP/3GPP2 VSP. T= his is always being thrown up as a reason that the 3GPP/3GPP2 solution cann= ot even fully address its own calling scenarios. It is however incomplete f= or the following reasons. [AJW] Let's agree to disagree on this point, it is a stated requirement in = TS23.167 (requirement 2 under section 4.1) that "Emergency services are ind= ependent from the IP-CAN with respect to the detection and routing of emerg= ency sessions. The emergency services shall be possible over at least a cel= lular access network, a fixed broadband access, I-WLAN access and a nomadic= access." I think, therefore that the solution is actually perfectly valid, the 3GPP = network is the IPCAN and it must allow independent detection and routing of= the emergency call. This requirement falls short of what some legislative = bodies are now considering the duty of the IPCAN to be, but it is still a g= ood start. First of all, I doubt that in this example either the Ecrit or 3GPP/3GPP2 s= olution would actually be possible now since neither are fully defined or f= ully implemented yet. Perhaps the VSP would provide some rudimentary E911 c= apability though probably not to the right PSAP. So the example is more hyp= othetical for future implementation in which case either solution might be = considered. [AJW] This is true for ECRIT in that LoST servers are not widely deployed a= nd publically available. However there are certainly NENA i2 deployments be= ing tested (not sure if they are actually live yet) where the=A0 originatin= g call includes a PIDF-LO in the body with the call, and the VSP in conjunc= tion with a VPC can route the emergency call to the correct PSAP. I fully e= xpect this to happen in cases where the Internet pipe is 3G so let's agree = that this is not hypothetical.=20 I am aware of two countries that are currently in the process or about to b= egin the process of legislating Internet access providers to make location = available for the purpose of routing emergency Internet calls. It will be i= nteresting to see what impact this legislation has on 3G data only devices = and associated network operators, presumably they will need to comply with = the Internet access provider legislation or stop providing, I think that it= is more likely that they will comply. Maybe you are aware that CDMA EvDO providers will be obligated by the FCC i= n the US to provide E911 capability assuming they are using licensed spectr= um. So in this example, and in a few more years when the 3GPP/3GPP2 solutio= n has been fully defined and implemented, the device in question would be a= ble to access the CDMA EvDO network, assuming it recognized the dialed emer= gency number and supported the 3GPP/3GPP2 solution, and make an IP based E9= 11 call directly via the serving EvDO network and not via its normal VSP. [AJW] Martin, Brian and possibly Richard have already described a serious f= law in this line of thinking. Namely that if I have a 3G Internet router, a= ny device behind that router has absolutely no visibility that it needs to = talk to a different VSP, the solution you are proposing almost suggests the= refore that the wireless router requires E-CSCF functionality in it and tha= t it can detect when a device in the home network is making an emergency ca= ll. This is very intrusive and certainly not backward compatible with the l= egacy devices already deployed.=20 =A0If it did not recognize the dialed emergency number or chose to use the = normal VSP anyway but still supported the 3GPP/3GPP2 solution, then the VSP= (e.g. based on receiving some access network related information from the = device in the SIP INVITE such as an EvDO cell ID and possibly based on subs= cription information if needed to imply 3GPP/3GPP2 capability for the devic= e) could send an error response back to the device (a SIP 380 response with= an emergency indication) that would cause the device to redirect the call = to the EvDO serving network. If the device did not support the 3GPP/3GPP2 s= olution, this would not work - but it seems unreasonable to treat non-suppo= rt of a solution as a weakness since almost every solution is susceptible t= o this. [AJW] Any device behind a home 3G router will have no visibility of the con= nected cell-id. Cell-ID is also of almost no use to anyone but the operator= of the access network, so including this in a call to a VSP that knows not= hing about EVDO, let along a specific access provider seems almost as big a= stretch as universal SUPL roaming. Why not simply make the location availa= ble to the caller using the mechanisms described in GeoPriv? Once this is d= one you have ECRIT, i2, or i3 and they will just work!=20 The above would not prevent the VSP from employing the Ecrit solution for o= ther types of access not supporting the 3GPP/3GPP2 solution and the increme= ntal cost to the VSP of supporting the 3GPP/3GPP2 solution (by means of the= 380 response) ought to be small. [AJW] The argument again is that device may not know about the underlying d= ependency between access and service and in a number of circumstances it ab= solutely will not know. The device might be able to learn the address of th= e local ES-Proxy, but if you are going to employ that solution why not just= employ an option to discover the LIS and the LoST server? The one case I have omitted but which I assume you may specifically have in= mind is where the device only supports IP data access and acts as a router= on behalf of another end device (e.g. a laptop). In that case, I think bot= h solutions would be severely handicapped. The Ecrit solution would have a = hard time obtaining location (unless the end device already had an accurate= location fix which it included in the SIP INVITE) and in routing to a PSTN= capable PSAP (particularly one in another country).=20 [AJW] Let's agree to disagree on this point. The 3GPP access behind the rou= ter is the Internet access provider and will likely have to provide locatio= n to the device. We have got pretty good LIS discovery mechanisms described= in Geopriv that address most major concerns, so actually I believe that EC= RIT and NENA i2 will work quite well. The 3GPP/3GPP2 solution - assuming the VSP supported it - might find locati= on easier (e.g. if the router or end device supported SUPL since that would= allow location for dispatch subsequent to call routing), but would find PS= TN PSAP routing just as hard. The parts of the Ecrit solution that appear unsuitable for cellular network= s I have already elaborated on - e.g. endpoint oriented location and routin= g, no explicit cellular location capability, no explicit support for PSAPs = accessed over the PSTN. [AJW] I think you will find that the WiMAX forum disagrees you with on a nu= mber of these points. And I have absolutely no doubt that with the 1.5 vers= ion of WiMAX I can support a fully mobile IP network using the ECRIT emerge= ncy calling architecture.=20 I am not sure that I understand what you mean by "no explicit cellular loca= tion capability", perhaps you can explain. Certainly using a protocol such = as HELD I can an awful lot and it all remains local so it doesn't require a= world in a database to support roaming such as is required in some protoco= ls that we will not mention here.;) =A0(the NENA i2 solution is not a global standard and seems impractical whe= re a PSAP is very remote from the VSP), no consideration for handover to or= from circuit mode access (which will remain the norm for many years) or ev= en to/from other IP access networks. [AJW] You are right that NENA i2 is not a global standard, but it is being = tailored for deployment in at least 3 countries at I am aware of, and forms= the basis for discussion in a number of others. I agree that circuit mode devices will be around for a many years to come, = I am less convinced that they will remain the norm, and with data only devi= ces increasing in popularity I see the need to hand-over in the way you des= cribe as unnecessary. Indeed I see it as a technological mismatch, equivale= nt to being able to hand-over my GSM call to a CDMA network; Without a spec= ial, purpose-built device I can't do it. Delivery of calls from VoIP to cir= cuit switched PSTN and vice versa is common place today from any number of = voice service providers and this is the mode of operation we should be disc= ussing. =A0 Kind Regards Stephen ---------------------------------------------------------------------------= --------------------- This=A0message=A0is=A0for=A0the=A0designated=A0recipient=A0only=A0and=A0may contain=A0privileged,=A0proprietary,=A0or=A0otherwise=A0private=A0informati= on.=A0=A0 If=A0you=A0have=A0received=A0it=A0in=A0error,=A0please=A0notify=A0the=A0sen= der immediately=A0and=A0delete=A0the=A0original.=A0=A0Any=A0unauthorized=A0use= =A0of this=A0email=A0is=A0prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] From bs7652@att.com Fri Mar 6 08:44:11 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B26813A657C for ; Fri, 6 Mar 2009 08:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U9Lur1ACVpl for ; Fri, 6 Mar 2009 08:44:09 -0800 (PST) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 6BBAB3A6784 for ; Fri, 6 Mar 2009 08:44:08 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-3.tower-146.messagelabs.com!1236357876!2971180!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 9607 invoked from network); 6 Mar 2009 16:44:37 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-3.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 6 Mar 2009 16:44:37 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n26GiZTs031188; Fri, 6 Mar 2009 11:44:36 -0500 Received: from 01GAF5142010621.AD.BLS.COM (01GAF5142010621.ad.bls.com [139.76.131.79]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id n26GiUTO031127; Fri, 6 Mar 2009 11:44:31 -0500 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 6 Mar 2009 11:44:30 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 6 Mar 2009 11:44:31 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Mar 2009 11:44:27 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0D5312D9@crexc41p> In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5374A196@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmY6xMaVsPKQOa6Rj2puYM6nfd6RAACFkpAARDTCVAATYabIA== References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com> <64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net> <7582BC68E4994F4ABF0BD4723975C3FA0D39534E@crexc41p> <1288E74A73964940B132A0B9EA8D8ABC5374A196@NASANEXMB04.na.qualcomm.com> From: "Stark, Barbara" To: "Edge, Stephen" , X-OriginalArrivalTime: 06 Mar 2009 16:44:31.0004 (UTC) FILETIME=[D2689DC0:01C99E7A] Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 16:44:11 -0000 Personally, I consider a "3GPP access network" and cellular networks in general to be "closed" networks. That is, 3GPP is able to define the requirements of a "3GPP access network", and the devices that connect to 3GPP access networks. 3GPP is doing a wonderful job at providing these requirements, together with SDOs like OMA that provide the actual SUPL and similar protocol standards.=20 I'm not worried about 3GPP access networks, and I'm not looking to the IETF to provide an end-to-end architecture for how they work and what devices need to do that connect to them. It is 3GPP's job to define requirements for a 3GPP access network, and not IETF's job. My interest in phonebcp has absolutely zero to do with 3GPP access networks and the devices that connect to them. My interest is that we need to have an architecture defined for "open" access networks, such that if regulators ever decide that they want to do regulation to achieve the goals of NENA i3 for all of these SIP calls riding over the Internet (and going over DSL access networks), there would be things written that would be acceptable solutions that would meet the objectives, without causing extraordinary pain to *wireline* service providers or consumers. Given that this is what I want phonebcp for, and given that SUPL has zero deployment or real applicability in DSL networks, statements about SUPL support in the context of phonebcp are meaningless and irrelevant to me. They're like a "don't care" or "no op" statement. SUPL is not an appropriate solution for the devices I want phonebcp to deal with. SUPL is completely appropriate for 3GPP devices, and, thankfully, I have 3GPP to provide the 3GPP architecture and requirements. I don't need or want the IETF to provide a 3GPP architecture for me.=20 However, I do recognize that if a 3GPP handset with a data connection were able to get its location via SUPL or directly from GPS, that it could have a VPN set up to an Internet Voice Service Provider, and the access network would have no ability to control what happened inside this VPN. If there were a LoST server that the handset could find and get emergency dialing and routing info, it could provide its location to that VSP and mark calls as emergency calls and provide appropriate routing info. IETF has provided the tools to make this work, and sufficient explanation in phonebcp so that I understand how to make this work, if I had to. Therefore, I am sufficiently satisfied that the IETF docs would not need be overhauled if it became necessary to support this scenario. That doesn't mean that I need or want the IETF to specifically describe how to do this scenario. In fact, I'd really rather they didn't. With that said, if I look at phonebcp from an unemotional and objective stand-point and ask "Is there anything, technically, that would prevent me from doing phonebcp in a cellular environment?", the answer is no. If I, individually, had gobs of money to spend on creating my very own *non*-3GPP-compliant access network that used GSM as an underlying access technology, on my private Caribbean island (since I have gobs of money, I think I could swing the island), there is absolutely no technical reason why I couldn't have that network support phonebcp. And pay for my own developers to create the handsets to connect to it.=20 That is, there is absolutely no technical reason why phonebcp could not be used for a device with a GSM radio. Therefore, to say that such a restriction exists would be inaccurate. The reason that phonebcp *won't* be applied to the GSM side of such devices, is because nobody *intends* to apply phonebcp to them. It is *not* IETF's job to say that a BCP doesn't apply to certain entities or devices because those entities and manufacturers don't want it to apply. That's just plain ludicrous. If we in the industry don't want it to apply, we don't apply it! It's incredibly simple not to implement an IETF RFC. I can not implement IETF RFCs in my sleep, with both hands tied behind my back. In fact, there are lots and lots of IETF RFCs that I'm not implementing, right now, as I type. There are only two reasons I could think of for someone trying to force such a statement ("this doesn't apply to 3GPP access networks because people involved in 3GPP access networks don't want it to apply" -- we already have a working solution -- and by the way I think you need to acknowledge that solution) into an IETF document. Either they're really worried that someone is a complete moron and is going to think that just because the IETF wrote this that it does apply to 3GPP networks, or they want to shove it in the face of the IETF people that, "nah, nah, you can't make me do it and I want to have you put it in writing that you can't make me; ooh, I pwned you!" So which is it. Do you think we're all morons, or are you trying to pwn these guys? I feel like I'm watching a Dr. Phil episode. One side says "I want you to admit that it's technically possible to use this on cell networks" and the other side says "No, I won't admit that, but I want you to admit that you can't make me implement this, and to acknowledge that I already have a solution" so the first side says "No way, I won't admit that". And the question Dr. Phil would ask is "Do you want to be right, or do you want to be happy?" You're actually both right. There, does that make you happy? Anyway, I'm done with this debate. You won't hear from me anymore on it. Barbara -----Original Message----- From: Edge, Stephen [mailto:sedge@qualcomm.com]=20 Sent: Wednesday, March 04, 2009 9:20 PM To: Stark, Barbara; br@brianrosen.net Cc: ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Barbara and others Thanks for the comments. When I look at the PhoneBCP I see that both HELD and DHCP are mandatory for the device whereas at least one of these is mandatory for the AN. While I can also see that SUPL is not ruled out (though it is not mentioned or referenced), it appears to have been displaced by the HELD and DHCP requirements. On the other hand, many cellular networks have already deployed or are in the process of deploying SUPL and I am not aware of any that have deployed an accurate location capability using HELD or DHCP. So I would like to know how you see the current requirements as being suitable - after all, they imply at the very least additional development and deployment on the part of network and device vendors and network operators, whereas if SUPL was one of the defined LCPs, that additional development and deployment might be mostly avoided. This question would not be applicable with some additional scope limitation and so I had not previously raised it. But it is certainly applicable in the context of the global scope that is being claimed by some responders. Kind Regards Stephen -----Original Message----- From: Stark, Barbara [mailto:bs7652@att.com] Sent: Friday, February 27, 2009 8:28 AM To: br@brianrosen.net; Edge, Stephen Cc: ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Thank you Brian. This is well said [except you left out the fact that ecrit also allows for devices to get their location through other mechanisms, such as GPS, SUPL, or other methods, and doesn't insist that the location be configured through DHCP or HELD]. I agree 100% that additional qualifications are unnecessary. Service providers, vendors, national bodies dealing with emergency services, and regulators aren't stupid. Please trust us to figure out for ourselves when/where/how to apply a "standard". There is no need to try to artificially limit or define scope, or to state the obvious (e.g., the architecture applies where it applies, and doesn't apply where it doesn't apply). We understand the role and scope of the IETF, and the role and scope of 3GPP and 3GPP2. And all the other SDOs (and national bodies and regulatory agencies). SDOs need to offer architectures that apply within the area of applicability for that SDO, and are useful to potential implementers, and leave it to the SPs, national bodies and regulators to decide which architectures and standards to use or to mandate within the scope of their network or jurisdiction. Again, we aren't stupid. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of br@brianrosen.net Sent: Friday, February 27, 2009 9:53 AM To: Edge, Stephen Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft Stephen Like any standards organization, the IETF restricts it's scope. Generally, the scope is "the Internet", although we very often describe solutions that are explicitly designed for private IP networks as well as the Internet. We don't write standards for circuit switched networks, and it should be no surprise that the ecrit solution does not cater to CS solutions. Nevertheless, we often try to make sure that our solutions harmonize reasonably well with existing solutions. Indeed, the ecrit solution clains global applicability to the Internet in general, and most private IP networks that can be interconnected to the Internet or to other IP networks via gateways. Looking at your list of problem areas: > - access to PSTN capable PSAPs This is out of scope for IETF. NENA has active work on this subject. It seems straightforward to interwork ecrit compatible devices and networks to existing CS connected PSAPs. As you know, CS interconnects are very nation-specific, so the NENA work may not have general applicability. However, it shows that it is possible to interwork. The NENA i2 work is also designed to take ecrit compatible devices and VSP networks, and interwork them to the existing network. The VSP would direct the call to the VPC, which would provide the services it does now, using the device provided location for routing. This is important for smooth transition from existing PSAPs and VSPs to "next generation" PSAPs and VSPs. > - handover between different IP access networks including different > types of access network In the ecrit solution, the access network the call is initiated on provides all the facilities needed for the device to initiate an emergency call. The call starts traversing it's normal call path, and eventually routes to the ESRP. Handoffs between IP networks should be transparent to this process, although we probably haven't done all the work we need to do for handoffs where the IP address as seen by the terminating network changes. This would generally be true of all current SIP based work. > - handover to/from circuit mode networks This would be out of scope for IETF. It's as applicable to a simple SIP call as it is a SIP emergency call, and there are no statements in any SIP documents on that subject. > - location for cellular access (and the requirement to support LCPs that > will be useless for cellular access) Location for cellular access networks has been considered carefully. Since cellular is a mobile network, the access network would pass the device a Location-By-Reference URI, using either DHCP or HELD. Either protocol is suitable for cellular networks. As we have pointed out several times, cellular networks support raw data packet services upon which many different kinds of networks can be constructed. My usual example is a large recreational vehicle traveling down a road with a cellular data card plugged into a router to which a wired (Ethernet) phone is connected. That phone must be able to make an emergency call, and it will get location from DHCP or HELD (or LLDP-MED). It is not aware of the cellular network, and doesn't know any cellular specific protocols. Cellular networks will have to support IETF location configuration protocols unless they actively prohibit examples like this, or they implement interworking between cellular-specific location protocols and DHCP or HELD in the data card. The ecrit standards permit proxy insertion of location, but, as above, we don't think that works in all cases. > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) The "load" of using DHCP or HELD to get location and querying LoST is pretty modest. The standards permit proxies to do this if the devices don't. As above, interwork functions to CS connected PSAPs is very feasible, and as above, cellular networks will have to support access to local LoST servers for devices that are connected to cellular networks and are ecrit compliant. > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls This is covered in the standards. None of the processes are dependent on authentication, although where it is possible, it's desirable so as to minimize fraudulent emergency calls Mechanisms for specific network authentication mechanisms are out of scope, and, like SIP basic calling, are not usually mentioned in IETF documents. Stephen, we've tried pretty hard to make sure this works for 3G/4G mobile networks. It's true that it doesn't do it the way 3GPP currently thinks it ought to work, but we claim they haven't thought through all the issues. While it would work, there are opportunities for improvement. We would be willing to do that if we could get the cooperation of 3GPP, which we have tried, and failed, to do. So, I think the documents do not need any qualification statements. Brian > Martin > > The 3GPP/3GPP2 solution has a defined restricted applicability (mainly to > 3GPP/3GPP2 access networks where the serving network also acts as the VSP) > and the specifications for it cover in detail all possible scenarios > consistent with these restrictions so far as we are aware. > > The Ecrit solution seems to claim global applicability to all types of IP > access (and the more that is said about this from Ecrit participants the > more this gets emphasized) but does not cover in detail all possible > scenarios (in some cases does not cover in any detail) which means that at > best the solution is incomplete and at worst intrinsically inapplicable to > some unstated set of scenarios. > > The missing, incomplete and problematic cases include the following: > > - access to PSTN capable PSAPs > - handover between different IP access networks including different > types of access network > - handover to/from circuit mode networks > - location for cellular access (and the requirement to support LCPs that > will be useless for cellular access) > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls > > Stating that some of these cases are out of scope or referencing an > incomplete and possibly questionable specification from some other > national SDO will not help the user who encounters such problems. But it > would certainly help network operators and implementers to acknowledge > their existence in one form or another because that would allow better > planning of deployments and would help focus attention on finding > solutions (whether in IETF or elsewhere) for the missing cases. > > Please note that despite these drawbacks, I will acknowledge that Ecrit > does have a valuable solution that covers many scenarios not covered by > 3GPP/3GPP2. It would be the delineation of these supported scenarios (or > equivalently unsupported scenarios) in some applicability statement that > would be particularly useful right now. > > Kind Regards > > Stephen > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Thursday, February 26, 2009 9:45 PM > To: Edge, Stephen; Richard Barnes > Cc: ECRIT > Subject: RE: [Ecrit] Comments on Framework Draft > > There's benefit in knowing the limitations of a framework, and every > architecture makes certain assumptions. Let's examine them though... > > The IETF might occasionally make the assumption that the standards it > develops are for Internet devices. That assumption probably need not be > stated explicitly. > > The ECRIT architecture relies on implementations of the protocols that it > references. That is not extraordinary. A reliance on implementation of > these protocols by endpoints, routing intermediaries and PSAPs should not > need to be explained. > > So the assumptions are: > - the Internet > - solutions are implemented and deployed > - the end device is a key component > > Only that last element is particularly novel ... or not that much really. > It's a design choice. Unless you were thinking of trunking the voice > elsewhere. > > Of course, you're suggesting that the design choice was made in ignorance > of all the constraints. You're suggesting that - as a result - the choice > is flawed and the solution is not going to work for cellular services. We > disagree. The solution is a basis for emergency calling in _any_ IP > network. > > Cheers, > Martin > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Edge, Stephen >> Sent: Friday, 27 February 2009 3:30 PM >> To: Richard Barnes >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Richard >> >> Thanks for the comments. Your statement below that "SIP emergency >> calling works if all parties behave as specified in these (IETF Ecrit) >> documents" to some degree highlights the problems we are raising. The >> documents do contain a number of implicit and explicit restrictions - >> like IP capable PSAPs, global IP access (no islands of circuit mode >> access for example), universal support of this solution by all access >> providers and VSPs (not much good if some opt for another solution) and >> end system oriented location and routing capability - which together >> make them unsuitable (we believe) for cellular wireless networks. If >> these restrictions and assumptions were all made explicit upfront, it >> would to a large degree (and possibly completely) address our concerns. >> >> You are right in assuming another set of specifications for the 3GPP >> and 3GPP2 solution. The applicability of this solution is explicitly >> defined in TS 23.167 (or more exactly in an already agreed CR in >> contribution S2-090752 which will become part of 23.167 in a few more >> weeks) to cover the following access types: GPRS (UTRAN WCDMA), I-WLAN, >> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN >> (LTE). So there is a restriction and arbitrary internet access is not >> covered (yet) as I have stated before. >> >> Kind Regards >> >> Stephen >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Wednesday, February 25, 2009 6:30 PM >> To: Edge, Stephen >> Cc: Brian Rosen; 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Stephen, >> >> I'm a little confused by the scope of what you're asking. The >> framework >> and phonebcp documents exist in order to describe the ECRIT solution: >> They say, in effect, "SIP emergency calling works if all parties behave >> as specified in these documents." >> >> As I understand what you're saying (and I'm by no means an expert in >> 3GPP), 3GPP specifies that one or more elements of this system behave >> differently. This simply means that 3GPP networks aren't complying >> with >> these specs. Just like there's no disclaimer in RFC 791 (IPv4) that >> says "this doesn't work on X.25 networks", it's not clear to me that an >> analogous disclaimer is called for here. >> >> I presume there are similar documents describing how emergency calling >> works in 3GPP networks. Do they include notes saying that the 3GPP >> solution doesn't work in the broader Internet? >> >> --Richard >> >> >> >> >> >> Edge, Stephen wrote: >> > Brian >> > >> > First of all apologies for the likely lateness of this reply - I >> actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest but >> it seems unlikely that my VPN, Outlook server and WiFi access >> capability will cooperate together to get it sent until I return to the >> office mid-next week. >> > >> > Anyhow thanks for your comments. There have actually been a number of >> conference calls between IETF and 3GPP participants over the last >> couple of years at which common features like support of IP emergency >> calls were discussed and these could have been good forum for >> participants on either side to have raised the kinds of issues you >> elaborate on below. Given that seems not so far to have happened, it >> could still be possible in future such calls. >> > >> > But the issues we are raising are not directly to do with further >> aligning the 2 solutions or with the lack of this in the past. We are >> simply pointing out that the solutions are currently different and that >> from a cellular wireless perspective, the Ecrit solution is not seen as >> suitable in all respects (for support of IP emergency calls originating >> from such access types). That is not just our point of view. 3GPP2 sent >> a liaison to Ecrit some months ago pointing out the same issues. >> > >> > So we are proposing that the Ecrit framework and phoneBCP spec.s >> include a statement acknowledging this - e.g. by referencing the >> alternative 3GPP/3GPP2 solution and indicating the IP access types for >> which the Ecrit solution will work without limitation (or equivalently >> the access types where limitations are not ruled out). >> > >> > We are not proposing further modification and extension of the Ecrit >> solution - just pointing out that this would be needed (as with the >> 3GPP/3GPP2 solution) to fully cover all types of access. >> > >> > Kind Regards >> > >> > Stephen >> > -----Original Message----- >> > From: Brian Rosen [mailto:br@brianrosen.net] >> > Sent: Wednesday, February 18, 2009 8:07 PM >> > To: Edge, Stephen; 'ECRIT' >> > Subject: RE: [Ecrit] Comments on Framework Draft >> > >> > I have bit my tongue on this one for a long time. >> > >> > Stephen, with respect, please go talk to 3GPP management and ask them >> why >> > there has been no participation in the ecrit effort despite multiple >> YEARS >> > of begging them to get involved. To put it frankly, 3GPP is quite >> willing >> > to bully IETF into doing its work on its schedule, but cannot be >> bothered to >> > get work done it knows it will eventually have to do when the IETF >> asks it >> > to do so. >> > >> > 3GPP understands the mess that is being created by not participating. >> They >> > know full well that when they finally get around to dealing with PS >> > terminated emergency calls, that there will be a lot of resistance to >> > changing fully specified and implemented standards to more closely >> align >> > with 3GPP standards. I expect you will have several interworking >> functions >> > to define and build. >> > >> > So, politely, please go away, we're finishing work we dearly wanted >> you all >> > to be involved with for years, but you refused to do anything. It's >> too >> > late for this rev. >> > >> > Now, having said that, there are quite a few people who have >> participated in >> > the IETF work who are IMS aware and I believe that despite your >> fears, >> > everything you need is in the specs. The mechanisms we have defined >> provide >> > the ability for the network to insert location, recognize and mark >> emergency >> > calls, and route on behalf of endpoints. An E-CSCF could quite >> > straightforwardly provide a SIP call towards an ecrit compatible >> PSAP. The >> > only not-quite-nice interwork would be from SUPL to HELD (or SIP), >> but it's >> > pretty easy to do that. I'll also note that we have tried to get OMA >> and >> > IETF to cooperate on location protocols, but we have been >> spectacularly >> > unsuccessful at that effort also. >> > >> > Brian >> > >> > >> > >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf >> >> Of Edge, Stephen >> >> Sent: Thursday, February 05, 2009 2:50 AM >> >> To: 'ECRIT' >> >> Subject: [Ecrit] Comments on Framework Draft >> >> >> >> All >> >> >> >> draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative >> >> description of how terminals and networks should support emergency >> >> calls made over IP capable facilities to IP capable PSAPs. It >> appears >> >> intended to cover all types of access network - including fixed >> line, >> >> WiFi and cellular (e.g. examples involving each can be found >> throughout >> >> the draft). >> >> >> >> When we evaluated this with respect to support of wireless cellular >> >> access and WiFi access associated with a cellular operator (e.g. >> WLAN >> >> or Femto cells integrated into a cellular network), we found that >> >> certain portions of the draft exhibited one or more of the following >> >> characteristics: >> >> >> >> (A) Inconsistent with already standardized wireless solutions >> >> >> >> (B) Inconsistent with essential wireless requirements and >> >> conventions >> >> >> >> (C) Already part of wireless standards or potentially part of >> >> future standards >> >> >> >> (A) refers to all portions of the draft framework that differ from >> the >> >> requirements and procedures currently standardized for wireless >> >> emergency access by 3GPP, 3GPP2 and OMA. This is a plain difference >> of >> >> solution and could be resolved through support of both solutions by >> >> terminals (with each solution being used according to the type of >> >> access network and VSP) or could be resolved by supporting only one >> >> solution and accessing only the types of network supporting that >> >> solution. To acknowledge this category, the framework document could >> >> reference the applicable wireless standards and point out that these >> >> are valid alternatives for wireless cellular based access. >> >> >> >> (B) refers to portions of the draft that would be unsuitable for >> >> wireless networks even if no alternative solution existed together >> with >> >> other portions missing from the draft that would be needed to fully >> >> support wireless networks. Examples of the former include: (a) >> emphasis >> >> on endpoint derivation of location, performance of Lost query and >> >> receipt of local dial strings; (b) restriction of LCPs to protocols >> >> that require terminal initiation (not allowing for network >> initiation >> >> as far as we can tell) and that include two LCPs (DHCP and LLDP) >> that >> >> are not applicable to (not defined for) cellular access; and (c) the >> >> requirement that a terminal or at least a LIS will update the PSAP >> >> whenever location changes. (a) is impractical due to network and >> >> terminal loading consequences and failure to support non-IP capable >> >> PSAPs; (b) makes location verification and updated location >> provision >> >> to PSAPs difficult or impossible; while (c) is also incompatible >> with >> >> support of existing non-IP capable PSAPs besides increasing terminal >> >> load and possibly interfering with optimum maintenance of the RF >> >> connection (e.g. if a terminal has to tune away from the serving >> base >> >> station or WLAN periodically to make location measurements). >> Examples >> >> of the latter include (d) absence of support for access to non-IP >> >> capable PSAPs as already mentioned (e.g. to support E911 phase 2 in >> the >> >> US); (e) no support for handover from the IP to the circuit domain >> when >> >> a terminal loses (e.g. moves out of) RF coverage in the IP domain; >> and >> >> (f) no allowance for limited access modes wherein a terminal may >> access >> >> a network only to place an emergency call with ensuing restrictions >> on >> >> (for example) location acquisition, PSAP callback and caller >> >> verification and identification to the PSAP. To resolve this >> category >> >> either significant changes to the framework document could be made >> or a >> >> disclaimer/applicability statement could be added stating that >> support >> >> of cellular wireless networks and their associated WLAN and Femto >> >> access points is not covered. >> >> >> >> Category (C) comprises concepts and capabilities in the draft that >> are >> >> either already part of the standardized solution for wireless >> networks >> >> or that might be added at a later time. Examples of the former >> include >> >> LoST, SIP location conveyance, general use of SIP, location for >> routing >> >> versus for dispatch, cellular positioning methods. Examples of the >> >> latter include use of location references and dereferencing and >> >> possible interworking between the current wireless network solutions >> >> (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. >> The >> >> presence of this category could be acknowledged by following the >> >> disclaimer for (B) with a statement that certain portions of the >> >> solution are expected to be incorporated into wireless networks now >> >> and/or in the future. >> >> >> >> We hope that these comments will be seen to be a useful addition to >> >> this review in the sense of enabling a more precise scoping for the >> >> framework document and we are willing to assist in providing wording >> >> for any disclaimer/applicability statement that the Ecrit working >> group >> >> may now deem fit to include. >> >> >> >> Kind Regards >> >> >> >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs >> (Qualcomm >> >> 3GPP2 TSG-X and TSG-C participant) >> >> >> >> PS this being sent on 2/4/09 at 11:50pm PST >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www.ietf.org/mailman/listinfo/ecrit >> > >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------ ------------------------ > 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://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.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 From MILANPA@nortel.com Fri Mar 6 09:36:30 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98B6E3A6919 for ; Fri, 6 Mar 2009 09:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pd935oXIdZcI for ; Fri, 6 Mar 2009 09:36:29 -0800 (PST) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 696213A68F3 for ; Fri, 6 Mar 2009 09:36:29 -0800 (PST) Received: from zharhxm1.corp.nortel.com (zharhxm1.corp.nortel.com [47.165.48.149]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n26HavA02127; Fri, 6 Mar 2009 17:36:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Mar 2009 17:36:53 -0000 Message-ID: <0913B6CD18F370498CD65864CF254E9008DA24B2@zharhxm1.corp.nortel.com> In-Reply-To: <499D6530.9040208@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt thread-index: AcmVI4VlMhaCNC6FTY+cdpWUDS3YwwJWtBZw References: <499D6530.9040208@ericsson.com> From: "Milan Patel" To: "Gonzalo Camarillo" , Subject: Re: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 17:36:30 -0000 Folks, In response to Gonzalo's comment on backwards compatibility, I propose a subclause "4.3 Backwards compatibility issues" as follows: ------------------------------------------------------------------------ ---------------------------------- 4.3 Backwards compatibility issues The backwards compatibility scenario considered in this document is where the registrar does not support the "sos" URI parameter. In this case, if the registrar receives a REGISTER request that includes the "sos" URI parameter in the Contact header, the registrar MUST proceed with registration procedures and silently ignore the URI-parameter in accordance with RFC 3261. This ensures the user is registered and thus can successfully initiate an emergency call. The drawback of proceeding with registration is if the address-of-record is barred or has roaming restrictions applied, then these restrictions will not be lifted and thus registration will be unsuccessful. This may limit the UAC's ability to successfully place an emergency call. If registration is successful, the registrar shall return a 200 (OK) response to the UAC and does not include the "sos" URI parameter in the Contact header. The UAC is aware of its registered contact address and address-of-record, however, cannot distinguish between this registration and a non-emergency registration. ------------------------------------------------------------------------ -------------------------------------- Comments/feedback/suggestions for improvement are appreciated. I will address Gonzalo's other comments in version -04 of the draft as well.=20 Best regards, Milan Milan Patel Carrier Networks Core Standards Nortel milanpa@nortel.com Telephone +44 162 843 2381 / ESN 560 2381 Mobile +44 774 053 9261 / ESN 748 9261 For the Companies listed below, The Institute of Chartered Accountants in England and Wales authorises A R Bloom, S Harris and C Hill to act as Insolvency Practitioners under section 390(2)(a) of the Insolvency Act 1986 and the Association of Chartered Certified Accountants authorises A M Hudson to act as an Insolvency Practitioner under section 390(2)(a) of the Insolvency Act 1986. The affairs, business and property of the Companies are being managed by the Joint Administrators, A R Bloom, S Harris, AM Hudson and C Hill who act as agents of the Companies only and without personal liability. The Companies are Nortel Networks UK Limited; Nortel Networks SA; Nortel GmbH; Nortel Networks France SAS; Nortel Networks NV; Nortel Networks SpA; Nortel Networks BV; Nortel Networks Polska SP Zoo; Nortel Networks Hispania SA; Nortel Networks (Austria) GmbH; Nortel Networks sro; Nortel Networks Engineering Service Kft; Nortel Networks Portugal SA; Nortel Networks Slovensko sro; Nortel Networks Oy; Nortel Networks Romania SRL; Nortel Networks AB; Nortel Networks International Finance & Holding BV -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Gonzalo Camarillo Sent: 19 February 2009 13:57 To: ecrit@ietf.org Subject: [Ecrit] Expert review of draft-patel-ecrit-sos-parameter-03.txt Folks, I have been asked to perform an expert review of the following draft: http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-03.txt The approach taken by the draft seems OK in general. I have a few comments though: The requirement in Section 3 is too specific because it already assumes that the solution will be an indication in the SIP header fields. The requirement does not need to make that assumption. I would remove "by providing an appropriate indication in the SIP header fields". In Section 5, the reference to RFC 2234 should be replaced with one to RFC 5234. Also in Section 5, the formal syntax should be rewritten so that it is compatible with the ABNF in RFC 3261. RFC 3261 already defines uri-parameter as follows: uri-parameter =3D transport-param / user-param / method-param / ttl-param / maddr-param / lr-param / other-param other-param =3D pname [ "=3D" pvalue ] pname =3D 1*paramchar pvalue =3D 1*paramchar This document should simply define a new value for pname. The document does not talk about backwards compatibility. What happens if the registrar does not understand the 'sos' parameter? Will it do the right thing? Will the UAC detect the failure? Is there a need to define an option tag?... the document should address these points. Cheers, Gonzalo _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Fri Mar 6 10:03:33 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E0E73A67F3 for ; Fri, 6 Mar 2009 10:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gz97CqisOyyo for ; Fri, 6 Mar 2009 10:03:31 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 19CA93A6C68 for ; Fri, 6 Mar 2009 10:03:31 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LfbUm-0000fq-MX; Fri, 06 Mar 2009 08:57:53 -0600 From: "Brian Rosen" To: "'Edge, Stephen'" , "'Winterbottom, James'" , "'ECRIT'" References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net> <1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC53749E3B@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5374A271@NASANEXMB04.na.qualcomm.com> In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5374A271@NASANEXMB04.na.qualcomm.com> Date: Fri, 6 Mar 2009 09:58:06 -0500 Message-ID: <048501c99e6b$f6f5e850$e4e1b8f0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwKeEe+gADZBfMABQDsYoAA26fDAAJM+RGAA0IcHYAAQamdg Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 18:03:33 -0000 Stephen I admire your willingness to keep pushing, despite lack of progress. I think we're pretty close to the "agree to disagree" stage, but let me = sum up where I think we are and could go 1. There is a fundamental difference between the ecrit architecture and = 3GPP architecture when applied to mobile networks, and that fundamental difference is edge intelligence vs network intelligence. This is a very = old argument, with lots of history, and we're not likely to actually = converge on one way or the other in the large sense. =20 We are both prisoners of our past. Your architecture for emergency = calls looks a whole lot like the current emergency call architecture in mobile networks today, and it works, within the limits it was designed for = anyway. Our bias towards edge intelligence is very old, and tends to always = work. We're constantly hearing that limits on compute power and bandwidth are arguments for more network intelligence, but decades of experience = suggests that isn't a very good argument, albeit simplicity is always a virtue = and compression is often helpful. Network intelligence tends to be an = business argument instead of a technical argument. 2. The IETF architecture would work in an IMS mobile network. It would = be straightforward to deploy, for example, HELD in the network, and have = the endpoints follow the current text in -phonebcp. Of course, 3GPP would = have to do work to deal with specifics like unitialized devices, handoffs, = etc. Gateways could be deployed to convert from PS to CS for CS connected = PSAPs. I even suspect you could make handoffs back and forth between CS and PS work, although the solution would be 3GPP specific. 3. The 3GPP architecture doesn't work where there is no relationship = between the access network and the calling network including the case where the = only service the 3GPP network provides is raw packet access. It doesn't = really work for fixed IMS networks that permit arbitrary nomadic access. =20 4. Although the IETF documents are biased towards edge intelligence, the specifications actually permit the network to determine a call is an emergency call, obtain the location from the network, add it to the signaling, route the call and send it to a PSAP. =20 5. There is admittedly some conflict in our docs on what we call = "Location Configuration Protocols". I would like us to keep in mind that an LCP = is "give me MY location" and not "give me HIS location". Specifically, = where you have a case in which the access network can completely specify the endpoints, and refuse service if the endpoint doesn't meet its = standards, then broad insistence on DHCP and HELD in all endpoints doesn't make = sense: the network can insist on any LCP, and all devices would have to = implement it. We used to have some text that said that, but it was removed = because of the data card in the router problem. There is another solution to that problem: interwork the network's LCP to DHCP/HELD, but consensus was to = just take the exception to the list of LCPs out. I will point out that the = data card in the router problem pretty much obviates the ability of the = network to insert location: it could with services it provides, but it also has = to provide one of the standard LCPs for the router to pass through. It = seems really silly to deploy two solutions when one works always and the other works only mostly. It's not beyond the realm of possibility to have = SUPL added to the list of protocols. There are issues with that, but they = could be addressed. However, see below. The latest set of changes to = -phonebcp on the list of protocols was explicitly designed to include SUPL support in devices connected to networks that support it. It was the same change = that removed LLDP-MED from the all-devices-support list. 7. Emergency calling solutions are filled with complexity to handle = cases that rarely occur. It's a fact of life: emergency calling ALWAYS has to work. Of course we strive to keep simple things simple and complex = things possible, but rare events driving architecture in emergency calling is nothing new. Finally, we've said before, and I believe the offer stands (although I'm = not empowered to definitively say it): The IETF is desirous of making 3GPP and IETF standards for emergency = calling more harmonious with each other. To do so, it is willing to negotiate, = and in some circumstances to change its standards, provided that 3GPP is = willing to do the same. The areas we would like to discuss include how location = is obtained for routing and delivered to a PSAP, what the representation = for location (geo and civic, value and reference) is, how emergency calls = are recognized and routed and the specifics of the SIP signaling to = accomplish the above. The IETF and 3GPP have strived to not have conflicts in each other's standards, and emergency calling should not be different. =20 3GPP has explicitly decided NOT to enter such discussions and = negotiations at this time. In the absence of official discussions and negotiations, I think our documents are complete, and accurate. There are no protocol police, and = the IETF is well aware that many vendors and network operators openly ignore parts of its standards. =20 Brian -----Original Message----- From: Edge, Stephen [mailto:sedge@qualcomm.com]=20 Sent: Friday, March 06, 2009 2:19 AM To: Winterbottom, James; Brian Rosen; ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Hi James Thanks for the comments and sorry for the delay in responding. I was = having a hard time deciding whether and how to respond to your detailed = comments on this particular scenario. But this is rather a corner case from a 3GPP/3GPP2 operator perspective. = The vast majority of devices that access cellular networks should in the = future have 3GPP/3GPP2 IMS capability if they support VoIP and will thus likely support the 3GPP/3GPP2 VoIP emergency solution. The case of a = non-3GPP/3GPP2 VoIP capable terminal accessing a VSP via a separate 3GPP/3GGP2 data = card, modem or router should account for only a small fraction of all users. = So 3GPP/3GPP2 has designed a solution for the normal case and has not yet addressed this more abnormal one. To address the latter, some extension = of the 3GPP/3GPP2 solution would be needed which I was attempting to arrive = at below - but not successfully since you do raise some good points. So to avoid more ado, I will concede the 3GPP/3GPP2 solution in its current = form is not suitable for this particular case and that Ecrit is more = suitable. That, however, does not change our original contention because for the = vast majority of cases where the device is fully 3GPP/3GPP2 capable, the 3GPP/3GPP2 VoIP emergency call solution should work fine whereas the = Ecrit solution suffers from all the disadvantages I mentioned before. In other words, supporting a more abnormal cellular user case (though I would agree not a trivial or invalid one) does not by itself turn a = solution into one suitable for the normal case. To become suitable for the normal case, Ecrit too would need some extensions.=20 Kind Regards Stephen ________________________________________ From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 Sent: Sunday, March 01, 2009 9:04 PM To: Edge, Stephen; Brian Rosen; ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Hi Stephen, I have the distinct impression that we are never going to agree on this subject, I would however like to point out some statements in text below that are either misleading, or at least able to be interpreted in an alternative manner than that which is provided. Please inline. Cheers James -----Original Message----- From: Edge, Stephen [mailto:sedge@qualcomm.com]=20 Sent: Friday, 27 February 2009 4:38 PM To: Winterbottom, James; Brian Rosen; ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Hi James Thanks for these further comments and for this oft repeated example - = namely use of a 3GPP or 3GPP2 IP access network to reach a non-3GPP/3GPP2 VSP. = This is always being thrown up as a reason that the 3GPP/3GPP2 solution = cannot even fully address its own calling scenarios. It is however incomplete = for the following reasons. [AJW] Let's agree to disagree on this point, it is a stated requirement = in TS23.167 (requirement 2 under section 4.1) that "Emergency services are independent from the IP-CAN with respect to the detection and routing of emergency sessions. The emergency services shall be possible over at = least a cellular access network, a fixed broadband access, I-WLAN access and a nomadic access." I think, therefore that the solution is actually perfectly valid, the = 3GPP network is the IPCAN and it must allow independent detection and routing = of the emergency call. This requirement falls short of what some = legislative bodies are now considering the duty of the IPCAN to be, but it is still = a good start. First of all, I doubt that in this example either the Ecrit or = 3GPP/3GPP2 solution would actually be possible now since neither are fully defined = or fully implemented yet. Perhaps the VSP would provide some rudimentary = E911 capability though probably not to the right PSAP. So the example is more hypothetical for future implementation in which case either solution = might be considered. [AJW] This is true for ECRIT in that LoST servers are not widely = deployed and publically available. However there are certainly NENA i2 = deployments being tested (not sure if they are actually live yet) where the=A0 = originating call includes a PIDF-LO in the body with the call, and the VSP in conjunction with a VPC can route the emergency call to the correct PSAP. = I fully expect this to happen in cases where the Internet pipe is 3G so = let's agree that this is not hypothetical.=20 I am aware of two countries that are currently in the process or about = to begin the process of legislating Internet access providers to make = location available for the purpose of routing emergency Internet calls. It will = be interesting to see what impact this legislation has on 3G data only = devices and associated network operators, presumably they will need to comply = with the Internet access provider legislation or stop providing, I think that = it is more likely that they will comply. Maybe you are aware that CDMA EvDO providers will be obligated by the = FCC in the US to provide E911 capability assuming they are using licensed = spectrum. So in this example, and in a few more years when the 3GPP/3GPP2 solution = has been fully defined and implemented, the device in question would be able = to access the CDMA EvDO network, assuming it recognized the dialed = emergency number and supported the 3GPP/3GPP2 solution, and make an IP based E911 = call directly via the serving EvDO network and not via its normal VSP. [AJW] Martin, Brian and possibly Richard have already described a = serious flaw in this line of thinking. Namely that if I have a 3G Internet = router, any device behind that router has absolutely no visibility that it needs = to talk to a different VSP, the solution you are proposing almost suggests therefore that the wireless router requires E-CSCF functionality in it = and that it can detect when a device in the home network is making an = emergency call. This is very intrusive and certainly not backward compatible with = the legacy devices already deployed.=20 =A0If it did not recognize the dialed emergency number or chose to use = the normal VSP anyway but still supported the 3GPP/3GPP2 solution, then the = VSP (e.g. based on receiving some access network related information from = the device in the SIP INVITE such as an EvDO cell ID and possibly based on subscription information if needed to imply 3GPP/3GPP2 capability for = the device) could send an error response back to the device (a SIP 380 = response with an emergency indication) that would cause the device to redirect = the call to the EvDO serving network. If the device did not support the 3GPP/3GPP2 solution, this would not work - but it seems unreasonable to treat non-support of a solution as a weakness since almost every = solution is susceptible to this. [AJW] Any device behind a home 3G router will have no visibility of the connected cell-id. Cell-ID is also of almost no use to anyone but the operator of the access network, so including this in a call to a VSP = that knows nothing about EVDO, let along a specific access provider seems = almost as big a stretch as universal SUPL roaming. Why not simply make the = location available to the caller using the mechanisms described in GeoPriv? Once = this is done you have ECRIT, i2, or i3 and they will just work!=20 The above would not prevent the VSP from employing the Ecrit solution = for other types of access not supporting the 3GPP/3GPP2 solution and the incremental cost to the VSP of supporting the 3GPP/3GPP2 solution (by = means of the 380 response) ought to be small. [AJW] The argument again is that device may not know about the = underlying dependency between access and service and in a number of circumstances = it absolutely will not know. The device might be able to learn the address = of the local ES-Proxy, but if you are going to employ that solution why not just employ an option to discover the LIS and the LoST server? The one case I have omitted but which I assume you may specifically have = in mind is where the device only supports IP data access and acts as a = router on behalf of another end device (e.g. a laptop). In that case, I think = both solutions would be severely handicapped. The Ecrit solution would have a hard time obtaining location (unless the end device already had an = accurate location fix which it included in the SIP INVITE) and in routing to a = PSTN capable PSAP (particularly one in another country).=20 [AJW] Let's agree to disagree on this point. The 3GPP access behind the router is the Internet access provider and will likely have to provide location to the device. We have got pretty good LIS discovery mechanisms described in Geopriv that address most major concerns, so actually I = believe that ECRIT and NENA i2 will work quite well. The 3GPP/3GPP2 solution - assuming the VSP supported it - might find location easier (e.g. if the router or end device supported SUPL since = that would allow location for dispatch subsequent to call routing), but would find PSTN PSAP routing just as hard. The parts of the Ecrit solution that appear unsuitable for cellular = networks I have already elaborated on - e.g. endpoint oriented location and = routing, no explicit cellular location capability, no explicit support for PSAPs accessed over the PSTN. [AJW] I think you will find that the WiMAX forum disagrees you with on a number of these points. And I have absolutely no doubt that with the 1.5 version of WiMAX I can support a fully mobile IP network using the ECRIT emergency calling architecture.=20 I am not sure that I understand what you mean by "no explicit cellular location capability", perhaps you can explain. Certainly using a = protocol such as HELD I can an awful lot and it all remains local so it doesn't require a world in a database to support roaming such as is required in = some protocols that we will not mention here.;) =A0(the NENA i2 solution is not a global standard and seems impractical = where a PSAP is very remote from the VSP), no consideration for handover to or from circuit mode access (which will remain the norm for many years) or = even to/from other IP access networks. [AJW] You are right that NENA i2 is not a global standard, but it is = being tailored for deployment in at least 3 countries at I am aware of, and = forms the basis for discussion in a number of others. I agree that circuit mode devices will be around for a many years to = come, I am less convinced that they will remain the norm, and with data only = devices increasing in popularity I see the need to hand-over in the way you = describe as unnecessary. Indeed I see it as a technological mismatch, equivalent = to being able to hand-over my GSM call to a CDMA network; Without a = special, purpose-built device I can't do it. Delivery of calls from VoIP to = circuit switched PSTN and vice versa is common place today from any number of = voice service providers and this is the mode of operation we should be = discussing. =A0 Kind Regards Stephen -------------------------------------------------------------------------= --- -------------------- This=A0message=A0is=A0for=A0the=A0designated=A0recipient=A0only=A0and=A0m= ay contain=A0privileged,=A0proprietary,=A0or=A0otherwise=A0private=A0informa= tion.=A0=A0 If=A0you=A0have=A0received=A0it=A0in=A0error,=A0please=A0notify=A0the=A0s= ender immediately=A0and=A0delete=A0the=A0original.=A0=A0Any=A0unauthorized=A0us= e=A0of this=A0email=A0is=A0prohibited. -------------------------------------------------------------------------= --- -------------------- [mf2] From hardie@qualcomm.com Fri Mar 6 10:43:36 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0657E3A691F for ; Fri, 6 Mar 2009 10:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.832 X-Spam-Level: X-Spam-Status: No, score=-105.832 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lU08ZsCWS9S for ; Fri, 6 Mar 2009 10:43:34 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id CE1B53A67FC for ; Fri, 6 Mar 2009 10:43:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1236365045; x=1267901045; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<048501c99e6b$f6f5e850$e 4e1b8f0$@net>|References:=20<1288E74A73964940B132A0B9EA8D 8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a=0D=0A=208d01 c991ff$fd063420$f7129c60$@net>=0D=0A=20<1288E74A73964940B 132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com>=0D =0A=20=0D=0A=20<1288E74A73964940B132A0B9EA8D8ABC53749E 3B@NASANEXMB04.na.qualcomm.com>=0D=0A=20=0D=0A=20<1288 E74A73964940B132A0B9EA8D8ABC5374A271@NASANEXMB04.na.qualc omm.com>=0D=0A=20<048501c99e6b$f6f5e850$e4e1b8f0$@net> |Date:=20Fri,=206=20Mar=202009=2010:43:46=20-0800|To:=20B rian=20Rosen=20,=20"Edge,=20Stephen" =20,=0D=0A=20=20=20=20=20=20=20=20"'W interbottom,=20James'"=20, =0D=0A=20=20=20=20=20=20=20=20"'ECRIT'"=0D=0A=09|From:=20Ted=20Hardie=20 |Subject:=20Re:=20[Ecrit]=20Comments=20on=20Framework=20D raft|Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5545"=3B=20 a=3D"16052160"; bh=ajwzaPZdz7Ekel+222pJyvM24C8P8iNkOfwQGRtFO2A=; b=TvN9LTUftGfAEbOJpzwVpiBWeTHIEeB9qsOWg4WPMSs4Cagh6H3sFtNR 4rUtMXiMdpPwWmXhWsq0YJQAbS3YRGhiOBXa5bRAAGCzUc0fN1DHhyqI1 MSM/bhGqO9kDGUiVa/42EmO1RON0J88FzWRy8YtdnBJz4YxTkDtxg2cuB A=; X-IronPort-AV: E=McAfee;i="5300,2777,5545"; a="16052160" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Mar 2009 10:43:52 -0800 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n26IhqD8020060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Mar 2009 10:43:52 -0800 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n26Ihjer018529 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 6 Mar 2009 10:43:52 -0800 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 6 Mar 2009 10:43:48 -0800 Received: from [10.227.68.131] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 6 Mar 2009 10:43:48 -0800 MIME-Version: 1.0 Message-ID: In-Reply-To: <048501c99e6b$f6f5e850$e4e1b8f0$@net> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a 8d01c991ff$fd063420$f7129c60$@net> <1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC53749E3B@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5374A271@NASANEXMB04.na.qualcomm.com> <048501c99e6b$f6f5e850$e4e1b8f0$@net> Date: Fri, 6 Mar 2009 10:43:46 -0800 To: Brian Rosen , "Edge, Stephen" , "'Winterbottom, James'" , "'ECRIT'" From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 18:43:36 -0000 At 6:58 AM -0800 3/6/09, Brian Rosen wrote: > >The IETF is desirous of making 3GPP and IETF standards for emergency calling >more harmonious with each other. To do so, it is willing to negotiate, and >in some circumstances to change its standards, provided that 3GPP is willing >to do the same. Uh, Brian, on what basis do you speak for the IETF in this manner? The willingness of the IETF to "negotiate" sounds more like the attitude of a sovereign power (or at least an SDO with serious turf issues) than a technical body striving to do the right thing. >The areas we would like to discuss include how location is >obtained for routing and delivered to a PSAP, what the representation for >location (geo and civic, value and reference) is, how emergency calls are >recognized and routed and the specifics of the SIP signaling to accomplish >the above. The IETF and 3GPP have strived to not have conflicts in each >other's standards, and emergency calling should not be different. > >3GPP has explicitly decided NOT to enter such discussions and negotiations >at this time. Individuals with experience in this realm have spoken about the issue in the past and are raising the issue again. Given that the IETF has historically said that the *best* way for progress to occur was to have technical contributors contribute, I find this "send me a liaison statement and we'll talk" attitude baffling and inappropriate. As for "agreeing to disagree", that's what I heard Stephen asking for all along; a statement in the document that described its applicability. I found your description of the end-to-end networks with edge intelligence both appropriate and accurate for the ECRIT case. Why not include that, along with a note saying that network architectures which rely upon network support/command/control do not work using this set of technologies and aren't expected to develop in that direction? Not including some statement of applicability here seems more like an attempt to control the outcome by ignoring reality than anything else, and I don't believe that's appropriate. >In the absence of official discussions and negotiations, I think our >documents are complete, and accurate. There are no protocol police, and the >IETF is well aware that many vendors and network operators openly ignore >parts of its standards. This sounds extraordinarily like you believe that all vendors and network operators *should* be following IETF standards and that the wise, benevolent IETF is saddened by the wayward behavior of these naughty children. This is a technical body, trying to write specs that work in the real world. It is not divinely inspired, though I have written enough howlers into my own documents to wish it were. Having Stephen request we recognize the existence of other models in a BCP document for a process that we all agree *must work the maximum out of time* seems either a good idea or harmless. Do we really not have the humility to manage that? Ted >Brian > >----- From sedge@qualcomm.com Fri Mar 6 18:25:41 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56E713A68FB for ; Fri, 6 Mar 2009 18:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k00VVQWxxzW for ; Fri, 6 Mar 2009 18:25:39 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 21BBC3A67B4 for ; Fri, 6 Mar 2009 18:25:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1236392770; x=1267928770; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20B rian=20Rosen=20,=0D=0A=20=20=20=20=20 =20=20=20"'Winterbottom,=20James'"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"'ECRIT'" =20|Date:=20Fri,=206=20Mar=202009=2018:26 :08=20-0800|Subject:=20RE:=20[Ecrit]=20Comments=20on=20Fr amework=20Draft|Thread-Topic:=20[Ecrit]=20Comments=20on =20Framework=20Draft|Thread-Index:=20AcmHZkcFqEtDIGTNRMy2 Xqm0XoWoXwKeEe+gADZBfMABQDsYoAA26fDAAJM+RGAAG+ZlYADeHaYQ |Message-ID:=20<1288E74A73964940B132A0B9EA8D8ABC5374A303@ NASANEXMB04.na.qualcomm.com>|References:=20<1288E74A73964 940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com>< 0a8d01c991ff$fd063420$f7129c60$@net>=0D=0A=20<1288E74A739 64940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com >=0D=0A=20=0D=0A=20<1288E74A73964940B132A0B9EA8D8ABC53 749E3B@NASANEXMB04.na.qualcomm.com>=0D=0A=20=0D=0A=20< 019501c99b53$2b0b1ff0$81215fd0$@net>|In-Reply-To:=20<0195 01c99b53$2b0b1ff0$81215fd0$@net>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5545"=3B=20a=3D"16048992"; bh=CqqZAGHWoUDFlhRlDuoalAOyMbjqIuU23JvE8kWQUwg=; b=vXdEQs7kMyYpN9NNPd9VbRcxVgCIqJuTSBeN46emIgkxnYOrrXRW3Wpp a4QFGn7kMayf109rR4QcxPzRa/3UpPUfX7mpfz4u9EtGOXV9EDqmE1VIo EBihZglpHBg/X29bdkTLCyethpDkmay6xs604GRtTAWTrQ97ZFPBIercr Y=; X-IronPort-AV: E=McAfee;i="5300,2777,5545"; a="16048992" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Mar 2009 18:26:10 -0800 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n272Q9Hp021374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Mar 2009 18:26:10 -0800 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n272Q967023373 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 6 Mar 2009 18:26:09 -0800 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub01.na.qualcomm.com ([10.46.93.121]) with mapi; Fri, 6 Mar 2009 18:26:09 -0800 From: "Edge, Stephen" To: Brian Rosen , "'Winterbottom, James'" , "'ECRIT'" Date: Fri, 6 Mar 2009 18:26:08 -0800 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwKeEe+gADZBfMABQDsYoAA26fDAAJM+RGAAG+ZlYADeHaYQ Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5374A303@NASANEXMB04.na.qualcomm.com> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net> <1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC53749E3B@NASANEXMB04.na.qualcomm.com> <019501c99b53$2b0b1ff0$81215fd0$@net> In-Reply-To: <019501c99b53$2b0b1ff0$81215fd0$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 02:25:41 -0000 Hi Brian Thanks for these comments. I have been responding generally slower than you= and other Ecrit participants have been sending and need to catch up. I wil= l try to do so by being brief where possible. Our basic thesis is that Ecrit is not suitable in its current form for cell= ular networks. If it will help, we can qualify what that includes - e.g. mo= bile devices that support the full 3GPP or 3GPP2 protocol stacks across the= radio interface - and thus exclude less normal cases that James and I were= discussing. I have not seen any good arguments yet that refute this main proposition. F= or example, even if WiMax endorses the Ecrit solution and decides to make u= se of it, it may in the end prove the point we are making rather than yours= . Why? Because unless WiMax complies with nearly all the SHALLs in the Phon= eBCP and most of the SHOULDs, it would not be compliant but only use Ecrit = as a basis. (By contrast, 3GPP and 3GPP2 implementations are expected to co= mply with all SHALLs and most SHOULDs in 3GPP/3GGP2 spec.s.) In your comments below, you are off on a tangent concerning which solution = may have the widest applicability. That is not what we are concerned with. = E.G. I can agree for the sake of argument (and to save a lot of time) that = Ecrit has a brilliant solution for all scenarios barring those I have ident= ified above. And our original contention would then still remain. Kind Regards Stephen -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Monday, March 02, 2009 8:23 AM To: 'Winterbottom, James'; Edge, Stephen; 'ECRIT' Subject: RE: [Ecrit] Comments on Framework Draft I'm also certain we're not going to converge, but let me step up a level an= d observe that there is a fundamental flaw with the current cellular emergenc= y call architecture: The assumption that the access network always provides emergency calling services, which is also related to the assumption that th= e home and visited networks have a contractual relationship. =20 This is flawed even for 3GPP IMS networks that are fixed. They assume "nomadic" services that are provided by the home network, including emergency calling, and where there may not be a relationship between the access network and the calling network. It's also true of services that a cellular network does not provide, but does provide the raw packet access. AOL/MSN/Yahoo Instant Messaging for example, or Skype. The ecrit architecture does not make this assumption. =20 When the home network provides emergency services, then you may have to get location from the access network, and send it via the home network. The device is the customer of both the access network and the calling network, which is why the ecrit architecture works, and the current IMS architecture does not. Brian From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 Sent: Monday, March 02, 2009 12:04 AM To: Edge, Stephen; Brian Rosen; ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Hi Stephen, I have the distinct impression that we are never going to agree on this subject, I would however like to point out some statements in text below that are either misleading, or at least able to be interpreted in an alternative manner than that which is provided. Please inline. Cheers James -----Original Message----- From: Edge, Stephen [mailto:sedge@qualcomm.com]=20 Sent: Friday, 27 February 2009 4:38 PM To: Winterbottom, James; Brian Rosen; ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Hi James Thanks for these further comments and for this oft repeated example - namel= y use of a 3GPP or 3GPP2 IP access network to reach a non-3GPP/3GPP2 VSP. Thi= s is always being thrown up as a reason that the 3GPP/3GPP2 solution cannot even fully address its own calling scenarios. It is however incomplete for the following reasons. [AJW] Let's agree to disagree on this point, it is a stated requirement in TS23.167 (requirement 2 under section 4.1) that "Emergency services are independent from the IP-CAN with respect to the detection and routing of emergency sessions. The emergency services shall be possible over at least = a cellular access network, a fixed broadband access, I-WLAN access and a nomadic access." I think, therefore that the solution is actually perfectly valid, the 3GPP network is the IPCAN and it must allow independent detection and routing of the emergency call. This requirement falls short of what some legislative bodies are now considering the duty of the IPCAN to be, but it is still a good start. First of all, I doubt that in this example either the Ecrit or 3GPP/3GPP2 solution would actually be possible now since neither are fully defined or fully implemented yet. Perhaps the VSP would provide some rudimentary E911 capability though probably not to the right PSAP. So the example is more hypothetical for future implementation in which case either solution might be considered. [AJW] This is true for ECRIT in that LoST servers are not widely deployed and publically available. However there are certainly NENA i2 deployments being tested (not sure if they are actually live yet) where the=A0 originat= ing call includes a PIDF-LO in the body with the call, and the VSP in conjunction with a VPC can route the emergency call to the correct PSAP. I fully expect this to happen in cases where the Internet pipe is 3G so let's agree that this is not hypothetical.=20 I am aware of two countries that are currently in the process or about to begin the process of legislating Internet access providers to make location available for the purpose of routing emergency Internet calls. It will be interesting to see what impact this legislation has on 3G data only devices and associated network operators, presumably they will need to comply with the Internet access provider legislation or stop providing, I think that it is more likely that they will comply. Maybe you are aware that CDMA EvDO providers will be obligated by the FCC i= n the US to provide E911 capability assuming they are using licensed spectrum= . So in this example, and in a few more years when the 3GPP/3GPP2 solution ha= s been fully defined and implemented, the device in question would be able to access the CDMA EvDO network, assuming it recognized the dialed emergency number and supported the 3GPP/3GPP2 solution, and make an IP based E911 cal= l directly via the serving EvDO network and not via its normal VSP. [AJW] Martin, Brian and possibly Richard have already described a serious flaw in this line of thinking. Namely that if I have a 3G Internet router, any device behind that router has absolutely no visibility that it needs to talk to a different VSP, the solution you are proposing almost suggests therefore that the wireless router requires E-CSCF functionality in it and that it can detect when a device in the home network is making an emergency call. This is very intrusive and certainly not backward compatible with the legacy devices already deployed.=20 =A0If it did not recognize the dialed emergency number or chose to use the normal VSP anyway but still supported the 3GPP/3GPP2 solution, then the VSP (e.g. based on receiving some access network related information from the device in the SIP INVITE such as an EvDO cell ID and possibly based on subscription information if needed to imply 3GPP/3GPP2 capability for the device) could send an error response back to the device (a SIP 380 response with an emergency indication) that would cause the device to redirect the call to the EvDO serving network. If the device did not support the 3GPP/3GPP2 solution, this would not work - but it seems unreasonable to treat non-support of a solution as a weakness since almost every solution i= s susceptible to this. [AJW] Any device behind a home 3G router will have no visibility of the connected cell-id. Cell-ID is also of almost no use to anyone but the operator of the access network, so including this in a call to a VSP that knows nothing about EVDO, let along a specific access provider seems almost as big a stretch as universal SUPL roaming. Why not simply make the locatio= n available to the caller using the mechanisms described in GeoPriv? Once thi= s is done you have ECRIT, i2, or i3 and they will just work!=20 The above would not prevent the VSP from employing the Ecrit solution for other types of access not supporting the 3GPP/3GPP2 solution and the incremental cost to the VSP of supporting the 3GPP/3GPP2 solution (by means of the 380 response) ought to be small. [AJW] The argument again is that device may not know about the underlying dependency between access and service and in a number of circumstances it absolutely will not know. The device might be able to learn the address of the local ES-Proxy, but if you are going to employ that solution why not just employ an option to discover the LIS and the LoST server? The one case I have omitted but which I assume you may specifically have in mind is where the device only supports IP data access and acts as a router on behalf of another end device (e.g. a laptop). In that case, I think both solutions would be severely handicapped. The Ecrit solution would have a hard time obtaining location (unless the end device already had an accurate location fix which it included in the SIP INVITE) and in routing to a PSTN capable PSAP (particularly one in another country).=20 [AJW] Let's agree to disagree on this point. The 3GPP access behind the router is the Internet access provider and will likely have to provide location to the device. We have got pretty good LIS discovery mechanisms described in Geopriv that address most major concerns, so actually I believ= e that ECRIT and NENA i2 will work quite well. The 3GPP/3GPP2 solution - assuming the VSP supported it - might find location easier (e.g. if the router or end device supported SUPL since that would allow location for dispatch subsequent to call routing), but would find PSTN PSAP routing just as hard. The parts of the Ecrit solution that appear unsuitable for cellular network= s I have already elaborated on - e.g. endpoint oriented location and routing, no explicit cellular location capability, no explicit support for PSAPs accessed over the PSTN. [AJW] I think you will find that the WiMAX forum disagrees you with on a number of these points. And I have absolutely no doubt that with the 1.5 version of WiMAX I can support a fully mobile IP network using the ECRIT emergency calling architecture.=20 I am not sure that I understand what you mean by "no explicit cellular location capability", perhaps you can explain. Certainly using a protocol such as HELD I can an awful lot and it all remains local so it doesn't require a world in a database to support roaming such as is required in som= e protocols that we will not mention here.;) =A0(the NENA i2 solution is not a global standard and seems impractical whe= re a PSAP is very remote from the VSP), no consideration for handover to or from circuit mode access (which will remain the norm for many years) or eve= n to/from other IP access networks. [AJW] You are right that NENA i2 is not a global standard, but it is being tailored for deployment in at least 3 countries at I am aware of, and forms the basis for discussion in a number of others. I agree that circuit mode devices will be around for a many years to come, = I am less convinced that they will remain the norm, and with data only device= s increasing in popularity I see the need to hand-over in the way you describ= e as unnecessary. Indeed I see it as a technological mismatch, equivalent to being able to hand-over my GSM call to a CDMA network; Without a special, purpose-built device I can't do it. Delivery of calls from VoIP to circuit switched PSTN and vice versa is common place today from any number of voice service providers and this is the mode of operation we should be discussing= . =A0 Kind Regards Stephen ---------------------------------------------------------------------------= - -------------------- This=A0message=A0is=A0for=A0the=A0designated=A0recipient=A0only=A0and=A0may contain=A0privileged,=A0proprietary,=A0or=A0otherwise=A0private=A0informati= on.=A0=A0 If=A0you=A0have=A0received=A0it=A0in=A0error,=A0please=A0notify=A0the=A0sen= der immediately=A0and=A0delete=A0the=A0original.=A0=A0Any=A0unauthorized=A0use= =A0of this=A0email=A0is=A0prohibited. ---------------------------------------------------------------------------= - -------------------- [mf2] From sedge@qualcomm.com Fri Mar 6 19:26:51 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D7E13A68EB for ; Fri, 6 Mar 2009 19:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.522 X-Spam-Level: X-Spam-Status: No, score=-104.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3m0PyECHKQi for ; Fri, 6 Mar 2009 19:26:48 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id C78223A68C4 for ; Fri, 6 Mar 2009 19:26:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1236396439; x=1267932439; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" Winterbottom,=20James"=20, =0D=0A=20=20=20=20=20=20=20=20"br@brianrosen.net"=0D=0A =09|CC:=20ECRIT=20 |Date:=20Fri,=206=20Mar=202009=2019:27:16=20-0800 |Subject:=20RE:=20[Ecrit]=20Comments=20on=20Framework=20D raft|Thread-Topic:=20[Ecrit]=20Comments=20on=20Framework =20Draft|Thread-Index:=20AcmY6xBP94jupkzETj+iA0b5U69mvgDj /IbwAAQz+pAAkHx7oA=3D=3D|Message-ID:=20<1288E74A73964940B 132A0B9EA8D8ABC5374A308@NASANEXMB04.na.qualcomm.com> |References:=20<1288E74A73964940B132A0B9EA8D8ABC535F0305@ NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c 60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEX MB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A7 3964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.c om><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB 04.na.qualcomm.com><64147.24.154.127.233.1235746352.squir rel@www.brianrosen.net>=0D=0A=20<1288E74A73964940B132A0B9 EA8D8ABC5374A0D6@NASANEXMB04.na.qualcomm.com>=0D=0A=20 |In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5545"=3B=20a=3D"16049573"; bh=vNLcpKwxR81mnw5+2ir0tiQKLmQLyLZ5C3/g3AhobZs=; b=PyNrLo2t1TjQ1/ibR5vTwuQwZ/npW9s+Opa+iv8XH4xfu84ENlZcy23g VbpPmjlNnYU7CxgIiaEHmYVdOBJfX9cqSbDRsQKdrKrrO1ZSUW2PkdYoW TQbdKOIJK/0wcxQIw9MCgfe+ej4aJkH6c8EyUCcCCLtMlJN/gI3YnH3pq Y=; X-IronPort-AV: E=McAfee;i="5300,2777,5545"; a="16049573" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Mar 2009 19:27:18 -0800 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n273RH7Q008668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Mar 2009 19:27:18 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n273RHZq005211 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 6 Mar 2009 19:27:17 -0800 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Fri, 6 Mar 2009 19:27:17 -0800 From: "Edge, Stephen" To: "Winterbottom, James" , "br@brianrosen.net" Date: Fri, 6 Mar 2009 19:27:16 -0800 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmY6xBP94jupkzETj+iA0b5U69mvgDj/IbwAAQz+pAAkHx7oA== Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5374A308@NASANEXMB04.na.qualcomm.com> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com><64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net> <1288E74A73964940B132A0B9EA8D8ABC5374A0D6@NASANEXMB04.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 03:26:51 -0000 Hi James Thanks for the comments for which I have embedded some responses below. In = every case, I feel sure that my original point remains sustained. Kind Regards Stephen ________________________________________ From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Wednesday, March 04, 2009 7:56 PM To: Edge, Stephen; br@brianrosen.net Cc: ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Hi Stephen, A few errors and clarifications. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of E= dge, Stephen Sent: Wednesday, 4 March 2009 4:32 PM To: br@brianrosen.net Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft Brian Thanks for these well considered responses. Below I am providing on an item= by item basis, and taking into account your responses, a few more reasons = why the current Ecrit solution is unsuitable - or, if you prefer, less suit= able than the 3GPP/3GPP2 solution - for cellular networks. 1. Access to PSTN capable PSAPs Assuming that the best available solution for this currently is the ongoing= NENA i2 standard (as you comment), then there are problems with providing = location for dispatch (initial and updated location). For example, the late= st i2.5 draft I have (December 2008) says that the VPC to LIS v3 interface = is being deprecated (thus not available), although this is the interface th= at the VPC would use to query location from the LIS. [AJW] The V3 interface is not being deprecated, what is being deprecated is= the old V3 schema and the rationale for that is that it makes more sense t= o re-use HELD (http://tools.ietf.org/html/draft-winterbottom-geopriv-deref-= protocol-03) an SIP for dereference protocols rather than reinventing the w= heel. [SE] Okay (got it!) Also I don't see any inclusion of accurate positioning support - e.g. using= A-GPS. Further, interworking with the circuit mode side for UA access (as = opposed to PSAP access) seems to be out of scope. So at best, this standard= is incomplete (i.e. not yet suitable for cellular networks). However, I ag= ree that there is some overlap between i2.5 and the 3GPP/3GPP2 solution. [AJW] i2 does not preclude the measurements being provided by the Target de= vice, or being requested of the Target device by the LIS. There are a slew = of contributions that show how this can easily be done using HELD. [SE] I think this is mostly or entirely in drafts - right? I don't think an= y of them deal with 3GPP/3GPP2 interworking - e.g. LIS to RNC, LIS to eNode= B etc. That represents future work and uncertainty (e.g. concerning complex= ity, feasibility, performance). Also I am not sure how complete the positio= ning support you refer to really is - e.g. in terms of supporting A-GNSS an= d the various terrestrial OTDOA methods. 2. Handover between different IP access networks including different types = of access network One of the issues here would be change of LIS across different networks whi= le avoiding impacts to both IP and PSTN capable PSAPs (i.e. handover must b= e transparent to PSAPs within the limitations imposed by SIP or some J-STD-= 036 type of circuit mode solution). The problem gets more difficult when ha= ndover to/from circuit mode access networks is considered. So far, 3GPP/3GP= P2 has not yet agreed on a solution although there are proposals and we exp= ect some resolution soon. On the Ecrit and NENA sides, I see much less prog= ress. 3. Handover to/from circuit mode networks We agree here at least on the out of scope aspect. I suppose I can accept t= hat it is not customary to point this out in IETF standards. But I hope you= can see that this is an issue for cellular networks most of which will hav= e extensive circuit mode coverage for a long time to come. 4. Location for cellular access (and the requirement to support LCPs that w= ill be useless for cellular access) The issue is not so much the LCP itself but the capability to support accur= ate positioning - e.g. using A-GPS, AFLT, OTDOA, enhanced cell ID etc. None= of those methods seem to be supported as part of DHCP or HELD right now. S= o some modification of the LCP related requirements or of the LCPs seems ne= eded. [AJW] I will stress that a number of these methods are network determinatio= n methods and are dependent on the location node accessing these measuremen= ts from directly from the RAN. In such cases anyone of the LCPs described i= s just as capable of obtaining these as any specific 3G location node. For = example, a device could launch a HELD request to the LIS, and the LIS could= request timing advance measurements from the network, or use SRI/PSL to co= ntact and SMLC. The determination procedures are transparent and are equall= y applicable to an LCP as they are to 3GPP specific procedures. Let's take a bit of a look at Target provided measurements. If my HELD-enab= le device were to include let's say relative delay measurements to the LIS = in an access network, then the LIS can easily use these, since the LIS know= s the locations of all the associated basestations. Now let's compare this = to 3GPP user-plane, where the SET would provide this information back to a = home-SLP, if the SET is roaming what use are these measurements? There are = two options for using them, neither of which is overly satisfactory. The H-= SLP can have a database containing every single base station on earth, and = can attempt to use them in that fashion, certainly some vendors are taking = that approach, but it is hardly workable in the long term. Or, the H-SLP ca= n find the SLP in the visited network and ask it to do the work for it. Cer= tainly SUPL defines a protocol to support the quest procedures for this, bu= t is very conveniently puts out of scope how the H-SLP determines the corre= ct V-SLP to contact. Indeed once you move to W-LAN this problem becomes int= ractable. Device provided network measurements are only relevant in that access netwo= rk and this point is sadly missed by the 3GPP adopted user-plane solution. To see how some of plan to address you concerns of LCP provided measuremen= ts please see: * draft-thomson-geopriv-held-measurements * draft-thomson-geopriv-held-grip * draft-thomson-geopriv-held-capabilities * [SE] Repeat my previous comment above about additional standardization need= ed and associated uncertainties. Regarding SUPL, I thought we had now agree= d that once an emergency call has been initiated, it will be an E-SLP in th= e serving network rather than an H-SLP in the home network that would be in= volved in roaming cases. The E-SLP can initiate positioning for both routin= g and dispatch and make use of RAN related measurements. Moreover, for HSPA= and LTE access, there are (or will be later this year) alternative control= plane solutions. Note that I am suggesting using SUPL (or any other method= ) to obtain location in advance of an emergency call. 5. Endpoint based location and routing for cellular access (issues here are= network and device loading as well as device impacts and problems with PST= N capable PSAPs) Endpoint based location when spread over millions (billions, planet-wide) o= f terminals will consume significant network and terminal resources. [AJW] Perhaps, but using an LCP this is local traffic, in contrast with SUP= L ALL communication goes back to the H-SLP and this can be a long way away = when the device is roaming. [SE] SUPL will not be used to pre-obtain location for a later emergency cal= l. It will generally be used only after an emergency call has been initiate= d and will be invoked by an E-SLP. A typical terminal is generally idle and interacts with the network very sp= aringly to update the network with its current location (e.g. current clust= er of potential serving cells). [AJW] A location URI means that unless the device changes access networks t= hat it does not need to perform this update at all. When the device does ch= ange access networks, it acquires a new location URI. [SE] a location URI does not help a device determine when it may have cross= ed a PSAP boundary. So if you want a mobile device to know the PSAP in adva= nce of an emergency call, a lot of location determination seems needed. Performing network assisted periodic location fixes and LoST queries would = add significantly to network load. Performing periodic location fixes in th= e terminal (e.g. using GPS) and estimating when a PSAP boundary may have be= en crossed would add to terminal load (e.g. thus battery drain). [AJW] In the mobile case I would perform these operations at call time, and= I certainly wouldn't do a GPS fix as a rough location fix will be quite ad= equate for purposes of obtaining a routing URI. In this case I could send a= HELD request the LIS with a responseTime=3DemergencyRouting. The LIS can i= nvoke techniques for enhanced cell etc is that falls into criteria set by t= he local jurisdiction, the device can then do the lost lookup using eh resu= lting location. It is certainly no less efficient for the device to do thes= e operations than it is for the network to do them on behalf of the device,= and it may be more efficient because these are local services. Ultimately = the bandwidth is the same or less using the ECRIT proposal for call routing= . [SE] The above is a more reasonable approach. However, the phoneBCP says: "= ED-31/INT-24 For devices which roam, refresh of location information SHOULD= be more frequent, with the frequency related to the mobility of the device= and the ability of the access network to support the refresh operation. I= f the device can detect that it has moved, for example when it changes acce= ss points, the device SHOULD refresh its location". Do you agree that maybe= this part of the phoneBCP is not suitable? Optimizations would be possible of course - e.g. based on observing nearby = cell IDs - but they will add to terminal complexity and testing costs. I ag= ree that the Ecrit solution does allow for proxies to do this but here the = solution also becomes incomplete because there seem no details of how this = would work - e.g. what location solutions would then be used. [AJW] I am sorry I don't understand this comment. If we look at almost any = cellular technology that I am aware of the device is already aware of neigh= bouring cells, it has to be as part of the general hand-over procedures. In= GSM this information is included in signal strength information already pa= ssed from the handset to the network. In WiMAX this is done using relative = delay measurements. Pick your network type, there are equivalents. Nothing = special needs to be done to the device to use them. Any network that suppor= ts a control-plane location architecture provides native messaging for gett= ing access to these measurements. This is handled in the LIS and is totally= transparent to the device, the device see normal network procedures taking= place. Perhaps I have misunderstood what you were trying to say. [SE] yes you are right that cell ID based methods will obtain location fast= er and more simply. But I was referring to use of visible cell IDs within a= terminal as an optimization to determine location changes without network = interaction which is something not currently supported (thus new impacts). 6. Support of unauthenticated users and users who can be authenticated but = are not permitted access/VSP service except for emergency calls I think the Ecrit solution and you both assume that this has already been r= esolved somehow at the access level and therefore the various procedures in= Ecrit can still be used. Maybe that is valid. However, there are still pro= blems that are not covered in the Ecrit drafts but need to be resolved incl= uding (a) obtaining IP access (e.g. via a WLAN, cellular network, cable lin= k) when not a valid subscriber, (b) obtaining access to the VSP and (c) ens= uring only emergency related services are provided (e.g. and not free Inter= net and location access). These and additional problems (e.g. UA identifica= tion) would have to be solved, maybe on a per access basis, and then ensure= d to be compatible with the rest of the Ecrit solution. A significant part = of the 3GPP/3GPP2 solution is concerned with this aspect and it has delayed= completion of the solution for the more normal case of valid subscriber ac= cess due to such compatibility issues. [AJW] Unauthenticated access is an interesting animal, and as you point out= in an IP world this has several different levels on which it operates. The= re are a few points on this that should be considered however, and fist and= foremost perhaps is the growing number of countries at that are disabling = this functionality! Another point of interest is that in cellular this is already technological= ly challenged when it comes to this function; devices that use different ph= ysical characteristic from the carrier network cannot be accommodated by th= is service even if they both have 3GPP cores. Private IP networks are very common, almost very house has one, and a very = large number have wireless LANs. Conversely there are very few private cell= ular networks. So I am not sure that a direct comparison can be made here, = certainly I don't intend to let just anyone on to private home LAN just bec= ause they claim they want to make an emergency call, it is tantamount to my= simply placing a T-200 phone on my letterbox along with a sign that says e= mergency only. There are thoughts on how to address some of these issues in ECRIT, and you= will have to forgive me but I haven't had time to address them in a draft = yet, I do hope to in the not too distant future. [SE] we think some countries will continue to require support of unauthenti= cated emergency access and, in particular, do not want to take the risk of = excluding support for it. Thus, we see this as a necessary part of any (sui= table) solution. Kind Regards Stephen -----Original Message----- From: br@brianrosen.net [mailto:br@brianrosen.net] Sent: Friday, February 27, 2009 6:53 AM To: Edge, Stephen Cc: Thomson, Martin; Richard Barnes; ECRIT Subject: Re: [Ecrit] Comments on Framework Draft Stephen Like any standards organization, the IETF restricts it's scope. Generally, the scope is "the Internet", although we very often describe solutions that are explicitly designed for private IP networks as well as the Internet. We don't write standards for circuit switched networks, and it should be no surprise that the ecrit solution does not cater to CS solutions. Nevertheless, we often try to make sure that our solutions harmonize reasonably well with existing solutions. Indeed, the ecrit solution clains global applicability to the Internet in general, and most private IP networks that can be interconnected to the Internet or to other IP networks via gateways. Looking at your list of problem areas: > - access to PSTN capable PSAPs This is out of scope for IETF. NENA has active work on this subject. It seems straightforward to interwork ecrit compatible devices and networks to existing CS connected PSAPs. As you know, CS interconnects are very nation-specific, so the NENA work may not have general applicability. However, it shows that it is possible to interwork. The NENA i2 work is also designed to take ecrit compatible devices and VSP networks, and interwork them to the existing network. The VSP would direct the call to the VPC, which would provide the services it does now, using the device provided location for routing. This is important for smooth transition from existing PSAPs and VSPs to "next generation" PSAPs and VSPs. > - handover between different IP access networks including different > types of access network In the ecrit solution, the access network the call is initiated on provides all the facilities needed for the device to initiate an emergency call. The call starts traversing it's normal call path, and eventually routes to the ESRP. Handoffs between IP networks should be transparent to this process, although we probably haven't done all the work we need to do for handoffs where the IP address as seen by the terminating network changes. This would generally be true of all current SIP based work. > - handover to/from circuit mode networks This would be out of scope for IETF. It's as applicable to a simple SIP call as it is a SIP emergency call, and there are no statements in any SIP documents on that subject. > - location for cellular access (and the requirement to support LCPs tha= t > will be useless for cellular access) Location for cellular access networks has been considered carefully. Since cellular is a mobile network, the access network would pass the device a Location-By-Reference URI, using either DHCP or HELD. Either protocol is suitable for cellular networks. As we have pointed out several times, cellular networks support raw data packet services upon which many different kinds of networks can be constructed. My usual example is a large recreational vehicle traveling down a road with a cellular data card plugged into a router to which a wired (Ethernet) phone is connected. That phone must be able to make an emergency call, and it will get location from DHCP or HELD (or LLDP-MED). It is not aware of the cellular network, and doesn't know any cellular specific protocols. Cellular networks will have to support IETF location configuration protocols unless they actively prohibit examples like this, or they implement interworking between cellular-specific location protocols and DHCP or HELD in the data card. The ecrit standards permit proxy insertion of location, but, as above, we don't think that works in all cases. > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) The "load" of using DHCP or HELD to get location and querying LoST is pretty modest. The standards permit proxies to do this if the devices don't. As above, interwork functions to CS connected PSAPs is very feasible, and as above, cellular networks will have to support access to local LoST servers for devices that are connected to cellular networks and are ecrit compliant. > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls This is covered in the standards. None of the processes are dependent on authentication, although where it is possible, it's desirable so as to minimize fraudulent emergency calls Mechanisms for specific network authentication mechanisms are out of scope, and, like SIP basic calling, are not usually mentioned in IETF documents. Stephen, we've tried pretty hard to make sure this works for 3G/4G mobile networks. It's true that it doesn't do it the way 3GPP currently thinks it ought to work, but we claim they haven't thought through all the issues. While it would work, there are opportunities for improvement. We would be willing to do that if we could get the cooperation of 3GPP, which we have tried, and failed, to do. So, I think the documents do not need any qualification statements. Brian > Martin > > The 3GPP/3GPP2 solution has a defined restricted applicability (mainly to > 3GPP/3GPP2 access networks where the serving network also acts as the VSP= ) > and the specifications for it cover in detail all possible scenarios > consistent with these restrictions so far as we are aware. > > The Ecrit solution seems to claim global applicability to all types of IP > access (and the more that is said about this from Ecrit participants the > more this gets emphasized) but does not cover in detail all possible > scenarios (in some cases does not cover in any detail) which means that a= t > best the solution is incomplete and at worst intrinsically inapplicable t= o > some unstated set of scenarios. > > The missing, incomplete and problematic cases include the following: > > - access to PSTN capable PSAPs > - handover between different IP access networks including different > types of access network > - handover to/from circuit mode networks > - location for cellular access (and the requirement to support LCPs tha= t > will be useless for cellular access) > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls > > Stating that some of these cases are out of scope or referencing an > incomplete and possibly questionable specification from some other > national SDO will not help the user who encounters such problems. But it > would certainly help network operators and implementers to acknowledge > their existence in one form or another because that would allow better > planning of deployments and would help focus attention on finding > solutions (whether in IETF or elsewhere) for the missing cases. > > Please note that despite these drawbacks, I will acknowledge that Ecrit > does have a valuable solution that covers many scenarios not covered by > 3GPP/3GPP2. It would be the delineation of these supported scenarios (or > equivalently unsupported scenarios) in some applicability statement that > would be particularly useful right now. > > Kind Regards > > Stephen > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Thursday, February 26, 2009 9:45 PM > To: Edge, Stephen; Richard Barnes > Cc: ECRIT > Subject: RE: [Ecrit] Comments on Framework Draft > > There's benefit in knowing the limitations of a framework, and every > architecture makes certain assumptions. Let's examine them though... > > The IETF might occasionally make the assumption that the standards it > develops are for Internet devices. That assumption probably need not be > stated explicitly. > > The ECRIT architecture relies on implementations of the protocols that it > references. That is not extraordinary. A reliance on implementation of > these protocols by endpoints, routing intermediaries and PSAPs should not > need to be explained. > > So the assumptions are: > - the Internet > - solutions are implemented and deployed > - the end device is a key component > > Only that last element is particularly novel ... or not that much really. > It's a design choice. Unless you were thinking of trunking the voice > elsewhere. > > Of course, you're suggesting that the design choice was made in ignorance > of all the constraints. You're suggesting that - as a result - the choic= e > is flawed and the solution is not going to work for cellular services. W= e > disagree. The solution is a basis for emergency calling in _any_ IP > network. > > Cheers, > Martin > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Edge, Stephen >> Sent: Friday, 27 February 2009 3:30 PM >> To: Richard Barnes >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Richard >> >> Thanks for the comments. Your statement below that "SIP emergency >> calling works if all parties behave as specified in these (IETF Ecrit) >> documents" to some degree highlights the problems we are raising. The >> documents do contain a number of implicit and explicit restrictions - >> like IP capable PSAPs, global IP access (no islands of circuit mode >> access for example), universal support of this solution by all access >> providers and VSPs (not much good if some opt for another solution) and >> end system oriented location and routing capability - which together >> make them unsuitable (we believe) for cellular wireless networks. If >> these restrictions and assumptions were all made explicit upfront, it >> would to a large degree (and possibly completely) address our concerns. >> >> You are right in assuming another set of specifications for the 3GPP >> and 3GPP2 solution. The applicability of this solution is explicitly >> defined in TS 23.167 (or more exactly in an already agreed CR in >> contribution S2-090752 which will become part of 23.167 in a few more >> weeks) to cover the following access types: GPRS (UTRAN WCDMA), I-WLAN, >> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN >> (LTE). So there is a restriction and arbitrary internet access is not >> covered (yet) as I have stated before. >> >> Kind Regards >> >> Stephen >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Wednesday, February 25, 2009 6:30 PM >> To: Edge, Stephen >> Cc: Brian Rosen; 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Stephen, >> >> I'm a little confused by the scope of what you're asking. The >> framework >> and phonebcp documents exist in order to describe the ECRIT solution: >> They say, in effect, "SIP emergency calling works if all parties behave >> as specified in these documents." >> >> As I understand what you're saying (and I'm by no means an expert in >> 3GPP), 3GPP specifies that one or more elements of this system behave >> differently. This simply means that 3GPP networks aren't complying >> with >> these specs. Just like there's no disclaimer in RFC 791 (IPv4) that >> says "this doesn't work on X.25 networks", it's not clear to me that an >> analogous disclaimer is called for here. >> >> I presume there are similar documents describing how emergency calling >> works in 3GPP networks. Do they include notes saying that the 3GPP >> solution doesn't work in the broader Internet? >> >> --Richard >> >> >> >> >> >> Edge, Stephen wrote: >> > Brian >> > >> > First of all apologies for the likely lateness of this reply - I >> actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest but >> it seems unlikely that my VPN, Outlook server and WiFi access >> capability will cooperate together to get it sent until I return to the >> office mid-next week. >> > >> > Anyhow thanks for your comments. There have actually been a number of >> conference calls between IETF and 3GPP participants over the last >> couple of years at which common features like support of IP emergency >> calls were discussed and these could have been good forum for >> participants on either side to have raised the kinds of issues you >> elaborate on below. Given that seems not so far to have happened, it >> could still be possible in future such calls. >> > >> > But the issues we are raising are not directly to do with further >> aligning the 2 solutions or with the lack of this in the past. We are >> simply pointing out that the solutions are currently different and that >> from a cellular wireless perspective, the Ecrit solution is not seen as >> suitable in all respects (for support of IP emergency calls originating >> from such access types). That is not just our point of view. 3GPP2 sent >> a liaison to Ecrit some months ago pointing out the same issues. >> > >> > So we are proposing that the Ecrit framework and phoneBCP spec.s >> include a statement acknowledging this - e.g. by referencing the >> alternative 3GPP/3GPP2 solution and indicating the IP access types for >> which the Ecrit solution will work without limitation (or equivalently >> the access types where limitations are not ruled out). >> > >> > We are not proposing further modification and extension of the Ecrit >> solution - just pointing out that this would be needed (as with the >> 3GPP/3GPP2 solution) to fully cover all types of access. >> > >> > Kind Regards >> > >> > Stephen >> > -----Original Message----- >> > From: Brian Rosen [mailto:br@brianrosen.net] >> > Sent: Wednesday, February 18, 2009 8:07 PM >> > To: Edge, Stephen; 'ECRIT' >> > Subject: RE: [Ecrit] Comments on Framework Draft >> > >> > I have bit my tongue on this one for a long time. >> > >> > Stephen, with respect, please go talk to 3GPP management and ask them >> why >> > there has been no participation in the ecrit effort despite multiple >> YEARS >> > of begging them to get involved. To put it frankly, 3GPP is quite >> willing >> > to bully IETF into doing its work on its schedule, but cannot be >> bothered to >> > get work done it knows it will eventually have to do when the IETF >> asks it >> > to do so. >> > >> > 3GPP understands the mess that is being created by not participating. >> They >> > know full well that when they finally get around to dealing with PS >> > terminated emergency calls, that there will be a lot of resistance to >> > changing fully specified and implemented standards to more closely >> align >> > with 3GPP standards. I expect you will have several interworking >> functions >> > to define and build. >> > >> > So, politely, please go away, we're finishing work we dearly wanted >> you all >> > to be involved with for years, but you refused to do anything. It's >> too >> > late for this rev. >> > >> > Now, having said that, there are quite a few people who have >> participated in >> > the IETF work who are IMS aware and I believe that despite your >> fears, >> > everything you need is in the specs. The mechanisms we have defined >> provide >> > the ability for the network to insert location, recognize and mark >> emergency >> > calls, and route on behalf of endpoints. An E-CSCF could quite >> > straightforwardly provide a SIP call towards an ecrit compatible >> PSAP. The >> > only not-quite-nice interwork would be from SUPL to HELD (or SIP), >> but it's >> > pretty easy to do that. I'll also note that we have tried to get OMA >> and >> > IETF to cooperate on location protocols, but we have been >> spectacularly >> > unsuccessful at that effort also. >> > >> > Brian >> > >> > >> > >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf >> >> Of Edge, Stephen >> >> Sent: Thursday, February 05, 2009 2:50 AM >> >> To: 'ECRIT' >> >> Subject: [Ecrit] Comments on Framework Draft >> >> >> >> All >> >> >> >> draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative >> >> description of how terminals and networks should support emergency >> >> calls made over IP capable facilities to IP capable PSAPs. It >> appears >> >> intended to cover all types of access network - including fixed >> line, >> >> WiFi and cellular (e.g. examples involving each can be found >> throughout >> >> the draft). >> >> >> >> When we evaluated this with respect to support of wireless cellular >> >> access and WiFi access associated with a cellular operator (e.g. >> WLAN >> >> or Femto cells integrated into a cellular network), we found that >> >> certain portions of the draft exhibited one or more of the following >> >> characteristics: >> >> >> >> (A) Inconsistent with already standardized wireless solutions >> >> >> >> (B) Inconsistent with essential wireless requirements and >> >> conventions >> >> >> >> (C) Already part of wireless standards or potentially part of >> >> future standards >> >> >> >> (A) refers to all portions of the draft framework that differ from >> the >> >> requirements and procedures currently standardized for wireless >> >> emergency access by 3GPP, 3GPP2 and OMA. This is a plain difference >> of >> >> solution and could be resolved through support of both solutions by >> >> terminals (with each solution being used according to the type of >> >> access network and VSP) or could be resolved by supporting only one >> >> solution and accessing only the types of network supporting that >> >> solution. To acknowledge this category, the framework document could >> >> reference the applicable wireless standards and point out that these >> >> are valid alternatives for wireless cellular based access. >> >> >> >> (B) refers to portions of the draft that would be unsuitable for >> >> wireless networks even if no alternative solution existed together >> with >> >> other portions missing from the draft that would be needed to fully >> >> support wireless networks. Examples of the former include: (a) >> emphasis >> >> on endpoint derivation of location, performance of Lost query and >> >> receipt of local dial strings; (b) restriction of LCPs to protocols >> >> that require terminal initiation (not allowing for network >> initiation >> >> as far as we can tell) and that include two LCPs (DHCP and LLDP) >> that >> >> are not applicable to (not defined for) cellular access; and (c) the >> >> requirement that a terminal or at least a LIS will update the PSAP >> >> whenever location changes. (a) is impractical due to network and >> >> terminal loading consequences and failure to support non-IP capable >> >> PSAPs; (b) makes location verification and updated location >> provision >> >> to PSAPs difficult or impossible; while (c) is also incompatible >> with >> >> support of existing non-IP capable PSAPs besides increasing terminal >> >> load and possibly interfering with optimum maintenance of the RF >> >> connection (e.g. if a terminal has to tune away from the serving >> base >> >> station or WLAN periodically to make location measurements). >> Examples >> >> of the latter include (d) absence of support for access to non-IP >> >> capable PSAPs as already mentioned (e.g. to support E911 phase 2 in >> the >> >> US); (e) no support for handover from the IP to the circuit domain >> when >> >> a terminal loses (e.g. moves out of) RF coverage in the IP domain; >> and >> >> (f) no allowance for limited access modes wherein a terminal may >> access >> >> a network only to place an emergency call with ensuing restrictions >> on >> >> (for example) location acquisition, PSAP callback and caller >> >> verification and identification to the PSAP. To resolve this >> category >> >> either significant changes to the framework document could be made >> or a >> >> disclaimer/applicability statement could be added stating that >> support >> >> of cellular wireless networks and their associated WLAN and Femto >> >> access points is not covered. >> >> >> >> Category (C) comprises concepts and capabilis in the draft that >> are >> >> either already part of the standardized solution for wireless >> networks >> >> or that might be added at a later time. Examples of the former >> include >> >> LoST, SIP location conveyance, general use of SIP, location for >> routing >> >> versus for dispatch, cellular positioning methods. Examples of the >> >> latter include use of location references and dereferencing and >> >> possible interworking between the current wireless network solutions >> >> (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. >> The >> >> presence of this category could be acknowledged by following the >> >> disclaimer for (B) with a statement that certain portions of the >> >> solution are expected to be incorporated into wireless networks now >> >> and/or in the future. >> >> >> >> We hope that these comments will be seen to be a useful addition to >> >> this review in the sense of enabling a more precise scoping for the >> >> framework document and we are willing to assist in providing wording >> >> for any disclaimer/applicability statement that the Ecrit working >> group >> >> may now deem fit to include. >> >> >> >> Kind Regards >> >> >> >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs >> (Qualcomm >> >> 3GPP2 TSG-X and TSG-C participant) >> >> >> >> PS this being sent on 2/4/09 at 11:50pm PST >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www.ietf.org/mailman/listinfo/ecrit >> > >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------------------= ----------------------- > 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://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.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] From sedge@qualcomm.com Fri Mar 6 20:26:50 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B595E3A683D for ; Fri, 6 Mar 2009 20:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.528 X-Spam-Level: X-Spam-Status: No, score=-103.528 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLOqyTNNg5qb for ; Fri, 6 Mar 2009 20:26:47 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id D67653A68CE for ; Fri, 6 Mar 2009 20:26:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1236400038; x=1267936038; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" Dawson,=20Martin"=20,=0D=0A=20 =20=20=20=20=20=20=20"Gabor.Bajko@nokia.com"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20"Winter bottom,=20James"=0D=0A=09 |CC:=20"ecrit@ietf.org"=20|Date:=20Fri, =206=20Mar=202009=2020:27:10=20-0800|Subject:=20RE:=20[Ec rit]=20Comments=20on=20Framework=20Draft|Thread-Topic:=20 [Ecrit]=20Comments=20on=20Framework=20Draft|Thread-Index: =20AcmdZjoOuohgihUhTAGl+xIzZYDEkgABM/qQAANbgBkAGD/o4AAM3G ZgADJfB4A=3D|Message-ID:=20<1288E74A73964940B132A0B9EA8D8 ABC5374A309@NASANEXMB04.na.qualcomm.com>|References:=20<1 288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qu alcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A 73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm. com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA 8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73 964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.co m><64147.24.154.127.233.1235746352.squirrel@www.brianrose n.net><7582BC68E4994F4ABF0BD4723975C3FA0D39534E@crexc41p> <1288E74A73964940B132A0B9EA8D8ABC5374A196@NASANEXMB04.na. qualcomm.com><96AD1EFB-0104-4B64-A94B-7A 1877F8ADC6@andrew.com>=0D=0A=09=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5545"=3B=20a=3D"16050008"; bh=M4NMYdXgYavugGdKtPvyy5V5CxP90Ns3XeODP7qEOAM=; b=wEwwLIOdzGgvZYV9xG1Y9gUJHM6MjKMeYn1YGSxmf868Xmfpz+YyOoWa p3V70SD9gVv5koRZWzv/5PcFxfciEYDg9/gdCnA6xL5xYrx92vsDxpEZq iadJLc7AoNvnqcqjBb7MFOK47YJvzXCAaXQ+sqg7aHtLaHU8v7n39RYkj w=; X-IronPort-AV: E=McAfee;i="5300,2777,5545"; a="16050008" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Mar 2009 20:27:13 -0800 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n274RDeb029584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Mar 2009 20:27:13 -0800 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n274RClt031295 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 6 Mar 2009 20:27:12 -0800 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Fri, 6 Mar 2009 20:27:12 -0800 From: "Edge, Stephen" To: "Dawson, Martin" , "Gabor.Bajko@nokia.com" , "Winterbottom, James" Date: Fri, 6 Mar 2009 20:27:10 -0800 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmdZjoOuohgihUhTAGl+xIzZYDEkgABM/qQAANbgBkAGD/o4AAM3GZgADJfB4A= Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5374A309@NASANEXMB04.na.qualcomm.com> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com><64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net><7582BC68E4994F4ABF0BD4723975C3FA0D39534E@crexc41p><1288E74A73964940B132A0B9EA8D8ABC5374A196@NASANEXMB04.na.qualcomm.com><96AD1EFB-0104-4B64-A94B-7A1877F8ADC6@andrew.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 04:26:50 -0000 Hi Martin I am trying to clear my Ecrit related backlog and now I have got to this me= ssage which I am answering even though not strictly addressed to me. (Hopef= ully Gabor will not mind.) Outside the 3GPP/3GPP2 "walled garden" (or 3GPP/3GPP2 "side of the wall"), = your comments make some sense. SUPL is not suitable right now as an LCP for= all emergency calls (e.g. for roamers as well as homers) if by LCP you mea= n a protocol enabling a device to obtain (configure) its own location in ad= vance of an emergency call and in some cases immediately after an emergency= call is invoked. But inside the walled garden (on the other side of the wall), an LCP is not= needed because the 3GPP/3GPP2 serving network can obtain location after an= emergency call is initiated using SUPL or a control plane solution. Furthe= r note that any fully 3GPP/3GPP2 capable device can assume this since it ca= n be a requirement on the 3GPP/3GPP2 network side (therefore no need for an= y discovery). Now recall we are supposed to be discussing whether or not the Ecrit soluti= on is globally suitable which means inside as well as outside of the walled= garden (on both sides of the wall). If the Ecrit solution remains unchange= d, then it suffers from all the drawbacks I already mentioned and have furt= her elaborated on. However, it could be changed to become more suitable and= one of the changes might be to relax the definition of what constitutes an= LCP such that SUPL can be included. This would improve suitability for 3GP= P/3GPP2 networks because it would avoid additional implementation for those= that will anyway be supporting SUPL. For the less normal case of access to= a 3GPP/3GPP2 network as an ISP (rather than as a VSP), something new would= be needed but that might also involve SUPL - e.g. support of SUPL in an 3G= PP/3GPP2 capable router which would enable a VSP E-SLP to obtain location f= or dispatch and possibly for routing. Kind Regards Stephen -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of D= awson, Martin Sent: Thursday, March 05, 2009 7:47 PM To: Gabor.Bajko@nokia.com; Winterbottom, James Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments on Framework Draft Gabor, I believe your first point was that HELD isn't suited to control plane. Prior to your sarcasm about the state of WiMAX deployment, James' point was simply that HELD is very well suited to control plane implementation and the WiMAX specification is evidence of that. A HELD-capable LIS is associated with the access network and can avail itself of any measurements that the access network has available. It's control plane because it doesn't rely on the measurements coming via the device (i.e. user plane). HELD allows for measurements obtained via the control plane and those from the device (user plane). Your criticism certainly applies to SUPL - but not to HELD. SUPL does not fit in with the ECRIT model because it is not a service which can be discovered and used in the network and, also, it cannot deliver location by reference and nor can it deliver location in civic address form. You can make SUPL work for emergency calls with a great deal of trouble. OMA added emergency service support in SUPL 2.0. The "E-SLP" that Stephen previously referred to being the case in point. However, the model of use is for the SLP to initiate the location procedure with the SET. It is an NI-LR mode query originated from the E-SLP and it is up to the SET to deal with the fact that it is getting an unsolicited SUPL INIT message from a previously unknown SLP. Apart from the obvious fact that an arbitrary VoIP service can't know anything about E-SLPs in an arbitrary access network, or the fact that the ECRIT model doesn't require a VSP to be involved at all, there is the simple fact that having the location platform initiate the location procedure is actually the opposite of what ECRIT describes for the emergency procedure. Nothing to do with a lack of professionalism I'm afraid. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Gabor.Bajko@nokia.com Sent: Friday, 6 March 2009 9:14 AM To: Winterbottom, James Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments on Framework Draft Who talked about LTE? The point is, that cellular networks provide connectivity to internet, and they'll be around for many years to come. And in those networks A-GPS combined with U-TDOA/AFLT is the positioning technology in use today, which is unlikely to be replaced in the near future as there is no better alternative around. I always found it unprofessional to not even mention these, but instead mandate dhcp, which has a very limited applicability. - gabor >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >ext Winterbottom, James >Sent: Thursday, March 05, 2009 1:55 AM >To: Bajko Gabor (Nokia-CIC/MtView) >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] Comments on Framework Draft > >There are certainly more WiMAX networks deployed at this point than LTE >networks... ;P > >But that aside, the experimental HELD location networks we have deployed >at the last 3 or so IETF meetings have all been control-plane and not >user-plane from a location determination perspective. > >Cheers >James > > > >-----Original Message----- >From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] >Sent: Thu 3/5/2009 2:25 AM >To: Winterbottom, James >Cc: sedge@qualcomm.com; bs7652@att.com; br@brianrosen.net; ecrit@ietf.org >Subject: RE: [Ecrit] Comments on Framework Draft > >Oh, I forgot about the abundance of deployed wimax networks. Huge >mistake, indeed. > >- gabor > > >-----Original Message----- > >From: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com] > >Sent: Wednesday, March 04, 2009 11:44 PM > >To: Bajko Gabor (Nokia-CIC/MtView) > >Cc: sedge@qualcomm.com; bs7652@att.com; br@brianrosen.net; >ecrit@ietf.org > >Subject: Re: [Ecrit] Comments on Framework Draft > > > >Gabor, > > > >You absolutey and totally wrong about HELD and control-plane. If > >anything, native HELD is best suited to control-plane location. Indeed > >in WiMAX it is the only means to invoke control-plane location. > > > >Cheers James > > > >Sent from my iPhone > > > >On 05/03/2009, at 5:07 PM, "Gabor.Bajko@nokia.com" > > > wrote: > > > >> Stephen, > >> > >> Thanks for pointing out these issues. If you look at the previous > >> versions of phoneBCP, you'll also see LLDP (which was developed for > >> fixed environment, like switches) on the list of mandatory LCPs. It > >> took 2 years (!) to take that out from there, so in that sense there > >> is some progress towards writing a more realistic set of >requirements. > >> > >> When it was requested to add SUPPL to the list, or to at least > >> mention that SUPPL is the one which is currently mostly used for > >> positioning (what an impertinent request it was to add to a document > >> intended to describe BEST Current Practices, the protocols which are > >> currently in use), the argument against it was that SUPPL requires > >> the existence of a subscription, while the internet is subscription > >> free. > >> > >> Meanwhile people refused to take a look at the applicability of a > >> DHCP based positioning method in today's world, where everything > >> tends to be mobile. > >> > >> An HTTP based protocol like HELD has the potential to offer solution > >> for many, but not all of the use cases, as it can deliver location > >> related measurement information to location servers. The cases when > >> HELD does not work is when positioning is done using network based > >> positioning methods involving control plane, like U-TDOA or AFLT. > >> But then again, these are the positioning technologies which are > >> currently used in indoor environments where (A-)GPS does not work. > >> Perhaps this is the reason why they are not mentioned in a Best > >> Current Practice document ... > >> > >> - Gabor > >> > >> > >>> -----Original Message----- > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>> Behalf Of > >>> ext Edge, Stephen > >>> Sent: Wednesday, March 04, 2009 6:20 PM > >>> To: Stark, Barbara; br@brianrosen.net > >>> Cc: ECRIT > >>> Subject: Re: [Ecrit] Comments on Framework Draft > >>> > >>> Barbara and others > >>> > >>> Thanks for the comments. > >>> > >>> When I look at the PhoneBCP I see that both HELD and DHCP are > >>> mandatory > >>> for the device whereas at least one of these is mandatory for the >AN. > >>> While I can also see that SUPL is not ruled out (though it is not > >>> mentioned or referenced), it appears to have been displaced by the > >>> HELD > >>> and DHCP requirements. On the other hand, many cellular networks >have > >>> already deployed or are in the process of deploying SUPL and I am >not > >>> aware of any that have deployed an accurate location capability >using > >>> HELD or DHCP. So I would like to know how you see the current > >>> requirements as being suitable - after all, they imply at the very > >>> least > >>> additional development and deployment on the part of network and > >>> device > >>> vendors and network operators, whereas if SUPL was one of the >defined > >>> LCPs, that additional development and deployment might be mostly > >>> avoided. > >>> This question would not be applicable with some additional scope > >>> limitation and so I had not previously raised it. But it is >certainly > >>> applicable in > >>> the context of the global scope that is being claimed by some > >>> responders. > >>> > >>> Kind Regards > >>> > >>> Stephen > >>> -----Original Message----- > >>> From: Stark, Barbara [mailto:bs7652@att.com] > >>> Sent: Friday, February 27, 2009 8:28 AM > >>> To: br@brianrosen.net; Edge, Stephen > >>> Cc: ECRIT > >>> Subject: RE: [Ecrit] Comments on Framework Draft > >>> > >>> Thank you Brian. This is well said [except you left out the fact >that > >>> ecrit also allows for devices to get their location through other > >>> mechanisms, such as GPS, SUPL, or other methods, and doesn't insist > >>> that > >>> the location be configured through DHCP or HELD]. > >>> > >>> I agree 100% that additional qualifications are unnecessary. >Service > >>> providers, vendors, national bodies dealing with emergency > >>> services, and > >>> regulators aren't stupid. Please trust us to figure out for >ourselves > >>> when/where/how to apply a "standard". There is no need to try to > >>> artificially limit or define scope, or to state the obvious (e.g., > >>> the > >>> architecture applies where it applies, and doesn't apply where it > >>> doesn't apply). We understand the role and scope of the IETF, and >the > >>> role and scope of 3GPP and 3GPP2. And all the other SDOs (and > >>> national > >>> bodies and regulatory agencies). SDOs need to offer architectures > >>> that > >>> apply within the area of applicability for that SDO, and are useful > >>> to > >>> potential implementers, and leave it to the SPs, national bodies >and > >>> regulators to decide which architectures and standards to use or to > >>> mandate within the scope of their network or jurisdiction. Again, >we > >>> aren't stupid. > >>> Barbara > >>> > >>> -----Original Message----- > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>> Behalf > >>> Of br@brianrosen.net > >>> Sent: Friday, February 27, 2009 9:53 AM > >>> To: Edge, Stephen > >>> Cc: ECRIT > >>> Subject: Re: [Ecrit] Comments on Framework Draft > >>> > >>> Stephen > >>> > >>> Like any standards organization, the IETF restricts it's scope. > >>> Generally, the scope is "the Internet", although we very often > >>> describe > >>> solutions that are explicitly designed for private IP networks as > >>> well > >>> as > >>> the Internet. We don't write standards for circuit switched > >>> networks, > >>> and > >>> it should be no surprise that the ecrit solution does not cater to >CS > >>> solutions. Nevertheless, we often try to make sure that our > >>> solutions > >>> harmonize reasonably well with existing solutions. > >>> > >>> Indeed, the ecrit solution clains global applicability to the > >>> Internet > >>> in > >>> general, and most private IP networks that can be interconnected to > >>> the > >>> Internet or to other IP networks via gateways. Looking at your > >>> list of > >>> problem areas: > >>>> - access to PSTN capable PSAPs > >>> This is out of scope for IETF. NENA has active work on this >subject. > >>> It > >>> seems straightforward to interwork ecrit compatible devices and > >>> networks > >>> to existing CS connected PSAPs. As you know, CS interconnects are > >>> very > >>> nation-specific, so the NENA work may not have general >applicability. > >>> However, it shows that it is possible to interwork. The NENA i2 > >>> work is > >>> also designed to take ecrit compatible devices and VSP networks, >and > >>> interwork them to the existing network. The VSP would direct the > >>> call > >>> to > >>> the VPC, which would provide the services it does now, using the > >>> device > >>> provided location for routing. This is important for smooth > >>> transition > >>> from existing PSAPs and VSPs to "next generation" PSAPs and VSPs. > >>>> - handover between different IP access networks including >different > >>>> types of access network > >>> In the ecrit solution, the access network the call is initiated on > >>> provides all the facilities needed for the device to initiate an > >>> emergency > >>> call. The call starts traversing it's normal call path, and > >>> eventually > >>> routes to the ESRP. Handoffs between IP networks should be > >>> transparent > >>> to > >>> this process, although we probably haven't done all the work we > >>> need to > >>> do > >>> for handoffs where the IP address as seen by the terminating >network > >>> changes. This would generally be true of all current SIP based >work. > >>>> - handover to/from circuit mode networks > >>> This would be out of scope for IETF. It's as applicable to a > >>> simple SIP > >>> call as it is a SIP emergency call, and there are no statements in > >>> any > >>> SIP > >>> documents on that subject. > >>>> - location for cellular access (and the requirement to support >LCPs > >>> that > >>>> will be useless for cellular access) > >>> Location for cellular access networks has been considered >carefully. > >>> Since cellular is a mobile network, the access network would pass >the > >>> device a Location-By-Reference URI, using either DHCP or HELD. > >>> Either > >>> protocol is suitable for cellular networks. As we have pointed out > >>> several times, cellular networks support raw data packet services > >>> upon > >>> which many different kinds of networks can be constructed. My >usual > >>> example is a large recreational vehicle traveling down a road with >a > >>> cellular data card plugged into a router to which a wired >(Ethernet) > >>> phone > >>> is connected. That phone must be able to make an emergency call, > >>> and it > >>> will get location from DHCP or HELD (or LLDP-MED). It is not aware > >>> of > >>> the > >>> cellular network, and doesn't know any cellular specific protocols. > >>> Cellular networks will have to support IETF location configuration > >>> protocols unless they actively prohibit examples like this, or they > >>> implement interworking between cellular-specific location protocols > >>> and > >>> DHCP or HELD in the data card. The ecrit standards permit proxy > >>> insertion > >>> of location, but, as above, we don't think that works in all cases. > >>>> - endpoint based location and routing for cellular access (issues > >>> here > >>>> are network and device loading as well as device impacts and > >>>> problems > >>>> with PSTN capable PSAPs) > >>> The "load" of using DHCP or HELD to get location and querying LoST >is > >>> pretty modest. The standards permit proxies to do this if the > >>> devices > >>> don't. As above, interwork functions to CS connected PSAPs is very > >>> feasible, and as above, cellular networks will have to support > >>> access to > >>> local LoST servers for devices that are connected to cellular > >>> networks > >>> and > >>> are ecrit compliant. > >>>> - support of unauthenticated users and users who can be > >>> authenticated > >>>> but are not permitted access/VSP service except for emergency >calls > >>> This is covered in the standards. None of the processes are > >>> dependent > >>> on > >>> authentication, although where it is possible, it's desirable so as > >>> to > >>> minimize fraudulent emergency calls > >>> Mechanisms for specific network authentication mechanisms are out >of > >>> scope, and, like SIP basic calling, are not usually mentioned in >IETF > >>> documents. > >>> > >>> Stephen, we've tried pretty hard to make sure this works for 3G/4G > >>> mobile > >>> networks. It's true that it doesn't do it the way 3GPP currently > >>> thinks > >>> it ought to work, but we claim they haven't thought through all the > >>> issues. While it would work, there are opportunities for > >>> improvement. > >>> We > >>> would be willing to do that if we could get the cooperation of >3GPP, > >>> which > >>> we have tried, and failed, to do. > >>> > >>> So, I think the documents do not need any qualification statements. > >>> > >>> Brian > >>> > >>>> Martin > >>>> > >>>> The 3GPP/3GPP2 solution has a defined restricted applicability > >>>> (mainly > >>> to > >>>> 3GPP/3GPP2 access networks where the serving network also acts as > >>>> the > >>> VSP) > >>>> and the specifications for it cover in detail all possible >scenarios > >>>> consistent with these restrictions so far as we are aware. > >>>> > >>>> The Ecrit solution seems to claim global applicability to all > >>>> types of > >>> IP > >>>> access (and the more that is said about this from Ecrit >participants > >>> the > >>>> more this gets emphasized) but does not cover in detail all >possible > >>>> scenarios (in some cases does not cover in any detail) which means > >>> that at > >>>> best the solution is incomplete and at worst intrinsically > >>> inapplicable to > >>>> some unstated set of scenarios. > >>>> > >>>> The missing, incomplete and problematic cases include the >following: > >>>> > >>>> - access to PSTN capable PSAPs > >>>> - handover between different IP access networks including >different > >>>> types of access network > >>>> - handover to/from circuit mode networks > >>>> - location for cellular access (and the requirement to support >LCPs > >>> that > >>>> will be useless for cellular access) > >>>> - endpoint based location and routing for cellular access (issues > >>> here > >>>> are network and device loading as well as device impacts and > >>>> problems > >>>> with PSTN capable PSAPs) > >>>> - support of unauthenticated users and users who can be > >>> authenticated > >>>> but are not permitted access/VSP service except for emergency >calls > >>>> > >>>> Stating that some of these cases are out of scope or referencing >an > >>>> incomplete and possibly questionable specification from some other > >>>> national SDO will not help the user who encounters such problems. > >>>> But > >>> it > >>>> would certainly help network operators and implementers to > >>>> acknowledge > >>>> their existence in one form or another because that would allow > >>>> better > >>>> planning of deployments and would help focus attention on finding > >>>> solutions (whether in IETF or elsewhere) for the missing cases. > >>>> > >>>> Please note that despite these drawbacks, I will acknowledge that > >>> Ecrit > >>>> does have a valuable solution that covers many scenarios not >covered > >>> by > >>>> 3GPP/3GPP2. It would be the delineation of these supported >scenarios > >>> (or > >>>> equivalently unsupported scenarios) in some applicability >statement > >>> that > >>>> would be particularly useful right now. > >>>> > >>>> Kind Regards > >>>> > >>>> Stephen > >>>> -----Original Message----- > >>>> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > >>>> Sent: Thursday, February 26, 2009 9:45 PM > >>>> To: Edge, Stephen; Richard Barnes > >>>> Cc: ECRIT > >>>> Subject: RE: [Ecrit] Comments on Framework Draft > >>>> > >>>> There's benefit in knowing the limitations of a framework, and >every > >>>> architecture makes certain assumptions. Let's examine them > >>>> though... > >>>> > >>>> The IETF might occasionally make the assumption that the standards > >>>> it > >>>> develops are for Internet devices. That assumption probably need > >>>> not > >>> be > >>>> stated explicitly. > >>>> > >>>> The ECRIT architecture relies on implementations of the protocols > >>>> that > >>> it > >>>> references. That is not extraordinary. A reliance on > >>>> implementation > >>> of > >>>> these protocols by endpoints, routing intermediaries and PSAPs > >>>> should > >>> not > >>>> need to be explained. > >>>> > >>>> So the assumptions are: > >>>> - the Internet > >>>> - solutions are implemented and deployed > >>>> - the end device is a key component > >>>> > >>>> Only that last element is particularly novel ... or not that much > >>> really. > >>>> It's a design choice. Unless you were thinking of trunking the > >>> voice > >>>> elsewhere. > >>>> > >>>> Of course, you're suggesting that the design choice was made in > >>> ignorance > >>>> of all the constraints. You're suggesting that - as a result - >the > >>> choice > >>>> is flawed and the solution is not going to work for cellular > >>>> services. > >>> We > >>>> disagree. The solution is a basis for emergency calling in _any_ >IP > >>>> network. > >>>> > >>>> Cheers, > >>>> Martin > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>> Behalf > >>>>> Of Edge, Stephen > >>>>> Sent: Friday, 27 February 2009 3:30 PM > >>>>> To: Richard Barnes > >>>>> Cc: 'ECRIT' > >>>>> Subject: Re: [Ecrit] Comments on Framework Draft > >>>>> > >>>>> Hi Richard > >>>>> > >>>>> Thanks for the comments. Your statement below that "SIP emergency > >>>>> calling works if all parties behave as specified in these (IETF > >>> Ecrit) > >>>>> documents" to some degree highlights the problems we are raising. > >>>>> The > >>>>> documents do contain a number of implicit and explicit > >>>>> restrictions - > >>>>> like IP capable PSAPs, global IP access (no islands of circuit >mode > >>>>> access for example), universal support of this solution by all > >>>>> access > >>>>> providers and VSPs (not much good if some opt for another >solution) > >>> and > >>>>> end system oriented location and routing capability - which > >>>>> together > >>>>> make them unsuitable (we believe) for cellular wireless networks. > >>>>> If > >>>>> these restrictions and assumptions were all made explicit > >>>>> upfront, it > >>>>> would to a large degree (and possibly completely) address our > >>> concerns. > >>>>> > >>>>> You are right in assuming another set of specifications for the > >>>>> 3GPP > >>>>> and 3GPP2 solution. The applicability of this solution is > >>>>> explicitly > >>>>> defined in TS 23.167 (or more exactly in an already agreed CR in > >>>>> contribution S2-090752 which will become part of 23.167 in a few > >>>>> more > >>>>> weeks) to cover the following access types: GPRS (UTRAN WCDMA), > >>> I-WLAN, > >>>>> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN > >>>>> (LTE). So there is a restriction and arbitrary internet access is > >>>>> not > >>>>> covered (yet) as I have stated before. > >>>>> > >>>>> Kind Regards > >>>>> > >>>>> Stephen > >>>>> -----Original Message----- > >>>>> From: Richard Barnes [mailto:rbarnes@bbn.com] > >>>>> Sent: Wednesday, February 25, 2009 6:30 PM > >>>>> To: Edge, Stephen > >>>>> Cc: Brian Rosen; 'ECRIT' > >>>>> Subject: Re: [Ecrit] Comments on Framework Draft > >>>>> > >>>>> Hi Stephen, > >>>>> > >>>>> I'm a little confused by the scope of what you're asking. The > >>>>> framework > >>>>> and phonebcp documents exist in order to describe the ECRIT > >>>>> solution: > >>>>> They say, in effect, "SIP emergency calling works if all parties > >>> behave > >>>>> as specified in these documents." > >>>>> > >>>>> As I understand what you're saying (and I'm by no means an expert > >>>>> in > >>>>> 3GPP), 3GPP specifies that one or more elements of this system > >>>>> behave > >>>>> differently. This simply means that 3GPP networks aren't >complying > >>>>> with > >>>>> these specs. Just like there's no disclaimer in RFC 791 (IPv4) > >>>>> that > >>>>> says "this doesn't work on X.25 networks", it's not clear to me > >>>>> that > >>> an > >>>>> analogous disclaimer is called for here. > >>>>> > >>>>> I presume there are similar documents describing how emergency > >>> calling > >>>>> works in 3GPP networks. Do they include notes saying that the >3GPP > >>>>> solution doesn't work in the broader Internet? > >>>>> > >>>>> --Richard > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Edge, Stephen wrote: > >>>>>> Brian > >>>>>> > >>>>>> First of all apologies for the likely lateness of this reply - I > >>>>> actually wrote it on 19 February in a 3GPP SA2 meeting in >Budapest > >>> but > >>>>> it seems unlikely that my VPN, Outlook server and WiFi access > >>>>> capability will cooperate together to get it sent until I return >to > >>> the > >>>>> office mid-next week. > >>>>>> > >>>>>> Anyhow thanks for your comments. There have actually been a >number > >>> of > >>>>> conference calls between IETF and 3GPP participants over the last > >>>>> couple of years at which common features like support of IP > >>>>> emergency > >>>>> calls were discussed and these could have been good forum for > >>>>> participants on either side to have raised the kinds of issues >you > >>>>> elaborate on below. Given that seems not so far to have happened, > >>>>> it > >>>>> could still be possible in future such calls. > >>>>>> > >>>>>> But the issues we are raising are not directly to do with >further > >>>>> aligning the 2 solutions or with the lack of this in the past. We > >>>>> are > >>>>> simply pointing out that the solutions are currently different >and > >>> that > >>>>> from a cellular wireless perspective, the Ecrit solution is not > >>>>> seen > >>> as > >>>>> suitable in all respects (for support of IP emergency calls > >>> originating > >>>>> from such access types). That is not just our point of view. >3GPP2 > >>> sent > >>>>> a liaison to Ecrit some months ago pointing out the same issues. > >>>>>> > >>>>>> So we are proposing that the Ecrit framework and phoneBCP spec.s > >>>>> include a statement acknowledging this - e.g. by referencing the > >>>>> alternative 3GPP/3GPP2 solution and indicating the IP access >types > >>> for > >>>>> which the Ecrit solution will work without limitation (or > >>> equivalently > >>>>> the access types where limitations are not ruled out). > >>>>>> > >>>>>> We are not proposing further modification and extension of the > >>> Ecrit > >>>>> solution - just pointing out that this would be needed (as with >the > >>>>> 3GPP/3GPP2 solution) to fully cover all types of access. > >>>>>> > >>>>>> Kind Regards > >>>>>> > >>>>>> Stephen > >>>>>> -----Original Message----- > >>>>>> From: Brian Rosen [mailto:br@brianrosen.net] > >>>>>> Sent: Wednesday, February 18, 2009 8:07 PM > >>>>>> To: Edge, Stephen; 'ECRIT' > >>>>>> Subject: RE: [Ecrit] Comments on Framework Draft > >>>>>> > >>>>>> I have bit my tongue on this one for a long time. > >>>>>> > >>>>>> Stephen, with respect, please go talk to 3GPP management and ask > >>> them > >>>>> why > >>>>>> there has been no participation in the ecrit effort despite > >>> multiple > >>>>> YEARS > >>>>>> of begging them to get involved. To put it frankly, 3GPP is >quite > >>>>> willing > >>>>>> to bully IETF into doing its work on its schedule, but cannot be > >>>>> bothered to > >>>>>> get work done it knows it will eventually have to do when the >IETF > >>>>> asks it > >>>>>> to do so. > >>>>>> > >>>>>> 3GPP understands the mess that is being created by not > >>> participating. > >>>>> They > >>>>>> know full well that when they finally get around to dealing with > >>>>>> PS > >>>>>> terminated emergency calls, that there will be a lot of >resistance > >>> to > >>>>>> changing fully specified and implemented standards to more >closely > >>>>> align > >>>>>> with 3GPP standards. I expect you will have several >interworking > >>>>> functions > >>>>>> to define and build. > >>>>>> > >>>>>> So, politely, please go away, we're finishing work we dearly > >>>>>> wanted > >>>>> you all > >>>>>> to be involved with for years, but you refused to do anything. > >>> It's > >>>>> too > >>>>>> late for this rev. > >>>>>> > >>>>>> Now, having said that, there are quite a few people who have > >>>>> participated in > >>>>>> the IETF work who are IMS aware and I believe that despite your > >>>>> fears, > >>>>>> everything you need is in the specs. The mechanisms we have > >>> defined > >>>>> provide > >>>>>> the ability for the network to insert location, recognize and >mark > >>>>> emergency > >>>>>> calls, and route on behalf of endpoints. An E-CSCF could quite > >>>>>> straightforwardly provide a SIP call towards an ecrit compatible > >>>>> PSAP. The > >>>>>> only not-quite-nice interwork would be from SUPL to HELD (or >SIP), > >>>>> but it's > >>>>>> pretty easy to do that. I'll also note that we have tried to >get > >>> OMA > >>>>> and > >>>>>> IETF to cooperate on location protocols, but we have been > >>>>> spectacularly > >>>>>> unsuccessful at that effort also. > >>>>>> > >>>>>> Brian > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > >>>>> Behalf > >>>>>>> Of Edge, Stephen > >>>>>>> Sent: Thursday, February 05, 2009 2:50 AM > >>>>>>> To: 'ECRIT' > >>>>>>> Subject: [Ecrit] Comments on Framework Draft > >>>>>>> > >>>>>>> All > >>>>>>> > >>>>>>> draft-ietf-ecrit-framework-07 is (as we see it) a mostly > >>> informative > >>>>>>> description of how terminals and networks should support > >>>>>>> emergency > >>>>>>> calls made over IP capable facilities to IP capable PSAPs. It > >>>>> appears > >>>>>>> intended to cover all types of access network - including fixed > >>>>> line, > >>>>>>> WiFi and cellular (e.g. examples involving each can be found > >>>>> throughout > >>>>>>> the draft). > >>>>>>> > >>>>>>> When we evaluated this with respect to support of wireless > >>> cellular > >>>>>>> access and WiFi access associated with a cellular operator >(e.g. > >>>>> WLAN > >>>>>>> or Femto cells integrated into a cellular network), we found >that > >>>>>>> certain portions of the draft exhibited one or more of the > >>> following > >>>>>>> characteristics: > >>>>>>> > >>>>>>> (A) Inconsistent with already standardized wireless >solutions > >>>>>>> > >>>>>>> (B) Inconsistent with essential wireless requirements and > >>>>>>> conventions > >>>>>>> > >>>>>>> (C) Already part of wireless standards or potentially part >of > >>>>>>> future standards > >>>>>>> > >>>>>>> (A) refers to all portions of the draft framework that differ > >>>>>>> from > >>>>> the > >>>>>>> requirements and procedures currently standardized for wireless > >>>>>>> emergency access by 3GPP, 3GPP2 and OMA. This is a plain > >>> difference > >>>>> of > >>>>>>> solution and could be resolved through support of both >solutions > >>> by > >>>>>>> terminals (with each solution being used according to the type >of > >>>>>>> access network and VSP) or could be resolved by supporting only > >>> one > >>>>>>> solution and accessing only the types of network supporting >that > >>>>>>> solution. To acknowledge this category, the framework document > >>> could > >>>>>>> reference the applicable wireless standards and point out that > >>> these > >>>>>>> are valid alternatives for wireless cellular based access. > >>>>>>> > >>>>>>> (B) refers to portions of the draft that would be unsuitable >for > >>>>>>> wireless networks even if no alternative solution existed > >>>>>>> together > >>>>> with > >>>>>>> other portions missing from the draft that would be needed to > >>> fully > >>>>>>> support wireless networks. Examples of the former include: (a) > >>>>> emphasis > >>>>>>> on endpoint derivation of location, performance of Lost query >and > >>>>>>> receipt of local dial strings; (b) restriction of LCPs to > >>> protocols > >>>>>>> that require terminal initiation (not allowing for network > >>>>> initiation > >>>>>>> as far as we can tell) and that include two LCPs (DHCP and >LLDP) > >>>>> that > >>>>>>> are not applicable to (not defined for) cellular access; and >(c) > >>> the > >>>>>>> requirement that a terminal or at least a LIS will update the > >>>>>>> PSAP > >>>>>>> whenever location changes. (a) is impractical due to network >and > >>>>>>> terminal loading consequences and failure to support non-IP > >>> capable > >>>>>>> PSAPs; (b) makes location verification and updated location > >>>>> provision > >>>>>>> to PSAPs difficult or impossible; while (c) is also >incompatible > >>>>> with > >>>>>>> support of existing non-IP capable PSAPs besides increasing > >>> terminal > >>>>>>> load and possibly interfering with optimum maintenance of the >RF > >>>>>>> connection (e.g. if a terminal has to tune away from the >serving > >>>>> base > >>>>>>> station or WLAN periodically to make location measurements). > >>>>> Examples > >>>>>>> of the latter include (d) absence of support for access to non- >IP > >>>>>>> capable PSAPs as already mentioned (e.g. to support E911 phase >2 > >>> in > >>>>> the > >>>>>>> US); (e) no support for handover from the IP to the circuit > >>>>>>> domain > >>>>> when > >>>>>>> a terminal loses (e.g. moves out of) RF coverage in the IP > >>>>>>> domain; > >>>>> and > >>>>>>> (f) no allowance for limited access modes wherein a terminal >may > >>>>> access > >>>>>>> a network only to place an emergency call with ensuing > >>> restrictions > >>>>> on > >>>>>>> (for example) location acquisition, PSAP callback and caller > >>>>>>> verification and identification to the PSAP. To resolve this > >>>>> category > >>>>>>> either significant changes to the framework document could be > >>>>>>> made > >>>>> or a > >>>>>>> disclaimer/applicability statement could be added stating that > >>>>> support > >>>>>>> of cellular wireless networks and their associated WLAN and >Femto > >>>>>>> access points is not covered. > >>>>>>> > >>>>>>> Category (C) comprises concepts and capabilities in the draft > >>>>>>> that > >>>>> are > >>>>>>> either already part of the standardized solution for wireless > >>>>> networks > >>>>>>> or that might be added at a later time. Examples of the former > >>>>> include > >>>>>>> LoST, SIP location conveyance, general use of SIP, location for > >>>>> routing > >>>>>>> versus for dispatch, cellular positioning methods. Examples of > >>>>>>> the > >>>>>>> latter include use of location references and dereferencing and > >>>>>>> possible interworking between the current wireless network > >>> solutions > >>>>>>> (in 3GPP, 3GPP2 and OMA) and the solution described in this > >>>>>>> draft. > >>>>> The > >>>>>>> presence of this category could be acknowledged by following >the > >>>>>>> disclaimer for (B) with a statement that certain portions of >the > >>>>>>> solution are expected to be incorporated into wireless networks > >>> now > >>>>>>> and/or in the future. > >>>>>>> > >>>>>>> We hope that these comments will be seen to be a useful >addition > >>> to > >>>>>>> this review in the sense of enabling a more precise scoping for > >>> the > >>>>>>> framework document and we are willing to assist in providing > >>> wording > >>>>>>> for any disclaimer/applicability statement that the Ecrit >working > >>>>> group > >>>>>>> may now deem fit to include. > >>>>>>> > >>>>>>> Kind Regards > >>>>>>> > >>>>>>> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs > >>>>> (Qualcomm > >>>>>>> 3GPP2 TSG-X and TSG-C participant) > >>>>>>> > >>>>>>> PS this being sent on 2/4/09 at 11:50pm PST > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Ecrit mailing list > >>>>>>> Ecrit@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Ecrit mailing list > >>>>>> Ecrit@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>>>> > >>>>> _______________________________________________ > >>>>> Ecrit mailing list > >>>>> Ecrit@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>> > >>>> > >>> --- > >>> ------------------------------------------------------------------- >-- > >>> ------------------------ > >>>> 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://www.ietf.org/mailman/listinfo/ecrit > >>>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www.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://www.ietf.org/mailman/listinfo/ecrit > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.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] > > > >----------------------------------------------------------------------- -- >----------------------- >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://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.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://www.ietf.org/mailman/listinfo/ecrit From root@core3.amsl.com Sat Mar 7 02:45:01 2009 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 479023A6987; Sat, 7 Mar 2009 02:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090307104501.479023A6987@core3.amsl.com> Date: Sat, 7 Mar 2009 02:45:01 -0800 (PST) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-sync-04.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 10:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements Author(s) : H. Schulzrinne, H. Tschofenig Filename : draft-ietf-ecrit-lost-sync-04.txt Pages : 24 Date : 2009-03-07 The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The main data structure, the element, used for encapsulating information about service boundaries is defined in the LoST protocol specification and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. This mechanism can be used for bulk exchange of elements between two entities. As such, this document can also be used without the LoST protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-lost-sync-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-07023120.I-D@ietf.org> --NextPart-- From Martin.Dawson@andrew.com Sun Mar 8 18:48:16 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FF0B3A6802 for ; Sun, 8 Mar 2009 18:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfclBlwDTeYk for ; Sun, 8 Mar 2009 18:48:13 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id AD9773A6B3C for ; Sun, 8 Mar 2009 18:47:51 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_08_21_08_10 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, 08 Mar 2009 21:08:10 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Mar 2009 20:48:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Mar 2009 20:48:21 -0500 Message-ID: In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5374A309@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmdZjoOuohgihUhTAGl+xIzZYDEkgABM/qQAANbgBkAGD/o4AAM3GZgADJfB4AAYGa2QA== References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com><64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net><7582BC68E4994F4ABF0BD4723975C3FA0D39534E@crexc41p><1288E74A73964940B132A0B9EA8D8ABC5374A196@NASANEXMB04.na.qualcomm.com><96AD1EFB-0104-4B64-A94B-7A1877F8ADC6@andrew.com> <1288E74 A73964940B132A0B9EA8D8ABC5374A309@NASANEXMB04.na.qualcomm.com> From: "Dawson, Martin" To: "Edge, Stephen" , , "Winterbottom, James" X-OriginalArrivalTime: 09 Mar 2009 01:48:22.0981 (UTC) FILETIME=[2168A750:01C9A059] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 01:48:16 -0000 Sticking with the pretence that this discussion can be taken at face=0D=0Av= alue...=0D=0A=0D=0AI found your comments puzzling Stephen. Juxtapose the fo= llowing:=0D=0A=0D=0A" SUPL is not suitable right now as an LCP..."=0D=0A=0D= =0A" But inside the walled garden (on the other side of the wall), an LCP=0D= =0Ais not needed..."=0D=0A=0D=0A"If the Ecrit solution remains unchanged, t= hen it suffers from all the=0D=0Adrawbacks I already mentioned... However, = it could be changed to become=0D=0Amore suitable [by relaxing] the definiti= on of what constitutes an LCP=0D=0Asuch that SUPL can be included."=0D=0A=0D= =0AI not only find the logic non-compelling, I can't find the logic. I can=0D= =0Aspot an apparent contradiction or two.=0D=0A=0D=0ACheers,=0D=0AMartin=0D= =0A=0D=0A-----Original Message-----=0D=0AFrom: Edge, Stephen [mailto:sedge@= qualcomm.com]=20=0D=0ASent: Saturday, 7 March 2009 3:27 PM=0D=0ATo: Dawson,= Martin; Gabor.Bajko@nokia.com; Winterbottom, James=0D=0ACc: ecrit@ietf.org=0D= =0ASubject: RE: [Ecrit] Comments on Framework Draft=0D=0A=0D=0AHi Martin=0D= =0A=0D=0AI am trying to clear my Ecrit related backlog and now I have got t= o this=0D=0Amessage which I am answering even though not strictly addressed= to me.=0D=0A(Hopefully Gabor will not mind.)=0D=0A=0D=0AOutside the 3GPP/3= GPP2 "walled garden" (or 3GPP/3GPP2 "side of the=0D=0Awall"), your comments= make some sense. SUPL is not suitable right now as=0D=0Aan LCP for all eme= rgency calls (e.g. for roamers as well as homers) if=0D=0Aby LCP you mean a= protocol enabling a device to obtain (configure) its=0D=0Aown location in = advance of an emergency call and in some cases=0D=0Aimmediately after an em= ergency call is invoked.=0D=0A=0D=0ABut inside the walled garden (on the ot= her side of the wall), an LCP is=0D=0Anot needed because the 3GPP/3GPP2 ser= ving network can obtain location=0D=0Aafter an emergency call is initiated = using SUPL or a control plane=0D=0Asolution. Further note that any fully 3G= PP/3GPP2 capable device can=0D=0Aassume this since it can be a requirement = on the 3GPP/3GPP2 network side=0D=0A(therefore no need for any discovery).=0D= =0A=0D=0ANow recall we are supposed to be discussing whether or not the Ecr= it=0D=0Asolution is globally suitable which means inside as well as outside= of=0D=0Athe walled garden (on both sides of the wall). If the Ecrit soluti= on=0D=0Aremains unchanged, then it suffers from all the drawbacks I already=0D= =0Amentioned and have further elaborated on. However, it could be changed=0D= =0Ato become more suitable and one of the changes might be to relax the=0D=0A= definition of what constitutes an LCP such that SUPL can be included.=0D=0A= This would improve suitability for 3GPP/3GPP2 networks because it would=0D=0A= avoid additional implementation for those that will anyway be supporting=0D= =0ASUPL. For the less normal case of access to a 3GPP/3GPP2 network as an=0D= =0AISP (rather than as a VSP), something new would be needed but that might=0D= =0Aalso involve SUPL - e.g. support of SUPL in an 3GPP/3GPP2 capable router=0D= =0Awhich would enable a VSP E-SLP to obtain location for dispatch and=0D=0A= possibly for routing.=0D=0A=0D=0AKind Regards=0D=0A=0D=0AStephen=0D=0A-----= Original Message-----=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounc= es@ietf.org] On Behalf=0D=0AOf Dawson, Martin=0D=0ASent: Thursday, March 05= , 2009 7:47 PM=0D=0ATo: Gabor.Bajko@nokia.com; Winterbottom, James=0D=0ACc:= ecrit@ietf.org=0D=0ASubject: Re: [Ecrit] Comments on Framework Draft=0D=0A=0D= =0AGabor,=0D=0A=0D=0AI believe your first point was that HELD isn't suited = to control plane.=0D=0APrior to your sarcasm about the state of WiMAX deplo= yment, James' point=0D=0Awas simply that HELD is very well suited to contro= l plane implementation=0D=0Aand the WiMAX specification is evidence of that= =2E=0D=0A=0D=0AA HELD-capable LIS is associated with the access network and= can avail=0D=0Aitself of any measurements that the access network has avai= lable. It's=0D=0Acontrol plane because it doesn't rely on the measurements = coming via the=0D=0Adevice (i.e. user plane). HELD allows for measurements = obtained via the=0D=0Acontrol plane and those from the device (user plane).=0D= =0A=0D=0AYour criticism certainly applies to SUPL - but not to HELD.=0D=0A=0D= =0ASUPL does not fit in with the ECRIT model because it is not a service=0D= =0Awhich can be discovered and used in the network and, also, it cannot=0D=0A= deliver location by reference and nor can it deliver location in civic=0D=0A= address form.=0D=0A=0D=0AYou can make SUPL work for emergency calls with a = great deal of trouble.=0D=0AOMA added emergency service support in SUPL 2.0= =2E The "E-SLP" that=0D=0AStephen previously referred to being the case in = point. However, the=0D=0Amodel of use is for the SLP to initiate the locati= on procedure with the=0D=0ASET. It is an NI-LR mode query originated from t= he E-SLP and it is up to=0D=0Athe SET to deal with the fact that it is gett= ing an unsolicited SUPL=0D=0AINIT message from a previously unknown SLP.=0D= =0A=0D=0AApart from the obvious fact that an arbitrary VoIP service can't k= now=0D=0Aanything about E-SLPs in an arbitrary access network, or the fact = that=0D=0Athe ECRIT model doesn't require a VSP to be involved at all, ther= e is=0D=0Athe simple fact that having the location platform initiate the lo= cation=0D=0Aprocedure is actually the opposite of what ECRIT describes for = the=0D=0Aemergency procedure. Nothing to do with a lack of professionalism = I'm=0D=0Aafraid.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Me= ssage-----=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On Behalf=0D=0AOf Gabor.Bajko@nokia.com=0D=0ASent: Friday, 6 March 2009 9= :14 AM=0D=0ATo: Winterbottom, James=0D=0ACc: ecrit@ietf.org=0D=0ASubject: R= e: [Ecrit] Comments on Framework Draft=0D=0A=0D=0AWho talked about LTE=3F=0D= =0AThe point is, that cellular networks provide connectivity to internet,=0D= =0Aand they'll be around for many years to come.=0D=0AAnd in those networks= A-GPS combined with U-TDOA/AFLT is the positioning=0D=0Atechnology in use = today, which is unlikely to be replaced in the near=0D=0Afuture as there is= no better alternative around. I always found it=0D=0Aunprofessional to not= even mention these, but instead mandate dhcp,=0D=0Awhich has a very limite= d applicability.=0D=0A=0D=0A- gabor=0D=0A=0D=0A=0D=0A >-----Original Messa= ge-----=0D=0A >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On=0D=0ABehalf Of=0D=0A >ext Winterbottom, James=0D=0A >Sent: Thursday,= March 05, 2009 1:55 AM=0D=0A >To: Bajko Gabor (Nokia-CIC/MtView)=0D=0A >= Cc: ecrit@ietf.org=0D=0A >Subject: Re: [Ecrit] Comments on Framework Draft=0D= =0A >=0D=0A >There are certainly more WiMAX networks deployed at this poi= nt than=0D=0ALTE=0D=0A >networks... ;P=0D=0A >=0D=0A >But that aside, th= e experimental HELD location networks we have=0D=0Adeployed=0D=0A >at the = last 3 or so IETF meetings have all been control-plane and not=0D=0A >user= -plane from a location determination perspective.=0D=0A >=0D=0A >Cheers=0D= =0A >James=0D=0A >=0D=0A >=0D=0A >=0D=0A >-----Original Message-----=0D= =0A >From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]=0D=0A >Se= nt: Thu 3/5/2009 2:25 AM=0D=0A >To: Winterbottom, James=0D=0A >Cc: sedge@= qualcomm.com; bs7652@att.com; br@brianrosen.net;=0D=0Aecrit@ietf.org=0D=0A = >Subject: RE: [Ecrit] Comments on Framework Draft=0D=0A >=0D=0A >Oh, I f= orgot about the abundance of deployed wimax networks. Huge=0D=0A >mistake,= indeed.=0D=0A >=0D=0A >- gabor=0D=0A >=0D=0A > >-----Original Message= -----=0D=0A > >From: ext Winterbottom, James=0D=0A[mailto:James.Winterbot= tom@andrew.com]=0D=0A > >Sent: Wednesday, March 04, 2009 11:44 PM=0D=0A = > >To: Bajko Gabor (Nokia-CIC/MtView)=0D=0A > >Cc: sedge@qualcomm.com; b= s7652@att.com; br@brianrosen.net;=0D=0A >ecrit@ietf.org=0D=0A > >Subject= : Re: [Ecrit] Comments on Framework Draft=0D=0A > >=0D=0A > >Gabor,=0D=0A= > >=0D=0A > >You absolutey and totally wrong about HELD and control-pl= ane. If=0D=0A > >anything, native HELD is best suited to control-plane lo= cation.=0D=0AIndeed=0D=0A > >in WiMAX it is the only means to invoke cont= rol-plane location.=0D=0A > >=0D=0A > >Cheers James=0D=0A > >=0D=0A = > >Sent from my iPhone=0D=0A > >=0D=0A > >On 05/03/2009, at 5:07 PM, "= Gabor.Bajko@nokia.com"=0D=0A > > > wrote:=0D= =0A > >=0D=0A > >> Stephen,=0D=0A > >>=0D=0A > >> Thanks for pointi= ng out these issues. If you look at the=0D=0Aprevious=0D=0A > >> versions= of phoneBCP, you'll also see LLDP (which was developed=0D=0Afor=0D=0A > = >> fixed environment, like switches) on the list of mandatory LCPs.=0D=0AIt=0D= =0A > >> took 2 years (!) to take that out from there, so in that sense=0D= =0Athere=0D=0A > >> is some progress towards writing a more realistic set= of=0D=0A >requirements.=0D=0A > >>=0D=0A > >> When it was requested t= o add SUPPL to the list, or to at least=0D=0A > >> mention that SUPPL is = the one which is currently mostly used for=0D=0A > >> positioning (what a= n impertinent request it was to add to a=0D=0Adocument=0D=0A > >> intende= d to describe BEST Current Practices, the protocols which=0D=0Aare=0D=0A >= >> currently in use), the argument against it was that SUPPL=0D=0Arequire= s=0D=0A > >> the existence of a subscription, while the internet is=0D=0A= subscription=0D=0A > >> free.=0D=0A > >>=0D=0A > >> Meanwhile people = refused to take a look at the applicability of=0D=0Aa=0D=0A > >> DHCP bas= ed positioning method in today's world, where everything=0D=0A > >> tends= to be mobile.=0D=0A > >>=0D=0A > >> An HTTP based protocol like HELD h= as the potential to offer=0D=0Asolution=0D=0A > >> for many, but not all = of the use cases, as it can deliver=0D=0Alocation=0D=0A > >> related meas= urement information to location servers. The cases=0D=0Awhen=0D=0A > >> H= ELD does not work is when positioning is done using network=0D=0Abased=0D=0A= > >> positioning methods involving control plane, like U-TDOA or=0D=0AAF= LT.=0D=0A > >> But then again, these are the positioning technologies whi= ch are=0D=0A > >> currently used in indoor environments where (A-)GPS doe= s not=0D=0Awork.=0D=0A > >> Perhaps this is the reason why they are not m= entioned in a Best=0D=0A > >> Current Practice document ...=0D=0A > >>=0D= =0A > >> - Gabor=0D=0A > >>=0D=0A > >>=0D=0A > >>> -----Original Me= ssage-----=0D=0A > >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces= @ietf.org] On=0D=0A > >>> Behalf Of=0D=0A > >>> ext Edge, Stephen=0D=0A= > >>> Sent: Wednesday, March 04, 2009 6:20 PM=0D=0A > >>> To: Stark, B= arbara; br@brianrosen.net=0D=0A > >>> Cc: ECRIT=0D=0A > >>> Subject: Re= : [Ecrit] Comments on Framework Draft=0D=0A > >>>=0D=0A > >>> Barbara a= nd others=0D=0A > >>>=0D=0A > >>> Thanks for the comments.=0D=0A > >>= >=0D=0A > >>> When I look at the PhoneBCP I see that both HELD and DHCP a= re=0D=0A > >>> mandatory=0D=0A > >>> for the device whereas at least on= e of these is mandatory for=0D=0Athe=0D=0A >AN.=0D=0A > >>> While I can = also see that SUPL is not ruled out (though it is=0D=0Anot=0D=0A > >>> me= ntioned or referenced), it appears to have been displaced by=0D=0Athe=0D=0A= > >>> HELD=0D=0A > >>> and DHCP requirements. On the other hand, many = cellular=0D=0Anetworks=0D=0A >have=0D=0A > >>> already deployed or are i= n the process of deploying SUPL and I=0D=0Aam=0D=0A >not=0D=0A > >>> awa= re of any that have deployed an accurate location capability=0D=0A >using=0D= =0A > >>> HELD or DHCP. So I would like to know how you see the current=0D= =0A > >>> requirements as being suitable - after all, they imply at the=0D= =0Avery=0D=0A > >>> least=0D=0A > >>> additional development and deploy= ment on the part of network=0D=0Aand=0D=0A > >>> device=0D=0A > >>> ven= dors and network operators, whereas if SUPL was one of the=0D=0A >defined=0D= =0A > >>> LCPs, that additional development and deployment might be=0D=0A= mostly=0D=0A > >>> avoided.=0D=0A > >>> This question would not be appl= icable with some additional=0D=0Ascope=0D=0A > >>> limitation and so I ha= d not previously raised it. But it is=0D=0A >certainly=0D=0A > >>> appli= cable in=0D=0A > >>> the context of the global scope that is being claime= d by some=0D=0A > >>> responders.=0D=0A > >>>=0D=0A > >>> Kind Regard= s=0D=0A > >>>=0D=0A > >>> Stephen=0D=0A > >>> -----Original Message--= ---=0D=0A > >>> From: Stark, Barbara [mailto:bs7652@att.com]=0D=0A > >>= > Sent: Friday, February 27, 2009 8:28 AM=0D=0A > >>> To: br@brianrosen.n= et; Edge, Stephen=0D=0A > >>> Cc: ECRIT=0D=0A > >>> Subject: RE: [Ecrit= ] Comments on Framework Draft=0D=0A > >>>=0D=0A > >>> Thank you Brian. = This is well said [except you left out the=0D=0Afact=0D=0A >that=0D=0A > = >>> ecrit also allows for devices to get their location through=0D=0Aother=0D= =0A > >>> mechanisms, such as GPS, SUPL, or other methods, and doesn't=0D= =0Ainsist=0D=0A > >>> that=0D=0A > >>> the location be configured throu= gh DHCP or HELD].=0D=0A > >>>=0D=0A > >>> I agree 100% that additional = qualifications are unnecessary.=0D=0A >Service=0D=0A > >>> providers, ve= ndors, national bodies dealing with emergency=0D=0A > >>> services, and=0D= =0A > >>> regulators aren't stupid. Please trust us to figure out for=0D=0A= >ourselves=0D=0A > >>> when/where/how to apply a "standard". There is n= o need to try=0D=0Ato=0D=0A > >>> artificially limit or define scope, or = to state the obvious=0D=0A(e.g.,=0D=0A > >>> the=0D=0A > >>> architectu= re applies where it applies, and doesn't apply where=0D=0Ait=0D=0A > >>> = doesn't apply). We understand the role and scope of the IETF,=0D=0Aand=0D=0A= >the=0D=0A > >>> role and scope of 3GPP and 3GPP2. And all the other SD= Os (and=0D=0A > >>> national=0D=0A > >>> bodies and regulatory agencies= ). SDOs need to offer=0D=0Aarchitectures=0D=0A > >>> that=0D=0A > >>> a= pply within the area of applicability for that SDO, and are=0D=0Auseful=0D=0A= > >>> to=0D=0A > >>> potential implementers, and leave it to the SPs, = national=0D=0Abodies=0D=0A >and=0D=0A > >>> regulators to decide which a= rchitectures and standards to use=0D=0Aor to=0D=0A > >>> mandate within t= he scope of their network or jurisdiction.=0D=0AAgain,=0D=0A >we=0D=0A > = >>> aren't stupid.=0D=0A > >>> Barbara=0D=0A > >>>=0D=0A > >>> -----= Original Message-----=0D=0A > >>> From: ecrit-bounces@ietf.org [mailto:ec= rit-bounces@ietf.org] On=0D=0A > >>> Behalf=0D=0A > >>> Of br@brianrose= n.net=0D=0A > >>> Sent: Friday, February 27, 2009 9:53 AM=0D=0A > >>> T= o: Edge, Stephen=0D=0A > >>> Cc: ECRIT=0D=0A > >>> Subject: Re: [Ecrit]= Comments on Framework Draft=0D=0A > >>>=0D=0A > >>> Stephen=0D=0A > = >>>=0D=0A > >>> Like any standards organization, the IETF restricts it's = scope.=0D=0A > >>> Generally, the scope is "the Internet", although we ve= ry often=0D=0A > >>> describe=0D=0A > >>> solutions that are explicitly= designed for private IP networks=0D=0Aas=0D=0A > >>> well=0D=0A > >>> = as=0D=0A > >>> the Internet. We don't write standards for circuit switch= ed=0D=0A > >>> networks,=0D=0A > >>> and=0D=0A > >>> it should be no = surprise that the ecrit solution does not cater=0D=0Ato=0D=0A >CS=0D=0A >= >>> solutions. Nevertheless, we often try to make sure that our=0D=0A >= >>> solutions=0D=0A > >>> harmonize reasonably well with existing solut= ions.=0D=0A > >>>=0D=0A > >>> Indeed, the ecrit solution clains global = applicability to the=0D=0A > >>> Internet=0D=0A > >>> in=0D=0A > >>> = general, and most private IP networks that can be=0D=0Ainterconnected to=0D= =0A > >>> the=0D=0A > >>> Internet or to other IP networks via gateways= =2E Looking at your=0D=0A > >>> list of=0D=0A > >>> problem areas:=0D=0A= > >>>> - access to PSTN capable PSAPs=0D=0A > >>> This is out of scop= e for IETF. NENA has active work on this=0D=0A >subject.=0D=0A > >>> It=0D= =0A > >>> seems straightforward to interwork ecrit compatible devices and=0D= =0A > >>> networks=0D=0A > >>> to existing CS connected PSAPs. As you = know, CS interconnects=0D=0Aare=0D=0A > >>> very=0D=0A > >>> nation-spe= cific, so the NENA work may not have general=0D=0A >applicability.=0D=0A = > >>> However, it shows that it is possible to interwork. The NENA=0D=0Ai= 2=0D=0A > >>> work is=0D=0A > >>> also designed to take ecrit compatibl= e devices and VSP=0D=0Anetworks,=0D=0A >and=0D=0A > >>> interwork them t= o the existing network. The VSP would direct=0D=0Athe=0D=0A > >>> call=0D= =0A > >>> to=0D=0A > >>> the VPC, which would provide the services it d= oes now, using=0D=0Athe=0D=0A > >>> device=0D=0A > >>> provided locatio= n for routing. This is important for smooth=0D=0A > >>> transition=0D=0A= > >>> from existing PSAPs and VSPs to "next generation" PSAPs and=0D=0AV= SPs.=0D=0A > >>>> - handover between different IP access networks includ= ing=0D=0A >different=0D=0A > >>>> types of access network=0D=0A > >>> = In the ecrit solution, the access network the call is initiated=0D=0Aon=0D=0A= > >>> provides all the facilities needed for the device to initiate=0D=0A= an=0D=0A > >>> emergency=0D=0A > >>> call. The call starts traversing= it's normal call path, and=0D=0A > >>> eventually=0D=0A > >>> routes t= o the ESRP. Handoffs between IP networks should be=0D=0A > >>> transpare= nt=0D=0A > >>> to=0D=0A > >>> this process, although we probably haven'= t done all the work we=0D=0A > >>> need to=0D=0A > >>> do=0D=0A > >>>= for handoffs where the IP address as seen by the terminating=0D=0A >netwo= rk=0D=0A > >>> changes. This would generally be true of all current SIP = based=0D=0A >work.=0D=0A > >>>> - handover to/from circuit mode network= s=0D=0A > >>> This would be out of scope for IETF. It's as applicable to= a=0D=0A > >>> simple SIP=0D=0A > >>> call as it is a SIP emergency cal= l, and there are no statements=0D=0Ain=0D=0A > >>> any=0D=0A > >>> SIP=0D= =0A > >>> documents on that subject.=0D=0A > >>>> - location for cellu= lar access (and the requirement to=0D=0Asupport=0D=0A >LCPs=0D=0A > >>> = that=0D=0A > >>>> will be useless for cellular access)=0D=0A > >>> Loca= tion for cellular access networks has been considered=0D=0A >carefully.=0D= =0A > >>> Since cellular is a mobile network, the access network would=0D= =0Apass=0D=0A >the=0D=0A > >>> device a Location-By-Reference URI, using= either DHCP or HELD.=0D=0A > >>> Either=0D=0A > >>> protocol is suitab= le for cellular networks. As we have pointed=0D=0Aout=0D=0A > >>> severa= l times, cellular networks support raw data packet=0D=0Aservices=0D=0A > = >>> upon=0D=0A > >>> which many different kinds of networks can be constr= ucted. My=0D=0A >usual=0D=0A > >>> example is a large recreational vehi= cle traveling down a road=0D=0Awith=0D=0A >a=0D=0A > >>> cellular data c= ard plugged into a router to which a wired=0D=0A >(Ethernet)=0D=0A > >>>= phone=0D=0A > >>> is connected. That phone must be able to make an emer= gency=0D=0Acall,=0D=0A > >>> and it=0D=0A > >>> will get location from = DHCP or HELD (or LLDP-MED). It is not=0D=0Aaware=0D=0A > >>> of=0D=0A >= >>> the=0D=0A > >>> cellular network, and doesn't know any cellular spe= cific=0D=0Aprotocols.=0D=0A > >>> Cellular networks will have to support = IETF location=0D=0Aconfiguration=0D=0A > >>> protocols unless they active= ly prohibit examples like this, or=0D=0Athey=0D=0A > >>> implement interw= orking between cellular-specific location=0D=0Aprotocols=0D=0A > >>> and=0D= =0A > >>> DHCP or HELD in the data card. The ecrit standards permit=0D=0A= proxy=0D=0A > >>> insertion=0D=0A > >>> of location, but, as above, we = don't think that works in all=0D=0Acases.=0D=0A > >>>> - endpoint based = location and routing for cellular access=0D=0A(issues=0D=0A > >>> here=0D= =0A > >>>> are network and device loading as well as device impacts and=0D= =0A > >>>> problems=0D=0A > >>>> with PSTN capable PSAPs)=0D=0A > >>>= The "load" of using DHCP or HELD to get location and querying=0D=0ALoST=0D= =0A >is=0D=0A > >>> pretty modest. The standards permit proxies to do t= his if the=0D=0A > >>> devices=0D=0A > >>> don't. As above, interwork = functions to CS connected PSAPs is=0D=0Avery=0D=0A > >>> feasible, and as= above, cellular networks will have to support=0D=0A > >>> access to=0D=0A= > >>> local LoST servers for devices that are connected to cellular=0D=0A= > >>> networks=0D=0A > >>> and=0D=0A > >>> are ecrit compliant.=0D=0A= > >>>> - support of unauthenticated users and users who can be=0D=0A >= >>> authenticated=0D=0A > >>>> but are not permitted access/VSP service= except for emergency=0D=0A >calls=0D=0A > >>> This is covered in the st= andards. None of the processes are=0D=0A > >>> dependent=0D=0A > >>> o= n=0D=0A > >>> authentication, although where it is possible, it's desirab= le=0D=0Aso as=0D=0A > >>> to=0D=0A > >>> minimize fraudulent emergency = calls=0D=0A > >>> Mechanisms for specific network authentication mechanis= ms are=0D=0Aout=0D=0A >of=0D=0A > >>> scope, and, like SIP basic calling= , are not usually mentioned=0D=0Ain=0D=0A >IETF=0D=0A > >>> documents.=0D= =0A > >>>=0D=0A > >>> Stephen, we've tried pretty hard to make sure thi= s works for=0D=0A3G/4G=0D=0A > >>> mobile=0D=0A > >>> networks. It's t= rue that it doesn't do it the way 3GPP=0D=0Acurrently=0D=0A > >>> thinks=0D= =0A > >>> it ought to work, but we claim they haven't thought through all=0D= =0Athe=0D=0A > >>> issues. While it would work, there are opportunities = for=0D=0A > >>> improvement.=0D=0A > >>> We=0D=0A > >>> would be will= ing to do that if we could get the cooperation of=0D=0A >3GPP,=0D=0A > >= >> which=0D=0A > >>> we have tried, and failed, to do.=0D=0A > >>>=0D=0A= > >>> So, I think the documents do not need any qualification=0D=0Astate= ments.=0D=0A > >>>=0D=0A > >>> Brian=0D=0A > >>>=0D=0A > >>>> Marti= n=0D=0A > >>>>=0D=0A > >>>> The 3GPP/3GPP2 solution has a defined restr= icted applicability=0D=0A > >>>> (mainly=0D=0A > >>> to=0D=0A > >>>> = 3GPP/3GPP2 access networks where the serving network also acts=0D=0Aas=0D=0A= > >>>> the=0D=0A > >>> VSP)=0D=0A > >>>> and the specifications for = it cover in detail all possible=0D=0A >scenarios=0D=0A > >>>> consistent= with these restrictions so far as we are aware.=0D=0A > >>>>=0D=0A > >= >>> The Ecrit solution seems to claim global applicability to all=0D=0A > = >>>> types of=0D=0A > >>> IP=0D=0A > >>>> access (and the more that is= said about this from Ecrit=0D=0A >participants=0D=0A > >>> the=0D=0A >= >>>> more this gets emphasized) but does not cover in detail all=0D=0A >= possible=0D=0A > >>>> scenarios (in some cases does not cover in any deta= il) which=0D=0Ameans=0D=0A > >>> that at=0D=0A > >>>> best the solution= is incomplete and at worst intrinsically=0D=0A > >>> inapplicable to=0D=0A= > >>>> some unstated set of scenarios.=0D=0A > >>>>=0D=0A > >>>> The= missing, incomplete and problematic cases include the=0D=0A >following:=0D= =0A > >>>>=0D=0A > >>>> - access to PSTN capable PSAPs=0D=0A > >>>> = - handover between different IP access networks including=0D=0A >differen= t=0D=0A > >>>> types of access network=0D=0A > >>>> - handover to/from= circuit mode networks=0D=0A > >>>> - location for cellular access (and = the requirement to=0D=0Asupport=0D=0A >LCPs=0D=0A > >>> that=0D=0A > >= >>> will be useless for cellular access)=0D=0A > >>>> - endpoint based l= ocation and routing for cellular access=0D=0A(issues=0D=0A > >>> here=0D=0A= > >>>> are network and device loading as well as device impacts and=0D=0A= > >>>> problems=0D=0A > >>>> with PSTN capable PSAPs)=0D=0A > >>>> = - support of unauthenticated users and users who can be=0D=0A > >>> authe= nticated=0D=0A > >>>> but are not permitted access/VSP service except for= emergency=0D=0A >calls=0D=0A > >>>>=0D=0A > >>>> Stating that some of= these cases are out of scope or=0D=0Areferencing=0D=0A >an=0D=0A > >>>>= incomplete and possibly questionable specification from some=0D=0Aother=0D= =0A > >>>> national SDO will not help the user who encounters such=0D=0Ap= roblems.=0D=0A > >>>> But=0D=0A > >>> it=0D=0A > >>>> would certainly= help network operators and implementers to=0D=0A > >>>> acknowledge=0D=0A= > >>>> their existence in one form or another because that would=0D=0Aal= low=0D=0A > >>>> better=0D=0A > >>>> planning of deployments and would = help focus attention on=0D=0Afinding=0D=0A > >>>> solutions (whether in I= ETF or elsewhere) for the missing=0D=0Acases.=0D=0A > >>>>=0D=0A > >>>>= Please note that despite these drawbacks, I will acknowledge=0D=0Athat=0D=0A= > >>> Ecrit=0D=0A > >>>> does have a valuable solution that covers man= y scenarios not=0D=0A >covered=0D=0A > >>> by=0D=0A > >>>> 3GPP/3GPP2.= It would be the delineation of these supported=0D=0A >scenarios=0D=0A > = >>> (or=0D=0A > >>>> equivalently unsupported scenarios) in some applica= bility=0D=0A >statement=0D=0A > >>> that=0D=0A > >>>> would be particu= larly useful right now.=0D=0A > >>>>=0D=0A > >>>> Kind Regards=0D=0A >= >>>>=0D=0A > >>>> Stephen=0D=0A > >>>> -----Original Message-----=0D=0A= > >>>> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=0D=0A >= >>>> Sent: Thursday, February 26, 2009 9:45 PM=0D=0A > >>>> To: Edge, S= tephen; Richard Barnes=0D=0A > >>>> Cc: ECRIT=0D=0A > >>>> Subject: RE:= [Ecrit] Comments on Framework Draft=0D=0A > >>>>=0D=0A > >>>> There's = benefit in knowing the limitations of a framework, and=0D=0A >every=0D=0A = > >>>> architecture makes certain assumptions. Let's examine them=0D=0A = > >>>> though...=0D=0A > >>>>=0D=0A > >>>> The IETF might occasionall= y make the assumption that the=0D=0Astandards=0D=0A > >>>> it=0D=0A > >= >>> develops are for Internet devices. That assumption probably=0D=0Aneed=0D= =0A > >>>> not=0D=0A > >>> be=0D=0A > >>>> stated explicitly.=0D=0A = > >>>>=0D=0A > >>>> The ECRIT architecture relies on implementations of = the=0D=0Aprotocols=0D=0A > >>>> that=0D=0A > >>> it=0D=0A > >>>> refe= rences. That is not extraordinary. A reliance on=0D=0A > >>>> implement= ation=0D=0A > >>> of=0D=0A > >>>> these protocols by endpoints, routing= intermediaries and PSAPs=0D=0A > >>>> should=0D=0A > >>> not=0D=0A > = >>>> need to be explained.=0D=0A > >>>>=0D=0A > >>>> So the assumption= s are:=0D=0A > >>>> - the Internet=0D=0A > >>>> - solutions are impleme= nted and deployed=0D=0A > >>>> - the end device is a key component=0D=0A = > >>>>=0D=0A > >>>> Only that last element is particularly novel ... or= not that=0D=0Amuch=0D=0A > >>> really.=0D=0A > >>>> It's a design cho= ice. Unless you were thinking of trunking=0D=0Athe=0D=0A > >>> voice=0D=0A= > >>>> elsewhere.=0D=0A > >>>>=0D=0A > >>>> Of course, you're sugges= ting that the design choice was made=0D=0Ain=0D=0A > >>> ignorance=0D=0A = > >>>> of all the constraints. You're suggesting that - as a result=0D=0A= -=0D=0A >the=0D=0A > >>> choice=0D=0A > >>>> is flawed and the solutio= n is not going to work for cellular=0D=0A > >>>> services.=0D=0A > >>> = We=0D=0A > >>>> disagree. The solution is a basis for emergency calling = in=0D=0A_any_=0D=0A >IP=0D=0A > >>>> network.=0D=0A > >>>>=0D=0A > >= >>> Cheers,=0D=0A > >>>> Martin=0D=0A > >>>>=0D=0A > >>>>=0D=0A > >= >>>> -----Original Message-----=0D=0A > >>>>> From: ecrit-bounces@ietf.or= g [mailto:ecrit-bounces@ietf.org]=0D=0AOn=0D=0A > >>> Behalf=0D=0A > >>= >>> Of Edge, Stephen=0D=0A > >>>>> Sent: Friday, 27 February 2009 3:30 PM=0D= =0A > >>>>> To: Richard Barnes=0D=0A > >>>>> Cc: 'ECRIT'=0D=0A > >>>>= > Subject: Re: [Ecrit] Comments on Framework Draft=0D=0A > >>>>>=0D=0A >= >>>>> Hi Richard=0D=0A > >>>>>=0D=0A > >>>>> Thanks for the comments.= Your statement below that "SIP=0D=0Aemergency=0D=0A > >>>>> calling work= s if all parties behave as specified in these=0D=0A(IETF=0D=0A > >>> Ecri= t)=0D=0A > >>>>> documents" to some degree highlights the problems we are=0D= =0Araising.=0D=0A > >>>>> The=0D=0A > >>>>> documents do contain a numb= er of implicit and explicit=0D=0A > >>>>> restrictions -=0D=0A > >>>>> = like IP capable PSAPs, global IP access (no islands of=0D=0Acircuit=0D=0A = >mode=0D=0A > >>>>> access for example), universal support of this soluti= on by=0D=0Aall=0D=0A > >>>>> access=0D=0A > >>>>> providers and VSPs (n= ot much good if some opt for another=0D=0A >solution)=0D=0A > >>> and=0D= =0A > >>>>> end system oriented location and routing capability - which=0D= =0A > >>>>> together=0D=0A > >>>>> make them unsuitable (we believe) fo= r cellular wireless=0D=0Anetworks.=0D=0A > >>>>> If=0D=0A > >>>>> these= restrictions and assumptions were all made explicit=0D=0A > >>>>> upfron= t, it=0D=0A > >>>>> would to a large degree (and possibly completely) add= ress our=0D=0A > >>> concerns.=0D=0A > >>>>>=0D=0A > >>>>> You are ri= ght in assuming another set of specifications for=0D=0Athe=0D=0A > >>>>> = 3GPP=0D=0A > >>>>> and 3GPP2 solution. The applicability of this solution= is=0D=0A > >>>>> explicitly=0D=0A > >>>>> defined in TS 23.167 (or mor= e exactly in an already agreed CR=0D=0Ain=0D=0A > >>>>> contribution S2-0= 90752 which will become part of 23.167 in a=0D=0Afew=0D=0A > >>>>> more=0D= =0A > >>>>> weeks) to cover the following access types: GPRS (UTRAN=0D=0A= WCDMA),=0D=0A > >>> I-WLAN,=0D=0A > >>>>> Fixed Broadband, CDMA2000 HRP= D, EPS UTRAN (WCDMA) and EPS=0D=0AE-UTRAN=0D=0A > >>>>> (LTE). So there i= s a restriction and arbitrary internet=0D=0Aaccess is=0D=0A > >>>>> not=0D= =0A > >>>>> covered (yet) as I have stated before.=0D=0A > >>>>>=0D=0A = > >>>>> Kind Regards=0D=0A > >>>>>=0D=0A > >>>>> Stephen=0D=0A > >>= >>> -----Original Message-----=0D=0A > >>>>> From: Richard Barnes [mailto= :rbarnes@bbn.com]=0D=0A > >>>>> Sent: Wednesday, February 25, 2009 6:30 P= M=0D=0A > >>>>> To: Edge, Stephen=0D=0A > >>>>> Cc: Brian Rosen; 'ECRIT= '=0D=0A > >>>>> Subject: Re: [Ecrit] Comments on Framework Draft=0D=0A >= >>>>>=0D=0A > >>>>> Hi Stephen,=0D=0A > >>>>>=0D=0A > >>>>> I'm a l= ittle confused by the scope of what you're asking.=0D=0AThe=0D=0A > >>>>>= framework=0D=0A > >>>>> and phonebcp documents exist in order to describ= e the ECRIT=0D=0A > >>>>> solution:=0D=0A > >>>>> They say, in effect, = "SIP emergency calling works if all=0D=0Aparties=0D=0A > >>> behave=0D=0A= > >>>>> as specified in these documents."=0D=0A > >>>>>=0D=0A > >>>>= > As I understand what you're saying (and I'm by no means an=0D=0Aexpert=0D= =0A > >>>>> in=0D=0A > >>>>> 3GPP), 3GPP specifies that one or more ele= ments of this=0D=0Asystem=0D=0A > >>>>> behave=0D=0A > >>>>> differentl= y. This simply means that 3GPP networks aren't=0D=0A >complying=0D=0A > = >>>>> with=0D=0A > >>>>> these specs. Just like there's no disclaimer i= n RFC 791=0D=0A(IPv4)=0D=0A > >>>>> that=0D=0A > >>>>> says "this doesn= 't work on X.25 networks", it's not clear to=0D=0Ame=0D=0A > >>>>> that=0D= =0A > >>> an=0D=0A > >>>>> analogous disclaimer is called for here.=0D=0A= > >>>>>=0D=0A > >>>>> I presume there are similar documents describing= how=0D=0Aemergency=0D=0A > >>> calling=0D=0A > >>>>> works in 3GPP net= works. Do they include notes saying that=0D=0Athe=0D=0A >3GPP=0D=0A > >= >>>> solution doesn't work in the broader Internet=3F=0D=0A > >>>>>=0D=0A= > >>>>> --Richard=0D=0A > >>>>>=0D=0A > >>>>>=0D=0A > >>>>>=0D=0A = > >>>>>=0D=0A > >>>>>=0D=0A > >>>>> Edge, Stephen wrote:=0D=0A > >>= >>>> Brian=0D=0A > >>>>>>=0D=0A > >>>>>> First of all apologies for the= likely lateness of this reply=0D=0A- I=0D=0A > >>>>> actually wrote it o= n 19 February in a 3GPP SA2 meeting in=0D=0A >Budapest=0D=0A > >>> but=0D= =0A > >>>>> it seems unlikely that my VPN, Outlook server and WiFi access=0D= =0A > >>>>> capability will cooperate together to get it sent until I=0D=0A= return=0D=0A >to=0D=0A > >>> the=0D=0A > >>>>> office mid-next week.=0D= =0A > >>>>>>=0D=0A > >>>>>> Anyhow thanks for your comments. There have= actually been a=0D=0A >number=0D=0A > >>> of=0D=0A > >>>>> conference= calls between IETF and 3GPP participants over the=0D=0Alast=0D=0A > >>>>= > couple of years at which common features like support of IP=0D=0A > >>>= >> emergency=0D=0A > >>>>> calls were discussed and these could have been= good forum for=0D=0A > >>>>> participants on either side to have raised = the kinds of=0D=0Aissues=0D=0A >you=0D=0A > >>>>> elaborate on below. Gi= ven that seems not so far to have=0D=0Ahappened,=0D=0A > >>>>> it=0D=0A = > >>>>> could still be possible in future such calls.=0D=0A > >>>>>>=0D=0A= > >>>>>> But the issues we are raising are not directly to do with=0D=0A= >further=0D=0A > >>>>> aligning the 2 solutions or with the lack of thi= s in the=0D=0Apast. We=0D=0A > >>>>> are=0D=0A > >>>>> simply pointing = out that the solutions are currently=0D=0Adifferent=0D=0A >and=0D=0A > >= >> that=0D=0A > >>>>> from a cellular wireless perspective, the Ecrit sol= ution is=0D=0Anot=0D=0A > >>>>> seen=0D=0A > >>> as=0D=0A > >>>>> sui= table in all respects (for support of IP emergency calls=0D=0A > >>> orig= inating=0D=0A > >>>>> from such access types). That is not just our point= of view.=0D=0A >3GPP2=0D=0A > >>> sent=0D=0A > >>>>> a liaison to Ecr= it some months ago pointing out the same=0D=0Aissues.=0D=0A > >>>>>>=0D=0A= > >>>>>> So we are proposing that the Ecrit framework and phoneBCP=0D=0A= spec.s=0D=0A > >>>>> include a statement acknowledging this - e.g. by ref= erencing=0D=0Athe=0D=0A > >>>>> alternative 3GPP/3GPP2 solution and indic= ating the IP access=0D=0A >types=0D=0A > >>> for=0D=0A > >>>>> which t= he Ecrit solution will work without limitation (or=0D=0A > >>> equivalent= ly=0D=0A > >>>>> the access types where limitations are not ruled out).=0D= =0A > >>>>>>=0D=0A > >>>>>> We are not proposing further modification a= nd extension of=0D=0Athe=0D=0A > >>> Ecrit=0D=0A > >>>>> solution - jus= t pointing out that this would be needed (as=0D=0Awith=0D=0A >the=0D=0A >= >>>>> 3GPP/3GPP2 solution) to fully cover all types of access.=0D=0A > = >>>>>>=0D=0A > >>>>>> Kind Regards=0D=0A > >>>>>>=0D=0A > >>>>>> Step= hen=0D=0A > >>>>>> -----Original Message-----=0D=0A > >>>>>> From: Bria= n Rosen [mailto:br@brianrosen.net]=0D=0A > >>>>>> Sent: Wednesday, Februa= ry 18, 2009 8:07 PM=0D=0A > >>>>>> To: Edge, Stephen; 'ECRIT'=0D=0A > >= >>>>> Subject: RE: [Ecrit] Comments on Framework Draft=0D=0A > >>>>>>=0D=0A= > >>>>>> I have bit my tongue on this one for a long time.=0D=0A > >>>= >>>=0D=0A > >>>>>> Stephen, with respect, please go talk to 3GPP manageme= nt and=0D=0Aask=0D=0A > >>> them=0D=0A > >>>>> why=0D=0A > >>>>>> the= re has been no participation in the ecrit effort despite=0D=0A > >>> mult= iple=0D=0A > >>>>> YEARS=0D=0A > >>>>>> of begging them to get involved= =2E To put it frankly, 3GPP is=0D=0A >quite=0D=0A > >>>>> willing=0D=0A= > >>>>>> to bully IETF into doing its work on its schedule, but=0D=0Acan= not be=0D=0A > >>>>> bothered to=0D=0A > >>>>>> get work done it knows = it will eventually have to do when=0D=0Athe=0D=0A >IETF=0D=0A > >>>>> as= ks it=0D=0A > >>>>>> to do so.=0D=0A > >>>>>>=0D=0A > >>>>>> 3GPP und= erstands the mess that is being created by not=0D=0A > >>> participating.=0D= =0A > >>>>> They=0D=0A > >>>>>> know full well that when they finally g= et around to dealing=0D=0Awith=0D=0A > >>>>>> PS=0D=0A > >>>>>> termina= ted emergency calls, that there will be a lot of=0D=0A >resistance=0D=0A = > >>> to=0D=0A > >>>>>> changing fully specified and implemented standar= ds to more=0D=0A >closely=0D=0A > >>>>> align=0D=0A > >>>>>> with 3GPP= standards. I expect you will have several=0D=0A >interworking=0D=0A > = >>>>> functions=0D=0A > >>>>>> to define and build.=0D=0A > >>>>>>=0D=0A= > >>>>>> So, politely, please go away, we're finishing work we dearly=0D= =0A > >>>>>> wanted=0D=0A > >>>>> you all=0D=0A > >>>>>> to be involv= ed with for years, but you refused to do=0D=0Aanything.=0D=0A > >>> It's=0D= =0A > >>>>> too=0D=0A > >>>>>> late for this rev.=0D=0A > >>>>>>=0D=0A= > >>>>>> Now, having said that, there are quite a few people who have=0D= =0A > >>>>> participated in=0D=0A > >>>>>> the IETF work who are IMS aw= are and I believe that despite=0D=0Ayour=0D=0A > >>>>> fears,=0D=0A > >= >>>>> everything you need is in the specs. The mechanisms we have=0D=0A >= >>> defined=0D=0A > >>>>> provide=0D=0A > >>>>>> the ability for the = network to insert location, recognize=0D=0Aand=0D=0A >mark=0D=0A > >>>>>= emergency=0D=0A > >>>>>> calls, and route on behalf of endpoints. An E-= CSCF could=0D=0Aquite=0D=0A > >>>>>> straightforwardly provide a SIP call= towards an ecrit=0D=0Acompatible=0D=0A > >>>>> PSAP. The=0D=0A > >>>>= >> only not-quite-nice interwork would be from SUPL to HELD (or=0D=0A >SIP= ),=0D=0A > >>>>> but it's=0D=0A > >>>>>> pretty easy to do that. I'll = also note that we have tried=0D=0Ato=0D=0A >get=0D=0A > >>> OMA=0D=0A >= >>>>> and=0D=0A > >>>>>> IETF to cooperate on location protocols, but w= e have been=0D=0A > >>>>> spectacularly=0D=0A > >>>>>> unsuccessful at = that effort also.=0D=0A > >>>>>>=0D=0A > >>>>>> Brian=0D=0A > >>>>>>=0D= =0A > >>>>>>=0D=0A > >>>>>>=0D=0A > >>>>>>> -----Original Message----= -=0D=0A > >>>>>>> From: ecrit-bounces@ietf.org=0D=0A[mailto:ecrit-bounces= @ietf.org] On=0D=0A > >>>>> Behalf=0D=0A > >>>>>>> Of Edge, Stephen=0D=0A= > >>>>>>> Sent: Thursday, February 05, 2009 2:50 AM=0D=0A > >>>>>>> To= : 'ECRIT'=0D=0A > >>>>>>> Subject: [Ecrit] Comments on Framework Draft=0D= =0A > >>>>>>>=0D=0A > >>>>>>> All=0D=0A > >>>>>>>=0D=0A > >>>>>>> d= raft-ietf-ecrit-framework-07 is (as we see it) a mostly=0D=0A > >>> infor= mative=0D=0A > >>>>>>> description of how terminals and networks should s= upport=0D=0A > >>>>>>> emergency=0D=0A > >>>>>>> calls made over IP cap= able facilities to IP capable PSAPs.=0D=0AIt=0D=0A > >>>>> appears=0D=0A = > >>>>>>> intended to cover all types of access network - including=0D=0A= fixed=0D=0A > >>>>> line,=0D=0A > >>>>>>> WiFi and cellular (e.g. examp= les involving each can be=0D=0Afound=0D=0A > >>>>> throughout=0D=0A > >= >>>>>> the draft).=0D=0A > >>>>>>>=0D=0A > >>>>>>> When we evaluated th= is with respect to support of wireless=0D=0A > >>> cellular=0D=0A > >>>= >>>> access and WiFi access associated with a cellular operator=0D=0A >(e.= g.=0D=0A > >>>>> WLAN=0D=0A > >>>>>>> or Femto cells integrated into a = cellular network), we=0D=0Afound=0D=0A >that=0D=0A > >>>>>>> certain por= tions of the draft exhibited one or more of the=0D=0A > >>> following=0D=0A= > >>>>>>> characteristics:=0D=0A > >>>>>>>=0D=0A > >>>>>>> (A) In= consistent with already standardized wireless=0D=0A >solutions=0D=0A > >= >>>>>>=0D=0A > >>>>>>> (B) Inconsistent with essential wireless requir= ements=0D=0Aand=0D=0A > >>>>>>> conventions=0D=0A > >>>>>>>=0D=0A > >= >>>>>> (C) Already part of wireless standards or potentially=0D=0Apart=0D= =0A >of=0D=0A > >>>>>>> future standards=0D=0A > >>>>>>>=0D=0A > >>>= >>>> (A) refers to all portions of the draft framework that=0D=0Adiffer=0D=0A= > >>>>>>> from=0D=0A > >>>>> the=0D=0A > >>>>>>> requirements and pr= ocedures currently standardized for=0D=0Awireless=0D=0A > >>>>>>> emergen= cy access by 3GPP, 3GPP2 and OMA. This is a plain=0D=0A > >>> difference=0D= =0A > >>>>> of=0D=0A > >>>>>>> solution and could be resolved through s= upport of both=0D=0A >solutions=0D=0A > >>> by=0D=0A > >>>>>>> termina= ls (with each solution being used according to the=0D=0Atype=0D=0A >of=0D=0A= > >>>>>>> access network and VSP) or could be resolved by supporting=0D=0A= only=0D=0A > >>> one=0D=0A > >>>>>>> solution and accessing only the ty= pes of network supporting=0D=0A >that=0D=0A > >>>>>>> solution. To ackno= wledge this category, the framework=0D=0Adocument=0D=0A > >>> could=0D=0A= > >>>>>>> reference the applicable wireless standards and point out=0D=0A= that=0D=0A > >>> these=0D=0A > >>>>>>> are valid alternatives for wirel= ess cellular based access.=0D=0A > >>>>>>>=0D=0A > >>>>>>> (B) refers t= o portions of the draft that would be=0D=0Aunsuitable=0D=0A >for=0D=0A > = >>>>>>> wireless networks even if no alternative solution existed=0D=0A >= >>>>>>> together=0D=0A > >>>>> with=0D=0A > >>>>>>> other portions mi= ssing from the draft that would be needed=0D=0Ato=0D=0A > >>> fully=0D=0A= > >>>>>>> support wireless networks. Examples of the former include:=0D=0A= (a)=0D=0A > >>>>> emphasis=0D=0A > >>>>>>> on endpoint derivation of lo= cation, performance of Lost=0D=0Aquery=0D=0A >and=0D=0A > >>>>>>> receip= t of local dial strings; (b) restriction of LCPs to=0D=0A > >>> protocols=0D= =0A > >>>>>>> that require terminal initiation (not allowing for network=0D= =0A > >>>>> initiation=0D=0A > >>>>>>> as far as we can tell) and that = include two LCPs (DHCP and=0D=0A >LLDP)=0D=0A > >>>>> that=0D=0A > >>>= >>>> are not applicable to (not defined for) cellular access;=0D=0Aand=0D=0A= >(c)=0D=0A > >>> the=0D=0A > >>>>>>> requirement that a terminal or a= t least a LIS will update=0D=0Athe=0D=0A > >>>>>>> PSAP=0D=0A > >>>>>>>= whenever location changes. (a) is impractical due to=0D=0Anetwork=0D=0A >= and=0D=0A > >>>>>>> terminal loading consequences and failure to support = non-IP=0D=0A > >>> capable=0D=0A > >>>>>>> PSAPs; (b) makes location ve= rification and updated location=0D=0A > >>>>> provision=0D=0A > >>>>>>>= to PSAPs difficult or impossible; while (c) is also=0D=0A >incompatible=0D= =0A > >>>>> with=0D=0A > >>>>>>> support of existing non-IP capable PSA= Ps besides increasing=0D=0A > >>> terminal=0D=0A > >>>>>>> load and pos= sibly interfering with optimum maintenance of=0D=0Athe=0D=0A >RF=0D=0A > = >>>>>>> connection (e.g. if a terminal has to tune away from the=0D=0A >s= erving=0D=0A > >>>>> base=0D=0A > >>>>>>> station or WLAN periodically = to make location=0D=0Ameasurements).=0D=0A > >>>>> Examples=0D=0A > >>>= >>>> of the latter include (d) absence of support for access to=0D=0Anon-=0D= =0A >IP=0D=0A > >>>>>>> capable PSAPs as already mentioned (e.g. to supp= ort E911=0D=0Aphase=0D=0A >2=0D=0A > >>> in=0D=0A > >>>>> the=0D=0A >= >>>>>>> US); (e) no support for handover from the IP to the circuit=0D=0A= > >>>>>>> domain=0D=0A > >>>>> when=0D=0A > >>>>>>> a terminal loses= (e.g. moves out of) RF coverage in the IP=0D=0A > >>>>>>> domain;=0D=0A = > >>>>> and=0D=0A > >>>>>>> (f) no allowance for limited access modes w= herein a=0D=0Aterminal=0D=0A >may=0D=0A > >>>>> access=0D=0A > >>>>>>>= a network only to place an emergency call with ensuing=0D=0A > >>> restr= ictions=0D=0A > >>>>> on=0D=0A > >>>>>>> (for example) location acquisi= tion, PSAP callback and=0D=0Acaller=0D=0A > >>>>>>> verification and iden= tification to the PSAP. To resolve=0D=0Athis=0D=0A > >>>>> category=0D=0A= > >>>>>>> either significant changes to the framework document could=0D=0A= be=0D=0A > >>>>>>> made=0D=0A > >>>>> or a=0D=0A > >>>>>>> disclaimer= /applicability statement could be added stating=0D=0Athat=0D=0A > >>>>> s= upport=0D=0A > >>>>>>> of cellular wireless networks and their associated= WLAN and=0D=0A >Femto=0D=0A > >>>>>>> access points is not covered.=0D=0A= > >>>>>>>=0D=0A > >>>>>>> Category (C) comprises concepts and capabili= ties in the=0D=0Adraft=0D=0A > >>>>>>> that=0D=0A > >>>>> are=0D=0A > = >>>>>>> either already part of the standardized solution for=0D=0Awireless=0D= =0A > >>>>> networks=0D=0A > >>>>>>> or that might be added at a later = time. Examples of the=0D=0Aformer=0D=0A > >>>>> include=0D=0A > >>>>>>>= LoST, SIP location conveyance, general use of SIP, location=0D=0Afor=0D=0A= > >>>>> routing=0D=0A > >>>>>>> versus for dispatch, cellular position= ing methods. Examples=0D=0Aof=0D=0A > >>>>>>> the=0D=0A > >>>>>>> latte= r include use of location references and dereferencing=0D=0Aand=0D=0A > >= >>>>>> possible interworking between the current wireless network=0D=0A > = >>> solutions=0D=0A > >>>>>>> (in 3GPP, 3GPP2 and OMA) and the solution = described in this=0D=0A > >>>>>>> draft.=0D=0A > >>>>> The=0D=0A > >>= >>>>> presence of this category could be acknowledged by=0D=0Afollowing=0D=0A= >the=0D=0A > >>>>>>> disclaimer for (B) with a statement that certain p= ortions=0D=0Aof=0D=0A >the=0D=0A > >>>>>>> solution are expected to be i= ncorporated into wireless=0D=0Anetworks=0D=0A > >>> now=0D=0A > >>>>>>>= and/or in the future.=0D=0A > >>>>>>>=0D=0A > >>>>>>> We hope that the= se comments will be seen to be a useful=0D=0A >addition=0D=0A > >>> to=0D= =0A > >>>>>>> this review in the sense of enabling a more precise scoping=0D= =0Afor=0D=0A > >>> the=0D=0A > >>>>>>> framework document and we are wi= lling to assist in=0D=0Aproviding=0D=0A > >>> wording=0D=0A > >>>>>>> f= or any disclaimer/applicability statement that the Ecrit=0D=0A >working=0D= =0A > >>>>> group=0D=0A > >>>>>>> may now deem fit to include.=0D=0A >= >>>>>>>=0D=0A > >>>>>>> Kind Regards=0D=0A > >>>>>>>=0D=0A > >>>>>>= > Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk=0D=0ABurroughs=0D=0A = > >>>>> (Qualcomm=0D=0A > >>>>>>> 3GPP2 TSG-X and TSG-C participant)=0D=0A= > >>>>>>>=0D=0A > >>>>>>> PS this being sent on 2/4/09 at 11:50pm PST=0D= =0A > >>>>>>>=0D=0A > >>>>>>> _________________________________________= ______=0D=0A > >>>>>>> Ecrit mailing list=0D=0A > >>>>>>> Ecrit@ietf.or= g=0D=0A > >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A > >= >>>>>=0D=0A > >>>>>> _______________________________________________=0D=0A= > >>>>>> Ecrit mailing list=0D=0A > >>>>>> Ecrit@ietf.org=0D=0A > >>= >>>> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A > >>>>>>=0D=0A > = >>>>> _______________________________________________=0D=0A > >>>>> Ecri= t mailing list=0D=0A > >>>>> Ecrit@ietf.org=0D=0A > >>>>> https://www.i= etf.org/mailman/listinfo/ecrit=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, proprietary, or otherwise private=0D=0Ainformation.=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 > >>> ------------------------=0D=0A > >>>> [mf2= ]=0D=0A > >>>> _______________________________________________=0D=0A > = >>>> Ecrit mailing list=0D=0A > >>>> Ecrit@ietf.org=0D=0A > >>>> https:= //www.ietf.org/mailman/listinfo/ecrit=0D=0A > >>>>=0D=0A > >>>=0D=0A >= >>> _______________________________________________=0D=0A > >>> Ecrit m= ailing list=0D=0A > >>> Ecrit@ietf.org=0D=0A > >>> https://www.ietf.org= /mailman/listinfo/ecrit=0D=0A > >>>=0D=0A > >>> *****=0D=0A > >>>=0D=0A= > >>> The information transmitted is intended only for the person or=0D=0A= > >>> entity to=0D=0A > >>> which it is addressed and may contain conf= idential,=0D=0Aproprietary,=0D=0A > >>> and/or=0D=0A > >>> privileged m= aterial. Any review, retransmission, dissemination=0D=0Aor=0D=0A > >>> ot= her=0D=0A > >>> use of, or taking of any action in reliance upon this=0D=0A= information=0D=0A >by=0D=0A > >>> persons or entities other than the int= ended recipient is=0D=0A > >>> prohibited. If=0D=0A > >>> you received = this in error, please contact the sender and=0D=0Adelete=0D=0A >the=0D=0A = > >>> material from all computers. GA621=0D=0A > >>>=0D=0A > >>>=0D=0A= > >>> _______________________________________________=0D=0A > >>> Ecri= t mailing list=0D=0A > >>> Ecrit@ietf.org=0D=0A > >>> https://www.ietf.= org/mailman/listinfo/ecrit=0D=0A > >> ___________________________________= ____________=0D=0A > >> Ecrit mailing list=0D=0A > >> Ecrit@ietf.org=0D= =0A > >> https://www.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 rece= ived it in error, please notify the sender=0D=0A > >immediately and delet= e the original. Any unauthorized use of=0D=0A > >this email is prohibite= d.=0D=0A >=0D=0A>---------------------------------------------------------= -------------=0D=0A >---=0D=0A > >-----------------------=0D=0A > >[mf= 2]=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, proprietary, or otherwise private information.=0D=0A= >If you have received it in error, please notify the sender=0D=0A >immed= iately and delete the original. Any unauthorized use of=0D=0A >this email= is prohibited.=0D=0A=0D=0A>-----------------------------------------------= ------------------------=0D=0A--=0D=0A >-----------------------=0D=0A >[m= f2]=0D=0A >=0D=0A >_______________________________________________=0D=0A = >Ecrit mailing list=0D=0A >Ecrit@ietf.org=0D=0A >https://www.ietf.org/ma= ilman/listinfo/ecrit=0D=0A_______________________________________________=0D= =0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman= /listinfo/ecrit=0D=0A=0D=0A------------------------------------------------= ------------------------=0D=0A------------------------=0D=0AThis message is= for the designated recipient only and may=0D=0Acontain privileged, proprie= tary, or otherwise private information.=0D=0AIf you have received it in err= or, please notify the sender=0D=0Aimmediately and delete the original. Any= unauthorized use of=0D=0Athis email is prohibited.=0D=0A------------------= ------------------------------------------------------=0D=0A---------------= ---------=0D=0A[mf2]=0D=0A=0D=0A___________________________________________= ____=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/= mailman/listinfo/ecrit=0D=0A=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0AThis message i= s for the designated recipient only and may=0D=0Acontain privileged, propri= etary, or otherwise private information. =20=0D=0AIf you have received it i= n error, please notify the sender=0D=0Aimmediately and delete the original.= Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A-------------= ---------------------------------------------------------------------------= --------=0D=0A[mf2]=0D=0A From Martin.Dawson@andrew.com Sun Mar 8 18:55:59 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D06BA3A6896 for ; Sun, 8 Mar 2009 18:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sefqbnY81Ee for ; Sun, 8 Mar 2009 18:55:59 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id CF1503A6802 for ; Sun, 8 Mar 2009 18:55:58 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_08_21_16_17 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, 08 Mar 2009 21:16:17 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Mar 2009 20:56:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Mar 2009 20:56:28 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: Acmei4kYJ1oDzWBhRKCOrMlj7ZtvgwBzaB1A References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E3B@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC5374A271@NASANEXMB04.na.qualcomm.com><048501c99e6b$f6f5e850$e4e1b8f0$@net> From: "Dawson, Martin" To: "Ted Hardie" , "Brian Rosen" , "Edge, Stephen" , "Winterbottom, James" , "ECRIT" X-OriginalArrivalTime: 09 Mar 2009 01:56:30.0568 (UTC) FILETIME=[44088680:01C9A05A] Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 01:55:59 -0000 I've already said why I think it would be quite a bad idea to put such a=0D= =0Acomment in PhoneBCP - never mind that it would be not appropriate and=0D= =0Awould beg the question of why every other alternative approach to=0D=0Ae= mergency communication architectures shouldn't also be cited.=0D=0A=0D=0AIf= you think it is simply not a big deal to include the comment then=0D=0Apre= sumably you also think it's not a big deal not to include the=0D=0Acomment.=0D= =0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFro= m: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0AOf= Ted Hardie=0D=0ASent: Saturday, 7 March 2009 5:44 AM=0D=0ATo: Brian Rosen;= Edge, Stephen; Winterbottom, James; 'ECRIT'=0D=0ASubject: Re: [Ecrit] Comm= ents on Framework Draft=0D=0A=0D=0AAt 6:58 AM -0800 3/6/09, Brian Rosen wro= te:=0D=0A>=0D=0A>The IETF is desirous of making 3GPP and IETF standards for= emergency=0D=0Acalling=0D=0A>more harmonious with each other. To do so, i= t is willing to negotiate,=0D=0Aand=0D=0A>in some circumstances to change i= ts standards, provided that 3GPP is=0D=0Awilling=0D=0A>to do the same.=20=0D= =0A=0D=0AUh, Brian, on what basis do you speak for the IETF in this manner=3F= The=0D=0Awillingness of the IETF to "negotiate" sounds more like the atti= tude of=0D=0Aa sovereign power (or at least an SDO with serious turf issues= ) than a=0D=0Atechnical body striving to do the right thing.=0D=0A=0D=0A=0D= =0A>The areas we would like to discuss include how location is=0D=0A>obtain= ed for routing and delivered to a PSAP, what the representation=0D=0Afor=0D= =0A>location (geo and civic, value and reference) is, how emergency calls=0D= =0Aare=0D=0A>recognized and routed and the specifics of the SIP signaling t= o=0D=0Aaccomplish=0D=0A>the above. The IETF and 3GPP have strived to not h= ave conflicts in=0D=0Aeach=0D=0A>other's standards, and emergency calling s= hould not be different.=0D=0A>=0D=0A>3GPP has explicitly decided NOT to ent= er such discussions and=0D=0Anegotiations=0D=0A>at this time.=0D=0A=0D=0AIn= dividuals with experience in this realm have spoken about the issue=0D=0Ain= the past and are raising the issue again. Given that the IETF has=0D=0Ahi= storically=0D=0Asaid that the *best* way for progress to occur was to have = technical=0D=0Acontributors contribute, I find this "send me a liaison stat= ement and=0D=0Awe'll=0D=0Atalk" attitude baffling and inappropriate.=0D=0A=0D= =0AAs for "agreeing to disagree", that's what I heard Stephen asking for=0D= =0Aall along; a statement in the document that described its applicability.=0D= =0AI found your description of the end-to-end networks with edge=0D=0Aintel= ligence=0D=0Aboth appropriate and accurate for the ECRIT case. Why not inc= lude that,=0D=0Aalong with a note saying that network architectures which r= ely upon=0D=0Anetwork support/command/control do not work using this set of=0D= =0Atechnologies=0D=0Aand aren't expected to develop in that direction=3F = Not including some=0D=0Astatement of applicability here seems more like an = attempt to control=0D=0Athe=0D=0Aoutcome by ignoring reality than anything = else, and I don't believe=0D=0Athat's appropriate.=0D=0A=0D=0A>In the absen= ce of official discussions and negotiations, I think our=0D=0A>documents ar= e complete, and accurate. There are no protocol police,=0D=0Aand the=0D=0A= >IETF is well aware that many vendors and network operators openly=0D=0Aign= ore=0D=0A>parts of its standards.=0D=0A=0D=0AThis sounds extraordinarily li= ke you believe that all vendors and=0D=0Anetwork=0D=0Aoperators *should* be= following IETF standards and that the wise,=0D=0Abenevolent=0D=0AIETF is s= addened by the wayward behavior of these naughty children.=0D=0A=0D=0AThis = is a technical body, trying to write specs that work in the real=0D=0Aworld= =2E=0D=0AIt is not divinely inspired, though I have written enough howlers = into=0D=0Amy own=0D=0Adocuments to wish it were. Having Stephen request we= recognize the=0D=0Aexistence of other models in a BCP document for a proce= ss that we all=0D=0Aagree *must work the maximum out of time* seems either = a good idea=0D=0Aor harmless. Do we really not have the humility to manage= that=3F=0D=0A=0D=0A=09=09=09=09Ted=0D=0A=0D=0A=0D=0A=0D=0A>Brian=0D=0A>=0D= =0A>-----=0D=0A_______________________________________________=0D=0AEcrit m= ailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman/listinfo/= ecrit=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 From br@brianrosen.net Mon Mar 9 06:07:29 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FE6828C131 for ; Mon, 9 Mar 2009 06:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3hExICR2Fi5 for ; Mon, 9 Mar 2009 06:07:28 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 08C153A6C97 for ; Mon, 9 Mar 2009 06:07:28 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LgfD0-0002DL-T4; Mon, 09 Mar 2009 08:07:55 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Edge, Stephen'" , "'Winterbottom, James'" , "'ECRIT'" References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a 8d01c991ff$fd063420$f7129c60$@net> <1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC53749E3B@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5374A271@NASANEXMB04.na.qualcomm.com> <048501c99e6b$f6f5e850$e4e1b8f0$@net> In-Reply-To: Date: Mon, 9 Mar 2009 09:08:04 -0400 Message-ID: <059a01c9a0b8$17290280$457b0780$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acmei4GskzRirZi/RPqTIMy/wuL8CgAAWBBg Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 13:07:29 -0000 Ted First of all, I proceeded the cited paragraph by: > Finally, we've said before, and I believe the offer stands (although I'm not >empowered to definitively say it): Then, there was an explicit effort to arrange a meeting with the relevant 3GPP and IETF people for the express purpose of seeing if we could move the two sets of standards closer together. That did not happen. That is what I was referring to. I believe, although I am not able to speak for the IETF that we are still interested. Discussions and negotiations are not liaisons. It was indeed talk: face to face meetings, that was proposed. 3GPP and IETF have done this in other areas in the past. I tried to argue that the ecrit architecture IS applicable to mobile networks such as 3GPP networks. The standards permit network insertion of location, and network routing (LoST query). I believe is the most appropriate architecture for IMS-like systems. Given the market direction of increasingly having the end device knowing its own location for various location based applications, with a large number of them not directly tied to the network operator (and thus being in the position that the endpoint tells the application where it is), I think they will eventually get there. Consider AOL/MSN/Yahoo IM. Just what part of the current IMS architecture is applicable to an emergency IM from AOL? Or Skype, or whatever Apple calls their iChat client in an iPhone when it eventually appears. The handset has to get it's location, and either run LoST itself, or the app server runs LoST for it. That's ecrit, and no amount of bashing what is currently written for emergency calls in IMS is applicable. The handset could use SUPL as an LCP, and the latest change to -phonebcp covers that. I'm reluctant to say that ecrit is not applicable to 3GPP/IMS. We indeed are going forward, knowing that 3GPP is unlikely to adopt the ecrit model any time soon. I think we often write a spec, believing it is the best solution, but knowing it is unlikely that some (or many) existing networks are likely to adopt it, at least right away. The document purports to be the BEST current practice, not the only practice. Every BCP and every IETF standard could have a statement that says "Various large networks may have their own solutions to the problem described, the IETF hereby acknowledges that there are other ways to solve the problem". I don't think that helps much. Brian -----Original Message----- From: Ted Hardie [mailto:hardie@qualcomm.com] Sent: Friday, March 06, 2009 1:44 PM To: Brian Rosen; Edge, Stephen; 'Winterbottom, James'; 'ECRIT' Subject: Re: [Ecrit] Comments on Framework Draft At 6:58 AM -0800 3/6/09, Brian Rosen wrote: > >The IETF is desirous of making 3GPP and IETF standards for emergency calling >more harmonious with each other. To do so, it is willing to negotiate, and >in some circumstances to change its standards, provided that 3GPP is willing >to do the same. Uh, Brian, on what basis do you speak for the IETF in this manner? The willingness of the IETF to "negotiate" sounds more like the attitude of a sovereign power (or at least an SDO with serious turf issues) than a technical body striving to do the right thing. >The areas we would like to discuss include how location is >obtained for routing and delivered to a PSAP, what the representation for >location (geo and civic, value and reference) is, how emergency calls are >recognized and routed and the specifics of the SIP signaling to accomplish >the above. The IETF and 3GPP have strived to not have conflicts in each >other's standards, and emergency calling should not be different. > >3GPP has explicitly decided NOT to enter such discussions and negotiations >at this time. Individuals with experience in this realm have spoken about the issue in the past and are raising the issue again. Given that the IETF has historically said that the *best* way for progress to occur was to have technical contributors contribute, I find this "send me a liaison statement and we'll talk" attitude baffling and inappropriate. As for "agreeing to disagree", that's what I heard Stephen asking for all along; a statement in the document that described its applicability. I found your description of the end-to-end networks with edge intelligence both appropriate and accurate for the ECRIT case. Why not include that, along with a note saying that network architectures which rely upon network support/command/control do not work using this set of technologies and aren't expected to develop in that direction? Not including some statement of applicability here seems more like an attempt to control the outcome by ignoring reality than anything else, and I don't believe that's appropriate. >In the absence of official discussions and negotiations, I think our >documents are complete, and accurate. There are no protocol police, and the >IETF is well aware that many vendors and network operators openly ignore >parts of its standards. This sounds extraordinarily like you believe that all vendors and network operators *should* be following IETF standards and that the wise, benevolent IETF is saddened by the wayward behavior of these naughty children. This is a technical body, trying to write specs that work in the real world. It is not divinely inspired, though I have written enough howlers into my own documents to wish it were. Having Stephen request we recognize the existence of other models in a BCP document for a process that we all agree *must work the maximum out of time* seems either a good idea or harmless. Do we really not have the humility to manage that? Ted >Brian > >----- From Hannes.Tschofenig@gmx.net Mon Mar 9 11:01:29 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E08F28C252 for ; Mon, 9 Mar 2009 11:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kREF6-5f-tE6 for ; Mon, 9 Mar 2009 11:01:28 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DD15828C21D for ; Mon, 9 Mar 2009 11:01:27 -0700 (PDT) Received: (qmail invoked by alias); 09 Mar 2009 18:01:59 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp012) with SMTP; 09 Mar 2009 19:01:59 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/CwNpUomPCMNIaTQMmbljolRNDAKzBsOvC5VJilB BKfLP5Vhb8H01e From: "Hannes Tschofenig" To: "'ECRIT'" Date: Mon, 9 Mar 2009 20:03:05 +0200 Message-ID: <004001c9a0e1$4c4b0340$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acmg4Uthyj+xooceRFSV0bHSULac4A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.74 Subject: [Ecrit] AGENDA X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 18:01:29 -0000 Here is the first version of the meeting agenda: http://www.ietf.org/proceedings/09mar/agenda/ecrit.txt This time we try an experiment by categorizing our documents into stages, based on what we proposed in http://tools.ietf.org/html/draft-tschofenig-rai-reducing-delays-00 I must admit that it looks interesting (particularly if we are able to follow a 3-stage process). Ciao Hannes & Marc From root@core3.amsl.com Mon Mar 9 14:45:01 2009 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6AFEB28C0D8; Mon, 9 Mar 2009 14:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090309214501.6AFEB28C0D8@core3.amsl.com> Date: Mon, 9 Mar 2009 14:45:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-local-emergency-rph-namespace-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 21:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : IANA Registering a SIP Resource Priority Header Namespace for Local Emergency Communications Author(s) : J. Polk Filename : draft-ietf-ecrit-local-emergency-rph-namespace-02.txt Pages : 8 Date : 2009-3-9 This document creates and IANA registers the new Session Initiation Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for local emergency usage to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-namespace-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-local-emergency-rph-namespace-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-3-9143409.I-D@ietf.org> --NextPart-- From drage@alcatel-lucent.com Mon Mar 9 14:45:34 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B8C728C29F for ; Mon, 9 Mar 2009 14:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwtoKmV0kF2I for ; Mon, 9 Mar 2009 14:45:32 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 5B3D928C1ED for ; Mon, 9 Mar 2009 14:45:30 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n29LjuN8011784 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 Mar 2009 22:45:56 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 9 Mar 2009 22:45:56 +0100 From: "DRAGE, Keith (Keith)" To: "Winterbottom, James" , "Edge, Stephen" , Brian Rosen , ECRIT Date: Mon, 9 Mar 2009 22:45:55 +0100 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwKeEe+gADZBfMABQDsYoAJCmxdw Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D674B1ACF0@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net> <1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 21:45:34 -0000 I've had this one sitting in my inbox for a while now thinking I ought to r= eply. The answer to your specific use case is: 1) If the VPN connection is at the IP level, then the mobile operator takes= no responsibility for emergency calls made over that IP connection, and it= is ip to the corporate network to deal with any emergency calls in an appr= opriate manner. 2) If the relationship to the corporate network is created at the SIP level= , e.g. via some form of business trunking arrangement, then it becomes the = responsibility of the local proxy provider to handle emergency calls. In th= is case, the business trunking documents I am familiar with essentially say= , make the emergency call as if you were a public network user (rather than= as a corporate network user), and then the rules specified by 3GPP apply. = Note that this is exactly the same thinking as when a 3GPP operator configu= res their roaming users to use a home network proxy rather than a local one= , and then tells them to reregister if they want to make an emergency call,= these things are all handled automatically within an IMS terminal. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Winterbottom, James > Sent: Thursday, February 26, 2009 4:48 AM > To: Edge, Stephen; Brian Rosen; ECRIT > Subject: Re: [Ecrit] Comments on Framework Draft >=20 > Hi Stephen, >=20 > It is a pity that you were not in the NENA location WG=20 > meeting in Orlando last week, as we had a very pertinent=20 > example put forward. >=20 > The example was a guy with a CDMA EVDO capable device, he is=20 > able to establish a VPN connection back into his corporate=20 > network and then make VoIP calls. The gentleman in question=20 > claims that he does this regularly. If he were to make an=20 > emergency call would it be following the ECRIT or 3GPP2 call flows? >=20 > The answer is that the call flow follows the ECRIT flow but=20 > the access is CDMA EVDO, clearly 3GPP2, and clearly cellular!=20 > Ipso facto ECRIT on cellular works! >=20 > I don't believe that anybody that understands the ECRIT=20 > architecture and has a notion of what products are being sold=20 > and used today can seriously suggest that the ECRIT=20 > architecture doesn't work for a cellular network. The fact=20 > that home routers with 3G Internet connections are being sold=20 > is an indicator that the 3G service is just another access to=20 > the Internet and that VoIP over 3G is being used and that=20 > ECRIT over 3G is quite possible. >=20 > Perhaps it would be pertinent at this time to ask precisely=20 > which bits of the ECRIT architecture you feel are unworkable=20 > in a 3GPP/2 network? >=20 > Cheers > James >=20 >=20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Edge, Stephen > Sent: Thursday, 26 February 2009 1:11 PM > To: Brian Rosen; 'ECRIT' > Subject: Re: [Ecrit] Comments on Framework Draft >=20 > Brian >=20 > First of all apologies for the likely lateness of this reply=20 > - I actually wrote it on 19 February in a 3GPP SA2 meeting in=20 > Budapest but it seems unlikely that my VPN, Outlook server=20 > and WiFi access capability will cooperate together to get it=20 > sent until I return to the office mid-next week. >=20 > Anyhow thanks for your comments. There have actually been a=20 > number of conference calls between IETF and 3GPP participants=20 > over the last couple of years at which common features like=20 > support of IP emergency calls were discussed and these could=20 > have been good forum for participants on either side to have=20 > raised the kinds of issues you elaborate on below. Given that=20 > seems not so far to have happened, it could still be possible=20 > in future such calls. >=20 > But the issues we are raising are not directly to do with=20 > further aligning the 2 solutions or with the lack of this in=20 > the past. We are simply pointing out that the solutions are=20 > currently different and that from a cellular wireless=20 > perspective, the Ecrit solution is not seen as suitable in=20 > all respects (for support of IP emergency calls originating=20 > from such access types). That is not just our point of view.=20 > 3GPP2 sent a liaison to Ecrit some months ago pointing out=20 > the same issues. >=20 > So we are proposing that the Ecrit framework and phoneBCP=20 > spec.s include a statement acknowledging this - e.g. by=20 > referencing the alternative 3GPP/3GPP2 solution and=20 > indicating the IP access types for which the Ecrit solution=20 > will work without limitation (or equivalently the access=20 > types where limitations are not ruled out). >=20 > We are not proposing further modification and extension of=20 > the Ecrit solution - just pointing out that this would be=20 > needed (as with the 3GPP/3GPP2 solution) to fully cover all=20 > types of access. >=20 > Kind Regards=20 >=20 > Stephen > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, February 18, 2009 8:07 PM > To: Edge, Stephen; 'ECRIT' > Subject: RE: [Ecrit] Comments on Framework Draft >=20 > I have bit my tongue on this one for a long time. >=20 > Stephen, with respect, please go talk to 3GPP management and=20 > ask them why there has been no participation in the ecrit=20 > effort despite multiple YEARS of begging them to get=20 > involved. To put it frankly, 3GPP is quite willing to bully=20 > IETF into doing its work on its schedule, but cannot be=20 > bothered to get work done it knows it will eventually have to=20 > do when the IETF asks it to do so. >=20 > 3GPP understands the mess that is being created by not=20 > participating. They know full well that when they finally=20 > get around to dealing with PS terminated emergency calls,=20 > that there will be a lot of resistance to changing fully=20 > specified and implemented standards to more closely align=20 > with 3GPP standards. I expect you will have several=20 > interworking functions to define and build. >=20 > So, politely, please go away, we're finishing work we dearly=20 > wanted you all to be involved with for years, but you refused=20 > to do anything. It's too late for this rev. >=20 > Now, having said that, there are quite a few people who have=20 > participated in the IETF work who are IMS aware and I believe=20 > that despite your fears, everything you need is in the specs.=20 > The mechanisms we have defined provide the ability for the=20 > network to insert location, recognize and mark emergency=20 > calls, and route on behalf of endpoints. An E-CSCF could=20 > quite straightforwardly provide a SIP call towards an ecrit=20 > compatible PSAP. The only not-quite-nice interwork would be=20 > from SUPL to HELD (or SIP), but it's pretty easy to do that. =20 > I'll also note that we have tried to get OMA and IETF to=20 > cooperate on location protocols, but we have been=20 > spectacularly unsuccessful at that effort also. >=20 > Brian >=20 > =20 >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > > Of Edge, Stephen > > Sent: Thursday, February 05, 2009 2:50 AM > > To: 'ECRIT' > > Subject: [Ecrit] Comments on Framework Draft > >=20 > > All > >=20 > > draft-ietf-ecrit-framework-07 is (as we see it) a mostly=20 > informative=20 > > description of how terminals and networks should support emergency=20 > > calls made over IP capable facilities to IP capable PSAPs.=20 > It appears=20 > > intended to cover all types of access network - including=20 > fixed line,=20 > > WiFi and cellular (e.g. examples involving each can be found=20 > > throughout the draft). > >=20 > > When we evaluated this with respect to support of wireless cellular=20 > > access and WiFi access associated with a cellular operator=20 > (e.g. WLAN=20 > > or Femto cells integrated into a cellular network), we found that=20 > > certain portions of the draft exhibited one or more of the following > > characteristics: > >=20 > > =A0=A0=A0 (A) Inconsistent with already standardized wireless solutions > >=20 > > =A0=A0=A0 (B) Inconsistent with essential wireless requirements and=20 > > conventions > >=20 > > =A0=A0=A0 (C) Already part of wireless standards or potentially part of= =20 > > future standards > >=20 > > (A) refers to all portions of the draft framework that=20 > differ from the=20 > > requirements and procedures currently standardized for wireless=20 > > emergency access by 3GPP, 3GPP2 and OMA. This is a plain=20 > difference of=20 > > solution and could be resolved through support of both solutions by=20 > > terminals (with each solution being used according to the type of=20 > > access network and VSP) or could be resolved by supporting only one=20 > > solution and accessing only the types of network supporting that=20 > > solution. To acknowledge this category, the framework=20 > document could=20 > > reference the applicable wireless standards and point out=20 > that these=20 > > are valid alternatives for wireless cellular based access. > >=20 > > (B) refers to portions of the draft that would be unsuitable for=20 > > wireless networks even if no alternative solution existed together=20 > > with other portions missing from the draft that would be needed to=20 > > fully support wireless networks. Examples of the former=20 > include: (a)=20 > > emphasis on endpoint derivation of location, performance of=20 > Lost query=20 > > and receipt of local dial strings; (b) restriction of LCPs to=20 > > protocols that require terminal initiation (not allowing=20 > for network=20 > > initiation as far as we can tell) and that include two LCPs=20 > (DHCP and=20 > > LLDP) that are not applicable to (not defined for) cellular access;=20 > > and (c) the requirement that a terminal or at least a LIS=20 > will update=20 > > the PSAP whenever location changes. (a) is impractical due=20 > to network=20 > > and terminal loading consequences and failure to support non-IP=20 > > capable PSAPs; (b) makes location verification and updated location=20 > > provision to PSAPs difficult or impossible; while (c) is also=20 > > incompatible with support of existing non-IP capable PSAPs besides=20 > > increasing terminal load and possibly interfering with optimum=20 > > maintenance of the RF connection (e.g. if a terminal has to=20 > tune away=20 > > from the serving base station or WLAN periodically to make location=20 > > measurements). Examples of the latter include (d) absence=20 > of support=20 > > for access to non-IP capable PSAPs as already mentioned (e.g. to=20 > > support E911 phase 2 in the US); (e) no support for=20 > handover from the=20 > > IP to the circuit domain when a terminal loses (e.g. moves=20 > out of) RF=20 > > coverage in the IP domain; and > > (f) no allowance for limited access modes wherein a terminal may=20 > > access a network only to place an emergency call with ensuing=20 > > restrictions on (for example) location acquisition, PSAP=20 > callback and=20 > > caller verification and identification to the PSAP. To resolve this=20 > > category either significant changes to the framework=20 > document could be=20 > > made or a disclaimer/applicability statement could be added stating=20 > > that support of cellular wireless networks and their=20 > associated WLAN=20 > > and Femto access points is not covered. > >=20 > > Category (C) comprises concepts and capabilities in the=20 > draft that are=20 > > either already part of the standardized solution for=20 > wireless networks=20 > > or that might be added at a later time. Examples of the=20 > former include=20 > > LoST, SIP location conveyance, general use of SIP, location for=20 > > routing versus for dispatch, cellular positioning methods.=20 > Examples of=20 > > the latter include use of location references and dereferencing and=20 > > possible interworking between the current wireless network=20 > solutions=20 > > (in 3GPP, 3GPP2 and OMA) and the solution described in this=20 > draft. The=20 > > presence of this category could be acknowledged by following the=20 > > disclaimer for (B) with a statement that certain portions of the=20 > > solution are expected to be incorporated into wireless networks now=20 > > and/or in the future. > >=20 > > We hope that these comments will be seen to be a useful addition to=20 > > this review in the sense of enabling a more precise scoping for the=20 > > framework document and we are willing to assist in=20 > providing wording=20 > > for any disclaimer/applicability statement that the Ecrit working=20 > > group may now deem fit to include. > >=20 > > Kind Regards > >=20 > > Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk=20 > Burroughs (Qualcomm > > 3GPP2 TSG-X and TSG-C participant) > >=20 > > PS this being sent on 2/4/09 at 11:50pm PST > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may=20 > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender=20 > immediately and delete the original. Any unauthorized use of=20 > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From drage@alcatel-lucent.com Mon Mar 9 14:46:23 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEDB83A6CAE for ; Mon, 9 Mar 2009 14:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.193 X-Spam-Level: X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asqUxtnkAvc1 for ; Mon, 9 Mar 2009 14:46:21 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 9378028C29E for ; Mon, 9 Mar 2009 14:46:16 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n29LkY8R012053 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 Mar 2009 22:46:34 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 9 Mar 2009 22:46:34 +0100 From: "DRAGE, Keith (Keith)" To: "Thomson, Martin" , "Edge, Stephen" , Richard Barnes Date: Mon, 9 Mar 2009 22:46:33 +0100 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmXuikRk+dIr3f0R02FPhxVSe0AlwA1eIWgAAJKN/ACCrAXIA== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D674B1ACF1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 21:46:23 -0000 That is making the assumption that IETF does not get sued when you try it o= n an phone connected to a 3GPP network and it fails to deliver it to a PSAP= . 3GPP operators's have no responsibility to deliver an IETF solution to thei= r end users. If IETF claims it should work, then they have to make it work,= or else be sued. Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Thomson, Martin > Sent: Friday, February 27, 2009 5:45 AM > To: Edge, Stephen; Richard Barnes > Cc: ECRIT > Subject: Re: [Ecrit] Comments on Framework Draft > > There's benefit in knowing the limitations of a framework, > and every architecture makes certain assumptions. Let's > examine them though... > > The IETF might occasionally make the assumption that the > standards it develops are for Internet devices. That > assumption probably need not be stated explicitly. > > The ECRIT architecture relies on implementations of the > protocols that it references. That is not extraordinary. A > reliance on implementation of these protocols by endpoints, > routing intermediaries and PSAPs should not need to be explained. > > So the assumptions are: > - the Internet > - solutions are implemented and deployed > - the end device is a key component > > Only that last element is particularly novel ... or not that > much really. It's a design choice. Unless you were > thinking of trunking the voice elsewhere. > > Of course, you're suggesting that the design choice was made > in ignorance of all the constraints. You're suggesting that > - as a result - the choice is flawed and the solution is not > going to work for cellular services. We disagree. The > solution is a basis for emergency calling in _any_ IP network. > > Cheers, > Martin > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Edge, Stephen > > Sent: Friday, 27 February 2009 3:30 PM > > To: Richard Barnes > > Cc: 'ECRIT' > > Subject: Re: [Ecrit] Comments on Framework Draft > > > > Hi Richard > > > > Thanks for the comments. Your statement below that "SIP emergency > > calling works if all parties behave as specified in these > (IETF Ecrit) > > documents" to some degree highlights the problems we are > raising. The > > documents do contain a number of implicit and explicit > restrictions - > > like IP capable PSAPs, global IP access (no islands of circuit mode > > access for example), universal support of this solution by > all access > > providers and VSPs (not much good if some opt for another solution) > > and end system oriented location and routing capability - which > > together make them unsuitable (we believe) for cellular wireless > > networks. If these restrictions and assumptions were all > made explicit > > upfront, it would to a large degree (and possibly > completely) address our concerns. > > > > You are right in assuming another set of specifications for > the 3GPP > > and 3GPP2 solution. The applicability of this solution is > explicitly > > defined in TS 23.167 (or more exactly in an already agreed CR in > > contribution S2-090752 which will become part of 23.167 in > a few more > > weeks) to cover the following access types: GPRS (UTRAN WCDMA), > > I-WLAN, Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS > > E-UTRAN (LTE). So there is a restriction and arbitrary > internet access > > is not covered (yet) as I have stated before. > > > > Kind Regards > > > > Stephen > > -----Original Message----- > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > Sent: Wednesday, February 25, 2009 6:30 PM > > To: Edge, Stephen > > Cc: Brian Rosen; 'ECRIT' > > Subject: Re: [Ecrit] Comments on Framework Draft > > > > Hi Stephen, > > > > I'm a little confused by the scope of what you're asking. The > > framework and phonebcp documents exist in order to describe > the ECRIT > > solution: > > They say, in effect, "SIP emergency calling works if all parties > > behave as specified in these documents." > > > > As I understand what you're saying (and I'm by no means an > expert in > > 3GPP), 3GPP specifies that one or more elements of this > system behave > > differently. This simply means that 3GPP networks aren't complying > > with these specs. Just like there's no disclaimer in RFC > 791 (IPv4) > > that says "this doesn't work on X.25 networks", it's not > clear to me > > that an analogous disclaimer is called for here. > > > > I presume there are similar documents describing how > emergency calling > > works in 3GPP networks. Do they include notes saying that the 3GPP > > solution doesn't work in the broader Internet? > > > > --Richard > > > > > > > > > > > > Edge, Stephen wrote: > > > Brian > > > > > > First of all apologies for the likely lateness of this reply - I > > actually wrote it on 19 February in a 3GPP SA2 meeting in > Budapest but > > it seems unlikely that my VPN, Outlook server and WiFi access > > capability will cooperate together to get it sent until I return to > > the office mid-next week. > > > > > > Anyhow thanks for your comments. There have actually been > a number > > > of > > conference calls between IETF and 3GPP participants over the last > > couple of years at which common features like support of IP > emergency > > calls were discussed and these could have been good forum for > > participants on either side to have raised the kinds of issues you > > elaborate on below. Given that seems not so far to have > happened, it > > could still be possible in future such calls. > > > > > > But the issues we are raising are not directly to do with further > > aligning the 2 solutions or with the lack of this in the > past. We are > > simply pointing out that the solutions are currently different and > > that from a cellular wireless perspective, the Ecrit > solution is not > > seen as suitable in all respects (for support of IP emergency calls > > originating from such access types). That is not just our point of > > view. 3GPP2 sent a liaison to Ecrit some months ago > pointing out the same issues. > > > > > > So we are proposing that the Ecrit framework and phoneBCP spec.s > > include a statement acknowledging this - e.g. by referencing the > > alternative 3GPP/3GPP2 solution and indicating the IP > access types for > > which the Ecrit solution will work without limitation (or > equivalently > > the access types where limitations are not ruled out). > > > > > > We are not proposing further modification and extension > of the Ecrit > > solution - just pointing out that this would be needed (as with the > > 3GPP/3GPP2 solution) to fully cover all types of access. > > > > > > Kind Regards > > > > > > Stephen > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Wednesday, February 18, 2009 8:07 PM > > > To: Edge, Stephen; 'ECRIT' > > > Subject: RE: [Ecrit] Comments on Framework Draft > > > > > > I have bit my tongue on this one for a long time. > > > > > > Stephen, with respect, please go talk to 3GPP management and ask > > > them > > why > > > there has been no participation in the ecrit effort > despite multiple > > YEARS > > > of begging them to get involved. To put it frankly, 3GPP is quite > > willing > > > to bully IETF into doing its work on its schedule, but cannot be > > bothered to > > > get work done it knows it will eventually have to do when the IETF > > asks it > > > to do so. > > > > > > 3GPP understands the mess that is being created by not > participating. > > They > > > know full well that when they finally get around to > dealing with PS > > > terminated emergency calls, that there will be a lot of > resistance > > > to changing fully specified and implemented standards to more > > > closely > > align > > > with 3GPP standards. I expect you will have several interworking > > functions > > > to define and build. > > > > > > So, politely, please go away, we're finishing work we > dearly wanted > > you all > > > to be involved with for years, but you refused to do > anything. It's > > too > > > late for this rev. > > > > > > Now, having said that, there are quite a few people who have > > participated in > > > the IETF work who are IMS aware and I believe that despite your > > fears, > > > everything you need is in the specs. The mechanisms we > have defined > > provide > > > the ability for the network to insert location, recognize and mark > > emergency > > > calls, and route on behalf of endpoints. An E-CSCF could quite > > > straightforwardly provide a SIP call towards an ecrit compatible > > PSAP. The > > > only not-quite-nice interwork would be from SUPL to HELD (or SIP), > > but it's > > > pretty easy to do that. I'll also note that we have tried to get > > > OMA > > and > > > IETF to cooperate on location protocols, but we have been > > spectacularly > > > unsuccessful at that effort also. > > > > > > Brian > > > > > > > > > > > >> -----Original Message----- > > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > > Behalf > > >> Of Edge, Stephen > > >> Sent: Thursday, February 05, 2009 2:50 AM > > >> To: 'ECRIT' > > >> Subject: [Ecrit] Comments on Framework Draft > > >> > > >> All > > >> > > >> draft-ietf-ecrit-framework-07 is (as we see it) a mostly > > >> informative description of how terminals and networks should > > >> support emergency calls made over IP capable facilities to IP > > >> capable PSAPs. It > > appears > > >> intended to cover all types of access network - including fixed > > line, > > >> WiFi and cellular (e.g. examples involving each can be found > > throughout > > >> the draft). > > >> > > >> When we evaluated this with respect to support of > wireless cellular > > >> access and WiFi access associated with a cellular operator (e.g. > > WLAN > > >> or Femto cells integrated into a cellular network), we > found that > > >> certain portions of the draft exhibited one or more of the > > >> following > > >> characteristics: > > >> > > >> (A) Inconsistent with already standardized wireless solutions > > >> > > >> (B) Inconsistent with essential wireless requirements and > > >> conventions > > >> > > >> (C) Already part of wireless standards or > potentially part of > > >> future standards > > >> > > >> (A) refers to all portions of the draft framework that > differ from > > the > > >> requirements and procedures currently standardized for wireless > > >> emergency access by 3GPP, 3GPP2 and OMA. This is a plain > difference > > of > > >> solution and could be resolved through support of both > solutions by > > >> terminals (with each solution being used according to > the type of > > >> access network and VSP) or could be resolved by > supporting only one > > >> solution and accessing only the types of network supporting that > > >> solution. To acknowledge this category, the framework document > > >> could reference the applicable wireless standards and point out > > >> that these are valid alternatives for wireless cellular > based access. > > >> > > >> (B) refers to portions of the draft that would be unsuitable for > > >> wireless networks even if no alternative solution > existed together > > with > > >> other portions missing from the draft that would be > needed to fully > > >> support wireless networks. Examples of the former include: (a) > > emphasis > > >> on endpoint derivation of location, performance of Lost > query and > > >> receipt of local dial strings; (b) restriction of LCPs > to protocols > > >> that require terminal initiation (not allowing for network > > initiation > > >> as far as we can tell) and that include two LCPs (DHCP and LLDP) > > that > > >> are not applicable to (not defined for) cellular access; and (c) > > >> the requirement that a terminal or at least a LIS will > update the > > >> PSAP whenever location changes. (a) is impractical due > to network > > >> and terminal loading consequences and failure to support non-IP > > >> capable PSAPs; (b) makes location verification and > updated location > > provision > > >> to PSAPs difficult or impossible; while (c) is also incompatible > > with > > >> support of existing non-IP capable PSAPs besides increasing > > >> terminal load and possibly interfering with optimum > maintenance of > > >> the RF connection (e.g. if a terminal has to tune away from the > > >> serving > > base > > >> station or WLAN periodically to make location measurements). > > Examples > > >> of the latter include (d) absence of support for access > to non-IP > > >> capable PSAPs as already mentioned (e.g. to support E911 > phase 2 in > > the > > >> US); (e) no support for handover from the IP to the > circuit domain > > when > > >> a terminal loses (e.g. moves out of) RF coverage in the > IP domain; > > and > > >> (f) no allowance for limited access modes wherein a terminal may > > access > > >> a network only to place an emergency call with ensuing > restrictions > > on > > >> (for example) location acquisition, PSAP callback and caller > > >> verification and identification to the PSAP. To resolve this > > category > > >> either significant changes to the framework document > could be made > > or a > > >> disclaimer/applicability statement could be added stating that > > support > > >> of cellular wireless networks and their associated WLAN > and Femto > > >> access points is not covered. > > >> > > >> Category (C) comprises concepts and capabilities in the > draft that > > are > > >> either already part of the standardized solution for wireless > > networks > > >> or that might be added at a later time. Examples of the former > > include > > >> LoST, SIP location conveyance, general use of SIP, location for > > routing > > >> versus for dispatch, cellular positioning methods. > Examples of the > > >> latter include use of location references and dereferencing and > > >> possible interworking between the current wireless network > > >> solutions (in 3GPP, 3GPP2 and OMA) and the solution > described in this draft. > > The > > >> presence of this category could be acknowledged by following the > > >> disclaimer for (B) with a statement that certain portions of the > > >> solution are expected to be incorporated into wireless > networks now > > >> and/or in the future. > > >> > > >> We hope that these comments will be seen to be a useful > addition to > > >> this review in the sense of enabling a more precise > scoping for the > > >> framework document and we are willing to assist in providing > > >> wording for any disclaimer/applicability statement that > the Ecrit > > >> working > > group > > >> may now deem fit to include. > > >> > > >> Kind Regards > > >> > > >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs > > (Qualcomm > > >> 3GPP2 TSG-X and TSG-C participant) > > >> > > >> PS this being sent on 2/4/09 at 11:50pm PST > > >> > > >> _______________________________________________ > > >> Ecrit mailing list > > >> Ecrit@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ecrit > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------- > ---------------------------------- > 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://www.ietf.org/mailman/listinfo/ecrit > From Hannes.Tschofenig@gmx.net Mon Mar 9 14:59:30 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7BD23A6CA1 for ; Mon, 9 Mar 2009 14:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JdkWI5Ui41j for ; Mon, 9 Mar 2009 14:59:30 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 7D1523A676A for ; Mon, 9 Mar 2009 14:59:29 -0700 (PDT) Received: (qmail invoked by alias); 09 Mar 2009 21:59:54 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp070) with SMTP; 09 Mar 2009 22:59:54 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18U4E4jgQQUFJLJi0ylWQN71KNyFj24Qku1a3HRpZ q6EtvkSl5C1vyb From: "Hannes Tschofenig" To: "'DRAGE, Keith \(Keith\)'" , "'Winterbottom, James'" , "'Edge, Stephen'" , "'Brian Rosen'" , "'ECRIT'" References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com> <28B7C3AA2A7ABA4A841F11217ABE78D674B1ACF0@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Date: Tue, 10 Mar 2009 00:01:02 +0200 Message-ID: <044d01c9a102$8ab34220$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D674B1ACF0@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Thread-Index: AcmHZkcFqEtDIGTNRMy2Xqm0XoWoXwKeEe+gADZBfMABQDsYoAJCmxdwAA/a36A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.77 Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 21:59:30 -0000 >The answer to your specific use case is: > >1) If the VPN connection is at the IP level, then the >mobile operator takes no responsibility for emergency calls >made over that IP connection, and it is ip to the corporate >network to deal with any emergency calls in an appropriate manner. No responsibility? What about location information that comes from the access? From sedge@qualcomm.com Mon Mar 9 18:22:55 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A15483A6900 for ; Mon, 9 Mar 2009 18:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.466 X-Spam-Level: X-Spam-Status: No, score=-105.466 tagged_above=-999 required=5 tests=[AWL=1.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3dLlwd3tW2w for ; Mon, 9 Mar 2009 18:22:51 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 9E4E03A68A9 for ; Mon, 9 Mar 2009 18:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1236648206; x=1268184206; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" Dawson,=20Martin"=20,=0D=0A=20 =20=20=20=20=20=20=20"br@brianrosen.net"=0D=0A=09|CC:=20ECRIT=20|Date:=20Mon, =209=20Mar=202009=2018:23:23=20-0700|Subject:=20RE:=20[Ec rit]=20Comments=20on=20Framework=20Draft|Thread-Topic:=20 [Ecrit]=20Comments=20on=20Framework=20Draft|Thread-Index: =20AcmY6xBP94jupkzETj+iA0b5U69mvgDj/IbwAGceYlAAwDSRoA=3D =3D|Message-ID:=20<1288E74A73964940B132A0B9EA8D8ABC5374A3 FE@NASANEXMB04.na.qualcomm.com>|References:=20<1288E74A73 964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.co m><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B 132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5 FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC537 49E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B13 2A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com><64147. 24.154.127.233.1235746352.squirrel@www.brianrosen.net>=0D =0A=20<1288E74A73964940B132A0B9EA8D8ABC5374A0D6@NASANEXMB 04.na.qualcomm.com>=0D=0A=20|In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5548"=3B=20a=3D"16121751"; bh=b0LaA4EkahakmalFlobAOJ6hEL4hB3g4JElSZEP3rZg=; b=jCZ0mrIM6XO6BJGoqUc7/+GtMKvrdeLC2yjDxSKWU3kpX/t6MfvOyTKT 6fe3Ku9Oo7yl4ABBaVxqyqntHOB9gbX0yY6XQaQyOL4prAS9dvYviyKyd pYa8hvzjwpcqPF57ycXNwOZq82UZldbZV0BsYtIKrY+gxF+NrrgfIaFKK o=; X-IronPort-AV: E=McAfee;i="5300,2777,5548"; a="16121751" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Mar 2009 18:23:26 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2A1NPLB007383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Mar 2009 18:23:25 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2A1NOPQ031297 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 Mar 2009 18:23:25 -0700 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub04.na.qualcomm.com ([129.46.134.222]) with mapi; Mon, 9 Mar 2009 18:23:24 -0700 From: "Edge, Stephen" To: "Dawson, Martin" , "br@brianrosen.net" Date: Mon, 9 Mar 2009 18:23:23 -0700 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmY6xBP94jupkzETj+iA0b5U69mvgDj/IbwAGceYlAAwDSRoA== Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5374A3FE@NASANEXMB04.na.qualcomm.com> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com><64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net> <1288E74A73964940B132A0B9EA8D8ABC5374A0D6@NASANEXMB04.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 01:22:55 -0000 Hi Martin Thanks for theses further comments - which I agree introduce a new twist to= this discussion. Your main assertion seems to be that most of the general points I raised ar= e not matters for Ecrit to resolve and standardize but instead represent pr= oblems to be resolved for the particular AN (either by an SDO associated wi= th the AN by or by some national SDO like NENA in the case of PSAP access).= The list of such issues seems to be: 1. Access to PSTN capable PSAPs 2. Handover between different IP access networks 3. Handover to/from circuit mode networks 4. Location for cellular access 6. Support of unauthenticated users (and users in limited service state) If I am generally right in this assumption, my first question is whether th= is is just your particular opinion or if this represents the view of Ecrit = generally. E.G. is there any danger that Ecrit (or some other IETF group) m= ight reclaim one or more of the above - perhaps after others SDOs (like 3GP= P) have produced their own solutions? If you are all quite certain that thi= s will not happen, or at least certain of this for some subset of the above= , it would very much help to include a statement on this in the phoneBCP an= d/or framework drafts so there is no ambiguity. My next comment is that solving the above for each type of AN probably repr= esents most of difficulty in producing a comprehensive solution. For exampl= e, handover after a location URI has been obtained from a LIS will be probl= ematic for continuing location (since the previous and now wrong LIS may re= ceive the next location request). Similarly access and handover to restrict= ed areas (cells or networks a user is not normally allowed to use) is probl= ematic particularly if normal IP connectivity is assumed. Further, use of H= ELD with a control plane location solution is highly problematic for any 3G= PP network because the current architecture and procedures are not able to = support location requests initiated solely from a location server (like an = SMLC or SAS) where there no prior interaction with the RAN and CN. Further = to that, control plane solutions cannot often obtain location accurately en= ough for dispatch and need to incorporate terminal based positioning using = say A-GPS which can lead to a user plane solution like SUPL. I could add ot= her problem areas if you believe this list is exhaustive. Now I am not sayi= ng that these problem areas cannot be solved - 3GPP and 3GPP2 have in fact = solved most of them (and should complete this by the end of this year) in t= he context of the 3GPP/3GPP2 solution. But your position now seems to be th= at any SDO must solve them subject to the various restrictions and requirem= ents imposed by the Ecrit phoneBCP and Framework drafts. Can you confirm th= at this is so? Kind Regards Stephen -----Original Message----- From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] Sent: Thursday, March 05, 2009 10:56 PM To: Edge, Stephen; br@brianrosen.net Cc: ECRIT Subject: RE: [Ecrit] Comments on Framework Draft There must be a word for the situation where everybody is talking about something but everybody knows the real subject is something else and what that real subject is. Suggestions welcome. Anyway, working on the basis that this whole thing isn't just about getting a "sound bite" added to the framework document that can be misappropriated for years to come to confuse the cellular industry into thinking ECRIT is not relevant to them, let's look at each of Stephen's topic areas below. A fundamental tenet of the argument is that, somehow, cellular is "special" and should be left to its "special" devices compared to every other Internet access technology. This, after all, is why we have IMS. It might have seemed reasonable ten years ago to define the core service architecture to accompany the new "Packet Service" mode of networking. In these days of Web 2.0, AJAX, Ruby on Rails, Flash, Silverlight, SOA, Azure... etc. against which IMS seems very.... "stodgy" it is reasonable to ask the question why such a monolithic and cellular-legacy service model is required. Nevertheless - 3GPP is entitled to do what 3GPP does. Actually I'm pretty sure you won't find references to IMS in Web 2.0 texts saying "of course cellular operators also use IMS as an application framework." Now - how specific are the "special" cases that are outlined below to cellular?: 1. Access to PSTN capable PSAPs Not specific to cellular. If a jurisdiction has PSTN capable PSAPs then VoIP calls originating from any form of access have to deal with that fact. The answer is fairly obvious - there has to be a media gateway behind the PSAP URI. And it might not just be a PSTN PSAP, there could be dedicated circuits to selective routers or, even, CAMA trunks involved. The manner in which this is done really does need to be spelt out by the jurisdiction; it can't be otherwise even if there are fairly common conventions. NENA looks after stating how this is done for the US. It's not up to 3GPP nor the IETF to tell jurisdictions how emergency calls that originate on Internet access get bridged into the legacy PSAP infrastructure. No more so than it was 3GPP's job to prescribe that E2+ had to be the PSAP/ALI to GMLC interface protocol used for CS E9-1-1 calls. 2. Handover between different IP access networks Not specific to cellular. There can be handover between WiFi and Ethernet, WiFi and WiMAX and so forth. Now - what we're really talking about here is a more fundamental capability related to mobile IP. 3GPP definitely has a very nice role to play in prescribing how this access-mobility occurs across the access technologies that 3GPP defines and supports. Since the ECRIT emergency model concerns itself from the IP layer up, it is quite possible for it to work very transparently to such mobility occurring beneath the surface. And, of course, any such nicely integrated access technologies would offer a nicely integrated LIS solution to ensure that the location service remains contiguous and consistent. It seems to me that it's quite bad engineering to couple the manner in which this is done to a specific IP service such as emergency calling. Can't help it if 3GPP do that - but it doesn't obviate the option of ECRIT being applied in the more elegant way. 3. Handover to/from circuit mode networks I'll give you this one... to an extent. Obviously the IETF doesn't think this is in the least bit relevant to them. On the other, in theory, a VoIP connection established on any form of IP access could be handed over to some other form of circuit access - e.g. DSL to ISDN. The issue, of course, is just how realistic these scenarios are. If you accept that the PSTN is going to go away (and I certainly do) then you also acknowledge that this is a transitional issue. You can argue that the PSTN is still going to be around for years to come (and I also agree with that) but that doesn't mean you have to create a specific mechanism to handover between circuit and packet for emergency services. I'm interested in just what it is that 3GPP have defined for this. I look at the current 23.167 specification and, I admit, it doesn't leap out at me. The stage 2 description has always struck me as kind of vague. The diagram concerning location information handling, for example, has the dotted boxes with non-prescriptive steps saying "procedure to obtain location" done here. It always kind of reminds me of that old cartoon with the engineers looking at the complex flow chart with the "a miracle happens here" box in the middle. I'm thinking of a call originated on IP. Let's say the E-CSCF invokes the E-SLP to do a SUPL NI-LR (assuming one manifestation of the dotted box in the diagram) and the resultant location is used to determine the correct MGCF route to deliver the call. Perhaps the PSAP supports an MLP interface to the LRF and can ask it for location updates - kicking off a SUPL NI-LR again. Now - the device "roams" to a bit of the network that can only support circuit service? What exactly happens? Does it initiate another call via the MSC? How does that interact with the existing emergency service semantics in the MSC? Obviously it wants to initiate a whole new call - and initiate control plane location determination so it can report an initial location to the GMLC. Is that GMLC the same node as the LRF? How does it deal with the fact that it's now got two pieces of state for what in theory is the same call? Or is it - given the MSC can't know about the PS call in progress? What has 3GPP actually defined for this? I am certainly interested in the mechanics of how this is all accomplished and done reliably. ITRW (the one you and I live in) 3G operators commonly force emergency calls onto the GERAN just because that's lower risk since GSM emergency calling is well established and things like UTDOA infrastructure are available on that access. This is quite the opposite tendency of looking to have seamless real time migration between access technologies on emergency calls (let alone seamless migration between PS and CS!). What carriers are planning to do this with emergency calls if you can say? 4. Location for cellular access. Certainly not specific to cellular access. Every technology has a need for accurate location determination. Wired technologies also, most appropriately, need the location to be provided in civic address form; something that the nominated LCPs are very good at. You're partly confusing the role of the LCP protocol with that of the server. You can send a very simple HELD request to a LIS to ask for location; it's incredibly simple to do; that's why HELD client implementations keep popping up from different sources. The complex stuff happens on the server side. A LIS receiving such a request can invoke all manner of control plane mechanisms (for the confused - "control plane" is not an antonym of "IP"; it just means interaction occurs between network elements and not over the traffic channel with the device). For example, the LIS might do UTDOA. Now, I suspect you realize this and carefully chose examples of technologies that involve measurements taken by the device. Fortunately this is not precluded by HELD either; I believe James has already pointed you at the material for this. Finally, since "cellular (=3D3GPP)" is clearly your one true interest here, the good news is that cellular networks already have terrific infrastructure and control plane mechanisms in place for location determination. This includes the UE peer signalling for AGPS, OTDOA and so forth. All a LIS in a 3GPP network has to do is provide the semantics of the LCP to the device and emergency network clients and to invoke that existing control plane infrastructure at the back end. It's certainly a lower cost and more robust alternative than building SUPL infrastructure in parallel to that control plane capability which already exists to support CS emergency calls anyway. 5. Endpoint based location and routing Nothing cellular specific about this one. Same thing applies to WiFi and WiMAX and wired technologies too. The old "network loading" furphy is often rolled out for these sorts of discussions; presumably it's attractive because it sounds "technical" but doesn't really warrant proper quantification and justification. Gosh "billions" of devices - how can we even consider having so many devices doing... "stuff"? It does prompt me to ask the question "what part of the term 'broadband' don't you understand?" I'm going to take a wild stab and suggest that a device being used to make an emergency call probably isn't "idle". Further, with respect to the general IETF location service model, I'm going to suggest that a device that wants to ask for its location isn't idle either. Even further, I'm going to suggest that a LIS servicing a location dereference can have enough integration with the access network to have the device paged and for location procedures to proceed (i.e. just like a control plane MT-LR or a SUPL NI-LR - though the latter is an ill-defined proposition with respect to arbitrary access types). Actually your commentary on this section strongly suggests to me that you don't actually understand how an ECRIT emergency call procedure works. You've certainly tried to characterize all this LoST and PSAP boundary stuff that's going on as a big deal. It isn't and there's certainly no more going on from either a device or network perspective than there would be to provide the same functionality via a control plane or SUPL approach. If you'd like an offline overview of how an ECRIT emergency call is made, let me know; it would be my pleasure. 6. Support of unauthenticated users Definitely not a cellular specific issue; every access technology has to ask itself about this. Actually every regulator in every jurisdiction has to ask themselves about this too - and hopefully they can avoid the mistake of thinking one form of public access technology is "special" compared to others as well. That would mitigate the risk of them coming up with inconsistent and confusing legislation. ECRIT is based on IP - so the key first step to getting an ECRIT-compliant emergency call underway is for the device to have IP access. In 3GPP parlance, you'd say it needs to have a network context. A good example of providing ECRIT-compliant emergency calling to unauthenticated devices is WiFi hotspots. Hotspots typically provide free layer 2 connectivity and an IP context in the first instance. Device traffic is "port-trapped" to the Hotspots' web site (and maybe a smattering of public Internet websites as well). The firewall isn't opened up until the user "authenticates"; the valid token very often taking the form of a credit card number and expiry date. So -what would a Hotspot need to do to provide "unauthenticated" emergency access? All it needs to do is to ensure that unauthenticated devices, in addition to having access to the portal web page, also have access to a LIS, a LoST server and to the PSAP URI(s) which service the location of that hotspot. That's it; sure there's no emergency call proxy via a third party VSP - but that's not necessary (I'm actually against it anyway) but it could be accommodated with some tweaks on the approach described. Now - what would a 3GPP network need to do to support an ECRIT-compliant unauthenticated emergency calling facility? You could probably describe it better than me - but I dare say it would involve allowing the device to establish an emergency IP context (something which I believe is required by 23.167 anyway - otherwise how would the UE be able to tell the P-CSCF it wants to do an emergency call?). Having permitted the creation of the emergency context, the 3GPP network would similarly just need to constrain the device's access to the LIS, LoST, and the PSAP URI(s) for the corresponding location. Obviously 3GPP have decided to define a different way of doing things and that's par for the course. It's 3GPP's prerogative to continue to act as if there is something special about cellular and that there's good reason for it to look different to both IP devices and the emergency network. It's not true - but that's never stopped the silo thinking before. And that puts me in mind of that scene from Python's Holy Grail movie. 3GPP guarding the bridge to "cellular land" - "None shall pass..." - It'll end much the same way as well. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Edge, Stephen Sent: Wednesday, 4 March 2009 4:32 PM To: br@brianrosen.net Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft Brian Thanks for these well considered responses. Below I am providing on an item by item basis, and taking into account your responses, a few more reasons why the current Ecrit solution is unsuitable - or, if you prefer, less suitable than the 3GPP/3GPP2 solution - for cellular networks. 1. Access to PSTN capable PSAPs Assuming that the best available solution for this currently is the ongoing NENA i2 standard (as you comment), then there are problems with providing location for dispatch (initial and updated location). For example, the latest i2.5 draft I have (December 2008) says that the VPC to LIS v3 interface is being deprecated (thus not available), although this is the interface that the VPC would use to query location from the LIS. Also I don't see any inclusion of accurate positioning support - e.g. using A-GPS. Further, interworking with the circuit mode side for UA access (as opposed to PSAP access) seems to be out of scope. So at best, this standard is incomplete (i.e. not yet suitable for cellular networks). However, I agree that there is some overlap between i2.5 and the 3GPP/3GPP2 solution. 2. Handover between different IP access networks including different types of access network One of the issues here would be change of LIS across different networks while avoiding impacts to both IP and PSTN capable PSAPs (i.e. handover must be transparent to PSAPs within the limitations imposed by SIP or some J-STD-036 type of circuit mode solution). The problem gets more difficult when handover to/from circuit mode access networks is considered. So far, 3GPP/3GPP2 has not yet agreed on a solution although there are proposals and we expect some resolution soon. On the Ecrit and NENA sides, I see much less progress. 3. Handover to/from circuit mode networks We agree here at least on the out of scope aspect. I suppose I can accept that it is not customary to point this out in IETF standards. But I hope you can see that this is an issue for cellular networks most of which will have extensive circuit mode coverage for a long time to come. 4. Location for cellular access (and the requirement to support LCPs that will be useless for cellular access) The issue is not so much the LCP itself but the capability to support accurate positioning - e.g. using A-GPS, AFLT, OTDOA, enhanced cell ID etc. None of those methods seem to be supported as part of DHCP or HELD right now. So some modification of the LCP related requirements or of the LCPs seems needed. 5. Endpoint based location and routing for cellular access (issues here are network and device loading as well as device impacts and problems with PSTN capable PSAPs) Endpoint based location when spread over millions (billions, planet-wide) of terminals will consume significant network and terminal resources. A typical terminal is generally idle and interacts with the network very sparingly to update the network with its current location (e.g. current cluster of potential serving cells). Performing network assisted periodic location fixes and LoST queries would add significantly to network load. Performing periodic location fixes in the terminal (e.g. using GPS) and estimating when a PSAP boundary may have been crossed would add to terminal load (e.g. thus battery drain). Optimizations would be possible of course - e.g. based on observing nearby cell IDs - but they will add to terminal complexity and testing costs. I agree that the Ecrit solution does allow for proxies to do this but here the solution also becomes incomplete because there seem no details of how this would work - e.g. what location solutions would then be used. 6. Support of unauthenticated users and users who can be authenticated but are not permitted access/VSP service except for emergency calls I think the Ecrit solution and you both assume that this has already been resolved somehow at the access level and therefore the various procedures in Ecrit can still be used. Maybe that is valid. However, there are still problems that are not covered in the Ecrit drafts but need to be resolved including (a) obtaining IP access (e.g. via a WLAN, cellular network, cable link) when not a valid subscriber, (b) obtaining access to the VSP and (c) ensuring only emergency related services are provided (e.g. and not free Internet and location access). These and additional problems (e.g. UA identification) would have to be solved, maybe on a per access basis, and then ensured to be compatible with the rest of the Ecrit solution. A significant part of the 3GPP/3GPP2 solution is concerned with this aspect and it has delayed completion of the solution for the more normal case of valid subscriber access due to such compatibility issues. Kind Regards Stephen -----Original Message----- From: br@brianrosen.net [mailto:br@brianrosen.net] Sent: Friday, February 27, 2009 6:53 AM To: Edge, Stephen Cc: Thomson, Martin; Richard Barnes; ECRIT Subject: Re: [Ecrit] Comments on Framework Draft Stephen Like any standards organization, the IETF restricts it's scope. Generally, the scope is "the Internet", although we very often describe solutions that are explicitly designed for private IP networks as well as the Internet. We don't write standards for circuit switched networks, and it should be no surprise that the ecrit solution does not cater to CS solutions. Nevertheless, we often try to make sure that our solutions harmonize reasonably well with existing solutions. Indeed, the ecrit solution clains global applicability to the Internet in general, and most private IP networks that can be interconnected to the Internet or to other IP networks via gateways. Looking at your list of problem areas: > - access to PSTN capable PSAPs This is out of scope for IETF. NENA has active work on this subject. It seems straightforward to interwork ecrit compatible devices and networks to existing CS connected PSAPs. As you know, CS interconnects are very nation-specific, so the NENA work may not have general applicability. However, it shows that it is possible to interwork. The NENA i2 work is also designed to take ecrit compatible devices and VSP networks, and interwork them to the existing network. The VSP would direct the call to the VPC, which would provide the services it does now, using the device provided location for routing. This is important for smooth transition from existing PSAPs and VSPs to "next generation" PSAPs and VSPs. > - handover between different IP access networks including different > types of access network In the ecrit solution, the access network the call is initiated on provides all the facilities needed for the device to initiate an emergency call. The call starts traversing it's normal call path, and eventually routes to the ESRP. Handoffs between IP networks should be transparent to this process, although we probably haven't done all the work we need to do for handoffs where the IP address as seen by the terminating network changes. This would generally be true of all current SIP based work. > - handover to/from circuit mode networks This would be out of scope for IETF. It's as applicable to a simple SIP call as it is a SIP emergency call, and there are no statements in any SIP documents on that subject. > - location for cellular access (and the requirement to support LCPs that > will be useless for cellular access) Location for cellular access networks has been considered carefully. Since cellular is a mobile network, the access network would pass the device a Location-By-Reference URI, using either DHCP or HELD. Either protocol is suitable for cellular networks. As we have pointed out several times, cellular networks support raw data packet services upon which many different kinds of networks can be constructed. My usual example is a large recreational vehicle traveling down a road with a cellular data card plugged into a router to which a wired (Ethernet) phone is connected. That phone must be able to make an emergency call, and it will get location from DHCP or HELD (or LLDP-MED). It is not aware of the cellular network, and doesn't know any cellular specific protocols. Cellular networks will have to support IETF location configuration protocols unless they actively prohibit examples like this, or they implement interworking between cellular-specific location protocols and DHCP or HELD in the data card. The ecrit standards permit proxy insertion of location, but, as above, we don't think that works in all cases. > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) The "load" of using DHCP or HELD to get location and querying LoST is pretty modest. The standards permit proxies to do this if the devices don't. As above, interwork functions to CS connected PSAPs is very feasible, and as above, cellular networks will have to support access to local LoST servers for devices that are connected to cellular networks and are ecrit compliant. > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls This is covered in the standards. None of the processes are dependent on authentication, although where it is possible, it's desirable so as to minimize fraudulent emergency calls Mechanisms for specific network authentication mechanisms are out of scope, and, like SIP basic calling, are not usually mentioned in IETF documents. Stephen, we've tried pretty hard to make sure this works for 3G/4G mobile networks. It's true that it doesn't do it the way 3GPP currently thinks it ought to work, but we claim they haven't thought through all the issues. While it would work, there are opportunities for improvement. We would be willing to do that if we could get the cooperation of 3GPP, which we have tried, and failed, to do. So, I think the documents do not need any qualification statements. Brian > Martin > > The 3GPP/3GPP2 solution has a defined restricted applicability (mainly to > 3GPP/3GPP2 access networks where the serving network also acts as the VSP) > and the specifications for it cover in detail all possible scenarios > consistent with these restrictions so far as we are aware. > > The Ecrit solution seems to claim global applicability to all types of IP > access (and the more that is said about this from Ecrit participants the > more this gets emphasized) but does not cover in detail all possible > scenarios (in some cases does not cover in any detail) which means that at > best the solution is incomplete and at worst intrinsically inapplicable to > some unstated set of scenarios. > > The missing, incomplete and problematic cases include the following: > > - access to PSTN capable PSAPs > - handover between different IP access networks including different > types of access network > - handover to/from circuit mode networks > - location for cellular access (and the requirement to support LCPs that > will be useless for cellular access) > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls > > Stating that some of these cases are out of scope or referencing an > incomplete and possibly questionable specification from some other > national SDO will not help the user who encounters such problems. But it > would certainly help network operators and implementers to acknowledge > their existence in one form or another because that would allow better > planning of deployments and would help focus attention on finding > solutions (whether in IETF or elsewhere) for the missing cases. > > Please note that despite these drawbacks, I will acknowledge that Ecrit > does have a valuable solution that covers many scenarios not covered by > 3GPP/3GPP2. It would be the delineation of these supported scenarios (or > equivalently unsupported scenarios) in some applicability statement that > would be particularly useful right now. > > Kind Regards > > Stephen > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Thursday, February 26, 2009 9:45 PM > To: Edge, Stephen; Richard Barnes > Cc: ECRIT > Subject: RE: [Ecrit] Comments on Framework Draft > > There's benefit in knowing the limitations of a framework, and every > architecture makes certain assumptions. Let's examine them though... > > The IETF might occasionally make the assumption that the standards it > develops are for Internet devices. That assumption probably need not be > stated explicitly. > > The ECRIT architecture relies on implementations of the protocols that it > references. That is not extraordinary. A reliance on implementation of > these protocols by endpoints, routing intermediaries and PSAPs should not > need to be explained. > > So the assumptions are: > - the Internet > - solutions are implemented and deployed > - the end device is a key component > > Only that last element is particularly novel ... or not that much really. > It's a design choice. Unless you were thinking of trunking the voice > elsewhere. > > Of course, you're suggesting that the design choice was made in ignorance > of all the constraints. You're suggesting that - as a result - the choice > is flawed and the solution is not going to work for cellular services. We > disagree. The solution is a basis for emergency calling in _any_ IP > network. > > Cheers, > Martin > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Edge, Stephen >> Sent: Friday, 27 February 2009 3:30 PM >> To: Richard Barnes >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Richard >> >> Thanks for the comments. Your statement below that "SIP emergency >> calling works if all parties behave as specified in these (IETF Ecrit) >> documents" to some degree highlights the problems we are raising. The >> documents do contain a number of implicit and explicit restrictions - >> like IP capable PSAPs, global IP access (no islands of circuit mode >> access for example), universal support of this solution by all access >> providers and VSPs (not much good if some opt for another solution) and >> end system oriented location and routing capability - which together >> make them unsuitable (we believe) for cellular wireless networks. If >> these restrictions and assumptions were all made explicit upfront, it >> would to a large degree (and possibly completely) address our concerns. >> >> You are right in assuming another set of specifications for the 3GPP >> and 3GPP2 solution. The applicability of this solution is explicitly >> defined in TS 23.167 (or more exactly in an already agreed CR in >> contribution S2-090752 which will become part of 23.167 in a few more >> weeks) to cover the following access types: GPRS (UTRAN WCDMA), I-WLAN, >> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN >> (LTE). So there is a restriction and arbitrary internet access is not >> covered (yet) as I have stated before. >> >> Kind Regards >> >> Stephen >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Wednesday, February 25, 2009 6:30 PM >> To: Edge, Stephen >> Cc: Brian Rosen; 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Stephen, >> >> I'm a little confused by the scope of what you're asking. The >> framework >> and phonebcp documents exist in order to describe the ECRIT solution: >> They say, in effect, "SIP emergency calling works if all parties behave >> as specified in these documents." >> >> As I understand what you're saying (and I'm by no means an expert in >> 3GPP), 3GPP specifies that one or more elements of this system behave >> differently. This simply means that 3GPP networks aren't complying >> with >> these specs. Just like there's no disclaimer in RFC 791 (IPv4) that >> says "this doesn't work on X.25 networks", it's not clear to me that an >> analogous disclaimer is called for here. >> >> I presume there are similar documents describing how emergency calling >> works in 3GPP networks. Do they include notes saying that the 3GPP >> solution doesn't work in the broader Internet? >> >> --Richard >> >> >> >> >> >> Edge, Stephen wrote: >> > Brian >> > >> > First of all apologies for the likely lateness of this reply - I >> actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest but >> it seems unlikely that my VPN, Outlook server and WiFi access >> capability will cooperate together to get it sent until I return to the >> office mid-next week. >> > >> > Anyhow thanks for your comments. There have actually been a number of >> conference calls between IETF and 3GPP participants over the last >> couple of years at which common features like support of IP emergency >> calls were discussed and these could have been good forum for >> participants on either side to have raised the kinds of issues you >> elaborate on below. Given that seems not so far to have happened, it >> could still be possible in future such calls. >> > >> > But the issues we are raising are not directly to do with further >> aligning the 2 solutions or with the lack of this in the past. We are >> simply pointing out that the solutions are currently different and that >> from a cellular wireless perspective, the Ecrit solution is not seen as >> suitable in all respects (for support of IP emergency calls originating >> from such access types). That is not just our point of view. 3GPP2 sent >> a liaison to Ecrit some months ago pointing out the same issues. >> > >> > So we are proposing that the Ecrit framework and phoneBCP spec.s >> include a statement acknowledging this - e.g. by referencing the >> alternative 3GPP/3GPP2 solution and indicating the IP access types for >> which the Ecrit solution will work without limitation (or equivalently >> the access types where limitations are not ruled out). >> > >> > We are not proposing further modification and extension of the Ecrit >> solution - just pointing out that this would be needed (as with the >> 3GPP/3GPP2 solution) to fully cover all types of access. >> > >> > Kind Regards >> > >> > Stephen >> > -----Original Message----- >> > From: Brian Rosen [mailto:br@brianrosen.net] >> > Sent: Wednesday, February 18, 2009 8:07 PM >> > To: Edge, Stephen; 'ECRIT' >> > Subject: RE: [Ecrit] Comments on Framework Draft >> > >> > I have bit my tongue on this one for a long time. >> > >> > Stephen, with respect, please go talk to 3GPP management and ask them >> why >> > there has been no participation in the ecrit effort despite multiple >> YEARS >> > of begging them to get involved. To put it frankly, 3GPP is quite >> willing >> > to bully IETF into doing its work on its schedule, but cannot be >> bothered to >> > get work done it knows it will eventually have to do when the IETF >> asks it >> > to do so. >> > >> > 3GPP understands the mess that is being created by not participating. >> They >> > know full well that when they finally get around to dealing with PS >> > terminated emergency calls, that there will be a lot of resistance to >> > changing fully specified and implemented standards to more closely >> align >> > with 3GPP standards. I expect you will have several interworking >> functions >> > to define and build. >> > >> > So, politely, please go away, we're finishing work we dearly wanted >> you all >> > to be involved with for years, but you refused to do anything. It's >> too >> > late for this rev. >> > >> > Now, having said that, there are quite a few people who have >> participated in >> > the IETF work who are IMS aware and I believe that despite your >> fears, >> > everything you need is in the specs. The mechanisms we have defined >> provide >> > the ability for the network to insert location, recognize and mark >> emergency >> > calls, and route on behalf of endpoints. An E-CSCF could quite >> > straightforwardly provide a SIP call towards an ecrit compatible >> PSAP. The >> > only not-quite-nice interwork would be from SUPL to HELD (or SIP), >> but it's >> > pretty easy to do that. I'll also note that we have tried to get OMA >> and >> > IETF to cooperate on location protocols, but we have been >> spectacularly >> > unsuccessful at that effort also. >> > >> > Brian >> > >> > >> > >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf >> >> Of Edge, Stephen >> >> Sent: Thursday, February 05, 2009 2:50 AM >> >> To: 'ECRIT' >> >> Subject: [Ecrit] Comments on Framework Draft >> >> >> >> All >> >> >> >> draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative >> >> description of how terminals and networks should support emergency >> >> calls made over IP capable facilities to IP capable PSAPs. It >> appears >> >> intended to cover all types of access network - including fixed >> line, >> >> WiFi and cellular (e.g. examples involving each can be found >> throughout >> >> the draft). >> >> >> >> When we evaluated this with respect to support of wireless cellular >> >> access and WiFi access associated with a cellular operator (e.g. >> WLAN >> >> or Femto cells integrated into a cellular network), we found that >> >> certain portions of the draft exhibited one or more of the following >> >> characteristics: >> >> >> >> (A) Inconsistent with already standardized wireless solutions >> >> >> >> (B) Inconsistent with essential wireless requirements and >> >> conventions >> >> >> >> (C) Already part of wireless standards or potentially part of >> >> future standards >> >> >> >> (A) refers to all portions of the draft framework that differ from >> the >> >> requirements and procedures currently standardized for wireless >> >> emergency access by 3GPP, 3GPP2 and OMA. This is a plain difference >> of >> >> solution and could be resolved through support of both solutions by >> >> terminals (with each solution being used according to the type of >> >> access network and VSP) or could be resolved by supporting only one >> >> solution and accessing only the types of network supporting that >> >> solution. To acknowledge this category, the framework document could >> >> reference the applicable wireless standards and point out that these >> >> are valid alternatives for wireless cellular based access. >> >> >> >> (B) refers to portions of the draft that would be unsuitable for >> >> wireless networks even if no alternative solution existed together >> with >> >> other portions missing from the draft that would be needed to fully >> >> support wireless networks. Examples of the former include: (a) >> emphasis >> >> on endpoint derivation of location, performance of Lost query and >> >> receipt of local dial strings; (b) restriction of LCPs to protocols >> >> that require terminal initiation (not allowing for network >> initiation >> >> as far as we can tell) and that include two LCPs (DHCP and LLDP) >> that >> >> are not applicable to (not defined for) cellular access; and (c) the >> >> requirement that a terminal or at least a LIS will update the PSAP >> >> whenever location changes. (a) is impractical due to network and >> >> terminal loading consequences and failure to support non-IP capable >> >> PSAPs; (b) makes location verification and updated location >> provision >> >> to PSAPs difficult or impossible; while (c) is also incompatible >> with >> >> support of existing non-IP capable PSAPs besides increasing terminal >> >> load and possibly interfering with optimum maintenance of the RF >> >> connection (e.g. if a terminal has to tune away from the serving >> base >> >> station or WLAN periodically to make location measurements). >> Examples >> >> of the latter include (d) absence of support for access to non-IP >> >> capable PSAPs as already mentioned (e.g. to support E911 phase 2 in >> the >> >> US); (e) no support for handover from the IP to the circuit domain >> when >> >> a terminal loses (e.g. moves out of) RF coverage in the IP domain; >> and >> >> (f) no allowance for limited access modes wherein a terminal may >> access >> >> a network only to place an emergency call with ensuing restrictions >> on >> >> (for example) location acquisition, PSAP callback and caller >> >> verification and identification to the PSAP. To resolve this >> category >> >> either significant changes to the framework document could be made >> or a >> >> disclaimer/applicability statement could be added stating that >> support >> >> of cellular wireless networks and their associated WLAN and Femto >> >> access points is not covered. >> >> >> >> Category (C) comprises concepts and capabilities in the draft that >> are >> >> either already part of the standardized solution for wireless >> networks >> >> or that might be added at a later time. Examples of the former >> include >> >> LoST, SIP location conveyance, general use of SIP, location for >> routing >> >> versus for dispatch, cellular positioning methods. Examples of the >> >> latter include use of location references and dereferencing and >> >> possible interworking between the current wireless network solutions >> >> (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. >> The >> >> presence of this category could be acknowledged by following the >> >> disclaimer for (B) with a statement that certain portions of the >> >> solution are expected to be incorporated into wireless networks now >> >> and/or in the future. >> >> >> >> We hope that these comments will be seen to be a useful addition to >> >> this review in the sense of enabling a more precise scoping for the >> >> framework document and we are willing to assist in providing wording >> >> for any disclaimer/applicability statement that the Ecrit working >> group >> >> may now deem fit to include. >> >> >> >> Kind Regards >> >> >> >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs >> (Qualcomm >> >> 3GPP2 TSG-X and TSG-C participant) >> >> >> >> PS this being sent on 2/4/09 at 11:50pm PST >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www.ietf.org/mailman/listinfo/ecrit >> > >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------ ------------------------ > 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://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.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] From Martin.Dawson@andrew.com Mon Mar 9 19:27:39 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71CB53A698E for ; Mon, 9 Mar 2009 19:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncXCRpRh2WRB for ; Mon, 9 Mar 2009 19:27:35 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 86B6D3A6900 for ; Mon, 9 Mar 2009 19:27:35 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_09_21_47_57 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 09 Mar 2009 21:47:56 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Mar 2009 21:28:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Mar 2009 21:28:06 -0500 Message-ID: In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5374A3FE@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmY6xBP94jupkzETj+iA0b5U69mvgDj/IbwAGceYlAAwDSRoAAC5dHQ References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com><64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net> <1288E74A73964940B132A0B9EA8D8ABC5374A0D6@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5374A3FE@NASANEXMB04.na.qualcomm.com> From: "Dawson, Martin" To: "Edge, Stephen" , X-OriginalArrivalTime: 10 Mar 2009 02:28:08.0997 (UTC) FILETIME=[D9FF8D50:01C9A127] Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 02:27:39 -0000 Hi Stephen,=0D=0A=0D=0ANo - I'd say you've gotten hold of the wrong end of = the stick; at least=0D=0Ain terms of the conclusion you're trying to drive.=0D= =0A=0D=0AWhat I'm saying is that none of the issues you brought up are spec= ific=0D=0Ato cellular and that, further, a properly engineered access - whe= ther it=0D=0Ais multi-technology or not - will support an ECRIT methodology=0D= =0Atransparently.=0D=0A=0D=0ATo use an analogy, a DNS service in an access = network can be similarly=0D=0Aaffected by many of the types of consideratio= ns you raise. Nevertheless,=0D=0Aa DNS service can be quite transparently p= rovided to clients running on=0D=0Aattached hosts, and without having to ch= ange their behaviour just=0D=0Abecause it's a 3G network, despite this fact= =2E By the same token, it=0D=0Awould hardly be appropriate for a DNS specif= ication to start talking=0D=0Aabout the sorts of things an access implement= er might need to do to=0D=0Aachieve this.=0D=0A=0D=0ACertainly, and ultimat= ely, it's up to 3G network implementers whether=0D=0Athey want to support a= general Internet emergency architecture (so that,=0D=0Afor example, an eme= rgency client on a laptop with a 3G modem can work=0D=0Ajust as well on tha= t network as it would attached to a residential=0D=0AEthernet connection, o= r that an emergency calling client on a PSP could=0D=0Awork just as well on= a 3G WiFi router as it would when attached to WiFi=0D=0Ahotspot).=20=0D=0A=0D= =0AAlternatively, if the network implementer just wants to support a 3GPP=0D= =0Aspecific model for emergency calling that pre-supposes an IMS=0D=0Asubsc= ription and which is targeted at conventional notions of handsets=0D=0Athen= they also have the choice of following those context-limited=0D=0Aspecific= ations of 3GPP.=0D=0A=0D=0AThere's no doubt, however, that the needs of the= latter can be met by=0D=0Aimplementing the infrastructure required for the= former but the converse=0D=0Ais not true. You are quite correct to *not* s= ay that the "problems" you=0D=0Aidentify below can't be solved. They most c= ertainly can - and it's=0D=0Abarely true to say that they are problematic. = They are no more so than=0D=0Aany engineering challenge. If you don't think= this sort of challenge=0D=0Ahasn't applied to cellular emergency services,= despite 3GPP=0D=0Aspecifications, then you must not have been involved in = any=0D=0Aimplementation.=0D=0A=0D=0AYou would be right to infer from my dis= course that I think 3GPP could do=0D=0Aa much better, and more helpful, job= of documenting how the ECRIT=0D=0Aemergency model should be supported. But= they don't have to (and=0D=0Acertainly don't appear to be inclined to) for= network implementers to be=0D=0Aable to do it anyway.=0D=0A=0D=0AI see you= r tack here, now, is to try and get an alternative statement in=0D=0Athe fr= amework - that could perhaps be used to make the argument that the=0D=0AIET= F doesn't know how ECRIT can be implemented in 3G networks. That=0D=0Awould= be a misrepresentation of the point that these considerations are=0D=0Aout= of scope and, as for the DNS example, it wouldn't be appropriate=0D=0Aanyw= ay.=0D=0A=0D=0AI don't presume to speak for the IETF. I think you know how = it's=0D=0Aorganized and that nobody can guarantee that somebody isn't going= to=0D=0Apost some new proposal or other for a work item. Actually, you cou= ldn't=0D=0Aget that kind of "we'll never venture to specify X" statement ou= t of=0D=0A3GPP either.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Origi= nal Message-----=0D=0AFrom: Edge, Stephen [mailto:sedge@qualcomm.com]=20=0D= =0ASent: Tuesday, 10 March 2009 12:23 PM=0D=0ATo: Dawson, Martin; br@brianr= osen.net=0D=0ACc: ECRIT=0D=0ASubject: RE: [Ecrit] Comments on Framework Dra= ft=0D=0A=0D=0AHi Martin=0D=0A=0D=0AThanks for theses further comments - whi= ch I agree introduce a new twist=0D=0Ato this discussion.=0D=0A=0D=0AYour m= ain assertion seems to be that most of the general points I raised=0D=0Aare= not matters for Ecrit to resolve and standardize but instead=0D=0Arepresen= t problems to be resolved for the particular AN (either by an=0D=0ASDO asso= ciated with the AN by or by some national SDO like NENA in the=0D=0Acase of= PSAP access). The list of such issues seems to be:=0D=0A=0D=0A1. Access to= PSTN capable PSAPs=0D=0A2. Handover between different IP access networks=0D= =0A3. Handover to/from circuit mode networks=0D=0A4. Location for cellular = access=0D=0A6. Support of unauthenticated users (and users in limited servi= ce state)=0D=0A=0D=0AIf I am generally right in this assumption, my first q= uestion is whether=0D=0Athis is just your particular opinion or if this rep= resents the view of=0D=0AEcrit generally. E.G. is there any danger that Ecr= it (or some other IETF=0D=0Agroup) might reclaim one or more of the above -= perhaps after others=0D=0ASDOs (like 3GPP) have produced their own solutio= ns=3F If you are all quite=0D=0Acertain that this will not happen, or at le= ast certain of this for some=0D=0Asubset of the above, it would very much h= elp to include a statement on=0D=0Athis in the phoneBCP and/or framework dr= afts so there is no ambiguity.=0D=0A=0D=0AMy next comment is that solving t= he above for each type of AN probably=0D=0Arepresents most of difficulty in= producing a comprehensive solution. For=0D=0Aexample, handover after a loc= ation URI has been obtained from a LIS will=0D=0Abe problematic for continu= ing location (since the previous and now wrong=0D=0ALIS may receive the nex= t location request). Similarly access and=0D=0Ahandover to restricted areas= (cells or networks a user is not normally=0D=0Aallowed to use) is problema= tic particularly if normal IP connectivity is=0D=0Aassumed. Further, use of= HELD with a control plane location solution is=0D=0Ahighly problematic for= any 3GPP network because the current architecture=0D=0Aand procedures are = not able to support location requests initiated=0D=0Asolely from a location= server (like an SMLC or SAS) where there no prior=0D=0Ainteraction with th= e RAN and CN. Further to that, control plane=0D=0Asolutions cannot often ob= tain location accurately enough for dispatch=0D=0Aand need to incorporate t= erminal based positioning using say A-GPS which=0D=0Acan lead to a user pla= ne solution like SUPL. I could add other problem=0D=0Aareas if you believe = this list is exhaustive. Now I am not saying that=0D=0Athese problem areas = cannot be solved - 3GPP and 3GPP2 have in fact=0D=0Asolved most of them (an= d should complete this by the end of this year)=0D=0Ain the context of the = 3GPP/3GPP2 solution. But your position now seems=0D=0Ato be that any SDO mu= st solve them subject to the various restrictions=0D=0Aand requirements imp= osed by the Ecrit phoneBCP and Framework drafts. Can=0D=0Ayou confirm that = this is so=3F=0D=0A=0D=0AKind Regards=0D=0A=0D=0AStephen=0D=0A-----Original= Message-----=0D=0AFrom: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D= =0ASent: Thursday, March 05, 2009 10:56 PM=0D=0ATo: Edge, Stephen; br@brian= rosen.net=0D=0ACc: ECRIT=0D=0ASubject: RE: [Ecrit] Comments on Framework Dr= aft=0D=0A=0D=0AThere must be a word for the situation where everybody is ta= lking about=0D=0Asomething but everybody knows the real subject is somethin= g else and=0D=0Awhat that real subject is. Suggestions welcome.=0D=0A=0D=0A= Anyway, working on the basis that this whole thing isn't just about=0D=0Age= tting a "sound bite" added to the framework document that can be=0D=0Amisap= propriated for years to come to confuse the cellular industry into=0D=0Athi= nking ECRIT is not relevant to them, let's look at each of Stephen's=0D=0At= opic areas below.=0D=0A=0D=0AA fundamental tenet of the argument is that, s= omehow, cellular is=0D=0A"special" and should be left to its "special" devi= ces compared to every=0D=0Aother Internet access technology. This, after al= l, is why we have IMS.=0D=0AIt might have seemed reasonable ten years ago t= o define the core service=0D=0Aarchitecture to accompany the new "Packet Se= rvice" mode of networking.=0D=0AIn these days of Web 2.0, AJAX, Ruby on Rai= ls, Flash, Silverlight, SOA,=0D=0AAzure... etc. against which IMS seems ver= y.... "stodgy" it is reasonable=0D=0Ato ask the question why such a monolit= hic and cellular-legacy service=0D=0Amodel is required. Nevertheless - 3GPP= is entitled to do what 3GPP does.=0D=0AActually I'm pretty sure you won't = find references to IMS in Web 2.0=0D=0Atexts saying "of course cellular ope= rators also use IMS as an=0D=0Aapplication framework."=0D=0A=0D=0ANow - how= specific are the "special" cases that are outlined below to=0D=0Acellular=3F= :=0D=0A=0D=0A1. Access to PSTN capable PSAPs=0D=0ANot specific to cellular.= If a jurisdiction has PSTN capable PSAPs then=0D=0AVoIP calls originating = from any form of access have to deal with that=0D=0Afact. The answer is fai= rly obvious - there has to be a media gateway=0D=0Abehind the PSAP URI. And= it might not just be a PSTN PSAP, there could=0D=0Abe dedicated circuits t= o selective routers or, even, CAMA trunks=0D=0Ainvolved. The manner in whic= h this is done really does need to be spelt=0D=0Aout by the jurisdiction; i= t can't be otherwise even if there are fairly=0D=0Acommon conventions. NENA= looks after stating how this is done for the=0D=0AUS. It's not up to 3GPP = nor the IETF to tell jurisdictions how emergency=0D=0Acalls that originate = on Internet access get bridged into the legacy PSAP=0D=0Ainfrastructure. No= more so than it was 3GPP's job to prescribe that E2+=0D=0Ahad to be the PS= AP/ALI to GMLC interface protocol used for CS E9-1-1=0D=0Acalls.=0D=0A=0D=0A= 2. Handover between different IP access networks=0D=0ANot specific to cellu= lar. There can be handover between WiFi and=0D=0AEthernet, WiFi and WiMAX a= nd so forth. Now - what we're really talking=0D=0Aabout here is a more fund= amental capability related to mobile IP. 3GPP=0D=0Adefinitely has a very ni= ce role to play in prescribing how this=0D=0Aaccess-mobility occurs across = the access technologies that 3GPP defines=0D=0Aand supports. Since the ECRI= T emergency model concerns itself from the=0D=0AIP layer up, it is quite po= ssible for it to work very transparently to=0D=0Asuch mobility occurring be= neath the surface. And, of course, any such=0D=0Anicely integrated access t= echnologies would offer a nicely integrated=0D=0ALIS solution to ensure tha= t the location service remains contiguous and=0D=0Aconsistent. It seems to = me that it's quite bad engineering to couple the=0D=0Amanner in which this = is done to a specific IP service such as emergency=0D=0Acalling. Can't help= it if 3GPP do that - but it doesn't obviate the=0D=0Aoption of ECRIT being= applied in the more elegant way.=0D=0A=0D=0A3. Handover to/from circuit mo= de networks=0D=0AI'll give you this one... to an extent. Obviously the IETF= doesn't think=0D=0Athis is in the least bit relevant to them. On the other= , in theory, a=0D=0AVoIP connection established on any form of IP access co= uld be handed=0D=0Aover to some other form of circuit access - e.g. DSL to = ISDN. The issue,=0D=0Aof course, is just how realistic these scenarios are.= If you accept that=0D=0Athe PSTN is going to go away (and I certainly do) = then you also=0D=0Aacknowledge that this is a transitional issue. You can a= rgue that the=0D=0APSTN is still going to be around for years to come (and = I also agree=0D=0Awith that) but that doesn't mean you have to create a spe= cific mechanism=0D=0Ato handover between circuit and packet for emergency s= ervices.=0D=0A=0D=0AI'm interested in just what it is that 3GPP have define= d for this. I=0D=0Alook at the current 23.167 specification and, I admit, i= t doesn't leap=0D=0Aout at me. The stage 2 description has always struck me= as kind of=0D=0Avague. The diagram concerning location information handlin= g, for=0D=0Aexample, has the dotted boxes with non-prescriptive steps sayin= g=0D=0A"procedure to obtain location" done here. It always kind of reminds = me=0D=0Aof that old cartoon with the engineers looking at the complex flow = chart=0D=0Awith the "a miracle happens here" box in the middle. I'm thinkin= g of a=0D=0Acall originated on IP. Let's say the E-CSCF invokes the E-SLP t= o do a=0D=0ASUPL NI-LR (assuming one manifestation of the dotted box in the= diagram)=0D=0Aand the resultant location is used to determine the correct = MGCF route=0D=0Ato deliver the call. Perhaps the PSAP supports an MLP inter= face to the=0D=0ALRF and can ask it for location updates - kicking off a SU= PL NI-LR=0D=0Aagain. Now - the device "roams" to a bit of the network that = can only=0D=0Asupport circuit service=3F What exactly happens=3F Does it in= itiate another=0D=0Acall via the MSC=3F How does that interact with the exi= sting emergency=0D=0Aservice semantics in the MSC=3F Obviously it wants to = initiate a whole new=0D=0Acall - and initiate control plane location determ= ination so it can=0D=0Areport an initial location to the GMLC. Is that GMLC= the same node as=0D=0Athe LRF=3F How does it deal with the fact that it's = now got two pieces of=0D=0Astate for what in theory is the same call=3F Or = is it - given the MSC=0D=0Acan't know about the PS call in progress=3F What= has 3GPP actually defined=0D=0Afor this=3F=0D=0A=0D=0AI am certainly inter= ested in the mechanics of how this is all=0D=0Aaccomplished and done reliab= ly. ITRW (the one you and I live in) 3G=0D=0Aoperators commonly force emerg= ency calls onto the GERAN just because=0D=0Athat's lower risk since GSM eme= rgency calling is well established and=0D=0Athings like UTDOA infrastructur= e are available on that access. This is=0D=0Aquite the opposite tendency of= looking to have seamless real time=0D=0Amigration between access technolog= ies on emergency calls (let alone=0D=0Aseamless migration between PS and CS= !). What carriers are planning to do=0D=0Athis with emergency calls if you = can say=3F=0D=0A=0D=0A4. Location for cellular access.=0D=0ACertainly not s= pecific to cellular access. Every technology has a need=0D=0Afor accurate l= ocation determination. Wired technologies also, most=0D=0Aappropriately, ne= ed the location to be provided in civic address form;=0D=0Asomething that t= he nominated LCPs are very good at. You're partly=0D=0Aconfusing the role o= f the LCP protocol with that of the server. You can=0D=0Asend a very simple= HELD request to a LIS to ask for location; it's=0D=0Aincredibly simple to = do; that's why HELD client implementations keep=0D=0Apopping up from differ= ent sources. The complex stuff happens on the=0D=0Aserver side. A LIS recei= ving such a request can invoke all manner of=0D=0Acontrol plane mechanisms = (for the confused - "control plane" is not an=0D=0Aantonym of "IP"; it just= means interaction occurs between network=0D=0Aelements and not over the tr= affic channel with the device). For example,=0D=0Athe LIS might do UTDOA. N= ow, I suspect you realize this and carefully=0D=0Achose examples of technol= ogies that involve measurements taken by the=0D=0Adevice. Fortunately this = is not precluded by HELD either; I believe=0D=0AJames has already pointed y= ou at the material for this.=0D=0A=0D=0AFinally, since "cellular (=3D3GPP)"= is clearly your one true interest=0D=0Ahere, the good news is that cellula= r networks already have terrific=0D=0Ainfrastructure and control plane mech= anisms in place for location=0D=0Adetermination. This includes the UE peer = signalling for AGPS, OTDOA and=0D=0Aso forth. All a LIS in a 3GPP network h= as to do is provide the semantics=0D=0Aof the LCP to the device and emergen= cy network clients and to invoke=0D=0Athat existing control plane infrastru= cture at the back end. It's=0D=0Acertainly a lower cost and more robust alt= ernative than building SUPL=0D=0Ainfrastructure in parallel to that control= plane capability which=0D=0Aalready exists to support CS emergency calls a= nyway.=0D=0A=0D=0A5. Endpoint based location and routing=0D=0ANothing cellu= lar specific about this one. Same thing applies to WiFi and=0D=0AWiMAX and = wired technologies too. The old "network loading" furphy is=0D=0Aoften roll= ed out for these sorts of discussions; presumably it's=0D=0Aattractive beca= use it sounds "technical" but doesn't really warrant=0D=0Aproper quantifica= tion and justification. Gosh "billions" of devices -=0D=0Ahow can we even c= onsider having so many devices doing... "stuff"=3F It=0D=0Adoes prompt me t= o ask the question "what part of the term 'broadband'=0D=0Adon't you unders= tand=3F" I'm going to take a wild stab and suggest that a=0D=0Adevice being= used to make an emergency call probably isn't "idle".=0D=0AFurther, with r= espect to the general IETF location service model, I'm=0D=0Agoing to sugges= t that a device that wants to ask for its location isn't=0D=0Aidle either. = Even further, I'm going to suggest that a LIS servicing a=0D=0Alocation der= eference can have enough integration with the access network=0D=0Ato have t= he device paged and for location procedures to proceed (i.e.=0D=0Ajust like= a control plane MT-LR or a SUPL NI-LR - though the latter is=0D=0Aan ill-d= efined proposition with respect to arbitrary access types).=0D=0A=0D=0AActu= ally your commentary on this section strongly suggests to me that=0D=0Ayou = don't actually understand how an ECRIT emergency call procedure=0D=0Aworks.= You've certainly tried to characterize all this LoST and PSAP=0D=0Aboundar= y stuff that's going on as a big deal. It isn't and there's=0D=0Acertainly = no more going on from either a device or network perspective=0D=0Athan ther= e would be to provide the same functionality via a control=0D=0Aplane or SU= PL approach. If you'd like an offline overview of how an=0D=0AECRIT emergen= cy call is made, let me know; it would be my pleasure.=0D=0A=0D=0A6. Suppor= t of unauthenticated users=0D=0ADefinitely not a cellular specific issue; e= very access technology has to=0D=0Aask itself about this. Actually every re= gulator in every jurisdiction=0D=0Ahas to ask themselves about this too - a= nd hopefully they can avoid the=0D=0Amistake of thinking one form of public= access technology is "special"=0D=0Acompared to others as well. That would= mitigate the risk of them coming=0D=0Aup with inconsistent and confusing l= egislation.=0D=0A=0D=0AECRIT is based on IP - so the key first step to gett= ing an=0D=0AECRIT-compliant emergency call underway is for the device to ha= ve IP=0D=0Aaccess. In 3GPP parlance, you'd say it needs to have a network c= ontext.=0D=0AA good example of providing ECRIT-compliant emergency calling = to=0D=0Aunauthenticated devices is WiFi hotspots. Hotspots typically provid= e=0D=0Afree layer 2 connectivity and an IP context in the first instance.=0D= =0ADevice traffic is "port-trapped" to the Hotspots' web site (and maybe a=0D= =0Asmattering of public Internet websites as well). The firewall isn't=0D=0A= opened up until the user "authenticates"; the valid token very often=0D=0At= aking the form of a credit card number and expiry date. So -what would=0D=0A= a Hotspot need to do to provide "unauthenticated" emergency access=3F All=0D= =0Ait needs to do is to ensure that unauthenticated devices, in addition to=0D= =0Ahaving access to the portal web page, also have access to a LIS, a LoST=0D= =0Aserver and to the PSAP URI(s) which service the location of that=0D=0Aho= tspot. That's it; sure there's no emergency call proxy via a third=0D=0Apar= ty VSP - but that's not necessary (I'm actually against it anyway)=0D=0Abut= it could be accommodated with some tweaks on the approach described.=0D=0A=0D= =0ANow - what would a 3GPP network need to do to support an ECRIT-compliant=0D= =0Aunauthenticated emergency calling facility=3F You could probably describ= e=0D=0Ait better than me - but I dare say it would involve allowing the dev= ice=0D=0Ato establish an emergency IP context (something which I believe is=0D= =0Arequired by 23.167 anyway - otherwise how would the UE be able to tell=0D= =0Athe P-CSCF it wants to do an emergency call=3F). Having permitted the=0D= =0Acreation of the emergency context, the 3GPP network would similarly just=0D= =0Aneed to constrain the device's access to the LIS, LoST, and the PSAP=0D=0A= URI(s) for the corresponding location. Obviously 3GPP have decided to=0D=0A= define a different way of doing things and that's par for the course.=0D=0A= It's 3GPP's prerogative to continue to act as if there is something=0D=0Asp= ecial about cellular and that there's good reason for it to look=0D=0Adiffe= rent to both IP devices and the emergency network. It's not true -=0D=0Abut= that's never stopped the silo thinking before. And that puts me in=0D=0Ami= nd of that scene from Python's Holy Grail movie. 3GPP guarding the=0D=0Abri= dge to "cellular land" - "None shall pass..." - It'll end much the=0D=0Asam= e way as well.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A-----Original Message---= --=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Beh= alf=0D=0AOf Edge, Stephen=0D=0ASent: Wednesday, 4 March 2009 4:32 PM=0D=0AT= o: br@brianrosen.net=0D=0ACc: ECRIT=0D=0ASubject: Re: [Ecrit] Comments on F= ramework Draft=0D=0A=0D=0ABrian=0D=0A=0D=0AThanks for these well considered= responses. Below I am providing on an=0D=0Aitem by item basis, and taking = into account your responses, a few more=0D=0Areasons why the current Ecrit = solution is unsuitable - or, if you=0D=0Aprefer, less suitable than the 3GP= P/3GPP2 solution - for cellular=0D=0Anetworks.=0D=0A=0D=0A1. Access to PSTN= capable PSAPs=0D=0AAssuming that the best available solution for this curr= ently is the=0D=0Aongoing NENA i2 standard (as you comment), then there are= problems with=0D=0Aproviding location for dispatch (initial and updated lo= cation). For=0D=0Aexample, the latest i2.5 draft I have (December 2008) say= s that the VPC=0D=0Ato LIS v3 interface is being deprecated (thus not avail= able), although=0D=0Athis is the interface that the VPC would use to query = location from the=0D=0ALIS. Also I don't see any inclusion of accurate posi= tioning support -=0D=0Ae.g. using A-GPS. Further, interworking with the cir= cuit mode side for=0D=0AUA access (as opposed to PSAP access) seems to be o= ut of scope. So at=0D=0Abest, this standard is incomplete (i.e. not yet sui= table for cellular=0D=0Anetworks). However, I agree that there is some over= lap between i2.5 and=0D=0Athe 3GPP/3GPP2 solution.=0D=0A=0D=0A2. Handover b= etween different IP access networks including different=0D=0Atypes of acces= s network=0D=0AOne of the issues here would be change of LIS across differe= nt networks=0D=0Awhile avoiding impacts to both IP and PSTN capable PSAPs (= i.e. handover=0D=0Amust be transparent to PSAPs within the limitations impo= sed by SIP or=0D=0Asome J-STD-036 type of circuit mode solution). The probl= em gets more=0D=0Adifficult when handover to/from circuit mode access netwo= rks is=0D=0Aconsidered. So far, 3GPP/3GPP2 has not yet agreed on a solution= although=0D=0Athere are proposals and we expect some resolution soon. On t= he Ecrit and=0D=0ANENA sides, I see much less progress.=0D=0A=0D=0A3. Hando= ver to/from circuit mode networks=0D=0AWe agree here at least on the out of= scope aspect. I suppose I can=0D=0Aaccept that it is not customary to poin= t this out in IETF standards. But=0D=0AI hope you can see that this is an i= ssue for cellular networks most of=0D=0Awhich will have extensive circuit m= ode coverage for a long time to come.=0D=0A=0D=0A4. Location for cellular a= ccess (and the requirement to support LCPs=0D=0Athat will be useless for ce= llular access)=0D=0AThe issue is not so much the LCP itself but the capabil= ity to support=0D=0Aaccurate positioning - e.g. using A-GPS, AFLT, OTDOA, e= nhanced cell ID=0D=0Aetc. None of those methods seem to be supported as par= t of DHCP or HELD=0D=0Aright now. So some modification of the LCP related r= equirements or of=0D=0Athe LCPs seems needed.=0D=0A=0D=0A5. Endpoint based = location and routing for cellular access (issues here=0D=0Aare network and = device loading as well as device impacts and problems=0D=0Awith PSTN capabl= e PSAPs)=0D=0AEndpoint based location when spread over millions (billions,=0D= =0Aplanet-wide) of terminals will consume significant network and terminal=0D= =0Aresources. A typical terminal is generally idle and interacts with the=0D= =0Anetwork very sparingly to update the network with its current location=0D= =0A(e.g. current cluster of potential serving cells). Performing network=0D= =0Aassisted periodic location fixes and LoST queries would add=0D=0Asignifi= cantly to network load. Performing periodic location fixes in the=0D=0Aterm= inal (e.g. using GPS) and estimating when a PSAP boundary may have=0D=0Abee= n crossed would add to terminal load (e.g. thus battery drain).=0D=0AOptimi= zations would be possible of course - e.g. based on observing=0D=0Anearby c= ell IDs - but they will add to terminal complexity and testing=0D=0Acosts. = I agree that the Ecrit solution does allow for proxies to do this=0D=0Abut = here the solution also becomes incomplete because there seem no=0D=0Adetail= s of how this would work - e.g. what location solutions would then=0D=0Abe = used.=0D=0A=0D=0A6. Support of unauthenticated users and users who can be a= uthenticated=0D=0Abut are not permitted access/VSP service except for emerg= ency calls=0D=0AI think the Ecrit solution and you both assume that this ha= s already=0D=0Abeen resolved somehow at the access level and therefore the = various=0D=0Aprocedures in Ecrit can still be used. Maybe that is valid. Ho= wever,=0D=0Athere are still problems that are not covered in the Ecrit draf= ts but=0D=0Aneed to be resolved including (a) obtaining IP access (e.g. via= a WLAN,=0D=0Acellular network, cable link) when not a valid subscriber, (b= ) obtaining=0D=0Aaccess to the VSP and (c) ensuring only emergency related = services are=0D=0Aprovided (e.g. and not free Internet and location access)= =2E These and=0D=0Aadditional problems (e.g. UA identification) would have = to be solved,=0D=0Amaybe on a per access basis, and then ensured to be comp= atible with the=0D=0Arest of the Ecrit solution. A significant part of the = 3GPP/3GPP2=0D=0Asolution is concerned with this aspect and it has delayed c= ompletion of=0D=0Athe solution for the more normal case of valid subscriber= access due to=0D=0Asuch compatibility issues.=0D=0A=0D=0AKind Regards=0D=0A=0D= =0AStephen=0D=0A-----Original Message-----=0D=0AFrom: br@brianrosen.net [ma= ilto:br@brianrosen.net]=0D=0ASent: Friday, February 27, 2009 6:53 AM=0D=0AT= o: Edge, Stephen=0D=0ACc: Thomson, Martin; Richard Barnes; ECRIT=0D=0ASubje= ct: Re: [Ecrit] Comments on Framework Draft=0D=0A=0D=0AStephen=0D=0A=0D=0AL= ike any standards organization, the IETF restricts it's scope.=0D=0AGeneral= ly, the scope is "the Internet", although we very often describe=0D=0Asolut= ions that are explicitly designed for private IP networks as well=0D=0Aas=0D= =0Athe Internet. We don't write standards for circuit switched networks,=0D= =0Aand=0D=0Ait should be no surprise that the ecrit solution does not cater= to CS=0D=0Asolutions. Nevertheless, we often try to make sure that our so= lutions=0D=0Aharmonize reasonably well with existing solutions.=0D=0A=0D=0A= Indeed, the ecrit solution clains global applicability to the Internet=0D=0A= in=0D=0Ageneral, and most private IP networks that can be interconnected to= the=0D=0AInternet or to other IP networks via gateways. Looking at your l= ist of=0D=0Aproblem areas:=0D=0A> - access to PSTN capable PSAPs=0D=0AThi= s is out of scope for IETF. NENA has active work on this subject.=0D=0AIt=0D= =0Aseems straightforward to interwork ecrit compatible devices and networks=0D= =0Ato existing CS connected PSAPs. As you know, CS interconnects are very=0D= =0Anation-specific, so the NENA work may not have general applicability.=0D= =0AHowever, it shows that it is possible to interwork. The NENA i2 work is=0D= =0Aalso designed to take ecrit compatible devices and VSP networks, and=0D=0A= interwork them to the existing network. The VSP would direct the call=0D=0A= to=0D=0Athe VPC, which would provide the services it does now, using the de= vice=0D=0Aprovided location for routing. This is important for smooth tran= sition=0D=0Afrom existing PSAPs and VSPs to "next generation" PSAPs and VSP= s.=0D=0A> - handover between different IP access networks including diffe= rent=0D=0A> types of access network=0D=0AIn the ecrit solution, the access = network the call is initiated on=0D=0Aprovides all the facilities needed fo= r the device to initiate an=0D=0Aemergency=0D=0Acall. The call starts tra= versing it's normal call path, and eventually=0D=0Aroutes to the ESRP. Han= doffs between IP networks should be transparent=0D=0Ato=0D=0Athis process, = although we probably haven't done all the work we need to=0D=0Ado=0D=0Afor = handoffs where the IP address as seen by the terminating network=0D=0Achang= es. This would generally be true of all current SIP based work.=0D=0A> -= handover to/from circuit mode networks=0D=0AThis would be out of scope for= IETF. It's as applicable to a simple SIP=0D=0Acall as it is a SIP emergen= cy call, and there are no statements in any=0D=0ASIP=0D=0Adocuments on that= subject.=0D=0A> - location for cellular access (and the requirement to s= upport LCPs=0D=0Athat=0D=0A> will be useless for cellular access)=0D=0ALoca= tion for cellular access networks has been considered carefully.=0D=0ASince= cellular is a mobile network, the access network would pass the=0D=0Adevic= e a Location-By-Reference URI, using either DHCP or HELD. Either=0D=0Aprot= ocol is suitable for cellular networks. As we have pointed out=0D=0Asevera= l times, cellular networks support raw data packet services upon=0D=0Awhich= many different kinds of networks can be constructed. My usual=0D=0Aexampl= e is a large recreational vehicle traveling down a road with a=0D=0Acellula= r data card plugged into a router to which a wired (Ethernet)=0D=0Aphone=0D= =0Ais connected. That phone must be able to make an emergency call, and it=0D= =0Awill get location from DHCP or HELD (or LLDP-MED). It is not aware of=0D= =0Athe=0D=0Acellular network, and doesn't know any cellular specific protoc= ols.=0D=0ACellular networks will have to support IETF location configuratio= n=0D=0Aprotocols unless they actively prohibit examples like this, or they=0D= =0Aimplement interworking between cellular-specific location protocols and=0D= =0ADHCP or HELD in the data card. The ecrit standards permit proxy=0D=0Ain= sertion=0D=0Aof location, but, as above, we don't think that works in all c= ases.=0D=0A> - endpoint based location and routing for cellular access (i= ssues=0D=0Ahere=0D=0A> are network and device loading as well as device imp= acts and problems=0D=0A> with PSTN capable PSAPs)=0D=0AThe "load" of using = DHCP or HELD to get location and querying LoST is=0D=0Apretty modest. The = standards permit proxies to do this if the devices=0D=0Adon't. As above, i= nterwork functions to CS connected PSAPs is very=0D=0Afeasible, and as abov= e, cellular networks will have to support access to=0D=0Alocal LoST servers= for devices that are connected to cellular networks=0D=0Aand=0D=0Aare ecri= t compliant.=0D=0A> - support of unauthenticated users and users who can = be=0D=0Aauthenticated=0D=0A> but are not permitted access/VSP service excep= t for emergency calls=0D=0AThis is covered in the standards. None of the p= rocesses are dependent=0D=0Aon=0D=0Aauthentication, although where it is po= ssible, it's desirable so as to=0D=0Aminimize fraudulent emergency calls=0D= =0AMechanisms for specific network authentication mechanisms are out of=0D=0A= scope, and, like SIP basic calling, are not usually mentioned in IETF=0D=0A= documents.=0D=0A=0D=0AStephen, we've tried pretty hard to make sure this wo= rks for 3G/4G=0D=0Amobile=0D=0Anetworks. It's true that it doesn't do it t= he way 3GPP currently thinks=0D=0Ait ought to work, but we claim they haven= 't thought through all the=0D=0Aissues. While it would work, there are opp= ortunities for improvement.=0D=0AWe=0D=0Awould be willing to do that if we = could get the cooperation of 3GPP,=0D=0Awhich=0D=0Awe have tried, and faile= d, to do.=0D=0A=0D=0ASo, I think the documents do not need any qualificatio= n statements.=0D=0A=0D=0ABrian=0D=0A=0D=0A> Martin=0D=0A>=0D=0A> The 3GPP/3= GPP2 solution has a defined restricted applicability (mainly=0D=0Ato=0D=0A>= 3GPP/3GPP2 access networks where the serving network also acts as the=0D=0A= VSP)=0D=0A> and the specifications for it cover in detail all possible scen= arios=0D=0A> consistent with these restrictions so far as we are aware.=0D=0A= >=0D=0A> The Ecrit solution seems to claim global applicability to all type= s of=0D=0AIP=0D=0A> access (and the more that is said about this from Ecrit= participants=0D=0Athe=0D=0A> more this gets emphasized) but does not cover= in detail all possible=0D=0A> scenarios (in some cases does not cover in a= ny detail) which means=0D=0Athat at=0D=0A> best the solution is incomplete = and at worst intrinsically=0D=0Ainapplicable to=0D=0A> some unstated set of= scenarios.=0D=0A>=0D=0A> The missing, incomplete and problematic cases inc= lude the following:=0D=0A>=0D=0A> - access to PSTN capable PSAPs=0D=0A> = - handover between different IP access networks including different=0D=0A>= types of access network=0D=0A> - handover to/from circuit mode networks=0D= =0A> - location for cellular access (and the requirement to support LCPs=0D= =0Athat=0D=0A> will be useless for cellular access)=0D=0A> - endpoint bas= ed location and routing for cellular access (issues=0D=0Ahere=0D=0A> are ne= twork and device loading as well as device impacts and problems=0D=0A> with= PSTN capable PSAPs)=0D=0A> - support of unauthenticated users and users = who can be=0D=0Aauthenticated=0D=0A> but are not permitted access/VSP servi= ce except for emergency calls=0D=0A>=0D=0A> Stating that some of these case= s are out of scope or referencing an=0D=0A> incomplete and possibly questio= nable specification from some other=0D=0A> national SDO will not help the u= ser who encounters such problems. But=0D=0Ait=0D=0A> would certainly help n= etwork operators and implementers to acknowledge=0D=0A> their existence in = one form or another because that would allow better=0D=0A> planning of depl= oyments and would help focus attention on finding=0D=0A> solutions (whether= in IETF or elsewhere) for the missing cases.=0D=0A>=0D=0A> Please note tha= t despite these drawbacks, I will acknowledge that=0D=0AEcrit=0D=0A> does h= ave a valuable solution that covers many scenarios not covered=0D=0Aby=0D=0A= > 3GPP/3GPP2. It would be the delineation of these supported scenarios=0D=0A= (or=0D=0A> equivalently unsupported scenarios) in some applicability statem= ent=0D=0Athat=0D=0A> would be particularly useful right now.=0D=0A>=0D=0A> = Kind Regards=0D=0A>=0D=0A> Stephen=0D=0A> -----Original Message-----=0D=0A>= From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=0D=0A> Sent: Thur= sday, February 26, 2009 9:45 PM=0D=0A> To: Edge, Stephen; Richard Barnes=0D= =0A> Cc: ECRIT=0D=0A> Subject: RE: [Ecrit] Comments on Framework Draft=0D=0A= >=0D=0A> There's benefit in knowing the limitations of a framework, and eve= ry=0D=0A> architecture makes certain assumptions. Let's examine them thoug= h...=0D=0A>=0D=0A> The IETF might occasionally make the assumption that the= standards it=0D=0A> develops are for Internet devices. That assumption pr= obably need not=0D=0Abe=0D=0A> stated explicitly.=0D=0A>=0D=0A> The ECRIT a= rchitecture relies on implementations of the protocols that=0D=0Ait=0D=0A> = references. That is not extraordinary. A reliance on implementation=0D=0A= of=0D=0A> these protocols by endpoints, routing intermediaries and PSAPs sh= ould=0D=0Anot=0D=0A> need to be explained.=0D=0A>=0D=0A> So the assumptions= are:=0D=0A> - the Internet=0D=0A> - solutions are implemented and deploy= ed=0D=0A> - the end device is a key component=0D=0A>=0D=0A> Only that last= element is particularly novel ... or not that much=0D=0Areally.=0D=0A> I= t's a design choice. Unless you were thinking of trunking the=0D=0Avoice=0D= =0A> elsewhere.=0D=0A>=0D=0A> Of course, you're suggesting that the design = choice was made in=0D=0Aignorance=0D=0A> of all the constraints. You're su= ggesting that - as a result - the=0D=0Achoice=0D=0A> is flawed and the solu= tion is not going to work for cellular services.=0D=0AWe=0D=0A> disagree. = The solution is a basis for emergency calling in _any_ IP=0D=0A> network.=0D= =0A>=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=0D=0A>=0D=0A>> -----Original Messa= ge-----=0D=0A>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org= ] On=0D=0ABehalf=0D=0A>> Of Edge, Stephen=0D=0A>> Sent: Friday, 27 February= 2009 3:30 PM=0D=0A>> To: Richard Barnes=0D=0A>> Cc: 'ECRIT'=0D=0A>> Subjec= t: Re: [Ecrit] Comments on Framework Draft=0D=0A>>=0D=0A>> Hi Richard=0D=0A= >>=0D=0A>> Thanks for the comments. Your statement below that "SIP emergenc= y=0D=0A>> calling works if all parties behave as specified in these (IETF=0D= =0AEcrit)=0D=0A>> documents" to some degree highlights the problems we are = raising. The=0D=0A>> documents do contain a number of implicit and explicit= restrictions -=0D=0A>> like IP capable PSAPs, global IP access (no islands= of circuit mode=0D=0A>> access for example), universal support of this sol= ution by all access=0D=0A>> providers and VSPs (not much good if some opt f= or another solution)=0D=0Aand=0D=0A>> end system oriented location and rout= ing capability - which together=0D=0A>> make them unsuitable (we believe) f= or cellular wireless networks. If=0D=0A>> these restrictions and assumption= s were all made explicit upfront, it=0D=0A>> would to a large degree (and p= ossibly completely) address our=0D=0Aconcerns.=0D=0A>>=0D=0A>> You are righ= t in assuming another set of specifications for the 3GPP=0D=0A>> and 3GPP2 = solution. The applicability of this solution is explicitly=0D=0A>> defined = in TS 23.167 (or more exactly in an already agreed CR in=0D=0A>> contributi= on S2-090752 which will become part of 23.167 in a few more=0D=0A>> weeks) = to cover the following access types: GPRS (UTRAN WCDMA),=0D=0AI-WLAN,=0D=0A= >> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN=0D=0A>= > (LTE). So there is a restriction and arbitrary internet access is not=0D=0A= >> covered (yet) as I have stated before.=0D=0A>>=0D=0A>> Kind Regards=0D=0A= >>=0D=0A>> Stephen=0D=0A>> -----Original Message-----=0D=0A>> From: Richard= Barnes [mailto:rbarnes@bbn.com]=0D=0A>> Sent: Wednesday, February 25, 2009= 6:30 PM=0D=0A>> To: Edge, Stephen=0D=0A>> Cc: Brian Rosen; 'ECRIT'=0D=0A>>= Subject: Re: [Ecrit] Comments on Framework Draft=0D=0A>>=0D=0A>> Hi Stephe= n,=0D=0A>>=0D=0A>> I'm a little confused by the scope of what you're asking= =2E The=0D=0A>> framework=0D=0A>> and phonebcp documents exist in order to= describe the ECRIT solution:=0D=0A>> They say, in effect, "SIP emergency c= alling works if all parties=0D=0Abehave=0D=0A>> as specified in these docum= ents."=0D=0A>>=0D=0A>> As I understand what you're saying (and I'm by no me= ans an expert in=0D=0A>> 3GPP), 3GPP specifies that one or more elements of= this system behave=0D=0A>> differently. This simply means that 3GPP netwo= rks aren't complying=0D=0A>> with=0D=0A>> these specs. Just like there's n= o disclaimer in RFC 791 (IPv4) that=0D=0A>> says "this doesn't work on X.25= networks", it's not clear to me that=0D=0Aan=0D=0A>> analogous disclaimer = is called for here.=0D=0A>>=0D=0A>> I presume there are similar documents d= escribing how emergency=0D=0Acalling=0D=0A>> works in 3GPP networks. Do th= ey include notes saying that the 3GPP=0D=0A>> solution doesn't work in the = broader Internet=3F=0D=0A>>=0D=0A>> --Richard=0D=0A>>=0D=0A>>=0D=0A>>=0D=0A= >>=0D=0A>>=0D=0A>> Edge, Stephen wrote:=0D=0A>> > Brian=0D=0A>> >=0D=0A>> >= First of all apologies for the likely lateness of this reply - I=0D=0A>> a= ctually wrote it on 19 February in a 3GPP SA2 meeting in Budapest=0D=0Abut=0D= =0A>> it seems unlikely that my VPN, Outlook server and WiFi access=0D=0A>>= capability will cooperate together to get it sent until I return to=0D=0At= he=0D=0A>> office mid-next week.=0D=0A>> >=0D=0A>> > Anyhow thanks for your= comments. There have actually been a number=0D=0Aof=0D=0A>> conference cal= ls between IETF and 3GPP participants over the last=0D=0A>> couple of years= at which common features like support of IP emergency=0D=0A>> calls were d= iscussed and these could have been good forum for=0D=0A>> participants on e= ither side to have raised the kinds of issues you=0D=0A>> elaborate on belo= w. Given that seems not so far to have happened, it=0D=0A>> could still be = possible in future such calls.=0D=0A>> >=0D=0A>> > But the issues we are ra= ising are not directly to do with further=0D=0A>> aligning the 2 solutions = or with the lack of this in the past. We are=0D=0A>> simply pointing out th= at the solutions are currently different and=0D=0Athat=0D=0A>> from a cellu= lar wireless perspective, the Ecrit solution is not seen=0D=0Aas=0D=0A>> su= itable in all respects (for support of IP emergency calls=0D=0Aoriginating=0D= =0A>> from such access types). That is not just our point of view. 3GPP2=0D= =0Asent=0D=0A>> a liaison to Ecrit some months ago pointing out the same is= sues.=0D=0A>> >=0D=0A>> > So we are proposing that the Ecrit framework and = phoneBCP spec.s=0D=0A>> include a statement acknowledging this - e.g. by re= ferencing the=0D=0A>> alternative 3GPP/3GPP2 solution and indicating the IP= access types=0D=0Afor=0D=0A>> which the Ecrit solution will work without l= imitation (or=0D=0Aequivalently=0D=0A>> the access types where limitations = are not ruled out).=0D=0A>> >=0D=0A>> > We are not proposing further modifi= cation and extension of the=0D=0AEcrit=0D=0A>> solution - just pointing out= that this would be needed (as with the=0D=0A>> 3GPP/3GPP2 solution) to ful= ly cover all types of access.=0D=0A>> >=0D=0A>> > Kind Regards=0D=0A>> >=0D= =0A>> > Stephen=0D=0A>> > -----Original Message-----=0D=0A>> > From: Brian = Rosen [mailto:br@brianrosen.net]=0D=0A>> > Sent: Wednesday, February 18, 20= 09 8:07 PM=0D=0A>> > To: Edge, Stephen; 'ECRIT'=0D=0A>> > Subject: RE: [Ecr= it] Comments on Framework Draft=0D=0A>> >=0D=0A>> > I have bit my tongue on= this one for a long time.=0D=0A>> >=0D=0A>> > Stephen, with respect, pleas= e go talk to 3GPP management and ask=0D=0Athem=0D=0A>> why=0D=0A>> > there = has been no participation in the ecrit effort despite=0D=0Amultiple=0D=0A>>= YEARS=0D=0A>> > of begging them to get involved. To put it frankly, 3GPP = is quite=0D=0A>> willing=0D=0A>> > to bully IETF into doing its work on its= schedule, but cannot be=0D=0A>> bothered to=0D=0A>> > get work done it kno= ws it will eventually have to do when the IETF=0D=0A>> asks it=0D=0A>> > to= do so.=0D=0A>> >=0D=0A>> > 3GPP understands the mess that is being created= by not=0D=0Aparticipating.=0D=0A>> They=0D=0A>> > know full well that when= they finally get around to dealing with PS=0D=0A>> > terminated emergency = calls, that there will be a lot of resistance=0D=0Ato=0D=0A>> > changing fu= lly specified and implemented standards to more closely=0D=0A>> align=0D=0A= >> > with 3GPP standards. I expect you will have several interworking=0D=0A= >> functions=0D=0A>> > to define and build.=0D=0A>> >=0D=0A>> > So, politel= y, please go away, we're finishing work we dearly wanted=0D=0A>> you all=0D= =0A>> > to be involved with for years, but you refused to do anything.=0D=0A= It's=0D=0A>> too=0D=0A>> > late for this rev.=0D=0A>> >=0D=0A>> > Now, havi= ng said that, there are quite a few people who have=0D=0A>> participated in=0D= =0A>> > the IETF work who are IMS aware and I believe that despite your=0D=0A= >> fears,=0D=0A>> > everything you need is in the specs. The mechanisms we= have=0D=0Adefined=0D=0A>> provide=0D=0A>> > the ability for the network to= insert location, recognize and mark=0D=0A>> emergency=0D=0A>> > calls, and= route on behalf of endpoints. An E-CSCF could quite=0D=0A>> > straightfor= wardly provide a SIP call towards an ecrit compatible=0D=0A>> PSAP. The=0D= =0A>> > only not-quite-nice interwork would be from SUPL to HELD (or SIP),=0D= =0A>> but it's=0D=0A>> > pretty easy to do that. I'll also note that we ha= ve tried to get=0D=0AOMA=0D=0A>> and=0D=0A>> > IETF to cooperate on locatio= n protocols, but we have been=0D=0A>> spectacularly=0D=0A>> > unsuccessful = at that effort also.=0D=0A>> >=0D=0A>> > Brian=0D=0A>> >=0D=0A>> >=0D=0A>> = >=0D=0A>> >> -----Original Message-----=0D=0A>> >> From: ecrit-bounces@ietf= =2Eorg [mailto:ecrit-bounces@ietf.org] On=0D=0A>> Behalf=0D=0A>> >> Of Edge= , Stephen=0D=0A>> >> Sent: Thursday, February 05, 2009 2:50 AM=0D=0A>> >> T= o: 'ECRIT'=0D=0A>> >> Subject: [Ecrit] Comments on Framework Draft=0D=0A>> = >>=0D=0A>> >> All=0D=0A>> >>=0D=0A>> >> draft-ietf-ecrit-framework-07 is (a= s we see it) a mostly=0D=0Ainformative=0D=0A>> >> description of how termin= als and networks should support emergency=0D=0A>> >> calls made over IP cap= able facilities to IP capable PSAPs. It=0D=0A>> appears=0D=0A>> >> intended= to cover all types of access network - including fixed=0D=0A>> line,=0D=0A= >> >> WiFi and cellular (e.g. examples involving each can be found=0D=0A>> = throughout=0D=0A>> >> the draft).=0D=0A>> >>=0D=0A>> >> When we evaluated t= his with respect to support of wireless=0D=0Acellular=0D=0A>> >> access and= WiFi access associated with a cellular operator (e.g.=0D=0A>> WLAN=0D=0A>>= >> or Femto cells integrated into a cellular network), we found that=0D=0A= >> >> certain portions of the draft exhibited one or more of the=0D=0Afollo= wing=0D=0A>> >> characteristics:=0D=0A>> >>=0D=0A>> >> (A) Inconsistent= with already standardized wireless solutions=0D=0A>> >>=0D=0A>> >> (B)= Inconsistent with essential wireless requirements and=0D=0A>> >> conventio= ns=0D=0A>> >>=0D=0A>> >> (C) Already part of wireless standards or pote= ntially part of=0D=0A>> >> future standards=0D=0A>> >>=0D=0A>> >> (A) refer= s to all portions of the draft framework that differ from=0D=0A>> the=0D=0A= >> >> requirements and procedures currently standardized for wireless=0D=0A= >> >> emergency access by 3GPP, 3GPP2 and OMA. This is a plain=0D=0Adiffere= nce=0D=0A>> of=0D=0A>> >> solution and could be resolved through support of= both solutions=0D=0Aby=0D=0A>> >> terminals (with each solution being used= according to the type of=0D=0A>> >> access network and VSP) or could be re= solved by supporting only=0D=0Aone=0D=0A>> >> solution and accessing only t= he types of network supporting that=0D=0A>> >> solution. To acknowledge thi= s category, the framework document=0D=0Acould=0D=0A>> >> reference the appl= icable wireless standards and point out that=0D=0Athese=0D=0A>> >> are vali= d alternatives for wireless cellular based access.=0D=0A>> >>=0D=0A>> >> (B= ) refers to portions of the draft that would be unsuitable for=0D=0A>> >> w= ireless networks even if no alternative solution existed together=0D=0A>> w= ith=0D=0A>> >> other portions missing from the draft that would be needed t= o=0D=0Afully=0D=0A>> >> support wireless networks. Examples of the former i= nclude: (a)=0D=0A>> emphasis=0D=0A>> >> on endpoint derivation of location,= performance of Lost query and=0D=0A>> >> receipt of local dial strings; (b= ) restriction of LCPs to=0D=0Aprotocols=0D=0A>> >> that require terminal in= itiation (not allowing for network=0D=0A>> initiation=0D=0A>> >> as far as = we can tell) and that include two LCPs (DHCP and LLDP)=0D=0A>> that=0D=0A>>= >> are not applicable to (not defined for) cellular access; and (c)=0D=0At= he=0D=0A>> >> requirement that a terminal or at least a LIS will update the= PSAP=0D=0A>> >> whenever location changes. (a) is impractical due to netwo= rk and=0D=0A>> >> terminal loading consequences and failure to support non-= IP=0D=0Acapable=0D=0A>> >> PSAPs; (b) makes location verification and updat= ed location=0D=0A>> provision=0D=0A>> >> to PSAPs difficult or impossible; = while (c) is also incompatible=0D=0A>> with=0D=0A>> >> support of existing = non-IP capable PSAPs besides increasing=0D=0Aterminal=0D=0A>> >> load and p= ossibly interfering with optimum maintenance of the RF=0D=0A>> >> connectio= n (e.g. if a terminal has to tune away from the serving=0D=0A>> base=0D=0A>= > >> station or WLAN periodically to make location measurements).=0D=0A>> E= xamples=0D=0A>> >> of the latter include (d) absence of support for access = to non-IP=0D=0A>> >> capable PSAPs as already mentioned (e.g. to support E9= 11 phase 2=0D=0Ain=0D=0A>> the=0D=0A>> >> US); (e) no support for handover = from the IP to the circuit domain=0D=0A>> when=0D=0A>> >> a terminal loses = (e.g. moves out of) RF coverage in the IP domain;=0D=0A>> and=0D=0A>> >> (f= ) no allowance for limited access modes wherein a terminal may=0D=0A>> acce= ss=0D=0A>> >> a network only to place an emergency call with ensuing=0D=0Ar= estrictions=0D=0A>> on=0D=0A>> >> (for example) location acquisition, PSAP = callback and caller=0D=0A>> >> verification and identification to the PSAP.= To resolve this=0D=0A>> category=0D=0A>> >> either significant changes to = the framework document could be made=0D=0A>> or a=0D=0A>> >> disclaimer/app= licability statement could be added stating that=0D=0A>> support=0D=0A>> >>= of cellular wireless networks and their associated WLAN and Femto=0D=0A>> = >> access points is not covered.=0D=0A>> >>=0D=0A>> >> Category (C) compris= es concepts and capabilities in the draft that=0D=0A>> are=0D=0A>> >> eithe= r already part of the standardized solution for wireless=0D=0A>> networks=0D= =0A>> >> or that might be added at a later time. Examples of the former=0D=0A= >> include=0D=0A>> >> LoST, SIP location conveyance, general use of SIP, lo= cation for=0D=0A>> routing=0D=0A>> >> versus for dispatch, cellular positio= ning methods. Examples of the=0D=0A>> >> latter include use of location ref= erences and dereferencing and=0D=0A>> >> possible interworking between the = current wireless network=0D=0Asolutions=0D=0A>> >> (in 3GPP, 3GPP2 and OMA)= and the solution described in this draft.=0D=0A>> The=0D=0A>> >> presence = of this category could be acknowledged by following the=0D=0A>> >> disclaim= er for (B) with a statement that certain portions of the=0D=0A>> >> solutio= n are expected to be incorporated into wireless networks=0D=0Anow=0D=0A>> >= > and/or in the future.=0D=0A>> >>=0D=0A>> >> We hope that these comments w= ill be seen to be a useful addition=0D=0Ato=0D=0A>> >> this review in the s= ense of enabling a more precise scoping for=0D=0Athe=0D=0A>> >> framework d= ocument and we are willing to assist in providing=0D=0Awording=0D=0A>> >> f= or any disclaimer/applicability statement that the Ecrit working=0D=0A>> gr= oup=0D=0A>> >> may now deem fit to include.=0D=0A>> >>=0D=0A>> >> Kind Rega= rds=0D=0A>> >>=0D=0A>> >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kir= k Burroughs=0D=0A>> (Qualcomm=0D=0A>> >> 3GPP2 TSG-X and TSG-C participant)=0D= =0A>> >>=0D=0A>> >> PS this being sent on 2/4/09 at 11:50pm PST=0D=0A>> >>=0D= =0A>> >> _______________________________________________=0D=0A>> >> Ecrit m= ailing list=0D=0A>> >> Ecrit@ietf.org=0D=0A>> >> https://www.ietf.org/mailm= an/listinfo/ecrit=0D=0A>> >=0D=0A>> > _____________________________________= __________=0D=0A>> > Ecrit mailing list=0D=0A>> > Ecrit@ietf.org=0D=0A>> > = https://www.ietf.org/mailman/listinfo/ecrit=0D=0A>> >=0D=0A>> _____________= __________________________________=0D=0A>> Ecrit mailing list=0D=0A>> Ecrit= @ietf.org=0D=0A>> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A>=0D=0A>=0D= =0A------------------------------------------------------------------------=0D= =0A------------------------=0D=0A> This message is for the designated recip= ient only and may=0D=0A> contain privileged, proprietary, or otherwise priv= ate information.=0D=0A> If you have received it in error, please notify the= sender=0D=0A> immediately and delete the original. Any unauthorized use o= f=0D=0A> this email is prohibited.=0D=0A>=0D=0A----------------------------= --------------------------------------------=0D=0A------------------------=0D= =0A> [mf2]=0D=0A> _______________________________________________=0D=0A> Ec= rit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www.ietf.org/mailman/= listinfo/ecrit=0D=0A>=0D=0A=0D=0A__________________________________________= _____=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org= /mailman/listinfo/ecrit=0D=0A=0D=0A----------------------------------------= --------------------------------=0D=0A------------------------=0D=0AThis me= ssage is for the designated recipient only and may=0D=0Acontain privileged,= proprietary, or otherwise private information.=0D=0AIf you have received i= t in error, please notify the sender=0D=0Aimmediately and delete the origin= al. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A----------= --------------------------------------------------------------=0D=0A-------= -----------------=0D=0A[mf2]=0D=0A=0D=0A=0D=0A-----------------------------= -------------------------------------------------------------------=0D=0ATh= is message is for the designated recipient only and may=0D=0Acontain privil= eged, proprietary, or otherwise private information. =20=0D=0AIf you have r= eceived it in error, please notify the sender=0D=0Aimmediately and delete t= he original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A-= ---------------------------------------------------------------------------= --------------------=0D=0A[mf2]=0D=0A From sedge@qualcomm.com Mon Mar 9 19:38:59 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A8553A6879 for ; Mon, 9 Mar 2009 19:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.537 X-Spam-Level: X-Spam-Status: No, score=-105.537 tagged_above=-999 required=5 tests=[AWL=1.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dtd5IfWk+Sf for ; Mon, 9 Mar 2009 19:38:55 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 546C93A69A8 for ; Mon, 9 Mar 2009 19:38:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1236652770; x=1268188770; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" Dawson,=20Martin"=20,=0D=0A=20 =20=20=20=20=20=20=20"br@brianrosen.net"=0D=0A=09|CC:=20ECRIT=20|Date:=20Mon, =209=20Mar=202009=2019:39:16=20-0700|Subject:=20RE:=20[Ec rit]=20Comments=20on=20Framework=20Draft|Thread-Topic:=20 [Ecrit]=20Comments=20on=20Framework=20Draft|Thread-Index: =20AcmY6xBP94jupkzETj+iA0b5U69mvgDj/IbwAGceYlAAwDSRoAAC5d HQAAEvOgA=3D|Message-ID:=20<1288E74A73964940B132A0B9EA8D8 ABC5374A407@NASANEXMB04.na.qualcomm.com>|References:=20<1 288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qu alcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A 73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm. com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA 8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73 964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.co m><64147.24.154.127.233.1235746352.squirrel@www.brianrose n.net>=0D=0A=20<1288E74A73964940B132A0B9EA8D8ABC5374A0D6@ NASANEXMB04.na.qualcomm.com>=0D=0A=20=0D=0A=20<1288E74 A73964940B132A0B9EA8D8ABC5374A3FE@NASANEXMB04.na.qualcomm .com>=0D=0A=20|In-Reply-To:=20|Accept-Language:=20e n-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5548"=3B=20a=3D"16123302"; bh=CCv6wNg/N0/MCkNBBXVo69q+ZeajCScX44LijJyXGMo=; b=ctmjzMt6CzK0qUpRTBRzy0Z/k5rTB7Ys33aYjPvoLzc6d0sf5n1hxNvr 4x0lLJo0sNcTAkdBsO9ZFB9NTidlVofGxzYUF6puIBAT+RlLmU/XCwEPV KaEsKuqGTbsuj06+IScpR+vUdj3WQITJgDY4bUL3lOq7qMFaxv8qYMGGN U=; X-IronPort-AV: E=McAfee;i="5300,2777,5548"; a="16123302" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Mar 2009 19:39:19 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2A2dJxY014604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Mar 2009 19:39:19 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2A2dIjv009783 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 9 Mar 2009 19:39:19 -0700 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub06.na.qualcomm.com ([129.46.134.254]) with mapi; Mon, 9 Mar 2009 19:39:18 -0700 From: "Edge, Stephen" To: "Dawson, Martin" , "br@brianrosen.net" Date: Mon, 9 Mar 2009 19:39:16 -0700 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmY6xBP94jupkzETj+iA0b5U69mvgDj/IbwAGceYlAAwDSRoAAC5dHQAAEvOgA= Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5374A407@NASANEXMB04.na.qualcomm.com> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com><64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net> <1288E74A73964940B132A0B9EA8D8ABC5374A0D6@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5374A3FE@NASANEXMB04.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 02:38:59 -0000 Martin Your earlier comments implied to me that you thought that problems 1, 2, 3,= 4 and 6 were not the responsibility of Ecrit but that of individual SDOs a= ssociated with particular AN types or, in the case of PSTN capable PSAP acc= ess, some national SDO like NENA. Can you clarify whether that is true and,= if not, who would or might standardize solutions for these? Kind Regards Stephen -----Original Message----- From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] Sent: Monday, March 09, 2009 7:28 PM To: Edge, Stephen; br@brianrosen.net Cc: ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Hi Stephen, No - I'd say you've gotten hold of the wrong end of the stick; at least in terms of the conclusion you're trying to drive. What I'm saying is that none of the issues you brought up are specific to cellular and that, further, a properly engineered access - whether it is multi-technology or not - will support an ECRIT methodology transparently. To use an analogy, a DNS service in an access network can be similarly affected by many of the types of considerations you raise. Nevertheless, a DNS service can be quite transparently provided to clients running on attached hosts, and without having to change their behaviour just because it's a 3G network, despite this fact. By the same token, it would hardly be appropriate for a DNS specification to start talking about the sorts of things an access implementer might need to do to achieve this. Certainly, and ultimately, it's up to 3G network implementers whether they want to support a general Internet emergency architecture (so that, for example, an emergency client on a laptop with a 3G modem can work just as well on that network as it would attached to a residential Ethernet connection, or that an emergency calling client on a PSP could work just as well on a 3G WiFi router as it would when attached to WiFi hotspot). Alternatively, if the network implementer just wants to support a 3GPP specific model for emergency calling that pre-supposes an IMS subscription and which is targeted at conventional notions of handsets then they also have the choice of following those context-limited specifications of 3GPP. There's no doubt, however, that the needs of the latter can be met by implementing the infrastructure required for the former but the converse is not true. You are quite correct to *not* say that the "problems" you identify below can't be solved. They most certainly can - and it's barely true to say that they are problematic. They are no more so than any engineering challenge. If you don't think this sort of challenge hasn't applied to cellular emergency services, despite 3GPP specifications, then you must not have been involved in any implementation. You would be right to infer from my discourse that I think 3GPP could do a much better, and more helpful, job of documenting how the ECRIT emergency model should be supported. But they don't have to (and certainly don't appear to be inclined to) for network implementers to be able to do it anyway. I see your tack here, now, is to try and get an alternative statement in the framework - that could perhaps be used to make the argument that the IETF doesn't know how ECRIT can be implemented in 3G networks. That would be a misrepresentation of the point that these considerations are out of scope and, as for the DNS example, it wouldn't be appropriate anyway. I don't presume to speak for the IETF. I think you know how it's organized and that nobody can guarantee that somebody isn't going to post some new proposal or other for a work item. Actually, you couldn't get that kind of "we'll never venture to specify X" statement out of 3GPP either. Cheers, Martin -----Original Message----- From: Edge, Stephen [mailto:sedge@qualcomm.com] Sent: Tuesday, 10 March 2009 12:23 PM To: Dawson, Martin; br@brianrosen.net Cc: ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Hi Martin Thanks for theses further comments - which I agree introduce a new twist to this discussion. Your main assertion seems to be that most of the general points I raised are not matters for Ecrit to resolve and standardize but instead represent problems to be resolved for the particular AN (either by an SDO associated with the AN by or by some national SDO like NENA in the case of PSAP access). The list of such issues seems to be: 1. Access to PSTN capable PSAPs 2. Handover between different IP access networks 3. Handover to/from circuit mode networks 4. Location for cellular access 6. Support of unauthenticated users (and users in limited service state) If I am generally right in this assumption, my first question is whether this is just your particular opinion or if this represents the view of Ecrit generally. E.G. is there any danger that Ecrit (or some other IETF group) might reclaim one or more of the above - perhaps after others SDOs (like 3GPP) have produced their own solutions? If you are all quite certain that this will not happen, or at least certain of this for some subset of the above, it would very much help to include a statement on this in the phoneBCP and/or framework drafts so there is no ambiguity. My next comment is that solving the above for each type of AN probably represents most of difficulty in producing a comprehensive solution. For example, handover after a location URI has been obtained from a LIS will be problematic for continuing location (since the previous and now wrong LIS may receive the next location request). Similarly access and handover to restricted areas (cells or networks a user is not normally allowed to use) is problematic particularly if normal IP connectivity is assumed. Further, use of HELD with a control plane location solution is highly problematic for any 3GPP network because the current architecture and procedures are not able to support location requests initiated solely from a location server (like an SMLC or SAS) where there no prior interaction with the RAN and CN. Further to that, control plane solutions cannot often obtain location accurately enough for dispatch and need to incorporate terminal based positioning using say A-GPS which can lead to a user plane solution like SUPL. I could add other problem areas if you believe this list is exhaustive. Now I am not saying that these problem areas cannot be solved - 3GPP and 3GPP2 have in fact solved most of them (and should complete this by the end of this year) in the context of the 3GPP/3GPP2 solution. But your position now seems to be that any SDO must solve them subject to the various restrictions and requirements imposed by the Ecrit phoneBCP and Framework drafts. Can you confirm that this is so? Kind Regards Stephen -----Original Message----- From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] Sent: Thursday, March 05, 2009 10:56 PM To: Edge, Stephen; br@brianrosen.net Cc: ECRIT Subject: RE: [Ecrit] Comments on Framework Draft There must be a word for the situation where everybody is talking about something but everybody knows the real subject is something else and what that real subject is. Suggestions welcome. Anyway, working on the basis that this whole thing isn't just about getting a "sound bite" added to the framework document that can be misappropriated for years to come to confuse the cellular industry into thinking ECRIT is not relevant to them, let's look at each of Stephen's topic areas below. A fundamental tenet of the argument is that, somehow, cellular is "special" and should be left to its "special" devices compared to every other Internet access technology. This, after all, is why we have IMS. It might have seemed reasonable ten years ago to define the core service architecture to accompany the new "Packet Service" mode of networking. In these days of Web 2.0, AJAX, Ruby on Rails, Flash, Silverlight, SOA, Azure... etc. against which IMS seems very.... "stodgy" it is reasonable to ask the question why such a monolithic and cellular-legacy service model is required. Nevertheless - 3GPP is entitled to do what 3GPP does. Actually I'm pretty sure you won't find references to IMS in Web 2.0 texts saying "of course cellular operators also use IMS as an application framework." Now - how specific are the "special" cases that are outlined below to cellular?: 1. Access to PSTN capable PSAPs Not specific to cellular. If a jurisdiction has PSTN capable PSAPs then VoIP calls originating from any form of access have to deal with that fact. The answer is fairly obvious - there has to be a media gateway behind the PSAP URI. And it might not just be a PSTN PSAP, there could be dedicated circuits to selective routers or, even, CAMA trunks involved. The manner in which this is done really does need to be spelt out by the jurisdiction; it can't be otherwise even if there are fairly common conventions. NENA looks after stating how this is done for the US. It's not up to 3GPP nor the IETF to tell jurisdictions how emergency calls that originate on Internet access get bridged into the legacy PSAP infrastructure. No more so than it was 3GPP's job to prescribe that E2+ had to be the PSAP/ALI to GMLC interface protocol used for CS E9-1-1 calls. 2. Handover between different IP access networks Not specific to cellular. There can be handover between WiFi and Ethernet, WiFi and WiMAX and so forth. Now - what we're really talking about here is a more fundamental capability related to mobile IP. 3GPP definitely has a very nice role to play in prescribing how this access-mobility occurs across the access technologies that 3GPP defines and supports. Since the ECRIT emergency model concerns itself from the IP layer up, it is quite possible for it to work very transparently to such mobility occurring beneath the surface. And, of course, any such nicely integrated access technologies would offer a nicely integrated LIS solution to ensure that the location service remains contiguous and consistent. It seems to me that it's quite bad engineering to couple the manner in which this is done to a specific IP service such as emergency calling. Can't help it if 3GPP do that - but it doesn't obviate the option of ECRIT being applied in the more elegant way. 3. Handover to/from circuit mode networks I'll give you this one... to an extent. Obviously the IETF doesn't think this is in the least bit relevant to them. On the other, in theory, a VoIP connection established on any form of IP access could be handed over to some other form of circuit access - e.g. DSL to ISDN. The issue, of course, is just how realistic these scenarios are. If you accept that the PSTN is going to go away (and I certainly do) then you also acknowledge that this is a transitional issue. You can argue that the PSTN is still going to be around for years to come (and I also agree with that) but that doesn't mean you have to create a specific mechanism to handover between circuit and packet for emergency services. I'm interested in just what it is that 3GPP have defined for this. I look at the current 23.167 specification and, I admit, it doesn't leap out at me. The stage 2 description has always struck me as kind of vague. The diagram concerning location information handling, for example, has the dotted boxes with non-prescriptive steps saying "procedure to obtain location" done here. It always kind of reminds me of that old cartoon with the engineers looking at the complex flow chart with the "a miracle happens here" box in the middle. I'm thinking of a call originated on IP. Let's say the E-CSCF invokes the E-SLP to do a SUPL NI-LR (assuming one manifestation of the dotted box in the diagram) and the resultant location is used to determine the correct MGCF route to deliver the call. Perhaps the PSAP supports an MLP interface to the LRF and can ask it for location updates - kicking off a SUPL NI-LR again. Now - the device "roams" to a bit of the network that can only support circuit service? What exactly happens? Does it initiate another call via the MSC? How does that interact with the existing emergency service semantics in the MSC? Obviously it wants to initiate a whole new call - and initiate control plane location determination so it can report an initial location to the GMLC. Is that GMLC the same node as the LRF? How does it deal with the fact that it's now got two pieces of state for what in theory is the same call? Or is it - given the MSC can't know about the PS call in progress? What has 3GPP actually defined for this? I am certainly interested in the mechanics of how this is all accomplished and done reliably. ITRW (the one you and I live in) 3G operators commonly force emergency calls onto the GERAN just because that's lower risk since GSM emergency calling is well established and things like UTDOA infrastructure are available on that access. This is quite the opposite tendency of looking to have seamless real time migration between access technologies on emergency calls (let alone seamless migration between PS and CS!). What carriers are planning to do this with emergency calls if you can say? 4. Location for cellular access. Certainly not specific to cellular access. Every technology has a need for accurate location determination. Wired technologies also, most appropriately, need the location to be provided in civic address form; something that the nominated LCPs are very good at. You're partly confusing the role of the LCP protocol with that of the server. You can send a very simple HELD request to a LIS to ask for location; it's incredibly simple to do; that's why HELD client implementations keep popping up from different sources. The complex stuff happens on the server side. A LIS receiving such a request can invoke all manner of control plane mechanisms (for the confused - "control plane" is not an antonym of "IP"; it just means interaction occurs between network elements and not over the traffic channel with the device). For example, the LIS might do UTDOA. Now, I suspect you realize this and carefully chose examples of technologies that involve measurements taken by the device. Fortunately this is not precluded by HELD either; I believe James has already pointed you at the material for this. Finally, since "cellular (=3D3GPP)" is clearly your one true interest here, the good news is that cellular networks already have terrific infrastructure and control plane mechanisms in place for location determination. This includes the UE peer signalling for AGPS, OTDOA and so forth. All a LIS in a 3GPP network has to do is provide the semantics of the LCP to the device and emergency network clients and to invoke that existing control plane infrastructure at the back end. It's certainly a lower cost and more robust alternative than building SUPL infrastructure in parallel to that control plane capability which already exists to support CS emergency calls anyway. 5. Endpoint based location and routing Nothing cellular specific about this one. Same thing applies to WiFi and WiMAX and wired technologies too. The old "network loading" furphy is often rolled out for these sorts of discussions; presumably it's attractive because it sounds "technical" but doesn't really warrant proper quantification and justification. Gosh "billions" of devices - how can we even consider having so many devices doing... "stuff"? It does prompt me to ask the question "what part of the term 'broadband' don't you understand?" I'm going to take a wild stab and suggest that a device being used to make an emergency call probably isn't "idle". Further, with respect to the general IETF location service model, I'm going to suggest that a device that wants to ask for its location isn't idle either. Even further, I'm going to suggest that a LIS servicing a location dereference can have enough integration with the access network to have the device paged and for location procedures to proceed (i.e. just like a control plane MT-LR or a SUPL NI-LR - though the latter is an ill-defined proposition with respect to arbitrary access types). Actually your commentary on this section strongly suggests to me that you don't actually understand how an ECRIT emergency call procedure works. You've certainly tried to characterize all this LoST and PSAP boundary stuff that's going on as a big deal. It isn't and there's certainly no more going on from either a device or network perspective than there would be to provide the same functionality via a control plane or SUPL approach. If you'd like an offline overview of how an ECRIT emergency call is made, let me know; it would be my pleasure. 6. Support of unauthenticated users Definitely not a cellular specific issue; every access technology has to ask itself about this. Actually every regulator in every jurisdiction has to ask themselves about this too - and hopefully they can avoid the mistake of thinking one form of public access technology is "special" compared to others as well. That would mitigate the risk of them coming up with inconsistent and confusing legislation. ECRIT is based on IP - so the key first step to getting an ECRIT-compliant emergency call underway is for the device to have IP access. In 3GPP parlance, you'd say it needs to have a network context. A good example of providing ECRIT-compliant emergency calling to unauthenticated devices is WiFi hotspots. Hotspots typically provide free layer 2 connectivity and an IP context in the first instance. Device traffic is "port-trapped" to the Hotspots' web site (and maybe a smattering of public Internet websites as well). The firewall isn't opened up until the user "authenticates"; the valid token very often taking the form of a credit card number and expiry date. So -what would a Hotspot need to do to provide "unauthenticated" emergency access? All it needs to do is to ensure that unauthenticated devices, in addition to having access to the portal web page, also have access to a LIS, a LoST server and to the PSAP URI(s) which service the location of that hotspot. That's it; sure there's no emergency call proxy via a third party VSP - but that's not necessary (I'm actually against it anyway) but it could be accommodated with some tweaks on the approach described. Now - what would a 3GPP network need to do to support an ECRIT-compliant unauthenticated emergency calling facility? You could probably describe it better than me - but I dare say it would involve allowing the device to establish an emergency IP context (something which I believe is required by 23.167 anyway - otherwise how would the UE be able to tell the P-CSCF it wants to do an emergency call?). Having permitted the creation of the emergency context, the 3GPP network would similarly just need to constrain the device's access to the LIS, LoST, and the PSAP URI(s) for the corresponding location. Obviously 3GPP have decided to define a different way of doing things and that's par for the course. It's 3GPP's prerogative to continue to act as if there is something special about cellular and that there's good reason for it to look different to both IP devices and the emergency network. It's not true - but that's never stopped the silo thinking before. And that puts me in mind of that scene from Python's Holy Grail movie. 3GPP guarding the bridge to "cellular land" - "None shall pass..." - It'll end much the same way as well. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Edge, Stephen Sent: Wednesday, 4 March 2009 4:32 PM To: br@brianrosen.net Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft Brian Thanks for these well considered responses. Below I am providing on an item by item basis, and taking into account your responses, a few more reasons why the current Ecrit solution is unsuitable - or, if you prefer, less suitable than the 3GPP/3GPP2 solution - for cellular networks. 1. Access to PSTN capable PSAPs Assuming that the best available solution for this currently is the ongoing NENA i2 standard (as you comment), then there are problems with providing location for dispatch (initial and updated location). For example, the latest i2.5 draft I have (December 2008) says that the VPC to LIS v3 interface is being deprecated (thus not available), although this is the interface that the VPC would use to query location from the LIS. Also I don't see any inclusion of accurate positioning support - e.g. using A-GPS. Further, interworking with the circuit mode side for UA access (as opposed to PSAP access) seems to be out of scope. So at best, this standard is incomplete (i.e. not yet suitable for cellular networks). However, I agree that there is some overlap between i2.5 and the 3GPP/3GPP2 solution. 2. Handover between different IP access networks including different types of access network One of the issues here would be change of LIS across different networks while avoiding impacts to both IP and PSTN capable PSAPs (i.e. handover must be transparent to PSAPs within the limitations imposed by SIP or some J-STD-036 type of circuit mode solution). The problem gets more difficult when handover to/from circuit mode access networks is considered. So far, 3GPP/3GPP2 has not yet agreed on a solution although there are proposals and we expect some resolution soon. On the Ecrit and NENA sides, I see much less progress. 3. Handover to/from circuit mode networks We agree here at least on the out of scope aspect. I suppose I can accept that it is not customary to point this out in IETF standards. But I hope you can see that this is an issue for cellular networks most of which will have extensive circuit mode coverage for a long time to come. 4. Location for cellular access (and the requirement to support LCPs that will be useless for cellular access) The issue is not so much the LCP itself but the capability to support accurate positioning - e.g. using A-GPS, AFLT, OTDOA, enhanced cell ID etc. None of those methods seem to be supported as part of DHCP or HELD right now. So some modification of the LCP related requirements or of the LCPs seems needed. 5. Endpoint based location and routing for cellular access (issues here are network and device loading as well as device impacts and problems with PSTN capable PSAPs) Endpoint based location when spread over millions (billions, planet-wide) of terminals will consume significant network and terminal resources. A typical terminal is generally idle and interacts with the network very sparingly to update the network with its current location (e.g. current cluster of potential serving cells). Performing network assisted periodic location fixes and LoST queries would add significantly to network load. Performing periodic location fixes in the terminal (e.g. using GPS) and estimating when a PSAP boundary may have been crossed would add to terminal load (e.g. thus battery drain). Optimizations would be possible of course - e.g. based on observing nearby cell IDs - but they will add to terminal complexity and testing costs. I agree that the Ecrit solution does allow for proxies to do this but here the solution also becomes incomplete because there seem no details of how this would work - e.g. what location solutions would then be used. 6. Support of unauthenticated users and users who can be authenticated but are not permitted access/VSP service except for emergency calls I think the Ecrit solution and you both assume that this has already been resolved somehow at the access level and therefore the various procedures in Ecrit can still be used. Maybe that is valid. However, there are still problems that are not covered in the Ecrit drafts but need to be resolved including (a) obtaining IP access (e.g. via a WLAN, cellular network, cable link) when not a valid subscriber, (b) obtaining access to the VSP and (c) ensuring only emergency related services are provided (e.g. and not free Internet and location access). These and additional problems (e.g. UA identification) would have to be solved, maybe on a per access basis, and then ensured to be compatible with the rest of the Ecrit solution. A significant part of the 3GPP/3GPP2 solution is concerned with this aspect and it has delayed completion of the solution for the more normal case of valid subscriber access due to such compatibility issues. Kind Regards Stephen -----Original Message----- From: br@brianrosen.net [mailto:br@brianrosen.net] Sent: Friday, February 27, 2009 6:53 AM To: Edge, Stephen Cc: Thomson, Martin; Richard Barnes; ECRIT Subject: Re: [Ecrit] Comments on Framework Draft Stephen Like any standards organization, the IETF restricts it's scope. Generally, the scope is "the Internet", although we very often describe solutions that are explicitly designed for private IP networks as well as the Internet. We don't write standards for circuit switched networks, and it should be no surprise that the ecrit solution does not cater to CS solutions. Nevertheless, we often try to make sure that our solutions harmonize reasonably well with existing solutions. Indeed, the ecrit solution clains global applicability to the Internet in general, and most private IP networks that can be interconnected to the Internet or to other IP networks via gateways. Looking at your list of problem areas: > - access to PSTN capable PSAPs This is out of scope for IETF. NENA has active work on this subject. It seems straightforward to interwork ecrit compatible devices and networks to existing CS connected PSAPs. As you know, CS interconnects are very nation-specific, so the NENA work may not have general applicability. However, it shows that it is possible to interwork. The NENA i2 work is also designed to take ecrit compatible devices and VSP networks, and interwork them to the existing network. The VSP would direct the call to the VPC, which would provide the services it does now, using the device provided location for routing. This is important for smooth transition from existing PSAPs and VSPs to "next generation" PSAPs and VSPs. > - handover between different IP access networks including different > types of access network In the ecrit solution, the access network the call is initiated on provides all the facilities needed for the device to initiate an emergency call. The call starts traversing it's normal call path, and eventually routes to the ESRP. Handoffs between IP networks should be transparent to this process, although we probably haven't done all the work we need to do for handoffs where the IP address as seen by the terminating network changes. This would generally be true of all current SIP based work. > - handover to/from circuit mode networks This would be out of scope for IETF. It's as applicable to a simple SIP call as it is a SIP emergency call, and there are no statements in any SIP documents on that subject. > - location for cellular access (and the requirement to support LCPs that > will be useless for cellular access) Location for cellular access networks has been considered carefully. Since cellular is a mobile network, the access network would pass the device a Location-By-Reference URI, using either DHCP or HELD. Either protocol is suitable for cellular networks. As we have pointed out several times, cellular networks support raw data packet services upon which many different kinds of networks can be constructed. My usual example is a large recreational vehicle traveling down a road with a cellular data card plugged into a router to which a wired (Ethernet) phone is connected. That phone must be able to make an emergency call, and it will get location from DHCP or HELD (or LLDP-MED). It is not aware of the cellular network, and doesn't know any cellular specific protocols. Cellular networks will have to support IETF location configuration protocols unless they actively prohibit examples like this, or they implement interworking between cellular-specific location protocols and DHCP or HELD in the data card. The ecrit standards permit proxy insertion of location, but, as above, we don't think that works in all cases. > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) The "load" of using DHCP or HELD to get location and querying LoST is pretty modest. The standards permit proxies to do this if the devices don't. As above, interwork functions to CS connected PSAPs is very feasible, and as above, cellular networks will have to support access to local LoST servers for devices that are connected to cellular networks and are ecrit compliant. > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls This is covered in the standards. None of the processes are dependent on authentication, although where it is possible, it's desirable so as to minimize fraudulent emergency calls Mechanisms for specific network authentication mechanisms are out of scope, and, like SIP basic calling, are not usually mentioned in IETF documents. Stephen, we've tried pretty hard to make sure this works for 3G/4G mobile networks. It's true that it doesn't do it the way 3GPP currently thinks it ought to work, but we claim they haven't thought through all the issues. While it would work, there are opportunities for improvement. We would be willing to do that if we could get the cooperation of 3GPP, which we have tried, and failed, to do. So, I think the documents do not need any qualification statements. Brian > Martin > > The 3GPP/3GPP2 solution has a defined restricted applicability (mainly to > 3GPP/3GPP2 access networks where the serving network also acts as the VSP) > and the specifications for it cover in detail all possible scenarios > consistent with these restrictions so far as we are aware. > > The Ecrit solution seems to claim global applicability to all types of IP > access (and the more that is said about this from Ecrit participants the > more this gets emphasized) but does not cover in detail all possible > scenarios (in some cases does not cover in any detail) which means that at > best the solution is incomplete and at worst intrinsically inapplicable to > some unstated set of scenarios. > > The missing, incomplete and problematic cases include the following: > > - access to PSTN capable PSAPs > - handover between different IP access networks including different > types of access network > - handover to/from circuit mode networks > - location for cellular access (and the requirement to support LCPs that > will be useless for cellular access) > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls > > Stating that some of these cases are out of scope or referencing an > incomplete and possibly questionable specification from some other > national SDO will not help the user who encounters such problems. But it > would certainly help network operators and implementers to acknowledge > their existence in one form or another because that would allow better > planning of deployments and would help focus attention on finding > solutions (whether in IETF or elsewhere) for the missing cases. > > Please note that despite these drawbacks, I will acknowledge that Ecrit > does have a valuable solution that covers many scenarios not covered by > 3GPP/3GPP2. It would be the delineation of these supported scenarios (or > equivalently unsupported scenarios) in some applicability statement that > would be particularly useful right now. > > Kind Regards > > Stephen > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Thursday, February 26, 2009 9:45 PM > To: Edge, Stephen; Richard Barnes > Cc: ECRIT > Subject: RE: [Ecrit] Comments on Framework Draft > > There's benefit in knowing the limitations of a framework, and every > architecture makes certain assumptions. Let's examine them though... > > The IETF might occasionally make the assumption that the standards it > develops are for Internet devices. That assumption probably need not be > stated explicitly. > > The ECRIT architecture relies on implementations of the protocols that it > references. That is not extraordinary. A reliance on implementation of > these protocols by endpoints, routing intermediaries and PSAPs should not > need to be explained. > > So the assumptions are: > - the Internet > - solutions are implemented and deployed > - the end device is a key component > > Only that last element is particularly novel ... or not that much really. > It's a design choice. Unless you were thinking of trunking the voice > elsewhere. > > Of course, you're suggesting that the design choice was made in ignorance > of all the constraints. You're suggesting that - as a result - the choice > is flawed and the solution is not going to work for cellular services. We > disagree. The solution is a basis for emergency calling in _any_ IP > network. > > Cheers, > Martin > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Edge, Stephen >> Sent: Friday, 27 February 2009 3:30 PM >> To: Richard Barnes >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Richard >> >> Thanks for the comments. Your statement below that "SIP emergency >> calling works if all parties behave as specified in these (IETF Ecrit) >> documents" to some degree highlights the problems we are raising. The >> documents do contain a number of implicit and explicit restrictions - >> like IP capable PSAPs, global IP access (no islands of circuit mode >> access for example), universal support of this solution by all access >> providers and VSPs (not much good if some opt for another solution) and >> end system oriented location and routing capability - which together >> make them unsuitable (we believe) for cellular wireless networks. If >> these restrictions and assumptions were all made explicit upfront, it >> would to a large degree (and possibly completely) address our concerns. >> >> You are right in assuming another set of specifications for the 3GPP >> and 3GPP2 solution. The applicability of this solution is explicitly >> defined in TS 23.167 (or more exactly in an already agreed CR in >> contribution S2-090752 which will become part of 23.167 in a few more >> weeks) to cover the following access types: GPRS (UTRAN WCDMA), I-WLAN, >> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN >> (LTE). So there is a restriction and arbitrary internet access is not >> covered (yet) as I have stated before. >> >> Kind Regards >> >> Stephen >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Wednesday, February 25, 2009 6:30 PM >> To: Edge, Stephen >> Cc: Brian Rosen; 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Stephen, >> >> I'm a little confused by the scope of what you're asking. The >> framework >> and phonebcp documents exist in order to describe the ECRIT solution: >> They say, in effect, "SIP emergency calling works if all parties behave >> as specified in these documents." >> >> As I understand what you're saying (and I'm by no means an expert in >> 3GPP), 3GPP specifies that one or more elements of this system behave >> differently. This simply means that 3GPP networks aren't complying >> with >> these specs. Just like there's no disclaimer in RFC 791 (IPv4) that >> says "this doesn't work on X.25 networks", it's not clear to me that an >> analogous disclaimer is called for here. >> >> I presume there are similar documents describing how emergency calling >> works in 3GPP networks. Do they include notes saying that the 3GPP >> solution doesn't work in the broader Internet? >> >> --Richard >> >> >> >> >> >> Edge, Stephen wrote: >> > Brian >> > >> > First of all apologies for the likely lateness of this reply - I >> actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest but >> it seems unlikely that my VPN, Outlook server and WiFi access >> capability will cooperate together to get it sent until I return to the >> office mid-next week. >> > >> > Anyhow thanks for your comments. There have actually been a number of >> conference calls between IETF and 3GPP participants over the last >> couple of years at which common features like support of IP emergency >> calls were discussed and these could have been good forum for >> participants on either side to have raised the kinds of issues you >> elaborate on below. Given that seems not so far to have happened, it >> could still be possible in future such calls. >> > >> > But the issues we are raising are not directly to do with further >> aligning the 2 solutions or with the lack of this in the past. We are >> simply pointing out that the solutions are currently different and that >> from a cellular wireless perspective, the Ecrit solution is not seen as >> suitable in all respects (for support of IP emergency calls originating >> from such access types). That is not just our point of view. 3GPP2 sent >> a liaison to Ecrit some months ago pointing out the same issues. >> > >> > So we are proposing that the Ecrit framework and phoneBCP spec.s >> include a statement acknowledging this - e.g. by referencing the >> alternative 3GPP/3GPP2 solution and indicating the IP access types for >> which the Ecrit solution will work without limitation (or equivalently >> the access types where limitations are not ruled out). >> > >> > We are not proposing further modification and extension of the Ecrit >> solution - just pointing out that this would be needed (as with the >> 3GPP/3GPP2 solution) to fully cover all types of access. >> > >> > Kind Regards >> > >> > Stephen >> > -----Original Message----- >> > From: Brian Rosen [mailto:br@brianrosen.net] >> > Sent: Wednesday, February 18, 2009 8:07 PM >> > To: Edge, Stephen; 'ECRIT' >> > Subject: RE: [Ecrit] Comments on Framework Draft >> > >> > I have bit my tongue on this one for a long time. >> > >> > Stephen, with respect, please go talk to 3GPP management and ask them >> why >> > there has been no participation in the ecrit effort despite multiple >> YEARS >> > of begging them to get involved. To put it frankly, 3GPP is quite >> willing >> > to bully IETF into doing its work on its schedule, but cannot be >> bothered to >> > get work done it knows it will eventually have to do when the IETF >> asks it >> > to do so. >> > >> > 3GPP understands the mess that is being created by not participating. >> They >> > know full well that when they finally get around to dealing with PS >> > terminated emergency calls, that there will be a lot of resistance to >> > changing fully specified and implemented standards to more closely >> align >> > with 3GPP standards. I expect you will have several interworking >> functions >> > to define and build. >> > >> > So, politely, please go away, we're finishing work we dearly wanted >> you all >> > to be involved with for years, but you refused to do anything. It's >> too >> > late for this rev. >> > >> > Now, having said that, there are quite a few people who have >> participated in >> > the IETF work who are IMS aware and I believe that despite your >> fears, >> > everything you need is in the specs. The mechanisms we have defined >> provide >> > the ability for the network to insert location, recognize and mark >> emergency >> > calls, and route on behalf of endpoints. An E-CSCF could quite >> > straightforwardly provide a SIP call towards an ecrit compatible >> PSAP. The >> > only not-quite-nice interwork would be from SUPL to HELD (or SIP), >> but it's >> > pretty easy to do that. I'll also note that we have tried to get OMA >> and >> > IETF to cooperate on location protocols, but we have been >> spectacularly >> > unsuccessful at that effort also. >> > >> > Brian >> > >> > >> > >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf >> >> Of Edge, Stephen >> >> Sent: Thursday, February 05, 2009 2:50 AM >> >> To: 'ECRIT' >> >> Subject: [Ecrit] Comments on Framework Draft >> >> >> >> All >> >> >> >> draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative >> >> description of how terminals and networks should support emergency >> >> calls made over IP capable facilities to IP capable PSAPs. It >> appears >> >> intended to cover all types of access network - including fixed >> line, >> >> WiFi and cellular (e.g. examples involving each can be found >> throughout >> >> the draft). >> >> >> >> When we evaluated this with respect to support of wireless cellular >> >> access and WiFi access associated with a cellular operator (e.g. >> WLAN >> >> or Femto cells integrated into a cellular network), we found that >> >> certain portions of the draft exhibited one or more of the following >> >> characteristics: >> >> >> >> (A) Inconsistent with already standardized wireless solutions >> >> >> >> (B) Inconsistent with essential wireless requirements and >> >> conventions >> >> >> >> (C) Already part of wireless standards or potentially part of >> >> future standards >> >> >> >> (A) refers to all portions of the draft framework that differ from >> the >> >> requirements and procedures currently standardized for wireless >> >> emergency access by 3GPP, 3GPP2 and OMA. This is a plain difference >> of >> >> solution and could be resolved through support of both solutions by >> >> terminals (with each solution being used according to the type of >> >> access network and VSP) or could be resolved by supporting only one >> >> solution and accessing only the types of network supporting that >> >> solution. To acknowledge this category, the framework document could >> >> reference the applicable wireless standards and point out that these >> >> are valid alternatives for wireless cellular based access. >> >> >> >> (B) refers to portions of the draft that would be unsuitable for >> >> wireless networks even if no alternative solution existed together >> with >> >> other portions missing from the draft that would be needed to fully >> >> support wireless networks. Examples of the former include: (a) >> emphasis >> >> on endpoint derivation of location, performance of Lost query and >> >> receipt of local dial strings; (b) restriction of LCPs to protocols >> >> that require terminal initiation (not allowing for network >> initiation >> >> as far as we can tell) and that include two LCPs (DHCP and LLDP) >> that >> >> are not applicable to (not defined for) cellular access; and (c) the >> >> requirement that a terminal or at least a LIS will update the PSAP >> >> whenever location changes. (a) is impractical due to network and >> >> terminal loading consequences and failure to support non-IP capable >> >> PSAPs; (b) makes location verification and updated location >> provision >> >> to PSAPs difficult or impossible; while (c) is also incompatible >> with >> >> support of existing non-IP capable PSAPs besides increasing terminal >> >> load and possibly interfering with optimum maintenance of the RF >> >> connection (e.g. if a terminal has to tune away from the serving >> base >> >> station or WLAN periodically to make location measurements). >> Examples >> >> of the latter include (d) absence of support for access to non-IP >> >> capable PSAPs as already mentioned (e.g. to support E911 phase 2 in >> the >> >> US); (e) no support for handover from the IP to the circuit domain >> when >> >> a terminal loses (e.g. moves out of) RF coverage in the IP domain; >> and >> >> (f) no allowance for limited access modes wherein a terminal may >> access >> >> a network only to place an emergency call with ensuing restrictions >> on >> >> (for example) location acquisition, PSAP callback and caller >> >> verification and identification to the PSAP. To resolve this >> category >> >> either significant changes to the framework document could be made >> or a >> >> disclaimer/applicability statement could be added stating that >> support >> >> of cellular wireless networks and their associated WLAN and Femto >> >> access points is not covered. >> >> >> >> Category (C) comprises concepts and capabilities in the draft that >> are >> >> either already part of the standardized solution for wireless >> networks >> >> or that might be added at a later time. Examples of the former >> include >> >> LoST, SIP location conveyance, general use of SIP, location for >> routing >> >> versus for dispatch, cellular positioning methods. Examples of the >> >> latter include use of location references and dereferencing and >> >> possible interworking between the current wireless network solutions >> >> (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. >> The >> >> presence of this category could be acknowledged by following the >> >> disclaimer for (B) with a statement that certain portions of the >> >> solution are expected to be incorporated into wireless networks now >> >> and/or in the future. >> >> >> >> We hope that these comments will be seen to be a useful addition to >> >> this review in the sense of enabling a more precise scoping for the >> >> framework document and we are willing to assist in providing wording >> >> for any disclaimer/applicability statement that the Ecrit working >> group >> >> may now deem fit to include. >> >> >> >> Kind Regards >> >> >> >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs >> (Qualcomm >> >> 3GPP2 TSG-X and TSG-C participant) >> >> >> >> PS this being sent on 2/4/09 at 11:50pm PST >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www.ietf.org/mailman/listinfo/ecrit >> > >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------ ------------------------ > 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://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.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] ---------------------------------------------------------------------------= --------------------- 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] From Martin.Dawson@andrew.com Mon Mar 9 20:11:24 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46E0F3A6A90 for ; Mon, 9 Mar 2009 20:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dxIHbWF2yu6 for ; Mon, 9 Mar 2009 20:11:20 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 2DA703A6961 for ; Mon, 9 Mar 2009 20:11:20 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_09_22_31_41 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 09 Mar 2009 22:31:40 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Mar 2009 22:11:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Mar 2009 22:11:51 -0500 Message-ID: In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5374A407@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmY6xBP94jupkzETj+iA0b5U69mvgDj/IbwAGceYlAAwDSRoAAC5dHQAAEvOgAAAJvtAA== References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com><64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net> <1288E74A73964940B132A0B9EA8D8ABC5374A0D6@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5374A3FE@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5374A407@NASANEXMB04.na.qualcomm.com> From: "Dawson, Martin" To: "Edge, Stephen" , X-OriginalArrivalTime: 10 Mar 2009 03:11:52.0877 (UTC) FILETIME=[F5F3DDD0:01C9A12D] Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 03:11:24 -0000 Hi Stephen,=0D=0A=0D=0ASome things - like the exact manner in which the IP = core should deliver=0D=0Acalls to a circuit service PSAP are clearly not wi= thin 3GPP's scope and,=0D=0Aif anyone is going to make such a specification= , it should be the=0D=0Aappropriate body within the PSAP jurisdiction (e.g.= NENA).=0D=0AAlternatively, the problem is addressed on a PSAP by PSAP basi= s. Some=0D=0Athings, like how to do seamless mobile IP between the differen= t access=0D=0Atechnologies 3GPP considers to be in its remit so that ECRIT = emergency=0D=0Acalls are supported seamlessly *could* be specified by 3GPP = *if they=0D=0Awanted to*. If 3GPP doesn't want to do it, then solutions can= be=0D=0Adesigned anyway. So - no - I wasn't implying that these organizati= ons=0D=0Ahave a responsibility to specify solutions to these things; but th= ere=0D=0Aare some things which they could appropriately take on the specifi= cation=0D=0Aof - given a desire to be proactive.=0D=0A=0D=0AAny organizatio= n (or individuals) could choose to document "standard"=0D=0Aapproaches to d= oing these things. I actually challenge the implication=0D=0Athat 3GPP has = documented how all these things are dealt with - even in=0D=0Athe narrow co= ntext of IMS emergency calling.=0D=0A=0D=0AAlternatively, and to the extent= that solutions can be built using=0D=0Aexisting standard interfaces and co= nfigurations of network elements in=0D=0Aappropriate ways, then explicit st= andardization is not an imperative.=0D=0A=0D=0AThese are generally true com= ments. I don't particularly like stating=0D=0Atruisms but ultimately that's= all you're driving at. Hence the=0D=0Aobservation that the goal of the dis= cussion is likely something other=0D=0Athan face value. It certainly wouldn= 't have been worth the effort if it=0D=0Awas.=0D=0A=0D=0ACheers,=0D=0AMarti= n=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Edge, Stephen [mailto:se= dge@qualcomm.com]=20=0D=0ASent: Tuesday, 10 March 2009 1:39 PM=0D=0ATo: Daw= son, Martin; br@brianrosen.net=0D=0ACc: ECRIT=0D=0ASubject: RE: [Ecrit] Com= ments on Framework Draft=0D=0A=0D=0AMartin=0D=0A=0D=0AYour earlier comments= implied to me that you thought that problems 1, 2,=0D=0A3, 4 and 6 were no= t the responsibility of Ecrit but that of individual=0D=0ASDOs associated w= ith particular AN types or, in the case of PSTN capable=0D=0APSAP access, s= ome national SDO like NENA. Can you clarify whether that=0D=0Ais true and, = if not, who would or might standardize solutions for these=3F=0D=0A=0D=0AKi= nd Regards=0D=0A=0D=0AStephen=0D=0A-----Original Message-----=0D=0AFrom: Da= wson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0ASent: Monday, March 09,= 2009 7:28 PM=0D=0ATo: Edge, Stephen; br@brianrosen.net=0D=0ACc: ECRIT=0D=0A= Subject: RE: [Ecrit] Comments on Framework Draft=0D=0A=0D=0AHi Stephen,=0D=0A=0D= =0ANo - I'd say you've gotten hold of the wrong end of the stick; at least=0D= =0Ain terms of the conclusion you're trying to drive.=0D=0A=0D=0AWhat I'm s= aying is that none of the issues you brought up are specific=0D=0Ato cellul= ar and that, further, a properly engineered access - whether it=0D=0Ais mul= ti-technology or not - will support an ECRIT methodology=0D=0Atransparently= =2E=0D=0A=0D=0ATo use an analogy, a DNS service in an access network can be= similarly=0D=0Aaffected by many of the types of considerations you raise. = Nevertheless,=0D=0Aa DNS service can be quite transparently provided to cli= ents running on=0D=0Aattached hosts, and without having to change their beh= aviour just=0D=0Abecause it's a 3G network, despite this fact. By the same = token, it=0D=0Awould hardly be appropriate for a DNS specification to start= talking=0D=0Aabout the sorts of things an access implementer might need to= do to=0D=0Aachieve this.=0D=0A=0D=0ACertainly, and ultimately, it's up to = 3G network implementers whether=0D=0Athey want to support a general Interne= t emergency architecture (so that,=0D=0Afor example, an emergency client on= a laptop with a 3G modem can work=0D=0Ajust as well on that network as it = would attached to a residential=0D=0AEthernet connection, or that an emerge= ncy calling client on a PSP could=0D=0Awork just as well on a 3G WiFi route= r as it would when attached to WiFi=0D=0Ahotspot).=0D=0A=0D=0AAlternatively= , if the network implementer just wants to support a 3GPP=0D=0Aspecific mod= el for emergency calling that pre-supposes an IMS=0D=0Asubscription and whi= ch is targeted at conventional notions of handsets=0D=0Athen they also have= the choice of following those context-limited=0D=0Aspecifications of 3GPP.=0D= =0A=0D=0AThere's no doubt, however, that the needs of the latter can be met= by=0D=0Aimplementing the infrastructure required for the former but the co= nverse=0D=0Ais not true. You are quite correct to *not* say that the "probl= ems" you=0D=0Aidentify below can't be solved. They most certainly can - and= it's=0D=0Abarely true to say that they are problematic. They are no more s= o than=0D=0Aany engineering challenge. If you don't think this sort of chal= lenge=0D=0Ahasn't applied to cellular emergency services, despite 3GPP=0D=0A= specifications, then you must not have been involved in any=0D=0Aimplementa= tion.=0D=0A=0D=0AYou would be right to infer from my discourse that I think= 3GPP could do=0D=0Aa much better, and more helpful, job of documenting how= the ECRIT=0D=0Aemergency model should be supported. But they don't have to= (and=0D=0Acertainly don't appear to be inclined to) for network implemente= rs to be=0D=0Aable to do it anyway.=0D=0A=0D=0AI see your tack here, now, i= s to try and get an alternative statement in=0D=0Athe framework - that coul= d perhaps be used to make the argument that the=0D=0AIETF doesn't know how = ECRIT can be implemented in 3G networks. That=0D=0Awould be a misrepresenta= tion of the point that these considerations are=0D=0Aout of scope and, as f= or the DNS example, it wouldn't be appropriate=0D=0Aanyway.=0D=0A=0D=0AI do= n't presume to speak for the IETF. I think you know how it's=0D=0Aorganized= and that nobody can guarantee that somebody isn't going to=0D=0Apost some = new proposal or other for a work item. Actually, you couldn't=0D=0Aget that= kind of "we'll never venture to specify X" statement out of=0D=0A3GPP eith= er.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D= =0AFrom: Edge, Stephen [mailto:sedge@qualcomm.com]=0D=0ASent: Tuesday, 10 M= arch 2009 12:23 PM=0D=0ATo: Dawson, Martin; br@brianrosen.net=0D=0ACc: ECRI= T=0D=0ASubject: RE: [Ecrit] Comments on Framework Draft=0D=0A=0D=0AHi Marti= n=0D=0A=0D=0AThanks for theses further comments - which I agree introduce a= new twist=0D=0Ato this discussion.=0D=0A=0D=0AYour main assertion seems to= be that most of the general points I raised=0D=0Aare not matters for Ecrit= to resolve and standardize but instead=0D=0Arepresent problems to be resol= ved for the particular AN (either by an=0D=0ASDO associated with the AN by = or by some national SDO like NENA in the=0D=0Acase of PSAP access). The lis= t of such issues seems to be:=0D=0A=0D=0A1. Access to PSTN capable PSAPs=0D= =0A2. Handover between different IP access networks=0D=0A3. Handover to/fro= m circuit mode networks=0D=0A4. Location for cellular access=0D=0A6. Suppor= t of unauthenticated users (and users in limited service state)=0D=0A=0D=0A= If I am generally right in this assumption, my first question is whether=0D= =0Athis is just your particular opinion or if this represents the view of=0D= =0AEcrit generally. E.G. is there any danger that Ecrit (or some other IETF=0D= =0Agroup) might reclaim one or more of the above - perhaps after others=0D=0A= SDOs (like 3GPP) have produced their own solutions=3F If you are all quite=0D= =0Acertain that this will not happen, or at least certain of this for some=0D= =0Asubset of the above, it would very much help to include a statement on=0D= =0Athis in the phoneBCP and/or framework drafts so there is no ambiguity.=0D= =0A=0D=0AMy next comment is that solving the above for each type of AN prob= ably=0D=0Arepresents most of difficulty in producing a comprehensive soluti= on. For=0D=0Aexample, handover after a location URI has been obtained from = a LIS will=0D=0Abe problematic for continuing location (since the previous = and now wrong=0D=0ALIS may receive the next location request). Similarly ac= cess and=0D=0Ahandover to restricted areas (cells or networks a user is not= normally=0D=0Aallowed to use) is problematic particularly if normal IP con= nectivity is=0D=0Aassumed. Further, use of HELD with a control plane locati= on solution is=0D=0Ahighly problematic for any 3GPP network because the cur= rent architecture=0D=0Aand procedures are not able to support location requ= ests initiated=0D=0Asolely from a location server (like an SMLC or SAS) whe= re there no prior=0D=0Ainteraction with the RAN and CN. Further to that, co= ntrol plane=0D=0Asolutions cannot often obtain location accurately enough f= or dispatch=0D=0Aand need to incorporate terminal based positioning using s= ay A-GPS which=0D=0Acan lead to a user plane solution like SUPL. I could ad= d other problem=0D=0Aareas if you believe this list is exhaustive. Now I am= not saying that=0D=0Athese problem areas cannot be solved - 3GPP and 3GPP2= have in fact=0D=0Asolved most of them (and should complete this by the end= of this year)=0D=0Ain the context of the 3GPP/3GPP2 solution. But your pos= ition now seems=0D=0Ato be that any SDO must solve them subject to the vari= ous restrictions=0D=0Aand requirements imposed by the Ecrit phoneBCP and Fr= amework drafts. Can=0D=0Ayou confirm that this is so=3F=0D=0A=0D=0AKind Reg= ards=0D=0A=0D=0AStephen=0D=0A-----Original Message-----=0D=0AFrom: Dawson, = Martin [mailto:Martin.Dawson@andrew.com]=0D=0ASent: Thursday, March 05, 200= 9 10:56 PM=0D=0ATo: Edge, Stephen; br@brianrosen.net=0D=0ACc: ECRIT=0D=0ASu= bject: RE: [Ecrit] Comments on Framework Draft=0D=0A=0D=0AThere must be a w= ord for the situation where everybody is talking about=0D=0Asomething but e= verybody knows the real subject is something else and=0D=0Awhat that real s= ubject is. Suggestions welcome.=0D=0A=0D=0AAnyway, working on the basis tha= t this whole thing isn't just about=0D=0Agetting a "sound bite" added to th= e framework document that can be=0D=0Amisappropriated for years to come to = confuse the cellular industry into=0D=0Athinking ECRIT is not relevant to t= hem, let's look at each of Stephen's=0D=0Atopic areas below.=0D=0A=0D=0AA f= undamental tenet of the argument is that, somehow, cellular is=0D=0A"specia= l" and should be left to its "special" devices compared to every=0D=0Aother= Internet access technology. This, after all, is why we have IMS.=0D=0AIt m= ight have seemed reasonable ten years ago to define the core service=0D=0Aa= rchitecture to accompany the new "Packet Service" mode of networking.=0D=0A= In these days of Web 2.0, AJAX, Ruby on Rails, Flash, Silverlight, SOA,=0D=0A= Azure... etc. against which IMS seems very.... "stodgy" it is reasonable=0D= =0Ato ask the question why such a monolithic and cellular-legacy service=0D= =0Amodel is required. Nevertheless - 3GPP is entitled to do what 3GPP does.=0D= =0AActually I'm pretty sure you won't find references to IMS in Web 2.0=0D=0A= texts saying "of course cellular operators also use IMS as an=0D=0Aapplicat= ion framework."=0D=0A=0D=0ANow - how specific are the "special" cases that = are outlined below to=0D=0Acellular=3F:=0D=0A=0D=0A1. Access to PSTN capabl= e PSAPs=0D=0ANot specific to cellular. If a jurisdiction has PSTN capable P= SAPs then=0D=0AVoIP calls originating from any form of access have to deal = with that=0D=0Afact. The answer is fairly obvious - there has to be a media= gateway=0D=0Abehind the PSAP URI. And it might not just be a PSTN PSAP, th= ere could=0D=0Abe dedicated circuits to selective routers or, even, CAMA tr= unks=0D=0Ainvolved. The manner in which this is done really does need to be= spelt=0D=0Aout by the jurisdiction; it can't be otherwise even if there ar= e fairly=0D=0Acommon conventions. NENA looks after stating how this is done= for the=0D=0AUS. It's not up to 3GPP nor the IETF to tell jurisdictions ho= w emergency=0D=0Acalls that originate on Internet access get bridged into t= he legacy PSAP=0D=0Ainfrastructure. No more so than it was 3GPP's job to pr= escribe that E2+=0D=0Ahad to be the PSAP/ALI to GMLC interface protocol use= d for CS E9-1-1=0D=0Acalls.=0D=0A=0D=0A2. Handover between different IP acc= ess networks=0D=0ANot specific to cellular. There can be handover between W= iFi and=0D=0AEthernet, WiFi and WiMAX and so forth. Now - what we're really= talking=0D=0Aabout here is a more fundamental capability related to mobile= IP. 3GPP=0D=0Adefinitely has a very nice role to play in prescribing how t= his=0D=0Aaccess-mobility occurs across the access technologies that 3GPP de= fines=0D=0Aand supports. Since the ECRIT emergency model concerns itself fr= om the=0D=0AIP layer up, it is quite possible for it to work very transpare= ntly to=0D=0Asuch mobility occurring beneath the surface. And, of course, a= ny such=0D=0Anicely integrated access technologies would offer a nicely int= egrated=0D=0ALIS solution to ensure that the location service remains conti= guous and=0D=0Aconsistent. It seems to me that it's quite bad engineering t= o couple the=0D=0Amanner in which this is done to a specific IP service suc= h as emergency=0D=0Acalling. Can't help it if 3GPP do that - but it doesn't= obviate the=0D=0Aoption of ECRIT being applied in the more elegant way.=0D= =0A=0D=0A3. Handover to/from circuit mode networks=0D=0AI'll give you this = one... to an extent. Obviously the IETF doesn't think=0D=0Athis is in the l= east bit relevant to them. On the other, in theory, a=0D=0AVoIP connection = established on any form of IP access could be handed=0D=0Aover to some othe= r form of circuit access - e.g. DSL to ISDN. The issue,=0D=0Aof course, is = just how realistic these scenarios are. If you accept that=0D=0Athe PSTN is= going to go away (and I certainly do) then you also=0D=0Aacknowledge that = this is a transitional issue. You can argue that the=0D=0APSTN is still goi= ng to be around for years to come (and I also agree=0D=0Awith that) but tha= t doesn't mean you have to create a specific mechanism=0D=0Ato handover bet= ween circuit and packet for emergency services.=0D=0A=0D=0AI'm interested i= n just what it is that 3GPP have defined for this. I=0D=0Alook at the curre= nt 23.167 specification and, I admit, it doesn't leap=0D=0Aout at me. The s= tage 2 description has always struck me as kind of=0D=0Avague. The diagram = concerning location information handling, for=0D=0Aexample, has the dotted = boxes with non-prescriptive steps saying=0D=0A"procedure to obtain location= " done here. It always kind of reminds me=0D=0Aof that old cartoon with the= engineers looking at the complex flow chart=0D=0Awith the "a miracle happe= ns here" box in the middle. I'm thinking of a=0D=0Acall originated on IP. L= et's say the E-CSCF invokes the E-SLP to do a=0D=0ASUPL NI-LR (assuming one= manifestation of the dotted box in the diagram)=0D=0Aand the resultant loc= ation is used to determine the correct MGCF route=0D=0Ato deliver the call.= Perhaps the PSAP supports an MLP interface to the=0D=0ALRF and can ask it = for location updates - kicking off a SUPL NI-LR=0D=0Aagain. Now - the devic= e "roams" to a bit of the network that can only=0D=0Asupport circuit servic= e=3F What exactly happens=3F Does it initiate another=0D=0Acall via the MSC= =3F How does that interact with the existing emergency=0D=0Aservice semanti= cs in the MSC=3F Obviously it wants to initiate a whole new=0D=0Acall - and= initiate control plane location determination so it can=0D=0Areport an ini= tial location to the GMLC. Is that GMLC the same node as=0D=0Athe LRF=3F Ho= w does it deal with the fact that it's now got two pieces of=0D=0Astate for= what in theory is the same call=3F Or is it - given the MSC=0D=0Acan't kno= w about the PS call in progress=3F What has 3GPP actually defined=0D=0Afor = this=3F=0D=0A=0D=0AI am certainly interested in the mechanics of how this i= s all=0D=0Aaccomplished and done reliably. ITRW (the one you and I live in)= 3G=0D=0Aoperators commonly force emergency calls onto the GERAN just becau= se=0D=0Athat's lower risk since GSM emergency calling is well established a= nd=0D=0Athings like UTDOA infrastructure are available on that access. This= is=0D=0Aquite the opposite tendency of looking to have seamless real time=0D= =0Amigration between access technologies on emergency calls (let alone=0D=0A= seamless migration between PS and CS!). What carriers are planning to do=0D= =0Athis with emergency calls if you can say=3F=0D=0A=0D=0A4. Location for c= ellular access.=0D=0ACertainly not specific to cellular access. Every techn= ology has a need=0D=0Afor accurate location determination. Wired technologi= es also, most=0D=0Aappropriately, need the location to be provided in civic= address form;=0D=0Asomething that the nominated LCPs are very good at. You= 're partly=0D=0Aconfusing the role of the LCP protocol with that of the ser= ver. You can=0D=0Asend a very simple HELD request to a LIS to ask for locat= ion; it's=0D=0Aincredibly simple to do; that's why HELD client implementati= ons keep=0D=0Apopping up from different sources. The complex stuff happens = on the=0D=0Aserver side. A LIS receiving such a request can invoke all mann= er of=0D=0Acontrol plane mechanisms (for the confused - "control plane" is = not an=0D=0Aantonym of "IP"; it just means interaction occurs between netwo= rk=0D=0Aelements and not over the traffic channel with the device). For exa= mple,=0D=0Athe LIS might do UTDOA. Now, I suspect you realize this and care= fully=0D=0Achose examples of technologies that involve measurements taken b= y the=0D=0Adevice. Fortunately this is not precluded by HELD either; I beli= eve=0D=0AJames has already pointed you at the material for this.=0D=0A=0D=0A= Finally, since "cellular (=3D3GPP)" is clearly your one true interest=0D=0A= here, the good news is that cellular networks already have terrific=0D=0Ain= frastructure and control plane mechanisms in place for location=0D=0Adeterm= ination. This includes the UE peer signalling for AGPS, OTDOA and=0D=0Aso f= orth. All a LIS in a 3GPP network has to do is provide the semantics=0D=0Ao= f the LCP to the device and emergency network clients and to invoke=0D=0Ath= at existing control plane infrastructure at the back end. It's=0D=0Acertain= ly a lower cost and more robust alternative than building SUPL=0D=0Ainfrast= ructure in parallel to that control plane capability which=0D=0Aalready exi= sts to support CS emergency calls anyway.=0D=0A=0D=0A5. Endpoint based loca= tion and routing=0D=0ANothing cellular specific about this one. Same thing = applies to WiFi and=0D=0AWiMAX and wired technologies too. The old "network= loading" furphy is=0D=0Aoften rolled out for these sorts of discussions; p= resumably it's=0D=0Aattractive because it sounds "technical" but doesn't re= ally warrant=0D=0Aproper quantification and justification. Gosh "billions" = of devices -=0D=0Ahow can we even consider having so many devices doing... = "stuff"=3F It=0D=0Adoes prompt me to ask the question "what part of the ter= m 'broadband'=0D=0Adon't you understand=3F" I'm going to take a wild stab a= nd suggest that a=0D=0Adevice being used to make an emergency call probably= isn't "idle".=0D=0AFurther, with respect to the general IETF location serv= ice model, I'm=0D=0Agoing to suggest that a device that wants to ask for it= s location isn't=0D=0Aidle either. Even further, I'm going to suggest that = a LIS servicing a=0D=0Alocation dereference can have enough integration wit= h the access network=0D=0Ato have the device paged and for location procedu= res to proceed (i.e.=0D=0Ajust like a control plane MT-LR or a SUPL NI-LR -= though the latter is=0D=0Aan ill-defined proposition with respect to arbit= rary access types).=0D=0A=0D=0AActually your commentary on this section str= ongly suggests to me that=0D=0Ayou don't actually understand how an ECRIT e= mergency call procedure=0D=0Aworks. You've certainly tried to characterize = all this LoST and PSAP=0D=0Aboundary stuff that's going on as a big deal. I= t isn't and there's=0D=0Acertainly no more going on from either a device or= network perspective=0D=0Athan there would be to provide the same functiona= lity via a control=0D=0Aplane or SUPL approach. If you'd like an offline ov= erview of how an=0D=0AECRIT emergency call is made, let me know; it would b= e my pleasure.=0D=0A=0D=0A6. Support of unauthenticated users=0D=0ADefinite= ly not a cellular specific issue; every access technology has to=0D=0Aask i= tself about this. Actually every regulator in every jurisdiction=0D=0Ahas t= o ask themselves about this too - and hopefully they can avoid the=0D=0Amis= take of thinking one form of public access technology is "special"=0D=0Acom= pared to others as well. That would mitigate the risk of them coming=0D=0Au= p with inconsistent and confusing legislation.=0D=0A=0D=0AECRIT is based on= IP - so the key first step to getting an=0D=0AECRIT-compliant emergency ca= ll underway is for the device to have IP=0D=0Aaccess. In 3GPP parlance, you= 'd say it needs to have a network context.=0D=0AA good example of providing= ECRIT-compliant emergency calling to=0D=0Aunauthenticated devices is WiFi = hotspots. Hotspots typically provide=0D=0Afree layer 2 connectivity and an = IP context in the first instance.=0D=0ADevice traffic is "port-trapped" to = the Hotspots' web site (and maybe a=0D=0Asmattering of public Internet webs= ites as well). The firewall isn't=0D=0Aopened up until the user "authentica= tes"; the valid token very often=0D=0Ataking the form of a credit card numb= er and expiry date. So -what would=0D=0Aa Hotspot need to do to provide "un= authenticated" emergency access=3F All=0D=0Ait needs to do is to ensure tha= t unauthenticated devices, in addition to=0D=0Ahaving access to the portal = web page, also have access to a LIS, a LoST=0D=0Aserver and to the PSAP URI= (s) which service the location of that=0D=0Ahotspot. That's it; sure there'= s no emergency call proxy via a third=0D=0Aparty VSP - but that's not neces= sary (I'm actually against it anyway)=0D=0Abut it could be accommodated wit= h some tweaks on the approach described.=0D=0A=0D=0ANow - what would a 3GPP= network need to do to support an ECRIT-compliant=0D=0Aunauthenticated emer= gency calling facility=3F You could probably describe=0D=0Ait better than m= e - but I dare say it would involve allowing the device=0D=0Ato establish a= n emergency IP context (something which I believe is=0D=0Arequired by 23.16= 7 anyway - otherwise how would the UE be able to tell=0D=0Athe P-CSCF it wa= nts to do an emergency call=3F). Having permitted the=0D=0Acreation of the = emergency context, the 3GPP network would similarly just=0D=0Aneed to const= rain the device's access to the LIS, LoST, and the PSAP=0D=0AURI(s) for the= corresponding location. Obviously 3GPP have decided to=0D=0Adefine a diffe= rent way of doing things and that's par for the course.=0D=0AIt's 3GPP's pr= erogative to continue to act as if there is something=0D=0Aspecial about ce= llular and that there's good reason for it to look=0D=0Adifferent to both I= P devices and the emergency network. It's not true -=0D=0Abut that's never = stopped the silo thinking before. And that puts me in=0D=0Amind of that sce= ne from Python's Holy Grail movie. 3GPP guarding the=0D=0Abridge to "cellul= ar land" - "None shall pass..." - It'll end much the=0D=0Asame way as well.=0D= =0A=0D=0ACheers,=0D=0AMartin=0D=0A-----Original Message-----=0D=0AFrom: ecr= it-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0AOf Edge,= Stephen=0D=0ASent: Wednesday, 4 March 2009 4:32 PM=0D=0ATo: br@brianrosen.= net=0D=0ACc: ECRIT=0D=0ASubject: Re: [Ecrit] Comments on Framework Draft=0D= =0A=0D=0ABrian=0D=0A=0D=0AThanks for these well considered responses. Below= I am providing on an=0D=0Aitem by item basis, and taking into account your= responses, a few more=0D=0Areasons why the current Ecrit solution is unsui= table - or, if you=0D=0Aprefer, less suitable than the 3GPP/3GPP2 solution = - for cellular=0D=0Anetworks.=0D=0A=0D=0A1. Access to PSTN capable PSAPs=0D= =0AAssuming that the best available solution for this currently is the=0D=0A= ongoing NENA i2 standard (as you comment), then there are problems with=0D=0A= providing location for dispatch (initial and updated location). For=0D=0Aex= ample, the latest i2.5 draft I have (December 2008) says that the VPC=0D=0A= to LIS v3 interface is being deprecated (thus not available), although=0D=0A= this is the interface that the VPC would use to query location from the=0D=0A= LIS. Also I don't see any inclusion of accurate positioning support -=0D=0A= e.g. using A-GPS. Further, interworking with the circuit mode side for=0D=0A= UA access (as opposed to PSAP access) seems to be out of scope. So at=0D=0A= best, this standard is incomplete (i.e. not yet suitable for cellular=0D=0A= networks). However, I agree that there is some overlap between i2.5 and=0D=0A= the 3GPP/3GPP2 solution.=0D=0A=0D=0A2. Handover between different IP access= networks including different=0D=0Atypes of access network=0D=0AOne of the = issues here would be change of LIS across different networks=0D=0Awhile avo= iding impacts to both IP and PSTN capable PSAPs (i.e. handover=0D=0Amust be= transparent to PSAPs within the limitations imposed by SIP or=0D=0Asome J-= STD-036 type of circuit mode solution). The problem gets more=0D=0Adifficul= t when handover to/from circuit mode access networks is=0D=0Aconsidered. So= far, 3GPP/3GPP2 has not yet agreed on a solution although=0D=0Athere are p= roposals and we expect some resolution soon. On the Ecrit and=0D=0ANENA sid= es, I see much less progress.=0D=0A=0D=0A3. Handover to/from circuit mode n= etworks=0D=0AWe agree here at least on the out of scope aspect. I suppose I= can=0D=0Aaccept that it is not customary to point this out in IETF standar= ds. But=0D=0AI hope you can see that this is an issue for cellular networks= most of=0D=0Awhich will have extensive circuit mode coverage for a long ti= me to come.=0D=0A=0D=0A4. Location for cellular access (and the requirement= to support LCPs=0D=0Athat will be useless for cellular access)=0D=0AThe is= sue is not so much the LCP itself but the capability to support=0D=0Aaccura= te positioning - e.g. using A-GPS, AFLT, OTDOA, enhanced cell ID=0D=0Aetc. = None of those methods seem to be supported as part of DHCP or HELD=0D=0Arig= ht now. So some modification of the LCP related requirements or of=0D=0Athe= LCPs seems needed.=0D=0A=0D=0A5. Endpoint based location and routing for c= ellular access (issues here=0D=0Aare network and device loading as well as = device impacts and problems=0D=0Awith PSTN capable PSAPs)=0D=0AEndpoint bas= ed location when spread over millions (billions,=0D=0Aplanet-wide) of termi= nals will consume significant network and terminal=0D=0Aresources. A typica= l terminal is generally idle and interacts with the=0D=0Anetwork very spari= ngly to update the network with its current location=0D=0A(e.g. current clu= ster of potential serving cells). Performing network=0D=0Aassisted periodic= location fixes and LoST queries would add=0D=0Asignificantly to network lo= ad. Performing periodic location fixes in the=0D=0Aterminal (e.g. using GPS= ) and estimating when a PSAP boundary may have=0D=0Abeen crossed would add = to terminal load (e.g. thus battery drain).=0D=0AOptimizations would be pos= sible of course - e.g. based on observing=0D=0Anearby cell IDs - but they w= ill add to terminal complexity and testing=0D=0Acosts. I agree that the Ecr= it solution does allow for proxies to do this=0D=0Abut here the solution al= so becomes incomplete because there seem no=0D=0Adetails of how this would = work - e.g. what location solutions would then=0D=0Abe used.=0D=0A=0D=0A6. = Support of unauthenticated users and users who can be authenticated=0D=0Abu= t are not permitted access/VSP service except for emergency calls=0D=0AI th= ink the Ecrit solution and you both assume that this has already=0D=0Abeen = resolved somehow at the access level and therefore the various=0D=0Aprocedu= res in Ecrit can still be used. Maybe that is valid. However,=0D=0Athere ar= e still problems that are not covered in the Ecrit drafts but=0D=0Aneed to = be resolved including (a) obtaining IP access (e.g. via a WLAN,=0D=0Acellul= ar network, cable link) when not a valid subscriber, (b) obtaining=0D=0Aacc= ess to the VSP and (c) ensuring only emergency related services are=0D=0Apr= ovided (e.g. and not free Internet and location access). These and=0D=0Aadd= itional problems (e.g. UA identification) would have to be solved,=0D=0Amay= be on a per access basis, and then ensured to be compatible with the=0D=0Ar= est of the Ecrit solution. A significant part of the 3GPP/3GPP2=0D=0Asoluti= on is concerned with this aspect and it has delayed completion of=0D=0Athe = solution for the more normal case of valid subscriber access due to=0D=0Asu= ch compatibility issues.=0D=0A=0D=0AKind Regards=0D=0A=0D=0AStephen=0D=0A--= ---Original Message-----=0D=0AFrom: br@brianrosen.net [mailto:br@brianrosen= =2Enet]=0D=0ASent: Friday, February 27, 2009 6:53 AM=0D=0ATo: Edge, Stephen=0D= =0ACc: Thomson, Martin; Richard Barnes; ECRIT=0D=0ASubject: Re: [Ecrit] Com= ments on Framework Draft=0D=0A=0D=0AStephen=0D=0A=0D=0ALike any standards o= rganization, the IETF restricts it's scope.=0D=0AGenerally, the scope is "t= he Internet", although we very often describe=0D=0Asolutions that are expli= citly designed for private IP networks as well=0D=0Aas=0D=0Athe Internet. = We don't write standards for circuit switched networks,=0D=0Aand=0D=0Ait sh= ould be no surprise that the ecrit solution does not cater to CS=0D=0Asolut= ions. Nevertheless, we often try to make sure that our solutions=0D=0Aharm= onize reasonably well with existing solutions.=0D=0A=0D=0AIndeed, the ecrit= solution clains global applicability to the Internet=0D=0Ain=0D=0Ageneral,= and most private IP networks that can be interconnected to the=0D=0AIntern= et or to other IP networks via gateways. Looking at your list of=0D=0Aprob= lem areas:=0D=0A> - access to PSTN capable PSAPs=0D=0AThis is out of scop= e for IETF. NENA has active work on this subject.=0D=0AIt=0D=0Aseems strai= ghtforward to interwork ecrit compatible devices and networks=0D=0Ato exist= ing CS connected PSAPs. As you know, CS interconnects are very=0D=0Anation= -specific, so the NENA work may not have general applicability.=0D=0AHoweve= r, it shows that it is possible to interwork. The NENA i2 work is=0D=0Aals= o designed to take ecrit compatible devices and VSP networks, and=0D=0Ainte= rwork them to the existing network. The VSP would direct the call=0D=0Ato=0D= =0Athe VPC, which would provide the services it does now, using the device=0D= =0Aprovided location for routing. This is important for smooth transition=0D= =0Afrom existing PSAPs and VSPs to "next generation" PSAPs and VSPs.=0D=0A>= - handover between different IP access networks including different=0D=0A= > types of access network=0D=0AIn the ecrit solution, the access network th= e call is initiated on=0D=0Aprovides all the facilities needed for the devi= ce to initiate an=0D=0Aemergency=0D=0Acall. The call starts traversing it= 's normal call path, and eventually=0D=0Aroutes to the ESRP. Handoffs betw= een IP networks should be transparent=0D=0Ato=0D=0Athis process, although w= e probably haven't done all the work we need to=0D=0Ado=0D=0Afor handoffs w= here the IP address as seen by the terminating network=0D=0Achanges. This = would generally be true of all current SIP based work.=0D=0A> - handover = to/from circuit mode networks=0D=0AThis would be out of scope for IETF. It= 's as applicable to a simple SIP=0D=0Acall as it is a SIP emergency call, a= nd there are no statements in any=0D=0ASIP=0D=0Adocuments on that subject.=0D= =0A> - location for cellular access (and the requirement to support LCPs=0D= =0Athat=0D=0A> will be useless for cellular access)=0D=0ALocation for cellu= lar access networks has been considered carefully.=0D=0ASince cellular is a= mobile network, the access network would pass the=0D=0Adevice a Location-B= y-Reference URI, using either DHCP or HELD. Either=0D=0Aprotocol is suitab= le for cellular networks. As we have pointed out=0D=0Aseveral times, cellu= lar networks support raw data packet services upon=0D=0Awhich many differen= t kinds of networks can be constructed. My usual=0D=0Aexample is a large r= ecreational vehicle traveling down a road with a=0D=0Acellular data card pl= ugged into a router to which a wired (Ethernet)=0D=0Aphone=0D=0Ais connecte= d. That phone must be able to make an emergency call, and it=0D=0Awill get= location from DHCP or HELD (or LLDP-MED). It is not aware of=0D=0Athe=0D=0A= cellular network, and doesn't know any cellular specific protocols.=0D=0ACe= llular networks will have to support IETF location configuration=0D=0Aproto= cols unless they actively prohibit examples like this, or they=0D=0Aimpleme= nt interworking between cellular-specific location protocols and=0D=0ADHCP = or HELD in the data card. The ecrit standards permit proxy=0D=0Ainsertion=0D= =0Aof location, but, as above, we don't think that works in all cases.=0D=0A= > - endpoint based location and routing for cellular access (issues=0D=0A= here=0D=0A> are network and device loading as well as device impacts and pr= oblems=0D=0A> with PSTN capable PSAPs)=0D=0AThe "load" of using DHCP or HEL= D to get location and querying LoST is=0D=0Apretty modest. The standards p= ermit proxies to do this if the devices=0D=0Adon't. As above, interwork fu= nctions to CS connected PSAPs is very=0D=0Afeasible, and as above, cellular= networks will have to support access to=0D=0Alocal LoST servers for device= s that are connected to cellular networks=0D=0Aand=0D=0Aare ecrit compliant= =2E=0D=0A> - support of unauthenticated users and users who can be=0D=0Aa= uthenticated=0D=0A> but are not permitted access/VSP service except for eme= rgency calls=0D=0AThis is covered in the standards. None of the processes = are dependent=0D=0Aon=0D=0Aauthentication, although where it is possible, i= t's desirable so as to=0D=0Aminimize fraudulent emergency calls=0D=0AMechan= isms for specific network authentication mechanisms are out of=0D=0Ascope, = and, like SIP basic calling, are not usually mentioned in IETF=0D=0Adocumen= ts.=0D=0A=0D=0AStephen, we've tried pretty hard to make sure this works for= 3G/4G=0D=0Amobile=0D=0Anetworks. It's true that it doesn't do it the way = 3GPP currently thinks=0D=0Ait ought to work, but we claim they haven't thou= ght through all the=0D=0Aissues. While it would work, there are opportunit= ies for improvement.=0D=0AWe=0D=0Awould be willing to do that if we could g= et the cooperation of 3GPP,=0D=0Awhich=0D=0Awe have tried, and failed, to d= o.=0D=0A=0D=0ASo, I think the documents do not need any qualification state= ments.=0D=0A=0D=0ABrian=0D=0A=0D=0A> Martin=0D=0A>=0D=0A> The 3GPP/3GPP2 so= lution has a defined restricted applicability (mainly=0D=0Ato=0D=0A> 3GPP/3= GPP2 access networks where the serving network also acts as the=0D=0AVSP)=0D= =0A> and the specifications for it cover in detail all possible scenarios=0D= =0A> consistent with these restrictions so far as we are aware.=0D=0A>=0D=0A= > The Ecrit solution seems to claim global applicability to all types of=0D= =0AIP=0D=0A> access (and the more that is said about this from Ecrit partic= ipants=0D=0Athe=0D=0A> more this gets emphasized) but does not cover in det= ail all possible=0D=0A> scenarios (in some cases does not cover in any deta= il) which means=0D=0Athat at=0D=0A> best the solution is incomplete and at = worst intrinsically=0D=0Ainapplicable to=0D=0A> some unstated set of scenar= ios.=0D=0A>=0D=0A> The missing, incomplete and problematic cases include th= e following:=0D=0A>=0D=0A> - access to PSTN capable PSAPs=0D=0A> - hand= over between different IP access networks including different=0D=0A> types = of access network=0D=0A> - handover to/from circuit mode networks=0D=0A> = - location for cellular access (and the requirement to support LCPs=0D=0A= that=0D=0A> will be useless for cellular access)=0D=0A> - endpoint based = location and routing for cellular access (issues=0D=0Ahere=0D=0A> are netwo= rk and device loading as well as device impacts and problems=0D=0A> with PS= TN capable PSAPs)=0D=0A> - support of unauthenticated users and users who= can be=0D=0Aauthenticated=0D=0A> but are not permitted access/VSP service = except for emergency calls=0D=0A>=0D=0A> Stating that some of these cases a= re out of scope or referencing an=0D=0A> incomplete and possibly questionab= le specification from some other=0D=0A> national SDO will not help the user= who encounters such problems. But=0D=0Ait=0D=0A> would certainly help netw= ork operators and implementers to acknowledge=0D=0A> their existence in one= form or another because that would allow better=0D=0A> planning of deploym= ents and would help focus attention on finding=0D=0A> solutions (whether in= IETF or elsewhere) for the missing cases.=0D=0A>=0D=0A> Please note that d= espite these drawbacks, I will acknowledge that=0D=0AEcrit=0D=0A> does have= a valuable solution that covers many scenarios not covered=0D=0Aby=0D=0A> = 3GPP/3GPP2. It would be the delineation of these supported scenarios=0D=0A(= or=0D=0A> equivalently unsupported scenarios) in some applicability stateme= nt=0D=0Athat=0D=0A> would be particularly useful right now.=0D=0A>=0D=0A> K= ind Regards=0D=0A>=0D=0A> Stephen=0D=0A> -----Original Message-----=0D=0A> = From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=0D=0A> Sent: Thurs= day, February 26, 2009 9:45 PM=0D=0A> To: Edge, Stephen; Richard Barnes=0D=0A= > Cc: ECRIT=0D=0A> Subject: RE: [Ecrit] Comments on Framework Draft=0D=0A>=0D= =0A> There's benefit in knowing the limitations of a framework, and every=0D= =0A> architecture makes certain assumptions. Let's examine them though...=0D= =0A>=0D=0A> The IETF might occasionally make the assumption that the standa= rds it=0D=0A> develops are for Internet devices. That assumption probably = need not=0D=0Abe=0D=0A> stated explicitly.=0D=0A>=0D=0A> The ECRIT architec= ture relies on implementations of the protocols that=0D=0Ait=0D=0A> referen= ces. That is not extraordinary. A reliance on implementation=0D=0Aof=0D=0A= > these protocols by endpoints, routing intermediaries and PSAPs should=0D=0A= not=0D=0A> need to be explained.=0D=0A>=0D=0A> So the assumptions are:=0D=0A= > - the Internet=0D=0A> - solutions are implemented and deployed=0D=0A> = - the end device is a key component=0D=0A>=0D=0A> Only that last element is= particularly novel ... or not that much=0D=0Areally.=0D=0A> It's a desig= n choice. Unless you were thinking of trunking the=0D=0Avoice=0D=0A> elsew= here.=0D=0A>=0D=0A> Of course, you're suggesting that the design choice was= made in=0D=0Aignorance=0D=0A> of all the constraints. You're suggesting t= hat - as a result - the=0D=0Achoice=0D=0A> is flawed and the solution is no= t going to work for cellular services.=0D=0AWe=0D=0A> disagree. The soluti= on is a basis for emergency calling in _any_ IP=0D=0A> network.=0D=0A>=0D=0A= > Cheers,=0D=0A> Martin=0D=0A>=0D=0A>=0D=0A>> -----Original Message-----=0D= =0A>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=0D=0A= Behalf=0D=0A>> Of Edge, Stephen=0D=0A>> Sent: Friday, 27 February 2009 3:30= PM=0D=0A>> To: Richard Barnes=0D=0A>> Cc: 'ECRIT'=0D=0A>> Subject: Re: [Ec= rit] Comments on Framework Draft=0D=0A>>=0D=0A>> Hi Richard=0D=0A>>=0D=0A>>= Thanks for the comments. Your statement below that "SIP emergency=0D=0A>> = calling works if all parties behave as specified in these (IETF=0D=0AEcrit)=0D= =0A>> documents" to some degree highlights the problems we are raising. The=0D= =0A>> documents do contain a number of implicit and explicit restrictions -=0D= =0A>> like IP capable PSAPs, global IP access (no islands of circuit mode=0D= =0A>> access for example), universal support of this solution by all access=0D= =0A>> providers and VSPs (not much good if some opt for another solution)=0D= =0Aand=0D=0A>> end system oriented location and routing capability - which = together=0D=0A>> make them unsuitable (we believe) for cellular wireless ne= tworks. If=0D=0A>> these restrictions and assumptions were all made explici= t upfront, it=0D=0A>> would to a large degree (and possibly completely) add= ress our=0D=0Aconcerns.=0D=0A>>=0D=0A>> You are right in assuming another s= et of specifications for the 3GPP=0D=0A>> and 3GPP2 solution. The applicabi= lity of this solution is explicitly=0D=0A>> defined in TS 23.167 (or more e= xactly in an already agreed CR in=0D=0A>> contribution S2-090752 which will= become part of 23.167 in a few more=0D=0A>> weeks) to cover the following = access types: GPRS (UTRAN WCDMA),=0D=0AI-WLAN,=0D=0A>> Fixed Broadband, CDM= A2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN=0D=0A>> (LTE). So there is a = restriction and arbitrary internet access is not=0D=0A>> covered (yet) as I= have stated before.=0D=0A>>=0D=0A>> Kind Regards=0D=0A>>=0D=0A>> Stephen=0D= =0A>> -----Original Message-----=0D=0A>> From: Richard Barnes [mailto:rbarn= es@bbn.com]=0D=0A>> Sent: Wednesday, February 25, 2009 6:30 PM=0D=0A>> To: = Edge, Stephen=0D=0A>> Cc: Brian Rosen; 'ECRIT'=0D=0A>> Subject: Re: [Ecrit]= Comments on Framework Draft=0D=0A>>=0D=0A>> Hi Stephen,=0D=0A>>=0D=0A>> I'= m a little confused by the scope of what you're asking. The=0D=0A>> framew= ork=0D=0A>> and phonebcp documents exist in order to describe the ECRIT sol= ution:=0D=0A>> They say, in effect, "SIP emergency calling works if all par= ties=0D=0Abehave=0D=0A>> as specified in these documents."=0D=0A>>=0D=0A>> = As I understand what you're saying (and I'm by no means an expert in=0D=0A>= > 3GPP), 3GPP specifies that one or more elements of this system behave=0D=0A= >> differently. This simply means that 3GPP networks aren't complying=0D=0A= >> with=0D=0A>> these specs. Just like there's no disclaimer in RFC 791 (I= Pv4) that=0D=0A>> says "this doesn't work on X.25 networks", it's not clear= to me that=0D=0Aan=0D=0A>> analogous disclaimer is called for here.=0D=0A>= >=0D=0A>> I presume there are similar documents describing how emergency=0D= =0Acalling=0D=0A>> works in 3GPP networks. Do they include notes saying th= at the 3GPP=0D=0A>> solution doesn't work in the broader Internet=3F=0D=0A>= >=0D=0A>> --Richard=0D=0A>>=0D=0A>>=0D=0A>>=0D=0A>>=0D=0A>>=0D=0A>> Edge, S= tephen wrote:=0D=0A>> > Brian=0D=0A>> >=0D=0A>> > First of all apologies fo= r the likely lateness of this reply - I=0D=0A>> actually wrote it on 19 Feb= ruary in a 3GPP SA2 meeting in Budapest=0D=0Abut=0D=0A>> it seems unlikely = that my VPN, Outlook server and WiFi access=0D=0A>> capability will coopera= te together to get it sent until I return to=0D=0Athe=0D=0A>> office mid-ne= xt week.=0D=0A>> >=0D=0A>> > Anyhow thanks for your comments. There have ac= tually been a number=0D=0Aof=0D=0A>> conference calls between IETF and 3GPP= participants over the last=0D=0A>> couple of years at which common feature= s like support of IP emergency=0D=0A>> calls were discussed and these could= have been good forum for=0D=0A>> participants on either side to have raise= d the kinds of issues you=0D=0A>> elaborate on below. Given that seems not = so far to have happened, it=0D=0A>> could still be possible in future such = calls.=0D=0A>> >=0D=0A>> > But the issues we are raising are not directly t= o do with further=0D=0A>> aligning the 2 solutions or with the lack of this= in the past. We are=0D=0A>> simply pointing out that the solutions are cur= rently different and=0D=0Athat=0D=0A>> from a cellular wireless perspective= , the Ecrit solution is not seen=0D=0Aas=0D=0A>> suitable in all respects (= for support of IP emergency calls=0D=0Aoriginating=0D=0A>> from such access= types). That is not just our point of view. 3GPP2=0D=0Asent=0D=0A>> a liai= son to Ecrit some months ago pointing out the same issues.=0D=0A>> >=0D=0A>= > > So we are proposing that the Ecrit framework and phoneBCP spec.s=0D=0A>= > include a statement acknowledging this - e.g. by referencing the=0D=0A>> = alternative 3GPP/3GPP2 solution and indicating the IP access types=0D=0Afor=0D= =0A>> which the Ecrit solution will work without limitation (or=0D=0Aequiva= lently=0D=0A>> the access types where limitations are not ruled out).=0D=0A= >> >=0D=0A>> > We are not proposing further modification and extension of t= he=0D=0AEcrit=0D=0A>> solution - just pointing out that this would be neede= d (as with the=0D=0A>> 3GPP/3GPP2 solution) to fully cover all types of acc= ess.=0D=0A>> >=0D=0A>> > Kind Regards=0D=0A>> >=0D=0A>> > Stephen=0D=0A>> >= -----Original Message-----=0D=0A>> > From: Brian Rosen [mailto:br@brianros= en.net]=0D=0A>> > Sent: Wednesday, February 18, 2009 8:07 PM=0D=0A>> > To: = Edge, Stephen; 'ECRIT'=0D=0A>> > Subject: RE: [Ecrit] Comments on Framework= Draft=0D=0A>> >=0D=0A>> > I have bit my tongue on this one for a long time= =2E=0D=0A>> >=0D=0A>> > Stephen, with respect, please go talk to 3GPP manag= ement and ask=0D=0Athem=0D=0A>> why=0D=0A>> > there has been no participati= on in the ecrit effort despite=0D=0Amultiple=0D=0A>> YEARS=0D=0A>> > of beg= ging them to get involved. To put it frankly, 3GPP is quite=0D=0A>> willin= g=0D=0A>> > to bully IETF into doing its work on its schedule, but cannot b= e=0D=0A>> bothered to=0D=0A>> > get work done it knows it will eventually h= ave to do when the IETF=0D=0A>> asks it=0D=0A>> > to do so.=0D=0A>> >=0D=0A= >> > 3GPP understands the mess that is being created by not=0D=0Aparticipat= ing.=0D=0A>> They=0D=0A>> > know full well that when they finally get aroun= d to dealing with PS=0D=0A>> > terminated emergency calls, that there will = be a lot of resistance=0D=0Ato=0D=0A>> > changing fully specified and imple= mented standards to more closely=0D=0A>> align=0D=0A>> > with 3GPP standard= s. I expect you will have several interworking=0D=0A>> functions=0D=0A>> >= to define and build.=0D=0A>> >=0D=0A>> > So, politely, please go away, we'= re finishing work we dearly wanted=0D=0A>> you all=0D=0A>> > to be involved= with for years, but you refused to do anything.=0D=0AIt's=0D=0A>> too=0D=0A= >> > late for this rev.=0D=0A>> >=0D=0A>> > Now, having said that, there ar= e quite a few people who have=0D=0A>> participated in=0D=0A>> > the IETF wo= rk who are IMS aware and I believe that despite your=0D=0A>> fears,=0D=0A>>= > everything you need is in the specs. The mechanisms we have=0D=0Adefine= d=0D=0A>> provide=0D=0A>> > the ability for the network to insert location,= recognize and mark=0D=0A>> emergency=0D=0A>> > calls, and route on behalf = of endpoints. An E-CSCF could quite=0D=0A>> > straightforwardly provide a = SIP call towards an ecrit compatible=0D=0A>> PSAP. The=0D=0A>> > only not-= quite-nice interwork would be from SUPL to HELD (or SIP),=0D=0A>> but it's=0D= =0A>> > pretty easy to do that. I'll also note that we have tried to get=0D= =0AOMA=0D=0A>> and=0D=0A>> > IETF to cooperate on location protocols, but w= e have been=0D=0A>> spectacularly=0D=0A>> > unsuccessful at that effort als= o.=0D=0A>> >=0D=0A>> > Brian=0D=0A>> >=0D=0A>> >=0D=0A>> >=0D=0A>> >> -----= Original Message-----=0D=0A>> >> From: ecrit-bounces@ietf.org [mailto:ecrit= -bounces@ietf.org] On=0D=0A>> Behalf=0D=0A>> >> Of Edge, Stephen=0D=0A>> >>= Sent: Thursday, February 05, 2009 2:50 AM=0D=0A>> >> To: 'ECRIT'=0D=0A>> >= > Subject: [Ecrit] Comments on Framework Draft=0D=0A>> >>=0D=0A>> >> All=0D= =0A>> >>=0D=0A>> >> draft-ietf-ecrit-framework-07 is (as we see it) a mostl= y=0D=0Ainformative=0D=0A>> >> description of how terminals and networks sho= uld support emergency=0D=0A>> >> calls made over IP capable facilities to I= P capable PSAPs. It=0D=0A>> appears=0D=0A>> >> intended to cover all types = of access network - including fixed=0D=0A>> line,=0D=0A>> >> WiFi and cellu= lar (e.g. examples involving each can be found=0D=0A>> throughout=0D=0A>> >= > the draft).=0D=0A>> >>=0D=0A>> >> When we evaluated this with respect to = support of wireless=0D=0Acellular=0D=0A>> >> access and WiFi access associa= ted with a cellular operator (e.g.=0D=0A>> WLAN=0D=0A>> >> or Femto cells i= ntegrated into a cellular network), we found that=0D=0A>> >> certain portio= ns of the draft exhibited one or more of the=0D=0Afollowing=0D=0A>> >> char= acteristics:=0D=0A>> >>=0D=0A>> >> (A) Inconsistent with already standa= rdized wireless solutions=0D=0A>> >>=0D=0A>> >> (B) Inconsistent with e= ssential wireless requirements and=0D=0A>> >> conventions=0D=0A>> >>=0D=0A>= > >> (C) Already part of wireless standards or potentially part of=0D=0A= >> >> future standards=0D=0A>> >>=0D=0A>> >> (A) refers to all portions of = the draft framework that differ from=0D=0A>> the=0D=0A>> >> requirements an= d procedures currently standardized for wireless=0D=0A>> >> emergency acces= s by 3GPP, 3GPP2 and OMA. This is a plain=0D=0Adifference=0D=0A>> of=0D=0A>= > >> solution and could be resolved through support of both solutions=0D=0A= by=0D=0A>> >> terminals (with each solution being used according to the typ= e of=0D=0A>> >> access network and VSP) or could be resolved by supporting = only=0D=0Aone=0D=0A>> >> solution and accessing only the types of network s= upporting that=0D=0A>> >> solution. To acknowledge this category, the frame= work document=0D=0Acould=0D=0A>> >> reference the applicable wireless stand= ards and point out that=0D=0Athese=0D=0A>> >> are valid alternatives for wi= reless cellular based access.=0D=0A>> >>=0D=0A>> >> (B) refers to portions = of the draft that would be unsuitable for=0D=0A>> >> wireless networks even= if no alternative solution existed together=0D=0A>> with=0D=0A>> >> other = portions missing from the draft that would be needed to=0D=0Afully=0D=0A>> = >> support wireless networks. Examples of the former include: (a)=0D=0A>> e= mphasis=0D=0A>> >> on endpoint derivation of location, performance of Lost = query and=0D=0A>> >> receipt of local dial strings; (b) restriction of LCPs= to=0D=0Aprotocols=0D=0A>> >> that require terminal initiation (not allowin= g for network=0D=0A>> initiation=0D=0A>> >> as far as we can tell) and that= include two LCPs (DHCP and LLDP)=0D=0A>> that=0D=0A>> >> are not applicabl= e to (not defined for) cellular access; and (c)=0D=0Athe=0D=0A>> >> require= ment that a terminal or at least a LIS will update the PSAP=0D=0A>> >> when= ever location changes. (a) is impractical due to network and=0D=0A>> >> ter= minal loading consequences and failure to support non-IP=0D=0Acapable=0D=0A= >> >> PSAPs; (b) makes location verification and updated location=0D=0A>> p= rovision=0D=0A>> >> to PSAPs difficult or impossible; while (c) is also inc= ompatible=0D=0A>> with=0D=0A>> >> support of existing non-IP capable PSAPs = besides increasing=0D=0Aterminal=0D=0A>> >> load and possibly interfering w= ith optimum maintenance of the RF=0D=0A>> >> connection (e.g. if a terminal= has to tune away from the serving=0D=0A>> base=0D=0A>> >> station or WLAN = periodically to make location measurements).=0D=0A>> Examples=0D=0A>> >> of= the latter include (d) absence of support for access to non-IP=0D=0A>> >> = capable PSAPs as already mentioned (e.g. to support E911 phase 2=0D=0Ain=0D= =0A>> the=0D=0A>> >> US); (e) no support for handover from the IP to the ci= rcuit domain=0D=0A>> when=0D=0A>> >> a terminal loses (e.g. moves out of) R= F coverage in the IP domain;=0D=0A>> and=0D=0A>> >> (f) no allowance for li= mited access modes wherein a terminal may=0D=0A>> access=0D=0A>> >> a netwo= rk only to place an emergency call with ensuing=0D=0Arestrictions=0D=0A>> o= n=0D=0A>> >> (for example) location acquisition, PSAP callback and caller=0D= =0A>> >> verification and identification to the PSAP. To resolve this=0D=0A= >> category=0D=0A>> >> either significant changes to the framework document= could be made=0D=0A>> or a=0D=0A>> >> disclaimer/applicability statement c= ould be added stating that=0D=0A>> support=0D=0A>> >> of cellular wireless = networks and their associated WLAN and Femto=0D=0A>> >> access points is no= t covered.=0D=0A>> >>=0D=0A>> >> Category (C) comprises concepts and capabi= lities in the draft that=0D=0A>> are=0D=0A>> >> either already part of the = standardized solution for wireless=0D=0A>> networks=0D=0A>> >> or that migh= t be added at a later time. Examples of the former=0D=0A>> include=0D=0A>> = >> LoST, SIP location conveyance, general use of SIP, location for=0D=0A>> = routing=0D=0A>> >> versus for dispatch, cellular positioning methods. Examp= les of the=0D=0A>> >> latter include use of location references and derefer= encing and=0D=0A>> >> possible interworking between the current wireless ne= twork=0D=0Asolutions=0D=0A>> >> (in 3GPP, 3GPP2 and OMA) and the solution d= escribed in this draft.=0D=0A>> The=0D=0A>> >> presence of this category co= uld be acknowledged by following the=0D=0A>> >> disclaimer for (B) with a s= tatement that certain portions of the=0D=0A>> >> solution are expected to b= e incorporated into wireless networks=0D=0Anow=0D=0A>> >> and/or in the fut= ure.=0D=0A>> >>=0D=0A>> >> We hope that these comments will be seen to be a= useful addition=0D=0Ato=0D=0A>> >> this review in the sense of enabling a = more precise scoping for=0D=0Athe=0D=0A>> >> framework document and we are = willing to assist in providing=0D=0Awording=0D=0A>> >> for any disclaimer/a= pplicability statement that the Ecrit working=0D=0A>> group=0D=0A>> >> may = now deem fit to include.=0D=0A>> >>=0D=0A>> >> Kind Regards=0D=0A>> >>=0D=0A= >> >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs=0D=0A>> = (Qualcomm=0D=0A>> >> 3GPP2 TSG-X and TSG-C participant)=0D=0A>> >>=0D=0A>> = >> PS this being sent on 2/4/09 at 11:50pm PST=0D=0A>> >>=0D=0A>> >> _____= __________________________________________=0D=0A>> >> Ecrit mailing list=0D= =0A>> >> Ecrit@ietf.org=0D=0A>> >> https://www.ietf.org/mailman/listinfo/ec= rit=0D=0A>> >=0D=0A>> > _______________________________________________=0D=0A= >> > Ecrit mailing list=0D=0A>> > Ecrit@ietf.org=0D=0A>> > https://www.ietf= =2Eorg/mailman/listinfo/ecrit=0D=0A>> >=0D=0A>> ___________________________= ____________________=0D=0A>> Ecrit mailing list=0D=0A>> Ecrit@ietf.org=0D=0A= >> https://www.ietf.org/mailman/listinfo/ecrit=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 infor= mation.=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> t= his email is prohibited.=0D=0A>=0D=0A--------------------------------------= ----------------------------------=0D=0A------------------------=0D=0A> [mf= 2]=0D=0A> _______________________________________________=0D=0A> Ecrit mail= ing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www.ietf.org/mailman/listinfo= /ecrit=0D=0A>=0D=0A=0D=0A_______________________________________________=0D= =0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman= /listinfo/ecrit=0D=0A=0D=0A------------------------------------------------= ------------------------=0D=0A------------------------=0D=0AThis message is= for the designated recipient only and may=0D=0Acontain privileged, proprie= tary, or otherwise private information.=0D=0AIf you have received it in err= or, please notify the sender=0D=0Aimmediately and delete the original. Any= unauthorized use of=0D=0Athis email is prohibited.=0D=0A------------------= ------------------------------------------------------=0D=0A---------------= ---------=0D=0A[mf2]=0D=0A=0D=0A=0D=0A-------------------------------------= -----------------------------------=0D=0A------------------------=0D=0AThis= message is for the designated recipient only and may=0D=0Acontain privileg= ed, proprietary, or otherwise private information.=0D=0AIf you have receive= d it in error, please notify the sender=0D=0Aimmediately and delete the ori= ginal. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A-------= -----------------------------------------------------------------=0D=0A----= --------------------=0D=0A[mf2]=0D=0A=0D=0A=0D=0A--------------------------= ----------------------------------------------------------------------=0D=0A= This message is for the designated recipient only and may=0D=0Acontain priv= ileged, proprietary, or otherwise private information. =20=0D=0AIf you have= received it in error, please notify the sender=0D=0Aimmediately and delete= the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0A[mf2]=0D=0A From andreaf@cs.columbia.edu Mon Mar 9 21:06:48 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6869B3A6C84 for ; Mon, 9 Mar 2009 21:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLMPsRSkw5qL for ; Mon, 9 Mar 2009 21:06:47 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 997423A6405 for ; Mon, 9 Mar 2009 21:06:47 -0700 (PDT) Received: from [10.0.1.200] (user-0cevfv5.cable.mindspring.com [24.239.191.229]) (user=agf2104 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2A47EvF024457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 10 Mar 2009 00:07:21 -0400 (EDT) Message-ID: <49B5E771.7010301@cs.columbia.edu> Date: Tue, 10 Mar 2009 00:07:13 -0400 From: "Andrea G. Forte" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Subject: [Ecrit] URN policy draft - draft-forte-ecrit-service-urn-policy-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 04:06:48 -0000 Dear all, this is the link to the updated version of the draft. http://www1.cs.columbia.edu/~andreaf/new/documents/ietf/draft-forte-ecrit-service-urn-policy-00.txt Regards, -Andrea From andreaf@cs.columbia.edu Mon Mar 9 21:11:10 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0185828C0DC for ; Mon, 9 Mar 2009 21:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.67 X-Spam-Level: X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWdiGy-p3f0x for ; Mon, 9 Mar 2009 21:11:09 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 4253328C0DD for ; Mon, 9 Mar 2009 21:11:09 -0700 (PDT) Received: from [10.0.1.200] (user-0cevfv5.cable.mindspring.com [24.239.191.229]) (user=agf2104 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2A4Bh5j025340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 10 Mar 2009 00:11:43 -0400 (EDT) Message-ID: <49B5E87E.8020802@cs.columbia.edu> Date: Tue, 10 Mar 2009 00:11:42 -0400 From: "Andrea G. Forte" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Subject: [Ecrit] service URN draft - draft-forte-ecrit-service-classification-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 04:11:10 -0000 Dear all, this is the link to the updated version of the draft. http://www1.cs.columbia.edu/~andreaf/new/documents/ietf/draft-forte-ecrit-service-classification-02.txt Regards, -Andrea From andreaf@cs.columbia.edu Mon Mar 9 21:11:14 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 033BB28C0F6 for ; Mon, 9 Mar 2009 21:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-NrIag8abVS for ; Mon, 9 Mar 2009 21:11:13 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 3A14228C0E0 for ; Mon, 9 Mar 2009 21:11:13 -0700 (PDT) Received: from [10.0.1.200] (user-0cevfv5.cable.mindspring.com [24.239.191.229]) (user=agf2104 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2A4BkBj012826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 10 Mar 2009 00:11:47 -0400 (EDT) Message-ID: <49B5E881.5050709@cs.columbia.edu> Date: Tue, 10 Mar 2009 00:11:45 -0400 From: "Andrea G. Forte" User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Subject: [Ecrit] Lost extension draft - draft-forte-ecrit-lost-extensions-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 04:11:14 -0000 Dear all, this is the link to the updated version of the draft. http://www1.cs.columbia.edu/~andreaf/new/documents/ietf/draft-forte-ecrit-lost-extensions-02.txt Regards, -Andrea From br@brianrosen.net Tue Mar 10 06:47:37 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932113A6908 for ; Tue, 10 Mar 2009 06:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-k83g67voaQ for ; Tue, 10 Mar 2009 06:47:33 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 7BA833A6901 for ; Tue, 10 Mar 2009 06:47:33 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Lh2JK-00069s-5o; Tue, 10 Mar 2009 08:47:59 -0500 From: "Brian Rosen" To: "'Edge, Stephen'" , "'Dawson, Martin'" References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com><64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net> <1288E74A73964940B132A0B9EA8D8ABC5374A0D6@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5374A3FE@NASANEXMB04.na.qualcomm.com> In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5374A3FE@NASANEXMB04.na.qualcomm.com> Date: Tue, 10 Mar 2009 09:48:02 -0400 Message-ID: <028701c9a186$d6ece9f0$84c6bdd0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmY6xBP94jupkzETj+iA0b5U69mvgDj/IbwAGceYlAAwDSRoAAaf17w Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: 'ECRIT' Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 13:47:37 -0000 Stephen In today's emergency services systems, the PSAPs are PSTN connected, and every country is different. To use ecrit within a country, it probably would take some nation-specific standardization to get ecrit originated calls into a legacy PSAP. The expectation, which is supported by some evidence, is that as PSAPs move to become IP connected, they will follow international standards, such as ecrit. Certainly, in North America, that will be true; IP connected PSAPs will assume ecrit standards in the interface between the origination network and the Emergency Services IP network (ESInet). Regardless of what 3GPP does, the interface into North American ESInets will be ecrit based. This should not be any burden on IMS systems; in NENA, we've spent some considerable time making sure the current standards can be met by E-CSCFs without introducing any other changes in 3GPP networks. In fact, we've put some work into making sure we can use an IMS network as an ESInet. In the transition between CS and PS connected PSAPs, there will be some need for nation-specific standards; we all start from different places, even if we end up in the same place. It may be that some of your concerns are handled in that transition phase. 1. Access to PSTN capable PSAPs: is nation specific, and must be defined by that nation. This is unfortunate, but unavoidable. Clearly there is a gateway, which is the target of the LoST PSAP URI, but what happens on the PSTN side of the gateway is very specific to the details of the emergency system in a country at this time. I don't think 3GPP can do much here either, for the same reason. 2. Handover between different IP access networks: There are two aspects here, the actual call origination, and the effect after the call is established if the access network changes. Generally, most of the discussion in ecrit is on the session establishment, and that would take place in one network; most systems don't actually allow handoff while doing session establishment (often, if the session establishment is in progress, handoff is either delayed, or the call attempt is dropped and retried after the handoff). There are small sections on mid call behavior, and on call termination in our docs. Most IETF protocols for IP handoff either have no visibility to SIP, or require renegotiation of IP addresses, neither of which would result in text in -framework or -phonebcp. Thus, I'm not sure there is any work needed for IP handoff, but if there is, I think we'd welcome text. 3. Handover to/from circuit mode networks. Again, this is a mid-call/session termination issue, and not a session establishment issue, and again, is not likely to have much effect on the documents at hand. NENA is working on North American specific legacy call origination (where the origination is CS, and thus North American specific), which would put a gateway between the CS origination network and the PS ESInet. I'm not aware of any IETF documents that discuss this in non-emergency calls, and we seem to be okay. I don't think there is any text needed in ecrit, given that. 4. Location for cellular access: we have covered that extensively in this discussion. Ecrit would permit the use of SUPL within the origination network, although you have the router with the data card problem. I will tell you that NENA's standards would require that the E-CSCF interwork SUPL to HELD, but that is not a big deal. 5. Endpoint based routing: as has been pointed out, ecrit permits network routing 6. Support of unauthenticated users (and users in limited service state): This one might well be 3GPP specific, because 3GPP has a very specific emergency registration process. I doubt that other access networks would want to copy the 3GPP mechanism. There is some text in -framework on unauthenticated access. I don't see the IETF standardizing an emergency registration mechanism, but you might propose it and see what happens. I think most networks either just allow an emergency call with no registration, allow a registration but restrict what calls can be made/received, or don't support emergency calls from non registered devices. Brian -----Original Message----- From: Edge, Stephen [mailto:sedge@qualcomm.com] Sent: Monday, March 09, 2009 9:23 PM To: Dawson, Martin; br@brianrosen.net Cc: ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Hi Martin Thanks for theses further comments - which I agree introduce a new twist to this discussion. Your main assertion seems to be that most of the general points I raised are not matters for Ecrit to resolve and standardize but instead represent problems to be resolved for the particular AN (either by an SDO associated with the AN by or by some national SDO like NENA in the case of PSAP access). The list of such issues seems to be: 1. Access to PSTN capable PSAPs 2. Handover between different IP access networks 3. Handover to/from circuit mode networks 4. Location for cellular access 6. Support of unauthenticated users (and users in limited service state) If I am generally right in this assumption, my first question is whether this is just your particular opinion or if this represents the view of Ecrit generally. E.G. is there any danger that Ecrit (or some other IETF group) might reclaim one or more of the above - perhaps after others SDOs (like 3GPP) have produced their own solutions? If you are all quite certain that this will not happen, or at least certain of this for some subset of the above, it would very much help to include a statement on this in the phoneBCP and/or framework drafts so there is no ambiguity. My next comment is that solving the above for each type of AN probably represents most of difficulty in producing a comprehensive solution. For example, handover after a location URI has been obtained from a LIS will be problematic for continuing location (since the previous and now wrong LIS may receive the next location request). Similarly access and handover to restricted areas (cells or networks a user is not normally allowed to use) is problematic particularly if normal IP connectivity is assumed. Further, use of HELD with a control plane location solution is highly problematic for any 3GPP network because the current architecture and procedures are not able to support location requests initiated solely from a location server (like an SMLC or SAS) where there no prior interaction with the RAN and CN. Further to that, control plane solutions cannot often obtain location accurately enough for dispatch and need to incorporate terminal based positioning using say A-GPS which can lead to a user plane solution like SUPL. I could add other problem areas if you believe this list is exhaustive. Now I am not saying that these problem areas cannot be solved - 3GPP and 3GPP2 have in fact solved most of them (and should complete this by the end of this year) in the context of the 3GPP/3GPP2 solution. But your position now seems to be that any SDO must solve them subject to the various restrictions and requirements imposed by the Ecrit phoneBCP and Framework drafts. Can you confirm that this is so? Kind Regards Stephen -----Original Message----- From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] Sent: Thursday, March 05, 2009 10:56 PM To: Edge, Stephen; br@brianrosen.net Cc: ECRIT Subject: RE: [Ecrit] Comments on Framework Draft There must be a word for the situation where everybody is talking about something but everybody knows the real subject is something else and what that real subject is. Suggestions welcome. Anyway, working on the basis that this whole thing isn't just about getting a "sound bite" added to the framework document that can be misappropriated for years to come to confuse the cellular industry into thinking ECRIT is not relevant to them, let's look at each of Stephen's topic areas below. A fundamental tenet of the argument is that, somehow, cellular is "special" and should be left to its "special" devices compared to every other Internet access technology. This, after all, is why we have IMS. It might have seemed reasonable ten years ago to define the core service architecture to accompany the new "Packet Service" mode of networking. In these days of Web 2.0, AJAX, Ruby on Rails, Flash, Silverlight, SOA, Azure... etc. against which IMS seems very.... "stodgy" it is reasonable to ask the question why such a monolithic and cellular-legacy service model is required. Nevertheless - 3GPP is entitled to do what 3GPP does. Actually I'm pretty sure you won't find references to IMS in Web 2.0 texts saying "of course cellular operators also use IMS as an application framework." Now - how specific are the "special" cases that are outlined below to cellular?: 1. Access to PSTN capable PSAPs Not specific to cellular. If a jurisdiction has PSTN capable PSAPs then VoIP calls originating from any form of access have to deal with that fact. The answer is fairly obvious - there has to be a media gateway behind the PSAP URI. And it might not just be a PSTN PSAP, there could be dedicated circuits to selective routers or, even, CAMA trunks involved. The manner in which this is done really does need to be spelt out by the jurisdiction; it can't be otherwise even if there are fairly common conventions. NENA looks after stating how this is done for the US. It's not up to 3GPP nor the IETF to tell jurisdictions how emergency calls that originate on Internet access get bridged into the legacy PSAP infrastructure. No more so than it was 3GPP's job to prescribe that E2+ had to be the PSAP/ALI to GMLC interface protocol used for CS E9-1-1 calls. 2. Handover between different IP access networks Not specific to cellular. There can be handover between WiFi and Ethernet, WiFi and WiMAX and so forth. Now - what we're really talking about here is a more fundamental capability related to mobile IP. 3GPP definitely has a very nice role to play in prescribing how this access-mobility occurs across the access technologies that 3GPP defines and supports. Since the ECRIT emergency model concerns itself from the IP layer up, it is quite possible for it to work very transparently to such mobility occurring beneath the surface. And, of course, any such nicely integrated access technologies would offer a nicely integrated LIS solution to ensure that the location service remains contiguous and consistent. It seems to me that it's quite bad engineering to couple the manner in which this is done to a specific IP service such as emergency calling. Can't help it if 3GPP do that - but it doesn't obviate the option of ECRIT being applied in the more elegant way. 3. Handover to/from circuit mode networks I'll give you this one... to an extent. Obviously the IETF doesn't think this is in the least bit relevant to them. On the other, in theory, a VoIP connection established on any form of IP access could be handed over to some other form of circuit access - e.g. DSL to ISDN. The issue, of course, is just how realistic these scenarios are. If you accept that the PSTN is going to go away (and I certainly do) then you also acknowledge that this is a transitional issue. You can argue that the PSTN is still going to be around for years to come (and I also agree with that) but that doesn't mean you have to create a specific mechanism to handover between circuit and packet for emergency services. I'm interested in just what it is that 3GPP have defined for this. I look at the current 23.167 specification and, I admit, it doesn't leap out at me. The stage 2 description has always struck me as kind of vague. The diagram concerning location information handling, for example, has the dotted boxes with non-prescriptive steps saying "procedure to obtain location" done here. It always kind of reminds me of that old cartoon with the engineers looking at the complex flow chart with the "a miracle happens here" box in the middle. I'm thinking of a call originated on IP. Let's say the E-CSCF invokes the E-SLP to do a SUPL NI-LR (assuming one manifestation of the dotted box in the diagram) and the resultant location is used to determine the correct MGCF route to deliver the call. Perhaps the PSAP supports an MLP interface to the LRF and can ask it for location updates - kicking off a SUPL NI-LR again. Now - the device "roams" to a bit of the network that can only support circuit service? What exactly happens? Does it initiate another call via the MSC? How does that interact with the existing emergency service semantics in the MSC? Obviously it wants to initiate a whole new call - and initiate control plane location determination so it can report an initial location to the GMLC. Is that GMLC the same node as the LRF? How does it deal with the fact that it's now got two pieces of state for what in theory is the same call? Or is it - given the MSC can't know about the PS call in progress? What has 3GPP actually defined for this? I am certainly interested in the mechanics of how this is all accomplished and done reliably. ITRW (the one you and I live in) 3G operators commonly force emergency calls onto the GERAN just because that's lower risk since GSM emergency calling is well established and things like UTDOA infrastructure are available on that access. This is quite the opposite tendency of looking to have seamless real time migration between access technologies on emergency calls (let alone seamless migration between PS and CS!). What carriers are planning to do this with emergency calls if you can say? 4. Location for cellular access. Certainly not specific to cellular access. Every technology has a need for accurate location determination. Wired technologies also, most appropriately, need the location to be provided in civic address form; something that the nominated LCPs are very good at. You're partly confusing the role of the LCP protocol with that of the server. You can send a very simple HELD request to a LIS to ask for location; it's incredibly simple to do; that's why HELD client implementations keep popping up from different sources. The complex stuff happens on the server side. A LIS receiving such a request can invoke all manner of control plane mechanisms (for the confused - "control plane" is not an antonym of "IP"; it just means interaction occurs between network elements and not over the traffic channel with the device). For example, the LIS might do UTDOA. Now, I suspect you realize this and carefully chose examples of technologies that involve measurements taken by the device. Fortunately this is not precluded by HELD either; I believe James has already pointed you at the material for this. Finally, since "cellular (=3GPP)" is clearly your one true interest here, the good news is that cellular networks already have terrific infrastructure and control plane mechanisms in place for location determination. This includes the UE peer signalling for AGPS, OTDOA and so forth. All a LIS in a 3GPP network has to do is provide the semantics of the LCP to the device and emergency network clients and to invoke that existing control plane infrastructure at the back end. It's certainly a lower cost and more robust alternative than building SUPL infrastructure in parallel to that control plane capability which already exists to support CS emergency calls anyway. 5. Endpoint based location and routing Nothing cellular specific about this one. Same thing applies to WiFi and WiMAX and wired technologies too. The old "network loading" furphy is often rolled out for these sorts of discussions; presumably it's attractive because it sounds "technical" but doesn't really warrant proper quantification and justification. Gosh "billions" of devices - how can we even consider having so many devices doing... "stuff"? It does prompt me to ask the question "what part of the term 'broadband' don't you understand?" I'm going to take a wild stab and suggest that a device being used to make an emergency call probably isn't "idle". Further, with respect to the general IETF location service model, I'm going to suggest that a device that wants to ask for its location isn't idle either. Even further, I'm going to suggest that a LIS servicing a location dereference can have enough integration with the access network to have the device paged and for location procedures to proceed (i.e. just like a control plane MT-LR or a SUPL NI-LR - though the latter is an ill-defined proposition with respect to arbitrary access types). Actually your commentary on this section strongly suggests to me that you don't actually understand how an ECRIT emergency call procedure works. You've certainly tried to characterize all this LoST and PSAP boundary stuff that's going on as a big deal. It isn't and there's certainly no more going on from either a device or network perspective than there would be to provide the same functionality via a control plane or SUPL approach. If you'd like an offline overview of how an ECRIT emergency call is made, let me know; it would be my pleasure. 6. Support of unauthenticated users Definitely not a cellular specific issue; every access technology has to ask itself about this. Actually every regulator in every jurisdiction has to ask themselves about this too - and hopefully they can avoid the mistake of thinking one form of public access technology is "special" compared to others as well. That would mitigate the risk of them coming up with inconsistent and confusing legislation. ECRIT is based on IP - so the key first step to getting an ECRIT-compliant emergency call underway is for the device to have IP access. In 3GPP parlance, you'd say it needs to have a network context. A good example of providing ECRIT-compliant emergency calling to unauthenticated devices is WiFi hotspots. Hotspots typically provide free layer 2 connectivity and an IP context in the first instance. Device traffic is "port-trapped" to the Hotspots' web site (and maybe a smattering of public Internet websites as well). The firewall isn't opened up until the user "authenticates"; the valid token very often taking the form of a credit card number and expiry date. So -what would a Hotspot need to do to provide "unauthenticated" emergency access? All it needs to do is to ensure that unauthenticated devices, in addition to having access to the portal web page, also have access to a LIS, a LoST server and to the PSAP URI(s) which service the location of that hotspot. That's it; sure there's no emergency call proxy via a third party VSP - but that's not necessary (I'm actually against it anyway) but it could be accommodated with some tweaks on the approach described. Now - what would a 3GPP network need to do to support an ECRIT-compliant unauthenticated emergency calling facility? You could probably describe it better than me - but I dare say it would involve allowing the device to establish an emergency IP context (something which I believe is required by 23.167 anyway - otherwise how would the UE be able to tell the P-CSCF it wants to do an emergency call?). Having permitted the creation of the emergency context, the 3GPP network would similarly just need to constrain the device's access to the LIS, LoST, and the PSAP URI(s) for the corresponding location. Obviously 3GPP have decided to define a different way of doing things and that's par for the course. It's 3GPP's prerogative to continue to act as if there is something special about cellular and that there's good reason for it to look different to both IP devices and the emergency network. It's not true - but that's never stopped the silo thinking before. And that puts me in mind of that scene from Python's Holy Grail movie. 3GPP guarding the bridge to "cellular land" - "None shall pass..." - It'll end much the same way as well. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Edge, Stephen Sent: Wednesday, 4 March 2009 4:32 PM To: br@brianrosen.net Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft Brian Thanks for these well considered responses. Below I am providing on an item by item basis, and taking into account your responses, a few more reasons why the current Ecrit solution is unsuitable - or, if you prefer, less suitable than the 3GPP/3GPP2 solution - for cellular networks. 1. Access to PSTN capable PSAPs Assuming that the best available solution for this currently is the ongoing NENA i2 standard (as you comment), then there are problems with providing location for dispatch (initial and updated location). For example, the latest i2.5 draft I have (December 2008) says that the VPC to LIS v3 interface is being deprecated (thus not available), although this is the interface that the VPC would use to query location from the LIS. Also I don't see any inclusion of accurate positioning support - e.g. using A-GPS. Further, interworking with the circuit mode side for UA access (as opposed to PSAP access) seems to be out of scope. So at best, this standard is incomplete (i.e. not yet suitable for cellular networks). However, I agree that there is some overlap between i2.5 and the 3GPP/3GPP2 solution. 2. Handover between different IP access networks including different types of access network One of the issues here would be change of LIS across different networks while avoiding impacts to both IP and PSTN capable PSAPs (i.e. handover must be transparent to PSAPs within the limitations imposed by SIP or some J-STD-036 type of circuit mode solution). The problem gets more difficult when handover to/from circuit mode access networks is considered. So far, 3GPP/3GPP2 has not yet agreed on a solution although there are proposals and we expect some resolution soon. On the Ecrit and NENA sides, I see much less progress. 3. Handover to/from circuit mode networks We agree here at least on the out of scope aspect. I suppose I can accept that it is not customary to point this out in IETF standards. But I hope you can see that this is an issue for cellular networks most of which will have extensive circuit mode coverage for a long time to come. 4. Location for cellular access (and the requirement to support LCPs that will be useless for cellular access) The issue is not so much the LCP itself but the capability to support accurate positioning - e.g. using A-GPS, AFLT, OTDOA, enhanced cell ID etc. None of those methods seem to be supported as part of DHCP or HELD right now. So some modification of the LCP related requirements or of the LCPs seems needed. 5. Endpoint based location and routing for cellular access (issues here are network and device loading as well as device impacts and problems with PSTN capable PSAPs) Endpoint based location when spread over millions (billions, planet-wide) of terminals will consume significant network and terminal resources. A typical terminal is generally idle and interacts with the network very sparingly to update the network with its current location (e.g. current cluster of potential serving cells). Performing network assisted periodic location fixes and LoST queries would add significantly to network load. Performing periodic location fixes in the terminal (e.g. using GPS) and estimating when a PSAP boundary may have been crossed would add to terminal load (e.g. thus battery drain). Optimizations would be possible of course - e.g. based on observing nearby cell IDs - but they will add to terminal complexity and testing costs. I agree that the Ecrit solution does allow for proxies to do this but here the solution also becomes incomplete because there seem no details of how this would work - e.g. what location solutions would then be used. 6. Support of unauthenticated users and users who can be authenticated but are not permitted access/VSP service except for emergency calls I think the Ecrit solution and you both assume that this has already been resolved somehow at the access level and therefore the various procedures in Ecrit can still be used. Maybe that is valid. However, there are still problems that are not covered in the Ecrit drafts but need to be resolved including (a) obtaining IP access (e.g. via a WLAN, cellular network, cable link) when not a valid subscriber, (b) obtaining access to the VSP and (c) ensuring only emergency related services are provided (e.g. and not free Internet and location access). These and additional problems (e.g. UA identification) would have to be solved, maybe on a per access basis, and then ensured to be compatible with the rest of the Ecrit solution. A significant part of the 3GPP/3GPP2 solution is concerned with this aspect and it has delayed completion of the solution for the more normal case of valid subscriber access due to such compatibility issues. Kind Regards Stephen -----Original Message----- From: br@brianrosen.net [mailto:br@brianrosen.net] Sent: Friday, February 27, 2009 6:53 AM To: Edge, Stephen Cc: Thomson, Martin; Richard Barnes; ECRIT Subject: Re: [Ecrit] Comments on Framework Draft Stephen Like any standards organization, the IETF restricts it's scope. Generally, the scope is "the Internet", although we very often describe solutions that are explicitly designed for private IP networks as well as the Internet. We don't write standards for circuit switched networks, and it should be no surprise that the ecrit solution does not cater to CS solutions. Nevertheless, we often try to make sure that our solutions harmonize reasonably well with existing solutions. Indeed, the ecrit solution clains global applicability to the Internet in general, and most private IP networks that can be interconnected to the Internet or to other IP networks via gateways. Looking at your list of problem areas: > - access to PSTN capable PSAPs This is out of scope for IETF. NENA has active work on this subject. It seems straightforward to interwork ecrit compatible devices and networks to existing CS connected PSAPs. As you know, CS interconnects are very nation-specific, so the NENA work may not have general applicability. However, it shows that it is possible to interwork. The NENA i2 work is also designed to take ecrit compatible devices and VSP networks, and interwork them to the existing network. The VSP would direct the call to the VPC, which would provide the services it does now, using the device provided location for routing. This is important for smooth transition from existing PSAPs and VSPs to "next generation" PSAPs and VSPs. > - handover between different IP access networks including different > types of access network In the ecrit solution, the access network the call is initiated on provides all the facilities needed for the device to initiate an emergency call. The call starts traversing it's normal call path, and eventually routes to the ESRP. Handoffs between IP networks should be transparent to this process, although we probably haven't done all the work we need to do for handoffs where the IP address as seen by the terminating network changes. This would generally be true of all current SIP based work. > - handover to/from circuit mode networks This would be out of scope for IETF. It's as applicable to a simple SIP call as it is a SIP emergency call, and there are no statements in any SIP documents on that subject. > - location for cellular access (and the requirement to support LCPs that > will be useless for cellular access) Location for cellular access networks has been considered carefully. Since cellular is a mobile network, the access network would pass the device a Location-By-Reference URI, using either DHCP or HELD. Either protocol is suitable for cellular networks. As we have pointed out several times, cellular networks support raw data packet services upon which many different kinds of networks can be constructed. My usual example is a large recreational vehicle traveling down a road with a cellular data card plugged into a router to which a wired (Ethernet) phone is connected. That phone must be able to make an emergency call, and it will get location from DHCP or HELD (or LLDP-MED). It is not aware of the cellular network, and doesn't know any cellular specific protocols. Cellular networks will have to support IETF location configuration protocols unless they actively prohibit examples like this, or they implement interworking between cellular-specific location protocols and DHCP or HELD in the data card. The ecrit standards permit proxy insertion of location, but, as above, we don't think that works in all cases. > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) The "load" of using DHCP or HELD to get location and querying LoST is pretty modest. The standards permit proxies to do this if the devices don't. As above, interwork functions to CS connected PSAPs is very feasible, and as above, cellular networks will have to support access to local LoST servers for devices that are connected to cellular networks and are ecrit compliant. > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls This is covered in the standards. None of the processes are dependent on authentication, although where it is possible, it's desirable so as to minimize fraudulent emergency calls Mechanisms for specific network authentication mechanisms are out of scope, and, like SIP basic calling, are not usually mentioned in IETF documents. Stephen, we've tried pretty hard to make sure this works for 3G/4G mobile networks. It's true that it doesn't do it the way 3GPP currently thinks it ought to work, but we claim they haven't thought through all the issues. While it would work, there are opportunities for improvement. We would be willing to do that if we could get the cooperation of 3GPP, which we have tried, and failed, to do. So, I think the documents do not need any qualification statements. Brian > Martin > > The 3GPP/3GPP2 solution has a defined restricted applicability (mainly to > 3GPP/3GPP2 access networks where the serving network also acts as the VSP) > and the specifications for it cover in detail all possible scenarios > consistent with these restrictions so far as we are aware. > > The Ecrit solution seems to claim global applicability to all types of IP > access (and the more that is said about this from Ecrit participants the > more this gets emphasized) but does not cover in detail all possible > scenarios (in some cases does not cover in any detail) which means that at > best the solution is incomplete and at worst intrinsically inapplicable to > some unstated set of scenarios. > > The missing, incomplete and problematic cases include the following: > > - access to PSTN capable PSAPs > - handover between different IP access networks including different > types of access network > - handover to/from circuit mode networks > - location for cellular access (and the requirement to support LCPs that > will be useless for cellular access) > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls > > Stating that some of these cases are out of scope or referencing an > incomplete and possibly questionable specification from some other > national SDO will not help the user who encounters such problems. But it > would certainly help network operators and implementers to acknowledge > their existence in one form or another because that would allow better > planning of deployments and would help focus attention on finding > solutions (whether in IETF or elsewhere) for the missing cases. > > Please note that despite these drawbacks, I will acknowledge that Ecrit > does have a valuable solution that covers many scenarios not covered by > 3GPP/3GPP2. It would be the delineation of these supported scenarios (or > equivalently unsupported scenarios) in some applicability statement that > would be particularly useful right now. > > Kind Regards > > Stephen > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Thursday, February 26, 2009 9:45 PM > To: Edge, Stephen; Richard Barnes > Cc: ECRIT > Subject: RE: [Ecrit] Comments on Framework Draft > > There's benefit in knowing the limitations of a framework, and every > architecture makes certain assumptions. Let's examine them though... > > The IETF might occasionally make the assumption that the standards it > develops are for Internet devices. That assumption probably need not be > stated explicitly. > > The ECRIT architecture relies on implementations of the protocols that it > references. That is not extraordinary. A reliance on implementation of > these protocols by endpoints, routing intermediaries and PSAPs should not > need to be explained. > > So the assumptions are: > - the Internet > - solutions are implemented and deployed > - the end device is a key component > > Only that last element is particularly novel ... or not that much really. > It's a design choice. Unless you were thinking of trunking the voice > elsewhere. > > Of course, you're suggesting that the design choice was made in ignorance > of all the constraints. You're suggesting that - as a result - the choice > is flawed and the solution is not going to work for cellular services. We > disagree. The solution is a basis for emergency calling in _any_ IP > network. > > Cheers, > Martin > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Edge, Stephen >> Sent: Friday, 27 February 2009 3:30 PM >> To: Richard Barnes >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Richard >> >> Thanks for the comments. Your statement below that "SIP emergency >> calling works if all parties behave as specified in these (IETF Ecrit) >> documents" to some degree highlights the problems we are raising. The >> documents do contain a number of implicit and explicit restrictions - >> like IP capable PSAPs, global IP access (no islands of circuit mode >> access for example), universal support of this solution by all access >> providers and VSPs (not much good if some opt for another solution) and >> end system oriented location and routing capability - which together >> make them unsuitable (we believe) for cellular wireless networks. If >> these restrictions and assumptions were all made explicit upfront, it >> would to a large degree (and possibly completely) address our concerns. >> >> You are right in assuming another set of specifications for the 3GPP >> and 3GPP2 solution. The applicability of this solution is explicitly >> defined in TS 23.167 (or more exactly in an already agreed CR in >> contribution S2-090752 which will become part of 23.167 in a few more >> weeks) to cover the following access types: GPRS (UTRAN WCDMA), I-WLAN, >> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN >> (LTE). So there is a restriction and arbitrary internet access is not >> covered (yet) as I have stated before. >> >> Kind Regards >> >> Stephen >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Wednesday, February 25, 2009 6:30 PM >> To: Edge, Stephen >> Cc: Brian Rosen; 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Stephen, >> >> I'm a little confused by the scope of what you're asking. The >> framework >> and phonebcp documents exist in order to describe the ECRIT solution: >> They say, in effect, "SIP emergency calling works if all parties behave >> as specified in these documents." >> >> As I understand what you're saying (and I'm by no means an expert in >> 3GPP), 3GPP specifies that one or more elements of this system behave >> differently. This simply means that 3GPP networks aren't complying >> with >> these specs. Just like there's no disclaimer in RFC 791 (IPv4) that >> says "this doesn't work on X.25 networks", it's not clear to me that an >> analogous disclaimer is called for here. >> >> I presume there are similar documents describing how emergency calling >> works in 3GPP networks. Do they include notes saying that the 3GPP >> solution doesn't work in the broader Internet? >> >> --Richard >> >> >> >> >> >> Edge, Stephen wrote: >> > Brian >> > >> > First of all apologies for the likely lateness of this reply - I >> actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest but >> it seems unlikely that my VPN, Outlook server and WiFi access >> capability will cooperate together to get it sent until I return to the >> office mid-next week. >> > >> > Anyhow thanks for your comments. There have actually been a number of >> conference calls between IETF and 3GPP participants over the last >> couple of years at which common features like support of IP emergency >> calls were discussed and these could have been good forum for >> participants on either side to have raised the kinds of issues you >> elaborate on below. Given that seems not so far to have happened, it >> could still be possible in future such calls. >> > >> > But the issues we are raising are not directly to do with further >> aligning the 2 solutions or with the lack of this in the past. We are >> simply pointing out that the solutions are currently different and that >> from a cellular wireless perspective, the Ecrit solution is not seen as >> suitable in all respects (for support of IP emergency calls originating >> from such access types). That is not just our point of view. 3GPP2 sent >> a liaison to Ecrit some months ago pointing out the same issues. >> > >> > So we are proposing that the Ecrit framework and phoneBCP spec.s >> include a statement acknowledging this - e.g. by referencing the >> alternative 3GPP/3GPP2 solution and indicating the IP access types for >> which the Ecrit solution will work without limitation (or equivalently >> the access types where limitations are not ruled out). >> > >> > We are not proposing further modification and extension of the Ecrit >> solution - just pointing out that this would be needed (as with the >> 3GPP/3GPP2 solution) to fully cover all types of access. >> > >> > Kind Regards >> > >> > Stephen >> > -----Original Message----- >> > From: Brian Rosen [mailto:br@brianrosen.net] >> > Sent: Wednesday, February 18, 2009 8:07 PM >> > To: Edge, Stephen; 'ECRIT' >> > Subject: RE: [Ecrit] Comments on Framework Draft >> > >> > I have bit my tongue on this one for a long time. >> > >> > Stephen, with respect, please go talk to 3GPP management and ask them >> why >> > there has been no participation in the ecrit effort despite multiple >> YEARS >> > of begging them to get involved. To put it frankly, 3GPP is quite >> willing >> > to bully IETF into doing its work on its schedule, but cannot be >> bothered to >> > get work done it knows it will eventually have to do when the IETF >> asks it >> > to do so. >> > >> > 3GPP understands the mess that is being created by not participating. >> They >> > know full well that when they finally get around to dealing with PS >> > terminated emergency calls, that there will be a lot of resistance to >> > changing fully specified and implemented standards to more closely >> align >> > with 3GPP standards. I expect you will have several interworking >> functions >> > to define and build. >> > >> > So, politely, please go away, we're finishing work we dearly wanted >> you all >> > to be involved with for years, but you refused to do anything. It's >> too >> > late for this rev. >> > >> > Now, having said that, there are quite a few people who have >> participated in >> > the IETF work who are IMS aware and I believe that despite your >> fears, >> > everything you need is in the specs. The mechanisms we have defined >> provide >> > the ability for the network to insert location, recognize and mark >> emergency >> > calls, and route on behalf of endpoints. An E-CSCF could quite >> > straightforwardly provide a SIP call towards an ecrit compatible >> PSAP. The >> > only not-quite-nice interwork would be from SUPL to HELD (or SIP), >> but it's >> > pretty easy to do that. I'll also note that we have tried to get OMA >> and >> > IETF to cooperate on location protocols, but we have been >> spectacularly >> > unsuccessful at that effort also. >> > >> > Brian >> > >> > >> > >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf >> >> Of Edge, Stephen >> >> Sent: Thursday, February 05, 2009 2:50 AM >> >> To: 'ECRIT' >> >> Subject: [Ecrit] Comments on Framework Draft >> >> >> >> All >> >> >> >> draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative >> >> description of how terminals and networks should support emergency >> >> calls made over IP capable facilities to IP capable PSAPs. It >> appears >> >> intended to cover all types of access network - including fixed >> line, >> >> WiFi and cellular (e.g. examples involving each can be found >> throughout >> >> the draft). >> >> >> >> When we evaluated this with respect to support of wireless cellular >> >> access and WiFi access associated with a cellular operator (e.g. >> WLAN >> >> or Femto cells integrated into a cellular network), we found that >> >> certain portions of the draft exhibited one or more of the following >> >> characteristics: >> >> >> >> (A) Inconsistent with already standardized wireless solutions >> >> >> >> (B) Inconsistent with essential wireless requirements and >> >> conventions >> >> >> >> (C) Already part of wireless standards or potentially part of >> >> future standards >> >> >> >> (A) refers to all portions of the draft framework that differ from >> the >> >> requirements and procedures currently standardized for wireless >> >> emergency access by 3GPP, 3GPP2 and OMA. This is a plain difference >> of >> >> solution and could be resolved through support of both solutions by >> >> terminals (with each solution being used according to the type of >> >> access network and VSP) or could be resolved by supporting only one >> >> solution and accessing only the types of network supporting that >> >> solution. To acknowledge this category, the framework document could >> >> reference the applicable wireless standards and point out that these >> >> are valid alternatives for wireless cellular based access. >> >> >> >> (B) refers to portions of the draft that would be unsuitable for >> >> wireless networks even if no alternative solution existed together >> with >> >> other portions missing from the draft that would be needed to fully >> >> support wireless networks. Examples of the former include: (a) >> emphasis >> >> on endpoint derivation of location, performance of Lost query and >> >> receipt of local dial strings; (b) restriction of LCPs to protocols >> >> that require terminal initiation (not allowing for network >> initiation >> >> as far as we can tell) and that include two LCPs (DHCP and LLDP) >> that >> >> are not applicable to (not defined for) cellular access; and (c) the >> >> requirement that a terminal or at least a LIS will update the PSAP >> >> whenever location changes. (a) is impractical due to network and >> >> terminal loading consequences and failure to support non-IP capable >> >> PSAPs; (b) makes location verification and updated location >> provision >> >> to PSAPs difficult or impossible; while (c) is also incompatible >> with >> >> support of existing non-IP capable PSAPs besides increasing terminal >> >> load and possibly interfering with optimum maintenance of the RF >> >> connection (e.g. if a terminal has to tune away from the serving >> base >> >> station or WLAN periodically to make location measurements). >> Examples >> >> of the latter include (d) absence of support for access to non-IP >> >> capable PSAPs as already mentioned (e.g. to support E911 phase 2 in >> the >> >> US); (e) no support for handover from the IP to the circuit domain >> when >> >> a terminal loses (e.g. moves out of) RF coverage in the IP domain; >> and >> >> (f) no allowance for limited access modes wherein a terminal may >> access >> >> a network only to place an emergency call with ensuing restrictions >> on >> >> (for example) location acquisition, PSAP callback and caller >> >> verification and identification to the PSAP. To resolve this >> category >> >> either significant changes to the framework document could be made >> or a >> >> disclaimer/applicability statement could be added stating that >> support >> >> of cellular wireless networks and their associated WLAN and Femto >> >> access points is not covered. >> >> >> >> Category (C) comprises concepts and capabilities in the draft that >> are >> >> either already part of the standardized solution for wireless >> networks >> >> or that might be added at a later time. Examples of the former >> include >> >> LoST, SIP location conveyance, general use of SIP, location for >> routing >> >> versus for dispatch, cellular positioning methods. Examples of the >> >> latter include use of location references and dereferencing and >> >> possible interworking between the current wireless network solutions >> >> (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. >> The >> >> presence of this category could be acknowledged by following the >> >> disclaimer for (B) with a statement that certain portions of the >> >> solution are expected to be incorporated into wireless networks now >> >> and/or in the future. >> >> >> >> We hope that these comments will be seen to be a useful addition to >> >> this review in the sense of enabling a more precise scoping for the >> >> framework document and we are willing to assist in providing wording >> >> for any disclaimer/applicability statement that the Ecrit working >> group >> >> may now deem fit to include. >> >> >> >> Kind Regards >> >> >> >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs >> (Qualcomm >> >> 3GPP2 TSG-X and TSG-C participant) >> >> >> >> PS this being sent on 2/4/09 at 11:50pm PST >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www.ietf.org/mailman/listinfo/ecrit >> > >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------ ------------------------ > 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://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.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] From hgs@cs.columbia.edu Tue Mar 10 14:31:55 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8650C3A685F for ; Tue, 10 Mar 2009 14:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpEnDxN-E9IK for ; Tue, 10 Mar 2009 14:31:54 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 816D33A6850 for ; Tue, 10 Mar 2009 14:31:54 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2ALWSNO019748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 10 Mar 2009 17:32:29 -0400 (EDT) Message-Id: <26D15A10-533F-4837-808E-105522B9517F@cs.columbia.edu> From: Henning Schulzrinne To: ECRIT Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 10 Mar 2009 17:32:28 -0400 X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Subject: [Ecrit] Premature disconnect: UI and call stages X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 21:31:55 -0000 A few of the interested parties had a beer-less phone bar discussion on the requirements for preventing premature disconnects. Among others, two issues came up: (1) We need to keep in mind that there are at least three types of UAs: (black phone) Analog phone, either with a hook switch or something like a cordless phone, connected via an ATA. The only user interface capabilities are ringing and possibly caller-ID injection. (dumb Etherphone) SIP phone, with no display and a hook switch (smartphone) soft phone, smart phone, Ethernet phone with GUI The mechanism should work for all of these, but some devices allow for different, more sophisticated, user interactions. For example, devices with a GUI can prevent interruption of the audio path by appropriate user confirmation. That is clearly not possible if the receiver is placed on-hook on an old electromechanical phone, as the audio path is interrupted by a mechanical switch. (2) There seem to be two separable goals: (ADP) Accidental disconnect prevention: Make it difficult for the user to accidentally disconnect before the call is over. Premature disconnect could happen either by inadvertent action (press End button by accident) or by putting the phone back into the cradle, while the call taker wants to continue the conversation. The second case is more of a potential misunderstanding, rather than a UI accident, but that distinction may not matter. Some or all emergency calls would have this feature, indicated on a call-by-call basis. (DC) Disconnect control: Allow the call taker to manage the disconnect process *at the instant the caller disconnect attempt occurs*. At that time, the call taker decides whether to let the disconnect proceed and terminate the call or ask the user to continue/resume the call, via some alerting mechanism. In that case, the user indicates the desire to disconnect to the call taker, which the call taker can agree to or not. The current requirement document states (ADP) as the fundamental requirement (which I think we all agree on), but also implies (DC). Separately, we also seem to agree that the call taker needs to be able to call back the user on the same device, but that's a separate problem. We agree, I believe, that the caller should be able to express the choice not to continue the conversation, e.g., by ignoring the alerting or by confirming the disconnect. We also agree that "open microphones", i.e., the ability to silently listen in on the caller is not something we want. If we have (ADP), but not (DC), we would satisfy the core requirement of preventing premature disconnect, as the UI mechanism for indicating "do not hang up yet" or "do you really want to hang up" is presumably similar. However, as Brian pointed out, you could get the situation that the call taker is accepts that the user hangs up and has no desire to continue the conversation. In that case, the phone would presumably produce a spurious alert and/or require an unnecessary user disconnect confirmation. Clearly, ADP requires no disconnect-time signaling; DC does. Henning From hardie@qualcomm.com Tue Mar 10 14:59:15 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1663A6844 for ; Tue, 10 Mar 2009 14:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.509 X-Spam-Level: X-Spam-Status: No, score=-105.509 tagged_above=-999 required=5 tests=[AWL=1.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtdJiWxOymwh for ; Tue, 10 Mar 2009 14:59:14 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 43E803A6847 for ; Tue, 10 Mar 2009 14:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1236722390; x=1268258390; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<26D15A10-533F-4837-808E -105522B9517F@cs.columbia.edu>|References:=20<26D15A10-53 3F-4837-808E-105522B9517F@cs.columbia.edu>|Date:=20Tue, =2010=20Mar=202009=2014:59:46=20-0700|To:=20Henning=20Sch ulzrinne=20,=20ECRIT=20|From:=20Ted=20Hardie=20|Subject: =20Re:=20[Ecrit]=20Premature=20disconnect:=20UI=20and=20c all=20stages|Content-Type:=20text/plain=3B=20charset=3D"u s-ascii"|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,554 9"=3B=20a=3D"16152910"; bh=7GAkmsxDfR8V9NceQ5r74z/kjZq0hezGM9OrPbH8OsU=; b=SSUF1+HsTAEBCQIEd1//mFLc2+BUHmmWidTko9/pQGpNgfWgmn+KXCso zVg2nTGSvKtzV2l/mtorF6H2gduuIZdyh3VfaVQkDPmqq0IvwL8hf9Tvy 9gTTi8kZdkz3us783wrbBbkb1hT6Vbik/uQW07wMSHIJ8QpAdvVsz+bfs Y=; X-IronPort-AV: E=McAfee;i="5300,2777,5549"; a="16152910" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Mar 2009 14:59:49 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2ALxn84015912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Mar 2009 14:59:49 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2ALxm8w015744 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 10 Mar 2009 14:59:49 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 10 Mar 2009 14:59:48 -0700 Received: from [10.227.68.110] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 10 Mar 2009 14:59:48 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <26D15A10-533F-4837-808E-105522B9517F@cs.columbia.edu> References: <26D15A10-533F-4837-808E-105522B9517F@cs.columbia.edu> Date: Tue, 10 Mar 2009 14:59:46 -0700 To: Henning Schulzrinne , ECRIT From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Subject: Re: [Ecrit] Premature disconnect: UI and call stages X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 21:59:15 -0000 Henning, Thanks for this very detailed summary of the call; since I got a day job interrupt that prevented me from attending, I really appreciate it. I have a couple of clarification questions, below. At 2:32 PM -0700 3/10/09, Henning Schulzrinne wrote: >A few of the interested parties had a beer-less phone bar discussion >on the requirements for preventing premature disconnects. Among >others, two issues came up: > >(1) We need to keep in mind that there are at least three types of UAs: > >(black phone) Analog phone, either with a hook switch or something >like a cordless phone, connected via an ATA. The only user interface >capabilities are ringing and possibly caller-ID injection. > >(dumb Etherphone) SIP phone, with no display and a hook switch > >(smartphone) soft phone, smart phone, Ethernet phone with GUI I believe that there is an underlying question here about whether the mechanisms being described will only be used for user-agents where voice is the primary mode of communication. Will there be an equivalent need for devices using real-time text or other session-based modes that are not voice based? Do these collapse to "smartphone" or are they potentially a different class of "dumb Etherphone"? >The mechanism should work for all of these, but some devices allow for >different, more sophisticated, user interactions. For example, devices >with a GUI can prevent interruption of the audio path by appropriate >user confirmation. That is clearly not possible if the receiver is >placed on-hook on an old electromechanical phone, as the audio path is >interrupted by a mechanical switch. > >(2) There seem to be two separable goals: > >(ADP) Accidental disconnect prevention: Make it difficult for the user >to accidentally disconnect before the call is over. Premature >disconnect could happen either by inadvertent action (press End button >by accident) or by putting the phone back into the cradle, while the >call taker wants to continue the conversation. The second case is more >of a potential misunderstanding, rather than a UI accident, but that >distinction may not matter. > >Some or all emergency calls would have this feature, indicated on a >call-by-call basis. Just to be clear, I do not think that lumping these in Accidental is really much better than calling it all "Premature". There is a class that really is fully accidental (inadvertant action, according to the paragraph above). The other, "potential misunderstanding" seems to shade into some party making a value judgement about when the call should end. I'd suggest keeping "Accidental" for just the inadvertent case. If I am missing some aspect of the conversation, of course, please let me know. >(DC) Disconnect control: Allow the call taker to manage the disconnect >process *at the instant the caller disconnect attempt occurs*. At that >time, the call taker decides whether to let the disconnect proceed and >terminate the call or ask the user to continue/resume the call, via >some alerting mechanism. In that case, the user indicates the desire >to disconnect to the call taker, which the call taker can agree to or >not. > >The current requirement document states (ADP) as the fundamental >requirement (which I think we all agree on), but also implies (DC). Did the folks on the call generally agree or disagree with DC as a requirement? It is a little hard to tell from what follows (you have users "express the choice" which doesn't quite mean "retain control"). My position on this point remains that the user must volunteer to let the call taker take this level of control and that any opt-in mechanism is fundamentally fine by me. Without user opt-in, I remain concerned about a system in which that the user "indicates the desire to disconnect/ with the call taker agreeing or not agreeing". >Separately, we also seem to agree that the call taker needs to be able >to call back the user on the same device, but that's a separate problem. > >We agree, I believe, that the caller should be able to express the >choice not to continue the conversation, e.g., by ignoring the >alerting or by confirming the disconnect. We also agree that "open >microphones", i.e., the ability to silently listen in on the caller is >not something we want. I hadn't realized that anyone was currently requesting this. I also don't want this, and I'm relieved to find it didn't have support on the call. >If we have (ADP), but not (DC), we would satisfy the core requirement >of preventing premature disconnect, as the UI mechanism for indicating >"do not hang up yet" or "do you really want to hang up" is presumably >similar. However, as Brian pointed out, you could get the situation >that the call taker is accepts that the user hangs up and has no >desire to continue the conversation. In that case, the phone would >presumably produce a spurious alert and/or require an unnecessary user >disconnect confirmation. > >Clearly, ADP requires no disconnect-time signaling; DC does. This seems to imply that ADP works the same way (that is, it has the same confirmation) no matter what the PSAP does. The PSAP wouldn't even see the attempt to hang up until the confirmation occurred. Is that your understanding? Thanks again for the quick udpate, Ted > >Henning >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From hgs@cs.columbia.edu Tue Mar 10 15:32:30 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A0703A6844 for ; Tue, 10 Mar 2009 15:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.742 X-Spam-Level: X-Spam-Status: No, score=-5.742 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2i+3HG6b0I51 for ; Tue, 10 Mar 2009 15:32:29 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id 730463A67F0 for ; Tue, 10 Mar 2009 15:32:29 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2AMX35d004061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 10 Mar 2009 18:33:03 -0400 (EDT) Message-Id: <8308AA10-5651-4AB6-BE04-F10DE3D3CD64@cs.columbia.edu> From: Henning Schulzrinne To: Ted Hardie In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 10 Mar 2009 18:33:03 -0400 References: <26D15A10-533F-4837-808E-105522B9517F@cs.columbia.edu> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.5 Cc: ECRIT Subject: Re: [Ecrit] Premature disconnect: UI and call stages X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 22:32:30 -0000 On Mar 10, 2009, at 5:59 PM, Ted Hardie wrote: > Henning, > > Thanks for this very detailed summary of the call; since I got a day > job Just to avoid misunderstandings: We discussed other issues and I'm not claiming to capture everybody's opinion or input. > > I believe that there is an underlying question here about whether > the mechanisms being described will only be used for user-agents > where voice is the primary mode of communication. Will there be an > equivalent need for devices using real-time text or other > session-based modes that are not voice based? Do these collapse > to "smartphone" or are they potentially a different class of > "dumb Etherphone"? Good question. I think the discussion focused on voice, but I suspect the issues are not altogether dissimilar for real-time text or video- for-signing, for example. I think you raise an important issue that the requirements document should note. >> > > Just to be clear, I do not think that lumping these in Accidental is > really much > better than calling it all "Premature". There is a class that > really is fully > accidental (inadvertant action, according to the paragraph above). > The other, "potential misunderstanding" seems to shade into some > party making a value judgement about when the call should end. > I'd suggest keeping "Accidental" for just the inadvertent case. If I > am missing some aspect of the conversation, of course, please let me > know. This distinction only occurred to me while writing the note. I didn't mean to make a strong distinction between accidental and premature, but I think the "fat finger" and "misunderstanding" part may make a difference in terms of user behavior and expectations. In the case of fat finger, the user may not have realized that anything is amiss. > > >> (DC) Disconnect control: Allow the call taker to manage the >> disconnect >> process *at the instant the caller disconnect attempt occurs*. At >> that >> time, the call taker decides whether to let the disconnect proceed >> and >> terminate the call or ask the user to continue/resume the call, via >> some alerting mechanism. In that case, the user indicates the desire >> to disconnect to the call taker, which the call taker can agree to or >> not. >> >> The current requirement document states (ADP) as the fundamental >> requirement (which I think we all agree on), but also implies (DC). > > Did the folks on the call generally agree or disagree with DC as a > requirement? It is a little hard to tell from what follows (you > have users > "express the choice" which doesn't quite mean "retain control"). That's one of the points we probably did not agree on. I hope I'm not misrepresenting Brian when I say that he considers it a MUST have, while I and maybe others consider it as something worth investigating, but not a hard requirement. > > > My position on this point remains that the user must volunteer to > let the call taker take this level of control and that any opt-in > mechanism > is fundamentally fine by me. Without user opt-in, I remain concerned > about a system in which that the user "indicates the desire to > disconnect/ > with the call taker agreeing or not agreeing". We didn't discuss opt-in vs. opt-out. Part of this relates to another issue, namely what happens during the time that the call taker requests the call to continue: (1) it just alerts, and the user can shut off the alert, but no other functions of the phone are affected. (2) It changes the ability of the phone to place other calls, for example. (3) The speaker/headset would continue to be connected to the call taker. (4) It keeps the line open, i.e., the microphone continue to operate. We agreed that open microphones are bad, so the user would always disconnect the microphone when indicating "I want to disconnect", until he picks up again. I think it would also be helpful for the document to acknowledge this issue. My perception is that we're talking (1) and (2), but not (3) and (4). It's not clear to me whether by opt-in you mean a general user configuration ("my phone doesn't play by these rules") or a per-call opt-in. > > > >> If we have (ADP), but not (DC), we would satisfy the core requirement >> of preventing premature disconnect, as the UI mechanism for >> indicating >> "do not hang up yet" or "do you really want to hang up" is presumably >> similar. However, as Brian pointed out, you could get the situation >> that the call taker is accepts that the user hangs up and has no >> desire to continue the conversation. In that case, the phone would >> presumably produce a spurious alert and/or require an unnecessary >> user >> disconnect confirmation. >> >> Clearly, ADP requires no disconnect-time signaling; DC does. > > This seems to imply that ADP works the same way (that is, it has > the same confirmation) no matter what the PSAP does. The PSAP > wouldn't even see the attempt to hang up until the confirmation > occurred. Is that your understanding? Correct. At the danger of further muddying the waters, there is also the possibility to combine ADP with a plain indication of UI actions, in the spirit of KPML or RFC 2833bis, which simply tells the call taker side what's happening ("hook flash"), but has no direct influence on call state. > > > Thanks again for the quick udpate, > > Ted > From br@brianrosen.net Tue Mar 10 15:36:59 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A9343A6924 for ; Tue, 10 Mar 2009 15:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vijtiyjxfqt4 for ; Tue, 10 Mar 2009 15:36:57 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 0AA463A6844 for ; Tue, 10 Mar 2009 15:36:54 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LhAZY-0000Ra-Oi; Tue, 10 Mar 2009 17:37:17 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Henning Schulzrinne'" , "'ECRIT'" References: <26D15A10-533F-4837-808E-105522B9517F@cs.columbia.edu> In-Reply-To: Date: Tue, 10 Mar 2009 18:37:29 -0400 Message-ID: <035901c9a1d0$ccf72bf0$66e583d0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acmhy4UV2xUHvfCcQRyH+aFZVcsUKQAAYXcw Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Premature disconnect: UI and call stages X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 22:36:59 -0000 I think the mechanisms apply equally to text and video devices, and expect there are a range of UIs for such devices. They tend to have software, and thus look more like the third class. Could be exceptions, like a TTY into an ATA. I think we did not agree on DC. I think Henning is mischaracterizing what some of us are asking for. It's not disconnect control explicitly. It's allowing the PSAP call taker to: 1. Understand what is happening (that is, know that the caller is trying to hang up) 2. Make a judgment that it's inappropriate to do so 3. Be able to cause an alert when the call taker believes it's appropriate to do so 4. Provide the ability of the caller to either undo what he tried to do, or override and really terminate the call The call taker can always terminate. We are advocating substituting the judgment of the call taker for the initial judgment of the caller, but providing an override for the caller to terminate. That is substantively different from opt-in. The whole point of this is that callers make many more mistakes than call takers do in these situations, and allowing the call taker to invoke alerting, as well as providing some way for the call to resume if the caller responds is the most appropriate behavior. Call takers need information; automatic things happening that the call taker doesn't understand is bad. The call taker wants to know what the user is doing (hanging up the phone, picking the phone back up, ...). Alerting is selective: first you decide if termination is appropriate If it's not, you make a judgment of whether alerting is appropriate. Then you watch and see what the user is doing. I clearly wasn't thinking straight on the call when Henning was describing his "UI-only" concept. He wants the device to alert by itself if disconnect is attempted on the caller side and resume the call if the caller picks back up. The problem I pointed out was that there is significant time between the user (attempting to) hang up and the time the call taker decides if it's appropriate to do, and if it is, disconnect from the PSAP side. During that time, the phone would be (inappropriately) alerting. What I didn't realize is it's much worse than that. If the phone just alerts, then the PSAP doesn't know the user is attempting to disconnect; she just hears silence (SIP phones shouldn't ringback, that's a local function). You have to signal the disconnect attempt to get the call taker to make the judgment call whether it's appropriate or not. Then the call taker signals the alert, if that's appropriate, and if the user attempts to resume, then that needs to be signaled. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Ted Hardie Sent: Tuesday, March 10, 2009 6:00 PM To: Henning Schulzrinne; ECRIT Subject: Re: [Ecrit] Premature disconnect: UI and call stages Henning, Thanks for this very detailed summary of the call; since I got a day job interrupt that prevented me from attending, I really appreciate it. I have a couple of clarification questions, below. At 2:32 PM -0700 3/10/09, Henning Schulzrinne wrote: >A few of the interested parties had a beer-less phone bar discussion >on the requirements for preventing premature disconnects. Among >others, two issues came up: > >(1) We need to keep in mind that there are at least three types of UAs: > >(black phone) Analog phone, either with a hook switch or something >like a cordless phone, connected via an ATA. The only user interface >capabilities are ringing and possibly caller-ID injection. > >(dumb Etherphone) SIP phone, with no display and a hook switch > >(smartphone) soft phone, smart phone, Ethernet phone with GUI I believe that there is an underlying question here about whether the mechanisms being described will only be used for user-agents where voice is the primary mode of communication. Will there be an equivalent need for devices using real-time text or other session-based modes that are not voice based? Do these collapse to "smartphone" or are they potentially a different class of "dumb Etherphone"? >The mechanism should work for all of these, but some devices allow for >different, more sophisticated, user interactions. For example, devices >with a GUI can prevent interruption of the audio path by appropriate >user confirmation. That is clearly not possible if the receiver is >placed on-hook on an old electromechanical phone, as the audio path is >interrupted by a mechanical switch. > >(2) There seem to be two separable goals: > >(ADP) Accidental disconnect prevention: Make it difficult for the user >to accidentally disconnect before the call is over. Premature >disconnect could happen either by inadvertent action (press End button >by accident) or by putting the phone back into the cradle, while the >call taker wants to continue the conversation. The second case is more >of a potential misunderstanding, rather than a UI accident, but that >distinction may not matter. > >Some or all emergency calls would have this feature, indicated on a >call-by-call basis. Just to be clear, I do not think that lumping these in Accidental is really much better than calling it all "Premature". There is a class that really is fully accidental (inadvertant action, according to the paragraph above). The other, "potential misunderstanding" seems to shade into some party making a value judgement about when the call should end. I'd suggest keeping "Accidental" for just the inadvertent case. If I am missing some aspect of the conversation, of course, please let me know. >(DC) Disconnect control: Allow the call taker to manage the disconnect >process *at the instant the caller disconnect attempt occurs*. At that >time, the call taker decides whether to let the disconnect proceed and >terminate the call or ask the user to continue/resume the call, via >some alerting mechanism. In that case, the user indicates the desire >to disconnect to the call taker, which the call taker can agree to or >not. > >The current requirement document states (ADP) as the fundamental >requirement (which I think we all agree on), but also implies (DC). Did the folks on the call generally agree or disagree with DC as a requirement? It is a little hard to tell from what follows (you have users "express the choice" which doesn't quite mean "retain control"). My position on this point remains that the user must volunteer to let the call taker take this level of control and that any opt-in mechanism is fundamentally fine by me. Without user opt-in, I remain concerned about a system in which that the user "indicates the desire to disconnect/ with the call taker agreeing or not agreeing". >Separately, we also seem to agree that the call taker needs to be able >to call back the user on the same device, but that's a separate problem. > >We agree, I believe, that the caller should be able to express the >choice not to continue the conversation, e.g., by ignoring the >alerting or by confirming the disconnect. We also agree that "open >microphones", i.e., the ability to silently listen in on the caller is >not something we want. I hadn't realized that anyone was currently requesting this. I also don't want this, and I'm relieved to find it didn't have support on the call. >If we have (ADP), but not (DC), we would satisfy the core requirement >of preventing premature disconnect, as the UI mechanism for indicating >"do not hang up yet" or "do you really want to hang up" is presumably >similar. However, as Brian pointed out, you could get the situation >that the call taker is accepts that the user hangs up and has no >desire to continue the conversation. In that case, the phone would >presumably produce a spurious alert and/or require an unnecessary user >disconnect confirmation. > >Clearly, ADP requires no disconnect-time signaling; DC does. This seems to imply that ADP works the same way (that is, it has the same confirmation) no matter what the PSAP does. The PSAP wouldn't even see the attempt to hang up until the confirmation occurred. Is that your understanding? Thanks again for the quick udpate, Ted > >Henning >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From g.caron@bell.ca Tue Mar 10 18:47:08 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7F7928C0FB for ; Tue, 10 Mar 2009 18:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfBvBQ7a1Usb for ; Tue, 10 Mar 2009 18:47:07 -0700 (PDT) Received: from mail150.messagelabs.com (mail150.messagelabs.com [85.158.136.115]) by core3.amsl.com (Postfix) with ESMTP id C5B0628C0DC for ; Tue, 10 Mar 2009 18:47:06 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-4.tower-150.messagelabs.com!1236736058!20177036!4 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [206.47.0.177] Received: (qmail 6314 invoked from network); 11 Mar 2009 01:47:40 -0000 Received: from bellnexxia.net (HELO TLS.Exchange.Bell.ca) (206.47.0.177) by server-4.tower-150.messagelabs.com with RC4-SHA encrypted SMTP; 11 Mar 2009 01:47:40 -0000 Received: from hub01-wyn.bell.corp.bce.ca (142.182.199.48) by dm1c8e.exchange3.bell.ca (198.235.102.108) with Microsoft SMTP Server id 8.1.340.0; Tue, 10 Mar 2009 21:47:36 -0400 Received: from MBX02.bell.corp.bce.ca ([142.182.199.11]) by hub01-wyn.bell.corp.bce.ca ([142.182.199.48]) with mapi; Tue, 10 Mar 2009 21:46:38 -0400 From: To: , , , Date: Tue, 10 Mar 2009 21:46:37 -0400 Thread-Topic: [Ecrit] Premature disconnect: UI and call stages Thread-Index: Acmhy4UV2xUHvfCcQRyH+aFZVcsUKQAAYXcwAAY58jA= Message-ID: <0FEAC1C09868B34A982F4FB40254B37C267D31BB46@MBX02.bell.corp.bce.ca> References: <26D15A10-533F-4837-808E-105522B9517F@cs.columbia.edu> <035901c9a1d0$ccf72bf0$66e583d0$@net> In-Reply-To: <035901c9a1d0$ccf72bf0$66e583d0$@net> Accept-Language: en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] Premature disconnect: UI and call stages X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 01:47:08 -0000 "What I didn't realize is it's much worse than that. If the phone just ale= rts, then the PSAP doesn't know the user is attempting to disconnect; she j= ust hears silence (SIP phones shouldn't ringback, that's a local function).= " I was going to point this out on the call but we've timed out. It seems to = me that UI-only alerting could potentially cause confusion at both ends. Th= e call taker should have the ability to cause alerting based on his assessm= ent of the situation as Brian pointed out. Guy -----Message d'origine----- De : ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] De la part de B= rian Rosen Envoy=E9 : 10 mars 2009 18:37 =C0 : 'Ted Hardie'; 'Henning Schulzrinne'; 'ECRIT' Objet : Re: [Ecrit] Premature disconnect: UI and call stages I think the mechanisms apply equally to text and video devices, and expect there are a range of UIs for such devices. They tend to have software, and thus look more like the third class. Could be exceptions, like a TTY into an ATA. I think we did not agree on DC. I think Henning is mischaracterizing what some of us are asking for. It's not disconnect control explicitly. It's allowing the PSAP call taker to: 1. Understand what is happening (that is, know that the caller is trying to hang up) 2. Make a judgment that it's inappropriate to do so 3. Be able to cause an alert when the call taker believes it's appropriate to do so 4. Provide the ability of the caller to either undo what he tried to do, or override and really terminate the call The call taker can always terminate. We are advocating substituting the judgment of the call taker for the initial judgment of the caller, but providing an override for the caller to terminate. That is substantively different from opt-in. The whole point o= f this is that callers make many more mistakes than call takers do in these situations, and allowing the call taker to invoke alerting, as well as providing some way for the call to resume if the caller responds is the mos= t appropriate behavior. Call takers need information; automatic things happening that the call take= r doesn't understand is bad. The call taker wants to know what the user is doing (hanging up the phone, picking the phone back up, ...). Alerting is selective: first you decide if termination is appropriate If it's not, you make a judgment of whether alerting is appropriate. Then you watch and see what the user is doing. I clearly wasn't thinking straight on the call when Henning was describing his "UI-only" concept. He wants the device to alert by itself if disconnec= t is attempted on the caller side and resume the call if the caller picks bac= k up. The problem I pointed out was that there is significant time between the user (attempting to) hang up and the time the call taker decides if it'= s appropriate to do, and if it is, disconnect from the PSAP side. During tha= t time, the phone would be (inappropriately) alerting. What I didn't realize is it's much worse than that. If the phone just alerts, then the PSAP doesn't know the user is attempting to disconnect; she just hears silence (SIP phones shouldn't ringback, that's a local function). You have to signal the disconnect attempt to get the call taker to make the judgment call whether it's appropriate or not. Then the call taker signals the alert, if that's appropriate, and if the user attempts to resume, then that needs to be signaled. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Ted Hardie Sent: Tuesday, March 10, 2009 6:00 PM To: Henning Schulzrinne; ECRIT Subject: Re: [Ecrit] Premature disconnect: UI and call stages Henning, Thanks for this very detailed summary of the call; since I got a day job interrupt that prevented me from attending, I really appreciate it. I have a couple of clarification questions, below. At 2:32 PM -0700 3/10/09, Henning Schulzrinne wrote: >A few of the interested parties had a beer-less phone bar discussion >on the requirements for preventing premature disconnects. Among >others, two issues came up: > >(1) We need to keep in mind that there are at least three types of UAs: > >(black phone) Analog phone, either with a hook switch or something >like a cordless phone, connected via an ATA. The only user interface >capabilities are ringing and possibly caller-ID injection. > >(dumb Etherphone) SIP phone, with no display and a hook switch > >(smartphone) soft phone, smart phone, Ethernet phone with GUI I believe that there is an underlying question here about whether the mechanisms being described will only be used for user-agents where voice is the primary mode of communication. Will there be an equivalent need for devices using real-time text or other session-based modes that are not voice based? Do these collapse to "smartphone" or are they potentially a different class of "dumb Etherphone"? >The mechanism should work for all of these, but some devices allow for >different, more sophisticated, user interactions. For example, devices >with a GUI can prevent interruption of the audio path by appropriate >user confirmation. That is clearly not possible if the receiver is >placed on-hook on an old electromechanical phone, as the audio path is >interrupted by a mechanical switch. > >(2) There seem to be two separable goals: > >(ADP) Accidental disconnect prevention: Make it difficult for the user >to accidentally disconnect before the call is over. Premature >disconnect could happen either by inadvertent action (press End button >by accident) or by putting the phone back into the cradle, while the >call taker wants to continue the conversation. The second case is more >of a potential misunderstanding, rather than a UI accident, but that >distinction may not matter. > >Some or all emergency calls would have this feature, indicated on a >call-by-call basis. Just to be clear, I do not think that lumping these in Accidental is really much better than calling it all "Premature". There is a class that really is fully accidental (inadvertant action, according to the paragraph above). The other, "potential misunderstanding" seems to shade into some party making a value judgement about when the call should end. I'd suggest keeping "Accidental" for just the inadvertent case. If I am missing some aspect of the conversation, of course, please let me know. >(DC) Disconnect control: Allow the call taker to manage the disconnect >process *at the instant the caller disconnect attempt occurs*. At that >time, the call taker decides whether to let the disconnect proceed and >terminate the call or ask the user to continue/resume the call, via >some alerting mechanism. In that case, the user indicates the desire >to disconnect to the call taker, which the call taker can agree to or >not. > >The current requirement document states (ADP) as the fundamental >requirement (which I think we all agree on), but also implies (DC). Did the folks on the call generally agree or disagree with DC as a requirement? It is a little hard to tell from what follows (you have users "express the choice" which doesn't quite mean "retain control"). My position on this point remains that the user must volunteer to let the call taker take this level of control and that any opt-in mechanism is fundamentally fine by me. Without user opt-in, I remain concerned about a system in which that the user "indicates the desire to disconnect/ with the call taker agreeing or not agreeing". >Separately, we also seem to agree that the call taker needs to be able >to call back the user on the same device, but that's a separate problem. > >We agree, I believe, that the caller should be able to express the >choice not to continue the conversation, e.g., by ignoring the >alerting or by confirming the disconnect. We also agree that "open >microphones", i.e., the ability to silently listen in on the caller is >not something we want. I hadn't realized that anyone was currently requesting this. I also don't want this, and I'm relieved to find it didn't have support on the call. >If we have (ADP), but not (DC), we would satisfy the core requirement >of preventing premature disconnect, as the UI mechanism for indicating >"do not hang up yet" or "do you really want to hang up" is presumably >similar. However, as Brian pointed out, you could get the situation >that the call taker is accepts that the user hangs up and has no >desire to continue the conversation. In that case, the phone would >presumably produce a spurious alert and/or require an unnecessary user >disconnect confirmation. > >Clearly, ADP requires no disconnect-time signaling; DC does. This seems to imply that ADP works the same way (that is, it has the same confirmation) no matter what the PSAP does. The PSAP wouldn't even see the attempt to hang up until the confirmation occurred. Is that your understanding? Thanks again for the quick udpate, Ted > >Henning >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From sedge@qualcomm.com Tue Mar 10 23:22:26 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 301723A698F for ; Tue, 10 Mar 2009 23:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhOncVMtz7+F for ; Tue, 10 Mar 2009 23:22:22 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id B98693A6962 for ; Tue, 10 Mar 2009 23:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1236752578; x=1268288578; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20B rian=20Rosen=20,=0D=0A=20=20=20=20=20 =20=20=20"'Dawson,=20Martin'"=0D=0A=09|CC:=20"'ECRIT'"=20|Date:=20Tue, =2010=20Mar=202009=2023:22:51=20-0700|Subject:=20RE:=20[E crit]=20Comments=20on=20Framework=20Draft|Thread-Topic: =20[Ecrit]=20Comments=20on=20Framework=20Draft |Thread-Index:=20AcmY6xBP94jupkzETj+iA0b5U69mvgDj/IbwAGce YlAAwDSRoAAaf17wACKgjKA=3D|Message-ID:=20<1288E74A7396494 0B132A0B9EA8D8ABC5374A4E8@NASANEXMB04.na.qualcomm.com> |References:=20<1288E74A73964940B132A0B9EA8D8ABC535F0305@ NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c 60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEX MB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A7 3964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.c om><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB 04.na.qualcomm.com><64147.24.154.127.233.1235746352.squir rel@www.brianrosen.net>=0D=0A=20<1288E74A73964940B132A0B9 EA8D8ABC5374A0D6@NASANEXMB04.na.qualcomm.com>=0D=0A=20 =0D=0A=20<1288E74A73964940B132A0B9EA8D8ABC5374A3FE@NASANE XMB04.na.qualcomm.com>=0D=0A=20<028701c9a186$d6ece9f0$84c 6bdd0$@net>|In-Reply-To:=20<028701c9a186$d6ece9f0$84c6bdd 0$@net>|Accept-Language:=20en-US|Content-Language:=20en-U S|X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5549"=3B=20a=3D"16148349"; bh=Uiev1boE+UpzxZSAF8EMeKnYnXxRnMTLGE1bxD4I8kk=; b=nvuWcO+urmWmD+W9vhjnZJ61RJMDrX1zPVg3Zmhh15cnGChXwbof7Zfw HzoLD6InkxHNDmX4Me5ILA4bkmBzT7AY5oCy6ezDnrBu4aDexOQvLRqTT F+MZsvIFpivAT2/IEMUuoAZz2wJEUlio23Ff9DAwprBhXwI6kHKBexQdm s=; X-IronPort-AV: E=McAfee;i="5300,2777,5549"; a="16148349" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Mar 2009 23:22:56 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2B6MuKr025101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Mar 2009 23:22:56 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2B6Mrgp009093 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 10 Mar 2009 23:22:53 -0700 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub05.na.qualcomm.com ([129.46.134.219]) with mapi; Tue, 10 Mar 2009 23:22:53 -0700 From: "Edge, Stephen" To: Brian Rosen , "'Dawson, Martin'" Date: Tue, 10 Mar 2009 23:22:51 -0700 Thread-Topic: [Ecrit] Comments on Framework Draft Thread-Index: AcmY6xBP94jupkzETj+iA0b5U69mvgDj/IbwAGceYlAAwDSRoAAaf17wACKgjKA= Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5374A4E8@NASANEXMB04.na.qualcomm.com> References: <1288E74A73964940B132A0B9EA8D8ABC535F0305@NASANEXMB04.na.qualcomm.com><0a8d01c991ff$fd063420$f7129c60$@net><1288E74A73964940B132A0B9EA8D8ABC53749D48@NASANEXMB04.na.qualcomm.com><49A5FEAE.6000605@bbn.com><1288E74A73964940B132A0B9EA8D8ABC53749E36@NASANEXMB04.na.qualcomm.com><1288E74A73964940B132A0B9EA8D8ABC53749E4B@NASANEXMB04.na.qualcomm.com><64147.24.154.127.233.1235746352.squirrel@www.brianrosen.net> <1288E74A73964940B132A0B9EA8D8ABC5374A0D6@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5374A3FE@NASANEXMB04.na.qualcomm.com> <028701c9a186$d6ece9f0$84c6bdd0$@net> In-Reply-To: <028701c9a186$d6ece9f0$84c6bdd0$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'ECRIT' Subject: Re: [Ecrit] Comments on Framework Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 06:22:26 -0000 Brian Thanks for these comments. I am rather slow at answering but this one seeme= d worth putting at the head of my backlog. Both you and Martin seem to agree that most of the general objections I rai= sed (points 1, 2, 3, 4 and 6) are not Ecrit specific issues but instead con= cern (or at least can concern) 3GPP/3GPP2 in the case of 3GPP/3GPP2 cellula= r access and (for 1) national SDOs like NENA. This does not diminish the si= ze of the problems but just transplants them elsewhere. As a matter of fact= , 3GPP/3GPP2 is already solving them for the PP solution and potentially co= uld do the same in the case of Ecrit. But your additional comments on the similarity of the 2 solutions suggests = a possible resolution to the original issue we raised at the beginning of t= his discussion. This would be to adapt the phoneBCP and Framework spec.s so= that the PP solution emerges as a legitimate solution for direct PP cellul= ar access when the ED supports the full PP protocol stack. It would mean ch= anging a number of requirements (e.g. adding more options) but need not inv= olve sacrificing effective support for the other non-PP cases. To put things more clearly, any device that is accessing a PP network and i= s aware of that would have the option of employing the current PP solution.= A device that is accessing a PP network indirectly (e.g. via a router) wou= ld need to be enabled to discover that - e.g. through DHCP. This would enab= le inclusion of information (e.g. PP network identity) to the VSP to suppor= t subsequent location using possibly SUPL or HELD. Such an approach ought to answer the issues we raised and solve the one tha= t you have namely arriving at a globally suitable and agreeable solution fo= r all access types. Most likely, the detailed changes to the Framework and BCP would take some = time to work out and agree but if we are to avoid 2 apparently conflicting = solutions, could be the best way forward. Kind Regards Stephen -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Tuesday, March 10, 2009 6:48 AM To: Edge, Stephen; 'Dawson, Martin' Cc: 'ECRIT' Subject: RE: [Ecrit] Comments on Framework Draft Stephen In today's emergency services systems, the PSAPs are PSTN connected, and every country is different. To use ecrit within a country, it probably would take some nation-specific standardization to get ecrit originated calls into a legacy PSAP. The expectation, which is supported by some evidence, is that as PSAPs move to become IP connected, they will follow international standards, such as ecrit. Certainly, in North America, that will be true; IP connected PSAPs will assume ecrit standards in the interface between the origination networ= k and the Emergency Services IP network (ESInet). Regardless of what 3GPP does, the interface into North American ESInets will be ecrit based. This should not be any burden on IMS systems; in NENA, we've spent some considerable time making sure the current standards can be met by E-CSCFs without introducing any other changes in 3GPP networks. In fact, we've put some work into making sure we can use an IMS network as an ESInet. In the transition between CS and PS connected PSAPs, there will be some nee= d for nation-specific standards; we all start from different places, even if we end up in the same place. It may be that some of your concerns are handled in that transition phase. 1. Access to PSTN capable PSAPs: is nation specific, and must be defined by that nation. This is unfortunate, but unavoidable. Clearly there is a gateway, which is the target of the LoST PSAP URI, but what happens on the PSTN side of the gateway is very specific to the details of the emergency system in a country at this time. I don't think 3GPP can do much here either, for the same reason. 2. Handover between different IP access networks: There are two aspects here, the actual call origination, and the effect after the call is established if the access network changes. Generally, most of the discussion in ecrit is on the session establishment, and that would take place in one network; most systems don't actually allow handoff while doing session establishment (often, if the session establishment is in progress, handoff is either delayed, or the call attempt is dropped and retried after the handoff). There are small sections on mid call behavior, and on call termination in our docs. Most IETF protocols for IP handoff either have no visibility to SIP, or require renegotiation of IP addresses, neither of which would result in text in -framework or -phonebcp. Thus, I'm not sure there is any work needed for IP handoff, but if there is, I think we'd welcome text. 3. Handover to/from circuit mode networks. Again, this is a mid-call/session termination issue, and not a session establishment issue, and again, is not likely to have much effect on the documents at hand. NEN= A is working on North American specific legacy call origination (where the origination is CS, and thus North American specific), which would put a gateway between the CS origination network and the PS ESInet. I'm not awar= e of any IETF documents that discuss this in non-emergency calls, and we seem to be okay. I don't think there is any text needed in ecrit, given that. 4. Location for cellular access: we have covered that extensively in this discussion. Ecrit would permit the use of SUPL within the origination network, although you have the router with the data card problem. I will tell you that NENA's standards would require that the E-CSCF interwork SUPL to HELD, but that is not a big deal. 5. Endpoint based routing: as has been pointed out, ecrit permits network routing 6. Support of unauthenticated users (and users in limited service state): This one might well be 3GPP specific, because 3GPP has a very specific emergency registration process. I doubt that other access networks would want to copy the 3GPP mechanism. There is some text in -framework on unauthenticated access. I don't see the IETF standardizing an emergency registration mechanism, but you might propose it and see what happens. I think most networks either just allow an emergency call with no registration, allow a registration but restrict what calls can be made/received, or don't support emergency calls from non registered devices= . Brian -----Original Message----- From: Edge, Stephen [mailto:sedge@qualcomm.com] Sent: Monday, March 09, 2009 9:23 PM To: Dawson, Martin; br@brianrosen.net Cc: ECRIT Subject: RE: [Ecrit] Comments on Framework Draft Hi Martin Thanks for theses further comments - which I agree introduce a new twist to this discussion. Your main assertion seems to be that most of the general points I raised ar= e not matters for Ecrit to resolve and standardize but instead represent problems to be resolved for the particular AN (either by an SDO associated with the AN by or by some national SDO like NENA in the case of PSAP access). The list of such issues seems to be: 1. Access to PSTN capable PSAPs 2. Handover between different IP access networks 3. Handover to/from circuit mode networks 4. Location for cellular access 6. Support of unauthenticated users (and users in limited service state) If I am generally right in this assumption, my first question is whether this is just your particular opinion or if this represents the view of Ecri= t generally. E.G. is there any danger that Ecrit (or some other IETF group) might reclaim one or more of the above - perhaps after others SDOs (like 3GPP) have produced their own solutions? If you are all quite certain that this will not happen, or at least certain of this for some subset of the above, it would very much help to include a statement on this in the phoneBCP and/or framework drafts so there is no ambiguity. My next comment is that solving the above for each type of AN probably represents most of difficulty in producing a comprehensive solution. For example, handover after a location URI has been obtained from a LIS will be problematic for continuing location (since the previous and now wrong LIS may receive the next location request). Similarly access and handover to restricted areas (cells or networks a user is not normally allowed to use) is problematic particularly if normal IP connectivity is assumed. Further, use of HELD with a control plane location solution is highly problematic fo= r any 3GPP network because the current architecture and procedures are not able to support location requests initiated solely from a location server (like an SMLC or SAS) where there no prior interaction with the RAN and CN. Further to that, control plane solutions cannot often obtain location accurately enough for dispatch and need to incorporate terminal based positioning using say A-GPS which can lead to a user plane solution like SUPL. I could add other problem areas if you believe this list is exhaustive. Now I am not saying that these problem areas cannot be solved - 3GPP and 3GPP2 have in fact solved most of them (and should complete this b= y the end of this year) in the context of the 3GPP/3GPP2 solution. But your position now seems to be that any SDO must solve them subject to the variou= s restrictions and requirements imposed by the Ecrit phoneBCP and Framework drafts. Can you confirm that this is so? Kind Regards Stephen -----Original Message----- From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] Sent: Thursday, March 05, 2009 10:56 PM To: Edge, Stephen; br@brianrosen.net Cc: ECRIT Subject: RE: [Ecrit] Comments on Framework Draft There must be a word for the situation where everybody is talking about something but everybody knows the real subject is something else and what that real subject is. Suggestions welcome. Anyway, working on the basis that this whole thing isn't just about getting a "sound bite" added to the framework document that can be misappropriated for years to come to confuse the cellular industry into thinking ECRIT is not relevant to them, let's look at each of Stephen's topic areas below. A fundamental tenet of the argument is that, somehow, cellular is "special" and should be left to its "special" devices compared to every other Internet access technology. This, after all, is why we have IMS. It might have seemed reasonable ten years ago to define the core service architecture to accompany the new "Packet Service" mode of networking. In these days of Web 2.0, AJAX, Ruby on Rails, Flash, Silverlight, SOA, Azure... etc. against which IMS seems very.... "stodgy" it is reasonable to ask the question why such a monolithic and cellular-legacy service model is required. Nevertheless - 3GPP is entitled to do what 3GPP does. Actually I'm pretty sure you won't find references to IMS in Web 2.0 texts saying "of course cellular operators also use IMS as an application framework." Now - how specific are the "special" cases that are outlined below to cellular?: 1. Access to PSTN capable PSAPs Not specific to cellular. If a jurisdiction has PSTN capable PSAPs then VoIP calls originating from any form of access have to deal with that fact. The answer is fairly obvious - there has to be a media gateway behind the PSAP URI. And it might not just be a PSTN PSAP, there could be dedicated circuits to selective routers or, even, CAMA trunks involved. The manner in which this is done really does need to be spelt out by the jurisdiction; it can't be otherwise even if there are fairly common conventions. NENA looks after stating how this is done for the US. It's not up to 3GPP nor the IETF to tell jurisdictions how emergency calls that originate on Internet access get bridged into the legacy PSAP infrastructure. No more so than it was 3GPP's job to prescribe that E2+ had to be the PSAP/ALI to GMLC interface protocol used for CS E9-1-1 calls. 2. Handover between different IP access networks Not specific to cellular. There can be handover between WiFi and Ethernet, WiFi and WiMAX and so forth. Now - what we're really talking about here is a more fundamental capability related to mobile IP. 3GPP definitely has a very nice role to play in prescribing how this access-mobility occurs across the access technologies that 3GPP defines and supports. Since the ECRIT emergency model concerns itself from the IP layer up, it is quite possible for it to work very transparently to such mobility occurring beneath the surface. And, of course, any such nicely integrated access technologies would offer a nicely integrated LIS solution to ensure that the location service remains contiguous and consistent. It seems to me that it's quite bad engineering to couple the manner in which this is done to a specific IP service such as emergency calling. Can't help it if 3GPP do that - but it doesn't obviate the option of ECRIT being applied in the more elegant way. 3. Handover to/from circuit mode networks I'll give you this one... to an extent. Obviously the IETF doesn't think this is in the least bit relevant to them. On the other, in theory, a VoIP connection established on any form of IP access could be handed over to some other form of circuit access - e.g. DSL to ISDN. The issue, of course, is just how realistic these scenarios are. If you accept that the PSTN is going to go away (and I certainly do) then you also acknowledge that this is a transitional issue. You can argue that the PSTN is still going to be around for years to come (and I also agree with that) but that doesn't mean you have to create a specific mechanism to handover between circuit and packet for emergency services. I'm interested in just what it is that 3GPP have defined for this. I look at the current 23.167 specification and, I admit, it doesn't leap out at me. The stage 2 description has always struck me as kind of vague. The diagram concerning location information handling, for example, has the dotted boxes with non-prescriptive steps saying "procedure to obtain location" done here. It always kind of reminds me of that old cartoon with the engineers looking at the complex flow chart with the "a miracle happens here" box in the middle. I'm thinking of a call originated on IP. Let's say the E-CSCF invokes the E-SLP to do a SUPL NI-LR (assuming one manifestation of the dotted box in the diagram) and the resultant location is used to determine the correct MGCF route to deliver the call. Perhaps the PSAP supports an MLP interface to the LRF and can ask it for location updates - kicking off a SUPL NI-LR again. Now - the device "roams" to a bit of the network that can only support circuit service? What exactly happens? Does it initiate another call via the MSC? How does that interact with the existing emergency service semantics in the MSC? Obviously it wants to initiate a whole new call - and initiate control plane location determination so it can report an initial location to the GMLC. Is that GMLC the same node as the LRF? How does it deal with the fact that it's now got two pieces of state for what in theory is the same call? Or is it - given the MSC can't know about the PS call in progress? What has 3GPP actually defined for this? I am certainly interested in the mechanics of how this is all accomplished and done reliably. ITRW (the one you and I live in) 3G operators commonly force emergency calls onto the GERAN just because that's lower risk since GSM emergency calling is well established and things like UTDOA infrastructure are available on that access. This is quite the opposite tendency of looking to have seamless real time migration between access technologies on emergency calls (let alone seamless migration between PS and CS!). What carriers are planning to do this with emergency calls if you can say? 4. Location for cellular access. Certainly not specific to cellular access. Every technology has a need for accurate location determination. Wired technologies also, most appropriately, need the location to be provided in civic address form; something that the nominated LCPs are very good at. You're partly confusing the role of the LCP protocol with that of the server. You can send a very simple HELD request to a LIS to ask for location; it's incredibly simple to do; that's why HELD client implementations keep popping up from different sources. The complex stuff happens on the server side. A LIS receiving such a request can invoke all manner of control plane mechanisms (for the confused - "control plane" is not an antonym of "IP"; it just means interaction occurs between network elements and not over the traffic channel with the device). For example, the LIS might do UTDOA. Now, I suspect you realize this and carefully chose examples of technologies that involve measurements taken by the device. Fortunately this is not precluded by HELD either; I believe James has already pointed you at the material for this. Finally, since "cellular (=3D3GPP)" is clearly your one true interest here, the good news is that cellular networks already have terrific infrastructure and control plane mechanisms in place for location determination. This includes the UE peer signalling for AGPS, OTDOA and so forth. All a LIS in a 3GPP network has to do is provide the semantics of the LCP to the device and emergency network clients and to invoke that existing control plane infrastructure at the back end. It's certainly a lower cost and more robust alternative than building SUPL infrastructure in parallel to that control plane capability which already exists to support CS emergency calls anyway. 5. Endpoint based location and routing Nothing cellular specific about this one. Same thing applies to WiFi and WiMAX and wired technologies too. The old "network loading" furphy is often rolled out for these sorts of discussions; presumably it's attractive because it sounds "technical" but doesn't really warrant proper quantification and justification. Gosh "billions" of devices - how can we even consider having so many devices doing... "stuff"? It does prompt me to ask the question "what part of the term 'broadband' don't you understand?" I'm going to take a wild stab and suggest that a device being used to make an emergency call probably isn't "idle". Further, with respect to the general IETF location service model, I'm going to suggest that a device that wants to ask for its location isn't idle either. Even further, I'm going to suggest that a LIS servicing a location dereference can have enough integration with the access network to have the device paged and for location procedures to proceed (i.e. just like a control plane MT-LR or a SUPL NI-LR - though the latter is an ill-defined proposition with respect to arbitrary access types). Actually your commentary on this section strongly suggests to me that you don't actually understand how an ECRIT emergency call procedure works. You've certainly tried to characterize all this LoST and PSAP boundary stuff that's going on as a big deal. It isn't and there's certainly no more going on from either a device or network perspective than there would be to provide the same functionality via a control plane or SUPL approach. If you'd like an offline overview of how an ECRIT emergency call is made, let me know; it would be my pleasure. 6. Support of unauthenticated users Definitely not a cellular specific issue; every access technology has to ask itself about this. Actually every regulator in every jurisdiction has to ask themselves about this too - and hopefully they can avoid the mistake of thinking one form of public access technology is "special" compared to others as well. That would mitigate the risk of them coming up with inconsistent and confusing legislation. ECRIT is based on IP - so the key first step to getting an ECRIT-compliant emergency call underway is for the device to have IP access. In 3GPP parlance, you'd say it needs to have a network context. A good example of providing ECRIT-compliant emergency calling to unauthenticated devices is WiFi hotspots. Hotspots typically provide free layer 2 connectivity and an IP context in the first instance. Device traffic is "port-trapped" to the Hotspots' web site (and maybe a smattering of public Internet websites as well). The firewall isn't opened up until the user "authenticates"; the valid token very often taking the form of a credit card number and expiry date. So -what would a Hotspot need to do to provide "unauthenticated" emergency access? All it needs to do is to ensure that unauthenticated devices, in addition to having access to the portal web page, also have access to a LIS, a LoST server and to the PSAP URI(s) which service the location of that hotspot. That's it; sure there's no emergency call proxy via a third party VSP - but that's not necessary (I'm actually against it anyway) but it could be accommodated with some tweaks on the approach described. Now - what would a 3GPP network need to do to support an ECRIT-compliant unauthenticated emergency calling facility? You could probably describe it better than me - but I dare say it would involve allowing the device to establish an emergency IP context (something which I believe is required by 23.167 anyway - otherwise how would the UE be able to tell the P-CSCF it wants to do an emergency call?). Having permitted the creation of the emergency context, the 3GPP network would similarly just need to constrain the device's access to the LIS, LoST, and the PSAP URI(s) for the corresponding location. Obviously 3GPP have decided to define a different way of doing things and that's par for the course. It's 3GPP's prerogative to continue to act as if there is something special about cellular and that there's good reason for it to look different to both IP devices and the emergency network. It's not true - but that's never stopped the silo thinking before. And that puts me in mind of that scene from Python's Holy Grail movie. 3GPP guarding the bridge to "cellular land" - "None shall pass..." - It'll end much the same way as well. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Edge, Stephen Sent: Wednesday, 4 March 2009 4:32 PM To: br@brianrosen.net Cc: ECRIT Subject: Re: [Ecrit] Comments on Framework Draft Brian Thanks for these well considered responses. Below I am providing on an item by item basis, and taking into account your responses, a few more reasons why the current Ecrit solution is unsuitable - or, if you prefer, less suitable than the 3GPP/3GPP2 solution - for cellular networks. 1. Access to PSTN capable PSAPs Assuming that the best available solution for this currently is the ongoing NENA i2 standard (as you comment), then there are problems with providing location for dispatch (initial and updated location). For example, the latest i2.5 draft I have (December 2008) says that the VPC to LIS v3 interface is being deprecated (thus not available), although this is the interface that the VPC would use to query location from the LIS. Also I don't see any inclusion of accurate positioning support - e.g. using A-GPS. Further, interworking with the circuit mode side for UA access (as opposed to PSAP access) seems to be out of scope. So at best, this standard is incomplete (i.e. not yet suitable for cellular networks). However, I agree that there is some overlap between i2.5 and the 3GPP/3GPP2 solution. 2. Handover between different IP access networks including different types of access network One of the issues here would be change of LIS across different networks while avoiding impacts to both IP and PSTN capable PSAPs (i.e. handover must be transparent to PSAPs within the limitations imposed by SIP or some J-STD-036 type of circuit mode solution). The problem gets more difficult when handover to/from circuit mode access networks is considered. So far, 3GPP/3GPP2 has not yet agreed on a solution although there are proposals and we expect some resolution soon. On the Ecrit and NENA sides, I see much less progress. 3. Handover to/from circuit mode networks We agree here at least on the out of scope aspect. I suppose I can accept that it is not customary to point this out in IETF standards. But I hope you can see that this is an issue for cellular networks most of which will have extensive circuit mode coverage for a long time to come. 4. Location for cellular access (and the requirement to support LCPs that will be useless for cellular access) The issue is not so much the LCP itself but the capability to support accurate positioning - e.g. using A-GPS, AFLT, OTDOA, enhanced cell ID etc. None of those methods seem to be supported as part of DHCP or HELD right now. So some modification of the LCP related requirements or of the LCPs seems needed. 5. Endpoint based location and routing for cellular access (issues here are network and device loading as well as device impacts and problems with PSTN capable PSAPs) Endpoint based location when spread over millions (billions, planet-wide) of terminals will consume significant network and terminal resources. A typical terminal is generally idle and interacts with the network very sparingly to update the network with its current location (e.g. current cluster of potential serving cells). Performing network assisted periodic location fixes and LoST queries would add significantly to network load. Performing periodic location fixes in the terminal (e.g. using GPS) and estimating when a PSAP boundary may have been crossed would add to terminal load (e.g. thus battery drain). Optimizations would be possible of course - e.g. based on observing nearby cell IDs - but they will add to terminal complexity and testing costs. I agree that the Ecrit solution does allow for proxies to do this but here the solution also becomes incomplete because there seem no details of how this would work - e.g. what location solutions would then be used. 6. Support of unauthenticated users and users who can be authenticated but are not permitted access/VSP service except for emergency calls I think the Ecrit solution and you both assume that this has already been resolved somehow at the access level and therefore the various procedures in Ecrit can still be used. Maybe that is valid. However, there are still problems that are not covered in the Ecrit drafts but need to be resolved including (a) obtaining IP access (e.g. via a WLAN, cellular network, cable link) when not a valid subscriber, (b) obtaining access to the VSP and (c) ensuring only emergency related services are provided (e.g. and not free Internet and location access). These and additional problems (e.g. UA identification) would have to be solved, maybe on a per access basis, and then ensured to be compatible with the rest of the Ecrit solution. A significant part of the 3GPP/3GPP2 solution is concerned with this aspect and it has delayed completion of the solution for the more normal case of valid subscriber access due to such compatibility issues. Kind Regards Stephen -----Original Message----- From: br@brianrosen.net [mailto:br@brianrosen.net] Sent: Friday, February 27, 2009 6:53 AM To: Edge, Stephen Cc: Thomson, Martin; Richard Barnes; ECRIT Subject: Re: [Ecrit] Comments on Framework Draft Stephen Like any standards organization, the IETF restricts it's scope. Generally, the scope is "the Internet", although we very often describe solutions that are explicitly designed for private IP networks as well as the Internet. We don't write standards for circuit switched networks, and it should be no surprise that the ecrit solution does not cater to CS solutions. Nevertheless, we often try to make sure that our solutions harmonize reasonably well with existing solutions. Indeed, the ecrit solution clains global applicability to the Internet in general, and most private IP networks that can be interconnected to the Internet or to other IP networks via gateways. Looking at your list of problem areas: > - access to PSTN capable PSAPs This is out of scope for IETF. NENA has active work on this subject. It seems straightforward to interwork ecrit compatible devices and networks to existing CS connected PSAPs. As you know, CS interconnects are very nation-specific, so the NENA work may not have general applicability. However, it shows that it is possible to interwork. The NENA i2 work is also designed to take ecrit compatible devices and VSP networks, and interwork them to the existing network. The VSP would direct the call to the VPC, which would provide the services it does now, using the device provided location for routing. This is important for smooth transition from existing PSAPs and VSPs to "next generation" PSAPs and VSPs. > - handover between different IP access networks including different > types of access network In the ecrit solution, the access network the call is initiated on provides all the facilities needed for the device to initiate an emergency call. The call starts traversing it's normal call path, and eventually routes to the ESRP. Handoffs between IP networks should be transparent to this process, although we probably haven't done all the work we need to do for handoffs where the IP address as seen by the terminating network changes. This would generally be true of all current SIP based work. > - handover to/from circuit mode networks This would be out of scope for IETF. It's as applicable to a simple SIP call as it is a SIP emergency call, and there are no statements in any SIP documents on that subject. > - location for cellular access (and the requirement to support LCPs that > will be useless for cellular access) Location for cellular access networks has been considered carefully. Since cellular is a mobile network, the access network would pass the device a Location-By-Reference URI, using either DHCP or HELD. Either protocol is suitable for cellular networks. As we have pointed out several times, cellular networks support raw data packet services upon which many different kinds of networks can be constructed. My usual example is a large recreational vehicle traveling down a road with a cellular data card plugged into a router to which a wired (Ethernet) phone is connected. That phone must be able to make an emergency call, and it will get location from DHCP or HELD (or LLDP-MED). It is not aware of the cellular network, and doesn't know any cellular specific protocols. Cellular networks will have to support IETF location configuration protocols unless they actively prohibit examples like this, or they implement interworking between cellular-specific location protocols and DHCP or HELD in the data card. The ecrit standards permit proxy insertion of location, but, as above, we don't think that works in all cases. > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) The "load" of using DHCP or HELD to get location and querying LoST is pretty modest. The standards permit proxies to do this if the devices don't. As above, interwork functions to CS connected PSAPs is very feasible, and as above, cellular networks will have to support access to local LoST servers for devices that are connected to cellular networks and are ecrit compliant. > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls This is covered in the standards. None of the processes are dependent on authentication, although where it is possible, it's desirable so as to minimize fraudulent emergency calls Mechanisms for specific network authentication mechanisms are out of scope, and, like SIP basic calling, are not usually mentioned in IETF documents. Stephen, we've tried pretty hard to make sure this works for 3G/4G mobile networks. It's true that it doesn't do it the way 3GPP currently thinks it ought to work, but we claim they haven't thought through all the issues. While it would work, there are opportunities for improvement. We would be willing to do that if we could get the cooperation of 3GPP, which we have tried, and failed, to do. So, I think the documents do not need any qualification statements. Brian > Martin > > The 3GPP/3GPP2 solution has a defined restricted applicability (mainly to > 3GPP/3GPP2 access networks where the serving network also acts as the VSP) > and the specifications for it cover in detail all possible scenarios > consistent with these restrictions so far as we are aware. > > The Ecrit solution seems to claim global applicability to all types of IP > access (and the more that is said about this from Ecrit participants the > more this gets emphasized) but does not cover in detail all possible > scenarios (in some cases does not cover in any detail) which means that at > best the solution is incomplete and at worst intrinsically inapplicable to > some unstated set of scenarios. > > The missing, incomplete and problematic cases include the following: > > - access to PSTN capable PSAPs > - handover between different IP access networks including different > types of access network > - handover to/from circuit mode networks > - location for cellular access (and the requirement to support LCPs that > will be useless for cellular access) > - endpoint based location and routing for cellular access (issues here > are network and device loading as well as device impacts and problems > with PSTN capable PSAPs) > - support of unauthenticated users and users who can be authenticated > but are not permitted access/VSP service except for emergency calls > > Stating that some of these cases are out of scope or referencing an > incomplete and possibly questionable specification from some other > national SDO will not help the user who encounters such problems. But it > would certainly help network operators and implementers to acknowledge > their existence in one form or another because that would allow better > planning of deployments and would help focus attention on finding > solutions (whether in IETF or elsewhere) for the missing cases. > > Please note that despite these drawbacks, I will acknowledge that Ecrit > does have a valuable solution that covers many scenarios not covered by > 3GPP/3GPP2. It would be the delineation of these supported scenarios (or > equivalently unsupported scenarios) in some applicability statement that > would be particularly useful right now. > > Kind Regards > > Stephen > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Thursday, February 26, 2009 9:45 PM > To: Edge, Stephen; Richard Barnes > Cc: ECRIT > Subject: RE: [Ecrit] Comments on Framework Draft > > There's benefit in knowing the limitations of a framework, and every > architecture makes certain assumptions. Let's examine them though... > > The IETF might occasionally make the assumption that the standards it > develops are for Internet devices. That assumption probably need not be > stated explicitly. > > The ECRIT architecture relies on implementations of the protocols that it > references. That is not extraordinary. A reliance on implementation of > these protocols by endpoints, routing intermediaries and PSAPs should not > need to be explained. > > So the assumptions are: > - the Internet > - solutions are implemented and deployed > - the end device is a key component > > Only that last element is particularly novel ... or not that much really. > It's a design choice. Unless you were thinking of trunking the voice > elsewhere. > > Of course, you're suggesting that the design choice was made in ignorance > of all the constraints. You're suggesting that - as a result - the choice > is flawed and the solution is not going to work for cellular services. We > disagree. The solution is a basis for emergency calling in _any_ IP > network. > > Cheers, > Martin > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Edge, Stephen >> Sent: Friday, 27 February 2009 3:30 PM >> To: Richard Barnes >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Richard >> >> Thanks for the comments. Your statement below that "SIP emergency >> calling works if all parties behave as specified in these (IETF Ecrit) >> documents" to some degree highlights the problems we are raising. The >> documents do contain a number of implicit and explicit restrictions - >> like IP capable PSAPs, global IP access (no islands of circuit mode >> access for example), universal support of this solution by all access >> providers and VSPs (not much good if some opt for another solution) and >> end system oriented location and routing capability - which together >> make them unsuitable (we believe) for cellular wireless networks. If >> these restrictions and assumptions were all made explicit upfront, it >> would to a large degree (and possibly completely) address our concerns. >> >> You are right in assuming another set of specifications for the 3GPP >> and 3GPP2 solution. The applicability of this solution is explicitly >> defined in TS 23.167 (or more exactly in an already agreed CR in >> contribution S2-090752 which will become part of 23.167 in a few more >> weeks) to cover the following access types: GPRS (UTRAN WCDMA), I-WLAN, >> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS E-UTRAN >> (LTE). So there is a restriction and arbitrary internet access is not >> covered (yet) as I have stated before. >> >> Kind Regards >> >> Stephen >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Wednesday, February 25, 2009 6:30 PM >> To: Edge, Stephen >> Cc: Brian Rosen; 'ECRIT' >> Subject: Re: [Ecrit] Comments on Framework Draft >> >> Hi Stephen, >> >> I'm a little confused by the scope of what you're asking. The >> framework >> and phonebcp documents exist in order to describe the ECRIT solution: >> They say, in effect, "SIP emergency calling works if all parties behave >> as specified in these documents." >> >> As I understand what you're saying (and I'm by no means an expert in >> 3GPP), 3GPP specifies that one or more elements of this system behave >> differently. This simply means that 3GPP networks aren't complying >> with >> these specs. Just like there's no disclaimer in RFC 791 (IPv4) that >> says "this doesn't work on X.25 networks", it's not clear to me that an >> analogous disclaimer is called for here. >> >> I presume there are similar documents describing how emergency calling >> works in 3GPP networks. Do they include notes saying that the 3GPP >> solution doesn't work in the broader Internet? >> >> --Richard >> >> >> >> >> >> Edge, Stephen wrote: >> > Brian >> > >> > First of all apologies for the likely lateness of this reply - I >> actually wrote it on 19 February in a 3GPP SA2 meeting in Budapest but >> it seems unlikely that my VPN, Outlook server and WiFi access >> capability will cooperate together to get it sent until I return to the >> office mid-next week. >> > >> > Anyhow thanks for your comments. There have actually been a number of >> conference calls between IETF and 3GPP participants over the last >> couple of years at which common features like support of IP emergency >> calls were discussed and these could have been good forum for >> participants on either side to have raised the kinds of issues you >> elaborate on below. Given that seems not so far to have happened, it >> could still be possible in future such calls. >> > >> > But the issues we are raising are not directly to do with further >> aligning the 2 solutions or with the lack of this in the past. We are >> simply pointing out that the solutions are currently different and that >> from a cellular wireless perspective, the Ecrit solution is not seen as >> suitable in all respects (for support of IP emergency calls originating >> from such access types). That is not just our point of view. 3GPP2 sent >> a liaison to Ecrit some months ago pointing out the same issues. >> > >> > So we are proposing that the Ecrit framework and phoneBCP spec.s >> include a statement acknowledging this - e.g. by referencing the >> alternative 3GPP/3GPP2 solution and indicating the IP access types for >> which the Ecrit solution will work without limitation (or equivalently >> the access types where limitations are not ruled out). >> > >> > We are not proposing further modification and extension of the Ecrit >> solution - just pointing out that this would be needed (as with the >> 3GPP/3GPP2 solution) to fully cover all types of access. >> > >> > Kind Regards >> > >> > Stephen >> > -----Original Message----- >> > From: Brian Rosen [mailto:br@brianrosen.net] >> > Sent: Wednesday, February 18, 2009 8:07 PM >> > To: Edge, Stephen; 'ECRIT' >> > Subject: RE: [Ecrit] Comments on Framework Draft >> > >> > I have bit my tongue on this one for a long time. >> > >> > Stephen, with respect, please go talk to 3GPP management and ask them >> why >> > there has been no participation in the ecrit effort despite multiple >> YEARS >> > of begging them to get involved. To put it frankly, 3GPP is quite >> willing >> > to bully IETF into doing its work on its schedule, but cannot be >> bothered to >> > get work done it knows it will eventually have to do when the IETF >> asks it >> > to do so. >> > >> > 3GPP understands the mess that is being created by not participating. >> They >> > know full well that when they finally get around to dealing with PS >> > terminated emergency calls, that there will be a lot of resistance to >> > changing fully specified and implemented standards to more closely >> align >> > with 3GPP standards. I expect you will have several interworking >> functions >> > to define and build. >> > >> > So, politely, please go away, we're finishing work we dearly wanted >> you all >> > to be involved with for years, but you refused to do anything. It's >> too >> > late for this rev. >> > >> > Now, having said that, there are quite a few people who have >> participated in >> > the IETF work who are IMS aware and I believe that despite your >> fears, >> > everything you need is in the specs. The mechanisms we have defined >> provide >> > the ability for the network to insert location, recognize and mark >> emergency >> > calls, and route on behalf of endpoints. An E-CSCF could quite >> > straightforwardly provide a SIP call towards an ecrit compatible >> PSAP. The >> > only not-quite-nice interwork would be from SUPL to HELD (or SIP), >> but it's >> > pretty easy to do that. I'll also note that we have tried to get OMA >> and >> > IETF to cooperate on location protocols, but we have been >> spectacularly >> > unsuccessful at that effort also. >> > >> > Brian >> > >> > >> > >> >> -----Original Message----- >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >> Behalf >> >> Of Edge, Stephen >> >> Sent: Thursday, February 05, 2009 2:50 AM >> >> To: 'ECRIT' >> >> Subject: [Ecrit] Comments on Framework Draft >> >> >> >> All >> >> >> >> draft-ietf-ecrit-framework-07 is (as we see it) a mostly informative >> >> description of how terminals and networks should support emergency >> >> calls made over IP capable facilities to IP capable PSAPs. It >> appears >> >> intended to cover all types of access network - including fixed >> line, >> >> WiFi and cellular (e.g. examples involving each can be found >> throughout >> >> the draft). >> >> >> >> When we evaluated this with respect to support of wireless cellular >> >> access and WiFi access associated with a cellular operator (e.g. >> WLAN >> >> or Femto cells integrated into a cellular network), we found that >> >> certain portions of the draft exhibited one or more of the following >> >> characteristics: >> >> >> >> (A) Inconsistent with already standardized wireless solutions >> >> >> >> (B) Inconsistent with essential wireless requirements and >> >> conventions >> >> >> >> (C) Already part of wireless standards or potentially part of >> >> future standards >> >> >> >> (A) refers to all portions of the draft framework that differ from >> the >> >> requirements and procedures currently standardized for wireless >> >> emergency access by 3GPP, 3GPP2 and OMA. This is a plain difference >> of >> >> solution and could be resolved through support of both solutions by >> >> terminals (with each solution being used according to the type of >> >> access network and VSP) or could be resolved by supporting only one >> >> solution and accessing only the types of network supporting that >> >> solution. To acknowledge this category, the framework document could >> >> reference the applicable wireless standards and point out that these >> >> are valid alternatives for wireless cellular based access. >> >> >> >> (B) refers to portions of the draft that would be unsuitable for >> >> wireless networks even if no alternative solution existed together >> with >> >> other portions missing from the draft that would be needed to fully >> >> support wireless networks. Examples of the former include: (a) >> emphasis >> >> on endpoint derivation of location, performance of Lost query and >> >> receipt of local dial strings; (b) restriction of LCPs to protocols >> >> that require terminal initiation (not allowing for network >> initiation >> >> as far as we can tell) and that include two LCPs (DHCP and LLDP) >> that >> >> are not applicable to (not defined for) cellular access; and (c) the >> >> requirement that a terminal or at least a LIS will update the PSAP >> >> whenever location changes. (a) is impractical due to network and >> >> terminal loading consequences and failure to support non-IP capable >> >> PSAPs; (b) makes location verification and updated location >> provision >> >> to PSAPs difficult or impossible; while (c) is also incompatible >> with >> >> support of existing non-IP capable PSAPs besides increasing terminal >> >> load and possibly interfering with optimum maintenance of the RF >> >> connection (e.g. if a terminal has to tune away from the serving >> base >> >> station or WLAN periodically to make location measurements). >> Examples >> >> of the latter include (d) absence of support for access to non-IP >> >> capable PSAPs as already mentioned (e.g. to support E911 phase 2 in >> the >> >> US); (e) no support for handover from the IP to the circuit domain >> when >> >> a terminal loses (e.g. moves out of) RF coverage in the IP domain; >> and >> >> (f) no allowance for limited access modes wherein a terminal may >> access >> >> a network only to place an emergency call with ensuing restrictions >> on >> >> (for example) location acquisition, PSAP callback and caller >> >> verification and identification to the PSAP. To resolve this >> category >> >> either significant changes to the framework document could be made >> or a >> >> disclaimer/applicability statement could be added stating that >> support >> >> of cellular wireless networks and their associated WLAN and Femto >> >> access points is not covered. >> >> >> >> Category (C) comprises concepts and capabilities in the draft that >> are >> >> either already part of the standardized solution for wireless >> networks >> >> or that might be added at a later time. Examples of the former >> include >> >> LoST, SIP location conveyance, general use of SIP, location for >> routing >> >> versus for dispatch, cellular positioning methods. Examples of the >> >> latter include use of location references and dereferencing and >> >> possible interworking between the current wireless network solutions >> >> (in 3GPP, 3GPP2 and OMA) and the solution described in this draft. >> The >> >> presence of this category could be acknowledged by following the >> >> disclaimer for (B) with a statement that certain portions of the >> >> solution are expected to be incorporated into wireless networks now >> >> and/or in the future. >> >> >> >> We hope that these comments will be seen to be a useful addition to >> >> this review in the sense of enabling a more precise scoping for the >> >> framework document and we are willing to assist in providing wording >> >> for any disclaimer/applicability statement that the Ecrit working >> group >> >> may now deem fit to include. >> >> >> >> Kind Regards >> >> >> >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk Burroughs >> (Qualcomm >> >> 3GPP2 TSG-X and TSG-C participant) >> >> >> >> PS this being sent on 2/4/09 at 11:50pm PST >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www.ietf.org/mailman/listinfo/ecrit >> > >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------ ------------------------ > 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://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.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] From Hannes.Tschofenig@gmx.net Wed Mar 11 07:10:49 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B3603A6BD2 for ; Wed, 11 Mar 2009 07:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgPbmkhTuwT7 for ; Wed, 11 Mar 2009 07:10:48 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id A72393A69D0 for ; Wed, 11 Mar 2009 07:10:43 -0700 (PDT) Received: (qmail invoked by alias); 11 Mar 2009 14:11:18 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp016) with SMTP; 11 Mar 2009 15:11:18 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18r1wk2newrqxgxmkjW6OY1ay21q7hI7Si/KDgMEL 7LDI2fSo9vTJQP From: "Hannes Tschofenig" To: "'ECRIT'" Date: Wed, 11 Mar 2009 16:12:25 +0200 Message-ID: <090001c9a253$676d2040$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmiU2ap6/ze8N0lQg2alsjZTIovMw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.68 Subject: [Ecrit] Short WGLC for draft-ietf-ecrit-lost-sync-04.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 14:10:49 -0000 Hi all, We have got feedback with the first WGLC that resulted in a number of changes to the document. Now, we would like to start a 2nd (short) WGLC to confirm the changes. Please also note that we changed the document type to "Experimental" (from initially "Standards Track"). This is a ECRIT Working Group Last Call for comments on http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-04.txt Please send your comments to the list by March 21, 2009. Ciao Hannes & Marc From hgs@cs.columbia.edu Wed Mar 11 20:00:40 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D0303A6BE4 for ; Wed, 11 Mar 2009 20:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.932 X-Spam-Level: X-Spam-Status: No, score=-4.932 tagged_above=-999 required=5 tests=[AWL=1.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ab+8Afeqk9Y for ; Wed, 11 Mar 2009 20:00:39 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 6751A3A6AE9 for ; Wed, 11 Mar 2009 20:00:39 -0700 (PDT) Received: from Upstairs.home (pool-98-109-204-63.nwrknj.fios.verizon.net [98.109.204.63]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2C31E8P029829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 11 Mar 2009 23:01:15 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: ECRIT Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Mar 2009 23:01:14 -0400 X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Subject: Re: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 03:00:40 -0000 I believe that the service list boundary draft fills a small, but important, hole in the LoST architecture, as it makes it possible to deal effectively with regions having different services. (Without this, user agent might miss new services when they move.) Henning > Karl Heinz prepared some nice slides for our "virtual interim > meeting" to describe the ServiceListBoundary concept, see http://tools.ietf.org/wg/ecrit/trac/attachment/wiki/WikiStart/draft-wolf-ecr > it-lost-servicelistboundary.ppt We had a couple of folks saying > that this is a useful extension to LoST. Marc and I would need a few > more folks who support the idea and are willing to review the > document. Please drop us a note. Ciao Hannes & Marc > From Hannes.Tschofenig@gmx.net Thu Mar 12 10:19:24 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23AD128C0F0 for ; Thu, 12 Mar 2009 10:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yv7pPO2IAmYB for ; Thu, 12 Mar 2009 10:19:22 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DA1A73A6BEE for ; Thu, 12 Mar 2009 10:19:21 -0700 (PDT) Received: (qmail invoked by alias); 12 Mar 2009 17:19:57 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp056) with SMTP; 12 Mar 2009 18:19:57 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/n/qEtADPnpn1v43DZsr/tMC1Oz9EL4fYpY1OWpB /1C+dPqhXLT4iT From: "Hannes Tschofenig" To: "'Henning Schulzrinne'" , "'ECRIT'" References: <26D15A10-533F-4837-808E-105522B9517F@cs.columbia.edu> Date: Thu, 12 Mar 2009 19:21:03 +0200 Message-ID: <09a901c9a336$ec4d9a40$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <26D15A10-533F-4837-808E-105522B9517F@cs.columbia.edu> Thread-Index: Acmhx7mHn+M8L/9bS9amS0UyjuADowBXnrbw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 Subject: Re: [Ecrit] Premature disconnect: UI and call stages X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 17:19:24 -0000 Some background: At the virtual interim meeting it became clear that we got stuck with this work. So, Marc and I wanted to chat with some ECRIT WG members (who have expressed a strong opinion about this subject) in order to figure out whether we can move this topic along somehow. As such, this was not an official ECRIT working group conference call. The following persons participed in this call: * Guy Caron * Brian Rosen * Randall Gellens * Henning Schulzrinne * Keith Drage * Roger Marschall * Marc Linsner * Hannes Tschofenig * (Ted Hardie was excused.) At the end of the call I asked Henning to post the problem classification he mentiond during the call to the mailing list. This is what you see below. Ciao Hannes PS: I think Roger took some more detailed notes. >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Henning Schulzrinne >Sent: 10 March, 2009 23:32 >To: ECRIT >Subject: [Ecrit] Premature disconnect: UI and call stages > >A few of the interested parties had a beer-less phone bar >discussion on the requirements for preventing premature >disconnects. Among others, two issues came up: > >(1) We need to keep in mind that there are at least three types of UAs: > >(black phone) Analog phone, either with a hook switch or >something like a cordless phone, connected via an ATA. The >only user interface capabilities are ringing and possibly >caller-ID injection. > >(dumb Etherphone) SIP phone, with no display and a hook switch > >(smartphone) soft phone, smart phone, Ethernet phone with GUI > >The mechanism should work for all of these, but some devices >allow for different, more sophisticated, user interactions. >For example, devices with a GUI can prevent interruption of >the audio path by appropriate user confirmation. That is >clearly not possible if the receiver is placed on-hook on an >old electromechanical phone, as the audio path is interrupted >by a mechanical switch. > >(2) There seem to be two separable goals: > >(ADP) Accidental disconnect prevention: Make it difficult for >the user to accidentally disconnect before the call is over. >Premature disconnect could happen either by inadvertent action >(press End button by accident) or by putting the phone back >into the cradle, while the call taker wants to continue the >conversation. The second case is more of a potential >misunderstanding, rather than a UI accident, but that >distinction may not matter. > >Some or all emergency calls would have this feature, indicated >on a call-by-call basis. > >(DC) Disconnect control: Allow the call taker to manage the >disconnect process *at the instant the caller disconnect >attempt occurs*. At that time, the call taker decides whether >to let the disconnect proceed and terminate the call or ask >the user to continue/resume the call, via some alerting >mechanism. In that case, the user indicates the desire to >disconnect to the call taker, which the call taker can agree to or not. > >The current requirement document states (ADP) as the >fundamental requirement (which I think we all agree on), but >also implies (DC). > >Separately, we also seem to agree that the call taker needs to >be able to call back the user on the same device, but that's a >separate problem. > >We agree, I believe, that the caller should be able to express >the choice not to continue the conversation, e.g., by ignoring >the alerting or by confirming the disconnect. We also agree >that "open microphones", i.e., the ability to silently listen >in on the caller is not something we want. > >If we have (ADP), but not (DC), we would satisfy the core >requirement of preventing premature disconnect, as the UI >mechanism for indicating "do not hang up yet" or "do you >really want to hang up" is presumably similar. However, as >Brian pointed out, you could get the situation that the call >taker is accepts that the user hangs up and has no desire to >continue the conversation. In that case, the phone would >presumably produce a spurious alert and/or require an >unnecessary user disconnect confirmation. > >Clearly, ADP requires no disconnect-time signaling; DC does. > > >Henning >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > From khwolf1@gmail.com Fri Mar 13 07:46:45 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC6AC3A6B0C for ; Fri, 13 Mar 2009 07:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a13bIVyTyPvL for ; Fri, 13 Mar 2009 07:46:39 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id E647D3A680E for ; Fri, 13 Mar 2009 07:46:38 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so1372432qwe.31 for ; Fri, 13 Mar 2009 07:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dtt7dpPseJWD4DHd5fJFMX7WiiY9w9BPMNS0Z/D09q8=; b=spZyoq9Eh6Lbcwx9NmmPvlasrDg9UmJWqDo3ydc41jjCampZx0NjZj9acIXVO6FiLu RC3P/Pj0GOt0kmUqLz4xrMJ/oZlwqkU192pNC5kktJOw56c8KAOcM7DW7zCphxCd2zNI z8N3DEiyIntnpnz43EuJ4OSiF62UJ+iAusDwI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EwtedqKkfFyrXHs3Joa3ripedLkexqJytGBxiiJdI1EYXXwnCHTvMxv67kCHVxqhrf P+CqTfOqVnFAsymR5a87MpVc+Wp0tBZ6zD1GI25ET/BwbmDN+Ul+zTDCyWLbNeBLCd0U 0H5xu1rKairUT92mzEJXrnn2zsstuVczajOZ8= MIME-Version: 1.0 Received: by 10.220.45.203 with SMTP id g11mr717940vcf.70.1236955637102; Fri, 13 Mar 2009 07:47:17 -0700 (PDT) In-Reply-To: <00e901c99c4e$ee6bbcb0$cb433610$@net> References: <53275.24.154.127.233.1235780998.squirrel@www.brianrosen.net> <00e901c99c4e$ee6bbcb0$cb433610$@net> Date: Fri, 13 Mar 2009 10:47:17 -0400 Message-ID: From: Karl Heinz Wolf To: Brian Rosen Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments on phonebcp-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 14:46:45 -0000 Thank you for putting back ED-6. I thought about the configuration of the home emergency number and how to map the home emergency number to the visited one. In case the same emergency (sub-)services exist in both the home and visited country, there shouldn=92t be a problem. But what about the following situation: the user dials his home dialstring for sos.physician, but this service does not exist in the visited country. Or the user just has a single home dial string for sos, but there is no such general emergency service in the visited country, but all the subservices. Where should the call be connected to? Would it make sense to have a rule on this like: Home emergency dial strings should be mapped to the corresponding emergency service in the visited country. In case there is not such a service in the visited country, the mapping for urn:service:sos should be used to connect the call. If there is no such general emergency service available, urn:service:sos.police should be tried, followed by other randomly selected services in case of failure. ? Karl Heinz On Tue, Mar 3, 2009 at 6:25 PM, Brian Rosen wrote: > Hmmmm. =A0That works. =A0Either I forgot about it, or we never actually > discussed it. > > I'll put it back and put some text in -framework about it: > You MAY provision home country > The device could discover home dial strings knowing home country via LoST= . > > Sorry about that. =A0ED-6 will come back. > > Brian > > -----Original Message----- > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > Sent: Tuesday, March 03, 2009 4:59 PM > To: Brian Rosen > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Comments on phonebcp-07 > > Brian, just one comment on the now deleted ED-6: > >> 1. ED-6 vs ED-9 is the difference between discovery with a home country >> code and provisioning of actual dial string. =A0We haven't described >> discovery, so I'll have to delete ED-6 >> > > I thought LoST would be the way to discover dial strings for the home > country. A mapping request with just the home country as location > information would be the discovery, wouldn't it? > > karl heinz > > From br@brianrosen.net Fri Mar 13 08:19:20 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EDD028C178 for ; Fri, 13 Mar 2009 08:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgRTzmQfPXhk for ; Fri, 13 Mar 2009 08:19:10 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 2F45D3A69A8 for ; Fri, 13 Mar 2009 08:19:05 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Li9Ad-00074h-1s; Fri, 13 Mar 2009 10:19:35 -0500 From: "Brian Rosen" To: "'Karl Heinz Wolf'" References: <53275.24.154.127.233.1235780998.squirrel@www.brianrosen.net> <00e901c99c4e$ee6bbcb0$cb433610$@net> In-Reply-To: Date: Fri, 13 Mar 2009 11:18:18 -0400 Message-ID: <00b701c9a3ef$05817050$108450f0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acmj6pchTug+2Mb2RMKfAzXNl275IAABCP2w Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments on phonebcp-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 15:19:20 -0000 I think we're better off saying (if it isn't already in LoST), that urn:service:sos MUST be specified (locally) and lead somewhere = appropriate. Then a missing service goes to urn:service:sos always. Brian -----Original Message----- From: Karl Heinz Wolf [mailto:khwolf1@gmail.com]=20 Sent: Friday, March 13, 2009 10:47 AM To: Brian Rosen Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments on phonebcp-07 Thank you for putting back ED-6. I thought about the configuration of the home emergency number and how to map the home emergency number to the visited one. In case the same emergency (sub-)services exist in both the home and visited country, there shouldn=92t be a problem. But what about the following situation: the user dials his home dialstring for sos.physician, but this service does not exist in the visited country. Or the user just has a single home dial string for sos, but there is no such general emergency service in the visited country, but all the subservices. Where should the call be connected to? Would it make sense to have a rule on this like: Home emergency dial strings should be mapped to the corresponding emergency service in the visited country. In case there is not such a service in the visited country, the mapping for urn:service:sos should be used to connect the call. If there is no such general emergency service available, urn:service:sos.police should be tried, followed by other randomly selected services in case of failure. ? Karl Heinz On Tue, Mar 3, 2009 at 6:25 PM, Brian Rosen wrote: > Hmmmm. =A0That works. =A0Either I forgot about it, or we never = actually > discussed it. > > I'll put it back and put some text in -framework about it: > You MAY provision home country > The device could discover home dial strings knowing home country via = LoST. > > Sorry about that. =A0ED-6 will come back. > > Brian > > -----Original Message----- > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > Sent: Tuesday, March 03, 2009 4:59 PM > To: Brian Rosen > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Comments on phonebcp-07 > > Brian, just one comment on the now deleted ED-6: > >> 1. ED-6 vs ED-9 is the difference between discovery with a home = country >> code and provisioning of actual dial string. =A0We haven't described >> discovery, so I'll have to delete ED-6 >> > > I thought LoST would be the way to discover dial strings for the home > country. A mapping request with just the home country as location > information would be the discovery, wouldn't it? > > karl heinz > > From spencer@wonderhamster.org Fri Mar 13 08:35:32 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E20273A6A22 for ; Fri, 13 Mar 2009 08:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, J_CHICKENPOX_39=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnH-nbAt5RQv for ; Fri, 13 Mar 2009 08:35:26 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 548463A69A8 for ; Fri, 13 Mar 2009 08:35:22 -0700 (PDT) Received: from S73602b (cpe-72-190-78-151.tx.res.rr.com [72.190.78.151]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1Li9QS0USW-000cqD; Fri, 13 Mar 2009 11:35:59 -0400 Message-ID: From: "Spencer Dawkins" To: "Brian Rosen" , "'Karl Heinz Wolf'" References: <53275.24.154.127.233.1235780998.squirrel@www.brianrosen.net> <00e901c99c4e$ee6bbcb0$cb433610$@net> <00b701c9a3ef$05817050$108450f0$@net> Date: Fri, 13 Mar 2009 10:35:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX18ch+zhDoLSiOIMssRF307Osq8l1H6OuLwuxmE NA0PCntORBFkY/VIN9YLTH6bj4CaA4UsxZ5hL9Gsx+9DqOZfxq ROL5/bXofXsu1/5X9sP8bmIVuIpRDVr+hyh1hCWBlk= Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments on phonebcp-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 15:35:33 -0000 I agree - the alternative, as Karl Heinz suggests, is to pick another URN, which might ALSO be missing, and/or just start trying services at random... Thanks, Spencer ----- Original Message ----- From: "Brian Rosen" To: "'Karl Heinz Wolf'" Cc: Sent: Friday, March 13, 2009 10:18 AM Subject: Re: [Ecrit] Comments on phonebcp-07 I think we're better off saying (if it isn't already in LoST), that urn:service:sos MUST be specified (locally) and lead somewhere appropriate. Then a missing service goes to urn:service:sos always. Brian -----Original Message----- From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] Sent: Friday, March 13, 2009 10:47 AM To: Brian Rosen Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments on phonebcp-07 Thank you for putting back ED-6. I thought about the configuration of the home emergency number and how to map the home emergency number to the visited one. In case the same emergency (sub-)services exist in both the home and visited country, there shouldn't be a problem. But what about the following situation: the user dials his home dialstring for sos.physician, but this service does not exist in the visited country. Or the user just has a single home dial string for sos, but there is no such general emergency service in the visited country, but all the subservices. Where should the call be connected to? Would it make sense to have a rule on this like: Home emergency dial strings should be mapped to the corresponding emergency service in the visited country. In case there is not such a service in the visited country, the mapping for urn:service:sos should be used to connect the call. If there is no such general emergency service available, urn:service:sos.police should be tried, followed by other randomly selected services in case of failure. ? Karl Heinz On Tue, Mar 3, 2009 at 6:25 PM, Brian Rosen wrote: > Hmmmm. That works. Either I forgot about it, or we never actually > discussed it. > > I'll put it back and put some text in -framework about it: > You MAY provision home country > The device could discover home dial strings knowing home country via LoST. > > Sorry about that. ED-6 will come back. > > Brian > > -----Original Message----- > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > Sent: Tuesday, March 03, 2009 4:59 PM > To: Brian Rosen > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Comments on phonebcp-07 > > Brian, just one comment on the now deleted ED-6: > >> 1. ED-6 vs ED-9 is the difference between discovery with a home country >> code and provisioning of actual dial string. We haven't described >> discovery, so I'll have to delete ED-6 >> > > I thought LoST would be the way to discover dial strings for the home > country. A mapping request with just the home country as location > information would be the discovery, wouldn't it? > > karl heinz > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From khwolf1@gmail.com Fri Mar 13 08:47:57 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B66D3A6BE9 for ; Fri, 13 Mar 2009 08:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Dr3b4RHekxw for ; Fri, 13 Mar 2009 08:47:50 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by core3.amsl.com (Postfix) with ESMTP id 2E3C43A6A01 for ; Fri, 13 Mar 2009 08:47:32 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id b2so1294807ana.4 for ; Fri, 13 Mar 2009 08:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HTMlY9r23XhrBoGysdP20a+/OI/O1WQYzeAy4LgoFPI=; b=vAF9izl7FwOPrP+Bbxty5OckIjI5fwFuh8qX8x63rCsG9W++E5BNhnCFZStd336JSN YmlLuVcEldRjARhxs4TVqGAHhJugX0MQHFj6+CrSXTj71IKpkqM6vsxsFq+KewtbgFf4 +b/43Wv0Nn0k9szSqCTfNVGAB92Lr8qJHJIWQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=UNIsMxSqODjFzoqrMf7dsRVQO3ZvOE7OE6xyxPrNc7Ywt0faxoXDOIEiBONLUrQ+Kc O6Xz1rXYFBo+rCXe0DfsrRCAAqoxuXedY0i2DQfU/wYNjxaifDTrr/ImfzQx97RAzjwR jIAhuljHy3p7JDICBbufeQMAifKQctmtb/f2k= MIME-Version: 1.0 Received: by 10.220.99.205 with SMTP id v13mr763783vcn.105.1236959290387; Fri, 13 Mar 2009 08:48:10 -0700 (PDT) In-Reply-To: References: <53275.24.154.127.233.1235780998.squirrel@www.brianrosen.net> <00e901c99c4e$ee6bbcb0$cb433610$@net> <00b701c9a3ef$05817050$108450f0$@net> Date: Fri, 13 Mar 2009 11:48:10 -0400 Message-ID: From: Karl Heinz Wolf To: Spencer Dawkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments on phonebcp-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 15:47:57 -0000 I just noticed that Spencer's first mail was off-list and so was my reply. My question there was: do you think every country having subservices could agree on picking one service as a default sos service? I certainly agree that having a urn:service:sos would make things easier. karl heinz On Fri, Mar 13, 2009 at 11:35 AM, Spencer Dawkins wrote: > I agree - the alternative, as Karl Heinz suggests, is to pick another URN, > which might ALSO be missing, and/or just start trying services at random... > > Thanks, > > Spencer > > ----- Original Message ----- From: "Brian Rosen" > To: "'Karl Heinz Wolf'" > Cc: > Sent: Friday, March 13, 2009 10:18 AM > Subject: Re: [Ecrit] Comments on phonebcp-07 > > > I think we're better off saying (if it isn't already in LoST), that > urn:service:sos MUST be specified (locally) and lead somewhere appropriate. > Then a missing service goes to urn:service:sos always. > > Brian > > -----Original Message----- > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > Sent: Friday, March 13, 2009 10:47 AM > To: Brian Rosen > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Comments on phonebcp-07 > > Thank you for putting back ED-6. > > I thought about the configuration of the home emergency number and how > to map the home emergency number to the visited one. In case the same > emergency (sub-)services exist in both the home and visited country, > there shouldn't be a problem. But what about the following situation: > the user dials his home dialstring for sos.physician, but this service > does not exist in the visited country. > Or the user just has a single home dial string for sos, but there is > no such general emergency service in the visited country, but all the > subservices. Where should the call be connected to? > > Would it make sense to have a rule on this like: > > Home emergency dial strings should be mapped to the corresponding > emergency service in the visited country. In case there is not such a > service in the visited country, the mapping for urn:service:sos should > be used to connect the call. If there is no such general emergency > service available, urn:service:sos.police should be tried, followed by > other randomly selected services in case of failure. > ? > > Karl Heinz > > > On Tue, Mar 3, 2009 at 6:25 PM, Brian Rosen wrote: >> >> Hmmmm. That works. Either I forgot about it, or we never actually >> discussed it. >> >> I'll put it back and put some text in -framework about it: >> You MAY provision home country >> The device could discover home dial strings knowing home country via LoST. >> >> Sorry about that. ED-6 will come back. >> >> Brian >> >> -----Original Message----- >> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >> Sent: Tuesday, March 03, 2009 4:59 PM >> To: Brian Rosen >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] Comments on phonebcp-07 >> >> Brian, just one comment on the now deleted ED-6: >> >>> 1. ED-6 vs ED-9 is the difference between discovery with a home country >>> code and provisioning of actual dial string. We haven't described >>> discovery, so I'll have to delete ED-6 >>> >> >> I thought LoST would be the way to discover dial strings for the home >> country. A mapping request with just the home country as location >> information would be the discovery, wouldn't it? >> >> karl heinz >> >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > From br@brianrosen.net Fri Mar 13 08:56:01 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 369FF3A687E for ; Fri, 13 Mar 2009 08:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ptd2QBYn1Po0 for ; Fri, 13 Mar 2009 08:55:54 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 54AA23A6BC4 for ; Fri, 13 Mar 2009 08:55:54 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Li9kE-0004Db-OT; Fri, 13 Mar 2009 10:56:24 -0500 From: "Brian Rosen" To: "'Karl Heinz Wolf'" , "'Spencer Dawkins'" References: <53275.24.154.127.233.1235780998.squirrel@www.brianrosen.net> <00e901c99c4e$ee6bbcb0$cb433610$@net> <00b701c9a3ef$05817050$108450f0$@net> In-Reply-To: Date: Fri, 13 Mar 2009 11:56:05 -0400 Message-ID: <000001c9a3f4$3a48b140$aeda13c0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acmj8xkVfHA7vjwyRmOrNxU9Xv0hiAAAPm6Q Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: ecrit@ietf.org Subject: Re: [Ecrit] Comments on phonebcp-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 15:56:01 -0000 As a practical matter, nearly every country already does that, because of the 1-1-2 action in mobile phones, so I think it's a practical answer. Brian -----Original Message----- From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] Sent: Friday, March 13, 2009 11:48 AM To: Spencer Dawkins Cc: Brian Rosen; ecrit@ietf.org Subject: Re: [Ecrit] Comments on phonebcp-07 I just noticed that Spencer's first mail was off-list and so was my reply. My question there was: do you think every country having subservices could agree on picking one service as a default sos service? I certainly agree that having a urn:service:sos would make things easier. karl heinz On Fri, Mar 13, 2009 at 11:35 AM, Spencer Dawkins wrote: > I agree - the alternative, as Karl Heinz suggests, is to pick another URN, > which might ALSO be missing, and/or just start trying services at random... > > Thanks, > > Spencer > > ----- Original Message ----- From: "Brian Rosen" > To: "'Karl Heinz Wolf'" > Cc: > Sent: Friday, March 13, 2009 10:18 AM > Subject: Re: [Ecrit] Comments on phonebcp-07 > > > I think we're better off saying (if it isn't already in LoST), that > urn:service:sos MUST be specified (locally) and lead somewhere appropriate. > Then a missing service goes to urn:service:sos always. > > Brian > > -----Original Message----- > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > Sent: Friday, March 13, 2009 10:47 AM > To: Brian Rosen > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Comments on phonebcp-07 > > Thank you for putting back ED-6. > > I thought about the configuration of the home emergency number and how > to map the home emergency number to the visited one. In case the same > emergency (sub-)services exist in both the home and visited country, > there shouldn't be a problem. But what about the following situation: > the user dials his home dialstring for sos.physician, but this service > does not exist in the visited country. > Or the user just has a single home dial string for sos, but there is > no such general emergency service in the visited country, but all the > subservices. Where should the call be connected to? > > Would it make sense to have a rule on this like: > > Home emergency dial strings should be mapped to the corresponding > emergency service in the visited country. In case there is not such a > service in the visited country, the mapping for urn:service:sos should > be used to connect the call. If there is no such general emergency > service available, urn:service:sos.police should be tried, followed by > other randomly selected services in case of failure. > ? > > Karl Heinz > > > On Tue, Mar 3, 2009 at 6:25 PM, Brian Rosen wrote: >> >> Hmmmm. That works. Either I forgot about it, or we never actually >> discussed it. >> >> I'll put it back and put some text in -framework about it: >> You MAY provision home country >> The device could discover home dial strings knowing home country via LoST. >> >> Sorry about that. ED-6 will come back. >> >> Brian >> >> -----Original Message----- >> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >> Sent: Tuesday, March 03, 2009 4:59 PM >> To: Brian Rosen >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] Comments on phonebcp-07 >> >> Brian, just one comment on the now deleted ED-6: >> >>> 1. ED-6 vs ED-9 is the difference between discovery with a home country >>> code and provisioning of actual dial string. We haven't described >>> discovery, so I'll have to delete ED-6 >>> >> >> I thought LoST would be the way to discover dial strings for the home >> country. A mapping request with just the home country as location >> information would be the discovery, wouldn't it? >> >> karl heinz >> >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > > From hannes.tschofenig@nsn.com Tue Mar 17 00:06:24 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E3D73A693F for ; Tue, 17 Mar 2009 00:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.558 X-Spam-Level: X-Spam-Status: No, score=-5.558 tagged_above=-999 required=5 tests=[AWL=1.041, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bvDn+k83svA for ; Tue, 17 Mar 2009 00:06:23 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 297203A67DD for ; Tue, 17 Mar 2009 00:06:22 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n2H76ZTb008760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Mar 2009 08:06:35 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n2H76ZgR031323; Tue, 17 Mar 2009 08:06:35 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Mar 2009 08:06:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Mar 2009 09:07:44 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45012890E3@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version of draft-barnes-ecrit-rough-loc? Thread-Index: AcmmzxGiYjWKjIPaRGmIgrmtf/2G4A== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "Richard Barnes" X-OriginalArrivalTime: 17 Mar 2009 07:06:35.0250 (UTC) FILETIME=[E897B520:01C9A6CE] Cc: ECRIT Subject: [Ecrit] New Version of draft-barnes-ecrit-rough-loc? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 07:06:24 -0000 Hi Richard,=20 I just checked my reading list and I was not sure whether there is an updated version of draft-barnes-ecrit-rough-loc available.=20 I believe you said that you wanted to ship an update of the draft based on the discussions during the virtual interim meeting.=20 Can you distribute a snapshot during this week?=20 Ciao Hannes From hannes.tschofenig@nsn.com Wed Mar 18 02:27:58 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0831D3A6885 for ; Wed, 18 Mar 2009 02:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.617 X-Spam-Level: X-Spam-Status: No, score=-5.617 tagged_above=-999 required=5 tests=[AWL=0.982, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5RX0zmkfgjO for ; Wed, 18 Mar 2009 02:27:57 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 13F293A67A5 for ; Wed, 18 Mar 2009 02:27:56 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n2I9SPPe027699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Mar 2009 10:28:25 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n2I9SPqu027070; Wed, 18 Mar 2009 10:28:25 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Mar 2009 10:28:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Mar 2009 11:29:33 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501289AA3@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LoST Mapping Architecture Document Thread-Index: AcmnrAvkPmTFvLkIQ4iz355Dya+Y+Q== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "Cullen Jennings" X-OriginalArrivalTime: 18 Mar 2009 09:28:24.0850 (UTC) FILETIME=[E31F5F20:01C9A7AB] Cc: marc.linsner@cisco.com, ECRIT Subject: [Ecrit] LoST Mapping Architecture Document X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 09:27:58 -0000 Hi Cullen,=20 Thanks for your comments regarding draft-ietf-ecrit-mapping-arch.=20 Based on your feedback the LoST architecture has been updated, see=20 http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-mapping-arch/ The update is briefly described in this mail: http://www.ietf.org/mail-archive/web/ecrit/current/msg05921.html.=20 I hope that this addresses your DISCUSS. Ciao Hannes From fluffy@cisco.com Wed Mar 18 17:23:37 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7DD93A698C for ; Wed, 18 Mar 2009 17:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.982 X-Spam-Level: X-Spam-Status: No, score=-99.982 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5vUJWvhFy9R for ; Wed, 18 Mar 2009 17:23:37 -0700 (PDT) Received: from dreaminn-nms.sunraytvi.com (66.236.51.35.ptr.us.xo.net [66.236.51.35]) by core3.amsl.com (Postfix) with ESMTP id 26DEB3A68E6 for ; Wed, 18 Mar 2009 17:23:37 -0700 (PDT) Received: from [10.10.1.70] (66.236.51.34.ptr.us.xo.net [66.236.51.34]) by dreaminn-nms.sunraytvi.com (8.13.1/8.13.1) with ESMTP id n2J0Nl8p032426; Wed, 18 Mar 2009 19:23:53 -0500 Message-Id: From: Cullen Jennings To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501289AA3@FIESEXC015.nsn-intra.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 18 Mar 2009 14:30:58 -0700 References: <3D3C75174CB95F42AD6BCC56E5555B4501289AA3@FIESEXC015.nsn-intra.net> X-Mailer: Apple Mail (2.930.3) Cc: marc.linsner@cisco.com, ECRIT Subject: Re: [Ecrit] LoST Mapping Architecture Document X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 00:23:37 -0000 Great - thanks. I'll take a look after the meeting. On Mar 18, 2009, at 2:29 , Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi Cullen, > > Thanks for your comments regarding draft-ietf-ecrit-mapping-arch. > > Based on your feedback the LoST architecture has been updated, see > http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-mapping-arch/ > > The update is briefly described in this mail: > http://www.ietf.org/mail-archive/web/ecrit/current/msg05921.html. > > I hope that this addresses your DISCUSS. > > Ciao > Hannes From rbarnes@bbn.com Thu Mar 19 23:11:48 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9492D3A67A8 for ; Thu, 19 Mar 2009 23:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3nBTZ32npSV for ; Thu, 19 Mar 2009 23:11:47 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 9590E3A69EA for ; Thu, 19 Mar 2009 23:11:47 -0700 (PDT) Received: from [128.89.252.163] (helo=Richard-Barnes-Laptop.local) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LkXy0-0004FD-Fh; Fri, 20 Mar 2009 02:12:29 -0400 Message-ID: <49C333CC.6000909@bbn.com> Date: Thu, 19 Mar 2009 23:12:28 -0700 From: Richard Barnes User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: ECRIT , draft-ietf-ecrit-lost-sync@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Ecrit] Review of draft-ietf-ecrit-lost-sync-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 06:11:48 -0000 I reviewed lost-sync-04 in order to update my earlier comments on -01. This version is much improved from the previous versions in terms of specificity (although it's still vague in places). It still seems to me that there are a few layers of detail missing. Specific comments below. --Richard 1. The document describes transactions for requesting and delivering mapping structures, but doesn't describe at all how these transactions create a synchronization system. There is clearly some tracking of state needed (especially for "pushMappings"), and the document is silent on how this state is initially established and then maintained. 2. In a similar vein, it would be helpful for this document to have some discussion of how this synchronization system relates to others that are out there (e.g., rsync). Since the name of the draft is "synchronization", there should be some discussion of how bidirectional sync is handled. 3. It seems like there should really be only 3 message types here instead of 4: (1) a "syncRequest" message sent from destination to source (getMappingsRequest), (2) a "syncUpdate" message sent from source to destination (getMappingsResponse == pushMappingsRequest), and (3) a "syncResult" message sent from destination to source (pushMappingsResponse). There can still be two types of transaction, but they're determined by which type of message (syncRequest or syncUpdate) is sent in the HTTP request. 4. In a similar vein to 2 and 3, the use of "client" and "server" is confusing. I would suggest using more appropriate names for these roles like "source" and "destination", along with some text that explains how these roles map to HTTP roles in each type of transaction. 5. My comment about the security considerations has not been addressed. The security considerations section is essentially a pointer to LoST, but this protocol is only peripherally related to LoST (at a technical level). Since it's about synchronization, I would expect this document to note that the primary risk is the injection of false location information (since the mappings themselves are public), which means that the parties should use HTTPS to carry the XML, authenticate the source, and use a ciphersuite that provides integrity protection to messages. From Martin.Thomson@andrew.com Sun Mar 22 10:50:22 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8DBE3A689D for ; Sun, 22 Mar 2009 10:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.745 X-Spam-Level: X-Spam-Status: No, score=-1.745 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeIwNYWAGU0x for ; Sun, 22 Mar 2009 10:50:22 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id D968A3A67DF for ; Sun, 22 Mar 2009 10:50:21 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_22_13_11_12 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 22 Mar 2009 13:11:12 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Mar 2009 12:51:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sun, 22 Mar 2009 12:51:07 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary Thread-Index: AcmivtEPBZRNqKtiRfmlfZW01DNSBAIKdPhg References: From: "Thomson, Martin" To: "Henning Schulzrinne" , "ECRIT" X-OriginalArrivalTime: 22 Mar 2009 17:51:09.0489 (UTC) FILETIME=[C84D0210:01C9AB16] Subject: Re: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 17:50:22 -0000 SSB0b28gdW5kZXJzdGFuZCBob3cgdGhpcyBpcyBuZWNlc3NhcnkgdG8gY29tcGxldGUgdGhlIHNv bHV0aW9uLiAgVGhlIGluc3RhbmNlcyB3aGVyZSB0aGlzIGlzIHRydWx5IHVzZWZ1bCBhcmUgcHJv YmFibHkgbGltaXRlZCwgYnV0IGl0IGlzIGVhc3kgdG8gZG8uICBJIGRvbid0IGhhdmUgYW55IGZl ZWRiYWNrIG9uIHRoZSBzb2x1dGlvbiAtIHdoYXQgaXMgc3VnZ2VzdGVkIGlzIHNpbWlsYXIgZW5v dWdoIHRvIHRoZSBzZXJ2aWNlIGJvdW5kYXJ5IG9wdGlvbiBhbHJlYWR5IGluIHBsYWNlLiAgU28g b24gdGhlIHByaW5jaXBsZSBvZiBsZWFzdCBzdXJwcmlzZSwgdGhpcyBpcyBhIGdvb2QgZG9jdW1l bnQuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZWNyaXQtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBP ZiBIZW5uaW5nIFNjaHVsenJpbm5lDQo+IFNlbnQ6IFdlZG5lc2RheSwgMTEgTWFyY2ggMjAwOSA4 OjAxIFBNDQo+IFRvOiBFQ1JJVA0KPiBTdWJqZWN0OiBSZTogW0Vjcml0XSBkcmFmdC13b2xmLWVj cml0LWxvc3Qtc2VydmljZWxpc3Rib3VuZGFyeQ0KPiANCj4gSSBiZWxpZXZlIHRoYXQgdGhlIHNl cnZpY2UgbGlzdCBib3VuZGFyeSBkcmFmdCBmaWxscyBhIHNtYWxsLCBidXQNCj4gaW1wb3J0YW50 LCBob2xlIGluIHRoZSBMb1NUIGFyY2hpdGVjdHVyZSwgYXMgaXQgbWFrZXMgaXQgcG9zc2libGUg dG8NCj4gZGVhbCBlZmZlY3RpdmVseSB3aXRoIHJlZ2lvbnMgaGF2aW5nIGRpZmZlcmVudCBzZXJ2 aWNlcy4gKFdpdGhvdXQNCj4gdGhpcywgdXNlciBhZ2VudCBtaWdodCBtaXNzIG5ldyBzZXJ2aWNl cyB3aGVuIHRoZXkgbW92ZS4pDQo+IA0KPiBIZW5uaW5nDQo+IA0KPiA+IEthcmwgSGVpbnogcHJl cGFyZWQgc29tZSBuaWNlIHNsaWRlcyBmb3Igb3VyICJ2aXJ0dWFsIGludGVyaW0NCj4gPiBtZWV0 aW5nIiB0byBkZXNjcmliZSB0aGUgU2VydmljZUxpc3RCb3VuZGFyeSBjb25jZXB0LCBzZWUNCj4g aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL2Vjcml0L3RyYWMvYXR0YWNobWVudC93aWtpL1dpa2lT dGFydC9kcmFmdC0NCj4gd29sZi1lY3INCj4gPiAgaXQtbG9zdC1zZXJ2aWNlbGlzdGJvdW5kYXJ5 LnBwdCBXZSBoYWQgYSBjb3VwbGUgb2YgZm9sa3Mgc2F5aW5nDQo+ID4gdGhhdCB0aGlzIGlzIGEg dXNlZnVsIGV4dGVuc2lvbiB0byBMb1NULiBNYXJjIGFuZCBJIHdvdWxkIG5lZWQgYSBmZXcNCj4g PiBtb3JlIGZvbGtzIHdobyBzdXBwb3J0IHRoZSBpZGVhIGFuZCBhcmUgd2lsbGluZyB0byByZXZp ZXcgdGhlDQo+ID4gZG9jdW1lbnQuIFBsZWFzZSBkcm9wIHVzIGEgbm90ZS4gQ2lhbyBIYW5uZXMg JiBNYXJjDQo+ID4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+IEVjcml0QGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVk IHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnks IG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZl ZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQg ZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWls IGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClttZjJdDQo= From rbarnes@bbn.com Sun Mar 22 12:08:13 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 731373A6BD6 for ; Sun, 22 Mar 2009 12:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZsQZ4Y9FMZ6 for ; Sun, 22 Mar 2009 12:08:12 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 907593A6806 for ; Sun, 22 Mar 2009 12:08:12 -0700 (PDT) Received: from [128.89.252.20] (helo=dhcp-17f1.meeting.ietf.org) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LlT2K-00059n-Bh; Sun, 22 Mar 2009 15:08:44 -0400 Message-ID: <49C68CBB.5060306@bbn.com> Date: Sun, 22 Mar 2009 12:08:43 -0700 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Thomson, Martin" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ECRIT Subject: Re: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2009 19:08:13 -0000 +1 Thomson, Martin wrote: > I too understand how this is necessary to complete the solution. The instances where this is truly useful are probably limited, but it is easy to do. I don't have any feedback on the solution - what is suggested is similar enough to the service boundary option already in place. So on the principle of least surprise, this is a good document. > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Henning Schulzrinne >> Sent: Wednesday, 11 March 2009 8:01 PM >> To: ECRIT >> Subject: Re: [Ecrit] draft-wolf-ecrit-lost-servicelistboundary >> >> I believe that the service list boundary draft fills a small, but >> important, hole in the LoST architecture, as it makes it possible to >> deal effectively with regions having different services. (Without >> this, user agent might miss new services when they move.) >> >> Henning >> >>> Karl Heinz prepared some nice slides for our "virtual interim >>> meeting" to describe the ServiceListBoundary concept, see >> http://tools.ietf.org/wg/ecrit/trac/attachment/wiki/WikiStart/draft- >> wolf-ecr >>> it-lost-servicelistboundary.ppt We had a couple of folks saying >>> that this is a useful extension to LoST. Marc and I would need a few >>> more folks who support the idea and are willing to review the >>> document. Please drop us a note. Ciao Hannes & Marc >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.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://www.ietf.org/mailman/listinfo/ecrit > From Hannes.Tschofenig@gmx.net Mon Mar 23 07:32:31 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B0E128C11E for ; Mon, 23 Mar 2009 07:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GibIioTkopSL for ; Mon, 23 Mar 2009 07:32:30 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E1E2528C10E for ; Mon, 23 Mar 2009 07:32:29 -0700 (PDT) Received: (qmail invoked by alias); 23 Mar 2009 14:33:18 -0000 Received: from dhcp-43b3.meeting.ietf.org (EHLO 4FIL42860) [130.129.67.179] by mail.gmx.net (mp071) with SMTP; 23 Mar 2009 15:33:18 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/oyt5p5WvoZndEiBjlQh+/MQWRjpAQC1be4iY1mj LvdiW45h/7kb22 From: "Hannes Tschofenig" To: "'ECRIT'" Date: Mon, 23 Mar 2009 07:34:31 -0700 Message-ID: <007a01c9abc4$7bd4c090$f7148182@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmqeCwiBTbkqSCdR1KGZF0ZrSNq2ABS1ypQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Subject: [Ecrit] FW: Audio Streams for IETF 74 in San Francisco X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 14:32:31 -0000 FYI Jabber for the meeting: ecrit@jabber.ietf.org >-----Original Message----- >From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On >Behalf Of Morgan Sackett >Sent: 21 March, 2009 15:55 >To: ietf@ietf.org >Subject: Audio Streams for IETF 74 in San Francisco > >There will be MP3 audio streams of the meetings happening in >the breakout rooms. Specifically these are > >Continental 1&2 >Continental 3 >Continental 4 >Continental 5 >Continental 6 >Imperial A >Imperial B >Franciscan A > >Please refer to the online agenda at >http://tools.ietf.org/agenda/74/ to find a link to the stream >for each session. > >If there are concerns about the audio streams, there are a few >ways to get our attention. Via email either >audio@meeting.ietf.org, or noc@meeting.ietf.org . Via XMPP at >noc@jabber.ietf.org. > >Morgan Sackett >VP of Engineering > >VeriLAN Event Services, Inc. >215 SE Morrison Street >Portland, OR 97214 > >Tel: 503 907-1415 >Fax: 503 224-8833 > >msackett@verilan.com >www.verilan.com > > >This e-mail contains proprietary information and may be confidential. >If you are not the intended recipient of this e-mail, you are >hereby notified that any dissemination, distribution or >copying of this message is strictly prohibited. If you >received this message in error, please delete it immediately. > > > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf > From andreaf@cs.columbia.edu Mon Mar 23 09:31:17 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DEF328C1A6 for ; Mon, 23 Mar 2009 09:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eETUf4qKAS12 for ; Mon, 23 Mar 2009 09:31:15 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 89DC828C1C2 for ; Mon, 23 Mar 2009 09:31:15 -0700 (PDT) Received: from [128.59.20.159] (irt-af.cs.columbia.edu [128.59.20.159]) (user=agf2104 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2NGW443018861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 23 Mar 2009 12:32:05 -0400 (EDT) Message-ID: <49C7B98B.8060003@cs.columbia.edu> Date: Mon, 23 Mar 2009 12:32:11 -0400 From: "Andrea G. Forte" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: ECRIT Content-Type: multipart/alternative; boundary="------------090303000100080408010604" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Subject: [Ecrit] [Fwd: New Version Notification for draft-forte-ecrit-lost-extensions-02] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 16:31:17 -0000 This is a multi-part message in MIME format. --------------090303000100080408010604 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit https://datatracker.ietf.org/drafts/draft-forte-ecrit-lost-extensions/ A new version of I-D, draft-forte-ecrit-lost-extensions-02.txt has been successfuly submitted by Andrea Forte and posted to the IETF repository. Filename: draft-forte-ecrit-lost-extensions Revision: 02 Title: Location-to-Service Translation Protocol (LoST) Extensions Creation_date: 2009-03-23 WG ID: Independent Submission Number_of_pages: 11 Abstract: An important class of location-based services answer the question "What instances of this service are closest to me?" Examples include finding restaurants, gas stations, stores, automated teller machines, wireless access points (hot spots) or parking spaces. Currently, the Location-to-Service Translation (LoST) protocol only supports mapping locations to a single service based on service regions. This document describes an extension that allows queries "N nearest" and "within distance X". The IETF Secretariat. -- http://www.cs.columbia.edu/~andreaf --------------090303000100080408010604 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit https://datatracker.ietf.org/drafts/draft-forte-ecrit-lost-extensions/


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

Filename:	 draft-forte-ecrit-lost-extensions
Revision:	 02
Title:		 Location-to-Service Translation Protocol (LoST) Extensions
Creation_date:	 2009-03-23
WG ID:		 Independent Submission
Number_of_pages: 11

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


The IETF Secretariat.

--
http://www.cs.columbia.edu/~andreaf
--------------090303000100080408010604-- From andreaf@cs.columbia.edu Mon Mar 23 09:31:42 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E5FC28C191 for ; Mon, 23 Mar 2009 09:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grnsLs-6Ah2x for ; Mon, 23 Mar 2009 09:31:41 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 3820428C18D for ; Mon, 23 Mar 2009 09:31:41 -0700 (PDT) Received: from [128.59.20.159] (irt-af.cs.columbia.edu [128.59.20.159]) (user=agf2104 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2NGWUko019031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 23 Mar 2009 12:32:30 -0400 (EDT) Message-ID: <49C7B9A5.7020803@cs.columbia.edu> Date: Mon, 23 Mar 2009 12:32:37 -0400 From: "Andrea G. Forte" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: ECRIT Content-Type: multipart/alternative; boundary="------------020405030809090606080907" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Subject: [Ecrit] [Fwd: New Version Notification for draft-forte-ecrit-service-urn-policy-00] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 16:31:42 -0000 This is a multi-part message in MIME format. --------------020405030809090606080907 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit https://datatracker.ietf.org/drafts/draft-forte-ecrit-service-urn-policy/ A new version of I-D, draft-forte-ecrit-service-urn-policy-00.txt has been successfuly submitted by Andrea Forte and posted to the IETF repository. Filename: draft-forte-ecrit-service-urn-policy Revision: 00 Title: Policy for defining new service-identifying labels Creation_date: 2009-03-23 WG ID: Independent Submission Number_of_pages: 4 Abstract: In order to provide location-based services, descriptive terms for services need to be defined. This document updates the policy for defining new service-identifying labels. The IETF Secretariat. -- http://www.cs.columbia.edu/~andreaf --------------020405030809090606080907 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit https://datatracker.ietf.org/drafts/draft-forte-ecrit-service-urn-policy/

A new version of I-D, draft-forte-ecrit-service-urn-policy-00.txt has been successfuly submitted by Andrea Forte and posted to the IETF repository.

Filename:	 draft-forte-ecrit-service-urn-policy
Revision:	 00
Title:		 Policy for defining new service-identifying labels
Creation_date:	 2009-03-23
WG ID:		 Independent Submission
Number_of_pages: 4

Abstract:
In order to provide location-based services, descriptive terms for
services need to be defined.  This document updates the policy for
defining new service-identifying labels.
                                                                                  


The IETF Secretariat.

--
http://www.cs.columbia.edu/~andreaf
--------------020405030809090606080907-- From andreaf@cs.columbia.edu Mon Mar 23 09:32:23 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1433B28C1DC for ; Mon, 23 Mar 2009 09:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+yEuGvwv3Le for ; Mon, 23 Mar 2009 09:32:22 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id A934E28C1FB for ; Mon, 23 Mar 2009 09:32:17 -0700 (PDT) Received: from [128.59.20.159] (irt-af.cs.columbia.edu [128.59.20.159]) (user=agf2104 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2NGX7HH019201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 23 Mar 2009 12:33:07 -0400 (EDT) Message-ID: <49C7B9C9.6090205@cs.columbia.edu> Date: Mon, 23 Mar 2009 12:33:13 -0400 From: "Andrea G. Forte" User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: ECRIT Content-Type: multipart/alternative; boundary="------------050509010702000400040209" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Subject: [Ecrit] [Fwd: New Version Notification for draft-forte-ecrit-service-classification-02] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 16:32:23 -0000 This is a multi-part message in MIME format. --------------050509010702000400040209 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit https://datatracker.ietf.org/drafts/draft-forte-ecrit-service-classification/ A new version of I-D, draft-forte-ecrit-service-classification-02.txt has been successfuly submitted by Andrea Forte and posted to the IETF repository. Filename: draft-forte-ecrit-service-classification Revision: 02 Title: Labels for Common Location-Based Services Creation_date: 2009-03-23 WG ID: Independent Submission Number_of_pages: 11 Abstract: This document creates a registry for describing the types of services available at a specific location. The registry is then referenced by other protocols that need a common set of service terms as protocol constants. In particular, we define location-based service as either a point at a specific geographic location (e.g., bus stop) or a service covering a specific region (e.g., pizza delivery). The IETF Secretariat. -- http://www.cs.columbia.edu/~andreaf --------------050509010702000400040209 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit https://datatracker.ietf.org/drafts/draft-forte-ecrit-service-classification/


A new version of I-D, draft-forte-ecrit-service-classification-02.txt has been successfuly submitted by Andrea Forte and posted to the IETF repository.

Filename:	 draft-forte-ecrit-service-classification
Revision:	 02
Title:		 Labels for Common Location-Based Services
Creation_date:	 2009-03-23
WG ID:		 Independent Submission
Number_of_pages: 11

Abstract:
This document creates a registry for describing the types of services
available at a specific location.  The registry is then referenced by
other protocols that need a common set of service terms as protocol
constants.  In particular, we define location-based service as either
a point at a specific geographic location (e.g., bus stop) or a
service covering a specific region (e.g., pizza delivery).
                                                                                  


The IETF Secretariat.

--
http://www.cs.columbia.edu/~andreaf
--------------050509010702000400040209-- From brian.rosen@neustar.biz Mon Mar 23 16:18:12 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B806C3A6AF4 for ; Mon, 23 Mar 2009 16:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1h4zLMAIfj+N for ; Mon, 23 Mar 2009 16:18:11 -0700 (PDT) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id E3AB43A6C58 for ; Mon, 23 Mar 2009 16:18:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1237850330; x=1237936730; h=From:Date:Subject:Message-ID:Content-class:Content-Type; b=WZeiXiVvTgbGz62UlKsBwrCTVXtuT+3NK2HtxEZO6wEMMnM/3SjeoymRlG3hD3g+DimdMmabODJyY7 2Ys1k2tQ== Received: from ([10.31.13.50]) by chihiron2.nc.neustar.com with ESMTP id 5202415.12514433; Mon, 23 Mar 2009 19:18:34 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9AC0D.8C5BFB70" Date: Mon, 23 Mar 2009 19:17:16 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal to add "applicability" statement to -framework/-phonebcp Thread-Index: AcmsDYGO8YO7fnl/So+OZAJ64K1/SQ== From: "Rosen, Brian" To: "ECRIT" Subject: [Ecrit] Proposal to add "applicability" statement to -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 23:18:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9AC0D.8C5BFB70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the meeting, there was not consensus on having applicability statements. I would like to propose the following be added to both documents: =20 This document describes a typical Internet environment where the endpoint device bears most of the burden of implementing emergency calls, and the origination network has a minor role. The underlying specifications permit the network to take a more expansive role in emergency calls, which Is not covered extensively in this document. ------_=_NextPart_001_01C9AC0D.8C5BFB70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the meeting, there was not consensus on  = having applicability statements.  I would like to propose the following be = added to both documents:

 

This document describes a typical Internet = environment where the endpoint device bears most of the burden of implementing emergency = calls, and the origination network has a minor role.  The underlying specifications permit the network to take a more expansive role in = emergency calls, which Is not covered extensively in this document.

------_=_NextPart_001_01C9AC0D.8C5BFB70-- From rbarnes@bbn.com Mon Mar 23 16:26:40 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB2728C15F for ; Mon, 23 Mar 2009 16:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INTmdhOkeYsN for ; Mon, 23 Mar 2009 16:26:40 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 130AD28C159 for ; Mon, 23 Mar 2009 16:26:40 -0700 (PDT) Received: from [128.89.255.247] (helo=dhcp-17f1.meeting.ietf.org) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LltYH-0002cP-B3; Mon, 23 Mar 2009 19:27:29 -0400 Message-ID: <49C81AE0.6060301@bbn.com> Date: Mon, 23 Mar 2009 16:27:28 -0700 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Rosen, Brian" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ECRIT Subject: Re: [Ecrit] Proposal to add "applicability" statement to -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 23:26:40 -0000 Editorial changes: This document describes an architecture for emergency calling in the typical Internet environment, in which the calling device bears most of the burden of implementing emergency calls, and the caller's IP access network has a supporting role. The underlying specifications allow for the network to take a more expansive role in emergency calls, but such cases are not covered extensively in this document. Rosen, Brian wrote: > In the meeting, there was not consensus on having applicability > statements. I would like to propose the following be added to both > documents: > > > > This document describes a typical Internet environment where the > endpoint device bears most of the burden of implementing emergency > calls, and the origination network has a minor role. The underlying > specifications permit the network to take a more expansive role in > emergency calls, which Is not covered extensively in this document. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From brian.rosen@neustar.biz Mon Mar 23 16:31:25 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8B728C219 for ; Mon, 23 Mar 2009 16:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1U+pYq+RriBe for ; Mon, 23 Mar 2009 16:31:24 -0700 (PDT) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id 4BED128C1FE for ; Mon, 23 Mar 2009 16:31:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1237851122; x=1237937522; h=From:Date:Subject:Message-ID:Content-class:Content-Type:Content-Transfer-Encod ing; b=jHcW6GJe395mDvnlIiXsisOaBvtVWumKEthkmSak1X0SaxQJp3LsW48GkLDprI3egwp4QIlPX4Ic9u udJZSdGA== Received: from ([10.31.13.50]) by chihiron2.nc.neustar.com with ESMTP id 5202415.12514773; Mon, 23 Mar 2009 19:31:49 -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: Mon, 23 Mar 2009 19:30:35 -0400 Message-ID: In-Reply-To: <49C81AE0.6060301@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposal to add "applicability" statement to -framework/-phonebcp Thread-Index: AcmsDvdFArTBDeNQQf2CpZz687B14gAACe+Q References: <49C81AE0.6060301@bbn.com> From: "Rosen, Brian" To: "Richard Barnes" Cc: ECRIT Subject: Re: [Ecrit] Proposal to add "applicability" statement to -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 23:31:25 -0000 Nah, it's not the access network (AN) it's the calling service provider (SP) that is affected. The examples are adding location (who adds the Geolocation header) and the LoST query. Both of those would be done by the SIP calling network in, for example, an IMS system. Brian -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com]=20 Sent: Monday, March 23, 2009 7:27 PM To: Rosen, Brian Cc: ECRIT Subject: Re: [Ecrit] Proposal to add "applicability" statement to -framework/-phonebcp Editorial changes: This document describes an architecture for emergency calling in the=20 typical Internet environment, in which the calling device bears most of=20 the burden of implementing emergency calls, and the caller's IP access=20 network has a supporting role. The underlying specifications allow for=20 the network to take a more expansive role in emergency calls, but such=20 cases are not covered extensively in this document. Rosen, Brian wrote: > In the meeting, there was not consensus on having applicability > statements. I would like to propose the following be added to both > documents: >=20 > =20 >=20 > This document describes a typical Internet environment where the > endpoint device bears most of the burden of implementing emergency > calls, and the origination network has a minor role. The underlying > specifications permit the network to take a more expansive role in > emergency calls, which Is not covered extensively in this document. >=20 >=20 >=20 >=20 > ------------------------------------------------------------------------ >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From jmpolk@cisco.com Mon Mar 23 16:32:46 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D9773A6C27 for ; Mon, 23 Mar 2009 16:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgSaUNegUUdB for ; Mon, 23 Mar 2009 16:32:45 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 369EC3A6893 for ; Mon, 23 Mar 2009 16:32:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,410,1233532800"; d="scan'208";a="40216204" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 23 Mar 2009 23:33:34 +0000 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 n2NNXYPJ024784; Mon, 23 Mar 2009 19:33:34 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2NNXYlh015263; Mon, 23 Mar 2009 23:33:34 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 19:33:33 -0400 Received: from jmpolk-wxp01.cisco.com ([10.82.218.213]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 19:33:33 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Mar 2009 18:33:27 -0500 To: Richard Barnes , "Rosen, Brian" From: "James M. Polk" In-Reply-To: <49C81AE0.6060301@bbn.com> References: <49C81AE0.6060301@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 23 Mar 2009 23:33:33.0528 (UTC) FILETIME=[C7EA5580:01C9AC0F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1512; t=1237851214; x=1238715214; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Proposal=20to=20add=20=22appl icability=22=20statement=0A=20=20to=09-framework/-phonebcp |Sender:=20 |To:=20Richard=20Barnes=20,=20=22Rosen,=20 Brian=22=20; bh=9+UsIn/PttS0YZghMvwxWPE63OfZexBvIg8k0a/6yn4=; b=sWJbZg5kyT3A/ZDSB4Urxcpzvvzs5PFZrZiaPT1ktuOKEP74G4b7DxOnGU iHJ0hoL2ye5QAF49gP0QGd8CD5T2+mCoZvir82yOT3sPvEYHlZQBxgnXwcHU JqKWsB2Bf4; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: ECRIT Subject: Re: [Ecrit] Proposal to add "applicability" statement to -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 23:32:46 -0000 both versions beg the question: - so where are they covered? (re: the end of the last sentence) James At 06:27 PM 3/23/2009, Richard Barnes wrote: >Editorial changes: > >This document describes an architecture for emergency calling in the >typical Internet environment, in which the calling device bears most >of the burden of implementing emergency calls, and the caller's IP >access network has a supporting role. The underlying specifications >allow for the network to take a more expansive role in emergency >calls, but such cases are not covered extensively in this document. > > > >Rosen, Brian wrote: >>In the meeting, there was not consensus on having applicability >>statements. I would like to propose the following be added to both >>documents: >> >>This document describes a typical Internet environment where the >>endpoint device bears most of the burden of implementing emergency >>calls, and the origination network has a minor role. The underlying >>specifications permit the network to take a more expansive role in >>emergency calls, which Is not covered extensively in this document. >> >> >>------------------------------------------------------------------------ >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Mon Mar 23 16:33:53 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED58E3A6C27 for ; Mon, 23 Mar 2009 16:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VI+3kcLu0o3 for ; Mon, 23 Mar 2009 16:33:53 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 35A973A6AF1 for ; Mon, 23 Mar 2009 16:33:53 -0700 (PDT) Received: from [128.89.255.247] (helo=dhcp-17f1.meeting.ietf.org) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LltfG-0002kc-AJ; Mon, 23 Mar 2009 19:34:42 -0400 Message-ID: <49C81C91.5080500@bbn.com> Date: Mon, 23 Mar 2009 16:34:41 -0700 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "James M. Polk" References: <49C81AE0.6060301@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Rosen, Brian" , ECRIT Subject: Re: [Ecrit] Proposal to add "applicability" statement to -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 23:33:54 -0000 In a future document. I volunteer Ted. James M. Polk wrote: > both versions beg the question: > > - so where are they covered? > > (re: the end of the last sentence) > > James > > At 06:27 PM 3/23/2009, Richard Barnes wrote: >> Editorial changes: >> >> This document describes an architecture for emergency calling in the >> typical Internet environment, in which the calling device bears most >> of the burden of implementing emergency calls, and the caller's IP >> access network has a supporting role. The underlying specifications >> allow for the network to take a more expansive role in emergency >> calls, but such cases are not covered extensively in this document. >> >> >> >> Rosen, Brian wrote: >>> In the meeting, there was not consensus on having applicability >>> statements. I would like to propose the following be added to both >>> documents: >>> >>> This document describes a typical Internet environment where the >>> endpoint device bears most of the burden of implementing emergency >>> calls, and the origination network has a minor role. The underlying >>> specifications permit the network to take a more expansive role in >>> emergency calls, which Is not covered extensively in this document. >>> >>> >>> ------------------------------------------------------------------------ >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > From brian.rosen@neustar.biz Mon Mar 23 16:35:15 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD6313A6C27 for ; Mon, 23 Mar 2009 16:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2uWeJNc+VCV for ; Mon, 23 Mar 2009 16:35:14 -0700 (PDT) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id 559703A6AF1 for ; Mon, 23 Mar 2009 16:35:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1237851363; x=1237937763; h=From:Date:Subject:Message-ID:Content-class:Content-Type:Content-Transfer-Encod ing; b=dNEFSQ1wFfkdjnPYZ8H2WsFVojfUAaopmgC+xZwcG0jWQQrUlq5/svJCaxOtN8GUGgJLjq8vWNIaOW wy0vzHsA== Received: from ([10.31.13.50]) by chihiron2.nc.neustar.com with ESMTP id 5202415.12514874; Mon, 23 Mar 2009 19:35:55 -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: Mon, 23 Mar 2009 19:34:59 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposal to add "applicability" statement to -framework/-phonebcp Thread-Index: AcmsD9Dz34gOlSRuQBy78/PN5mcH/wAAAdgQ References: <49C81AE0.6060301@bbn.com> From: "Rosen, Brian" To: "James M. Polk" , "Richard Barnes" Cc: ECRIT Subject: Re: [Ecrit] Proposal to add "applicability" statement to -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 23:35:15 -0000 Some other document, in some other organization probably. Brian -----Original Message----- From: James M. Polk [mailto:jmpolk@cisco.com]=20 Sent: Monday, March 23, 2009 7:33 PM To: Richard Barnes; Rosen, Brian Cc: ECRIT Subject: Re: [Ecrit] Proposal to add "applicability" statement to -framework/-phonebcp both versions beg the question: - so where are they covered? (re: the end of the last sentence) James At 06:27 PM 3/23/2009, Richard Barnes wrote: >Editorial changes: > >This document describes an architecture for emergency calling in the=20 >typical Internet environment, in which the calling device bears most=20 >of the burden of implementing emergency calls, and the caller's IP=20 >access network has a supporting role. The underlying specifications=20 >allow for the network to take a more expansive role in emergency=20 >calls, but such cases are not covered extensively in this document. > > > >Rosen, Brian wrote: >>In the meeting, there was not consensus on having applicability >>statements. I would like to propose the following be added to both >>documents: >> >>This document describes a typical Internet environment where the >>endpoint device bears most of the burden of implementing emergency >>calls, and the origination network has a minor role. The underlying >>specifications permit the network to take a more expansive role in >>emergency calls, which Is not covered extensively in this document. >> >> >>---------------------------------------------------------------------- -- >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.ietf.org/mailman/listinfo/ecrit >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Mon Mar 23 16:55:09 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DDD428C0DF for ; Mon, 23 Mar 2009 16:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOWL0HSsq3RJ for ; Mon, 23 Mar 2009 16:55:08 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 5B91D3A6991 for ; Mon, 23 Mar 2009 16:55:08 -0700 (PDT) Received: from [128.89.255.247] (helo=dhcp-17f1.meeting.ietf.org) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1Lltzn-0002xB-AF; Mon, 23 Mar 2009 19:55:58 -0400 Message-ID: <49C82189.8070806@bbn.com> Date: Mon, 23 Mar 2009 16:55:53 -0700 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Rosen, Brian" References: <49C81AE0.6060301@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ECRIT Subject: Re: [Ecrit] Proposal to add "applicability" statement to -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 23:55:09 -0000 To be clear, it's the *Internet* Service Provider, not the *Voice* Service Provider, which may or may not be there. In summary, s/IP access network/Internet Service Provider/ Rosen, Brian wrote: > Nah, it's not the access network (AN) it's the calling service provider > (SP) that is affected. The examples are adding location (who adds the > Geolocation header) and the LoST query. Both of those would be done by > the SIP calling network in, for example, an IMS system. > > Brian > > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Monday, March 23, 2009 7:27 PM > To: Rosen, Brian > Cc: ECRIT > Subject: Re: [Ecrit] Proposal to add "applicability" statement to > -framework/-phonebcp > > Editorial changes: > > This document describes an architecture for emergency calling in the > typical Internet environment, in which the calling device bears most of > the burden of implementing emergency calls, and the caller's IP access > network has a supporting role. The underlying specifications allow for > the network to take a more expansive role in emergency calls, but such > cases are not covered extensively in this document. > > > > Rosen, Brian wrote: >> In the meeting, there was not consensus on having applicability >> statements. I would like to propose the following be added to both >> documents: >> >> >> >> This document describes a typical Internet environment where the >> endpoint device bears most of the burden of implementing emergency >> calls, and the origination network has a minor role. The underlying >> specifications permit the network to take a more expansive role in >> emergency calls, which Is not covered extensively in this document. >> >> >> >> >> > ------------------------------------------------------------------------ >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > From Martin.Dawson@andrew.com Mon Mar 23 16:57:09 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE64128C203 for ; Mon, 23 Mar 2009 16:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiwYDjkElHhP for ; Mon, 23 Mar 2009 16:57:09 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id DD3DC28C1D0 for ; Mon, 23 Mar 2009 16:57:08 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_23_19_17_57 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, 23 Mar 2009 19:17:57 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Mar 2009 18:57:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Mar 2009 18:57:50 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp Thread-Index: AcmsD9Dz34gOlSRuQBy78/PN5mcH/wAAAdgQAAC9XqA= References: <49C81AE0.6060301@bbn.com> From: "Dawson, Martin" To: "Rosen, Brian" , "James M. Polk" , "Richard Barnes" X-OriginalArrivalTime: 23 Mar 2009 23:57:52.0475 (UTC) FILETIME=[2D83FAB0:01C9AC13] Cc: ECRIT Subject: Re: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 23:57:09 -0000 So - "Network operators and voice service providers may play a more=0D=0Aex= pansive role in the processing of emergency calls but any such=0D=0Aadditio= nal measures are outside the scope of this document"=3F=0D=0A=0D=0AIt feels= like a pretty moot point to me. Why are we doing this=3F=0D=0A=0D=0ACheers= ,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: ecrit-bounce= s@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0AOf Rosen, Brian=0D= =0ASent: Tuesday, 24 March 2009 10:35 AM=0D=0ATo: James M. Polk; Richard Ba= rnes=0D=0ACc: ECRIT=0D=0ASubject: Re: [Ecrit] Proposal to add "applicabilit= y" statementto=0D=0A-framework/-phonebcp=0D=0A=0D=0ASome other document, in= some other organization probably.=0D=0A=0D=0ABrian=0D=0A=0D=0A-----Origina= l Message-----=0D=0AFrom: James M. Polk [mailto:jmpolk@cisco.com]=20=0D=0AS= ent: Monday, March 23, 2009 7:33 PM=0D=0ATo: Richard Barnes; Rosen, Brian=0D= =0ACc: ECRIT=0D=0ASubject: Re: [Ecrit] Proposal to add "applicability" stat= ement to=0D=0A-framework/-phonebcp=0D=0A=0D=0Aboth versions beg the questio= n:=0D=0A=0D=0A - so where are they covered=3F=0D=0A=0D=0A(re: the e= nd of the last sentence)=0D=0A=0D=0AJames=0D=0A=0D=0AAt 06:27 PM 3/23/2009,= Richard Barnes wrote:=0D=0A>Editorial changes:=0D=0A>=0D=0A>This document = describes an architecture for emergency calling in the=20=0D=0A>typical Int= ernet environment, in which the calling device bears most=20=0D=0A>of the b= urden of implementing emergency calls, and the caller's IP=20=0D=0A>access = network has a supporting role. The underlying specifications=20=0D=0A>allo= w for the network to take a more expansive role in emergency=20=0D=0A>calls= , but such cases are not covered extensively in this document.=0D=0A>=0D=0A= >=0D=0A>=0D=0A>Rosen, Brian wrote:=0D=0A>>In the meeting, there was not con= sensus on having applicability=0D=0A>>statements. I would like to propose= the following be added to both=0D=0A>>documents:=0D=0A>>=0D=0A>>This docum= ent describes a typical Internet environment where the=0D=0A>>endpoint devi= ce bears most of the burden of implementing emergency=0D=0A>>calls, and the= origination network has a minor role. The underlying=0D=0A>>specification= s permit the network to take a more expansive role in=0D=0A>>emergency call= s, which Is not covered extensively in this document.=0D=0A>>=0D=0A>>=0D=0A= >>----------------------------------------------------------------------=0D= =0A--=0D=0A>>_______________________________________________=0D=0A>>Ecrit m= ailing list=0D=0A>>Ecrit@ietf.org=0D=0A>>https://www.ietf.org/mailman/listi= nfo/ecrit=0D=0A>_______________________________________________=0D=0A>Ecrit= mailing list=0D=0A>Ecrit@ietf.org=0D=0A>https://www.ietf.org/mailman/listi= nfo/ecrit=0D=0A=0D=0A_______________________________________________=0D=0AE= crit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman/lis= tinfo/ecrit=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 From Martin.Dawson@andrew.com Mon Mar 23 16:58:12 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 380783A6933 for ; Mon, 23 Mar 2009 16:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.153 X-Spam-Level: X-Spam-Status: No, score=-1.153 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NnyXJClpg4m for ; Mon, 23 Mar 2009 16:58:11 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 684CA28C1E2 for ; Mon, 23 Mar 2009 16:58:07 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_23_19_18_56 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, 23 Mar 2009 19:18:56 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Mar 2009 18:58:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Mar 2009 18:58:49 -0500 Message-ID: In-Reply-To: <49C82189.8070806@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp Thread-Index: AcmsEut4+l8goxZ0TtCSHi0UMF6ZdQAAE3ig References: <49C81AE0.6060301@bbn.com> <49C82189.8070806@bbn.com> From: "Dawson, Martin" To: "Richard Barnes" , "Rosen, Brian" X-OriginalArrivalTime: 23 Mar 2009 23:58:51.0960 (UTC) FILETIME=[50F8AB80:01C9AC13] Cc: ECRIT Subject: Re: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2009 23:58:12 -0000 Isn't that the other way around=3F The VSP may or may not be there=3F=0D=0A=0D= =0A-----Original Message-----=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecr= it-bounces@ietf.org] On Behalf=0D=0AOf Richard Barnes=0D=0ASent: Tuesday, 2= 4 March 2009 10:56 AM=0D=0ATo: Rosen, Brian=0D=0ACc: ECRIT=0D=0ASubject: Re= : [Ecrit] Proposal to add "applicability" statementto=0D=0A-framework/-phon= ebcp=0D=0A=0D=0ATo be clear, it's the *Internet* Service Provider, not the = *Voice*=20=0D=0AService Provider, which may or may not be there.=0D=0A=0D=0A= In summary, s/IP access network/Internet Service Provider/=0D=0A=0D=0A=0D=0A= Rosen, Brian wrote:=0D=0A> Nah, it's not the access network (AN) it's the c= alling service=0D=0Aprovider=0D=0A> (SP) that is affected. The examples ar= e adding location (who adds the=0D=0A> Geolocation header) and the LoST que= ry. Both of those would be done=0D=0Aby=0D=0A> the SIP calling network in,= for example, an IMS system.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A> -----O= riginal Message-----=0D=0A> From: Richard Barnes [mailto:rbarnes@bbn.com] =0D= =0A> Sent: Monday, March 23, 2009 7:27 PM=0D=0A> To: Rosen, Brian=0D=0A> Cc= : ECRIT=0D=0A> Subject: Re: [Ecrit] Proposal to add "applicability" stateme= nt to=0D=0A> -framework/-phonebcp=0D=0A>=20=0D=0A> Editorial changes:=0D=0A= >=20=0D=0A> This document describes an architecture for emergency calling i= n the=20=0D=0A> typical Internet environment, in which the calling device b= ears most=0D=0Aof=20=0D=0A> the burden of implementing emergency calls, and= the caller's IP access=0D=0A=0D=0A> network has a supporting role. The un= derlying specifications allow=0D=0Afor=20=0D=0A> the network to take a more= expansive role in emergency calls, but such=0D=0A=0D=0A> cases are not cov= ered extensively in this document.=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> Ros= en, Brian wrote:=0D=0A>> In the meeting, there was not consensus on having= applicability=0D=0A>> statements. I would like to propose the following b= e added to both=0D=0A>> documents:=0D=0A>>=0D=0A>> =20=0D=0A>>=0D=0A>> This= document describes a typical Internet environment where the=0D=0A>> endpoi= nt device bears most of the burden of implementing emergency=0D=0A>> calls,= and the origination network has a minor role. The underlying=0D=0A>> spec= ifications permit the network to take a more expansive role in=0D=0A>> emer= gency calls, which Is not covered extensively in this document.=0D=0A>>=0D=0A= >>=0D=0A>>=0D=0A>>=0D=0A>>=0D=0A>=0D=0A------------------------------------= ------------------------------------=0D=0A>> ______________________________= _________________=0D=0A>> Ecrit mailing list=0D=0A>> Ecrit@ietf.org=0D=0A>>= https://www.ietf.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A_______________= ________________________________=0D=0AEcrit mailing list=0D=0AEcrit@ietf.or= g=0D=0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A-------------= ---------------------------------------------------------------------------= --------=0D=0AThis message is for the designated recipient only and may=0D=0A= contain privileged, proprietary, or otherwise private information. =20=0D=0A= If you have received it in error, please notify the sender=0D=0Aimmediately= and delete the original. Any unauthorized use of=0D=0Athis email is prohi= bited.=0D=0A---------------------------------------------------------------= ---------------------------------=0D=0A[mf2]=0D=0A From rbarnes@bbn.com Mon Mar 23 17:03:20 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AF693A6991 for ; Mon, 23 Mar 2009 17:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id it0JRK0AUvkX for ; Mon, 23 Mar 2009 17:03:19 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 57DBB3A6C86 for ; Mon, 23 Mar 2009 17:03:07 -0700 (PDT) Received: from [128.89.255.247] (helo=dhcp-17f1.meeting.ietf.org) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1Llu7W-00033N-Bn; Mon, 23 Mar 2009 20:03:55 -0400 Message-ID: <49C82369.2070003@bbn.com> Date: Mon, 23 Mar 2009 17:03:53 -0700 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Dawson, Martin" References: <49C81AE0.6060301@bbn.com> <49C82189.8070806@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Rosen, Brian" , ECRIT Subject: Re: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 00:03:20 -0000 That's what I meant: -- ISP plays a role in Framework (i.e., it has requirements) -- VSP does not (no requirements - may not be there) Dawson, Martin wrote: > Isn't that the other way around? The VSP may or may not be there? > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Richard Barnes > Sent: Tuesday, 24 March 2009 10:56 AM > To: Rosen, Brian > Cc: ECRIT > Subject: Re: [Ecrit] Proposal to add "applicability" statementto > -framework/-phonebcp > > To be clear, it's the *Internet* Service Provider, not the *Voice* > Service Provider, which may or may not be there. > > In summary, s/IP access network/Internet Service Provider/ > > > Rosen, Brian wrote: >> Nah, it's not the access network (AN) it's the calling service > provider >> (SP) that is affected. The examples are adding location (who adds the >> Geolocation header) and the LoST query. Both of those would be done > by >> the SIP calling network in, for example, an IMS system. >> >> Brian >> >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Monday, March 23, 2009 7:27 PM >> To: Rosen, Brian >> Cc: ECRIT >> Subject: Re: [Ecrit] Proposal to add "applicability" statement to >> -framework/-phonebcp >> >> Editorial changes: >> >> This document describes an architecture for emergency calling in the >> typical Internet environment, in which the calling device bears most > of >> the burden of implementing emergency calls, and the caller's IP access > >> network has a supporting role. The underlying specifications allow > for >> the network to take a more expansive role in emergency calls, but such > >> cases are not covered extensively in this document. >> >> >> >> Rosen, Brian wrote: >>> In the meeting, there was not consensus on having applicability >>> statements. I would like to propose the following be added to both >>> documents: >>> >>> >>> >>> This document describes a typical Internet environment where the >>> endpoint device bears most of the burden of implementing emergency >>> calls, and the origination network has a minor role. The underlying >>> specifications permit the network to take a more expansive role in >>> emergency calls, which Is not covered extensively in this document. >>> >>> >>> >>> >>> > ------------------------------------------------------------------------ >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------------------------------ > 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] > > From jmpolk@cisco.com Mon Mar 23 17:03:39 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29C8A3A6A43 for ; Mon, 23 Mar 2009 17:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10sIBdGum3VD for ; Mon, 23 Mar 2009 17:03:38 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 4D19F3A6A3A for ; Mon, 23 Mar 2009 17:03:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,410,1233532800"; d="scan'208";a="145838234" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-3.cisco.com with ESMTP; 24 Mar 2009 00:04:28 +0000 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 n2O04ScE005069; Mon, 23 Mar 2009 20:04:28 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2O04Spu013061; Tue, 24 Mar 2009 00:04:28 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 20:04:28 -0400 Received: from jmpolk-wxp01.cisco.com ([10.82.218.213]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Mar 2009 20:04:27 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Mar 2009 19:04:21 -0500 To: "Rosen, Brian" , "Richard Barnes" From: "James M. Polk" In-Reply-To: References: <49C81AE0.6060301@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 24 Mar 2009 00:04:27.0507 (UTC) FILETIME=[18F91430:01C9AC14] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2064; t=1237853068; x=1238717068; 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]=20Proposal=20to=20add=20=22appl icability=22=20statement=20=0A=20=20to=09-framework/-phonebc p |Sender:=20 |To:=20=22Rosen,=20Brian=22=20,=0A =20=20=20=20=20=20=20=20=22Richard=20Barnes=22=20; bh=1+BowpiReiXrwRXP/Ul5ZShJOtshczdrCib5LJP0iTI=; b=GnV3ALY36Fy7/+etvFr7LIEOqD/tWKs16ApOXjr5g8c/xcn8Nj0wHhYVcE EI0TkexJGCzrsuhUwqNe+Jymk1UFLUq0fEoDldA2BfmfR3kd3D2ciqJpUNg8 sYpFg56CKJ; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: ECRIT Subject: Re: [Ecrit] Proposal to add "applicability" statement to -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 00:03:39 -0000 At 06:34 PM 3/23/2009, Rosen, Brian wrote: >Some other document, in some other organization probably. could that be said - to leave the read knowing we are purposely not answering the question "here". >Brian > >-----Original Message----- >From: James M. Polk [mailto:jmpolk@cisco.com] >Sent: Monday, March 23, 2009 7:33 PM >To: Richard Barnes; Rosen, Brian >Cc: ECRIT >Subject: Re: [Ecrit] Proposal to add "applicability" statement to >-framework/-phonebcp > >both versions beg the question: > > - so where are they covered? > >(re: the end of the last sentence) > >James > >At 06:27 PM 3/23/2009, Richard Barnes wrote: > >Editorial changes: > > > >This document describes an architecture for emergency calling in the > >typical Internet environment, in which the calling device bears most > >of the burden of implementing emergency calls, and the caller's IP > >access network has a supporting role. The underlying specifications > >allow for the network to take a more expansive role in emergency > >calls, but such cases are not covered extensively in this document. > > > > > > > >Rosen, Brian wrote: > >>In the meeting, there was not consensus on having applicability > >>statements. I would like to propose the following be added to both > >>documents: > >> > >>This document describes a typical Internet environment where the > >>endpoint device bears most of the burden of implementing emergency > >>calls, and the origination network has a minor role. The underlying > >>specifications permit the network to take a more expansive role in > >>emergency calls, which Is not covered extensively in this document. > >> > >> > >>---------------------------------------------------------------------- >-- > >>_______________________________________________ > >>Ecrit mailing list > >>Ecrit@ietf.org > >>https://www.ietf.org/mailman/listinfo/ecrit > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Mon Mar 23 17:05:47 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E513728C22A for ; Mon, 23 Mar 2009 17:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3Ci6aRvikMQ for ; Mon, 23 Mar 2009 17:05:47 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 092163A6A92 for ; Mon, 23 Mar 2009 17:05:47 -0700 (PDT) Received: from [128.89.255.247] (helo=dhcp-17f1.meeting.ietf.org) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LluA8-00033n-Ak; Mon, 23 Mar 2009 20:06:36 -0400 Message-ID: <49C82409.30806@bbn.com> Date: Mon, 23 Mar 2009 17:06:33 -0700 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "James M. Polk" References: <49C81AE0.6060301@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Rosen, Brian" , ECRIT Subject: Re: [Ecrit] Proposal to add "applicability" statement to -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 00:05:48 -0000 Updated proposal: This document describes an architecture for emergency calling in the typical Internet environment, in which the calling device bears most of the burden of implementing emergency calls, and the caller's Internet Service Provider has a supporting role. The underlying specifications allow for the network to take a more expansive role in emergency calls, but such cases are not covered extensively in this document (they are left for future study in other documents). James M. Polk wrote: > At 06:34 PM 3/23/2009, Rosen, Brian wrote: >> Some other document, in some other organization probably. > > could that be said - to leave the read knowing we are purposely not > answering the question "here". > > >> Brian >> >> -----Original Message----- >> From: James M. Polk [mailto:jmpolk@cisco.com] >> Sent: Monday, March 23, 2009 7:33 PM >> To: Richard Barnes; Rosen, Brian >> Cc: ECRIT >> Subject: Re: [Ecrit] Proposal to add "applicability" statement to >> -framework/-phonebcp >> >> both versions beg the question: >> >> - so where are they covered? >> >> (re: the end of the last sentence) >> >> James >> >> At 06:27 PM 3/23/2009, Richard Barnes wrote: >> >Editorial changes: >> > >> >This document describes an architecture for emergency calling in the >> >typical Internet environment, in which the calling device bears most >> >of the burden of implementing emergency calls, and the caller's IP >> >access network has a supporting role. The underlying specifications >> >allow for the network to take a more expansive role in emergency >> >calls, but such cases are not covered extensively in this document. >> > >> > >> > >> >Rosen, Brian wrote: >> >>In the meeting, there was not consensus on having applicability >> >>statements. I would like to propose the following be added to both >> >>documents: >> >> >> >>This document describes a typical Internet environment where the >> >>endpoint device bears most of the burden of implementing emergency >> >>calls, and the origination network has a minor role. The underlying >> >>specifications permit the network to take a more expansive role in >> >>emergency calls, which Is not covered extensively in this document. >> >> >> >> >> >>---------------------------------------------------------------------- >> -- >> >>_______________________________________________ >> >>Ecrit mailing list >> >>Ecrit@ietf.org >> >>https://www.ietf.org/mailman/listinfo/ecrit >> >_______________________________________________ >> >Ecrit mailing list >> >Ecrit@ietf.org >> >https://www.ietf.org/mailman/listinfo/ecrit > > From drage@alcatel-lucent.com Mon Mar 23 17:19:42 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D5623A69DC for ; Mon, 23 Mar 2009 17:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.247 X-Spam-Level: X-Spam-Status: No, score=-6.247 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZowMvOQn-T5K for ; Mon, 23 Mar 2009 17:19:41 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 790923A6933 for ; Mon, 23 Mar 2009 17:19:41 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2O0KH4i013983 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Mar 2009 01:20:17 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 24 Mar 2009 01:20:17 +0100 From: "DRAGE, Keith (Keith)" To: Richard Barnes , "James M. Polk" Date: Tue, 24 Mar 2009 01:20:16 +0100 Thread-Topic: [Ecrit] Proposal to add "applicability" statement to -framework/-phonebcp Thread-Index: AcmsFGocVsseKsUiREeSPD+7wPmlIQAAXobA Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D67577C4D8@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <49C81AE0.6060301@bbn.com> <49C82409.30806@bbn.com> In-Reply-To: <49C82409.30806@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "Rosen, Brian" , ECRIT Subject: Re: [Ecrit] Proposal to add "applicability" statement to -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 00:19:42 -0000 Where you have said "network to take a more expansive role", I think genera= lly we need to say we have not addressed the issues that may arise where it= does so. That is essentially the crux of the difference between the two mo= dels, and we have agreed in the past that there is a framework/phonebcp pha= se 2 will attempt to address this issue. Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Richard Barnes > Sent: Tuesday, March 24, 2009 12:07 AM > To: James M. Polk > Cc: Rosen, Brian; ECRIT > Subject: Re: [Ecrit] Proposal to add "applicability"=20 > statement to -framework/-phonebcp >=20 > Updated proposal: >=20 > This document describes an architecture for emergency calling=20 > in the typical Internet environment, in which the calling=20 > device bears most of the burden of implementing emergency=20 > calls, and the caller's Internet Service Provider has a=20 > supporting role. The underlying specifications allow for the=20 > network to take a more expansive role in emergency calls, but=20 > such cases are not covered extensively in this document (they=20 > are left for future study in other documents). >=20 >=20 >=20 > James M. Polk wrote: > > At 06:34 PM 3/23/2009, Rosen, Brian wrote: > >> Some other document, in some other organization probably. > >=20 > > could that be said - to leave the read knowing we are purposely not=20 > > answering the question "here". > >=20 > >=20 > >> Brian > >> > >> -----Original Message----- > >> From: James M. Polk [mailto:jmpolk@cisco.com] > >> Sent: Monday, March 23, 2009 7:33 PM > >> To: Richard Barnes; Rosen, Brian > >> Cc: ECRIT > >> Subject: Re: [Ecrit] Proposal to add "applicability" statement to=20 > >> -framework/-phonebcp > >> > >> both versions beg the question: > >> > >> - so where are they covered? > >> > >> (re: the end of the last sentence) > >> > >> James > >> > >> At 06:27 PM 3/23/2009, Richard Barnes wrote: > >> >Editorial changes: > >> > > >> >This document describes an architecture for emergency=20 > calling in the=20 > >> >typical Internet environment, in which the calling device=20 > bears most=20 > >> >of the burden of implementing emergency calls, and the=20 > caller's IP=20 > >> >access network has a supporting role. The underlying=20 > specifications=20 > >> >allow for the network to take a more expansive role in emergency=20 > >> >calls, but such cases are not covered extensively in this=20 > document. > >> > > >> > > >> > > >> >Rosen, Brian wrote: > >> >>In the meeting, there was not consensus on having applicability=20 > >> >>statements. I would like to propose the following be=20 > added to both > >> >>documents: > >> >> > >> >>This document describes a typical Internet environment where the=20 > >> >>endpoint device bears most of the burden of implementing=20 > emergency=20 > >> >>calls, and the origination network has a minor role. The=20 > >> >>underlying specifications permit the network to take a more=20 > >> >>expansive role in emergency calls, which Is not covered=20 > extensively in this document. > >> >> > >> >> > >>=20 > >>------------------------------------------------------------------- > >> >>--- > >> -- > >> >>_______________________________________________ > >> >>Ecrit mailing list > >> >>Ecrit@ietf.org > >> >>https://www.ietf.org/mailman/listinfo/ecrit > >> >_______________________________________________ > >> >Ecrit mailing list > >> >Ecrit@ietf.org > >> >https://www.ietf.org/mailman/listinfo/ecrit > >=20 > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From rbarnes@bbn.com Mon Mar 23 17:41:55 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF84628C272 for ; Mon, 23 Mar 2009 17:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ye86C5jc+Hax for ; Mon, 23 Mar 2009 17:41:55 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id D6C9028C271 for ; Mon, 23 Mar 2009 17:41:54 -0700 (PDT) Received: from [128.89.252.40] (helo=dhcp-17f1.meeting.ietf.org) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Lluj5-0002kj-FF; Mon, 23 Mar 2009 20:42:44 -0400 Message-ID: <49C82C82.7010709@bbn.com> Date: Mon, 23 Mar 2009 17:42:42 -0700 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <49C81AE0.6060301@bbn.com> <49C82409.30806@bbn.com> <28B7C3AA2A7ABA4A841F11217ABE78D67577C4D8@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D67577C4D8@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Rosen, Brian" , ECRIT Subject: Re: [Ecrit] Proposal to add "applicability" statement to -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 00:41:56 -0000 "but such cases (and any associated issues) are not covered extensively in this document; rather, they are left for future study in other documents." DRAGE, Keith (Keith) wrote: > Where you have said "network to take a more expansive role", I think generally we need to say we have not addressed the issues that may arise where it does so. That is essentially the crux of the difference between the two models, and we have agreed in the past that there is a framework/phonebcp phase 2 will attempt to address this issue. > > Keith > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf Of Richard Barnes >> Sent: Tuesday, March 24, 2009 12:07 AM >> To: James M. Polk >> Cc: Rosen, Brian; ECRIT >> Subject: Re: [Ecrit] Proposal to add "applicability" >> statement to -framework/-phonebcp >> >> Updated proposal: >> >> This document describes an architecture for emergency calling >> in the typical Internet environment, in which the calling >> device bears most of the burden of implementing emergency >> calls, and the caller's Internet Service Provider has a >> supporting role. The underlying specifications allow for the >> network to take a more expansive role in emergency calls, but >> such cases are not covered extensively in this document (they >> are left for future study in other documents). >> >> >> >> James M. Polk wrote: >>> At 06:34 PM 3/23/2009, Rosen, Brian wrote: >>>> Some other document, in some other organization probably. >>> could that be said - to leave the read knowing we are purposely not >>> answering the question "here". >>> >>> >>>> Brian >>>> >>>> -----Original Message----- >>>> From: James M. Polk [mailto:jmpolk@cisco.com] >>>> Sent: Monday, March 23, 2009 7:33 PM >>>> To: Richard Barnes; Rosen, Brian >>>> Cc: ECRIT >>>> Subject: Re: [Ecrit] Proposal to add "applicability" statement to >>>> -framework/-phonebcp >>>> >>>> both versions beg the question: >>>> >>>> - so where are they covered? >>>> >>>> (re: the end of the last sentence) >>>> >>>> James >>>> >>>> At 06:27 PM 3/23/2009, Richard Barnes wrote: >>>>> Editorial changes: >>>>> >>>>> This document describes an architecture for emergency >> calling in the >>>>> typical Internet environment, in which the calling device >> bears most >>>>> of the burden of implementing emergency calls, and the >> caller's IP >>>>> access network has a supporting role. The underlying >> specifications >>>>> allow for the network to take a more expansive role in emergency >>>>> calls, but such cases are not covered extensively in this >> document. >>>>> >>>>> >>>>> Rosen, Brian wrote: >>>>>> In the meeting, there was not consensus on having applicability >>>>>> statements. I would like to propose the following be >> added to both >>>>>> documents: >>>>>> >>>>>> This document describes a typical Internet environment where the >>>>>> endpoint device bears most of the burden of implementing >> emergency >>>>>> calls, and the origination network has a minor role. The >>>>>> underlying specifications permit the network to take a more >>>>>> expansive role in emergency calls, which Is not covered >> extensively in this document. >>>>>> >>>> ------------------------------------------------------------------- >>>>>> --- >>>> -- >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> From brian.rosen@neustar.biz Mon Mar 23 19:35:47 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C74573A6B59 for ; Mon, 23 Mar 2009 19:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdmXwoumCb6N for ; Mon, 23 Mar 2009 19:35:46 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 971AD3A697A for ; Mon, 23 Mar 2009 19:35:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1237862195; x=1237948595; h=From:Date:Subject:Message-ID:Content-class:Content-Type; b=nObatP3fZFN7kOSUuXFLWUHQ/FwoP18DWebkXX546aW2v3Q/aEyMT0GT9VzqnjxgLfNuALSoTOki40 oB94hY0Q== Received: from ([10.31.13.50]) by stihiron2.va.neustar.com with ESMTP id 5202732.16846726; Mon, 23 Mar 2009 22:36:22 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9AC29.46596EF8" Date: Mon, 23 Mar 2009 22:36:02 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp Thread-Index: AcmsKUZZa39D9bCbRi66AXwxf811iA== From: "Rosen, Brian" To: , Cc: ecrit@ietf.org Subject: Re: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 02:35:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9AC29.46596EF8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Tm8uDQoNClRoZSBJU1AgcmVxdWlyZW1lbnRzIGFyZSB1bndhaXZlcmluZy4gIFRoZSBWU1AgcmVx dWlyZW1lbnRzIGNoYW5nZS4gIFRoZSBWU1AsIG5vdCB0aGUgSVNQIGFkZHMgbG9jYXRpb24gYW5k IHJvdXRlLCBub3QgdGhlIElTUC4NCg0KQnJpYW4NCi0tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LS0NCkZyb206IFJpY2hhcmQgQmFybmVzDQpUbzogRGF3c29uLCBNYXJ0aW4NCkNjOiBCcmlhbiBS b3Nlbg0KQ2M6IEVDUklUDQpTZW50OiBNYXIgMjMsIDIwMDkgNTowMyBQTQ0KU3ViamVjdDogUmU6 IFtFY3JpdF0gUHJvcG9zYWwgdG8gYWRkICJhcHBsaWNhYmlsaXR5IiBzdGF0ZW1lbnR0bwktZnJh bWV3b3JrLy1waG9uZWJjcA0KDQpUaGF0J3Mgd2hhdCBJIG1lYW50Og0KLS0gSVNQIHBsYXlzIGEg cm9sZSBpbiBGcmFtZXdvcmsgKGkuZS4sIGl0IGhhcyByZXF1aXJlbWVudHMpDQotLSBWU1AgZG9l cyBub3QgKG5vIHJlcXVpcmVtZW50cyAtIG1heSBub3QgYmUgdGhlcmUpDQoNCkRhd3NvbiwgTWFy dGluIHdyb3RlOg0KPiBJc24ndCB0aGF0IHRoZSBvdGhlciB3YXkgYXJvdW5kPyBUaGUgVlNQIG1h eSBvciBtYXkgbm90IGJlIHRoZXJlPw0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogZWNyaXQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmVjcml0LWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBSaWNoYXJkIEJhcm5lcw0KPiBTZW50OiBUdWVzZGF5LCAy NCBNYXJjaCAyMDA5IDEwOjU2IEFNDQo+IFRvOiBSb3NlbiwgQnJpYW4NCj4gQ2M6IEVDUklUDQo+ IFN1YmplY3Q6IFJlOiBbRWNyaXRdIFByb3Bvc2FsIHRvIGFkZCAiYXBwbGljYWJpbGl0eSIgc3Rh dGVtZW50dG8NCj4gLWZyYW1ld29yay8tcGhvbmViY3ANCj4gDQo+IFRvIGJlIGNsZWFyLCBpdCdz IHRoZSAqSW50ZXJuZXQqIFNlcnZpY2UgUHJvdmlkZXIsIG5vdCB0aGUgKlZvaWNlKiANCj4gU2Vy dmljZSBQcm92aWRlciwgd2hpY2ggbWF5IG9yIG1heSBub3QgYmUgdGhlcmUuDQo+IA0KPiBJbiBz dW1tYXJ5LCBzL0lQIGFjY2VzcyBuZXR3b3JrL0ludGVybmV0IFNlcnZpY2UgUHJvdmlkZXIvDQo+ IA0KPiANCj4gUm9zZW4sIEJyaWFuIHdyb3RlOg0KPj4gTmFoLCBpdCdzIG5vdCB0aGUgYWNjZXNz IG5ldHdvcmsgKEFOKSBpdCdzIHRoZSBjYWxsaW5nIHNlcnZpY2UNCj4gcHJvdmlkZXINCj4+IChT UCkgdGhhdCBpcyBhZmZlY3RlZC4gIFRoZSBleGFtcGxlcyBhcmUgYWRkaW5nIGxvY2F0aW9uICh3 aG8gYWRkcyB0aGUNCj4+IEdlb2xvY2F0aW9uIGhlYWRlcikgYW5kIHRoZSBMb1NUIHF1ZXJ5LiAg Qm90aCBvZiB0aG9zZSB3b3VsZCBiZSBkb25lDQo+IGJ5DQo+PiB0aGUgU0lQIGNhbGxpbmcgbmV0 d29yayBpbiwgZm9yIGV4YW1wbGUsIGFuIElNUyBzeXN0ZW0uDQo+Pg0KPj4gQnJpYW4NCj4+DQo+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogUmljaGFyZCBCYXJuZXMgW21h aWx0bzpyYmFybmVzQGJibi5jb21dIA0KPj4gU2VudDogTW9uZGF5LCBNYXJjaCAyMywgMjAwOSA3 OjI3IFBNDQo+PiBUbzogUm9zZW4sIEJyaWFuDQo+PiBDYzogRUNSSVQNCj4+IFN1YmplY3Q6IFJl OiBbRWNyaXRdIFByb3Bvc2FsIHRvIGFkZCAiYXBwbGljYWJpbGl0eSIgc3RhdGVtZW50IHRvDQo+ PiAtZnJhbWV3b3JrLy1waG9uZWJjcA0KPj4NCj4+IEVkaXRvcmlhbCBjaGFuZ2VzOg0KPj4NCj4+ IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIGFyY2hpdGVjdHVyZSBmb3IgZW1lcmdlbmN5IGNh bGxpbmcgaW4gdGhlIA0KPj4gdHlwaWNhbCBJbnRlcm5ldCBlbnZpcm9ubWVudCwgaW4gd2hpY2gg dGhlIGNhbGxpbmcgZGV2aWNlIGJlYXJzIG1vc3QNCj4gb2YgDQo+Pg0KDQotLS0tLS1PcmlnaW5h bCBNZXNzYWdlIFRydW5jYXRlZC0tLS0tLQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K QnJpYW4gUm9zZW4NCk5ldVN0YXINCig3MjQpIDM4Mi0xMDUxDQpicmlhbi5yb3NlbkBuZXVzdGFy LmJpeg0K ------_=_NextPart_001_01C9AC29.46596EF8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTEuNTkiPg0KPFRJVExFPlJlOiBbRWNyaXRd IFByb3Bvc2FsIHRvIGFkZCAmcXVvdDthcHBsaWNhYmlsaXR5JnF1b3Q7IHN0YXRlbWVudHRvCS1m cmFtZXdvcmsvLXBob25lYmNwPC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KPCEtLSBDb252ZXJ0 ZWQgZnJvbSB0ZXh0L3BsYWluIGZvcm1hdCAtLT4NCg0KPFA+PEZPTlQgU0laRT0yPk5vLjxCUj4N CjxCUj4NClRoZSBJU1AgcmVxdWlyZW1lbnRzIGFyZSB1bndhaXZlcmluZy4mbmJzcDsgVGhlIFZT UCByZXF1aXJlbWVudHMgY2hhbmdlLiZuYnNwOyBUaGUgVlNQLCBub3QgdGhlIElTUCBhZGRzIGxv Y2F0aW9uIGFuZCByb3V0ZSwgbm90IHRoZSBJU1AuPEJSPg0KPEJSPg0KQnJpYW48QlI+DQotLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0tPEJSPg0KRnJvbTogUmljaGFyZCBCYXJuZXM8QlI+DQpU bzogRGF3c29uLCBNYXJ0aW48QlI+DQpDYzogQnJpYW4gUm9zZW48QlI+DQpDYzogRUNSSVQ8QlI+ DQpTZW50OiBNYXIgMjMsIDIwMDkgNTowMyBQTTxCUj4NClN1YmplY3Q6IFJlOiBbRWNyaXRdIFBy b3Bvc2FsIHRvIGFkZCAmcXVvdDthcHBsaWNhYmlsaXR5JnF1b3Q7IHN0YXRlbWVudHRvJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC1mcmFtZXdvcmsvLXBob25lYmNw PEJSPg0KPEJSPg0KVGhhdCdzIHdoYXQgSSBtZWFudDo8QlI+DQotLSBJU1AgcGxheXMgYSByb2xl IGluIEZyYW1ld29yayAoaS5lLiwgaXQgaGFzIHJlcXVpcmVtZW50cyk8QlI+DQotLSBWU1AgZG9l cyBub3QgKG5vIHJlcXVpcmVtZW50cyAtIG1heSBub3QgYmUgdGhlcmUpPEJSPg0KPEJSPg0KRGF3 c29uLCBNYXJ0aW4gd3JvdGU6PEJSPg0KJmd0OyBJc24ndCB0aGF0IHRoZSBvdGhlciB3YXkgYXJv dW5kPyBUaGUgVlNQIG1heSBvciBtYXkgbm90IGJlIHRoZXJlPzxCUj4NCiZndDs8QlI+DQomZ3Q7 IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPg0KJmd0OyBGcm9tOiBlY3JpdC1ib3VuY2Vz QGlldGYub3JnIFs8QSBIUkVGPSJtYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRv OmVjcml0LWJvdW5jZXNAaWV0Zi5vcmc8L0E+XSBPbiBCZWhhbGY8QlI+DQomZ3Q7IE9mIFJpY2hh cmQgQmFybmVzPEJSPg0KJmd0OyBTZW50OiBUdWVzZGF5LCAyNCBNYXJjaCAyMDA5IDEwOjU2IEFN PEJSPg0KJmd0OyBUbzogUm9zZW4sIEJyaWFuPEJSPg0KJmd0OyBDYzogRUNSSVQ8QlI+DQomZ3Q7 IFN1YmplY3Q6IFJlOiBbRWNyaXRdIFByb3Bvc2FsIHRvIGFkZCAmcXVvdDthcHBsaWNhYmlsaXR5 JnF1b3Q7IHN0YXRlbWVudHRvPEJSPg0KJmd0OyAtZnJhbWV3b3JrLy1waG9uZWJjcDxCUj4NCiZn dDs8QlI+DQomZ3Q7IFRvIGJlIGNsZWFyLCBpdCdzIHRoZSAqSW50ZXJuZXQqIFNlcnZpY2UgUHJv dmlkZXIsIG5vdCB0aGUgKlZvaWNlKjxCUj4NCiZndDsgU2VydmljZSBQcm92aWRlciwgd2hpY2gg bWF5IG9yIG1heSBub3QgYmUgdGhlcmUuPEJSPg0KJmd0OzxCUj4NCiZndDsgSW4gc3VtbWFyeSwg cy9JUCBhY2Nlc3MgbmV0d29yay9JbnRlcm5ldCBTZXJ2aWNlIFByb3ZpZGVyLzxCUj4NCiZndDs8 QlI+DQomZ3Q7PEJSPg0KJmd0OyBSb3NlbiwgQnJpYW4gd3JvdGU6PEJSPg0KJmd0OyZndDsgTmFo LCBpdCdzIG5vdCB0aGUgYWNjZXNzIG5ldHdvcmsgKEFOKSBpdCdzIHRoZSBjYWxsaW5nIHNlcnZp Y2U8QlI+DQomZ3Q7IHByb3ZpZGVyPEJSPg0KJmd0OyZndDsgKFNQKSB0aGF0IGlzIGFmZmVjdGVk LiZuYnNwOyBUaGUgZXhhbXBsZXMgYXJlIGFkZGluZyBsb2NhdGlvbiAod2hvIGFkZHMgdGhlPEJS Pg0KJmd0OyZndDsgR2VvbG9jYXRpb24gaGVhZGVyKSBhbmQgdGhlIExvU1QgcXVlcnkuJm5ic3A7 IEJvdGggb2YgdGhvc2Ugd291bGQgYmUgZG9uZTxCUj4NCiZndDsgYnk8QlI+DQomZ3Q7Jmd0OyB0 aGUgU0lQIGNhbGxpbmcgbmV0d29yayBpbiwgZm9yIGV4YW1wbGUsIGFuIElNUyBzeXN0ZW0uPEJS Pg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyBCcmlhbjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZn dDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+DQomZ3Q7Jmd0OyBGcm9tOiBSaWNoYXJk IEJhcm5lcyBbPEEgSFJFRj0ibWFpbHRvOnJiYXJuZXNAYmJuLmNvbSI+bWFpbHRvOnJiYXJuZXNA YmJuLmNvbTwvQT5dPEJSPg0KJmd0OyZndDsgU2VudDogTW9uZGF5LCBNYXJjaCAyMywgMjAwOSA3 OjI3IFBNPEJSPg0KJmd0OyZndDsgVG86IFJvc2VuLCBCcmlhbjxCUj4NCiZndDsmZ3Q7IENjOiBF Q1JJVDxCUj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbRWNyaXRdIFByb3Bvc2FsIHRvIGFkZCAm cXVvdDthcHBsaWNhYmlsaXR5JnF1b3Q7IHN0YXRlbWVudCB0bzxCUj4NCiZndDsmZ3Q7IC1mcmFt ZXdvcmsvLXBob25lYmNwPEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyBFZGl0b3JpYWwgY2hh bmdlczo8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVz IGFuIGFyY2hpdGVjdHVyZSBmb3IgZW1lcmdlbmN5IGNhbGxpbmcgaW4gdGhlPEJSPg0KJmd0OyZn dDsgdHlwaWNhbCBJbnRlcm5ldCBlbnZpcm9ubWVudCwgaW4gd2hpY2ggdGhlIGNhbGxpbmcgZGV2 aWNlIGJlYXJzIG1vc3Q8QlI+DQomZ3Q7IG9mPEJSPg0KJmd0OyZndDs8QlI+DQo8QlI+DQotLS0t LS1PcmlnaW5hbCBNZXNzYWdlIFRydW5jYXRlZC0tLS0tLTxCUj4NCjxCUj4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPEJSPg0KQnJpYW4gUm9zZW48QlI+DQpOZXVTdGFyPEJSPg0KKDcyNCkg MzgyLTEwNTE8QlI+DQpicmlhbi5yb3NlbkBuZXVzdGFyLmJpejxCUj4NCjwvRk9OVD4NCjwvUD4N Cg0KPC9CT0RZPg0KPC9IVE1MPg== ------_=_NextPart_001_01C9AC29.46596EF8-- From Martin.Dawson@andrew.com Mon Mar 23 19:46:56 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43A4B3A6C56 for ; Mon, 23 Mar 2009 19:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.156 X-Spam-Level: X-Spam-Status: No, score=-1.156 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbgbi6Y8X6oi for ; Mon, 23 Mar 2009 19:46:49 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id C36323A6A92 for ; Mon, 23 Mar 2009 19:46:46 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_23_22_07_41 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, 23 Mar 2009 22:07:40 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Mar 2009 21:47:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9AC2A.E31FDE25" Date: Mon, 23 Mar 2009 21:47:34 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp Thread-Index: AcmsKUZZa39D9bCbRi66AXwxf811iAAAF7Zg References: From: "Dawson, Martin" To: "Rosen, Brian" , X-OriginalArrivalTime: 24 Mar 2009 02:47:36.0016 (UTC) FILETIME=[E3610500:01C9AC2A] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 02:46:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9AC2A.E31FDE25 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Apart from Richard's original statement, which I think parses to be the=0D=0A= opposite of intent, I think we're all agreeing...=0D=0A=0D=0A=20=0D=0A=0D=0A= Richard's original statement was:=0D=0A=0D=0A=20=0D=0A=0D=0A> To be clear, = it's the *Internet* Service Provider, not the *Voice*=0D=0A> Service Provid= er, which may or may not be there.=0D=0A=0D=0A=0D=0A=0D=0AThat statement ac= tually says that the ISP may or may not be there. I=0D=0Adon't think anybod= y actually thinks an Internet emergency call can be=0D=0Amade without some = access to the Internet... :-)=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0A= Martin=0D=0A=0D=0A________________________________=0D=0A=0D=0AFrom: Rosen, = Brian [mailto:Brian.Rosen@neustar.biz]=20=0D=0ASent: Tuesday, 24 March 2009= 1:36 PM=0D=0ATo: rbarnes@bbn.com; Dawson, Martin=0D=0ACc: ecrit@ietf.org=0D= =0ASubject: Re: [Ecrit] Proposal to add "applicability" statementto=0D=0A-f= ramework/-phonebcp=0D=0A=0D=0A=20=0D=0A=0D=0ANo.=0D=0A=0D=0AThe ISP require= ments are unwaivering.=0D=0A=0D=0A[[MCD]] "requirements are unwaivering" =3D= "it has requirements" in my=0D=0Abook. So I think we're saying the same th= ing.=0D=0A=0D=0AThe VSP requirements change. The VSP, not the ISP adds loc= ation and=0D=0Aroute, not the ISP.=0D=0A=0D=0A[[MCD]] "requirements change"= =3D "may not be there" by the same token.=0D=0AThe device may query the LI= S and LoST and send the INVITE directly to=0D=0Athe PSAP URI... so, yes, th= e ISP doesn't do it but nor is it necessary=0D=0Afor some VSP to do it. I t= hink that's what we're all saying.=0D=0A=0D=0A=0D=0A=0D=0ABrian=0D=0A------= Original Message------=0D=0AFrom: Richard Barnes=0D=0ATo: Dawson, Martin=0D= =0ACc: Brian Rosen=0D=0ACc: ECRIT=0D=0ASent: Mar 23, 2009 5:03 PM=0D=0ASubj= ect: Re: [Ecrit] Proposal to add "applicability" statementto=0D=0A-framewor= k/-phonebcp=0D=0A=0D=0AThat's what I meant:=0D=0A-- ISP plays a role in Fra= mework (i.e., it has requirements)=0D=0A-- VSP does not (no requirements - = may not be there)=0D=0A=0D=0ADawson, Martin wrote:=0D=0A> Isn't that the ot= her way around=3F The VSP may or may not be there=3F=0D=0A>=0D=0A> -----Ori= ginal Message-----=0D=0A> From: ecrit-bounces@ietf.org [mailto:ecrit-bounce= s@ietf.org] On Behalf=0D=0A> Of Richard Barnes=0D=0A> Sent: Tuesday, 24 Mar= ch 2009 10:56 AM=0D=0A> To: Rosen, Brian=0D=0A> Cc: ECRIT=0D=0A> Subject: R= e: [Ecrit] Proposal to add "applicability" statementto=0D=0A> -framework/-p= honebcp=0D=0A>=0D=0A> To be clear, it's the *Internet* Service Provider, no= t the *Voice*=0D=0A> Service Provider, which may or may not be there.=0D=0A= >=0D=0A> In summary, s/IP access network/Internet Service Provider/=0D=0A>=0D= =0A>=0D=0A> Rosen, Brian wrote:=0D=0A>> Nah, it's not the access network (A= N) it's the calling service=0D=0A> provider=0D=0A>> (SP) that is affected. = The examples are adding location (who adds=0D=0Athe=0D=0A>> Geolocation he= ader) and the LoST query. Both of those would be done=0D=0A> by=0D=0A>> th= e SIP calling network in, for example, an IMS system.=0D=0A>>=0D=0A>> Brian=0D= =0A>>=0D=0A>> -----Original Message-----=0D=0A>> From: Richard Barnes [mail= to:rbarnes@bbn.com]=0D=0A>> Sent: Monday, March 23, 2009 7:27 PM=0D=0A>> To= : Rosen, Brian=0D=0A>> Cc: ECRIT=0D=0A>> Subject: Re: [Ecrit] Proposal to a= dd "applicability" statement to=0D=0A>> -framework/-phonebcp=0D=0A>>=0D=0A>= > Editorial changes:=0D=0A>>=0D=0A>> This document describes an architectur= e for emergency calling in the=0D=0A>> typical Internet environment, in whi= ch the calling device bears most=0D=0A> of=0D=0A>>=0D=0A=0D=0A------Origina= l Message Truncated------=0D=0A=0D=0A--------------------------=0D=0ABrian = Rosen=0D=0ANeuStar=0D=0A(724) 382-1051=0D=0Abrian.rosen@neustar.biz=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_01C9AC2A.E31FDE25 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0ARe: [Ecrit]= Proposal to add "applicability" statementto=0D=0A-framework/-pho= nebcp=0D=0A=0D=0A=0D=0A= =0D=0A=0D=0A<= !--[if gte mso 9]>=0D=0A =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A

Apart from Richard’s o= riginal statement,=0D=0Awhich I think parses to be the opposite of intent, = I think we’re all agreeing…

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

 =

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

Richard’s original statement was:<= /p>=0D=0A=0D=0A

=  

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

> To b= e clear, it's the *Internet* Service Provider, not the *Voice*
=0D=0A>= ; Service Provider, which may or may not be there.
=0D=0A
=0D=0A=

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

That statement actually says that the ISP=0D=0Amay or may n= ot be there. I don’t think anybody actually thinks an Internet emerge= ncy=0D=0Acall can be made without some access to the Internet… J

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

 

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

C= heers,

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

Martin

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

From:<= font=0D=0Asize=3D2 face=3DTahoma>=0D=0ARosen, Brian [mailto:Brian.Rosen@neustar.biz] =
=0D=0ASent: Tuesday, 24 = March 2009 1:36=0D=0APM
=0D=0ATo: rbarnes@bbn.com; Dawson,=0D=0AMartin
=0D=0ACc: ecrit@ietf.org
=0D=0ASubject: Re: [Ecrit] Proposal to=0D=0Aadd "= applicability" statementto -framework/-phonebcp

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

 

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

No.
=0D=0A=0D=0AThe ISP requirements are unwaivering.

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

<= i>[[MCD]]= “requirements=0D=0Aare unwaivering” =3D “it has requirem= ents” in my book. So I think we’re saying=0D=0Athe same thing.<= o:p>

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

The VSP requirements change.  The VSP, not the=0D=0AISP adds lo= cation and route, not the ISP.

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

[[MCD]] = 220;requirements=0D=0Achange” =3D “may not be there” by t= he same token. The device may query the LIS=0D=0Aand LoST and send the INVI= TE directly to the PSAP URI… so, yes, the ISP doesn’t=0D=0Ado i= t but nor is it necessary for some VSP to do it. I think that’s what = we’re=0D=0Aall saying.

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


=0D=0A
=0D=0ABrian
=0D=0A------= Original Message------
=0D=0AFrom: Richard Barnes
=0D=0ATo: Dawson, M= artin
=0D=0ACc: Brian Rosen
=0D=0ACc: ECRIT
=0D=0ASent: Mar 23, 20= 09 5:03 PM
=0D=0ASubject: Re: [Ecrit] Proposal to add "applicabilit= y"=0D=0Astatementto        -framewo= rk/-phonebcp
=0D=0A
=0D=0AThat's what I meant:
=0D=0A-- ISP plays = a role in Framework (i.e., it has requirements)
=0D=0A-- VSP does not (n= o requirements - may not be there)
=0D=0A
=0D=0ADawson, Martin=0D=0Awrote:=0D=0A> Isn't that the other way around=3F The VSP may or may not be t= here=3F
=0D=0A>
=0D=0A> -----Original Message-----
=0D=0A>= ; From: ecrit-bounces@ietf.org [m= ailto:ecrit-bounces@ietf.org]=0D=0AOn Behalf
=0D=0A> Of Richard B= arnes
=0D=0A> Sent: Tuesday, 24 March 2009 10:56 AM
=0D=0A> To:= Rosen, Brian
=0D=0A> Cc: ECRIT
=0D=0A> Subject: Re: [Ecrit] Pr= oposal to add "applicability" statementto
=0D=0A> -framewor= k/-phonebcp
=0D=0A>
=0D=0A> To be clear, it's the *Internet* Se= rvice Provider, not the *Voice*
=0D=0A> Service Provider, which may o= r may not be there.
=0D=0A>
=0D=0A> In summary, s/IP access net= work/Internet Service Provider/
=0D=0A>
=0D=0A>
=0D=0A> R= osen, Brian wrote:
=0D=0A>> Nah, it's not the access network (AN) = it's the calling service
=0D=0A> provider
=0D=0A>> (SP) that= is affected.  The examples are adding location (who=0D=0Aadds the
=0D= =0A>> Geolocation header) and the LoST query.  Both of those wou= ld be=0D=0Adone
=0D=0A> by
=0D=0A>> the SIP calling network = in, for example, an IMS system.
=0D=0A>>
=0D=0A>> Brian=0D=0A>>
=0D=0A>> -----Original Message-----
=0D=0A>= > From: Richard Barnes [mailto:rbarne= s@bbn.com]
=0D=0A>> Sent: Monday, March 23, 2009 7:27 PM
=0D= =0A>> To: Rosen, Brian
=0D=0A>> Cc: ECRIT
=0D=0A>> = Subject: Re: [Ecrit] Proposal to add "applicability"=0D=0Astateme= nt to
=0D=0A>> -framework/-phonebcp
=0D=0A>>
=0D=0A>= ;> Editorial changes:
=0D=0A>>
=0D=0A>> This document = describes an architecture for emergency calling in the
=0D=0A>> ty= pical Internet environment, in which the calling device bears most
=0D=0A= > of
=0D=0A>>
=0D=0A
=0D=0A------Original Message Truncat= ed------
=0D=0A
=0D=0A--------------------------
=0D=0ABrian Rosen=
=0D=0ANeuStar
=0D=0A(724) 382-1051
=0D=0Abrian.rosen@neustar.biz<= /span>

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


---------------------------= ---------------------------------------------------------------------
=0D= =0AThis message is for the designated recipie= nt only and may
=0D=0Acontain privileged, propr= ietary, or otherwise private information.  =0D=0AIf you have received it in error,&nbs= p;please notify the sender
=0D=0Aimmediately and&nbs= p;delete the original.  Any unauthorized use&= nbsp;of
=0D=0Athis email is prohibited.
=0D=0A--------= ---------------------------------------------------------------------------= -------------
=0D=0A[mf2]
=0D=0A=0D=0A=0D= =0A ------_=_NextPart_001_01C9AC2A.E31FDE25-- From rbarnes@bbn.com Tue Mar 24 10:24:58 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 033D828C10C for ; Tue, 24 Mar 2009 10:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnPmrgLyVwAJ for ; Tue, 24 Mar 2009 10:24:57 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id E33DF3A67F5 for ; Tue, 24 Mar 2009 10:24:56 -0700 (PDT) Received: from [128.89.252.28] (helo=dhcp-17f1.meeting.ietf.org) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LmANm-0008Gb-AJ; Tue, 24 Mar 2009 13:25:46 -0400 Message-ID: <49C91795.9030208@bbn.com> Date: Tue, 24 Mar 2009 10:25:41 -0700 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Dawson, Martin" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Rosen, Brian" , ecrit@ietf.org Subject: Re: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 17:24:58 -0000 Yes, I think we all agree, and agree that my original sentence was poorly constructed. Updated proposal: This document describes an architecture for emergency calling in the typical Internet environment, in which the calling device bears most of the burden of implementing emergency calls, and the caller's Internet Service Provider has a supporting role. The underlying specifications allow for the network to take a more expansive role in emergency calls, but such cases (and any associated issues) are not covered extensively in this document; rather, they are left for future study in other documents. Dawson, Martin wrote: > Apart from Richard's original statement, which I think parses to be the > opposite of intent, I think we're all agreeing... > > > > Richard's original statement was: > > > >> To be clear, it's the *Internet* Service Provider, not the *Voice* >> Service Provider, which may or may not be there. > > > > That statement actually says that the ISP may or may not be there. I > don't think anybody actually thinks an Internet emergency call can be > made without some access to the Internet... :-) > > > > Cheers, > > Martin > > ________________________________ > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Tuesday, 24 March 2009 1:36 PM > To: rbarnes@bbn.com; Dawson, Martin > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Proposal to add "applicability" statementto > -framework/-phonebcp > > > > No. > > The ISP requirements are unwaivering. > > [[MCD]] "requirements are unwaivering" = "it has requirements" in my > book. So I think we're saying the same thing. > > The VSP requirements change. The VSP, not the ISP adds location and > route, not the ISP. > > [[MCD]] "requirements change" = "may not be there" by the same token. > The device may query the LIS and LoST and send the INVITE directly to > the PSAP URI... so, yes, the ISP doesn't do it but nor is it necessary > for some VSP to do it. I think that's what we're all saying. > > > > Brian > ------Original Message------ > From: Richard Barnes > To: Dawson, Martin > Cc: Brian Rosen > Cc: ECRIT > Sent: Mar 23, 2009 5:03 PM > Subject: Re: [Ecrit] Proposal to add "applicability" statementto > -framework/-phonebcp > > That's what I meant: > -- ISP plays a role in Framework (i.e., it has requirements) > -- VSP does not (no requirements - may not be there) > > Dawson, Martin wrote: >> Isn't that the other way around? The VSP may or may not be there? >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Richard Barnes >> Sent: Tuesday, 24 March 2009 10:56 AM >> To: Rosen, Brian >> Cc: ECRIT >> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >> -framework/-phonebcp >> >> To be clear, it's the *Internet* Service Provider, not the *Voice* >> Service Provider, which may or may not be there. >> >> In summary, s/IP access network/Internet Service Provider/ >> >> >> Rosen, Brian wrote: >>> Nah, it's not the access network (AN) it's the calling service >> provider >>> (SP) that is affected. The examples are adding location (who adds > the >>> Geolocation header) and the LoST query. Both of those would be done >> by >>> the SIP calling network in, for example, an IMS system. >>> >>> Brian >>> >>> -----Original Message----- >>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>> Sent: Monday, March 23, 2009 7:27 PM >>> To: Rosen, Brian >>> Cc: ECRIT >>> Subject: Re: [Ecrit] Proposal to add "applicability" statement to >>> -framework/-phonebcp >>> >>> Editorial changes: >>> >>> This document describes an architecture for emergency calling in the >>> typical Internet environment, in which the calling device bears most >> of > > ------Original Message Truncated------ > > -------------------------- > Brian Rosen > NeuStar > (724) 382-1051 > brian.rosen@neustar.biz > > ------------------------------------------------------------------------------------------------ > 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] > From randy@qualcomm.com Tue Mar 24 10:47:05 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E8C128C102 for ; Tue, 24 Mar 2009 10:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=-0.357, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKDOZHKFNVUf for ; Tue, 24 Mar 2009 10:47:03 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id DE1BC3A6928 for ; Tue, 24 Mar 2009 10:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1237916875; x=1269452875; h=message-id:in-reply-to:references:x-mailer: x-message-note:date:to:from:subject:cc:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20<49C91795.9030208@bbn.com>|References:=20 =0D=0A=20=0D=0A=20<49C91795.9030208@bbn.co m>|X-Mailer:=20Eudora=20for=20Mac=20OS=20X |X-message-Note:=20Warning:=20Outlook=20in=20use.=20=20Up grade=20to=20Eudora:=20|Date:=20Tu e,=2024=20Mar=202009=2010:44:29=20-0700|To:=20Richard=20B arnes=20,=0D=0A=20=20=20=20=20=20=20=20" Dawson,=20Martin"=0D=0A=09 |From:=20Randall=20Gellens=20 |Subject:=20Re:=20[Ecrit]=20Proposal=20to=20add=20"applic ability"=20=09statementto=0D=0A=20-framework/-phonebcp |CC:=20"Rosen,=20Brian"=20,=20,=0D=0A=20=20=20=20=20=20=20=20|MIME-Version:=201.0|Content-Type:=20text/p lain=3B=20charset=3D"us-ascii"=3B=20format=3Dflowed |X-Random-Sig-Tag:=201.0b28|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5563"=3B=20a=3D"16542488"; bh=ser0mEN9qYKE2biPmqvATebvcJWnaVDPvXQBtgb/B0Y=; b=D8mdX+VRDwwz5BgRP9vGlmwT/wqOqm1fdVcL4V1xG4AIgBPAm8yJVeNR B/ohTUvddIHfWzjI0slpYaPs/uib0U8eU5Lrd40dcLsNWWck9A6Y71ZmN xiFUWbGJSfnDpdP33LAXwPiVWVaT7o+8tQ6nhX8dF1Q1uY7Ono4HajNeC g=; X-IronPort-AV: E=McAfee;i="5300,2777,5563"; a="16542488" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Mar 2009 10:47:55 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2OHlsah010103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Mar 2009 10:47:55 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2OHlscg029322 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Mar 2009 10:47:54 -0700 (PDT) Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 24 Mar 2009 10:47:53 -0700 Received: from [172.28.176.165] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 24 Mar 2009 10:47:53 -0700 Message-ID: In-Reply-To: <49C91795.9030208@bbn.com> References: <49C91795.9030208@bbn.com> X-Mailer: Eudora for Mac OS X X-message-Note: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 24 Mar 2009 10:44:29 -0700 To: Richard Barnes , "Dawson, Martin" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 Cc: "Rosen, Brian" , ecrit@ietf.org Subject: Re: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 17:47:05 -0000 At 10:25 AM -0700 3/24/09, Richard Barnes wrote: > This document describes an architecture for emergency calling in > the typical Internet environment, in which the calling device bears > most of the burden of implementing emergency calls, and the > caller's Internet Service Provider has a supporting role. The > underlying specifications allow for the network to take a more > expansive role in emergency calls, but such cases (and any > associated issues) are not covered extensively in this document; > rather, they are left for future study in other documents. How about adding a sentence along the lines of what Keith proposed during the meeting, which, if I understood correctly, would be something like: "Note that this is one framework for placing emergency calls. Other frameworks may exist, and there is no guarantee that an entity implementing this framework will be able to interoperate with an entity using a different framework." -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- There is something fascinating about science. One gets such wholesale returns of conjecture out of such a trifling investment of fact. --Mark Twain From spencer@wonderhamster.org Tue Mar 24 10:58:48 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ACA43A68C1 for ; Tue, 24 Mar 2009 10:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6Ze3GDqsVgb for ; Tue, 24 Mar 2009 10:58:47 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id C8D713A66B4 for ; Tue, 24 Mar 2009 10:58:47 -0700 (PDT) Received: from S73602b (dhcp-63fb.meeting.ietf.org [130.129.99.251]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1LmAuT22Qn-000d9f; Tue, 24 Mar 2009 13:59:38 -0400 Message-ID: <246F6886EDBF40A99109FEB1EDE23233@china.huawei.com> From: "Spencer Dawkins" To: "Richard Barnes" , "Dawson, Martin" References: <49C91795.9030208@bbn.com> Date: Tue, 24 Mar 2009 12:59:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1/WjeHxBAqWhRZLE4cK+SzpZbBxGeeTaxrDXCJ t4cQklPVXQnwgoov53Lamrts6Bn1B1XmEfHEJotIXKAEMtO1qK YjiMETcR3rA6yL7hdJZx8k4LHsTv0+Iy2yVWRM17q8= Cc: "Rosen, Brian" , ecrit@ietf.org Subject: Re: [Ecrit] Proposal to add "applicability"statementto -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 17:58:48 -0000 One point from the discussion that doesn't appear here - "in other documents" means "in other documents, probably produced by other SDOs", or something like that. Not sure what the right words are, but this was mentioned during the "high bar/heavy burden" discussion at the face-to-face meeting. Just on style - "typical" doesn't seem necessary to me, but no one else has questioned it. Thanks, Spencer > Updated proposal: > > This document describes an architecture for emergency calling in the > typical Internet environment, in which the calling device bears most of > the burden of implementing emergency calls, and the caller's Internet > Service Provider has a supporting role. The underlying specifications > allow for the network to take a more expansive role in emergency calls, > but such cases (and any associated issues) are not covered extensively in > this document; rather, they are left for future study in other documents. From brian.rosen@neustar.biz Tue Mar 24 11:10:39 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C589D3A6A1A for ; Tue, 24 Mar 2009 11:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-OBwuIQdHkM for ; Tue, 24 Mar 2009 11:10:38 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 646783A698E for ; Tue, 24 Mar 2009 11:10:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1237918288; x=1238004688; h=From:Date:Subject:Message-ID:Content-class:Content-Type:Content-Transfer-Encod ing; b=H+q8KHt0otJLrA1R60MKz9nXwMO7XZGUG+4fdDqAsqaG322NHMD07MyvHV46UNOL7EgbodYOKYbyye a8qWDETQ== Received: from ([10.31.13.50]) by stihiron1.va.neustar.com with ESMTP id 5202702.16368973; Tue, 24 Mar 2009 14:11:13 -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: Tue, 24 Mar 2009 14:10:28 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp Thread-Index: AcmsqLQJVnvVFYg6SOeKp2u8bLo5IwAAq0mQ References: <49C91795.9030208@bbn.com> From: "Rosen, Brian" To: "Randall Gellens" , "Richard Barnes" , "Dawson, Martin" Cc: ecrit@ietf.org Subject: Re: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 18:10:39 -0000 I don't want this "loophole" opened any wider than it has to be. We know that there are differences between endpoints rather than networks doing location and routing functions. Although there are other differences, they mostly have to do with backwards compatibility with existing PSTN oriented, nationally defined, existing emergency call system. I don't think that needs to be in the scope of the loophole. =20 Brian -----Original Message----- From: Randall Gellens [mailto:randy@qualcomm.com]=20 Sent: Tuesday, March 24, 2009 1:44 PM To: Richard Barnes; Dawson, Martin Cc: Rosen, Brian; ecrit@ietf.org; drage@alcatel-lucent.com Subject: Re: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp At 10:25 AM -0700 3/24/09, Richard Barnes wrote: > This document describes an architecture for emergency calling in=20 > the typical Internet environment, in which the calling device bears=20 > most of the burden of implementing emergency calls, and the=20 > caller's Internet Service Provider has a supporting role. The=20 > underlying specifications allow for the network to take a more=20 > expansive role in emergency calls, but such cases (and any=20 > associated issues) are not covered extensively in this document;=20 > rather, they are left for future study in other documents. How about adding a sentence along the lines of what Keith proposed=20 during the meeting, which, if I understood correctly, would be=20 something like: "Note that this is one framework for placing=20 emergency calls. Other frameworks may exist, and there is no=20 guarantee that an entity implementing this framework will be able to=20 interoperate with an entity using a different framework." --=20 Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- There is something fascinating about science. One gets such wholesale returns of conjecture out of such a trifling investment of fact. --Mark Twain From br@brianrosen.net Tue Mar 24 11:13:28 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4057228C11B for ; Tue, 24 Mar 2009 11:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCzExBrlSXNp for ; Tue, 24 Mar 2009 11:13:27 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 064583A687C for ; Tue, 24 Mar 2009 11:13:27 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LmB8U-0008VD-IS; Tue, 24 Mar 2009 13:14:06 -0500 From: "Brian Rosen" To: "'Richard Barnes'" , "'Dawson, Martin'" References: <49C91795.9030208@bbn.com> In-Reply-To: <49C91795.9030208@bbn.com> Date: Tue, 24 Mar 2009 14:14:07 -0400 Message-ID: <00fd01c9acac$575e73d0$061b5b70$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmspY/dBN0NQMjvRU2PxAFZQQpwJgABm35w Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: "Rosen, Brian" , ecrit@ietf.org Subject: Re: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 18:13:28 -0000 Richard We're not communicating. Where your sentence says "Internet Service Provider", I want it changed to "calling network service provider". It is the network that would add location and route calls, not the ISP. The ISP supplies location in both scenarios. The difference is to whom (the end device or the proxy in the calling network). Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Tuesday, March 24, 2009 1:26 PM To: Dawson, Martin Cc: Rosen, Brian; ecrit@ietf.org Subject: Re: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp Yes, I think we all agree, and agree that my original sentence was poorly constructed. Updated proposal: This document describes an architecture for emergency calling in the typical Internet environment, in which the calling device bears most of the burden of implementing emergency calls, and the caller's Internet Service Provider has a supporting role. The underlying specifications allow for the network to take a more expansive role in emergency calls, but such cases (and any associated issues) are not covered extensively in this document; rather, they are left for future study in other documents. Dawson, Martin wrote: > Apart from Richard's original statement, which I think parses to be the > opposite of intent, I think we're all agreeing... > > > > Richard's original statement was: > > > >> To be clear, it's the *Internet* Service Provider, not the *Voice* >> Service Provider, which may or may not be there. > > > > That statement actually says that the ISP may or may not be there. I > don't think anybody actually thinks an Internet emergency call can be > made without some access to the Internet... :-) > > > > Cheers, > > Martin > > ________________________________ > > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Tuesday, 24 March 2009 1:36 PM > To: rbarnes@bbn.com; Dawson, Martin > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Proposal to add "applicability" statementto > -framework/-phonebcp > > > > No. > > The ISP requirements are unwaivering. > > [[MCD]] "requirements are unwaivering" = "it has requirements" in my > book. So I think we're saying the same thing. > > The VSP requirements change. The VSP, not the ISP adds location and > route, not the ISP. > > [[MCD]] "requirements change" = "may not be there" by the same token. > The device may query the LIS and LoST and send the INVITE directly to > the PSAP URI... so, yes, the ISP doesn't do it but nor is it necessary > for some VSP to do it. I think that's what we're all saying. > > > > Brian > ------Original Message------ > From: Richard Barnes > To: Dawson, Martin > Cc: Brian Rosen > Cc: ECRIT > Sent: Mar 23, 2009 5:03 PM > Subject: Re: [Ecrit] Proposal to add "applicability" statementto > -framework/-phonebcp > > That's what I meant: > -- ISP plays a role in Framework (i.e., it has requirements) > -- VSP does not (no requirements - may not be there) > > Dawson, Martin wrote: >> Isn't that the other way around? The VSP may or may not be there? >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Richard Barnes >> Sent: Tuesday, 24 March 2009 10:56 AM >> To: Rosen, Brian >> Cc: ECRIT >> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >> -framework/-phonebcp >> >> To be clear, it's the *Internet* Service Provider, not the *Voice* >> Service Provider, which may or may not be there. >> >> In summary, s/IP access network/Internet Service Provider/ >> >> >> Rosen, Brian wrote: >>> Nah, it's not the access network (AN) it's the calling service >> provider >>> (SP) that is affected. The examples are adding location (who adds > the >>> Geolocation header) and the LoST query. Both of those would be done >> by >>> the SIP calling network in, for example, an IMS system. >>> >>> Brian >>> >>> -----Original Message----- >>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>> Sent: Monday, March 23, 2009 7:27 PM >>> To: Rosen, Brian >>> Cc: ECRIT >>> Subject: Re: [Ecrit] Proposal to add "applicability" statement to >>> -framework/-phonebcp >>> >>> Editorial changes: >>> >>> This document describes an architecture for emergency calling in the >>> typical Internet environment, in which the calling device bears most >> of > > ------Original Message Truncated------ > > -------------------------- > Brian Rosen > NeuStar > (724) 382-1051 > brian.rosen@neustar.biz > > ---------------------------------------------------------------------------- -------------------- > 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://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Tue Mar 24 12:03:13 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56B083A681F for ; Tue, 24 Mar 2009 12:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pg+PcPctf81a for ; Tue, 24 Mar 2009 12:03:12 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 03ED628C358 for ; Tue, 24 Mar 2009 12:03:06 -0700 (PDT) Received: from [128.89.252.52] (helo=dhcp-17f1.meeting.ietf.org) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LmBuk-0002Ty-ET; Tue, 24 Mar 2009 15:03:54 -0400 Message-ID: <49C92E99.8080909@bbn.com> Date: Tue, 24 Mar 2009 12:03:53 -0700 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Brian Rosen References: <49C91795.9030208@bbn.com> <00fd01c9acac$575e73d0$061b5b70$@net> In-Reply-To: <00fd01c9acac$575e73d0$061b5b70$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Dawson, Martin'" , ecrit@ietf.org, "Rosen, Brian" Subject: Re: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 19:03:13 -0000 Aha, I get it. So both types of service provider show up. -- The ISP MUST provide location information (in either case) -- The VSP MAY add location and route calls Does the following capture it? (Also added a call out to "interoperability issues" to address Mr. Gellens' concern): This document describes an architecture for emergency calling in the typical Internet environment, in which the calling device bears most of the burden of implementing emergency calls, and the caller's Internet Service Provider has a supporting role. The caller's Voice Service Provider plays a minor role, if such a provider is present at all. The underlying specifications do allow for the Voice Service Provider to take a more expansive role in emergency calls. However, such cases and any associated issues (e.g., interoperability issues) are not covered extensively in this document; rather, they are left for future study in other documents. --Richard Brian Rosen wrote: > Richard > > We're not communicating. Where your sentence says "Internet Service > Provider", I want it changed to "calling network service provider". It is > the network that would add location and route calls, not the ISP. The ISP > supplies location in both scenarios. The difference is to whom (the end > device or the proxy in the calling network). > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Richard Barnes > Sent: Tuesday, March 24, 2009 1:26 PM > To: Dawson, Martin > Cc: Rosen, Brian; ecrit@ietf.org > Subject: Re: [Ecrit] Proposal to add "applicability" statementto > -framework/-phonebcp > > Yes, I think we all agree, and agree that my original sentence was > poorly constructed. > > Updated proposal: > > This document describes an architecture for emergency calling in the > typical Internet environment, in which the calling device bears most of > the burden of implementing emergency calls, and the caller's Internet > Service Provider has a supporting role. The underlying specifications > allow for the network to take a more expansive role in emergency calls, > but such cases (and any associated issues) are not covered extensively > in this document; rather, they are left for future study in other > documents. > > > Dawson, Martin wrote: >> Apart from Richard's original statement, which I think parses to be the >> opposite of intent, I think we're all agreeing... >> >> >> >> Richard's original statement was: >> >> >> >>> To be clear, it's the *Internet* Service Provider, not the *Voice* >>> Service Provider, which may or may not be there. >> >> >> That statement actually says that the ISP may or may not be there. I >> don't think anybody actually thinks an Internet emergency call can be >> made without some access to the Internet... :-) >> >> >> >> Cheers, >> >> Martin >> >> ________________________________ >> >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Tuesday, 24 March 2009 1:36 PM >> To: rbarnes@bbn.com; Dawson, Martin >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >> -framework/-phonebcp >> >> >> >> No. >> >> The ISP requirements are unwaivering. >> >> [[MCD]] "requirements are unwaivering" = "it has requirements" in my >> book. So I think we're saying the same thing. >> >> The VSP requirements change. The VSP, not the ISP adds location and >> route, not the ISP. >> >> [[MCD]] "requirements change" = "may not be there" by the same token. >> The device may query the LIS and LoST and send the INVITE directly to >> the PSAP URI... so, yes, the ISP doesn't do it but nor is it necessary >> for some VSP to do it. I think that's what we're all saying. >> >> >> >> Brian >> ------Original Message------ >> From: Richard Barnes >> To: Dawson, Martin >> Cc: Brian Rosen >> Cc: ECRIT >> Sent: Mar 23, 2009 5:03 PM >> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >> -framework/-phonebcp >> >> That's what I meant: >> -- ISP plays a role in Framework (i.e., it has requirements) >> -- VSP does not (no requirements - may not be there) >> >> Dawson, Martin wrote: >>> Isn't that the other way around? The VSP may or may not be there? >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>> Of Richard Barnes >>> Sent: Tuesday, 24 March 2009 10:56 AM >>> To: Rosen, Brian >>> Cc: ECRIT >>> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >>> -framework/-phonebcp >>> >>> To be clear, it's the *Internet* Service Provider, not the *Voice* >>> Service Provider, which may or may not be there. >>> >>> In summary, s/IP access network/Internet Service Provider/ >>> >>> >>> Rosen, Brian wrote: >>>> Nah, it's not the access network (AN) it's the calling service >>> provider >>>> (SP) that is affected. The examples are adding location (who adds >> the >>>> Geolocation header) and the LoST query. Both of those would be done >>> by >>>> the SIP calling network in, for example, an IMS system. >>>> >>>> Brian >>>> >>>> -----Original Message----- >>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>> Sent: Monday, March 23, 2009 7:27 PM >>>> To: Rosen, Brian >>>> Cc: ECRIT >>>> Subject: Re: [Ecrit] Proposal to add "applicability" statement to >>>> -framework/-phonebcp >>>> >>>> Editorial changes: >>>> >>>> This document describes an architecture for emergency calling in the >>>> typical Internet environment, in which the calling device bears most >>> of >> ------Original Message Truncated------ >> >> -------------------------- >> Brian Rosen >> NeuStar >> (724) 382-1051 >> brian.rosen@neustar.biz >> >> > ---------------------------------------------------------------------------- > -------------------- >> 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://www.ietf.org/mailman/listinfo/ecrit > > From br@brianrosen.net Tue Mar 24 13:14:05 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C4AE3A6C20 for ; Tue, 24 Mar 2009 13:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hd-Opk-RX-uS for ; Tue, 24 Mar 2009 13:14:04 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 55F603A68BA for ; Tue, 24 Mar 2009 13:14:04 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LmD1H-0008MC-Eh; Tue, 24 Mar 2009 15:14:44 -0500 From: "Brian Rosen" To: "'Richard Barnes'" References: <49C91795.9030208@bbn.com> <00fd01c9acac$575e73d0$061b5b70$@net> <49C92E99.8080909@bbn.com> In-Reply-To: <49C92E99.8080909@bbn.com> Date: Tue, 24 Mar 2009 16:14:49 -0400 Message-ID: <013201c9acbd$31938e40$94baaac0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acmss0cswfgjdEuLQ6+wma/PywmFKQACdjAQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: "'Dawson, Martin'" , ecrit@ietf.org, "Rosen, Brian" Subject: Re: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:14:05 -0000 Better. "Voice" is too limiting. -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com] Sent: Tuesday, March 24, 2009 3:04 PM To: Brian Rosen Cc: 'Dawson, Martin'; Rosen, Brian; ecrit@ietf.org Subject: Re: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp Aha, I get it. So both types of service provider show up. -- The ISP MUST provide location information (in either case) -- The VSP MAY add location and route calls Does the following capture it? (Also added a call out to "interoperability issues" to address Mr. Gellens' concern): This document describes an architecture for emergency calling in the typical Internet environment, in which the calling device bears most of the burden of implementing emergency calls, and the caller's Internet Service Provider has a supporting role. The caller's Voice Service Provider plays a minor role, if such a provider is present at all. The underlying specifications do allow for the Voice Service Provider to take a more expansive role in emergency calls. However, such cases and any associated issues (e.g., interoperability issues) are not covered extensively in this document; rather, they are left for future study in other documents. --Richard Brian Rosen wrote: > Richard > > We're not communicating. Where your sentence says "Internet Service > Provider", I want it changed to "calling network service provider". It is > the network that would add location and route calls, not the ISP. The ISP > supplies location in both scenarios. The difference is to whom (the end > device or the proxy in the calling network). > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Richard Barnes > Sent: Tuesday, March 24, 2009 1:26 PM > To: Dawson, Martin > Cc: Rosen, Brian; ecrit@ietf.org > Subject: Re: [Ecrit] Proposal to add "applicability" statementto > -framework/-phonebcp > > Yes, I think we all agree, and agree that my original sentence was > poorly constructed. > > Updated proposal: > > This document describes an architecture for emergency calling in the > typical Internet environment, in which the calling device bears most of > the burden of implementing emergency calls, and the caller's Internet > Service Provider has a supporting role. The underlying specifications > allow for the network to take a more expansive role in emergency calls, > but such cases (and any associated issues) are not covered extensively > in this document; rather, they are left for future study in other > documents. > > > Dawson, Martin wrote: >> Apart from Richard's original statement, which I think parses to be the >> opposite of intent, I think we're all agreeing... >> >> >> >> Richard's original statement was: >> >> >> >>> To be clear, it's the *Internet* Service Provider, not the *Voice* >>> Service Provider, which may or may not be there. >> >> >> That statement actually says that the ISP may or may not be there. I >> don't think anybody actually thinks an Internet emergency call can be >> made without some access to the Internet... :-) >> >> >> >> Cheers, >> >> Martin >> >> ________________________________ >> >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >> Sent: Tuesday, 24 March 2009 1:36 PM >> To: rbarnes@bbn.com; Dawson, Martin >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >> -framework/-phonebcp >> >> >> >> No. >> >> The ISP requirements are unwaivering. >> >> [[MCD]] "requirements are unwaivering" = "it has requirements" in my >> book. So I think we're saying the same thing. >> >> The VSP requirements change. The VSP, not the ISP adds location and >> route, not the ISP. >> >> [[MCD]] "requirements change" = "may not be there" by the same token. >> The device may query the LIS and LoST and send the INVITE directly to >> the PSAP URI... so, yes, the ISP doesn't do it but nor is it necessary >> for some VSP to do it. I think that's what we're all saying. >> >> >> >> Brian >> ------Original Message------ >> From: Richard Barnes >> To: Dawson, Martin >> Cc: Brian Rosen >> Cc: ECRIT >> Sent: Mar 23, 2009 5:03 PM >> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >> -framework/-phonebcp >> >> That's what I meant: >> -- ISP plays a role in Framework (i.e., it has requirements) >> -- VSP does not (no requirements - may not be there) >> >> Dawson, Martin wrote: >>> Isn't that the other way around? The VSP may or may not be there? >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>> Of Richard Barnes >>> Sent: Tuesday, 24 March 2009 10:56 AM >>> To: Rosen, Brian >>> Cc: ECRIT >>> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >>> -framework/-phonebcp >>> >>> To be clear, it's the *Internet* Service Provider, not the *Voice* >>> Service Provider, which may or may not be there. >>> >>> In summary, s/IP access network/Internet Service Provider/ >>> >>> >>> Rosen, Brian wrote: >>>> Nah, it's not the access network (AN) it's the calling service >>> provider >>>> (SP) that is affected. The examples are adding location (who adds >> the >>>> Geolocation header) and the LoST query. Both of those would be done >>> by >>>> the SIP calling network in, for example, an IMS system. >>>> >>>> Brian >>>> >>>> -----Original Message----- >>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>> Sent: Monday, March 23, 2009 7:27 PM >>>> To: Rosen, Brian >>>> Cc: ECRIT >>>> Subject: Re: [Ecrit] Proposal to add "applicability" statement to >>>> -framework/-phonebcp >>>> >>>> Editorial changes: >>>> >>>> This document describes an architecture for emergency calling in the >>>> typical Internet environment, in which the calling device bears most >>> of >> ------Original Message Truncated------ >> >> -------------------------- >> Brian Rosen >> NeuStar >> (724) 382-1051 >> brian.rosen@neustar.biz >> >> > ---------------------------------------------------------------------------- > -------------------- >> 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://www.ietf.org/mailman/listinfo/ecrit > > From rbarnes@bbn.com Tue Mar 24 13:26:57 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751F628C19A for ; Tue, 24 Mar 2009 13:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jz5EmBRnPcuj for ; Tue, 24 Mar 2009 13:26:56 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 232EA28C2BC for ; Tue, 24 Mar 2009 13:26:56 -0700 (PDT) Received: from [128.89.252.49] (helo=dhcp-17f1.meeting.ietf.org) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LmDDu-0003Pw-F9; Tue, 24 Mar 2009 16:27:47 -0400 Message-ID: <49C9423C.30808@bbn.com> Date: Tue, 24 Mar 2009 13:27:40 -0700 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Brian Rosen References: <49C91795.9030208@bbn.com> <00fd01c9acac$575e73d0$061b5b70$@net> <49C92E99.8080909@bbn.com> <013201c9acbd$31938e40$94baaac0$@net> In-Reply-To: <013201c9acbd$31938e40$94baaac0$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Dawson, Martin'" , ecrit@ietf.org, "Rosen, Brian" Subject: Re: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:26:57 -0000 "SIP"? That's the charter scope. The critical distinction is that it's at the application layer (where the application is whatever is being used to reach the PSAP). Brian Rosen wrote: > Better. "Voice" is too limiting. > > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Tuesday, March 24, 2009 3:04 PM > To: Brian Rosen > Cc: 'Dawson, Martin'; Rosen, Brian; ecrit@ietf.org > Subject: Re: [Ecrit] Proposal to add "applicability" statementto > -framework/-phonebcp > > Aha, I get it. So both types of service provider show up. > -- The ISP MUST provide location information (in either case) > -- The VSP MAY add location and route calls > > Does the following capture it? (Also added a call out to > "interoperability issues" to address Mr. Gellens' concern): > > This document describes an architecture for emergency calling in the > typical Internet environment, in which the calling device bears most of > the burden of implementing emergency calls, and the caller's Internet > Service Provider has a supporting role. The caller's Voice Service > Provider plays a minor role, if such a provider is present at all. The > underlying specifications do allow for the Voice Service Provider to > take a more expansive role in emergency calls. However, such cases and > any associated issues (e.g., interoperability issues) are not covered > extensively in this document; rather, they are left for future study in > other documents. > > --Richard > > > Brian Rosen wrote: >> Richard >> >> We're not communicating. Where your sentence says "Internet Service >> Provider", I want it changed to "calling network service provider". It is >> the network that would add location and route calls, not the ISP. The ISP >> supplies location in both scenarios. The difference is to whom (the end >> device or the proxy in the calling network). >> >> Brian >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> Richard Barnes >> Sent: Tuesday, March 24, 2009 1:26 PM >> To: Dawson, Martin >> Cc: Rosen, Brian; ecrit@ietf.org >> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >> -framework/-phonebcp >> >> Yes, I think we all agree, and agree that my original sentence was >> poorly constructed. >> >> Updated proposal: >> >> This document describes an architecture for emergency calling in the >> typical Internet environment, in which the calling device bears most of >> the burden of implementing emergency calls, and the caller's Internet >> Service Provider has a supporting role. The underlying specifications >> allow for the network to take a more expansive role in emergency calls, >> but such cases (and any associated issues) are not covered extensively >> in this document; rather, they are left for future study in other >> documents. >> >> >> Dawson, Martin wrote: >>> Apart from Richard's original statement, which I think parses to be the >>> opposite of intent, I think we're all agreeing... >>> >>> >>> >>> Richard's original statement was: >>> >>> >>> >>>> To be clear, it's the *Internet* Service Provider, not the *Voice* >>>> Service Provider, which may or may not be there. >>> >>> That statement actually says that the ISP may or may not be there. I >>> don't think anybody actually thinks an Internet emergency call can be >>> made without some access to the Internet... :-) >>> >>> >>> >>> Cheers, >>> >>> Martin >>> >>> ________________________________ >>> >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Tuesday, 24 March 2009 1:36 PM >>> To: rbarnes@bbn.com; Dawson, Martin >>> Cc: ecrit@ietf.org >>> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >>> -framework/-phonebcp >>> >>> >>> >>> No. >>> >>> The ISP requirements are unwaivering. >>> >>> [[MCD]] "requirements are unwaivering" = "it has requirements" in my >>> book. So I think we're saying the same thing. >>> >>> The VSP requirements change. The VSP, not the ISP adds location and >>> route, not the ISP. >>> >>> [[MCD]] "requirements change" = "may not be there" by the same token. >>> The device may query the LIS and LoST and send the INVITE directly to >>> the PSAP URI... so, yes, the ISP doesn't do it but nor is it necessary >>> for some VSP to do it. I think that's what we're all saying. >>> >>> >>> >>> Brian >>> ------Original Message------ >>> From: Richard Barnes >>> To: Dawson, Martin >>> Cc: Brian Rosen >>> Cc: ECRIT >>> Sent: Mar 23, 2009 5:03 PM >>> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >>> -framework/-phonebcp >>> >>> That's what I meant: >>> -- ISP plays a role in Framework (i.e., it has requirements) >>> -- VSP does not (no requirements - may not be there) >>> >>> Dawson, Martin wrote: >>>> Isn't that the other way around? The VSP may or may not be there? >>>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>>> Of Richard Barnes >>>> Sent: Tuesday, 24 March 2009 10:56 AM >>>> To: Rosen, Brian >>>> Cc: ECRIT >>>> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >>>> -framework/-phonebcp >>>> >>>> To be clear, it's the *Internet* Service Provider, not the *Voice* >>>> Service Provider, which may or may not be there. >>>> >>>> In summary, s/IP access network/Internet Service Provider/ >>>> >>>> >>>> Rosen, Brian wrote: >>>>> Nah, it's not the access network (AN) it's the calling service >>>> provider >>>>> (SP) that is affected. The examples are adding location (who adds >>> the >>>>> Geolocation header) and the LoST query. Both of those would be done >>>> by >>>>> the SIP calling network in, for example, an IMS system. >>>>> >>>>> Brian >>>>> >>>>> -----Original Message----- >>>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>>> Sent: Monday, March 23, 2009 7:27 PM >>>>> To: Rosen, Brian >>>>> Cc: ECRIT >>>>> Subject: Re: [Ecrit] Proposal to add "applicability" statement to >>>>> -framework/-phonebcp >>>>> >>>>> Editorial changes: >>>>> >>>>> This document describes an architecture for emergency calling in the >>>>> typical Internet environment, in which the calling device bears most >>>> of >>> ------Original Message Truncated------ >>> >>> -------------------------- >>> Brian Rosen >>> NeuStar >>> (724) 382-1051 >>> brian.rosen@neustar.biz >>> >>> > ---------------------------------------------------------------------------- >> -------------------- >>> 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://www.ietf.org/mailman/listinfo/ecrit >> >> > > From bs7652@att.com Tue Mar 24 13:35:07 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00C6628C16B for ; Tue, 24 Mar 2009 13:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.762 X-Spam-Level: X-Spam-Status: No, score=-105.762 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVkcN2SRDOhy for ; Tue, 24 Mar 2009 13:35:05 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id 60A7828C10B for ; Tue, 24 Mar 2009 13:35:05 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-5.tower-121.messagelabs.com!1237926955!32258646!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 29187 invoked from network); 24 Mar 2009 20:35:55 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-5.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 24 Mar 2009 20:35:55 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2OKZsLZ026296; Tue, 24 Mar 2009 16:35:55 -0400 Received: from 01GAF5142010621.AD.BLS.COM (01GAF5142010621.ad.bls.com [139.76.131.79]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id n2OKZlgV025730; Tue, 24 Mar 2009 16:35:51 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 24 Mar 2009 16:35:49 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 24 Mar 2009 16:35:48 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 16:35:43 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0D88065B@crexc41p> In-Reply-To: <013201c9acbd$31938e40$94baaac0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposal to add"applicability" statementto -framework/-phonebcp thread-index: Acmss0cswfgjdEuLQ6+wma/PywmFKQACdjAQAABUbgA= References: <49C91795.9030208@bbn.com> <00fd01c9acac$575e73d0$061b5b70$@net><49C92E99.8080909@bbn.com> <013201c9acbd$31938e40$94baaac0$@net> From: "Stark, Barbara" To: "Brian Rosen" , "Richard Barnes" X-OriginalArrivalTime: 24 Mar 2009 20:35:48.0353 (UTC) FILETIME=[1D638710:01C9ACC0] Cc: "Dawson, Martin" , ecrit@ietf.org, "Rosen, Brian" Subject: Re: [Ecrit] Proposal to add"applicability" statementto -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:35:07 -0000 I was doing fine with the course of this discussion till this "interoperability" word came into the picture. I'm not convinced we have an "interoperability issue". I do think that how this framework "interconnects" to other networks is something that is not covered in this document, and that it would be ok to say that this isn't covered. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Tuesday, March 24, 2009 4:15 PM To: 'Richard Barnes' Cc: 'Dawson, Martin'; ecrit@ietf.org; Rosen,Brian Subject: Re: [Ecrit] Proposal to add"applicability" statementto -framework/-phonebcp Better. "Voice" is too limiting. -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com]=20 Sent: Tuesday, March 24, 2009 3:04 PM To: Brian Rosen Cc: 'Dawson, Martin'; Rosen, Brian; ecrit@ietf.org Subject: Re: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp Aha, I get it. So both types of service provider show up. -- The ISP MUST provide location information (in either case) -- The VSP MAY add location and route calls Does the following capture it? (Also added a call out to=20 "interoperability issues" to address Mr. Gellens' concern): This document describes an architecture for emergency calling in the=20 typical Internet environment, in which the calling device bears most of=20 the burden of implementing emergency calls, and the caller's Internet=20 Service Provider has a supporting role. The caller's Voice Service=20 Provider plays a minor role, if such a provider is present at all. The=20 underlying specifications do allow for the Voice Service Provider to=20 take a more expansive role in emergency calls. However, such cases and=20 any associated issues (e.g., interoperability issues) are not covered=20 extensively in this document; rather, they are left for future study in=20 other documents. --Richard Brian Rosen wrote: > Richard >=20 > We're not communicating. Where your sentence says "Internet Service > Provider", I want it changed to "calling network service provider". It is > the network that would add location and route calls, not the ISP. The ISP > supplies location in both scenarios. The difference is to whom (the end > device or the proxy in the calling network). >=20 > Brian >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Richard Barnes > Sent: Tuesday, March 24, 2009 1:26 PM > To: Dawson, Martin > Cc: Rosen, Brian; ecrit@ietf.org > Subject: Re: [Ecrit] Proposal to add "applicability" statementto > -framework/-phonebcp >=20 > Yes, I think we all agree, and agree that my original sentence was=20 > poorly constructed. >=20 > Updated proposal: >=20 > This document describes an architecture for emergency calling in the=20 > typical Internet environment, in which the calling device bears most of=20 > the burden of implementing emergency calls, and the caller's Internet=20 > Service Provider has a supporting role. The underlying specifications > allow for the network to take a more expansive role in emergency calls,=20 > but such cases (and any associated issues) are not covered extensively > in this document; rather, they are left for future study in other=20 > documents. >=20 >=20 > Dawson, Martin wrote: >> Apart from Richard's original statement, which I think parses to be the >> opposite of intent, I think we're all agreeing... >> >> =20 >> >> Richard's original statement was: >> >> =20 >> >>> To be clear, it's the *Internet* Service Provider, not the *Voice* >>> Service Provider, which may or may not be there. >> >> >> That statement actually says that the ISP may or may not be there. I >> don't think anybody actually thinks an Internet emergency call can be >> made without some access to the Internet... :-) >> >> =20 >> >> Cheers, >> >> Martin >> >> ________________________________ >> >> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 >> Sent: Tuesday, 24 March 2009 1:36 PM >> To: rbarnes@bbn.com; Dawson, Martin >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >> -framework/-phonebcp >> >> =20 >> >> No. >> >> The ISP requirements are unwaivering. >> >> [[MCD]] "requirements are unwaivering" =3D "it has requirements" in = my >> book. So I think we're saying the same thing. >> >> The VSP requirements change. The VSP, not the ISP adds location and >> route, not the ISP. >> >> [[MCD]] "requirements change" =3D "may not be there" by the same = token. >> The device may query the LIS and LoST and send the INVITE directly to >> the PSAP URI... so, yes, the ISP doesn't do it but nor is it necessary >> for some VSP to do it. I think that's what we're all saying. >> >> >> >> Brian >> ------Original Message------ >> From: Richard Barnes >> To: Dawson, Martin >> Cc: Brian Rosen >> Cc: ECRIT >> Sent: Mar 23, 2009 5:03 PM >> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >> -framework/-phonebcp >> >> That's what I meant: >> -- ISP plays a role in Framework (i.e., it has requirements) >> -- VSP does not (no requirements - may not be there) >> >> Dawson, Martin wrote: >>> Isn't that the other way around? The VSP may or may not be there? >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>> Of Richard Barnes >>> Sent: Tuesday, 24 March 2009 10:56 AM >>> To: Rosen, Brian >>> Cc: ECRIT >>> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >>> -framework/-phonebcp >>> >>> To be clear, it's the *Internet* Service Provider, not the *Voice* >>> Service Provider, which may or may not be there. >>> >>> In summary, s/IP access network/Internet Service Provider/ >>> >>> >>> Rosen, Brian wrote: >>>> Nah, it's not the access network (AN) it's the calling service >>> provider >>>> (SP) that is affected. The examples are adding location (who adds >> the >>>> Geolocation header) and the LoST query. Both of those would be done >>> by >>>> the SIP calling network in, for example, an IMS system. >>>> >>>> Brian >>>> >>>> -----Original Message----- >>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>> Sent: Monday, March 23, 2009 7:27 PM >>>> To: Rosen, Brian >>>> Cc: ECRIT >>>> Subject: Re: [Ecrit] Proposal to add "applicability" statement to >>>> -framework/-phonebcp >>>> >>>> Editorial changes: >>>> >>>> This document describes an architecture for emergency calling in the >>>> typical Internet environment, in which the calling device bears most >>> of >> ------Original Message Truncated------ >> >> -------------------------- >> Brian Rosen >> NeuStar >> (724) 382-1051 >> brian.rosen@neustar.biz >> >> > ------------------------------------------------------------------------ ---- > -------------------- >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. =20 >> 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://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.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 From br@brianrosen.net Tue Mar 24 13:37:32 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCE2028C16B for ; Tue, 24 Mar 2009 13:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYwH1iI7xatv for ; Tue, 24 Mar 2009 13:37:31 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 9A3683A69BD for ; Tue, 24 Mar 2009 13:37:31 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LmDNx-0002es-3B; Tue, 24 Mar 2009 15:38:11 -0500 From: "Brian Rosen" To: "'Richard Barnes'" References: <49C91795.9030208@bbn.com> <00fd01c9acac$575e73d0$061b5b70$@net> <49C92E99.8080909@bbn.com> <013201c9acbd$31938e40$94baaac0$@net> <49C9423C.30808@bbn.com> In-Reply-To: <49C9423C.30808@bbn.com> Date: Tue, 24 Mar 2009 16:38:14 -0400 Message-ID: <013901c9acc0$77e849a0$67b8dce0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acmsvvm2azrmObUvQvm4kZO0lIeGYgAAWJIQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Cc: "'Dawson, Martin'" , ecrit@ietf.org, "Rosen, Brian" Subject: Re: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:37:32 -0000 Phonebcp differentiates between the access network and a (generic) "service provider". Will that do? Brian -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com] Sent: Tuesday, March 24, 2009 4:28 PM To: Brian Rosen Cc: 'Dawson, Martin'; Rosen, Brian; ecrit@ietf.org Subject: Re: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp "SIP"? That's the charter scope. The critical distinction is that it's at the application layer (where the application is whatever is being used to reach the PSAP). Brian Rosen wrote: > Better. "Voice" is too limiting. > > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Tuesday, March 24, 2009 3:04 PM > To: Brian Rosen > Cc: 'Dawson, Martin'; Rosen, Brian; ecrit@ietf.org > Subject: Re: [Ecrit] Proposal to add "applicability" statementto > -framework/-phonebcp > > Aha, I get it. So both types of service provider show up. > -- The ISP MUST provide location information (in either case) > -- The VSP MAY add location and route calls > > Does the following capture it? (Also added a call out to > "interoperability issues" to address Mr. Gellens' concern): > > This document describes an architecture for emergency calling in the > typical Internet environment, in which the calling device bears most of > the burden of implementing emergency calls, and the caller's Internet > Service Provider has a supporting role. The caller's Voice Service > Provider plays a minor role, if such a provider is present at all. The > underlying specifications do allow for the Voice Service Provider to > take a more expansive role in emergency calls. However, such cases and > any associated issues (e.g., interoperability issues) are not covered > extensively in this document; rather, they are left for future study in > other documents. > > --Richard > > > Brian Rosen wrote: >> Richard >> >> We're not communicating. Where your sentence says "Internet Service >> Provider", I want it changed to "calling network service provider". It is >> the network that would add location and route calls, not the ISP. The ISP >> supplies location in both scenarios. The difference is to whom (the end >> device or the proxy in the calling network). >> >> Brian >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> Richard Barnes >> Sent: Tuesday, March 24, 2009 1:26 PM >> To: Dawson, Martin >> Cc: Rosen, Brian; ecrit@ietf.org >> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >> -framework/-phonebcp >> >> Yes, I think we all agree, and agree that my original sentence was >> poorly constructed. >> >> Updated proposal: >> >> This document describes an architecture for emergency calling in the >> typical Internet environment, in which the calling device bears most of >> the burden of implementing emergency calls, and the caller's Internet >> Service Provider has a supporting role. The underlying specifications >> allow for the network to take a more expansive role in emergency calls, >> but such cases (and any associated issues) are not covered extensively >> in this document; rather, they are left for future study in other >> documents. >> >> >> Dawson, Martin wrote: >>> Apart from Richard's original statement, which I think parses to be the >>> opposite of intent, I think we're all agreeing... >>> >>> >>> >>> Richard's original statement was: >>> >>> >>> >>>> To be clear, it's the *Internet* Service Provider, not the *Voice* >>>> Service Provider, which may or may not be there. >>> >>> That statement actually says that the ISP may or may not be there. I >>> don't think anybody actually thinks an Internet emergency call can be >>> made without some access to the Internet... :-) >>> >>> >>> >>> Cheers, >>> >>> Martin >>> >>> ________________________________ >>> >>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>> Sent: Tuesday, 24 March 2009 1:36 PM >>> To: rbarnes@bbn.com; Dawson, Martin >>> Cc: ecrit@ietf.org >>> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >>> -framework/-phonebcp >>> >>> >>> >>> No. >>> >>> The ISP requirements are unwaivering. >>> >>> [[MCD]] "requirements are unwaivering" = "it has requirements" in my >>> book. So I think we're saying the same thing. >>> >>> The VSP requirements change. The VSP, not the ISP adds location and >>> route, not the ISP. >>> >>> [[MCD]] "requirements change" = "may not be there" by the same token. >>> The device may query the LIS and LoST and send the INVITE directly to >>> the PSAP URI... so, yes, the ISP doesn't do it but nor is it necessary >>> for some VSP to do it. I think that's what we're all saying. >>> >>> >>> >>> Brian >>> ------Original Message------ >>> From: Richard Barnes >>> To: Dawson, Martin >>> Cc: Brian Rosen >>> Cc: ECRIT >>> Sent: Mar 23, 2009 5:03 PM >>> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >>> -framework/-phonebcp >>> >>> That's what I meant: >>> -- ISP plays a role in Framework (i.e., it has requirements) >>> -- VSP does not (no requirements - may not be there) >>> >>> Dawson, Martin wrote: >>>> Isn't that the other way around? The VSP may or may not be there? >>>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>>> Of Richard Barnes >>>> Sent: Tuesday, 24 March 2009 10:56 AM >>>> To: Rosen, Brian >>>> Cc: ECRIT >>>> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >>>> -framework/-phonebcp >>>> >>>> To be clear, it's the *Internet* Service Provider, not the *Voice* >>>> Service Provider, which may or may not be there. >>>> >>>> In summary, s/IP access network/Internet Service Provider/ >>>> >>>> >>>> Rosen, Brian wrote: >>>>> Nah, it's not the access network (AN) it's the calling service >>>> provider >>>>> (SP) that is affected. The examples are adding location (who adds >>> the >>>>> Geolocation header) and the LoST query. Both of those would be done >>>> by >>>>> the SIP calling network in, for example, an IMS system. >>>>> >>>>> Brian >>>>> >>>>> -----Original Message----- >>>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>>> Sent: Monday, March 23, 2009 7:27 PM >>>>> To: Rosen, Brian >>>>> Cc: ECRIT >>>>> Subject: Re: [Ecrit] Proposal to add "applicability" statement to >>>>> -framework/-phonebcp >>>>> >>>>> Editorial changes: >>>>> >>>>> This document describes an architecture for emergency calling in the >>>>> typical Internet environment, in which the calling device bears most >>>> of >>> ------Original Message Truncated------ >>> >>> -------------------------- >>> Brian Rosen >>> NeuStar >>> (724) 382-1051 >>> brian.rosen@neustar.biz >>> >>> > ---------------------------------------------------------------------------- >> -------------------- >>> 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://www.ietf.org/mailman/listinfo/ecrit >> >> > > From rbarnes@bbn.com Tue Mar 24 13:42:23 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76B2E28C16B for ; Tue, 24 Mar 2009 13:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ1nJW5cjRup for ; Tue, 24 Mar 2009 13:42:22 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 1B2103A6989 for ; Tue, 24 Mar 2009 13:42:22 -0700 (PDT) Received: from [128.89.252.49] (helo=dhcp-17f1.meeting.ietf.org) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LmDSq-0003br-FV; Tue, 24 Mar 2009 16:43:13 -0400 Message-ID: <49C945DE.9010308@bbn.com> Date: Tue, 24 Mar 2009 13:43:10 -0700 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Brian Rosen References: <49C91795.9030208@bbn.com> <00fd01c9acac$575e73d0$061b5b70$@net> <49C92E99.8080909@bbn.com> <013201c9acbd$31938e40$94baaac0$@net> <49C9423C.30808@bbn.com> <013901c9acc0$77e849a0$67b8dce0$@net> In-Reply-To: <013901c9acc0$77e849a0$67b8dce0$@net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Dawson, Martin'" , ecrit@ietf.org, "Rosen, Brian" Subject: Re: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 20:42:23 -0000 Sure, as long as the document later makes a distinction later on. May be good to have a pointer in this para. --Richard Brian Rosen wrote: > Phonebcp differentiates between the access network and a (generic) "service > provider". Will that do? > > Brian > > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Tuesday, March 24, 2009 4:28 PM > To: Brian Rosen > Cc: 'Dawson, Martin'; Rosen, Brian; ecrit@ietf.org > Subject: Re: [Ecrit] Proposal to add "applicability" statementto > -framework/-phonebcp > > "SIP"? That's the charter scope. The critical distinction is that it's > at the application layer (where the application is whatever is being > used to reach the PSAP). > > > Brian Rosen wrote: >> Better. "Voice" is too limiting. >> >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Tuesday, March 24, 2009 3:04 PM >> To: Brian Rosen >> Cc: 'Dawson, Martin'; Rosen, Brian; ecrit@ietf.org >> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >> -framework/-phonebcp >> >> Aha, I get it. So both types of service provider show up. >> -- The ISP MUST provide location information (in either case) >> -- The VSP MAY add location and route calls >> >> Does the following capture it? (Also added a call out to >> "interoperability issues" to address Mr. Gellens' concern): >> >> This document describes an architecture for emergency calling in the >> typical Internet environment, in which the calling device bears most of >> the burden of implementing emergency calls, and the caller's Internet >> Service Provider has a supporting role. The caller's Voice Service >> Provider plays a minor role, if such a provider is present at all. The >> underlying specifications do allow for the Voice Service Provider to >> take a more expansive role in emergency calls. However, such cases and >> any associated issues (e.g., interoperability issues) are not covered >> extensively in this document; rather, they are left for future study in >> other documents. >> >> --Richard >> >> >> Brian Rosen wrote: >>> Richard >>> >>> We're not communicating. Where your sentence says "Internet Service >>> Provider", I want it changed to "calling network service provider". It > is >>> the network that would add location and route calls, not the ISP. The > ISP >>> supplies location in both scenarios. The difference is to whom (the end >>> device or the proxy in the calling network). >>> >>> Brian >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >>> Richard Barnes >>> Sent: Tuesday, March 24, 2009 1:26 PM >>> To: Dawson, Martin >>> Cc: Rosen, Brian; ecrit@ietf.org >>> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >>> -framework/-phonebcp >>> >>> Yes, I think we all agree, and agree that my original sentence was >>> poorly constructed. >>> >>> Updated proposal: >>> >>> This document describes an architecture for emergency calling in the >>> typical Internet environment, in which the calling device bears most of >>> the burden of implementing emergency calls, and the caller's Internet >>> Service Provider has a supporting role. The underlying specifications >>> allow for the network to take a more expansive role in emergency calls, >>> but such cases (and any associated issues) are not covered extensively >>> in this document; rather, they are left for future study in other >>> documents. >>> >>> >>> Dawson, Martin wrote: >>>> Apart from Richard's original statement, which I think parses to be the >>>> opposite of intent, I think we're all agreeing... >>>> >>>> >>>> >>>> Richard's original statement was: >>>> >>>> >>>> >>>>> To be clear, it's the *Internet* Service Provider, not the *Voice* >>>>> Service Provider, which may or may not be there. >>>> That statement actually says that the ISP may or may not be there. I >>>> don't think anybody actually thinks an Internet emergency call can be >>>> made without some access to the Internet... :-) >>>> >>>> >>>> >>>> Cheers, >>>> >>>> Martin >>>> >>>> ________________________________ >>>> >>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>> Sent: Tuesday, 24 March 2009 1:36 PM >>>> To: rbarnes@bbn.com; Dawson, Martin >>>> Cc: ecrit@ietf.org >>>> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >>>> -framework/-phonebcp >>>> >>>> >>>> >>>> No. >>>> >>>> The ISP requirements are unwaivering. >>>> >>>> [[MCD]] "requirements are unwaivering" = "it has requirements" in my >>>> book. So I think we're saying the same thing. >>>> >>>> The VSP requirements change. The VSP, not the ISP adds location and >>>> route, not the ISP. >>>> >>>> [[MCD]] "requirements change" = "may not be there" by the same token. >>>> The device may query the LIS and LoST and send the INVITE directly to >>>> the PSAP URI... so, yes, the ISP doesn't do it but nor is it necessary >>>> for some VSP to do it. I think that's what we're all saying. >>>> >>>> >>>> >>>> Brian >>>> ------Original Message------ >>>> From: Richard Barnes >>>> To: Dawson, Martin >>>> Cc: Brian Rosen >>>> Cc: ECRIT >>>> Sent: Mar 23, 2009 5:03 PM >>>> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >>>> -framework/-phonebcp >>>> >>>> That's what I meant: >>>> -- ISP plays a role in Framework (i.e., it has requirements) >>>> -- VSP does not (no requirements - may not be there) >>>> >>>> Dawson, Martin wrote: >>>>> Isn't that the other way around? The VSP may or may not be there? >>>>> >>>>> -----Original Message----- >>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>>>> Of Richard Barnes >>>>> Sent: Tuesday, 24 March 2009 10:56 AM >>>>> To: Rosen, Brian >>>>> Cc: ECRIT >>>>> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >>>>> -framework/-phonebcp >>>>> >>>>> To be clear, it's the *Internet* Service Provider, not the *Voice* >>>>> Service Provider, which may or may not be there. >>>>> >>>>> In summary, s/IP access network/Internet Service Provider/ >>>>> >>>>> >>>>> Rosen, Brian wrote: >>>>>> Nah, it's not the access network (AN) it's the calling service >>>>> provider >>>>>> (SP) that is affected. The examples are adding location (who adds >>>> the >>>>>> Geolocation header) and the LoST query. Both of those would be done >>>>> by >>>>>> the SIP calling network in, for example, an IMS system. >>>>>> >>>>>> Brian >>>>>> >>>>>> -----Original Message----- >>>>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>>>> Sent: Monday, March 23, 2009 7:27 PM >>>>>> To: Rosen, Brian >>>>>> Cc: ECRIT >>>>>> Subject: Re: [Ecrit] Proposal to add "applicability" statement to >>>>>> -framework/-phonebcp >>>>>> >>>>>> Editorial changes: >>>>>> >>>>>> This document describes an architecture for emergency calling in the >>>>>> typical Internet environment, in which the calling device bears most >>>>> of >>>> ------Original Message Truncated------ >>>> >>>> -------------------------- >>>> Brian Rosen >>>> NeuStar >>>> (724) 382-1051 >>>> brian.rosen@neustar.biz >>>> >>>> > ---------------------------------------------------------------------------- >>> -------------------- >>>> 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://www.ietf.org/mailman/listinfo/ecrit >>> >>> >> > > From mlinsner@cisco.com Tue Mar 24 14:06:50 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E63D33A6AC7 for ; Tue, 24 Mar 2009 14:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxpcfHxT+BHm for ; Tue, 24 Mar 2009 14:06:49 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 577323A6989 for ; Tue, 24 Mar 2009 14:06:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,414,1233532800"; d="scan'208";a="40283272" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 24 Mar 2009 21:07:40 +0000 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 n2OL7egM030467 for ; Tue, 24 Mar 2009 17:07:40 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2OL7eem027786 for ; Tue, 24 Mar 2009 21:07:40 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); Tue, 24 Mar 2009 17:07:40 -0400 Received: from [130.129.87.221] ([10.21.124.111]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 17:07:39 -0400 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Tue, 24 Mar 2009 14:07:36 -0700 From: Marc Linsner To: "'ECRIT'" Message-ID: Thread-Topic: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp Thread-Index: AcmsxI5v/73BBO/D6UqAlKMMVkxu1A== In-Reply-To: <49C945DE.9010308@bbn.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 24 Mar 2009 21:07:39.0833 (UTC) FILETIME=[90B83A90:01C9ACC4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9215; t=1237928860; x=1238792860; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20Proposal=20to=20add=20=22appl icability=22=20statementto=0A=20-framework/-phonebcp |Sender:=20 |To:=20=22'ECRIT'=22=20; bh=xoiZBppHmKgc8STAQ/DaDb8C70O07CLF/6ymBCpBqGk=; b=Y0EyTYaOQTSrITU5mZwj25GtxDbJ9v+2mN9vAKrryS0hsDlvfs6Qamx5NQ Zkw44n9z1/2Pvx8WMQq4A5emK60p+7AlvCfwfagP9+/upkcee7VtXv0HtGzW mZzvKg1O29; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Ecrit] Proposal to add "applicability" statementto -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:06:51 -0000 Not married to it....just trying to find common ground (and make it a little more IETF-ese). " This document describes an architecture for emergency calling contained within the common Internet environment. In this environment, the originating host bears most of the burden of implementing emergency calls, and the caller's Access Network Provider may have a supporting role. If such exists, the caller's Application Service Provider plays a minor role. The underlying specifications do allow for the Application Service Provider to take a more expansive role in emergency calls. However, such cases and any associated issues that arise outside this environment are for further study. " -Marc- On 3/24/09 1:43 PM, "Richard Barnes" wrote: > Sure, as long as the document later makes a distinction later on. May > be good to have a pointer in this para. > --Richard > > Brian Rosen wrote: >> Phonebcp differentiates between the access network and a (generic) "service >> provider". Will that do? >> >> Brian >> >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Tuesday, March 24, 2009 4:28 PM >> To: Brian Rosen >> Cc: 'Dawson, Martin'; Rosen, Brian; ecrit@ietf.org >> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >> -framework/-phonebcp >> >> "SIP"? That's the charter scope. The critical distinction is that it's >> at the application layer (where the application is whatever is being >> used to reach the PSAP). >> >> >> Brian Rosen wrote: >>> Better. "Voice" is too limiting. >>> >>> -----Original Message----- >>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>> Sent: Tuesday, March 24, 2009 3:04 PM >>> To: Brian Rosen >>> Cc: 'Dawson, Martin'; Rosen, Brian; ecrit@ietf.org >>> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >>> -framework/-phonebcp >>> >>> Aha, I get it. So both types of service provider show up. >>> -- The ISP MUST provide location information (in either case) >>> -- The VSP MAY add location and route calls >>> >>> Does the following capture it? (Also added a call out to >>> "interoperability issues" to address Mr. Gellens' concern): >>> >>> This document describes an architecture for emergency calling in the >>> typical Internet environment, in which the calling device bears most of >>> the burden of implementing emergency calls, and the caller's Internet >>> Service Provider has a supporting role. The caller's Voice Service >>> Provider plays a minor role, if such a provider is present at all. The >>> underlying specifications do allow for the Voice Service Provider to >>> take a more expansive role in emergency calls. However, such cases and >>> any associated issues (e.g., interoperability issues) are not covered >>> extensively in this document; rather, they are left for future study in >>> other documents. >>> >>> --Richard >>> >>> >>> Brian Rosen wrote: >>>> Richard >>>> >>>> We're not communicating. Where your sentence says "Internet Service >>>> Provider", I want it changed to "calling network service provider". It >> is >>>> the network that would add location and route calls, not the ISP. The >> ISP >>>> supplies location in both scenarios. The difference is to whom (the end >>>> device or the proxy in the calling network). >>>> >>>> Brian >>>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >>>> Richard Barnes >>>> Sent: Tuesday, March 24, 2009 1:26 PM >>>> To: Dawson, Martin >>>> Cc: Rosen, Brian; ecrit@ietf.org >>>> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >>>> -framework/-phonebcp >>>> >>>> Yes, I think we all agree, and agree that my original sentence was >>>> poorly constructed. >>>> >>>> Updated proposal: >>>> >>>> This document describes an architecture for emergency calling in the >>>> typical Internet environment, in which the calling device bears most of >>>> the burden of implementing emergency calls, and the caller's Internet >>>> Service Provider has a supporting role. The underlying specifications >>>> allow for the network to take a more expansive role in emergency calls, >>>> but such cases (and any associated issues) are not covered extensively >>>> in this document; rather, they are left for future study in other >>>> documents. >>>> >>>> >>>> Dawson, Martin wrote: >>>>> Apart from Richard's original statement, which I think parses to be the >>>>> opposite of intent, I think we're all agreeing... >>>>> >>>>> >>>>> >>>>> Richard's original statement was: >>>>> >>>>> >>>>> >>>>>> To be clear, it's the *Internet* Service Provider, not the *Voice* >>>>>> Service Provider, which may or may not be there. >>>>> That statement actually says that the ISP may or may not be there. I >>>>> don't think anybody actually thinks an Internet emergency call can be >>>>> made without some access to the Internet... :-) >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> Martin >>>>> >>>>> ________________________________ >>>>> >>>>> From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>> Sent: Tuesday, 24 March 2009 1:36 PM >>>>> To: rbarnes@bbn.com; Dawson, Martin >>>>> Cc: ecrit@ietf.org >>>>> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >>>>> -framework/-phonebcp >>>>> >>>>> >>>>> >>>>> No. >>>>> >>>>> The ISP requirements are unwaivering. >>>>> >>>>> [[MCD]] "requirements are unwaivering" = "it has requirements" in my >>>>> book. So I think we're saying the same thing. >>>>> >>>>> The VSP requirements change. The VSP, not the ISP adds location and >>>>> route, not the ISP. >>>>> >>>>> [[MCD]] "requirements change" = "may not be there" by the same token. >>>>> The device may query the LIS and LoST and send the INVITE directly to >>>>> the PSAP URI... so, yes, the ISP doesn't do it but nor is it necessary >>>>> for some VSP to do it. I think that's what we're all saying. >>>>> >>>>> >>>>> >>>>> Brian >>>>> ------Original Message------ >>>>> From: Richard Barnes >>>>> To: Dawson, Martin >>>>> Cc: Brian Rosen >>>>> Cc: ECRIT >>>>> Sent: Mar 23, 2009 5:03 PM >>>>> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >>>>> -framework/-phonebcp >>>>> >>>>> That's what I meant: >>>>> -- ISP plays a role in Framework (i.e., it has requirements) >>>>> -- VSP does not (no requirements - may not be there) >>>>> >>>>> Dawson, Martin wrote: >>>>>> Isn't that the other way around? The VSP may or may not be there? >>>>>> >>>>>> -----Original Message----- >>>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>>>>> Of Richard Barnes >>>>>> Sent: Tuesday, 24 March 2009 10:56 AM >>>>>> To: Rosen, Brian >>>>>> Cc: ECRIT >>>>>> Subject: Re: [Ecrit] Proposal to add "applicability" statementto >>>>>> -framework/-phonebcp >>>>>> >>>>>> To be clear, it's the *Internet* Service Provider, not the *Voice* >>>>>> Service Provider, which may or may not be there. >>>>>> >>>>>> In summary, s/IP access network/Internet Service Provider/ >>>>>> >>>>>> >>>>>> Rosen, Brian wrote: >>>>>>> Nah, it's not the access network (AN) it's the calling service >>>>>> provider >>>>>>> (SP) that is affected. The examples are adding location (who adds >>>>> the >>>>>>> Geolocation header) and the LoST query. Both of those would be done >>>>>> by >>>>>>> the SIP calling network in, for example, an IMS system. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>>>>> Sent: Monday, March 23, 2009 7:27 PM >>>>>>> To: Rosen, Brian >>>>>>> Cc: ECRIT >>>>>>> Subject: Re: [Ecrit] Proposal to add "applicability" statement to >>>>>>> -framework/-phonebcp >>>>>>> >>>>>>> Editorial changes: >>>>>>> >>>>>>> This document describes an architecture for emergency calling in the >>>>>>> typical Internet environment, in which the calling device bears most >>>>>> of >>>>> ------Original Message Truncated------ >>>>> >>>>> -------------------------- >>>>> Brian Rosen >>>>> NeuStar >>>>> (724) 382-1051 >>>>> brian.rosen@neustar.biz >>>>> >>>>> >> ---------------------------------------------------------------------------- >>>> -------------------- >>>>> 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://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>> >> >> > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From randy@qualcomm.com Tue Mar 24 14:32:02 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0953028C1CB for ; Tue, 24 Mar 2009 14:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.867 X-Spam-Level: X-Spam-Status: No, score=-102.867 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epCQC4JaYhBR for ; Tue, 24 Mar 2009 14:32:01 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 10E9728C1C9 for ; Tue, 24 Mar 2009 14:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1237930372; x=1269466372; h=message-id:in-reply-to:references:x-mailer: x-message-note:date:to:from:subject:cc:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20<7582BC68E4994F4ABF0BD4723975C3FA0D88065B @crexc41p>|References:=20=0D=0A=20<49C9179 5.=0D=0A=209030208@bbn.com>=0D=0A=20<00fd01c9acac$575e73d 0$061b5b70$@net><49C92E99.8080909@bbn.com>=0D=0A=20<01320 1c9acbd$31938e40$94baaac0$@net>=0D=0A=20<7582BC68E4994F4A BF0BD4723975C3FA0D88065B@crexc41p>|X-Mailer:=20Eudora=20f or=20Mac=20OS=20X|X-message-Note:=20Warning:=20Outlook=20 in=20use.=20=20Upgrade=20to=20Eudora:=20|Date:=20Tue,=2024=20Mar=202009=2014:32:23=20-0700 |To:=20"Stark,=20Barbara"=20,=20Brian=20R osen=20,=0D=0A=20=20=20=20=20=20=20=20 Richard=20Barnes=20|From:=20Randall=20Ge llens=20|Subject:=20Re:=20[Ecrit]=20P roposal=20to=20=09add"applicability"=09statementto=0D=0A =20-framework/-phonebcp|CC:=20"Dawson,=20Martin"=20,=20,=0D=0A=20=20=20 =20=20=20=20=20"Rosen,=0D=0A=20=09Brian"=20|MIME-Version:=201.0|Content-Type:=20text/plai n=3B=20charset=3D"us-ascii"=3B=20format=3Dflowed |X-Random-Sig-Tag:=201.0b28|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5563"=3B=20a=3D"16551843"; bh=oJaO0d+CV6mtetsOgd+cOpxp2BX73JMUfgfERnx1E/A=; b=U2mPqRhpS/Ow/N/1Gnq8SJVGbHdXhJGqJA4L7pc7bgaDWUe3ViSEWs4o xsfJngyFbWlHRk/+vNhRcD6l/hqrF+XRnU/nvE5JeWcLzEG0s/tETkhql wVEZcDRdgyTS5Xhza6h536O0kuWOyJuL6MJk7/G1blqFmqpOdwRVLwmT3 Y=; X-IronPort-AV: E=McAfee;i="5300,2777,5563"; a="16551843" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Mar 2009 14:32:52 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2OLWqVV027860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Mar 2009 14:32:52 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2OLWmeb012710 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Mar 2009 14:32:48 -0700 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 24 Mar 2009 14:32:47 -0700 Received: from [172.28.176.165] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 24 Mar 2009 14:32:47 -0700 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0D88065B@crexc41p> References: <49C91795. 9030208@bbn.com> <00fd01c9acac$575e73d0$061b5b70$@net><49C92E99.8080909@bbn.com> <013201c9acbd$31938e40$94baaac0$@net> <7582BC68E4994F4ABF0BD4723975C3FA0D88065B@crexc41p> X-Mailer: Eudora for Mac OS X X-message-Note: Warning: Outlook in use. Upgrade to Eudora: Date: Tue, 24 Mar 2009 14:32:23 -0700 To: "Stark, Barbara" , Brian Rosen , Richard Barnes From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 Cc: "Dawson, Martin" , ecrit@ietf.org, "Rosen, Brian" Subject: Re: [Ecrit] Proposal to add"applicability" statementto -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:32:02 -0000 At 4:35 PM -0400 3/24/09, Barbara Stark wrote: > I was doing fine with the course of this discussion till this > "interoperability" word came into the picture. I'm not convinced we have > an "interoperability issue". I do think that how this framework > "interconnects" to other networks is something that is not covered in > this document, and that it would be ok to say that this isn't covered. How about a sentence such as "Interworking between the framework described here and other frameworks is not currently specified." -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Language is a virus from outer space. --William S. Burroughs From Hannes.Tschofenig@gmx.net Tue Mar 24 14:39:28 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B65083A6A6B for ; Tue, 24 Mar 2009 14:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMBcBHPH4yFk for ; Tue, 24 Mar 2009 14:39:28 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 88E033A67FD for ; Tue, 24 Mar 2009 14:39:27 -0700 (PDT) Received: (qmail invoked by alias); 24 Mar 2009 21:40:16 -0000 Received: from dhcp-14f7.meeting.ietf.org (EHLO 4FIL42860) [130.129.20.247] by mail.gmx.net (mp034) with SMTP; 24 Mar 2009 22:40:16 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+/DWhZHwS/USCIELiF2aMGEVNPC9UxOZWZRuu6cv 7LGAK8m8aA+Axe From: "Hannes Tschofenig" To: "'Randall Gellens'" , "'Stark, Barbara'" , "'Brian Rosen'" , "'Richard Barnes'" References: <49C91795.9030208@bbn.com><00fd01c9acac$575e73d0$061b5b70$@net><49C92E99.8080909@bbn.com><013201c9acbd$31938e40$94baaac0$@net><7582BC68E4994F4ABF0BD4723975C3FA0D88065B@crexc41p> Date: Tue, 24 Mar 2009 14:41:28 -0700 Message-ID: <007901c9acc9$4f51ba90$421fa20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 thread-index: AcmsyBfU3lfwG7J7SKimj48KL7vxAwAARTHg X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Cc: "'Dawson, Martin'" , ecrit@ietf.org, "'Rosen, Brian'" Subject: Re: [Ecrit] Proposal to add"applicability" statementto -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:39:28 -0000 Btw, is the plan to put similar statements into 3GPP, etc. documents as well? >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Randall Gellens >Sent: 24 March, 2009 14:32 >To: Stark, Barbara; Brian Rosen; Richard Barnes >Cc: Dawson, Martin; ecrit@ietf.org; Rosen,Brian >Subject: Re: [Ecrit] Proposal to add"applicability" >statementto -framework/-phonebcp > >At 4:35 PM -0400 3/24/09, Barbara Stark wrote: > >> I was doing fine with the course of this discussion till this >> "interoperability" word came into the picture. I'm not convinced we >> have an "interoperability issue". I do think that how this >framework >> "interconnects" to other networks is something that is not >covered in >> this document, and that it would be ok to say that this >isn't covered. > >How about a sentence such as "Interworking between the >framework described here and other frameworks is not currently >specified." > >-- >Randall Gellens >Opinions are personal; facts are suspect; I speak for myself only >-------------- Randomly selected tag: --------------- Language >is a virus from outer space. --William S. Burroughs >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > From Martin.Thomson@andrew.com Tue Mar 24 14:40:52 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94CE03A6BD8 for ; Tue, 24 Mar 2009 14:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwQZNTfo6OoZ for ; Tue, 24 Mar 2009 14:40:51 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 9C2FA3A67FD for ; Tue, 24 Mar 2009 14:40:51 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_24_17_01_47 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 24 Mar 2009 17:01:47 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 16:41:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 24 Mar 2009 16:41:40 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposal to add"applicability" statementto -framework/-phonebcp Thread-Index: AcmsyBhB2HdHrWARSfGfD8aaoundzgAAIksA References: <49C91795.9030208@bbn.com><00fd01c9acac$575e73d0$061b5b70$@net><49C92E99.8080909@bbn.com><013201c9acbd$31938e40$94baaac0$@net><7582BC68E4994F4ABF0BD4723975C3FA0D88065B@crexc41p> From: "Thomson, Martin" To: "Randall Gellens" , "Stark, Barbara" , "Brian Rosen" , "Richard Barnes" X-OriginalArrivalTime: 24 Mar 2009 21:41:41.0866 (UTC) FILETIME=[51DDBCA0:01C9ACC9] Cc: "Dawson, Martin" , ecrit@ietf.org, "Rosen, Brian" Subject: Re: [Ecrit] Proposal to add"applicability" statementto -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:40:52 -0000 VGhhdCdzIHdoYXQgaXMgY29tbW9ubHkgcmVmZXJyZWQgdG8gYXMgYSAiZm9yd2FyZCBsb29raW5n IHN0YXRlbWVudCIuICBJIGRvbid0IGxpa2UgdGhlIHVzZSBvZiAiY3VycmVudGx5IiBvciAiYXQg dGhlIHRpbWUgb2Ygd3JpdGluZyIsIG9yIGFueXRoaW5nIGxpa2UgdGhhdC4NCg0KSSd2ZSB3YXRj aGVkIHRoaXMgZGlzY3Vzc2lvbiB3aXRoIGZhbHRlcmluZyBpbnRlcmVzdC4gIE15IGZlZWxpbmcg aXMgdGhhdCB0aGlzIGlzIGFuIGFsbW9zdCBmYXJjaWNhbCB3YXN0ZSBvZiBvdXIgdGltZS4NCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBlY3JpdC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIFJhbmRh bGwgR2VsbGVucw0KPiBTZW50OiBUdWVzZGF5LCAyNCBNYXJjaCAyMDA5IDI6MzIgUE0NCj4gVG86 IFN0YXJrLCBCYXJiYXJhOyBCcmlhbiBSb3NlbjsgUmljaGFyZCBCYXJuZXMNCj4gQ2M6IERhd3Nv biwgTWFydGluOyBlY3JpdEBpZXRmLm9yZzsgUm9zZW4sQnJpYW4NCj4gU3ViamVjdDogUmU6IFtF Y3JpdF0gUHJvcG9zYWwgdG8gYWRkImFwcGxpY2FiaWxpdHkiIHN0YXRlbWVudHRvIC0NCj4gZnJh bWV3b3JrLy1waG9uZWJjcA0KPiANCj4gQXQgNDozNSBQTSAtMDQwMCAzLzI0LzA5LCBCYXJiYXJh IFN0YXJrIHdyb3RlOg0KPiANCj4gPiAgSSB3YXMgZG9pbmcgZmluZSB3aXRoIHRoZSBjb3Vyc2Ug b2YgdGhpcyBkaXNjdXNzaW9uIHRpbGwgdGhpcw0KPiA+ICAiaW50ZXJvcGVyYWJpbGl0eSIgd29y ZCBjYW1lIGludG8gdGhlIHBpY3R1cmUuIEknbSBub3QgY29udmluY2VkIHdlDQo+IGhhdmUNCj4g PiAgYW4gImludGVyb3BlcmFiaWxpdHkgaXNzdWUiLiBJIGRvIHRoaW5rIHRoYXQgaG93IHRoaXMg ZnJhbWV3b3JrDQo+ID4gICJpbnRlcmNvbm5lY3RzIiB0byBvdGhlciBuZXR3b3JrcyBpcyBzb21l dGhpbmcgdGhhdCBpcyBub3QgY292ZXJlZA0KPiBpbg0KPiA+ICB0aGlzIGRvY3VtZW50LCBhbmQg dGhhdCBpdCB3b3VsZCBiZSBvayB0byBzYXkgdGhhdCB0aGlzIGlzbid0DQo+IGNvdmVyZWQuDQo+ IA0KPiBIb3cgYWJvdXQgYSBzZW50ZW5jZSBzdWNoIGFzICJJbnRlcndvcmtpbmcgYmV0d2VlbiB0 aGUgZnJhbWV3b3JrDQo+IGRlc2NyaWJlZCBoZXJlIGFuZCBvdGhlciBmcmFtZXdvcmtzIGlzIG5v dCBjdXJyZW50bHkgc3BlY2lmaWVkLiINCj4gDQo+IC0tDQo+IFJhbmRhbGwgR2VsbGVucw0KPiBP cGluaW9ucyBhcmUgcGVyc29uYWw7ICAgIGZhY3RzIGFyZSBzdXNwZWN0OyAgICBJIHNwZWFrIGZv ciBteXNlbGYgb25seQ0KPiAtLS0tLS0tLS0tLS0tLSBSYW5kb21seSBzZWxlY3RlZCB0YWc6IC0t LS0tLS0tLS0tLS0tLQ0KPiBMYW5ndWFnZSBpcyBhIHZpcnVzIGZyb20gb3V0ZXIgc3BhY2UuICAt LVdpbGxpYW0gUy4gQnVycm91Z2hzDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IEVjcml0IG1haWxpbmcgbGlzdA0KPiBFY3JpdEBpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUg ZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHBy b3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhh dmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRp YXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0K dGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpbbWYyXQ0K From bs7652@att.com Tue Mar 24 14:59:14 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E02D3A6A9A for ; Tue, 24 Mar 2009 14:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.959 X-Spam-Level: X-Spam-Status: No, score=-104.959 tagged_above=-999 required=5 tests=[AWL=-0.626, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXbGjrB7WCVo for ; Tue, 24 Mar 2009 14:59:13 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 5E1023A6A9D for ; Tue, 24 Mar 2009 14:59:13 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-2.tower-146.messagelabs.com!1237932004!11387871!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 15295 invoked from network); 24 Mar 2009 22:00:05 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-2.tower-146.messagelabs.com with AES256-SHA encrypted SMTP; 24 Mar 2009 22:00:05 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2OM01LY027834; Tue, 24 Mar 2009 18:00:03 -0400 Received: from 01GAF5142010625.AD.BLS.COM (01GAF5142010625.ad.bls.com [139.76.131.31]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id n2OLxsju027757; Tue, 24 Mar 2009 17:59:58 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 24 Mar 2009 17:59:57 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 24 Mar 2009 17:59:57 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 17:59:49 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0D880695@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposal to add"applicability" statementto -framework/-phonebcp thread-index: AcmsyBhB2HdHrWARSfGfD8aaoundzgAAIksAAABnhsA= References: <49C91795.9030208@bbn.com><00fd01c9acac$575e73d0$061b5b70$@net><49C92E99.8080909@bbn.com><013201c9acbd$31938e40$94baaac0$@net><7582BC68E4994F4ABF0BD4723975C3FA0D88065B@crexc41p> From: "Stark, Barbara" To: "Thomson, Martin" , "Randall Gellens" , "Brian Rosen" , "Richard Barnes" X-OriginalArrivalTime: 24 Mar 2009 21:59:57.0167 (UTC) FILETIME=[DEB767F0:01C9ACCB] Cc: "Dawson, Martin" , ecrit@ietf.org, "Rosen, Brian" Subject: Re: [Ecrit] Proposal to add"applicability" statementto -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:59:14 -0000 I agree that "currently" isn't needed in the sentence. Something either = is or isn't covered in the document. I also have a problem with = specifically bringing up other "frameworks" as not being covered. = There's so much that this document doesn't cover (which is fine, because = otherwise we'd never finish it). Basically, this document doesn't = describe interworking between this framework and anything external to = this framework. Barbara -----Original Message----- From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=20 Sent: Tuesday, March 24, 2009 5:42 PM To: Randall Gellens; Stark, Barbara; Brian Rosen; Richard Barnes Cc: Dawson, Martin; ecrit@ietf.org; Rosen,Brian Subject: RE: [Ecrit] Proposal to add"applicability" statementto = -framework/-phonebcp That's what is commonly referred to as a "forward looking statement". I = don't like the use of "currently" or "at the time of writing", or = anything like that. I've watched this discussion with faltering interest. My feeling is = that this is an almost farcical waste of our time. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Randall Gellens > Sent: Tuesday, 24 March 2009 2:32 PM > To: Stark, Barbara; Brian Rosen; Richard Barnes > Cc: Dawson, Martin; ecrit@ietf.org; Rosen,Brian > Subject: Re: [Ecrit] Proposal to add"applicability" statementto - > framework/-phonebcp >=20 > At 4:35 PM -0400 3/24/09, Barbara Stark wrote: >=20 > > I was doing fine with the course of this discussion till this > > "interoperability" word came into the picture. I'm not convinced we > have > > an "interoperability issue". I do think that how this framework > > "interconnects" to other networks is something that is not covered > in > > this document, and that it would be ok to say that this isn't > covered. >=20 > How about a sentence such as "Interworking between the framework > described here and other frameworks is not currently specified." >=20 > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > Language is a virus from outer space. --William S. Burroughs > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -------------------------------------------------------------------------= ----------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 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] ***** 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 From root@core3.amsl.com Tue Mar 24 16:00:01 2009 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id EB9153A6B9E; Tue, 24 Mar 2009 16:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090324230001.EB9153A6B9E@core3.amsl.com> Date: Tue, 24 Mar 2009 16:00:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-local-emergency-rph-namespace-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 23:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : IANA Registering a SIP Resource Priority Header Namespace for Local Emergency Communications Author(s) : J. Polk Filename : draft-ietf-ecrit-local-emergency-rph-namespace-03.txt Pages : 9 Date : 2009-03-24 This document creates and IANA registers the new Session Initiation Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for local emergency usage to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-namespace-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-local-emergency-rph-namespace-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-24154550.I-D@ietf.org> --NextPart-- From jmpolk@cisco.com Tue Mar 24 16:19:11 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 241143A681D for ; Tue, 24 Mar 2009 16:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.453 X-Spam-Level: X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fM6NJcdJW5H for ; Tue, 24 Mar 2009 16:19:10 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0D1773A67E1 for ; Tue, 24 Mar 2009 16:19:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,415,1233532800"; d="scan'208";a="161058844" Received: from syd-dkim-1.cisco.com ([64.104.193.116]) by sj-iport-1.cisco.com with ESMTP; 24 Mar 2009 23:20:01 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by syd-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n2ONJxOH001110 for ; Wed, 25 Mar 2009 10:20:00 +1100 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n2ONJx6V009274 for ; Tue, 24 Mar 2009 23:19: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); Tue, 24 Mar 2009 16:19:59 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.23.126]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Mar 2009 16:19:58 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 24 Mar 2009 18:19:54 -0500 To: "'ECRIT'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 24 Mar 2009 23:19:59.0078 (UTC) FILETIME=[0CE0E060:01C9ACD7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1019; t=1237936800; x=1238800800; c=relaxed/simple; s=syddkim1002; 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:=20Promised=20new=20version=20of=20=22esnet=22=20R PH |Sender:=20; bh=qQSjY25rtO6uGvmg/N/inxEUosffH5dyKFxX9+ZIdZw=; b=XPA0lSUovlMBMHUAA/i6skfx5BKqyhW82Hv/tg+jChy1cSjtNFkaLemVtu VDQ3APQ1U0WSVWEDgsqMvKrMbw1LVFK7GtqowfeDpG3DVlvRKcHE5XlKbXeK Ef5F6gEagqWIC/GHHFFUiZTv+CMicA1RIr+RZHA6MOVHC1Eumdtm4=; Authentication-Results: syd-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/syddkim1002 verified; ); Subject: [Ecrit] Promised new version of "esnet" RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 23:19:11 -0000 WG Here is the announcement of the new -03 version of the esnet resource-pirority header for this WG. How's that for fulfilling a promise from within 24 hours, eh? I believe this version addresses each of Janet's concerns from yesterday's session. Please comment at will James Title : IANA Registering a SIP Resource Priority Header Namespace for Local Emergency Communications Author(s) : J. Polk Filename : draft-ietf-ecrit-local-emergency-rph-namespace-03.txt Pages : 9 Date : 2009-03-24 This document creates and IANA registers the new Session Initiation Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for local emergency usage to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-namespace-03.txt From drage@alcatel-lucent.com Tue Mar 24 17:24:08 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0B8F3A6A0C for ; Tue, 24 Mar 2009 17:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYuonAArHCFk for ; Tue, 24 Mar 2009 17:24:08 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id C7BA73A69E1 for ; Tue, 24 Mar 2009 17:24:07 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2P0OaoQ020009 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Mar 2009 01:24:36 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 25 Mar 2009 01:24:36 +0100 From: "DRAGE, Keith (Keith)" To: Hannes Tschofenig , "'Randall Gellens'" , "'Stark, Barbara'" , "'Brian Rosen'" , "'Richard Barnes'" Date: Wed, 25 Mar 2009 01:24:37 +0100 Thread-Topic: [Ecrit] Proposal to add"applicability" statementto -framework/-phonebcp Thread-Index: AcmsyBfU3lfwG7J7SKimj48KL7vxAwAARTHgAAWtWoA= Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6757BE27C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <49C91795.9030208@bbn.com><00fd01c9acac$575e73d0$061b5b70$@net><49C92E99.8080909@bbn.com><013201c9acbd$31938e40$94baaac0$@net><7582BC68E4994F4ABF0BD4723975C3FA0D88065B@crexc41p> <007901c9acc9$4f51ba90$421fa20a@nsnintra.net> In-Reply-To: <007901c9acc9$4f51ba90$421fa20a@nsnintra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: "'Dawson, Martin'" , "ecrit@ietf.org" , "'Rosen, Brian'" Subject: Re: [Ecrit] Proposal to add"applicability" statementto -framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:24:09 -0000 I think you will find that the stage 3 3GPP document already contains the s= tatement of what it is applicable to. It does not in itself claim to solve = the worlds problems. That covers ETSI TISPAN and 3GPP2 as well. regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Hannes Tschofenig > Sent: Tuesday, March 24, 2009 9:41 PM > To: 'Randall Gellens'; 'Stark, Barbara'; 'Brian Rosen';=20 > 'Richard Barnes' > Cc: 'Dawson, Martin'; ecrit@ietf.org; 'Rosen, Brian' > Subject: Re: [Ecrit] Proposal to add"applicability"=20 > statementto -framework/-phonebcp >=20 > Btw, is the plan to put similar statements into 3GPP, etc.=20 > documents as well?=20 >=20 > >-----Original Message----- > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf=20 > >Of Randall Gellens > >Sent: 24 March, 2009 14:32 > >To: Stark, Barbara; Brian Rosen; Richard Barnes > >Cc: Dawson, Martin; ecrit@ietf.org; Rosen,Brian > >Subject: Re: [Ecrit] Proposal to add"applicability"=20 > >statementto -framework/-phonebcp > > > >At 4:35 PM -0400 3/24/09, Barbara Stark wrote: > > > >> I was doing fine with the course of this discussion till this=20 > >> "interoperability" word came into the picture. I'm not=20 > convinced we=20 > >> have an "interoperability issue". I do think that how this > >framework > >> "interconnects" to other networks is something that is not > >covered in > >> this document, and that it would be ok to say that this > >isn't covered. > > > >How about a sentence such as "Interworking between the framework=20 > >described here and other frameworks is not currently specified." > > > >-- > >Randall Gellens > >Opinions are personal; facts are suspect; I speak for=20 > myself only > >-------------- Randomly selected tag: --------------- Language is a=20 > >virus from outer space. --William S. Burroughs=20 > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From Martin.Dawson@andrew.com Tue Mar 24 17:33:02 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D5983A6880 for ; Tue, 24 Mar 2009 17:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.86 X-Spam-Level: X-Spam-Status: No, score=-0.86 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9qlzxFkOTmn for ; Tue, 24 Mar 2009 17:33:01 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 8EA343A68A4 for ; Tue, 24 Mar 2009 17:33:01 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_24_19_53_57 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 24 Mar 2009 19:53:56 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 19:33:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 19:33:48 -0500 Message-ID: In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D6757BE27C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposal to add"applicability" statementto-framework/-phonebcp Thread-Index: AcmsyBfU3lfwG7J7SKimj48KL7vxAwAARTHgAAWtWoAAAFIagA== References: <49C91795.9030208@bbn.com><00fd01c9acac$575e73d0$061b5b70$@net><49C92E99.8080909@bbn.com><013201c9acbd$31938e40$94baaac0$@net><7582BC68E4994F4ABF0BD4723975C3FA0D88065B@crexc41p> <007901c9acc9$4f51ba90$421fa20a@nsnintra.net> <28B7C3AA2A7ABA4A841F11217ABE78D6757BE27C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> From: "Dawson, Martin" To: "DRAGE, Keith (Keith)" , "Hannes Tschofenig" , "Randall Gellens" , "Stark, Barbara" , "Brian Rosen" , "Richard Barnes" X-OriginalArrivalTime: 25 Mar 2009 00:33:50.0799 (UTC) FILETIME=[5E63D5F0:01C9ACE1] Cc: "Rosen, Brian" , ecrit@ietf.org Subject: Re: [Ecrit] Proposal to add"applicability" statementto-framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:33:02 -0000 Sure - but do they actually say "This framework may not address=0D=0Arequir= ements that are addressed by other frameworks"=3F Which is what is=0D=0Aact= ually being asked for here. And which, btw, I think is a pretty=0D=0Apointl= ess comment anyway.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original= Message-----=0D=0AFrom: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.= com]=20=0D=0ASent: Wednesday, 25 March 2009 11:25 AM=0D=0ATo: Hannes Tschof= enig; 'Randall Gellens'; 'Stark, Barbara'; 'Brian=0D=0ARosen'; 'Richard Bar= nes'=0D=0ACc: Dawson, Martin; ecrit@ietf.org; 'Rosen, Brian'=0D=0ASubject: = RE: [Ecrit] Proposal to add"applicability"=0D=0Astatementto-framework/-phon= ebcp=0D=0A=0D=0AI think you will find that the stage 3 3GPP document alread= y contains=0D=0Athe statement of what it is applicable to. It does not in i= tself claim=0D=0Ato solve the worlds problems.=0D=0A=0D=0AThat covers ETSI = TISPAN and 3GPP2 as well.=0D=0A=0D=0Aregards=0D=0A=0D=0AKeith=0D=0A=0D=0A> = -----Original Message-----=0D=0A> From: ecrit-bounces@ietf.org [mailto:ecri= t-bounces@ietf.org]=20=0D=0A> On Behalf Of Hannes Tschofenig=0D=0A> Sent: T= uesday, March 24, 2009 9:41 PM=0D=0A> To: 'Randall Gellens'; 'Stark, Barbar= a'; 'Brian Rosen';=20=0D=0A> 'Richard Barnes'=0D=0A> Cc: 'Dawson, Martin'; = ecrit@ietf.org; 'Rosen, Brian'=0D=0A> Subject: Re: [Ecrit] Proposal to add"= applicability"=20=0D=0A> statementto -framework/-phonebcp=0D=0A>=20=0D=0A> = Btw, is the plan to put similar statements into 3GPP, etc.=20=0D=0A> docume= nts as well=3F=20=0D=0A>=20=0D=0A> >-----Original Message-----=0D=0A> >From= : ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20=0D=0A> On Behal= f=20=0D=0A> >Of Randall Gellens=0D=0A> >Sent: 24 March, 2009 14:32=0D=0A> >= To: Stark, Barbara; Brian Rosen; Richard Barnes=0D=0A> >Cc: Dawson, Martin;= ecrit@ietf.org; Rosen,Brian=0D=0A> >Subject: Re: [Ecrit] Proposal to add"a= pplicability"=20=0D=0A> >statementto -framework/-phonebcp=0D=0A> >=0D=0A> >= At 4:35 PM -0400 3/24/09, Barbara Stark wrote:=0D=0A> >=0D=0A> >> I was do= ing fine with the course of this discussion till this=20=0D=0A> >> "interop= erability" word came into the picture. I'm not=20=0D=0A> convinced we=20=0D= =0A> >> have an "interoperability issue". I do think that how this=0D=0A> = >framework=0D=0A> >> "interconnects" to other networks is something that is= not=0D=0A> >covered in=0D=0A> >> this document, and that it would be ok to= say that this=0D=0A> >isn't covered.=0D=0A> >=0D=0A> >How about a sentence= such as "Interworking between the framework=20=0D=0A> >described here and = other frameworks is not currently specified."=0D=0A> >=0D=0A> >--=0D=0A> >R= andall Gellens=0D=0A> >Opinions are personal; facts are suspect; I sp= eak for=20=0D=0A> myself only=0D=0A> >-------------- Randomly selected tag:= --------------- Language is a=20=0D=0A> >virus from outer space. --Willia= m S. Burroughs=20=0D=0A> >_______________________________________________=0D= =0A> >Ecrit mailing list=0D=0A> >Ecrit@ietf.org=0D=0A> >https://www.ietf.or= g/mailman/listinfo/ecrit=0D=0A> >=0D=0A>=20=0D=0A> ________________________= _______________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A= > https://www.ietf.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A--------------= ---------------------------------------------------------------------------= -------=0D=0AThis message is for the designated recipient only and may=0D=0A= contain privileged, proprietary, or otherwise private information. =20=0D=0A= If you have received it in error, please notify the sender=0D=0Aimmediately= and delete the original. Any unauthorized use of=0D=0Athis email is prohi= bited.=0D=0A---------------------------------------------------------------= ---------------------------------=0D=0A[mf2]=0D=0A From drage@alcatel-lucent.com Tue Mar 24 17:40:03 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A5363A6A02 for ; Tue, 24 Mar 2009 17:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.939 X-Spam-Level: X-Spam-Status: No, score=-5.939 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iq6C+Wg0SZYi for ; Tue, 24 Mar 2009 17:40:02 -0700 (PDT) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id A70503A68A7 for ; Tue, 24 Mar 2009 17:40:01 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2P0drNo021658 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Mar 2009 01:39:53 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 25 Mar 2009 01:39:53 +0100 From: "DRAGE, Keith (Keith)" To: "Dawson, Martin" , Hannes Tschofenig , Randall Gellens , "Stark, Barbara" , Brian Rosen , Richard Barnes Date: Wed, 25 Mar 2009 01:39:55 +0100 Thread-Topic: [Ecrit] Proposal to add"applicability" statementto-framework/-phonebcp Thread-Index: AcmsyBfU3lfwG7J7SKimj48KL7vxAwAARTHgAAWtWoAAAFIagAAAPatg Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6757BE282@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <49C91795.9030208@bbn.com><00fd01c9acac$575e73d0$061b5b70$@net><49C92E99.8080909@bbn.com><013201c9acbd$31938e40$94baaac0$@net><7582BC68E4994F4ABF0BD4723975C3FA0D88065B@crexc41p> <007901c9acc9$4f51ba90$421fa20a@nsnintra.net> <28B7C3AA2A7ABA4A841F11217ABE78D6757BE27C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] Proposal to add"applicability" statementto-framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:40:03 -0000 As it does not provide the chance for meeting another framework, it doesn't= need to. The ecrit documents do. Keith=20 > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20 > Sent: Wednesday, March 25, 2009 12:34 AM > To: DRAGE, Keith (Keith); Hannes Tschofenig; Randall Gellens;=20 > Stark, Barbara; Brian Rosen; Richard Barnes > Cc: ecrit@ietf.org; Rosen, Brian > Subject: RE: [Ecrit] Proposal to add"applicability"=20 > statementto-framework/-phonebcp >=20 > Sure - but do they actually say "This framework may not=20 > address requirements that are addressed by other frameworks"?=20 > Which is what is actually being asked for here. And which,=20 > btw, I think is a pretty pointless comment anyway. >=20 > Cheers, > Martin >=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Wednesday, 25 March 2009 11:25 AM > To: Hannes Tschofenig; 'Randall Gellens'; 'Stark, Barbara';=20 > 'Brian Rosen'; 'Richard Barnes' > Cc: Dawson, Martin; ecrit@ietf.org; 'Rosen, Brian' > Subject: RE: [Ecrit] Proposal to add"applicability" > statementto-framework/-phonebcp >=20 > I think you will find that the stage 3 3GPP document already=20 > contains the statement of what it is applicable to. It does=20 > not in itself claim to solve the worlds problems. >=20 > That covers ETSI TISPAN and 3GPP2 as well. >=20 > regards >=20 > Keith >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > > Of Hannes Tschofenig > > Sent: Tuesday, March 24, 2009 9:41 PM > > To: 'Randall Gellens'; 'Stark, Barbara'; 'Brian Rosen'; 'Richard=20 > > Barnes' > > Cc: 'Dawson, Martin'; ecrit@ietf.org; 'Rosen, Brian' > > Subject: Re: [Ecrit] Proposal to add"applicability"=20 > > statementto -framework/-phonebcp > >=20 > > Btw, is the plan to put similar statements into 3GPP, etc.=20 > > documents as well?=20 > >=20 > > >-----Original Message----- > > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > On Behalf > > >Of Randall Gellens > > >Sent: 24 March, 2009 14:32 > > >To: Stark, Barbara; Brian Rosen; Richard Barnes > > >Cc: Dawson, Martin; ecrit@ietf.org; Rosen,Brian > > >Subject: Re: [Ecrit] Proposal to add"applicability"=20 > > >statementto -framework/-phonebcp > > > > > >At 4:35 PM -0400 3/24/09, Barbara Stark wrote: > > > > > >> I was doing fine with the course of this discussion till this=20 > > >> "interoperability" word came into the picture. I'm not > > convinced we > > >> have an "interoperability issue". I do think that how this > > >framework > > >> "interconnects" to other networks is something that is not > > >covered in > > >> this document, and that it would be ok to say that this > > >isn't covered. > > > > > >How about a sentence such as "Interworking between the framework=20 > > >described here and other frameworks is not currently specified." > > > > > >-- > > >Randall Gellens > > >Opinions are personal; facts are suspect; I speak for=20 > > myself only > > >-------------- Randomly selected tag: ---------------=20 > Language is a=20 > > >virus from outer space. --William S. Burroughs=20 > > >_______________________________________________ > > >Ecrit mailing list > > >Ecrit@ietf.org > > >https://www.ietf.org/mailman/listinfo/ecrit > > > > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may=20 > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender=20 > immediately and delete the original. Any unauthorized use of=20 > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 > = From James.Winterbottom@andrew.com Tue Mar 24 17:48:12 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96EBE3A69D8 for ; Tue, 24 Mar 2009 17:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.017 X-Spam-Level: X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAiY4U3p6FEm for ; Tue, 24 Mar 2009 17:48:11 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 46C553A6A88 for ; Tue, 24 Mar 2009 17:48:04 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_24_20_09_01 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 24 Mar 2009 20:09:01 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 19:48:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 19:48:53 -0500 Message-ID: In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D6757BE282@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposal toadd"applicability" statementto-framework/-phonebcp Thread-Index: AcmsyBfU3lfwG7J7SKimj48KL7vxAwAARTHgAAWtWoAAAFIagAAAPatgAABJFeA= References: <49C91795.9030208@bbn.com><00fd01c9acac$575e73d0$061b5b70$@net><49C92E99.8080909@bbn.com><013201c9acbd$31938e40$94baaac0$@net><7582BC68E4994F4ABF0BD4723975C3FA0D88065B@crexc41p><007901c9acc9$4f51ba90$421fa20a@nsnintra.net><28B7C3AA2A7ABA4A841F11217ABE78D6757BE27C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <28B7C3AA2A7ABA4A841F11217ABE78D6757BE282@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> From: "Winterbottom, James" To: "DRAGE, Keith (Keith)" , "Dawson, Martin" , "Hannes Tschofenig" , "Randall Gellens" , "Stark,Barbara" , "Brian Rosen" , "Richard Barnes" X-OriginalArrivalTime: 25 Mar 2009 00:48:55.0723 (UTC) FILETIME=[79C447B0:01C9ACE3] Cc: "Rosen, Brian" , ecrit@ietf.org Subject: Re: [Ecrit] Proposal toadd"applicability" statementto-framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:48:12 -0000 So be clear then Keith you are saying that the 3GPP document clearly=0D=0As= tate that unvetted Internet access MUST NOT be allowed through networks=0D=0A= that support these protocols=3F=0D=0A=0D=0AUnless they say that then the 3G= PP document absolutely do collide with=0D=0Aother frameworks and the same d= egree of applicability is there!=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D= =0A-----Original Message-----=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecr= it-bounces@ietf.org] On Behalf=0D=0AOf DRAGE, Keith (Keith)=0D=0ASent: Wedn= esday, 25 March 2009 11:40 AM=0D=0ATo: Dawson, Martin; Hannes Tschofenig; R= andall Gellens; Stark,Barbara;=0D=0ABrian Rosen; Richard Barnes=0D=0ACc: Ro= sen, Brian; ecrit@ietf.org=0D=0ASubject: Re: [Ecrit] Proposal toadd"applica= bility"=0D=0Astatementto-framework/-phonebcp=0D=0A=0D=0AAs it does not prov= ide the chance for meeting another framework, it=0D=0Adoesn't need to. The = ecrit documents do.=0D=0A=0D=0AKeith=20=0D=0A=0D=0A> -----Original Message-= ----=0D=0A> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20=0D=0A= > Sent: Wednesday, March 25, 2009 12:34 AM=0D=0A> To: DRAGE, Keith (Keith);= Hannes Tschofenig; Randall Gellens;=20=0D=0A> Stark, Barbara; Brian Rosen;= Richard Barnes=0D=0A> Cc: ecrit@ietf.org; Rosen, Brian=0D=0A> Subject: RE:= [Ecrit] Proposal to add"applicability"=20=0D=0A> statementto-framework/-ph= onebcp=0D=0A>=20=0D=0A> Sure - but do they actually say "This framework may= not=20=0D=0A> address requirements that are addressed by other frameworks"= =3F=20=0D=0A> Which is what is actually being asked for here. And which, =0D= =0A> btw, I think is a pretty pointless comment anyway.=0D=0A>=20=0D=0A> Ch= eers,=0D=0A> Martin=0D=0A>=20=0D=0A> -----Original Message-----=0D=0A> From= : DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=0D=0A> Sent: Wedne= sday, 25 March 2009 11:25 AM=0D=0A> To: Hannes Tschofenig; 'Randall Gellens= '; 'Stark, Barbara';=20=0D=0A> 'Brian Rosen'; 'Richard Barnes'=0D=0A> Cc: D= awson, Martin; ecrit@ietf.org; 'Rosen, Brian'=0D=0A> Subject: RE: [Ecrit] P= roposal to add"applicability"=0D=0A> statementto-framework/-phonebcp=0D=0A>= =20=0D=0A> I think you will find that the stage 3 3GPP document already=20=0D= =0A> contains the statement of what it is applicable to. It does=20=0D=0A> = not in itself claim to solve the worlds problems.=0D=0A>=20=0D=0A> That cov= ers ETSI TISPAN and 3GPP2 as well.=0D=0A>=20=0D=0A> regards=0D=0A>=20=0D=0A= > Keith=0D=0A>=20=0D=0A> > -----Original Message-----=0D=0A> > From: ecrit-= bounces@ietf.org=20=0D=0A> [mailto:ecrit-bounces@ietf.org] On Behalf=20=0D=0A= > > Of Hannes Tschofenig=0D=0A> > Sent: Tuesday, March 24, 2009 9:41 PM=0D=0A= > > To: 'Randall Gellens'; 'Stark, Barbara'; 'Brian Rosen'; 'Richard=20=0D=0A= > > Barnes'=0D=0A> > Cc: 'Dawson, Martin'; ecrit@ietf.org; 'Rosen, Brian'=0D= =0A> > Subject: Re: [Ecrit] Proposal to add"applicability"=20=0D=0A> > stat= ementto -framework/-phonebcp=0D=0A> >=20=0D=0A> > Btw, is the plan to put s= imilar statements into 3GPP, etc.=20=0D=0A> > documents as well=3F=20=0D=0A= > >=20=0D=0A> > >-----Original Message-----=0D=0A> > >From: ecrit-bounces@i= etf.org [mailto:ecrit-bounces@ietf.org]=0D=0A> > On Behalf=0D=0A> > >Of Ran= dall Gellens=0D=0A> > >Sent: 24 March, 2009 14:32=0D=0A> > >To: Stark, Barb= ara; Brian Rosen; Richard Barnes=0D=0A> > >Cc: Dawson, Martin; ecrit@ietf.o= rg; Rosen,Brian=0D=0A> > >Subject: Re: [Ecrit] Proposal to add"applicabilit= y"=20=0D=0A> > >statementto -framework/-phonebcp=0D=0A> > >=0D=0A> > >At 4:= 35 PM -0400 3/24/09, Barbara Stark wrote:=0D=0A> > >=0D=0A> > >> I was doi= ng fine with the course of this discussion till this=20=0D=0A> > >> "intero= perability" word came into the picture. I'm not=0D=0A> > convinced we=0D=0A= > > >> have an "interoperability issue". I do think that how this=0D=0A> >= >framework=0D=0A> > >> "interconnects" to other networks is something that= is not=0D=0A> > >covered in=0D=0A> > >> this document, and that it would b= e ok to say that this=0D=0A> > >isn't covered.=0D=0A> > >=0D=0A> > >How abo= ut a sentence such as "Interworking between the framework=20=0D=0A> > >desc= ribed here and other frameworks is not currently specified."=0D=0A> > >=0D=0A= > > >--=0D=0A> > >Randall Gellens=0D=0A> > >Opinions are personal; facts= are suspect; I speak for=20=0D=0A> > myself only=0D=0A> > >------------= -- Randomly selected tag: ---------------=20=0D=0A> Language is a=20=0D=0A>= > >virus from outer space. --William S. Burroughs=20=0D=0A> > >__________= _____________________________________=0D=0A> > >Ecrit mailing list=0D=0A> >= >Ecrit@ietf.org=0D=0A> > >https://www.ietf.org/mailman/listinfo/ecrit=0D=0A= > > >=0D=0A> >=20=0D=0A> > _______________________________________________=0D= =0A> > Ecrit mailing list=0D=0A> > Ecrit@ietf.org=0D=0A> > https://www.ietf= =2Eorg/mailman/listinfo/ecrit=0D=0A> >=20=0D=0A> --------------------------= ------------------------------------=0D=0A> -------------------------------= ---=0D=0A> This message is for the designated recipient only and may=20=0D=0A= > contain privileged, proprietary, or otherwise private information. =20=0D= =0A> If you have received it in error, please notify the sender=20=0D=0A> i= mmediately and delete the original. Any unauthorized use of=20=0D=0A> this= email is prohibited.=0D=0A> ----------------------------------------------= ----------------=0D=0A> ----------------------------------=0D=0A> [mf2]=0D=0A= >=20=0D=0A>=20=0D=0A_______________________________________________=0D=0AEc= rit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman/list= info/ecrit=0D=0A=0D=0A-----------------------------------------------------= -------------------------------------------=0D=0AThis message is for the de= signated recipient only and may=0D=0Acontain privileged, proprietary, or ot= herwise private information. =20=0D=0AIf you have received it in error, ple= ase notify the sender=0D=0Aimmediately and delete the original. Any unauth= orized use of=0D=0Athis email is prohibited.=0D=0A-------------------------= -----------------------------------------------------------------------=0D=0A= [mf2]=0D=0A From jgunn6@csc.com Tue Mar 24 17:48:12 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4F233A6A88; Tue, 24 Mar 2009 17:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRvgjiPTc6qW; Tue, 24 Mar 2009 17:48:11 -0700 (PDT) Received: from mail86.messagelabs.com (mail86.messagelabs.com [216.82.242.179]) by core3.amsl.com (Postfix) with ESMTP id 00AA03A69CA; Tue, 24 Mar 2009 17:47:52 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-14.tower-86.messagelabs.com!1237942123!6295639!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 20814 invoked from network); 25 Mar 2009 00:48:43 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-14.tower-86.messagelabs.com with AES256-SHA encrypted SMTP; 25 Mar 2009 00:48:43 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n2P0mgC3030733; Tue, 24 Mar 2009 20:48:42 -0400 In-Reply-To: To: "James M. Polk" MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF83 November 04, 2004 From: Janet P Gunn Message-ID: Date: Tue, 24 Mar 2009 20:48:39 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.0.1 HF996|December 23, 2008) at 03/24/2009 08:50:54 PM, Serialize complete at 03/24/2009 08:50:54 PM Content-Type: multipart/alternative; boundary="=_alternative 0004736485257584_=" Cc: 'ECRIT' , ecrit-bounces@ietf.org Subject: Re: [Ecrit] Promised new version of "esnet" RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:48:12 -0000 This is a multipart message in MIME format. --=_alternative 0004736485257584_= Content-Type: text/plain; charset="US-ASCII" The changes in the 03 version address my concerns. As far as I am concerns it is now ready to go. Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. "James M. Polk" Sent by: ecrit-bounces@ietf.org 03/24/2009 07:19 PM To "'ECRIT'" cc Subject [Ecrit] Promised new version of "esnet" RPH WG Here is the announcement of the new -03 version of the esnet resource-pirority header for this WG. How's that for fulfilling a promise from within 24 hours, eh? I believe this version addresses each of Janet's concerns from yesterday's session. Please comment at will James Title : IANA Registering a SIP Resource Priority Header Namespace for Local Emergency Communications Author(s) : J. Polk Filename : draft-ietf-ecrit-local-emergency-rph-namespace-03.txt Pages : 9 Date : 2009-03-24 This document creates and IANA registers the new Session Initiation Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for local emergency usage to a public safety answering point (PSAP), between PSAPs, and between a PSAP and first responders and their organizations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-namespace-03.txt _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --=_alternative 0004736485257584_= Content-Type: text/html; charset="US-ASCII"
The changes in the 03 version address my concerns.  As far as I am concerns it is now ready to go.

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.


"James M. Polk" <jmpolk@cisco.com>
Sent by: ecrit-bounces@ietf.org

03/24/2009 07:19 PM

To
"'ECRIT'" <ecrit@ietf.org>
cc
Subject
[Ecrit] Promised new version of "esnet" RPH





WG

Here is the announcement of the new -03 version of the esnet
resource-pirority header for this WG.  How's that for fulfilling a
promise from within 24 hours, eh?

I believe this version addresses each of Janet's concerns from
yesterday's session.

Please comment at will

James

                Title           : IANA Registering a SIP Resource Priority Header
Namespace for
                                Local Emergency Communications
                Author(s)       : J. Polk
                Filename        : draft-ietf-ecrit-local-emergency-rph-namespace-03.txt
                Pages           : 9
                Date            : 2009-03-24

This document creates and IANA registers the new Session Initiation
Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for
local emergency usage to a public safety answering point (PSAP),
between PSAPs, and between a PSAP and first responders and their
organizations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-namespace-03.txt

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
--=_alternative 0004736485257584_=-- From Martin.Dawson@andrew.com Tue Mar 24 17:53:45 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 044553A69FB for ; Tue, 24 Mar 2009 17:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.843 X-Spam-Level: X-Spam-Status: No, score=-0.843 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxZtsjEZ8wTd for ; Tue, 24 Mar 2009 17:53:44 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 054793A6880 for ; Tue, 24 Mar 2009 17:53:43 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_24_20_14_40 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 24 Mar 2009 20:14:40 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Mar 2009 19:54:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Mar 2009 19:54:32 -0500 Message-ID: In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D6757BE282@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposal to add"applicability"statementto-framework/-phonebcp Thread-Index: AcmsyBfU3lfwG7J7SKimj48KL7vxAwAARTHgAAWtWoAAAFIagAAAPatgAAB9lAA= References: <49C91795.9030208@bbn.com><00fd01c9acac$575e73d0$061b5b70$@net><49C92E99.8080909@bbn.com><013201c9acbd$31938e40$94baaac0$@net><7582BC68E4994F4ABF0BD4723975C3FA0D88065B@crexc41p> <007901c9acc9$4f51ba90$421fa20a@nsnintra.net> <28B7C3AA2A7ABA4A841F11217ABE78D6757BE27C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <28B7C3AA2A7ABA4A841F11217ABE78D6757BE282@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> From: "Dawson, Martin" To: "DRAGE, Keith (Keith)" , "Hannes Tschofenig" , "Randall Gellens" , "Stark, Barbara" , "Brian Rosen" , "Richard Barnes" X-OriginalArrivalTime: 25 Mar 2009 00:54:35.0026 (UTC) FILETIME=[4401CF20:01C9ACE4] Cc: "Rosen, Brian" , ecrit@ietf.org Subject: Re: [Ecrit] Proposal to add"applicability"statementto-framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:53:45 -0000 The apparent lack of logical symmetry in that comment baffles me.=0D=0A=0D=0A= Cheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: DRAGE,= Keith (Keith) [mailto:drage@alcatel-lucent.com]=20=0D=0ASent: Wednesday, 2= 5 March 2009 11:40 AM=0D=0ATo: Dawson, Martin; Hannes Tschofenig; Randall G= ellens; Stark, Barbara;=0D=0ABrian Rosen; Richard Barnes=0D=0ACc: ecrit@iet= f.org; Rosen, Brian=0D=0ASubject: RE: [Ecrit] Proposal to=0D=0Aadd"applicab= ility"statementto-framework/-phonebcp=0D=0A=0D=0AAs it does not provide the= chance for meeting another framework, it=0D=0Adoesn't need to. The ecrit d= ocuments do.=0D=0A=0D=0AKeith=20=0D=0A=0D=0A> -----Original Message-----=0D= =0A> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20=0D=0A> Sent:= Wednesday, March 25, 2009 12:34 AM=0D=0A> To: DRAGE, Keith (Keith); Hannes= Tschofenig; Randall Gellens;=20=0D=0A> Stark, Barbara; Brian Rosen; Richar= d Barnes=0D=0A> Cc: ecrit@ietf.org; Rosen, Brian=0D=0A> Subject: RE: [Ecrit= ] Proposal to add"applicability"=20=0D=0A> statementto-framework/-phonebcp=0D= =0A>=20=0D=0A> Sure - but do they actually say "This framework may not=20=0D= =0A> address requirements that are addressed by other frameworks"=3F=20=0D=0A= > Which is what is actually being asked for here. And which,=20=0D=0A> btw,= I think is a pretty pointless comment anyway.=0D=0A>=20=0D=0A> Cheers,=0D=0A= > Martin=0D=0A>=20=0D=0A> -----Original Message-----=0D=0A> From: DRAGE, Ke= ith (Keith) [mailto:drage@alcatel-lucent.com]=0D=0A> Sent: Wednesday, 25 Ma= rch 2009 11:25 AM=0D=0A> To: Hannes Tschofenig; 'Randall Gellens'; 'Stark, = Barbara';=20=0D=0A> 'Brian Rosen'; 'Richard Barnes'=0D=0A> Cc: Dawson, Mart= in; ecrit@ietf.org; 'Rosen, Brian'=0D=0A> Subject: RE: [Ecrit] Proposal to = add"applicability"=0D=0A> statementto-framework/-phonebcp=0D=0A>=20=0D=0A> = I think you will find that the stage 3 3GPP document already=20=0D=0A> cont= ains the statement of what it is applicable to. It does=20=0D=0A> not in it= self claim to solve the worlds problems.=0D=0A>=20=0D=0A> That covers ETSI = TISPAN and 3GPP2 as well.=0D=0A>=20=0D=0A> regards=0D=0A>=20=0D=0A> Keith=0D= =0A>=20=0D=0A> > -----Original Message-----=0D=0A> > From: ecrit-bounces@ie= tf.org=20=0D=0A> [mailto:ecrit-bounces@ietf.org] On Behalf=20=0D=0A> > Of H= annes Tschofenig=0D=0A> > Sent: Tuesday, March 24, 2009 9:41 PM=0D=0A> > To= : 'Randall Gellens'; 'Stark, Barbara'; 'Brian Rosen'; 'Richard=20=0D=0A> > = Barnes'=0D=0A> > Cc: 'Dawson, Martin'; ecrit@ietf.org; 'Rosen, Brian'=0D=0A= > > Subject: Re: [Ecrit] Proposal to add"applicability"=20=0D=0A> > stateme= ntto -framework/-phonebcp=0D=0A> >=20=0D=0A> > Btw, is the plan to put simi= lar statements into 3GPP, etc.=20=0D=0A> > documents as well=3F=20=0D=0A> >= =20=0D=0A> > >-----Original Message-----=0D=0A> > >From: ecrit-bounces@ietf= =2Eorg [mailto:ecrit-bounces@ietf.org]=0D=0A> > On Behalf=0D=0A> > >Of Rand= all Gellens=0D=0A> > >Sent: 24 March, 2009 14:32=0D=0A> > >To: Stark, Barba= ra; Brian Rosen; Richard Barnes=0D=0A> > >Cc: Dawson, Martin; ecrit@ietf.or= g; Rosen,Brian=0D=0A> > >Subject: Re: [Ecrit] Proposal to add"applicability= "=20=0D=0A> > >statementto -framework/-phonebcp=0D=0A> > >=0D=0A> > >At 4:3= 5 PM -0400 3/24/09, Barbara Stark wrote:=0D=0A> > >=0D=0A> > >> I was doin= g fine with the course of this discussion till this=20=0D=0A> > >> "interop= erability" word came into the picture. I'm not=0D=0A> > convinced we=0D=0A>= > >> have an "interoperability issue". I do think that how this=0D=0A> > = >framework=0D=0A> > >> "interconnects" to other networks is something that = is not=0D=0A> > >covered in=0D=0A> > >> this document, and that it would be= ok to say that this=0D=0A> > >isn't covered.=0D=0A> > >=0D=0A> > >How abou= t a sentence such as "Interworking between the framework=20=0D=0A> > >descr= ibed here and other frameworks is not currently specified."=0D=0A> > >=0D=0A= > > >--=0D=0A> > >Randall Gellens=0D=0A> > >Opinions are personal; facts= are suspect; I speak for=20=0D=0A> > myself only=0D=0A> > >------------= -- Randomly selected tag: ---------------=20=0D=0A> Language is a=20=0D=0A>= > >virus from outer space. --William S. Burroughs=20=0D=0A> > >__________= _____________________________________=0D=0A> > >Ecrit mailing list=0D=0A> >= >Ecrit@ietf.org=0D=0A> > >https://www.ietf.org/mailman/listinfo/ecrit=0D=0A= > > >=0D=0A> >=20=0D=0A> > _______________________________________________=0D= =0A> > Ecrit mailing list=0D=0A> > Ecrit@ietf.org=0D=0A> > https://www.ietf= =2Eorg/mailman/listinfo/ecrit=0D=0A> >=20=0D=0A> --------------------------= ------------------------------------=0D=0A> -------------------------------= ---=0D=0A> This message is for the designated recipient only and may=20=0D=0A= > contain privileged, proprietary, or otherwise private information. =20=0D= =0A> If you have received it in error, please notify the sender=20=0D=0A> i= mmediately and delete the original. Any unauthorized use of=20=0D=0A> this= email is prohibited.=0D=0A> ----------------------------------------------= ----------------=0D=0A> ----------------------------------=0D=0A> [mf2]=0D=0A= >=20=0D=0A>=20=0D=0A-------------------------------------------------------= -----------------------------------------=0D=0AThis message is for the desi= gnated recipient only and may=0D=0Acontain privileged, proprietary, or othe= rwise private information. =20=0D=0AIf you have received it in error, pleas= e notify the sender=0D=0Aimmediately and delete the original. Any unauthor= ized use of=0D=0Athis email is prohibited.=0D=0A---------------------------= ---------------------------------------------------------------------=0D=0A= [mf2]=0D=0A From James.Winterbottom@andrew.com Tue Mar 24 22:20:31 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D6013A67EB for ; Tue, 24 Mar 2009 22:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsHCjWhzuJNK for ; Tue, 24 Mar 2009 22:20:26 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 2829E3A67B2 for ; Tue, 24 Mar 2009 22:20:25 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_25_00_41_22 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 25 Mar 2009 00:41:22 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 00:21:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9AD09.85470A94" Date: Wed, 25 Mar 2009 00:21:14 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Why an applicability statement to framework and BCP is not required Thread-Index: AcmtCYR/k/Sxf5KMSyO7RBLBI3Ny3g== From: "Winterbottom, James" To: X-OriginalArrivalTime: 25 Mar 2009 05:21:16.0067 (UTC) FILETIME=[855EE730:01C9AD09] Subject: [Ecrit] Why an applicability statement to framework and BCP is not required X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 05:20:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9AD09.85470A94 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with the people that have said this debate is farcical.=0D=0A=0D=0A= =20=0D=0A=0D=0ACellular carriers can and do market their 3G services as wir= eless=0D=0Abroadband. In a number of cases, and I can't believe that it is = only=0D=0Ahere, services provide open Internet connectivity allowing access= to=0D=0Aindependent voice service providers (not IMS). When these services= are=0D=0Asold in this manner, they are still cellular, but the carrier is = really=0D=0Ajust an ISP and the ECRIT model for emergency calling is as app= licable=0D=0Ato them as it is for any DSL ISP. Any specific "cellular" emer= gency call=0D=0Aprocedures are not invoked, the carrier by the very nature = of the=0D=0Aservice they are selling has broken the access-to-voice-service= link.=0D=0AThis makes the ECRIT architecture applicable.=20=0D=0A=0D=0A =0D= =0A=0D=0AThe result is that no applicability statement is required in the E= CRIT=0D=0Adocuments. Indeed, unless specific statements in the 3GPP specifi= cations=0D=0Aare made to say that open Internet services SHALL NOT be provi= ded=0D=0Athrough these technologies I can't see how ECRIT is not applicable= to=0D=0Acellular. I can't see 3GPP adding such a statement, and I think th= at=0D=0Atheir primary customers would go up in arms if they did. I propose = that=0D=0Athe applicability statement resolution be dropped unless the prop= onents=0D=0Aof these applicability statements can stand up and say that ope= n=0D=0AInternet services over 3GPP networks don't happen now and will not=0D= =0Ahappen in the future or they can point us to a 3GPP specification that=0D= =0Adescribes how a totally decoupled access and voice service can deliver=0D= =0Aan emergency call to the correct PSAP.=0D=0A=0D=0A=20=0D=0A=0D=0ACheers=0D= =0A=0D=0AJames=0D=0A=0D=0A=20=0D=0A=0D=0A----------------------------------= --------------------------------------------------------------=0D=0AThis me= ssage is for the designated recipient only and may=0D=0Acontain privileged,= proprietary, or otherwise private information. =20=0D=0AIf you have receiv= ed it in error, please notify the sender=0D=0Aimmediately and delete the or= iginal. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A------= ---------------------------------------------------------------------------= ---------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C9AD09.85470A94 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

I agree with the people that have said th= is debate is farcical.

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

 

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

Cellular carriers can and do market their 3G services as=0D= =0Awireless broadband. In a number of cases, and I can’t believe that= it is=0D=0Aonly here, services provide open Internet connectivity allowing= access to=0D=0Aindependent voice service providers (not IMS). When these s= ervices are sold in=0D=0Athis manner, they are still cellular, but the carr= ier is really just an ISP and=0D=0Athe ECRIT model for emergency calling is= as applicable to them as it is for any=0D=0ADSL ISP. Any specific “c= ellular” emergency call procedures are not=0D=0Ainvoked, the carrier = by the very nature of the service they are selling has=0D=0Abroken the acce= ss-to-voice-service link. This makes the ECRIT architecture applicable.=0D=0A=

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

 

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

= The result is that no applicability statement is required in=0D=0Athe ECRIT= documents. Indeed, unless specific statements in the 3GPP=0D=0Aspecificati= ons are made to say that open Internet services SHALL NOT be=0D=0Aprovided = through these technologies I can’t see how ECRIT is not=0D=0Aapplicab= le to cellular. I can’t see 3GPP adding such a statement, and I=0D=0A= think that their primary customers would go up in arms if they did. I propo= se=0D=0Athat the applicability statement resolution be dropped unless the p= roponents of=0D=0Athese applicability statements can stand up and say that = open Internet services=0D=0Aover 3GPP networks don’t happen now and w= ill not happen in the future or=0D=0Athey can point us to a 3GPP specificat= ion that describes how a totally=0D=0Adecoupled access and voice service ca= n deliver an emergency call to the correct=0D=0APSAP.

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

 <= /font>

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

Cheers

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

<= span style=3D'font-size:10.0pt;=0D=0Afont-family:Arial'>James

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

 =

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


-------------------------------------= -----------------------------------------------------------
=0D=0AThis&n= bsp;message is for the designated recipient o= nly and may
=0D=0Acontain privileged, proprietary,&n= bsp;or otherwise private information.  
=0D=0AI= f you have received it in error, please&= nbsp;notify the sender
=0D=0Aimmediately and delete&= nbsp;the original.  Any unauthorized use of=0D=0Athis email is prohibited.
=0D=0A-----------------= ---------------------------------------------------------------------------= ----
=0D=0A[mf2]
=0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01C9AD09.85470A94-- From br@brianrosen.net Wed Mar 25 08:22:35 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B59528C189 for ; Wed, 25 Mar 2009 08:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXoE8fOqBIxq for ; Wed, 25 Mar 2009 08:22:34 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id BD1353A6811 for ; Wed, 25 Mar 2009 08:22:34 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=www.brianrosen.net) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LmUwp-00042v-43 for ecrit@ietf.org; Wed, 25 Mar 2009 10:23:19 -0500 Received: from 130.129.86.225 ([130.129.86.225]) (SquirrelMail authenticated user br@brianrosen.net) by www.brianrosen.net with HTTP; Wed, 25 Mar 2009 11:23:19 -0400 (EDT) Message-ID: <51261.130.129.86.225.1237994599.squirrel@www.brianrosen.net> Date: Wed, 25 Mar 2009 11:23:19 -0400 (EDT) From: "Brian Rosen" To: ecrit@ietf.org User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal 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: Subject: [Ecrit] Authority to Citizen Alert BOF happens this morning X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 15:22:35 -0000 If you are not on the earlywarning list, we are having a BOF on Authority to Citizen Alerts this morning in Imperial B Brian From jmpolk@cisco.com Wed Mar 25 09:46:24 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 171E33A67D1; Wed, 25 Mar 2009 09:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w45b23V+UJKH; Wed, 25 Mar 2009 09:46:23 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 318D93A693C; Wed, 25 Mar 2009 09:46:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,419,1233532800"; d="scan'208";a="161477487" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 25 Mar 2009 16:47:07 +0000 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 n2PGl7vP008224; Wed, 25 Mar 2009 09:47:07 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2PGl7wk021939; Wed, 25 Mar 2009 16:47:07 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 09:47:07 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.22.191]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 09:47:06 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 25 Mar 2009 11:47:04 -0500 To: Janet P Gunn From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 25 Mar 2009 16:47:06.0905 (UTC) FILETIME=[552E7890:01C9AD69] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2260; t=1237999627; x=1238863627; 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]=20Promised=20new=20version=20of =20=22esnet=22=20RPH |Sender:=20; bh=NTmnvvDE+IBZhEr6zjuHkYG31SarCa7K7TU/VkneG84=; b=Yq6jfWrjCHrBapoz8t4hfro1r0y5YnBNw8xUdDd4qIEbekpzU3DyLc7Rcn fycyLRP80xtJ2XiVv2J6wv/E1P3/tK3lzGGdYned8sNIxTd4XLzcHQ6Qd7Bv LiojJ+t57g; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: 'ECRIT' , ecrit-bounces@ietf.org Subject: Re: [Ecrit] Promised new version of "esnet" RPH X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 16:46:24 -0000 Chairs Addressing the last of the open issues within draft-ietf-ecrit-local-emergency-rph-namespace-03, I formally request this document progress to WGLC, towards becoming a standards track RFC. James At 07:48 PM 3/24/2009, Janet P Gunn wrote: >The changes in the 03 version address my concerns. As far as I am >concerns it is now ready to go. > >Janet > >This is a PRIVATE message. If you are not the intended recipient, >please delete without copying and kindly advise us by e-mail of the >mistake in delivery. >NOTE: Regardless of content, this e-mail shall not operate to bind >CSC to any order or other contract unless pursuant to explicit >written agreement or government initiative expressly permitting the >use of e-mail for such purpose. > > >"James M. Polk" >Sent by: ecrit-bounces@ietf.org > >03/24/2009 07:19 PM >To >"'ECRIT'" >cc >Subject >[Ecrit] Promised new version of "esnet" RPH > > > > >WG > >Here is the announcement of the new -03 version of the esnet >resource-pirority header for this WG. How's that for fulfilling a >promise from within 24 hours, eh? > >I believe this version addresses each of Janet's concerns from >yesterday's session. > >Please comment at will > >James > > Title : IANA Registering a SIP Resource > Priority Header >Namespace for > Local Emergency Communications > Author(s) : J. Polk > Filename : > draft-ietf-ecrit-local-emergency-rph-namespace-03.txt > Pages : 9 > Date : 2009-03-24 > >This document creates and IANA registers the new Session Initiation >Protocol (SIP) Resource Priority header (RPH) namespace "esnet" for >local emergency usage to a public safety answering point (PSAP), >between PSAPs, and between a PSAP and first responders and their >organizations. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-local-emergency-rph-namespace-03.txt > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From drage@alcatel-lucent.com Wed Mar 25 10:44:50 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 890CE3A6A9A for ; Wed, 25 Mar 2009 10:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.931 X-Spam-Level: X-Spam-Status: No, score=-5.931 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgunSerMP68R for ; Wed, 25 Mar 2009 10:44:49 -0700 (PDT) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 0ED393A6BA6 for ; Wed, 25 Mar 2009 10:44:48 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2PHiXAR016339 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Mar 2009 18:44:33 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 25 Mar 2009 18:44:33 +0100 From: "DRAGE, Keith (Keith)" To: "Dawson, Martin" , Hannes Tschofenig , Randall Gellens , "Stark, Barbara" , Brian Rosen , Richard Barnes Date: Wed, 25 Mar 2009 18:44:32 +0100 Thread-Topic: [Ecrit] Proposal to add"applicability"statementto-framework/-phonebcp Thread-Index: AcmsyBfU3lfwG7J7SKimj48KL7vxAwAARTHgAAWtWoAAAFIagAAAPatgAAB9lAAAHZRIwA== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6757BE6C9@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <49C91795.9030208@bbn.com><00fd01c9acac$575e73d0$061b5b70$@net><49C92E99.8080909@bbn.com><013201c9acbd$31938e40$94baaac0$@net><7582BC68E4994F4ABF0BD4723975C3FA0D88065B@crexc41p> <007901c9acc9$4f51ba90$421fa20a@nsnintra.net> <28B7C3AA2A7ABA4A841F11217ABE78D6757BE27C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <28B7C3AA2A7ABA4A841F11217ABE78D6757BE282@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] Proposal to add"applicability"statementto-framework/-phonebcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 17:44:50 -0000 Well at the end of the day, we are discussing what we want in the ecrit doc= ument.=20 3GPP is a member organisation, and indeed if I recall correctly Andrew is a= supporting organisation of one of the relevant organisations. It is the me= mber organisations who decide what the document says. Go write your contribution. Keith=20 > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20 > Sent: Wednesday, March 25, 2009 12:55 AM > To: DRAGE, Keith (Keith); Hannes Tschofenig; Randall Gellens;=20 > Stark, Barbara; Brian Rosen; Richard Barnes > Cc: ecrit@ietf.org; Rosen, Brian > Subject: RE: [Ecrit] Proposal to=20 > add"applicability"statementto-framework/-phonebcp >=20 > The apparent lack of logical symmetry in that comment baffles me. >=20 > Cheers, > Martin >=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Wednesday, 25 March 2009 11:40 AM > To: Dawson, Martin; Hannes Tschofenig; Randall Gellens;=20 > Stark, Barbara; Brian Rosen; Richard Barnes > Cc: ecrit@ietf.org; Rosen, Brian > Subject: RE: [Ecrit] Proposal to > add"applicability"statementto-framework/-phonebcp >=20 > As it does not provide the chance for meeting another=20 > framework, it doesn't need to. The ecrit documents do. >=20 > Keith=20 >=20 > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: Wednesday, March 25, 2009 12:34 AM > > To: DRAGE, Keith (Keith); Hannes Tschofenig; Randall=20 > Gellens; Stark,=20 > > Barbara; Brian Rosen; Richard Barnes > > Cc: ecrit@ietf.org; Rosen, Brian > > Subject: RE: [Ecrit] Proposal to add"applicability"=20 > > statementto-framework/-phonebcp > >=20 > > Sure - but do they actually say "This framework may not address=20 > > requirements that are addressed by other frameworks"? > > Which is what is actually being asked for here. And which, btw, I=20 > > think is a pretty pointless comment anyway. > >=20 > > Cheers, > > Martin > >=20 > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > > Sent: Wednesday, 25 March 2009 11:25 AM > > To: Hannes Tschofenig; 'Randall Gellens'; 'Stark, Barbara'; 'Brian=20 > > Rosen'; 'Richard Barnes' > > Cc: Dawson, Martin; ecrit@ietf.org; 'Rosen, Brian' > > Subject: RE: [Ecrit] Proposal to add"applicability" > > statementto-framework/-phonebcp > >=20 > > I think you will find that the stage 3 3GPP document=20 > already contains=20 > > the statement of what it is applicable to. It does not in=20 > itself claim=20 > > to solve the worlds problems. > >=20 > > That covers ETSI TISPAN and 3GPP2 as well. > >=20 > > regards > >=20 > > Keith > >=20 > > > -----Original Message----- > > > From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf > > > Of Hannes Tschofenig > > > Sent: Tuesday, March 24, 2009 9:41 PM > > > To: 'Randall Gellens'; 'Stark, Barbara'; 'Brian Rosen'; 'Richard=20 > > > Barnes' > > > Cc: 'Dawson, Martin'; ecrit@ietf.org; 'Rosen, Brian' > > > Subject: Re: [Ecrit] Proposal to add"applicability"=20 > > > statementto -framework/-phonebcp > > >=20 > > > Btw, is the plan to put similar statements into 3GPP, etc.=20 > > > documents as well?=20 > > >=20 > > > >-----Original Message----- > > > >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > > > On Behalf > > > >Of Randall Gellens > > > >Sent: 24 March, 2009 14:32 > > > >To: Stark, Barbara; Brian Rosen; Richard Barnes > > > >Cc: Dawson, Martin; ecrit@ietf.org; Rosen,Brian > > > >Subject: Re: [Ecrit] Proposal to add"applicability"=20 > > > >statementto -framework/-phonebcp > > > > > > > >At 4:35 PM -0400 3/24/09, Barbara Stark wrote: > > > > > > > >> I was doing fine with the course of this discussion till this=20 > > > >> "interoperability" word came into the picture. I'm not > > > convinced we > > > >> have an "interoperability issue". I do think that how this > > > >framework > > > >> "interconnects" to other networks is something that is not > > > >covered in > > > >> this document, and that it would be ok to say that this > > > >isn't covered. > > > > > > > >How about a sentence such as "Interworking between the framework=20 > > > >described here and other frameworks is not currently specified." > > > > > > > >-- > > > >Randall Gellens > > > >Opinions are personal; facts are suspect; I speak for=20 > > > myself only > > > >-------------- Randomly selected tag: --------------- > > Language is a > > > >virus from outer space. --William S. Burroughs=20 > > > >_______________________________________________ > > > >Ecrit mailing list > > > >Ecrit@ietf.org > > > >https://www.ietf.org/mailman/listinfo/ecrit > > > > > > >=20 > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > >=20 > > -------------------------------------------------------------- > > ---------------------------------- > > This message is for the designated recipient only and may contain=20 > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender=20 > immediately=20 > > and delete the original. Any unauthorized use of this email is=20 > > prohibited. > > -------------------------------------------------------------- > > ---------------------------------- > > [mf2] > >=20 > >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may=20 > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender=20 > immediately and delete the original. Any unauthorized use of=20 > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 > = From rbarnes@bbn.com Wed Mar 25 11:26:25 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E70403A6D70 for ; Wed, 25 Mar 2009 11:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEPeXyiw+Dyc for ; Wed, 25 Mar 2009 11:26:25 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 103E83A6D7F for ; Wed, 25 Mar 2009 11:26:25 -0700 (PDT) Received: from [128.89.252.95] (helo=dhcp-17f1.meeting.ietf.org) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LmXop-00022U-BL; Wed, 25 Mar 2009 14:27:15 -0400 Message-ID: <49CA7782.2090806@bbn.com> Date: Wed, 25 Mar 2009 11:27:14 -0700 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Winterbottom, James" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] Why an applicability statement to framework and BCP is not required X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 18:26:26 -0000 This argument is pretty persuasive. Could someone who wants to add something propose a paragraph and explain why the below doesn't apply? If no such text is forthcoming, ISTM that we should go ahead with the document as it is. --Richard Winterbottom, James wrote: > I agree with the people that have said this debate is farcical. > > > > Cellular carriers can and do market their 3G services as wireless > broadband. In a number of cases, and I can't believe that it is only > here, services provide open Internet connectivity allowing access to > independent voice service providers (not IMS). When these services are > sold in this manner, they are still cellular, but the carrier is really > just an ISP and the ECRIT model for emergency calling is as applicable > to them as it is for any DSL ISP. Any specific "cellular" emergency call > procedures are not invoked, the carrier by the very nature of the > service they are selling has broken the access-to-voice-service link. > This makes the ECRIT architecture applicable. > > > > The result is that no applicability statement is required in the ECRIT > documents. Indeed, unless specific statements in the 3GPP specifications > are made to say that open Internet services SHALL NOT be provided > through these technologies I can't see how ECRIT is not applicable to > cellular. I can't see 3GPP adding such a statement, and I think that > their primary customers would go up in arms if they did. I propose that > the applicability statement resolution be dropped unless the proponents > of these applicability statements can stand up and say that open > Internet services over 3GPP networks don't happen now and will not > happen in the future or they can point us to a 3GPP specification that > describes how a totally decoupled access and voice service can deliver > an emergency call to the correct PSAP. > > > > Cheers > > James > > > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hardie@qualcomm.com Wed Mar 25 14:52:05 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BBBF3A6DB4 for ; Wed, 25 Mar 2009 14:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.374 X-Spam-Level: X-Spam-Status: No, score=-103.374 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NWA-ixALMdB for ; Wed, 25 Mar 2009 14:52:04 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 725983A6B3A for ; Wed, 25 Mar 2009 14:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1238017977; x=1269553977; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<49CA7782.2090806@bbn.c om>|References:=20=0D=0A=20<49CA7782.2090806@bbn.com> |Date:=20Wed,=2025=20Mar=202009=2014:52:49=20-0700|To:=20 Richard=20Barnes=20,=0D=0A=20=20=20=20 =20=20=20=20"Winterbottom,=20James"=0D=0A=09|From:=20Ted=20Hardie=20|Subject:=20Re:=20[Ecrit]=20Why=20an=20applicabilit y=20statement=20to=20framework=20and=20BCP=0D=0A=20is=20 =20not=09required|CC:=20"ecrit@ietf.org"=20|Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5564"=3B=20 a=3D"16596400"; bh=pRTn3Y8b6/7tGr8BxeVr6ABkj7KmDiODgFgXJysh1Ds=; b=ZCWc3S0NWjDGkLxePMRtigL60wPZL5HFxBmIhO+dtylABYIJUNafbI6u mLSP/2TESyU7d6uEattpfzWf9dJZpPfvrgdf6Ku+xeuBFNwA311A3W/xZ /NQEpVf7OwSMecYyQyQfenWE9RzHiNOg8FRaVu1C3mCmHmnYAigKPzLhi 0=; X-IronPort-AV: E=McAfee;i="5300,2777,5564"; a="16596400" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Mar 2009 14:52:56 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2PLqsY4021242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Mar 2009 14:52:54 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2PLqp8U010811 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Mar 2009 14:52:53 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 25 Mar 2009 14:52:51 -0700 Received: from [130.129.80.242] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 25 Mar 2009 14:52:50 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <49CA7782.2090806@bbn.com> References: <49CA7782.2090806@bbn.com> Date: Wed, 25 Mar 2009 14:52:49 -0700 To: Richard Barnes , "Winterbottom, James" From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Why an applicability statement to framework and BCP is not required X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 21:52:05 -0000 At 11:27 AM -0700 3/25/09, Richard Barnes wrote: >This argument is pretty persuasive. Could someone who wants to add >something propose a paragraph and explain why the below doesn't apply? >If no such text is forthcoming, ISTM that we should go ahead with the >document as it is. >--Richard Actually, the argument James puts forward below seems pretty much the same as he put forward in late February, and which Stephen answered then (Feb 26th, at least as it arrived to me). It is pretty obvious that we're not going to get to full or measurable rough consensus on this, and I thought Brian's text was a very useful step in getting us to a working compromise. Going back over discussions that led us to the conclusion that we weren't going to get consensus doesn't seem likely to move us forward much. I can't speak for anyone else, but moving forward with text discussions to see if there is a compromise statement here seems more likely to get us out of these weeds. Two cents, Ted >Winterbottom, James wrote: >> I agree with the people that have said this debate is farcical. >> >> >> >> Cellular carriers can and do market their 3G services as wireless >> broadband. In a number of cases, and I can't believe that it is only >> here, services provide open Internet connectivity allowing access to >> independent voice service providers (not IMS). When these services are >> sold in this manner, they are still cellular, but the carrier is really >> just an ISP and the ECRIT model for emergency calling is as applicable >> to them as it is for any DSL ISP. Any specific "cellular" emergency call >> procedures are not invoked, the carrier by the very nature of the >> service they are selling has broken the access-to-voice-service link. >> This makes the ECRIT architecture applicable. >> >> >> >> The result is that no applicability statement is required in the ECRIT >> documents. Indeed, unless specific statements in the 3GPP specifications >> are made to say that open Internet services SHALL NOT be provided >> through these technologies I can't see how ECRIT is not applicable to >> cellular. I can't see 3GPP adding such a statement, and I think that >> their primary customers would go up in arms if they did. I propose that >> the applicability statement resolution be dropped unless the proponents >> of these applicability statements can stand up and say that open >> Internet services over 3GPP networks don't happen now and will not >> happen in the future or they can point us to a 3GPP specification that >> describes how a totally decoupled access and voice service can deliver >> an emergency call to the correct PSAP. >> >> >> >> Cheers >> >> James >> >> >> >> ------------------------------------------------------------------------------------------------ >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> ------------------------------------------------------------------------------------------------ >> [mf2] >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@andrew.com Wed Mar 25 15:04:10 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38EEF3A6B30 for ; Wed, 25 Mar 2009 15:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.294 X-Spam-Level: X-Spam-Status: No, score=-1.294 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0u4Nq0mcxEvn for ; Wed, 25 Mar 2009 15:04:09 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 2B25E3A6A8A for ; Wed, 25 Mar 2009 15:04:09 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_25_17_25_08 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 25 Mar 2009 17:25:08 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 17:05: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Mar 2009 17:05:01 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Why an applicability statement to framework and BCP is not required Thread-Index: AcmtlBDU3Kf3JbLWRsC5icPSIu2IxgAAFMCz References: <49CA7782.2090806@bbn.com> From: "Winterbottom, James" To: "Ted Hardie" , "Richard Barnes" X-OriginalArrivalTime: 25 Mar 2009 22:05:01.0292 (UTC) FILETIME=[BE66F2C0:01C9AD95] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Why an applicability statement to framework and BCP is not required X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 22:04:10 -0000 Actually Ted I don't recall see an explicit reference to a 3GPP specificati= on that address the problem I have described below. Indeed my recollection,= admittedly it has been some time since I have looked at the 3GPP solution = in detail, was that this deployment is deemed out of scope. That is, 3GPP d= o not have a solution for it, but recognize it as being an issue. ECRIT fil= ls this hole. Applicability to only packet deployments is not in question I= hope, consequently how that packet is provided is also, I hope, not an iss= ue, otherwise need to consider applicability to every other type of physica= l access network. Indeed this same argument can be posed for every IETF pro= tocol or framework document.=0D=0A=0D=0AIf we have to have an applicability= statement, and I don't think we do, then it should be even more simple tha= n what has been currently proposed.=20=0D=0A=0D=0A"This document applies to= all devices and networks that participate in Internet emergency calling".=0D= =0A=0D=0AThis wording has been carefully chosen to say Internet. In all the= scenarios that Stephen has raised he is describing very specific IMS envir= onments, and while these may be IP, they are not Internet, they are walled = gardens, and in these you can do what ever you want. If 3G operators want t= o provide open Internet connectivity then these specifications do apply to = them and they need to adhere to them.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D= =0A=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Ted Hardie [mailto:har= die@qualcomm.com]=0D=0ASent: Wed 3/25/2009 4:52 PM=0D=0ATo: Richard Barnes;= Winterbottom, James=0D=0ACc: ecrit@ietf.org=0D=0ASubject: Re: [Ecrit] Why = an applicability statement to framework and BCP is not=09required=0D=0A =0D= =0AAt 11:27 AM -0700 3/25/09, Richard Barnes wrote:=0D=0A>This argument is = pretty persuasive. Could someone who wants to add=0D=0A>something propose = a paragraph and explain why the below doesn't apply=3F=0D=0A>If no such tex= t is forthcoming, ISTM that we should go ahead with the=0D=0A>document as i= t is.=0D=0A>--Richard=0D=0A=0D=0AActually, the argument James puts forward = below seems pretty much=0D=0Athe same as he put forward in late February, a= nd which Stephen=0D=0Aanswered then (Feb 26th, at least as it arrived to me= ).=0D=0A=0D=0AIt is pretty obvious that we're not going to get to full or m= easurable rough=0D=0Aconsensus on this, and I thought Brian's text was a ve= ry useful step in getting=0D=0Aus to a working compromise. Going back over= discussions that led us to the=0D=0Aconclusion that we weren't going to ge= t consensus doesn't seem likely to move=0D=0Aus forward much.=0D=0A=0D=0AI = can't speak for anyone else, but moving forward with text discussions=0D=0A= to see if there is a compromise statement here seems more likely to get=0D=0A= us out of these weeds.=0D=0A=0D=0ATwo cents,=0D=0A=09=09=09Ted=0D=0A=0D=0A>= Winterbottom, James wrote:=0D=0A>> I agree with the people that have said t= his debate is farcical.=0D=0A>>=0D=0A>>=20=0D=0A>>=0D=0A>> Cellular carrier= s can and do market their 3G services as wireless=0D=0A>> broadband. In a n= umber of cases, and I can't believe that it is only=0D=0A>> here, services = provide open Internet connectivity allowing access to=0D=0A>> independent v= oice service providers (not IMS). When these services are=0D=0A>> sold in t= his manner, they are still cellular, but the carrier is really=0D=0A>> just= an ISP and the ECRIT model for emergency calling is as applicable=0D=0A>> = to them as it is for any DSL ISP. Any specific "cellular" emergency call=0D= =0A>> procedures are not invoked, the carrier by the very nature of the=0D=0A= >> service they are selling has broken the access-to-voice-service link.=0D= =0A>> This makes the ECRIT architecture applicable.=0D=0A>>=0D=0A>>=20=0D=0A= >>=0D=0A>> The result is that no applicability statement is required in the= ECRIT=0D=0A>> documents. Indeed, unless specific statements in the 3GPP sp= ecifications=0D=0A>> are made to say that open Internet services SHALL NOT = be provided=0D=0A>> through these technologies I can't see how ECRIT is not= applicable to=0D=0A>> cellular. I can't see 3GPP adding such a statement, = and I think that=0D=0A>> their primary customers would go up in arms if the= y did. I propose that=0D=0A>> the applicability statement resolution be dro= pped unless the proponents=0D=0A>> of these applicability statements can st= and up and say that open=0D=0A>> Internet services over 3GPP networks don't= happen now and will not=0D=0A>> happen in the future or they can point us = to a 3GPP specification that=0D=0A>> describes how a totally decoupled acce= ss and voice service can deliver=0D=0A>> an emergency call to the correct P= SAP.=0D=0A>>=0D=0A>>=20=0D=0A>>=0D=0A>> Cheers=0D=0A>>=0D=0A>> James=0D=0A>= >=0D=0A>>=20=0D=0A>>=0D=0A>> ----------------------------------------------= --------------------------------------------------=0D=0A>> This message is = for the designated recipient only and may=0D=0A>> contain privileged, propr= ietary, or otherwise private information.=20=0D=0A>> If you have received i= t in error, please notify the sender=0D=0A>> immediately and delete the ori= ginal. 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>> Ecrit mailing= list=0D=0A>> Ecrit@ietf.org=0D=0A>> https://www.ietf.org/mailman/listinfo/= ecrit=0D=0A>_______________________________________________=0D=0A>Ecrit mai= ling list=0D=0A>Ecrit@ietf.org=0D=0A>https://www.ietf.org/mailman/listinfo/= ecrit=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 err= or, 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 From rbarnes@bbn.com Wed Mar 25 16:27:57 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 565223A680C for ; Wed, 25 Mar 2009 16:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylNsDtVmP3W1 for ; Wed, 25 Mar 2009 16:27:56 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id CD2103A6C3C for ; Wed, 25 Mar 2009 16:27:54 -0700 (PDT) Received: from [128.89.252.81] (helo=dhcp-17f1.meeting.ietf.org) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LmcWb-0006RH-9u; Wed, 25 Mar 2009 19:28:45 -0400 Message-ID: <49CABE28.2050206@bbn.com> Date: Wed, 25 Mar 2009 16:28:40 -0700 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Ted Hardie References: <49CA7782.2090806@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Why an applicability statement to framework and BCP is not required X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 23:27:57 -0000 > I can't speak for anyone else, but moving forward with text discussions > to see if there is a compromise statement here seems more likely to get > us out of these weeds. Sorry, that was meant to be the more important thrust of my message. Ted, you've been one of the people arguing that text is needed -- could you propose some? --Richard > > Two cents, > Ted > >> Winterbottom, James wrote: >>> I agree with the people that have said this debate is farcical. >>> >>> >>> >>> Cellular carriers can and do market their 3G services as wireless >>> broadband. In a number of cases, and I can't believe that it is only >>> here, services provide open Internet connectivity allowing access to >>> independent voice service providers (not IMS). When these services are >>> sold in this manner, they are still cellular, but the carrier is really >>> just an ISP and the ECRIT model for emergency calling is as applicable >>> to them as it is for any DSL ISP. Any specific "cellular" emergency call >>> procedures are not invoked, the carrier by the very nature of the >>> service they are selling has broken the access-to-voice-service link. >>> This makes the ECRIT architecture applicable. >>> >>> >>> >>> The result is that no applicability statement is required in the ECRIT >>> documents. Indeed, unless specific statements in the 3GPP specifications >>> are made to say that open Internet services SHALL NOT be provided >>> through these technologies I can't see how ECRIT is not applicable to >>> cellular. I can't see 3GPP adding such a statement, and I think that >>> their primary customers would go up in arms if they did. I propose that >>> the applicability statement resolution be dropped unless the proponents >>> of these applicability statements can stand up and say that open >>> Internet services over 3GPP networks don't happen now and will not >>> happen in the future or they can point us to a 3GPP specification that >>> describes how a totally decoupled access and voice service can deliver >>> an emergency call to the correct PSAP. >>> >>> >>> >>> Cheers >>> >>> James >>> >>> >>> >>> ------------------------------------------------------------------------------------------------ >>> This message is for the designated recipient only and may >>> contain privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender >>> immediately and delete the original. Any unauthorized use of >>> this email is prohibited. >>> ------------------------------------------------------------------------------------------------ >>> [mf2] >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > From hardie@qualcomm.com Wed Mar 25 16:28:26 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 430303A684A for ; Wed, 25 Mar 2009 16:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.333 X-Spam-Level: X-Spam-Status: No, score=-103.333 tagged_above=-999 required=5 tests=[AWL=-0.734, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7I2jBlhhLxI for ; Wed, 25 Mar 2009 16:28:25 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 487A93A680C for ; Wed, 25 Mar 2009 16:28:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1238023758; x=1269559758; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20|References:=20 =0D=0A=20<49CA7782.2090806@bbn.com>=20=0D=0A=20|Date:=20Wed,=2025=20Mar =202009=2016:29:13=20-0700|To:=20"Winterbottom,=20James" =20,=0D=0A=20=20=20=20=20 =20=20=20Richard=20Barnes=0D=0A=09|From: =20Ted=20Hardie=20|Subject:=20RE:=20 [Ecrit]=20Why=20an=20applicability=20statement=20to=20fra mework=20and=20BCP=0D=0A=20is=20=20=20not=09required|CC: =20"ecrit@ietf.org"=20|Content-Type:=20te xt/plain=3B=20charset=3D"us-ascii"|X-IronPort-AV:=20E=3DM cAfee=3Bi=3D"5300,2777,5564"=3B=20a=3D"16599760"; bh=LnQP+9KZntQrVgqrffz1opf8u8MZd+wyQSsEgxQ3LRU=; b=fiqPNFw8/2iRfziC9gJotkVtp8I2yUOb8bo9yYV2m8H//HFQEHO6NCHx F8dTz3OX6Fd5IeMGj5dS4sg2OcNTk+q4yHbZPyUw5iRzAc7zWpfP74yHF AXGBbE62ji95/eSH06Ci0vPcq41T3JO5dVKmlM9DgH21MM7cV/fNdxd5M I=; X-IronPort-AV: E=McAfee;i="5300,2777,5564"; a="16599760" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Mar 2009 16:29:17 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2PNTHNx015764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Mar 2009 16:29:17 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2PNTHdH009882 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Mar 2009 16:29:17 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 25 Mar 2009 16:29:16 -0700 Received: from [130.129.80.242] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 25 Mar 2009 16:29:15 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: References: <49CA7782.2090806@bbn.com> Date: Wed, 25 Mar 2009 16:29:13 -0700 To: "Winterbottom, James" , Richard Barnes From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Why an applicability statement to framework and BCP is not required X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 23:28:26 -0000 At 3:05 PM -0700 3/25/09, Winterbottom, James wrote: >Actually Ted I don't recall see an explicit reference to a 3GPP specification that address the problem I have described below. Indeed my recollection, admittedly it has been some time since I have looked at the 3GPP solution in detail, was that this deployment is deemed out of scope. That is, 3GPP do not have a solution for it, but recognize it as being an issue. ECRIT fills this hole. Applicability to only packet deployments is not in question I hope, consequently how that packet is provided is also, I hope, not an issue, otherwise need to consider applicability to every other type of physical access network. Indeed this same argument can be posed for every IETF protocol or framework document. > >If we have to have an applicability statement, and I don't think we do, then it should be even more simple than what has been currently proposed. > >"This document applies to all devices and networks that participate in Internet emergency calling". That's a pretty major revision of Framework, Section 4. That claims to consider all private networks using IP. See: Devices that create media sessions and exchange audio, video and/or text, and have the capability to establish sessions to a wide variety of addresses, and communicate over private IP networks or the Internet, should support emergency calls. If you are meeting that remit, you need to acknowledge that other functional entities exist and are currently doing their best to get the emergency calls to their responders. If you want to limit this to something that passes *your* view of what constitutes the Internet, then we have a bigger problem. Again, just speaking for myself, Ted From hardie@qualcomm.com Wed Mar 25 16:32:33 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D10928C171 for ; Wed, 25 Mar 2009 16:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.297 X-Spam-Level: X-Spam-Status: No, score=-105.297 tagged_above=-999 required=5 tests=[AWL=1.303, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdHmgzLjsJPw for ; Wed, 25 Mar 2009 16:32:32 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 600F128C1AB for ; Wed, 25 Mar 2009 16:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1238024005; x=1269560005; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20|In-Reply-To:=20<49CABE28.2050206@bbn.c om>|References:=20=0D=0A=20<49CA7782.2090806@bbn.com> =20=0D=0A=20<49CA BE28.2050206@bbn.com>|Date:=20Wed,=2025=20Mar=202009=2016 :33:10=20-0700|To:=20Richard=20Barnes=20 |From:=20Ted=20Hardie=20|Subject:=20 Re:=20[Ecrit]=20Why=20an=20applicability=20statement=20to =20framework=20and=20BCP=0D=0A=20is=20=20=20not=09require d|CC:=20"Winterbottom,=20James"=20,=0D=0A=20=20=20=20=20=20=20=20"ecrit@ietf.org" =0D=0A=09|Content-Type:=20text/plain=3B =20charset=3D"us-ascii"|X-IronPort-AV:=20E=3DMcAfee=3Bi =3D"5300,2777,5564"=3B=20a=3D"16615204"; bh=8XrhMdXTIf3XLSZPZ21QvXB1XoK/TDjT8s2I0/n9Y1I=; b=p/RPVL/Rr77aEpFlJa6jyEGOl+y37iPAAZXi9ehpgU5fuyI1ip/DVFhw Muz7sFvsnao/jMB+5nBiuekDG96nmTeEv93xKkh+wVts/u0AwdKaZW2Kv MHatdknq2A3AV3SNqU9CjrAkdEGBmtRhsPZixS/9CrMxwtPU7tWpD/Ehw c=; X-IronPort-AV: E=McAfee;i="5300,2777,5564"; a="16615204" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Mar 2009 16:33:25 -0700 Received: from msgtransport03.qualcomm.com (msgtransport03.qualcomm.com [129.46.61.154]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2PNXOuj003143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Mar 2009 16:33:24 -0700 Received: from nasanexhub05.na.qualcomm.com (nasanexhub05.na.qualcomm.com [129.46.134.219]) by msgtransport03.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2PNXIvg007784 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Mar 2009 16:33:24 -0700 Received: from nasanexmsp02.na.qualcomm.com (10.45.56.203) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 25 Mar 2009 16:33:14 -0700 Received: from [130.129.80.242] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.203) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 25 Mar 2009 16:33:14 -0700 MIME-Version: 1.0 Message-ID: In-Reply-To: <49CABE28.2050206@bbn.com> References: <49CA7782.2090806@bbn.com> <49CABE28.2050206@bbn.com> Date: Wed, 25 Mar 2009 16:33:10 -0700 To: Richard Barnes From: Ted Hardie Content-Type: text/plain; charset="us-ascii" Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Why an applicability statement to framework and BCP is not required X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 23:32:33 -0000 At 4:28 PM -0700 3/25/09, Richard Barnes wrote: > > I can't speak for anyone else, but moving forward with text discussions >> to see if there is a compromise statement here seems more likely to get >> us out of these weeds. > >Sorry, that was meant to be the more important thrust of my message. > >Ted, you've been one of the people arguing that text is needed -- could >you propose some? > >--Richard I personally was fine with the direction of discussion that arose out of Brian's text. But again, I am not speaking for anyone else. regards, Ted > >> >> Two cents, >> Ted >> >>> Winterbottom, James wrote: >>>> I agree with the people that have said this debate is farcical. >>>> >>>> >>>> >>>> Cellular carriers can and do market their 3G services as wireless >>>> broadband. In a number of cases, and I can't believe that it is only >>>> here, services provide open Internet connectivity allowing access to >>>> independent voice service providers (not IMS). When these services are >>>> sold in this manner, they are still cellular, but the carrier is really >>>> just an ISP and the ECRIT model for emergency calling is as applicable >>>> to them as it is for any DSL ISP. Any specific "cellular" emergency call >>>> procedures are not invoked, the carrier by the very nature of the >>>> service they are selling has broken the access-to-voice-service link. >>>> This makes the ECRIT architecture applicable. >>>> >>>> >>>> >>>> The result is that no applicability statement is required in the ECRIT >>>> documents. Indeed, unless specific statements in the 3GPP specifications >>>> are made to say that open Internet services SHALL NOT be provided >>>> through these technologies I can't see how ECRIT is not applicable to >>>> cellular. I can't see 3GPP adding such a statement, and I think that >>>> their primary customers would go up in arms if they did. I propose that >>>> the applicability statement resolution be dropped unless the proponents >>>> of these applicability statements can stand up and say that open >>>> Internet services over 3GPP networks don't happen now and will not >>>> happen in the future or they can point us to a 3GPP specification that >>>> describes how a totally decoupled access and voice service can deliver >>>> an emergency call to the correct PSAP. >>>> >>>> >>>> >>>> Cheers >>>> >>>> James >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------------------------ >>>> This message is for the designated recipient only and may >>>> contain privileged, proprietary, or otherwise private information. >>>> If you have received it in error, please notify the sender >>>> immediately and delete the original. Any unauthorized use of >>>> this email is prohibited. >>>> ------------------------------------------------------------------------------------------------ >>>> [mf2] >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> From Hannes.Tschofenig@gmx.net Wed Mar 25 16:35:01 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17A0A28C1D8 for ; Wed, 25 Mar 2009 16:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0vQmLWgCZ75 for ; Wed, 25 Mar 2009 16:35:00 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id AE2B73A6D5B for ; Wed, 25 Mar 2009 16:34:59 -0700 (PDT) Received: (qmail invoked by alias); 25 Mar 2009 23:35:50 -0000 Received: from dhcp-14f7.meeting.ietf.org (EHLO 4FIL42860) [130.129.20.247] by mail.gmx.net (mp048) with SMTP; 26 Mar 2009 00:35:50 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+8X7N0LfK8Y7kkTKBTLqdQxqIATR8+jz695Himtv BwX/B4pTNb8YV5 From: "Hannes Tschofenig" To: "'Richard Barnes'" , "'Ted Hardie'" References: <49CA7782.2090806@bbn.com> <49CABE28.2050206@bbn.com> Date: Wed, 25 Mar 2009 16:36:58 -0700 Message-ID: <01b401c9ada2$99643c00$f7148182@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmtoX1I2zIhiEiDTraDVOw3r3CfMAAAFlFQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <49CABE28.2050206@bbn.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Why an applicability statement to framework and BCP is not required X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 23:35:01 -0000 >> I can't speak for anyone else, but moving forward with text >> discussions to see if there is a compromise statement here >seems more >> likely to get us out of these weeds. Ted, isn't that essentially saying something like: "If you (James) stop arguing against the ideas we (Ted, Stephen, Randy) have in mind we could get much faster to the result we like. " I think that James asks fair questions since he tries to understand what you (and your co-workers) are unhappy about. This is particularly a fair question given that you have been participating in the ECRIT working group for a long time (and co-author one of the core documents) and have not raised your concerns earlier. Ciao Hannes >Sorry, that was meant to be the more important thrust of my message. > >Ted, you've been one of the people arguing that text is needed >-- could you propose some? > >--Richard > > >> >> Two cents, >> Ted >> >>> Winterbottom, James wrote: >>>> I agree with the people that have said this debate is farcical. >>>> >>>> >>>> >>>> Cellular carriers can and do market their 3G services as wireless >>>> broadband. In a number of cases, and I can't believe that >it is only >>>> here, services provide open Internet connectivity allowing >access to >>>> independent voice service providers (not IMS). When these services >>>> are sold in this manner, they are still cellular, but the >carrier is >>>> really just an ISP and the ECRIT model for emergency calling is as >>>> applicable to them as it is for any DSL ISP. Any specific >"cellular" >>>> emergency call procedures are not invoked, the carrier by the very >>>> nature of the service they are selling has broken the >access-to-voice-service link. >>>> This makes the ECRIT architecture applicable. >>>> >>>> >>>> >>>> The result is that no applicability statement is required in the >>>> ECRIT documents. Indeed, unless specific statements in the 3GPP >>>> specifications are made to say that open Internet services >SHALL NOT >>>> be provided through these technologies I can't see how >ECRIT is not >>>> applicable to cellular. I can't see 3GPP adding such a statement, >>>> and I think that their primary customers would go up in >arms if they >>>> did. I propose that the applicability statement resolution be >>>> dropped unless the proponents of these applicability >statements can >>>> stand up and say that open Internet services over 3GPP networks >>>> don't happen now and will not happen in the future or they >can point >>>> us to a 3GPP specification that describes how a totally decoupled >>>> access and voice service can deliver an emergency call to >the correct PSAP. >>>> >>>> >>>> >>>> Cheers >>>> >>>> James >>>> >>>> >>>> >>>> >-------------------------------------------------------------------- >>>> ---------------------------- This message is for the designated >>>> recipient only and may contain privileged, proprietary, or >otherwise >>>> private information. >>>> If you have received it in error, please notify the sender >>>> immediately and delete the original. Any unauthorized use of this >>>> email is prohibited. >>>> >-------------------------------------------------------------------- >>>> ---------------------------- >>>> [mf2] >>>> >>>> >>>> >>>> >-------------------------------------------------------------------- >>>> ---- >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > From James.Winterbottom@andrew.com Wed Mar 25 16:50:19 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D458D3A6DBF for ; Wed, 25 Mar 2009 16:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2I2-viL6Tjqg for ; Wed, 25 Mar 2009 16:50:17 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id BB4123A6DBC for ; Wed, 25 Mar 2009 16:50:17 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_25_19_11_17 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 25 Mar 2009 19:11:16 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 18:51:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Mar 2009 18:51:08 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Why an applicability statement to framework and BCP is not required Thread-Index: AcmtoYVMK0BDqAIuQ+m5tVoC7fyMlAAAWCng References: <49CA7782.2090806@bbn.com> From: "Winterbottom, James" To: "Ted Hardie" , "Richard Barnes" X-OriginalArrivalTime: 25 Mar 2009 23:51:09.0920 (UTC) FILETIME=[92667600:01C9ADA4] Cc: ecrit@ietf.org Subject: Re: [Ecrit] Why an applicability statement to framework and BCP is not required X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 23:50:19 -0000 This has nothing what-so-ever to do with what I think the Internet is or=0D= =0Ais not. You, Stephen, Randy and to some extent Keith have argued that=0D= =0A3GPP is somehow special and exempt from these specifications because it=0D= =0Acan, in some circumstances, provide its own emergency calling=0D=0Aproce= dures.=20=0D=0A=0D=0AI have highlighted, more than once, that 3G networks a= re also deployed=0D=0Aas broadband services in the same way that other ISP = services are=0D=0Aprovided and that these should be subject to the ECRIT sp= ecifications.=0D=0AThe argument that 3GPP is somehow "special" in these cas= es does not=0D=0Aapply.=0D=0A=0D=0ATo your comment on section 4, it says "s= hould", not must, so the text is=0D=0Aa recommendation and not a mandate, a= s a manufacturer of 3G terminal=0D=0Aequipment Qualcomm is free to ignore t= his advice.=0D=0A=0D=0AThe only rationale I can see for continuing to push = for these=0D=0Aapplicability statements is to provide certain companies wit= h a clear=0D=0Areference to say to operators and other standards bodies, "l= ook, ECRIT=0D=0Adoesn't apply here it says so", something that I think the = vast majority=0D=0Aof people on this list do not agree with!=0D=0A=0D=0AChe= ers=0D=0AJames=0D=0A=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Ted H= ardie [mailto:hardie@qualcomm.com]=20=0D=0ASent: Thursday, 26 March 2009 10= :29 AM=0D=0ATo: Winterbottom, James; Richard Barnes=0D=0ACc: ecrit@ietf.org=0D= =0ASubject: RE: [Ecrit] Why an applicability statement to framework and BCP=0D= =0Ais not required=0D=0A=0D=0AAt 3:05 PM -0700 3/25/09, Winterbottom, James= wrote:=0D=0A>Actually Ted I don't recall see an explicit reference to a 3G= PP=0D=0Aspecification that address the problem I have described below. Inde= ed my=0D=0Arecollection, admittedly it has been some time since I have look= ed at=0D=0Athe 3GPP solution in detail, was that this deployment is deemed = out of=0D=0Ascope. That is, 3GPP do not have a solution for it, but recogni= ze it as=0D=0Abeing an issue. ECRIT fills this hole. Applicability to only = packet=0D=0Adeployments is not in question I hope, consequently how that pa= cket is=0D=0Aprovided is also, I hope, not an issue, otherwise need to cons= ider=0D=0Aapplicability to every other type of physical access network. Ind= eed=0D=0Athis same argument can be posed for every IETF protocol or framewo= rk=0D=0Adocument.=0D=0A>=0D=0A>If we have to have an applicability statemen= t, and I don't think we do,=0D=0Athen it should be even more simple than wh= at has been currently=0D=0Aproposed.=0D=0A>=0D=0A>"This document applies to= all devices and networks that participate in=0D=0AInternet emergency calli= ng".=0D=0A=0D=0AThat's a pretty major revision of Framework, Section 4. Th= at claims to=0D=0Aconsider all=0D=0Aprivate networks using IP. See:=0D=0A=0D= =0A Devices that create media sessions and exchange audio, video and/or=0D= =0A text, and have the capability to establish sessions to a wide variety=0D= =0A of addresses, and communicate over private IP networks or the=0D=0A = Internet, should support emergency calls.=0D=0A=0D=0AIf you are meeting th= at remit, you need to acknowledge that other=0D=0Afunctional entities exist= and are currently doing their best to get=0D=0Athe emergency calls to thei= r responders. If you want to limit=0D=0Athis to something that passes *you= r* view of what constitutes=0D=0Athe Internet, then we have a bigger proble= m.=0D=0A=0D=0AAgain, just speaking for myself,=0D=0A=09=09=09=09Ted=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 From rbarnes@bbn.com Wed Mar 25 17:23:12 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 014FE3A6BEA for ; Wed, 25 Mar 2009 17:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7JEc8hK8hWK for ; Wed, 25 Mar 2009 17:23:11 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 0C0B73A680F for ; Wed, 25 Mar 2009 17:22:52 -0700 (PDT) Received: from [128.89.252.81] (helo=dhcp-17f1.meeting.ietf.org) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LmdNn-00071z-CD for ecrit@ietf.org; Wed, 25 Mar 2009 20:23:43 -0400 Message-ID: <49CACB08.8010502@bbn.com> Date: Wed, 25 Mar 2009 17:23:36 -0700 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Ecrit] Reset button: ECRIT text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 00:23:12 -0000 Proposal (latest from previous thread, due to Linsner): This document describes an architecture for emergency calling contained within the common Internet environment. In this environment, the originating host bears most of the burden of implementing emergency calls, and the caller's Access Network Provider may have a supporting role. If such exists, the caller's Application Service Provider plays a minor role. The underlying specifications do allow for the Application Service Provider to take a more expansive role in emergency calls. However, such cases and any associated issues that arise outside this environment are for further study. If you have comments, please submit a revision to the above proposal. --Richard From hgs@cs.columbia.edu Wed Mar 25 17:38:44 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 345523A65A5 for ; Wed, 25 Mar 2009 17:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ixyFGp67Rlb for ; Wed, 25 Mar 2009 17:38:43 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 2F3C53A68E6 for ; Wed, 25 Mar 2009 17:38:43 -0700 (PDT) Received: from dhcp-57e0.meeting.ietf.org (dhcp-57e0.meeting.ietf.org [130.129.87.224] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2Q0dTmY022552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Mar 2009 20:39:30 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Richard Barnes In-Reply-To: <49CACB08.8010502@bbn.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Mar 2009 20:39:25 -0400 References: <49CACB08.8010502@bbn.com> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: ECRIT Subject: Re: [Ecrit] Reset button: ECRIT text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 00:38:44 -0000 Is there an "uncommon" Internet environment? This is so vague to make any amateur lawyer proud... On Mar 25, 2009, at 8:23 PM, Richard Barnes wrote: > > > > Proposal (latest from previous thread, due to Linsner): > > This document describes an architecture for emergency calling > contained > within the common Internet environment. In this environment, the > originating host bears most of the burden of implementing emergency > calls, and the caller's Access Network Provider may have a > supporting role. If such exists, the caller's Application Service > Provider plays a minor role. The underlying specifications do allow > for the Application Service Provider to take a more expansive role > in emergency calls. However, such cases and any associated issues > that arise outside this environment are for further study. > > If you have comments, please submit a revision to the above proposal. > > --Richard > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From rbarnes@bbn.com Wed Mar 25 17:47:05 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D51A53A6BEA for ; Wed, 25 Mar 2009 17:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WffuS8dGOc8A for ; Wed, 25 Mar 2009 17:47:05 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 08C9F3A6BD5 for ; Wed, 25 Mar 2009 17:47:05 -0700 (PDT) Received: from [128.89.252.81] (helo=dhcp-17f1.meeting.ietf.org) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LmdlF-0007L8-Al; Wed, 25 Mar 2009 20:47:57 -0400 Message-ID: <49CAD0B2.5030005@bbn.com> Date: Wed, 25 Mar 2009 17:47:46 -0700 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Henning Schulzrinne References: <49CACB08.8010502@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ECRIT Subject: Re: [Ecrit] Reset button: ECRIT text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 00:47:05 -0000 "Common" == "public" / "open" ? (vs. "usual") Henning Schulzrinne wrote: > Is there an "uncommon" Internet environment? > > This is so vague to make any amateur lawyer proud... > > On Mar 25, 2009, at 8:23 PM, Richard Barnes wrote: > >> >> >> >> Proposal (latest from previous thread, due to Linsner): >> >> This document describes an architecture for emergency calling contained >> within the common Internet environment. In this environment, the >> originating host bears most of the burden of implementing emergency >> calls, and the caller's Access Network Provider may have a supporting >> role. If such exists, the caller's Application Service Provider plays >> a minor role. The underlying specifications do allow for the >> Application Service Provider to take a more expansive role in >> emergency calls. However, such cases and any associated issues that >> arise outside this environment are for further study. >> >> If you have comments, please submit a revision to the above proposal. >> >> --Richard >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > From Hannes.Tschofenig@gmx.net Wed Mar 25 17:53:28 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92C283A689C for ; Wed, 25 Mar 2009 17:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5e2aa97+fWuu for ; Wed, 25 Mar 2009 17:53:27 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 42B9C3A6359 for ; Wed, 25 Mar 2009 17:53:26 -0700 (PDT) Received: (qmail invoked by alias); 26 Mar 2009 00:54:18 -0000 Received: from dhcp-14f7.meeting.ietf.org (EHLO 4FIL42860) [130.129.20.247] by mail.gmx.net (mp048) with SMTP; 26 Mar 2009 01:54:18 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18f3Fwk4WIfbP6+ECeONgjbYT5Pr2Womb7lfcOcQ8 8P26s2h2kN3GXs From: "Hannes Tschofenig" To: "'Richard Barnes'" , "'ECRIT'" References: <49CACB08.8010502@bbn.com> Date: Wed, 25 Mar 2009 17:55:26 -0700 Message-ID: <026101c9adad$8efb6f80$f7148182@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmtqS1tQJTM+0itQCmGQmDP7XJqkAAA/4bw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <49CACB08.8010502@bbn.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59 Subject: Re: [Ecrit] Reset button: ECRIT text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 00:53:28 -0000 I don't agree that the area where the application service providers takes a more expansive role in emergency calls is for further study. What do we actually mean by the most of the burden of implementing emergency calls? Ciao Hannes >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >On Behalf Of Richard Barnes >Sent: 25 March, 2009 17:24 >To: ECRIT >Subject: [Ecrit] Reset button: ECRIT text > >nton%20and%20Lavrov-thumb-320x374.jpg> > >Proposal (latest from previous thread, due to Linsner): > >This document describes an architecture for emergency calling >contained within the common Internet environment. In this >environment, the originating host bears most of the burden of >implementing emergency calls, and the caller's Access Network >Provider may have a supporting role. If such exists, the >caller's Application Service Provider plays a minor role. The >underlying specifications do allow for the Application Service >Provider to take a more expansive role in emergency calls. >However, such cases and any associated issues that arise >outside this environment are for further study. > >If you have comments, please submit a revision to the above proposal. > >--Richard >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > From hgs@cs.columbia.edu Wed Mar 25 17:55:16 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B6A23A6BEA for ; Wed, 25 Mar 2009 17:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYBXpKIO2NNJ for ; Wed, 25 Mar 2009 17:55:15 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 509EC3A689C for ; Wed, 25 Mar 2009 17:55:15 -0700 (PDT) Received: from dhcp-57e0.meeting.ietf.org (dhcp-57e0.meeting.ietf.org [130.129.87.224] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.1) with ESMTP id n2Q0u5Cx025290 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 25 Mar 2009 20:56:06 -0400 (EDT) Message-Id: <481A6905-7F86-4CD8-965B-6994A01EC5CD@cs.columbia.edu> From: Henning Schulzrinne To: Richard Barnes In-Reply-To: <49CAD0B2.5030005@bbn.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Mar 2009 20:56:04 -0400 References: <49CACB08.8010502@bbn.com> <49CAD0B2.5030005@bbn.com> X-Mailer: Apple Mail (2.930.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: ECRIT Subject: Re: [Ecrit] Reset button: ECRIT text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 00:55:16 -0000 Would this, as noted, exclude enterprise or hotel WiFi environments, which are presumably neither public nor open? What makes a 3GPP Internet access environment, offered by a common carrier to the public, less open/public than the port-restricted NATed environment common in hotels? Henning On Mar 25, 2009, at 8:47 PM, Richard Barnes wrote: > "Common" == "public" / "open" ? From rbarnes@bbn.com Wed Mar 25 18:03:08 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 593003A6805 for ; Wed, 25 Mar 2009 18:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMKYYBw4StvR for ; Wed, 25 Mar 2009 18:03:07 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id A0D7E3A659C for ; Wed, 25 Mar 2009 18:03:07 -0700 (PDT) Received: from [128.89.252.81] (helo=dhcp-17f1.meeting.ietf.org) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1Lme0l-0007eK-Cj for ecrit@ietf.org; Wed, 25 Mar 2009 21:04:00 -0400 Message-ID: <49CAD47B.8040400@bbn.com> Date: Wed, 25 Mar 2009 18:03:55 -0700 From: Richard Barnes User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Ecrit] Reset 2: Framework text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 01:03:08 -0000 Proposal (trying to be more concrete): This document focuses on the case in which all three steps in the emergency calling process -- location configuration, call routing, and call placement -- are performed by the calling endpoint, with the endpoint's Access Service Provider supporting the process by providing location information. Calls may be routed via an application-layer Communications Service Provider (e.g., a Voice Service Provider), but need not be. The underlying protocols can also be used to support other models in which parts of the process are delegated to the Communications Service Provider. This document does not address in detail either these models or interoperability issues between them and the model described here. From Martin.Thomson@andrew.com Wed Mar 25 18:03:23 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F405D3A6832 for ; Wed, 25 Mar 2009 18:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvwLLs56aSck for ; Wed, 25 Mar 2009 18:03:22 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 16D9C3A6D66 for ; Wed, 25 Mar 2009 18:03:21 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_25_20_07_39 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 25 Mar 2009 20:07:39 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 19:47:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 25 Mar 2009 19:47:30 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Reset button: ECRIT text Thread-Index: Acmtq1kK/DkuTTNSRUaR6zqw3P/DkgAAQK7Q References: <49CACB08.8010502@bbn.com> From: "Thomson, Martin" To: "Henning Schulzrinne" , "Richard Barnes" X-OriginalArrivalTime: 26 Mar 2009 00:47:32.0443 (UTC) FILETIME=[728A82B0:01C9ADAC] Cc: ECRIT Subject: Re: [Ecrit] Reset button: ECRIT text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 01:03:23 -0000 KzEgOiBSaWNoYXJkLCB0aGVyZSdzIGEgcmljaCBmdXR1cmUgZm9yIHlvdSBpbiBkcmFmdGluZyBw YXRlbnRzIGlmIHlvdSB3YW50ZWQgYSBuZXcgY2FyZWVyLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IGVjcml0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzplY3JpdC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgSGVubmluZyBTY2h1bHpyaW5uZQ0KPiBT ZW50OiBXZWRuZXNkYXksIDI1IE1hcmNoIDIwMDkgNTozOSBQTQ0KPiBUbzogUmljaGFyZCBCYXJu ZXMNCj4gQ2M6IEVDUklUDQo+IFN1YmplY3Q6IFJlOiBbRWNyaXRdIFJlc2V0IGJ1dHRvbjogRUNS SVQgdGV4dA0KPiANCj4gSXMgdGhlcmUgYW4gInVuY29tbW9uIiBJbnRlcm5ldCBlbnZpcm9ubWVu dD8NCj4gDQo+IFRoaXMgaXMgc28gdmFndWUgdG8gbWFrZSBhbnkgYW1hdGV1ciBsYXd5ZXIgcHJv dWQuLi4NCj4gDQo+IE9uIE1hciAyNSwgMjAwOSwgYXQgODoyMyBQTSwgUmljaGFyZCBCYXJuZXMg d3JvdGU6DQo+IA0KPiA+DQo+IDxodHRwOi8vd3d3LnN3YW1wcG9saXRpY3MuY29tL25ld3MvcG9s aXRpY3MvYmxvZy8yMDA5LzAzLzA2L0NsaW50b24lMjBhDQo+IG5kJTIwTGF2cm92LXRodW1iLTMy MHgzNzQuanBnDQo+ID4gPg0KPiA+DQo+ID4gUHJvcG9zYWwgKGxhdGVzdCBmcm9tIHByZXZpb3Vz IHRocmVhZCwgZHVlIHRvIExpbnNuZXIpOg0KPiA+DQo+ID4gVGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgYW4gYXJjaGl0ZWN0dXJlIGZvciBlbWVyZ2VuY3kgY2FsbGluZw0KPiA+IGNvbnRhaW5lZA0K PiA+IHdpdGhpbiB0aGUgY29tbW9uIEludGVybmV0IGVudmlyb25tZW50LiBJbiB0aGlzIGVudmly b25tZW50LCB0aGUNCj4gPiBvcmlnaW5hdGluZyBob3N0IGJlYXJzIG1vc3Qgb2YgdGhlIGJ1cmRl biBvZiBpbXBsZW1lbnRpbmcgZW1lcmdlbmN5DQo+ID4gY2FsbHMsIGFuZCB0aGUgY2FsbGVyJ3Mg QWNjZXNzIE5ldHdvcmsgUHJvdmlkZXIgbWF5IGhhdmUgYQ0KPiA+IHN1cHBvcnRpbmcgcm9sZS4g IElmIHN1Y2ggZXhpc3RzLCB0aGUgY2FsbGVyJ3MgQXBwbGljYXRpb24gU2VydmljZQ0KPiA+IFBy b3ZpZGVyIHBsYXlzIGEgbWlub3Igcm9sZS4gIFRoZSB1bmRlcmx5aW5nIHNwZWNpZmljYXRpb25z IGRvIGFsbG93DQo+ID4gZm9yIHRoZSBBcHBsaWNhdGlvbiBTZXJ2aWNlIFByb3ZpZGVyIHRvIHRh a2UgYSBtb3JlIGV4cGFuc2l2ZSByb2xlDQo+ID4gaW4gZW1lcmdlbmN5IGNhbGxzLiBIb3dldmVy LCBzdWNoIGNhc2VzIGFuZCBhbnkgYXNzb2NpYXRlZCBpc3N1ZXMNCj4gPiB0aGF0IGFyaXNlIG91 dHNpZGUgdGhpcyBlbnZpcm9ubWVudCBhcmUgZm9yIGZ1cnRoZXIgc3R1ZHkuDQo+ID4NCj4gPiBJ ZiB5b3UgaGF2ZSBjb21tZW50cywgcGxlYXNlIHN1Ym1pdCBhIHJldmlzaW9uIHRvIHRoZSBhYm92 ZSBwcm9wb3NhbC4NCj4gPg0KPiA+IC0tUmljaGFyZA0KPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gRWNyaXQgbWFpbGluZyBsaXN0DQo+ID4g RWNyaXRAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2Vjcml0DQo+ID4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IEVjcml0IG1haWxpbmcgbGlzdA0KPiBFY3JpdEBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWdu YXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0 YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkg YW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBl bWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpbbWYyXQ0K From Martin.Dawson@andrew.com Wed Mar 25 18:14:40 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3AB228C227 for ; Wed, 25 Mar 2009 18:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.128 X-Spam-Level: X-Spam-Status: No, score=-1.128 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sw1Lx4-QDDZB for ; Wed, 25 Mar 2009 18:14:40 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 8D44028C221 for ; Wed, 25 Mar 2009 18:14:39 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_25_20_35_38 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 25 Mar 2009 20:35:38 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Mar 2009 20:15:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Mar 2009 20:15:28 -0500 Message-ID: In-Reply-To: <49CAD47B.8040400@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Reset 2: Framework text Thread-Index: Acmtrsqsx/IRHeJNST2Ke6LwnL40xwAATHHg References: <49CAD47B.8040400@bbn.com> From: "Dawson, Martin" To: "Richard Barnes" , "ECRIT" X-OriginalArrivalTime: 26 Mar 2009 01:15:31.0418 (UTC) FILETIME=[5B49C3A0:01C9ADB0] Subject: Re: [Ecrit] Reset 2: Framework text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 01:14:41 -0000 +1 - I do like this better than anything else so far proposed.=0D=0A=0D=0AH= opefully it can't be misrepresented - so we aren't dealing with an=0D=0A"ov= ercharge" button... :)=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Origi= nal Message-----=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ie= tf.org] On Behalf=0D=0AOf Richard Barnes=0D=0ASent: Thursday, 26 March 2009= 12:04 PM=0D=0ATo: ECRIT=0D=0ASubject: [Ecrit] Reset 2: Framework text=0D=0A=0D= =0AProposal (trying to be more concrete):=0D=0A=0D=0AThis document focuses = on the case in which all three steps in the=20=0D=0Aemergency calling proce= ss -- location configuration, call routing, and=20=0D=0Acall placement -- a= re performed by the calling endpoint, with the=20=0D=0Aendpoint's Access Se= rvice Provider supporting the process by providing=20=0D=0Alocation informa= tion. Calls may be routed via an application-layer=20=0D=0ACommunications = Service Provider (e.g., a Voice Service Provider), but=20=0D=0Aneed not be.= The underlying protocols can also be used to support other=0D=0A=0D=0Amod= els in which parts of the process are delegated to the Communications=0D=0A=0D= =0AService Provider. This document does not address in detail either these=0D= =0A=0D=0Amodels or interoperability issues between them and the model descr= ibed=0D=0Ahere.=0D=0A=0D=0A_______________________________________________=0D= =0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.ietf.org/mailman= /listinfo/ecrit=0D=0A=0D=0A------------------------------------------------= ------------------------------------------------=0D=0AThis message is for t= he 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=0Aimmediately and delete the original. Any u= nauthorized use of=0D=0Athis email is prohibited.=0D=0A--------------------= ---------------------------------------------------------------------------= -=0D=0A[mf2]=0D=0A From spencer@wonderhamster.org Wed Mar 25 18:35:20 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E80ED28C227 for ; Wed, 25 Mar 2009 18:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsKQclyuU0v0 for ; Wed, 25 Mar 2009 18:35:20 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 2099828C20F for ; Wed, 25 Mar 2009 18:35:20 -0700 (PDT) Received: from S73602b (dhcp-63fb.meeting.ietf.org [130.129.99.251]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1LmeVs1UYv-000d3Q; Wed, 25 Mar 2009 21:36:12 -0400 Message-ID: From: "Spencer Dawkins" To: "Dawson, Martin" , "Richard Barnes" , "ECRIT" References: <49CAD47B.8040400@bbn.com> Date: Wed, 25 Mar 2009 20:35:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1/czEzWK19PbtJz8c9wIspf2+5Ox3TxbsTEtKh KD4vqyqunmpfHx871n09OMgquzjRRnK8rAXaLq7nf+menBBrpi Cy2mDAefM+Sp/SvIu0++46HNG+KHlyUwg44Xoj/ZyY= Subject: Re: [Ecrit] Reset 2: Framework text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 01:35:21 -0000 This sounds more like the discussion in the room than previous versions, FWIW... Spencer > +1 - I do like this better than anything else so far proposed. > > Hopefully it can't be misrepresented - so we aren't dealing with an > "overcharge" button... :) > > Cheers, > Martin > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Richard Barnes > Sent: Thursday, 26 March 2009 12:04 PM > To: ECRIT > Subject: [Ecrit] Reset 2: Framework text > > Proposal (trying to be more concrete): > > This document focuses on the case in which all three steps in the > emergency calling process -- location configuration, call routing, and > call placement -- are performed by the calling endpoint, with the > endpoint's Access Service Provider supporting the process by providing > location information. Calls may be routed via an application-layer > Communications Service Provider (e.g., a Voice Service Provider), but > need not be. The underlying protocols can also be used to support other > > models in which parts of the process are delegated to the Communications > > Service Provider. This document does not address in detail either these > > models or interoperability issues between them and the model described > here. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.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://www.ietf.org/mailman/listinfo/ecrit > From Gabor.Bajko@nokia.com Wed Mar 25 21:44:23 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA2D53A67D4 for ; Wed, 25 Mar 2009 21:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exbBSKHGBnZ1 for ; Wed, 25 Mar 2009 21:44:22 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 76B043A67AA for ; Wed, 25 Mar 2009 21:44:22 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2Q4jD9i008832 for ; Wed, 25 Mar 2009 23:45:15 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 06:45:10 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 06:45:05 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Thu, 26 Mar 2009 05:45:04 +0100 From: To: Date: Thu, 26 Mar 2009 05:45:03 +0100 Thread-Topic: [Ecrit] Why an applicability statement to framework and BCP is not required Thread-Index: AcmtlBDU3Kf3JbLWRsC5icPSIu2IxgAAFMCzAA2dpAA= Message-ID: References: <49CA7782.2090806@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 26 Mar 2009 04:45:05.0286 (UTC) FILETIME=[A1E5C260:01C9ADCD] X-Nokia-AV: Clean Subject: Re: [Ecrit] Why an applicability statement to framework and BCP is not required X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 04:44:23 -0000 >"This document applies to all devices and networks that participate in >Internet emergency calling". I think this is a good clarification. ietf defines 'internet emergency call= ing', 3gpp and other similar SDOs define 'IMS emergency calling'. They are = not, and they do not have to be the same thing. On the other hand, http://www.ietf.org/internet-drafts/draft-ietf-ecrit-pho= nebcp-08.txt is a collection of requirements, thus a better title for it wo= uld be 'Requirements for Internet Emergency Calling' and an Intended Status= of Standards Track instead of BCP. And the above applicability statement could say: "This document is a collection of requirements for devices and networks tha= t participate in Internet Emergency Calling" - gabor >-----Original Message----- >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf O= f >ext Winterbottom, James >Sent: Wednesday, March 25, 2009 3:05 PM >To: Ted Hardie; Richard Barnes >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] Why an applicability statement to framework and BCP >is not required > >Actually Ted I don't recall see an explicit reference to a 3GPP >specification that address the problem I have described below. Indeed my >recollection, admittedly it has been some time since I have looked at th= e >3GPP solution in detail, was that this deployment is deemed out of scope= . >That is, 3GPP do not have a solution for it, but recognize it as being a= n >issue. ECRIT fills this hole. Applicability to only packet deployments i= s >not in question I hope, consequently how that packet is provided is also= , >I hope, not an issue, otherwise need to consider applicability to every >other type of physical access network. Indeed this same argument can be >posed for every IETF protocol or framework document. > >If we have to have an applicability statement, and I don't think we do, >then it should be even more simple than what has been currently proposed= . > >"This document applies to all devices and networks that participate in >Internet emergency calling". > >This wording has been carefully chosen to say Internet. In all the >scenarios that Stephen has raised he is describing very specific IMS >environments, and while these may be IP, they are not Internet, they are >walled gardens, and in these you can do what ever you want. If 3G >operators want to provide open Internet connectivity then these >specifications do apply to them and they need to adhere to them. > >Cheers >James > > > >-----Original Message----- >From: Ted Hardie [mailto:hardie@qualcomm.com] >Sent: Wed 3/25/2009 4:52 PM >To: Richard Barnes; Winterbottom, James >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] Why an applicability statement to framework and BCP >is not required > >At 11:27 AM -0700 3/25/09, Richard Barnes wrote: >>This argument is pretty persuasive. Could someone who wants to add >>something propose a paragraph and explain why the below doesn't apply? >>If no such text is forthcoming, ISTM that we should go ahead with the >>document as it is. >>--Richard > >Actually, the argument James puts forward below seems pretty much >the same as he put forward in late February, and which Stephen >answered then (Feb 26th, at least as it arrived to me). > >It is pretty obvious that we're not going to get to full or measurable >rough >consensus on this, and I thought Brian's text was a very useful step in >getting >us to a working compromise. Going back over discussions that led us to >the >conclusion that we weren't going to get consensus doesn't seem likely to >move >us forward much. > >I can't speak for anyone else, but moving forward with text discussions >to see if there is a compromise statement here seems more likely to get >us out of these weeds. > >Two cents, > Ted > >>Winterbottom, James wrote: >>> I agree with the people that have said this debate is farcical. >>> >>> >>> >>> Cellular carriers can and do market their 3G services as wireless >>> broadband. In a number of cases, and I can't believe that it is only >>> here, services provide open Internet connectivity allowing access to >>> independent voice service providers (not IMS). When these services ar= e >>> sold in this manner, they are still cellular, but the carrier is >really >>> just an ISP and the ECRIT model for emergency calling is as applicabl= e >>> to them as it is for any DSL ISP. Any specific "cellular" emergency >call >>> procedures are not invoked, the carrier by the very nature of the >>> service they are selling has broken the access-to-voice-service link. >>> This makes the ECRIT architecture applicable. >>> >>> >>> >>> The result is that no applicability statement is required in the ECRI= T >>> documents. Indeed, unless specific statements in the 3GPP >specifications >>> are made to say that open Internet services SHALL NOT be provided >>> through these technologies I can't see how ECRIT is not applicable to >>> cellular. I can't see 3GPP adding such a statement, and I think that >>> their primary customers would go up in arms if they did. I propose >that >>> the applicability statement resolution be dropped unless the >proponents >>> of these applicability statements can stand up and say that open >>> Internet services over 3GPP networks don't happen now and will not >>> happen in the future or they can point us to a 3GPP specification tha= t >>> describes how a totally decoupled access and voice service can delive= r >>> an emergency call to the correct PSAP. >>> >>> >>> >>> Cheers >>> >>> James >>> >>> >>> >>> ---------------------------------------------------------------------= - >-------------------------- >>> This message is for the designated recipient only and may >>> contain privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender >>> immediately and delete the original. Any unauthorized use of >>> this email is prohibited. >>> ---------------------------------------------------------------------= - >-------------------------- >>> [mf2] >>> >>> >>> >>> ---------------------------------------------------------------------= - >-- >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www.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://www.ietf.org/mailman/listinfo/ecrit From mlinsner@cisco.com Wed Mar 25 22:01:46 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDDE93A67D4 for ; Wed, 25 Mar 2009 22:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7KnQ2dRPX95 for ; Wed, 25 Mar 2009 22:01:46 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 232AB3A6BB1 for ; Wed, 25 Mar 2009 22:01:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,423,1233532800"; d="scan'208";a="68940642" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 26 Mar 2009 05:02:39 +0000 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 n2Q52d2h025205; Wed, 25 Mar 2009 22:02:39 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n2Q52ckh015759; Thu, 26 Mar 2009 05:02:39 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, 26 Mar 2009 01:02:38 -0400 Received: from [10.10.7.21] ([10.21.68.107]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Mar 2009 01:02:37 -0400 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Wed, 25 Mar 2009 22:02:34 -0700 From: Marc Linsner To: Henning Schulzrinne Message-ID: Thread-Topic: [Ecrit] Reset button: ECRIT text Thread-Index: Acmt0BL64bXD42mdoEOBLmJlD0/pOA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Mar 2009 05:02:38.0073 (UTC) FILETIME=[15684E90:01C9ADD0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=341; t=1238043759; x=1238907759; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20Re=3A=20[Ecrit]=20Reset=20button=3A=20ECRIT=20t ext |Sender:=20; bh=9FPm3G7MI785tZ2HZX69mHsJdLH+KmUrxypDjciqAYw=; b=xE+JG/tv5NqoFx88jvVcbVHXR8FnSgpfgxxPg2i7QNsF7eYQqSiJC8i0W3 UBilTFRifrtIpBuY46HVPzNJ5LJeRHDTvRspKTua5QtwtbfVlnL1O/H5hDOz cvj9jvQ9gc; Authentication-Results: sj-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: ECRIT Subject: Re: [Ecrit] Reset button: ECRIT text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 05:01:47 -0000 > Is there an "uncommon" Internet environment? Yes, one where the network attempts to be smarter than the host. >From an application pov, the IETF Internet architecture encompasses smart hosts and dumb networks in support of end to end communication. The success of the Internet is directly due to this architecture. -Marc- From sedge@qualcomm.com Wed Mar 25 22:39:35 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA1B33A6DE7 for ; Wed, 25 Mar 2009 22:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.543 X-Spam-Level: X-Spam-Status: No, score=-103.543 tagged_above=-999 required=5 tests=[AWL=-0.944, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWU8hXZ0OvPo for ; Wed, 25 Mar 2009 22:39:34 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 8D0D63A6DDD for ; Wed, 25 Mar 2009 22:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1238046027; x=1269582027; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20S pencer=20Dawkins=20,=0D=0A=20 =20=20=20=20=20=20=20"Dawson,=20Martin"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20Richard =20Barnes=20,=20ECRIT=0D=0A=09|Date:=20Wed,=2025=20Mar=202009=2022:39:55=20-0700 |Subject:=20RE:=20[Ecrit]=20Reset=202:=20Framework=20text |Thread-Topic:=20[Ecrit]=20Reset=202:=20Framework=20text |Thread-Index:=20Acmts0SoRaQCrqEfSc2SQp74eLA9kAAIC+gg |Message-ID:=20<1288E74A73964940B132A0B9EA8D8ABC5658AA75@ NASANEXMB04.na.qualcomm.com>|References:=20<49CAD47B.8040 400@bbn.com>=0D=0A=09=0D=0A=20|In-Reply-To:=20|Accept-Language:=20 en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5564"=3B=20a=3D"16606587"; bh=5dJQ9MG5h3Ql4bhcYFwLSLOMJGowF0AYx6erOo70M6E=; b=hEP8GkCC5R7zX4Hcemm811aLh3zHWajE/N/21F8t7+eGZxScNs/85BGE YwRLXRK9TwTwhpyftCjcwEgo85nJ1ym0dfurt9m3MREqXl2pIbty3k5xf SNnkMLMCGRY/KCOzFsIZJOP6w+a9WXJ2CdX/CvKn+OjfaY81x7VuAcKtg c=; X-IronPort-AV: E=McAfee;i="5300,2777,5564"; a="16606587" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Mar 2009 22:40:00 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2Q5dx1W031361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Mar 2009 22:39:59 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2Q5du3H009331 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Mar 2009 22:39:57 -0700 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Wed, 25 Mar 2009 22:39:56 -0700 From: "Edge, Stephen" To: Spencer Dawkins , "Dawson, Martin" , Richard Barnes , ECRIT Date: Wed, 25 Mar 2009 22:39:55 -0700 Thread-Topic: [Ecrit] Reset 2: Framework text Thread-Index: Acmts0SoRaQCrqEfSc2SQp74eLA9kAAIC+gg Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5658AA75@NASANEXMB04.na.qualcomm.com> References: <49CAD47B.8040400@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] Reset 2: Framework text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 05:39:35 -0000 I agree this may be heading in a mutually agreeable direction. But I have t= he following suggested changes. I am using a "**" to indicate the changes. This document focuses on the case in which all three steps in the emergency= calling process -- location configuration, call routing, and call placemen= t - **can be and** are performed by the calling endpoint, with the endpoint= 's Access Service Provider supporting the process by providing location inf= ormation. Calls **in this case** may be routed via an application-layer Co= mmunications Service Provider (e.g., a Voice Service Provider), but need no= t be. The underlying protocols can also be used to support other models in= which parts of the process are delegated to the Communications Service Pro= vider. This document does not address in detail either these models or int= eroperability issues between them and the model described here. The "can be" above automatically removes scenarios that cannot be supported= (of course) without the need to elaborate on what these are - or even (for= those with some views) whether they exist. The "in this case" applies the = same restriction to CSP routing. Kind Regards Stephen -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of S= pencer Dawkins Sent: Wednesday, March 25, 2009 6:36 PM To: Dawson, Martin; Richard Barnes; ECRIT Subject: Re: [Ecrit] Reset 2: Framework text This sounds more like the discussion in the room than previous versions,=20 FWIW... Spencer > +1 - I do like this better than anything else so far proposed. > > Hopefully it can't be misrepresented - so we aren't dealing with an > "overcharge" button... :) > > Cheers, > Martin > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Richard Barnes > Sent: Thursday, 26 March 2009 12:04 PM > To: ECRIT > Subject: [Ecrit] Reset 2: Framework text > > Proposal (trying to be more concrete): > > This document focuses on the case in which all three steps in the > emergency calling process -- location configuration, call routing, and > call placement -- are performed by the calling endpoint, with the > endpoint's Access Service Provider supporting the process by providing > location information. Calls may be routed via an application-layer > Communications Service Provider (e.g., a Voice Service Provider), but > need not be. The underlying protocols can also be used to support other > > models in which parts of the process are delegated to the Communications > > Service Provider. This document does not address in detail either these > > models or interoperability issues between them and the model described > here. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.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://www.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From Martin.Dawson@andrew.com Wed Mar 25 22:49:15 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E565A3A6DE7 for ; Wed, 25 Mar 2009 22:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.132 X-Spam-Level: X-Spam-Status: No, score=-1.132 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84fs92PR0GDb for ; Wed, 25 Mar 2009 22:49:15 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id D598E3A67D4 for ; Wed, 25 Mar 2009 22:49:14 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_26_01_10_13 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 26 Mar 2009 01:10:13 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 00:50:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Mar 2009 00:50:04 -0500 Message-ID: In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5658AA75@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Reset 2: Framework text Thread-Index: Acmts0SoRaQCrqEfSc2SQp74eLA9kAAIC+ggAAC+5jA= References: <49CAD47B.8040400@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC5658AA75@NASANEXMB04.na.qualcomm.com> From: "Dawson, Martin" To: "Edge, Stephen" , "Spencer Dawkins" , "Richard Barnes" , "ECRIT" X-OriginalArrivalTime: 26 Mar 2009 05:50:05.0923 (UTC) FILETIME=[B6DBBB30:01C9ADD6] Subject: Re: [Ecrit] Reset 2: Framework text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 05:49:16 -0000 These additions were implied in the original text and are redundant.=0D=0AT= hey only serve to convey some significance that isn't intended. I=0D=0Apref= er the clarity and economy of Richard's original.=0D=0A=0D=0ACheers,=0D=0AM= artin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Edge, Stephen [mailt= o:sedge@qualcomm.com]=20=0D=0ASent: Thursday, 26 March 2009 4:40 PM=0D=0ATo= : Spencer Dawkins; Dawson, Martin; Richard Barnes; ECRIT=0D=0ASubject: RE: = [Ecrit] Reset 2: Framework text=0D=0A=0D=0AI agree this may be heading in a= mutually agreeable direction. But I=0D=0Ahave the following suggested chan= ges. I am using a "**" to indicate the=0D=0Achanges.=0D=0A=0D=0AThis docume= nt focuses on the case in which all three steps in the=0D=0Aemergency calli= ng process -- location configuration, call routing, and=0D=0Acall placement= - **can be and** are performed by the calling endpoint,=0D=0Awith the endp= oint's Access Service Provider supporting the process by=0D=0Aproviding loc= ation information. Calls **in this case** may be routed=0D=0Avia an applic= ation-layer Communications Service Provider (e.g., a Voice=0D=0AService Pro= vider), but need not be. The underlying protocols can also=0D=0Abe used to= support other models in which parts of the process are=0D=0Adelegated to t= he Communications Service Provider. This document does=0D=0Anot address in= detail either these models or interoperability issues=0D=0Abetween them an= d the model described here.=0D=0A=0D=0AThe "can be" above automatically rem= oves scenarios that cannot be=0D=0Asupported (of course) without the need t= o elaborate on what these are -=0D=0Aor even (for those with some views) wh= ether they exist. The "in this=0D=0Acase" applies the same restriction to C= SP routing.=0D=0A=0D=0AKind Regards=0D=0A=0D=0AStephen=0D=0A-----Original M= essage-----=0D=0AFrom: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.or= g] On Behalf=0D=0AOf Spencer Dawkins=0D=0ASent: Wednesday, March 25, 2009 6= :36 PM=0D=0ATo: Dawson, Martin; Richard Barnes; ECRIT=0D=0ASubject: Re: [Ec= rit] Reset 2: Framework text=0D=0A=0D=0AThis sounds more like the discussio= n in the room than previous versions,=0D=0A=0D=0AFWIW...=0D=0A=0D=0ASpencer=0D= =0A=0D=0A=0D=0A> +1 - I do like this better than anything else so far propo= sed.=0D=0A>=0D=0A> Hopefully it can't be misrepresented - so we aren't deal= ing with an=0D=0A> "overcharge" button... :)=0D=0A>=0D=0A> Cheers,=0D=0A> M= artin=0D=0A>=0D=0A> -----Original Message-----=0D=0A> From: ecrit-bounces@i= etf.org [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0A> Of Richard Barnes=0D= =0A> Sent: Thursday, 26 March 2009 12:04 PM=0D=0A> To: ECRIT=0D=0A> Subject= : [Ecrit] Reset 2: Framework text=0D=0A>=0D=0A> Proposal (trying to be more= concrete):=0D=0A>=0D=0A> This document focuses on the case in which all th= ree steps in the=0D=0A> emergency calling process -- location configuration= , call routing, and=0D=0A> call placement -- are performed by the calling e= ndpoint, with the=0D=0A> endpoint's Access Service Provider supporting the = process by providing=0D=0A> location information. Calls may be routed via = an application-layer=0D=0A> Communications Service Provider (e.g., a Voice = Service Provider), but=0D=0A> need not be. The underlying protocols can al= so be used to support=0D=0Aother=0D=0A>=0D=0A> models in which parts of the= process are delegated to the=0D=0ACommunications=0D=0A>=0D=0A> Service Pro= vider. This document does not address in detail either=0D=0Athese=0D=0A>=0D= =0A> models or interoperability issues between them and the model described=0D= =0A> here.=0D=0A>=0D=0A> _______________________________________________=0D= =0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www.ietf.org/m= ailman/listinfo/ecrit=0D=0A>=0D=0A>=0D=0A----------------------------------= --------------------------------------=0D=0A------------------------=0D=0A>= This message is for the designated recipient only and may=0D=0A> contain p= rivileged, proprietary, or otherwise private information.=0D=0A> If you hav= e received it in error, please notify the sender=0D=0A> immediately and del= ete the original. Any unauthorized use of=0D=0A> this email is prohibited.=0D= =0A>=0D=0A-----------------------------------------------------------------= -------=0D=0A------------------------=0D=0A> [mf2]=0D=0A>=0D=0A> __________= _____________________________________=0D=0A> Ecrit mailing list=0D=0A> Ecri= t@ietf.org=0D=0A> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A=0D= =0A=0D=0A_______________________________________________=0D=0AEcrit mailing= list=0D=0AEcrit@ietf.org=0D=0Ahttps://www.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 From sedge@qualcomm.com Wed Mar 25 23:36:03 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 923003A6DFA for ; Wed, 25 Mar 2009 23:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.494 X-Spam-Level: X-Spam-Status: No, score=-103.494 tagged_above=-999 required=5 tests=[AWL=-0.895, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dnj+B5g0rTA for ; Wed, 25 Mar 2009 23:36:02 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 42AED3A6D46 for ; Wed, 25 Mar 2009 23:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1238049415; x=1269585415; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" Dawson,=20Martin"=20,=0D=0A=20 =20=20=20=20=20=20=20Spencer=20Dawkins=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20Richard =20Barnes=20,=20ECRIT=0D=0A=09|Date:=20Wed,=2025=20Mar=202009=2023:36:50=20-0700 |Subject:=20RE:=20[Ecrit]=20Reset=202:=20Framework=20text |Thread-Topic:=20[Ecrit]=20Reset=202:=20Framework=20text |Thread-Index:=20Acmts0SoRaQCrqEfSc2SQp74eLA9kAAIC+ggAAC+ 5jAAAJzf8A=3D=3D|Message-ID:=20<1288E74A73964940B132A0B9E A8D8ABC5658AA78@NASANEXMB04.na.qualcomm.com>|References: =20<49CAD47B.8040400@bbn.com>=0D=0A=20=0D=0A=20<1288E74A7396 4940B132A0B9EA8D8ABC5658AA75@NASANEXMB04.na.qualcomm.com> =0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5564"=3B=20a=3D"16607610"; bh=IY1iFRVN123lCCkiVJL5y2BhF+FXTNv87JCxMbumf/4=; b=B7+2FtGFvFDdutQx7F7t+W21Yp4prZowErHuX+JOJP/rDrtGCMT/OUHM Oq/z/g3Ff6vQpVZdixGoDtxLZLkAJ+NdMaSPbqWCQcLCB+xKbrhtE1d5/ VRPDUANCTvdrmQQYmk/DDEAlhrthP7FeWTPfq1O1EZlVoOw4mHIblk6dw k=; X-IronPort-AV: E=McAfee;i="5300,2777,5564"; a="16607610" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Mar 2009 23:36:55 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2Q6aslT005535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Mar 2009 23:36:55 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2Q6aqNN008839 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 Mar 2009 23:36:52 -0700 (PDT) Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Wed, 25 Mar 2009 23:36:51 -0700 From: "Edge, Stephen" To: "Dawson, Martin" , Spencer Dawkins , Richard Barnes , ECRIT Date: Wed, 25 Mar 2009 23:36:50 -0700 Thread-Topic: [Ecrit] Reset 2: Framework text Thread-Index: Acmts0SoRaQCrqEfSc2SQp74eLA9kAAIC+ggAAC+5jAAAJzf8A== Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5658AA78@NASANEXMB04.na.qualcomm.com> References: <49CAD47B.8040400@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC5658AA75@NASANEXMB04.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] Reset 2: Framework text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 06:36:03 -0000 Well it you want economy, the "can be and are" could be changed to just "ca= n be" - there are plenty of "can be"s already in both drafts. But I think t= he wording below is more clear and only a couple of words longer.=20 Kind Regards Stephen -----Original Message----- From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20 Sent: Wednesday, March 25, 2009 10:50 PM To: Edge, Stephen; Spencer Dawkins; Richard Barnes; ECRIT Subject: RE: [Ecrit] Reset 2: Framework text These additions were implied in the original text and are redundant. They only serve to convey some significance that isn't intended. I prefer the clarity and economy of Richard's original. Cheers, Martin -----Original Message----- From: Edge, Stephen [mailto:sedge@qualcomm.com]=20 Sent: Thursday, 26 March 2009 4:40 PM To: Spencer Dawkins; Dawson, Martin; Richard Barnes; ECRIT Subject: RE: [Ecrit] Reset 2: Framework text I agree this may be heading in a mutually agreeable direction. But I have the following suggested changes. I am using a "**" to indicate the changes. This document focuses on the case in which all three steps in the emergency calling process -- location configuration, call routing, and call placement - **can be and** are performed by the calling endpoint, with the endpoint's Access Service Provider supporting the process by providing location information. Calls **in this case** may be routed via an application-layer Communications Service Provider (e.g., a Voice Service Provider), but need not be. The underlying protocols can also be used to support other models in which parts of the process are delegated to the Communications Service Provider. This document does not address in detail either these models or interoperability issues between them and the model described here. The "can be" above automatically removes scenarios that cannot be supported (of course) without the need to elaborate on what these are - or even (for those with some views) whether they exist. The "in this case" applies the same restriction to CSP routing. Kind Regards Stephen -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: Wednesday, March 25, 2009 6:36 PM To: Dawson, Martin; Richard Barnes; ECRIT Subject: Re: [Ecrit] Reset 2: Framework text This sounds more like the discussion in the room than previous versions, FWIW... Spencer > +1 - I do like this better than anything else so far proposed. > > Hopefully it can't be misrepresented - so we aren't dealing with an > "overcharge" button... :) > > Cheers, > Martin > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Richard Barnes > Sent: Thursday, 26 March 2009 12:04 PM > To: ECRIT > Subject: [Ecrit] Reset 2: Framework text > > Proposal (trying to be more concrete): > > This document focuses on the case in which all three steps in the > emergency calling process -- location configuration, call routing, and > call placement -- are performed by the calling endpoint, with the > endpoint's Access Service Provider supporting the process by providing > location information. Calls may be routed via an application-layer > Communications Service Provider (e.g., a Voice Service Provider), but > need not be. The underlying protocols can also be used to support other > > models in which parts of the process are delegated to the Communications > > Service Provider. This document does not address in detail either these > > models or interoperability issues between them and the model described > here. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.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://www.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 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] From Martin.Dawson@andrew.com Thu Mar 26 00:54:13 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AF0E3A68EC for ; Thu, 26 Mar 2009 00:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.136 X-Spam-Level: X-Spam-Status: No, score=-1.136 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNLhq-2dIZKF for ; Thu, 26 Mar 2009 00:54:12 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 3B1643A6833 for ; Thu, 26 Mar 2009 00:54:12 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_26_03_15_12 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 26 Mar 2009 03:15:12 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 02:55:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Mar 2009 02:51:45 -0500 Message-ID: In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5658AA78@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Reset 2: Framework text Thread-Index: Acmts0SoRaQCrqEfSc2SQp74eLA9kAAIC+ggAAC+5jAAAJzf8AADsLrA References: <49CAD47B.8040400@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC5658AA75@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5658AA78@NASANEXMB04.na.qualcomm.com> From: "Dawson, Martin" To: "Edge, Stephen" , "Spencer Dawkins" , "Richard Barnes" , "ECRIT" X-OriginalArrivalTime: 26 Mar 2009 07:55:04.0801 (UTC) FILETIME=[2C89B510:01C9ADE8] Subject: Re: [Ecrit] Reset 2: Framework text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 07:54:13 -0000 No. I believe the original is clearer and more correct.=0D=0A=0D=0ACheers,=0D= =0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Edge, Stephen [m= ailto:sedge@qualcomm.com]=20=0D=0ASent: Thursday, 26 March 2009 5:37 PM=0D=0A= To: Dawson, Martin; Spencer Dawkins; Richard Barnes; ECRIT=0D=0ASubject: RE= : [Ecrit] Reset 2: Framework text=0D=0A=0D=0AWell it you want economy, the = "can be and are" could be changed to just=0D=0A"can be" - there are plenty = of "can be"s already in both drafts. But I=0D=0Athink the wording below is = more clear and only a couple of words longer.=0D=0A=0D=0A=0D=0AKind Regards=0D= =0A=0D=0AStephen=0D=0A-----Original Message-----=0D=0AFrom: Dawson, Martin = [mailto:Martin.Dawson@andrew.com]=20=0D=0ASent: Wednesday, March 25, 2009 1= 0:50 PM=0D=0ATo: Edge, Stephen; Spencer Dawkins; Richard Barnes; ECRIT=0D=0A= Subject: RE: [Ecrit] Reset 2: Framework text=0D=0A=0D=0AThese additions wer= e implied in the original text and are redundant.=0D=0AThey only serve to c= onvey some significance that isn't intended. I=0D=0Aprefer the clarity and = economy of Richard's original.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A--= ---Original Message-----=0D=0AFrom: Edge, Stephen [mailto:sedge@qualcomm.co= m]=20=0D=0ASent: Thursday, 26 March 2009 4:40 PM=0D=0ATo: Spencer Dawkins; = Dawson, Martin; Richard Barnes; ECRIT=0D=0ASubject: RE: [Ecrit] Reset 2: Fr= amework text=0D=0A=0D=0AI agree this may be heading in a mutually agreeable= direction. But I=0D=0Ahave the following suggested changes. I am using a "= **" to indicate the=0D=0Achanges.=0D=0A=0D=0AThis document focuses on the c= ase in which all three steps in the=0D=0Aemergency calling process -- locat= ion configuration, call routing, and=0D=0Acall placement - **can be and** a= re performed by the calling endpoint,=0D=0Awith the endpoint's Access Servi= ce Provider supporting the process by=0D=0Aproviding location information. = Calls **in this case** may be routed=0D=0Avia an application-layer Communi= cations Service Provider (e.g., a Voice=0D=0AService Provider), but need no= t be. The underlying protocols can also=0D=0Abe used to support other mode= ls in which parts of the process are=0D=0Adelegated to the Communications S= ervice Provider. This document does=0D=0Anot address in detail either thes= e models or interoperability issues=0D=0Abetween them and the model describ= ed here.=0D=0A=0D=0AThe "can be" above automatically removes scenarios that= cannot be=0D=0Asupported (of course) without the need to elaborate on what= these are -=0D=0Aor even (for those with some views) whether they exist. T= he "in this=0D=0Acase" applies the same restriction to CSP routing.=0D=0A=0D= =0AKind Regards=0D=0A=0D=0AStephen=0D=0A-----Original Message-----=0D=0AFro= m: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0AOf= Spencer Dawkins=0D=0ASent: Wednesday, March 25, 2009 6:36 PM=0D=0ATo: Daws= on, Martin; Richard Barnes; ECRIT=0D=0ASubject: Re: [Ecrit] Reset 2: Framew= ork text=0D=0A=0D=0AThis sounds more like the discussion in the room than p= revious versions,=0D=0A=0D=0AFWIW...=0D=0A=0D=0ASpencer=0D=0A=0D=0A=0D=0A> = +1 - I do like this better than anything else so far proposed.=0D=0A>=0D=0A= > Hopefully it can't be misrepresented - so we aren't dealing with an=0D=0A= > "overcharge" button... :)=0D=0A>=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=0D=0A= > -----Original Message-----=0D=0A> From: ecrit-bounces@ietf.org [mailto:ec= rit-bounces@ietf.org] On Behalf=0D=0A> Of Richard Barnes=0D=0A> Sent: Thurs= day, 26 March 2009 12:04 PM=0D=0A> To: ECRIT=0D=0A> Subject: [Ecrit] Reset = 2: Framework text=0D=0A>=0D=0A> Proposal (trying to be more concrete):=0D=0A= >=0D=0A> This document focuses on the case in which all three steps in the=0D= =0A> emergency calling process -- location configuration, call routing, and=0D= =0A> call placement -- are performed by the calling endpoint, with the=0D=0A= > endpoint's Access Service Provider supporting the process by providing=0D= =0A> location information. Calls may be routed via an application-layer=0D= =0A> Communications Service Provider (e.g., a Voice Service Provider), but=0D= =0A> need not be. The underlying protocols can also be used to support=0D=0A= other=0D=0A>=0D=0A> models in which parts of the process are delegated to t= he=0D=0ACommunications=0D=0A>=0D=0A> Service Provider. This document does = not address in detail either=0D=0Athese=0D=0A>=0D=0A> models or interoperab= ility issues between them and the model described=0D=0A> here.=0D=0A>=0D=0A= > _______________________________________________=0D=0A> Ecrit mailing list=0D= =0A> Ecrit@ietf.org=0D=0A> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A= >=0D=0A>=0D=0A-------------------------------------------------------------= -----------=0D=0A------------------------=0D=0A> This message is for the de= signated recipient only and may=0D=0A> contain privileged, proprietary, or = otherwise private information.=0D=0A> If you have received it in error, ple= ase notify the sender=0D=0A> immediately and delete the original. Any unau= thorized use of=0D=0A> this email is prohibited.=0D=0A>=0D=0A--------------= ----------------------------------------------------------=0D=0A-----------= -------------=0D=0A> [mf2]=0D=0A>=0D=0A> __________________________________= _____________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https:= //www.ietf.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A=0D=0A=0D=0A__________= _____________________________________=0D=0AEcrit mailing list=0D=0AEcrit@ie= tf.org=0D=0Ahttps://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A--------= ----------------------------------------------------------------=0D=0A-----= -------------------=0D=0AThis message is for the designated recipient only = and may=0D=0Acontain privileged, proprietary, or otherwise private informat= ion. =20=0D=0AIf you have received it in error, please notify the sender=0D= =0Aimmediately and delete the original. Any unauthorized use of=0D=0Athis = email is prohibited.=0D=0A-------------------------------------------------= -----------------------=0D=0A------------------------=0D=0A[mf2]=0D=0A=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 From sedge@qualcomm.com Thu Mar 26 02:38:45 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 331AE3A681C for ; Thu, 26 Mar 2009 02:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6K7t0hRrXCg2 for ; Thu, 26 Mar 2009 02:38:43 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id CBDB33A689F for ; Thu, 26 Mar 2009 02:38:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1238060377; x=1269596377; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" Dawson,=20Martin"=20,=0D=0A=20 =20=20=20=20=20=20=20Spencer=20Dawkins=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20Richard =20Barnes=20,=20ECRIT=0D=0A=09|Date:=20Thu,=2026=20Mar=202009=2002:39:17=20-0700 |Subject:=20RE:=20[Ecrit]=20Reset=202:=20Framework=20text |Thread-Topic:=20[Ecrit]=20Reset=202:=20Framework=20text |Thread-Index:=20Acmts0SoRaQCrqEfSc2SQp74eLA9kAAIC+ggAAC+ 5jAAAJzf8AADsLrAAANVWyA=3D|Message-ID:=20<1288E74A7396494 0B132A0B9EA8D8ABC5658AA7C@NASANEXMB04.na.qualcomm.com> |References:=20<49CAD47B.8040400@bbn.com>=0D=0A=20=0D=0A=20< 1288E74A73964940B132A0B9EA8D8ABC5658AA75@NASANEXMB04.na.q ualcomm.com>=0D=0A=20=0D=0A=20<1288E74A73964940B132A0B 9EA8D8ABC5658AA78@NASANEXMB04.na.qualcomm.com>=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5564"=3B=20a=3D"16610959"; bh=+zy8uQ20G4LVKRz0xgYCucEMcXDQtSAQglQEptCylt8=; b=KjeRzDpDZKWFc/vKWh+XNi9U83wOn9uOi3IXoafsHaitvS9M1T+5Ucbt TsC9uZRd15veRKuMiQ7HCDTKGT1B6kFgbwNWAL2pFO1CApSa+sYwG6fZ1 Wpr5T/HvkUHg9+HX289tqlyw0NLxDuVHpXdqVmRbGU0kGtOJQLgF0XKHr s=; X-IronPort-AV: E=McAfee;i="5300,2777,5564"; a="16610959" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Mar 2009 02:39:36 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2Q9dahC024612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Mar 2009 02:39:36 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2Q9dK83017250 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 Mar 2009 02:39:24 -0700 (PDT) Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub03.na.qualcomm.com ([10.46.93.98]) with mapi; Thu, 26 Mar 2009 02:39:20 -0700 From: "Edge, Stephen" To: "Dawson, Martin" , Spencer Dawkins , Richard Barnes , ECRIT Date: Thu, 26 Mar 2009 02:39:17 -0700 Thread-Topic: [Ecrit] Reset 2: Framework text Thread-Index: Acmts0SoRaQCrqEfSc2SQp74eLA9kAAIC+ggAAC+5jAAAJzf8AADsLrAAANVWyA= Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5658AA7C@NASANEXMB04.na.qualcomm.com> References: <49CAD47B.8040400@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC5658AA75@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5658AA78@NASANEXMB04.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] Reset 2: Framework text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 09:38:45 -0000 This means that about 95% of the wording could already be acceptable and th= at about 5% needs more discussion. Is that too optimistic? If not, further views on the remaining 5% seem need= ed. -----Original Message----- From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20 Sent: Thursday, March 26, 2009 12:52 AM To: Edge, Stephen; Spencer Dawkins; Richard Barnes; ECRIT Subject: RE: [Ecrit] Reset 2: Framework text No. I believe the original is clearer and more correct. Cheers, Martin -----Original Message----- From: Edge, Stephen [mailto:sedge@qualcomm.com]=20 Sent: Thursday, 26 March 2009 5:37 PM To: Dawson, Martin; Spencer Dawkins; Richard Barnes; ECRIT Subject: RE: [Ecrit] Reset 2: Framework text Well it you want economy, the "can be and are" could be changed to just "can be" - there are plenty of "can be"s already in both drafts. But I think the wording below is more clear and only a couple of words longer. Kind Regards Stephen -----Original Message----- From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20 Sent: Wednesday, March 25, 2009 10:50 PM To: Edge, Stephen; Spencer Dawkins; Richard Barnes; ECRIT Subject: RE: [Ecrit] Reset 2: Framework text These additions were implied in the original text and are redundant. They only serve to convey some significance that isn't intended. I prefer the clarity and economy of Richard's original. Cheers, Martin -----Original Message----- From: Edge, Stephen [mailto:sedge@qualcomm.com]=20 Sent: Thursday, 26 March 2009 4:40 PM To: Spencer Dawkins; Dawson, Martin; Richard Barnes; ECRIT Subject: RE: [Ecrit] Reset 2: Framework text I agree this may be heading in a mutually agreeable direction. But I have the following suggested changes. I am using a "**" to indicate the changes. This document focuses on the case in which all three steps in the emergency calling process -- location configuration, call routing, and call placement - **can be and** are performed by the calling endpoint, with the endpoint's Access Service Provider supporting the process by providing location information. Calls **in this case** may be routed via an application-layer Communications Service Provider (e.g., a Voice Service Provider), but need not be. The underlying protocols can also be used to support other models in which parts of the process are delegated to the Communications Service Provider. This document does not address in detail either these models or interoperability issues between them and the model described here. The "can be" above automatically removes scenarios that cannot be supported (of course) without the need to elaborate on what these are - or even (for those with some views) whether they exist. The "in this case" applies the same restriction to CSP routing. Kind Regards Stephen -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: Wednesday, March 25, 2009 6:36 PM To: Dawson, Martin; Richard Barnes; ECRIT Subject: Re: [Ecrit] Reset 2: Framework text This sounds more like the discussion in the room than previous versions, FWIW... Spencer > +1 - I do like this better than anything else so far proposed. > > Hopefully it can't be misrepresented - so we aren't dealing with an > "overcharge" button... :) > > Cheers, > Martin > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Richard Barnes > Sent: Thursday, 26 March 2009 12:04 PM > To: ECRIT > Subject: [Ecrit] Reset 2: Framework text > > Proposal (trying to be more concrete): > > This document focuses on the case in which all three steps in the > emergency calling process -- location configuration, call routing, and > call placement -- are performed by the calling endpoint, with the > endpoint's Access Service Provider supporting the process by providing > location information. Calls may be routed via an application-layer > Communications Service Provider (e.g., a Voice Service Provider), but > need not be. The underlying protocols can also be used to support other > > models in which parts of the process are delegated to the Communications > > Service Provider. This document does not address in detail either these > > models or interoperability issues between them and the model described > here. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.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://www.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 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. =20 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] From Martin.Dawson@andrew.com Thu Mar 26 03:54:11 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AFF43A6BE4 for ; Thu, 26 Mar 2009 03:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yK0vr6WFgkFD for ; Thu, 26 Mar 2009 03:54:10 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 4641F3A6BB0 for ; Thu, 26 Mar 2009 03:54:09 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_03_26_06_15_09 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, 26 Mar 2009 06:15:09 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Mar 2009 05:55:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Mar 2009 05:54:56 -0500 Message-ID: In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5658AA7C@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Reset 2: Framework text Thread-Index: Acmts0SoRaQCrqEfSc2SQp74eLA9kAAIC+ggAAC+5jAAAJzf8AADsLrAAANVWyAAAw9/oA== References: <49CAD47B.8040400@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC5658AA75@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5658AA78@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5658AA7C@NASANEXMB04.na.qualcomm.com> From: "Dawson, Martin" To: "Edge, Stephen" , "Spencer Dawkins" , "Richard Barnes" , "ECRIT" X-OriginalArrivalTime: 26 Mar 2009 10:55:02.0338 (UTC) FILETIME=[505F1A20:01C9AE01] Subject: Re: [Ecrit] Reset 2: Framework text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 10:54:11 -0000 I was discussing it=3F=0D=0A=0D=0AI've expressed my view. The original is c= learer and more correct.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Ori= ginal Message-----=0D=0AFrom: Edge, Stephen [mailto:sedge@qualcomm.com]=20=0D= =0ASent: Thursday, 26 March 2009 8:39 PM=0D=0ATo: Dawson, Martin; Spencer D= awkins; Richard Barnes; ECRIT=0D=0ASubject: RE: [Ecrit] Reset 2: Framework = text=0D=0A=0D=0AThis means that about 95% of the wording could already be a= cceptable and=0D=0Athat about 5% needs more discussion.=0D=0A=0D=0AIs that = too optimistic=3F If not, further views on the remaining 5% seem=0D=0Aneede= d.=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Dawson, Martin [mailto:= Martin.Dawson@andrew.com]=20=0D=0ASent: Thursday, March 26, 2009 12:52 AM=0D= =0ATo: Edge, Stephen; Spencer Dawkins; Richard Barnes; ECRIT=0D=0ASubject: = RE: [Ecrit] Reset 2: Framework text=0D=0A=0D=0ANo. I believe the original i= s clearer and more correct.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----= Original Message-----=0D=0AFrom: Edge, Stephen [mailto:sedge@qualcomm.com] =0D= =0ASent: Thursday, 26 March 2009 5:37 PM=0D=0ATo: Dawson, Martin; Spencer D= awkins; Richard Barnes; ECRIT=0D=0ASubject: RE: [Ecrit] Reset 2: Framework = text=0D=0A=0D=0AWell it you want economy, the "can be and are" could be cha= nged to just=0D=0A"can be" - there are plenty of "can be"s already in both = drafts. But I=0D=0Athink the wording below is more clear and only a couple = of words longer.=0D=0A=0D=0A=0D=0AKind Regards=0D=0A=0D=0AStephen=0D=0A----= -Original Message-----=0D=0AFrom: Dawson, Martin [mailto:Martin.Dawson@andr= ew.com]=20=0D=0ASent: Wednesday, March 25, 2009 10:50 PM=0D=0ATo: Edge, Ste= phen; Spencer Dawkins; Richard Barnes; ECRIT=0D=0ASubject: RE: [Ecrit] Rese= t 2: Framework text=0D=0A=0D=0AThese additions were implied in the original= text and are redundant.=0D=0AThey only serve to convey some significance t= hat isn't intended. I=0D=0Aprefer the clarity and economy of Richard's orig= inal.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D= =0AFrom: Edge, Stephen [mailto:sedge@qualcomm.com]=20=0D=0ASent: Thursday, = 26 March 2009 4:40 PM=0D=0ATo: Spencer Dawkins; Dawson, Martin; Richard Bar= nes; ECRIT=0D=0ASubject: RE: [Ecrit] Reset 2: Framework text=0D=0A=0D=0AI a= gree this may be heading in a mutually agreeable direction. But I=0D=0Ahave= the following suggested changes. I am using a "**" to indicate the=0D=0Ach= anges.=0D=0A=0D=0AThis document focuses on the case in which all three step= s in the=0D=0Aemergency calling process -- location configuration, call rou= ting, and=0D=0Acall placement - **can be and** are performed by the calling= endpoint,=0D=0Awith the endpoint's Access Service Provider supporting the = process by=0D=0Aproviding location information. Calls **in this case** may= be routed=0D=0Avia an application-layer Communications Service Provider (e= =2Eg., a Voice=0D=0AService Provider), but need not be. The underlying pro= tocols can also=0D=0Abe used to support other models in which parts of the = process are=0D=0Adelegated to the Communications Service Provider. This do= cument does=0D=0Anot address in detail either these models or interoperabil= ity issues=0D=0Abetween them and the model described here.=0D=0A=0D=0AThe "= can be" above automatically removes scenarios that cannot be=0D=0Asupported= (of course) without the need to elaborate on what these are -=0D=0Aor even= (for those with some views) whether they exist. The "in this=0D=0Acase" ap= plies the same restriction to CSP routing.=0D=0A=0D=0AKind Regards=0D=0A=0D= =0AStephen=0D=0A-----Original Message-----=0D=0AFrom: ecrit-bounces@ietf.or= g [mailto:ecrit-bounces@ietf.org] On Behalf=0D=0AOf Spencer Dawkins=0D=0ASe= nt: Wednesday, March 25, 2009 6:36 PM=0D=0ATo: Dawson, Martin; Richard Barn= es; ECRIT=0D=0ASubject: Re: [Ecrit] Reset 2: Framework text=0D=0A=0D=0AThis= sounds more like the discussion in the room than previous versions,=0D=0A=0D= =0AFWIW...=0D=0A=0D=0ASpencer=0D=0A=0D=0A=0D=0A> +1 - I do like this better= than anything else so far proposed.=0D=0A>=0D=0A> Hopefully it can't be mi= srepresented - so we aren't dealing with an=0D=0A> "overcharge" button... := )=0D=0A>=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=0D=0A> -----Original Message--= ---=0D=0A> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf=0D=0A> Of Richard Barnes=0D=0A> Sent: Thursday, 26 March 2009 12:04 = PM=0D=0A> To: ECRIT=0D=0A> Subject: [Ecrit] Reset 2: Framework text=0D=0A>=0D= =0A> Proposal (trying to be more concrete):=0D=0A>=0D=0A> This document foc= uses on the case in which all three steps in the=0D=0A> emergency calling p= rocess -- location configuration, call routing, and=0D=0A> call placement -= - are performed by the calling endpoint, with the=0D=0A> endpoint's Access = Service Provider supporting the process by providing=0D=0A> location inform= ation. Calls may be routed via an application-layer=0D=0A> Communications = Service Provider (e.g., a Voice Service Provider), but=0D=0A> need not be. = The underlying protocols can also be used to support=0D=0Aother=0D=0A>=0D=0A= > models in which parts of the process are delegated to the=0D=0ACommunicat= ions=0D=0A>=0D=0A> Service Provider. This document does not address in det= ail either=0D=0Athese=0D=0A>=0D=0A> models or interoperability issues betwe= en them and the model described=0D=0A> here.=0D=0A>=0D=0A> ________________= _______________________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf= =2Eorg=0D=0A> https://www.ietf.org/mailman/listinfo/ecrit=0D=0A>=0D=0A>=0D=0A= ------------------------------------------------------------------------=0D= =0A------------------------=0D=0A> This message is for the designated recip= ient only and may=0D=0A> contain privileged, proprietary, or otherwise priv= ate information.=0D=0A> If you have received it in error, please notify the= sender=0D=0A> immediately and delete the original. Any unauthorized use o= f=0D=0A> this email is prohibited.=0D=0A>=0D=0A----------------------------= --------------------------------------------=0D=0A------------------------=0D= =0A> [mf2]=0D=0A>=0D=0A> _______________________________________________=0D= =0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www.ietf.org/m= ailman/listinfo/ecrit=0D=0A>=20=0D=0A=0D=0A=0D=0A__________________________= _____________________=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttp= s://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A------------------------= ------------------------------------------------=0D=0A---------------------= ---=0D=0AThis message is for the designated recipient only and may=0D=0Acon= tain privileged, proprietary, or otherwise private information. =20=0D=0AIf= you have received it in error, please notify the sender=0D=0Aimmediately a= nd delete the original. Any unauthorized use of=0D=0Athis email is prohibi= ted.=0D=0A-----------------------------------------------------------------= -------=0D=0A------------------------=0D=0A[mf2]=0D=0A=0D=0A=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------------------------=0D=0A[mf2]=0D=0A=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 From sedge@qualcomm.com Thu Mar 26 04:25:09 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4933A681C for ; Thu, 26 Mar 2009 04:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.409 X-Spam-Level: X-Spam-Status: No, score=-105.409 tagged_above=-999 required=5 tests=[AWL=1.190, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jn-Q63keCriq for ; Thu, 26 Mar 2009 04:25:06 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 8C1213A69CE for ; Thu, 26 Mar 2009 04:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=sedge@qualcomm.com; q=dns/txt; s=qcdkim; t=1238066759; x=1269602759; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Edge,=20Stephen"=20|To:=20" Dawson,=20Martin"=20,=0D=0A=20 =20=20=20=20=20=20=20Spencer=20Dawkins=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20Richard =20Barnes=20,=20ECRIT=0D=0A=09|Date:=20Thu,=2026=20Mar=202009=2004:25:52=20-0700 |Subject:=20RE:=20[Ecrit]=20Reset=202:=20Framework=20text |Thread-Topic:=20[Ecrit]=20Reset=202:=20Framework=20text |Thread-Index:=20Acmts0SoRaQCrqEfSc2SQp74eLA9kAAIC+ggAAC+ 5jAAAJzf8AADsLrAAANVWyAAAw9/oAAA9UqQ|Message-ID:=20<1288E 74A73964940B132A0B9EA8D8ABC5658AA7E@NASANEXMB04.na.qualco mm.com>|References:=20<49CAD47B.8040400@bbn.com>=0D=0A =20=0D =0A=20<1288E74A73964940B132A0B9EA8D8ABC5658AA75@NASANEXMB 04.na.qualcomm.com>=0D=0A=20=0D=0A=20<1288E74A73964940 B132A0B9EA8D8ABC5658AA78@NASANEXMB04.na.qualcomm.com>=0D =0A=20=0D=0A=20<1288E74A73964940B132A0B9EA8D8ABC5658AA 7C@NASANEXMB04.na.qualcomm.com>=0D=0A=20|In-Reply-To: =20|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5564"=3B=20a=3D"16627627"; bh=s9G/TZhDCOB3U7EPSoIwW6NXNVX0wG5FtzdjGs6L5Fw=; b=FPJqGI5OHFAhe/j/iqev29l53ZKUNe1HgPBXc3hWS1lOijuvirsrucaY QpVWxNFONHNmdomK6zJ2KhjN5am45BKXhHMfmFIs4WO3IerSZk/CLYE4L f3aivpqZVvCioO1V8E/r/Lzhk7V38puhME6hevKNFdDEM7BBfRvmQkHse E=; X-IronPort-AV: E=McAfee;i="5300,2777,5564"; a="16627627" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Mar 2009 04:25:58 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2QBPwn7001174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Mar 2009 04:25:58 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2QBPtD5021486 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 Mar 2009 04:25:55 -0700 Received: from NASANEXMB04.na.qualcomm.com ([129.46.52.82]) by nasanexhub04.na.qualcomm.com ([129.46.134.222]) with mapi; Thu, 26 Mar 2009 04:25:55 -0700 From: "Edge, Stephen" To: "Dawson, Martin" , Spencer Dawkins , Richard Barnes , ECRIT Date: Thu, 26 Mar 2009 04:25:52 -0700 Thread-Topic: [Ecrit] Reset 2: Framework text Thread-Index: Acmts0SoRaQCrqEfSc2SQp74eLA9kAAIC+ggAAC+5jAAAJzf8AADsLrAAANVWyAAAw9/oAAA9UqQ Message-ID: <1288E74A73964940B132A0B9EA8D8ABC5658AA7E@NASANEXMB04.na.qualcomm.com> References: <49CAD47B.8040400@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC5658AA75@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5658AA78@NASANEXMB04.na.qualcomm.com> <1288E74A73964940B132A0B9EA8D8ABC5658AA7C@NASANEXMB04.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Ecrit] Reset 2: Framework text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 11:25:09 -0000 And I've discussed and expressed my view too - the new version is clearer a= nd more correct. That's why more discussion and other views are needed. Kind Regards Stephen -----Original Message----- From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20 Sent: Thursday, March 26, 2009 3:55 AM To: Edge, Stephen; Spencer Dawkins; Richard Barnes; ECRIT Subject: RE: [Ecrit] Reset 2: Framework text I was discussing it? I've expressed my view. The original is clearer and more correct. Cheers, Martin -----Original Message----- From: Edge, Stephen [mailto:sedge@qualcomm.com]=20 Sent: Thursday, 26 March 2009 8:39 PM To: Dawson, Martin; Spencer Dawkins; Richard Barnes; ECRIT Subject: RE: [Ecrit] Reset 2: Framework text This means that about 95% of the wording could already be acceptable and that about 5% needs more discussion. Is that too optimistic? If not, further views on the remaining 5% seem needed. -----Original Message----- From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20 Sent: Thursday, March 26, 2009 12:52 AM To: Edge, Stephen; Spencer Dawkins; Richard Barnes; ECRIT Subject: RE: [Ecrit] Reset 2: Framework text No. I believe the original is clearer and more correct. Cheers, Martin -----Original Message----- From: Edge, Stephen [mailto:sedge@qualcomm.com]=20 Sent: Thursday, 26 March 2009 5:37 PM To: Dawson, Martin; Spencer Dawkins; Richard Barnes; ECRIT Subject: RE: [Ecrit] Reset 2: Framework text Well it you want economy, the "can be and are" could be changed to just "can be" - there are plenty of "can be"s already in both drafts. But I think the wording below is more clear and only a couple of words longer. Kind Regards Stephen -----Original Message----- From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20 Sent: Wednesday, March 25, 2009 10:50 PM To: Edge, Stephen; Spencer Dawkins; Richard Barnes; ECRIT Subject: RE: [Ecrit] Reset 2: Framework text These additions were implied in the original text and are redundant. They only serve to convey some significance that isn't intended. I prefer the clarity and economy of Richard's original. Cheers, Martin -----Original Message----- From: Edge, Stephen [mailto:sedge@qualcomm.com]=20 Sent: Thursday, 26 March 2009 4:40 PM To: Spencer Dawkins; Dawson, Martin; Richard Barnes; ECRIT Subject: RE: [Ecrit] Reset 2: Framework text I agree this may be heading in a mutually agreeable direction. But I have the following suggested changes. I am using a "**" to indicate the changes. This document focuses on the case in which all three steps in the emergency calling process -- location configuration, call routing, and call placement - **can be and** are performed by the calling endpoint, with the endpoint's Access Service Provider supporting the process by providing location information. Calls **in this case** may be routed via an application-layer Communications Service Provider (e.g., a Voice Service Provider), but need not be. The underlying protocols can also be used to support other models in which parts of the process are delegated to the Communications Service Provider. This document does not address in detail either these models or interoperability issues between them and the model described here. The "can be" above automatically removes scenarios that cannot be supported (of course) without the need to elaborate on what these are - or even (for those with some views) whether they exist. The "in this case" applies the same restriction to CSP routing. Kind Regards Stephen -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: Wednesday, March 25, 2009 6:36 PM To: Dawson, Martin; Richard Barnes; ECRIT Subject: Re: [Ecrit] Reset 2: Framework text This sounds more like the discussion in the room than previous versions, FWIW... Spencer > +1 - I do like this better than anything else so far proposed. > > Hopefully it can't be misrepresented - so we aren't dealing with an > "overcharge" button... :) > > Cheers, > Martin > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Richard Barnes > Sent: Thursday, 26 March 2009 12:04 PM > To: ECRIT > Subject: [Ecrit] Reset 2: Framework text > > Proposal (trying to be more concrete): > > This document focuses on the case in which all three steps in the > emergency calling process -- location configuration, call routing, and > call placement -- are performed by the calling endpoint, with the > endpoint's Access Service Provider supporting the process by providing > location information. Calls may be routed via an application-layer > Communications Service Provider (e.g., a Voice Service Provider), but > need not be. The underlying protocols can also be used to support other > > models in which parts of the process are delegated to the Communications > > Service Provider. This document does not address in detail either these > > models or interoperability issues between them and the model described > here. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.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://www.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 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. =20 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. =20 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] From bs7652@att.com Thu Mar 26 08:21:47 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46CBA3A6AC3 for ; Thu, 26 Mar 2009 08:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.022 X-Spam-Level: X-Spam-Status: No, score=-106.022 tagged_above=-999 required=5 tests=[AWL=0.577, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkE1sxpH7ovK for ; Thu, 26 Mar 2009 08:21:46 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 0D9203A6B4F for ; Thu, 26 Mar 2009 08:21:46 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: bs7652@att.com X-Msg-Ref: server-12.tower-161.messagelabs.com!1238080957!32994091!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 21220 invoked from network); 26 Mar 2009 15:22:38 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-12.tower-161.messagelabs.com with AES256-SHA encrypted SMTP; 26 Mar 2009 15:22:38 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n2QFMa9n020197; Thu, 26 Mar 2009 11:22:37 -0400 Received: from 01GAF5142010622.AD.BLS.COM (01GAF5142010622.ad.bls.com [139.76.131.83]) by mlph073.enaf.sfdc.sbc.com (8.14.3/8.14.3) with SMTP id n2QFMUSo020056; Thu, 26 Mar 2009 11:22:31 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 26 Mar 2009 11:22:30 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 26 Mar 2009 11:22:30 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.3168 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Mar 2009 11:22:28 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0D880B65@crexc41p> In-Reply-To: <1288E74A73964940B132A0B9EA8D8ABC5658AA75@NASANEXMB04.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Reset 2: Framework text thread-index: Acmts0SoRaQCrqEfSc2SQp74eLA9kAAIC+ggABQhbZA= References: <49CAD47B.8040400@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC5658AA75@NASANEXMB04.na.qualcomm.com> From: "Stark, Barbara" To: "Edge, Stephen" , "Spencer Dawkins" , "Dawson, Martin" , "Richard Barnes" , "ECRIT" X-OriginalArrivalTime: 26 Mar 2009 15:22:30.0287 (UTC) FILETIME=[ADB1C9F0:01C9AE26] Subject: Re: [Ecrit] Reset 2: Framework text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 15:21:47 -0000 I'm fine with Stephen's proposed wording. The main thing I want to avoid is any suggestion that the IETF, in any way, has the authority to impose this document on any entity. Statements that try to say where or in which cases this document cannot be imposed, suggest that such imposition could occur -- which is why I want to avoid such statements. The newest wording from Richard tells me about what case this document was designed to be able to handle, without suggesting that it can or must be imposed in that case (or not imposed in cases that differ from the one described). That makes me happy. Descriptions that help me understand what use case / model that the editors had in mind are generally useful in understanding why the requirements are what they are. Therefore, such descriptions are a positive addition. That, too, makes me happy. The revisions that Stephen proposes do not alter my reading of what the paragraph says. It's obvious to me that endpoints that cannot perform the steps in the doc, will not perform the steps; but I don't object to saying that, if it helps us achieve consensus. I'm still happy. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Edge, Stephen Sent: Thursday, March 26, 2009 1:40 AM To: Spencer Dawkins; Dawson, Martin; Richard Barnes; ECRIT Subject: Re: [Ecrit] Reset 2: Framework text I agree this may be heading in a mutually agreeable direction. But I have the following suggested changes. I am using a "**" to indicate the changes. This document focuses on the case in which all three steps in the emergency calling process -- location configuration, call routing, and call placement - **can be and** are performed by the calling endpoint, with the endpoint's Access Service Provider supporting the process by providing location information. Calls **in this case** may be routed via an application-layer Communications Service Provider (e.g., a Voice Service Provider), but need not be. The underlying protocols can also be used to support other models in which parts of the process are delegated to the Communications Service Provider. This document does not address in detail either these models or interoperability issues between them and the model described here. The "can be" above automatically removes scenarios that cannot be supported (of course) without the need to elaborate on what these are - or even (for those with some views) whether they exist. The "in this case" applies the same restriction to CSP routing. Kind Regards Stephen -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: Wednesday, March 25, 2009 6:36 PM To: Dawson, Martin; Richard Barnes; ECRIT Subject: Re: [Ecrit] Reset 2: Framework text This sounds more like the discussion in the room than previous versions, FWIW... Spencer > +1 - I do like this better than anything else so far proposed. > > Hopefully it can't be misrepresented - so we aren't dealing with an > "overcharge" button... :) > > Cheers, > Martin > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Richard Barnes > Sent: Thursday, 26 March 2009 12:04 PM > To: ECRIT > Subject: [Ecrit] Reset 2: Framework text > > Proposal (trying to be more concrete): > > This document focuses on the case in which all three steps in the > emergency calling process -- location configuration, call routing, and > call placement -- are performed by the calling endpoint, with the > endpoint's Access Service Provider supporting the process by providing > location information. Calls may be routed via an application-layer > Communications Service Provider (e.g., a Voice Service Provider), but > need not be. The underlying protocols can also be used to support other > > models in which parts of the process are delegated to the Communications > > Service Provider. This document does not address in detail either these > > models or interoperability issues between them and the model described > here. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.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://www.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA622 From br@brianrosen.net Thu Mar 26 08:33:47 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD8E53A69DE for ; Thu, 26 Mar 2009 08:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOuzFh8ONsil for ; Thu, 26 Mar 2009 08:33:46 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 9BB973A681C for ; Thu, 26 Mar 2009 08:33:46 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LmrbA-0004J1-0Y; Thu, 26 Mar 2009 10:34:29 -0500 From: "Brian Rosen" To: "'Stark, Barbara'" , "'Edge, Stephen'" , "'Spencer Dawkins'" , "'Dawson, Martin'" , "'Richard Barnes'" , "'ECRIT'" References: <49CAD47B.8040400@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC5658AA75@NASANEXMB04.na.qualcomm.com> <7582BC68E4994F4ABF0BD4723975C3FA0D880B65@crexc41p> In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0D880B65@crexc41p> Date: Thu, 26 Mar 2009 11:34:31 -0400 Message-ID: <016201c9ae28$5f10a120$1d31e360$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acmts0SoRaQCrqEfSc2SQp74eLA9kAAIC+ggABQhbZAAAQtBIA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Reset 2: Framework text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 15:33:47 -0000 If this change is all we need to do to progress the document, then I am okay with Stephen's addition. If there are no more objections, I will release a rev ASAP. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Stark, Barbara Sent: Thursday, March 26, 2009 11:22 AM To: Edge, Stephen; Spencer Dawkins; Dawson, Martin; Richard Barnes; ECRIT Subject: Re: [Ecrit] Reset 2: Framework text I'm fine with Stephen's proposed wording. The main thing I want to avoid is any suggestion that the IETF, in any way, has the authority to impose this document on any entity. Statements that try to say where or in which cases this document cannot be imposed, suggest that such imposition could occur -- which is why I want to avoid such statements. The newest wording from Richard tells me about what case this document was designed to be able to handle, without suggesting that it can or must be imposed in that case (or not imposed in cases that differ from the one described). That makes me happy. Descriptions that help me understand what use case / model that the editors had in mind are generally useful in understanding why the requirements are what they are. Therefore, such descriptions are a positive addition. That, too, makes me happy. The revisions that Stephen proposes do not alter my reading of what the paragraph says. It's obvious to me that endpoints that cannot perform the steps in the doc, will not perform the steps; but I don't object to saying that, if it helps us achieve consensus. I'm still happy. Barbara -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Edge, Stephen Sent: Thursday, March 26, 2009 1:40 AM To: Spencer Dawkins; Dawson, Martin; Richard Barnes; ECRIT Subject: Re: [Ecrit] Reset 2: Framework text I agree this may be heading in a mutually agreeable direction. But I have the following suggested changes. I am using a "**" to indicate the changes. This document focuses on the case in which all three steps in the emergency calling process -- location configuration, call routing, and call placement - **can be and** are performed by the calling endpoint, with the endpoint's Access Service Provider supporting the process by providing location information. Calls **in this case** may be routed via an application-layer Communications Service Provider (e.g., a Voice Service Provider), but need not be. The underlying protocols can also be used to support other models in which parts of the process are delegated to the Communications Service Provider. This document does not address in detail either these models or interoperability issues between them and the model described here. The "can be" above automatically removes scenarios that cannot be supported (of course) without the need to elaborate on what these are - or even (for those with some views) whether they exist. The "in this case" applies the same restriction to CSP routing. Kind Regards Stephen -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Spencer Dawkins Sent: Wednesday, March 25, 2009 6:36 PM To: Dawson, Martin; Richard Barnes; ECRIT Subject: Re: [Ecrit] Reset 2: Framework text This sounds more like the discussion in the room than previous versions, FWIW... Spencer > +1 - I do like this better than anything else so far proposed. > > Hopefully it can't be misrepresented - so we aren't dealing with an > "overcharge" button... :) > > Cheers, > Martin > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Richard Barnes > Sent: Thursday, 26 March 2009 12:04 PM > To: ECRIT > Subject: [Ecrit] Reset 2: Framework text > > Proposal (trying to be more concrete): > > This document focuses on the case in which all three steps in the > emergency calling process -- location configuration, call routing, and > call placement -- are performed by the calling endpoint, with the > endpoint's Access Service Provider supporting the process by providing > location information. Calls may be routed via an application-layer > Communications Service Provider (e.g., a Voice Service Provider), but > need not be. The underlying protocols can also be used to support other > > models in which parts of the process are delegated to the Communications > > Service Provider. This document does not address in detail either these > > models or interoperability issues between them and the model described > here. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.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://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From drage@alcatel-lucent.com Thu Mar 26 09:37:23 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80B4828C17A for ; Thu, 26 Mar 2009 09:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdhUp05PaG70 for ; Thu, 26 Mar 2009 09:37:22 -0700 (PDT) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id F096628C178 for ; Thu, 26 Mar 2009 09:37:21 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2QGb8fD023627 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 Mar 2009 17:37:09 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 26 Mar 2009 17:37:07 +0100 From: "DRAGE, Keith (Keith)" To: Brian Rosen , "'Stark, Barbara'" , "'Edge, Stephen'" , "'Spencer Dawkins'" , "'Dawson, Martin'" , "'Richard Barnes'" , "'ECRIT'" Date: Thu, 26 Mar 2009 17:37:05 +0100 Thread-Topic: [Ecrit] Reset 2: Framework text Thread-Index: Acmts0SoRaQCrqEfSc2SQp74eLA9kAAIC+ggABQhbZAAAQtBIAACNtwQ Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6757BE8AE@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <49CAD47B.8040400@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC5658AA75@NASANEXMB04.na.qualcomm.com> <7582BC68E4994F4ABF0BD4723975C3FA0D880B65@crexc41p> <016201c9ae28$5f10a120$1d31e360$@net> In-Reply-To: <016201c9ae28$5f10a120$1d31e360$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [Ecrit] Reset 2: Framework text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 16:37:23 -0000 Do as you have said. Keith=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Brian Rosen > Sent: Thursday, March 26, 2009 3:35 PM > To: 'Stark, Barbara'; 'Edge, Stephen'; 'Spencer Dawkins';=20 > 'Dawson, Martin'; 'Richard Barnes'; 'ECRIT' > Subject: Re: [Ecrit] Reset 2: Framework text >=20 > If this change is all we need to do to progress the document,=20 > then I am okay with Stephen's addition. >=20 > If there are no more objections, I will release a rev ASAP. >=20 > Brian >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Stark, Barbara > Sent: Thursday, March 26, 2009 11:22 AM > To: Edge, Stephen; Spencer Dawkins; Dawson, Martin; Richard=20 > Barnes; ECRIT > Subject: Re: [Ecrit] Reset 2: Framework text >=20 > I'm fine with Stephen's proposed wording. >=20 > The main thing I want to avoid is any suggestion that the=20 > IETF, in any way, has the authority to impose this document=20 > on any entity. Statements that try to say where or in which=20 > cases this document cannot be imposed, suggest that such=20 > imposition could occur -- which is why I want to avoid such=20 > statements. >=20 > The newest wording from Richard tells me about what case this=20 > document was designed to be able to handle, without=20 > suggesting that it can or must be imposed in that case (or=20 > not imposed in cases that differ from the one described).=20 > That makes me happy. >=20 > Descriptions that help me understand what use case / model=20 > that the editors had in mind are generally useful in=20 > understanding why the requirements are what they are.=20 > Therefore, such descriptions are a positive addition. That,=20 > too, makes me happy. >=20 > The revisions that Stephen proposes do not alter my reading=20 > of what the paragraph says. It's obvious to me that endpoints=20 > that cannot perform the steps in the doc, will not perform=20 > the steps; but I don't object to saying that, if it helps us=20 > achieve consensus. I'm still happy. > Barbara >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Edge, Stephen > Sent: Thursday, March 26, 2009 1:40 AM > To: Spencer Dawkins; Dawson, Martin; Richard Barnes; ECRIT > Subject: Re: [Ecrit] Reset 2: Framework text >=20 > I agree this may be heading in a mutually agreeable=20 > direction. But I have the following suggested changes. I am=20 > using a "**" to indicate the changes. >=20 > This document focuses on the case in which all three steps in=20 > the emergency calling process -- location configuration, call=20 > routing, and call placement - **can be and** are performed by=20 > the calling endpoint, with the endpoint's Access Service=20 > Provider supporting the process by providing location=20 > information. Calls **in this case** may be routed via an=20 > application-layer Communications Service Provider (e.g., a=20 > Voice Service Provider), but need not be. The underlying=20 > protocols can also be used to support other models in which=20 > parts of the process are delegated to the Communications=20 > Service Provider. This document does not address in detail=20 > either these models or interoperability issues between them=20 > and the model described here. >=20 > The "can be" above automatically removes scenarios that=20 > cannot be supported (of course) without the need to elaborate=20 > on what these are - or even (for those with some views)=20 > whether they exist. The "in this case" applies the same=20 > restriction to CSP routing. >=20 > Kind Regards >=20 > Stephen > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Spencer Dawkins > Sent: Wednesday, March 25, 2009 6:36 PM > To: Dawson, Martin; Richard Barnes; ECRIT > Subject: Re: [Ecrit] Reset 2: Framework text >=20 > This sounds more like the discussion in the room than=20 > previous versions, >=20 > FWIW... >=20 > Spencer >=20 >=20 > > +1 - I do like this better than anything else so far proposed. > > > > Hopefully it can't be misrepresented - so we aren't dealing with an=20 > > "overcharge" button... :) > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On Behalf=20 > > Of Richard Barnes > > Sent: Thursday, 26 March 2009 12:04 PM > > To: ECRIT > > Subject: [Ecrit] Reset 2: Framework text > > > > Proposal (trying to be more concrete): > > > > This document focuses on the case in which all three steps in the=20 > > emergency calling process -- location configuration, call=20 > routing, and=20 > > call placement -- are performed by the calling endpoint, with the=20 > > endpoint's Access Service Provider supporting the process=20 > by providing=20 > > location information. Calls may be routed via an application-layer=20 > > Communications Service Provider (e.g., a Voice Service=20 > Provider), but=20 > > need not be. The underlying protocols can also be used to support > other > > > > models in which parts of the process are delegated to the > Communications > > > > Service Provider. This document does not address in detail either > these > > > > models or interoperability issues between them and the=20 > model described=20 > > here. > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > -------------------------------------------------------------- > ---------- > ------------------------ > > This message is for the designated recipient only and may contain=20 > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender=20 > immediately=20 > > and delete the original. Any unauthorized use of this email is=20 > > prohibited. > > > -------------------------------------------------------------- > ---------- > ------------------------ > > [mf2] > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.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. GA622 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From spencer@wonderhamster.org Thu Mar 26 09:49:44 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F53928B23E for ; Thu, 26 Mar 2009 09:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Zua4gG9-ZXQ for ; Thu, 26 Mar 2009 09:49:43 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 501D03A68E5 for ; Thu, 26 Mar 2009 09:49:43 -0700 (PDT) Received: from S73602b (dhcp-63fb.meeting.ietf.org [130.129.99.251]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1LmsmB19dY-000d1V; Thu, 26 Mar 2009 12:50:04 -0400 Message-ID: <20D564E916814D7787A5B82EEC109A79@china.huawei.com> From: "Spencer Dawkins" To: "DRAGE, Keith \(Keith\)" , "Brian Rosen" , "'Stark, Barbara'" , "'Edge, Stephen'" , "'Dawson, Martin'" , "'Richard Barnes'" , "'ECRIT'" References: <49CAD47B.8040400@bbn.com><1288E74A73964940B132A0B9EA8D8ABC5658AA75@NASANEXMB04.na.qualcomm.com><7582BC68E4994F4ABF0BD4723975C3FA0D880B65@crexc41p> <016201c9ae28$5f10a120$1d31e360$@net> <28B7C3AA2A7ABA4A841F11217ABE78D6757BE8AE@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Date: Thu, 26 Mar 2009 11:49:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX19CuwYYViA/K69uH6R4UPKfm6apQNGclOU8ZOm ZDr2oMd+DlkyBZXyw3RzThRnZYj8CnNnnY+7hU9SuG+E10QyI+ UoKXyhc1PKsarVeEF2SuEGcf1P6UR6BlreJd7YxPHQ= Subject: Re: [Ecrit] Reset 2: Framework text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 16:49:44 -0000 Agree... Spencer ----- Original Message ----- From: "DRAGE, Keith (Keith)" To: "Brian Rosen" ; "'Stark, Barbara'" ; "'Edge, Stephen'" ; "'Spencer Dawkins'" ; "'Dawson, Martin'" ; "'Richard Barnes'" ; "'ECRIT'" Sent: Thursday, March 26, 2009 11:37 AM Subject: RE: [Ecrit] Reset 2: Framework text Do as you have said. Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Brian Rosen > Sent: Thursday, March 26, 2009 3:35 PM > To: 'Stark, Barbara'; 'Edge, Stephen'; 'Spencer Dawkins'; > 'Dawson, Martin'; 'Richard Barnes'; 'ECRIT' > Subject: Re: [Ecrit] Reset 2: Framework text > > If this change is all we need to do to progress the document, > then I am okay with Stephen's addition. > > If there are no more objections, I will release a rev ASAP. > > Brian > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Stark, Barbara > Sent: Thursday, March 26, 2009 11:22 AM > To: Edge, Stephen; Spencer Dawkins; Dawson, Martin; Richard > Barnes; ECRIT > Subject: Re: [Ecrit] Reset 2: Framework text > > I'm fine with Stephen's proposed wording. > > The main thing I want to avoid is any suggestion that the > IETF, in any way, has the authority to impose this document > on any entity. Statements that try to say where or in which > cases this document cannot be imposed, suggest that such > imposition could occur -- which is why I want to avoid such > statements. > > The newest wording from Richard tells me about what case this > document was designed to be able to handle, without > suggesting that it can or must be imposed in that case (or > not imposed in cases that differ from the one described). > That makes me happy. > > Descriptions that help me understand what use case / model > that the editors had in mind are generally useful in > understanding why the requirements are what they are. > Therefore, such descriptions are a positive addition. That, > too, makes me happy. > > The revisions that Stephen proposes do not alter my reading > of what the paragraph says. It's obvious to me that endpoints > that cannot perform the steps in the doc, will not perform > the steps; but I don't object to saying that, if it helps us > achieve consensus. I'm still happy. > Barbara > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Edge, Stephen > Sent: Thursday, March 26, 2009 1:40 AM > To: Spencer Dawkins; Dawson, Martin; Richard Barnes; ECRIT > Subject: Re: [Ecrit] Reset 2: Framework text > > I agree this may be heading in a mutually agreeable > direction. But I have the following suggested changes. I am > using a "**" to indicate the changes. > > This document focuses on the case in which all three steps in > the emergency calling process -- location configuration, call > routing, and call placement - **can be and** are performed by > the calling endpoint, with the endpoint's Access Service > Provider supporting the process by providing location > information. Calls **in this case** may be routed via an > application-layer Communications Service Provider (e.g., a > Voice Service Provider), but need not be. The underlying > protocols can also be used to support other models in which > parts of the process are delegated to the Communications > Service Provider. This document does not address in detail > either these models or interoperability issues between them > and the model described here. > > The "can be" above automatically removes scenarios that > cannot be supported (of course) without the need to elaborate > on what these are - or even (for those with some views) > whether they exist. The "in this case" applies the same > restriction to CSP routing. > > Kind Regards > > Stephen > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > On Behalf Of Spencer Dawkins > Sent: Wednesday, March 25, 2009 6:36 PM > To: Dawson, Martin; Richard Barnes; ECRIT > Subject: Re: [Ecrit] Reset 2: Framework text > > This sounds more like the discussion in the room than > previous versions, > > FWIW... > > Spencer > > > > +1 - I do like this better than anything else so far proposed. > > > > Hopefully it can't be misrepresented - so we aren't dealing with an > > "overcharge" button... :) > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf > > Of Richard Barnes > > Sent: Thursday, 26 March 2009 12:04 PM > > To: ECRIT > > Subject: [Ecrit] Reset 2: Framework text > > > > Proposal (trying to be more concrete): > > > > This document focuses on the case in which all three steps in the > > emergency calling process -- location configuration, call > routing, and > > call placement -- are performed by the calling endpoint, with the > > endpoint's Access Service Provider supporting the process > by providing > > location information. Calls may be routed via an application-layer > > Communications Service Provider (e.g., a Voice Service > Provider), but > > need not be. The underlying protocols can also be used to support > other > > > > models in which parts of the process are delegated to the > Communications > > > > Service Provider. This document does not address in detail either > these > > > > models or interoperability issues between them and the > model described > > here. > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.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://www.ietf.org/mailman/listinfo/ecrit > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > ***** > > The information transmitted is intended only for the person > or entity to which it is addressed and may contain > confidential, proprietary, and/or privileged material. Any > review, retransmission, dissemination or other use of, or > taking of any action in reliance upon this information by > persons or entities other than the intended recipient is > prohibited. If you received this in error, please contact the > sender and delete the material from all computers. GA622 > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From randy@qualcomm.com Thu Mar 26 10:17:07 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 941B428C200 for ; Thu, 26 Mar 2009 10:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.813 X-Spam-Level: X-Spam-Status: No, score=-104.813 tagged_above=-999 required=5 tests=[AWL=1.786, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pv769NMbnzuw for ; Thu, 26 Mar 2009 10:17:06 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 8C87028C1FD for ; Thu, 26 Mar 2009 10:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1238087880; x=1269623880; h=message-id:in-reply-to:references:x-mailer: x-message-note:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-ironport-av; z=Message-ID:=20 |In-Reply-To:=20<7582BC68E4994F4ABF0BD4723975C3FA0D880B65 @crexc41p>|References:=20<49CAD47B.8040400@bbn.com> =0D=0A=20<1288E74A73964940B132A0B9EA8D8ABC5658AA75@NASANE XMB04.na.qualcomm.com>=0D=0A=20<7582BC68E4994F4ABF0BD4723 975C3FA0D880B65@crexc41p>|X-Mailer:=20Eudora=20for=20Mac =20OS=20X|X-message-Note:=20Warning:=20Outlook=20in=20use .=20=20Upgrade=20to=20Eudora:=20 |Date:=20Thu,=2026=20Mar=202009=2010:17:43=20-0700|To:=20 "Stark,=20Barbara"=20,=20"Edge,=20Stephen "=20,=0D=0A=20=20=20=20=20=20=20=20Sp encer=20Dawkins=20,=0D=0A=20 =20=20=20=20=20=20=20"Dawson,=20Martin"=0D=0A=09,=0D=0A=20=20=20=20=20=20=20=20Richard =20Barnes=20,=20ECRIT=0D=0A=09|From:=20Randall=20Gellens=20 |Subject:=20Re:=20[Ecrit]=20Reset=202:=20Framework=20text |MIME-Version:=201.0|Content-Type:=20text/plain=3B=20char set=3D"us-ascii"=3B=20format=3Dflowed|X-Random-Sig-Tag: =201.0b28|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,55 65"=3B=20a=3D"16636860"; bh=p4wtYwTOlbiHAfXB/HowE5ei9mPPkwIwsM8X2lODTkU=; b=UzMRcnRq5V8vu0j2lp1H/aX+XCAD1GMXmD0p8X+pjZ2KDtNHEVhkTL/J RsvjIY66cLqv8umV//CrQ8hJ8etKTSTodtNnr3VKvvc9YxwnL/f/n9ir7 ojd5CVwGVJfiArXBGulNvJggjSt0NWprUF+6gRyezUYfn6ghRbKNW13N7 c=; X-IronPort-AV: E=McAfee;i="5300,2777,5565"; a="16636860" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Mar 2009 10:18:00 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2QHHxNv008752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Mar 2009 10:17:59 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n2QHHxcH032578 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 Mar 2009 10:17:59 -0700 Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 26 Mar 2009 10:17:59 -0700 Received: from [67.99.198.91] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 26 Mar 2009 10:17:58 -0700 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0D880B65@crexc41p> References: <49CAD47B.8040400@bbn.com> <1288E74A73964940B132A0B9EA8D8ABC5658AA75@NASANEXMB04.na.qualcomm.com> <7582BC68E4994F4ABF0BD4723975C3FA0D880B65@crexc41p> X-Mailer: Eudora for Mac OS X X-message-Note: Warning: Outlook in use. Upgrade to Eudora: Date: Thu, 26 Mar 2009 10:17:43 -0700 To: "Stark, Barbara" , "Edge, Stephen" , Spencer Dawkins , "Dawson, Martin" , Richard Barnes , ECRIT From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 Subject: Re: [Ecrit] Reset 2: Framework text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 17:17:07 -0000 At 11:22 AM -0400 3/26/09, Barbara Stark wrote: > I'm fine with Stephen's proposed wording. > > The main thing I want to avoid is any suggestion that the IETF, in any > way, has the authority to impose this document on any entity. ... > Descriptions that help me understand what use case / model that the > editors had in mind are generally useful in understanding why the > requirements are what they are. Therefore, such descriptions are a > positive addition. That, too, makes me happy. I think Barbara has said it very well. Let's go with Stephen's proposed wording. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Nobody can be exactly like me. Even I have trouble doing it. --Tallulah Bankhead From RMarshall@telecomsys.com Thu Mar 26 15:53:26 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E4CE28C0ED for ; Thu, 26 Mar 2009 15:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7s-wD+wOK1V for ; Thu, 26 Mar 2009 15:53:25 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [206.173.41.176]) by core3.amsl.com (Postfix) with ESMTP id 4B8FD3A6B3D for ; Thu, 26 Mar 2009 15:53:25 -0700 (PDT) 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, 26 Mar 2009 15:54:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Mar 2009 15:51:27 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65750C648C2E@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Reset 2: Framework text Thread-Index: AcmuNtdoV8wsbCmTQqGpZOO2mfqQzAALm2AA References: <49CAD47B.8040400@bbn.com><1288E74A73964940B132A0B9EA8D8ABC5658AA75@NASANEXMB04.na.qualcomm.com><7582BC68E4994F4ABF0BD4723975C3FA0D880B65@crexc41p> From: "Roger Marshall" To: "Randall Gellens" , "Stark, Barbara" , "Edge, Stephen" , "Spencer Dawkins" , "Dawson, Martin" , "Richard Barnes" , "ECRIT" Subject: Re: [Ecrit] Reset 2: Framework text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2009 22:53:26 -0000 I'm also good with the Stephen worded version. -roger. > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Randall Gellens > Sent: Thursday, March 26, 2009 10:18 AM > To: Stark, Barbara; Edge, Stephen; Spencer Dawkins; Dawson,=20 > Martin; Richard Barnes; ECRIT > Subject: Re: [Ecrit] Reset 2: Framework text >=20 > At 11:22 AM -0400 3/26/09, Barbara Stark wrote: >=20 > > I'm fine with Stephen's proposed wording. > > > > The main thing I want to avoid is any suggestion that the IETF, in=20 > > any way, has the authority to impose this document on any entity. >=20 > ... >=20 > > Descriptions that help me understand what use case / model=20 > that the =20 > > editors had in mind are generally useful in understanding why the =20 > > requirements are what they are. Therefore, such descriptions are a =20 > > positive addition. That, too, makes me happy. >=20 > I think Barbara has said it very well. >=20 > Let's go with Stephen's proposed wording. >=20 > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for=20 > myself only > -------------- Randomly selected tag: --------------- Nobody=20 > can be exactly like me. Even I have trouble doing it. > --Tallulah Bankhead=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. From drage@alcatel-lucent.com Thu Mar 26 17:16:09 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53E6D28C0E7 for ; Thu, 26 Mar 2009 17:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gglTNyczybeL for ; Thu, 26 Mar 2009 17:16:08 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 2B9B13A67DA for ; Thu, 26 Mar 2009 17:16:07 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2R0GvYH020945 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 27 Mar 2009 01:16:58 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 27 Mar 2009 01:16:57 +0100 From: "DRAGE, Keith (Keith)" To: "'ECRIT'" Date: Fri, 27 Mar 2009 01:16:56 +0100 Thread-Topic: Comments on draft-ietf-ecrit-local-emergency-rph-namespace-03 Thread-Index: AcmucVZwqa8WZkvrRxGMXk2uwk8tnA== Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6757BE90B@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: [Ecrit] Comments on draft-ietf-ecrit-local-emergency-rph-namespace-03 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 00:16:09 -0000 Aside from some editorials, I have the following comments on the latest rev= ision of this document: 1) Remove the abbreviation RPH. It is never used alone and not a real abbre= viation associated with this header field. 2) Align the abstract and introduction text with RFC 5478. 3) Section 1: Within controlled environments, such as an IMS infrastructure or=20 Emergency Services network (ESInet), where misuse can be reduced to=20 a minimum because these types of networks have great controls in=20 place, this namespace can be to provide an explicit priority=20 indication that facilitates differing treatment of emergency SIP=20 messages according to local policy, or more likely, a contractual=20 agreement between the network organizations. This indication is=20 used to differentiate SIP requests, or dialogs, from other requests=20 or dialogs that do not have the need for priority treatment. I would suggest inserting the word "solely" before "to differentiate SIP re= quests". It is not used outside the scope of the Resource-Priority header f= ield. 4) Section 1: It can also be imagined that Voice Service Providers (VSP) directly=20 attached to an ESInet can have a trust relationship with the ESInet=20 such that within these networks, SIP requests (thereby the session=20 they establish) make use of this "esnet" namespace for appropriate=20 treatment. The use of the term VSP throughout the document gives the impression that t= his is only intended for voice emergency calls. It can be used on any SIP r= equest that relates to an emergency call. Can we preface this sentence with= "As an example" and check other usages in the document. 5) Section 1: Usage of the "esnet" namespace is to be defined in a future=20 document(s).=20 I think this prejudges what other standardisation is required. I do not bel= ieve another document is required and certainly we do not have one chartere= d. I would prefer to remove this sentence. If the solution is not this simp= le, then at least replace it with "Usage of the namespace is governed by ag= reements between domains, in accordance with the guidance already given in = RFC 4412" or something like this. 6) Section 2: This document updates the behaviors of the SIP Resource Priority=20 header, defined in [RFC4412], during the treatment options=20 surrounding this new "esnet" namespace only.=20 I think the use of the word "updates" here is a poor choice, as it does not= update RFC 4412, nor indeed does it really provide any additional normativ= e behaviour on the Resource-Priority header field. 7) Section 3.2: This section discusses preemption. I would prefer to just say:=20 "The namespace definition has to indicate whether the namespace is preempti= on or priority. It is envisages that use of this namespace is primarily pri= ority, however in accordance with the current practice of some regulatory b= odies, preemption of emergency calls is permitted by this namespace definit= ion. Such preemption is not defined further in this document." I will send the editorials directly to James. regards Keith= From drage@alcatel-lucent.com Thu Mar 26 22:10:26 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 742273A6C14 for ; Thu, 26 Mar 2009 22:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.929 X-Spam-Level: X-Spam-Status: No, score=-5.929 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqTpbRhwDZXo for ; Thu, 26 Mar 2009 22:10:23 -0700 (PDT) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id 1BFC33A6C21 for ; Thu, 26 Mar 2009 22:10:20 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n2R5B7Oa032141 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Mar 2009 06:11:08 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 27 Mar 2009 06:11:07 +0100 From: "DRAGE, Keith (Keith)" To: Brian Rosen , "'Karl Heinz Wolf'" , "'Spencer Dawkins'" Date: Fri, 27 Mar 2009 06:11:05 +0100 Thread-Topic: [Ecrit] Comments on phonebcp-07 Thread-Index: Acmj8xkVfHA7vjwyRmOrNxU9Xv0hiAAAPm6QAqmCDPA= Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6757BE921@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <53275.24.154.127.233.1235780998.squirrel@www.brianrosen.net> <00e901c99c4e$ee6bbcb0$cb433610$@net> <00b701c9a3ef$05817050$108450f0$@net> <000001c9a3f4$3a48b140$aeda13c0$@net> In-Reply-To: <000001c9a3f4$3a48b140$aeda13c0$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Comments on phonebcp-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 05:10:26 -0000 I would note that the text in RFC 5031 leads one to the belief that if a su= bservice is defined, use of the service above the subservice is equally val= id and should result in delivery to some valid answer point. This would app= ear to apply to both counselling and sos. So it would appear to me that any usage of a subservice implies a requireme= nt to also route the top level service to some point where it can be dealt = with. regards Keith=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Brian Rosen > Sent: Friday, March 13, 2009 3:56 PM > To: 'Karl Heinz Wolf'; 'Spencer Dawkins' > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Comments on phonebcp-07 >=20 > As a practical matter, nearly every country already does=20 > that, because of the 1-1-2 action in mobile phones, so I=20 > think it's a practical answer. >=20 > Brian >=20 > -----Original Message----- > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > Sent: Friday, March 13, 2009 11:48 AM > To: Spencer Dawkins > Cc: Brian Rosen; ecrit@ietf.org > Subject: Re: [Ecrit] Comments on phonebcp-07 >=20 > I just noticed that Spencer's first mail was off-list and so=20 > was my reply. >=20 > My question there was: do you think every country having=20 > subservices could agree on picking one service as a default=20 > sos service? > I certainly agree that having a urn:service:sos would make=20 > things easier. >=20 > karl heinz >=20 > On Fri, Mar 13, 2009 at 11:35 AM, Spencer Dawkins=20 > wrote: > > I agree - the alternative, as Karl Heinz suggests, is to=20 > pick another=20 > > URN, which might ALSO be missing, and/or just start trying=20 > services at > random... > > > > Thanks, > > > > Spencer > > > > ----- Original Message ----- From: "Brian Rosen" > > To: "'Karl Heinz Wolf'" > > Cc: > > Sent: Friday, March 13, 2009 10:18 AM > > Subject: Re: [Ecrit] Comments on phonebcp-07 > > > > > > I think we're better off saying (if it isn't already in LoST), that=20 > > urn:service:sos MUST be specified (locally) and lead somewhere > appropriate. > > Then a missing service goes to urn:service:sos always. > > > > Brian > > > > -----Original Message----- > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > Sent: Friday, March 13, 2009 10:47 AM > > To: Brian Rosen > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] Comments on phonebcp-07 > > > > Thank you for putting back ED-6. > > > > I thought about the configuration of the home emergency=20 > number and how=20 > > to map the home emergency number to the visited one. In=20 > case the same=20 > > emergency (sub-)services exist in both the home and visited=20 > country,=20 > > there shouldn't be a problem. But what about the following=20 > situation: > > the user dials his home dialstring for sos.physician, but=20 > this service=20 > > does not exist in the visited country. > > Or the user just has a single home dial string for sos, but=20 > there is=20 > > no such general emergency service in the visited country,=20 > but all the=20 > > subservices. Where should the call be connected to? > > > > Would it make sense to have a rule on this like: > > > > Home emergency dial strings should be mapped to the corresponding=20 > > emergency service in the visited country. In case there is=20 > not such a=20 > > service in the visited country, the mapping for=20 > urn:service:sos should=20 > > be used to connect the call. If there is no such general emergency=20 > > service available, urn:service:sos.police should be tried,=20 > followed by=20 > > other randomly selected services in case of failure. > > ? > > > > Karl Heinz > > > > > > On Tue, Mar 3, 2009 at 6:25 PM, Brian Rosen=20 > wrote: > >> > >> Hmmmm. That works. Either I forgot about it, or we never actually=20 > >> discussed it. > >> > >> I'll put it back and put some text in -framework about it: > >> You MAY provision home country > >> The device could discover home dial strings knowing home=20 > country via > LoST. > >> > >> Sorry about that. ED-6 will come back. > >> > >> Brian > >> > >> -----Original Message----- > >> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > >> Sent: Tuesday, March 03, 2009 4:59 PM > >> To: Brian Rosen > >> Cc: ecrit@ietf.org > >> Subject: Re: [Ecrit] Comments on phonebcp-07 > >> > >> Brian, just one comment on the now deleted ED-6: > >> > >>> 1. ED-6 vs ED-9 is the difference between discovery with a home=20 > >>> country code and provisioning of actual dial string. We haven't=20 > >>> described discovery, so I'll have to delete ED-6 > >>> > >> > >> I thought LoST would be the way to discover dial strings=20 > for the home=20 > >> country. A mapping request with just the home country as location=20 > >> information would be the discovery, wouldn't it? > >> > >> karl heinz > >> > >> > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From br@brianrosen.net Fri Mar 27 10:14:46 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61EA828C140 for ; Fri, 27 Mar 2009 10:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpx+brHC7IW0 for ; Fri, 27 Mar 2009 10:14:45 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 229453A6C3F for ; Fri, 27 Mar 2009 10:14:45 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LnFeT-00068f-CL; Fri, 27 Mar 2009 12:15:31 -0500 From: "Brian Rosen" To: "'Elwell, John'" , References: <53275.24.154.127.233.1235780998.squirrel@www.brianrosen.net> <0D5F89FAC29E2C41B98A6A762007F5D0019841D0@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0019841D0@GBNTHT12009MSX.gb002.siemens.net> Date: Fri, 27 Mar 2009 13:15:34 -0400 Message-ID: <016901c9aeff$a6835c50$f38a14f0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmZO7wrCJSl+7uKRxu/R6D9XpQw8QCzHAqABIgnjfA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Comments on phonebcp-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 17:14:46 -0000 Finishing this up > 5. I'll downgrade the sip-sips reference to Informational. > Could refer to > the 3.1 text. [JRE] It still doesn't make sense to me for a normative statement to refer to 3.1 of sip-sips when that section does not contain any normative language. All we are doing is saying that TLS MUST be used, and this doesn't seem to require any reference to sip-sips. So I would suggest removing the reference to sip-sips entirely.
I'll remove the reference to sip-sips In addition (apologies if this has already been discussed), by mandating TLS we effectively are saying that you can't make an emergency call if you can't use TLS! I doubt if that is really the intent. Should it not say something like "An end device MUST use TLS, if available, when attempting to establish an emergency call."?
It's been discussed, and look at the very next requirement > > 6. Don't know how to define a requirement which assumes the > presence of a > B2BUA. I propose to leave as is [JRE] Let me put it a different way. I don't think this is necessarily achievable by the end device (UA). If the registrar does not support GRUU, the UA may not have any means of obtaining a globally routable contact URI. Perhaps the second "MUST" should be "SHOULD", with some rationale why it might not always be possible. In any case, a locally routable contact URI is acceptable if a B2BUA maps it to a globally routable contact URI.
see below > > 7. I'll fix the text for MUST and delete "normal" > > 8. An actual problem. Calls out for a way to mark the Route as the > emergency route. Two solutions were discussed. One is to use the sos > parameter. The other is to say that the Geolocation header > must not have > a "used for routing" parameter unless the LoST routing was > completed. I > think I will recommend the second. [JRE] OK - but I didn't see this in 08.
-08 says: If a device understands the SIP Location Conveyance extension and supports LoST [RFC5222], the Geolocation "used-for-routing" header parameter MUST be added to the corresponding URI in the Geolocation header. If the device is unable to obtain a PSAP URI for any reason it MUST NOT include "used-for-routing" on a Geolocation URI, so that downstream entities know that LoST routing has not been completed. > 10. If the device is no longer registered, then the Contact can't be > valid. I can insert text to this effect. [JRE] I didn't see this in 08.
It will now read: A Contact header MUST be present which MUST be globally routable, for example a GRUU [I-D.ietf-sip-gruu], and be valid for several minutes following the termination of the call, provided that the UAC remains registered with the same registrar, to permit an immediate call-back to the specific device which placed the emergency call. It is acceptable if the UAC inserts a locally routable URI and a subsequent B2BUA maps that to a globally routable URI. > > 11. Tried to make the requirement minimal (no Replaces, for > example), but > I think you need referred by. I'll think some more about > that. I'll add > text that says device implementers should consider the effect > of emergency > call transfer on a stressed user; generally, the device should do the > transfer. [JRE] I didn't see anything in 08. For a device, the requirement is to support receipt of REFER with method=INVITE, I believe, and to handle the Referred-By header field in such a request. If so, this should be stated clearly.
Rewrote to: ED-67 During the course of an emergency call, devices and proxies MUST support REFER transactions with method=INVITE and the Referred-by: header in that transaction. > > 12. Don't understand the problem. The situation described is > AFTER a call > session is established, but before it is terminated. LoST > resolution is > complete. [JRE] What I meant is how can the UA determine that the new call originated at a PSAP. If the device did a LoST query, then a From or PAI URI matching the result of the LoST query might be one mechanism. But if the device didn't do a LoST query, or if the call comes from a different PSAP (e.g., because the original call was forwarded or transferred) that might not help.
At this time, I think the domain idea is all we have to work with. As you know, there is a draft that proposes new mechanisms to mark call backs. If I just qualify the current text that this won't always work, and future work will address this, is that okay? Suggested text: Recognizing a call back from the domain of the PSAP will not always work, and further standardization will be required to give the UA the ability to recognize a call back > > 13. a) If a call arrives while an emergency call is up, we > don't want a > call waiting tone, alert or other prompt, we don't want the > emergency call > put on hold and we don't want the incoming call to be answered. [JRE] Thanks for the clarification, but this does not alter the fact that call waiting is not an outgoing call feature. It would be better to say what we mean, e.g., MUST disable features that will interrupt an ongoing emergency call, such as call waiting...
Rewrote to: User Agents and proxies MUST disable features that will interrupt an ongoing emergency call, such as: > b) Although some features can be applied to incoming calls, > they are also > applicable to outgoing calls, which is what we want here; we > don't want > the emergency call put on hold, put into a client-side conference, ... [JRE] This too could be covered by the form of words I suggested above.
Reworded to: The User Agent and Proxies MUST disable call features which would interfere with the ability of call backs from the PSAP to be completed such as: > c) I'll add a definition of "flash hold" to -framework. Of > course "flash > hold" does involve a proxy, where normal SIP hold does not. > You don't > want Hold (that is, disconnect the media to or from the PSAP). [JRE] Flash hold as you now describe it in the framework is a PSTN feature, so how does it relate to a SIP device?
How 'bout I just delete any reference to "flash" and just say "Hold"? > > 14. Call waiting on an incoming call is the same as on an > outgoing call: > you don't alert to another call, you don't offer hold and switch. The > PSAP callback stays up. Yes, 486 or voicemail is > appropriate. Indeed the > recognition of the callback is difficult, and I hope we will > charter an > item. I think the domain recognition is a reasonable first > step, and I > recognize it won't always work. When it doesn't, callback > won't get the > feature suppression. Not a good thing, but not fatal. [JRE] That is one way of interpreting the text of ED-72, but the way I interpreted it is this. If I am engaged in a (non-PSAP) call and a callback from a PSAP arrives, the callback is not allowed to use call waiting to interrupt the existing call. That seems wrong. So there are two situations: i) during an ordinary call when a callback from a PSAP arrives, and ii) during a call that is a callback from a PSAP (which really should be treated no differently from a call to a PSAP).
In the rewording, I used " interfere with the ability of call backs from the PSAP to be completed". I have also deleted "Call Waiting" from the list, so I think the meaning is now clear. > > 15. I may be misinterpreting your concern, but I think the > B2BUA that maps > Contact doesn't alter the caller's domain as seen by the > called party. If > the call arrives directed TO the Contact or AoR given out in > the original > emergency call, and it's FROM the same domain that answered > the call, then > it should be treated as a call back. [JRE] I didn't express my concern correctly. How does the end device determine the domain of the PSAP that answers the call? We don't yet have response identity defined in SIP. We could get the PSAP to send a request (e.g., UPDATE) in the reverse direction and use PAI in that request or RFC 4916 to change the From URI.
Aha. I'll add a reference to 4916: [RFC4916] may be used by the PSAP to inform the UA of the domain of the PSAP. > > > 17. The response certainly should be using TLS, but it might > not work. > I'll add text. [JRE] "The test response SHOULD be protected with TLS. If the body cannot be protected, the location SHOULD NOT be included in the response.." Although the first hop from the responding node might be TLS, it is not known that all upstream hops are TLS.
What do you want me to do? S/MIME isn't a practical answer. From john.elwell@siemens-enterprise.com Fri Mar 27 14:16:21 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A64E3A6C68 for ; Fri, 27 Mar 2009 14:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41ARbr1hX9Pc for ; Fri, 27 Mar 2009 14:16:20 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id D380E3A6C49 for ; Fri, 27 Mar 2009 14:16:19 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KH600L7PODMIY@siemenscomms.co.uk> for ecrit@ietf.org; Fri, 27 Mar 2009 21:15:22 +0000 (GMT) Date: Fri, 27 Mar 2009 21:15:17 +0000 From: "Elwell, John" In-reply-to: <016901c9aeff$a6835c50$f38a14f0$@net> To: Brian Rosen , ecrit@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001B50EB8@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Ecrit] Comments on phonebcp-07 Thread-Index: AcmZO7wrCJSl+7uKRxu/R6D9XpQw8QCzHAqABIgnjfAAO2jUoA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <53275.24.154.127.233.1235780998.squirrel@www.brianrosen.net> <0D5F89FAC29E2C41B98A6A762007F5D0019841D0@GBNTHT12009MSX.gb002.siemens.net> <016901c9aeff$a6835c50$f38a14f0$@net> Subject: Re: [Ecrit] Comments on phonebcp-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 21:16:21 -0000 Brian, Thanks for addressing my concerns. Just a couple of outstanding points below. > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: 27 March 2009 17:16 > To: Elwell, John; ecrit@ietf.org > Subject: RE: [Ecrit] Comments on phonebcp-07 >=20 > Finishing this up >=20 > > 5. I'll downgrade the sip-sips reference to Informational. =20 > > Could refer to > > the 3.1 text. > [JRE] It still doesn't make sense to me for a normative statement to > refer to 3.1 of sip-sips when that section does not contain any > normative language. All we are doing is saying that TLS MUST be used, > and this doesn't seem to require any reference to sip-sips. So I would > suggest removing the reference to sip-sips entirely. >
I'll remove the reference to sip-sips [JRE] OK >=20 > In addition (apologies if this has already been discussed),=20 > by mandating > TLS we effectively are saying that you can't make an emergency call if > you can't use TLS! I doubt if that is really the intent. Should it not > say something like "An end device MUST use TLS, if available, when > attempting to establish an emergency call."? >
It's been discussed, and look at the very next requirement [JRE] But the ED-61 talks about only the case where TLS fails, rather than the case where TLS is simply not available. I guess it is a question of interpretation of words, but if you can't find a port for TLS, you can't even attempt it. So instead of "fails" I would say "is not available or fails". >=20 > >=20 > > 6. Don't know how to define a requirement which assumes the=20 > > presence of a > > B2BUA. I propose to leave as is > [JRE] Let me put it a different way. I don't think this is necessarily > achievable by the end device (UA). If the registrar does not support > GRUU, the UA may not have any means of obtaining a globally routable > contact URI. Perhaps the second "MUST" should be "SHOULD", with some > rationale why it might not always be possible. In any case, a locally > routable contact URI is acceptable if a B2BUA maps it to a globally > routable contact URI.=20 >
see below > >=20 > > 7. I'll fix the text for MUST and delete "normal" > >=20 > > 8. An actual problem. Calls out for a way to mark the Route as the > > emergency route. Two solutions were discussed. One is to=20 > use the sos > > parameter. The other is to say that the Geolocation header=20 > > must not have > > a "used for routing" parameter unless the LoST routing was=20 > > completed. I > > think I will recommend the second. > [JRE] OK - but I didn't see this in 08. >
-08 says: > If a device understands the SIP Location Conveyance extension=20 > and supports > LoST [RFC5222], the Geolocation "used-for-routing" header=20 > parameter MUST be > added to the corresponding URI in the Geolocation header. If=20 > the device is > unable to obtain a PSAP URI for any reason it > MUST NOT include "used-for-routing" on a Geolocation URI, so=20 > that downstream > entities know that LoST routing has not been completed. [JRE] OK >=20 > > 10. If the device is no longer registered, then the=20 > Contact can't be > > valid. I can insert text to this effect. =20 > [JRE] I didn't see this in 08. >
It will now read: > A Contact header MUST be present which MUST be globally routable, for > example a GRUU [I-D.ietf-sip-gruu], and be valid for several minutes > following the termination of the call,=20 > provided that the UAC remains registered with the same=20 > registrar, to permit > an immediate call-back to the specific device which placed=20 > the emergency > call. It is acceptable if the UAC inserts a locally routable=20 > URI and a > subsequent B2BUA maps that to a globally routable URI. [JRE] Good. >=20 >=20 >=20 > >=20 > > 11. Tried to make the requirement minimal (no Replaces, for=20 > > example), but > > I think you need referred by. I'll think some more about=20 > > that. I'll add > > text that says device implementers should consider the effect=20 > > of emergency > > call transfer on a stressed user; generally, the device=20 > should do the > > transfer. > [JRE] I didn't see anything in 08. For a device, the requirement is to > support receipt of REFER with method=3DINVITE, I believe, and to = handle > the Referred-By header field in such a request. If so, this should be > stated clearly. >
Rewrote to: > ED-67 During the course of an emergency call, devices and proxies MUST > support REFER transactions with method=3DINVITE and the=20 > Referred-by: header > in that transaction. [JRE] OK >=20 >=20 > >=20 > > 12. Don't understand the problem. The situation described is=20 > > AFTER a call > > session is established, but before it is terminated. LoST=20 > > resolution is > > complete. > [JRE] What I meant is how can the UA determine that the new call > originated at a PSAP. If the device did a LoST query, then a=20 > From or PAI > URI matching the result of the LoST query might be one=20 > mechanism. But if > the device didn't do a LoST query, or if the call comes from=20 > a different > PSAP (e.g., because the original call was forwarded or=20 > transferred) that > might not help. >
At this time, I think the domain idea is all we have to=20 > work with. As > you know, there is a draft that proposes new mechanisms to=20 > mark call backs. > If I just qualify the current text that this won't always=20 > work, and future > work will address this, is that okay? Suggested text: > Recognizing a call back from the domain of the PSAP will not=20 > always work, > and further > standardization will be required to give the UA the ability=20 > to recognize a > call back [JRE] Good >=20 > >=20 > > 13. a) If a call arrives while an emergency call is up, we=20 > > don't want a > > call waiting tone, alert or other prompt, we don't want the=20 > > emergency call > > put on hold and we don't want the incoming call to be answered. > [JRE] Thanks for the clarification, but this does not alter the fact > that call waiting is not an outgoing call feature. It would=20 > be better to > say what we mean, e.g., MUST disable features that will interrupt an > ongoing emergency call, such as call waiting... >
Rewrote to: > User Agents and proxies MUST disable features that will interrupt an > ongoing emergency call, such as: [JRE] Good >=20 > > b) Although some features can be applied to incoming calls,=20 > > they are also > > applicable to outgoing calls, which is what we want here; we=20 > > don't want > > the emergency call put on hold, put into a client-side=20 > conference, ... > [JRE] This too could be covered by the form of words I=20 > suggested above. >
Reworded to: > The User Agent and Proxies MUST disable call features which=20 > would interfere > with the ability of call backs from the PSAP to be completed such as: [JRE] Good >=20 > > c) I'll add a definition of "flash hold" to -framework. Of =20 > > course "flash > > hold" does involve a proxy, where normal SIP hold does not. =20 > > You don't > > want Hold (that is, disconnect the media to or from the PSAP). > [JRE] Flash hold as you now describe it in the framework is a PSTN > feature, so how does it relate to a SIP device? >
How 'bout I just delete any reference to "flash" and just=20 > say "Hold"? [JRE] OK >=20 > >=20 > > 14. Call waiting on an incoming call is the same as on an=20 > > outgoing call: > > you don't alert to another call, you don't offer hold and=20 > switch. The > > PSAP callback stays up. Yes, 486 or voicemail is=20 > > appropriate. Indeed the > > recognition of the callback is difficult, and I hope we will=20 > > charter an > > item. I think the domain recognition is a reasonable first=20 > > step, and I > > recognize it won't always work. When it doesn't, callback=20 > > won't get the > > feature suppression. Not a good thing, but not fatal. > [JRE] That is one way of interpreting the text of ED-72, but the way I > interpreted it is this. If I am engaged in a (non-PSAP) call and a > callback from a PSAP arrives, the callback is not allowed to use call > waiting to interrupt the existing call. That seems wrong. So there are > two situations: i) during an ordinary call when a callback from a PSAP > arrives, and ii) during a call that is a callback from a PSAP (which > really should be treated no differently from a call to a PSAP). >
In the rewording, I used " interfere with the ability of=20 > call backs from the PSAP to be completed". I have also deleted "Call > Waiting" > from the list, so I think the meaning is now clear. [JRE] OK >=20 > >=20 > > 15. I may be misinterpreting your concern, but I think the=20 > > B2BUA that maps > > Contact doesn't alter the caller's domain as seen by the=20 > > called party. If > > the call arrives directed TO the Contact or AoR given out in=20 > > the original > > emergency call, and it's FROM the same domain that answered=20 > > the call, then > > it should be treated as a call back. > [JRE] I didn't express my concern correctly. How does the end device > determine the domain of the PSAP that answers the call? We don't yet > have response identity defined in SIP. We could get the PSAP to send a > request (e.g., UPDATE) in the reverse direction and use PAI in that > request or RFC 4916 to change the From URI. >
Aha. I'll add a reference to 4916: > [RFC4916] may be used by the PSAP to inform the UA of the=20 > domain of the > PSAP. [JRE] OK >=20 > >=20 > >=20 > > 17. The response certainly should be using TLS, but it might=20 > > not work.=20 > > I'll add text. > [JRE] "The test response > SHOULD be protected with TLS. If the body cannot be protected, the > location SHOULD NOT be included in the response.." > Although the first hop from the responding node might be TLS,=20 > it is not > known that all upstream hops are TLS. >=20 >
What do you want me to do? S/MIME isn't a practical answer. [JRE] I don't see the point of SHOULD. If the request has arrived over an all TLS path, then the response should follow an all TLS path, based on the Via header field. If the request has not arrived over an all TLS path, it is unclear what the UAS can do. Can the UAS check the string of Via headers and check the path is all TLS? Otherwise I feel that the SHOULD is rather pointless. If the UAC wants to protect its location during test, it should use SIPS, rather than relying on the UAS to fix the problem. John From br@brianrosen.net Fri Mar 27 14:36:39 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F06A03A6AC7 for ; Fri, 27 Mar 2009 14:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D47r3Bd85Rl1 for ; Fri, 27 Mar 2009 14:36:37 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 886493A6A9B for ; Fri, 27 Mar 2009 14:36:37 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LnJjs-0005l7-Nb; Fri, 27 Mar 2009 16:37:21 -0500 From: "Brian Rosen" To: "'Elwell, John'" , References: <53275.24.154.127.233.1235780998.squirrel@www.brianrosen.net> <0D5F89FAC29E2C41B98A6A762007F5D0019841D0@GBNTHT12009MSX.gb002.siemens.net> <016901c9aeff$a6835c50$f38a14f0$@net> <0D5F89FAC29E2C41B98A6A762007F5D001B50EB8@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001B50EB8@GBNTHT12009MSX.gb002.siemens.net> Date: Fri, 27 Mar 2009 17:37:27 -0400 Message-ID: <01d101c9af24$3bfb2cd0$b3f18670$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmZO7wrCJSl+7uKRxu/R6D9XpQw8QCzHAqABIgnjfAAO2jUoAADHGGQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] Comments on phonebcp-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 21:36:39 -0000 Thanks I will fix ED-61 as you suggest. If I change ED-82 last line to: Use of SIPS for the request would assure the response containing the location is kept private. Would that be acceptable? Brian -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] Sent: Friday, March 27, 2009 5:15 PM To: Brian Rosen; ecrit@ietf.org Subject: RE: [Ecrit] Comments on phonebcp-07 Brian, Thanks for addressing my concerns. Just a couple of outstanding points below. > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: 27 March 2009 17:16 > To: Elwell, John; ecrit@ietf.org > Subject: RE: [Ecrit] Comments on phonebcp-07 > > Finishing this up > > > 5. I'll downgrade the sip-sips reference to Informational. > > Could refer to > > the 3.1 text. > [JRE] It still doesn't make sense to me for a normative statement to > refer to 3.1 of sip-sips when that section does not contain any > normative language. All we are doing is saying that TLS MUST be used, > and this doesn't seem to require any reference to sip-sips. So I would > suggest removing the reference to sip-sips entirely. >
I'll remove the reference to sip-sips [JRE] OK > > In addition (apologies if this has already been discussed), > by mandating > TLS we effectively are saying that you can't make an emergency call if > you can't use TLS! I doubt if that is really the intent. Should it not > say something like "An end device MUST use TLS, if available, when > attempting to establish an emergency call."? >
It's been discussed, and look at the very next requirement [JRE] But the ED-61 talks about only the case where TLS fails, rather than the case where TLS is simply not available. I guess it is a question of interpretation of words, but if you can't find a port for TLS, you can't even attempt it. So instead of "fails" I would say "is not available or fails". > > > > > 6. Don't know how to define a requirement which assumes the > > presence of a > > B2BUA. I propose to leave as is > [JRE] Let me put it a different way. I don't think this is necessarily > achievable by the end device (UA). If the registrar does not support > GRUU, the UA may not have any means of obtaining a globally routable > contact URI. Perhaps the second "MUST" should be "SHOULD", with some > rationale why it might not always be possible. In any case, a locally > routable contact URI is acceptable if a B2BUA maps it to a globally > routable contact URI. >
see below > > > > 7. I'll fix the text for MUST and delete "normal" > > > > 8. An actual problem. Calls out for a way to mark the Route as the > > emergency route. Two solutions were discussed. One is to > use the sos > > parameter. The other is to say that the Geolocation header > > must not have > > a "used for routing" parameter unless the LoST routing was > > completed. I > > think I will recommend the second. > [JRE] OK - but I didn't see this in 08. >
-08 says: > If a device understands the SIP Location Conveyance extension > and supports > LoST [RFC5222], the Geolocation "used-for-routing" header > parameter MUST be > added to the corresponding URI in the Geolocation header. If > the device is > unable to obtain a PSAP URI for any reason it > MUST NOT include "used-for-routing" on a Geolocation URI, so > that downstream > entities know that LoST routing has not been completed. [JRE] OK > > > 10. If the device is no longer registered, then the > Contact can't be > > valid. I can insert text to this effect. > [JRE] I didn't see this in 08. >
It will now read: > A Contact header MUST be present which MUST be globally routable, for > example a GRUU [I-D.ietf-sip-gruu], and be valid for several minutes > following the termination of the call, > provided that the UAC remains registered with the same > registrar, to permit > an immediate call-back to the specific device which placed > the emergency > call. It is acceptable if the UAC inserts a locally routable > URI and a > subsequent B2BUA maps that to a globally routable URI. [JRE] Good. > > > > > > > 11. Tried to make the requirement minimal (no Replaces, for > > example), but > > I think you need referred by. I'll think some more about > > that. I'll add > > text that says device implementers should consider the effect > > of emergency > > call transfer on a stressed user; generally, the device > should do the > > transfer. > [JRE] I didn't see anything in 08. For a device, the requirement is to > support receipt of REFER with method=INVITE, I believe, and to handle > the Referred-By header field in such a request. If so, this should be > stated clearly. >
Rewrote to: > ED-67 During the course of an emergency call, devices and proxies MUST > support REFER transactions with method=INVITE and the > Referred-by: header > in that transaction. [JRE] OK > > > > > > 12. Don't understand the problem. The situation described is > > AFTER a call > > session is established, but before it is terminated. LoST > > resolution is > > complete. > [JRE] What I meant is how can the UA determine that the new call > originated at a PSAP. If the device did a LoST query, then a > From or PAI > URI matching the result of the LoST query might be one > mechanism. But if > the device didn't do a LoST query, or if the call comes from > a different > PSAP (e.g., because the original call was forwarded or > transferred) that > might not help. >
At this time, I think the domain idea is all we have to > work with. As > you know, there is a draft that proposes new mechanisms to > mark call backs. > If I just qualify the current text that this won't always > work, and future > work will address this, is that okay? Suggested text: > Recognizing a call back from the domain of the PSAP will not > always work, > and further > standardization will be required to give the UA the ability > to recognize a > call back [JRE] Good > > > > > 13. a) If a call arrives while an emergency call is up, we > > don't want a > > call waiting tone, alert or other prompt, we don't want the > > emergency call > > put on hold and we don't want the incoming call to be answered. > [JRE] Thanks for the clarification, but this does not alter the fact > that call waiting is not an outgoing call feature. It would > be better to > say what we mean, e.g., MUST disable features that will interrupt an > ongoing emergency call, such as call waiting... >
Rewrote to: > User Agents and proxies MUST disable features that will interrupt an > ongoing emergency call, such as: [JRE] Good > > > b) Although some features can be applied to incoming calls, > > they are also > > applicable to outgoing calls, which is what we want here; we > > don't want > > the emergency call put on hold, put into a client-side > conference, ... > [JRE] This too could be covered by the form of words I > suggested above. >
Reworded to: > The User Agent and Proxies MUST disable call features which > would interfere > with the ability of call backs from the PSAP to be completed such as: [JRE] Good > > > c) I'll add a definition of "flash hold" to -framework. Of > > course "flash > > hold" does involve a proxy, where normal SIP hold does not. > > You don't > > want Hold (that is, disconnect the media to or from the PSAP). > [JRE] Flash hold as you now describe it in the framework is a PSTN > feature, so how does it relate to a SIP device? >
How 'bout I just delete any reference to "flash" and just > say "Hold"? [JRE] OK > > > > > 14. Call waiting on an incoming call is the same as on an > > outgoing call: > > you don't alert to another call, you don't offer hold and > switch. The > > PSAP callback stays up. Yes, 486 or voicemail is > > appropriate. Indeed the > > recognition of the callback is difficult, and I hope we will > > charter an > > item. I think the domain recognition is a reasonable first > > step, and I > > recognize it won't always work. When it doesn't, callback > > won't get the > > feature suppression. Not a good thing, but not fatal. > [JRE] That is one way of interpreting the text of ED-72, but the way I > interpreted it is this. If I am engaged in a (non-PSAP) call and a > callback from a PSAP arrives, the callback is not allowed to use call > waiting to interrupt the existing call. That seems wrong. So there are > two situations: i) during an ordinary call when a callback from a PSAP > arrives, and ii) during a call that is a callback from a PSAP (which > really should be treated no differently from a call to a PSAP). >
In the rewording, I used " interfere with the ability of > call backs from the PSAP to be completed". I have also deleted "Call > Waiting" > from the list, so I think the meaning is now clear. [JRE] OK > > > > > 15. I may be misinterpreting your concern, but I think the > > B2BUA that maps > > Contact doesn't alter the caller's domain as seen by the > > called party. If > > the call arrives directed TO the Contact or AoR given out in > > the original > > emergency call, and it's FROM the same domain that answered > > the call, then > > it should be treated as a call back. > [JRE] I didn't express my concern correctly. How does the end device > determine the domain of the PSAP that answers the call? We don't yet > have response identity defined in SIP. We could get the PSAP to send a > request (e.g., UPDATE) in the reverse direction and use PAI in that > request or RFC 4916 to change the From URI. >
Aha. I'll add a reference to 4916: > [RFC4916] may be used by the PSAP to inform the UA of the > domain of the > PSAP. [JRE] OK > > > > > > > 17. The response certainly should be using TLS, but it might > > not work. > > I'll add text. > [JRE] "The test response > SHOULD be protected with TLS. If the body cannot be protected, the > location SHOULD NOT be included in the response.." > Although the first hop from the responding node might be TLS, > it is not > known that all upstream hops are TLS. > >
What do you want me to do? S/MIME isn't a practical answer. [JRE] I don't see the point of SHOULD. If the request has arrived over an all TLS path, then the response should follow an all TLS path, based on the Via header field. If the request has not arrived over an all TLS path, it is unclear what the UAS can do. Can the UAS check the string of Via headers and check the path is all TLS? Otherwise I feel that the SHOULD is rather pointless. If the UAC wants to protect its location during test, it should use SIPS, rather than relying on the UAS to fix the problem. John From john.elwell@siemens-enterprise.com Fri Mar 27 15:10:52 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2ED3A6B8A for ; Fri, 27 Mar 2009 15:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wPtwR+v0x-L for ; Fri, 27 Mar 2009 15:10:52 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 13CAB3A6905 for ; Fri, 27 Mar 2009 15:10:51 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KH60009OQ5YFS@siemenscomms.co.uk> for ecrit@ietf.org; Fri, 27 Mar 2009 21:53:58 +0000 (GMT) Date: Fri, 27 Mar 2009 21:53:55 +0000 From: "Elwell, John" In-reply-to: <01d101c9af24$3bfb2cd0$b3f18670$@net> To: Brian Rosen , ecrit@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001B50EBC@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [Ecrit] Comments on phonebcp-07 Thread-Index: AcmZO7wrCJSl+7uKRxu/R6D9XpQw8QCzHAqABIgnjfAAO2jUoAADHGGQAADjU9A= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <53275.24.154.127.233.1235780998.squirrel@www.brianrosen.net> <0D5F89FAC29E2C41B98A6A762007F5D0019841D0@GBNTHT12009MSX.gb002.siemens.net> <016901c9aeff$a6835c50$f38a14f0$@net> <0D5F89FAC29E2C41B98A6A762007F5D001B50EB8@GBNTHT12009MSX.gb002.siemens.net> <01d101c9af24$3bfb2cd0$b3f18670$@net> Subject: Re: [Ecrit] Comments on phonebcp-07 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 22:10:52 -0000 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: 27 March 2009 21:37 > To: Elwell, John; ecrit@ietf.org > Subject: RE: [Ecrit] Comments on phonebcp-07 >=20 > Thanks >=20 > I will fix ED-61 as you suggest. >=20 > If I change ED-82 last line to: > Use of SIPS for the request would assure the response containing the > location is kept private. >=20 > Would that be acceptable? [JRE] Yes John From root@core3.amsl.com Fri Mar 27 15:45:01 2009 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3A85B3A6A6B; Fri, 27 Mar 2009 15:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090327224501.3A85B3A6A6B@core3.amsl.com> Date: Fri, 27 Mar 2009 15:45:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-framework-09.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 22:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Framework for Emergency Calling using Internet Multimedia Author(s) : B. Rosen, et al. Filename : draft-ietf-ecrit-framework-09.txt Pages : 37 Date : 2009-03-27 The IETF has standardized 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-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-framework-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-27153657.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri Mar 27 15:45:01 2009 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 444B33A6B81; Fri, 27 Mar 2009 15:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090327224501.444B33A6B81@core3.amsl.com> Date: Fri, 27 Mar 2009 15:45:01 -0700 (PDT) Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-09.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 22:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Best Current Practice for Communications Services in support of Emergency Calling Author(s) : B. Rosen, J. Polk Filename : draft-ietf-ecrit-phonebcp-09.txt Pages : 45 Date : 2009-03-27 The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. 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-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-phonebcp-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-27153740.I-D@ietf.org> --NextPart-- From br@brianrosen.net Fri Mar 27 16:41:08 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D2EA3A6B8A for ; Fri, 27 Mar 2009 16:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9c+dsw-PIc50 for ; Fri, 27 Mar 2009 16:41:07 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id B21733A6B83 for ; Fri, 27 Mar 2009 16:41:07 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1LnLgM-0005oj-5G for ecrit@ietf.org; Fri, 27 Mar 2009 18:41:50 -0500 From: "Brian Rosen" To: References: <20090327224501.444B33A6B81@core3.amsl.com> In-Reply-To: <20090327224501.444B33A6B81@core3.amsl.com> Date: Fri, 27 Mar 2009 19:41:58 -0400 Message-ID: <020a01c9af35$a0a141e0$e1e3c5a0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmvLdBPdQNA0/WURK+xWV2791sJagAB4DeQ Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-09.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 23:41:08 -0000 I have dealt with all of the issues raised by John Elwell. I have added the agreed-upon text to -framework and -phonebcp. I ask that we request publication of both of these documents. Brian -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, March 27, 2009 6:45 PM To: i-d-announce@ietf.org Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-09.txt 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-09.txt Pages : 45 Date : 2009-03-27 The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. 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-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From gunnar.hellstrom@omnitor.se Sat Mar 28 08:30:31 2009 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 837803A6A04 for ; Sat, 28 Mar 2009 08:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TRA27XocivM for ; Sat, 28 Mar 2009 08:30:30 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 5643F3A6837 for ; Sat, 28 Mar 2009 08:30:29 -0700 (PDT) Received: (qmail 50490 invoked from network); 28 Mar 2009 15:31:28 -0000 Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 28 Mar 2009 15:31:28 -0000 Received: (qmail 71782 invoked from network); 28 Mar 2009 15:31:22 -0000 Received: from h16n1fls34o265.telia.com (HELO GunnarH) (gunnar.hellstrom@omnitor.se@[213.64.232.16]) (envelope-sender ) by s57.loopia.se (qmail-ldap-1.03) with SMTP for ; 28 Mar 2009 15:31:22 -0000 From: "Gunnar Hellstrom" To: , "Brian Rosen" References: <20090327224501.3A85B3A6A6B@core3.amsl.com> Date: Sat, 28 Mar 2009 16:31:29 +0100 Message-ID: <003001c9afba$44702d70$211ea8c0@GunnarH> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmvLd81tlepZceYSYeGbih7J01RLgAhEWXw In-Reply-To: <20090327224501.3A85B3A6A6B@core3.amsl.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Subject: Re: [Ecrit] I-D Action:draft-ietf-ecrit-framework-09 - distorded reference X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2009 15:30:31 -0000 Brian, A minor editorial: I noticed that the reference to RFC 4103 in section 9.1 was distorded in editing. It looks like this now: xref target="RFC4103"/> It should look like this: [RFC4103] /Gunnar -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, March 27, 2009 11:45 PM To: i-d-announce@ietf.org Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-framework-09.txt 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-09.txt Pages : 37 Date : 2009-03-27 The IETF has standardized 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-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.
=0D= =0A=0D=0A

Hi Stephen,

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

 

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

Thankyou for you comments.

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

 

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

Cheers

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

James

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

 <= /p>=0D=0A=0D=0A

= -----Original Message---= --
=0D=0AFrom: Edge, Stephen [mailto:sedge@qualcomm.com]
=0D=0ASent:= Thursday, 5 March 2009 2:55 PM
=0D=0ATo: Winterbottom, James; Stark, Ba= rbara; br@brianrosen.net
=0D=0ACc: ECRIT
=0D=0ASubject: RE: [Ecrit] C= omments on Framework Draft

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

 

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

Hi James

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

<= font size=3D2 face=3D"Courier New"><= o:p> 

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

Thank= s for these comments.

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

 

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

I assume you recall that SUPL would use an E-SLP located in the serv= ing=0D=0A3GPP/3GPP2 network in case of combined access and VSP support. The= re are then=0D=0Ano roaming or global database issues as all location is su= pported within the=0D=0Aserving network.

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

 

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

[AJW] You are quite correct, the=0D= =0AE-SLP is the node that would be used. Just to point out though that ther= e are=0D=0Ano SETs currently that support the large number of E-SLP certifi= cates required=0D=0Ato make this solution workable, since the SET is not al= lowed to respond to an=0D=0ASLP that it cannot authenticate. I certainly th= ink it remains to be seen is the=0D=0Acurrently proposed E-SLP trust model = is workable on a large scale.

=0D=0A=0D=0A<= p class=3DMsoPlainText> 

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

Recall that you are claiming that the current Ecrit solu= tion minus SUPL=0D=0Ais suitable for this case which will be by far the mos= t common one for emergency=0D=0Acalls made via cellular networks. So I stil= l ask you to justify why mandating=0D=0Asupport for DHCP and HELD and not i= ncluding SUPL is a suitable solution.

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

[AJW] There are no SUPL=0D=0A2.0 deployments at this stag= e, and SUPL 1.0 is not suitable for emergency=0D=0Aservices. So nobody is m= aking SUPL emergency calls at this stage. I do however=0D=0Aknow of i2 and = i3/ECRIT trials that are currently in progress where devices are=0D=0Aobtai= ning location information from a LIS.

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

 

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

For other scenarios not involving cellular access or w= here the cellular=0D=0Acarrier is used only as an ISP, SUPL can still be su= itable. For example, it is=0D=0Anot true that a worldwide detailed database= would be needed (e.g. containing=0D=0Athe cell IDs of networks). A-GPS and= A-GNSS can work quite well using fairly=0D=0Acoarse location information (= e.g. country or network identification) to seed=0D=0Aassistance data and su= ch coarse location information can be obtained by a=0D=0Anumber of means (e= =2Eg. IP address, country/network portions of a cell ID,=0D=0Aprevious loca= tion estimate).

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

 

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

 

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

 =

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

 

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

Kind Regards=

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

 

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

Stephen<= /span>

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

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

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

From: = Winterbottom, James [mailto:James.Winterbottom@andrew.com]

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

Sent: Wednesday, March 04, = 2009 7:02 PM

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

To: Edge, Stephen; Stark, Barbara; br@brianrosen.net

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

Cc: ECRIT

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

Subject: RE: [Ecrit] Comments on= Framework Draft

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

 

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

Hi Stephen,

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

 

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

SUPL has one very huge disadvantage, it mandates the use of a home SLP.

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

SUPL roaming = between carriers is basically unimplementable. The=

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

mechanisms required to support an H= -SLP determining the V-SLP address

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

are deliberately left out of scope by OMA, and larg= e numbers of

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

companies are busily putting IPR on the ways in which this can occur.

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

There are no l= arge-scale deployments of RLP that I am aware of, and=0D=0Athis<= /span>

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

is a clear indicator o= f how bad the currently proposed architecture is.<= /p>=0D=0A=0D=0A

=  

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

All this means that for SUPL to be deploya= ble on a large scale any=0D=0AH-SLP

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

simply has to have the entire world in a database. = This is abundantly

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

evident when you look at systems like the global Nokia solution. I=0D= =0Athink

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

th= at this is mammoth task to maintain for general cell coverage, on a

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

global basis when = you include W-LAN and femto-cells it is quite simply

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

ridiculous.

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

 <= /p>=0D=0A=0D=0A

= The result is that SUPL is next to u= seless as a solution for anything

=0D=0A=0D=0A<= p class=3DMsoPlainText>other than providing basic-cell location or assistan= ce data for GPS. It

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

is not local in the same sense that an LCP is. All of the other

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

determination = mechanisms that you described in your previous email

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

simply don't work in SUPL to any = reasonable degree, and I would argue

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

don't work at all once the device in a foreign netw= ork.

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

&= nbsp;

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

Cheers

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

James

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

 

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

 

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

 

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

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

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

From: ecrit-bou= nces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf

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

Of Edge, Stephen

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

Sent: Thursday, 5 March = 2009 1:20 PM

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

To: Stark, Barbara; br@brianrosen.net

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

Cc: ECRIT

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

Subject: Re: [Ecrit] Comments on Framework Draft

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

 

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

Barbara and other= s

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

&nbs= p;

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

Thanks for th= e comments.

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

 

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

Whe= n I look at the PhoneBCP I see that both HELD and DHCP are mandatory

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

for the device wh= ereas at least one of these is mandatory for the AN.

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

While I can also see that SUPL is= not ruled out (though it is not

=0D=0A=0D=0Amentioned or referenced), it appears to have been dis= placed by the HELD

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

and DHCP requirements. On the other hand, many cellular networks ha= ve

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

already = deployed or are in the process of deploying SUPL and I am not

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

aware of any that have d= eployed an accurate location capability using

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

HELD or DHCP. So I would like to know how = you see the current

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

requirements as being suitable - after all, they imply at the very=0D= =0Aleast

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

ad= ditional development and deployment on the part of network and device<= /o:p>

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

vendors and netw= ork operators, whereas if SUPL was one of the defined

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

LCPs, that additional developmen= t and deployment might be mostly

=0D=0A=0D=0Aavoided. This question would not be applicable with s= ome additional

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

scope limitation and so I had not previously raised it. But it is<= /o:p>

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

certainly applic= able in

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

&nb= sp;the context of the global scope that is being claimed by some=

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

responders.=

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

 

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

Kind Regards

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

 =

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

Stephen

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

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

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

From: Stark, Ba= rbara [mailto:bs7652@att.com]

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

Sent: Friday, February 27, 2009 8:28 AM

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

To: br@brianrosen.net; Edge= , Stephen

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

<= font size=3D2 face=3D"Courier New">C= c: ECRIT

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

Su= bject: RE: [Ecrit] Comments on Framework Draft

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

 

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

Thank you Brian. This is well said [except you lef= t out the fact that

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

ecrit also allows for devices to get their location through other

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

mechanisms, s= uch as GPS, SUPL, or other methods, and doesn't insist that

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

the location be configured= through DHCP or HELD].

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

 

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

I agree 100% that additional qualifications are unnecessary. Service=

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

providers,= vendors, national bodies dealing with emergency services,=0D=0Aand

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

regulators aren't = stupid. Please trust us to figure out for ourselves

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

artificially limit or define scope, or to = state the obvious (e.g., the

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

architecture applies where it applies, and doesn't apply = where it

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

do= esn't apply). We understand the role and scope of the IETF, and the

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

role and scope of = 3GPP and 3GPP2. And all the other SDOs (and national

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

bodies and regulatory agencies). = SDOs need to offer architectures that

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

apply within the area of applicability for that SD= O, and are useful to

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

potential implementers, and leave it to the SPs, national bodies an= d

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

regulator= s to decide which architectures and standards to use or to

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

mandate within the scope of= their network or jurisdiction. Again, we

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

aren't stupid.

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

Barbara

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

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

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

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

From: ecrit-bounces@ietf.org [mailto:ecrit= -bounces@ietf.org] On Behalf

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

Of br@brianrosen.net

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

Sent: Friday, February 27, 2009 9:53 AM=

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

To: Edge, Stephen=

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

Cc: ECRIT<= /o:p>

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

Subject: Re: [Ec= rit] Comments on Framework Draft

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

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

Stephen

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

 

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

Like any standards organization, the IETF restricts it's scope.=

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

Generally, the = scope is "the Internet", although we very=0D=0Aoften describe

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

solutions that= are explicitly designed for private IP networks as well<= /font>

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

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

<= span style=3D'font-size:=0D=0A10.0pt'>the Internet.  We don't write st= andards for circuit switched=0D=0Anetworks,

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

and

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

it should be no surprise that the ecrit solution do= es not cater to CS

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

solutions.  Nevertheless, we often try to make sure that our=0D= =0Asolutions

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

harmonize reasonably well with existing solutions.

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

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

<= span style=3D'font-size:=0D=0A10.0pt'>Indeed, the ecrit solution clains glo= bal applicability to the Internet

=0D=0A=0D=0A<= p class=3DMsoPlainText>in

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

general, and most private IP networks that can be interconnected= to the

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

Int= ernet or to other IP networks via gateways.  Looking at your=0D=0Alist= of

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

problem= areas:

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

>= ;   - access to PSTN capable PSAPs

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

This is out of scope for IETF.  NENA = has active work on this=0D=0Asubject.

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

It

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

seems straightforward to interwork ecrit compatible device= s and=0D=0Anetworks

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

to existing CS connected PSAPs.  As you know, CS interconnects= are=0D=0Avery

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

nation-specific, so the NENA work may not have general applicability.

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

However, it s= hows that it is possible to interwork.  The NENA i2=0D=0Awork is<= /o:p>

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

also designed to= take ecrit compatible devices and VSP networks, and

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

interwork them to the existing ne= twork.  The VSP would direct the=0D=0Acall=0D=0A=0D=0A

to

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

the VPC, which would provide the services it does = now, using the device

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

provided location for routing.  This is important for smoot= h=0D=0Atransition

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

from existing PSAPs and VSPs to "next generation" PSAPs an= d=0D=0AVSPs.

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

>   - handover between different IP access networks=0D=0Ainc= luding different

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

> types of access network

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

In the ecrit solution, the access network the call = is initiated on

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

provides all the facilities needed for the device to initiate an<= /o:p>

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

emergency

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

call.  = The call starts traversing it's normal call path, and=0D=0Aeventually=

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

routes to the E= SRP.  Handoffs between IP networks should be=0D=0Atransparent

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

to

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

this process, although we p= robably haven't done all the work we need to

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

do

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

for handoffs where the IP address as seen by the te= rminating network

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

changes.  This would generally be true of all current SIP based= work.

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

>=    - handover to/from circuit mode networks

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

This would be out of scope for I= ETF.  It's as applicable to a=0D=0Asimple SIP=

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

call as it is a SIP emergency call,= and there are no statements in any

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

SIP

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

documents on that subject.

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

>   - location for cellular a= ccess (and the requirement to=0D=0Asupport LCPs=0D=0A=0D=0A

that

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

> will be useless for cellular access)

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

Location for cellul= ar access networks has been considered carefully.<= /p>=0D=0A=0D=0A

= Since cellular is a mobile network, = the access network would pass the

=0D=0A=0D=0A<= p class=3DMsoPlainText>device a Location-By-Reference URI, using either DHC= P or HELD. =0D=0AEither

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

protocol is suitable for cellular networks.  As we h= ave pointed=0D=0Aout

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

several times, cellular networks support raw data packet services u= pon

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

which m= any different kinds of networks can be constructed.  My=0D=0Ausual

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

example is a l= arge recreational vehicle traveling down a road with a

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

cellular data card plugged into= a router to which a wired (Ethernet)

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

phone

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

is connected.  That phone must be able to make an = emergency call,=0D=0Aand it

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

will get location from DHCP or HELD (or LLDP-MED).  I= t is not=0D=0Aaware of

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

the

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

cellular network, and doesn't know any cellular specific protocols.

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

Cellular netwo= rks will have to support IETF location configuration

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

protocols unless they actively pr= ohibit examples like this, or they

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

implement interworking between cellular-specific lo= cation protocols and

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

DHCP or HELD in the data card.  The ecrit standards permit pro= xy

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

insertio= n

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

of locati= on, but, as above, we don't think that works in all cases.

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

>   - endpoint= based location and routing for cellular=0D=0Aaccess (issues

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

here

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

> are network and device loa= ding as well as device impacts and=0D=0Aproblems=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>> with PSTN capable PSAPs)

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

The "load&quo= t; of using DHCP or HELD to get location and querying=0D=0ALoST is

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

pretty modest. = ; The standards permit proxies to do this if the=0D=0Adevices

=0D=0A=0D=0A

don't.  As above, i= nterwork functions to CS connected PSAPs is=0D=0Avery

=0D=0A=0D=0A

feasible, and as above, cellular= networks will have to support access=0D=0Ato

=0D= =0A=0D=0A

local LoST servers for devices that are co= nnected to cellular networks

=0D=0A=0D=0A

and

=0D=0A=0D=0A

are ecrit compliant.

=0D=0A=0D=0A

>   - support of unauthenticated users an= d users who can=0D=0Abe

=0D=0A=0D=0A

authenticated

=0D=0A=0D=0A

> but are not permitted access/VSP service except for emergen= cy=0D=0Acalls

=0D=0A=0D=0A

This is covered in the standards.  None of the processes are=0D=0Ad= ependent

=0D=0A=0D=0A

on=

=0D=0A=0D=0A

authentica= tion, although where it is possible, it's desirable so as to

=0D=0A=0D=0A

minimize fraudulent emerg= ency calls

=0D=0A=0D=0A

= = Mechanisms for specific network authentication mechanisms are out of

=0D=0A=0D=0A

scope, and, like = SIP basic calling, are not usually mentioned in IETF

=0D=0A=0D=0A

documents.

=0D=0A=0D=0A

 =0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>Stephen, we've tried pretty hard to m= ake sure this works for 3G/4G

=0D=0A=0D=0A

mobile

=0D=0A=0D=0A

networks.  It's true that it doesn't do it the way 3GPP cur= rently=0D=0Athinks

=0D=0A=0D=0A

it ought to work, but we claim they haven't thought through all the=

=0D=0A=0D=0A

issues.&nb= sp; While it would work, there are opportunities for=0D=0Aimprovement.=

=0D=0A=0D=0A

We

=0D=0A=0D=0A

would be willing to do = that if we could get the cooperation of 3GPP,

=0D= =0A=0D=0A

which

=0D=0A=0D= =0A

we have tried, and failed, to do.

=0D=0A=0D=0A

 

=0D=0A=0D=0A

So, I think the documents do no= t need any qualification statements.

=0D=0A=0D=0A=

 

=0D=0A=0D=0A

Brian

=0D=0A=0D=0A

 

=0D=0A=0D=0A

> Martin

=0D=0A=0D=0A

> 

=0D=0A=0D=0A

> The 3GPP/3GPP2 solution has a defined restricted applicability=0D= =0A(mainly

=0D=0A=0D=0A

= = to

=0D=0A=0D=0A

> 3GP= P/3GPP2 access networks where the serving network also acts as=0D=0Athe

=0D=0A=0D=0A

VSP)

=0D=0A=0D=0A

> and the specifica= tions for it cover in detail all possible=0D=0Ascenarios<= /font>

=0D=0A=0D=0A

> consistent with these re= strictions so far as we are aware.

=0D=0A=0D=0A=

> 

=0D=0A=0D=0A=

> The Ecrit solution seems to claim global appli= cability to all=0D=0Atypes of

=0D=0A=0D=0A

IP

=0D=0A=0D=0A

> access (and the more that is said about this from Ecrit=0D=0A= participants

=0D=0A=0D=0A

the

=0D=0A=0D=0A

> = more this gets emphasized) but does not cover in detail all=0D=0Apossible

=0D=0A=0D=0A

> scenario= s (in some cases does not cover in any detail) which means

=0D=0A=0D=0A

that at

=0D=0A=0D=0A

> best the solution is inco= mplete and at worst intrinsically

=0D=0A=0D=0A<= p class=3DMsoPlainText>inapplicable to

=0D=0A=0D= =0A

> some unstated set of scenarios.

=0D=0A=0D=0A

> 

=0D=0A=0D=0A

> The missing, incomp= lete and problematic cases include the=0D=0Afollowing:

=0D=0A=0D=0A

> 

=0D=0A=0D=0A

>   - access to PS= TN capable PSAPs

=0D=0A=0D=0A

>   - handover between different IP access networks=0D= =0Aincluding different

=0D=0A=0D=0A

> types of access network

=0D=0A=0D= =0A

>   - handover to/from circuit mode n= etworks

=0D=0A=0D=0A

>= ;   - location for cellular access (and the requirement to=0D=0As= upport LCPs

=0D=0A=0D=0A

that

=0D=0A=0D=0A

> = will be useless for cellular access)

=0D=0A=0D=0A=

>   - endpoint based location and rout= ing for cellular=0D=0Aaccess (issues

=0D=0A=0D=0A=

here

=0D=0A=0D=0A

> are network and device loading as well as device imp= acts and=0D=0Aproblems

=0D=0A=0D=0A

> with PSTN capable PSAPs)

=0D=0A=0D= =0A

>   - support of unauthenticated user= s and users who can=0D=0Abe

=0D=0A=0D=0A

authenticated

=0D=0A=0D=0A

> but are not permitted access/VSP service except fo= r emergency=0D=0Acalls

=0D=0A=0D=0A

> 

=0D=0A=0D=0A

> Stating that some of these cases are out of scope or refere= ncing=0D=0Aan

=0D=0A=0D=0A

> incomplete and possibly questionable specification from some other<= o:p>

=0D=0A=0D=0A

> national= SDO will not help the user who encounters such problems.=0D=0ABut

=0D=0A=0D=0A

it

=0D=0A=0D=0A

> would certainly help n= etwork operators and implementers to=0D=0Aacknowledge

=0D=0A=0D=0A

> their existence in one form= or another because that would allow=0D=0Abetter=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>> planning of deployments and woul= d help focus attention on finding

=0D=0A=0D=0A<= p class=3DMsoPlainText>> solutions (whether in IETF or elsewhere) for th= e missing cases.

=0D=0A=0D=0A

> 

=0D=0A=0D=0A

> Please note that despite these drawbacks, I will acknowledge t= hat

=0D=0A=0D=0A

Ecrit

=0D=0A=0D=0A

> does hav= e a valuable solution that covers many scenarios not=0D=0Acovered

=0D=0A=0D=0A

by

=0D=0A=0D=0A

> 3GPP/3GPP2. It would be t= he delineation of these supported=0D=0Ascenarios=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>(or

=0D=0A=0D= =0A

> equivalently unsupported scenarios) in some a= pplicability=0D=0Astatement

=0D=0A=0D=0A

that

=0D=0A=0D=0A

> would be particularly useful right now.

=0D=0A=0D=0A

> 

=0D=0A=0D=0A

> Kind Regards

=0D=0A=0D=0A

> 

=0D=0A=0D=0A

> Stephen=

=0D=0A=0D=0A

> -----Original Mes= sage-----

=0D=0A=0D=0A

<= font size=3D2 face=3D"Courier New">&= gt; From: Thomson, Martin=0D=0A= [mailto:Martin.Thomson@andrew.com]

=0D=0A=0D=0A=

> Sent: Thursday, February 26, 2009 9:45 PM=

=0D=0A=0D=0A

> To: Edge, = Stephen; Richard Barnes

=0D=0A=0D=0A

> Cc: ECRIT

=0D=0A=0D=0A

> Subject: RE: [Ecrit] Comments on Framework Draft=

=0D=0A=0D=0A

> <= /span>

=0D=0A=0D=0A

> There's benefit i= n knowing the limitations of a framework, and=0D=0Aevery<= /font>

=0D=0A=0D=0A

> architecture makes certa= in assumptions.  Let's examine them=0D=0Athough...

=0D=0A=0D=0A

> 

=0D=0A=0D=0A

> The IETF might occasional= ly make the assumption that the standards=0D=0Ait<= /p>=0D=0A=0D=0A

= > develops are for Internet devic= es.  That assumption probably=0D=0Aneed not=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>be

=0D=0A=0D= =0A

> stated explicitly.=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>> =0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>> The ECRIT architecture relies on= implementations of the protocols=0D=0Athat

=0D= =0A=0D=0A

it

=0D=0A=0D=0A=

> references.  That is not extraordinary.&n= bsp; A reliance on=0D=0Aimplementation

=0D=0A=0D= =0A

of

=0D=0A=0D=0A

> these protocols by endpoints, routing intermediaries = and PSAPs=0D=0Ashould

=0D=0A=0D=0A

not

=0D=0A=0D=0A

> need to be explained.

=0D=0A=0D=0A

> 

=0D=0A=0D=0A

> So the assumptions are:=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>>  - the Internet<= /span>

=0D=0A=0D=0A

>  - solutions= are implemented and deployed

=0D=0A=0D=0A

>  - the end device is a key component

=0D=0A=0D=0A

> <= /span>

=0D=0A=0D=0A

> Only that last el= ement is particularly novel ... or not that much=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>really.

=0D= =0A=0D=0A

>   It's a design choice.&nbs= p; Unless you were thinking=0D=0Aof trunking the=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>voice

=0D= =0A=0D=0A

> elsewhere.=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>> =0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>> Of course, you're suggesting tha= t the design choice was made in

=0D=0A=0D=0A

ignorance

=0D=0A=0D=0A

> of all the constraints.  You're suggesting th= at - as a result=0D=0A- the

=0D=0A=0D=0A

choice

=0D=0A=0D=0A

> is flawed and the solution is not going to work for cellula= r=0D=0Aservices.

=0D=0A=0D=0A

We

=0D=0A=0D=0A

= = > disagree.  The solution is a basis for emergency calling in=0D=0A= _any_ IP

=0D=0A=0D=0A

&g= t; network.

=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

>> -----Original Message-----

=0D=0A=0D= =0A

>> From: ecrit-bounces@ietf.org [mailto:ecri= t-bounces@ietf.org]=0D=0AOn

=0D=0A=0D=0A

Behalf

=0D=0A=0D=0A

>> Of Edge, Stephen

=0D=0A=0D=0A=

>> Sent: Friday, 27 February 2009 3:30 PM

=0D=0A=0D=0A

>> To: R= ichard Barnes

=0D=0A=0D=0A

>> Cc: 'ECRIT'

=0D=0A=0D=0A

>> Subject: Re: [Ecrit] Comments on Framework Draft

=0D=0A=0D=0A

>>&nbs= p;

=0D=0A=0D=0A

>> Hi R= ichard

=0D=0A=0D=0A

>= > 

=0D=0A=0D=0A

= = >> Thanks for the comments. Your statement below that "SIP=0D=0A= emergency

=0D=0A=0D=0A

<= font size=3D2 face=3D"Courier New">&= gt;> calling works if all parties behave as specified in these=0D=0A(IET= F

=0D=0A=0D=0A

Ecrit)

=0D=0A=0D=0A

>> docu= ments" to some degree highlights the problems we are=0D=0Araising. The=

=0D=0A=0D=0A

>> d= ocuments do contain a number of implicit and explicit=0D=0Arestrictions -

=0D=0A=0D=0A

>> like= IP capable PSAPs, global IP access (no islands of circuit=0D=0Amode

=0D=0A=0D=0A

>> access f= or example), universal support of this solution by all=0D=0Aaccess

=0D=0A=0D=0A

>> providers = and VSPs (not much good if some opt for another=0D=0Asolution)

=0D=0A=0D=0A

and

=0D=0A=0D=0A

>> end system oriented l= ocation and routing capability - which=0D=0Atogether

=0D=0A=0D=0A

>> make them unsuitable (we= believe) for cellular wireless=0D=0Anetworks. If<= /p>=0D=0A=0D=0A

= >> these restrictions and assu= mptions were all made explicit=0D=0Aupfront, it=0D=0A=0D=0A

>> would to a large degree (and = possibly completely) address our

=0D=0A=0D=0Aconcerns.

=0D=0A=0D=0A

>> 

=0D=0A=0D=0A=

>> You are right in assuming another set of s= pecifications for=0D=0Athe 3GPP

=0D=0A=0D=0A

>> and 3GPP2 solution. The applicability of this= solution is=0D=0Aexplicitly

=0D=0A=0D=0A

>> defined in TS 23.167 (or more exactly in an alre= ady agreed CR=0D=0Ain

=0D=0A=0D=0A

>> contribution S2-090752 which will become part of 23.167= in a=0D=0Afew more

=0D=0A=0D=0A

>> weeks) to cover the following access types: GPRS (UTRAN=0D= =0AWCDMA),

=0D=0A=0D=0A

= = I-WLAN,

=0D=0A=0D=0A

>= ;> Fixed Broadband, CDMA2000 HRPD, EPS UTRAN (WCDMA) and EPS=0D=0AE-UTRA= N

=0D=0A=0D=0A

>> = (LTE). So there is a restriction and arbitrary internet access=0D=0Ais not<= o:p>

=0D=0A=0D=0A

>> cove= red (yet) as I have stated before.

=0D=0A=0D=0A=

>> 

=0D=0A=0D= =0A

>> Kind Regards

=0D= =0A=0D=0A

>> =0D=0A=0D=0A

>> Stephen

=0D=0A=0D=0A

>> -----Original Message--= ---

=0D=0A=0D=0A

>>= ; From: Richard Barnes [mailto:rbarnes@bbn.com]=0D=0A=0D=0A

>> Sent: Wednesday, February 25,= 2009 6:30 PM

=0D=0A=0D=0A

>> To: Edge, Stephen

=0D=0A=0D=0A

>> Cc: Brian Rosen; 'ECRIT'

=0D=0A=0D=0A

>> Subject: Re: [Ecrit] Com= ments on Framework Draft

=0D=0A=0D=0A

>> 

=0D=0A=0D=0A

>> Hi Stephen,

=0D=0A=0D=0A

>> 

=0D=0A=0D=0A=

>> I'm a little confused by the scope of what= you're=0D=0Aasking.  The

=0D=0A=0D=0A

>> framework

=0D=0A=0D= =0A

>> and phonebcp documents exist in order to = describe the ECRIT=0D=0Asolution:

=0D=0A=0D=0A<= p class=3DMsoPlainText>>> They say, in effect, "SIP emergency ca= lling works if all=0D=0Aparties

=0D=0A=0D=0A

behave

=0D=0A=0D=0A

>> as specified in these documents."=

=0D=0A=0D=0A

>> 

=0D=0A=0D=0A

>> As I unde= rstand what you're saying (and I'm by no means an=0D=0Aexpert in=

=0D=0A=0D=0A

>> 3GPP), 3GPP s= pecifies that one or more elements of this system=0D=0Abehave

=0D=0A=0D=0A

>> differently.&nb= sp; This simply means that 3GPP networks aren't=0D=0Acomplying

=0D=0A=0D=0A

>> with

=0D=0A=0D=0A

>> these specs.&= nbsp; Just like there's no disclaimer in RFC 791=0D=0A(IPv4) that

=0D=0A=0D=0A

>> says "th= is doesn't work on X.25 networks", it's not=0D=0Aclear to me that=

=0D=0A=0D=0A

an

=0D=0A=0D=0A

>> analogous disc= laimer is called for here.

=0D=0A=0D=0A

>> 

=0D=0A=0D=0A

>> I presume there are similar documents describi= ng how emergency

=0D=0A=0D=0A

calling

=0D=0A=0D=0A

>> works in 3GPP networks.  Do they include notes saying=0D= =0Athat the 3GPP

=0D=0A=0D=0A

>> solution doesn't work in the broader Internet=3F

=0D=0A=0D=0A

>> 

=0D=0A=0D=0A

>> --Richard=

=0D=0A=0D=0A

>> 

=0D=0A=0D=0A

>&g= t; 

=0D=0A=0D=0A

&g= t;> 

=0D=0A=0D=0A

>> 

=0D=0A=0D=0A

>> 

=0D=0A=0D=0A

>> Edge, Stephen wrote:

=0D=0A=0D= =0A

>> > Brian

=0D= =0A=0D=0A

>> >

=0D= =0A=0D=0A

>> > First of all apologies for t= he likely lateness of this=0D=0Areply - I

=0D=0A=0D= =0A

>> actually wrote it on 19 February in a 3GP= P SA2 meeting in Budapest=

=0D=0A=0D=0A

but

=0D=0A=0D=0A

>> it seems unlikely that my VPN, Outlook server and WiFi access<= o:p>

=0D=0A=0D=0A

>> capa= bility will cooperate together to get it sent until I=0D=0Areturn to

=0D=0A=0D=0A

the

=0D=0A=0D=0A

>> office mid-next= week.

=0D=0A=0D=0A

>= > >

=0D=0A=0D=0A

<= font size=3D2 face=3D"Courier New">&= gt;> > Anyhow thanks for your comments. There have actually been=0D=0A= a number

=0D=0A=0D=0A

of=

=0D=0A=0D=0A

>> c= onference calls between IETF and 3GPP participants over the=0D=0Alast<= /o:p>

=0D=0A=0D=0A

>> couple = of years at which common features like support of IP=0D=0Aemergency

=0D=0A=0D=0A

>> calls wer= e discussed and these could have been good forum for

=0D=0A=0D=0A

>> participants on either s= ide to have raised the kinds of issues=0D=0Ayou=0D=0A=0D=0A

>> elaborate on below. Given tha= t seems not so far to have=0D=0Ahappened, it

=0D= =0A=0D=0A

>> could still be possible in future= such calls.

=0D=0A=0D=0A

>> >

=0D=0A=0D=0A

>> > But the issues we are raising are not directly to do wit= h=0D=0Afurther

=0D=0A=0D=0A

>> aligning the 2 solutions or with the lack of this in the past.=0D= =0AWe are

=0D=0A=0D=0A

<= font size=3D2 face=3D"Courier New">&= gt;> simply pointing out that the solutions are currently different=0D=0A= and

=0D=0A=0D=0A

that

=0D=0A=0D=0A

>> from= a cellular wireless perspective, the Ecrit solution is=0D=0Anot seen<= /o:p>

=0D=0A=0D=0A

as

=0D=0A=0D=0A

>> suitable in all= respects (for support of IP emergency calls

=0D= =0A=0D=0A

originating

=0D= =0A=0D=0A

>> from such access types). That is = not just our point of view.=0D=0A3GPP2

=0D=0A=0D= =0A

sent

=0D=0A=0D=0A

>> a liaison to Ecrit some months ago pointing out= the same=0D=0Aissues.

=0D=0A=0D=0A

>> >

=0D=0A=0D=0A

>> > So we are proposing that the Ecrit framework and p= honeBCP=0D=0Aspec.s

=0D=0A=0D=0A

>> include a statement acknowledging this - e.g. by referenci= ng=0D=0Athe

=0D=0A=0D=0A

>> alternative 3GPP/3GPP2 solution and indicating the IP access=0D=0A= types

=0D=0A=0D=0A

for

=0D=0A=0D=0A

>> whic= h the Ecrit solution will work without limitation (or

=0D=0A=0D=0A

equivalently

=0D=0A=0D=0A

>> the access types wher= e limitations are not ruled out).

=0D=0A=0D=0A<= p class=3DMsoPlainText>>> >

=0D=0A=0D=0A=

>> > We are not proposing further modifica= tion and extension=0D=0Aof the

=0D=0A=0D=0A

Ecrit

=0D=0A=0D=0A

>> solution - just pointing out that this would be needed = (as=0D=0Awith the

=0D=0A=0D=0A

>> 3GPP/3GPP2 solution) to fully cover all types of access.

=0D=0A=0D=0A

>> >=

=0D=0A=0D=0A

>> &= gt; Kind Regards

=0D=0A=0D=0A

>> >

=0D=0A=0D=0A

>> > Stephen

=0D=0A=0D=0A>> > -----Original Message-----

=0D=0A=0D=0A

>> > From: Bri= an Rosen [mailto:br@brianrosen.net]

=0D=0A=0D=0A=

>> > Sent: Wednesday, February 18, 2009 8:= 07 PM

=0D=0A=0D=0A

>&= gt; > To: Edge, Stephen; 'ECRIT'

=0D=0A=0D=0A=

>> > Subject: RE: [Ecrit] Comments on Fram= ework Draft

=0D=0A=0D=0A

>> >

=0D=0A=0D=0A

>> > I have bit my tongue on this one for a long time.

=0D=0A=0D=0A

>> >=

=0D=0A=0D=0A

>> > S= tephen, with respect, please go talk to 3GPP management=0D=0Aand ask

=0D=0A=0D=0A

them

=0D=0A=0D=0A

>> why=

=0D=0A=0D=0A

>> > there ha= s been no participation in the ecrit effort=0D=0Adespite<= /font>

=0D=0A=0D=0A

multiple

=0D=0A=0D=0A

>> YEARS

=0D=0A=0D=0A

>> > of begging th= em to get involved.  To put it frankly,=0D=0A3GPP is quite<= /span>

=0D=0A=0D=0A

>> willing<= /o:p>

=0D=0A=0D=0A

>> > to= bully IETF into doing its work on its schedule, but=0D=0Acannot be

=0D=0A=0D=0A

>> bothered = to

=0D=0A=0D=0A

>>= > get work done it knows it will eventually have to do when=0D=0Athe IE= TF

=0D=0A=0D=0A

>>= asks it

=0D=0A=0D=0A

&g= t;> > to do so.

=0D=0A=0D=0A

>> >

=0D=0A=0D=0A

>> > 3GPP understands the mess that is being created by= not

=0D=0A=0D=0A

partic= ipating.

=0D=0A=0D=0A

&g= t;> They

=0D=0A=0D=0A

>> > know full well that when they finally get around to=0D=0Adea= ling with PS

=0D=0A=0D=0A

>> > terminated emergency calls, that there will be a lot of=0D=0A= resistance

=0D=0A=0D=0A

= = to

=0D=0A=0D=0A

>>= > changing fully specified and implemented standards to=0D=0Amore close= ly

=0D=0A=0D=0A

>>= align

=0D=0A=0D=0A

>= > > with 3GPP standards.  I expect you will have several=0D=0Ain= terworking

=0D=0A=0D=0A

= = >> functions

=0D=0A=0D=0A

>> > to define and build.

=0D=0A=0D= =0A

>> >

=0D=0A=0D= =0A

>> > So, politely, please go away, we're = finishing work we=0D=0Adearly wanted

=0D=0A=0D=0A=

>> you all

=0D=0A=0D= =0A

>> > to be involved with for years, but y= ou refused to do=0D=0Aanything.

=0D=0A=0D=0A

It's

=0D=0A=0D=0A

>> too

=0D=0A=0D=0A

>> > late for this rev.

=0D= =0A=0D=0A

>> >

=0D= =0A=0D=0A

>> > Now, having said that, there= are quite a few people who=0D=0Ahave

=0D=0A=0D= =0A

>> participated in<= /p>=0D=0A=0D=0A

= >> > the IETF work who are = IMS aware and I believe that=0D=0Adespite your

=0D= =0A=0D=0A

>> fears,=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>>> > everything you need is = in the specs.  The mechanisms=0D=0Awe have=0D=0A=0D=0A

defined

=0D= =0A=0D=0A

>> provide<= /p>=0D=0A=0D=0A

= >> > the ability for the ne= twork to insert location, recognize=0D=0Aand mark<= /p>=0D=0A=0D=0A

= >> emergency=

=0D=0A=0D=0A

>> > calls, and rou= te on behalf of endpoints.  An E-CSCF=0D=0Acould quite

=0D=0A=0D=0A

>> > straightforw= ardly provide a SIP call towards an ecrit=0D=0Acompatible=

=0D=0A=0D=0A

>> PSAP.  The

=0D=0A=0D=0A

>> > = only not-quite-nice interwork would be from SUPL to HELD=0D=0A(or SIP),

=0D=0A=0D=0A

>> but i= t's

=0D=0A=0D=0A

>>= ; > pretty easy to do that.  I'll also note that we have=0D=0Atried= to get

=0D=0A=0D=0A

OMA=

=0D=0A=0D=0A

>> a= nd

=0D=0A=0D=0A

>>= > IETF to cooperate on location protocols, but we have been<= /span>

=0D=0A=0D=0A

>> spectacularly=

=0D=0A=0D=0A

>> &= gt; unsuccessful at that effort also.

=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

>> >> -----Original Message---= --

=0D=0A=0D=0A

>>= >> From: ecrit-bounces@ietf.org=0D=0A[mailto:ecrit-bounces@ietf.org]= On

=0D=0A=0D=0A

>>= ; Behalf

=0D=0A=0D=0A

&g= t;> >> Of Edge, Stephen

=0D=0A=0D=0A>> >> Sent: Thursday, February 05, 2009 2= :50 AM

=0D=0A=0D=0A

>= > >> To: 'ECRIT'

=0D=0A=0D=0A

>> >> Subject: [Ecrit] Comments on Framework Draft

=0D=0A=0D=0A

>> >= >

=0D=0A=0D=0A

>&g= t; >> All

=0D=0A=0D=0A

>> >>

=0D=0A=0D=0A

>> >> draft-ietf-ecrit-framework-07 is (as we see it= ) a=0D=0Amostly

=0D=0A=0D=0A

informative

=0D=0A=0D=0A

>> >> description of how terminals and networks should=0D= =0Asupport emergency

=0D=0A=0D=0A

>> >> calls made over IP capable facilities to IP capab= le=0D=0APSAPs. It

=0D=0A=0D=0A

>> appears

=0D=0A=0D=0A

>> >> intended to cover all types of access network = -=0D=0Aincluding fixed

=0D=0A=0D=0A

>> line,

=0D=0A=0D=0A

>> >> WiFi and cellular (e.g. examples involving eac= h can=0D=0Abe found

=0D=0A=0D=0A

>> throughout

=0D=0A=0D=0A

>> >> the draft).

=0D= =0A=0D=0A

>> >>=

=0D=0A=0D=0A

>> >> When we evaluated= this with respect to support of=0D=0Awireless

=0D= =0A=0D=0A

cellular

=0D=0A=0D= =0A

>> >> access and WiFi access associate= d with a cellular=0D=0Aoperator (e.g.

=0D=0A=0D= =0A

>> WLAN

=0D=0A=0D= =0A

>> >> or Femto cells integrated into a= cellular network),=0D=0Awe found that

=0D=0A=0D= =0A

>> >> certain portions of the draft ex= hibited one or more of=0D=0Athe

=0D=0A=0D=0A

following

=0D=0A=0D=0A

>> >> characteristics:

=0D=0A=0D=0A

>> >>

=0D=0A=0D=0A

>> >> &= nbsp;   (A) Inconsistent with already=0D=0Astandardized wireless = solutions

=0D=0A=0D=0A

<= font size=3D2 face=3D"Courier New">&= gt;> >>

=0D=0A=0D=0A

>> >>     (B) Inconsistent with=0D=0A= essential wireless requirements and

=0D=0A=0D=0A=

>> >> conventions

=0D=0A=0D=0A

>> >>

=0D=0A=0D=0A

>> >> &n= bsp;   (C) Already part of wireless=0D=0Astandards or potentially= part of

=0D=0A=0D=0A

&g= t;> >> future standards

=0D=0A=0D=0A>> >>

=0D=0A=0D= =0A

>> >> (A) refers to all portions of th= e draft framework=0D=0Athat differ from

=0D=0A=0D= =0A

>> the

=0D=0A=0D= =0A

>> >> requirements and procedures curr= ently standardized=0D=0Afor wireless

=0D=0A=0D=0A=

>> >> emergency access by 3GPP, 3GPP2 a= nd OMA. This is a=0D=0Aplain

=0D=0A=0D=0A

difference

=0D=0A=0D=0A

>> of

=0D=0A=0D=0A

>> >> solution and could be resolved through= support of=0D=0Aboth solutions

=0D=0A=0D=0A

by

=0D=0A=0D=0A

>> >> terminals (with each solution being used accor= ding to=0D=0Athe type of

=0D=0A=0D=0A

>> >> access network and VSP) or could be resolved b= y=0D=0Asupporting only

=0D=0A=0D=0A

one

=0D=0A=0D=0A

>> >> solution and accessing only the types of network=0D=0A= supporting that

=0D=0A=0D=0A

>> >> solution. To acknowledge this category, the framewor= k=0D=0Adocument

=0D=0A=0D=0A

could

=0D=0A=0D=0A

= = >> >> reference the applicable wireless standards and point=0D=0A= out that

=0D=0A=0D=0A

th= ese

=0D=0A=0D=0A

>>= ; >> are valid alternatives for wireless cellular based=0D=0Aaccess.<= o:p>

=0D=0A=0D=0A

>> >= >

=0D=0A=0D=0A

>&g= t; >> (B) refers to portions of the draft that would be=0D=0Aunsuitab= le for

=0D=0A=0D=0A

>= > >> wireless networks even if no alternative solution=0D=0Aexiste= d together

=0D=0A=0D=0A

= = >> with

=0D=0A=0D=0A

>> >> other portions missing from the draft that would be=0D= =0Aneeded to

=0D=0A=0D=0A

fully

=0D=0A=0D=0A

>= ;> >> support wireless networks. Examples of the former=0D=0Ainclu= de: (a)

=0D=0A=0D=0A

>= ;> emphasis

=0D=0A=0D=0A

>> >> on endpoint derivation of location, performance of=0D= =0ALost query and

=0D=0A=0D=0A

>> >> receipt of local dial strings; (b) restriction of=0D= =0ALCPs to

=0D=0A=0D=0A

= = protocols

=0D=0A=0D=0A

<= font size=3D2 face=3D"Courier New">&= gt;> >> that require terminal initiation (not allowing for=0D=0Ane= twork

=0D=0A=0D=0A

>>= initiation

=0D=0A=0D=0A

>> >> as far as we can tell) and that include two LCPs=0D=0A(D= HCP and LLDP)

=0D=0A=0D=0A

>> that

=0D=0A=0D=0A

>> >> are not applicable to (not defined for) cellular=0D= =0Aaccess; and (c)

=0D=0A=0D=0A

the

=0D=0A=0D=0A

>> >> requirement that a terminal or at least a LIS will=0D=0A= update the PSAP

=0D=0A=0D=0A

>> >> whenever location changes. (a) is impractical due to=0D= =0Anetwork and

=0D=0A=0D=0A

>> >> terminal loading consequences and failure to support=0D= =0Anon-IP

=0D=0A=0D=0A

<= font size=3D2 face=3D"Courier New">c= apable

=0D=0A=0D=0A

>= > >> PSAPs; (b) makes location verification and updated=0D=0Alocat= ion

=0D=0A=0D=0A

>>= ; provision

=0D=0A=0D=0A

>> >> to PSAPs difficult or impossible; while (c) is also=0D=0A= incompatible

=0D=0A=0D=0A

>> with

=0D=0A=0D=0A

>> >> support of existing non-IP capable PSAPs besides=0D=0A= increasing

=0D=0A=0D=0A

= = terminal

=0D=0A=0D=0A

&g= t;> >> load and possibly interfering with optimum=0D=0Amaintenance= of the RF

=0D=0A=0D=0A

= = >> >> connection (e.g. if a terminal has to tune away from=0D=0A= the serving

=0D=0A=0D=0A

>> base

=0D=0A=0D=0A

>> >> station or WLAN periodically to make location=0D=0Ame= asurements).

=0D=0A=0D=0A

>> Examples

=0D=0A=0D=0A

>> >> of the latter include (d) absence of support for=0D= =0Aaccess to non-IP

=0D=0A=0D=0A

>> >> capable PSAPs as already mentioned (e.g. to suppo= rt=0D=0AE911 phase 2

=0D=0A=0D=0A

in

=0D=0A=0D=0A

= = >> the

=0D=0A=0D=0A

>> >> US); (e) no support for handover from the IP to the=0D=0A= circuit domain

=0D=0A=0D=0A

>> when

=0D=0A=0D=0A

>> >> a terminal loses (e.g. moves out of) RF coverage i= n=0D=0Athe IP domain;

=0D=0A=0D=0A

>> and

=0D=0A=0D=0A

>> >> (f) no allowance for limited access modes wher= ein a=0D=0Aterminal may

=0D=0A=0D=0A

>> access

=0D=0A=0D=0A

>> >> a network only to place an emergency call= with=0D=0Aensuing

=0D=0A=0D=0A

restrictions

=0D=0A=0D=0A

>> on

=0D=0A=0D=0A

>> >> (for example) location acquisition, PSAP callback= and=0D=0Acaller

=0D=0A=0D=0A

>> >> verification and identification to the PSAP. To=0D= =0Aresolve this

=0D=0A=0D=0A

>> category

=0D=0A=0D=0A

>> >> either significant changes to the framework do= cument=0D=0Acould be made

=0D=0A=0D=0A

>> or a

=0D=0A=0D=0A

>> >> disclaimer/applicability statement could be ad= ded=0D=0Astating that

=0D=0A=0D=0A

>> support

=0D=0A=0D=0A

>> >> of cellular wireless networks and their = associated=0D=0AWLAN and Femto

=0D=0A=0D=0A

>> >> access points is not covered.

=0D=0A=0D=0A

>> >><= o:p>

=0D=0A=0D=0A

>> >= > Category (C) comprises concepts and capabilities in=0D=0Athe draft tha= t

=0D=0A=0D=0A

>> = are

=0D=0A=0D=0A

>>= ; >> either already part of the standardized solution for=0D=0Awirele= ss

=0D=0A=0D=0A

>>= networks

=0D=0A=0D=0A

<= font size=3D2 face=3D"Courier New">&= gt;> >> or that might be added at a later time. Examples of=0D=0At= he former

=0D=0A=0D=0A

<= font size=3D2 face=3D"Courier New">&= gt;> include

=0D=0A=0D=0A

>> >> LoST, SIP location conveyance, general use of SIP,=0D= =0Alocation for

=0D=0A=0D=0A

>> routing

=0D=0A=0D=0A

>> >> versus for dispatch, cellular positioning meth= ods.=0D=0AExamples of the

=0D=0A=0D=0A

>> >> latter include use of location references and=0D= =0Adereferencing and

=0D=0A=0D=0A

>> >> possible interworking between the current wireles= s=0D=0Anetwork

=0D=0A=0D=0A

solutions

=0D=0A=0D=0A

>> >> (in 3GPP, 3GPP2 and OMA) and the solution described=0D= =0Ain this draft.

=0D=0A=0D=0A

>> The

=0D=0A=0D=0A

>> >> presence of this category could be acknowledged b= y=0D=0Afollowing the

=0D=0A=0D=0A

>> >> disclaimer for (B) with a statement that certain=0D= =0Aportions of the

=0D=0A=0D=0A

>> >> solution are expected to be incorporated into=0D=0A= wireless networks

=0D=0A=0D=0A

now

=0D=0A=0D=0A

= = >> >> and/or in the future.

=0D=0A=0D= =0A

>> >>

=0D=0A=0D= =0A

>> >> We hope that these comments will= be seen to be a=0D=0Auseful addition

=0D=0A=0D= =0A

to

=0D=0A=0D=0A

>> >> this review in the sense of enabling a m= ore precise=0D=0Ascoping for

=0D=0A=0D=0A

the

=0D=0A=0D=0A

>> >> framework document and we are willing to assis= t in=0D=0Aproviding

=0D=0A=0D=0A

wording

=0D=0A=0D=0A

>> >> for any disclaimer/applicability statement that the=0D= =0AEcrit working

=0D=0A=0D=0A

>> group

=0D=0A=0D=0A

>> >> may now deem fit to include.=

=0D=0A=0D=0A

>> >>=

=0D=0A=0D=0A

>> >> Kind= Regards

=0D=0A=0D=0A

&g= t;> >>

=0D=0A=0D=0A

>> >> Stephen Edge (Qualcomm 3GPP SA2 participant), Kirk=0D= =0ABurroughs

=0D=0A=0D=0A

>> (Qualcomm

=0D=0A=0D=0A

>> >> 3GPP2 TSG-X and TSG-C participant)

=0D=0A=0D=0A

>> >>

=0D=0A=0D=0A

>> >> = PS  this being sent on 2/4/09 at 11:50pm PST<= /p>=0D=0A=0D=0A

= >> >><= /font>

=0D=0A=0D=0A

>> >> ___________= ____________________________________

=0D=0A=0D=0A=

>> >> Ecrit mailing list

=0D=0A=0D=0A

>> >> Ecrit@i= etf.org

=0D=0A=0D=0A

>= ;> >> https://www.ietf.org/mailman/listinfo/ecrit

=0D=0A=0D=0A

>> >

=0D=0A=0D=0A

>> > __________= _____________________________________

=0D=0A=0D= =0A

>> > Ecrit mailing list=

=0D=0A=0D=0A

>> > Ecrit@ietf.org=

=0D=0A=0D=0A

>> &= gt; https://www.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A

>> >=

=0D=0A=0D=0A

>> __________________________= _____________________

=0D=0A=0D=0A

>> Ecrit mailing list

=0D=0A=0D= =0A

>> Ecrit@ietf.org=0D=0A=0D=0A

<= span style=3D'font-size:=0D=0A10.0pt'>>> https://www.ietf.org/mailman= /listinfo/ecrit

=0D=0A=0D=0A

> 

=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=0D=0A

> contain pr= ivileged, proprietary, or otherwise private information.<= /font>

=0D=0A=0D=0A

> If you have received it = in error, please notify the sender

=0D=0A=0D=0A=

> immediately and delete the original.  Any= unauthorized use of

=0D=0A=0D=0A

> this email is prohibited.

=0D=0A=0D= =0A

> 

=0D=0A=0D=0A=

---------------------------------------------------= ---------------------

=0D=0A=0D=0A

------------------------

=0D=0A=0D=0A=

> [mf2]

=0D=0A=0D=0A=

> ______________________________________________= _

=0D=0A=0D=0A

> Ecri= t mailing list

=0D=0A=0D=0A

> Ecrit@ietf.org

=0D=0A=0D=0A

> https://www.ietf.org/mailman/listinfo/ecrit

=0D=0A=0D=0A

> 

=0D=0A=0D=0A

 

=0D=0A=0D=0A

______________________________= _________________

=0D=0A=0D=0A

Ecrit mailing list

=0D=0A=0D=0A

Ecrit@ietf.org

=0D=0A=0D=0A

https://www.ietf.org/mailman/listinfo/ecrit

=0D=0A=0D=0A

 =

=0D=0A=0D=0A

*****

=0D= =0A=0D=0A

 

=0D=0A=0D= =0A

The information transmitted is intended only for t= he person or entity=0D=0Ato

=0D=0A=0D=0A

which it is addressed and may contain confidential, propri= etary, and/or

=0D=0A=0D=0A

privileged material. Any review, retransmission, dissemination or other<= o:p>

=0D=0A=0D=0A

use of, or ta= king of any action in reliance upon this information by

=0D=0A=0D=0A

persons or entities other than= the intended recipient is prohibited. If

=0D=0A=0D= =0A

you received this in error, please contact the sen= der and delete the

=0D=0A=0D=0A

material from all computers. GA621

=0D=0A=0D= =0A

 

=0D=0A=0D=0A

 

=0D=0A=0D=0A

_______________________________________________=

=0D=0A=0D=0A

Ecrit mailing list

=0D=0A=0D=0A

Ecrit@ietf.org=

=0D=0A=0D=0A

https://ww= w.ietf.org/mailman/listinfo/ecrit

=0D=0A=0D=0A<= p class=3DMsoPlainText> 

=0D=0A=0D=0A

--------------------------------------------------------= ----------------------------------------

=0D=0A=0D= =0A

This message is for the designated recipient only = and may

=0D=0A=0D=0A

con= tain privileged, proprietary, or otherwise private information.<= /span>

=0D=0A=0D=0A

If you have received i= t in error, please notify the sender

=0D=0A=0D=0A=

immediately and delete the original.  Any unau= thorized use of

=0D=0A=0D=0A

this email is prohibited.

=0D=0A=0D=0A

-------------------------------------------------------= -----------------------------------------

=0D=0A=0D= =0A

[mf2]

=0D=0A=0D=0A

 

=0D=0A=0D=0A

 

=0D=0A=0D=0A