From ecrit-bounces@ietf.org Mon Oct 01 16:29:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcRt1-0001l1-DT; Mon, 01 Oct 2007 16:29:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcRsz-0001k7-DB for ecrit@ietf.org; Mon, 01 Oct 2007 16:29:01 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IcRsu-0002pd-1p for ecrit@ietf.org; Mon, 01 Oct 2007 16:29:01 -0400 Received: (qmail invoked by alias); 01 Oct 2007 20:28:46 -0000 Received: from p54984E22.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.78.34] by mail.gmx.net (mp026) with SMTP; 01 Oct 2007 22:28:46 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX196hdk/9UB6DUK+Yz0XDJosqFZW0I5jZIWeQFz2yM Q3JaTfU6nBKo8L Message-ID: <4701587C.8030700@gmx.net> Date: Mon, 01 Oct 2007 22:28:44 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ECRIT , GEOPRIV , es-coordination@lists.cs.columbia.edu Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ecrit] 3rd Emergency Services Workshop: Registration Open X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, we are currently finalizing the preparation for the 3rd SDO emergency services workshop: http://www.emergency-services-coordination.info/2007Nov/ Registration for the workshop is now possible via the link available on the main workshop page. We are again using the EDAS system. Here is the direct link to the EDAS registration page: https://edas.info/r5867 Deadline for registration: 25th October 2007 Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 02 10:53:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icj6n-00082C-6P; Tue, 02 Oct 2007 10:52:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icj6m-000827-9C for ecrit@ietf.org; Tue, 02 Oct 2007 10:52:24 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Icj6g-0003un-4B for ecrit@ietf.org; Tue, 02 Oct 2007 10:52:24 -0400 Received: from ([139.76.131.79]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.185689341; Tue, 02 Oct 2007 10:51:41 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 2 Oct 2007 10:51:42 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 2 Oct 2007 10:51:41 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Oct 2007 10:51:39 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA05E3433C@crexc41p> In-Reply-To: <0bea01c804f4$8cafc540$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: was [Geopriv] HELD Emergency Text thread-index: AcgEkkRIvt0BMW31Sq+6EqPYbJ/A8wAV8dtwAAJttXAAA5+7wA== References: <7582BC68E4994F4ABF0BD4723975C3FA05E34268@crexc41p> <0bea01c804f4$8cafc540$640fa8c0@cis.neustar.com> From: "Stark, Barbara" To: "Brian Rosen" , "Winterbottom, James" , X-OriginalArrivalTime: 02 Oct 2007 14:51:41.0591 (UTC) FILETIME=[BE4E6A70:01C80503] X-Spam-Score: 0.2 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Subject: [Ecrit] was [Geopriv] HELD Emergency Text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Moving this to ecrit... My main objection was the recommended proscription against doing an emergencyDispatch request at call time. I'm fine with the minimum sequence, but see no reason to recommend against emergencyDipatch from being requested at call time. But certainly, at emergency call time, a device using HELD for location acquisition MUST send a request with emergencyRouting. Barbara -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, October 02, 2007 9:03 AM To: Stark, Barbara; 'Winterbottom, James'; geopriv@ietf.org Subject: RE: [Geopriv] HELD Emergency Text >=20 > As for not using emergencyDispatch when making an emergency call, I > don't think this is quite right. I think we would want both an > emergencyDispatch and emergencyRouting query at call time. The > emergencyRouting value would be used for routing, and the > emergencyDispatch would update the currently saved Dispatch location. Well, I think that's complicated. First of all, the minimum sequence is emergencyRouting and send the call. UPDATE location later if you need to. Question to James et. al. on a reference: Do you ever think something like the notion of emergencyRouting/Dispatch would get encoded in the reference? I hope not. Then you could ask for both, but you need to do that in separate requests so that the response to the Routing request comes in as soon as it's ready. And of course if you get both, and you have them before you send the call (meaning they come in quickly), then you want to use and send Dispatch and discard Routing unless there is an error. ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA621 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 02 10:58:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcjCu-00071W-Jc; Tue, 02 Oct 2007 10:58:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcjCt-00070B-Bb for ecrit@ietf.org; Tue, 02 Oct 2007 10:58:43 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IcjCs-000465-4b for ecrit@ietf.org; Tue, 02 Oct 2007 10:58:43 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IcjCg-0000xZ-MW; Tue, 02 Oct 2007 09:58:30 -0500 From: "Brian Rosen" To: "'Stark, Barbara'" , "'Winterbottom, James'" , References: <7582BC68E4994F4ABF0BD4723975C3FA05E34268@crexc41p> <0bea01c804f4$8cafc540$640fa8c0@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA05E3433C@crexc41p> Date: Tue, 2 Oct 2007 10:58:34 -0400 Message-ID: <0c5401c80504$b7365b20$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA05E3433C@crexc41p> Thread-Index: AcgEkkRIvt0BMW31Sq+6EqPYbJ/A8wAV8dtwAAJttXAAA5+7wAAAkVAw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Subject: [Ecrit] RE: was [Geopriv] HELD Emergency Text X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I agree. I think the sequence is: 1. Ask for emergencyRouting 2. Query LoST with it 3. Send the call 4. Ask for emergencyDispatch 5. If it's different, UPDATE location Brian > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Tuesday, October 02, 2007 10:52 AM > To: Brian Rosen; Winterbottom, James; ecrit@ietf.org > Subject: was [Geopriv] HELD Emergency Text > > Moving this to ecrit... > My main objection was the recommended proscription against doing an > emergencyDispatch request at call time. I'm fine with the minimum > sequence, but see no reason to recommend against emergencyDipatch from > being requested at call time. But certainly, at emergency call time, a > device using HELD for location acquisition MUST send a request with > emergencyRouting. > Barbara > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Tuesday, October 02, 2007 9:03 AM > To: Stark, Barbara; 'Winterbottom, James'; geopriv@ietf.org > Subject: RE: [Geopriv] HELD Emergency Text > > > > > > As for not using emergencyDispatch when making an emergency call, I > > don't think this is quite right. I think we would want both an > > emergencyDispatch and emergencyRouting query at call time. The > > emergencyRouting value would be used for routing, and the > > emergencyDispatch would update the currently saved Dispatch location. > Well, I think that's complicated. > > First of all, the minimum sequence is emergencyRouting and send the > call. > UPDATE location later if you need to. > > Question to James et. al. on a reference: Do you ever think something > like > the notion of emergencyRouting/Dispatch would get encoded in the > reference? > I hope not. > > Then you could ask for both, but you need to do that in separate > requests so > that the response to the Routing request comes in as soon as it's ready. > > And of course if you get both, and you have them before you send the > call > (meaning they come in quickly), then you want to use and send Dispatch > and > discard Routing unless there is an error. > > > ***** > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential, proprietary, and/or > privileged material. Any review, retransmission, dissemination or other > use of, or taking of any action in reliance upon this information by > persons or entities other than the intended recipient is prohibited. If > you received this in error, please contact the sender and delete the > material from all computers. GA621 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 02 12:55:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icl1K-0003Nv-Fe; Tue, 02 Oct 2007 12:54:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icl1G-0003AH-U8; Tue, 02 Oct 2007 12:54:51 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icl1F-0001Z9-Gp; Tue, 02 Oct 2007 12:54:50 -0400 X-IronPort-AV: E=Sophos;i="4.21,220,1188802800"; d="scan'208";a="229077480" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 02 Oct 2007 09:54:48 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l92GsmCF006739; Tue, 2 Oct 2007 09:54:48 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l92Gsm1g005293; Tue, 2 Oct 2007 16:54:48 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Oct 2007 09:54:48 -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: Tue, 2 Oct 2007 09:54:55 -0700 Message-ID: In-Reply-To: <46F5172E.3000005@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft liaison response for IEEE 802.11u EAP method for emergency calls Thread-Index: Acf9G7H0qKbBRemkTDCHK3ZOgsqdzwH96N6A From: "Joseph Salowey (jsalowey)" To: "Hannes Tschofenig" , "Bernard Aboba" X-OriginalArrivalTime: 02 Oct 2007 16:54:48.0564 (UTC) FILETIME=[F1490B40:01C80514] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12241; t=1191344088; x=1192208088; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20Draft=20liaison=20response=20for=20IEEE=20802.11u=20E AP=20method=20for=20emergency=20calls |Sender:=20; bh=/x7bxBFgABN64FNCJeZpClBL+kn1Ds4mHV837DpyeSc=; b=Zd3LuebeInXGxtJa2X6czxyk01MQksJOGP8NysBPL9rbYFkSZe1VAypNZo9LAtnp8B/ZdnLD RyyA++Q5kbelu2WEVYkbtdlKGqIKlAB4dPJsWknoBJJ9BeVpW7aYVB9D; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 Cc: ecrit-chairs@tools.ietf.org, emu@ietf.org, ECRIT Subject: [Ecrit] RE: Draft liaison response for IEEE 802.11u EAP method for emergency calls X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Hannes, Comments inline below.=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Saturday, September 22, 2007 6:23 AM > To: Bernard Aboba > Cc: Joseph Salowey (jsalowey); emu@ietf.org;=20 > ecrit-chairs@tools.ietf.org; ECRIT > Subject: Re: Draft liaison response for IEEE 802.11u EAP=20 > method for emergency calls >=20 > Hi Bernard, >=20 > thanks for your input. Please find a few more thoughts below: >=20 > Bernard Aboba wrote: > > It is not clear to me whether the requirements do in fact prohibit=20 > > server-side authentication. As you note, without server-side=20 > > authentication man-in-the-middle attacks are possible; =20 > however, even=20 > > with server-side authentication, additional requirements=20 > may need to=20 > > be imposed in order to provide the desired level of security. > > > I also believe that the requirements does not rule out=20 > server-side authentication. >=20 > > Requirement #1 is "No Pre-configured trust relationship". =20 > This could=20 > > refer to pre-configuration of the server with respect to=20 > the expected=20 > > client credential (PSK or certificate), or it could refer to=20 > > pre-configuration of the client with respect to the server, (such=20 > > trust anchors). The text seems focused on the former more than the=20 > > latter. Assuming that clients can be pre-configured with trust=20 > > anchors, then TLS-based EAP methods could meet the requirement. > > > I agree that this aspect of no pre-configured trust=20 > relationship is quite likely to refer to pre-established=20 > shared secrets. >=20 > > Requirement #2 is "Small" number of messages. While this=20 > requirement=20 > > clearly excludes long exchanges, it is not clear to me that=20 > TLS-based=20 > > methods are excluded, particularly if the method is to be=20 > implemented=20 > > on the AP itself, which potentially would result in lower=20 > round-trip=20 > > times and eliminate the possibility of AAA-based frame loss. > > > I doubt that the performance argument counts a lot here given=20 > that the exchange is, as you indicated, local. >=20 > > It may be possible that requirements #1 and #2 are compatible with=20 > > proposals involving unauthenticated client access combined=20 > with server > > authentication. However, due to lack of a pre-configured network=20 > > access profile, this scenario presents additional threats that are=20 > > worthy of further discussion. > > > > The presentation refers to the desire to for confidentiality=20 > > (presumably at L2, rather than using SRTP). Where=20 > confidentiality is=20 > > desirable, it will also presumably be important for the client to=20 > > determine that it has connected to a legitimate network. > Whereby "legitimate network" is already a quite difficult requirement. >=20 [Joe] This is a central point, if one does not know what is a legitimate network then why bother to authenticate it? =20 > > > > Where a pre-configured network access profile exists, the binding=20 > > between a validated server certificate and an advertised SSID is=20 > > pre-configured. However, where there is no pre-configured network=20 > > access profile, the binding may be difficult to establish without=20 > > imposition of additional requirements. > > > > For example, the server certificate/SSID binding cannot be=20 > determined=20 > > solely via verification of the server certificate. An=20 > attacker could=20 > > obtain a valid server certificate for "example.com"; does=20 > this entitle=20 > > them to advertise an SSID of "Emergency Network" or even "Example"? > > Since SSIDs are not globally unique, there is no verifiable mapping=20 > > between a Server-Id and an allowed set of SSIDs. In=20 > general, a CA has=20 > > no way of determining whether a server has the rights to a=20 > particular=20 > > SSID or not, so that a CA cannot in practice vouch for an RFC 4334=20 > > SSID extension within a server certificate. > > > > Therefore verification of a binding between the server identity and=20 > > the advertised network would only seem to be possible by=20 > requiring the=20 > > advertised network name to match the Server-Id advertised in the=20 > > server certificate. This in turn would require restricting the=20 > > allowable SSIDs, or adding another field to the IEEE 802.11=20 > > Beacon/Probe Response. > > > I don't think it make a lot of sense to bind the certificate=20 > to the advertised SSID. >=20 [Joe] This depends upon what you are trying to do. If you want to have some assurance at the time of connection need to be able to check that the entity that you are authenticating is authorized to provide the service. Tying SSIDs to the certificate is one way to do this. There are others that may be more attractive as well.=20 >=20 > WHAT CAN YOU ACCOMPLISH WITH SERVER-SIDE AUTHENTICATION? >=20 > The important question here, I believe, is what you would do with=20 > server-side authentication in such a context given that it=20 > has entirely=20 > different semantic than the server-side authentication that=20 > is typically=20 > exercised in EAP exchanges between the peer and the EAP server in the=20 > user's home network. >=20 > I don't think that addressing man-in-the-middle attacks is the main=20 > objective. Instead, I could imagine that when something goes=20 > wrong then=20 > the end user might be able to indicate that he or she was interacting=20 > with a specific network.I see this more as a "debugging" tool. >=20 [Joe] But do you need to go through all this complex cryptographic calculations and message exchanges just for "debugging"?=20 > When some verification steps fails, for example because the=20 > certificate=20 > of the server is expired, then in an emergency situation you=20 > will just=20 > continue rather than dropping the conversation. Additionally,=20 > everyone=20 > should be able to setup networks and hence the adversary can=20 > easily do=20 > the same. What would the network of an adversary=20 > differentiate from one=20 > that is from someone else? >=20 > WHAT ASSUMPTIONS DO WE MAKE WITH RESPECT TO THE SERVER'S=20 > CERTIFICATE AND=20 > THE TRUST ANCHORS? >=20 > Do we assume that persons that setup networks, such as my=20 > home network,=20 > a coffee shop, the IETF network, have to obtain a certificate=20 > for their=20 > network from > a) from any company that sells certs typically found in web servers > b) from a dedicated emergency services provider >=20 > (Note1) >=20 > May I re-use existing trust anchors, such as those available=20 > with my web=20 > browsers, or do end devices need to add new root certs into their=20 > certificate store? >=20 > In case (b) can I assume that the PSAP also uses the same=20 > trust anchor=20 > so that I could potentially use DTLS-SRTP for end-to-end=20 > media security=20 > to ensure that I am actually speaking to a real PSAP rather=20 > than to an=20 > adversary? >=20 >=20 > Ciao > Hannes >=20 > Note 1: Would it be allowed to just skip server-side=20 > authentication and=20 > to end-up with a unauthenticated Diffie-Helman exchange? One=20 > might argue=20 > that this does not provide a lot of advantages and we could also skip=20 > the EAP exchange entirely but that's not completely true that=20 > architectures, such as Wimax, assume that keying material is exported=20 > during network attachment and that these keys are used for other=20 > protocols. Hence, if one would change then the impact for the=20 > other work=20 > done before would be too large. >=20 [Joe] However it seems that we really ought to make sure we are gaining something from this exchange. If not we are just introducing delays into the system at a critical point. Wouldn't you want to reduce the delay at this point? > > > > > > > > > > > >> From: "Joseph Salowey (jsalowey)" > >> To: > >> CC: , "Bernard Aboba"=20 > >> > >> Subject: Draft liaison response for IEEE 802.11u EAP method for=20 > >> emergency calls > >> Date: Sun, 16 Sep 2007 22:26:36 -0700 > >> > >> The EMU working group has a liaison request from IEEE=20 > 802.11u on EAP > >> methods for emergency calls. The liaison request can be=20 > found on the > >> liaison statement page, https://datatracker.ietf.org/liaison/ (May > >> 2007). We had a presentations and discussion of this topic at the > >> Chicago EMU meeting. Below is a draft response based on=20 > the discussion > >> in the meeting. It would be good to have comments on or=20 > approval of the > >> text by Monday, October 1, so a revised response can be=20 > created to be > >> sent as a response to the IEEE. > >> > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> 802.11u Liaison response for EAP Methods for Emergency=20 > Communications > >> > >> We have had discussion of EAP method for Emergency=20 > services at the last > >> IETF meeting in Chicago. The following is a summary of=20 > working group > >> discussion on this topic. > >> > >> Currently there are no standards track EAP methods that meet the > >> requirements as understood by the EMU working group. =20 > There are several > >> possible candidates of existing EAP methods that may meet=20 > or be slightly > >> modified to meet some of the 802.11u requirements for emergency > >> services, especially if minimal latency is not the strongest > >> requirement. TTLS (draft-funk-eap-ttls-v0-01.txt) and EAP-FAST > >> (RFC4851) are TLS based methods that can support server only > >> authentication. It was also pointed out that EAP-TLS > >> (draft-simon-emu-rfc2716bis-11.txt) could be modified to=20 > create a new > >> EAP method that only requires server side authentication. =20 > In order to > >> truly support emergency services these methods would need to forego > >> server certificate validation which negates much of the=20 > security they > >> provide by allowing man-in-the-middle attacks. These TLS=20 > based methods > >> also require a significant number of round trips that may not be > >> acceptable for emergency communication. > >> > >> There were also several questions raised in the working=20 > group during the > >> discussion that might help in further determining the best=20 > approach. > >> These are summarized below: > >> > >> 1) It is not clear how to make the tradeoff between security and > >> low-latency. If there is not existing trust relationship there are > >> limits as to what security properties can be provided. =20 > What security > >> properties are desirable and what is the tolerance for=20 > extra-round trips > >> for the communication? > >> > >> 2) PSK was described as having worse DOS resistance=20 > properties that EAP. > >> It seems that in many cases EAP would have worse DOS=20 > resistance that > >> PSK, which cases is EAP better? > >> > >> 3) It seems that most public access networks already=20 > provide an open > >> access network, why couldn't this network be used for emergency > >> communication? > >> > >> 4) What regulatory requirements are driving the need for=20 > encryption? > >> This creates some conflicts because encryption without=20 > authentication > >> does not satisfy most useful security requirements. > >> > >> As the 802.11u group is certainly aware, there are other=20 > groups within > >> the IETF that are looking at unauthenticated emergency=20 > services. In > >> particular, the ECRIT group within the IETF has ongoing=20 > work in this > >> area: > >> > >>=20 > http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthentic > ated-acces > >> s-00 > >> > >> We encourage IEEE working group members to continue the=20 > discussion with > >> the IETF in the EMU and the ECRIT working groups. > > >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 09 10:57:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfGW4-0003ml-6H; Tue, 09 Oct 2007 10:57:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfGW2-0003jr-9N for ecrit@ietf.org; Tue, 09 Oct 2007 10:56:58 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfGW1-0005M4-9N for ecrit@ietf.org; Tue, 09 Oct 2007 10:56:58 -0400 Received: from ([139.76.131.87]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.31074306; Tue, 09 Oct 2007 10:56:36 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 9 Oct 2007 10:56:36 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 9 Oct 2007 10:56:35 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Oct 2007 10:56:33 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA05E35018@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Phonebcp-02 comments (mostly substantive) thread-index: AcgKhJTr0zHxwx+1RTyIEdcW1tp1tw== From: "Stark, Barbara" To: X-OriginalArrivalTime: 09 Oct 2007 14:56:35.0699 (UTC) FILETIME=[967FFC30:01C80A84] X-Spam-Score: 0.2 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Subject: [Ecrit] Phonebcp-02 comments (mostly substantive) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Here are my mostly substantive comments on phonebcp-02. I'll send other comments separately. First, I'd like to say that Brian did an outstanding job on this document. It's really good. Barbara ---------- ED-11/SP-9 All emergency services specified in [I-D.ietf-ecrit-service-urn] MUST be recognized. Devices/Service Providers MUST be capable of recognizing all of the associated dial strings. Comment: Service Providers may only be able to recognize home strings. Nowhere is it required/recommended for end devices to provide SPs with their current location outside of an emergency call. It is also not required/recommended that SPs attempt to locate devices prior to an emergency call. This means that SPs that operate as core applications in the open Internet will have no ability to know the local dialstrings. Perhaps the last sentence of this requirement could read: "...all of the associated dial strings that known to them." --------- 6.5 End system location configuration I'd like to see an additional requirement along the lines of: ED-XX Endpoints using HELD to configure location for use with emergency services MUST set protocol parameters as follows:=20 - responseTime =3D emergencyRouting (when requesting a location for routing an emergency call) or - responseTime =3D emergencyDispatch (when requesting a location for emergency dispatch) ---------- ED-22 Endpoints SHOULD try all LCPs supported by the device in any order or in parallel. The first one that succeeds in supplying location can be used. Comment: Does this mean it is or isn't ok to stop after the first successful attempt? I think it should be ok to not do others if one succeeds. ----------- AN-14 Network administrators MUST take care in assigning IP addresses such that VPN address assignments can be distinguished from local devices (by subnet choice, for example), and LISs should not attempt to provide location to addresses that arrive via VPN connections. Comment: Would it be reasonable to have a similar requirement for that LISs should not provide location for enterprise gateways, or connections from other service providers? ----------- ED-26 For devices which are not expected to roam, refreshing on the order of once per day is RECOMMENDED. ED-27 For devices which roam, refresh of location 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. There can be instances in which a device is aware of when it moves, for example when it changes access points. When this type of event occurs, the device SHOULD refresh its location. Comment: I think an additional requirement is needed along the lines of: If location is configured as a PIDF-LO, the device MUST refresh location prior to the retention-expires value. If this value is not present, RFC 4119 says it must be assumed to be 24 hours. ------------ AN-21 Location validation of civic locations via LoST SHOULD be performed by the LIS before entering a location in its database. Comment: Why does it have to be via LoST? We have existing validation mechanisms that should continue to be valid. I'd like to strike "via LoST", or provide it as an example mechanism. Also we validate long before it gets to the LIS, so we wouldn't expect the LIS to do this. How about "Location validation of civic locations entered into a LIS database MUST be performed (e.g. via LoST)." I think this is a MUST and not a SHOULD. ------------- 6.10. Location validation I'd like to see an additional requirement along the lines of: ED-XX Endpoints MUST validate user-entered locations (Section 6.2.1) via LoST. Validation SHOULD be performed in conjunction with the LoST route query.=20 ------------- ED-39 If the LCP does not return location in the form of a PIDF-LO [RFC4119], the endpoint MUST map the location information it receives from the configuration protocol to a PIDF-LO. Comment: Have we decided whether we need more guidance on geo format conversion? Can we reference that guidance for converting civic format is in RFC 4776 for DHCP and in the LLDP-MED spec? -------------- ED-44/AN-25/SP-23 Uninitialized devices SHOULD NOT be capable of placing an emergency call unless local regulations require it. Comment: I'd like to see better definition of what you mean by "uninitialized device". I'd like to see this term in framework terminology section (and I'll make that comment against framework). From framework, I gather that uninitialized devices are "not registered, or that don't have valid call back identifiers". Does this mean that a device that registers against an Asterisk server in my basement is "initialized"? Should the "or" in the definition be "and" (i.e., valid call back is required to be considered initialized)? I'll put this whole comment in framework, but may need to revisit these requirements based on what's decided there. Probably not, though. --------------- ED-47/SP-26 Uninitialized devices MUST include identifiers in the signaling that can be used by the service provider to identify the device and to allow filtering of calls from the device by the PSAP/ ESRP. Comment: Since this is a must, is there any recommendation as to what sort of ID needs to be included? --------------- SP-27 All proxies in the outbound path SHOULD recognize emergency calls with a Request URI of the service URN in the "sos" tree. An endpoint places a service URN in the Request URI to indicate that the endpoint understood the call was an emergency call. A proxy that processes such a call looks for the presence of a Route header with a URI of a PSAP. Absence of such a Route header indicates the UAC was unable to invoke LoST and the proxy MUST perform the LoST mapping and insert a Route header with the URI obtained. Comment: What does a PSAP URI look like (since the proxy is expected to look for the presence of such a thing)? Or is the proxy really only expected to look for a non-null and routable URI in the Route header? --------------- ED-55/SP-32 sips: MUST be specified when attempting to signal an emergency call with SIP. Comment: If the device is configured to do SIP over IPsec, is TLS still needed? I'm also concerned as to whether this is really practical -- I'd prefer for the device to make all calls (including emergency calls) the way it's been configured to make calls.=20 --------------- ED-60 The initial SIP signaling Method is an INVITE:=20 5. A Route: header SHOULD be present with a PSAP URI obtained from LoST (see Section 8) and the loose route parameter. A sips URI [RFC3261] SHOULD be specified, unless the operation must be retried due to a failure to establish a TLS connection. If the device does not do dial plan interpretation, no Route: header will be present. Comment: A Route header would also not be present if LoST failed, even if it did do dial plan interpretation? ---------------- 11. If a device understands the SIP Location Conveyance extension and supports LoST [I-D.ietf-ecrit-lost] then whichever location is used for routing the message towards the PSAP or ESRP, even if there is only one, the Geolocation "message-routed-on- this- uri" header parameter SHOULD be added to the corresponding URI in the Geolocation header. Comment: Why isn't this a MUST? ---------------- SP-35 SIP Proxy servers processing emergency calls: 1. If the proxy does dial plan interpretation on behalf of user agents, the proxy MUST look for the local emergency dialstring at the location of the end device and MAY look for the home dialstring. =20 Comment: Same as my first comment about SPs not knowing local dialstrings. Since the device probably didn't include location in the SIP INVITE, these means the SP will likely use the default location on record, and will only recognize dialstrings associated with that location. ------------------ SP-35 SIP Proxy servers processing emergency calls: 1. If the proxy does dial plan interpretation on behalf of user agents, the proxy MUST look for the local emergency dialstring at the location of the end device and MAY look for the home dialstring. If it finds it, the proxy MUST: * Add a Route header with the service URN appropriate for the emergency dialstring. * Replace the Request-URI (which was the dialstring) with the PSAP URI obtained from LoST. Comment: Are these backwards? Should the Request-URI be the service URN and the Route header be the PSAP URI? ------------------- 13. Disabling of features Comment: I'm really not comfortable with disabling features without properly thinking through scenarios where they might be useful, and then proving they aren't needed or can be worked around. I want to avoid the Law of Unintended Consequences. I think this is probably the only big issue that remains in this document (for me). I'll start a discussion on the list. ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA623 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 09 11:02:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfGb2-00060D-Ob; Tue, 09 Oct 2007 11:02:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfGb0-0005rZ-Ve for ecrit@ietf.org; Tue, 09 Oct 2007 11:02:06 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfGau-0002NR-LK for ecrit@ietf.org; Tue, 09 Oct 2007 11:02:06 -0400 Received: from ([139.76.131.91]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.31075092; Tue, 09 Oct 2007 11:01:26 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 9 Oct 2007 11:01:26 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 9 Oct 2007 11:01:26 -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, 9 Oct 2007 11:01:25 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA05E35023@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Phonebcp-02 comments (mostly semantics) Thread-Index: AcgKhULxHdovUqRGRr23P1mJXfS7cA== From: "Stark, Barbara" To: X-OriginalArrivalTime: 09 Oct 2007 15:01:26.0417 (UTC) FILETIME=[43C80810:01C80A85] X-Spam-Score: 0.2 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Ecrit] Phonebcp-02 comments (mostly semantics) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Following are my mostly semantic comments on phonebcp-02. I also have a Word document that includes all my purely editorial comments. Unless others want to see those, I'll just send that directly to the editors. Barbara -------------------------------- ED-18 Endpoints SHOULD do location configuration themselves. This sentence is awkward, both in wording, and in since it doesn't seem to agree with requirements in 6.5. 6.5 says endpoints MUST support all those techniques. Should 6.5 says "Endpoints that support methods for location configuration MUST...", and should this say "Endpoints SHOULD support location configuration as described in Section 6.5."? Or should both requirements be a must? --------------------------------- ED-32/AN-19 The LIS SHOULD provide a location reference which permits a subscription with appropriate filtering. Does this mean the LIS should always provide? Or should be able to provide, either when requested, or per LIS policy? ---------------------------------- ED-61/SP-38 During the course of an emergency call, devices and proxies MUST support REFER transactions and the Referred-by: header [RFC3515] to: 2. Be REFERed to a secondary PSAP. Some responder's dispatchers are not located in the primary PSAP. The call may have to be transferred to another PSAP. Most often this will be an attended transfer, or a bridged transfer.(For devices that are Mobile). Does the parenthetic (about devices that are mobile) apply to the entire requirement, or does it imply that only mobile devices will do bridged transfer? The intent of the parenthetic is unclear. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 10 13:47:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iffdr-0000lj-HA; Wed, 10 Oct 2007 13:46:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iffdo-0000jo-QR; Wed, 10 Oct 2007 13:46:40 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iffdn-0002FX-IY; Wed, 10 Oct 2007 13:46:40 -0400 X-IronPort-AV: E=Sophos;i="4.21,255,1188802800"; d="scan'208";a="11732472" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 10 Oct 2007 10:46:39 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9AHkcuY006477; Wed, 10 Oct 2007 10:46:38 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l9AHkZpH008689; Wed, 10 Oct 2007 17:46:35 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 10:46:32 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.70.12]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Oct 2007 10:46:31 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 10 Oct 2007 12:46:29 -0500 To: "Dan Warren" , "yanglili 60087" , "Rathod Subhashchandra" From: "James M. Polk" In-Reply-To: <6918D1F7F8770C4FB182838A7BDFD6C8017CD659@GSMDUBEX02.GSM.TL D> References: <6918D1F7F8770C4FB182838A7BDFD6C8017CD659@GSMDUBEX02.GSM.TLD> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: X-OriginalArrivalTime: 10 Oct 2007 17:46:31.0649 (UTC) FILETIME=[7E2C3D10:01C80B65] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2035; t=1192038398; x=1192902398; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Sip]=20URI=20for=20Emergency=20call? |Sender:=20; bh=5YQFobhlu+MgHIanu+kmtPYE+lDT03PKVIT8DDsjsf4=; b=jqp2C70F8WPR7YIfy+WNMWEMIri5JYYcqWYWrB4EvWPnOA6rnJRyVl19xgx/thoNj9tSZLXJ dTGxFhu/2FHR7NU1Mswfj+cSc1RIX4Vnxgngv6yJlB5bZMKe1IvxU3gUMziDAIPQAROZrZE74I RqeYwflRFCbixfHPhWHtLkYr8=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: sip@ietf.org, "'ecrit@ietf.org'" , Sip-implementors@lists.cs.columbia.edu Subject: [Ecrit] RE: [Sip] URI for Emergency call? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This discussion belongs on the ECRIT list, since=20 you're asking questions about an ECRIT document http://www.ietf.org/html.charters/ecrit-charter.html [I've added ecrit added here, but kept sip on=20 this message to make sure all who read this=20 message on the sip list know this thread should move lists] At 05:06 AM 10/10/2007, Dan Warren wrote: >Content-class: urn:content-classes:message >Content-Type: text/plain; > charset=3D"UTF-8" > > Does this imply then that all IMS subscriber=20 > profiles have to include this IMPU? Or is it=20 > expected that the IMPU is configured on all=20 > devices and is routed by rote in the network? > >Dan > > > -----Original Message----- > > From: yanglili 60087 [mailto:kadyyang@huawei.com] > > Sent: 10 October 2007 10:07 > > To: Rathod Subhashchandra > > Cc: sip@ietf.org; Sip-implementors@lists.cs.columbia.edu > > Subject: =E5=9B=9E=E5=A4=8D:[Sip] URI for Emergency call? > > > > Hi > > > > The Service URN is used for the request-URI. > > > > And the 'sip:user@sos.domain' is the IMPU of the originated user. > > > > Hope this helps. > > > > Cheers > > Lili Yang > > Huawei Technologies > > >Forthcoming GSMA Events: GSMA Mobile Asia=20 >Congress Macau 12 - 15 November 2007=20 >www.mobileasiacongress.com GSMA Mobile World=20 >Congress Barcelona 11 - 14 February 2008=20 >www.mobileworldcongress.com This email and its=20 >attachments are intended for the above named=20 >only and may be confidential. If they have come=20 >to you in error you must take no action based on=20 >them, nor must you copy or show them to anyone;=20 >please reply to this email or call +44 207 759=20 >2300 and highlight the error= _______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 10 18:57:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfkT8-00063T-J9; Wed, 10 Oct 2007 18:55:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfkT7-00063O-Db for ecrit@ietf.org; Wed, 10 Oct 2007 18:55:57 -0400 Received: from sea-mimesweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfkT1-000485-50 for ecrit@ietf.org; Wed, 10 Oct 2007 18:55:57 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Wed, 10 Oct 2007 15:55:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [ECRIT] wg milestone updates Date: Wed, 10 Oct 2007 15:55:38 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657508613C47@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ECRIT] wg milestone updates Thread-Index: AcgLTZWRcGuXQsumSbWMWI7jk6H1jgADKgNQAA13x0A= From: "Roger Marshall" To: "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At the last IETF meeting, the ECRIT workgroup (& chairs) agreed that we should update the milestone dates. The following is what is proposed: --- Goals and Milestones* * (Indicates date that the document is submitted to the IESG.) Done Informational RFC containing terminology definitions and the requirements Done An Informational document describing the threats and security considerations Done A Standards Track RFC describing how to identify a session set-up request is to an emergency response center Done A Standards Track RFC describing how to route an emergency call based on location information Done An Informational document describing the Mapping Protocol Architecture Feb 2008 An Informational document describing the ECRIT Framework Feb 2008 A BCP document describing the emergency call support for devices --- Please post any comments to the ecrit list. Thanks. -roger marshall. =20 The information contained in this message may be privileged and/or confiden= tial. If you are not the intended recipient, or responsible for delivering = this message to the intended recipient, any review, forwarding, disseminati= on, distribution or copying of this communication or any attachment(s) is s= trictly prohibited. If you have received this message in error, please so n= otify the sender immediately, and delete it and all attachments from your c= omputer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 11 00:10:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfpME-0008LQ-G0; Thu, 11 Oct 2007 00:09:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfpMD-0008Jj-2N for ecrit@ietf.org; Thu, 11 Oct 2007 00:09:09 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfpM9-0008F6-MB for ecrit@ietf.org; Thu, 11 Oct 2007 00:09:05 -0400 X-SEF-Processed: 5_0_0_910__2007_10_10_23_19_01 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 10 Oct 2007 23:19:00 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Oct 2007 23:09: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: Wed, 10 Oct 2007 23:09:02 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-winterbottom-ecrit-specifying-holes-00 Thread-Index: AcgLvHVFdzvDolFNTT6YEpOiZ5CBJA== From: "Winterbottom, James" To: "ecrit" X-OriginalArrivalTime: 11 Oct 2007 04:09:04.0687 (UTC) FILETIME=[765183F0:01C80BBC] X-Spam-Score: 1.8 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Ecrit] draft-winterbottom-ecrit-specifying-holes-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org FYI,=0D=0A=0D=0A=0D=0AA new version of I-D, draft-winterbottom-ecrit-specif= ying-holes-00.txt=0D=0Ahas been successfully submitted by James Winterbotto= m and posted to the=0D=0AIETF repository.=0D=0A=0D=0AFilename:=09 draft-win= terbottom-ecrit-specifying-holes=0D=0ARevision:=09 00=0D=0ATitle:=09=09 Spe= cifying Holes in LoST Service Boundaries=0D=0ACreation_date:=09 2007-10-11=0D= =0AWG ID:=09=09 Independent Submission=0D=0ANumber_of_pages: 16=0D=0A=0D=0A= Abstract:=0D=0AThis document describes how holes can be specified in servic= e=0D=0Aboundaries. One means of implementing a solution is described.=0D=0A=0D= =0Ahttp://tools.ietf.org/html/draft-winterbottom-ecrit-specifying-holes-00=0D= =0A=0D=0A=0D=0A------------------------------------------------------------= ------------------------------------=0D=0AThis message is for the designate= d recipient only and may=0D=0Acontain privileged, proprietary, or otherwise= private information. =20=0D=0AIf you have received it in error, please not= ify the sender=0D=0Aimmediately and delete the original. Any unauthorized = use of=0D=0Athis email is prohibited.=0D=0A--------------------------------= ----------------------------------------------------------------=0D=0A[mf2]=0D= =0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 11 04:21:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IftHE-0003lt-Cq; Thu, 11 Oct 2007 04:20:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IftHC-0003js-Mn for ecrit@ietf.org; Thu, 11 Oct 2007 04:20:14 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IftH5-000576-My for ecrit@ietf.org; Thu, 11 Oct 2007 04:20:14 -0400 Received: from [194.72.13.18] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IftGo-0004Mf-2a; Thu, 11 Oct 2007 03:19:51 -0500 From: "Brian Rosen" To: "'James M. Polk'" , "'Dan Warren'" , "'yanglili 60087'" , "'Rathod Subhashchandra'" References: <6918D1F7F8770C4FB182838A7BDFD6C8017CD659@GSMDUBEX02.GSM.TLD> Subject: RE: [Ecrit] RE: [Sip] URI for Emergency call? Date: Thu, 11 Oct 2007 04:19:51 -0400 Message-ID: <068b01c80bdf$80bc0f40$240118ac@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgLZaGMgbAmdgXBTs6etD2xRFcEGwAePSVw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ecrit@ietf.org, Sip-implementors@lists.cs.columbia.edu X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'm not an IMS expert, so I'm not going to comment on IMPUs, but let me = point out that in countries that do not have a single emergency number, = support for the individual emergency service numbers, and their = corresponding service URNs is required. This means that mapping 1-1-2 to urn:service:sos is required but you = might also need to map: 1-1-7 to urn:service:sos.police 1-1-8 to urn:service:sos.fire . . . Brian > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Wednesday, October 10, 2007 1:46 PM > To: Dan Warren; yanglili 60087; Rathod Subhashchandra > Cc: sip@ietf.org; 'ecrit@ietf.org'; = Sip-implementors@lists.cs.columbia.edu > Subject: [Ecrit] RE: [Sip] URI for Emergency call? >=20 > This discussion belongs on the ECRIT list, since > you're asking questions about an ECRIT document >=20 > http://www.ietf.org/html.charters/ecrit-charter.html >=20 > [I've added ecrit added here, but kept sip on > this message to make sure all who read this > message on the sip list know this thread should move lists] >=20 > At 05:06 AM 10/10/2007, Dan Warren wrote: > >Content-class: urn:content-classes:message > >Content-Type: text/plain; > > charset=3D"UTF-8" > > > > Does this imply then that all IMS subscriber > > profiles have to include this IMPU? Or is it > > expected that the IMPU is configured on all > > devices and is routed by rote in the network? > > > >Dan > > > > > -----Original Message----- > > > From: yanglili 60087 [mailto:kadyyang@huawei.com] > > > Sent: 10 October 2007 10:07 > > > To: Rathod Subhashchandra > > > Cc: sip@ietf.org; Sip-implementors@lists.cs.columbia.edu > > > Subject: =C3=A5=E2=80=BA=C5=BE=C3=A5=C2=A4=C2=8D:[Sip] URI for = Emergency call? > > > > > > Hi > > > > > > The Service URN is used for the request-URI. > > > > > > And the 'sip:user@sos.domain' is the IMPU of the originated user. > > > > > > Hope this helps. > > > > > > Cheers > > > Lili Yang > > > Huawei Technologies > > > > >Forthcoming GSMA Events: GSMA Mobile Asia > >Congress Macau 12 - 15 November 2007 > >www.mobileasiacongress.com GSMA Mobile World > >Congress Barcelona 11 - 14 February 2008 > >www.mobileworldcongress.com This email and its > >attachments are intended for the above named > >only and may be confidential. If they have come > >to you in error you must take no action based on > >them, nor must you copy or show them to anyone; > >please reply to this email or call +44 207 759 > >2300 and highlight the error > _______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sipping@ietf.org for new developments on the application of sip >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 11 04:30:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IftQS-0005FQ-G0; Thu, 11 Oct 2007 04:29:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IftQQ-0005FD-I3 for ecrit@ietf.org; Thu, 11 Oct 2007 04:29:46 -0400 Received: from ns6.neustar.com ([156.154.16.88] helo=va.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IftQQ-0008AE-9r for ecrit@ietf.org; Thu, 11 Oct 2007 04:29:46 -0400 Received: from ([10.31.13.50]) by stihiron2.va.neustar.com with ESMTP id 5202732.2206993; Thu, 11 Oct 2007 04:29:36 -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: Thu, 11 Oct 2007 04:29:34 -0400 Message-ID: <31D151A3D66E404AACBBB0247ACA54A745FE62@STNTEXCH11.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: urn:service:sos.ambulance thread-index: AcgL4NqW8BNSShHrSTCrCBvESsERQQ== From: "Rosen, Brian" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Ecrit] urn:service:sos.ambulance X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org There is a "typo" in draft-ietf-ecrit-service-urn-07 In section 4.4, there is no registration for sos.ambulance. I don't know how we missed that, but we did. The description is provided in 4.2, but it's not in the IANA registration request (4.4). It's on the RFC Editor's queue. Can this be fixed there? Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 11 13:34:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig1ud-0001Rp-LZ; Thu, 11 Oct 2007 13:33:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig1ub-0001PF-Vq for ecrit@ietf.org; Thu, 11 Oct 2007 13:33:30 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ig1ub-0007Rg-JF for ecrit@ietf.org; Thu, 11 Oct 2007 13:33:29 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9BHXSom030940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 Oct 2007 10:33:28 -0700 Received: from [98.207.5.180] (vpn-10-50-0-170.qualcomm.com [10.50.0.170]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9BHXQv9019333; Thu, 11 Oct 2007 10:33:27 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <31D151A3D66E404AACBBB0247ACA54A745FE62@STNTEXCH11.cis.neustar.com> References: <31D151A3D66E404AACBBB0247ACA54A745FE62@STNTEXCH11.cis.neustar.com> Date: Thu, 11 Oct 2007 10:33:25 -0700 To: "Rosen, Brian" , From: Ted Hardie Subject: Re: [Ecrit] urn:service:sos.ambulance Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 4:29 AM -0400 10/11/07, Rosen, Brian wrote: >There is a "typo" in draft-ietf-ecrit-service-urn-07 >In section 4.4, there is no registration for sos.ambulance. > >I don't know how we missed that, but we did. The description is >provided in 4.2, but it's not in the IANA registration request (4.4). > >It's on the RFC Editor's queue. Can this be fixed there? > >Brian > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit Probably; you need to get approval from the shepharding AD to fix it after IESG processing. Note that the IANA processing is done prior to the RFC Editor's, so you may want to drop a note to IANA now. Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 12 17:04:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgRfV-0004SQ-Q7; Fri, 12 Oct 2007 17:03:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgRfT-0003zq-Nd for ecrit@ietf.org; Fri, 12 Oct 2007 17:03:35 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgRfG-00050J-Co for ecrit@ietf.org; Fri, 12 Oct 2007 17:03:27 -0400 Received: from ([139.76.131.83]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.31393710; Fri, 12 Oct 2007 17:02:46 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 12 Oct 2007 17:02:46 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 12 Oct 2007 17:02:46 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Date: Fri, 12 Oct 2007 17:02:45 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on framework-03 thread-index: AcgNEz0H4eY/i76RRpipY75+8p1o8w== From: "Stark, Barbara" To: X-OriginalArrivalTime: 12 Oct 2007 21:02:46.0809 (UTC) FILETIME=[3D8A9090:01C80D13] X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [Ecrit] Comments on framework-03 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This is also a good document, and I only have a few comments. I have a Word document with all the editorial/grammatical comments, that I'll send directly to the authors (everyone should try typing "uninitialized" 20 times, fast). Barbara --------------- Terminology I recommend including "Uninitialized Device" in the terminology section. Uninitialized Device: A device that is not registered, or that doesn't have valid call back identifiers. (??) [Should this be an "or" or an "and"? I stole this from later in the text, but to be honest, I'm not really sure what the definition is.] ---------------- 3. Overview of how emergency calls are placed o It determines the PSAP's URI by querying the LoST mapping server with its location. I recommend slightly modifying to include updating location, too: "It updates its location, using the same methods as before, and updates the cached PSAP URI by..." ----------------- 6.3. Who adds location, endpoint or proxy The calling network must provide another way for the device to learn the local dial string (and update it when the user moves to a location where the dial string(s) change) or do the dial string determination itself. This would be nice. It works well in current cellular environments, but isn't practical in an open Internet environment. I'd like to see the verbiage toned back a little. Similar comment made against phonebcp. ------------------ 6.10. Location validation "Test functions (Section 15) should also re-validate." I don't understand what it is that this sentence says test functions should do. Section 15 doesn't discuss location validation. Or is the successful execution of a test a form of validation? ------------------ 6.12. Other location considerations "Although support of TLS is mandatory in [RFC3261], many devices do not support it. Implementing location conveyance in SIP mandates inclusion of TLS support." RFC 3261 says "It is strongly RECOMMENDED that UAs be capable initiating TLS". That doesn't quite sound like mandatory, to me. I'm aware of many devices that intend to support IPsec, and not TLS. Anyway, I don't think the 2nd sentence quoted above is true. ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA622 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 15 08:42:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhPG3-0008W7-0G; Mon, 15 Oct 2007 08:41:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhPG1-0008Vw-Pt for ecrit@ietf.org; Mon, 15 Oct 2007 08:41:17 -0400 Received: from mu-out-0910.google.com ([209.85.134.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhPFs-0007RP-29 for ecrit@ietf.org; Mon, 15 Oct 2007 08:41:17 -0400 Received: by mu-out-0910.google.com with SMTP id w8so1716147mue for ; Mon, 15 Oct 2007 05:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Fp+hkd2ZlW7P2LLsO9W8shjHCEV4sRtSycmjppNICgE=; b=U2SmtDA15a1fFLS7VftQbxnnmZEVvqQmRKxfHQjQO6j1yzA+roaQXB9vRNmGhn+oECZB8lne/RARnfd+wMZ2WL0L53F/C9nkBu4HN8+KLny1JNXGBiwiL8RnD/ryqWIZhuGjX6OccI4kbKrZLk8R87WVAo6j9F1g7N1fSdJhBkQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gxMZanGC/JKtdhqBHNQ+5r9RbjWUkVaqv1o5YtaqFKRWuLvFbp/LvLdSKxEiHZhtfol9cYPd2Ixw1qJJE3ynOWYPM4P2EAk6Ut9onJBmoSlGO7Q7geRO6v82ksNRtoM5/vMfssmXFkrKu7WonJf3P/05uRpT2jH7sAa5Jx4DtWQ= Received: by 10.82.172.10 with SMTP id u10mr11042103bue.1192452039768; Mon, 15 Oct 2007 05:40:39 -0700 (PDT) Received: by 10.82.182.9 with HTTP; Mon, 15 Oct 2007 05:40:39 -0700 (PDT) Message-ID: Date: Mon, 15 Oct 2007 14:40:39 +0200 From: "Karl Heinz Wolf" To: ecrit@ietf.org Subject: Re: [Ecrit] Comments on framework-03 In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I read the framework document, too. Except editorial comments, I have one problem with recognizing emergency calls and dial strings. The framework document says: 1) Users are not expected to "dial" an emergency URN. 2) Having the home dial string work is optional. 3) The LoST response may contain the dial string for emergency calls appropriate for the location provided. Now, how can a user place an emergency call when the UA supports no home dial string and the LoST response does not contain the visited dial string? Do I get here something wrong? Karl Heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 15 09:15:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhPmU-0002bJ-1u; Mon, 15 Oct 2007 09:14:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhPmS-0002ZB-8d for ecrit@ietf.org; Mon, 15 Oct 2007 09:14:48 -0400 Received: from demumfd002.nsn-inter.net ([217.115.75.234]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhPmR-0002JA-Oq for ecrit@ietf.org; Mon, 15 Oct 2007 09:14:48 -0400 Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id l9FDEkJc018263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Oct 2007 15:14:46 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id l9FDEkxq023182; Mon, 15 Oct 2007 15:14:46 +0200 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 15:14:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Comments on framework-03 Date: Mon, 15 Oct 2007 15:14:45 +0200 Message-ID: <5FB585F183235B42A9E70095055136FB3AB2C9@DEMUEXC012.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on framework-03 Thread-Index: AcgPKVX1l/62w31pSROUrAmtGADSpgAA5C1g References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> From: "Tschofenig, Hannes (NSN - DE/Munich)" To: "ext Karl Heinz Wolf" , X-OriginalArrivalTime: 15 Oct 2007 13:14:46.0065 (UTC) FILETIME=[5B5A5210:01C80F2D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hallo Karl Heinz,=20 > I read the framework document, too. Except editorial comments, I have > one problem with recognizing emergency calls and dial strings. The > framework document says: >=20 > 1) Users are not expected to "dial" an emergency URN. >=20 That's true because the emergency URN is somewhat difficult to dial compared to an emergency dial string.=20 urn:service:sos.police vs. 911 > 2) Having the home dial string work is optional. >=20 I wonder why this is stated in the document given that it is quite easy to accomplished.=20 > 3) The LoST response may contain the dial string for emergency calls > appropriate for the location provided. Right. This is for the visited emergency dial string.=20 >=20 > Now, how can a user place an emergency call when the UA supports no > home dial string and the LoST response does not contain the visited > dial string? >=20 > Do I get here something wrong? I need to check whether the document indeed says that the home emergency dial string is optional. It shouldn't.=20 Ciao Hannes > Karl Heinz >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 15 09:33:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQ3r-0000rL-Em; Mon, 15 Oct 2007 09:32:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQ3p-0000rC-Fb for ecrit@ietf.org; Mon, 15 Oct 2007 09:32:45 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhQ3p-0002uU-7I for ecrit@ietf.org; Mon, 15 Oct 2007 09:32:45 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IhQ3g-0006WL-Mu; Mon, 15 Oct 2007 08:32:37 -0500 From: "Brian Rosen" To: "'Tschofenig, Hannes \(NSN - DE/Munich\)'" , "'ext Karl Heinz Wolf'" , References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <5FB585F183235B42A9E70095055136FB3AB2C9@DEMUEXC012.nsn-intra.net> Subject: RE: [Ecrit] Comments on framework-03 Date: Mon, 15 Oct 2007 09:32:41 -0400 Message-ID: <03db01c80f2f$de436f20$8d0d1f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <5FB585F183235B42A9E70095055136FB3AB2C9@DEMUEXC012.nsn-intra.net> Thread-Index: AcgPKVX1l/62w31pSROUrAmtGADSpgAA5C1gAABuaNA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > Do I get here something wrong? > I need to check whether the document indeed says that the home emergency > dial string is optional. It shouldn't. Yes, it's optional. The local (visited) one is required. Home is not. When you roam to London, you dial 9-9-9, not your home number. Supporting the home number is "nice to have". Supporting the local number is a hard requirement, sometimes a legal requirement. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 15 09:34:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQ5L-0001Aw-Ci; Mon, 15 Oct 2007 09:34:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQ5J-0001Af-M9 for ecrit@ietf.org; Mon, 15 Oct 2007 09:34:17 -0400 Received: from fk-out-0910.google.com ([209.85.128.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhQ5D-0000Rg-G0 for ecrit@ietf.org; Mon, 15 Oct 2007 09:34:17 -0400 Received: by fk-out-0910.google.com with SMTP id z23so1515759fkz for ; Mon, 15 Oct 2007 06:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=D/edrDBSh5B9tecVulT2uQFNWWbly9AiJQ5yOgsoQ0o=; b=ECcU80XXm8xpplRl5RlAUp62CkUVKg6Flni0ULTqECRSSYydT/tnXjCBFHeAs8H7iVWOCTVRqwZTHtBHP/nFO/y3b6ifLFuAMXSMAX3VH8D1U9YUe6x89bfLuRpTOUoNuZxgaBq8t6LAIbFmnC4eGWBtu7lQ1SKn+MvxiqUfT7U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Qh0oR2X04tGD6h8k3X752aGi0JvD26mgmuZm0WjnEPJRwh5BoKZn3DeYbj1jPxyGDejlaGOdC03bhWPZmp/rJW7Qupcvtebd/JpFeAJqCTV949TnmkHiLfInfZ1pJcfwaGNvNZhETF4UBizzvqiP7fnR7l5VXGOKcUfXPFZOr90= Received: by 10.82.111.8 with SMTP id j8mr11183294buc.1192455234968; Mon, 15 Oct 2007 06:33:54 -0700 (PDT) Received: by 10.82.182.9 with HTTP; Mon, 15 Oct 2007 06:33:54 -0700 (PDT) Message-ID: Date: Mon, 15 Oct 2007 15:33:54 +0200 From: "Karl Heinz Wolf" To: "Tschofenig, Hannes (NSN - DE/Munich)" Subject: Re: [Ecrit] Comments on framework-03 In-Reply-To: <5FB585F183235B42A9E70095055136FB3AB2C9@DEMUEXC012.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <5FB585F183235B42A9E70095055136FB3AB2C9@DEMUEXC012.nsn-intra.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On 10/15/07, Tschofenig, Hannes (NSN - DE/Munich) wrote: > Hallo Karl Heinz, > > > > I read the framework document, too. Except editorial comments, I have > > one problem with recognizing emergency calls and dial strings. The > > framework document says: > > > > 1) Users are not expected to "dial" an emergency URN. > > > That's true because the emergency URN is somewhat difficult to dial > compared to an emergency dial string. > > urn:service:sos.police vs. 911 Of course! > > > 2) Having the home dial string work is optional. > > > I wonder why this is stated in the document given that it is quite easy > to accomplished. Maybe because of dial plan conflicts of the home and visited country? > > > 3) The LoST response may contain the dial string for emergency calls > > appropriate for the location provided. > Right. This is for the visited emergency dial string. > But there is just a "may". The serviceNumber in Lost is optional. > > > > Now, how can a user place an emergency call when the UA supports no > > home dial string and the LoST response does not contain the visited > > dial string? > > > > Do I get here something wrong? > I need to check whether the document indeed says that the home emergency > dial string is optional. It shouldn't. Chapter 5, end of the 3. paragraph: "Having the home dial string work is optional." karl heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 15 09:48:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQIU-0006JG-Os; Mon, 15 Oct 2007 09:47:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQIT-0006Dm-4B for ecrit@ietf.org; Mon, 15 Oct 2007 09:47:53 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhQIM-0000xL-Vi for ecrit@ietf.org; Mon, 15 Oct 2007 09:47:53 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IhQHx-0001wd-2f; Mon, 15 Oct 2007 08:47:23 -0500 From: "Brian Rosen" To: "'Karl Heinz Wolf'" , References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> Subject: RE: [Ecrit] Comments on framework-03 Date: Mon, 15 Oct 2007 09:47:23 -0400 Message-ID: <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcgPKOVKG2WGhI/wRWGn7Hh6qnOSGAAAINSg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The problem with writing this text is that the big bad IMS is out there. IMS configures the local dial string into the UA not using LoST. It works because of the relationship between the visited network and the UA. That technique won't work in most other environments, because the relationships are different. I probably should make a pass through -phonebcp and find all the "SHOULDS" and have text in -framework (and/or -phonebcp) that covers the cases where it doesn't apply. The problem is that it leads to pretty awkward wording. Brian > -----Original Message----- > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > Sent: Monday, October 15, 2007 8:41 AM > To: ecrit@ietf.org > Subject: Re: [Ecrit] Comments on framework-03 > > I read the framework document, too. Except editorial comments, I have > one problem with recognizing emergency calls and dial strings. The > framework document says: > > 1) Users are not expected to "dial" an emergency URN. > > 2) Having the home dial string work is optional. > > 3) The LoST response may contain the dial string for emergency calls > appropriate for the location provided. > > Now, how can a user place an emergency call when the UA supports no > home dial string and the LoST response does not contain the visited > dial string? > > Do I get here something wrong? > Karl Heinz > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 15 09:59:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQT5-00006M-5q; Mon, 15 Oct 2007 09:58:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhQT3-0008JB-4S for ecrit@ietf.org; Mon, 15 Oct 2007 09:58:49 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhQSs-0003eV-NM for ecrit@ietf.org; Mon, 15 Oct 2007 09:58:39 -0400 Received: from ([139.76.131.87]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.186643222; Mon, 15 Oct 2007 09:58:14 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 15 Oct 2007 09:58:14 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 15 Oct 2007 09:58:13 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Subject: RE: [Ecrit] Comments on framework-03 Date: Mon, 15 Oct 2007 09:58:13 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA05FFC79D@crexc41p> In-Reply-To: <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on framework-03 thread-index: AcgPKOVKG2WGhI/wRWGn7Hh6qnOSGAAAINSgAAJbYwA= References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> From: "Stark, Barbara" To: "Brian Rosen" , "Karl Heinz Wolf" , X-OriginalArrivalTime: 15 Oct 2007 13:58:13.0884 (UTC) FILETIME=[6DBBEBC0:01C80F33] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hey! Not all IMS is big and bad. :) I assume you're referring to 3GPP access networks, and not necessarily IMS. Many companies intend to deploy IMS only within a core network (i.e., a home IMS), with no need for or dependency on the existence of a visited IMS network.=20 Barbara -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Monday, October 15, 2007 9:47 AM To: 'Karl Heinz Wolf'; ecrit@ietf.org Subject: RE: [Ecrit] Comments on framework-03 The problem with writing this text is that the big bad IMS is out there. IMS configures the local dial string into the UA not using LoST. It works because of the relationship between the visited network and the UA. That technique won't work in most other environments, because the relationships are different. I probably should make a pass through -phonebcp and find all the "SHOULDS" and have text in -framework (and/or -phonebcp) that covers the cases where it doesn't apply. The problem is that it leads to pretty awkward wording. =20 Brian > -----Original Message----- > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > Sent: Monday, October 15, 2007 8:41 AM > To: ecrit@ietf.org > Subject: Re: [Ecrit] Comments on framework-03 >=20 > I read the framework document, too. Except editorial comments, I have > one problem with recognizing emergency calls and dial strings. The > framework document says: >=20 > 1) Users are not expected to "dial" an emergency URN. >=20 > 2) Having the home dial string work is optional. >=20 > 3) The LoST response may contain the dial string for emergency calls > appropriate for the location provided. >=20 > Now, how can a user place an emergency call when the UA supports no > home dial string and the LoST response does not contain the visited > dial string? >=20 > Do I get here something wrong? > Karl Heinz >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA623 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 15 10:43:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhR9a-00063j-Ry; Mon, 15 Oct 2007 10:42:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhR9a-0005tm-1S for ecrit@ietf.org; Mon, 15 Oct 2007 10:42:46 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhR9P-0002xc-TO for ecrit@ietf.org; Mon, 15 Oct 2007 10:42:42 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l9FEfvZ3003874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Oct 2007 10:41:57 -0400 (EDT) In-Reply-To: <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Comments on framework-03 Date: Mon, 15 Oct 2007 10:43:27 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: -1.0 (-) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org My general observation is that a SHOULD in a document is underspecified unless there's a condition that indicates when the action asked for is not required. Omitting it is just punting. If you go by 2119, it also makes an implementation only conditionally compliant, even though there may be an alternate, equally-functional way of implementing a certain desirable outcome. In this particular case, we know the condition, so we should state it. It's not like IMS is some kind of secret. Henning On Oct 15, 2007, at 9:47 AM, Brian Rosen wrote: > The problem with writing this text is that the big bad IMS is out > there. > IMS configures the local dial string into the UA not using LoST. > > It works because of the relationship between the visited network > and the UA. > That technique won't work in most other environments, because the > relationships are different. > > I probably should make a pass through -phonebcp and find all the > "SHOULDS" > and have text in -framework (and/or -phonebcp) that covers the > cases where > it doesn't apply. > > The problem is that it leads to pretty awkward wording. > > Brian > >> -----Original Message----- >> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >> Sent: Monday, October 15, 2007 8:41 AM >> To: ecrit@ietf.org >> Subject: Re: [Ecrit] Comments on framework-03 >> >> I read the framework document, too. Except editorial comments, I have >> one problem with recognizing emergency calls and dial strings. The >> framework document says: >> >> 1) Users are not expected to "dial" an emergency URN. >> >> 2) Having the home dial string work is optional. >> >> 3) The LoST response may contain the dial string for emergency calls >> appropriate for the location provided. >> >> Now, how can a user place an emergency call when the UA supports no >> home dial string and the LoST response does not contain the visited >> dial string? >> >> Do I get here something wrong? >> Karl Heinz >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 15 10:52:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhRIk-0001EC-MK; Mon, 15 Oct 2007 10:52:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhRIi-0001Ba-OM for ecrit@ietf.org; Mon, 15 Oct 2007 10:52:12 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhRIh-0003Pc-Ht for ecrit@ietf.org; Mon, 15 Oct 2007 10:52:12 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IhRIY-0002Sl-6S; Mon, 15 Oct 2007 09:52:02 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> Subject: RE: [Ecrit] Comments on framework-03 Date: Mon, 15 Oct 2007 10:52:05 -0400 Message-ID: <03e801c80f3a$f62615b0$8d0d1f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcgPOY/KNgJlhzlDTYSnTJyHwm62kgAAQjKQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org You are, of course, correct. And you did write "too many SHOULDs" in your last edit, which I actually read as "too many SHOULDs without an explanation of why they are not MUSTs". I guess I have to make a pass through and address those. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, October 15, 2007 10:43 AM > To: Brian Rosen > Cc: 'Karl Heinz Wolf'; ecrit@ietf.org > Subject: Re: [Ecrit] Comments on framework-03 > > My general observation is that a SHOULD in a document is > underspecified unless there's a condition that indicates when the > action asked for is not required. Omitting it is just punting. If you > go by 2119, it also makes an implementation only conditionally > compliant, even though there may be an alternate, equally-functional > way of implementing a certain desirable outcome. In this particular > case, we know the condition, so we should state it. It's not like IMS > is some kind of secret. > > Henning > > On Oct 15, 2007, at 9:47 AM, Brian Rosen wrote: > > > The problem with writing this text is that the big bad IMS is out > > there. > > IMS configures the local dial string into the UA not using LoST. > > > > It works because of the relationship between the visited network > > and the UA. > > That technique won't work in most other environments, because the > > relationships are different. > > > > I probably should make a pass through -phonebcp and find all the > > "SHOULDS" > > and have text in -framework (and/or -phonebcp) that covers the > > cases where > > it doesn't apply. > > > > The problem is that it leads to pretty awkward wording. > > > > Brian > > > >> -----Original Message----- > >> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > >> Sent: Monday, October 15, 2007 8:41 AM > >> To: ecrit@ietf.org > >> Subject: Re: [Ecrit] Comments on framework-03 > >> > >> I read the framework document, too. Except editorial comments, I have > >> one problem with recognizing emergency calls and dial strings. The > >> framework document says: > >> > >> 1) Users are not expected to "dial" an emergency URN. > >> > >> 2) Having the home dial string work is optional. > >> > >> 3) The LoST response may contain the dial string for emergency calls > >> appropriate for the location provided. > >> > >> Now, how can a user place an emergency call when the UA supports no > >> home dial string and the LoST response does not contain the visited > >> dial string? > >> > >> Do I get here something wrong? > >> Karl Heinz > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 16 04:08:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhhTG-0002dv-AA; Tue, 16 Oct 2007 04:08:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhhTF-0002d4-Hl for ecrit@ietf.org; Tue, 16 Oct 2007 04:08:09 -0400 Received: from mu-out-0910.google.com ([209.85.134.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhhT9-0000xL-7h for ecrit@ietf.org; Tue, 16 Oct 2007 04:08:09 -0400 Received: by mu-out-0910.google.com with SMTP id w8so2081191mue for ; Tue, 16 Oct 2007 01:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=NzaT+PPw9yLPCw6Au3KnrXFbU+DE3jQflpwd+Y62JDc=; b=nobJ4hTG1m/EXrID/QBqgs90I+s1/z/FTyaPieTBiCkOhi5IhT/4txFr4SqQLFy/1zfEEcrCOeZmagjhPR7K+qt3RtrDgcoLolMATofmSIAxjI9nGP1Zwj/j22n1rNR6tD752k4N9um206/9QX3DXxOIbjTZZjCTtqCpdKBddE0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fulaS0O4APs7b4CLa1LSLyVxC5kRYWymMLnf8MnepyFlLMqUXVokzl4VZxQ+n88yDuZwY+woKZgdKqpesosc54uCaArzkSkSCK11u7vcDycw+mi+jxTMcWeypRW6Corkvq6/6qSpI3j8tsH3FCuShsLdBIbqTmj9LoZBf41o700= Received: by 10.82.177.3 with SMTP id z3mr13230399bue.1192522058115; Tue, 16 Oct 2007 01:07:38 -0700 (PDT) Received: by 10.82.182.9 with HTTP; Tue, 16 Oct 2007 01:07:38 -0700 (PDT) Message-ID: Date: Tue, 16 Oct 2007 10:07:38 +0200 From: "Karl Heinz Wolf" To: ecrit@ietf.org Subject: Re: [Ecrit] Comments on framework-03 In-Reply-To: <03e801c80f3a$f62615b0$8d0d1f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> <03e801c80f3a$f62615b0$8d0d1f0a@cis.neustar.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Besides the troubles with home and visited dialplans, how can the visited dialstring be figured out if the LoST response not necessarily contains a dial string? karl heinz On 10/15/07, Brian Rosen wrote: > You are, of course, correct. > > And you did write "too many SHOULDs" in your last edit, which I actually > read as "too many SHOULDs without an explanation of why they are not MUSTs". > > I guess I have to make a pass through and address those. > > Brian > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Monday, October 15, 2007 10:43 AM > > To: Brian Rosen > > Cc: 'Karl Heinz Wolf'; ecrit@ietf.org > > Subject: Re: [Ecrit] Comments on framework-03 > > > > My general observation is that a SHOULD in a document is > > underspecified unless there's a condition that indicates when the > > action asked for is not required. Omitting it is just punting. If you > > go by 2119, it also makes an implementation only conditionally > > compliant, even though there may be an alternate, equally-functional > > way of implementing a certain desirable outcome. In this particular > > case, we know the condition, so we should state it. It's not like IMS > > is some kind of secret. > > > > Henning > > > > On Oct 15, 2007, at 9:47 AM, Brian Rosen wrote: > > > > > The problem with writing this text is that the big bad IMS is out > > > there. > > > IMS configures the local dial string into the UA not using LoST. > > > > > > It works because of the relationship between the visited network > > > and the UA. > > > That technique won't work in most other environments, because the > > > relationships are different. > > > > > > I probably should make a pass through -phonebcp and find all the > > > "SHOULDS" > > > and have text in -framework (and/or -phonebcp) that covers the > > > cases where > > > it doesn't apply. > > > > > > The problem is that it leads to pretty awkward wording. > > > > > > Brian > > > > > >> -----Original Message----- > > >> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > >> Sent: Monday, October 15, 2007 8:41 AM > > >> To: ecrit@ietf.org > > >> Subject: Re: [Ecrit] Comments on framework-03 > > >> > > >> I read the framework document, too. Except editorial comments, I have > > >> one problem with recognizing emergency calls and dial strings. The > > >> framework document says: > > >> > > >> 1) Users are not expected to "dial" an emergency URN. > > >> > > >> 2) Having the home dial string work is optional. > > >> > > >> 3) The LoST response may contain the dial string for emergency calls > > >> appropriate for the location provided. > > >> > > >> Now, how can a user place an emergency call when the UA supports no > > >> home dial string and the LoST response does not contain the visited > > >> dial string? > > >> > > >> Do I get here something wrong? > > >> Karl Heinz > > >> > > >> _______________________________________________ > > >> Ecrit mailing list > > >> Ecrit@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 16 04:34:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihhsq-0000xi-8M; Tue, 16 Oct 2007 04:34:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihhso-0000wx-7d for ecrit@ietf.org; Tue, 16 Oct 2007 04:34:34 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ihhsn-0001zN-Hx for ecrit@ietf.org; Tue, 16 Oct 2007 04:34:34 -0400 Received: (qmail invoked by alias); 16 Oct 2007 08:34:32 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp056) with SMTP; 16 Oct 2007 10:34:32 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+IiXV7V1aIVVMTIHMbNfRkyPG6VZ5BKs8Q9WRMSP GOboT1xrw/iUG+ Message-ID: <47147798.3090706@gmx.net> Date: Tue, 16 Oct 2007 11:34:32 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Karl Heinz Wolf Subject: Re: [Ecrit] Comments on framework-03 References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> <03e801c80f3a$f62615b0$8d0d1f0a@cis.neustar.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Karl Heinz Wolf wrote: > Besides the troubles with home and visited dialplans, how can the > visited dialstring be figured out if the LoST response not necessarily > contains a dial string? > > LoST is the mechanism to obtain the visited emergency dial string. Ciao Hannes > karl heinz > > > On 10/15/07, Brian Rosen wrote: > >> You are, of course, correct. >> >> And you did write "too many SHOULDs" in your last edit, which I actually >> read as "too many SHOULDs without an explanation of why they are not MUSTs". >> >> I guess I have to make a pass through and address those. >> >> Brian >> >> >>> -----Original Message----- >>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>> Sent: Monday, October 15, 2007 10:43 AM >>> To: Brian Rosen >>> Cc: 'Karl Heinz Wolf'; ecrit@ietf.org >>> Subject: Re: [Ecrit] Comments on framework-03 >>> >>> My general observation is that a SHOULD in a document is >>> underspecified unless there's a condition that indicates when the >>> action asked for is not required. Omitting it is just punting. If you >>> go by 2119, it also makes an implementation only conditionally >>> compliant, even though there may be an alternate, equally-functional >>> way of implementing a certain desirable outcome. In this particular >>> case, we know the condition, so we should state it. It's not like IMS >>> is some kind of secret. >>> >>> Henning >>> >>> On Oct 15, 2007, at 9:47 AM, Brian Rosen wrote: >>> >>> >>>> The problem with writing this text is that the big bad IMS is out >>>> there. >>>> IMS configures the local dial string into the UA not using LoST. >>>> >>>> It works because of the relationship between the visited network >>>> and the UA. >>>> That technique won't work in most other environments, because the >>>> relationships are different. >>>> >>>> I probably should make a pass through -phonebcp and find all the >>>> "SHOULDS" >>>> and have text in -framework (and/or -phonebcp) that covers the >>>> cases where >>>> it doesn't apply. >>>> >>>> The problem is that it leads to pretty awkward wording. >>>> >>>> Brian >>>> >>>> >>>>> -----Original Message----- >>>>> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >>>>> Sent: Monday, October 15, 2007 8:41 AM >>>>> To: ecrit@ietf.org >>>>> Subject: Re: [Ecrit] Comments on framework-03 >>>>> >>>>> I read the framework document, too. Except editorial comments, I have >>>>> one problem with recognizing emergency calls and dial strings. The >>>>> framework document says: >>>>> >>>>> 1) Users are not expected to "dial" an emergency URN. >>>>> >>>>> 2) Having the home dial string work is optional. >>>>> >>>>> 3) The LoST response may contain the dial string for emergency calls >>>>> appropriate for the location provided. >>>>> >>>>> Now, how can a user place an emergency call when the UA supports no >>>>> home dial string and the LoST response does not contain the visited >>>>> dial string? >>>>> >>>>> Do I get here something wrong? >>>>> Karl Heinz >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>> >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 16 04:51:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihi7u-0006wr-Kv; Tue, 16 Oct 2007 04:50:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihi7s-0006f3-P1 for ecrit@ietf.org; Tue, 16 Oct 2007 04:50:08 -0400 Received: from fk-out-0910.google.com ([209.85.128.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihi7b-0002I4-E5 for ecrit@ietf.org; Tue, 16 Oct 2007 04:49:56 -0400 Received: by fk-out-0910.google.com with SMTP id z23so1776485fkz for ; Tue, 16 Oct 2007 01:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=N50ZDiceDeR3jNqsm3eZPp+i+zLsebvIsSI5ZfCqfq4=; b=dz7CgKt+ocGkeQAgvNOeM0Rgm0TttiGyimBZuuux9s0ROTgWl/aqWAkRL5SvJNPKP2mgimXtgVJM+l/fqDxticZuiNexL8GXVOp3ivjd6IUop6jTFwHMsfE5XAUvnIuLLMK2VAN+MPqt7kdmaZdmVqI3XYg+wfV2VXBo0zfZlsE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bj4NnnZt0QK3Z6Jq4qsGObFNEmSAXG+xbzDyx9e98RXDo6Sv1KXhNLjuGFOK7eBtMZ7a5Xk4WxcAGuGN088Up9YmWc8Qo5mUiIrFgXAYBJpokE60N3AG+gTTOyU5Zj/ko9d3Uy1GrZeeb5fhg3cikwj0IF/C7zGGRsg0E5r3a/E= Received: by 10.82.175.17 with SMTP id x17mr13317589bue.1192524563429; Tue, 16 Oct 2007 01:49:23 -0700 (PDT) Received: by 10.82.182.9 with HTTP; Tue, 16 Oct 2007 01:49:23 -0700 (PDT) Message-ID: Date: Tue, 16 Oct 2007 10:49:23 +0200 From: "Karl Heinz Wolf" To: "Hannes Tschofenig" Subject: Re: [Ecrit] Comments on framework-03 In-Reply-To: <47147798.3090706@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> <03e801c80f3a$f62615b0$8d0d1f0a@cis.neustar.com> <47147798.3090706@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org hi Hannes, > LoST is the mechanism to obtain the visited emergency dial string. But draft-ietf-ecrit-lost-06 says the service number is just optional: 5.7. The Service Number: the Element The service number is returned in the optional element. That's why I'm confused. karl heinz > > On 10/15/07, Brian Rosen wrote: > > > >> You are, of course, correct. > >> > >> And you did write "too many SHOULDs" in your last edit, which I actually > >> read as "too many SHOULDs without an explanation of why they are not MUSTs". > >> > >> I guess I have to make a pass through and address those. > >> > >> Brian > >> > >> > >>> -----Original Message----- > >>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>> Sent: Monday, October 15, 2007 10:43 AM > >>> To: Brian Rosen > >>> Cc: 'Karl Heinz Wolf'; ecrit@ietf.org > >>> Subject: Re: [Ecrit] Comments on framework-03 > >>> > >>> My general observation is that a SHOULD in a document is > >>> underspecified unless there's a condition that indicates when the > >>> action asked for is not required. Omitting it is just punting. If you > >>> go by 2119, it also makes an implementation only conditionally > >>> compliant, even though there may be an alternate, equally-functional > >>> way of implementing a certain desirable outcome. In this particular > >>> case, we know the condition, so we should state it. It's not like IMS > >>> is some kind of secret. > >>> > >>> Henning > >>> > >>> On Oct 15, 2007, at 9:47 AM, Brian Rosen wrote: > >>> > >>> > >>>> The problem with writing this text is that the big bad IMS is out > >>>> there. > >>>> IMS configures the local dial string into the UA not using LoST. > >>>> > >>>> It works because of the relationship between the visited network > >>>> and the UA. > >>>> That technique won't work in most other environments, because the > >>>> relationships are different. > >>>> > >>>> I probably should make a pass through -phonebcp and find all the > >>>> "SHOULDS" > >>>> and have text in -framework (and/or -phonebcp) that covers the > >>>> cases where > >>>> it doesn't apply. > >>>> > >>>> The problem is that it leads to pretty awkward wording. > >>>> > >>>> Brian > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > >>>>> Sent: Monday, October 15, 2007 8:41 AM > >>>>> To: ecrit@ietf.org > >>>>> Subject: Re: [Ecrit] Comments on framework-03 > >>>>> > >>>>> I read the framework document, too. Except editorial comments, I have > >>>>> one problem with recognizing emergency calls and dial strings. The > >>>>> framework document says: > >>>>> > >>>>> 1) Users are not expected to "dial" an emergency URN. > >>>>> > >>>>> 2) Having the home dial string work is optional. > >>>>> > >>>>> 3) The LoST response may contain the dial string for emergency calls > >>>>> appropriate for the location provided. > >>>>> > >>>>> Now, how can a user place an emergency call when the UA supports no > >>>>> home dial string and the LoST response does not contain the visited > >>>>> dial string? > >>>>> > >>>>> Do I get here something wrong? > >>>>> Karl Heinz > >>>>> > >>>>> _______________________________________________ > >>>>> Ecrit mailing list > >>>>> Ecrit@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>> > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>> > >> > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 16 04:57:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhiEW-0007lB-5r; Tue, 16 Oct 2007 04:57:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhiEV-0007kU-4W for ecrit@ietf.org; Tue, 16 Oct 2007 04:56:59 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IhiEJ-0002UE-QR for ecrit@ietf.org; Tue, 16 Oct 2007 04:56:54 -0400 Received: (qmail invoked by alias); 16 Oct 2007 08:56:21 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp020) with SMTP; 16 Oct 2007 10:56:21 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX192SGsr2D92WBAj3dssLeXbreg0y6anVJm8RFqlU0 I717zoC50u+om0 Message-ID: <47147CB4.1010108@gmx.net> Date: Tue, 16 Oct 2007 11:56:20 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Karl Heinz Wolf Subject: Re: [Ecrit] Comments on framework-03 References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> <03e801c80f3a$f62615b0$8d0d1f0a@cis.neustar.com> <47147798.3090706@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Karl Heinz, Karl Heinz Wolf wrote: > hi Hannes, > > >> LoST is the mechanism to obtain the visited emergency dial string. >> > > But draft-ietf-ecrit-lost-06 says the service number is just optional: > > 5.7. The Service Number: the Element > > The service number is returned in the optional > element. > > > > That's why I'm confused. > > LoST may also be used in cases where the dial string is not needed. For example, when LoST is used only to validate civic addresses then it is not needed. Another example, when a proxy uses LoST for location based routing then the element will not be helpful. The Phone BCP document should say: When LoST is used by the end host then the must be returned. Does this make sense? Ciao Hannes > karl heinz > > > > >>> On 10/15/07, Brian Rosen wrote: >>> >>> >>>> You are, of course, correct. >>>> >>>> And you did write "too many SHOULDs" in your last edit, which I actually >>>> read as "too many SHOULDs without an explanation of why they are not MUSTs". >>>> >>>> I guess I have to make a pass through and address those. >>>> >>>> Brian >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>> Sent: Monday, October 15, 2007 10:43 AM >>>>> To: Brian Rosen >>>>> Cc: 'Karl Heinz Wolf'; ecrit@ietf.org >>>>> Subject: Re: [Ecrit] Comments on framework-03 >>>>> >>>>> My general observation is that a SHOULD in a document is >>>>> underspecified unless there's a condition that indicates when the >>>>> action asked for is not required. Omitting it is just punting. If you >>>>> go by 2119, it also makes an implementation only conditionally >>>>> compliant, even though there may be an alternate, equally-functional >>>>> way of implementing a certain desirable outcome. In this particular >>>>> case, we know the condition, so we should state it. It's not like IMS >>>>> is some kind of secret. >>>>> >>>>> Henning >>>>> >>>>> On Oct 15, 2007, at 9:47 AM, Brian Rosen wrote: >>>>> >>>>> >>>>> >>>>>> The problem with writing this text is that the big bad IMS is out >>>>>> there. >>>>>> IMS configures the local dial string into the UA not using LoST. >>>>>> >>>>>> It works because of the relationship between the visited network >>>>>> and the UA. >>>>>> That technique won't work in most other environments, because the >>>>>> relationships are different. >>>>>> >>>>>> I probably should make a pass through -phonebcp and find all the >>>>>> "SHOULDS" >>>>>> and have text in -framework (and/or -phonebcp) that covers the >>>>>> cases where >>>>>> it doesn't apply. >>>>>> >>>>>> The problem is that it leads to pretty awkward wording. >>>>>> >>>>>> Brian >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >>>>>>> Sent: Monday, October 15, 2007 8:41 AM >>>>>>> To: ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] Comments on framework-03 >>>>>>> >>>>>>> I read the framework document, too. Except editorial comments, I have >>>>>>> one problem with recognizing emergency calls and dial strings. The >>>>>>> framework document says: >>>>>>> >>>>>>> 1) Users are not expected to "dial" an emergency URN. >>>>>>> >>>>>>> 2) Having the home dial string work is optional. >>>>>>> >>>>>>> 3) The LoST response may contain the dial string for emergency calls >>>>>>> appropriate for the location provided. >>>>>>> >>>>>>> Now, how can a user place an emergency call when the UA supports no >>>>>>> home dial string and the LoST response does not contain the visited >>>>>>> dial string? >>>>>>> >>>>>>> Do I get here something wrong? >>>>>>> Karl Heinz >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 16 05:15:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhiWH-0000XL-QC; Tue, 16 Oct 2007 05:15:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhiWF-0000Ra-TV for ecrit@ietf.org; Tue, 16 Oct 2007 05:15:19 -0400 Received: from fk-out-0910.google.com ([209.85.128.188]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhiWF-00032u-62 for ecrit@ietf.org; Tue, 16 Oct 2007 05:15:19 -0400 Received: by fk-out-0910.google.com with SMTP id z23so1781498fkz for ; Tue, 16 Oct 2007 02:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=TQUtWZbPFHg2HLARXoX7GqOwEbjDgi808hGnBNwa3v0=; b=dgunKRJ59oRdei9B/skMZN8XxrNMsKvHU/qAmwe2TURCJ3LL42zr+vEfYoRkL22evzjroMPfposX0M2gBBrJSYf0wgn3vfvHC3IsJ2fn27mpA49BbpAuxiqS1yl6mhjfzo59cVZf7w670scscQhySBUNEQUTgCsOnTrD1qzIo8I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ubd3yxaHBrhqb6V15vCEkoJsqOPW6AyUF8kn+iFS9sFC6VGn20Ezbh5QeQ8rRt4itu2wnSfR3nJQNPh1C+BrVQKnPNh1xByFeQzwWHQMAGjKIbbbDHY9ZrxRKjAF8N1D16BBWQsQFRPNFgdDpBzm/9h7xLEpjlspuJ84g9w/HKo= Received: by 10.82.183.19 with SMTP id g19mr13376222buf.1192526118114; Tue, 16 Oct 2007 02:15:18 -0700 (PDT) Received: by 10.82.182.9 with HTTP; Tue, 16 Oct 2007 02:15:18 -0700 (PDT) Message-ID: Date: Tue, 16 Oct 2007 11:15:18 +0200 From: "Karl Heinz Wolf" To: "Hannes Tschofenig" Subject: Re: [Ecrit] Comments on framework-03 In-Reply-To: <47147CB4.1010108@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> <03e801c80f3a$f62615b0$8d0d1f0a@cis.neustar.com> <47147798.3090706@gmx.net> <47147CB4.1010108@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > > >> LoST is the mechanism to obtain the visited emergency dial string. > >> > > > > But draft-ietf-ecrit-lost-06 says the service number is just optional: > > > > 5.7. The Service Number: the Element > > > > The service number is returned in the optional > > element. > > > > > > > > That's why I'm confused. > > > > > LoST may also be used in cases where the dial string is not needed. For > example, when LoST is used only to validate civic addresses then it is > not needed. > Another example, when a proxy uses LoST for location based routing then > the element will not be helpful. but it wouldn't harm, would it? > > The Phone BCP document should say: When LoST is used by the end host > then the must be returned. > how does the LoST Server know if a client or a proxy does the findService request? ciao karl heinz > > > > > > > >>> On 10/15/07, Brian Rosen wrote: > >>> > >>> > >>>> You are, of course, correct. > >>>> > >>>> And you did write "too many SHOULDs" in your last edit, which I actually > >>>> read as "too many SHOULDs without an explanation of why they are not MUSTs". > >>>> > >>>> I guess I have to make a pass through and address those. > >>>> > >>>> Brian > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>>>> Sent: Monday, October 15, 2007 10:43 AM > >>>>> To: Brian Rosen > >>>>> Cc: 'Karl Heinz Wolf'; ecrit@ietf.org > >>>>> Subject: Re: [Ecrit] Comments on framework-03 > >>>>> > >>>>> My general observation is that a SHOULD in a document is > >>>>> underspecified unless there's a condition that indicates when the > >>>>> action asked for is not required. Omitting it is just punting. If you > >>>>> go by 2119, it also makes an implementation only conditionally > >>>>> compliant, even though there may be an alternate, equally-functional > >>>>> way of implementing a certain desirable outcome. In this particular > >>>>> case, we know the condition, so we should state it. It's not like IMS > >>>>> is some kind of secret. > >>>>> > >>>>> Henning > >>>>> > >>>>> On Oct 15, 2007, at 9:47 AM, Brian Rosen wrote: > >>>>> > >>>>> > >>>>> > >>>>>> The problem with writing this text is that the big bad IMS is out > >>>>>> there. > >>>>>> IMS configures the local dial string into the UA not using LoST. > >>>>>> > >>>>>> It works because of the relationship between the visited network > >>>>>> and the UA. > >>>>>> That technique won't work in most other environments, because the > >>>>>> relationships are different. > >>>>>> > >>>>>> I probably should make a pass through -phonebcp and find all the > >>>>>> "SHOULDS" > >>>>>> and have text in -framework (and/or -phonebcp) that covers the > >>>>>> cases where > >>>>>> it doesn't apply. > >>>>>> > >>>>>> The problem is that it leads to pretty awkward wording. > >>>>>> > >>>>>> Brian > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > >>>>>>> Sent: Monday, October 15, 2007 8:41 AM > >>>>>>> To: ecrit@ietf.org > >>>>>>> Subject: Re: [Ecrit] Comments on framework-03 > >>>>>>> > >>>>>>> I read the framework document, too. Except editorial comments, I have > >>>>>>> one problem with recognizing emergency calls and dial strings. The > >>>>>>> framework document says: > >>>>>>> > >>>>>>> 1) Users are not expected to "dial" an emergency URN. > >>>>>>> > >>>>>>> 2) Having the home dial string work is optional. > >>>>>>> > >>>>>>> 3) The LoST response may contain the dial string for emergency calls > >>>>>>> appropriate for the location provided. > >>>>>>> > >>>>>>> Now, how can a user place an emergency call when the UA supports no > >>>>>>> home dial string and the LoST response does not contain the visited > >>>>>>> dial string? > >>>>>>> > >>>>>>> Do I get here something wrong? > >>>>>>> Karl Heinz > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Ecrit mailing list > >>>>>>> Ecrit@ietf.org > >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>> > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> Ecrit mailing list > >>>>>> Ecrit@ietf.org > >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>> > >>>>>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/ecrit > >>> > >>> > >> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 16 08:14:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhlIg-0001pq-8g; Tue, 16 Oct 2007 08:13:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhlIe-0001nC-Cw for ecrit@ietf.org; Tue, 16 Oct 2007 08:13:28 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhlIX-0000q4-Bc for ecrit@ietf.org; Tue, 16 Oct 2007 08:13:28 -0400 Received: from [192.168.0.41] (pool-70-21-206-158.nwrk.east.verizon.net [70.21.206.158]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l9GCD2sR009681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Oct 2007 08:13:03 -0400 (EDT) In-Reply-To: References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> <03e801c80f3a$f62615b0$8d0d1f0a@cis.neustar.com> <47147798.3090706@gmx.net> <47147CB4.1010108@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2FE54B4F-4521-4C5D-AF1C-73561C55EA1D@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Comments on framework-03 Date: Tue, 16 Oct 2007 08:12:53 -0400 To: Karl Heinz Wolf X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: -1.0 (-) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org >> ed. For >> example, when LoST is used only to validate civic addresses then >> it is >> not needed. >> Another example, when a proxy uses LoST for location based routing >> then >> the element will not be helpful. > > but it wouldn't harm, would it? Not all services may have dial strings, at least in the long term. Remember that LoST can be used for things other than emergency calls. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 16 09:41:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhmfT-0007Em-Ml; Tue, 16 Oct 2007 09:41:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhmfR-0007C7-Eg for ecrit@ietf.org; Tue, 16 Oct 2007 09:41:05 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhmfL-00048x-AD for ecrit@ietf.org; Tue, 16 Oct 2007 09:41:05 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Ihmf7-0007M5-OJ; Tue, 16 Oct 2007 08:40:46 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Karl Heinz Wolf'" References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p><03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com><03e801c80f3a$f62615b0$8d0d1f0a@cis.neustar.com><47147798.3090706@gmx.net><47147CB4.1010108@gmx.net> <2FE54B4F-4521-4C5D-AF1C-73561C55EA1D@cs.columbia.edu> Subject: RE: [Ecrit] Comments on framework-03 Date: Tue, 16 Oct 2007 09:40:49 -0400 Message-ID: <059301c80ffa$2b563610$8d0d1f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <2FE54B4F-4521-4C5D-AF1C-73561C55EA1D@cs.columbia.edu> Thread-Index: AcgP7h1nsCC3buYcSyyv26lpeT+iZQAC9x8Q X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think this does make sense to discuss in -framework, with a rule in -phonebcp. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, October 16, 2007 8:13 AM > To: Karl Heinz Wolf > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Comments on framework-03 > > >> ed. For > >> example, when LoST is used only to validate civic addresses then > >> it is > >> not needed. > >> Another example, when a proxy uses LoST for location based routing > >> then > >> the element will not be helpful. > > > > but it wouldn't harm, would it? > > > Not all services may have dial strings, at least in the long term. > Remember that LoST can be used for things other than emergency calls. > > Henning > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 16 10:39:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhnZH-0006wJ-Ua; Tue, 16 Oct 2007 10:38:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhnZG-0006v7-Of for ecrit@ietf.org; Tue, 16 Oct 2007 10:38:46 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhnZA-0006mj-K7 for ecrit@ietf.org; Tue, 16 Oct 2007 10:38:46 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IhnYv-0000OH-6R; Tue, 16 Oct 2007 10:38:26 -0400 Message-ID: <4714CCE0.7030004@bbn.com> Date: Tue, 16 Oct 2007 10:38:24 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Comments on framework-03 References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> <03e801c80f3a$f62615b0$8d0d1f0a@cis.neustar.com> <47147798.3090706@gmx.net> <47147CB4.1010108@gmx.net> <2FE54B4F-4521-4C5D-AF1C-73561C55EA1D@cs.columbia.edu> In-Reply-To: <2FE54B4F-4521-4C5D-AF1C-73561C55EA1D@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think what's unclear is exactly when serviceNumber is returned. It seems like the document assumes that if there is a serviceNumber, it will be returned, but it doesn't make this explicit requirement. You could imagine a LoST server that knows serviceNumbers but only returns a serviceNumber for, say, urn:service:sos, under the assumption that other services could be reached via that dial string (an assumption that works in the US, but not elsewhere). This behavior is implicitly disallowed -- there's no way for the client to get the other numbers, since there's no request mechanism for that -- but still possible. It seems like LoST requires one of the two following changes to address Karl Heinz's concern: 1) A clause in section 5.7 to say that if a LoST server has a serviceNumber, then it MUST return it. (Possibly with one or two exceptions, like validation) 2) A mechanism for a client to explicitly request a service number be included in their findServiceResponse (and a mechanism for the server to indicate he has none). I prefer option (1) because it is much simpler. --Richard Henning Schulzrinne wrote: >>> ed. For >>> example, when LoST is used only to validate civic addresses then it is >>> not needed. >>> Another example, when a proxy uses LoST for location based routing then >>> the element will not be helpful. >> >> but it wouldn't harm, would it? > > > Not all services may have dial strings, at least in the long term. > Remember that LoST can be used for things other than emergency calls. > > Henning > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 16 10:45:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihnfj-00085s-QV; Tue, 16 Oct 2007 10:45:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihnfi-0007ny-94 for ecrit@ietf.org; Tue, 16 Oct 2007 10:45:26 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ihnfb-0006Bv-4R for ecrit@ietf.org; Tue, 16 Oct 2007 10:45:19 -0400 Received: (qmail invoked by alias); 16 Oct 2007 14:45:15 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp019) with SMTP; 16 Oct 2007 16:45:15 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19rwn0O1nhrgn0vMwGgMJYq1aG7uQzyEagYh2Q8I/ fWAhkKr6iVBhrb Message-ID: <4714CE7B.7090205@gmx.net> Date: Tue, 16 Oct 2007 17:45:15 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Karl Heinz Wolf Subject: Re: [Ecrit] Comments on framework-03 References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> <03e801c80f3a$f62615b0$8d0d1f0a@cis.neustar.com> <47147798.3090706@gmx.net> <47147CB4.1010108@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hallo Karl Heinz, Karl Heinz Wolf wrote: >>>> LoST is the mechanism to obtain the visited emergency dial string. >>>> >>>> >>> But draft-ietf-ecrit-lost-06 says the service number is just optional: >>> >>> 5.7. The Service Number: the Element >>> >>> The service number is returned in the optional >>> element. >>> >>> >>> >>> That's why I'm confused. >>> >>> >>> >> LoST may also be used in cases where the dial string is not needed. For >> example, when LoST is used only to validate civic addresses then it is >> not needed. >> Another example, when a proxy uses LoST for location based routing then >> the element will not be helpful. >> > > but it wouldn't harm, would it? > No. It does not harm. I just wouldn't be needed by the proxy (in a normal setting where the end host provided the Service URN). If you consider legacy clients then there is obviously the limitation that they wouldn't be able to learn the visited dial string automatically, they phone would not be able to recognize that this is an emergency call and the proxy might not recognize the emergency call either.... > >> The Phone BCP document should say: When LoST is used by the end host >> then the must be returned. >> >> > > how does the LoST Server know if a client or a proxy does the > findService request? > It would only know in an environment, such as envisioned by the 3GPP IMS emergency services architecture or enterprise networks where these functions are provided "locally". In these architectures the LoST server, the proxy, and the location server are deployed locally and they would obviously know each other. Ciao Hannes > ciao > karl heinz > > > >>> >>> >>>>> On 10/15/07, Brian Rosen wrote: >>>>> >>>>> >>>>> >>>>>> You are, of course, correct. >>>>>> >>>>>> And you did write "too many SHOULDs" in your last edit, which I actually >>>>>> read as "too many SHOULDs without an explanation of why they are not MUSTs". >>>>>> >>>>>> I guess I have to make a pass through and address those. >>>>>> >>>>>> Brian >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>>>> Sent: Monday, October 15, 2007 10:43 AM >>>>>>> To: Brian Rosen >>>>>>> Cc: 'Karl Heinz Wolf'; ecrit@ietf.org >>>>>>> Subject: Re: [Ecrit] Comments on framework-03 >>>>>>> >>>>>>> My general observation is that a SHOULD in a document is >>>>>>> underspecified unless there's a condition that indicates when the >>>>>>> action asked for is not required. Omitting it is just punting. If you >>>>>>> go by 2119, it also makes an implementation only conditionally >>>>>>> compliant, even though there may be an alternate, equally-functional >>>>>>> way of implementing a certain desirable outcome. In this particular >>>>>>> case, we know the condition, so we should state it. It's not like IMS >>>>>>> is some kind of secret. >>>>>>> >>>>>>> Henning >>>>>>> >>>>>>> On Oct 15, 2007, at 9:47 AM, Brian Rosen wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> The problem with writing this text is that the big bad IMS is out >>>>>>>> there. >>>>>>>> IMS configures the local dial string into the UA not using LoST. >>>>>>>> >>>>>>>> It works because of the relationship between the visited network >>>>>>>> and the UA. >>>>>>>> That technique won't work in most other environments, because the >>>>>>>> relationships are different. >>>>>>>> >>>>>>>> I probably should make a pass through -phonebcp and find all the >>>>>>>> "SHOULDS" >>>>>>>> and have text in -framework (and/or -phonebcp) that covers the >>>>>>>> cases where >>>>>>>> it doesn't apply. >>>>>>>> >>>>>>>> The problem is that it leads to pretty awkward wording. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >>>>>>>>> Sent: Monday, October 15, 2007 8:41 AM >>>>>>>>> To: ecrit@ietf.org >>>>>>>>> Subject: Re: [Ecrit] Comments on framework-03 >>>>>>>>> >>>>>>>>> I read the framework document, too. Except editorial comments, I have >>>>>>>>> one problem with recognizing emergency calls and dial strings. The >>>>>>>>> framework document says: >>>>>>>>> >>>>>>>>> 1) Users are not expected to "dial" an emergency URN. >>>>>>>>> >>>>>>>>> 2) Having the home dial string work is optional. >>>>>>>>> >>>>>>>>> 3) The LoST response may contain the dial string for emergency calls >>>>>>>>> appropriate for the location provided. >>>>>>>>> >>>>>>>>> Now, how can a user place an emergency call when the UA supports no >>>>>>>>> home dial string and the LoST response does not contain the visited >>>>>>>>> dial string? >>>>>>>>> >>>>>>>>> Do I get here something wrong? >>>>>>>>> Karl Heinz >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Ecrit mailing list >>>>>>>>> Ecrit@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Ecrit mailing list >>>>>>>> Ecrit@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>> >>>>>>>> >>>>>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> >>>>> >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 16 10:49:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihnjp-0003so-KO; Tue, 16 Oct 2007 10:49:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihnjp-0003sg-6t for ecrit@ietf.org; Tue, 16 Oct 2007 10:49:41 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ihnjn-000785-Sm for ecrit@ietf.org; Tue, 16 Oct 2007 10:49:41 -0400 Received: (qmail invoked by alias); 16 Oct 2007 14:49:38 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp001) with SMTP; 16 Oct 2007 16:49:38 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Y9yE6yVaYg0MbfBOT9E8zQfXfJnQt1muxNAeNP9 bDuQ/Fph/P4moo Message-ID: <4714CF82.8000708@gmx.net> Date: Tue, 16 Oct 2007 17:49:38 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Richard Barnes Subject: Re: [Ecrit] Comments on framework-03 References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> <03e801c80f3a$f62615b0$8d0d1f0a@cis.neustar.com> <47147798.3090706@gmx.net> <47147CB4.1010108@gmx.net> <2FE54B4F-4521-4C5D-AF1C-73561C55EA1D@cs.columbia.edu> <4714CCE0.7030004@bbn.com> In-Reply-To: <4714CCE0.7030004@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I would feel much better to put such a statement into the Phone BCP. That's the right place. Richard Barnes wrote: > I think what's unclear is exactly when serviceNumber is returned. It > seems like the document assumes that if there is a serviceNumber, it > will be returned, but it doesn't make this explicit requirement. > > You could imagine a LoST server that knows serviceNumbers but only > returns a serviceNumber for, say, urn:service:sos, under the > assumption that other services could be reached via that dial string > (an assumption that works in the US, but not elsewhere). This > behavior is implicitly disallowed -- there's no way for the client to > get the other numbers, since there's no request mechanism for that -- > but still possible. > > It seems like LoST requires one of the two following changes to > address Karl Heinz's concern: > 1) A clause in section 5.7 to say that if a LoST server has a > serviceNumber, then it MUST return it. (Possibly with one or two > exceptions, like validation) > 2) A mechanism for a client to explicitly request a service number be > included in their findServiceResponse (and a mechanism for the server > to indicate he has none). > > I prefer option (1) because it is much simpler. > > --Richard > > > > > > Henning Schulzrinne wrote: >>>> ed. For >>>> example, when LoST is used only to validate civic addresses then it is >>>> not needed. >>>> Another example, when a proxy uses LoST for location based routing >>>> then >>>> the element will not be helpful. >>> >>> but it wouldn't harm, would it? >> >> >> Not all services may have dial strings, at least in the long term. >> Remember that LoST can be used for things other than emergency calls. >> >> Henning >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 16 11:03:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhnwI-0000m5-LY; Tue, 16 Oct 2007 11:02:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhnwH-0000jW-C3 for ecrit@ietf.org; Tue, 16 Oct 2007 11:02:33 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhnwG-0006j7-IA for ecrit@ietf.org; Tue, 16 Oct 2007 11:02:33 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Ihnw6-0007il-Rc; Tue, 16 Oct 2007 10:02:23 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'Karl Heinz Wolf'" References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> <03e801c80f3a$f62615b0$8d0d1f0a@cis.neustar.com> <47147798.3090706@gmx.net> <47147CB4.1010108@gmx.net> <4714CE7B.7090205@gmx.net> Subject: RE: [Ecrit] Comments on framework-03 Date: Tue, 16 Oct 2007 11:02:34 -0400 Message-ID: <05c101c81005$9724c770$8d0d1f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4714CE7B.7090205@gmx.net> Thread-Index: AcgQA0UU1ZmGtI8HQIix9owCkE5i5wAAdzfA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think it should be something like: If there is a possibility of an endpoint or proxy needing the dial string it MUST be returned. If the configuration of the server and its clients limits use to circumstances where the endpoint or proxy has other mechanisms to determine the dial string, or the service URN supplied does not have a dial string, or the use of the query is strictly for validation, then the parameter need not be returned". > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, October 16, 2007 10:45 AM > To: Karl Heinz Wolf > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Comments on framework-03 > > Hallo Karl Heinz, > > Karl Heinz Wolf wrote: > >>>> LoST is the mechanism to obtain the visited emergency dial string. > >>>> > >>>> > >>> But draft-ietf-ecrit-lost-06 says the service number is just optional: > >>> > >>> 5.7. The Service Number: the Element > >>> > >>> The service number is returned in the optional > >>> element. > >>> > >>> > >>> > >>> That's why I'm confused. > >>> > >>> > >>> > >> LoST may also be used in cases where the dial string is not needed. For > >> example, when LoST is used only to validate civic addresses then it is > >> not needed. > >> Another example, when a proxy uses LoST for location based routing then > >> the element will not be helpful. > >> > > > > but it wouldn't harm, would it? > > > No. It does not harm. I just wouldn't be needed by the proxy (in a > normal setting where the end host provided the Service URN). > If you consider legacy clients then there is obviously the limitation > that they wouldn't be able to learn the visited dial string > automatically, they phone would not be able to recognize that this is an > emergency call and the proxy might not recognize the emergency call > either.... > > > > >> The Phone BCP document should say: When LoST is used by the end host > >> then the must be returned. > >> > >> > > > > how does the LoST Server know if a client or a proxy does the > > findService request? > > > It would only know in an environment, such as envisioned by the 3GPP IMS > emergency services architecture or enterprise networks where these > functions are provided "locally". In these architectures the LoST > server, the proxy, and the location server are deployed locally and they > would obviously know each other. > > Ciao > Hannes > > > ciao > > karl heinz > > > > > > > >>> > >>> > >>>>> On 10/15/07, Brian Rosen wrote: > >>>>> > >>>>> > >>>>> > >>>>>> You are, of course, correct. > >>>>>> > >>>>>> And you did write "too many SHOULDs" in your last edit, which I > actually > >>>>>> read as "too many SHOULDs without an explanation of why they are > not MUSTs". > >>>>>> > >>>>>> I guess I have to make a pass through and address those. > >>>>>> > >>>>>> Brian > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>>>>>> Sent: Monday, October 15, 2007 10:43 AM > >>>>>>> To: Brian Rosen > >>>>>>> Cc: 'Karl Heinz Wolf'; ecrit@ietf.org > >>>>>>> Subject: Re: [Ecrit] Comments on framework-03 > >>>>>>> > >>>>>>> My general observation is that a SHOULD in a document is > >>>>>>> underspecified unless there's a condition that indicates when the > >>>>>>> action asked for is not required. Omitting it is just punting. If > you > >>>>>>> go by 2119, it also makes an implementation only conditionally > >>>>>>> compliant, even though there may be an alternate, equally- > functional > >>>>>>> way of implementing a certain desirable outcome. In this > particular > >>>>>>> case, we know the condition, so we should state it. It's not like > IMS > >>>>>>> is some kind of secret. > >>>>>>> > >>>>>>> Henning > >>>>>>> > >>>>>>> On Oct 15, 2007, at 9:47 AM, Brian Rosen wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> The problem with writing this text is that the big bad IMS is out > >>>>>>>> there. > >>>>>>>> IMS configures the local dial string into the UA not using LoST. > >>>>>>>> > >>>>>>>> It works because of the relationship between the visited network > >>>>>>>> and the UA. > >>>>>>>> That technique won't work in most other environments, because the > >>>>>>>> relationships are different. > >>>>>>>> > >>>>>>>> I probably should make a pass through -phonebcp and find all the > >>>>>>>> "SHOULDS" > >>>>>>>> and have text in -framework (and/or -phonebcp) that covers the > >>>>>>>> cases where > >>>>>>>> it doesn't apply. > >>>>>>>> > >>>>>>>> The problem is that it leads to pretty awkward wording. > >>>>>>>> > >>>>>>>> Brian > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > >>>>>>>>> Sent: Monday, October 15, 2007 8:41 AM > >>>>>>>>> To: ecrit@ietf.org > >>>>>>>>> Subject: Re: [Ecrit] Comments on framework-03 > >>>>>>>>> > >>>>>>>>> I read the framework document, too. Except editorial comments, I > have > >>>>>>>>> one problem with recognizing emergency calls and dial strings. > The > >>>>>>>>> framework document says: > >>>>>>>>> > >>>>>>>>> 1) Users are not expected to "dial" an emergency URN. > >>>>>>>>> > >>>>>>>>> 2) Having the home dial string work is optional. > >>>>>>>>> > >>>>>>>>> 3) The LoST response may contain the dial string for emergency > calls > >>>>>>>>> appropriate for the location provided. > >>>>>>>>> > >>>>>>>>> Now, how can a user place an emergency call when the UA supports > no > >>>>>>>>> home dial string and the LoST response does not contain the > visited > >>>>>>>>> dial string? > >>>>>>>>> > >>>>>>>>> Do I get here something wrong? > >>>>>>>>> Karl Heinz > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Ecrit mailing list > >>>>>>>>> Ecrit@ietf.org > >>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Ecrit mailing list > >>>>>>>> Ecrit@ietf.org > >>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>> _______________________________________________ > >>>>> Ecrit mailing list > >>>>> Ecrit@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>> > >>>>> > >>>>> > >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 16 11:19:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhoC2-0000mx-E3; Tue, 16 Oct 2007 11:18:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhoC1-0000mq-7E for ecrit@ietf.org; Tue, 16 Oct 2007 11:18:49 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhoC0-0007Hj-Ps for ecrit@ietf.org; Tue, 16 Oct 2007 11:18:49 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IhoBz-0007ge-5X; Tue, 16 Oct 2007 11:18:48 -0400 Message-ID: <4714D655.6040509@bbn.com> Date: Tue, 16 Oct 2007 11:18:45 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Comments on framework-03 References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> <03e801c80f3a$f62615b0$8d0d1f0a@cis.neustar.com> <47147798.3090706@gmx.net> <47147CB4.1010108@gmx.net> <2FE54B4F-4521-4C5D-AF1C-73561C55EA1D@cs.columbia.edu> <4714CCE0.7030004@bbn.com> <4714CF82.8000708@gmx.net> In-Reply-To: <4714CF82.8000708@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org You can put it in phonebcp if you like, but it's a statement that applies to ALL LoST servers and ONLY to LoST servers. So it seems like the LoST document would be the place to put it. --Richard Hannes Tschofenig wrote: > I would feel much better to put such a statement into the Phone BCP. > That's the right place. > > > Richard Barnes wrote: >> I think what's unclear is exactly when serviceNumber is returned. It >> seems like the document assumes that if there is a serviceNumber, it >> will be returned, but it doesn't make this explicit requirement. >> >> You could imagine a LoST server that knows serviceNumbers but only >> returns a serviceNumber for, say, urn:service:sos, under the >> assumption that other services could be reached via that dial string >> (an assumption that works in the US, but not elsewhere). This >> behavior is implicitly disallowed -- there's no way for the client to >> get the other numbers, since there's no request mechanism for that -- >> but still possible. >> >> It seems like LoST requires one of the two following changes to >> address Karl Heinz's concern: >> 1) A clause in section 5.7 to say that if a LoST server has a >> serviceNumber, then it MUST return it. (Possibly with one or two >> exceptions, like validation) >> 2) A mechanism for a client to explicitly request a service number be >> included in their findServiceResponse (and a mechanism for the server >> to indicate he has none). >> >> I prefer option (1) because it is much simpler. >> >> --Richard >> >> >> >> >> >> Henning Schulzrinne wrote: >>>>> ed. For >>>>> example, when LoST is used only to validate civic addresses then it is >>>>> not needed. >>>>> Another example, when a proxy uses LoST for location based routing >>>>> then >>>>> the element will not be helpful. >>>> >>>> but it wouldn't harm, would it? >>> >>> >>> Not all services may have dial strings, at least in the long term. >>> Remember that LoST can be used for things other than emergency calls. >>> >>> Henning >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 16 11:40:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhoW9-0005XA-1S; Tue, 16 Oct 2007 11:39:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhoW7-0005X4-Ah for ecrit@ietf.org; Tue, 16 Oct 2007 11:39:35 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhoW6-0008Cb-Ex for ecrit@ietf.org; Tue, 16 Oct 2007 11:39:35 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IhoW4-0001Vw-6Q; Tue, 16 Oct 2007 11:39:33 -0400 Message-ID: <4714DB33.8050302@bbn.com> Date: Tue, 16 Oct 2007 11:39:31 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Comments on framework-03 References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> <03e801c80f3a$f62615b0$8d0d1f0a@cis.neustar.com> <47147798.3090706@gmx.net> <47147CB4.1010108@gmx.net> <4714CE7B.7090205@gmx.net> <05c101c81005$9724c770$8d0d1f0a@cis.neustar.com> In-Reply-To: <05c101c81005$9724c770$8d0d1f0a@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > If there is a possibility of an endpoint or proxy needing the dial string it > MUST be returned. If the configuration of the server and its clients limits > use to circumstances where the endpoint or proxy has other mechanisms to > determine the dial string, or the service URN supplied does not have a dial > string, or the use of the query is strictly for validation, then the > parameter need not be returned". It seems to me like you're headed down same path as the "suppose you control every device on the network" special case. As I've said before, making special exceptions for this case doesn't make any sense: If you control the whole system, then you can use things however you want, and we don't need to say anything about it. And moreover, it tempts people to think they're in the special case when they might not be, possibly causing calls to fail as a result. For example, how does the LoST server know there's NO possibility of the client needing a dial string? Maybe it's in a walled-garden network (in which case, again, it can do whatever it wants), but maybe the operator just assumes that requests for certain URNs don't need dial strings. It's hard to differentiate between these two cases, so I tend to not to make special exceptions the non-standard case at all. If you're going to add text to phonebcp, it should be simple: "LoST servers MUST include service numbers whenever possible." --Richard > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Tuesday, October 16, 2007 10:45 AM >> To: Karl Heinz Wolf >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] Comments on framework-03 >> >> Hallo Karl Heinz, >> >> Karl Heinz Wolf wrote: >>>>>> LoST is the mechanism to obtain the visited emergency dial string. >>>>>> >>>>>> >>>>> But draft-ietf-ecrit-lost-06 says the service number is just optional: >>>>> >>>>> 5.7. The Service Number: the Element >>>>> >>>>> The service number is returned in the optional >>>>> element. >>>>> >>>>> >>>>> >>>>> That's why I'm confused. >>>>> >>>>> >>>>> >>>> LoST may also be used in cases where the dial string is not needed. For >>>> example, when LoST is used only to validate civic addresses then it is >>>> not needed. >>>> Another example, when a proxy uses LoST for location based routing then >>>> the element will not be helpful. >>>> >>> but it wouldn't harm, would it? >>> >> No. It does not harm. I just wouldn't be needed by the proxy (in a >> normal setting where the end host provided the Service URN). >> If you consider legacy clients then there is obviously the limitation >> that they wouldn't be able to learn the visited dial string >> automatically, they phone would not be able to recognize that this is an >> emergency call and the proxy might not recognize the emergency call >> either.... >> >>>> The Phone BCP document should say: When LoST is used by the end host >>>> then the must be returned. >>>> >>>> >>> how does the LoST Server know if a client or a proxy does the >>> findService request? >>> >> It would only know in an environment, such as envisioned by the 3GPP IMS >> emergency services architecture or enterprise networks where these >> functions are provided "locally". In these architectures the LoST >> server, the proxy, and the location server are deployed locally and they >> would obviously know each other. >> >> Ciao >> Hannes >> >>> ciao >>> karl heinz >>> >>> >>> >>>>> >>>>>>> On 10/15/07, Brian Rosen wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> You are, of course, correct. >>>>>>>> >>>>>>>> And you did write "too many SHOULDs" in your last edit, which I >> actually >>>>>>>> read as "too many SHOULDs without an explanation of why they are >> not MUSTs". >>>>>>>> I guess I have to make a pass through and address those. >>>>>>>> >>>>>>>> Brian >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>>>>>> Sent: Monday, October 15, 2007 10:43 AM >>>>>>>>> To: Brian Rosen >>>>>>>>> Cc: 'Karl Heinz Wolf'; ecrit@ietf.org >>>>>>>>> Subject: Re: [Ecrit] Comments on framework-03 >>>>>>>>> >>>>>>>>> My general observation is that a SHOULD in a document is >>>>>>>>> underspecified unless there's a condition that indicates when the >>>>>>>>> action asked for is not required. Omitting it is just punting. If >> you >>>>>>>>> go by 2119, it also makes an implementation only conditionally >>>>>>>>> compliant, even though there may be an alternate, equally- >> functional >>>>>>>>> way of implementing a certain desirable outcome. In this >> particular >>>>>>>>> case, we know the condition, so we should state it. It's not like >> IMS >>>>>>>>> is some kind of secret. >>>>>>>>> >>>>>>>>> Henning >>>>>>>>> >>>>>>>>> On Oct 15, 2007, at 9:47 AM, Brian Rosen wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> The problem with writing this text is that the big bad IMS is out >>>>>>>>>> there. >>>>>>>>>> IMS configures the local dial string into the UA not using LoST. >>>>>>>>>> >>>>>>>>>> It works because of the relationship between the visited network >>>>>>>>>> and the UA. >>>>>>>>>> That technique won't work in most other environments, because the >>>>>>>>>> relationships are different. >>>>>>>>>> >>>>>>>>>> I probably should make a pass through -phonebcp and find all the >>>>>>>>>> "SHOULDS" >>>>>>>>>> and have text in -framework (and/or -phonebcp) that covers the >>>>>>>>>> cases where >>>>>>>>>> it doesn't apply. >>>>>>>>>> >>>>>>>>>> The problem is that it leads to pretty awkward wording. >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] >>>>>>>>>>> Sent: Monday, October 15, 2007 8:41 AM >>>>>>>>>>> To: ecrit@ietf.org >>>>>>>>>>> Subject: Re: [Ecrit] Comments on framework-03 >>>>>>>>>>> >>>>>>>>>>> I read the framework document, too. Except editorial comments, I >> have >>>>>>>>>>> one problem with recognizing emergency calls and dial strings. >> The >>>>>>>>>>> framework document says: >>>>>>>>>>> >>>>>>>>>>> 1) Users are not expected to "dial" an emergency URN. >>>>>>>>>>> >>>>>>>>>>> 2) Having the home dial string work is optional. >>>>>>>>>>> >>>>>>>>>>> 3) The LoST response may contain the dial string for emergency >> calls >>>>>>>>>>> appropriate for the location provided. >>>>>>>>>>> >>>>>>>>>>> Now, how can a user place an emergency call when the UA supports >> no >>>>>>>>>>> home dial string and the LoST response does not contain the >> visited >>>>>>>>>>> dial string? >>>>>>>>>>> >>>>>>>>>>> Do I get here something wrong? >>>>>>>>>>> Karl Heinz >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Ecrit mailing list >>>>>>>>>>> Ecrit@ietf.org >>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Ecrit mailing list >>>>>>>>>> Ecrit@ietf.org >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> >>>>>>> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 16 11:57:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihomh-00078S-H4; Tue, 16 Oct 2007 11:56:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihomf-000720-Sz for ecrit@ietf.org; Tue, 16 Oct 2007 11:56:42 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ihomf-0000Se-KR for ecrit@ietf.org; Tue, 16 Oct 2007 11:56:41 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Ihomf-0008SU-4E for ecrit@ietf.org; Tue, 16 Oct 2007 11:56:41 -0400 Message-ID: <4714DF37.4080405@bbn.com> Date: Tue, 16 Oct 2007 11:56:39 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ecrit] Do URNs ever show up in a Request-URI? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org draft-ietf-ecrit-framework says that the mechanism for getting dial strings (serviceNumbers) is LoST. The way you get dial strings from LoST is to do a findService query, which returns not only the dial string, but one or more contact URIs. That means that if an entity gets dial strings, then it also has PSAP URIs. The call routing process described in framework/phonebcp is as follows: R-URI = dialstring URI 1. (dial string recognition; dial string from LoST) R-URI = URN 2. (service to URI translation; mapping from LoST) R-URI = PSAP URI My question is: Service URNs only ever show up if an entity does 1 and not 2. But the dial string and the mapping come from the same LoST response. So why would someone do 1 and not 2? Can we disregard the case when R-URI=URN? --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 16 12:08:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihoxk-0000yr-C7; Tue, 16 Oct 2007 12:08:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihoxi-0000yh-TQ for ecrit@ietf.org; Tue, 16 Oct 2007 12:08:06 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihoxh-0001lJ-Od for ecrit@ietf.org; Tue, 16 Oct 2007 12:08:06 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IhoxY-0003Bx-2C; Tue, 16 Oct 2007 11:07:56 -0500 From: "Brian Rosen" To: "'Richard Barnes'" , "'ECRIT'" References: <4714DF37.4080405@bbn.com> Subject: RE: [Ecrit] Do URNs ever show up in a Request-URI? Date: Tue, 16 Oct 2007 12:08:01 -0400 Message-ID: <05d401c8100e$bb7988f0$8d0d1f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4714DF37.4080405@bbn.com> Thread-Index: AcgQDTA9OmRaTEmLRIuoO8QTGlIdCwAAQbiw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org In IMS, the UA does dial string recognition, but does not query LoST. The E-CSCF does routing. I think if you get the dialstring from LoST then you would normally expect the PSAP URI in R-URI from the element that did the LoST query. So the cases are use LoST to get dialstring implies same element does routing. Not using LoST for dialstring MAY mean some other element does routing. Brian > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Tuesday, October 16, 2007 11:57 AM > To: ECRIT > Subject: [Ecrit] Do URNs ever show up in a Request-URI? > > draft-ietf-ecrit-framework says that the mechanism for getting dial > strings (serviceNumbers) is LoST. The way you get dial strings from > LoST is to do a findService query, which returns not only the dial > string, but one or more contact URIs. That means that if an entity gets > dial strings, then it also has PSAP URIs. > > The call routing process described in framework/phonebcp is as follows: > R-URI = dialstring URI > 1. (dial string recognition; dial string from LoST) > R-URI = URN > 2. (service to URI translation; mapping from LoST) > R-URI = PSAP URI > > My question is: Service URNs only ever show up if an entity does 1 and > not 2. But the dial string and the mapping come from the same LoST > response. So why would someone do 1 and not 2? Can we disregard the > case when R-URI=URN? > > --Richard > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 16 12:31:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhpJl-0005pp-FF; Tue, 16 Oct 2007 12:30:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhpJk-0005nA-5h for ecrit@ietf.org; Tue, 16 Oct 2007 12:30:52 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhpJb-0002Qv-TL for ecrit@ietf.org; Tue, 16 Oct 2007 12:30:50 -0400 Received: from ([139.76.131.31]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.31687196; Tue, 16 Oct 2007 12:30:02 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 16 Oct 2007 12:30:02 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 16 Oct 2007 12:30:02 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Subject: RE: [Ecrit] Comments on framework-03 Date: Tue, 16 Oct 2007 12:30:01 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA05FFCA2E@crexc41p> In-Reply-To: <05c101c81005$9724c770$8d0d1f0a@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on framework-03 thread-index: AcgQA0UU1ZmGtI8HQIix9owCkE5i5wAAdzfAAABXg6A= References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> <03e801c80f3a$f62615b0$8d0d1f0a@cis.neustar.com> <47147798.3090706@gmx.net> <47147CB4.1010108@gmx.net><4714CE7B.7090205@gmx.net> <05c101c81005$9724c770$8d0d1f0a@cis.neustar.com> From: "Stark, Barbara" To: "Brian Rosen" , "Hannes Tschofenig" , "Karl Heinz Wolf" X-OriginalArrivalTime: 16 Oct 2007 16:30:02.0024 (UTC) FILETIME=[CD058A80:01C81011] X-Spam-Score: 0.2 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hmmm. There are so many caveats, that I'm not really sure what it says. Also, it sounds more like a requirement on the LoST server, than the endpoint or proxy. Phonebcp doesn't have requirements for LoST servers, so it seems out of place.=20 In reading LoST, it appears that the endpoint and proxy have absolutely no control over whether or not serviceNumber is returned. Clearly, they have to do a findService request, that includes a location, and emergency service URNs in . But that's basically already covered in phonebcp. It seems like the requirement is that if a LoST server has serviceNumbers defined for a requested service URN, for the location in the request, then the LoST server MUST include those serviceNumbers in its response. Barbara =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, October 16, 2007 11:03 AM To: 'Hannes Tschofenig'; 'Karl Heinz Wolf' Cc: ecrit@ietf.org Subject: RE: [Ecrit] Comments on framework-03 I think it should be something like: If there is a possibility of an endpoint or proxy needing the dial string it MUST be returned. If the configuration of the server and its clients limits use to circumstances where the endpoint or proxy has other mechanisms to determine the dial string, or the service URN supplied does not have a dial string, or the use of the query is strictly for validation, then the parameter need not be returned". > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, October 16, 2007 10:45 AM > To: Karl Heinz Wolf > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Comments on framework-03 >=20 > Hallo Karl Heinz, >=20 > Karl Heinz Wolf wrote: > >>>> LoST is the mechanism to obtain the visited emergency dial string. > >>>> > >>>> > >>> But draft-ietf-ecrit-lost-06 says the service number is just optional: > >>> > >>> 5.7. The Service Number: the Element > >>> > >>> The service number is returned in the optional > >>> element. > >>> > >>> > >>> > >>> That's why I'm confused. > >>> > >>> > >>> > >> LoST may also be used in cases where the dial string is not needed. For > >> example, when LoST is used only to validate civic addresses then it is > >> not needed. > >> Another example, when a proxy uses LoST for location based routing then > >> the element will not be helpful. > >> > > > > but it wouldn't harm, would it? > > > No. It does not harm. I just wouldn't be needed by the proxy (in a > normal setting where the end host provided the Service URN). > If you consider legacy clients then there is obviously the limitation > that they wouldn't be able to learn the visited dial string > automatically, they phone would not be able to recognize that this is an > emergency call and the proxy might not recognize the emergency call > either.... >=20 > > > >> The Phone BCP document should say: When LoST is used by the end host > >> then the must be returned. > >> > >> > > > > how does the LoST Server know if a client or a proxy does the > > findService request? > > > It would only know in an environment, such as envisioned by the 3GPP IMS > emergency services architecture or enterprise networks where these > functions are provided "locally". In these architectures the LoST > server, the proxy, and the location server are deployed locally and they > would obviously know each other. >=20 > Ciao > Hannes >=20 > > ciao > > karl heinz > > > > > > > >>> > >>> > >>>>> On 10/15/07, Brian Rosen wrote: > >>>>> > >>>>> > >>>>> > >>>>>> You are, of course, correct. > >>>>>> > >>>>>> And you did write "too many SHOULDs" in your last edit, which I > actually > >>>>>> read as "too many SHOULDs without an explanation of why they are > not MUSTs". > >>>>>> > >>>>>> I guess I have to make a pass through and address those. > >>>>>> > >>>>>> Brian > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>>>>>> Sent: Monday, October 15, 2007 10:43 AM > >>>>>>> To: Brian Rosen > >>>>>>> Cc: 'Karl Heinz Wolf'; ecrit@ietf.org > >>>>>>> Subject: Re: [Ecrit] Comments on framework-03 > >>>>>>> > >>>>>>> My general observation is that a SHOULD in a document is > >>>>>>> underspecified unless there's a condition that indicates when the > >>>>>>> action asked for is not required. Omitting it is just punting. If > you > >>>>>>> go by 2119, it also makes an implementation only conditionally > >>>>>>> compliant, even though there may be an alternate, equally- > functional > >>>>>>> way of implementing a certain desirable outcome. In this > particular > >>>>>>> case, we know the condition, so we should state it. It's not like > IMS > >>>>>>> is some kind of secret. > >>>>>>> > >>>>>>> Henning > >>>>>>> > >>>>>>> On Oct 15, 2007, at 9:47 AM, Brian Rosen wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> The problem with writing this text is that the big bad IMS is out > >>>>>>>> there. > >>>>>>>> IMS configures the local dial string into the UA not using LoST. > >>>>>>>> > >>>>>>>> It works because of the relationship between the visited network > >>>>>>>> and the UA. > >>>>>>>> That technique won't work in most other environments, because the > >>>>>>>> relationships are different. > >>>>>>>> > >>>>>>>> I probably should make a pass through -phonebcp and find all the > >>>>>>>> "SHOULDS" > >>>>>>>> and have text in -framework (and/or -phonebcp) that covers the > >>>>>>>> cases where > >>>>>>>> it doesn't apply. > >>>>>>>> > >>>>>>>> The problem is that it leads to pretty awkward wording. > >>>>>>>> > >>>>>>>> Brian > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > >>>>>>>>> Sent: Monday, October 15, 2007 8:41 AM > >>>>>>>>> To: ecrit@ietf.org > >>>>>>>>> Subject: Re: [Ecrit] Comments on framework-03 > >>>>>>>>> > >>>>>>>>> I read the framework document, too. Except editorial comments, I > have > >>>>>>>>> one problem with recognizing emergency calls and dial strings. > The > >>>>>>>>> framework document says: > >>>>>>>>> > >>>>>>>>> 1) Users are not expected to "dial" an emergency URN. > >>>>>>>>> > >>>>>>>>> 2) Having the home dial string work is optional. > >>>>>>>>> > >>>>>>>>> 3) The LoST response may contain the dial string for emergency > calls > >>>>>>>>> appropriate for the location provided. > >>>>>>>>> > >>>>>>>>> Now, how can a user place an emergency call when the UA supports > no > >>>>>>>>> home dial string and the LoST response does not contain the > visited > >>>>>>>>> dial string? > >>>>>>>>> > >>>>>>>>> Do I get here something wrong? > >>>>>>>>> Karl Heinz > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Ecrit mailing list > >>>>>>>>> Ecrit@ietf.org > >>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> Ecrit mailing list > >>>>>>>> Ecrit@ietf.org > >>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>> _______________________________________________ > >>>>> Ecrit mailing list > >>>>> Ecrit@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>>> > >>>>> > >>>>> > >> >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA625 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 16 13:20:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihq5v-0001PN-EW; Tue, 16 Oct 2007 13:20:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihq5t-0001PA-DC for ecrit@ietf.org; Tue, 16 Oct 2007 13:20:37 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihq5p-0004k2-Ux for ecrit@ietf.org; Tue, 16 Oct 2007 13:20:37 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9GHK3cO030156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Oct 2007 10:20:04 -0700 Received: from [98.207.5.180] (vpn-10-50-16-48.qualcomm.com [10.50.16.48]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9GHK2oI016691; Tue, 16 Oct 2007 10:20:02 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4714CCE0.7030004@bbn.com> References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> <03e801c80f3a$f62615b0$8d0d1f0a@cis.neustar.com> <47147798.3090706@gmx.net> <47147CB4.1010108@gmx.net> <2FE54B4F-4521-4C5D-AF1C-73561C55EA1D@cs.columbia.edu> <4714CCE0.7030004@bbn.com> Date: Tue, 16 Oct 2007 10:19:52 -0700 To: Richard Barnes , Henning Schulzrinne From: Ted Hardie Subject: Re: [Ecrit] Comments on framework-03 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -4.0 (----) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 10:38 AM -0400 10/16/07, Richard Barnes wrote: >I think what's unclear is exactly when serviceNumber is returned. It seems like the document assumes that if there is a serviceNumber, it will be returned, but it doesn't make this explicit requirement. > >You could imagine a LoST server that knows serviceNumbers but only returns a serviceNumber for, say, urn:service:sos, under the assumption that other services could be reached via that dial string (an assumption that works in the US, but not elsewhere). This behavior is implicitly disallowed -- there's no way for the client to get the other numbers, since there's no request mechanism for that -- but still possible. > >It seems like LoST requires one of the two following changes to address Karl Heinz's concern: >1) A clause in section 5.7 to say that if a LoST server has a serviceNumber, then it MUST return it. (Possibly with one or two exceptions, like validation) So, I think this kind of statement does not belong in -framework; it *might* belong in BCP. I'm a little leery of it even there. At the moment, it is up to the folks configuring the LoST server to set up the data mapping. In the case above, where the LoST server returns 911 as a serviceNumber for urn:service:sos, but does not return a serviceNumber for others, it may simply be because the user should use the returned URIs instead. The phrase "if a Lost server has a serviceNumber, it MUST return it" specifies how someone should set up the data mapping, and it might be taken to imply that someone deploying lost needs to set up serviceNumbers for any service they deploy. They don't, as Henning already pointed out. If the serviceNumber is just a different way of invoking the same set of mechanisms that would otherwise be reached through the URIs LoST returned, how is getting the serviceNumber back all that important? Are you assuming that there will be LoST enabled devices that do not have the ability to invoke the URIs? Or are you assuming that there will be some difference between the procedures used with serviceNumbers and the other URIs (e.g., someone dialing a serviceNumber uses a service that is at least partially circuit-switched, because it invokes the PSTN, as versus as more pure VoIP process)? regards, Ted >2) A mechanism for a client to explicitly request a service number be included in their findServiceResponse (and a mechanism for the server to indicate he has none). > >I prefer option (1) because it is much simpler. > >- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 16 13:46:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhqUT-0007Ra-5X; Tue, 16 Oct 2007 13:46:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhqUR-0007RN-SO for ecrit@ietf.org; Tue, 16 Oct 2007 13:45:59 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhqUR-0007RP-Gk for ecrit@ietf.org; Tue, 16 Oct 2007 13:45:59 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IhqUQ-0001hu-5f; Tue, 16 Oct 2007 13:45:59 -0400 Message-ID: <4714F8D4.3090004@bbn.com> Date: Tue, 16 Oct 2007 13:45:56 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Ecrit] Comments on framework-03 References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> <03e801c80f3a$f62615b0$8d0d1f0a@cis.neustar.com> <47147798.3090706@gmx.net> <47147CB4.1010108@gmx.net> <2FE54B4F-4521-4C5D-AF1C-73561C55EA1D@cs.columbia.edu> <4714CCE0.7030004@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Ted, > So, I think this kind of statement does not belong in -framework; it *might* belong > in BCP. I'm a little leery of it even there. I was actually suggesting that it go in LoST, although I think it might fit better in the BCP, since it's less important for non-emergency numbers (although still relevant, e.g., for things like 4-1-1 or 3-1-1). > ... it might be taken to imply that someone deploying > lost needs to set up serviceNumbers for any service they deploy. They don't, > as Henning already pointed out. I think there's a misunderstanding here: I meant the phrase "If a LoST server has a serviceNumber" to mean "if there is a serviceNumber in the configured data mapping". This presumes that operators will configure in all relevant service numbers, but doesn't require them to configure any. The situation I want to avoid (and what I think got this started) is when the LoST server has a serviceNumber configured for an area, but doesn't return it for some reason -- this being one interpretation of an optional field. > ... Are you assuming that there will be > LoST enabled devices that do not have the ability to invoke the URIs? > Or are you assuming that there will be some difference between the procedures > used with serviceNumbers and the other URIs? In the context of an entity that is already LoST-capable, the serviceNumber is essentially a UI element. It seems like the assumption is that users will want to continue to use serviceNumbers to refer to services, instead of URNs. I believe that there are regulatory requirements for this UI (i.e., recognizing local numbers) in some jurisdictions. Cheers, --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 16 14:14:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihqvv-0000bA-Qp; Tue, 16 Oct 2007 14:14:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihqvt-0000Zo-Jv for ecrit@ietf.org; Tue, 16 Oct 2007 14:14:21 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ihqvn-0007L9-EC for ecrit@ietf.org; Tue, 16 Oct 2007 14:14:21 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9GIDerk004940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Oct 2007 11:13:40 -0700 Received: from [98.207.5.180] (vpn-10-50-16-48.qualcomm.com [10.50.16.48]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9GIDbVv013330; Tue, 16 Oct 2007 11:13:38 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <4714F8D4.3090004@bbn.com> References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> <03e801c80f3a$f62615b0$8d0d1f0a@cis.neustar.com> <47147798.3090706@gmx.net> <47147CB4.1010108@gmx.net> <2FE54B4F-4521-4C5D-AF1C-73561C55EA1D@cs.columbia.edu> <4714CCE0.7030004@bbn.com> <4714F8D4.3090004@bbn.com> Date: Tue, 16 Oct 2007 11:13:44 -0700 To: Richard Barnes From: Ted Hardie Subject: Re: [Ecrit] Comments on framework-03 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > >>... it might be taken to imply that someone deploying >>lost needs to set up serviceNumbers for any service they deploy. They don't, >>as Henning already pointed out. > >I think there's a misunderstanding here: I meant the phrase "If a LoST server has a serviceNumber" to mean "if there is a serviceNumber in the configured data mapping". This presumes that operators will configure in all relevant service numbers, but doesn't require them to configure any. > >The situation I want to avoid (and what I think got this started) is when the LoST server has a serviceNumber configured for an area, but doesn't return it for some reason -- this being one interpretation of an optional field. Maybe I am confused here. I am having troubling matching up "configured for an area" being true and "returned" being false. The configuration process tells the server what to return for specific areas, so I'm really having trouble imagining any conditions for "doesn't return it for some reason". To put this another way, doesn't this end up saying "you MUST return the values you were configured to return"? Sorry if I'm being dense. It sounds like we at least agree that we're not trying to have anyone set up new serviceNumbers for services they plan to deploy, and that's important. serviceNumbers are optional; you should be able to deploy a LoST/URI mapping without one. >>... Are you assuming that there will be >>LoST enabled devices that do not have the ability to invoke the URIs? Or are you assuming that there will be some difference between the procedures >>used with serviceNumbers and the other URIs? > >In the context of an entity that is already LoST-capable, the serviceNumber is essentially a UI element. It seems like the assumption is that users will want to continue to use serviceNumbers to refer to services, instead of URNs. I believe that there are regulatory requirements for this UI (i.e., recognizing local numbers) in some jurisdictions. > That's what is a bit tricky about all this, isn't it? A UI element should be specific to a particular UI context, but once someone is returned a serviceNumber, they may well expect it to work on any device. So if I start the call on my wifi phone, get a serviceNumber of 112 for the area in which I'm roaming but lose battery before the call goes through, I expect to be able to pick up the next phone I see and dial 112. regards, Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 16 20:37:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihwu4-0004GA-IE; Tue, 16 Oct 2007 20:36:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihwu3-0004FX-Oe for ecrit@ietf.org; Tue, 16 Oct 2007 20:36:51 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ihwu3-00067h-7R for ecrit@ietf.org; Tue, 16 Oct 2007 20:36:51 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Ihwu2-0006fA-4m; Tue, 16 Oct 2007 20:36:50 -0400 Message-ID: <4715591E.6030803@bbn.com> Date: Tue, 16 Oct 2007 20:36:46 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Hardie , Henning Schulzrinne , ECRIT Subject: Re: [Ecrit] Comments on framework-03 References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> <03e801c80f3a$f62615b0$8d0d1f0a@cis.neustar.com> <47147798.3090706@gmx.net> <47147CB4.1010108@gmx.net> <2FE54B4F-4521-4C5D-AF1C-73561C55EA1D@cs.columbia.edu> <4714CCE0.7030004@bbn.com> <4714F8D4.3090004@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org To try to capture the issue a little more succinctly, let me recall Karl Heinz's original observation. The framework/phonebcp says: 1) Users are not expected to "dial" an emergency URN. (i.e., they're expected to use a serviceNumber) 2) Having the home dial string work is optional. 3) It's also optional for LoST to return a visited dial string (even when one exists at some layer) [per the LoST spec] So there's an apparent contradiction: The device is expected to recognize emergency calls by the fact the the user has dialed a serviceNumber, but may not have one (either home or visited). Thus, the goal of the requirement I proposed is to clarify that when (1) is true (i.e., there is a serviceNumber that the user is expected to dial to initiate emergency calls), that the LoST server (3) returns that serviceNumber. This issue is based on the assumption (stated in the BCP) that users are expected to initiate emergency calls using a serviceNumber instead of a URN/URI. As you point out, there's a second underlying assumption that LoST operators have configured in all available/relevant serviceNumbers. But I'm trying to say that there needs to be a further requirement that the LoST server include the serviceNumber in all findServiceResponses. This is slightly stronger than saying "you MUST return the values you were configured to return" -- it's more like saying "you MUST return ALL the values you were configured to return". Kind of a "don't try to be too smart" rule. Let me propose an example to try to clarify: Suppose that a LoST server had the following logical "mapping table" Region URN URI serviceNumber US urn:service:sos sip:psap@esrp.us 911 US urn:service:sos.fire sip:psap@esrp.us 911 US urn:service:pizza sip:papajohns.com [none] Now, say that the LoST server omits serviceNumber elements from findServiceResponses when validateLocation="true" -- in order to save a few bits here and there, assuming that clients are really after the validation, not the mapping. This is allowed by the LoST spec (AFAICT). However, it's also entirely reasonable that a client would only do one findService request in order to validate and get the mapping. When this client and this server meet, and the client does a findService request with validateLocation="true", he doesn't get back a serviceNumber -- even though the LoST server knows that it's associated with the mapping. This is not a huge problem, just a corner case that would be nice to rule out. To reply specifically to your comments: > The configuration process tells > the server what to return for specific areas, so I'm really having trouble imagining > any conditions for "doesn't return it for some reason". The risk is that the server adds more logic besides "return this number for this area" based on other factors: Other parameters in the request (like validateLocation), whether the location is geodetic or civic, even the IP address of the requestor. > It sounds like we at least agree that we're not trying > to have anyone set up new serviceNumbers for services they plan to deploy, > and that's important. We definitely agree on that point. I'm just trying to make sure that existing, configured serviceNumbers get maximal distribution. Cheers, --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 16 23:39:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhzjB-0001oG-F9; Tue, 16 Oct 2007 23:37:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ihzj9-0001lD-7k for ecrit@ietf.org; Tue, 16 Oct 2007 23:37:47 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ihzj5-0004zb-Hr for ecrit@ietf.org; Tue, 16 Oct 2007 23:37:44 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9H3bHv8006658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Oct 2007 20:37:17 -0700 Received: from [98.207.5.180] (vpn-10-50-16-48.qualcomm.com [10.50.16.48]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9H3bFpg017784; Tue, 16 Oct 2007 20:37:16 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4715591E.6030803@bbn.com> References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p> <03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com> <03e801c80f3a$f62615b0$8d0d1f0a@cis.neustar.com> <47147798.3090706@gmx.net> <47147CB4.1010108@gmx.net> <2FE54B4F-4521-4C5D-AF1C-73561C55EA1D@cs.columbia.edu> <4714CCE0.7030004@bbn.com> <4714F8D4.3090004@bbn.com> <4715591E.6030803@bbn.com> Date: Tue, 16 Oct 2007 20:37:21 -0700 To: Richard Barnes , Henning Schulzrinne , ECRIT From: Ted Hardie Subject: Re: [Ecrit] Comments on framework-03 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 8:36 PM -0400 10/16/07, Richard Barnes wrote: >To try to capture the issue a little more succinctly, let me recall Karl Heinz's original observation. The framework/phonebcp says: > >1) Users are not expected to "dial" an emergency URN. (i.e., they're expected to use a serviceNumber) > >2) Having the home dial string work is optional. > >3) It's also optional for LoST to return a visited dial string (even when one exists at some layer) [per the LoST spec] ("home" and "visited" are loaded terms; I'd prefer to avoid them). Yes, this can happen. It *will* happen whenever the folks maintaining a LoST server include any service that does not have a serviceNumber. (Such services may be reachable through some other UI element, such populating a directory entry for "Poison Control" or "Suicide Prevention" which has been pre-configured). The most common emergency services may get serviceNumbers, and the responders there may well get trained on pushing things to more unusual responders when they get dialed. But it is ultimately up to a jurisdiction to determine what serviceNumbers get mapped to what service URNs. Putting this another way, we may be able to reduce this happening when a service URN and serviceNumber are both available, but we should not be blind to the fact it will happen. We also may not be the right people to judge whether a jurisdiction making this choice is making a mistake. We also have to be aware that treating serviceNumber as a UI construct has an inherent problem if there are multiple schemes returned (If I dial the serviceNumber and there were sip, xmpp, and sms URIs present, which one gets picked?) >So there's an apparent contradiction: The device is expected to recognize emergency calls by the fact the the user has dialed a serviceNumber, but may not have one (either home or visited). Thus, the goal of the requirement I proposed is to clarify that when (1) is true (i.e., there is a serviceNumber that the user is expected to dial to initiate emergency calls), that the LoST server (3) returns that serviceNumber. This issue is based on the assumption (stated in the BCP) that users are expected to initiate emergency calls using a serviceNumber instead of a URN/URI. > >As you point out, there's a second underlying assumption that LoST operators have configured in all available/relevant serviceNumbers. But I'm trying to say that there needs to be a further requirement that the LoST server include the serviceNumber in all findServiceResponses. >This is slightly stronger than saying "you MUST return the values you were configured to return" -- it's more like saying "you MUST return ALL the values you were configured to return". Kind of a "don't try to be too smart" rule. Well, serviceNumber is part of the mapping (like the URIs returned), and I really have trouble picturing this problem arising, but if you wanted to include advice like: "The element returned with a response to a request including a should be identical to that returned as a response to the same request where location validation is not requested." I would be okay with that. If there are other examples where you think the responses might vary, we should discuss them. Thanks for your efforts to clarify the discussion. Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 17 00:07:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii0Az-0001sZ-Sr; Wed, 17 Oct 2007 00:06:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii0Ay-0001pt-5c for ecrit@ietf.org; Wed, 17 Oct 2007 00:06:32 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ii0As-0004qN-07 for ecrit@ietf.org; Wed, 17 Oct 2007 00:06:32 -0400 X-SEF-Processed: 5_0_0_910__2007_10_16_23_16_12 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 16 Oct 2007 23:16:12 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Oct 2007 23:06:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Comments on framework-03 Date: Tue, 16 Oct 2007 23:06:08 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on framework-03 Thread-Index: AcgQb/+L+EXNYS6DRSSkKo4esYISxQAAt4Cg References: <7582BC68E4994F4ABF0BD4723975C3FA05FFC6FB@crexc41p><03df01c80f31$eefbe980$8d0d1f0a@cis.neustar.com><03e801c80f3a$f62615b0$8d0d1f0a@cis.neustar.com><47147798.3090706@gmx.net><47147CB4.1010108@gmx.net><2FE54B4F-4521-4C5D-AF1C-73561C55EA1D@cs.columbia.edu><4714CCE0.7030004@bbn.com> <4714F8D4.3090004@bbn.com> <4715591E.6030803@bbn.com> From: "Winterbottom, James" To: "Ted Hardie" , "Richard Barnes" , "Henning Schulzrinne" , "ECRIT" X-OriginalArrivalTime: 17 Oct 2007 04:06:09.0976 (UTC) FILETIME=[0CA93B80:01C81073] X-Spam-Score: 1.8 (+) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Looking at this from the outside in, it may be that we need a set of=0D=0Av= ery short BCPs that provide some guidance on good things to do when=0D=0Apr= ovisioning a LoST server.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A> -= ----Original Message-----=0D=0A> From: Ted Hardie [mailto:hardie@qualcomm.c= om]=0D=0A> Sent: Wednesday, 17 October 2007 1:37 PM=0D=0A> To: Richard Barn= es; Henning Schulzrinne; ECRIT=0D=0A> Subject: Re: [Ecrit] Comments on fram= ework-03=0D=0A>=20=0D=0A> At 8:36 PM -0400 10/16/07, Richard Barnes wrote:=0D= =0A> >To try to capture the issue a little more succinctly, let me recall=0D= =0AKarl=0D=0A> Heinz's original observation. The framework/phonebcp says:=0D= =0A> >=0D=0A> >1) Users are not expected to "dial" an emergency URN. (i.e.= , they're=0D=0A> expected to use a serviceNumber)=0D=0A> >=0D=0A> >2) Havin= g the home dial string work is optional.=0D=0A> >=0D=0A> >3) It's also opti= onal for LoST to return a visited dial string (even=0D=0Awhen=0D=0A> one ex= ists at some layer) [per the LoST spec]=0D=0A>=20=0D=0A> ("home" and "visit= ed" are loaded terms; I'd prefer to avoid them).=0D=0A>=20=0D=0A> Yes, this= can happen. It *will* happen whenever the folks maintaining=0D=0A> a LoST= server include any service that does not have a serviceNumber.=0D=0A> (Suc= h services may be reachable through some other UI element, such=0D=0A> popu= lating a directory entry for "Poison Control" or "Suicide=0D=0APrevention"=0D= =0A> which has been pre-configured). The most common emergency services=0D= =0A> may get serviceNumbers, and the responders there may well get trained=0D= =0A> on pushing things to more unusual responders when they get dialed.=0D=0A= > But it is ultimately up to a jurisdiction to determine what=0D=0AserviceN= umbers=0D=0A> get mapped to what service URNs.=0D=0A>=20=0D=0A> Putting thi= s another way, we may be able to reduce this happening when=0D=0A> a servic= e URN and serviceNumber are both available, but we should not=0D=0Abe=0D=0A= > blind to the fact it will happen. We also may not be the right people=0D= =0Ato=0D=0A> judge whether a jurisdiction making this choice is making a mi= stake.=0D=0A>=20=0D=0A> We also have to be aware that treating serviceNumbe= r as a UI construct=0D=0Ahas=0D=0A> an inherent problem if there are multip= le schemes returned (If I dial=0D=0A> the serviceNumber and there were sip,= xmpp, and sms URIs present,=0D=0Awhich=0D=0A> one gets picked=3F)=0D=0A> =0D= =0A> >So there's an apparent contradiction: The device is expected to=0D=0A= recognize=0D=0A> emergency calls by the fact the the user has dialed a serv= iceNumber,=0D=0Abut=0D=0A> may not have one (either home or visited). Thus= , the goal of the=0D=0A> requirement I proposed is to clarify that when (1)= is true (i.e.,=0D=0Athere is=0D=0A> a serviceNumber that the user is expec= ted to dial to initiate=0D=0Aemergency=0D=0A> calls), that the LoST server = (3) returns that serviceNumber. This=0D=0Aissue=0D=0A> is based on the ass= umption (stated in the BCP) that users are expected=0D=0Ato=0D=0A> initiate= emergency calls using a serviceNumber instead of a URN/URI.=0D=0A> >=0D=0A= > >As you point out, there's a second underlying assumption that LoST=0D=0A= > operators have configured in all available/relevant serviceNumbers.=0D=0A= But=0D=0A> I'm trying to say that there needs to be a further requirement t= hat=0D=0Athe=0D=0A> LoST server include the serviceNumber in all findServic= eResponses.=0D=0A> >This is slightly stronger than saying "you MUST return = the values you=0D=0A> were configured to return" -- it's more like saying "= you MUST return=0D=0AALL=0D=0A> the values you were configured to return". = Kind of a "don't try to be=0D=0Atoo=0D=0A> smart" rule.=0D=0A>=20=0D=0A> W= ell, serviceNumber is part of the mapping (like the URIs returned),=0D=0Aan= d I=0D=0A> really=0D=0A> have trouble picturing this problem arising, but i= f you wanted to=0D=0Ainclude=0D=0A> advice like:=0D=0A>=20=0D=0A> "The element returned with a response to a request=0D=0Aincluding a=0D=0A= > should be identical to that returned as a=0D=0A= > response=0D=0A> to the same request where location validation is not requ= ested."=0D=0A>=20=0D=0A> I would be okay with that. If there are other exa= mples where you=0D=0Athink=0D=0A> the responses might vary, we should discu= ss them.=0D=0A>=20=0D=0A> Thanks for your efforts to clarify the discussion= =2E=0D=0A> =09=09=09=09=09Ted=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> ________= _______________________________________=0D=0A> Ecrit mailing list=0D=0A> Ec= rit@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0AThis message is for the designated recipient onl= y and may=0D=0Acontain privileged, proprietary, or otherwise private inform= ation. =20=0D=0AIf you have received it in error, please notify the sender=0D= =0Aimmediately and delete the original. Any unauthorized use of=0D=0Athis = email is prohibited.=0D=0A-------------------------------------------------= -----------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 17 04:13:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii40w-00069k-Vm; Wed, 17 Oct 2007 04:12:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii40t-00062s-LY for ecrit@ietf.org; Wed, 17 Oct 2007 04:12:23 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ii40k-0002al-AK for ecrit@ietf.org; Wed, 17 Oct 2007 04:12:15 -0400 Received: (qmail invoked by alias); 17 Oct 2007 08:12:05 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp054) with SMTP; 17 Oct 2007 10:12:05 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX185hNkaeAk5BFe/qI5sAHb0r7FlWBYeGbKrcgosbM 8R0EU95upEfzb4 Message-ID: <4715C3D2.8030307@gmx.net> Date: Wed, 17 Oct 2007 11:12:02 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Ecrit] draft-winterbottom-ecrit-specifying-holes-00 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: ecrit X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Martin, Hi James, thanks for the document. A few comments: * I don't think this type of document is a BCP. The draft header says GEOPRIV rather than ECRIT. I wonder whether you think that the document updates draft-ietf-ecrit-lost-06? * Introduction "The boundary is a polygon made up of sets of geodetic coordinates specifying an enclosed area." The boundary may also be expressed using civic location info. We did not specify holes for civic location information, however. I think we should also investigate that aspect! "This document describes how holes SHOULD be specified in service boundaries defined using a GML encoding for the polygons and their internal elements (holes)." The RFC 2119 "SHOULD" in this sentence is not appropriate here. No interoperability issue in this document. Maybe you want to reference the figure in the text and to add a caption to it. * Section 3 The rules seem to be fine with me although one might argue that they are common sense. " A hole MUST be a legal polygon in accordance with the geoshape specification [geoshape]. There is no restriction on the number of points that may be used to express the perimeter of the hole. " I would rather write: " A hole MUST be a legal polygon in accordance with the geoshape specification [geoshape] with the exception that there is no restriction on the number of points that may be used to express the perimeter of the hole. " I recall that there is this 16 point restriction in the geoshape document. * Section 4: I assume that this section is more a reminder on how the polygon is specified in PIDF-LO profile/Geoshapes. Do you think it is necessary? * Section 6 I wonder whether you really need a normative reference to [I-D.schulzrinne-ecrit-lost-sync]. In some sense I am a bit confused about this section. While I see it being useful to have a mechanism for synchronizing information between LoST servers I wonder why holes in polygons of service boundaries are really so special that a description of the synchronization mechanism is necessary. * IANA Considerations It is good to see that you believe that the location profile "geodetic-2d" can be reused instead of defining an additional, new location profile. Ciao Hannes Winterbottom, James wrote: > FYI, > > > A new version of I-D, draft-winterbottom-ecrit-specifying-holes-00.txt > has been successfully submitted by James Winterbottom and posted to the > IETF repository. > > Filename: draft-winterbottom-ecrit-specifying-holes > Revision: 00 > Title: Specifying Holes in LoST Service Boundaries > Creation_date: 2007-10-11 > WG ID: Independent Submission > Number_of_pages: 16 > > Abstract: > This document describes how holes can be specified in service > boundaries. One means of implementing a solution is described. > > http://tools.ietf.org/html/draft-winterbottom-ecrit-specifying-holes-00 > > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 17 07:51:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii7PY-0000LK-3D; Wed, 17 Oct 2007 07:50:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii7PW-0000L6-Qf for ecrit@ietf.org; Wed, 17 Oct 2007 07:50:02 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ii7PW-0002Fl-3q for ecrit@ietf.org; Wed, 17 Oct 2007 07:50:02 -0400 X-IronPort-AV: E=Sophos;i="4.21,289,1188792000"; d="scan'208";a="74201234" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 17 Oct 2007 07:50:01 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9HBo1ih019568; Wed, 17 Oct 2007 07:50:01 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9HBnsk7010028; Wed, 17 Oct 2007 11:49:54 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); Wed, 17 Oct 2007 07:49:54 -0400 Received: from mlinsnerwxp02 ([10.21.119.226]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Oct 2007 07:49:53 -0400 From: "Marc Linsner" To: "'Winterbottom, James'" , "'ECRIT'" Subject: RE: [Ecrit] Comments on framework-03 Date: Wed, 17 Oct 2007 07:49:48 -0400 Message-ID: <002601c810b3$d47b2610$e277150a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcgQb/+L+EXNYS6DRSSkKo4esYISxQAAt4CgABA0j6A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-OriginalArrivalTime: 17 Oct 2007 11:49:53.0765 (UTC) FILETIME=[D4EE8150:01C810B3] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15488.002 X-TM-AS-Result: No--39.523100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5359; t=1192621801; x=1193485801; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20Comments=20on=20framework-03 |Sender:=20 |To:=20=22'Winterbottom, =20James'=22=20, =0 A=20=20=20=20=20=20=20=20=22'ECRIT'=22=20; bh=AQ9r10LiOdYQNCRkZmpTGY9ROfBpLsjk2QoMKZvnS50=; b=AMAu1Os5fpZCGHC1iBLro/H5og2rU597rpXofxn1YaSMYVxetSccyQEoRtJt/DGd6i8vOqcf LDUwlNgIlhr0HtKwrl/vAEIAiKYTNPuvGv7/cG1lNfxrKzLp2aeAUZHy; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This might be a better task for NENA. -Marc- > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Wednesday, October 17, 2007 12:06 AM > To: Ted Hardie; Richard Barnes; Henning Schulzrinne; ECRIT > Subject: RE: [Ecrit] Comments on framework-03 > > Looking at this from the outside in, it may be that we need a > set of very short BCPs that provide some guidance on good > things to do when provisioning a LoST server. > > Cheers > James > > > > -----Original Message----- > > From: Ted Hardie [mailto:hardie@qualcomm.com] > > Sent: Wednesday, 17 October 2007 1:37 PM > > To: Richard Barnes; Henning Schulzrinne; ECRIT > > Subject: Re: [Ecrit] Comments on framework-03 > > > > At 8:36 PM -0400 10/16/07, Richard Barnes wrote: > > >To try to capture the issue a little more succinctly, let me recall > Karl > > Heinz's original observation. The framework/phonebcp says: > > > > > >1) Users are not expected to "dial" an emergency URN. > (i.e., they're > > expected to use a serviceNumber) > > > > > >2) Having the home dial string work is optional. > > > > > >3) It's also optional for LoST to return a visited dial > string (even > when > > one exists at some layer) [per the LoST spec] > > > > ("home" and "visited" are loaded terms; I'd prefer to avoid them). > > > > Yes, this can happen. It *will* happen whenever the folks > maintaining > > a LoST server include any service that does not have a > serviceNumber. > > (Such services may be reachable through some other UI element, such > > populating a directory entry for "Poison Control" or "Suicide > Prevention" > > which has been pre-configured). The most common emergency services > > may get serviceNumbers, and the responders there may well > get trained > > on pushing things to more unusual responders when they get dialed. > > But it is ultimately up to a jurisdiction to determine what > serviceNumbers > > get mapped to what service URNs. > > > > Putting this another way, we may be able to reduce this > happening when > > a service URN and serviceNumber are both available, but we > should not > be > > blind to the fact it will happen. We also may not be the > right people > to > > judge whether a jurisdiction making this choice is making a mistake. > > > > We also have to be aware that treating serviceNumber as a > UI construct > has > > an inherent problem if there are multiple schemes returned > (If I dial > > the serviceNumber and there were sip, xmpp, and sms URIs present, > which > > one gets picked?) > > > > >So there's an apparent contradiction: The device is expected to > recognize > > emergency calls by the fact the the user has dialed a serviceNumber, > but > > may not have one (either home or visited). Thus, the goal of the > > requirement I proposed is to clarify that when (1) is true (i.e., > there is > > a serviceNumber that the user is expected to dial to initiate > emergency > > calls), that the LoST server (3) returns that serviceNumber. This > issue > > is based on the assumption (stated in the BCP) that users > are expected > to > > initiate emergency calls using a serviceNumber instead of a URN/URI. > > > > > >As you point out, there's a second underlying assumption that LoST > > operators have configured in all available/relevant serviceNumbers. > But > > I'm trying to say that there needs to be a further requirement that > the > > LoST server include the serviceNumber in all findServiceResponses. > > >This is slightly stronger than saying "you MUST return the > values you > > were configured to return" -- it's more like saying "you MUST return > ALL > > the values you were configured to return". Kind of a > "don't try to be > too > > smart" rule. > > > > Well, serviceNumber is part of the mapping (like the URIs returned), > and I > > really > > have trouble picturing this problem arising, but if you wanted to > include > > advice like: > > > > "The element returned with a response to a request > including a > > should be identical to that returned as a > > response to the same request where location validation is not > > requested." > > > > I would be okay with that. If there are other examples where you > think > > the responses might vary, we should discuss them. > > > > Thanks for your efforts to clarify the discussion. > > Ted > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 17 07:55:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii7V7-00031v-Md; Wed, 17 Oct 2007 07:55:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii7V5-00031T-A0 for ecrit@ietf.org; Wed, 17 Oct 2007 07:55:47 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ii7V4-0002Ra-IS for ecrit@ietf.org; Wed, 17 Oct 2007 07:55:47 -0400 X-SEF-Processed: 5_0_0_910__2007_10_17_07_05_49 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, 17 Oct 2007 07:05:49 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Oct 2007 06:55:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] draft-winterbottom-ecrit-specifying-holes-00 Date: Wed, 17 Oct 2007 06:55:44 -0500 Message-ID: In-Reply-To: <4715C3D2.8030307@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-winterbottom-ecrit-specifying-holes-00 Thread-Index: AcgQlWoqDSfqKCfnSk68SNSDly4Q2wAGmtQg References: <4715C3D2.8030307@gmx.net> From: "Winterbottom, James" To: "Hannes Tschofenig" X-OriginalArrivalTime: 17 Oct 2007 11:55:46.0165 (UTC) FILETIME=[A6FA7A50:01C810B4] X-Spam-Score: 1.8 (+) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: ecrit X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Hannes,=20=0D=0A=0D=0AThanks very much for the comments.=0D=0AA few comm= ents of mine inline:=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A> -----O= riginal Message-----=0D=0A> From: Hannes Tschofenig [mailto:Hannes.Tschofen= ig@gmx.net]=0D=0A> Sent: Wednesday, 17 October 2007 6:12 PM=0D=0A> To: Wint= erbottom, James=0D=0A> Cc: ecrit=0D=0A> Subject: Re: [Ecrit] draft-winterbo= ttom-ecrit-specifying-holes-00=0D=0A>=20=0D=0A> Hi Martin,=0D=0A> Hi James,=0D= =0A>=20=0D=0A> thanks for the document. A few comments:=0D=0A>=20=0D=0A> * = I don't think this type of document is a BCP. The draft header says=0D=0A> = GEOPRIV rather than ECRIT. I wonder whether you think that the=0D=0Adocumen= t=0D=0A> updates draft-ietf-ecrit-lost-06=3F=0D=0A>=20=0D=0A[AJW] Yes.. Geo= priv is a querk I shall fix that. Maybe it updates LoST,=0D=0AI actually wa= nted this document as an appendix to Henning's file-format=0D=0Adocument bu= t he refused. May be it stands on its own.=0D=0A=0D=0A=0D=0A> * Introductio= n=0D=0A>=20=0D=0A> "The boundary is a polygon made up of sets of geodetic c= oordinates=0D=0A> specifying an enclosed area."=0D=0A>=20=0D=0A> The bounda= ry may also be expressed using civic location info. We did=0D=0Anot=0D=0A> = specify holes for civic location information, however. I think we=0D=0Ashou= ld=0D=0A> also investigate that aspect!=0D=0A>=20=0D=0A[AJW] Yes in so far = as Civic needs to express areas too, and I don't=0D=0Abelieve that the revi= sed civic format can cater for this. In fact I=0D=0Adon't believe that it c= an even address the kinds of ranges required=0D=0Awithout holes, and this n= eeds to be explored in a lot more detail.=0D=0ACurrently I view it as out o= f scope for this document.=0D=0A=0D=0A> "This document describes how holes = SHOULD be specified in service=0D=0A> boundaries defined using a GML encodi= ng for the polygons and their=0D=0A> internal elements (holes)."=0D=0A>=20=0D= =0A> The RFC 2119 "SHOULD" in this sentence is not appropriate here. No=0D=0A= > interoperability issue in this document.=0D=0A>=20=0D=0A[AJW] I don't thi= nk that this is quite right. Polygons don't strictly=0D=0Aspeaking, allow b= oundary lines to cross on another, and similarly, other=0D=0Athan the first= and last points it isn't good practice to share points.=0D=0AUnless this i= s clearly pointed out, it may well lead to interoperability=0D=0Aproblems.=0D= =0A=0D=0A=0D=0A> Maybe you want to reference the figure in the text and to = add a=0D=0Acaption=0D=0A> to it.=0D=0A>=20=0D=0A>=20=0D=0A> * Section 3=0D=0A= >=20=0D=0A> The rules seem to be fine with me although one might argue that= they=0D=0Aare=0D=0A> common sense.=0D=0A=0D=0A=0D=0A[AJW] I actually had t= o clarify my rationale to at least one person, and=0D=0Athat was reflected = back into the rules as you see them. So maybe they=0D=0Aare only common sen= se after they spelt out.=0D=0A=0D=0A>=20=0D=0A> "=0D=0A> A hole MUST be a l= egal polygon in accordance with the geoshape=0D=0A> specification [geoshape= ]. There is no restriction on the number of=0D=0A> points that may be used = to express the perimeter of the hole.=0D=0A> "=0D=0A>=20=0D=0A> I would rat= her write:=0D=0A>=20=0D=0A> "=0D=0A> A hole MUST be a legal polygon in acco= rdance with the geoshape=0D=0A> specification [geoshape] with the exception= that there is no=0D=0Arestriction=0D=0A> on the number of points that may = be used to express the perimeter of=0D=0Athe=0D=0A> hole.=0D=0A> "=0D=0A> =0D= =0A> I recall that there is this 16 point restriction in the geoshape=0D=0A= document.=0D=0A>=0D=0A[AJW] Not quite. GeoShape says that if interoperabili= ty with 3GPP GAD is=0D=0Arequired that points in total must not exceed 16 p= oints. There is no=0D=0A3GPP GAD interoperability required in this case bec= ause we are=0D=0Aexpressing a service boundary and not a Target Location.=0D= =0A=0D=0A=20=0D=0A> * Section 4: I assume that this section is more a remin= der on how the=0D=0A> polygon is specified in PIDF-LO profile/Geoshapes.=0D= =0A> Do you think it is necessary=3F=0D=0A>=0D=0A[AJW] Probably not. I will= delete this in the next version.=0D=0A=0D=0A=20=0D=0A> * Section 6=0D=0A> =0D= =0A> I wonder whether you really need a normative reference to=0D=0A> [I-D.= schulzrinne-ecrit-lost-sync]. In some sense I am a bit confused=0D=0A> abou= t this section. While I see it being useful to have a mechanism=0D=0Afor=0D= =0A> synchronizing information between LoST servers I wonder why holes in=0D= =0A> polygons of service boundaries are really so special that a=0D=0Adescr= iption=0D=0A> of the synchronization mechanism is necessary.=0D=0A>=0D=0A[A= JW] The rationale for this may be flawed. I see Henning's document as=0D=0A= not only defining the file inter-change format between LoST servers but=0D=0A= also forming the basis for data feeds into LoST servers. Having a=0D=0Astan= dard format for this kind of thing is a good idea, and I don't see=0D=0Awhy= Henning's suggested format couldn't work in this area. Again common=0D=0As= ense dictates one format is better than many.=0D=0A=0D=0A=20=0D=0A> * IANA = Considerations=0D=0A>=20=0D=0A> It is good to see that you believe that the= location profile=0D=0A> "geodetic-2d" can be reused instead of defining an= additional, new=0D=0A> location profile.=0D=0A>=20=0D=0A> Ciao=0D=0A> Hann= es=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> Winterbottom, James wrote:=0D=0A> >= FYI,=0D=0A> >=0D=0A> >=0D=0A> > A new version of I-D,=0D=0Adraft-winterbot= tom-ecrit-specifying-holes-00.txt=0D=0A> > has been successfully submitted = by James Winterbottom and posted to=0D=0Athe=0D=0A> > IETF repository.=0D=0A= > >=0D=0A> > Filename:=09 draft-winterbottom-ecrit-specifying-holes=0D=0A> = > Revision:=09 00=0D=0A> > Title:=09=09 Specifying Holes in LoST Service Bo= undaries=0D=0A> > Creation_date:=09 2007-10-11=0D=0A> > WG ID:=09=09 Indepe= ndent Submission=0D=0A> > Number_of_pages: 16=0D=0A> >=0D=0A> > Abstract:=0D= =0A> > This document describes how holes can be specified in service=0D=0A>= > boundaries. One means of implementing a solution is described.=0D=0A> >=0D= =0A> >=0D=0Ahttp://tools.ietf.org/html/draft-winterbottom-ecrit-specifying-= holes-00=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A----------------------------------= --------------------------------------=0D=0A> ------------------------=0D=0A= > > This message is for the designated recipient only and may=0D=0A> > cont= ain privileged, proprietary, or otherwise private information.=0D=0A> > If = you have received it in error, please notify the sender=0D=0A> > immediatel= y and delete 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> > _______________________________________________=0D=0A= > > Ecrit mailing list=0D=0A> > Ecrit@ietf.org=0D=0A> > https://www1.ietf.o= rg/mailman/listinfo/ecrit=0D=0A> >=0D=0A>=20=0D=0A=0D=0A-------------------= ---------------------------------------------------------------------------= --=0D=0AThis message is for the designated recipient only and may=0D=0Acont= ain privileged, proprietary, or otherwise private information. =20=0D=0AIf = you have received it in error, please notify the sender=0D=0Aimmediately an= d delete the original. Any unauthorized use of=0D=0Athis email is prohibit= ed.=0D=0A------------------------------------------------------------------= ------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 17 07:57:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii7Ux-0002zd-2L; Wed, 17 Oct 2007 07:55:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii7Uv-0002yM-HO for ecrit@ietf.org; Wed, 17 Oct 2007 07:55:37 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ii7Up-0001ft-BH for ecrit@ietf.org; Wed, 17 Oct 2007 07:55:37 -0400 X-SEF-Processed: 5_0_0_910__2007_10_17_07_05_18 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 17 Oct 2007 07:05:18 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Oct 2007 06:55:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Comments on framework-03 Date: Wed, 17 Oct 2007 06:55:13 -0500 Message-ID: In-Reply-To: <002601c810b3$d47b2610$e277150a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on framework-03 Thread-Index: AcgQb/+L+EXNYS6DRSSkKo4esYISxQAAt4CgABA0j6AAACu3IA== References: <002601c810b3$d47b2610$e277150a@cisco.com> From: "Winterbottom, James" To: "Marc Linsner" , "ECRIT" X-OriginalArrivalTime: 17 Oct 2007 11:55:15.0708 (UTC) FILETIME=[94D31BC0:01C810B4] X-Spam-Score: 1.8 (+) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org That could be too.=0D=0AI don't really have an opinion either way. I just t= hink some degree of=0D=0Aclarification is required.=0D=0A=0D=0ACheers=0D=0A= James=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Marc Linsn= er [mailto:mlinsner@cisco.com]=0D=0A> Sent: Wednesday, 17 October 2007 9:50= PM=0D=0A> To: Winterbottom, James; 'ECRIT'=0D=0A> Subject: RE: [Ecrit] Com= ments on framework-03=0D=0A>=20=0D=0A> This might be a better task for NENA= =2E=0D=0A>=20=0D=0A> -Marc-=0D=0A>=20=0D=0A> > -----Original Message-----=0D= =0A> > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=0D=0A= > > Sent: Wednesday, October 17, 2007 12:06 AM=0D=0A> > To: Ted Hardie; Ric= hard Barnes; Henning Schulzrinne; ECRIT=0D=0A> > Subject: RE: [Ecrit] Comme= nts on framework-03=0D=0A> >=0D=0A> > Looking at this from the outside in, = it may be that we need a=0D=0A> > set of very short BCPs that provide some = guidance on good=0D=0A> > things to do when provisioning a LoST server.=0D=0A= > >=0D=0A> > Cheers=0D=0A> > James=0D=0A> >=0D=0A> >=0D=0A> > > -----Origin= al Message-----=0D=0A> > > From: Ted Hardie [mailto:hardie@qualcomm.com]=0D= =0A> > > Sent: Wednesday, 17 October 2007 1:37 PM=0D=0A> > > To: Richard Ba= rnes; Henning Schulzrinne; ECRIT=0D=0A> > > Subject: Re: [Ecrit] Comments o= n framework-03=0D=0A> > >=0D=0A> > > At 8:36 PM -0400 10/16/07, Richard Bar= nes wrote:=0D=0A> > > >To try to capture the issue a little more succinctly= , let me=0D=0Arecall=0D=0A> > Karl=0D=0A> > > Heinz's original observation.= The framework/phonebcp says:=0D=0A> > > >=0D=0A> > > >1) Users are not ex= pected to "dial" an emergency URN.=0D=0A> > (i.e., they're=0D=0A> > > expec= ted to use a serviceNumber)=0D=0A> > > >=0D=0A> > > >2) Having the home dia= l string work is optional.=0D=0A> > > >=0D=0A> > > >3) It's also optional f= or LoST to return a visited dial=0D=0A> > string (even=0D=0A> > when=0D=0A>= > > one exists at some layer) [per the LoST spec]=0D=0A> > >=0D=0A> > > ("= home" and "visited" are loaded terms; I'd prefer to avoid them).=0D=0A> > >=0D= =0A> > > Yes, this can happen. It *will* happen whenever the folks=0D=0A> = > maintaining=0D=0A> > > a LoST server include any service that does not ha= ve a=0D=0A> > serviceNumber.=0D=0A> > > (Such services may be reachable thr= ough some other UI element,=0D=0Asuch=0D=0A> > > populating a directory ent= ry for "Poison Control" or "Suicide=0D=0A> > Prevention"=0D=0A> > > which h= as been pre-configured). The most common emergency=0D=0Aservices=0D=0A> > = > may get serviceNumbers, and the responders there may well=0D=0A> > get tr= ained=0D=0A> > > on pushing things to more unusual responders when they get= dialed.=0D=0A> > > But it is ultimately up to a jurisdiction to determine = what=0D=0A> > serviceNumbers=0D=0A> > > get mapped to what service URNs.=0D= =0A> > >=0D=0A> > > Putting this another way, we may be able to reduce this=0D= =0A> > happening when=0D=0A> > > a service URN and serviceNumber are both = available, but we=0D=0A> > should not=0D=0A> > be=0D=0A> > > blind to the f= act it will happen. We also may not be the=0D=0A> > right people=0D=0A> > = to=0D=0A> > > judge whether a jurisdiction making this choice is making a=0D= =0Amistake.=0D=0A> > >=0D=0A> > > We also have to be aware that treating se= rviceNumber as a=0D=0A> > UI construct=0D=0A> > has=0D=0A> > > an inherent = problem if there are multiple schemes returned=0D=0A> > (If I dial=0D=0A> >= > the serviceNumber and there were sip, xmpp, and sms URIs present,=0D=0A>= > which=0D=0A> > > one gets picked=3F)=0D=0A> > >=0D=0A> > > >So there's a= n apparent contradiction: The device is expected to=0D=0A> > recognize=0D=0A= > > > emergency calls by the fact the the user has dialed a=0D=0AserviceNum= ber,=0D=0A> > but=0D=0A> > > may not have one (either home or visited). Th= us, the goal of the=0D=0A> > > requirement I proposed is to clarify that wh= en (1) is true (i.e.,=0D=0A> > there is=0D=0A> > > a serviceNumber that the= user is expected to dial to initiate=0D=0A> > emergency=0D=0A> > > calls),= that the LoST server (3) returns that serviceNumber. This=0D=0A> > issue=0D= =0A> > > is based on the assumption (stated in the BCP) that users=0D=0A> >= are expected=0D=0A> > to=0D=0A> > > initiate emergency calls using a servi= ceNumber instead of a=0D=0AURN/URI.=0D=0A> > > >=0D=0A> > > >As you point o= ut, there's a second underlying assumption that=0D=0ALoST=0D=0A> > > operat= ors have configured in all available/relevant=0D=0AserviceNumbers.=0D=0A> >= But=0D=0A> > > I'm trying to say that there needs to be a further requirem= ent=0D=0Athat=0D=0A> > the=0D=0A> > > LoST server include the serviceNumber= in all findServiceResponses.=0D=0A> > > >This is slightly stronger than sa= ying "you MUST return the=0D=0A> > values you=0D=0A> > > were configured to= return" -- it's more like saying "you MUST=0D=0Areturn=0D=0A> > ALL=0D=0A>= > > the values you were configured to return". Kind of a=0D=0A> > "don't = try to be=0D=0A> > too=0D=0A> > > smart" rule.=0D=0A> > >=0D=0A> > > Well, = serviceNumber is part of the mapping (like the URIs=0D=0Areturned),=0D=0A> = > and I=0D=0A> > > really=0D=0A> > > have trouble picturing this problem ar= ising, but if you wanted to=0D=0A> > include=0D=0A> > > advice like:=0D=0A>= > >=0D=0A> > > "The element returned with a response to a reque= st=0D=0A> > including a=0D=0A> > > should be ide= ntical to that returned as a=0D=0A> > > response to the same request where = location validation is not=0D=0A> > > requested."=0D=0A> > >=0D=0A> > > I w= ould be okay with that. If there are other examples where you=0D=0A> > thi= nk=0D=0A> > > the responses might vary, we should discuss them.=0D=0A> > >=0D= =0A> > > Thanks for your efforts to clarify the discussion.=0D=0A> > > =09=09= =09=09=09Ted=0D=0A> > >=0D=0A> > >=0D=0A> > >=0D=0A> > > __________________= _____________________________=0D=0A> > > Ecrit mailing list=0D=0A> > > Ecri= t@ietf.org=0D=0A> > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> >=0D= =0A> > --------------------------------------------------------------=0D=0A= > > ----------------------------------=0D=0A> > This message is for the des= ignated recipient only and may=0D=0A> > contain privileged, proprietary, or= otherwise private information.=0D=0A> > If you have received it in error, = please notify the sender=0D=0A> > immediately and delete the original. Any= unauthorized use of=0D=0A> > this email is prohibited.=0D=0A> > ----------= ----------------------------------------------------=0D=0A> > -------------= ---------------------=0D=0A> > [mf2]=0D=0A> >=0D=0A> >=0D=0A> > ___________= ____________________________________=0D=0A> > Ecrit mailing list=0D=0A> > E= crit@ietf.org=0D=0A> > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0AThis message is for the designated recipient = only and may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 17 08:35:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii86E-0002uH-8m; Wed, 17 Oct 2007 08:34:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii86C-0002t5-AP for ecrit@ietf.org; Wed, 17 Oct 2007 08:34:08 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ii86B-0003Uz-CS for ecrit@ietf.org; Wed, 17 Oct 2007 08:34:08 -0400 Received: from [24.154.127.115] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Ii863-0003Gk-51; Wed, 17 Oct 2007 07:33:59 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Marc Linsner'" , "'ECRIT'" References: <002601c810b3$d47b2610$e277150a@cisco.com> Subject: RE: [Ecrit] Comments on framework-03 Date: Wed, 17 Oct 2007 08:34:03 -0400 Message-ID: <072401c810ba$0203e3f0$8d0d1f0a@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcgQb/+L+EXNYS6DRSSkKo4esYISxQAAt4CgABA0j6AAACu3IAAAstfQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org NENA has determined that the 9-1-1 Authority (the government agency that runs a local emergency call system) will be responsible to provide LoST servers, and will have documents that describe what they should do and how they should be configured. I would like IETF documents to result in implementations that meet NENA's requirements on the query side at least. How the servers are actually provisioned is NENA's problem I think. However, I don't think this is enough, I think we need to leave proxy and phone vendors, and network operators, with systems that work regardless of where a subscriber roams or nomads (sic). I think that means more text in IETF documents. I wonder if we should look at it as there is no harm in providing the number even if the device has another way to get it (conflicts between them are a problem, but too little information is much worse than too much here). So, maybe we should have the text be MUST except if the only operation is validation or the service URN doesn't have a dial string to give. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Wednesday, October 17, 2007 7:55 AM > To: Marc Linsner; ECRIT > Subject: RE: [Ecrit] Comments on framework-03 > > That could be too. > I don't really have an opinion either way. I just think some degree of > clarification is required. > > Cheers > James > > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Wednesday, 17 October 2007 9:50 PM > > To: Winterbottom, James; 'ECRIT' > > Subject: RE: [Ecrit] Comments on framework-03 > > > > This might be a better task for NENA. > > > > -Marc- > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Wednesday, October 17, 2007 12:06 AM > > > To: Ted Hardie; Richard Barnes; Henning Schulzrinne; ECRIT > > > Subject: RE: [Ecrit] Comments on framework-03 > > > > > > Looking at this from the outside in, it may be that we need a > > > set of very short BCPs that provide some guidance on good > > > things to do when provisioning a LoST server. > > > > > > Cheers > > > James > > > > > > > > > > -----Original Message----- > > > > From: Ted Hardie [mailto:hardie@qualcomm.com] > > > > Sent: Wednesday, 17 October 2007 1:37 PM > > > > To: Richard Barnes; Henning Schulzrinne; ECRIT > > > > Subject: Re: [Ecrit] Comments on framework-03 > > > > > > > > At 8:36 PM -0400 10/16/07, Richard Barnes wrote: > > > > >To try to capture the issue a little more succinctly, let me > recall > > > Karl > > > > Heinz's original observation. The framework/phonebcp says: > > > > > > > > > >1) Users are not expected to "dial" an emergency URN. > > > (i.e., they're > > > > expected to use a serviceNumber) > > > > > > > > > >2) Having the home dial string work is optional. > > > > > > > > > >3) It's also optional for LoST to return a visited dial > > > string (even > > > when > > > > one exists at some layer) [per the LoST spec] > > > > > > > > ("home" and "visited" are loaded terms; I'd prefer to avoid them). > > > > > > > > Yes, this can happen. It *will* happen whenever the folks > > > maintaining > > > > a LoST server include any service that does not have a > > > serviceNumber. > > > > (Such services may be reachable through some other UI element, > such > > > > populating a directory entry for "Poison Control" or "Suicide > > > Prevention" > > > > which has been pre-configured). The most common emergency > services > > > > may get serviceNumbers, and the responders there may well > > > get trained > > > > on pushing things to more unusual responders when they get dialed. > > > > But it is ultimately up to a jurisdiction to determine what > > > serviceNumbers > > > > get mapped to what service URNs. > > > > > > > > Putting this another way, we may be able to reduce this > > > happening when > > > > a service URN and serviceNumber are both available, but we > > > should not > > > be > > > > blind to the fact it will happen. We also may not be the > > > right people > > > to > > > > judge whether a jurisdiction making this choice is making a > mistake. > > > > > > > > We also have to be aware that treating serviceNumber as a > > > UI construct > > > has > > > > an inherent problem if there are multiple schemes returned > > > (If I dial > > > > the serviceNumber and there were sip, xmpp, and sms URIs present, > > > which > > > > one gets picked?) > > > > > > > > >So there's an apparent contradiction: The device is expected to > > > recognize > > > > emergency calls by the fact the the user has dialed a > serviceNumber, > > > but > > > > may not have one (either home or visited). Thus, the goal of the > > > > requirement I proposed is to clarify that when (1) is true (i.e., > > > there is > > > > a serviceNumber that the user is expected to dial to initiate > > > emergency > > > > calls), that the LoST server (3) returns that serviceNumber. This > > > issue > > > > is based on the assumption (stated in the BCP) that users > > > are expected > > > to > > > > initiate emergency calls using a serviceNumber instead of a > URN/URI. > > > > > > > > > >As you point out, there's a second underlying assumption that > LoST > > > > operators have configured in all available/relevant > serviceNumbers. > > > But > > > > I'm trying to say that there needs to be a further requirement > that > > > the > > > > LoST server include the serviceNumber in all findServiceResponses. > > > > >This is slightly stronger than saying "you MUST return the > > > values you > > > > were configured to return" -- it's more like saying "you MUST > return > > > ALL > > > > the values you were configured to return". Kind of a > > > "don't try to be > > > too > > > > smart" rule. > > > > > > > > Well, serviceNumber is part of the mapping (like the URIs > returned), > > > and I > > > > really > > > > have trouble picturing this problem arising, but if you wanted to > > > include > > > > advice like: > > > > > > > > "The element returned with a response to a request > > > including a > > > > should be identical to that returned as a > > > > response to the same request where location validation is not > > > > requested." > > > > > > > > I would be okay with that. If there are other examples where you > > > think > > > > the responses might vary, we should discuss them. > > > > > > > > Thanks for your efforts to clarify the discussion. > > > > Ted > > > > > > > > > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > -------------------------------------------------------------- > > > ---------------------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > -------------------------------------------------------------- > > > ---------------------------------- > > > [mf2] > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 17 08:40:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii8CQ-0006Xt-99; Wed, 17 Oct 2007 08:40:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii8CO-0006W6-JP for ecrit@ietf.org; Wed, 17 Oct 2007 08:40:32 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ii8CO-0003fm-7B for ecrit@ietf.org; Wed, 17 Oct 2007 08:40:32 -0400 Received: from [192.168.0.41] (pool-70-21-206-158.nwrk.east.verizon.net [70.21.206.158]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l9HCeElr027581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 17 Oct 2007 08:40:15 -0400 (EDT) In-Reply-To: <072401c810ba$0203e3f0$8d0d1f0a@cis.neustar.com> References: <002601c810b3$d47b2610$e277150a@cisco.com> <072401c810ba$0203e3f0$8d0d1f0a@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Comments on framework-03 Date: Wed, 17 Oct 2007 08:40:11 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I agree with Brian's last statement. "MUST deliver if the service has one" seems easy enough to understand and implement. Even for validation, providing the service number is hardly onerous, so I'm not convinced that we need to create exceptions. On Oct 17, 2007, at 8:34 AM, Brian Rosen wrote: > NENA has determined that the 9-1-1 Authority (the government agency > that > runs a local emergency call system) will be responsible to provide > LoST > servers, and will have documents that describe what they should do > and how > they should be configured. > > I would like IETF documents to result in implementations that meet > NENA's > requirements on the query side at least. How the servers are actually > provisioned is NENA's problem I think. > > However, I don't think this is enough, I think we need to leave > proxy and > phone vendors, and network operators, with systems that work > regardless of > where a subscriber roams or nomads (sic). I think that means more > text in > IETF documents. > > I wonder if we should look at it as there is no harm in providing > the number > even if the device has another way to get it (conflicts between > them are a > problem, but too little information is much worse than too much > here). So, > maybe we should have the text be MUST except if the only operation is > validation or the service URN doesn't have a dial string to give. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 17 09:30:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii8yM-00033h-AK; Wed, 17 Oct 2007 09:30:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii8yK-00032s-IG for ecrit@ietf.org; Wed, 17 Oct 2007 09:30:04 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ii8yJ-0005KZ-8F for ecrit@ietf.org; Wed, 17 Oct 2007 09:30:03 -0400 Received: from ([139.76.131.87]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.31768973; Wed, 17 Oct 2007 09:29:25 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 17 Oct 2007 09:29:37 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 17 Oct 2007 09:29:37 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Comments on framework-03 Date: Wed, 17 Oct 2007 09:29:35 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA05FFCBBB@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Comments on framework-03 thread-index: AcgQu2H/C65RbErWSiKnZMf8hFRbsQAAm2Ag References: <002601c810b3$d47b2610$e277150a@cisco.com><072401c810ba$0203e3f0$8d0d1f0a@cis.neustar.com> From: "Stark, Barbara" To: "Henning Schulzrinne" , "Brian Rosen" X-OriginalArrivalTime: 17 Oct 2007 13:29:37.0255 (UTC) FILETIME=[C35E9F70:01C810C1] X-Spam-Score: 0.2 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Given that I had the same interpretation (mis-interpretation?) of the LoST requirements in this area as Richard, I think it would be valuable to be explicit about the LoST server returning serviceNumber values when serviceNumber values are configured, in response to a findService request. Which is to say, I also agree with what Henning and Brian seem to be saying.=20 As a NIT, then, on LoST section 3 text, which says: and A LoST client retrieves contact URIs based on location information and a service identifier with this request and response. The same query type may also ask for location validation and for service numbers, either combined with a mapping request or separately. The details can be found in Section 8 and Section 8.4. I think that the findService query type cannot "also ask" for service numbers (since there's no way in the query to ask for service numbers). Rather, the response may also include service numbers. Suggested rewording: "The same query type may also ask for location validation, either combined with a mapping request or separately. The response may also include service numbers." Barbara -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Wednesday, October 17, 2007 8:40 AM To: Brian Rosen Cc: 'ECRIT' Subject: Re: [Ecrit] Comments on framework-03 I agree with Brian's last statement. "MUST deliver if the service has =20 one" seems easy enough to understand and implement. Even for =20 validation, providing the service number is hardly onerous, so I'm =20 not convinced that we need to create exceptions. On Oct 17, 2007, at 8:34 AM, Brian Rosen wrote: > NENA has determined that the 9-1-1 Authority (the government agency =20 > that > runs a local emergency call system) will be responsible to provide =20 > LoST > servers, and will have documents that describe what they should do =20 > and how > they should be configured. > > I would like IETF documents to result in implementations that meet =20 > NENA's > requirements on the query side at least. How the servers are actually > provisioned is NENA's problem I think. > > However, I don't think this is enough, I think we need to leave =20 > proxy and > phone vendors, and network operators, with systems that work =20 > regardless of > where a subscriber roams or nomads (sic). I think that means more =20 > text in > IETF documents. > > I wonder if we should look at it as there is no harm in providing =20 > the number > even if the device has another way to get it (conflicts between =20 > them are a > problem, but too little information is much worse than too much =20 > here). So, > maybe we should have the text be MUST except if the only operation is > validation or the service URN doesn't have a dial string to give. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA623 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 17 10:14:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii9ef-0000Gx-R6; Wed, 17 Oct 2007 10:13:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ii9ee-0000G2-45 for ecrit@ietf.org; Wed, 17 Oct 2007 10:13:48 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ii9ec-0006Ln-L2 for ecrit@ietf.org; Wed, 17 Oct 2007 10:13:47 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Ii9eX-0004fa-43; Wed, 17 Oct 2007 10:13:41 -0400 Message-ID: <47161894.3070104@bbn.com> Date: Wed, 17 Oct 2007 10:13:40 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Comments on framework-03 References: <002601c810b3$d47b2610$e277150a@cisco.com> <072401c810ba$0203e3f0$8d0d1f0a@cis.neustar.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Yes. Thanks Henning, that's what I was trying to get at earlier. --RB Henning Schulzrinne wrote: > I agree with Brian's last statement. "MUST deliver if the service has > one" seems easy enough to understand and implement. Even for validation, > providing the service number is hardly onerous, so I'm not convinced > that we need to create exceptions. > > On Oct 17, 2007, at 8:34 AM, Brian Rosen wrote: > >> NENA has determined that the 9-1-1 Authority (the government agency that >> runs a local emergency call system) will be responsible to provide LoST >> servers, and will have documents that describe what they should do and >> how >> they should be configured. >> >> I would like IETF documents to result in implementations that meet NENA's >> requirements on the query side at least. How the servers are actually >> provisioned is NENA's problem I think. >> >> However, I don't think this is enough, I think we need to leave proxy and >> phone vendors, and network operators, with systems that work >> regardless of >> where a subscriber roams or nomads (sic). I think that means more >> text in >> IETF documents. >> >> I wonder if we should look at it as there is no harm in providing the >> number >> even if the device has another way to get it (conflicts between them >> are a >> problem, but too little information is much worse than too much >> here). So, >> maybe we should have the text be MUST except if the only operation is >> validation or the service URN doesn't have a dial string to give. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 18 17:18:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiclM-000765-Ta; Thu, 18 Oct 2007 17:18:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiclL-000755-Ez for ecrit@ietf.org; Thu, 18 Oct 2007 17:18:39 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iickq-000183-Rs for ecrit@ietf.org; Thu, 18 Oct 2007 17:18:39 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Iickk-0003YC-4f for ecrit@ietf.org; Thu, 18 Oct 2007 17:18:02 -0400 Message-ID: <4717CD89.1010208@bbn.com> Date: Thu, 18 Oct 2007 17:18:01 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Ecrit] LoST serviceBoundaryReference as a URI? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org It seems odd to me that LoST uses its own, unique serviceBoundaryReference format for references to service boundaries, rather than encoding the same information in a URI. Is there a compelling reason for this? It seems like having URIs that point to serviceBoundaries could be useful, as a usage of LbyR. The reference could return a PIDF-LO for the PSAP presentity with location information from the . The PSAP elements could go in field. (You could even define a "service-boundary" value for , and put the in the block. It would be nice if there were a sensible place for a service URN, but I don't see an obvious one.) There would be an expectation that these URLs would be accessible by anyone, just like SBrefs. One reason to do this would be to resolve the location hiding problem: A location provider that doesn't want to provide endpoint location to all requesters could provide instead a set of URIs: one to refer to the endpoint's location (with limited access), and others to refer to relevant PSAP SBs. Endpoints could then query LoST with locations within the provided SBs, and include these URIs as LbyR in an emergeny call. --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 18 17:30:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iicvu-0005jz-6b; Thu, 18 Oct 2007 17:29:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iicvt-0005iq-Ee for ecrit@ietf.org; Thu, 18 Oct 2007 17:29:33 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iicvg-0001Zl-8u for ecrit@ietf.org; Thu, 18 Oct 2007 17:29:33 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l9ILT3Nf028267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 18 Oct 2007 17:29:03 -0400 (EDT) In-Reply-To: <4717CD89.1010208@bbn.com> References: <4717CD89.1010208@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST serviceBoundaryReference as a URI? Date: Thu, 18 Oct 2007 17:30:39 -0400 To: Richard Barnes X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This was discussed earlier. The reason is that we want to be able to use the caching mechanisms in LoST, so we want to refer to an object, not a location. Plus, we currently do not have a LoST URL as such. Henning On Oct 18, 2007, at 5:18 PM, Richard Barnes wrote: > It seems odd to me that LoST uses its own, unique > serviceBoundaryReference format for references to service > boundaries, rather than encoding the same information in a URI. Is > there a compelling reason for this? > > It seems like having URIs that point to serviceBoundaries could be > useful, as a usage of LbyR. The reference could return a PIDF-LO > for the PSAP presentity with location information from the > . The PSAP elements could go in > field. (You could even define a "service-boundary" value for > , and put the in the block. It would > be nice if there were a sensible place for a service URN, but I > don't see an obvious one.) There would be an expectation that > these URLs would be accessible by anyone, just like SBrefs. > > One reason to do this would be to resolve the location hiding > problem: A location provider that doesn't want to provide endpoint > location to all requesters could provide instead a set of URIs: one > to refer to the endpoint's location (with limited access), and > others to refer to relevant PSAP SBs. Endpoints could then query > LoST with locations within the provided SBs, and include these URIs > as LbyR in an emergeny call. > > --Richard > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 18 18:40:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iie1c-0004Bu-3G; Thu, 18 Oct 2007 18:39:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iie1a-0004Ac-Ov for ecrit@ietf.org; Thu, 18 Oct 2007 18:39:30 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iie1M-0004HP-KK for ecrit@ietf.org; Thu, 18 Oct 2007 18:39:25 -0400 Received: (qmail invoked by alias); 18 Oct 2007 22:38:47 -0000 Received: from p5498542D.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.84.45] by mail.gmx.net (mp029) with SMTP; 19 Oct 2007 00:38:47 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/Y8ZtpAkDYjYsSxOIxGaLavOcEWX3vmLPQvn4hr0 MgnSI5xpNnLmGX Message-ID: <4717E077.60608@gmx.net> Date: Fri, 19 Oct 2007 00:38:47 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: de672dd48bf7248e70d446cd2da63266 Subject: [Ecrit] Review of draft-ietf-ecrit-framework-03 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian, James, Andy, Henning, I went through the framework draft http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-03.txt and have a few comments. The document is getting better and better. Thank you Brian for the substantial update. Technical Comments: ------------------- * Section 3 gives the impression that the emergency services variant that requires the end host to -- recognize the emergency call, -- obtain location information, and to -- determine the PSAP URI is the only variant. That's, however, not true as the later text in the document reveals. Hence, I suggest that this section is labeled as an example. Additionally, I would highlight the other variants as well. * Section 4 reads a bit like text of a regulator. While it seems that this is the current direction of regulators I wonder whether we should really say better delete the section. Furthermore, one paragraph is repeated, namely "Certainly, any device .... should work.". * " Such translation is best done by the endpoint, because emergency calls convey location in the signaling, but non emergency calls do not normally do that. " That's not the only reason. In general one could say that the end host would not execute the emergency service related procedures. Additionally, the proxy might not be able to uniquely detect the visited emergency dial string as an emergency call. This statement also applies to the subsequent sentence: " Dial string recognition could be performed in a signaling intermediary (proxy server) if for some reason, the endpoint does not recognize it. " * " Note: It is undesirable to have a single "button" emergency call user interface element. These mechanisms tend to result in a very high rate of false or accidental emergency calls. In order to minimize this rate, devices SHOULD only initiate emergency calls based on entry of specific emergency call dial strings. " I am not sure we need to put this into the draft. First, we don't provide a reference that supports our statement. Second, this is not really our area of expertise. Finally, the "SHOULD" is not appropriate here. * Section 5 " For end systems, on the other hand, it is desirable to have a universal identifier, independent of location, to allow the automated inclusion of location information and to allow the device and other entities in the call path to perform appropriate processing within the signaling protocol in an emergency call set-up. " The benefit is not really for the end system as such. I see the benefit more as a mechanism for emergency services call marking; hence for the entities that are along the signaling path. * Section 6.1: " In IETF location protocols, there is a element (Postal Community Name) that can be included in a location to provide the post office name as well as the actual jurisdictional community name. There is no other accommodation for postal addresses in these protocols. " In which protocols is an element for postal community name? * Section 6.2.2: " The threshold for when interior location is needed is approximately 650 m2 (that is derived from fire brigade recommendations of spacing of alarm pull stations) should have, but interior space layout, construction materials and other factors should be considered. The ultimate goal is to be able to find the person in need quickly if responders arrive at the location given. " Do we have a reference that supports this statement? * Section 6.3 " However NATs and other middleboxes often make it impossible to determine a reference identifier the access network could use to determine the location. " As we discussed in GEOPRIV this is not really a problem. Section 6.6: " The presence of NAT and VPN tunnels (that assign new IP addresses to communications) can obscure identifiers used by LCPs to determine location, especially using HELD. " The same is true for DHCP. " In mobile handsets, routing is often accomplished with the cell site and sector of the tower serving the call, because it can take many seconds to start up the location determination mechanism and obtain an accurate location. " This functionality is not provided by LoST. " NENA recommends IP based systems complete calls in two seconds (last dial press to ring at PSAP). " I suggest to add a reference. * Section 6.8: " In a subscription environment, the PSAP could update the parameters in the filter (immediate response required). " I suggest to add a bit more text regarding the meaning of the "subscription environment". " In a HELD dereference, there is no way to cancel and the PSAP will have to choose a ResponseTime that it will wait for even if it wants to dispatch sooner than that. " Not sure what that means. * Section 6.9: " Guidelines for dealing with multiple locations are also given in [I-D.ietf-ecrit-lost]. " The guidelines in LoST regarding multiple location refer to something entirely different. I would delete this sentence. * Section 6.10: " Validation in this context means both that there is a mapping from the address to a PSAP and that the PSAP understands how to direct responders to the location. " We use a different description of the term validation. See ECRIT terminology draft. The same is true for the following text as well: " Validation is normally a concern for civic addresses, although there could be a concern that a given geo is within at least one PSAP service boundary; that is, a "valid" geo is one where there is a mapping. " * Section 6.11 " Default locations must be marked as such so that the PSAP knows that the location is not accurate. " How is this done? * Section 6.12 " To prevent against spoofing of the DHCP server, devices implementing DHCP for location configuration should use DHCP security mechanisms [RFC3118]. " That's true for all protocols, including HELD. For most protocols, such as DHCP, this is, however, not practical to assume that DHCP security is used. * Section 7: Delete this section since we have a separate document on this topic. * Section 14: " Media should be kept secure, preferably by use of Secure RTP [RFC3711]. " You should indicate what mechanisms are required for establishing the keying material for SRTP. * Acknowledgements I suggest to be more accurate. People volunteer todo reviews and spend a lot of time providing feedback. We should acknowledge their work at least by saying what type of feedback they provided. Editorial Comments: ------------------- * Search for "Section Section" in the .txt file. * Introduction: " Tunnels can obscure the identity of the actual access network that knows the location. " I guess what you want to say is the following: "When IP addresses are used to determine the location information of an end host then different results are accomplished depending on whether the inner or the outer tunnel address are used for the lookup." * FROM: "There will be PSAPs that require new systems to terminate to existing mechanisms for some time. " TO: "There will be PSAPs that require new systems to terminate existing mechanisms for some time." * FROM: " o The call is routed to the most appropriate PSAP, selected principally by the location of the caller. " TO: " o The call is routed to the most appropriate PSAP, selected principally by the location of the caller and the service URN. " " Section 3: FROM: " An emergency call can be distinguished (Section 5) from any other call by a unique Service URN [I-D.ietf-ecrit-service-urn], that is placed in the call set-up signaling when a home or visited emergency dial string is detected. " TO: " When a home or visited emergency dial string is detected then the call is marked with a Service URN [I-D.ietf-ecrit-service-urn]. Thereby, an emergency call can be distinguished (Section 5) from non-emergency calls by other SIP signaling entities. " * FROM: " The call is routed (Section 8) based on location using the LoST protocol [I-D.ietf-ecrit-lost], that maps a location to a set of PSAP or URIs. " TO: " The call is routed (Section 8) based on location and the service URN using the LoST protocol [I-D.ietf-ecrit-lost] that maps the input to a set of PSAP URIs. " FROM: " At some time after her device has booted, Alice initiates an emergency call. She may do this by dialing an emergency dial string valid for her current ("local") location, or for her "home" location. " TO: " At some time, Alice initiates an emergency call. She may do this by dialing an emergency dial string valid for her current ("local") location, or for her "home" location. " * FROM: " If the endpoint does not support the translation of dial strings to telephone numbers, the dialing sequence would be represented as a dial string [RFC4967] and the outgoing proxy would recognize the dial string and translate to the service URN. " TO: " If the endpoint does not support the translation of dial strings to service URNs, the dialing sequence would be represented as a tel URI [RFC4967]. The outgoing proxy would have to recognize the dial string and translate to the service URN. In some cases the proxy might have difficulties to detect the emergency call. " * Section 5 I suggest to move the following paragraph " While in some countries there is a single 3 digit dial string that is used for all emergency calls (i.e. 9-1-1 in North America), in some countries there are several 3 digit numbers used for different types of calls. For example, in Switzerland, 1-1-7 is used to call police, 1-1-8 is used to call the fire brigade, and 1-4-4 is used for emergency medical assistance. In other countries, there are no "short codes" or "service codes" for 3 digit dialing of emergency services and local (PSTN) numbers are used. " after the first paragraph: " Using the PSTN, emergency help can often be summoned by dialing a nationally designated, widely known number, regardless of where the telephone was purchased. The appropriate number is determined by the infrastructure the telephone is connected to. However, this number differs between localities, even though it is often the same for a country or region, as it is in many countries in the European Union. In some countries, there is a single digit sequence that is used for all types of emergencies. In others, there are several sequences that are specific to the type of responder needed, e.g., one for police, another for fire. " * Section 6.1: "Geospatial (geo)" --> geodetic. * " In IETF protocols, civic and geospatial forms are both supported. " I would add references here. * Terminology Section I would be add references to all the terms. The term "access network" or "access network provider" is defined differently in http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps-05.txt The same is true for LIS. The confidence and uncertainty require a reference. You might, for example, want to look at http://cobweb.ecn.purdue.edu/~ee650/downloads/uncertainty-in-measurement-uk.pdf With respect to the mobility related terminology you might also refer to http://www.ietf.org/rfc/rfc3753.txt. * There are far too many normative references in the document. I would at least move the following refs to the informative section: - [I-D.barnes-geopriv-lo-sec] - [I-D.ietf-sipping-config-framework] - [RFC2401] - [RFC3118] - [RFC3920] - [RFC4033] - [RFC4190] idnits says: Checking nits according to http://www.ietf.org/ID-Checklist.html: ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of http://www.ietf.org/ID-Checklist.html for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 56 has weird spacing: '...support emerg...' == Line 476 has weird spacing: '...support emerg...' Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 19 08:56:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IirOA-0003jL-3M; Fri, 19 Oct 2007 08:55:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IirO4-0003f4-Et for ecrit@ietf.org; Fri, 19 Oct 2007 08:55:36 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IirNx-000667-4R for ecrit@ietf.org; Fri, 19 Oct 2007 08:55:36 -0400 Received: from mail.bbn.com ([128.33.1.19]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IirNk-0007sP-63; Fri, 19 Oct 2007 08:55:16 -0400 Received: from col-dhcp33-244-186.bbn.com ([128.33.244.186] helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.67) (envelope-from ) id 1IirNj-0002bY-3g; Fri, 19 Oct 2007 08:55:15 -0400 Message-ID: <4718A931.5050401@bbn.com> Date: Fri, 19 Oct 2007 08:55:13 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Henning Schulzrinne , ECRIT Subject: Re: [Ecrit] LoST serviceBoundaryReference as a URI? References: <4717CD89.1010208@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > The reason is that we want to be able to use > the caching mechanisms in LoST, so we want to refer to an object, not a > location. I'm not sure I understand this. If I'm reading the LoST draft right, to dereference a serviceBoundaryReference you send a getServiceBoundary query directly to the server in the "source" attribute of the reference and get back a location (serviceBoundary) and a path. So I don't see how caching plays into this? > Plus, we currently do not have a LoST URL as such. Seems like you could do this with any LbyR URL, e.g., an HTTP or SIP URL. The mapping would be something like the following: The sbref becomes the URI (borrowing from the SAML URI binding): https://authoritative.eg/lost-sb?key=4A841E8B sips:4A841E8B@authoritative.eg --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 19 13:29:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiveZ-0001Er-1h; Fri, 19 Oct 2007 13:28:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiveW-0001BK-QH for ecrit@ietf.org; Fri, 19 Oct 2007 13:28:52 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiveQ-0001JD-I8 for ecrit@ietf.org; Fri, 19 Oct 2007 13:28:52 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9JHRr6U027219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 19 Oct 2007 10:27:53 -0700 Received: from [98.207.5.180] (carbuncle.qualcomm.com [129.46.226.27]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9JHRpKX005854; Fri, 19 Oct 2007 10:27:52 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <4718A931.5050401@bbn.com> References: <4717CD89.1010208@bbn.com> <4718A931.5050401@bbn.com> Date: Fri, 19 Oct 2007 10:28:03 -0700 To: Richard Barnes , Henning Schulzrinne , ECRIT From: Ted Hardie Subject: Re: [Ecrit] LoST serviceBoundaryReference as a URI? Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 8:55 AM -0400 10/19/07, Richard Barnes wrote: >>The reason is that we want to be able to use the caching mechanisms in LoST, so we want to refer to an object, not a location. > >I'm not sure I understand this. If I'm reading the LoST draft right, to dereference a serviceBoundaryReference you send a getServiceBoundary query directly to the server in the "source" attribute of the reference and get back a location (serviceBoundary) and a path. So I don't see how caching plays into this? > >>Plus, we currently do not have a LoST URL as such. > >Seems like you could do this with any LbyR URL, e.g., an HTTP or SIP URL. The mapping would be something like the following: The sbref > > > >becomes the URI (borrowing from the SAML URI binding): > >https://authoritative.eg/lost-sb?key=4A841E8B >sips:4A841E8B@authoritative.eg Seems to me this buys you absolutely nothing and potentially forces the client to understand/invoke protocol processing for some other protocol. We know the client "speaks" lost. What's the advantage to forcing them to speak anything else? Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 19 14:03:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiwC3-0003eY-9W; Fri, 19 Oct 2007 14:03:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IiwC0-0003XS-Gk for ecrit@ietf.org; Fri, 19 Oct 2007 14:03:28 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IiwBy-0002jA-Uo for ecrit@ietf.org; Fri, 19 Oct 2007 14:03:28 -0400 Received: from mail.bbn.com ([128.33.1.19]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IiwBj-0006nl-4y; Fri, 19 Oct 2007 14:03:11 -0400 Received: from col-dhcp33-244-186.bbn.com ([128.33.244.186] helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.67) (envelope-from ) id 1IiwBj-0006F2-D0; Fri, 19 Oct 2007 14:03:11 -0400 Message-ID: <4718F15D.5040109@bbn.com> Date: Fri, 19 Oct 2007 14:03:09 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Ecrit] LoST serviceBoundaryReference as a URI? References: <4717CD89.1010208@bbn.com> <4718A931.5050401@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > Seems to me this buys you absolutely nothing and potentially forces the client to > understand/invoke protocol processing for some other protocol. We know > the client "speaks" lost. What's the advantage to forcing them to speak > anything else? That's true if the only entity that wants the service boundary is the LoST client. I was thinking more about cases where one entity wants to point another entity to a service boundary, such as a client telling a proxy "this is the service boundary of the PSAP I'm calling" . In this case, there's no guarantee that the receiving entity, the one that does the dereference, speaks LoST. So I think there are two advantages: The first (and less clearly advantageous) is that dereferences doesn't depend on support for LoST, just L-by-R dereference -- which may be more or less common. The second, greater advantage is that there's already protocol fields that can carry a URI, and none that carry a serviceBoundaryReference. I should also be clear that I didn't mean to get rid of serviceBoundaryReferences, just to add an additional, optional mechanism for referring to service boundaries. So nobody would be forced to speak anything other than LoST. --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Oct 19 14:30:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiwbn-0003fU-Ol; Fri, 19 Oct 2007 14:30:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iiwbm-0003dL-AE for ecrit@ietf.org; Fri, 19 Oct 2007 14:30:06 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iiwbe-0004H4-2A for ecrit@ietf.org; Fri, 19 Oct 2007 14:30:04 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9JITHYL009995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 19 Oct 2007 11:29:17 -0700 Received: from [98.207.5.180] (carbuncle.qualcomm.com [129.46.226.27]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9JITGoY023143; Fri, 19 Oct 2007 11:29:16 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <4718F15D.5040109@bbn.com> References: <4717CD89.1010208@bbn.com> <4718A931.5050401@bbn.com> <4718F15D.5040109@bbn.com> Date: Fri, 19 Oct 2007 11:29:27 -0700 To: Richard Barnes From: Ted Hardie Subject: Re: [Ecrit] LoST serviceBoundaryReference as a URI? Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 2:03 PM -0400 10/19/07, Richard Barnes wrote: > >That's true if the only entity that wants the service boundary is the LoST client. I was thinking more about cases where one entity wants to point another entity to a service boundary, such as a client telling a proxy "this is the service boundary of the PSAP I'm calling" . In this case, there's no guarantee that the receiving entity, the one that does the dereference, speaks LoST. The set of mechanisms around serviceBoundaries are there to minimize the number of queries that need to go to LoST servers by letting the queriers know when they are still within a serviceBoundary. If I understand what you are proposing, you want the serviceBoundaryReference to be passed away from the client to a location-aware proxy that does not speak LoST but will cache this data for some other purpose. That is a different optimization. >So I think there are two advantages: The first (and less clearly advantageous) is that dereferences doesn't depend on support for LoST, just L-by-R dereference -- which may be more or less common. The second, greater advantage is that there's already protocol fields that can carry a URI, and none that carry a serviceBoundaryReference. I've argued that creating a LoST uri has advantages for the second reason, but I agree with those in the working group who asked that it be decoupled from progress on the main spec. I still have some drafts of the docs around, if you are interested in working on them. >I should also be clear that I didn't mean to get rid of serviceBoundaryReferences, just to add an additional, optional mechanism for referring to service boundaries. So nobody would be forced to speak anything other than LoST. If you would like to propose an extension for the purpose, I would be happy to review it and I may well support it. I'm immensely relieved to hear that you are not proposing this as a protocol change to a doc that's already in an AD queue for publication requested. That tends to get things pushed down the queue, and I think we're way past the time when we should have shipped LoST. Ted >--Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 22 10:08:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijxwa-0000E1-Un; Mon, 22 Oct 2007 10:07:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjxwY-0000Bd-PL for ecrit@ietf.org; Mon, 22 Oct 2007 10:07:46 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjxwY-00039H-Bo for ecrit@ietf.org; Mon, 22 Oct 2007 10:07:46 -0400 Received: from mail.bbn.com ([128.33.1.19]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IjxwX-0003Br-68; Mon, 22 Oct 2007 10:07:45 -0400 Received: from col-dhcp33-244-155.bbn.com ([128.33.244.155] helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.67) (envelope-from ) id 1IjxwX-0005Qh-RF; Mon, 22 Oct 2007 10:07:45 -0400 Message-ID: <471CAEB0.3060602@bbn.com> Date: Mon, 22 Oct 2007 10:07:44 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Hardie , ECRIT Subject: Re: [Ecrit] LoST serviceBoundaryReference as a URI? References: <4717CD89.1010208@bbn.com> <4718A931.5050401@bbn.com> <4718F15D.5040109@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > The set of mechanisms around serviceBoundaries are there to minimize the number > of queries that need to go to LoST servers by letting the queriers know when they > are still within a serviceBoundary. If I understand what you are proposing, you > want the serviceBoundaryReference to be passed away from the client to > a location-aware proxy that does not speak LoST but will cache this data for > some other purpose. That is a different optimization. Sure, no disagreement there. Let me clarify the use case I have in mind: In current proposals, LoST is used to verify that the destination (e.g., R-URI or Route:) of an emergency call is in fact a PSAP URI. In order to do this verification, the verifier needs a location and a service URN. Emergency calls by definition carry a service URN, but may not have location (e.g., in the location hiding use case). Service boundaries are useful because the service boundary could be used as an ersatz location when there is no other location available. That is, a verifier could use a location within the boundary with the provided URN to verify that a URI is a PSAP URI. Having a URI reference to a service boundary is convenient because 1) It can be provisioned as a location reference in HELD, and 2) It can be carried in a SIP Geolocation header field Having the LoST server provide such references is a convenient discovery mechanism, and having the LoST server (or its delegate) be the target of these references avoids the need for lots of entities to maintain references to the same service boundary. > I've argued that creating a LoST uri has advantages for the second reason, but I agree > with those in the working group who asked that it be decoupled from progress on the > main spec. I still have some drafts of the docs around, if you are interested in working > on them. In order to support the above use case, such a URI would need to have more semantics than the one last specified in LoST (-03). In addition to referring to the LoST server itself (the function of the LoST URI in -03), there would need to be a way to refer to individual service boundaries. (You could conceivably refer to other things, like mappings, in this way, but I'm not sure to what extent that's feasible.) I'm not sure that a LoST URI is necessary for this case either, because the transaction doesn't require any of the semantics of LoST beyond the simple retrieval semantics of the getServiceBoundary query. And that request is essentially equivalent to an HTTP GET. If you think a LoST URI is still the way to go, though, I'd be glad to take a look at the remaining docs and try to make some progress. Best, --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 22 10:20:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijy8p-000582-U9; Mon, 22 Oct 2007 10:20:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijy8o-00055y-5t for ecrit@ietf.org; Mon, 22 Oct 2007 10:20:26 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ijy8h-0004sc-W3 for ecrit@ietf.org; Mon, 22 Oct 2007 10:20:26 -0400 Received: from [24.154.127.115] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Ijy8Z-0006GD-4F; Mon, 22 Oct 2007 09:20:11 -0500 From: "Brian Rosen" To: "'Richard Barnes'" , "'Ted Hardie'" , "'ECRIT'" References: <4717CD89.1010208@bbn.com><4718A931.5050401@bbn.com> <4718F15D.5040109@bbn.com> <471CAEB0.3060602@bbn.com> Subject: RE: [Ecrit] LoST serviceBoundaryReference as a URI? Date: Mon, 22 Oct 2007 10:20:17 -0400 Message-ID: <03a401c814b6$ad877c00$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcgUtRog52Pfv184TAyd90LlZO181wAAPiPw In-Reply-To: <471CAEB0.3060602@bbn.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This doesn't make any sense to me. The reference has to resolve to the real location when the PSAP gets it. That means the domain of the location reference has to be that of the LIS. The LIS could get the service boundary, and return that as the value for a dereference done by some entity other than a PSAP, but that means the LIS wants the value from LoST, not a URI. Brian > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Monday, October 22, 2007 10:08 AM > To: Ted Hardie; ECRIT > Subject: Re: [Ecrit] LoST serviceBoundaryReference as a URI? > > > The set of mechanisms around serviceBoundaries are there to minimize the > number > > of queries that need to go to LoST servers by letting the queriers know > when they > > are still within a serviceBoundary. If I understand what you are > proposing, you > > want the serviceBoundaryReference to be passed away from the client to > > a location-aware proxy that does not speak LoST but will cache this data > for > > some other purpose. That is a different optimization. > > Sure, no disagreement there. Let me clarify the use case I have in > mind: In current proposals, LoST is used to verify that the destination > (e.g., R-URI or Route:) of an emergency call is in fact a PSAP URI. In > order to do this verification, the verifier needs a location and a > service URN. Emergency calls by definition carry a service URN, but may > not have location (e.g., in the location hiding use case). Service > boundaries are useful because the service boundary could be used as an > ersatz location when there is no other location available. That is, a > verifier could use a location within the boundary with the provided URN > to verify that a URI is a PSAP URI. > > Having a URI reference to a service boundary is convenient because > 1) It can be provisioned as a location reference in HELD, and > 2) It can be carried in a SIP Geolocation header field > > Having the LoST server provide such references is a convenient discovery > mechanism, and having the LoST server (or its delegate) be the target of > these references avoids the need for lots of entities to maintain > references to the same service boundary. > > > I've argued that creating a LoST uri has advantages for the second > reason, but I agree > > with those in the working group who asked that it be decoupled from > progress on the > > main spec. I still have some drafts of the docs around, if you are > interested in working > > on them. > > In order to support the above use case, such a URI would need to have > more semantics than the one last specified in LoST (-03). In addition > to referring to the LoST server itself (the function of the LoST URI in > -03), there would need to be a way to refer to individual service > boundaries. (You could conceivably refer to other things, like > mappings, in this way, but I'm not sure to what extent that's feasible.) > > I'm not sure that a LoST URI is necessary for this case either, because > the transaction doesn't require any of the semantics of LoST beyond the > simple retrieval semantics of the getServiceBoundary query. And that > request is essentially equivalent to an HTTP GET. > > If you think a LoST URI is still the way to go, though, I'd be glad to > take a look at the remaining docs and try to make some progress. > > Best, > --Richard > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 22 10:51:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijybi-00030w-UX; Mon, 22 Oct 2007 10:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijybh-0002zF-LW for ecrit@ietf.org; Mon, 22 Oct 2007 10:50:17 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjybZ-0005yv-G3 for ecrit@ietf.org; Mon, 22 Oct 2007 10:50:17 -0400 Received: from mail.bbn.com ([128.33.1.19]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IjybH-0003uF-6H; Mon, 22 Oct 2007 10:49:52 -0400 Received: from col-dhcp33-244-155.bbn.com ([128.33.244.155] helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.67) (envelope-from ) id 1IjybH-000152-CS; Mon, 22 Oct 2007 10:49:51 -0400 Message-ID: <471CB88E.40009@bbn.com> Date: Mon, 22 Oct 2007 10:49:50 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Rosen , ECRIT Subject: Re: [Ecrit] LoST serviceBoundaryReference as a URI? References: <4717CD89.1010208@bbn.com><4718A931.5050401@bbn.com> <4718F15D.5040109@bbn.com> <471CAEB0.3060602@bbn.com> <03a401c814b6$ad877c00$640fa8c0@cis.neustar.com> In-Reply-To: <03a401c814b6$ad877c00$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, Keep in mind that there can be multiple location references in an INVITE. They all have to refer to the same location (that of the endpoint), but some of them could do that by saying "it's within this service boundary" while others could say "it's at this point". > The reference has to resolve to the real > location when the PSAP gets it. Really, you only need ONE of the references to resolve to the real location. Suppose you have the following headers: Geolocation: Geolocation: ;used-for-routing The PSAP could use the first one to get precise location, while other entities could use the second one to get a service boundary to verify that the destination is a PSAP. > The LIS could get the service > boundary, and return that as the value for a dereference done by some entity > other than a PSAP Using a URI that points to a service boundary does the same thing without the LIS having to (1) apply transformations to the location (i.e., it just has to deny or allow), or (2) maintain a local cache of the serviceBoundary (just needs the reference). --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 22 11:34:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjzHp-0005MG-Ru; Mon, 22 Oct 2007 11:33:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjzHN-0004pt-S5 for ecrit@ietf.org; Mon, 22 Oct 2007 11:33:21 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjzHN-0000Q7-Cf for ecrit@ietf.org; Mon, 22 Oct 2007 11:33:21 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IjzHD-0002uu-2u; Mon, 22 Oct 2007 10:33:12 -0500 From: "Brian Rosen" To: "'Richard Barnes'" , "'ECRIT'" References: <4717CD89.1010208@bbn.com><4718A931.5050401@bbn.com> <4718F15D.5040109@bbn.com> <471CAEB0.3060602@bbn.com> <03a401c814b6$ad877c00$640fa8c0@cis.neustar.com> <471CB88E.40009@bbn.com> Subject: RE: [Ecrit] LoST serviceBoundaryReference as a URI? Date: Mon, 22 Oct 2007 11:33:16 -0400 Message-ID: <03b501c814c0$e0657140$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcgUutKcOWO2w4f2SEu0GXFa6sjW3gABWvKw In-Reply-To: <471CB88E.40009@bbn.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think the burden of handling location hiding should be on the access network. I think the burden of location verification should be on the verifier. I think the endpoint, the PSAP or a non-involved proxy, should have zero burden for these shenanigans. That means I want the LIS to return a simple reference, which everyone treats as the actual location. I want the verifier, if it wants to, to dereference it, and deal with what it gets back. I want the PSAP to get one reference, and use it. Among other things, the PSAP doesn't know which reference to use. You would think it would start with the one used for routing. I don't care how much work the LIS has to do to hide location, and I don't care how much work the verifier has to do to verify. I care a lot how much work everyone else has to do to make it possible for these things to happen. Brian > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Monday, October 22, 2007 10:50 AM > To: Brian Rosen; ECRIT > Subject: Re: [Ecrit] LoST serviceBoundaryReference as a URI? > > Brian, > > Keep in mind that there can be multiple location references in an > INVITE. They all have to refer to the same location (that of the > endpoint), but some of them could do that by saying "it's within this > service boundary" while others could say "it's at this point". > > > The reference has to resolve to the real > > location when the PSAP gets it. > > Really, you only need ONE of the references to resolve to the real > location. Suppose you have the following headers: > > Geolocation: > Geolocation: ;used-for-routing > > The PSAP could use the first one to get precise location, while other > entities could use the second one to get a service boundary to verify > that the destination is a PSAP. > > > The LIS could get the service > > boundary, and return that as the value for a dereference done by some > entity > > other than a PSAP > > Using a URI that points to a service boundary does the same thing > without the LIS having to (1) apply transformations to the location > (i.e., it just has to deny or allow), or (2) maintain a local cache of > the serviceBoundary (just needs the reference). > > --Richard > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 22 12:15:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjzwV-00061L-4O; Mon, 22 Oct 2007 12:15:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjzwT-00061D-IF for ecrit@ietf.org; Mon, 22 Oct 2007 12:15:49 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IjzwS-0003DU-W8 for ecrit@ietf.org; Mon, 22 Oct 2007 12:15:49 -0400 Received: from mail.bbn.com ([128.33.1.19]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IjzwS-0005En-5M for ecrit@ietf.org; Mon, 22 Oct 2007 12:15:48 -0400 Received: from col-dhcp33-244-155.bbn.com ([128.33.244.155] helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.67) (envelope-from ) id 1IjzwS-0002my-Jx for ecrit@ietf.org; Mon, 22 Oct 2007 12:15:48 -0400 Message-ID: <471CCCB3.7050607@bbn.com> Date: Mon, 22 Oct 2007 12:15:47 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Ecrit] [Fwd: New Version Notification for draft-barnes-ecrit-auth-01] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This draft seeks to frame the problem of fraud within the emergency calling system in a much broader sense than draft-barnes-ecrit-auth-00. We present a set of logical entities involved in emergency calling, and discuss the fraud risks faced by each of them. Our hope is that this document can help to clarify what fraud-prevention mechanisms are necessary in emergency calling systems. --Richard -------- Original Message -------- Subject: New Version Notification for draft-barnes-ecrit-auth-01 Date: Mon, 22 Oct 2007 12:08:47 -0400 From: IETF I-D Submission Tool To: rbarnes@bbn.com CC: mlepinski@bbn.com A new version of I-D, draft-barnes-ecrit-auth-01.txt has been successfuly submitted by Richard Barnes and posted to the IETF repository. Filename: draft-barnes-ecrit-auth Revision: 01 Title: Fraud mitigation for IP-based emergency calling Creation_date: 2007-10-22 WG ID: Independent Submission Number_of_pages: 14 Abstract: The use of Internet technologies for emergency calling creates opportunities for fraud, relative to traditional circuit-switched emergency calling. This document describes the context for IP-based emergency calling, and the types of fraud which are possible within the system. A mitigation strategy for fraud against voice service providers is described; techniques for detecting or preventing other types of fraud will be incorporated in this document as they are available. The IETF Secretariat. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 22 12:56:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik0Yh-0001a9-P7; Mon, 22 Oct 2007 12:55:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik0Yf-0001WQ-Bh for ecrit@ietf.org; Mon, 22 Oct 2007 12:55:17 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik0Yf-000165-3J for ecrit@ietf.org; Mon, 22 Oct 2007 12:55:17 -0400 Received: from mail.bbn.com ([128.33.1.19]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Ik0Ye-0005Lb-5o; Mon, 22 Oct 2007 12:55:16 -0400 Received: from col-dhcp33-244-155.bbn.com ([128.33.244.155] helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.67) (envelope-from ) id 1Ik0Ye-0006PZ-Ri; Mon, 22 Oct 2007 12:55:16 -0400 Message-ID: <471CD5F3.4010907@bbn.com> Date: Mon, 22 Oct 2007 12:55:15 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Rosen , ECRIT Subject: Re: [Ecrit] LoST serviceBoundaryReference as a URI? References: <4717CD89.1010208@bbn.com><4718A931.5050401@bbn.com> <4718F15D.5040109@bbn.com> <471CAEB0.3060602@bbn.com> <03a401c814b6$ad877c00$640fa8c0@cis.neustar.com> <471CB88E.40009@bbn.com> <03b501c814c0$e0657140$640fa8c0@cis.neustar.com> In-Reply-To: <03b501c814c0$e0657140$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > I think the burden of handling location hiding should be on the access > network. I think the burden of location verification should be on the > verifier. I think the endpoint, the PSAP or a non-involved proxy, should > have zero burden for these shenanigans. Creating an additional way to refer to service boundaries adds work for anybody. It just provides another mechanism for referring to what the LoST server already provides. -- The LIS still has to do the work to figure out which service boundary references to give to the endpoint -- The verifier still has to acquire the location and do the LoST query to verify -- The PSAP still gets location to the same accuracy in the same amount of time (it can do multiple dereferences in parallel) -- Non-involved proxies can just ignore the location headers The only entity that gets any more work here is the LoST server, who may have to answer more queries for service boundaries. --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 22 13:17:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik0td-0005tI-NH; Mon, 22 Oct 2007 13:16:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ik0td-0005lL-4p for ecrit@ietf.org; Mon, 22 Oct 2007 13:16:57 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ik0tY-00027p-NE for ecrit@ietf.org; Mon, 22 Oct 2007 13:16:53 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Ik0tO-0002Qz-8K; Mon, 22 Oct 2007 12:16:42 -0500 From: "Brian Rosen" To: "'Richard Barnes'" , "'ECRIT'" References: <4717CD89.1010208@bbn.com><4718A931.5050401@bbn.com> <4718F15D.5040109@bbn.com> <471CAEB0.3060602@bbn.com> <03a401c814b6$ad877c00$640fa8c0@cis.neustar.com> <471CB88E.40009@bbn.com> <03b501c814c0$e0657140$640fa8c0@cis.neustar.com> <471CD5F3.4010907@bbn.com> Subject: RE: [Ecrit] LoST serviceBoundaryReference as a URI? Date: Mon, 22 Oct 2007 13:16:47 -0400 Message-ID: <03e501c814cf$568c4c00$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcgUzFJ/C2Y+FEA9RW6O1cfhw+4X7QAAG2rQ In-Reply-To: <471CD5F3.4010907@bbn.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org No, you want the LoST server to have to handle content indirection for service boundaries, and only because some access networks want to hide location. I think that's putting the burden on the LoST server inappropriately. You are also putting burdens on endpoints, non-involved proxies and PSAPs to handle multiple locations. The other way, the LIS does all the work. That's, in my opinion, as it should be. Brian > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Monday, October 22, 2007 12:55 PM > To: Brian Rosen; ECRIT > Subject: Re: [Ecrit] LoST serviceBoundaryReference as a URI? > > > I think the burden of handling location hiding should be on the access > > network. I think the burden of location verification should be on the > > verifier. I think the endpoint, the PSAP or a non-involved proxy, > should > > have zero burden for these shenanigans. > > Creating an additional way to refer to service boundaries adds work for > anybody. It just provides another mechanism for referring to what the > LoST server already provides. > > -- The LIS still has to do the work to figure out which service boundary > references to give to the endpoint > > -- The verifier still has to acquire the location and do the LoST query > to verify > > -- The PSAP still gets location to the same accuracy in the same amount > of time (it can do multiple dereferences in parallel) > > -- Non-involved proxies can just ignore the location headers > > The only entity that gets any more work here is the LoST server, who may > have to answer more queries for service boundaries. > > --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 24 14:48:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IklG2-0002yF-SI; Wed, 24 Oct 2007 14:47:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IklG1-0002pq-S6 for ecrit@ietf.org; Wed, 24 Oct 2007 14:47:09 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IklFn-0001Gp-14 for ecrit@ietf.org; Wed, 24 Oct 2007 14:47:01 -0400 Received: (qmail invoked by alias); 24 Oct 2007 18:46:28 -0000 Received: from p54984907.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.73.7] by mail.gmx.net (mp031) with SMTP; 24 Oct 2007 20:46:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19CHVsFswlC6X2kxcF+Pu5HR/ioHdCNGNab/EQPS3 zvVNS9gD/vJUxM Message-ID: <471F9303.4030403@gmx.net> Date: Wed, 24 Oct 2007 20:46:27 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Roger Marshall References: <8C837214C95C864C9F34F3635C2A657508613C47@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A657508613C47@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ECRIT Subject: [Ecrit] WG milestone updates: Feedback needed! X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Some of us do not care a lot about milestones. However, we need to consider two aspects: * We want to provide people looking at the charter page some idea what we do and when it is supposed to be finished. * We also want to set milestones for ourself. Having said that I would appreciate to receive some comments whether the indicated milestones are actually accomplishable. Ciao Hannes Roger Marshall wrote: > At the last IETF meeting, the ECRIT workgroup (& chairs) agreed that we > should update the milestone dates. > > The following is what is proposed: > > --- > Goals and Milestones* > > * (Indicates date that the document is submitted to the IESG.) > > Done Informational RFC containing terminology definitions and the > requirements > > Done An Informational document describing the threats and security > considerations > > Done A Standards Track RFC describing how to identify a session set-up > request is to an emergency response center > > Done A Standards Track RFC describing how to route an emergency call > based on location information > > Done An Informational document describing the Mapping Protocol > Architecture > > Feb 2008 An Informational document describing the ECRIT Framework > > Feb 2008 A BCP document describing the emergency call support for > devices > > --- > > Please post any comments to the ecrit list. > > Thanks. > > -roger marshall. > > > > The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Oct 25 16:05:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il8wz-0005Lr-OO; Thu, 25 Oct 2007 16:05:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il8wy-0005Ld-AJ for ecrit@ietf.org; Thu, 25 Oct 2007 16:05:04 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Il8ww-0004cA-LT for ecrit@ietf.org; Thu, 25 Oct 2007 16:05:04 -0400 Received: from mail.bbn.com ([128.33.1.19]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Il8ww-0005RX-3W; Thu, 25 Oct 2007 16:05:02 -0400 Received: from dhcp89-089-119.bbn.com ([128.89.89.119] helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.67) (envelope-from ) id 1Il8ww-0000Gw-09; Thu, 25 Oct 2007 16:05:02 -0400 Message-ID: <4720F68F.7070000@bbn.com> Date: Thu, 25 Oct 2007 16:03:27 -0400 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ECRIT , Brian Rosen , hgs@cs.columbia.edu, "James M. Polk" , andy@hxr.us Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: Subject: [Ecrit] draft-ecrit-framework-03 (comments on document content) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This is the first half of my review of draft-ietf-ecrit-framework-03. I've tried to separate my comments into "Comments on document content" (more substantive) and "Comments on document clarity" (more editorial), but the line between the two is blurry at times. (Note: "Comments on document clarity" follow in a subsequent email.) Comments on document content --------------------------------------- Section 2: I believe there should be a reference to phonebcp somewhere in the introduction and an explanation of how the two documents fit together. Section 3: Given that the ESRP appears in both Figure 1 and Figure 2, I would recommend adding a bullet to the list (after paragraph 2 of Section 3) on how the ESRP fits into the call setup process. Section 3: I find Figure 2 very difficult to parse. Instead of an arrow diagram, consider just using a list of messages (as illustrated below) to describe the messages appearing in Figure 1. [M1]: LCP request from Alice to configuration server (ask for location). LCP reply from configuration server to Alice (reply with location). [M2]: SIP REGISTER from Alice to configuration server. 200 OK (REGISTER) response from configuration server to Alice [M3]: Initial LoST Protocol Query from Alice to LoST server (contains location) (and so on ...) Section 6: The point of paragraph 6 seems to be that dispatch location must be accurate to within 3 cm (with high confidence) and let current measurement technology is several orders of magnitude away from being able to achieve this accuracy. It's not clear to me what conclusion we want readers to draw from this paragraph. It would be nice if we could provide some guidance to those building mobile systems regarding what they should do in the absence of location determination technology that meets emergency service needs. (As an aside, I'm not sure where the 3cm number comes from. If I'm standing near a wall in my apartment and using my cell phone and my neighbor is standing near the same wall in his apartment with his cell phone, given that neither of us talk with our cell phones pressed up against the wall, it seems likely that our cell phones are about 60 cm apart.) Section 6.2: In the second paragraph, the document highlights the problem of multiple, contradictory, locations but doesn't provide any guidance on how to deal with the problem. I don't know that we ever reached concensus on the correct "default" behaivor for dealing with multiple locations, but I think that either framework or phonebcp should provide some guidance on reasonable default behaivor. (And if the text ends up in Phonebcp, I would probably put a reference in framework.) As an aside, I personally agree with Barbara's suggestions in: http://www1.ietf.org/mail-archive/web/ecrit/current/msg04407.html Section 6.6: In paragraph 4, the document correctly identifies the there is a time-vs-accuracy trade-off in many location determination technologies. However, the guidance that it provides is unclear. The text seems to say both that when there is a 'quick fix' available that it is preferable to wait, but also that 'quick fixes' take too long and therefore one should not wait. I'm not sure what the best advice is to give to a reader who is facing a time-vs-accuracy trade-off, but it would be nice if we could provide at least some rule of thumb. Section 6.12: I don't think that Paragraph 2 (on DHCP security) belongs in this section. First, it seems odd that it specifically discusses security for DHCP and not for other location configuration protocols (e.g. HELD). Second, it seems that this type of security text would better fit in the Security Considerations section of the document. I would suggest text like the following: "To avoid spoofing attacks, mechanisms for authentication of the location configuration server by the device SHOULD be used. In particular, when DHCP is used as an LCP, the security mechanisms of RFC 3118 should be used, and when HELD is used as an LCP server-side TLS authentication should be used." (Note: I haven't read the security considerations section of LLDP-MED recently to know if any particular authentication mechanisms should be called out in this document.) In paragraph 3, I think a distinction needs to be made between confidentiality (encryption) mechanisms and integrity protection (signature) mechanisms within S/MIME. In particular, RFC 3261 specifies the use of multipart/signed for integrity protection of SIP bodies. This mechanism does not "obscure" location and should not interfere with intermediate proxies who need to route based on location (or SDP media types). Therefore, I would suggest text such as: "Confidentiality mechanisms such as S/MIME encryption of SIP signaling [RFC 3261] cannot be used because they obscure location. Only hop-by-hop confidentiality mechanisms such as TLS may be used." Section 9.1: The first paragraph indicates that emergency calls are subject to the requirements of RFC 3693. I think it may be worth noting that RFC 3693 explicitly makes an exception for the emergency case. In particular, RFC 3693 indicates that for non-emergency calls, if I can't authenticate the party recieving location information, then I shouldn't send the location information (unless of course, I have a rule that states "it is acceptable to send location information to anyone"), and we don't want the reader to infer that this is also the case with emergency calls. I think we've agreed that for emergency calls, whether to send location to a PSAP that cannot be authenticated is a matter of local policy, but that generally such policy will indicate that location should be sent (even without authentication). I believe it is inappropriate for this section to suggest the use of SIPS. Draft-ietf-sip-sips clarifies that SIPS should be used only when the desired outcome is for call setup to fail if the request cannot be sent over TLS for every hop. This is certainly not the desired outcome for an emergency call. For an emergency call, it is generally quite important that call setup suceed even if some pair of proxies along the signaling path fail to establish a TLS connection. Draft-ietf-sip-sips (Section 3.1.3) makes it clear that in such cases, the correct behaivor of the UAC is target the request for a SIP URI and sent it to the outbound proxy over a TLS connection. (A proxy that recieves a SIP request over a TLS connection should then attempt to send it over a TLS connection for the next hop whenever possible.) Note: There is also TLS-related text in Section 6.12, I would consider deleting the instructions on TLS use in Section 6.12 unless there is a good reason to repeat the text. Section 14: In the second paragraph, merely suggesting the use of S-RTP without guidance on key management is likely to produce bad results. (For instance, a device manufacturer who reads this document might decide that for Media security the UAC will send an offer for an S-RTP session that includes the first message of a MIKEY RSA-R exchange. Unfortunately, if the PSAP doesn't support this particular mode of MIKEY, then the S-RTP key cannot be established and call setup fails. This is obviously a very bad result for an emergency call.) Therefore, I belive that this document should either provide guidance on how to establish S-RTP keys (e.g. DTLS-SRTP) or else should not suggest the use of S-RTP. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Oct 28 07:37:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Im6Qa-0005dm-8U; Sun, 28 Oct 2007 07:35:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Im6QY-0005V2-Sz for ecrit@ietf.org; Sun, 28 Oct 2007 07:35:34 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Im6QO-00070w-H7 for ecrit@ietf.org; Sun, 28 Oct 2007 07:35:25 -0400 Received: (qmail invoked by alias); 28 Oct 2007 11:35:07 -0000 Received: from p54984246.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.66.70] by mail.gmx.net (mp058) with SMTP; 28 Oct 2007 12:35:07 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+pApEJBrGp0lf2lYWP5iqgsxxoSetV1YPh29PQLV vixUsV9Wb819wW Message-ID: <472473EC.1060208@gmx.net> Date: Sun, 28 Oct 2007 12:35:08 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Subject: [Ecrit] Review of draft-ietf-ecrit-phonebcp-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian, I read through the most recent phone BCP draft: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-02.txt The document is getting close to WGLC, I believe. Thank you for working so hard on the draft update. There are only a couple of editorial and terminology issues. In some other cases the usage of RFC 2119 language is not required since there is no protocol impact. I will provide these detailed comments to you at the next week's emergency services workshop. I also made a few comments on the framework document that have impact for this document as well. For example, I noted that requirements like the following one are not really in the scope of our work: " ED-10 Devices SHOULD NOT have one button emergency calling initiation. " A few selected technical issues: ED-13/SP-11/AN-1 Elements MUST NOT convert (civic to geo or geo to civic) from the form of location the determination mechanism supplied. You cannot put a "MUST NOT" requirement here since we need this translation in case we receive location information from DHCP and use it with SIP Location Conveyance. In some sense this contradicts requirement ED-39. AN-4 Access networks supporting copper, fiber or other hard wired IP packet service SHOULD support location configuration. If the network does not support location configuration, it MUST require every device that connects to the network to support end system measured location. I am not sure what this sentence means but I thought we concluded that end hosts have to support a range of location configuration protocols and networks have to at least support one of them. This sentence sounds different to me. ED-19/SP-13 Where proxies provide location on behalf of endpoints, the proxy MUST provide a mechanism to supply emergency dial strings to the device if the device recognizes them, or the proxy MUST track the location of the device with sufficient accuracy and timeliness to be able to recognize the local dial string at the time of an emergency call. The environments where proxies add location on behalf of the end points are exactly those where the proxy has a relationship to the access network. Hence, the proxy can also detect the visited emergency dial string. We NEVER EVER agreed that the proxy supplies emergency dial strings to the device. I know that there was once a draft about this subject and I saw this issue showing up in various presentations but we don't need it. As such, I suggest to delete this sentence rather quickly. ED-25 Software which uses LCPs SHOULD locate and use the actual hardware network interface. Not so sure what this should tell us. AN-15 Placement of NAT devices should consider the effect of the NAT on the LCP. We have to consider this already for the design of the LCP.We don't need to repeat it here. ED-35 If a UA has more than one location available to it, it MUST choose one location to use to route the call towards the PSAP. Shouldn't we just point to the PIDF-LO profile document? SP-20 Proxies handling emergency calls MUST insert a default location if the call does not contain a location. Proxies should only add a default location if the they are unable to determine the location of the end point. I would add this qualification. AN-23/SP-21 Default locations MUST be marked with method=Default and an appropriate provided-by in the PIDF-LO. So far, there is no method field indicating "default" in http://www.iana.org/assignments/method-tokens We would have to add it. ED-40/AN-24 To prevent against spoofing of the DHCP server, elements implementing DHCP for location configuration SHOULD use [RFC3118]. Delete this since the DHCP document already says it. Additionally, you should consider that RFC 3118 is largely a theoretical aspect, i.e., not deployable. Delete the section about "uninitialized devices" per decision at the last IETF meeting. 9.1. Use of TLS I think you might want to capture some of the discussions we had around * TLS session resumption * TLS session resumption without server side state * TLS Ciphersuite usage to ensure proper performance There is some repetition between Section 9.2 and Section 8 when it comes to the service URN usage. Maybe there is room for simplification Regarding ED-77: ED-77 In its response to the test, the PSAP MAY include a text body (text/plain) indicating the identity of the PSAP, the requested service, and the location reported with the call. I recall in one of the document reviews that someone spotted a security vulnerability, namely that an adversary would use emergency call test mechanisms to determine the location of someone else. Do you think that this could be a problem? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Oct 28 08:41:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Im7R9-0007Gh-24; Sun, 28 Oct 2007 08:40:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Im7R5-0007Ea-Hk for ecrit@ietf.org; Sun, 28 Oct 2007 08:40:13 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Im7R4-0000uZ-67 for ecrit@ietf.org; Sun, 28 Oct 2007 08:40:11 -0400 Received: (qmail invoked by alias); 28 Oct 2007 12:40:03 -0000 Received: from p54984246.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.66.70] by mail.gmx.net (mp041) with SMTP; 28 Oct 2007 13:40:03 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX185eCspnpM5TCs401tBWYCLCqaXEmMYitBCenQPHk MsjN+7e/5kmBnm Message-ID: <47248323.5060006@gmx.net> Date: Sun, 28 Oct 2007 13:40:03 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =?windows-1252?Q?Gunnar_Hellstr=F6m?= Subject: Re: [Ecrit] Modification proposals for media support in draft-ietf-ecrit-phonebcp References: <45D47D3D00463E2A@pne-smtpout2-sn1.fre.skanova.net> (added by postmaster@pne.skanova.net) In-Reply-To: <45D47D3D00463E2A@pne-smtpout2-sn1.fre.skanova.net> (added by postmaster@pne.skanova.net) Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: "Ecrit@Ietf. Org" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Gunnar, I just found this mail and noticed that nobody responded to you. Are these issues covered with the recent draft update? Ciao Hannes Gunnar Hellström wrote: > I want to propose a few small modifications to > draft-ietf-ecrit-phonebcp-00.txt > > > 1. Editorial and explanation. > ---------------------------------- > The last lines in section 2 reads: > > “o The proxy recognizes the call as an emergency call and routes the > call using normal SIP routing mechanisms > [RFC4504] details Best Current Practice for SIP user agents. This > memo can be considered an addition to it for endpoints.” > > A full stop is missing after mechanisms, and it is unusual to start a > sentence with a reference. I also suggest to include a hint on what is found > in RFC 4504 > > I suggest a slight change to: > > " o The proxy recognizes the call as an emergency call, routes the > call using normal SIP routing mechanisms. > > Best Current Practice for SIP user agents including handling of audio and > real-time text [RFC 4103] media detailed in [RFC4504] SHOULD be applied. > This memo can be considered an addition to it for endpoints." > > 2. Add a bullet point in the list in section 2. > ------------------------------------------------ > I also suggest that the sequence of steps should end with media > establishment rather than just routing > > Insert as a new bullet point last in the list in section 2: > > o The call is established and common media streams opened. > > > 3. More real-time text improvements > --------------------------------------- > Section 3 starts: > " Although present PSAPs have only support for voice calls" > > That is not true. A reasonable part of the population has also support for > real-time text calls. So, the support for real-time text expected from IP is > to maintain and extend support rather than fulfilling new expectations. > > I suggest rewording to: > > " Support for voice calls and real-time text calls placed > through PSTN facilities or systems connected to the PSTN is found in present > PSAPs. Future PSAPs will however support Internet connectivity and a wider > range of media types and provide higher functionality." > > 4. Handle unused references. > ---------------------------- > In the current version, I have observed two unused references. > [RFC 4103] and [draft-ietf-sipping-toip], both related to the real-time text > medium. > > Revival of reference [rfc 4103] is proposed in 3) above. > > In order to revive the use of [sipping-toip], I suggest adding this line > between the two paragraphs of section 3: > > "The expectations for emergency service support for the real-time text > medium, described in [draft-ietf-sipping-toip], section 7.1 SHOULD be > fulfilled." > > ( draft-ietf-sipping-toip-07 is in publication requested state ) > > > > With these small changes I think the phonebcp draft will be a good guidance > for design of user terminals. > > > > Thanks > > Gunnar > > ------------------------------------------------------------------- > Gunnar Hellström > Omnitor > gunnar.hellstrom@omnitor.se > Tel: +46708204288 > www.omnitor.se > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Oct 28 10:21:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Im8zH-0003yi-Ja; Sun, 28 Oct 2007 10:19:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Im8zG-0003xd-Ks; Sun, 28 Oct 2007 10:19:34 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Im8zB-0006AO-A9; Sun, 28 Oct 2007 10:19:29 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=localhost.localdomain) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Im8z9-00027v-5m; Sun, 28 Oct 2007 10:19:28 -0400 Message-ID: <47249A6E.5080808@bbn.com> Date: Sun, 28 Oct 2007 10:19:26 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: Hannes Tschofenig References: <4724626A.3030806@gmx.net> In-Reply-To: <4724626A.3030806@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: GEOPRIV , ECRIT Subject: [Ecrit] Re: [Geopriv] RFC 3205 & HELD X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org It's also worth noting that RFC 3205 is just a set of recommendations, not anything binding. Since the document doesn't make a general requirement for ALL http-based protocols to have a different URI scheme and port number, was there something in particular about HELD that led you to those requirements? We should probably have this same debate about LoST, although it may be mostly subsumed by previous discussions. (Cross-posted to ECRIT) --RB Hannes Tschofenig wrote: > I have read RFC 3205 and my impression is that for HELD we have to > * define a new URI scheme, and > * use a different port number. > > Thoughts? > > Ciao > Hannes > > PS: What is the value of WSDL in the HELD specification? > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Oct 28 10:23:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Im92c-0000AI-AW; Sun, 28 Oct 2007 10:23:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Im92b-00007Y-Kx for ecrit@ietf.org; Sun, 28 Oct 2007 10:23:01 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Im92b-0006Fs-3t for ecrit@ietf.org; Sun, 28 Oct 2007 10:23:01 -0400 Received: (qmail invoked by alias); 28 Oct 2007 14:22:59 -0000 Received: from p54984246.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.66.70] by mail.gmx.net (mp042) with SMTP; 28 Oct 2007 15:22:59 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+isWYrPiKiJUECSA4odfyuZXzfXoM174Max8zlYG 0C3nCO1044+JnD Message-ID: <47249B43.9050204@gmx.net> Date: Sun, 28 Oct 2007 15:22:59 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Richard Barnes References: <4724626A.3030806@gmx.net> <47249A6E.5080808@bbn.com> In-Reply-To: <47249A6E.5080808@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: GEOPRIV , ECRIT Subject: [Ecrit] Re: [Geopriv] RFC 3205 & HELD X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org RFC 3205 essentially says: If you use HTTP for things other than webbrowsing then you should register a new URI scheme and use a different port number. I was wondering what people think about that idea. Richard Barnes wrote: > It's also worth noting that RFC 3205 is just a set of recommendations, > not anything binding. Since the document doesn't make a general > requirement for ALL http-based protocols to have a different URI > scheme and port number, was there something in particular about HELD > that led you to those requirements? > > We should probably have this same debate about LoST, although it may > be mostly subsumed by previous discussions. (Cross-posted to ECRIT) > > --RB > > > > > Hannes Tschofenig wrote: >> I have read RFC 3205 and my impression is that for HELD we have to >> * define a new URI scheme, and >> * use a different port number. >> >> Thoughts? >> >> Ciao >> Hannes >> >> PS: What is the value of WSDL in the HELD specification? >> >> >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Oct 28 18:31:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImGe0-0007gj-BU; Sun, 28 Oct 2007 18:30:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImGdw-0007fh-Gx; Sun, 28 Oct 2007 18:30:04 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImGdq-0005wK-Bm; Sun, 28 Oct 2007 18:30:04 -0400 X-SEF-Processed: 5_0_0_910__2007_10_28_17_39_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); Sun, 28 Oct 2007 17:39:56 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 28 Oct 2007 17:29:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Re: [Geopriv] RFC 3205 & HELD Date: Sun, 28 Oct 2007 17:29:39 -0500 Message-ID: In-Reply-To: <47249B43.9050204@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Geopriv] RFC 3205 & HELD Thread-Index: AcgZblRtzcQg+p+5TaGs6pQm6ewc9wAQUTYg References: <4724626A.3030806@gmx.net> <47249A6E.5080808@bbn.com> <47249B43.9050204@gmx.net> From: "Thomson, Martin" To: "Hannes Tschofenig" , "Richard Barnes" X-OriginalArrivalTime: 28 Oct 2007 22:29:40.0753 (UTC) FILETIME=[07E74810:01C819B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1589924476==" Errors-To: ecrit-bounces@ietf.org --===============1589924476== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSByZWFkIFJGQyAzMjA1IGEgd2hpbGUgYmFjayB3aGVuIGdvaW5nIHRocm91Z2ggdGhlIGluaXRp YWwgcmV2aXNpb25zIG9mIHRoZSBkb2N1bWVudC4gIEdpdmVuIHRoZSBuYXR1cmUgb2YgdGhlIGRp c2NvdmVyeSBwcm9jZXNzLCB0aGUgVVJJIHNjaGVtZSBpcyBub3QgYSBkZWZpbml0ZSByZXF1aXJl bWVudC4gIE9yaWdpbmFsbHksIHdoZW4gYSBHRVQgcmV0dXJuZWQgYSBQSURGLUxPIChyYXRoZXIg dGhhbiBhIHdyYXBwZWQgUElERi1MTykgSSB3YXMgb2YgdGhlIG9waW5pb24gdGhhdCB0aGUgaHR0 cDogVVJJIHdhcyBiZXN0LiAgR2l2ZW4gdGhlIGNoYW5nZSB0byBhIHdyYXBwZWQgUElERi1MTywg SSBhbSB0ZW5kaW5nIHRvd2FyZHMgYSBuZXcgc2NoZW1lLg0KDQpJIHRoaW5rIHRoYXQgd2UgaGF2 ZSB0byBjb25zaWRlciB0aGUgdXNhZ2UgY29udGV4dC4gIFByaW1hcmlseSwgYSBIRUxEIFVSSSB3 aWxsIGJlIG9idGFpbmVkIGZyb20gdGhlIGRpc2NvdmVyeSBwcm9jZXNzLiAgQXJlIHRoZXJlIGFu eSBvdGhlciBjYXNlcyB3aGVyZSBhIEhFTEQgVVJJIHdvdWxkIGJlIHVzZWQ/ICBQZXJoYXBzIHRo ZSB3ZWItcGFnZSB0ZXN0IG1pZ2h0IHdvcms7IHRoYXQgaXMsIGNhbiB3ZSBpbWFnaW5lIHRoZSBV UkkgYXBwZWFyaW5nIG9uIGEgd2ViLXBhZ2U/ICBJZiBzbywgd2UgZG9uJ3Qgd2FudCB0aGUgc2Vt YW50aWNzIG9mIEhFTEQgY29uZnVzZWQgd2l0aCB0aGUgc2VtYW50aWNzIGV4cGVjdGVkIGJ5IGEg cmVndWxhciB3ZWIgdXNlci4NCg0KSSBkb24ndCB0aGluayB0aGF0IGRpc2N1c3NpbmcgcG9ydHMg aXMgbmVjZXNzYXJ5IC0gSSdkIGxpa2UgdGhlIGNob2ljZSBvZiBwb3J0IHRvIGJlIGV4cGxpY2l0 IGluIGFsbCBjYXNlcy4NCg0KSSB0aGluayB0aGF0IExvU1QgaXMgbXVjaCBjbGVhcmVyIC0gbWFr ZSBhIG5ldyBzY2hlbWUuDQoNCkNoZWVycywNCk1hcnRpbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IEhhbm5lcyBUc2Nob2ZlbmlnIFttYWlsdG86SGFubmVzLlRzY2hv ZmVuaWdAZ214Lm5ldF0NCj4gU2VudDogTW9uZGF5LCAyOSBPY3RvYmVyIDIwMDcgMToyMyBBTQ0K PiBUbzogUmljaGFyZCBCYXJuZXMNCj4gQ2M6IEdFT1BSSVY7IEVDUklUDQo+IFN1YmplY3Q6IFtF Y3JpdF0gUmU6IFtHZW9wcml2XSBSRkMgMzIwNSAmIEhFTEQNCj4gDQo+IFJGQyAzMjA1IGVzc2Vu dGlhbGx5IHNheXM6IElmIHlvdSB1c2UgSFRUUCBmb3IgdGhpbmdzIG90aGVyIHRoYW4NCj4gd2Vi YnJvd3NpbmcgdGhlbiB5b3Ugc2hvdWxkIHJlZ2lzdGVyIGEgbmV3IFVSSSBzY2hlbWUgYW5kIHVz ZSBhDQo+IGRpZmZlcmVudCBwb3J0IG51bWJlci4NCj4gDQo+IEkgd2FzIHdvbmRlcmluZyB3aGF0 IHBlb3BsZSB0aGluayBhYm91dCB0aGF0IGlkZWEuDQo+IA0KPiANCj4gUmljaGFyZCBCYXJuZXMg d3JvdGU6DQo+ID4gSXQncyBhbHNvIHdvcnRoIG5vdGluZyB0aGF0IFJGQyAzMjA1IGlzIGp1c3Qg YSBzZXQgb2YgcmVjb21tZW5kYXRpb25zLA0KPiA+IG5vdCBhbnl0aGluZyBiaW5kaW5nLiAgU2lu Y2UgdGhlIGRvY3VtZW50IGRvZXNuJ3QgbWFrZSBhIGdlbmVyYWwNCj4gPiByZXF1aXJlbWVudCBm b3IgQUxMIGh0dHAtYmFzZWQgcHJvdG9jb2xzIHRvIGhhdmUgYSBkaWZmZXJlbnQgVVJJDQo+ID4g c2NoZW1lIGFuZCBwb3J0IG51bWJlciwgd2FzIHRoZXJlIHNvbWV0aGluZyBpbiBwYXJ0aWN1bGFy IGFib3V0IEhFTEQNCj4gPiB0aGF0IGxlZCB5b3UgdG8gdGhvc2UgcmVxdWlyZW1lbnRzPw0KPiA+ DQo+ID4gV2Ugc2hvdWxkIHByb2JhYmx5IGhhdmUgdGhpcyBzYW1lIGRlYmF0ZSBhYm91dCBMb1NU LCBhbHRob3VnaCBpdCBtYXkNCj4gPiBiZSBtb3N0bHkgc3Vic3VtZWQgYnkgcHJldmlvdXMgZGlz Y3Vzc2lvbnMuICAoQ3Jvc3MtcG9zdGVkIHRvIEVDUklUKQ0KPiA+DQo+ID4gLS1SQg0KPiA+DQo+ ID4NCj4gPg0KPiA+DQo+ID4gSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+ID4+IEkgaGF2ZSBy ZWFkIFJGQyAzMjA1IGFuZCBteSBpbXByZXNzaW9uIGlzIHRoYXQgZm9yIEhFTEQgd2UgaGF2ZSB0 bw0KPiA+PiAqIGRlZmluZSBhIG5ldyBVUkkgc2NoZW1lLCBhbmQNCj4gPj4gKiB1c2UgYSBkaWZm ZXJlbnQgcG9ydCBudW1iZXIuDQo+ID4+DQo+ID4+IFRob3VnaHRzPw0KPiA+Pg0KPiA+PiBDaWFv DQo+ID4+IEhhbm5lcw0KPiA+Pg0KPiA+PiBQUzogV2hhdCBpcyB0aGUgdmFsdWUgb2YgV1NETCBp biB0aGUgSEVMRCBzcGVjaWZpY2F0aW9uPw0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBHZW9wcml2IG1h aWxpbmcgbGlzdA0KPiA+PiBHZW9wcml2QGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3MS5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dlb3ByaXYNCj4gPj4NCj4gDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBFY3JpdCBtYWlsaW5nIGxp c3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZWNyaXQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpU aGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkN CmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGlu Zm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFu eSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJdDQo= --===============1589924476== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1589924476==-- From ecrit-bounces@ietf.org Mon Oct 29 07:18:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImScK-0004Z6-LB; Mon, 29 Oct 2007 07:17:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImScJ-0004TR-V3 for ecrit@ietf.org; Mon, 29 Oct 2007 07:17:12 -0400 Received: from 67.254.241.83.in-addr.dgcsystems.net ([83.241.254.67] helo=smtp.dgcsystems.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImScA-0004SA-Ic for ecrit@ietf.org; Mon, 29 Oct 2007 07:17:03 -0400 Received: from GunnarH ([217.13.240.136]) by smtp.dgcsystems.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Oct 2007 12:17:00 +0100 From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "'Hannes Tschofenig'" Subject: RE: [Ecrit] Modification proposals for media support in draft-ietf-ecrit-phonebcp Date: Mon, 29 Oct 2007 12:17:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcgZX6m3IjwI0v8kTqWJPAMs6CoQgAAmd/Sg In-Reply-To: <47248323.5060006@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Message-ID: X-OriginalArrivalTime: 29 Oct 2007 11:17:01.0055 (UTC) FILETIME=[3A0FD8F0:01C81A1D] X-Spam-Score: 1.7 (+) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: "'Ecrit@Ietf. Org'" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi, Thanks, I have inline answers marked below. Change proposals are marked ++++++++=20 Further comments: 1. Connection of relay services -------------------------------- Recent experience with trials with emergency calls with people with communication related disabilities have made me realize that there are further procedures to define. In order to handle these calls, it is often most efficient to set up a = three party multimedia call with the user, the PSAP and a suitable relay = service. The relay services support call handling by translating, e.g. between = sign language and voice, between real-time text and voice, by adding = real-time text as captions to voice or by supporting weak speech or speech that is hard to understand with clear speech. PSAPS may be able to handle real-time text themselves, but it was = evident from the trial that support from a full three-party connected text relay service made it possible for the the PSAP to concentrate on their = original task. It is obvious for the other communication modes that relay = services need to be invoked in the calls. Some signaling may be needed for invoking the most appropriate relay services rapidly end efficiently in the call.=20 There are two requirement points in the phonebcp draft that relate to = this need, and may be expanded a bit in order to include this need. It is in 9.2, point 15 and in 11, point 1. 1.1 Use Caller preferences for connection of relay services. ------------------------------------------------------------- 9.2 point 15 now reads: " 15. SIP Caller Preferences [RFC3841] MAY be used to signal how the PSAP should handle the call. For example, a language preference expressed in an Accept-Language header may be used as a hint to cause the PSAP to route the call to a call taker who speaks the requested language. " The Caller Preference [RFC 3841] may be used also for indicating the = need to connect a relay service, either simply by specifying a media preference = for text or a media preference for video with a language preference for a = sign language.=20 ++++I suggest to add last in this point.=20 ------------------------------------ "SIP Caller Preferences may also be used to indicate a need to invoke a relay service for communication with people with disabilities in the = call." 1.2 Use of conference calls and REFER to invoke relay services -------------------------------------------------------------- Section 11, point 1 now reads:=20 " 11. Mid-call behavior ED-61/SP-38 During the course of an emergency call, devices and proxies MUST support REFER transactions and the Referred-by: header [RFC3515] to: 1. Be REFERed to a conference bridge; PSAPs often include dispatchers, responders or specialists on a call." A relay service can be seen as a specialist to be included in the call.=20 ++++It may be good to point that out specifically by adding the = following sentence last in Section 11, point 1.: ------------------------------ "Relay services for communication with people with disabilities may be included in the call in this way." 2. There is a slight inconsistency around the use of G.711. ----------------------------------------------------------- Requirement ED-60 in Appendix A, Point 12 says: " 12. A normal SDP offer SHOULD be included in the INVITE. The offer MUST include the G.711 codec, see Section 14." Requirement ED-71, in Appendix A, says: " ED-71 Endpoints supporting voice MUST support G.711 A law (and mu Law in North America) encoded voice as described in [RFC3551]." So, ED-60 gives the impression that voice support is mandatory, while = ED-71 gives the impression that it is optional. There are current SIP = terminals with only real-time text support according to RFC 4103. The question is = if such designs shall be enabled to call emergency services, or if they = need to be complemented with a G.711 voice codec. Some text users are not = interested in using voice at all. +++++Conclusion: ----------- If there is any specific reason why voice is needed in the call, then I think the words "supporting voice" should be deleted from ED-71. If not, = the last sentence in ED-60 Point 12 should read "If voice is supported, the offer MUST include the G.711 codec, see Section 14. 3. Further points inline below. Gunnar -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Sunday, October 28, 2007 1:40 PM To: Gunnar Hellstr=F6m Cc: Ecrit@Ietf. Org Subject: Re: [Ecrit] Modification proposals for media support in draft-ietf-ecrit-phonebcp Hi Gunnar, I just found this mail and noticed that nobody responded to you. Are these issues covered with the recent draft update? Ciao Hannes Gunnar Hellstr=F6m wrote: > I want to propose a few small modifications to=20 > draft-ietf-ecrit-phonebcp-00.txt > > > 1. Editorial and explanation. > ---------------------------------- > The last lines in section 2 reads: > > =93o The proxy recognizes the call as an emergency call and routes = the > call using normal SIP routing mechanisms > [RFC4504] details Best Current Practice for SIP user agents. This > memo can be considered an addition to it for endpoints.=94 > > A full stop is missing after mechanisms, and it is unusual to start a=20 > sentence with a reference. I also suggest to include a hint on what is = > found in RFC 4504 > > I suggest a slight change to: > > " o The proxy recognizes the call as an emergency call, routes the > call using normal SIP routing mechanisms. > > Best Current Practice for SIP user agents including handling of audio=20 > and real-time text [RFC 4103] media detailed in [RFC4504] SHOULD be applied. > This memo can be considered an addition to it for endpoints." The text is rearranged and the new text mainly found in sections 9 = ED-54 and repeated in A.1. Some small adjustments are still needed. It reads: " ED-54 Best Current Practice for SIP user agents including handling = of audio, video and real-time text [RFC4103] SHOULD be applied. This memo can be considered as an addition to it for endpoints." I have a couple of comments still on it: A. Originally, this sentence referred to RFC 4504 as a general Best = Current Practice for SIP endpoints, and especially the real-time text support.=20 By eliminating RFC 4504, it is not clear what Best Current Practice it refers to. It has instead a direct reference to RFC 4103 for real-time = text, and that is good and equally important as the G.711 reference for voice elsewhere. I do not know what reasoning there was behind removing the reference to = RFC 4504. Not knowing the background,=20 +++++I suggest to include the reference "[RFC 4504]" again after the = words "SIP user agents" to read "SIP user agents [RFC 4504]".=20 If there was a specific reason to omit the reference to RFC 4504, I = think ED-54 can be left without that reference.=20 +++++B. It may be unclear what "it" in the last sentence refers to. I suggest changing "it" to "such Best Current Practice". =20 > > 2. Add a bullet point in the list in section 2. > ------------------------------------------------ > I also suggest that the sequence of steps should end with media=20 > establishment rather than just routing > > Insert as a new bullet point last in the list in section 2: > > o The call is established and common media streams opened. > This is now well covered in section 14. > > 3. More real-time text improvements > --------------------------------------- > Section 3 starts: > " Although present PSAPs have only support for voice calls" > > That is not true. A reasonable part of the population has also support = > for real-time text calls. So, the support for real-time text expected=20 > from IP is to maintain and extend support rather than fulfilling new expectations. > > I suggest rewording to: > > " Support for voice calls and real-time text calls placed through PSTN = > facilities or systems connected to the PSTN is found in present PSAPs. = > Future PSAPs will however support Internet connectivity and a wider=20 > range of media types and provide higher functionality." This is well expressed in other ways now. > > 4. Handle unused references. > ---------------------------- > In the current version, I have observed two unused references. > [RFC 4103] and [draft-ietf-sipping-toip], both related to the=20 > real-time text medium. > > Revival of reference [rfc 4103] is proposed in 3) above. > > In order to revive the use of [sipping-toip], I suggest adding this=20 > line between the two paragraphs of section 3: > > "The expectations for emergency service support for the real-time text = > medium, described in [draft-ietf-sipping-toip], section 7.1 SHOULD be=20 > fulfilled." > > ( draft-ietf-sipping-toip-07 is in publication requested state ) Yes, done. > > > > With these small changes I think the phonebcp draft will be a good=20 > guidance for design of user terminals. > Tanks Gunnar > > > Thanks > > Gunnar > > ------------------------------------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > Tel: +46708204288 > www.omnitor.se > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > =20 __________ NOD32 2599 (20071017) Information __________ Detta meddelande =E4r genoms=F6kt av NOD32 Antivirus. http://www.nod32.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 29 14:14:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImZ6U-0005Dx-KF; Mon, 29 Oct 2007 14:12:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImZ6O-0004nS-Iu for ecrit@ietf.org; Mon, 29 Oct 2007 14:12:40 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImZ6M-0004lf-5J for ecrit@ietf.org; Mon, 29 Oct 2007 14:12:38 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l9TICaVw021426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 29 Oct 2007 11:12:37 -0700 Received: from [98.207.5.180] (carbuncle.qualcomm.com [129.46.226.27]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l9TICYRC024685 for ; Mon, 29 Oct 2007 11:12:36 -0700 Mime-Version: 1.0 Message-Id: Date: Mon, 29 Oct 2007 11:12:42 -0700 To: ecrit@ietf.org From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [Ecrit] LoST last call? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Is there an issue with Lost? It shows in the data tracker as having gone to publication requested more than a month ago, but it doesn't seem to have moved into either AD evaluation or IETF Last Call. Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Oct 29 19:55:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImePR-0007PB-N3; Mon, 29 Oct 2007 19:52:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImePD-0007Kh-7w for ecrit@ietf.org; Mon, 29 Oct 2007 19:52:28 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ImePC-0000yt-SU for ecrit@ietf.org; Mon, 29 Oct 2007 19:52:27 -0400 Received: (qmail invoked by alias); 29 Oct 2007 23:52:25 -0000 Received: from ip-90-187-166-39.web.vodafone.de (EHLO [90.187.166.39]) [90.187.166.39] by mail.gmx.net (mp030) with SMTP; 30 Oct 2007 00:52:25 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/ppiU0LMbpdrERyHTyX2aOuX8eDzs6j6KmHCyWgu FG5J1FaQ21mZeI Message-ID: <47267236.30105@gmx.net> Date: Tue, 30 Oct 2007 00:52:22 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Ecrit] media security & phone bcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I noticed that phone bcp talks about signaling security but it does not speak about media security. I believe SRTP is possible for emergency calls. For key management I would mandate Security Descriptions [RFC4568] Sounds reasonable? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 30 02:07:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImkED-00057t-MN; Tue, 30 Oct 2007 02:05:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImkED-00056z-5o for ecrit@ietf.org; Tue, 30 Oct 2007 02:05:29 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImkEC-0005Pm-Sm for ecrit@ietf.org; Tue, 30 Oct 2007 02:05:29 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=localhost.localdomain) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1ImkEB-0005ZM-5w; Tue, 30 Oct 2007 02:05:28 -0400 Message-ID: <4726C9A6.4050304@bbn.com> Date: Tue, 30 Oct 2007 02:05:26 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] media security & phone bcp References: <47267236.30105@gmx.net> In-Reply-To: <47267236.30105@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes, That's a good catch. There should be a discussion of media security in phonebcp. Could you clarify why you think SDES is the mechanism of choice? --Richard Hannes Tschofenig wrote: > I noticed that phone bcp talks about signaling security but it does not > speak about media security. > I believe SRTP is possible for emergency calls. For key management I > would mandate Security Descriptions [RFC4568] > > Sounds reasonable? > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 30 03:26:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImlSj-0001Cr-Ls; Tue, 30 Oct 2007 03:24:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImlSi-0001Ck-1q for ecrit@ietf.org; Tue, 30 Oct 2007 03:24:32 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImlSh-0007mb-K4 for ecrit@ietf.org; Tue, 30 Oct 2007 03:24:31 -0400 Received: from mobile-166-214-074-117.mycingular.net ([166.214.74.117] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1ImlSa-00079y-QK; Tue, 30 Oct 2007 02:24:27 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'ECRIT'" References: <47267236.30105@gmx.net> Subject: RE: [Ecrit] media security & phone bcp Date: Tue, 30 Oct 2007 03:23:39 -0400 Message-ID: <011e01c81ac5$e82c8390$754ad6a6@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgahyfCN2vNX6r7T+u6NI8zdxgIyQAPlgEQ In-Reply-To: <47267236.30105@gmx.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org My problem with this is that the state of media security in SIP can best be described as chaotic. There are few interoperable implementations. The basic SRTP is easy to specify, but there is no clear guidance we can give on the signaling to establish the SRTP connections. As you know, there is work on this in rtpsec, but that appears to be far from solidifying as yet. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Monday, October 29, 2007 7:52 PM > To: ECRIT > Subject: [Ecrit] media security & phone bcp > > I noticed that phone bcp talks about signaling security but it does not > speak about media security. > I believe SRTP is possible for emergency calls. For key management I > would mandate Security Descriptions [RFC4568] > > Sounds reasonable? > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 30 06:49:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImodG-0000gm-GE; Tue, 30 Oct 2007 06:47:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImodF-0000gZ-E2 for ecrit@ietf.org; Tue, 30 Oct 2007 06:47:37 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imod9-0004ax-6v for ecrit@ietf.org; Tue, 30 Oct 2007 06:47:37 -0400 Received: from ([139.76.131.91]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.32616953; Tue, 30 Oct 2007 06:46:46 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 30 Oct 2007 06:46:46 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 30 Oct 2007 06:46:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] media security & phone bcp Date: Tue, 30 Oct 2007 06:46:42 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA06376479@crexc41p> In-Reply-To: <011e01c81ac5$e82c8390$754ad6a6@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] media security & phone bcp Thread-Index: AcgahyfCN2vNX6r7T+u6NI8zdxgIyQAPlgEQAAbcvXA= References: <47267236.30105@gmx.net> <011e01c81ac5$e82c8390$754ad6a6@cis.neustar.com> From: "Stark, Barbara" To: "Brian Rosen" , "Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 30 Oct 2007 10:46:45.0960 (UTC) FILETIME=[2A981480:01C81AE2] X-Spam-Score: 0.2 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I agree with Brian's assessment. Also, SRTP is "heavy". Currently, there's no push for the added expense of SRTP to be supported in consumer end devices. Until it becomes common in end devices, I can't support mandating it for use with emergency calls. And I think it's going to be a long time (maybe a really long time) before it gets implemented in consumer end devices. Barbara -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, October 30, 2007 3:24 AM To: 'Hannes Tschofenig'; 'ECRIT' Subject: RE: [Ecrit] media security & phone bcp My problem with this is that the state of media security in SIP can best be described as chaotic. There are few interoperable implementations. The basic SRTP is easy to specify, but there is no clear guidance we can give on the signaling to establish the SRTP connections. As you know, there is work on this in rtpsec, but that appears to be far from solidifying as yet. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Monday, October 29, 2007 7:52 PM > To: ECRIT > Subject: [Ecrit] media security & phone bcp >=20 > I noticed that phone bcp talks about signaling security but it does not > speak about media security. > I believe SRTP is possible for emergency calls. For key management I > would mandate Security Descriptions [RFC4568] >=20 > Sounds reasonable? >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Oct 30 19:00:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1In03U-0008Ex-EC; Tue, 30 Oct 2007 18:59:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1In03T-0008Eo-1O for ecrit@ietf.org; Tue, 30 Oct 2007 18:59:27 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1In03M-0002im-T3 for ecrit@ietf.org; Tue, 30 Oct 2007 18:59:27 -0400 Received: from [172.20.100.180] (adsl-67-117-91-116.dsl.sntc01.pacbell.net [67.117.91.116]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id l9UMwmq8011732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 30 Oct 2007 18:58:49 -0400 (EDT) In-Reply-To: <011e01c81ac5$e82c8390$754ad6a6@cis.neustar.com> References: <47267236.30105@gmx.net> <011e01c81ac5$e82c8390$754ad6a6@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <58CDA762-59B5-4DBB-AFD5-68E2F35CD736@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] media security & phone bcp Date: Tue, 30 Oct 2007 10:14:44 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 1.9 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I agree with Brian here; this requirement will likely just be ignored and should best be done in a revision of the document in a year or two, once we have a better idea which combination of techniques is generally being implemented. As far as I know, the SIP and MMUSIC WGs have not reached consensus on this. It is not clear that we have a motivation that makes all emergency media so much more privacy-sensitive than all other phone calls. On Oct 30, 2007, at 3:23 AM, Brian Rosen wrote: > My problem with this is that the state of media security in SIP can > best be > described as chaotic. There are few interoperable > implementations. The > basic SRTP is easy to specify, but there is no clear guidance we > can give on > the signaling to establish the SRTP connections. As you know, > there is work > on this in rtpsec, but that appears to be far from solidifying as yet. > > Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 31 10:22:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InESF-0006nY-Bi; Wed, 31 Oct 2007 10:21:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InESE-0006nQ-GP for ecrit@ietf.org; Wed, 31 Oct 2007 10:21:58 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InESD-00077a-VH for ecrit@ietf.org; Wed, 31 Oct 2007 10:21:58 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=localhost.localdomain) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1InESD-0001wW-4N; Wed, 31 Oct 2007 10:21:57 -0400 Message-ID: <47288F84.5010203@bbn.com> Date: Wed, 31 Oct 2007 10:21:56 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: "Stark, Barbara" , ECRIT References: <002801c81bbc$a673fd00$1d69fe90@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA063767D9@crexc41p> In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA063767D9@crexc41p> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Subject: [Ecrit] Re: [Geopriv] Use of IP address as an identifier indraft-ietf-geopriv-http-location-delivery X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Right, I think what's needed is more a caveat that HELD provides the location of the source IP address in the IP header of the request -- whatever that may be. --Richard Stark, Barbara wrote: > How is a client supposed to know whether a "VPN, NAT or other IP address > modification exists between the client and the server which could > produce incorrect location"? One of the best uses of HELD is the case > where there is a NAT (and the box with the NAT is location unaware). For > landline broadband services, this NAT exists, but doesn't produce an > incorrect location. So this NAT is ok. How can you distinguish between a > NAT that produces an incorrect location, vs. one that produces a correct > location? > > The VPN could be originated out of the router, and not the client. How > would the client know this VPN even exists? > > Unless you can tell me the logic to use to implement this proposed > requirement, I can't support it. > Barbara > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, October 31, 2007 8:51 AM > To: geopriv@ietf.org > Subject: [Geopriv] Use of IP address as an identifier > indraft-ietf-geopriv-http-location-delivery > > In the long set of discussions that have lead to HELD, one of the > biggest > concerns a few of us have had is the problem than an IP address may not > be a > good identifier for determining the location of the client. There is a > draft that describes alternate identifiers. However, there is no > discussion > in the present draft of the base protocol on these issues. > > I would like to propose that we add text something like: > > Use of HELD is subject to the viability of the identifier used by the > LIS to > determine location. This document describes the use of the IP address > of > the client as the identifier. When a NAT, VPN or other forms of address > modification occur between the client and the server, the location > returned > may be inaccurate. This is not always the case. For example, a NAT > used in > a residential local area network is typically not a problem, because the > external IP address used on the WAN side of the NAT is in fact the right > identifier for all of the devices in the residence. On the other hand, > if > there is a VPN between the client and the server, for example for a > teleworker, then the address seen by the server may not be the right > address > to identify the location of the client. Where a VPN is deployed, > clients > often have the ability to bypass the VPN for a transaction like HELD. > > HELD Clients MUST NOT send HELD requests where IP address is the > identifier > and a VPN, NAT or other IP address modification exists between the > client > and the server which could produce incorrect location. HELD MUST NOT be > deployed in networks where the client cannot comply reasonably reliably > with > that requirement. > > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > ***** > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623 > > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > R _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Oct 31 11:58:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InFx8-0001Qk-BP; Wed, 31 Oct 2007 11:57:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InFx7-0001Pm-4x for ecrit@ietf.org; Wed, 31 Oct 2007 11:57:57 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InFx0-0004uq-KM for ecrit@ietf.org; Wed, 31 Oct 2007 11:57:57 -0400 X-SEF-Processed: 5_0_0_910__2007_10_31_11_07_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); Wed, 31 Oct 2007 11:07:56 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Oct 2007 10:57:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address as anidentifier indraft-ietf-geopriv-http-location-delivery Date: Wed, 31 Oct 2007 10:57:37 -0500 Message-ID: In-Reply-To: <47288F84.5010203@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Geopriv] Use of IP address as anidentifier indraft-ietf-geopriv-http-location-delivery Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3Tg References: <002801c81bbc$a673fd00$1d69fe90@cis.neustar.com><7582BC68E4994F4ABF0BD4723975C3FA063767D9@crexc41p> <47288F84.5010203@bbn.com> From: "Dawson, Martin" To: "Richard Barnes" , "Stark, Barbara" , "ECRIT" X-OriginalArrivalTime: 31 Oct 2007 15:57:37.0989 (UTC) FILETIME=[C27B9750:01C81BD6] X-Spam-Score: 1.8 (+) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think that the "device" requirement at most should be that efforts=0D=0As= hould be made to ensure that the LIS is discovered and used on the=0D=0Aphy= sical access network and not via any VPN tunnel.=0D=0A=0D=0APerhaps more im= portantly, there should be a complementary requirement on=0D=0Athe LIS that= it not attempt to provide location for an IP address that=0D=0Ait cannot a= ssociate a physical location with. For example, a LIS in an=0D=0Aenterprise= , where that enterprise supports VPN access, should know or be=0D=0Aable to= determine that the client requests are arriving over a VPN from=0D=0Aan en= d point whose location cannot be determined. The HELD response=0D=0Ashould = indicate that location cannot be provided.=0D=0A=0D=0ACheers,=0D=0AMartin=0D= =0A=0D=0A-----Original Message-----=0D=0AFrom: Richard Barnes [mailto:rbarn= es@bbn.com]=20=0D=0ASent: Thursday, 1 November 2007 1:22 AM=0D=0ATo: Stark,= Barbara; ECRIT=0D=0ASubject: [Ecrit] Re: [Geopriv] Use of IP address as an= identifier=0D=0Aindraft-ietf-geopriv-http-location-delivery=0D=0A=0D=0ARigh= t, I think what's needed is more a caveat that HELD provides the=20=0D=0Alo= cation of the source IP address in the IP header of the request --=20=0D=0A= whatever that may be.=0D=0A=0D=0A--Richard=0D=0A=0D=0A=0D=0A=0D=0AStark, Ba= rbara wrote:=0D=0A> How is a client supposed to know whether a "VPN, NAT or= other IP=0D=0Aaddress=0D=0A> modification exists between the client and th= e server which could=0D=0A> produce incorrect location"=3F One of the best = uses of HELD is the case=0D=0A> where there is a NAT (and the box with the = NAT is location unaware).=0D=0AFor=0D=0A> landline broadband services, this= NAT exists, but doesn't produce an=0D=0A> incorrect location. So this NAT = is ok. How can you distinguish between=0D=0Aa=0D=0A> NAT that produces an i= ncorrect location, vs. one that produces a=0D=0Acorrect=0D=0A> location=3F=0D= =0A>=20=0D=0A> The VPN could be originated out of the router, and not the c= lient. How=0D=0A> would the client know this VPN even exists=3F=0D=0A>=20=0D= =0A> Unless you can tell me the logic to use to implement this proposed=0D=0A= > requirement, I can't support it.=0D=0A> Barbara=0D=0A>=20=0D=0A> -----Ori= ginal Message-----=0D=0A> From: Brian Rosen [mailto:br@brianrosen.net]=20=0D= =0A> Sent: Wednesday, October 31, 2007 8:51 AM=0D=0A> To: geopriv@ietf.org=0D= =0A> Subject: [Geopriv] Use of IP address as an identifier=0D=0A> indraft-i= etf-geopriv-http-location-delivery=0D=0A>=20=0D=0A> In the long set of disc= ussions that have lead to HELD, one of the=0D=0A> biggest=0D=0A> concerns a= few of us have had is the problem than an IP address may=0D=0Anot=0D=0A> b= e a=0D=0A> good identifier for determining the location of the client. The= re is=0D=0Aa=0D=0A> draft that describes alternate identifiers. However, t= here is no=0D=0A> discussion=0D=0A> in the present draft of the base protoc= ol on these issues. =20=0D=0A>=20=0D=0A> I would like to propose that we ad= d text something like:=0D=0A>=20=0D=0A> Use of HELD is subject to the viabi= lity of the identifier used by the=0D=0A> LIS to=0D=0A> determine location.= This document describes the use of the IP address=0D=0A> of=0D=0A> the cl= ient as the identifier. When a NAT, VPN or other forms of=0D=0Aaddress=0D=0A= > modification occur between the client and the server, the location=0D=0A>= returned=0D=0A> may be inaccurate. This is not always the case. For exam= ple, a NAT=0D=0A> used in=0D=0A> a residential local area network is typica= lly not a problem, because=0D=0Athe=0D=0A> external IP address used on the = WAN side of the NAT is in fact the=0D=0Aright=0D=0A> identifier for all of = the devices in the residence. On the other=0D=0Ahand,=0D=0A> if=0D=0A> the= re is a VPN between the client and the server, for example for a=0D=0A> tel= eworker, then the address seen by the server may not be the right=0D=0A> ad= dress=0D=0A> to identify the location of the client. Where a VPN is deploy= ed,=0D=0A> clients=0D=0A> often have the ability to bypass the VPN for a tr= ansaction like HELD.=0D=0A>=20=0D=0A> HELD Clients MUST NOT send HELD reque= sts where IP address is the=0D=0A> identifier=0D=0A> and a VPN, NAT or othe= r IP address modification exists between the=0D=0A> client=0D=0A> and the s= erver which could produce incorrect location. HELD MUST NOT=0D=0Abe=0D=0A>= deployed in networks where the client cannot comply reasonably=0D=0Areliab= ly=0D=0A> with=0D=0A> that requirement.=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A= >=20=0D=0A> _______________________________________________=0D=0A> Geopriv = mailing list=0D=0A> Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailman/l= istinfo/geopriv=0D=0A>=20=0D=0A> *****=0D=0A>=20=0D=0A> The information tra= nsmitted is intended only for the person or entity=0D=0Ato which it is addr= essed and may contain confidential, proprietary,=0D=0Aand/or privileged mat= erial. Any review, retransmission, dissemination or=0D=0Aother use of, or t= aking of any action in reliance upon this information=0D=0Aby persons or en= tities other than the intended recipient is prohibited.=0D=0AIf you receive= d this in error, please contact the sender and delete the=0D=0Amaterial fro= m all computers. GA623=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> _____= __________________________________________=0D=0A> Geopriv mailing list=0D=0A= > Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/geopriv=0D= =0A>=20=0D=0AR=0D=0A=0D=0A_______________________________________________=0D= =0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www1.ietf.org/mailma= n/listinfo/ecrit=0D=0A=0D=0A-----------------------------------------------= -------------------------------------------------=0D=0AThis message is for = the designated recipient only and may=0D=0Acontain privileged, proprietary,= or otherwise private information. =20=0D=0AIf you have received it in erro= r, please notify the sender=0D=0Aimmediately and delete the original. Any = unauthorized use of=0D=0Athis email is prohibited.=0D=0A-------------------= ---------------------------------------------------------------------------= --=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit