From br@brianrosen.net Wed Mar 2 13:57:01 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 484FE3A68C4 for ; Wed, 2 Mar 2011 13:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH6PpZfgVPEW for ; Wed, 2 Mar 2011 13:57:00 -0800 (PST) Received: from barmail5.idig.net (barmail5.idig.net [64.34.111.236]) by core3.amsl.com (Postfix) with ESMTP id ED0D53A68BD for ; Wed, 2 Mar 2011 13:56:59 -0800 (PST) X-ASG-Debug-ID: 1299103077-00f27e5477e583000f-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail5.idig.net with ESMTP id pryuGobV67FHtKRI for ; Wed, 02 Mar 2011 13:58:00 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=mlus-lt500.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PutrY-0006z0-A3; Wed, 02 Mar 2011 13:45:46 -0800 Mime-Version: 1.0 (Apple Message framework v1082) X-ASG-Orig-Subj: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: Date: Wed, 2 Mar 2011 16:45:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> References: <4D61266D.1030104@ericsson.com> To: Brian Rosen X-Mailer: Apple Mail (2.1082) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1299103080 X-Barracuda-URL: http://64.34.111.236:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.56872 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 Cc: ecrit Org Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 21:57:01 -0000 Folks, we need to decide what to do about codecs, as discussed below. I believe we have been over this, and the only thing that made sense was = to require G.711 as the common codec. I'm still comfortable with that, and propose to leave the text as is. Brian On Feb 22, 2011, at 1:17 PM, Brian Rosen wrote: > Thank you for this review. It shows once again what a brand new set = of eyes can do for document. My thanks, again, to all the GenART = reviewers and the system. >=20 > See inline for my responses >=20 > On Feb 20, 2011, at 9:34 AM, Miguel A. Garcia wrote: >=20 >> I have been selected as the General Area Review Team (Gen-ART) >> reviewer for this draft. For background on Gen-ART, please see the = FAQ at >>=20 >> Please resolve these comments along with any other comments you may = receive. >>=20 >> Document: draft-ietf-ecrit-phonebcp-16.txt >> Reviewer: Miguel Garcia >> Review Date: 2011-02-20 >> IETF LC End Date: 2011-02-21 >>=20 >> Summary: This draft is on the right track but has open issues, = described in the review. >>=20 >> Major issues: None >>=20 >> Minor issues: >>=20 >> - I don't understand the last sentence in Section 6.2.1, which reads: >>=20 >> Where a civic form of location is provided, all >> fields in the PIDF-LO [RFC4119] and [RFC5139] MUST be able to be >> specified. >>=20 >> what I don't understand is the meaning of "MUST be able to be = specified". And I don't understand if this is a requirement for the = service provider, for the access network, or for the end device. Can you = explain what is the intention of the sentence? > The notion is that the location configuration protocol may generate a = PIDF that contains any of the elements defined in 4119/5139. All = downstream elements must pass all fields. It applies to all the = entities. Any suggestions for rewording to make this more clear would = be appreciated. >=20 >=20 >=20 >>=20 >>=20 >>=20 >> - Section 6.5, second paragraph (req. AN-13/INT-14). I have a problem = with the sentence that reads: >>=20 >> If the access network supports more than one location >> configuration protocol, all such protocols MUST return the same >> location, within the constraints of the protocols deployed. >>=20 >> I don't understand how this requirement can be achieved. Assume that = an access network supports several location configuration protocols, = which are able to determine the location by different means. Ideally all = protocols should return the same location, but in practice, it will be = difficult, due to the different accuracy and confidence among the = various protocols. Additionally, I believe there is nothing the access = network administrator can do to make sure that all location protocols = will return the same location for a given device. >>=20 >> Conclusion: I consider this sentence to be a hope rather than a = requirement. Perhaps it can be rephrased saying that ".... it is = expected that all such protocols will return the same location ....". > This is a PROTOCOL issue and not a location determination issue. = Think of the protocol as being a transport mechanism for the location. = Each transport must return the same location. This is saying if you = have more than one protocol and more than one location determination = mechanism, all protocols must return the same location >=20 >=20 >>=20 >>=20 >>=20 >> - Section 6.5., requirement AN-15/INT-17. It seems that this = requirement is duplicated from the second sentence of requirements = AN-13/INT-14 (see my previous comment). So, there should be only one = requirement with the same text, and my previous comment should apply. > Yes, that is a problem. I propose to delete the sentence in the prior = section, and leave this one. >=20 >>=20 >>=20 >>=20 >> - Section 7, Requirement ED-51. I think this requirement also applies = to the Service Provider (at least the configuration part of it), so it = should get an SP number as well. > Yeah, I see the problem. It might be easier to just delete the = sentence, but I could add an AN requirement. Anyone else have an = opinion? >=20 >>=20 >>=20 >>=20 >> - Section 9.2, first bullet point. The text reads: >>=20 >> If >> the device cannot interpret local dial strings, the Request-URI >> SHOULD be a dial string URI [RFC4967] with the dialed digits. >>=20 >> I don't understand how this requirement can be enforced. If someone = has not read this document and has not implemented local dial strings, = how can you put a requirement around dial string URIs to that person who = has not implemented dial string URIs and possibly not read your draft? > If the device implementer didn't read the document, then it wouldn't = conform to this document. If they did, then they should use dial = strings. The device generates this, it doesn't get it from other = entity. I don't understand the problem. >=20 >=20 >>=20 >> Perhaps you can say that "it is expected that ...", but not placing a = formal requirement. >>=20 >> This comment also applies to bullet point 2 in the same Section 9.2, = regarding the To header field. > Same response. >=20 >>=20 >>=20 >>=20 >> - Section 9.2, bullet point 10. The text reads: >>=20 >> A SDP offer SHOULD be included in the INVITE. If voice is >> supported the offer MUST include the G.711 codec, see >> Section 14. >>=20 >> Honestly, this is an unrealistic requirement. G.711 is well known for = its bandwidth consumption. Due to this, as far as I know, there is no = cellular network in the world that support or uses G.711 either in = circuit-switched or VoIP. I don't think this draft is going to change = the current status quo. Actually, none has ever got to standardize a = single codec for an application. Due to this, protocols like SIP/SDP = support an codec negotiation mechanism in the format of the SDP offer = answer. >>=20 >> Other considerations: >>=20 >> The requirement is nod needed, because in the absence of it, SDP = offer answer will get to negotiate to a single codec for the emergency = call. >>=20 >> This requirement falls into the category of national or supranational = regulation. There will be organisms which will dictate minimum or = recommended support in terms of codecs, and this regulation will be = above the requirements in this document. >>=20 >> My recommendation is to delete this requirement. >>=20 >> I also noticed that this requirement is also repeated in Section 14, = Requirement AD-73. The recommendation is also to delete such = requirement. >>=20 >> Also, req ED-77 in Section 14 tries to do the same with a video = codec. The recommendation is still the same. > This has been discussed before. The goal is to be able to have any = device, anywhere, be able to complete an emergency call. To make that = work, you have to have at least one common codec. It's not something a = local regulation could fix: when you get off a plane, your softclient on = your VoIP service provider, must be able to complete an emergency call = where you are. >=20 > The alternative is to have the document have a requirement on PSAPs to = implement a relatively long list of codecs, and then have each device = implement at least one of those. That would be quite difficult to make = such a list, and even if you did, some service would have a problem. >=20 >=20 >>=20 >>=20 >>=20 >> - Section 12, the text reads: >>=20 >> Dropping of the old call MUST only >> occur if the user is attempting to hang up >>=20 >> But the previous sentence says: >>=20 >> If in the interval, an incoming call is received from >> the domain of the PSAP, the device MUST drop the old call and alert >> for the (new) incoming call. >>=20 >> So, we have two scenarios for dropping an old call: >> 1) the user is attempting to hung up >> 2) an incoming call is received from the PSAP >>=20 >> Therefore, I disagree with the "MUST only occur" of the first = sentence. Please rephrase the text to avoid contradictions. > Is see your point. In SIP, hang up requires the complete BYE = transaction, and you can be in the middle of that transaction when the = new call arrives. The problem is the word "drop". What we are = attempting to say is that even though you are in the middle of that = transaction, you have to abandon it, and accept the new call. So I need = a better word for "drop". >=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Nits: >>=20 >> - Expands acronyms at first occurrence. This includes: PSAP, PIDF, = PIDF-LO, HELD, LCP, and LoST. > the terminology sections says: > This document uses terms from [RFC3261], [RFC5012] and = [I-D.ietf-ecrit-framework]. >=20 > I thought that would be enough. I can expand the acronyms here. >=20 >>=20 >> - Section 9.2, first bullet point >> s/tree, If/tree. If >>=20 >> - Section 9.2, second bullet point >> s/not find a a Router/not find a Router >>=20 >> - Section 11 >> s/and the Referred-by: header/and the Referred-by header > Thanks, I'll fix these >=20 >=20 >>=20 >>=20 >> BR, >>=20 >> Miguel >>=20 >>=20 >>=20 >> --=20 >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From bernard_aboba@hotmail.com Wed Mar 2 15:14:56 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09F1A3A6907 for ; Wed, 2 Mar 2011 15:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyKscHWhkjR4 for ; Wed, 2 Mar 2011 15:14:52 -0800 (PST) Received: from blu0-omc3-s4.blu0.hotmail.com (blu0-omc3-s4.blu0.hotmail.com [65.55.116.79]) by core3.amsl.com (Postfix) with ESMTP id D91593A68E2 for ; Wed, 2 Mar 2011 15:14:51 -0800 (PST) Received: from BLU152-DS14 ([65.55.116.72]) by blu0-omc3-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Mar 2011 15:15:57 -0800 X-Originating-IP: [131.107.0.94] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'Brian Rosen'" References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> In-Reply-To: <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> Date: Wed, 2 Mar 2011 15:15:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJzo0y1yGuvGL1qq7rSY//SYXx9LAE0nfAmAenRbZuSsh2XQA== Content-Language: en-us X-OriginalArrivalTime: 02 Mar 2011 23:15:57.0902 (UTC) FILETIME=[C99756E0:01CBD92F] Cc: 'ecrit Org' Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 23:14:56 -0000 It seems to me that the requirements could be different on the PSAP side (which could be expected to support more codecs) than on the handset. For example, the requirements for the PSAP could be support of codecs A, B AND C. It is already suggested in Section 9.2 that "PSAPs may support a wide range of media types and codecs". This is just a "may", not even a "MAY". Yet in ED-73 it is suggested that " It is desirable to include wideband codecs such as AMR-WB in the offer." What is the point of doing that if there is not even a recommendation that the PSAP support a wideband codec? That raises the question of whether it would make sense to require the PSAP to implement at least one codec widely implemented on mobile devices. In terms of the handset requirements generated by whatever is decided on the PSAP, it would make sense for the handset to have to implement at least one of the MANDATORY to implement PSAP codecs. If it turns out that the PSAP is only mandated to support G.711, but recommended to do others, then you'd have to mandate G.711 on the handset. But if there are multiple mandatory-to-implement codecs on the PSAP side, then the handset should only have to implement one of them. -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen Sent: Wednesday, March 02, 2011 1:46 PM To: Brian Rosen Cc: ecrit Org Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt Folks, we need to decide what to do about codecs, as discussed below. I believe we have been over this, and the only thing that made sense was to require G.711 as the common codec. I'm still comfortable with that, and propose to leave the text as is. Brian On Feb 22, 2011, at 1:17 PM, Brian Rosen wrote: > Thank you for this review. It shows once again what a brand new set of eyes can do for document. My thanks, again, to all the GenART reviewers and the system. > > See inline for my responses > > On Feb 20, 2011, at 9:34 AM, Miguel A. Garcia wrote: > >> I have been selected as the General Area Review Team (Gen-ART) >> reviewer for this draft. For background on Gen-ART, please see the >> FAQ at >> >> Please resolve these comments along with any other comments you may receive. >> >> Document: draft-ietf-ecrit-phonebcp-16.txt >> Reviewer: Miguel Garcia Review Date: >> 2011-02-20 IETF LC End Date: 2011-02-21 >> >> Summary: This draft is on the right track but has open issues, described in the review. >> >> Major issues: None >> >> Minor issues: >> >> - I don't understand the last sentence in Section 6.2.1, which reads: >> >> Where a civic form of location is provided, all fields in the >> PIDF-LO [RFC4119] and [RFC5139] MUST be able to be specified. >> >> what I don't understand is the meaning of "MUST be able to be specified". And I don't understand if this is a requirement for the service provider, for the access network, or for the end device. Can you explain what is the intention of the sentence? > The notion is that the location configuration protocol may generate a PIDF that contains any of the elements defined in 4119/5139. All downstream elements must pass all fields. It applies to all the entities. Any suggestions for rewording to make this more clear would be appreciated. > > > >> >> >> >> - Section 6.5, second paragraph (req. AN-13/INT-14). I have a problem with the sentence that reads: >> >> If the access network supports more than one location configuration >> protocol, all such protocols MUST return the same location, within >> the constraints of the protocols deployed. >> >> I don't understand how this requirement can be achieved. Assume that an access network supports several location configuration protocols, which are able to determine the location by different means. Ideally all protocols should return the same location, but in practice, it will be difficult, due to the different accuracy and confidence among the various protocols. Additionally, I believe there is nothing the access network administrator can do to make sure that all location protocols will return the same location for a given device. >> >> Conclusion: I consider this sentence to be a hope rather than a requirement. Perhaps it can be rephrased saying that ".... it is expected that all such protocols will return the same location ....". > This is a PROTOCOL issue and not a location determination issue. > Think of the protocol as being a transport mechanism for the location. > Each transport must return the same location. This is saying if you > have more than one protocol and more than one location determination > mechanism, all protocols must return the same location > > >> >> >> >> - Section 6.5., requirement AN-15/INT-17. It seems that this requirement is duplicated from the second sentence of requirements AN-13/INT-14 (see my previous comment). So, there should be only one requirement with the same text, and my previous comment should apply. > Yes, that is a problem. I propose to delete the sentence in the prior section, and leave this one. > >> >> >> >> - Section 7, Requirement ED-51. I think this requirement also applies to the Service Provider (at least the configuration part of it), so it should get an SP number as well. > Yeah, I see the problem. It might be easier to just delete the sentence, but I could add an AN requirement. Anyone else have an opinion? > >> >> >> >> - Section 9.2, first bullet point. The text reads: >> >> If >> the device cannot interpret local dial strings, the Request-URI >> SHOULD be a dial string URI [RFC4967] with the dialed digits. >> >> I don't understand how this requirement can be enforced. If someone has not read this document and has not implemented local dial strings, how can you put a requirement around dial string URIs to that person who has not implemented dial string URIs and possibly not read your draft? > If the device implementer didn't read the document, then it wouldn't conform to this document. If they did, then they should use dial strings. The device generates this, it doesn't get it from other entity. I don't understand the problem. > > >> >> Perhaps you can say that "it is expected that ...", but not placing a formal requirement. >> >> This comment also applies to bullet point 2 in the same Section 9.2, regarding the To header field. > Same response. > >> >> >> >> - Section 9.2, bullet point 10. The text reads: >> >> A SDP offer SHOULD be included in the INVITE. If voice is >> supported the offer MUST include the G.711 codec, see >> Section 14. >> >> Honestly, this is an unrealistic requirement. G.711 is well known for its bandwidth consumption. Due to this, as far as I know, there is no cellular network in the world that support or uses G.711 either in circuit-switched or VoIP. I don't think this draft is going to change the current status quo. Actually, none has ever got to standardize a single codec for an application. Due to this, protocols like SIP/SDP support an codec negotiation mechanism in the format of the SDP offer answer. >> >> Other considerations: >> >> The requirement is nod needed, because in the absence of it, SDP offer answer will get to negotiate to a single codec for the emergency call. >> >> This requirement falls into the category of national or supranational regulation. There will be organisms which will dictate minimum or recommended support in terms of codecs, and this regulation will be above the requirements in this document. >> >> My recommendation is to delete this requirement. >> >> I also noticed that this requirement is also repeated in Section 14, Requirement AD-73. The recommendation is also to delete such requirement. >> >> Also, req ED-77 in Section 14 tries to do the same with a video codec. The recommendation is still the same. > This has been discussed before. The goal is to be able to have any device, anywhere, be able to complete an emergency call. To make that work, you have to have at least one common codec. It's not something a local regulation could fix: when you get off a plane, your softclient on your VoIP service provider, must be able to complete an emergency call where you are. > > The alternative is to have the document have a requirement on PSAPs to implement a relatively long list of codecs, and then have each device implement at least one of those. That would be quite difficult to make such a list, and even if you did, some service would have a problem. > > >> >> >> >> - Section 12, the text reads: >> >> Dropping of the old call MUST only >> occur if the user is attempting to hang up >> >> But the previous sentence says: >> >> If in the interval, an incoming call is received from the domain of >> the PSAP, the device MUST drop the old call and alert for the (new) >> incoming call. >> >> So, we have two scenarios for dropping an old call: >> 1) the user is attempting to hung up >> 2) an incoming call is received from the PSAP >> >> Therefore, I disagree with the "MUST only occur" of the first sentence. Please rephrase the text to avoid contradictions. > Is see your point. In SIP, hang up requires the complete BYE transaction, and you can be in the middle of that transaction when the new call arrives. The problem is the word "drop". What we are attempting to say is that even though you are in the middle of that transaction, you have to abandon it, and accept the new call. So I need a better word for "drop". > >> >> >> >> >> >> Nits: >> >> - Expands acronyms at first occurrence. This includes: PSAP, PIDF, PIDF-LO, HELD, LCP, and LoST. > the terminology sections says: > This document uses terms from [RFC3261], [RFC5012] and [I-D.ietf-ecrit-framework]. > > I thought that would be enough. I can expand the acronyms here. > >> >> - Section 9.2, first bullet point >> s/tree, If/tree. If >> >> - Section 9.2, second bullet point >> s/not find a a Router/not find a Router >> >> - Section 11 >> s/and the Referred-by: header/and the Referred-by header > Thanks, I'll fix these > > >> >> >> BR, >> >> Miguel >> >> >> >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Wed Mar 2 16:34:19 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CE2F3A690E for ; Wed, 2 Mar 2011 16:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.166 X-Spam-Level: X-Spam-Status: No, score=-102.166 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0y5-MzSlzOK for ; Wed, 2 Mar 2011 16:34:16 -0800 (PST) Received: from barmail5.idig.net (barmail5.idig.net [64.34.111.236]) by core3.amsl.com (Postfix) with ESMTP id AA0D43A67F5 for ; Wed, 2 Mar 2011 16:34:16 -0800 (PST) X-ASG-Debug-ID: 1299111481-00f27e5478ee670001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail5.idig.net with ESMTP id s39XGFBeJ0w9vPNs; Wed, 02 Mar 2011 16:18:01 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=mlus-lt500.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PuwEt-0000jA-J5; Wed, 02 Mar 2011 16:18:02 -0800 Mime-Version: 1.0 (Apple Message framework v1082) X-ASG-Orig-Subj: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: Date: Wed, 2 Mar 2011 19:17:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> To: Bernard Aboba X-Mailer: Apple Mail (2.1082) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1299111481 X-Barracuda-URL: http://64.34.111.236:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.56882 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 Cc: 'ecrit Org' Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 00:34:19 -0000 The problem is agreeing on which ones Although you could pick AMR, what do you do about other systems? Is it = reasonable to expect all devices to implement 711 or AMR? Hardly. How many codecs must a PSAP implement? 2 is reasonable. Is 6, 8? This was the discussion we had before. Brian =20 On Mar 2, 2011, at 6:15 PM, Bernard Aboba wrote: > It seems to me that the requirements could be different on the PSAP = side > (which could be expected to support more codecs) than on the handset. = For > example, the requirements for the PSAP could be support of codecs A, B = AND > C. =20 >=20 > It is already suggested in Section 9.2 that "PSAPs may support a wide = range > of media types and codecs". This is just a "may", not even a "MAY". = Yet > in ED-73 it is suggested that " It is desirable to include wideband = codecs > such as AMR-WB in the offer." What is the point of doing that if = there is > not even a recommendation that the PSAP support a wideband codec? = That > raises the question of whether it would make sense to require the PSAP = to > implement at least one codec widely implemented on mobile devices.=20 >=20 > In terms of the handset requirements generated by whatever is decided = on the > PSAP, it would make sense for the handset to have to implement at = least one > of the MANDATORY to implement PSAP codecs. If it turns out that the = PSAP > is only mandated to support G.711, but recommended to do others, then = you'd > have to mandate G.711 on the handset. But if there are multiple > mandatory-to-implement codecs on the PSAP side, then the handset = should only > have to implement one of them.=20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of > Brian Rosen > Sent: Wednesday, March 02, 2011 1:46 PM > To: Brian Rosen > Cc: ecrit Org > Subject: Re: [Ecrit] Gen-ART review of = draft-ietf-ecrit-phonebcp-16.txt >=20 > Folks, we need to decide what to do about codecs, as discussed below. >=20 > I believe we have been over this, and the only thing that made sense = was to > require G.711 as the common codec. >=20 > I'm still comfortable with that, and propose to leave the text as is. >=20 > Brian >=20 > On Feb 22, 2011, at 1:17 PM, Brian Rosen wrote: >=20 >> Thank you for this review. It shows once again what a brand new set = of > eyes can do for document. My thanks, again, to all the GenART = reviewers > and the system. >>=20 >> See inline for my responses >>=20 >> On Feb 20, 2011, at 9:34 AM, Miguel A. Garcia wrote: >>=20 >>> I have been selected as the General Area Review Team (Gen-ART)=20 >>> reviewer for this draft. For background on Gen-ART, please see the=20= >>> FAQ at >>>=20 >>> Please resolve these comments along with any other comments you may > receive. >>>=20 >>> Document: draft-ietf-ecrit-phonebcp-16.txt >>> Reviewer: Miguel Garcia Review Date:=20= >>> 2011-02-20 IETF LC End Date: 2011-02-21 >>>=20 >>> Summary: This draft is on the right track but has open issues, = described > in the review. >>>=20 >>> Major issues: None >>>=20 >>> Minor issues: >>>=20 >>> - I don't understand the last sentence in Section 6.2.1, which = reads: >>>=20 >>> Where a civic form of location is provided, all fields in the=20 >>> PIDF-LO [RFC4119] and [RFC5139] MUST be able to be specified. >>>=20 >>> what I don't understand is the meaning of "MUST be able to be = specified". > And I don't understand if this is a requirement for the service = provider, > for the access network, or for the end device. Can you explain what is = the > intention of the sentence? >> The notion is that the location configuration protocol may generate a = PIDF > that contains any of the elements defined in 4119/5139. All = downstream > elements must pass all fields. It applies to all the entities. Any > suggestions for rewording to make this more clear would be = appreciated. >>=20 >>=20 >>=20 >>>=20 >>>=20 >>>=20 >>> - Section 6.5, second paragraph (req. AN-13/INT-14). I have a = problem > with the sentence that reads: >>>=20 >>> If the access network supports more than one location configuration=20= >>> protocol, all such protocols MUST return the same location, within=20= >>> the constraints of the protocols deployed. >>>=20 >>> I don't understand how this requirement can be achieved. Assume that = an > access network supports several location configuration protocols, = which are > able to determine the location by different means. Ideally all = protocols > should return the same location, but in practice, it will be = difficult, due > to the different accuracy and confidence among the various protocols. > Additionally, I believe there is nothing the access network = administrator > can do to make sure that all location protocols will return the same > location for a given device. >>>=20 >>> Conclusion: I consider this sentence to be a hope rather than a > requirement. Perhaps it can be rephrased saying that ".... it is = expected > that all such protocols will return the same location ....". >> This is a PROTOCOL issue and not a location determination issue. =20 >> Think of the protocol as being a transport mechanism for the = location. =20 >> Each transport must return the same location. This is saying if you=20= >> have more than one protocol and more than one location determination=20= >> mechanism, all protocols must return the same location >>=20 >>=20 >>>=20 >>>=20 >>>=20 >>> - Section 6.5., requirement AN-15/INT-17. It seems that this = requirement > is duplicated from the second sentence of requirements AN-13/INT-14 = (see my > previous comment). So, there should be only one requirement with the = same > text, and my previous comment should apply. >> Yes, that is a problem. I propose to delete the sentence in the = prior > section, and leave this one. >>=20 >>>=20 >>>=20 >>>=20 >>> - Section 7, Requirement ED-51. I think this requirement also = applies to > the Service Provider (at least the configuration part of it), so it = should > get an SP number as well. >> Yeah, I see the problem. It might be easier to just delete the = sentence, > but I could add an AN requirement. Anyone else have an opinion? >>=20 >>>=20 >>>=20 >>>=20 >>> - Section 9.2, first bullet point. The text reads: >>>=20 >>> If >>> the device cannot interpret local dial strings, the Request-URI >>> SHOULD be a dial string URI [RFC4967] with the dialed digits. >>>=20 >>> I don't understand how this requirement can be enforced. If someone = has > not read this document and has not implemented local dial strings, how = can > you put a requirement around dial string URIs to that person who has = not > implemented dial string URIs and possibly not read your draft? >> If the device implementer didn't read the document, then it wouldn't > conform to this document. If they did, then they should use dial = strings. > The device generates this, it doesn't get it from other entity. I = don't > understand the problem. >>=20 >>=20 >>>=20 >>> Perhaps you can say that "it is expected that ...", but not placing = a > formal requirement. >>>=20 >>> This comment also applies to bullet point 2 in the same Section 9.2, > regarding the To header field. >> Same response. >>=20 >>>=20 >>>=20 >>>=20 >>> - Section 9.2, bullet point 10. The text reads: >>>=20 >>> A SDP offer SHOULD be included in the INVITE. If voice is >>> supported the offer MUST include the G.711 codec, see >>> Section 14. >>>=20 >>> Honestly, this is an unrealistic requirement. G.711 is well known = for its > bandwidth consumption. Due to this, as far as I know, there is no = cellular > network in the world that support or uses G.711 either in = circuit-switched > or VoIP. I don't think this draft is going to change the current = status quo. > Actually, none has ever got to standardize a single codec for an > application. Due to this, protocols like SIP/SDP support an codec > negotiation mechanism in the format of the SDP offer answer. >>>=20 >>> Other considerations: >>>=20 >>> The requirement is nod needed, because in the absence of it, SDP = offer > answer will get to negotiate to a single codec for the emergency call. >>>=20 >>> This requirement falls into the category of national or = supranational > regulation. There will be organisms which will dictate minimum or > recommended support in terms of codecs, and this regulation will be = above > the requirements in this document. >>>=20 >>> My recommendation is to delete this requirement. >>>=20 >>> I also noticed that this requirement is also repeated in Section 14, > Requirement AD-73. The recommendation is also to delete such = requirement. >>>=20 >>> Also, req ED-77 in Section 14 tries to do the same with a video = codec. > The recommendation is still the same. >> This has been discussed before. The goal is to be able to have any > device, anywhere, be able to complete an emergency call. To make that = work, > you have to have at least one common codec. It's not something a = local > regulation could fix: when you get off a plane, your softclient on = your VoIP > service provider, must be able to complete an emergency call where you = are. >>=20 >> The alternative is to have the document have a requirement on PSAPs = to > implement a relatively long list of codecs, and then have each device > implement at least one of those. That would be quite difficult to = make such > a list, and even if you did, some service would have a problem. >>=20 >>=20 >>>=20 >>>=20 >>>=20 >>> - Section 12, the text reads: >>>=20 >>> Dropping of the old call MUST only >>> occur if the user is attempting to hang up >>>=20 >>> But the previous sentence says: >>>=20 >>> If in the interval, an incoming call is received from the domain of=20= >>> the PSAP, the device MUST drop the old call and alert for the (new)=20= >>> incoming call. >>>=20 >>> So, we have two scenarios for dropping an old call: >>> 1) the user is attempting to hung up >>> 2) an incoming call is received from the PSAP >>>=20 >>> Therefore, I disagree with the "MUST only occur" of the first = sentence. > Please rephrase the text to avoid contradictions. >> Is see your point. In SIP, hang up requires the complete BYE = transaction, > and you can be in the middle of that transaction when the new call = arrives. > The problem is the word "drop". What we are attempting to say is that = even > though you are in the middle of that transaction, you have to abandon = it, > and accept the new call. So I need a better word for "drop". >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Nits: >>>=20 >>> - Expands acronyms at first occurrence. This includes: PSAP, PIDF, > PIDF-LO, HELD, LCP, and LoST. >> the terminology sections says: >> This document uses terms from [RFC3261], [RFC5012] and > [I-D.ietf-ecrit-framework]. >>=20 >> I thought that would be enough. I can expand the acronyms here. >>=20 >>>=20 >>> - Section 9.2, first bullet point >>> s/tree, If/tree. If >>>=20 >>> - Section 9.2, second bullet point >>> s/not find a a Router/not find a Router >>>=20 >>> - Section 11 >>> s/and the Referred-by: header/and the Referred-by header >> Thanks, I'll fix these >>=20 >>=20 >>>=20 >>>=20 >>> BR, >>>=20 >>> Miguel >>>=20 >>>=20 >>>=20 >>> -- >>> Miguel A. Garcia >>> +34-91-339-3608 >>> Ericsson Spain >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From rbarnes@bbn.com Wed Mar 2 17:01:03 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00873A68D0 for ; Wed, 2 Mar 2011 17:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2pr-0jk3bpt for ; Wed, 2 Mar 2011 17:01:02 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 3799C3A67EB for ; Wed, 2 Mar 2011 17:01:02 -0800 (PST) Received: from [128.89.254.1] (port=58049 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Puwvf-0004xq-0e; Wed, 02 Mar 2011 20:02:07 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Wed, 2 Mar 2011 20:02:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <75430548-5E9C-4FB5-9D82-C1E7EAF58010@bbn.com> References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1082) Cc: 'ecrit Org' Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 01:01:03 -0000 Do you have a pointer to the prior discussion? --Richard On Mar 2, 2011, at 7:17 PM, Brian Rosen wrote: > The problem is agreeing on which ones >=20 > Although you could pick AMR, what do you do about other systems? Is = it reasonable to expect all devices to implement 711 or AMR? Hardly. > How many codecs must a PSAP implement? 2 is reasonable. Is 6, 8? >=20 > This was the discussion we had before. >=20 > Brian >=20 > On Mar 2, 2011, at 6:15 PM, Bernard Aboba wrote: >=20 >> It seems to me that the requirements could be different on the PSAP = side >> (which could be expected to support more codecs) than on the handset. = For >> example, the requirements for the PSAP could be support of codecs A, = B AND >> C. =20 >>=20 >> It is already suggested in Section 9.2 that "PSAPs may support a wide = range >> of media types and codecs". This is just a "may", not even a = "MAY". Yet >> in ED-73 it is suggested that " It is desirable to include wideband = codecs >> such as AMR-WB in the offer." What is the point of doing that if = there is >> not even a recommendation that the PSAP support a wideband codec? = That >> raises the question of whether it would make sense to require the = PSAP to >> implement at least one codec widely implemented on mobile devices.=20 >>=20 >> In terms of the handset requirements generated by whatever is decided = on the >> PSAP, it would make sense for the handset to have to implement at = least one >> of the MANDATORY to implement PSAP codecs. If it turns out that the = PSAP >> is only mandated to support G.711, but recommended to do others, then = you'd >> have to mandate G.711 on the handset. But if there are multiple >> mandatory-to-implement codecs on the PSAP side, then the handset = should only >> have to implement one of them.=20 >>=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of >> Brian Rosen >> Sent: Wednesday, March 02, 2011 1:46 PM >> To: Brian Rosen >> Cc: ecrit Org >> Subject: Re: [Ecrit] Gen-ART review of = draft-ietf-ecrit-phonebcp-16.txt >>=20 >> Folks, we need to decide what to do about codecs, as discussed below. >>=20 >> I believe we have been over this, and the only thing that made sense = was to >> require G.711 as the common codec. >>=20 >> I'm still comfortable with that, and propose to leave the text as is. >>=20 >> Brian >>=20 >> On Feb 22, 2011, at 1:17 PM, Brian Rosen wrote: >>=20 >>> Thank you for this review. It shows once again what a brand new set = of >> eyes can do for document. My thanks, again, to all the GenART = reviewers >> and the system. >>>=20 >>> See inline for my responses >>>=20 >>> On Feb 20, 2011, at 9:34 AM, Miguel A. Garcia wrote: >>>=20 >>>> I have been selected as the General Area Review Team (Gen-ART)=20 >>>> reviewer for this draft. For background on Gen-ART, please see the=20= >>>> FAQ at >>>>=20 >>>> Please resolve these comments along with any other comments you may >> receive. >>>>=20 >>>> Document: draft-ietf-ecrit-phonebcp-16.txt >>>> Reviewer: Miguel Garcia Review Date:=20= >>>> 2011-02-20 IETF LC End Date: 2011-02-21 >>>>=20 >>>> Summary: This draft is on the right track but has open issues, = described >> in the review. >>>>=20 >>>> Major issues: None >>>>=20 >>>> Minor issues: >>>>=20 >>>> - I don't understand the last sentence in Section 6.2.1, which = reads: >>>>=20 >>>> Where a civic form of location is provided, all fields in the=20 >>>> PIDF-LO [RFC4119] and [RFC5139] MUST be able to be specified. >>>>=20 >>>> what I don't understand is the meaning of "MUST be able to be = specified". >> And I don't understand if this is a requirement for the service = provider, >> for the access network, or for the end device. Can you explain what = is the >> intention of the sentence? >>> The notion is that the location configuration protocol may generate = a PIDF >> that contains any of the elements defined in 4119/5139. All = downstream >> elements must pass all fields. It applies to all the entities. Any >> suggestions for rewording to make this more clear would be = appreciated. >>>=20 >>>=20 >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> - Section 6.5, second paragraph (req. AN-13/INT-14). I have a = problem >> with the sentence that reads: >>>>=20 >>>> If the access network supports more than one location = configuration=20 >>>> protocol, all such protocols MUST return the same location, within=20= >>>> the constraints of the protocols deployed. >>>>=20 >>>> I don't understand how this requirement can be achieved. Assume = that an >> access network supports several location configuration protocols, = which are >> able to determine the location by different means. Ideally all = protocols >> should return the same location, but in practice, it will be = difficult, due >> to the different accuracy and confidence among the various protocols. >> Additionally, I believe there is nothing the access network = administrator >> can do to make sure that all location protocols will return the same >> location for a given device. >>>>=20 >>>> Conclusion: I consider this sentence to be a hope rather than a >> requirement. Perhaps it can be rephrased saying that ".... it is = expected >> that all such protocols will return the same location ....". >>> This is a PROTOCOL issue and not a location determination issue. =20 >>> Think of the protocol as being a transport mechanism for the = location. =20 >>> Each transport must return the same location. This is saying if you=20= >>> have more than one protocol and more than one location determination=20= >>> mechanism, all protocols must return the same location >>>=20 >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> - Section 6.5., requirement AN-15/INT-17. It seems that this = requirement >> is duplicated from the second sentence of requirements AN-13/INT-14 = (see my >> previous comment). So, there should be only one requirement with the = same >> text, and my previous comment should apply. >>> Yes, that is a problem. I propose to delete the sentence in the = prior >> section, and leave this one. >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> - Section 7, Requirement ED-51. I think this requirement also = applies to >> the Service Provider (at least the configuration part of it), so it = should >> get an SP number as well. >>> Yeah, I see the problem. It might be easier to just delete the = sentence, >> but I could add an AN requirement. Anyone else have an opinion? >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> - Section 9.2, first bullet point. The text reads: >>>>=20 >>>> If >>>> the device cannot interpret local dial strings, the Request-URI >>>> SHOULD be a dial string URI [RFC4967] with the dialed digits. >>>>=20 >>>> I don't understand how this requirement can be enforced. If someone = has >> not read this document and has not implemented local dial strings, = how can >> you put a requirement around dial string URIs to that person who has = not >> implemented dial string URIs and possibly not read your draft? >>> If the device implementer didn't read the document, then it wouldn't >> conform to this document. If they did, then they should use dial = strings. >> The device generates this, it doesn't get it from other entity. I = don't >> understand the problem. >>>=20 >>>=20 >>>>=20 >>>> Perhaps you can say that "it is expected that ...", but not placing = a >> formal requirement. >>>>=20 >>>> This comment also applies to bullet point 2 in the same Section = 9.2, >> regarding the To header field. >>> Same response. >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> - Section 9.2, bullet point 10. The text reads: >>>>=20 >>>> A SDP offer SHOULD be included in the INVITE. If voice is >>>> supported the offer MUST include the G.711 codec, see >>>> Section 14. >>>>=20 >>>> Honestly, this is an unrealistic requirement. G.711 is well known = for its >> bandwidth consumption. Due to this, as far as I know, there is no = cellular >> network in the world that support or uses G.711 either in = circuit-switched >> or VoIP. I don't think this draft is going to change the current = status quo. >> Actually, none has ever got to standardize a single codec for an >> application. Due to this, protocols like SIP/SDP support an codec >> negotiation mechanism in the format of the SDP offer answer. >>>>=20 >>>> Other considerations: >>>>=20 >>>> The requirement is nod needed, because in the absence of it, SDP = offer >> answer will get to negotiate to a single codec for the emergency = call. >>>>=20 >>>> This requirement falls into the category of national or = supranational >> regulation. There will be organisms which will dictate minimum or >> recommended support in terms of codecs, and this regulation will be = above >> the requirements in this document. >>>>=20 >>>> My recommendation is to delete this requirement. >>>>=20 >>>> I also noticed that this requirement is also repeated in Section = 14, >> Requirement AD-73. The recommendation is also to delete such = requirement. >>>>=20 >>>> Also, req ED-77 in Section 14 tries to do the same with a video = codec. >> The recommendation is still the same. >>> This has been discussed before. The goal is to be able to have any >> device, anywhere, be able to complete an emergency call. To make = that work, >> you have to have at least one common codec. It's not something a = local >> regulation could fix: when you get off a plane, your softclient on = your VoIP >> service provider, must be able to complete an emergency call where = you are. >>>=20 >>> The alternative is to have the document have a requirement on PSAPs = to >> implement a relatively long list of codecs, and then have each device >> implement at least one of those. That would be quite difficult to = make such >> a list, and even if you did, some service would have a problem. >>>=20 >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> - Section 12, the text reads: >>>>=20 >>>> Dropping of the old call MUST only >>>> occur if the user is attempting to hang up >>>>=20 >>>> But the previous sentence says: >>>>=20 >>>> If in the interval, an incoming call is received from the domain = of=20 >>>> the PSAP, the device MUST drop the old call and alert for the = (new)=20 >>>> incoming call. >>>>=20 >>>> So, we have two scenarios for dropping an old call: >>>> 1) the user is attempting to hung up >>>> 2) an incoming call is received from the PSAP >>>>=20 >>>> Therefore, I disagree with the "MUST only occur" of the first = sentence. >> Please rephrase the text to avoid contradictions. >>> Is see your point. In SIP, hang up requires the complete BYE = transaction, >> and you can be in the middle of that transaction when the new call = arrives. >> The problem is the word "drop". What we are attempting to say is = that even >> though you are in the middle of that transaction, you have to abandon = it, >> and accept the new call. So I need a better word for "drop". >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Nits: >>>>=20 >>>> - Expands acronyms at first occurrence. This includes: PSAP, PIDF, >> PIDF-LO, HELD, LCP, and LoST. >>> the terminology sections says: >>> This document uses terms from [RFC3261], [RFC5012] and >> [I-D.ietf-ecrit-framework]. >>>=20 >>> I thought that would be enough. I can expand the acronyms here. >>>=20 >>>>=20 >>>> - Section 9.2, first bullet point >>>> s/tree, If/tree. If >>>>=20 >>>> - Section 9.2, second bullet point >>>> s/not find a a Router/not find a Router >>>>=20 >>>> - Section 11 >>>> s/and the Referred-by: header/and the Referred-by header >>> Thanks, I'll fix these >>>=20 >>>=20 >>>>=20 >>>>=20 >>>> BR, >>>>=20 >>>> Miguel >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Miguel A. Garcia >>>> +34-91-339-3608 >>>> Ericsson Spain >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From gunnar.hellstrom@omnitor.se Wed Mar 2 21:27:01 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99FCA3A696A for ; Wed, 2 Mar 2011 21:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfuDtwAmrWyr for ; Wed, 2 Mar 2011 21:27:00 -0800 (PST) Received: from vsp-outgoing1.binero.net (vsp-outgoing1.binero.net [193.17.218.160]) by core3.amsl.com (Postfix) with SMTP id 0C9873A6969 for ; Wed, 2 Mar 2011 21:26:58 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.39.229]) by vsp-outgoing1.binero.net (Halon Mail Gateway) with ESMTP for ; Thu, 3 Mar 2011 06:27:57 +0100 (CET) Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-03-01.atm.binero.net (Postfix) with ESMTPA id B86733A17A for ; Thu, 3 Mar 2011 06:27:56 +0100 (CET) Message-ID: <4D6F26E3.9020505@omnitor.se> Date: Thu, 03 Mar 2011 06:28:03 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: ecrit@ietf.org References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> <75430548-5E9C-4FB5-9D82-C1E7EAF58010@bbn.com> In-Reply-To: <75430548-5E9C-4FB5-9D82-C1E7EAF58010@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 05:27:01 -0000 The solution can be to label the codec points ED-x/SP-x meaning that it is the service providers responsibility to make sure that transcoding is made if there is no codec match between what the PSAP has in reality and what the endpoint has in reality. Thus the Service provider takes part in the ED tasks when needed. The same is valid if the user device is not at all a SIP device, but need to be able to make IP based emergency calls. Then, the service provider needs to be the conversion point for whatever protocol and media coding you have between the service provider and the terminal. This can be done in the document in two alternative ways: 1. Change the explanation of ED to mean functions provided by the End Device and Service Provider together in a way decided by the service provider. 2. Use ED/SP labels on the requirements that must be handled in this combined way to guarantee functionality. It would of course be good also to have a very short list of alternative codecs here so that the service provider can know that it does not need to activate transcoding in most cases, e.g. mobile. /Gunnar Hellström Richard L. Barnes skrev 2011-03-03 02:02: > Do you have a pointer to the prior discussion? > --Richard > > On Mar 2, 2011, at 7:17 PM, Brian Rosen wrote: > >> The problem is agreeing on which ones >> >> Although you could pick AMR, what do you do about other systems? Is it reasonable to expect all devices to implement 711 or AMR? Hardly. >> How many codecs must a PSAP implement? 2 is reasonable. Is 6, 8? >> >> This was the discussion we had before. >> >> Brian >> >> On Mar 2, 2011, at 6:15 PM, Bernard Aboba wrote: >> >>> It seems to me that the requirements could be different on the PSAP side >>> (which could be expected to support more codecs) than on the handset. For >>> example, the requirements for the PSAP could be support of codecs A, B AND >>> C. >>> >>> It is already suggested in Section 9.2 that "PSAPs may support a wide range >>> of media types and codecs". This is just a "may", not even a "MAY". Yet >>> in ED-73 it is suggested that " It is desirable to include wideband codecs >>> such as AMR-WB in the offer." What is the point of doing that if there is >>> not even a recommendation that the PSAP support a wideband codec? That >>> raises the question of whether it would make sense to require the PSAP to >>> implement at least one codec widely implemented on mobile devices. >>> >>> In terms of the handset requirements generated by whatever is decided on the >>> PSAP, it would make sense for the handset to have to implement at least one >>> of the MANDATORY to implement PSAP codecs. If it turns out that the PSAP >>> is only mandated to support G.711, but recommended to do others, then you'd >>> have to mandate G.711 on the handset. But if there are multiple >>> mandatory-to-implement codecs on the PSAP side, then the handset should only >>> have to implement one of them. >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >>> Brian Rosen >>> Sent: Wednesday, March 02, 2011 1:46 PM >>> To: Brian Rosen >>> Cc: ecrit Org >>> Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt >>> >>> Folks, we need to decide what to do about codecs, as discussed below. >>> >>> I believe we have been over this, and the only thing that made sense was to >>> require G.711 as the common codec. >>> >>> I'm still comfortable with that, and propose to leave the text as is. >>> >>> Brian >>> >>> On Feb 22, 2011, at 1:17 PM, Brian Rosen wrote: >>> >>>> Thank you for this review. It shows once again what a brand new set of >>> eyes can do for document. My thanks, again, to all the GenART reviewers >>> and the system. >>>> See inline for my responses >>>> >>>> On Feb 20, 2011, at 9:34 AM, Miguel A. Garcia wrote: >>>> >>>>> I have been selected as the General Area Review Team (Gen-ART) >>>>> reviewer for this draft. For background on Gen-ART, please see the >>>>> FAQ at >>>>> >>>>> Please resolve these comments along with any other comments you may >>> receive. >>>>> Document: draft-ietf-ecrit-phonebcp-16.txt >>>>> Reviewer: Miguel Garcia Review Date: >>>>> 2011-02-20 IETF LC End Date: 2011-02-21 >>>>> >>>>> Summary: This draft is on the right track but has open issues, described >>> in the review. >>>>> Major issues: None >>>>> >>>>> Minor issues: >>>>> >>>>> - I don't understand the last sentence in Section 6.2.1, which reads: >>>>> >>>>> Where a civic form of location is provided, all fields in the >>>>> PIDF-LO [RFC4119] and [RFC5139] MUST be able to be specified. >>>>> >>>>> what I don't understand is the meaning of "MUST be able to be specified". >>> And I don't understand if this is a requirement for the service provider, >>> for the access network, or for the end device. Can you explain what is the >>> intention of the sentence? >>>> The notion is that the location configuration protocol may generate a PIDF >>> that contains any of the elements defined in 4119/5139. All downstream >>> elements must pass all fields. It applies to all the entities. Any >>> suggestions for rewording to make this more clear would be appreciated. >>>> >>>> >>>>> >>>>> >>>>> - Section 6.5, second paragraph (req. AN-13/INT-14). I have a problem >>> with the sentence that reads: >>>>> If the access network supports more than one location configuration >>>>> protocol, all such protocols MUST return the same location, within >>>>> the constraints of the protocols deployed. >>>>> >>>>> I don't understand how this requirement can be achieved. Assume that an >>> access network supports several location configuration protocols, which are >>> able to determine the location by different means. Ideally all protocols >>> should return the same location, but in practice, it will be difficult, due >>> to the different accuracy and confidence among the various protocols. >>> Additionally, I believe there is nothing the access network administrator >>> can do to make sure that all location protocols will return the same >>> location for a given device. >>>>> Conclusion: I consider this sentence to be a hope rather than a >>> requirement. Perhaps it can be rephrased saying that ".... it is expected >>> that all such protocols will return the same location ....". >>>> This is a PROTOCOL issue and not a location determination issue. >>>> Think of the protocol as being a transport mechanism for the location. >>>> Each transport must return the same location. This is saying if you >>>> have more than one protocol and more than one location determination >>>> mechanism, all protocols must return the same location >>>> >>>> >>>>> >>>>> >>>>> - Section 6.5., requirement AN-15/INT-17. It seems that this requirement >>> is duplicated from the second sentence of requirements AN-13/INT-14 (see my >>> previous comment). So, there should be only one requirement with the same >>> text, and my previous comment should apply. >>>> Yes, that is a problem. I propose to delete the sentence in the prior >>> section, and leave this one. >>>>> >>>>> >>>>> - Section 7, Requirement ED-51. I think this requirement also applies to >>> the Service Provider (at least the configuration part of it), so it should >>> get an SP number as well. >>>> Yeah, I see the problem. It might be easier to just delete the sentence, >>> but I could add an AN requirement. Anyone else have an opinion? >>>>> >>>>> >>>>> - Section 9.2, first bullet point. The text reads: >>>>> >>>>> If >>>>> the device cannot interpret local dial strings, the Request-URI >>>>> SHOULD be a dial string URI [RFC4967] with the dialed digits. >>>>> >>>>> I don't understand how this requirement can be enforced. If someone has >>> not read this document and has not implemented local dial strings, how can >>> you put a requirement around dial string URIs to that person who has not >>> implemented dial string URIs and possibly not read your draft? >>>> If the device implementer didn't read the document, then it wouldn't >>> conform to this document. If they did, then they should use dial strings. >>> The device generates this, it doesn't get it from other entity. I don't >>> understand the problem. >>>> >>>>> Perhaps you can say that "it is expected that ...", but not placing a >>> formal requirement. >>>>> This comment also applies to bullet point 2 in the same Section 9.2, >>> regarding the To header field. >>>> Same response. >>>> >>>>> >>>>> >>>>> - Section 9.2, bullet point 10. The text reads: >>>>> >>>>> A SDP offer SHOULD be included in the INVITE. If voice is >>>>> supported the offer MUST include the G.711 codec, see >>>>> Section 14. >>>>> >>>>> Honestly, this is an unrealistic requirement. G.711 is well known for its >>> bandwidth consumption. Due to this, as far as I know, there is no cellular >>> network in the world that support or uses G.711 either in circuit-switched >>> or VoIP. I don't think this draft is going to change the current status quo. >>> Actually, none has ever got to standardize a single codec for an >>> application. Due to this, protocols like SIP/SDP support an codec >>> negotiation mechanism in the format of the SDP offer answer. >>>>> Other considerations: >>>>> >>>>> The requirement is nod needed, because in the absence of it, SDP offer >>> answer will get to negotiate to a single codec for the emergency call. >>>>> This requirement falls into the category of national or supranational >>> regulation. There will be organisms which will dictate minimum or >>> recommended support in terms of codecs, and this regulation will be above >>> the requirements in this document. >>>>> My recommendation is to delete this requirement. >>>>> >>>>> I also noticed that this requirement is also repeated in Section 14, >>> Requirement AD-73. The recommendation is also to delete such requirement. >>>>> Also, req ED-77 in Section 14 tries to do the same with a video codec. >>> The recommendation is still the same. >>>> This has been discussed before. The goal is to be able to have any >>> device, anywhere, be able to complete an emergency call. To make that work, >>> you have to have at least one common codec. It's not something a local >>> regulation could fix: when you get off a plane, your softclient on your VoIP >>> service provider, must be able to complete an emergency call where you are. >>>> The alternative is to have the document have a requirement on PSAPs to >>> implement a relatively long list of codecs, and then have each device >>> implement at least one of those. That would be quite difficult to make such >>> a list, and even if you did, some service would have a problem. >>>> >>>>> >>>>> >>>>> - Section 12, the text reads: >>>>> >>>>> Dropping of the old call MUST only >>>>> occur if the user is attempting to hang up >>>>> >>>>> But the previous sentence says: >>>>> >>>>> If in the interval, an incoming call is received from the domain of >>>>> the PSAP, the device MUST drop the old call and alert for the (new) >>>>> incoming call. >>>>> >>>>> So, we have two scenarios for dropping an old call: >>>>> 1) the user is attempting to hung up >>>>> 2) an incoming call is received from the PSAP >>>>> >>>>> Therefore, I disagree with the "MUST only occur" of the first sentence. >>> Please rephrase the text to avoid contradictions. >>>> Is see your point. In SIP, hang up requires the complete BYE transaction, >>> and you can be in the middle of that transaction when the new call arrives. >>> The problem is the word "drop". What we are attempting to say is that even >>> though you are in the middle of that transaction, you have to abandon it, >>> and accept the new call. So I need a better word for "drop". >>>>> >>>>> >>>>> >>>>> >>>>> Nits: >>>>> >>>>> - Expands acronyms at first occurrence. This includes: PSAP, PIDF, >>> PIDF-LO, HELD, LCP, and LoST. >>>> the terminology sections says: >>>> This document uses terms from [RFC3261], [RFC5012] and >>> [I-D.ietf-ecrit-framework]. >>>> I thought that would be enough. I can expand the acronyms here. >>>> >>>>> - Section 9.2, first bullet point >>>>> s/tree, If/tree. If >>>>> >>>>> - Section 9.2, second bullet point >>>>> s/not find a a Router/not find a Router >>>>> >>>>> - Section 11 >>>>> s/and the Referred-by: header/and the Referred-by header >>>> Thanks, I'll fix these >>>> >>>> >>>>> >>>>> BR, >>>>> >>>>> Miguel >>>>> >>>>> >>>>> >>>>> -- >>>>> Miguel A. Garcia >>>>> +34-91-339-3608 >>>>> Ericsson Spain >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From keith.drage@alcatel-lucent.com Thu Mar 3 04:12:16 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DE123A6947 for ; Thu, 3 Mar 2011 04:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.522 X-Spam-Level: X-Spam-Status: No, score=-105.522 tagged_above=-999 required=5 tests=[AWL=0.727, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7bna9o56SNK for ; Thu, 3 Mar 2011 04:12:14 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 7DF893A6784 for ; Thu, 3 Mar 2011 04:12:14 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p23CCur8021502 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Mar 2011 13:13:12 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 3 Mar 2011 13:13:09 +0100 From: "DRAGE, Keith (Keith)" To: Brian Rosen , Bernard Aboba Date: Thu, 3 Mar 2011 13:13:07 +0100 Thread-Topic: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt Thread-Index: AcvZOuf6lrLuPy5CTqahZMLmrBj21AAYOwXg Message-ID: References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: 'ecrit Org' Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 12:12:16 -0000 PSAPs all support G.711 at the moment essentially. There are PSAPs out ther= e that will support this and only this. It is also the common denominator o= f what everything else will convert to. So while GSM uses AMR, it provides = gateways to the circuit switched world that will convert this to G.711. So I guess UEs not supported by any other infrastructure must support G.711= . They can support other codecs and not G.711 if they belong to a known inf= rastructure where that infrastructure will do the conversion. Any other codecs have to be an optional extra with no guarantee of support. Regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Brian Rosen > Sent: 03 March 2011 00:18 > To: Bernard Aboba > Cc: 'ecrit Org' > Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt >=20 > The problem is agreeing on which ones >=20 > Although you could pick AMR, what do you do about other systems? Is it > reasonable to expect all devices to implement 711 or AMR? Hardly. > How many codecs must a PSAP implement? 2 is reasonable. Is 6, 8? >=20 > This was the discussion we had before. >=20 > Brian >=20 > On Mar 2, 2011, at 6:15 PM, Bernard Aboba wrote: >=20 > > It seems to me that the requirements could be different on the PSAP sid= e > > (which could be expected to support more codecs) than on the handset. > For > > example, the requirements for the PSAP could be support of codecs A, B > AND > > C. > > > > It is already suggested in Section 9.2 that "PSAPs may support a wide > range > > of media types and codecs". This is just a "may", not even a "MAY". > Yet > > in ED-73 it is suggested that " It is desirable to include wideband > codecs > > such as AMR-WB in the offer." What is the point of doing that if there > is > > not even a recommendation that the PSAP support a wideband codec? Tha= t > > raises the question of whether it would make sense to require the PSAP > to > > implement at least one codec widely implemented on mobile devices. > > > > In terms of the handset requirements generated by whatever is decided o= n > the > > PSAP, it would make sense for the handset to have to implement at least > one > > of the MANDATORY to implement PSAP codecs. If it turns out that the > PSAP > > is only mandated to support G.711, but recommended to do others, then > you'd > > have to mandate G.711 on the handset. But if there are multiple > > mandatory-to-implement codecs on the PSAP side, then the handset should > only > > have to implement one of them. > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > Brian Rosen > > Sent: Wednesday, March 02, 2011 1:46 PM > > To: Brian Rosen > > Cc: ecrit Org > > Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt > > > > Folks, we need to decide what to do about codecs, as discussed below. > > > > I believe we have been over this, and the only thing that made sense wa= s > to > > require G.711 as the common codec. > > > > I'm still comfortable with that, and propose to leave the text as is. > > > > Brian > > > > On Feb 22, 2011, at 1:17 PM, Brian Rosen wrote: > > > >> Thank you for this review. It shows once again what a brand new set o= f > > eyes can do for document. My thanks, again, to all the GenART > reviewers > > and the system. > >> > >> See inline for my responses > >> > >> On Feb 20, 2011, at 9:34 AM, Miguel A. Garcia wrote: > >> > >>> I have been selected as the General Area Review Team (Gen-ART) > >>> reviewer for this draft. For background on Gen-ART, please see the > >>> FAQ at > >>> > >>> Please resolve these comments along with any other comments you may > > receive. > >>> > >>> Document: draft-ietf-ecrit-phonebcp-16.txt > >>> Reviewer: Miguel Garcia Review Date: > >>> 2011-02-20 IETF LC End Date: 2011-02-21 > >>> > >>> Summary: This draft is on the right track but has open issues, > described > > in the review. > >>> > >>> Major issues: None > >>> > >>> Minor issues: > >>> > >>> - I don't understand the last sentence in Section 6.2.1, which reads: > >>> > >>> Where a civic form of location is provided, all fields in the > >>> PIDF-LO [RFC4119] and [RFC5139] MUST be able to be specified. > >>> > >>> what I don't understand is the meaning of "MUST be able to be > specified". > > And I don't understand if this is a requirement for the service > provider, > > for the access network, or for the end device. Can you explain what is > the > > intention of the sentence? > >> The notion is that the location configuration protocol may generate a > PIDF > > that contains any of the elements defined in 4119/5139. All downstream > > elements must pass all fields. It applies to all the entities. Any > > suggestions for rewording to make this more clear would be appreciated. > >> > >> > >> > >>> > >>> > >>> > >>> - Section 6.5, second paragraph (req. AN-13/INT-14). I have a problem > > with the sentence that reads: > >>> > >>> If the access network supports more than one location configuration > >>> protocol, all such protocols MUST return the same location, within > >>> the constraints of the protocols deployed. > >>> > >>> I don't understand how this requirement can be achieved. Assume that > an > > access network supports several location configuration protocols, which > are > > able to determine the location by different means. Ideally all protocol= s > > should return the same location, but in practice, it will be difficult, > due > > to the different accuracy and confidence among the various protocols. > > Additionally, I believe there is nothing the access network > administrator > > can do to make sure that all location protocols will return the same > > location for a given device. > >>> > >>> Conclusion: I consider this sentence to be a hope rather than a > > requirement. Perhaps it can be rephrased saying that ".... it is > expected > > that all such protocols will return the same location ....". > >> This is a PROTOCOL issue and not a location determination issue. > >> Think of the protocol as being a transport mechanism for the location. > >> Each transport must return the same location. This is saying if you > >> have more than one protocol and more than one location determination > >> mechanism, all protocols must return the same location > >> > >> > >>> > >>> > >>> > >>> - Section 6.5., requirement AN-15/INT-17. It seems that this > requirement > > is duplicated from the second sentence of requirements AN-13/INT-14 (se= e > my > > previous comment). So, there should be only one requirement with the > same > > text, and my previous comment should apply. > >> Yes, that is a problem. I propose to delete the sentence in the prior > > section, and leave this one. > >> > >>> > >>> > >>> > >>> - Section 7, Requirement ED-51. I think this requirement also applies > to > > the Service Provider (at least the configuration part of it), so it > should > > get an SP number as well. > >> Yeah, I see the problem. It might be easier to just delete the > sentence, > > but I could add an AN requirement. Anyone else have an opinion? > >> > >>> > >>> > >>> > >>> - Section 9.2, first bullet point. The text reads: > >>> > >>> If > >>> the device cannot interpret local dial strings, the Request-URI > >>> SHOULD be a dial string URI [RFC4967] with the dialed digits. > >>> > >>> I don't understand how this requirement can be enforced. If someone > has > > not read this document and has not implemented local dial strings, how > can > > you put a requirement around dial string URIs to that person who has no= t > > implemented dial string URIs and possibly not read your draft? > >> If the device implementer didn't read the document, then it wouldn't > > conform to this document. If they did, then they should use dial > strings. > > The device generates this, it doesn't get it from other entity. I don'= t > > understand the problem. > >> > >> > >>> > >>> Perhaps you can say that "it is expected that ...", but not placing a > > formal requirement. > >>> > >>> This comment also applies to bullet point 2 in the same Section 9.2, > > regarding the To header field. > >> Same response. > >> > >>> > >>> > >>> > >>> - Section 9.2, bullet point 10. The text reads: > >>> > >>> A SDP offer SHOULD be included in the INVITE. If voice is > >>> supported the offer MUST include the G.711 codec, see > >>> Section 14. > >>> > >>> Honestly, this is an unrealistic requirement. G.711 is well known for > its > > bandwidth consumption. Due to this, as far as I know, there is no > cellular > > network in the world that support or uses G.711 either in circuit- > switched > > or VoIP. I don't think this draft is going to change the current status > quo. > > Actually, none has ever got to standardize a single codec for an > > application. Due to this, protocols like SIP/SDP support an codec > > negotiation mechanism in the format of the SDP offer answer. > >>> > >>> Other considerations: > >>> > >>> The requirement is nod needed, because in the absence of it, SDP offe= r > > answer will get to negotiate to a single codec for the emergency call. > >>> > >>> This requirement falls into the category of national or supranational > > regulation. There will be organisms which will dictate minimum or > > recommended support in terms of codecs, and this regulation will be > above > > the requirements in this document. > >>> > >>> My recommendation is to delete this requirement. > >>> > >>> I also noticed that this requirement is also repeated in Section 14, > > Requirement AD-73. The recommendation is also to delete such > requirement. > >>> > >>> Also, req ED-77 in Section 14 tries to do the same with a video codec= . > > The recommendation is still the same. > >> This has been discussed before. The goal is to be able to have any > > device, anywhere, be able to complete an emergency call. To make that > work, > > you have to have at least one common codec. It's not something a local > > regulation could fix: when you get off a plane, your softclient on your > VoIP > > service provider, must be able to complete an emergency call where you > are. > >> > >> The alternative is to have the document have a requirement on PSAPs to > > implement a relatively long list of codecs, and then have each device > > implement at least one of those. That would be quite difficult to make > such > > a list, and even if you did, some service would have a problem. > >> > >> > >>> > >>> > >>> > >>> - Section 12, the text reads: > >>> > >>> Dropping of the old call MUST only > >>> occur if the user is attempting to hang up > >>> > >>> But the previous sentence says: > >>> > >>> If in the interval, an incoming call is received from the domain of > >>> the PSAP, the device MUST drop the old call and alert for the (new) > >>> incoming call. > >>> > >>> So, we have two scenarios for dropping an old call: > >>> 1) the user is attempting to hung up > >>> 2) an incoming call is received from the PSAP > >>> > >>> Therefore, I disagree with the "MUST only occur" of the first > sentence. > > Please rephrase the text to avoid contradictions. > >> Is see your point. In SIP, hang up requires the complete BYE > transaction, > > and you can be in the middle of that transaction when the new call > arrives. > > The problem is the word "drop". What we are attempting to say is that > even > > though you are in the middle of that transaction, you have to abandon > it, > > and accept the new call. So I need a better word for "drop". > >> > >>> > >>> > >>> > >>> > >>> > >>> Nits: > >>> > >>> - Expands acronyms at first occurrence. This includes: PSAP, PIDF, > > PIDF-LO, HELD, LCP, and LoST. > >> the terminology sections says: > >> This document uses terms from [RFC3261], [RFC5012] and > > [I-D.ietf-ecrit-framework]. > >> > >> I thought that would be enough. I can expand the acronyms here. > >> > >>> > >>> - Section 9.2, first bullet point > >>> s/tree, If/tree. If > >>> > >>> - Section 9.2, second bullet point > >>> s/not find a a Router/not find a Router > >>> > >>> - Section 11 > >>> s/and the Referred-by: header/and the Referred-by header > >> Thanks, I'll fix these > >> > >> > >>> > >>> > >>> BR, > >>> > >>> Miguel > >>> > >>> > >>> > >>> -- > >>> Miguel A. Garcia > >>> +34-91-339-3608 > >>> Ericsson Spain > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From gunnar.hellstrom@omnitor.se Thu Mar 3 04:37:51 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B951E28C0DE for ; Thu, 3 Mar 2011 04:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZISP8aIDNgq for ; Thu, 3 Mar 2011 04:37:50 -0800 (PST) Received: from vsp-outgoing1.binero.net (vsp-outgoing1.binero.net [193.17.218.160]) by core3.amsl.com (Postfix) with SMTP id 60AFB3A69CF for ; Thu, 3 Mar 2011 04:37:49 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.39.229]) by vsp-outgoing1.binero.net (Halon Mail Gateway) with ESMTP for ; Thu, 3 Mar 2011 13:38:47 +0100 (CET) Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-07-01.atm.binero.net (Postfix) with ESMTPA id BF3D03A1E9 for ; Thu, 3 Mar 2011 13:38:46 +0100 (CET) Message-ID: <4D6F8BDC.7020409@omnitor.se> Date: Thu, 03 Mar 2011 13:38:52 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: ecrit@ietf.org References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 12:37:51 -0000 Yes, you can do the conversion in the infrastructure, but the requirement is marked by ED-73 in the draft. ED means "end devices and applications (requirements prefaced by "ED-")" So, in order to allow the infrastructure to do the conversion, the classification of this requirement could be changed to ED/SP. /Gunnar DRAGE, Keith (Keith) skrev 2011-03-03 13:13: > PSAPs all support G.711 at the moment essentially. There are PSAPs out there that will support this and only this. It is also the common denominator of what everything else will convert to. So while GSM uses AMR, it provides gateways to the circuit switched world that will convert this to G.711. > > So I guess UEs not supported by any other infrastructure must support G.711. They can support other codecs and not G.711 if they belong to a known infrastructure where that infrastructure will do the conversion. > > Any other codecs have to be an optional extra with no guarantee of support. > > Regards > > Keith > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> Brian Rosen >> Sent: 03 March 2011 00:18 >> To: Bernard Aboba >> Cc: 'ecrit Org' >> Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt >> >> The problem is agreeing on which ones >> >> Although you could pick AMR, what do you do about other systems? Is it >> reasonable to expect all devices to implement 711 or AMR? Hardly. >> How many codecs must a PSAP implement? 2 is reasonable. Is 6, 8? >> >> This was the discussion we had before. >> >> Brian >> >> On Mar 2, 2011, at 6:15 PM, Bernard Aboba wrote: >> >>> It seems to me that the requirements could be different on the PSAP side >>> (which could be expected to support more codecs) than on the handset. >> For >>> example, the requirements for the PSAP could be support of codecs A, B >> AND >>> C. >>> >>> It is already suggested in Section 9.2 that "PSAPs may support a wide >> range >>> of media types and codecs". This is just a "may", not even a "MAY". >> Yet >>> in ED-73 it is suggested that " It is desirable to include wideband >> codecs >>> such as AMR-WB in the offer." What is the point of doing that if there >> is >>> not even a recommendation that the PSAP support a wideband codec? That >>> raises the question of whether it would make sense to require the PSAP >> to >>> implement at least one codec widely implemented on mobile devices. >>> >>> In terms of the handset requirements generated by whatever is decided on >> the >>> PSAP, it would make sense for the handset to have to implement at least >> one >>> of the MANDATORY to implement PSAP codecs. If it turns out that the >> PSAP >>> is only mandated to support G.711, but recommended to do others, then >> you'd >>> have to mandate G.711 on the handset. But if there are multiple >>> mandatory-to-implement codecs on the PSAP side, then the handset should >> only >>> have to implement one of them. >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of >>> Brian Rosen >>> Sent: Wednesday, March 02, 2011 1:46 PM >>> To: Brian Rosen >>> Cc: ecrit Org >>> Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt >>> >>> Folks, we need to decide what to do about codecs, as discussed below. >>> >>> I believe we have been over this, and the only thing that made sense was >> to >>> require G.711 as the common codec. >>> >>> I'm still comfortable with that, and propose to leave the text as is. >>> >>> Brian >>> >>> On Feb 22, 2011, at 1:17 PM, Brian Rosen wrote: >>> >>>> Thank you for this review. It shows once again what a brand new set of >>> eyes can do for document. My thanks, again, to all the GenART >> reviewers >>> and the system. >>>> See inline for my responses >>>> >>>> On Feb 20, 2011, at 9:34 AM, Miguel A. Garcia wrote: >>>> >>>>> I have been selected as the General Area Review Team (Gen-ART) >>>>> reviewer for this draft. For background on Gen-ART, please see the >>>>> FAQ at >>>>> >>>>> Please resolve these comments along with any other comments you may >>> receive. >>>>> Document: draft-ietf-ecrit-phonebcp-16.txt >>>>> Reviewer: Miguel Garcia Review Date: >>>>> 2011-02-20 IETF LC End Date: 2011-02-21 >>>>> >>>>> Summary: This draft is on the right track but has open issues, >> described >>> in the review. >>>>> Major issues: None >>>>> >>>>> Minor issues: >>>>> >>>>> - I don't understand the last sentence in Section 6.2.1, which reads: >>>>> >>>>> Where a civic form of location is provided, all fields in the >>>>> PIDF-LO [RFC4119] and [RFC5139] MUST be able to be specified. >>>>> >>>>> what I don't understand is the meaning of "MUST be able to be >> specified". >>> And I don't understand if this is a requirement for the service >> provider, >>> for the access network, or for the end device. Can you explain what is >> the >>> intention of the sentence? >>>> The notion is that the location configuration protocol may generate a >> PIDF >>> that contains any of the elements defined in 4119/5139. All downstream >>> elements must pass all fields. It applies to all the entities. Any >>> suggestions for rewording to make this more clear would be appreciated. >>>> >>>> >>>>> >>>>> >>>>> - Section 6.5, second paragraph (req. AN-13/INT-14). I have a problem >>> with the sentence that reads: >>>>> If the access network supports more than one location configuration >>>>> protocol, all such protocols MUST return the same location, within >>>>> the constraints of the protocols deployed. >>>>> >>>>> I don't understand how this requirement can be achieved. Assume that >> an >>> access network supports several location configuration protocols, which >> are >>> able to determine the location by different means. Ideally all protocols >>> should return the same location, but in practice, it will be difficult, >> due >>> to the different accuracy and confidence among the various protocols. >>> Additionally, I believe there is nothing the access network >> administrator >>> can do to make sure that all location protocols will return the same >>> location for a given device. >>>>> Conclusion: I consider this sentence to be a hope rather than a >>> requirement. Perhaps it can be rephrased saying that ".... it is >> expected >>> that all such protocols will return the same location ....". >>>> This is a PROTOCOL issue and not a location determination issue. >>>> Think of the protocol as being a transport mechanism for the location. >>>> Each transport must return the same location. This is saying if you >>>> have more than one protocol and more than one location determination >>>> mechanism, all protocols must return the same location >>>> >>>> >>>>> >>>>> >>>>> - Section 6.5., requirement AN-15/INT-17. It seems that this >> requirement >>> is duplicated from the second sentence of requirements AN-13/INT-14 (see >> my >>> previous comment). So, there should be only one requirement with the >> same >>> text, and my previous comment should apply. >>>> Yes, that is a problem. I propose to delete the sentence in the prior >>> section, and leave this one. >>>>> >>>>> >>>>> - Section 7, Requirement ED-51. I think this requirement also applies >> to >>> the Service Provider (at least the configuration part of it), so it >> should >>> get an SP number as well. >>>> Yeah, I see the problem. It might be easier to just delete the >> sentence, >>> but I could add an AN requirement. Anyone else have an opinion? >>>>> >>>>> >>>>> - Section 9.2, first bullet point. The text reads: >>>>> >>>>> If >>>>> the device cannot interpret local dial strings, the Request-URI >>>>> SHOULD be a dial string URI [RFC4967] with the dialed digits. >>>>> >>>>> I don't understand how this requirement can be enforced. If someone >> has >>> not read this document and has not implemented local dial strings, how >> can >>> you put a requirement around dial string URIs to that person who has not >>> implemented dial string URIs and possibly not read your draft? >>>> If the device implementer didn't read the document, then it wouldn't >>> conform to this document. If they did, then they should use dial >> strings. >>> The device generates this, it doesn't get it from other entity. I don't >>> understand the problem. >>>> >>>>> Perhaps you can say that "it is expected that ...", but not placing a >>> formal requirement. >>>>> This comment also applies to bullet point 2 in the same Section 9.2, >>> regarding the To header field. >>>> Same response. >>>> >>>>> >>>>> >>>>> - Section 9.2, bullet point 10. The text reads: >>>>> >>>>> A SDP offer SHOULD be included in the INVITE. If voice is >>>>> supported the offer MUST include the G.711 codec, see >>>>> Section 14. >>>>> >>>>> Honestly, this is an unrealistic requirement. G.711 is well known for >> its >>> bandwidth consumption. Due to this, as far as I know, there is no >> cellular >>> network in the world that support or uses G.711 either in circuit- >> switched >>> or VoIP. I don't think this draft is going to change the current status >> quo. >>> Actually, none has ever got to standardize a single codec for an >>> application. Due to this, protocols like SIP/SDP support an codec >>> negotiation mechanism in the format of the SDP offer answer. >>>>> Other considerations: >>>>> >>>>> The requirement is nod needed, because in the absence of it, SDP offer >>> answer will get to negotiate to a single codec for the emergency call. >>>>> This requirement falls into the category of national or supranational >>> regulation. There will be organisms which will dictate minimum or >>> recommended support in terms of codecs, and this regulation will be >> above >>> the requirements in this document. >>>>> My recommendation is to delete this requirement. >>>>> >>>>> I also noticed that this requirement is also repeated in Section 14, >>> Requirement AD-73. The recommendation is also to delete such >> requirement. >>>>> Also, req ED-77 in Section 14 tries to do the same with a video codec. >>> The recommendation is still the same. >>>> This has been discussed before. The goal is to be able to have any >>> device, anywhere, be able to complete an emergency call. To make that >> work, >>> you have to have at least one common codec. It's not something a local >>> regulation could fix: when you get off a plane, your softclient on your >> VoIP >>> service provider, must be able to complete an emergency call where you >> are. >>>> The alternative is to have the document have a requirement on PSAPs to >>> implement a relatively long list of codecs, and then have each device >>> implement at least one of those. That would be quite difficult to make >> such >>> a list, and even if you did, some service would have a problem. >>>> >>>>> >>>>> >>>>> - Section 12, the text reads: >>>>> >>>>> Dropping of the old call MUST only >>>>> occur if the user is attempting to hang up >>>>> >>>>> But the previous sentence says: >>>>> >>>>> If in the interval, an incoming call is received from the domain of >>>>> the PSAP, the device MUST drop the old call and alert for the (new) >>>>> incoming call. >>>>> >>>>> So, we have two scenarios for dropping an old call: >>>>> 1) the user is attempting to hung up >>>>> 2) an incoming call is received from the PSAP >>>>> >>>>> Therefore, I disagree with the "MUST only occur" of the first >> sentence. >>> Please rephrase the text to avoid contradictions. >>>> Is see your point. In SIP, hang up requires the complete BYE >> transaction, >>> and you can be in the middle of that transaction when the new call >> arrives. >>> The problem is the word "drop". What we are attempting to say is that >> even >>> though you are in the middle of that transaction, you have to abandon >> it, >>> and accept the new call. So I need a better word for "drop". >>>>> >>>>> >>>>> >>>>> >>>>> Nits: >>>>> >>>>> - Expands acronyms at first occurrence. This includes: PSAP, PIDF, >>> PIDF-LO, HELD, LCP, and LoST. >>>> the terminology sections says: >>>> This document uses terms from [RFC3261], [RFC5012] and >>> [I-D.ietf-ecrit-framework]. >>>> I thought that would be enough. I can expand the acronyms here. >>>> >>>>> - Section 9.2, first bullet point >>>>> s/tree, If/tree. If >>>>> >>>>> - Section 9.2, second bullet point >>>>> s/not find a a Router/not find a Router >>>>> >>>>> - Section 11 >>>>> s/and the Referred-by: header/and the Referred-by header >>>> Thanks, I'll fix these >>>> >>>> >>>>> >>>>> BR, >>>>> >>>>> Miguel >>>>> >>>>> >>>>> >>>>> -- >>>>> Miguel A. Garcia >>>>> +34-91-339-3608 >>>>> Ericsson Spain >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From gunnar.hellstrom@omnitor.se Thu Mar 3 04:37:55 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A2AC28C0CF for ; Thu, 3 Mar 2011 04:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0S8+Ycgwq+5e for ; Thu, 3 Mar 2011 04:37:54 -0800 (PST) Received: from vsp-outgoing1.binero.net (vsp-outgoing1.binero.net [193.17.218.160]) by core3.amsl.com (Postfix) with SMTP id 00F8D28C0E1 for ; Thu, 3 Mar 2011 04:37:53 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.39.229]) by vsp-outgoing1.binero.net (Halon Mail Gateway) with ESMTP for ; Thu, 3 Mar 2011 13:38:54 +0100 (CET) Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-07-01.atm.binero.net (Postfix) with ESMTPA id 2EFD03A20B for ; Thu, 3 Mar 2011 13:38:54 +0100 (CET) Message-ID: <4D6F8BE4.5050604@omnitor.se> Date: Thu, 03 Mar 2011 13:39:00 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: ecrit@ietf.org References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 12:37:55 -0000 Yes, you can do the conversion in the infrastructure, but the requirement is marked by ED-73 in the draft. ED means "end devices and applications (requirements prefaced by "ED-")" So, in order to allow the infrastructure to do the conversion, the classification of this requirement could be changed to ED/SP. /Gunnar DRAGE, Keith (Keith) skrev 2011-03-03 13:13: > PSAPs all support G.711 at the moment essentially. There are PSAPs out there that will support this and only this. It is also the common denominator of what everything else will convert to. So while GSM uses AMR, it provides gateways to the circuit switched world that will convert this to G.711. > > So I guess UEs not supported by any other infrastructure must support G.711. They can support other codecs and not G.711 if they belong to a known infrastructure where that infrastructure will do the conversion. > > Any other codecs have to be an optional extra with no guarantee of support. > > Regards > > Keith > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> Brian Rosen >> Sent: 03 March 2011 00:18 >> To: Bernard Aboba >> Cc: 'ecrit Org' >> Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt >> >> The problem is agreeing on which ones >> >> Although you could pick AMR, what do you do about other systems? Is it >> reasonable to expect all devices to implement 711 or AMR? Hardly. >> How many codecs must a PSAP implement? 2 is reasonable. Is 6, 8? >> >> This was the discussion we had before. >> >> Brian >> >> On Mar 2, 2011, at 6:15 PM, Bernard Aboba wrote: >> >>> It seems to me that the requirements could be different on the PSAP side >>> (which could be expected to support more codecs) than on the handset. >> For >>> example, the requirements for the PSAP could be support of codecs A, B >> AND >>> C. >>> >>> It is already suggested in Section 9.2 that "PSAPs may support a wide >> range >>> of media types and codecs". This is just a "may", not even a "MAY". >> Yet >>> in ED-73 it is suggested that " It is desirable to include wideband >> codecs >>> such as AMR-WB in the offer." What is the point of doing that if there >> is >>> not even a recommendation that the PSAP support a wideband codec? That >>> raises the question of whether it would make sense to require the PSAP >> to >>> implement at least one codec widely implemented on mobile devices. >>> >>> In terms of the handset requirements generated by whatever is decided on >> the >>> PSAP, it would make sense for the handset to have to implement at least >> one >>> of the MANDATORY to implement PSAP codecs. If it turns out that the >> PSAP >>> is only mandated to support G.711, but recommended to do others, then >> you'd >>> have to mandate G.711 on the handset. But if there are multiple >>> mandatory-to-implement codecs on the PSAP side, then the handset should >> only >>> have to implement one of them. >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of >>> Brian Rosen >>> Sent: Wednesday, March 02, 2011 1:46 PM >>> To: Brian Rosen >>> Cc: ecrit Org >>> Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt >>> >>> Folks, we need to decide what to do about codecs, as discussed below. >>> >>> I believe we have been over this, and the only thing that made sense was >> to >>> require G.711 as the common codec. >>> >>> I'm still comfortable with that, and propose to leave the text as is. >>> >>> Brian >>> >>> On Feb 22, 2011, at 1:17 PM, Brian Rosen wrote: >>> >>>> Thank you for this review. It shows once again what a brand new set of >>> eyes can do for document. My thanks, again, to all the GenART >> reviewers >>> and the system. >>>> See inline for my responses >>>> >>>> On Feb 20, 2011, at 9:34 AM, Miguel A. Garcia wrote: >>>> >>>>> I have been selected as the General Area Review Team (Gen-ART) >>>>> reviewer for this draft. For background on Gen-ART, please see the >>>>> FAQ at >>>>> >>>>> Please resolve these comments along with any other comments you may >>> receive. >>>>> Document: draft-ietf-ecrit-phonebcp-16.txt >>>>> Reviewer: Miguel Garcia Review Date: >>>>> 2011-02-20 IETF LC End Date: 2011-02-21 >>>>> >>>>> Summary: This draft is on the right track but has open issues, >> described >>> in the review. >>>>> Major issues: None >>>>> >>>>> Minor issues: >>>>> >>>>> - I don't understand the last sentence in Section 6.2.1, which reads: >>>>> >>>>> Where a civic form of location is provided, all fields in the >>>>> PIDF-LO [RFC4119] and [RFC5139] MUST be able to be specified. >>>>> >>>>> what I don't understand is the meaning of "MUST be able to be >> specified". >>> And I don't understand if this is a requirement for the service >> provider, >>> for the access network, or for the end device. Can you explain what is >> the >>> intention of the sentence? >>>> The notion is that the location configuration protocol may generate a >> PIDF >>> that contains any of the elements defined in 4119/5139. All downstream >>> elements must pass all fields. It applies to all the entities. Any >>> suggestions for rewording to make this more clear would be appreciated. >>>> >>>> >>>>> >>>>> >>>>> - Section 6.5, second paragraph (req. AN-13/INT-14). I have a problem >>> with the sentence that reads: >>>>> If the access network supports more than one location configuration >>>>> protocol, all such protocols MUST return the same location, within >>>>> the constraints of the protocols deployed. >>>>> >>>>> I don't understand how this requirement can be achieved. Assume that >> an >>> access network supports several location configuration protocols, which >> are >>> able to determine the location by different means. Ideally all protocols >>> should return the same location, but in practice, it will be difficult, >> due >>> to the different accuracy and confidence among the various protocols. >>> Additionally, I believe there is nothing the access network >> administrator >>> can do to make sure that all location protocols will return the same >>> location for a given device. >>>>> Conclusion: I consider this sentence to be a hope rather than a >>> requirement. Perhaps it can be rephrased saying that ".... it is >> expected >>> that all such protocols will return the same location ....". >>>> This is a PROTOCOL issue and not a location determination issue. >>>> Think of the protocol as being a transport mechanism for the location. >>>> Each transport must return the same location. This is saying if you >>>> have more than one protocol and more than one location determination >>>> mechanism, all protocols must return the same location >>>> >>>> >>>>> >>>>> >>>>> - Section 6.5., requirement AN-15/INT-17. It seems that this >> requirement >>> is duplicated from the second sentence of requirements AN-13/INT-14 (see >> my >>> previous comment). So, there should be only one requirement with the >> same >>> text, and my previous comment should apply. >>>> Yes, that is a problem. I propose to delete the sentence in the prior >>> section, and leave this one. >>>>> >>>>> >>>>> - Section 7, Requirement ED-51. I think this requirement also applies >> to >>> the Service Provider (at least the configuration part of it), so it >> should >>> get an SP number as well. >>>> Yeah, I see the problem. It might be easier to just delete the >> sentence, >>> but I could add an AN requirement. Anyone else have an opinion? >>>>> >>>>> >>>>> - Section 9.2, first bullet point. The text reads: >>>>> >>>>> If >>>>> the device cannot interpret local dial strings, the Request-URI >>>>> SHOULD be a dial string URI [RFC4967] with the dialed digits. >>>>> >>>>> I don't understand how this requirement can be enforced. If someone >> has >>> not read this document and has not implemented local dial strings, how >> can >>> you put a requirement around dial string URIs to that person who has not >>> implemented dial string URIs and possibly not read your draft? >>>> If the device implementer didn't read the document, then it wouldn't >>> conform to this document. If they did, then they should use dial >> strings. >>> The device generates this, it doesn't get it from other entity. I don't >>> understand the problem. >>>> >>>>> Perhaps you can say that "it is expected that ...", but not placing a >>> formal requirement. >>>>> This comment also applies to bullet point 2 in the same Section 9.2, >>> regarding the To header field. >>>> Same response. >>>> >>>>> >>>>> >>>>> - Section 9.2, bullet point 10. The text reads: >>>>> >>>>> A SDP offer SHOULD be included in the INVITE. If voice is >>>>> supported the offer MUST include the G.711 codec, see >>>>> Section 14. >>>>> >>>>> Honestly, this is an unrealistic requirement. G.711 is well known for >> its >>> bandwidth consumption. Due to this, as far as I know, there is no >> cellular >>> network in the world that support or uses G.711 either in circuit- >> switched >>> or VoIP. I don't think this draft is going to change the current status >> quo. >>> Actually, none has ever got to standardize a single codec for an >>> application. Due to this, protocols like SIP/SDP support an codec >>> negotiation mechanism in the format of the SDP offer answer. >>>>> Other considerations: >>>>> >>>>> The requirement is nod needed, because in the absence of it, SDP offer >>> answer will get to negotiate to a single codec for the emergency call. >>>>> This requirement falls into the category of national or supranational >>> regulation. There will be organisms which will dictate minimum or >>> recommended support in terms of codecs, and this regulation will be >> above >>> the requirements in this document. >>>>> My recommendation is to delete this requirement. >>>>> >>>>> I also noticed that this requirement is also repeated in Section 14, >>> Requirement AD-73. The recommendation is also to delete such >> requirement. >>>>> Also, req ED-77 in Section 14 tries to do the same with a video codec. >>> The recommendation is still the same. >>>> This has been discussed before. The goal is to be able to have any >>> device, anywhere, be able to complete an emergency call. To make that >> work, >>> you have to have at least one common codec. It's not something a local >>> regulation could fix: when you get off a plane, your softclient on your >> VoIP >>> service provider, must be able to complete an emergency call where you >> are. >>>> The alternative is to have the document have a requirement on PSAPs to >>> implement a relatively long list of codecs, and then have each device >>> implement at least one of those. That would be quite difficult to make >> such >>> a list, and even if you did, some service would have a problem. >>>> >>>>> >>>>> >>>>> - Section 12, the text reads: >>>>> >>>>> Dropping of the old call MUST only >>>>> occur if the user is attempting to hang up >>>>> >>>>> But the previous sentence says: >>>>> >>>>> If in the interval, an incoming call is received from the domain of >>>>> the PSAP, the device MUST drop the old call and alert for the (new) >>>>> incoming call. >>>>> >>>>> So, we have two scenarios for dropping an old call: >>>>> 1) the user is attempting to hung up >>>>> 2) an incoming call is received from the PSAP >>>>> >>>>> Therefore, I disagree with the "MUST only occur" of the first >> sentence. >>> Please rephrase the text to avoid contradictions. >>>> Is see your point. In SIP, hang up requires the complete BYE >> transaction, >>> and you can be in the middle of that transaction when the new call >> arrives. >>> The problem is the word "drop". What we are attempting to say is that >> even >>> though you are in the middle of that transaction, you have to abandon >> it, >>> and accept the new call. So I need a better word for "drop". >>>>> >>>>> >>>>> >>>>> >>>>> Nits: >>>>> >>>>> - Expands acronyms at first occurrence. This includes: PSAP, PIDF, >>> PIDF-LO, HELD, LCP, and LoST. >>>> the terminology sections says: >>>> This document uses terms from [RFC3261], [RFC5012] and >>> [I-D.ietf-ecrit-framework]. >>>> I thought that would be enough. I can expand the acronyms here. >>>> >>>>> - Section 9.2, first bullet point >>>>> s/tree, If/tree. If >>>>> >>>>> - Section 9.2, second bullet point >>>>> s/not find a a Router/not find a Router >>>>> >>>>> - Section 11 >>>>> s/and the Referred-by: header/and the Referred-by header >>>> Thanks, I'll fix these >>>> >>>> >>>>> >>>>> BR, >>>>> >>>>> Miguel >>>>> >>>>> >>>>> >>>>> -- >>>>> Miguel A. Garcia >>>>> +34-91-339-3608 >>>>> Ericsson Spain >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hgs@cs.columbia.edu Thu Mar 3 05:41:57 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B319F3A67DB for ; Thu, 3 Mar 2011 05:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLHBX0q0Q7d7 for ; Thu, 3 Mar 2011 05:41:57 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id D49B03A67BD for ; Thu, 3 Mar 2011 05:41:56 -0800 (PST) Received: from [192.168.1.15] (pool-74-96-51-195.washdc.east.verizon.net [74.96.51.195]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p23DgxuG025942 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 3 Mar 2011 08:42:59 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: Date: Thu, 3 Mar 2011 08:42:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <26E805AD-4D40-4C7E-9C07-56959336B858@cs.columbia.edu> References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1082) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: 'ecrit Org' Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 13:41:57 -0000 Since these types of documents are often used for RFPs, national = regulations and other requirement documents, would it make sense to = create a list of "recommended" codecs? While it does not ensure that = both sides can negotiate anything other than G.711, it greatly increases = the likelihood. Thus, we could say something like "It is RECOMMENDED that the PSAP supports AMR-WB, G.722, G.729." I suspect that identifying this larger set wouldn't be that hard. =46rom = a quick look at phone specs, lists like G.722, G.723, G.726, G.729 a/b, GSM, G.711 (snom) G.722, G.723, G.726, G.729 a/b, GSM, iLBC, G.711 (Grandstream) G.722, G.729 a/b, G.711 u/a law (Polycom) G.722, G.726, G.729 a/b, G.711 u/a law (Cisco) are common. There's a pattern here... Thus, by looking at the support in commodity PBX phones today, we should = be able to come up with a reasonable set that is likely going to be = easily commercially available. This would also set a process in motion - = a few years later, we might then be able to promote a non-G.711 codec to = a required status. On Mar 3, 2011, at 7:13 AM, DRAGE, Keith (Keith) wrote: > PSAPs all support G.711 at the moment essentially. There are PSAPs out = there that will support this and only this. It is also the common = denominator of what everything else will convert to. So while GSM uses = AMR, it provides gateways to the circuit switched world that will = convert this to G.711. >=20 > So I guess UEs not supported by any other infrastructure must support = G.711. They can support other codecs and not G.711 if they belong to a = known infrastructure where that infrastructure will do the conversion. >=20 > Any other codecs have to be an optional extra with no guarantee of = support. >=20 > Regards >=20 > Keith From mlinsner@cisco.com Thu Mar 3 05:57:27 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1B733A67F9 for ; Thu, 3 Mar 2011 05:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqFxqvx9Wj3s for ; Thu, 3 Mar 2011 05:57:26 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E7D773A67F4 for ; Thu, 3 Mar 2011 05:57:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=14658; q=dns/txt; s=iport; t=1299160713; x=1300370313; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=9LTCmxdDj9axuudUVJEOeQtWMjF72OR6MdLZ5AQ3wFk=; b=fPhLIHC4cVL+a9CTbmBJtuNsthGCWKEk8wTjc+O8r0BJuWaaT1pJQJ4F 1LSFqxIgmvSE0R4AyA5xQTOpnP4dbXojWExLi0sB2sW9+m2MM8YedRvb+ G5N33lHZ+ZwFl+arYbylTmL+LbQYr8MPV0HAWnP7lq2EjyTY1f4Sfnpql 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkAAHItb02rRN+K/2dsb2JhbACYCRUOjjl0oxyKE5IFhWEEhRqHEoNCgxg X-IronPort-AV: E=Sophos;i="4.62,258,1297036800"; d="scan'208";a="268817082" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 03 Mar 2011 13:58:33 +0000 Received: from [10.116.195.119] (rtp-mlinsner-8716.cisco.com [10.116.195.119]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p23DwUff009139; Thu, 3 Mar 2011 13:58:32 GMT User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Thu, 03 Mar 2011 08:58:28 -0500 From: Marc Linsner To: Message-ID: Thread-Topic: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "DRAGE, Keith \(Keith\)" Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 13:57:27 -0000 I agree with the sentiment of Keith's message, G.711 should be the only MUST support codec. Since 80%+ of the PSAPs (in the US) are still analog, I wouldn't use the justification that all PSAPs essentially support G.711. It is reasonable to justify G.711 by stating that it's the most common codec used in 'local' wireline telephony networks, where the PSAPs currently live. -Marc- -----Original Message----- From: "DRAGE, Keith (Keith)" Date: Thu, 3 Mar 2011 13:13:07 +0100 To: Brian Rosen , Bernard Aboba Cc: 'ecrit Org' Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt >PSAPs all support G.711 at the moment essentially. There are PSAPs out >there that will support this and only this. It is also the common >denominator of what everything else will convert to. So while GSM uses >AMR, it provides gateways to the circuit switched world that will convert >this to G.711. > >So I guess UEs not supported by any other infrastructure must support >G.711. They can support other codecs and not G.711 if they belong to a >known infrastructure where that infrastructure will do the conversion. > >Any other codecs have to be an optional extra with no guarantee of >support. > >Regards > >Keith > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>Of >> Brian Rosen >> Sent: 03 March 2011 00:18 >> To: Bernard Aboba >> Cc: 'ecrit Org' >> Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt >> >> The problem is agreeing on which ones >> >> Although you could pick AMR, what do you do about other systems? Is it >> reasonable to expect all devices to implement 711 or AMR? Hardly. >> How many codecs must a PSAP implement? 2 is reasonable. Is 6, 8? >> >> This was the discussion we had before. >> >> Brian >> >> On Mar 2, 2011, at 6:15 PM, Bernard Aboba wrote: >> >> > It seems to me that the requirements could be different on the PSAP >>side >> > (which could be expected to support more codecs) than on the handset. >> For >> > example, the requirements for the PSAP could be support of codecs A, B >> AND >> > C. >> > >> > It is already suggested in Section 9.2 that "PSAPs may support a wide >> range >> > of media types and codecs". This is just a "may", not even a "MAY". >> Yet >> > in ED-73 it is suggested that " It is desirable to include wideband >> codecs >> > such as AMR-WB in the offer." What is the point of doing that if >>there >> is >> > not even a recommendation that the PSAP support a wideband codec? >>That >> > raises the question of whether it would make sense to require the PSAP >> to >> > implement at least one codec widely implemented on mobile devices. >> > >> > In terms of the handset requirements generated by whatever is decided >>on >> the >> > PSAP, it would make sense for the handset to have to implement at >>least >> one >> > of the MANDATORY to implement PSAP codecs. If it turns out that the >> PSAP >> > is only mandated to support G.711, but recommended to do others, then >> you'd >> > have to mandate G.711 on the handset. But if there are multiple >> > mandatory-to-implement codecs on the PSAP side, then the handset >>should >> only >> > have to implement one of them. >> > >> > -----Original Message----- >> > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of >> > Brian Rosen >> > Sent: Wednesday, March 02, 2011 1:46 PM >> > To: Brian Rosen >> > Cc: ecrit Org >> > Subject: Re: [Ecrit] Gen-ART review of >>draft-ietf-ecrit-phonebcp-16.txt >> > >> > Folks, we need to decide what to do about codecs, as discussed below. >> > >> > I believe we have been over this, and the only thing that made sense >>was >> to >> > require G.711 as the common codec. >> > >> > I'm still comfortable with that, and propose to leave the text as is. >> > >> > Brian >> > >> > On Feb 22, 2011, at 1:17 PM, Brian Rosen wrote: >> > >> >> Thank you for this review. It shows once again what a brand new set >>of >> > eyes can do for document. My thanks, again, to all the GenART >> reviewers >> > and the system. >> >> >> >> See inline for my responses >> >> >> >> On Feb 20, 2011, at 9:34 AM, Miguel A. Garcia wrote: >> >> >> >>> I have been selected as the General Area Review Team (Gen-ART) >> >>> reviewer for this draft. For background on Gen-ART, please see the >> >>> FAQ at >> >>> >> >>> Please resolve these comments along with any other comments you may >> > receive. >> >>> >> >>> Document: draft-ietf-ecrit-phonebcp-16.txt >> >>> Reviewer: Miguel Garcia Review Date: >> >>> 2011-02-20 IETF LC End Date: 2011-02-21 >> >>> >> >>> Summary: This draft is on the right track but has open issues, >> described >> > in the review. >> >>> >> >>> Major issues: None >> >>> >> >>> Minor issues: >> >>> >> >>> - I don't understand the last sentence in Section 6.2.1, which >>reads: >> >>> >> >>> Where a civic form of location is provided, all fields in the >> >>> PIDF-LO [RFC4119] and [RFC5139] MUST be able to be specified. >> >>> >> >>> what I don't understand is the meaning of "MUST be able to be >> specified". >> > And I don't understand if this is a requirement for the service >> provider, >> > for the access network, or for the end device. Can you explain what is >> the >> > intention of the sentence? >> >> The notion is that the location configuration protocol may generate a >> PIDF >> > that contains any of the elements defined in 4119/5139. All >>downstream >> > elements must pass all fields. It applies to all the entities. Any >> > suggestions for rewording to make this more clear would be >>appreciated. >> >> >> >> >> >> >> >>> >> >>> >> >>> >> >>> - Section 6.5, second paragraph (req. AN-13/INT-14). I have a >>problem >> > with the sentence that reads: >> >>> >> >>> If the access network supports more than one location configuration >> >>> protocol, all such protocols MUST return the same location, within >> >>> the constraints of the protocols deployed. >> >>> >> >>> I don't understand how this requirement can be achieved. Assume that >> an >> > access network supports several location configuration protocols, >>which >> are >> > able to determine the location by different means. Ideally all >>protocols >> > should return the same location, but in practice, it will be >>difficult, >> due >> > to the different accuracy and confidence among the various protocols. >> > Additionally, I believe there is nothing the access network >> administrator >> > can do to make sure that all location protocols will return the same >> > location for a given device. >> >>> >> >>> Conclusion: I consider this sentence to be a hope rather than a >> > requirement. Perhaps it can be rephrased saying that ".... it is >> expected >> > that all such protocols will return the same location ....". >> >> This is a PROTOCOL issue and not a location determination issue. >> >> Think of the protocol as being a transport mechanism for the >>location. >> >> Each transport must return the same location. This is saying if you >> >> have more than one protocol and more than one location determination >> >> mechanism, all protocols must return the same location >> >> >> >> >> >>> >> >>> >> >>> >> >>> - Section 6.5., requirement AN-15/INT-17. It seems that this >> requirement >> > is duplicated from the second sentence of requirements AN-13/INT-14 >>(see >> my >> > previous comment). So, there should be only one requirement with the >> same >> > text, and my previous comment should apply. >> >> Yes, that is a problem. I propose to delete the sentence in the >>prior >> > section, and leave this one. >> >> >> >>> >> >>> >> >>> >> >>> - Section 7, Requirement ED-51. I think this requirement also >>applies >> to >> > the Service Provider (at least the configuration part of it), so it >> should >> > get an SP number as well. >> >> Yeah, I see the problem. It might be easier to just delete the >> sentence, >> > but I could add an AN requirement. Anyone else have an opinion? >> >> >> >>> >> >>> >> >>> >> >>> - Section 9.2, first bullet point. The text reads: >> >>> >> >>> If >> >>> the device cannot interpret local dial strings, the Request-URI >> >>> SHOULD be a dial string URI [RFC4967] with the dialed digits. >> >>> >> >>> I don't understand how this requirement can be enforced. If someone >> has >> > not read this document and has not implemented local dial strings, how >> can >> > you put a requirement around dial string URIs to that person who has >>not >> > implemented dial string URIs and possibly not read your draft? >> >> If the device implementer didn't read the document, then it wouldn't >> > conform to this document. If they did, then they should use dial >> strings. >> > The device generates this, it doesn't get it from other entity. I >>don't >> > understand the problem. >> >> >> >> >> >>> >> >>> Perhaps you can say that "it is expected that ...", but not placing >>a >> > formal requirement. >> >>> >> >>> This comment also applies to bullet point 2 in the same Section 9.2, >> > regarding the To header field. >> >> Same response. >> >> >> >>> >> >>> >> >>> >> >>> - Section 9.2, bullet point 10. The text reads: >> >>> >> >>> A SDP offer SHOULD be included in the INVITE. If voice is >> >>> supported the offer MUST include the G.711 codec, see >> >>> Section 14. >> >>> >> >>> Honestly, this is an unrealistic requirement. G.711 is well known >>for >> its >> > bandwidth consumption. Due to this, as far as I know, there is no >> cellular >> > network in the world that support or uses G.711 either in circuit- >> switched >> > or VoIP. I don't think this draft is going to change the current >>status >> quo. >> > Actually, none has ever got to standardize a single codec for an >> > application. Due to this, protocols like SIP/SDP support an codec >> > negotiation mechanism in the format of the SDP offer answer. >> >>> >> >>> Other considerations: >> >>> >> >>> The requirement is nod needed, because in the absence of it, SDP >>offer >> > answer will get to negotiate to a single codec for the emergency call. >> >>> >> >>> This requirement falls into the category of national or >>supranational >> > regulation. There will be organisms which will dictate minimum or >> > recommended support in terms of codecs, and this regulation will be >> above >> > the requirements in this document. >> >>> >> >>> My recommendation is to delete this requirement. >> >>> >> >>> I also noticed that this requirement is also repeated in Section 14, >> > Requirement AD-73. The recommendation is also to delete such >> requirement. >> >>> >> >>> Also, req ED-77 in Section 14 tries to do the same with a video >>codec. >> > The recommendation is still the same. >> >> This has been discussed before. The goal is to be able to have any >> > device, anywhere, be able to complete an emergency call. To make that >> work, >> > you have to have at least one common codec. It's not something a >>local >> > regulation could fix: when you get off a plane, your softclient on >>your >> VoIP >> > service provider, must be able to complete an emergency call where you >> are. >> >> >> >> The alternative is to have the document have a requirement on PSAPs >>to >> > implement a relatively long list of codecs, and then have each device >> > implement at least one of those. That would be quite difficult to >>make >> such >> > a list, and even if you did, some service would have a problem. >> >> >> >> >> >>> >> >>> >> >>> >> >>> - Section 12, the text reads: >> >>> >> >>> Dropping of the old call MUST only >> >>> occur if the user is attempting to hang up >> >>> >> >>> But the previous sentence says: >> >>> >> >>> If in the interval, an incoming call is received from the domain of >> >>> the PSAP, the device MUST drop the old call and alert for the (new) >> >>> incoming call. >> >>> >> >>> So, we have two scenarios for dropping an old call: >> >>> 1) the user is attempting to hung up >> >>> 2) an incoming call is received from the PSAP >> >>> >> >>> Therefore, I disagree with the "MUST only occur" of the first >> sentence. >> > Please rephrase the text to avoid contradictions. >> >> Is see your point. In SIP, hang up requires the complete BYE >> transaction, >> > and you can be in the middle of that transaction when the new call >> arrives. >> > The problem is the word "drop". What we are attempting to say is that >> even >> > though you are in the middle of that transaction, you have to abandon >> it, >> > and accept the new call. So I need a better word for "drop". >> >> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> Nits: >> >>> >> >>> - Expands acronyms at first occurrence. This includes: PSAP, PIDF, >> > PIDF-LO, HELD, LCP, and LoST. >> >> the terminology sections says: >> >> This document uses terms from [RFC3261], [RFC5012] and >> > [I-D.ietf-ecrit-framework]. >> >> >> >> I thought that would be enough. I can expand the acronyms here. >> >> >> >>> >> >>> - Section 9.2, first bullet point >> >>> s/tree, If/tree. If >> >>> >> >>> - Section 9.2, second bullet point >> >>> s/not find a a Router/not find a Router >> >>> >> >>> - Section 11 >> >>> s/and the Referred-by: header/and the Referred-by header >> >> Thanks, I'll fix these >> >> >> >> >> >>> >> >>> >> >>> BR, >> >>> >> >>> Miguel >> >>> >> >>> >> >>> >> >>> -- >> >>> Miguel A. Garcia >> >>> +34-91-339-3608 >> >>> Ericsson Spain >> >> >> >> _______________________________________________ >> >> Ecrit mailing list >> >> Ecrit@ietf.org >> >> https://www.ietf.org/mailman/listinfo/ecrit >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www.ietf.org/mailman/listinfo/ecrit >> > >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Thu Mar 3 06:33:14 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12D1B3A67E7 for ; Thu, 3 Mar 2011 06:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.274 X-Spam-Level: X-Spam-Status: No, score=-102.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIr6UwZpY-Im for ; Thu, 3 Mar 2011 06:33:13 -0800 (PST) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by core3.amsl.com (Postfix) with ESMTP id 285FC3A6802 for ; Thu, 3 Mar 2011 06:33:13 -0800 (PST) X-ASG-Debug-ID: 1299162854-011a9f17533c09f0001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id TnwRXoBxtQ9GAJ68; Thu, 03 Mar 2011 06:34:14 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=mlus-lt500.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Pv9bX-00077K-TH; Thu, 03 Mar 2011 06:34:13 -0800 Mime-Version: 1.0 (Apple Message framework v1082) X-ASG-Orig-Subj: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <26E805AD-4D40-4C7E-9C07-56959336B858@cs.columbia.edu> Date: Thu, 3 Mar 2011 09:34:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <12E789B1-F912-4459-BBBF-50543811227E@brianrosen.net> References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> <26E805AD-4D40-4C7E-9C07-56959336B858@cs.columbia.edu> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1082) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1299162854 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.56937 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "DRAGE, Keith \(Keith\)" , 'ecrit Org' Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 14:33:14 -0000 The comment that started this thread was discussing mobile phones. All = PBX phones support G.711. Most current mobile phones don't. =20 I don't have a problem with a recommended set of codecs if that is 3-5 = codecs. I have a problem if it's 10-15. I would actually like a few of those to be wide band. Wide band is = really a good thing for emergency calls. OTOH, not all mobile phones = support any WB codecs. =20 We are the IETF, we are talking about newer systems, and we are talking = about things that require upgrades (or new features) in phones. = Worrying about not having enough bandwidth for G.711 seems to me to be = an old problem, not a current or new problem. If we could get away with = it, I'd make the codec the new IETF codec and require wideband modes. = That is unrealistic, of course. Brian On Mar 3, 2011, at 8:42 AM, Henning Schulzrinne wrote: > Since these types of documents are often used for RFPs, national = regulations and other requirement documents, would it make sense to = create a list of "recommended" codecs? While it does not ensure that = both sides can negotiate anything other than G.711, it greatly increases = the likelihood. Thus, we could say something like >=20 > "It is RECOMMENDED that the PSAP supports AMR-WB, G.722, G.729." >=20 > I suspect that identifying this larger set wouldn't be that hard. =46rom= a quick look at phone specs, lists like >=20 > G.722, G.723, G.726, G.729 a/b, GSM, G.711 (snom) > G.722, G.723, G.726, G.729 a/b, GSM, iLBC, G.711 (Grandstream) > G.722, G.729 a/b, G.711 u/a law (Polycom) > G.722, G.726, G.729 a/b, G.711 u/a law (Cisco) >=20 > are common. There's a pattern here... >=20 > Thus, by looking at the support in commodity PBX phones today, we = should be able to come up with a reasonable set that is likely going to = be easily commercially available. This would also set a process in = motion - a few years later, we might then be able to promote a non-G.711 = codec to a required status. >=20 > On Mar 3, 2011, at 7:13 AM, DRAGE, Keith (Keith) wrote: >=20 >> PSAPs all support G.711 at the moment essentially. There are PSAPs = out there that will support this and only this. It is also the common = denominator of what everything else will convert to. So while GSM uses = AMR, it provides gateways to the circuit switched world that will = convert this to G.711. >>=20 >> So I guess UEs not supported by any other infrastructure must support = G.711. They can support other codecs and not G.711 if they belong to a = known infrastructure where that infrastructure will do the conversion. >>=20 >> Any other codecs have to be an optional extra with no guarantee of = support. >>=20 >> Regards >>=20 >> Keith >=20 From James.Winterbottom@andrew.com Thu Mar 3 06:58:38 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5129C3A69F2 for ; Thu, 3 Mar 2011 06:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtPxARW4otQL for ; Thu, 3 Mar 2011 06:58:37 -0800 (PST) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id 3533F3A69F1 for ; Thu, 3 Mar 2011 06:58:37 -0800 (PST) X-AuditID: 0a0404e9-b7c06ae000002334-71-4d6face03f94 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id C0.6A.09012.0ECAF6D4; Thu, 3 Mar 2011 08:59:44 -0600 (CST) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 3 Mar 2011 08:59:44 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 3 Mar 2011 22:59:41 +0800 From: "Winterbottom, James" To: "'br@brianrosen.net'" , "'hgs@cs.columbia.edu'" Date: Thu, 3 Mar 2011 22:59:40 +0800 Thread-Topic: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt Thread-Index: AcvZsBkSBUvmIgnVQHWj3x3HqMo4pAAA4XN7 Message-ID: <5A55A45AE77F5941B18E5457ECAC818801210026E797@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "'keith.drage@alcatel-lucent.com'" , "'ecrit@ietf.org'" Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 14:58:38 -0000 TW9zdCBtb2JpbGUgcGhvbmVzIHRvZGF5IGRvbid0IGRvIG5hdGl2ZSBWb0lQIGVpdGhlciwgdGhl eSByZXF1aXJlIGEgc2VwYXJhdGUgYXBwbGljYXRpb24gdG8gZG8gdGhpcy4gSSBjb25mZXNzIHRv IGlnbm9yYW5jZSBoZXJlLCBidXQgc29tZSBsaWtlIFNreXBlIHdvdWxkIHVzZSBzb2Z0d2FyZSBj b2RlY3Mgd291bGRuJ3QgdGhleT8NCkFzc3VtaW5nIHRoaXMgaXMgdGhlIGNhc2UgaXMgdXBncmFk ZSBzdWNoIGFuIGlzc3VlPw0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBl Y3JpdC1ib3VuY2VzQGlldGYub3JnIDxlY3JpdC1ib3VuY2VzQGlldGYub3JnPg0KVG86IEhlbm5p bmcgU2NodWx6cmlubmUgPGhnc0Bjcy5jb2x1bWJpYS5lZHU+DQpDYzogRFJBR0UsIEtlaXRoIChL ZWl0aCkgPGtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbT47ICdlY3JpdCBPcmcnIDxlY3Jp dEBpZXRmLm9yZz4NClNlbnQ6IFRodSBNYXIgMDMgMjI6MzQ6MDggMjAxMQpTdWJqZWN0OiBSZTog W0Vjcml0XSBHZW4tQVJUIHJldmlldyBvZiBkcmFmdC1pZXRmLWVjcml0LXBob25lYmNwLTE2LnR4 dA0KDQpUaGUgY29tbWVudCB0aGF0IHN0YXJ0ZWQgdGhpcyB0aHJlYWQgd2FzIGRpc2N1c3Npbmcg bW9iaWxlIHBob25lcy4gIEFsbCBQQlggcGhvbmVzIHN1cHBvcnQgRy43MTEuICBNb3N0IGN1cnJl bnQgbW9iaWxlIHBob25lcyBkb24ndC4gIA0KDQpJIGRvbid0IGhhdmUgYSBwcm9ibGVtIHdpdGgg YSByZWNvbW1lbmRlZCBzZXQgb2YgY29kZWNzIGlmIHRoYXQgaXMgMy01IGNvZGVjcy4gIEkgaGF2 ZSBhIHByb2JsZW0gaWYgaXQncyAxMC0xNS4NCg0KSSB3b3VsZCBhY3R1YWxseSBsaWtlIGEgZmV3 IG9mIHRob3NlIHRvIGJlIHdpZGUgYmFuZC4gIFdpZGUgYmFuZCBpcyByZWFsbHkgYSBnb29kIHRo aW5nIGZvciBlbWVyZ2VuY3kgY2FsbHMuICBPVE9ILCBub3QgYWxsIG1vYmlsZSBwaG9uZXMgc3Vw cG9ydCBhbnkgV0IgY29kZWNzLiAgDQoNCldlIGFyZSB0aGUgSUVURiwgd2UgYXJlIHRhbGtpbmcg YWJvdXQgbmV3ZXIgc3lzdGVtcywgYW5kIHdlIGFyZSB0YWxraW5nIGFib3V0IHRoaW5ncyB0aGF0 IHJlcXVpcmUgdXBncmFkZXMgKG9yIG5ldyBmZWF0dXJlcykgaW4gcGhvbmVzLiAgV29ycnlpbmcg YWJvdXQgbm90IGhhdmluZyBlbm91Z2ggYmFuZHdpZHRoIGZvciBHLjcxMSBzZWVtcyB0byBtZSB0 byBiZSBhbiBvbGQgcHJvYmxlbSwgbm90IGEgY3VycmVudCBvciBuZXcgcHJvYmxlbS4gIElmIHdl IGNvdWxkIGdldCBhd2F5IHdpdGggaXQsIEknZCBtYWtlIHRoZSBjb2RlYyB0aGUgbmV3IElFVEYg Y29kZWMgYW5kIHJlcXVpcmUgd2lkZWJhbmQgbW9kZXMuICBUaGF0IGlzIHVucmVhbGlzdGljLCBv ZiBjb3Vyc2UuDQoNCkJyaWFuDQoNCk9uIE1hciAzLCAyMDExLCBhdCA4OjQyIEFNLCBIZW5uaW5n IFNjaHVsenJpbm5lIHdyb3RlOg0KDQo+IFNpbmNlIHRoZXNlIHR5cGVzIG9mIGRvY3VtZW50cyBh cmUgb2Z0ZW4gdXNlZCBmb3IgUkZQcywgbmF0aW9uYWwgcmVndWxhdGlvbnMgYW5kIG90aGVyIHJl cXVpcmVtZW50IGRvY3VtZW50cywgd291bGQgaXQgbWFrZSBzZW5zZSB0byBjcmVhdGUgYSBsaXN0 IG9mICJyZWNvbW1lbmRlZCIgY29kZWNzPyBXaGlsZSBpdCBkb2VzIG5vdCBlbnN1cmUgdGhhdCBi b3RoIHNpZGVzIGNhbiBuZWdvdGlhdGUgYW55dGhpbmcgb3RoZXIgdGhhbiBHLjcxMSwgaXQgZ3Jl YXRseSBpbmNyZWFzZXMgdGhlIGxpa2VsaWhvb2QuIFRodXMsIHdlIGNvdWxkIHNheSBzb21ldGhp bmcgbGlrZQ0KPiANCj4gIkl0IGlzIFJFQ09NTUVOREVEIHRoYXQgdGhlIFBTQVAgc3VwcG9ydHMg QU1SLVdCLCBHLjcyMiwgRy43MjkuIg0KPiANCj4gSSBzdXNwZWN0IHRoYXQgaWRlbnRpZnlpbmcg dGhpcyBsYXJnZXIgc2V0IHdvdWxkbid0IGJlIHRoYXQgaGFyZC4gRnJvbSBhIHF1aWNrIGxvb2sg YXQgcGhvbmUgc3BlY3MsIGxpc3RzIGxpa2UNCj4gDQo+IEcuNzIyLCBHLjcyMywgRy43MjYsIEcu NzI5IGEvYiwgR1NNLCBHLjcxMSAoc25vbSkNCj4gRy43MjIsIEcuNzIzLCBHLjcyNiwgRy43Mjkg YS9iLCBHU00sIGlMQkMsIEcuNzExIChHcmFuZHN0cmVhbSkNCj4gRy43MjIsIEcuNzI5IGEvYiwg Ry43MTEgdS9hIGxhdyAoUG9seWNvbSkNCj4gRy43MjIsIEcuNzI2LCBHLjcyOSBhL2IsIEcuNzEx IHUvYSBsYXcgKENpc2NvKQ0KPiANCj4gYXJlIGNvbW1vbi4gVGhlcmUncyBhIHBhdHRlcm4gaGVy ZS4uLg0KPiANCj4gVGh1cywgYnkgbG9va2luZyBhdCB0aGUgc3VwcG9ydCBpbiBjb21tb2RpdHkg UEJYIHBob25lcyB0b2RheSwgd2Ugc2hvdWxkIGJlIGFibGUgdG8gY29tZSB1cCB3aXRoIGEgcmVh c29uYWJsZSBzZXQgdGhhdCBpcyBsaWtlbHkgZ29pbmcgdG8gYmUgZWFzaWx5IGNvbW1lcmNpYWxs eSBhdmFpbGFibGUuIFRoaXMgd291bGQgYWxzbyBzZXQgYSBwcm9jZXNzIGluIG1vdGlvbiAtIGEg ZmV3IHllYXJzIGxhdGVyLCB3ZSBtaWdodCB0aGVuIGJlIGFibGUgdG8gcHJvbW90ZSBhIG5vbi1H LjcxMSBjb2RlYyB0byBhIHJlcXVpcmVkIHN0YXR1cy4NCj4gDQo+IE9uIE1hciAzLCAyMDExLCBh dCA3OjEzIEFNLCBEUkFHRSwgS2VpdGggKEtlaXRoKSB3cm90ZToNCj4gDQo+PiBQU0FQcyBhbGwg c3VwcG9ydCBHLjcxMSBhdCB0aGUgbW9tZW50IGVzc2VudGlhbGx5LiBUaGVyZSBhcmUgUFNBUHMg b3V0IHRoZXJlIHRoYXQgd2lsbCBzdXBwb3J0IHRoaXMgYW5kIG9ubHkgdGhpcy4gSXQgaXMgYWxz byB0aGUgY29tbW9uIGRlbm9taW5hdG9yIG9mIHdoYXQgZXZlcnl0aGluZyBlbHNlIHdpbGwgY29u dmVydCB0by4gU28gd2hpbGUgR1NNIHVzZXMgQU1SLCBpdCBwcm92aWRlcyBnYXRld2F5cyB0byB0 aGUgY2lyY3VpdCBzd2l0Y2hlZCB3b3JsZCB0aGF0IHdpbGwgY29udmVydCB0aGlzIHRvIEcuNzEx Lg0KPj4gDQo+PiBTbyBJIGd1ZXNzIFVFcyBub3Qgc3VwcG9ydGVkIGJ5IGFueSBvdGhlciBpbmZy YXN0cnVjdHVyZSBtdXN0IHN1cHBvcnQgRy43MTEuIFRoZXkgY2FuIHN1cHBvcnQgb3RoZXIgY29k ZWNzIGFuZCBub3QgRy43MTEgaWYgdGhleSBiZWxvbmcgdG8gYSBrbm93biBpbmZyYXN0cnVjdHVy ZSB3aGVyZSB0aGF0IGluZnJhc3RydWN0dXJlIHdpbGwgZG8gdGhlIGNvbnZlcnNpb24uDQo+PiAN Cj4+IEFueSBvdGhlciBjb2RlY3MgaGF2ZSB0byBiZSBhbiBvcHRpb25hbCBleHRyYSB3aXRoIG5v IGd1YXJhbnRlZSBvZiBzdXBwb3J0Lg0KPj4gDQo+PiBSZWdhcmRzDQo+PiANCj4+IEtlaXRoDQo+ IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRWNy aXQgbWFpbGluZyBsaXN0DQpFY3JpdEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9lY3JpdA0K From gunnar.hellstrom@omnitor.se Thu Mar 3 12:34:49 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17BE23A6973 for ; Thu, 3 Mar 2011 12:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b099c9OXD3ET for ; Thu, 3 Mar 2011 12:34:48 -0800 (PST) Received: from vsp-outgoing1.binero.net (vsp-outgoing1.binero.net [193.17.218.160]) by core3.amsl.com (Postfix) with SMTP id 85FC93A688F for ; Thu, 3 Mar 2011 12:34:47 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.39.229]) by vsp-outgoing1.binero.net (Halon Mail Gateway) with ESMTP for ; Thu, 3 Mar 2011 21:35:47 +0100 (CET) Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-09-01.atm.binero.net (Postfix) with ESMTPA id 0C0043A21B for ; Thu, 3 Mar 2011 21:35:47 +0100 (CET) Message-ID: <4D6FFBA2.4060009@omnitor.se> Date: Thu, 03 Mar 2011 21:35:46 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: ecrit@ietf.org References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> <26E805AD-4D40-4C7E-9C07-56959336B858@cs.columbia.edu> <12E789B1-F912-4459-BBBF-50543811227E@brianrosen.net> In-Reply-To: <12E789B1-F912-4459-BBBF-50543811227E@brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 20:34:49 -0000 This discussion has made it clear that some change is needed to allow service providers with non-SIP devices to enable their device users to call emergency services. And also service providers with devices using new kinds of codecs not supported by PSAPs. For both cases, the easiest way seems me to be to insert three definitions in the Framework draft. Phonebcp refers to Framework for terms. The terms in need of definition are End Device, Endpoint and Application. I suggest the following inserts in Chapter 1, Terminology, of draft-ietf-ecrit-framework ---------------------------------------------------------------------------------------------------------------------------------------------------- Application: Software functions performing the tasks related to the End Device so that the Endpoint can perform the protocols, functions and media codings required in this Framework. An Application may be distributed among the End Device and various nodes in the Service Provider's Infrastructure. End Device: Physical device on the user side where the emergency call is handled. Endpoint: The entity representing the user where the protocols excpected to be performed by End Devices and Applications are handled. This may in reality be implemented at different points for different functions. If a Service Provider has SIP terminals capable of the same media as the PSAP, the Endpoint is in the user terminal. If a Service Provider has non-SIP devices, the Endpoint for call control and media may be in a gateway in the Service Provider's infrastructure etc. ------------------------------------------------------------------------------- By this little change we enable for example the whole current and future Mobile networks to use the emergency services specified by the Framework and Phonebcp specifications. We also enable Service Providers using other call control protocols than SIP to use emergency services. Without these changes, the application of the ecrit specifications remain very limited to native SIP terminals, implementing exactly the same codecs as listed in Phonebcp. Gunnar _____________________________________________ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 Brian Rosen skrev 2011-03-03 15:34: > The comment that started this thread was discussing mobile phones. All PBX phones support G.711. Most current mobile phones don't. > > I don't have a problem with a recommended set of codecs if that is 3-5 codecs. I have a problem if it's 10-15. > > I would actually like a few of those to be wide band. Wide band is really a good thing for emergency calls. OTOH, not all mobile phones support any WB codecs. > > We are the IETF, we are talking about newer systems, and we are talking about things that require upgrades (or new features) in phones. Worrying about not having enough bandwidth for G.711 seems to me to be an old problem, not a current or new problem. If we could get away with it, I'd make the codec the new IETF codec and require wideband modes. That is unrealistic, of course. > > Brian > > On Mar 3, 2011, at 8:42 AM, Henning Schulzrinne wrote: > >> Since these types of documents are often used for RFPs, national regulations and other requirement documents, would it make sense to create a list of "recommended" codecs? While it does not ensure that both sides can negotiate anything other than G.711, it greatly increases the likelihood. Thus, we could say something like >> >> "It is RECOMMENDED that the PSAP supports AMR-WB, G.722, G.729." >> >> I suspect that identifying this larger set wouldn't be that hard. From a quick look at phone specs, lists like >> >> G.722, G.723, G.726, G.729 a/b, GSM, G.711 (snom) >> G.722, G.723, G.726, G.729 a/b, GSM, iLBC, G.711 (Grandstream) >> G.722, G.729 a/b, G.711 u/a law (Polycom) >> G.722, G.726, G.729 a/b, G.711 u/a law (Cisco) >> >> are common. There's a pattern here... >> >> Thus, by looking at the support in commodity PBX phones today, we should be able to come up with a reasonable set that is likely going to be easily commercially available. This would also set a process in motion - a few years later, we might then be able to promote a non-G.711 codec to a required status. >> >> On Mar 3, 2011, at 7:13 AM, DRAGE, Keith (Keith) wrote: >> >>> PSAPs all support G.711 at the moment essentially. There are PSAPs out there that will support this and only this. It is also the common denominator of what everything else will convert to. So while GSM uses AMR, it provides gateways to the circuit switched world that will convert this to G.711. >>> >>> So I guess UEs not supported by any other infrastructure must support G.711. They can support other codecs and not G.711 if they belong to a known infrastructure where that infrastructure will do the conversion. >>> >>> Any other codecs have to be an optional extra with no guarantee of support. >>> >>> Regards >>> >>> Keith > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From gunnar.hellstrom@omnitor.se Thu Mar 3 12:56:41 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5867A3A6800 for ; Thu, 3 Mar 2011 12:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gaYYJt6TH7I for ; Thu, 3 Mar 2011 12:56:39 -0800 (PST) Received: from vsp-outgoing1.binero.net (vsp-outgoing1.binero.net [193.17.218.160]) by core3.amsl.com (Postfix) with SMTP id 1CC803A6823 for ; Thu, 3 Mar 2011 12:56:38 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.39.229]) by vsp-outgoing1.binero.net (Halon Mail Gateway) with ESMTP for ; Thu, 3 Mar 2011 21:57:40 +0100 (CET) Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-07-01.atm.binero.net (Postfix) with ESMTPA id 6F8D33A1F1 for ; Thu, 3 Mar 2011 21:57:40 +0100 (CET) Message-ID: <4D7000C3.3080209@omnitor.se> Date: Thu, 03 Mar 2011 21:57:39 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: ecrit@ietf.org References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> <26E805AD-4D40-4C7E-9C07-56959336B858@cs.columbia.edu> <12E789B1-F912-4459-BBBF-50543811227E@brianrosen.net> In-Reply-To: <12E789B1-F912-4459-BBBF-50543811227E@brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 20:56:41 -0000 When deciding on the audio codec list, it is relevant to check if other bodies do similar lists of mandatory codecs. Harmonization is of course of value. It is then interesting to note that the current proposal for mandatory audio codec for public procurements and telecom devices in USA is G.722. This is because of the better characteristics for users with hearing impairments of wide-band codecs over the old telephone quality codecs. This is stated in the proposal from the US Access Board for refresh of US Acts Sections 508 and 255. See http://www.access-board.gov/sec508/refresh/draft-rule.htm "906 Audio Clarity for Interconnected VoIP" On the other hand, this is not decided, and it is just one country, so it may not be what we need to dictate in Phonebcp. Tricky. It may be a disaster for a person with hearing impairment to have G.722 or AMR-WB audio quality in all every-day calls, but suddenly limited to G.711 quality in the Emergency call. This is also a question for the Framework specification. Gunnar ___________________________________________________ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 Brian Rosen skrev 2011-03-03 15:34: > The comment that started this thread was discussing mobile phones. All PBX phones support G.711. Most current mobile phones don't. > > I don't have a problem with a recommended set of codecs if that is 3-5 codecs. I have a problem if it's 10-15. > > I would actually like a few of those to be wide band. Wide band is really a good thing for emergency calls. OTOH, not all mobile phones support any WB codecs. > > We are the IETF, we are talking about newer systems, and we are talking about things that require upgrades (or new features) in phones. Worrying about not having enough bandwidth for G.711 seems to me to be an old problem, not a current or new problem. If we could get away with it, I'd make the codec the new IETF codec and require wideband modes. That is unrealistic, of course. > > Brian > > On Mar 3, 2011, at 8:42 AM, Henning Schulzrinne wrote: > >> Since these types of documents are often used for RFPs, national regulations and other requirement documents, would it make sense to create a list of "recommended" codecs? While it does not ensure that both sides can negotiate anything other than G.711, it greatly increases the likelihood. Thus, we could say something like >> >> "It is RECOMMENDED that the PSAP supports AMR-WB, G.722, G.729." >> >> I suspect that identifying this larger set wouldn't be that hard. From a quick look at phone specs, lists like >> >> G.722, G.723, G.726, G.729 a/b, GSM, G.711 (snom) >> G.722, G.723, G.726, G.729 a/b, GSM, iLBC, G.711 (Grandstream) >> G.722, G.729 a/b, G.711 u/a law (Polycom) >> G.722, G.726, G.729 a/b, G.711 u/a law (Cisco) >> >> are common. There's a pattern here... >> >> Thus, by looking at the support in commodity PBX phones today, we should be able to come up with a reasonable set that is likely going to be easily commercially available. This would also set a process in motion - a few years later, we might then be able to promote a non-G.711 codec to a required status. >> >> On Mar 3, 2011, at 7:13 AM, DRAGE, Keith (Keith) wrote: >> >>> PSAPs all support G.711 at the moment essentially. There are PSAPs out there that will support this and only this. It is also the common denominator of what everything else will convert to. So while GSM uses AMR, it provides gateways to the circuit switched world that will convert this to G.711. >>> >>> So I guess UEs not supported by any other infrastructure must support G.711. They can support other codecs and not G.711 if they belong to a known infrastructure where that infrastructure will do the conversion. >>> >>> Any other codecs have to be an optional extra with no guarantee of support. >>> >>> Regards >>> >>> Keith > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hgs@cs.columbia.edu Thu Mar 3 19:27:44 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FA7D3A691D for ; Thu, 3 Mar 2011 19:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUYe1RIY9EcF for ; Thu, 3 Mar 2011 19:27:42 -0800 (PST) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by core3.amsl.com (Postfix) with ESMTP id 355053A6918 for ; Thu, 3 Mar 2011 19:27:42 -0800 (PST) Received: from [192.168.1.15] (pool-74-96-51-195.washdc.east.verizon.net [74.96.51.195]) (user=hgs10 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p243SjeA018455 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 3 Mar 2011 22:28:46 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <12E789B1-F912-4459-BBBF-50543811227E@brianrosen.net> Date: Thu, 3 Mar 2011 22:28:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5D628A73-1BCC-4020-82AD-AA50F7F3B970@cs.columbia.edu> References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> <26E805AD-4D40-4C7E-9C07-56959336B858@cs.columbia.edu> <12E789B1-F912-4459-BBBF-50543811227E@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1082) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: "DRAGE, Keith \(Keith\)" , 'ecrit Org' Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 03:27:44 -0000 Since the PSAP phones won't (likely) be mobile, non-support for specific = codecs seems less of an issue, except that mobile phones won't give you = the better quality. But many of the applications where this matters, = e.g., to support callers with disabilities, aren't necessarily mobile. = And transcoding AMR-WB into G.722 is certainly better than transcoding = it into G.711. =46rom what I can tell from my quick survey of commodity PBX phones, = there does appear to be a list of 3-5 codecs that would cover a pretty = broad spectrum, for example, G.722 + G.729a/b + G.711. Even G.722 + = G.711 wouldn't be bad; since neither codec is patent-encumbered, the = incremental cost should be essentially zero. There is no reason we can't = revisit the list in a few years. Even if we add a new recommended codec = every 5 years and never retire one, this will hardly be a major = complexity driver, given that the older codecs will be relatively = lightweight compared to the newer ones. Is there any downside to specifying G.711 MUST, G.722 SHOULD, for = example? Henning On Mar 3, 2011, at 9:34 AM, Brian Rosen wrote: > The comment that started this thread was discussing mobile phones. = All PBX phones support G.711. Most current mobile phones don't. =20 >=20 > I don't have a problem with a recommended set of codecs if that is 3-5 = codecs. I have a problem if it's 10-15. >=20 > I would actually like a few of those to be wide band. Wide band is = really a good thing for emergency calls. OTOH, not all mobile phones = support any WB codecs. =20 >=20 > We are the IETF, we are talking about newer systems, and we are = talking about things that require upgrades (or new features) in phones. = Worrying about not having enough bandwidth for G.711 seems to me to be = an old problem, not a current or new problem. If we could get away with = it, I'd make the codec the new IETF codec and require wideband modes. = That is unrealistic, of course. >=20 > Brian >=20 > On Mar 3, 2011, at 8:42 AM, Henning Schulzrinne wrote: >=20 >> Since these types of documents are often used for RFPs, national = regulations and other requirement documents, would it make sense to = create a list of "recommended" codecs? While it does not ensure that = both sides can negotiate anything other than G.711, it greatly increases = the likelihood. Thus, we could say something like >>=20 >> "It is RECOMMENDED that the PSAP supports AMR-WB, G.722, G.729." >>=20 >> I suspect that identifying this larger set wouldn't be that hard. = =46rom a quick look at phone specs, lists like >>=20 >> G.722, G.723, G.726, G.729 a/b, GSM, G.711 (snom) >> G.722, G.723, G.726, G.729 a/b, GSM, iLBC, G.711 (Grandstream) >> G.722, G.729 a/b, G.711 u/a law (Polycom) >> G.722, G.726, G.729 a/b, G.711 u/a law (Cisco) >>=20 >> are common. There's a pattern here... >>=20 >> Thus, by looking at the support in commodity PBX phones today, we = should be able to come up with a reasonable set that is likely going to = be easily commercially available. This would also set a process in = motion - a few years later, we might then be able to promote a non-G.711 = codec to a required status. >>=20 >> On Mar 3, 2011, at 7:13 AM, DRAGE, Keith (Keith) wrote: >>=20 >>> PSAPs all support G.711 at the moment essentially. There are PSAPs = out there that will support this and only this. It is also the common = denominator of what everything else will convert to. So while GSM uses = AMR, it provides gateways to the circuit switched world that will = convert this to G.711. >>>=20 >>> So I guess UEs not supported by any other infrastructure must = support G.711. They can support other codecs and not G.711 if they = belong to a known infrastructure where that infrastructure will do the = conversion. >>>=20 >>> Any other codecs have to be an optional extra with no guarantee of = support. >>>=20 >>> Regards >>>=20 >>> Keith >>=20 >=20 >=20 From br@brianrosen.net Sat Mar 5 07:28:08 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CC193A6A8A for ; Sat, 5 Mar 2011 07:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.339 X-Spam-Level: X-Spam-Status: No, score=-102.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iv2KiiEvIJSw for ; Sat, 5 Mar 2011 07:28:07 -0800 (PST) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by core3.amsl.com (Postfix) with ESMTP id 3B64A3A6A78 for ; Sat, 5 Mar 2011 07:28:07 -0800 (PST) X-ASG-Debug-ID: 1299338703-011a9f1753430480001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id tjAVtqyfHzTMcBuH; Sat, 05 Mar 2011 07:25:03 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=agoo-lt500.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PvtLm-0000YI-Gw; Sat, 05 Mar 2011 07:25:02 -0800 Mime-Version: 1.0 (Apple Message framework v1082) X-ASG-Orig-Subj: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <5D628A73-1BCC-4020-82AD-AA50F7F3B970@cs.columbia.edu> Date: Sat, 5 Mar 2011 10:24:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <69A77C08-DB6A-4A64-B960-D6EBF2932BCF@brianrosen.net> References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> <26E805AD-4D40-4C7E-9C07-56959336B858@cs.columbia.edu> <12E789B1-F912-4459-BBBF-50543811227E@brianrosen.net> <5D628A73-1BCC-4020-82AD-AA50F7F3B970@cs.columbia.edu> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1082) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1299338703 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.57131 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "DRAGE, Keith \(Keith\)" , 'ecrit Org' Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 15:28:08 -0000 Nope, no downside. I can do that. Doesn't handle the problem that started this: mobile phones don't do = G.711 or G.722 Brian On Mar 3, 2011, at 10:28 PM, Henning Schulzrinne wrote: > Since the PSAP phones won't (likely) be mobile, non-support for = specific codecs seems less of an issue, except that mobile phones won't = give you the better quality. But many of the applications where this = matters, e.g., to support callers with disabilities, aren't necessarily = mobile. And transcoding AMR-WB into G.722 is certainly better than = transcoding it into G.711. >=20 > =46rom what I can tell from my quick survey of commodity PBX phones, = there does appear to be a list of 3-5 codecs that would cover a pretty = broad spectrum, for example, G.722 + G.729a/b + G.711. Even G.722 + = G.711 wouldn't be bad; since neither codec is patent-encumbered, the = incremental cost should be essentially zero. There is no reason we can't = revisit the list in a few years. Even if we add a new recommended codec = every 5 years and never retire one, this will hardly be a major = complexity driver, given that the older codecs will be relatively = lightweight compared to the newer ones. >=20 > Is there any downside to specifying G.711 MUST, G.722 SHOULD, for = example? >=20 > Henning >=20 > On Mar 3, 2011, at 9:34 AM, Brian Rosen wrote: >=20 >> The comment that started this thread was discussing mobile phones. = All PBX phones support G.711. Most current mobile phones don't. =20 >>=20 >> I don't have a problem with a recommended set of codecs if that is = 3-5 codecs. I have a problem if it's 10-15. >>=20 >> I would actually like a few of those to be wide band. Wide band is = really a good thing for emergency calls. OTOH, not all mobile phones = support any WB codecs. =20 >>=20 >> We are the IETF, we are talking about newer systems, and we are = talking about things that require upgrades (or new features) in phones. = Worrying about not having enough bandwidth for G.711 seems to me to be = an old problem, not a current or new problem. If we could get away with = it, I'd make the codec the new IETF codec and require wideband modes. = That is unrealistic, of course. >>=20 >> Brian >>=20 >> On Mar 3, 2011, at 8:42 AM, Henning Schulzrinne wrote: >>=20 >>> Since these types of documents are often used for RFPs, national = regulations and other requirement documents, would it make sense to = create a list of "recommended" codecs? While it does not ensure that = both sides can negotiate anything other than G.711, it greatly increases = the likelihood. Thus, we could say something like >>>=20 >>> "It is RECOMMENDED that the PSAP supports AMR-WB, G.722, G.729." >>>=20 >>> I suspect that identifying this larger set wouldn't be that hard. = =46rom a quick look at phone specs, lists like >>>=20 >>> G.722, G.723, G.726, G.729 a/b, GSM, G.711 (snom) >>> G.722, G.723, G.726, G.729 a/b, GSM, iLBC, G.711 (Grandstream) >>> G.722, G.729 a/b, G.711 u/a law (Polycom) >>> G.722, G.726, G.729 a/b, G.711 u/a law (Cisco) >>>=20 >>> are common. There's a pattern here... >>>=20 >>> Thus, by looking at the support in commodity PBX phones today, we = should be able to come up with a reasonable set that is likely going to = be easily commercially available. This would also set a process in = motion - a few years later, we might then be able to promote a non-G.711 = codec to a required status. >>>=20 >>> On Mar 3, 2011, at 7:13 AM, DRAGE, Keith (Keith) wrote: >>>=20 >>>> PSAPs all support G.711 at the moment essentially. There are PSAPs = out there that will support this and only this. It is also the common = denominator of what everything else will convert to. So while GSM uses = AMR, it provides gateways to the circuit switched world that will = convert this to G.711. >>>>=20 >>>> So I guess UEs not supported by any other infrastructure must = support G.711. They can support other codecs and not G.711 if they = belong to a known infrastructure where that infrastructure will do the = conversion. >>>>=20 >>>> Any other codecs have to be an optional extra with no guarantee of = support. >>>>=20 >>>> Regards >>>>=20 >>>> Keith >>>=20 >>=20 >>=20 >=20 From gunnar.hellstrom@omnitor.se Sat Mar 5 07:57:52 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A59F3A693B for ; Sat, 5 Mar 2011 07:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boLjt4RYqZ1T for ; Sat, 5 Mar 2011 07:57:51 -0800 (PST) Received: from vsp-outgoing1.binero.net (vsp-outgoing1.binero.net [193.17.218.160]) by core3.amsl.com (Postfix) with SMTP id 15FE83A6A95 for ; Sat, 5 Mar 2011 07:57:49 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.39.229]) by vsp-outgoing1.binero.net (Halon Mail Gateway) with ESMTP for ; Sat, 5 Mar 2011 16:58:52 +0100 (CET) Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-09-01.atm.binero.net (Postfix) with ESMTPA id 2DE023A125; Sat, 5 Mar 2011 16:58:52 +0100 (CET) Message-ID: <4D725DBE.2060308@omnitor.se> Date: Sat, 05 Mar 2011 16:58:54 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: ecrit@ietf.org, Brian Rosen , Henning Schulzrinne References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> <26E805AD-4D40-4C7E-9C07-56959336B858@cs.columbia.edu> <12E789B1-F912-4459-BBBF-50543811227E@brianrosen.net> <5D628A73-1BCC-4020-82AD-AA50F7F3B970@cs.columbia.edu> <69A77C08-DB6A-4A64-B960-D6EBF2932BCF@brianrosen.net> In-Reply-To: <69A77C08-DB6A-4A64-B960-D6EBF2932BCF@brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 15:57:52 -0000 An indication that transcoding is acceptable is also needed. Right now the codec requirement ED-73 is on the End Device. Solution: Either change to ED-73/SP-41 or change the definition of ED- to include a possilbe transcoder or gateway. Still does not handle the initial problem neatly. /Gunnar Brian Rosen skrev 2011-03-05 16:24: > Nope, no downside. I can do that. > > Doesn't handle the problem that started this: mobile phones don't do G.711 or G.722 > > Brian > > On Mar 3, 2011, at 10:28 PM, Henning Schulzrinne wrote: > >> Since the PSAP phones won't (likely) be mobile, non-support for specific codecs seems less of an issue, except that mobile phones won't give you the better quality. But many of the applications where this matters, e.g., to support callers with disabilities, aren't necessarily mobile. And transcoding AMR-WB into G.722 is certainly better than transcoding it into G.711. >> >> From what I can tell from my quick survey of commodity PBX phones, there does appear to be a list of 3-5 codecs that would cover a pretty broad spectrum, for example, G.722 + G.729a/b + G.711. Even G.722 + G.711 wouldn't be bad; since neither codec is patent-encumbered, the incremental cost should be essentially zero. There is no reason we can't revisit the list in a few years. Even if we add a new recommended codec every 5 years and never retire one, this will hardly be a major complexity driver, given that the older codecs will be relatively lightweight compared to the newer ones. >> >> Is there any downside to specifying G.711 MUST, G.722 SHOULD, for example? >> >> Henning >> >> On Mar 3, 2011, at 9:34 AM, Brian Rosen wrote: >> >>> The comment that started this thread was discussing mobile phones. All PBX phones support G.711. Most current mobile phones don't. >>> >>> I don't have a problem with a recommended set of codecs if that is 3-5 codecs. I have a problem if it's 10-15. >>> >>> I would actually like a few of those to be wide band. Wide band is really a good thing for emergency calls. OTOH, not all mobile phones support any WB codecs. >>> >>> We are the IETF, we are talking about newer systems, and we are talking about things that require upgrades (or new features) in phones. Worrying about not having enough bandwidth for G.711 seems to me to be an old problem, not a current or new problem. If we could get away with it, I'd make the codec the new IETF codec and require wideband modes. That is unrealistic, of course. >>> >>> Brian >>> >>> On Mar 3, 2011, at 8:42 AM, Henning Schulzrinne wrote: >>> >>>> Since these types of documents are often used for RFPs, national regulations and other requirement documents, would it make sense to create a list of "recommended" codecs? While it does not ensure that both sides can negotiate anything other than G.711, it greatly increases the likelihood. Thus, we could say something like >>>> >>>> "It is RECOMMENDED that the PSAP supports AMR-WB, G.722, G.729." >>>> >>>> I suspect that identifying this larger set wouldn't be that hard. From a quick look at phone specs, lists like >>>> >>>> G.722, G.723, G.726, G.729 a/b, GSM, G.711 (snom) >>>> G.722, G.723, G.726, G.729 a/b, GSM, iLBC, G.711 (Grandstream) >>>> G.722, G.729 a/b, G.711 u/a law (Polycom) >>>> G.722, G.726, G.729 a/b, G.711 u/a law (Cisco) >>>> >>>> are common. There's a pattern here... >>>> >>>> Thus, by looking at the support in commodity PBX phones today, we should be able to come up with a reasonable set that is likely going to be easily commercially available. This would also set a process in motion - a few years later, we might then be able to promote a non-G.711 codec to a required status. >>>> >>>> On Mar 3, 2011, at 7:13 AM, DRAGE, Keith (Keith) wrote: >>>> >>>>> PSAPs all support G.711 at the moment essentially. There are PSAPs out there that will support this and only this. It is also the common denominator of what everything else will convert to. So while GSM uses AMR, it provides gateways to the circuit switched world that will convert this to G.711. >>>>> >>>>> So I guess UEs not supported by any other infrastructure must support G.711. They can support other codecs and not G.711 if they belong to a known infrastructure where that infrastructure will do the conversion. >>>>> >>>>> Any other codecs have to be an optional extra with no guarantee of support. >>>>> >>>>> Regards >>>>> >>>>> Keith >>> > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hgs@cs.columbia.edu Sat Mar 5 08:47:00 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF94D3A6A8C for ; Sat, 5 Mar 2011 08:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BL6hVO94mlD6 for ; Sat, 5 Mar 2011 08:47:00 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id ADE243A6821 for ; Sat, 5 Mar 2011 08:46:59 -0800 (PST) Received: from new-host.home (pool-173-54-225-113.nwrknj.fios.verizon.net [173.54.225.113]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p25Gm3Vq008242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 5 Mar 2011 11:48:04 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <69A77C08-DB6A-4A64-B960-D6EBF2932BCF@brianrosen.net> Date: Sat, 5 Mar 2011 11:48:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5878DF10-7E81-4C00-979C-526FB1732778@cs.columbia.edu> References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> <26E805AD-4D40-4C7E-9C07-56959336B858@cs.columbia.edu> <12E789B1-F912-4459-BBBF-50543811227E@brianrosen.net> <5D628A73-1BCC-4020-82AD-AA50F7F3B970@cs.columbia.edu> <69A77C08-DB6A-4A64-B960-D6EBF2932BCF@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1082) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: "DRAGE, Keith \(Keith\)" , 'ecrit Org' Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 16:47:00 -0000 There's nothing we can do about this problem, particularly given that = there doesn't appear to be a universal codec for mobile devices. Also, I = suspect that all mobile calls *today* show up as G.711 by the time they = reach the ESInet, since they go through a circuit-to-packet conversion. = Once we have VoIP-over-LTE, it might be appropriate to add the most = common wideband codec for that configuration to the SHOULD list. There = doesn't seem to be as much point in adding narrowband codecs, since the = conversion to G.711 is cheap and no quality would be lost in = translation. Henning On Mar 5, 2011, at 10:24 AM, Brian Rosen wrote: > Nope, no downside. I can do that. >=20 > Doesn't handle the problem that started this: mobile phones don't do = G.711 or G.722 From jmpolk@cisco.com Sat Mar 5 22:36:46 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 064E03A6AD4 for ; Sat, 5 Mar 2011 22:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNpKfuBiv+8K for ; Sat, 5 Mar 2011 22:36:42 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 4CA683A695F for ; Sat, 5 Mar 2011 22:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1954; q=dns/txt; s=iport; t=1299393474; x=1300603074; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=sKJ/ZkZFhYb7hnNHGP8O2fokKHcgQUtETLPmqyl2Z8M=; b=EwPr2rsd6WAkmlQppcSwteAi9hugyvDI66tfxAiw4UL+Z92ske99f4uE 96Lr++FSA0pa+xysr1tOjRPuNHAwL7b6BpZ8WUz7OIdSP4POY31zA7mCG 6+mJ8nWhiYB2Bi+9+F0cvrpp5w7Kv+K5IzwuPGYpz03qw5D0mJGqHEjTL 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANO6ck2rRN+J/2dsb2JhbACma3SjAJpghWIEhRyTMQ X-IronPort-AV: E=Sophos;i="4.62,271,1297036800"; d="scan'208";a="270380992" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 06 Mar 2011 06:37:53 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p266brCX000350; Sun, 6 Mar 2011 06:37:53 GMT Message-Id: <201103060637.p266brCX000350@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 06 Mar 2011 00:37:52 -0600 To: Henning Schulzrinne , Brian Rosen From: "James M. Polk" In-Reply-To: <5878DF10-7E81-4C00-979C-526FB1732778@cs.columbia.edu> References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> <26E805AD-4D40-4C7E-9C07-56959336B858@cs.columbia.edu> <12E789B1-F912-4459-BBBF-50543811227E@brianrosen.net> <5D628A73-1BCC-4020-82AD-AA50F7F3B970@cs.columbia.edu> <69A77C08-DB6A-4A64-B960-D6EBF2932BCF@brianrosen.net> <5878DF10-7E81-4C00-979C-526FB1732778@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "DRAGE, Keith \(Keith\)" , 'ecrit Org' Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 06:36:48 -0000 I agree with Henning here. We really cannot really control or reliably expect that within the existing SW upgradeable "interworking" products that we can mandate a codec. That said, Gunnar is also right, this shouldn't be only an "ED" requirement. Along those lines, I think this requirement, while well intentioned, falls into the gap between IP and circuit, in which we can't truthfully say that we "know" this only applies to the IP part - at least not without rewording to limit this. Something needs to state definitively that when the media gets to the ESRP - via mobile or wired - it needs to be in either the G.711 or G.722 codec for interoperability sake. That means the cellco mobile devices can use whatever codec they want, as long as the cellco converts to 711 or 722 once the media is transcoded to RTP. I'm not sure we have a requirement that say exactly that, and I think we should for this situation. James At 10:48 AM 3/5/2011, Henning Schulzrinne wrote: >There's nothing we can do about this problem, particularly given >that there doesn't appear to be a universal codec for mobile >devices. Also, I suspect that all mobile calls *today* show up as >G.711 by the time they reach the ESInet, since they go through a >circuit-to-packet conversion. Once we have VoIP-over-LTE, it might >be appropriate to add the most common wideband codec for that >configuration to the SHOULD list. There doesn't seem to be as much >point in adding narrowband codecs, since the conversion to G.711 is >cheap and no quality would be lost in translation. > >Henning > >On Mar 5, 2011, at 10:24 AM, Brian Rosen wrote: > > > Nope, no downside. I can do that. > > > > Doesn't handle the problem that started this: mobile phones don't > do G.711 or G.722 > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From gunnar.hellstrom@omnitor.se Sat Mar 5 23:37:48 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 946D43A6A4F for ; Sat, 5 Mar 2011 23:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ub4g+GwMbKT for ; Sat, 5 Mar 2011 23:37:47 -0800 (PST) Received: from vsp-outgoing1.binero.net (vsp-outgoing1.binero.net [193.17.218.160]) by core3.amsl.com (Postfix) with SMTP id 07B203A689F for ; Sat, 5 Mar 2011 23:37:45 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.39.229]) by vsp-outgoing1.binero.net (Halon Mail Gateway) with ESMTP for ; Sun, 6 Mar 2011 08:38:49 +0100 (CET) Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-08-01.atm.binero.net (Postfix) with ESMTPA id 914953A13B for ; Sun, 6 Mar 2011 08:38:49 +0100 (CET) Message-ID: <4D733A08.8090203@omnitor.se> Date: Sun, 06 Mar 2011 08:38:48 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: ecrit@ietf.org References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> <26E805AD-4D40-4C7E-9C07-56959336B858@cs.columbia.edu> <12E789B1-F912-4459-BBBF-50543811227E@brianrosen.net> <5D628A73-1BCC-4020-82AD-AA50F7F3B970@cs.columbia.edu> <69A77C08-DB6A-4A64-B960-D6EBF2932BCF@brianrosen.net> <5878DF10-7E81-4C00-979C-526FB1732778@cs.columbia.edu> <201103060637.p266brCX000350@sj-core-3.cisco.com> In-Reply-To: <201103060637.p266brCX000350@sj-core-3.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 07:37:48 -0000 We should explicitly say that we expect that the reader shall understand the specification freely and for example be fre to apply the media requirement in a Media Gateway instead of the endpoint. Can the solution be to include the following in the introduction: "This specification describes a conceptual interface to the PSAP distributed among devices and network components. Service providers who cannot distribute the tasks as specified here shall make sure that their services comply at the interface to the PSAP." The Framework draft has a sentence in that direction where it talks about other signaling protocols. So it is natural to include something similar in Phonebcp. Or, if we focus on media, under 14. Media add: "The following requirements for media shall be met at the interface to the PSAP. If they are not handled directly by the end device, conversion must be possible to take place in the service provider's network." Note "possible". It must still be OK to offer AMR-WB and find that the PSAP luckily supports it, so we do not need to invoke transcoding to G.722. Gunnar James M. Polk skrev 2011-03-06 07:37: > I agree with Henning here. We really cannot really control or reliably > expect that within the existing SW upgradeable "interworking" products > that we can mandate a codec. > > That said, Gunnar is also right, this shouldn't be only an "ED" > requirement. > > Along those lines, I think this requirement, while well intentioned, > falls into the gap between IP and circuit, in which we can't > truthfully say that we "know" this only applies to the IP part - at > least not without rewording to limit this. > > Something needs to state definitively that when the media gets to the > ESRP - via mobile or wired - it needs to be in either the G.711 or > G.722 codec for interoperability sake. That means the cellco mobile > devices can use whatever codec they want, as long as the cellco > converts to 711 or 722 once the media is transcoded to RTP. > > I'm not sure we have a requirement that say exactly that, and I think > we should for this situation. > > James > > At 10:48 AM 3/5/2011, Henning Schulzrinne wrote: >> There's nothing we can do about this problem, particularly given that >> there doesn't appear to be a universal codec for mobile devices. >> Also, I suspect that all mobile calls *today* show up as G.711 by the >> time they reach the ESInet, since they go through a circuit-to-packet >> conversion. Once we have VoIP-over-LTE, it might be appropriate to >> add the most common wideband codec for that configuration to the >> SHOULD list. There doesn't seem to be as much point in adding >> narrowband codecs, since the conversion to G.711 is cheap and no >> quality would be lost in translation. >> >> Henning >> >> On Mar 5, 2011, at 10:24 AM, Brian Rosen wrote: >> >> > Nope, no downside. I can do that. >> > >> > Doesn't handle the problem that started this: mobile phones don't >> do G.711 or G.722 >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hgs@cs.columbia.edu Sun Mar 6 07:15:10 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9B423A67DA for ; Sun, 6 Mar 2011 07:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqG9hO4TW+75 for ; Sun, 6 Mar 2011 07:15:10 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by core3.amsl.com (Postfix) with ESMTP id 21E5F3A67D0 for ; Sun, 6 Mar 2011 07:15:09 -0800 (PST) Received: from new-host.home (pool-173-54-225-113.nwrknj.fios.verizon.net [173.54.225.113]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p26FGJuJ029852 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 6 Mar 2011 10:16:20 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Henning Schulzrinne In-Reply-To: <4D733A08.8090203@omnitor.se> Date: Sun, 6 Mar 2011 10:16:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <768D3007-A938-4215-B603-51250E13796A@cs.columbia.edu> References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> <26E805AD-4D40-4C7E-9C07-56959336B858@cs.columbia.edu> <12E789B1-F912-4459-BBBF-50543811227E@brianrosen.net> <5D628A73-1BCC-4020-82AD-AA50F7F3B970@cs.columbia.edu> <69A77C08-DB6A-4A64-B960-D6EBF2932BCF@brianrosen.net> <5878DF10-7E81-4C00-979C-526FB1732778@cs.columbia.edu> <201103060637.p266brCX000350@sj-core-3.cisco.com> <4D733A08.8090203@omnitor.se> To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= X-Mailer: Apple Mail (2.1082) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: ecrit@ietf.org Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 15:15:10 -0000 On Mar 6, 2011, at 2:38 AM, Gunnar Hellstr=F6m wrote: >=20 >=20 > Note "possible". It must still be OK to offer AMR-WB and find that the = PSAP luckily supports it, so we do not need to invoke transcoding to = G.722. Definitely. The goal of having a mandatory codec list is to prevent = negotiation failure, not to preempt or prevent negotiation. The goal of = the SHOULD list is to increase the chance of negotiation success at the = highest possible quality level. Henning= From forte@att.com Mon Mar 7 08:46:24 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4505A3A699E for ; Mon, 7 Mar 2011 08:46:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.202 X-Spam-Level: X-Spam-Status: No, score=-105.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCPOtqSBvK14 for ; Mon, 7 Mar 2011 08:46:21 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 54E543A6908 for ; Mon, 7 Mar 2011 08:46:21 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: forte@att.com X-Msg-Ref: server-15.tower-119.messagelabs.com!1299516454!7544951!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 8814 invoked from network); 7 Mar 2011 16:47:34 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-15.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Mar 2011 16:47:34 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p27Glukw027392; Mon, 7 Mar 2011 11:47:57 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p27Gls9R027319; Mon, 7 Mar 2011 11:47:54 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p27GlUpR009589; Mon, 7 Mar 2011 11:47:30 -0500 Received: from [151.109.8.240] (ds151-109-8-240.dhcps.ugn.att.com [151.109.8.240]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p27GlNAa009280; Mon, 7 Mar 2011 11:47:24 -0500 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Mon, 07 Mar 2011 11:47:24 -0500 From: "Andrea G. Forte" To: "martin.thomson@andrew.com" Message-ID: Thread-Topic: [RAI] Review of draft-forte-lost-extensions-02 In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3382343247_34472802" Cc: ecrit@ietf.org Subject: [Ecrit] [RAI] Review of draft-forte-lost-extensions-02 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 16:46:24 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3382343247_34472802 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Martin, Thank you for your comments and apologize for my late reply. Please read my responses inline. (Sorry for the duplicate, I forgot to include the ECRIT mailing list in my previous email). -Andrea > From: "Thomson, Martin" > Date: January 24, 2011 8:56:43 PM CST > To: "draft-forte-lost-extensions@tools.ietf.org" > , "rai@ietf.org" > Cc: "rai-ads@tools.ietf.org" > Subject: [RAI] Review of draft-forte-lost-extensions-02 > > Review of draft-forte-lost-extensions-02 > Martin Thomson, 2011-01-25 > > I don't think that I've had the opportunity to comment on this draft > before. There are several issues that I think prevent this draft from > being the basis for interoperable implementations. > > The most significant concern I have arises from the underlying model that > is used to define the extensions to the query. Lack of > clarity on how the draft defines the problem translates into what I think > is a confused solution. > > The solution as described can be made to work, but it relies on > assumptions that are not documented. As documented, there are likely to > be interoperability issues. > > Terminology > Section 3 of this document refines the concept of a service region. > Three concepts are extracted from the basic ideas in RFC 5222: > > 1. services without the concept of a service region (point-based > services that are identified purely by proximity) > > 2. services that serve a geographic area where the geographic area for > different services of the same basic type overlap significantly (for > example, the overlapping serving area of competing home delivery > services) > > 3. services that serve strictly non-overlapping geographic areas for a > particular service (that is, PSAPs) > > The latter two cases are both referred to as "service region" without > qualification. It appears that (2) is the concept intended in most > cases. Some clearer terminology might help. Perhaps if you use "service > boundary" - as RFC 5222 uses it - to refer to the fence that is crossed > where answers might change; and "served region" or to refer to the > geographic area that is served by the particular service instance. > > Thus you can observe that service boundaries might be of limited use > where multiple services of the same type have overlapping served regions. > And you can also observe that some services lack a served area; and for > these services, a service boundary may for different reasons (it's only > the area where the N service instances provided in the answer are closer > than other instances). [AGF] I agree on that clearer terminology might help. In RFC 5222 what you call "served area" is called "service area" as you can infer from reading Section 12.2, for example, while a Service Boundary is the boundary of a Service Region. I will go ahead and rewrite this part taking into consideration such definitions. > > > Extension proposals > RFC 5222 is dreadfully vague on the use of geographic areas in the > element. Particularly when the area intersects with the areas > of multiple services. I have inferred that the idea is that the LoST > server picks the single best choice, because that makes the most sense > for emergency uses (no good comes from presenting a choice in these > cases). [AGF] What you infer is not correct. The LoST protocol has been designed to support both emergency and non-emergency services. You can read in RFC5222, Section 12.2 the following: "A server MAY return multiple elements if the shape extends across multiple service areas.". I know of some LoST servers behaving like this also for emergency services so that when the user location overlaps between two PSAP boundaries, both PSAPs are returned by the LoST server. > > What this draft proposes for "within X" relies on some sort of implicit > processing that is inconsistent with RFC5222. It relies on the fact that > the LoST server knows that a particular service is somehow special. [AGF] Currently the "within X" query is the default query so that unless you specify the element to be true it will treat it as "within X" query. The LoST server does not need to have some implicit knowledge. I think it is a good idea though to assume that when the element is missing, it is assumed to be true rather than false. This will make the default query a "served by" query thus making the behavior consistent with RFC 5222 for emergency services (which use a "served by" query). > > This doesn't make for very clear protocol semantics. It's probably still > viable, but the document needs to make this assumption clear. > > I'm not sure how this out-of-band information interacts with recursive > resolution. A LoST gateway that performs recursive lookups might not be > able make the right choice without an explicit, in-band indication of > intent. [AGF] This does not apply as per comments above. > > Attempting to overload the element as described in Section 5.1 > does not make for clear protocol semantics. [AGF] Practically it is the same problem. I want to search for points of service within that region because my location is within that region (with a certain probability). Let me rephrase it. We can think of the area of uncertainty in a shape as the probability that a user might be within that area and so we want to look for services within that area. All we are doing with a "within X" query is to manually set the uncertainty level in user location. The semantics are the same. > > > My reading of RFC5222 leads me to infer that there is an implicit > parameter in the protocol that is set to 1. There's always > the possibility that a location with uncertainty overlaps the served area > of multiple PSAPs - but LoST assumes that there is only one right answer. > > It seems like the right way to approach the proposed extensions is to > lift the implied limit beyond 1. Adding the element seems > like the right thing to do, but the semantics that I associate with > element doesn't seem to fit. > > I'd encourage the authors to re-examine the basic model they are using to > construct their proposed solution. [AGF] I think I have already addressed this in a previous comment. As we can read in RFC5222 in Section 12.2, the LoST server MAY return multiple mapping elements therefore there is no such thing as an implicit limit to 1. Since there is a MAY in the sentence, the implicit limit has to be assumed to be equal to "no limit". As such, what we propose is semantically correct. Limits of current implementations should not be a limit for the design of new protocols. You are thinking about emergency services but LoST was designed also for non-emergency services, so it makes sense that RFC 5222 allows LoST to return multiple elements. > > > Section 5.3 seems very confused for these reasons. A simpler model would > require less explanation. > > On > Section 5.4 states: > > When the element is not present in a query then > all available points of interest for the requested type of service > SHALL be returned by the LoST server. > > Which seems contrary to what is implicit in RFC5222. See above. [AGF] It is not contrary. See my comment above. > > > On > The admonition: > > [...] Only geodetic profiles SHOULD be used [...] > > ... and subsequent use of an unwrapped element in the > element is strange. How is a civic address not the location of > the service? If there are multiple forms of location, it would be better > to use similar guidance to what is in RFC5491: > > 1. recommend multiple elements when there are > multiple forms available > > 2. recommend that a geodetic form is provided where possible [AGF] Yes, I agree. > > > The location profile can be used to identify which location you want to > use if the content of the element is not sufficient. [AGF] I am not sure what you mean by this. > > > The reason given for these recommendations: > > [...] as the computation of the distance, route and other metrics > would at some point require geocoding of the civic address in > geodetic coordinates. Because of this, the position specified in > SHOULD be represented by using the element. > > ... is not necessary for interoperability. This seems more for the > convenience of LoST server implementations. Wouldn't these reasons be > better suited to a LoST server provisioning guide? > > A better reason might be that a recipient of the mapping information > might need to use this information without the necessary context to > understand the civic address. However, the same reason doesn't support > the recommendation for using a . [AGF] There might be situations where the client would want to perform some light computations on location information but without having enough "power" to do geo encoding/decoding. > > > Iterative Responses > The use of iterative resolution in LoST is a weak point that the ability > to provide multiple mappings does not help. In the case where a server > is able to provide only some answers, there is no facility for the server > to indicate where the remainder of the answers are found (that is, the > referral). [AGF] I am not sure I follow. The authoritative server for that region and for that class of service will reply with the results. Iteration continues only until an authoritative server is found. > > > Even if you can address that concern, there's also the concern that the > referred LoST server is able to provide better (closer) answers than the > ones provided. The draft might offer guidance on how to resolve this > issue. [AGF] I still do not understand the issue. From RFC5222, Section 8.3.3 you can read: "In Iterative mode, the server contacted returns a redirection response indicating the next server to be queried if the server contacted cannot provide an answer itself." > > > Security > The security section could use some expansion. It's not sufficient to > just refer to RFC5222. > > The denial of service concerns that Shida raised in his review are worth > discussing. A LoST server is discovered using the same means whether it > be for emergency or commercial uses. The possibility that commercial > uses could interfere with public safety is a significant concern. As > Shida notes, scaling is probably trivial to address, but that's not the > whole story. [AGF] I am very skeptical about this. >From a regulatory perspective: the NG911 infrastructure is mostly paid and maintained by collecting 911 fees that tax payers have to pay. I do not think LoST servers paid with tax payers money for 911 can be used for supporting non-911 services. >From a security perspective: in the most general case, let's assume we have two different LoST servers, one used by the NG911 client to discover the correct ESRP and one used by the ESRP to discover the correct PSAP. The second LoST server would be inside the ESInet thus behind a firewall. Access to this LoST server would be granted only to known ESRPs via access control lists (this is how many vendors have it implemented) or similar. The first LoST server will be more reachable than the second one as it does not have to be necessarily in the ESInet. This, however, can be configured to only support urn:service:sos as type of service and will be an authoritative server for this type of service only (given the regulatory issues mentioned above and security concerns). At this point, the same security considerations as in RFC5222 apply. > > > We've seen problems that overwhelm a system, despite calculations > predicting ample capacity, simply due to high demand for a particular > application that is poorly configured. Specific mechanisms to protect > public safety queries might be difficult to design, but the document > should at a minimum acknowledge the problem. [AGF] We could indeed include the discussion above in the draft. > > > Nits: > Section 5.2 - typo: wether > > Most of the examples use http://www.thisisnotdoneyet.net/lostNe still. > > Using a namespace prefix of "gml" rather than "p2" would be more helpful > to the reader. Consistent use of namespace prefixes throughout would > also help disambiguate the three or so namespaces used. > > --Martin > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai --B_3382343247_34472802 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Martin,

Thank you fo= r your comments and apologize for my late reply. Please read my responses in= line.
(Sorry for the duplicate, I forgot to inc= lude the ECRIT mailing list in my previous email).

-Andrea


From: "Thomson, Martin" <= Martin.Thomson@andrew.com>
Date: <= /b>January 2= 4, 2011 8:56:43 PM CST
Subject: <= /span>[RAI] Revi= ew of draft-forte-lost-extensions-02

Review of = draft-forte-lost-extensions-02
Martin Thomson, 2011-01-25

 I= don't think that I've had the opportunity to comment on this draft
&nbs= p;before.  There are several issues that I think prevent this draft fro= m
 being the basis for interoperable implementations.

 = ;The most significant concern I have arises from the underlying model that  is used to define the extensions to the <findService> query. =  Lack of
 clarity on how the draft defines the problem transla= tes into what I think
 is a confused solution.

 The so= lution as described can be made to work, but it relies on
 assumpti= ons that are not documented.  As documented, there are likely to
&n= bsp;be interoperability issues.

Terminology
 Section 3 of th= is document refines the concept of a service region.
 Three concept= s are extracted from the basic ideas in RFC 5222:

   = 1. services without the concept of a service region (point-based
 &= nbsp;    services that are identified purely by proximit= y)

   2. services that serve a geographic area where = the geographic area for
      different se= rvices of the same basic type overlap significantly (for
  &nb= sp;   example, the overlapping serving area of competing home= delivery
      services)

 &n= bsp; 3. services that serve strictly non-overlapping geographic areas f= or a
      particular service (that is, PS= APs)

 The latter two cases are both referred to as "service reg= ion" without
 qualification.  It appears that (2) is the conce= pt intended in most
 cases.  Some clearer terminology might he= lp.  Perhaps if you use "service
 boundary" - as RFC 5222 uses= it - to refer to the fence that is crossed
 where answers might ch= ange; and "served region" or to refer to the
 geographic area that = is served by the particular service instance.

 Thus you can obs= erve that service boundaries might be of limited use
 where multipl= e services of the same type have overlapping served regions.
 And y= ou can also observe that some services lack a served area; and for
 = ;these services, a service boundary may for different reasons (it's only
=  the area where the N service instances provided in the answer are clo= ser
 than other instances).
[AGF]
I agree on that clearer terminology might hel= p.
In RFC 5222 what you call "served area" is called "service area= " as you can infer from reading Section 12.2, for example, while 
=
a Service Boundary is the boundary of a Service Region. I will go ahead= and rewrite this part taking into consideration such 
defini= tions.



Extension propo= sals
 RFC 5222 is dreadfully vague on the use of geographic areas i= n the
 <location> element.  Particularly when the area i= ntersects with the areas
 of multiple services.  I have inferr= ed that the idea is that the LoST
 server picks the single best cho= ice, because that makes the most sense
 for emergency uses (no good= comes from presenting a choice in these
 cases).
[AGF]
What you infer is n= ot correct. 
The LoST protocol has been designed to support b= oth emergency and non-emergency services.
You can read in RFC5222,= Section 12.2 the following: "A server MAY return multiple <mapping>&n= bsp;
elements if the shape extends across multiple service areas."= . I know of some LoST servers behaving 
like this also for em= ergency services so that when the user location overlaps between two PSAP&nb= sp;
boundaries, both PSAPs are returned by the LoST server.
<= div>

 What this draft proposes = for "within X" relies on some sort of implicit
 processing that is = inconsistent with RFC5222.  It relies on the fact that
 the Lo= ST server knows that a particular service is somehow special.
[AGF]
Currently the "w= ithin X" query is the default query so that unless you specify 
the <region> element to be true it will treat it as "within X" quer= y. The LoST server does not need 
to have some implicit knowl= edge.
I think it is a good idea though to assume that when the <= ;region> element is missing, it is assumed to 
be true rat= her than false. This will make the default query a "served by" query thus ma= king the behavior
consistent with RFC 5222 for emergency services = (which use a "served by" query).


 This doesn't make for very clear protocol semantics.  It'= s probably still
 viable, but the document needs to make this assum= ption clear.

 I'm not sure how this out-of-band information int= eracts with recursive
 resolution.  A LoST gateway that perfor= ms recursive lookups might not be
 able make the right choice witho= ut an explicit, in-band indication of
 intent.
[AGF]
This does not apply as= per comments above.


&nbs= p;Attempting to overload the <location> element as described in Sectio= n 5.1
 does not make for clear protocol semantics.
[AGF]
Practically it is= the same problem. I want to search for points of service within that region= because my 
location is within that region (with a certain p= robability).

Let me rephrase it.
We= can think of the area of uncertainty in a shape as the probability that a u= ser might be within 
that area and so we want to look for ser= vices within that area.
All we are doing with a "within X" query i= s to manually set the uncertainty level in user location. 
Th= e semantics are the same.


 My r= eading of RFC5222 leads me to infer that there is an implicit
 <= le:limit> parameter in the protocol that is set to 1.  There's alway= s
 the possibility that a location with uncertainty overlaps the se= rved area
 of multiple PSAPs - but LoST assumes that there is only = one right answer.

 It seems like the right way to approach the = proposed extensions is to
 lift the implied limit beyond 1.  A= dding the <le:limit> element seems
 like the right thing to d= o, but the semantics that I associate with
 <le:region> eleme= nt doesn't seem to fit.

 I'd encourage the authors to re-examin= e the basic model they are using to
 construct their proposed solut= ion.
[AGF]
I= think I have already addressed this in a previous comment. As we can read i= n RFC5222 in Section 12.2, the LoST server MAY return 
multip= le mapping elements therefore there is no such thing as an implicit limit to= 1. Since there is a MAY in the sentence, the implicit 
limit= has to be assumed to be equal to "no limit". As such, what we propose is se= mantically correct.
Limits of current implementations should not b= e a limit for the design of new protocols. You are thinking about emergency = services but LoST 
was designed also for non-emergency servic= es, so it makes sense that RFC 5222 allows LoST to return multiple <mappi= ng> elements.




 Section 5.3 seems very confused for these reasons.  A = simpler model would
 require less explanation.

On <le:lim= it>
 Section 5.4 states:

  When the <limit&= gt; element is not present in a <findService> query then
 &nb= sp;all available points of interest for the requested type of service
&n= bsp; SHALL be returned by the LoST server.

 Which seems co= ntrary to what is implicit in RFC5222.  See above.
[AGF]
It is not contrary. See my= comment above.



On <= ;le:serviceLocation>
 The admonition:

  [...] = Only geodetic profiles SHOULD be used [...]

 ... and subsequent= use of an unwrapped <ca:civicAddress> element in the
 <ma= pping> element is strange.  How is a civic address not the location = of
 the service?  If there are multiple forms of location, it = would be better
 to use similar guidance to what is in RFC5491:
=
   1. recommend multiple <le:serviceLocation> elem= ents when there are
      multiple forms a= vailable

   2. recommend that a geodetic form is prov= ided where possible
[A= GF]
Yes, I agree.


 Th= e location profile can be used to identify which location you want to
&n= bsp;use if the content of the element is not sufficient.
<= /div>
[AGF]
I am not sure what you me= an by this.



 The= reason given for these recommendations:

   [...] as = the computation of the distance, route and other metrics
  wou= ld at some point require geocoding of the civic address in
  g= eodetic coordinates.  Because of this, the position specified in
&n= bsp; <serviceLocation> SHOULD be represented by using the <Poi= nt> element.

 ... is not necessary for interoperability. &nb= sp;This seems more for the
 convenience of LoST server implementati= ons.  Wouldn't these reasons be
 better suited to a LoST serve= r provisioning guide?

 A better reason might be that a recipien= t of the mapping information
 might need to use this information wi= thout the necessary context to
 understand the civic address.  = ;However, the same reason doesn't support
 the recommendation for u= sing a <gml:Point>.
<= div>[AGF]
There might be situations where the client would want to perform some light computations on l= ocation information 
but without having enough "power" to do = geo encoding/decoding.

<= div>

Iterative Responses
 The use of iterative resolution in LoST is a = weak point that the ability
 to provide multiple mappings does not = help.  In the case where a server
 is able to provide only som= e answers, there is no facility for the server
 to indicate where t= he remainder of the answers are found (that is, the
 referral).
[AGF]
I am not = sure I follow. The authoritative server for that region and for that class o= f service will reply 
with the results. Iteration continues o= nly until an authoritative server is found.



 Even if you can address that concern, there's a= lso the concern that the
 referred LoST server is able to provide b= etter (closer) answers than the
 ones provided.  The draft mig= ht offer guidance on how to resolve this
 issue.
=
[AGF]
I still do not understan= d the issue. From RFC5222, Section 8.3.3 you can read: "In Iterative mode,
the server contacted returns a redirection response indicating the = next server to be queried if the 
server contacted cannot pro= vide an answer itself."


Security
=  The security section could use some expansion.  It's not sufficie= nt to
 just refer to RFC5222.

 The denial of service c= oncerns that Shida raised in his review are worth
 discussing. &nbs= p;A LoST server is discovered using the same means whether it
 be f= or emergency or commercial uses.  The possibility that commercial
&= nbsp;uses could interfere with public safety is a significant concern.  = ;As
 Shida notes, scaling is probably trivial to address, but that'= s not the
 whole story.
<= /span>
[AGF]
I am very skeptical about this. 
<= br>
From a regulatory perspective: the NG911 infrastructure is mos= tly paid and maintained by collecting 911 fees that tax payers 
have to pay. I do not think LoST servers paid with tax payers money for 9= 11 can be used for supporting non-911 services.

Fro= m a security perspective:  in the most general case, let's assume we ha= ve two different LoST servers, one used by the NG911 client to discover the&= nbsp;
correct ESRP and one used by the ESRP to discover the correc= t PSAP. The second LoST server would be inside the ESInet thus 
behind a firewall. Access to this LoST server would be granted only to kn= own ESRPs via access control lists (this is how many
vendors have = it implemented) or similar. The first LoST server will be more reachable tha= n the second one as it does not have to be necessarily in the 
ESInet. This, however, can be configured to only support urn:service:sos a= s type of service and will be an authoritative server for 
th= is type of service only (given the regulatory issues mentioned above and sec= urity concerns).
At this point, the same security considerations a= s in RFC5222 apply.


=


 We've seen problems that overwhelm a system, despite cal= culations
 predicting ample capacity, simply due to high demand for= a particular
 application that is poorly configured.  Specifi= c mechanisms to protect
 public safety queries might be difficult t= o design, but the document
 should at a minimum acknowledge the pro= blem.
[AGF]
= We could indeed include the discussion above in the draft.




Nits:
 Section = 5.2 - typo: wether

 Most of the examples use http://www.thisisnotdoneyet.net/lostNe st= ill.

 Using a namespace prefix of "gml" rather than "p2" would = be more helpful
 to the reader.  Consistent use of namespace p= refixes throughout would
 also help disambiguate the three or so na= mespaces used.

--Martin
__________________________________________= _____
RAI mailing list
RAI@ietf.org<= br>https://www.ietf.org/= mailman/listinfo/rai

<= /span>
 --B_3382343247_34472802-- From Martin.Dawson@andrew.com Mon Mar 7 19:34:59 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E959C3A68AE for ; Mon, 7 Mar 2011 19:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FcRlu9EisKS for ; Mon, 7 Mar 2011 19:34:58 -0800 (PST) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id E521E3A681E for ; Mon, 7 Mar 2011 19:34:57 -0800 (PST) X-AuditID: 0a0404e8-b7b33ae0000009d1-3e-4d75a42f6584 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 05.BE.02513.F24A57D4; Mon, 7 Mar 2011 21:36:15 -0600 (CST) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 7 Mar 2011 21:36:10 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 8 Mar 2011 11:34:43 +0800 From: "Dawson, Martin" To: "James M. Polk" , Henning Schulzrinne , Brian Rosen Date: Tue, 8 Mar 2011 11:34:42 +0800 Thread-Topic: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt Thread-Index: AcvbyQ3Te6owU+mATUG9EFbHv95PeQBeEW+A Message-ID: <8B0A9FCBB9832F43971E38010638454F0400B68462@SISPE7MB1.commscope.com> References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> <26E805AD-4D40-4C7E-9C07-56959336B858@cs.columbia.edu> <12E789B1-F912-4459-BBBF-50543811227E@brianrosen.net> <5D628A73-1BCC-4020-82AD-AA50F7F3B970@cs.columbia.edu> <69A77C08-DB6A-4A64-B960-D6EBF2932BCF@brianrosen.net> <5878DF10-7E81-4C00-979C-526FB1732778@cs.columbia.edu> <201103060637.p266brCX000350@sj-core-3.cisco.com> In-Reply-To: <201103060637.p266brCX000350@sj-core-3.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "DRAGE, Keith \(Keith\)" , 'ecrit Org' Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 03:35:00 -0000 I agree with this. I'll go out on a limb and confess I don't understand why the point of (circ= uit service) mobile codecs came up anyway. These are air interface codecs a= nd they will have been transcoded by the time the traffic hits the circuits= in the core network anyway. I'm struggling to see why they are pertinent t= o the spec at all. Cheers, Martin -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of J= ames M. Polk Sent: Sunday, 6 March 2011 5:38 PM To: Henning Schulzrinne; Brian Rosen Cc: DRAGE, Keith (Keith); 'ecrit Org' Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt I agree with Henning here. We really cannot really control or=20 reliably expect that within the existing SW upgradeable=20 "interworking" products that we can mandate a codec. That said, Gunnar is also right, this shouldn't be only an "ED" requirement= . Along those lines, I think this requirement, while well intentioned,=20 falls into the gap between IP and circuit, in which we can't=20 truthfully say that we "know" this only applies to the IP part - at=20 least not without rewording to limit this. Something needs to state definitively that when the media gets to the=20 ESRP - via mobile or wired - it needs to be in either the G.711 or=20 G.722 codec for interoperability sake. That means the cellco mobile=20 devices can use whatever codec they want, as long as the cellco=20 converts to 711 or 722 once the media is transcoded to RTP. I'm not sure we have a requirement that say exactly that, and I think=20 we should for this situation. James At 10:48 AM 3/5/2011, Henning Schulzrinne wrote: >There's nothing we can do about this problem, particularly given=20 >that there doesn't appear to be a universal codec for mobile=20 >devices. Also, I suspect that all mobile calls *today* show up as=20 >G.711 by the time they reach the ESInet, since they go through a=20 >circuit-to-packet conversion. Once we have VoIP-over-LTE, it might=20 >be appropriate to add the most common wideband codec for that=20 >configuration to the SHOULD list. There doesn't seem to be as much=20 >point in adding narrowband codecs, since the conversion to G.711 is=20 >cheap and no quality would be lost in translation. > >Henning > >On Mar 5, 2011, at 10:24 AM, Brian Rosen wrote: > > > Nope, no downside. I can do that. > > > > Doesn't handle the problem that started this: mobile phones don't=20 > do G.711 or G.722 > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From gunnar.hellstrom@omnitor.se Tue Mar 8 01:58:51 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C4A3A67DA for ; Tue, 8 Mar 2011 01:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVBH+SZ4Rz4P for ; Tue, 8 Mar 2011 01:58:50 -0800 (PST) Received: from vsp-outgoing1.binero.net (vsp-outgoing1.binero.net [193.17.218.160]) by core3.amsl.com (Postfix) with SMTP id 0E6483A67C0 for ; Tue, 8 Mar 2011 01:58:48 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.39.229]) by vsp-outgoing1.binero.net (Halon Mail Gateway) with ESMTP for ; Tue, 8 Mar 2011 10:59:55 +0100 (CET) Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-06-01.atm.binero.net (Postfix) with ESMTPA id 2D1573A123; Tue, 8 Mar 2011 10:59:55 +0100 (CET) Message-ID: <4D75FE1E.3010008@omnitor.se> Date: Tue, 08 Mar 2011 10:59:58 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: ecrit@ietf.org References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> <26E805AD-4D40-4C7E-9C07-56959336B858@cs.columbia.edu> <12E789B1-F912-4459-BBBF-50543811227E@brianrosen.net> <5D628A73-1BCC-4020-82AD-AA50F7F3B970@cs.columbia.edu> <69A77C08-DB6A-4A64-B960-D6EBF2932BCF@brianrosen.net> <5878DF10-7E81-4C00-979C-526FB1732778@cs.columbia.edu> <201103060637.p266brCX000350@sj-core-3.cisco.com> <8B0A9FCBB9832F43971E38010638454F0400B68462@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0400B68462@SISPE7MB1.commscope.com> Content-Type: multipart/alternative; boundary="------------010108040601050409060706" Cc: Martin.Dawson@andrew.com Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 09:58:51 -0000 This is a multi-part message in MIME format. --------------010108040601050409060706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We do not need to go to circuit switched mobile networks to find needs to use other codecs than G.711 in endpoints. There are plenty of other situations when a service provider want to keep the endpoints simple, and can accept the responsibility to do any transcoding needed in the network. As a more simple example, in line with the original intentions of Phonebcp, I can imagine that there are VoIP providers who want to have the endpoints use only iLBC and introduce transcoding to whatever is available in the PSAP interface in their networks. Many comments have indicated that transcoding in the network is to be expected. The draft should reflect this view. The same reasoning applies to the other media: real-time text, text messaging and video. Many points in the draft has already shared responsibility between various nodes declared. There are many ED-x/INT-y or ED-z/SP-q requirements indicating that responsibility to behave as the PSAP interface requires can be placed either in the end device or the network. Chapter 5 about identifying emergency calls is a good example of shared responsibility between ED and SP. Something similar should be done for chapter 14. After reading the draft, I am not sure if the SP-x requirements are administrative responsibilities on the service provider, or real actions anywhere in the service provider network. Assuming that SP-x requirements are suitable for this case, I want to propose the following slightly modified text for Chapter 14 to allow transcoding, and also that guaranteed support of other codecs can be decided later: -------------------------------------------------------------------------------------------- 14. Media The service provider MUST make sure that the media types supported by both the PSAPs and the endpoints are negotiated, coded and transported according to commonly supported specifications. Alignment with what PSAPs support may be done directly in the endpoint or in the service providers network. This chapter provides the minimum set of media types and codecs that PSAPs are guaranteed to handle. Extensions are possible by local, regional or global agreements. ED-71/SP-41 Media streams MUST be sent and received on RTP [RFC3550]. ED-72/SP-42 Normal SIP offer/answer [RFC3264] negotiations MUST be used to agree on the media streams to be used. ED-73/SP-43 For endpoints supporting voice, G.722 or G.711 A law (and mu Law if they are intended be used in North America) encoded voice as described in [RFC3551] MUST be supported either directly by the endpoint or through conversion by the service provider. It is desirable to include other wideband codecs such as AMR-WB in the offer. ED-74/SP-44 Silence suppression (Voice Activity Detection methods) MUST NOT be used on emergency calls. PSAP call takers sometimes get information on what is happening in the background to determine how to process the call. ED-75/SP-45 For endpoints supporting Instant Messaging (IM) either [RFC3428] or [RFC4975] MUST be supported directly by the endpoint or through conversion by the service provider. ED-76/SP-46 For endpoints supporting real-time text, [RFC4103] MUST be supported either directly by the endpoint or through conversion by the service provider. The expectations for emergency service support for the real-time text medium are described in [RFC5194], Section 7.1. ED-77/SP-47 For endpoints supporting video, H.264 per [I-D.ietf-avt-rtp-rfc3984bis] MUST be supported either directly by the endpoint or through conversion by the service provider. ------------------------------------------------------------------------------------------ /Gunnar Dawson, Martin skrev 2011-03-08 04:34: > I agree with this. > > I'll go out on a limb and confess I don't understand why the point of (circuit service) mobile codecs came up anyway. These are air interface codecs and they will have been transcoded by the time the traffic hits the circuits in the core network anyway. I'm struggling to see why they are pertinent to the spec at all. > > Cheers, > Martin > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James M. Polk > Sent: Sunday, 6 March 2011 5:38 PM > To: Henning Schulzrinne; Brian Rosen > Cc: DRAGE, Keith (Keith); 'ecrit Org' > Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt > > I agree with Henning here. We really cannot really control or > reliably expect that within the existing SW upgradeable > "interworking" products that we can mandate a codec. > > That said, Gunnar is also right, this shouldn't be only an "ED" requirement. > > Along those lines, I think this requirement, while well intentioned, > falls into the gap between IP and circuit, in which we can't > truthfully say that we "know" this only applies to the IP part - at > least not without rewording to limit this. > > Something needs to state definitively that when the media gets to the > ESRP - via mobile or wired - it needs to be in either the G.711 or > G.722 codec for interoperability sake. That means the cellco mobile > devices can use whatever codec they want, as long as the cellco > converts to 711 or 722 once the media is transcoded to RTP. > > I'm not sure we have a requirement that say exactly that, and I think > we should for this situation. > > James > > At 10:48 AM 3/5/2011, Henning Schulzrinne wrote: >> There's nothing we can do about this problem, particularly given >> that there doesn't appear to be a universal codec for mobile >> devices. Also, I suspect that all mobile calls *today* show up as >> G.711 by the time they reach the ESInet, since they go through a >> circuit-to-packet conversion. Once we have VoIP-over-LTE, it might >> be appropriate to add the most common wideband codec for that >> configuration to the SHOULD list. There doesn't seem to be as much >> point in adding narrowband codecs, since the conversion to G.711 is >> cheap and no quality would be lost in translation. >> >> Henning >> >> On Mar 5, 2011, at 10:24 AM, Brian Rosen wrote: >> >>> Nope, no downside. I can do that. >>> >>> Doesn't handle the problem that started this: mobile phones don't >> do G.711 or G.722 >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --------------010108040601050409060706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit We do not need to go to circuit switched mobile networks to find needs to use other codecs than G.711 in endpoints.

There are plenty of other situations when a service provider want to keep the endpoints simple, and can accept the responsibility to do any transcoding needed in the network. As a more simple example, in line with the original intentions of Phonebcp, I can imagine that there are VoIP providers who want to have the endpoints use only iLBC and introduce transcoding to whatever is available in the PSAP interface in their networks.

Many comments have indicated that transcoding in the network is to be expected. The draft should reflect this view.

The same reasoning applies to the other media: real-time text, text messaging and video.

Many points in the draft has already shared responsibility between various nodes declared. There are many ED-x/INT-y or ED-z/SP-q requirements indicating that responsibility to behave as the PSAP interface requires can be placed either in the end device or the network.

Chapter 5 about identifying emergency calls is a good example of shared responsibility between ED and SP.

Something similar should be done for chapter 14.

After reading the draft, I am not sure if the SP-x requirements are administrative responsibilities on the service provider, or real actions anywhere in the service provider network.
Assuming that SP-x requirements are suitable for this case, I want to propose the following slightly modified text for Chapter 14 to allow transcoding,  and also that guaranteed support of other codecs can be decided later:

--------------------------------------------------------------------------------------------
14. Media

The service provider MUST make sure that the media types supported by both the PSAPs and the endpoints are negotiated, coded and transported according to commonly supported specifications. Alignment with what PSAPs support may be done directly in the endpoint or in the service providers network.
This chapter provides the minimum set of media types and codecs that PSAPs are guaranteed to handle. Extensions are possible by local, regional or global agreements.

ED-71/SP-41 Media streams MUST be sent and received on RTP [RFC3550].
 
ED-72/SP-42 Normal SIP offer/answer [RFC3264] negotiations MUST be used to agree on the media streams to be used.

ED-73/SP-43 For endpoints supporting voice, G.722 or G.711 A law (and mu Law if they are intended be used in North America) encoded voice as described in [RFC3551] MUST be supported either directly by the endpoint or through conversion by the service provider. It is desirable to include other wideband codecs such as AMR-WB in the offer.

ED-74/SP-44 Silence suppression (Voice Activity Detection methods) MUST NOT be used on emergency calls. PSAP call takers sometimes get information on what is happening in the background to determine how to process the call.  

ED-75/SP-45 For endpoints supporting Instant Messaging (IM) either [RFC3428] or [RFC4975] MUST be supported directly by the endpoint or through conversion by the service provider.

ED-76/SP-46 For endpoints supporting real-time text, [RFC4103] MUST be supported either directly by the endpoint or through conversion by the service provider. The expectations for emergency service support for the real-time text medium are described in [RFC5194], Section 7.1. 

ED-77/SP-47 For endpoints supporting video, H.264 per [I-D.ietf-avt-rtp-rfc3984bis] MUST be supported either directly by the endpoint or through conversion by the service provider.

 
------------------------------------------------------------------------------------------
 
/Gunnar


Dawson, Martin skrev 2011-03-08 04:34: 
I agree with this.

I'll go out on a limb and confess I don't understand why the point of (circuit service) mobile codecs came up anyway. These are air interface codecs and they will have been transcoded by the time the traffic hits the circuits in the core network anyway. I'm struggling to see why they are pertinent to the spec at all.

Cheers,
Martin

-----Original Message-----
From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James M. Polk
Sent: Sunday, 6 March 2011 5:38 PM
To: Henning Schulzrinne; Brian Rosen
Cc: DRAGE, Keith (Keith); 'ecrit Org'
Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt

I agree with Henning here. We really cannot really control or 
reliably expect that within the existing SW upgradeable 
"interworking" products that we can mandate a codec.

That said, Gunnar is also right, this shouldn't be only an "ED" requirement.

Along those lines, I think this requirement, while well intentioned, 
falls into the gap between IP and circuit, in which we can't 
truthfully say that we "know" this only applies to the IP part - at 
least not without rewording to limit this.

Something needs to state definitively that when the media gets to the 
ESRP - via mobile or wired - it needs to be in either the G.711 or 
G.722 codec for interoperability sake. That means the cellco mobile 
devices can use whatever codec they want, as long as the cellco 
converts to 711 or 722 once the media is transcoded to RTP.

I'm not sure we have a requirement that say exactly that, and I think 
we should for this situation.

James

At 10:48 AM 3/5/2011, Henning Schulzrinne wrote:

There's nothing we can do about this problem, particularly given 
that there doesn't appear to be a universal codec for mobile 
devices. Also, I suspect that all mobile calls *today* show up as 
G.711 by the time they reach the ESInet, since they go through a 
circuit-to-packet conversion. Once we have VoIP-over-LTE, it might 
be appropriate to add the most common wideband codec for that 
configuration to the SHOULD list. There doesn't seem to be as much 
point in adding narrowband codecs, since the conversion to G.711 is 
cheap and no quality would be lost in translation.

Henning

On Mar 5, 2011, at 10:24 AM, Brian Rosen wrote:


Nope, no downside.  I can do that.

Doesn't handle the problem that started this: mobile phones don't 

do G.711 or G.722

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

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
--------------010108040601050409060706-- From Martin.Thomson@andrew.com Tue Mar 8 15:19:19 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D50E3A67AB for ; Tue, 8 Mar 2011 15:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEpYwXekbfdh for ; Tue, 8 Mar 2011 15:19:17 -0800 (PST) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id 7074F3A659B for ; Tue, 8 Mar 2011 15:19:17 -0800 (PST) X-AuditID: 0a0404e8-b7b22ae000004e95-a6-4d76b9c42e90 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 0C.05.20117.4C9B67D4; Tue, 8 Mar 2011 17:20:37 -0600 (CST) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Tue, 8 Mar 2011 17:20:32 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 9 Mar 2011 07:20:28 +0800 From: "Thomson, Martin" To: "Andrea G. Forte" Date: Wed, 9 Mar 2011 07:20:26 +0800 Thread-Topic: [RAI] Review of draft-forte-lost-extensions-02 Thread-Index: Acvc52ysA4FTKO+cRnSv4hObBBQ7agA/mExg Message-ID: <8B0A9FCBB9832F43971E38010638454F0400B68569@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "draft-forte-lost-extensions@tools.ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] [RAI] Review of draft-forte-lost-extensions-02 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 23:19:19 -0000 It's been a while since I sent the original email, so this might take a lit= tle while to process. On 2011-03-08 at 03:47:24, Andrea G. Forte wrote: > Martin, >=20 > Thank you for your comments and apologize for my late reply. Please=20 > read my responses inline. > (Sorry for the duplicate, I forgot to include the ECRIT mailing list=20 > in my previous email). >=20 > -Andrea >=20 >=20 >=20 > From: "Thomson, Martin" >=20 > Date: January 24, 2011 8:56:43 PM CST >=20 > To: "draft-forte-lost-extensions@tools.ietf.org" > , "rai@ietf.org" > >=20 > Cc: "rai-ads@tools.ietf.org" >=20 > Subject: [RAI] Review of draft-forte-lost-extensions-02 >=20 >=20 > Review of draft-forte-lost-extensions-02 > Martin Thomson, 2011-01-25 >=20 > I don't think that I've had the opportunity to comment on this draft > before. There are several issues that I think prevent this draft=20 > from > being the basis for interoperable implementations. >=20 > The most significant concern I have arises from the underlying model=20 > that > is used to define the extensions to the query. > Lack of > clarity on how the draft defines the problem translates into what I=20 > think > is a confused solution. >=20 > The solution as described can be made to work, but it relies on > assumptions that are not documented. As documented, there are=20 > likely to > be interoperability issues. >=20 > Terminology > Section 3 of this document refines the concept of a service region. > Three concepts are extracted from the basic ideas in RFC 5222: >=20 > 1. services without the concept of a service region (point- based > services that are identified purely by proximity) >=20 > 2. services that serve a geographic area where the geographic area=20 > for > different services of the same basic type overlap significantly=20 > (for > example, the overlapping serving area of competing home=20 > delivery > services) >=20 > 3. services that serve strictly non-overlapping geographic areas=20 > for a > particular service (that is, PSAPs) >=20 > The latter two cases are both referred to as "service region" > without > qualification. It appears that (2) is the concept intended in most > cases. Some clearer terminology might help. Perhaps if you use=20 > "service > boundary" - as RFC 5222 uses it - to refer to the fence that is=20 > crossed > where answers might change; and "served region" or to refer to the > geographic area that is served by the particular service instance. >=20 > Thus you can observe that service boundaries might be of limited use > where multiple services of the same type have overlapping served=20 > regions. > And you can also observe that some services lack a served area; and=20 > for > these services, a service boundary may for different reasons (it's=20 > only > the area where the N service instances provided in the answer are=20 > closer > than other instances). >=20 > [AGF] > I agree on that clearer terminology might help. > In RFC 5222 what you call "served area" is called "service area" as=20 > you can infer from reading Section 12.2, for example, while a Service=20 > Boundary is the boundary of a Service Region. I will go ahead and=20 > rewrite this part taking into consideration such definitions. >=20 >=20 >=20 >=20 > Extension proposals > RFC 5222 is dreadfully vague on the use of geographic areas in the > element. Particularly when the area intersects with the=20 > areas > of multiple services. I have inferred that the idea is that the=20 > LoST > server picks the single best choice, because that makes the most=20 > sense > for emergency uses (no good comes from presenting a choice in these > cases). >=20 >=20 > [AGF] > What you infer is not correct. > The LoST protocol has been designed to support both emergency and non-=20 > emergency services. > You can read in RFC5222, Section 12.2 the following: "A server MAY=20 > return multiple elements if the shape extends across=20 > multiple service areas.". I know of some LoST servers behaving like=20 > this also for emergency services so that when the user location=20 > overlaps between two PSAP boundaries, both PSAPs are returned by the LoST= server. >=20 >=20 >=20 > What this draft proposes for "within X" relies on some sort of=20 > implicit > processing that is inconsistent with RFC5222. It relies on the fact=20 > that > the LoST server knows that a particular service is somehow special. >=20 >=20 > [AGF] > Currently the "within X" query is the default query so that unless you=20 > specify the element to be true it will treat it as "within X" > query. > The LoST server does not need > to have some implicit knowledge. > I think it is a good idea though to assume that when the =20 > element is missing, it is assumed to be true rather than false. This=20 > will make the default query a "served by" query thus making the=20 > behavior consistent with RFC 5222 for emergency services (which use a=20 > "served by" > query). >=20 >=20 >=20 > This doesn't make for very clear protocol semantics. It's probably=20 > still > viable, but the document needs to make this assumption clear. >=20 > I'm not sure how this out-of-band information interacts with=20 > recursive > resolution. A LoST gateway that performs recursive lookups might=20 > not be > able make the right choice without an explicit, in-band indication=20 > of > intent. >=20 >=20 > [AGF] > This does not apply as per comments above. >=20 >=20 >=20 > Attempting to overload the element as described in=20 > Section 5.1 > does not make for clear protocol semantics. >=20 > [AGF] > Practically it is the same problem. I want to search for points of=20 > service within that region because my location is within that region=20 > (with a certain probability). >=20 > Let me rephrase it. > We can think of the area of uncertainty in a shape as the probability=20 > that a user might be within that area and so we want to look for=20 > services within that area. > All we are doing with a "within X" query is to manually set the=20 > uncertainty level in user location. > The semantics are the same. >=20 >=20 >=20 > My reading of RFC5222 leads me to infer that there is an implicit > parameter in the protocol that is set to 1. There's=20 > always > the possibility that a location with uncertainty overlaps the served=20 > area > of multiple PSAPs - but LoST assumes that there is only one right=20 > answer. >=20 > It seems like the right way to approach the proposed extensions is=20 > to > lift the implied limit beyond 1. Adding the element=20 > seems > like the right thing to do, but the semantics that I associate with > element doesn't seem to fit. >=20 > I'd encourage the authors to re-examine the basic model they are=20 > using to > construct their proposed solution. >=20 > [AGF] > I think I have already addressed this in a previous comment. As we can=20 > read in RFC5222 in Section 12.2, the LoST server MAY return multiple=20 > mapping elements therefore there is no such thing as an implicit limit=20 > to 1. Since there is a MAY in the sentence, the implicit limit has to=20 > be assumed to be equal to "no limit". As such, what we propose is=20 > semantically correct. > Limits of current implementations should not be a limit for the design=20 > of new protocols. You are thinking about emergency services but LoST=20 > was designed also for non-emergency services, so it makes sense that=20 > RFC > 5222 allows LoST to return multiple elements. >=20 >=20 >=20 >=20 >=20 > Section 5.3 seems very confused for these reasons. A simpler model=20 > would > require less explanation. >=20 > On > Section 5.4 states: >=20 > When the element is not present in a query=20 > then > all available points of interest for the requested type of service > SHALL be returned by the LoST server. >=20 > Which seems contrary to what is implicit in RFC5222. See above. >=20 > [AGF] > It is not contrary. See my comment above. >=20 >=20 >=20 >=20 > On > The admonition: >=20 > [...] Only geodetic profiles SHOULD be used [...] >=20 > ... and subsequent use of an unwrapped element in=20 > the > element is strange. How is a civic address not the=20 > location of > the service? If there are multiple forms of location, it would be=20 > better > to use similar guidance to what is in RFC5491: >=20 > 1. recommend multiple elements when there are > multiple forms available >=20 > 2. recommend that a geodetic form is provided where possible >=20 > [AGF] > Yes, I agree. >=20 >=20 >=20 > The location profile can be used to identify which location you want=20 > to > use if the content of the element is not sufficient. >=20 > [AGF] > I am not sure what you mean by this. >=20 >=20 >=20 >=20 > The reason given for these recommendations: >=20 > [...] as the computation of the distance, route and other metrics > would at some point require geocoding of the civic address in > geodetic coordinates. Because of this, the position specified in > SHOULD be represented by using the =20 > element. >=20 > ... is not necessary for interoperability. This seems more for the > convenience of LoST server implementations. Wouldn't these reasons=20 > be > better suited to a LoST server provisioning guide? >=20 > A better reason might be that a recipient of the mapping information > might need to use this information without the necessary context to > understand the civic address. However, the same reason doesn't=20 > support > the recommendation for using a . >=20 > [AGF] > There might be situations where the client would want to perform some=20 > light computations on location information but without having enough=20 > "power" to do geo encoding/decoding. >=20 >=20 >=20 >=20 > Iterative Responses > The use of iterative resolution in LoST is a weak point that the=20 > ability > to provide multiple mappings does not help. In the case where a=20 > server > is able to provide only some answers, there is no facility for the=20 > server > to indicate where the remainder of the answers are found (that is,=20 > the > referral). >=20 > [AGF] > I am not sure I follow. The authoritative server for that region and=20 > for that class of service will reply with the results. Iteration=20 > continues only until an authoritative server is found. >=20 >=20 >=20 >=20 > Even if you can address that concern, there's also the concern that=20 > the > referred LoST server is able to provide better (closer) answers than=20 > the > ones provided. The draft might offer guidance on how to resolve=20 > this > issue. >=20 > [AGF] > I still do not understand the issue. From RFC5222, Section 8.3.3 you=20 > can > read: "In Iterative mode, > the server contacted returns a redirection response indicating the=20 > next server to be queried if the server contacted cannot provide an=20 > answer itself." >=20 >=20 >=20 > Security > The security section could use some expansion. It's not sufficient=20 > to > just refer to RFC5222. >=20 > The denial of service concerns that Shida raised in his review are=20 > worth > discussing. A LoST server is discovered using the same means=20 > whether it > be for emergency or commercial uses. The possibility that=20 > commercial > uses could interfere with public safety is a significant concern. =20 > As > Shida notes, scaling is probably trivial to address, but that's not=20 > the > whole story. >=20 > [AGF] > I am very skeptical about this. >=20 > From a regulatory perspective: the NG911 infrastructure is mostly paid=20 > and maintained by collecting 911 fees that tax payers have to pay. I=20 > do not think LoST servers paid with tax payers money for > 911 can be used for supporting non-911 services. >=20 > From a security perspective: in the most general case, let's assume=20 > we have two different LoST servers, one used by the NG911 client to=20 > discover the correct ESRP and one used by the ESRP to discover the=20 > correct PSAP. The second LoST server would be inside the ESInet thus=20 > behind a firewall. Access to this LoST server would be granted only to=20 > known ESRPs via access control lists (this is how many vendors have it=20 > implemented) or similar. The first LoST server will be more reachable=20 > than the second one as it does not have to be necessarily in the=20 > ESInet. This, however, can be configured to only support=20 > urn:service:sos as type of service and will be an authoritative server=20 > for this type of service only (given the regulatory issues mentioned=20 > above and security concerns). > At this point, the same security considerations as in RFC5222 apply. >=20 >=20 >=20 >=20 >=20 > We've seen problems that overwhelm a system, despite calculations > predicting ample capacity, simply due to high demand for a=20 > particular > application that is poorly configured. Specific mechanisms to=20 > protect > public safety queries might be difficult to design, but the document > should at a minimum acknowledge the problem. >=20 > [AGF] > We could indeed include the discussion above in the draft. >=20 >=20 >=20 >=20 >=20 > Nits: > Section 5.2 - typo: wether >=20 > Most of the examples use http://www.thisisnotdoneyet.net/lostNe > still. >=20 > Using a namespace prefix of "gml" rather than "p2" would be more=20 > helpful > to the reader. Consistent use of namespace prefixes throughout=20 > would > also help disambiguate the three or so namespaces used. >=20 > --Martin > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai >=20 >=20 From keith.drage@alcatel-lucent.com Wed Mar 9 08:11:57 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 901ED3A6914 for ; Wed, 9 Mar 2011 08:11:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.704 X-Spam-Level: X-Spam-Status: No, score=-105.704 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHlUF624NSA1 for ; Wed, 9 Mar 2011 08:11:47 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id D00AE3A69F1 for ; Wed, 9 Mar 2011 08:11:36 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p29GC1nQ026900 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Mar 2011 17:12:13 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 9 Mar 2011 17:12:06 +0100 From: "DRAGE, Keith (Keith)" To: "Dawson, Martin" , "James M. Polk" , Henning Schulzrinne , Brian Rosen Date: Wed, 9 Mar 2011 17:12:05 +0100 Thread-Topic: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt Thread-Index: AcvbyQ3Te6owU+mATUG9EFbHv95PeQBeEW+AAExoiUA= Message-ID: References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> <26E805AD-4D40-4C7E-9C07-56959336B858@cs.columbia.edu> <12E789B1-F912-4459-BBBF-50543811227E@brianrosen.net> <5D628A73-1BCC-4020-82AD-AA50F7F3B970@cs.columbia.edu> <69A77C08-DB6A-4A64-B960-D6EBF2932BCF@brianrosen.net> <5878DF10-7E81-4C00-979C-526FB1732778@cs.columbia.edu> <201103060637.p266brCX000350@sj-core-3.cisco.com> <8B0A9FCBB9832F43971E38010638454F0400B68462@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0400B68462@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: 'ecrit Org' Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 16:11:58 -0000 The applicability of this document to most mobile phone networks is tenuous= anyway.=20 For Voip, 3GPP and 3GPP2 based networks have a defined manner of supporting= emergency calls covered by 3GPP common IMS specifications, backed up by us= e of the existing CS network where such exists.=20 As far as the 3GPP and 3GPP2 operators are concerned the 3GPP specification= s meet their obligations to the regulators, and the phones wishing to use t= hose capabilities have to correspond to the 3GPP specifications. Those specifications correspond to phone BCP only where they are trying to = address a common requirement. Key things they will not do is use of Lost an= d Lost servers, endpoint location validation, no encryption of location, as= this is protected by trust domains, no direct calling of the PSAP from the= end device - recognition instead by intermediate SIP entities, etc. If as an end user you choose to ignore those provisions for support of emer= gency calls in 3GPP and 3GPP2 networks, and make the call using an IP conne= ction to some other service provider, then that is your look out. It impose= s no obligations on the 3GPP or 3GPP2 service provider. Now there were comments prior to this to write some of this into the docume= nt. As far as I am concerned those comments are still open. Regards Keith > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: 08 March 2011 03:35 > To: James M. Polk; Henning Schulzrinne; Brian Rosen > Cc: DRAGE, Keith (Keith); 'ecrit Org' > Subject: RE: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt >=20 > I agree with this. >=20 > I'll go out on a limb and confess I don't understand why the point of > (circuit service) mobile codecs came up anyway. These are air interface > codecs and they will have been transcoded by the time the traffic hits th= e > circuits in the core network anyway. I'm struggling to see why they are > pertinent to the spec at all. >=20 > Cheers, > Martin >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > James M. Polk > Sent: Sunday, 6 March 2011 5:38 PM > To: Henning Schulzrinne; Brian Rosen > Cc: DRAGE, Keith (Keith); 'ecrit Org' > Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt >=20 > I agree with Henning here. We really cannot really control or > reliably expect that within the existing SW upgradeable > "interworking" products that we can mandate a codec. >=20 > That said, Gunnar is also right, this shouldn't be only an "ED" > requirement. >=20 > Along those lines, I think this requirement, while well intentioned, > falls into the gap between IP and circuit, in which we can't > truthfully say that we "know" this only applies to the IP part - at > least not without rewording to limit this. >=20 > Something needs to state definitively that when the media gets to the > ESRP - via mobile or wired - it needs to be in either the G.711 or > G.722 codec for interoperability sake. That means the cellco mobile > devices can use whatever codec they want, as long as the cellco > converts to 711 or 722 once the media is transcoded to RTP. >=20 > I'm not sure we have a requirement that say exactly that, and I think > we should for this situation. >=20 > James >=20 > At 10:48 AM 3/5/2011, Henning Schulzrinne wrote: > >There's nothing we can do about this problem, particularly given > >that there doesn't appear to be a universal codec for mobile > >devices. Also, I suspect that all mobile calls *today* show up as > >G.711 by the time they reach the ESInet, since they go through a > >circuit-to-packet conversion. Once we have VoIP-over-LTE, it might > >be appropriate to add the most common wideband codec for that > >configuration to the SHOULD list. There doesn't seem to be as much > >point in adding narrowband codecs, since the conversion to G.711 is > >cheap and no quality would be lost in translation. > > > >Henning > > > >On Mar 5, 2011, at 10:24 AM, Brian Rosen wrote: > > > > > Nope, no downside. I can do that. > > > > > > Doesn't handle the problem that started this: mobile phones don't > > do G.711 or G.722 > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Wed Mar 9 08:22:32 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9FF3A6859 for ; Wed, 9 Mar 2011 08:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2nFuM8d+CWr for ; Wed, 9 Mar 2011 08:22:30 -0800 (PST) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by core3.amsl.com (Postfix) with ESMTP id 757C03A683E for ; Wed, 9 Mar 2011 08:22:30 -0800 (PST) X-ASG-Debug-ID: 1299687825-011a9f0eca116230001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id HibMr4D9oFx5gyPF; Wed, 09 Mar 2011 08:23:46 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=wbla-lt500.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PxMAo-0005Vq-DI; Wed, 09 Mar 2011 08:23:45 -0800 Mime-Version: 1.0 (Apple Message framework v1082) X-ASG-Orig-Subj: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: Date: Wed, 9 Mar 2011 11:23:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> <26E805AD-4D40-4C7E-9C07-56959336B858@cs.columbia.edu> <12E789B1-F912-4459-BBBF-50543811227E@brianrosen.net> <5D628A73-1BCC-4020-82AD-AA50F7F3B970@cs.columbia.edu> <69A77C08-DB6A-4A64-B960-D6EBF2932BCF@brianrosen.net> <5878DF10-7E81-4C00-979C-526FB1732778@cs.columbia.edu> <201103060637.p266brCX000350@sj-core-3.cisco.com> <8B0A9FCBB9832F43971E38010638454F0400B68462@SISPE7MB1.commscope.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1082) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1299687825 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.30 X-Barracuda-Spam-Status: No, SCORE=0.30 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=NO_OBLIGATION X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.57517 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.30 NO_OBLIGATION BODY: There is no obligation Cc: "Dawson, Martin" , 'ecrit Org' Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 16:22:32 -0000 This is a BCP for Internet connected devices, service providers and = access networks. There are no protocol police. =20 I woud point out that a 3GPP service provider may be an access network = (raw packet service). Please send text. Brian On Mar 9, 2011, at 11:12 AM, DRAGE, Keith (Keith) wrote: > The applicability of this document to most mobile phone networks is = tenuous anyway.=20 >=20 > For Voip, 3GPP and 3GPP2 based networks have a defined manner of = supporting emergency calls covered by 3GPP common IMS specifications, = backed up by use of the existing CS network where such exists.=20 >=20 > As far as the 3GPP and 3GPP2 operators are concerned the 3GPP = specifications meet their obligations to the regulators, and the phones = wishing to use those capabilities have to correspond to the 3GPP = specifications. >=20 > Those specifications correspond to phone BCP only where they are = trying to address a common requirement. Key things they will not do is = use of Lost and Lost servers, endpoint location validation, no = encryption of location, as this is protected by trust domains, no direct = calling of the PSAP from the end device - recognition instead by = intermediate SIP entities, etc. >=20 > If as an end user you choose to ignore those provisions for support of = emergency calls in 3GPP and 3GPP2 networks, and make the call using an = IP connection to some other service provider, then that is your look = out. It imposes no obligations on the 3GPP or 3GPP2 service provider. >=20 > Now there were comments prior to this to write some of this into the = document. As far as I am concerned those comments are still open. >=20 > Regards >=20 > Keith >=20 >> -----Original Message----- >> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] >> Sent: 08 March 2011 03:35 >> To: James M. Polk; Henning Schulzrinne; Brian Rosen >> Cc: DRAGE, Keith (Keith); 'ecrit Org' >> Subject: RE: [Ecrit] Gen-ART review of = draft-ietf-ecrit-phonebcp-16.txt >>=20 >> I agree with this. >>=20 >> I'll go out on a limb and confess I don't understand why the point of >> (circuit service) mobile codecs came up anyway. These are air = interface >> codecs and they will have been transcoded by the time the traffic = hits the >> circuits in the core network anyway. I'm struggling to see why they = are >> pertinent to the spec at all. >>=20 >> Cheers, >> Martin >>=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of >> James M. Polk >> Sent: Sunday, 6 March 2011 5:38 PM >> To: Henning Schulzrinne; Brian Rosen >> Cc: DRAGE, Keith (Keith); 'ecrit Org' >> Subject: Re: [Ecrit] Gen-ART review of = draft-ietf-ecrit-phonebcp-16.txt >>=20 >> I agree with Henning here. We really cannot really control or >> reliably expect that within the existing SW upgradeable >> "interworking" products that we can mandate a codec. >>=20 >> That said, Gunnar is also right, this shouldn't be only an "ED" >> requirement. >>=20 >> Along those lines, I think this requirement, while well intentioned, >> falls into the gap between IP and circuit, in which we can't >> truthfully say that we "know" this only applies to the IP part - at >> least not without rewording to limit this. >>=20 >> Something needs to state definitively that when the media gets to the >> ESRP - via mobile or wired - it needs to be in either the G.711 or >> G.722 codec for interoperability sake. That means the cellco mobile >> devices can use whatever codec they want, as long as the cellco >> converts to 711 or 722 once the media is transcoded to RTP. >>=20 >> I'm not sure we have a requirement that say exactly that, and I think >> we should for this situation. >>=20 >> James >>=20 >> At 10:48 AM 3/5/2011, Henning Schulzrinne wrote: >>> There's nothing we can do about this problem, particularly given >>> that there doesn't appear to be a universal codec for mobile >>> devices. Also, I suspect that all mobile calls *today* show up as >>> G.711 by the time they reach the ESInet, since they go through a >>> circuit-to-packet conversion. Once we have VoIP-over-LTE, it might >>> be appropriate to add the most common wideband codec for that >>> configuration to the SHOULD list. There doesn't seem to be as much >>> point in adding narrowband codecs, since the conversion to G.711 is >>> cheap and no quality would be lost in translation. >>>=20 >>> Henning >>>=20 >>> On Mar 5, 2011, at 10:24 AM, Brian Rosen wrote: >>>=20 >>>> Nope, no downside. I can do that. >>>>=20 >>>> Doesn't handle the problem that started this: mobile phones don't >>> do G.711 or G.722 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Wed Mar 9 18:26:29 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5ABA3A67F6 for ; Wed, 9 Mar 2011 18:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYmoZevBsUyj for ; Wed, 9 Mar 2011 18:26:28 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 87CE33A67D6 for ; Wed, 9 Mar 2011 18:26:28 -0800 (PST) Received: from [128.89.254.94] (port=57781 helo=[192.168.1.10]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PxVbF-0004X7-21; Wed, 09 Mar 2011 21:27:37 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: "Richard L. Barnes" In-Reply-To: <20110309160102.3FD163A6866@core3.amsl.com> Date: Wed, 9 Mar 2011 21:27:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110309160102.3FD163A6866@core3.amsl.com> To: Ted Hardie , andy@hxr.us, "Hannes (NSN - FI/Espoo) Tschofenig" , hgs+ecrit@cs.columbia.edu, Gonzalo Camarillo , Robert Sparks , ecrit Org , marc.linsner@cisco.com, Russ Housley X-Mailer: Apple Mail (2.1082) Subject: Re: [Ecrit] IPR Disclosure: Todd S. Glassey's Statement about IPR related to RFC 5222 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 02:26:29 -0000 I'm pretty sure that this IPR filing is mis-filed, since the referenced = patent (6,327,629, "Stored procedure universal calling interface") is = neither held by Mr. Glassey nor at all relevant to RFC 5222: It would seem that he's referring to patent number 6,370,629 = ("Controlling access to stored information based on geographical = location and date and time"), which was indeed issued to Mr. Glassey and = others in March 2002. =20 It's still not clear to me that this patent has any relevance to RFC = 5222, but I appreciate Mr. Glassey making the disclosure. --Richard On Mar 9, 2011, at 11:01 AM, IETF Secretariat wrote: > Dear Ted Hardie, Andrew Newton, Hannes Tschofenig, Henning = Schulzrinne: >=20 > An IPR disclosure that pertains to your RFC entitled "LoST: A > Location-to-Service Translation Protocol" (RFC5222) was submitted to = the IETF > Secretariat on 2011-03-07 and has been posted on the "IETF Page of = Intellectual > Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1505/). = The title > of the IPR disclosure is "Todd S. Glassey's Statement about IPR = related to RFC > 5222." >=20 > The IETF Secretariat >=20 >=20 From Martin.Dawson@commscope.com Thu Mar 10 21:47:04 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84D7D3A6AD5 for ; Thu, 10 Mar 2011 21:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aE9v0jb9I8Dc for ; Thu, 10 Mar 2011 21:47:03 -0800 (PST) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id E8C703A6873 for ; Thu, 10 Mar 2011 21:47:02 -0800 (PST) X-AuditID: 0a0404e8-b7cd5ae000006393-4d-4d79b7a9e77d Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 4D.AB.25491.9A7B97D4; Thu, 10 Mar 2011 23:48:25 -0600 (CST) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 10 Mar 2011 23:48:20 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 11 Mar 2011 13:48:18 +0800 From: "Dawson, Martin" To: "DRAGE, Keith (Keith)" Date: Fri, 11 Mar 2011 13:48:16 +0800 Thread-Topic: IMS and ECRIT are not incompatible Thread-Index: AcvbyQ3Te6owU+mATUG9EFbHv95PeQBeEW+AAExoiUAAGdbX0A== Message-ID: <8B0A9FCBB9832F43971E38010638454F0400B6891E@SISPE7MB1.commscope.com> References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> <26E805AD-4D40-4C7E-9C07-56959336B858@cs.columbia.edu> <12E789B1-F912-4459-BBBF-50543811227E@brianrosen.net> <5D628A73-1BCC-4020-82AD-AA50F7F3B970@cs.columbia.edu> <69A77C08-DB6A-4A64-B960-D6EBF2932BCF@brianrosen.net> <5878DF10-7E81-4C00-979C-526FB1732778@cs.columbia.edu> <201103060637.p266brCX000350@sj-core-3.cisco.com> <8B0A9FCBB9832F43971E38010638454F0400B68462@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: 'ecrit Org' Subject: [Ecrit] IMS and ECRIT are not incompatible X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 05:47:04 -0000 Given this is going off-topic with respect to the original thread, I'll pic= k up Keith's point with a new subject title. There's a meme going around that IMS emergency calling, specified in the st= age 2 3GPP TS 23.167, is somehow a mutually exclusive alternative or incons= istent architecture with ECRIT and phone BCP. I don't think that's true at all. It should be self evident that, like any other solution, IMS needs to addre= ss the functions of location determination and call routing. And, indeed, t= hese functions are covered in 23.167 and are attributed to the "LRF" (Locat= ion Retrieval Function) network element. The spec decomposes the LRF into t= he logical functions of "LS" and "RDF" ("Location Server" and "Route Determ= ination Function"). Most aspects of the operation of the LS and RDF are lef= t out of scope or considered implementation dependent - which is fair enoug= h. ECRIT isn't ruled out. There is a quite practical, IMS consistent, deployme= nt of the LRF that uses LoST as the implementation for the RDF and HELD for= the LS function. This should not be any surprise since IMS is much like an= over the top VoIP service with the simplification that all the elements ca= n be in the same trust domain (though I find IMS specifications to be curio= usly silent of the use case of a subscriber initiating a call from a comple= tely third party IP-CAN such as a residential WiFi access). It's also attra= ctive in that it's consistent with respect to the principle of IMS being ba= sed on IETF specifications as opposed to inventing 3GPP-specific mechanisms= . The real value to the network/IMS operator of course is that an implementat= ion that used LoST and HELD as described above would also support the more = general use cases that Keith rules out below - while obviating the need to = resort to pseudo-legalistic arguments to justify the limited scope of IMS. = It would also facilitate the use case mentioned above assuming the broadban= d provider behind the residential WiFi connection also had a consistent imp= lementation. It's all good. Cheers, Martin -----Original Message----- From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]=20 Sent: Thursday, 10 March 2011 3:12 AM To: Dawson, Martin; James M. Polk; Henning Schulzrinne; Brian Rosen Cc: 'ecrit Org' Subject: RE: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt The applicability of this document to most mobile phone networks is tenuous= anyway.=20 For Voip, 3GPP and 3GPP2 based networks have a defined manner of supporting= emergency calls covered by 3GPP common IMS specifications, backed up by us= e of the existing CS network where such exists.=20 As far as the 3GPP and 3GPP2 operators are concerned the 3GPP specification= s meet their obligations to the regulators, and the phones wishing to use t= hose capabilities have to correspond to the 3GPP specifications. Those specifications correspond to phone BCP only where they are trying to = address a common requirement. Key things they will not do is use of Lost an= d Lost servers, endpoint location validation, no encryption of location, as= this is protected by trust domains, no direct calling of the PSAP from the= end device - recognition instead by intermediate SIP entities, etc. If as an end user you choose to ignore those provisions for support of emer= gency calls in 3GPP and 3GPP2 networks, and make the call using an IP conne= ction to some other service provider, then that is your look out. It impose= s no obligations on the 3GPP or 3GPP2 service provider. Now there were comments prior to this to write some of this into the docume= nt. As far as I am concerned those comments are still open. Regards Keith > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: 08 March 2011 03:35 > To: James M. Polk; Henning Schulzrinne; Brian Rosen > Cc: DRAGE, Keith (Keith); 'ecrit Org' > Subject: RE: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt >=20 > I agree with this. >=20 > I'll go out on a limb and confess I don't understand why the point of > (circuit service) mobile codecs came up anyway. These are air interface > codecs and they will have been transcoded by the time the traffic hits th= e > circuits in the core network anyway. I'm struggling to see why they are > pertinent to the spec at all. >=20 > Cheers, > Martin >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > James M. Polk > Sent: Sunday, 6 March 2011 5:38 PM > To: Henning Schulzrinne; Brian Rosen > Cc: DRAGE, Keith (Keith); 'ecrit Org' > Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt >=20 > I agree with Henning here. We really cannot really control or > reliably expect that within the existing SW upgradeable > "interworking" products that we can mandate a codec. >=20 > That said, Gunnar is also right, this shouldn't be only an "ED" > requirement. >=20 > Along those lines, I think this requirement, while well intentioned, > falls into the gap between IP and circuit, in which we can't > truthfully say that we "know" this only applies to the IP part - at > least not without rewording to limit this. >=20 > Something needs to state definitively that when the media gets to the > ESRP - via mobile or wired - it needs to be in either the G.711 or > G.722 codec for interoperability sake. That means the cellco mobile > devices can use whatever codec they want, as long as the cellco > converts to 711 or 722 once the media is transcoded to RTP. >=20 > I'm not sure we have a requirement that say exactly that, and I think > we should for this situation. >=20 > James >=20 > At 10:48 AM 3/5/2011, Henning Schulzrinne wrote: > >There's nothing we can do about this problem, particularly given > >that there doesn't appear to be a universal codec for mobile > >devices. Also, I suspect that all mobile calls *today* show up as > >G.711 by the time they reach the ESInet, since they go through a > >circuit-to-packet conversion. Once we have VoIP-over-LTE, it might > >be appropriate to add the most common wideband codec for that > >configuration to the SHOULD list. There doesn't seem to be as much > >point in adding narrowband codecs, since the conversion to G.711 is > >cheap and no quality would be lost in translation. > > > >Henning > > > >On Mar 5, 2011, at 10:24 AM, Brian Rosen wrote: > > > > > Nope, no downside. I can do that. > > > > > > Doesn't handle the problem that started this: mobile phones don't > > do G.711 or G.722 > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From gunnar.hellstrom@omnitor.se Thu Mar 10 22:26:39 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F014C3A6892 for ; Thu, 10 Mar 2011 22:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWYfrtME7vMN for ; Thu, 10 Mar 2011 22:26:24 -0800 (PST) Received: from vsp-outgoing1.binero.net (vsp-outgoing1.binero.net [193.17.218.160]) by core3.amsl.com (Postfix) with SMTP id 76C193A6934 for ; Thu, 10 Mar 2011 22:26:23 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.39.229]) by vsp-outgoing1.binero.net (Halon Mail Gateway) with ESMTP for ; Fri, 11 Mar 2011 07:27:33 +0100 (CET) Received: from [192.168.50.31] (h225n1fls32o933.telia.com [213.67.165.225]) by smtp-01-01.atm.binero.net (Postfix) with ESMTPA id 708C23A230 for ; Fri, 11 Mar 2011 07:27:33 +0100 (CET) Message-ID: <4D79C0D5.6020301@omnitor.se> Date: Fri, 11 Mar 2011 07:27:33 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: ecrit@ietf.org References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> <26E805AD-4D40-4C7E-9C07-56959336B858@cs.columbia.edu> <12E789B1-F912-4459-BBBF-50543811227E@brianrosen.net> <5D628A73-1BCC-4020-82AD-AA50F7F3B970@cs.columbia.edu> <69A77C08-DB6A-4A64-B960-D6EBF2932BCF@brianrosen.net> <5878DF10-7E81-4C00-979C-526FB1732778@cs.columbia.edu> <201103060637.p266brCX000350@sj-core-3.cisco.com> <8B0A9FCBB9832F43971E38010638454F0400B68462@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F0400B6891E@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0400B6891E@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Ecrit] IMS and ECRIT are not incompatible X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 06:26:39 -0000 A consequence of this discussion is that next task for Ecrit could be to more strictly specify the inter-service interface to the emergency service network ( Where M7 is in Figure 1 of the ecrit-framework draft ). Now, both Phonebcp and Framework describe a collaboration between many elements in the service provider's network. A service provider with an established structure need today analyze Phonebcp to pick what is relevant as it is said. Other functions need to be provided as intended when the call reaches the Emergency Service Network even if they are done in another way than what Phonebcp says internally in the Service Provider's network. This need will be much more evident when service providers with IP but not SIP based conversational services want to arrange emergency calling. Will it be sufficiently easy to do that mapping from Phonebcp and Framework, or is a true Emergency Service Network interface specification needed? Gunnar ___________________________________________________ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 Dawson, Martin skrev 2011-03-11 06:48: > Given this is going off-topic with respect to the original thread, I'll pick up Keith's point with a new subject title. > > There's a meme going around that IMS emergency calling, specified in the stage 2 3GPP TS 23.167, is somehow a mutually exclusive alternative or inconsistent architecture with ECRIT and phone BCP. > > I don't think that's true at all. > > It should be self evident that, like any other solution, IMS needs to address the functions of location determination and call routing. And, indeed, these functions are covered in 23.167 and are attributed to the "LRF" (Location Retrieval Function) network element. The spec decomposes the LRF into the logical functions of "LS" and "RDF" ("Location Server" and "Route Determination Function"). Most aspects of the operation of the LS and RDF are left out of scope or considered implementation dependent - which is fair enough. > > ECRIT isn't ruled out. There is a quite practical, IMS consistent, deployment of the LRF that uses LoST as the implementation for the RDF and HELD for the LS function. This should not be any surprise since IMS is much like an over the top VoIP service with the simplification that all the elements can be in the same trust domain (though I find IMS specifications to be curiously silent of the use case of a subscriber initiating a call from a completely third party IP-CAN such as a residential WiFi access). It's also attractive in that it's consistent with respect to the principle of IMS being based on IETF specifications as opposed to inventing 3GPP-specific mechanisms. > > The real value to the network/IMS operator of course is that an implementation that used LoST and HELD as described above would also support the more general use cases that Keith rules out below - while obviating the need to resort to pseudo-legalistic arguments to justify the limited scope of IMS. It would also facilitate the use case mentioned above assuming the broadband provider behind the residential WiFi connection also had a consistent implementation. It's all good. > > Cheers, > Martin > > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: Thursday, 10 March 2011 3:12 AM > To: Dawson, Martin; James M. Polk; Henning Schulzrinne; Brian Rosen > Cc: 'ecrit Org' > Subject: RE: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt > > The applicability of this document to most mobile phone networks is tenuous anyway. > > For Voip, 3GPP and 3GPP2 based networks have a defined manner of supporting emergency calls covered by 3GPP common IMS specifications, backed up by use of the existing CS network where such exists. > > As far as the 3GPP and 3GPP2 operators are concerned the 3GPP specifications meet their obligations to the regulators, and the phones wishing to use those capabilities have to correspond to the 3GPP specifications. > > Those specifications correspond to phone BCP only where they are trying to address a common requirement. Key things they will not do is use of Lost and Lost servers, endpoint location validation, no encryption of location, as this is protected by trust domains, no direct calling of the PSAP from the end device - recognition instead by intermediate SIP entities, etc. > > If as an end user you choose to ignore those provisions for support of emergency calls in 3GPP and 3GPP2 networks, and make the call using an IP connection to some other service provider, then that is your look out. It imposes no obligations on the 3GPP or 3GPP2 service provider. > > Now there were comments prior to this to write some of this into the document. As far as I am concerned those comments are still open. > > Regards > > Keith > >> -----Original Message----- >> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] >> Sent: 08 March 2011 03:35 >> To: James M. Polk; Henning Schulzrinne; Brian Rosen >> Cc: DRAGE, Keith (Keith); 'ecrit Org' >> Subject: RE: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt >> >> I agree with this. >> >> I'll go out on a limb and confess I don't understand why the point of >> (circuit service) mobile codecs came up anyway. These are air interface >> codecs and they will have been transcoded by the time the traffic hits the >> circuits in the core network anyway. I'm struggling to see why they are >> pertinent to the spec at all. >> >> Cheers, >> Martin >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of >> James M. Polk >> Sent: Sunday, 6 March 2011 5:38 PM >> To: Henning Schulzrinne; Brian Rosen >> Cc: DRAGE, Keith (Keith); 'ecrit Org' >> Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt >> >> I agree with Henning here. We really cannot really control or >> reliably expect that within the existing SW upgradeable >> "interworking" products that we can mandate a codec. >> >> That said, Gunnar is also right, this shouldn't be only an "ED" >> requirement. >> >> Along those lines, I think this requirement, while well intentioned, >> falls into the gap between IP and circuit, in which we can't >> truthfully say that we "know" this only applies to the IP part - at >> least not without rewording to limit this. >> >> Something needs to state definitively that when the media gets to the >> ESRP - via mobile or wired - it needs to be in either the G.711 or >> G.722 codec for interoperability sake. That means the cellco mobile >> devices can use whatever codec they want, as long as the cellco >> converts to 711 or 722 once the media is transcoded to RTP. >> >> I'm not sure we have a requirement that say exactly that, and I think >> we should for this situation. >> >> James >> >> At 10:48 AM 3/5/2011, Henning Schulzrinne wrote: >>> There's nothing we can do about this problem, particularly given >>> that there doesn't appear to be a universal codec for mobile >>> devices. Also, I suspect that all mobile calls *today* show up as >>> G.711 by the time they reach the ESInet, since they go through a >>> circuit-to-packet conversion. Once we have VoIP-over-LTE, it might >>> be appropriate to add the most common wideband codec for that >>> configuration to the SHOULD list. There doesn't seem to be as much >>> point in adding narrowband codecs, since the conversion to G.711 is >>> cheap and no quality would be lost in translation. >>> >>> Henning >>> >>> On Mar 5, 2011, at 10:24 AM, Brian Rosen wrote: >>> >>>> Nope, no downside. I can do that. >>>> >>>> Doesn't handle the problem that started this: mobile phones don't >>> do G.711 or G.722 >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From keith.drage@alcatel-lucent.com Fri Mar 11 06:45:13 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A3C23A6C36 for ; Fri, 11 Mar 2011 06:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.73 X-Spam-Level: X-Spam-Status: No, score=-105.73 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbAnIEQnG+Mm for ; Fri, 11 Mar 2011 06:45:11 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 5C70E3A6C35 for ; Fri, 11 Mar 2011 06:45:10 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p2BEkHxM010162 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 11 Mar 2011 15:46:26 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 11 Mar 2011 15:46:02 +0100 From: "DRAGE, Keith (Keith)" To: "Dawson, Martin" Date: Fri, 11 Mar 2011 15:46:01 +0100 Thread-Topic: IMS and ECRIT are not incompatible Thread-Index: AcvbyQ3Te6owU+mATUG9EFbHv95PeQBeEW+AAExoiUAAGdbX0ABAvKmw Message-ID: References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> <26E805AD-4D40-4C7E-9C07-56959336B858@cs.columbia.edu> <12E789B1-F912-4459-BBBF-50543811227E@brianrosen.net> <5D628A73-1BCC-4020-82AD-AA50F7F3B970@cs.columbia.edu> <69A77C08-DB6A-4A64-B960-D6EBF2932BCF@brianrosen.net> <5878DF10-7E81-4C00-979C-526FB1732778@cs.columbia.edu> <201103060637.p266brCX000350@sj-core-3.cisco.com> <8B0A9FCBB9832F43971E38010638454F0400B68462@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F0400B6878F@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0400B6878F@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: 'ecrit Org' Subject: Re: [Ecrit] IMS and ECRIT are not incompatible X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 14:45:13 -0000 I didn't say they were incompatible, or that they would never work. However= it is more a matter of fitting where they touch. If for example in a 3GPP network running LTE, you attempt to contact a LOST= server from the terminal, as specified in phoneBCP, you are not going to f= ind one provided by your 3GPP access provider because there is no requireme= nt in 23.167 to provide one. You may be able to find one provided by someon= e else. If you make such an attempt in a phone without a UICC, then you are not eve= n going to be able to get the request to leave the terminal. If you do attempt to follow phoneBCP as a pure IP connection to some non-3G= PP provider, then you will not get the emergency bearer specified in 23.167= for LTE, UTRAN and cdma2000 accesses. That means other users could well ge= t priority on the radio access over you. I would also add that many 3GPP or 3GPP2 operators will initially support e= mergency calls by pushing you back to the CS network (where they already ha= ve universal coverage), they can only do that if you follow the procedures = by which they recognize the emergency call attempt in the first place. Phon= eBCP does not provide for the UE making a call in that form. The bottom line is that if you make an emergency call using a 3GPP or 3GPP2= phone in the manner specified in 23.167, then the 3GPP or 3GPP2 operator w= ill undertake to ensure that it works. If you attempt to make the emergency= call using procedures on the phone that are not specified in 23.167, then = you will have to do your own analysis on what works, and it is on your own = head if it does not. If you want to alter what 3GPP specifies, then you make the appropriate con= tribution to 3GPP, not try and write something in an IETF RFC to imply that= it is accepted fact. Regards Keith > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@commscope.com] > Sent: 10 March 2011 04:55 > To: DRAGE, Keith (Keith) > Cc: 'ecrit Org' > Subject: IMS and ECRIT are not incompatible >=20 > Given this is going off-topic with respect to the original thread, I'll > pick up Keith's point with a new subject title. >=20 > There's a meme going around that IMS emergency calling, specified in the > stage 2 3GPP TS 23.167, is somehow a mutually exclusive alternative or > inconsistent architecture with ECRIT and phone BCP. >=20 > I don't think that's true at all. >=20 > It should be self evident that, like any other solution, IMS needs to > address the functions of location determination and call routing. And, > indeed, these functions are covered in 23.167 and are attributed to the > "LRF" (Location Retrieval Function) network element. The spec decomposes > the LRF into the logical functions of "LS" and "RDF" ("Location Server" > and "Route Determination Function"). Most aspects of the operation of the > LS and RDF are left out of scope or implementation dependent - which is > fair enough. >=20 > There's a quite practical, IMS consistent, deployment of the LRF that use= s > LoST as the implementation for the RDF and HELD for the LS function. This > should not be any surprise since IMS is like an over the top VoIP service > with the simplification that all the elements can be in the same trust > domain (though I find IMS specifications to be curiously silent of the us= e > case of a subscriber initiating a call from a completely third party IP- > CAN such as a residential WiFi access). It's also attractive in that it's > consistent with respect to the principle of IMS being based on IETF > specifications as opposed to inventing 3GPP-specific mechanisms. >=20 > The real value to the network/IMS operator of course is that an > implementation that used LoST and HELD as described above would also > support the more general use cases that Keith rules out below - and > obviating the need to resort to pseudo-legalistic arguments to justify th= e > limited scope of IMS. It would also facilitate the use case mentioned > above assuming the broadband provider behind the residential WiFi > connection also had a consistent implementation. It's all good. >=20 > Cheers, > Martin >=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: Thursday, 10 March 2011 3:12 AM > To: Dawson, Martin; James M. Polk; Henning Schulzrinne; Brian Rosen > Cc: 'ecrit Org' > Subject: RE: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt >=20 > The applicability of this document to most mobile phone networks is > tenuous anyway. >=20 > For Voip, 3GPP and 3GPP2 based networks have a defined manner of > supporting emergency calls covered by 3GPP common IMS specifications, > backed up by use of the existing CS network where such exists. >=20 > As far as the 3GPP and 3GPP2 operators are concerned the 3GPP > specifications meet their obligations to the regulators, and the phones > wishing to use those capabilities have to correspond to the 3GPP > specifications. >=20 > Those specifications correspond to phone BCP only where they are trying t= o > address a common requirement. Key things they will not do is use of Lost > and Lost servers, endpoint location validation, no encryption of location= , > as this is protected by trust domains, no direct calling of the PSAP from > the end device - recognition instead by intermediate SIP entities, etc. >=20 > If as an end user you choose to ignore those provisions for support of > emergency calls in 3GPP and 3GPP2 networks, and make the call using an IP > connection to some other service provider, then that is your look out. It > imposes no obligations on the 3GPP or 3GPP2 service provider. >=20 > Now there were comments prior to this to write some of this into the > document. As far as I am concerned those comments are still open. >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: 08 March 2011 03:35 > > To: James M. Polk; Henning Schulzrinne; Brian Rosen > > Cc: DRAGE, Keith (Keith); 'ecrit Org' > > Subject: RE: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt > > > > I agree with this. > > > > I'll go out on a limb and confess I don't understand why the point of > > (circuit service) mobile codecs came up anyway. These are air interface > > codecs and they will have been transcoded by the time the traffic hits > the > > circuits in the core network anyway. I'm struggling to see why they are > > pertinent to the spec at all. > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > James M. Polk > > Sent: Sunday, 6 March 2011 5:38 PM > > To: Henning Schulzrinne; Brian Rosen > > Cc: DRAGE, Keith (Keith); 'ecrit Org' > > Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt > > > > I agree with Henning here. We really cannot really control or > > reliably expect that within the existing SW upgradeable > > "interworking" products that we can mandate a codec. > > > > That said, Gunnar is also right, this shouldn't be only an "ED" > > requirement. > > > > Along those lines, I think this requirement, while well intentioned, > > falls into the gap between IP and circuit, in which we can't > > truthfully say that we "know" this only applies to the IP part - at > > least not without rewording to limit this. > > > > Something needs to state definitively that when the media gets to the > > ESRP - via mobile or wired - it needs to be in either the G.711 or > > G.722 codec for interoperability sake. That means the cellco mobile > > devices can use whatever codec they want, as long as the cellco > > converts to 711 or 722 once the media is transcoded to RTP. > > > > I'm not sure we have a requirement that say exactly that, and I think > > we should for this situation. > > > > James > > > > At 10:48 AM 3/5/2011, Henning Schulzrinne wrote: > > >There's nothing we can do about this problem, particularly given > > >that there doesn't appear to be a universal codec for mobile > > >devices. Also, I suspect that all mobile calls *today* show up as > > >G.711 by the time they reach the ESInet, since they go through a > > >circuit-to-packet conversion. Once we have VoIP-over-LTE, it might > > >be appropriate to add the most common wideband codec for that > > >configuration to the SHOULD list. There doesn't seem to be as much > > >point in adding narrowband codecs, since the conversion to G.711 is > > >cheap and no quality would be lost in translation. > > > > > >Henning > > > > > >On Mar 5, 2011, at 10:24 AM, Brian Rosen wrote: > > > > > > > Nope, no downside. I can do that. > > > > > > > > Doesn't handle the problem that started this: mobile phones don't > > > do G.711 or G.722 > > > > > >_______________________________________________ > > >Ecrit mailing list > > >Ecrit@ietf.org > > >https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit From Martin.Dawson@commscope.com Sun Mar 13 23:28:10 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E6423A6A63 for ; Sun, 13 Mar 2011 23:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uItBRifsveN for ; Sun, 13 Mar 2011 23:28:08 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id B15A23A6A60 for ; Sun, 13 Mar 2011 23:28:08 -0700 (PDT) X-AuditID: 0a0404e8-b7cd5ae000006393-5e-4d7db368630d Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 54.77.25491.863BD7D4; Mon, 14 Mar 2011 01:19:20 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 14 Mar 2011 01:19:16 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 14 Mar 2011 14:19:14 +0800 From: "Dawson, Martin" To: "DRAGE, Keith (Keith)" Date: Mon, 14 Mar 2011 14:19:13 +0800 Thread-Topic: IMS and ECRIT are not incompatible Thread-Index: AcvbyQ3Te6owU+mATUG9EFbHv95PeQBeEW+AAExoiUAAGdbX0ABAvKmwAIt978A= Message-ID: <8B0A9FCBB9832F43971E38010638454F0400B68AF0@SISPE7MB1.commscope.com> References: <4D61266D.1030104@ericsson.com> <13A40E9A-EC45-402D-A2A9-EBF6E9FF2B3A@brianrosen.net> <26E805AD-4D40-4C7E-9C07-56959336B858@cs.columbia.edu> <12E789B1-F912-4459-BBBF-50543811227E@brianrosen.net> <5D628A73-1BCC-4020-82AD-AA50F7F3B970@cs.columbia.edu> <69A77C08-DB6A-4A64-B960-D6EBF2932BCF@brianrosen.net> <5878DF10-7E81-4C00-979C-526FB1732778@cs.columbia.edu> <201103060637.p266brCX000350@sj-core-3.cisco.com> <8B0A9FCBB9832F43971E38010638454F0400B68462@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F0400B6878F@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: 'ecrit Org' Subject: Re: [Ecrit] IMS and ECRIT are not incompatible X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 06:28:10 -0000 Hi Keith, You appear to continue to argue that it's an either/or situation - despite = your no doubt sincere assurances. My argument is that IMS with all it's ben= efits (perceived or actual) can still be implemented while, with no additio= nal complexity, also having a network that supports the general ECRIT model= . Responses below. Cheers, Martin -----Original Message----- From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]=20 Sent: Saturday, 12 March 2011 1:46 AM To: Dawson, Martin Cc: 'ecrit Org' Subject: RE: IMS and ECRIT are not incompatible I didn't say they were incompatible, or that they would never work. [[MCD] ] I'm sure you weren't saying that; I'm sure you weren't even intend= ing to imply it... though there was nothing to prevent the inference. However it is more a matter of fitting where they touch. If for example in a 3GPP network running LTE, you attempt to contact a LOST= server from the terminal, as specified in phoneBCP, you are not going to f= ind one provided by your 3GPP access provider because there is no requireme= nt in 23.167 to provide one. You may be able to find one provided by someon= e else. [[MCD] ] This doesn't sound right. There's no requirement in 23.167 that th= ere isn't a LoST server or that the RDF couldn't be implemented as a LoST s= erver. The LRF could query LoST in response to the routing request from the= E-CSCF. If the operator did that then they have the option to provide acce= ss to that LoST service for non-IMS phone-bcp procedures as well thereby su= pporting both the IMS use case and the general use cases as well. If you make such an attempt in a phone without a UICC, then you are not eve= n going to be able to get the request to leave the terminal. [[MCD] ] That's an IMS-specific consideration. The question of providing un= registered access to VoIP 9-1-1 is orthogonal. You can still do the emergen= cy registration procedures on IMS without excluding LoST and LIS for the LR= F mechanisms. If you do attempt to follow phoneBCP as a pure IP connection to some non-3G= PP provider, then you will not get the emergency bearer specified in 23.167= for LTE, UTRAN and cdma2000 accesses. That means other users could well ge= t priority on the radio access over you. [[MCD] ] Ditto, that's an IMS consideration. The question of priority for V= OIP 9-1-1 calls is orthogonal. You don't have to throw away IMS if you real= ly really think this is an imperative. Further, in principle, layer 4 metho= ds can still provide priority to sessions established with known PSAP/ESIne= t destinations consistent with the area of coverage of the network; so QoS = becomes a matter of degree not a binary consideration.=20 I would also add that many 3GPP or 3GPP2 operators will initially support e= mergency calls by pushing you back to the CS network (where they already ha= ve universal coverage), they can only do that if you follow the procedures = by which they recognize the emergency call attempt in the first place. Phon= eBCP does not provide for the UE making a call in that form. [[MCD] ] Absolutely agree; and phone-BCP isn't even a consideration if that= 's the scenario. Indeed the apparent likelihood that fallback to circuit se= rvices will be used for 9-1-1 (and, probably, voice generally) only raises = the question of when IMS will be the relevant consideration anyway. At the = same time, the increasing emphasis on strategies involving WiFi off-load ra= ise the question of how 9-1-1 would be supported in that case when the WiFi= may well be independent of the operator network. The best hope is actually= that phone-bcp procedures can be used on that access; that may be where Vo= IP actually bites first for mobile operators. The bottom line is that if you make an emergency call using a 3GPP or 3GPP2= phone in the manner specified in 23.167, then the 3GPP or 3GPP2 operator w= ill undertake to ensure that it works. If you attempt to make the emergency= call using procedures on the phone that are not specified in 23.167, then = you will have to do your own analysis on what works, and it is on your own = head if it does not. [[MCD] ] This falls under the category of the pseudo-legalistic argument. T= here is no explicit regulation currently and, as Brian says, there are no p= rotocol police. When it comes to supporting emergency calls made on IP (tha= t is - VoIP) operators have their own choices as to the extent and manner i= n which they implement solutions. There's not much in the way regulatory im= perative at the moment - so if you're not subscribing to any circuit servic= e (wired or wireless) at the moment you're already taking the consequences = "on your own head". But then... that's what people are doing isn't it. If you want to alter what 3GPP specifies, then you make the appropriate con= tribution to 3GPP, not try and write something in an IETF RFC to imply that= it is accepted fact. [[MCD] ] That would be good. I'd really like to see 3GPP taking a proactive= approach to showing how the ECRIT and associated IETF protocols can comfor= tably be integrated with the IMS use case. As I say, this should not be a s= urprising possibility given the design principle of IMS anyway. Regards Keith > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@commscope.com] > Sent: 10 March 2011 04:55 > To: DRAGE, Keith (Keith) > Cc: 'ecrit Org' > Subject: IMS and ECRIT are not incompatible >=20 > Given this is going off-topic with respect to the original thread, I'll > pick up Keith's point with a new subject title. >=20 > There's a meme going around that IMS emergency calling, specified in the > stage 2 3GPP TS 23.167, is somehow a mutually exclusive alternative or > inconsistent architecture with ECRIT and phone BCP. >=20 > I don't think that's true at all. >=20 > It should be self evident that, like any other solution, IMS needs to > address the functions of location determination and call routing. And, > indeed, these functions are covered in 23.167 and are attributed to the > "LRF" (Location Retrieval Function) network element. The spec decomposes > the LRF into the logical functions of "LS" and "RDF" ("Location Server" > and "Route Determination Function"). Most aspects of the operation of the > LS and RDF are left out of scope or implementation dependent - which is > fair enough. >=20 > There's a quite practical, IMS consistent, deployment of the LRF that use= s > LoST as the implementation for the RDF and HELD for the LS function. This > should not be any surprise since IMS is like an over the top VoIP service > with the simplification that all the elements can be in the same trust > domain (though I find IMS specifications to be curiously silent of the us= e > case of a subscriber initiating a call from a completely third party IP- > CAN such as a residential WiFi access). It's also attractive in that it's > consistent with respect to the principle of IMS being based on IETF > specifications as opposed to inventing 3GPP-specific mechanisms. >=20 > The real value to the network/IMS operator of course is that an > implementation that used LoST and HELD as described above would also > support the more general use cases that Keith rules out below - and > obviating the need to resort to pseudo-legalistic arguments to justify th= e > limited scope of IMS. It would also facilitate the use case mentioned > above assuming the broadband provider behind the residential WiFi > connection also had a consistent implementation. It's all good. >=20 > Cheers, > Martin >=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: Thursday, 10 March 2011 3:12 AM > To: Dawson, Martin; James M. Polk; Henning Schulzrinne; Brian Rosen > Cc: 'ecrit Org' > Subject: RE: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt >=20 > The applicability of this document to most mobile phone networks is > tenuous anyway. >=20 > For Voip, 3GPP and 3GPP2 based networks have a defined manner of > supporting emergency calls covered by 3GPP common IMS specifications, > backed up by use of the existing CS network where such exists. >=20 > As far as the 3GPP and 3GPP2 operators are concerned the 3GPP > specifications meet their obligations to the regulators, and the phones > wishing to use those capabilities have to correspond to the 3GPP > specifications. >=20 > Those specifications correspond to phone BCP only where they are trying t= o > address a common requirement. Key things they will not do is use of Lost > and Lost servers, endpoint location validation, no encryption of location= , > as this is protected by trust domains, no direct calling of the PSAP from > the end device - recognition instead by intermediate SIP entities, etc. >=20 > If as an end user you choose to ignore those provisions for support of > emergency calls in 3GPP and 3GPP2 networks, and make the call using an IP > connection to some other service provider, then that is your look out. It > imposes no obligations on the 3GPP or 3GPP2 service provider. >=20 > Now there were comments prior to this to write some of this into the > document. As far as I am concerned those comments are still open. >=20 > Regards >=20 > Keith >=20 > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: 08 March 2011 03:35 > > To: James M. Polk; Henning Schulzrinne; Brian Rosen > > Cc: DRAGE, Keith (Keith); 'ecrit Org' > > Subject: RE: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt > > > > I agree with this. > > > > I'll go out on a limb and confess I don't understand why the point of > > (circuit service) mobile codecs came up anyway. These are air interface > > codecs and they will have been transcoded by the time the traffic hits > the > > circuits in the core network anyway. I'm struggling to see why they are > > pertinent to the spec at all. > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of > > James M. Polk > > Sent: Sunday, 6 March 2011 5:38 PM > > To: Henning Schulzrinne; Brian Rosen > > Cc: DRAGE, Keith (Keith); 'ecrit Org' > > Subject: Re: [Ecrit] Gen-ART review of draft-ietf-ecrit-phonebcp-16.txt > > > > I agree with Henning here. We really cannot really control or > > reliably expect that within the existing SW upgradeable > > "interworking" products that we can mandate a codec. > > > > That said, Gunnar is also right, this shouldn't be only an "ED" > > requirement. > > > > Along those lines, I think this requirement, while well intentioned, > > falls into the gap between IP and circuit, in which we can't > > truthfully say that we "know" this only applies to the IP part - at > > least not without rewording to limit this. > > > > Something needs to state definitively that when the media gets to the > > ESRP - via mobile or wired - it needs to be in either the G.711 or > > G.722 codec for interoperability sake. That means the cellco mobile > > devices can use whatever codec they want, as long as the cellco > > converts to 711 or 722 once the media is transcoded to RTP. > > > > I'm not sure we have a requirement that say exactly that, and I think > > we should for this situation. > > > > James > > > > At 10:48 AM 3/5/2011, Henning Schulzrinne wrote: > > >There's nothing we can do about this problem, particularly given > > >that there doesn't appear to be a universal codec for mobile > > >devices. Also, I suspect that all mobile calls *today* show up as > > >G.711 by the time they reach the ESInet, since they go through a > > >circuit-to-packet conversion. Once we have VoIP-over-LTE, it might > > >be appropriate to add the most common wideband codec for that > > >configuration to the SHOULD list. There doesn't seem to be as much > > >point in adding narrowband codecs, since the conversion to G.711 is > > >cheap and no quality would be lost in translation. > > > > > >Henning > > > > > >On Mar 5, 2011, at 10:24 AM, Brian Rosen wrote: > > > > > > > Nope, no downside. I can do that. > > > > > > > > Doesn't handle the problem that started this: mobile phones don't > > > do G.711 or G.722 > > > > > >_______________________________________________ > > >Ecrit mailing list > > >Ecrit@ietf.org > > >https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit From mlinsner@cisco.com Thu Mar 17 05:56:28 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 691BE3A696E for ; Thu, 17 Mar 2011 05:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nY1+XYlOCLnc for ; Thu, 17 Mar 2011 05:56:25 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id ED2193A695F for ; Thu, 17 Mar 2011 05:56:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=4846; q=dns/txt; s=iport; t=1300366673; x=1301576273; h=date:subject:from:to:message-id:mime-version; bh=7Ix+Ed8o+W1VOgXOBPxxqXCJZopmWVy0rwKZhm16Goo=; b=kze90DL0c1qaX6XtFHMJnY+xZSkaoYctoE+4tGFBSqJc2/BXLypYPvZN y6O8j+kbZQoLPs/3iGwoDoJjtPyb5cWdttUxDp7PwsUoTOA2oojW2Mkky o2rg7/fNvcQ9T5y4Y6M6sGDukutWGDCHq5CSTXaFfiDZ5zuECbQ7fvJXH Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkHAHKigU2tJV2Z/2dsb2JhbACCW5YBAYYHAYYaT3eoG5wvhWMEjF6DTQ X-IronPort-AV: E=Sophos;i="4.63,199,1299456000"; d="scan'208,217";a="668070162" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-6.cisco.com with ESMTP; 17 Mar 2011 12:57:52 +0000 Received: from [10.116.195.124] (rtp-mlinsner-87111.cisco.com [10.116.195.124]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2HCvp7o027588 for ; Thu, 17 Mar 2011 12:57:51 GMT User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Thu, 17 Mar 2011 08:57:49 -0400 From: Marc Linsner To: Message-ID: Thread-Topic: Proposed Agenda - Prague Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3383197072_276271" Subject: [Ecrit] Proposed Agenda - Prague X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 12:56:28 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3383197072_276271 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable ECRIT WG Meeting Tuesday, March 29, 13:00 - 15:00 =AD Congress Hall I -------------------------------------------------------------------------- 10 min * Agenda Bashing, Draft Status Update (Marc Linsner, Richard Barnes, Roger Marshall) 10 min * Additional Data related to an Emergency Call (Brian/Hannes) http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ Intention: Discuss open issues 30 min. * Public Safety Answering Point (PSAP) Callbacks (Hannes/Milan?) http://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback/ Intention: Discuss issues/differences 30 min. * Trustworthy Location Information (Hannes/Bernard) http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/ Intention: Discuss issues/differences 30 min. * Extensions to the Emergency Services Architecture for dealing wit= h Unauthenticated and Unauthorized Devices (Dirk) http://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access/ Intention: Discuss issues and differences 10 min. * Open Discussion --B_3383197072_276271 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
ECRIT WG Meeting Tuesday, March 29, 13:00 - 15:0= 0 – Congress Hall I


---------= -----------------------------------------------------------------
10 min * Agenda Bashing, = Draft Status Update (Marc Linsner,
Richard Barnes, Roger Marshall)

10 min * Additional Data related to an Emergency = Call (Brian/Hannes)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/
Intention: Discu= ss open issues
=
30 min. * = Public Safety Answering Point (PSAP) Callbacks (Hannes/Milan?)
Intention: Discuss issues/differences

30 min. * Trustworthy Location Informati= on (Hannes/Bernard)
Intent= ion: Discuss issues/differences

30 min. * Extensions to the Emergency Services Architecture for deali= ng with
Unauthe= nticated and Unauthorized Devices (Dirk)
Intention: Discuss issues and differences

10 min. * Open Discussion

--B_3383197072_276271-- From RMarshall@telecomsys.com Thu Mar 17 10:43:55 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7F73A69F3 for ; Thu, 17 Mar 2011 10:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2gGmB7KbaSV for ; Thu, 17 Mar 2011 10:43:52 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [199.165.246.12]) by core3.amsl.com (Postfix) with ESMTP id E2F0C3A6A25 for ; Thu, 17 Mar 2011 10:43:51 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Thu, 17 Mar 2011 10:45:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE4CB.14BE49F6" Date: Thu, 17 Mar 2011 10:45:18 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657518A40683@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposed Agenda - Prague Thread-Index: AcvkovaM4Dqjf/xFQVeuZUSfexDAxgAJq43g References: From: "Roger Marshall" To: "Marc Linsner" , , "Richard L. Barnes" Subject: Re: [Ecrit] Proposed Agenda - Prague X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 17:43:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE4CB.14BE49F6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Marc: I'd like to request 10 min. to introduce a new individual draft that talks about an extension to RFC5222 that allows for the return of "similar" civic address elements when trying to validate an address that it doesn't have inside. =20 The draft link:=20 http://tools.ietf.org/id/draft-marshall-ecrit-similar-location-00.txt =20 This initial draft is a simple start, based on prior IETF77, 78 discussions that have been brought up as needed, and seeks to satisfy the need for a similar mechanism within NENA's i3 specification document. =20 -roger marshall. =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Thursday, March 17, 2011 5:58 AM To: ecrit@ietf.org Subject: [Ecrit] Proposed Agenda - Prague =20 ECRIT WG Meeting Tuesday, March 29, 13:00 - 15:00 - Congress Hall I =20 =20 ------------------------------------------------------------------------ -- 10 min * Agenda Bashing, Draft Status Update (Marc Linsner, Richard Barnes, Roger Marshall) =20 10 min * Additional Data related to an Emergency Call (Brian/Hannes) http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ Intention: Discuss open issues =20 30 min. * Public Safety Answering Point (PSAP) Callbacks (Hannes/Milan?) http://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback/ Intention: Discuss issues/differences =20 30 min. * Trustworthy Location Information (Hannes/Bernard) http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/ Intention: Discuss issues/differences =20 30 min. * Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices (Dirk) http://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access/ Intention: Discuss issues and differences =20 10 min. * Open Discussion =20 CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. ------_=_NextPart_001_01CBE4CB.14BE49F6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Marc:

I’d= like to request 10 min. to introduce a new individual draft that talks abo= ut an extension to RFC5222 that allows for the return of “similarR= 21; civic address elements when trying to validate an address that it doesn= ’t have inside.

 

The draft link:

http://tools.ietf.org/id/= draft-marshall-ecrit-similar-location-00.txt

 

This initial draft is a simple start, based on prior IETF77, 78 discuss= ions that have been brought up as needed, and seeks to satisfy the need for= a similar mechanism within NENA’s i3 specification document.

 

-roger marshall.

 

Fro= m: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf O= f Marc Linsner
Sent: Thursday, March 17, 2011 5:58 AM
T= o: ecrit@ietf.org
Subject: [Ecrit] Proposed Agenda - Prague

 

<= div>

ECRIT WG Meeting Tuesday, March 29, 13:00 - 15:00 R= 11; Congress Hall I

 =

 

<= div>

-----------------------------------------------------------= ---------------

10 min * Agenda= Bashing, Draft Status Update (Marc Linsner,

Richard Barnes, Roger Marshall)

 

= 10 min * = Additional Data related to an Emergency Call (Brian/Hannes)

Inte= ntion: Discuss open issues

 

30 min. * Public Safety Answ= ering Point (PSAP) Callbacks (Hannes/Milan?)

http://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callba= ck/

Intention: Discuss issu= es/differences

 

30 min. * Trustworthy Location Informati= on (Hannes/Bernard)

Intention: Discuss issues/differen= ces

 

30 min. * Extensions to the Emergency Services Arch= itecture for dealing with

Unaut= henticated and Unauthorized Devices (Dirk)

Intenti= on: Discuss issues and differences

 

10 min. * Open Discu= ssion

 <= /p>

CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

------_=_NextPart_001_01CBE4CB.14BE49F6-- From Martin.Thomson@commscope.com Thu Mar 17 21:31:02 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AED763A6A17 for ; Thu, 17 Mar 2011 21:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ML0x-jajoEyx for ; Thu, 17 Mar 2011 21:31:02 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id 9DF673A69D3 for ; Thu, 17 Mar 2011 21:30:59 -0700 (PDT) X-AuditID: 0a0404e9-b7ba5ae000000969-6d-4d82e05c8e3f Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id DC.A9.02409.C50E28D4; Thu, 17 Mar 2011 23:32:28 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 17 Mar 2011 23:32:28 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 18 Mar 2011 12:32:25 +0800 From: "Thomson, Martin" To: "Rosen, Brian" , "ecrit@ietf.org" Date: Fri, 18 Mar 2011 12:32:24 +0800 Thread-Topic: LoST and multiple responses -phone-bcp Thread-Index: AcvlJXpwnC+2zDhFRu+8qwnDqa1LnQ== Message-ID: <8B0A9FCBB9832F43971E38010638454F0400BEFF64@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Ecrit] LoST and multiple responses -phone-bcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 04:31:02 -0000 I was always under the impression that RFC5222 didn't allow for multiple re= sponses. Andrea corrected me on this, but it made me think: Shouldn't -phone-bcp say something about a LoST server offering multiple ro= utes? I looked, and Section 8 seemed to be the right place, but there isn'= t anything on it. The argument is exactly the same as for multiple locations: AN/SP-?? A LoST server SHOULD provide at most one emergency service mappi= ng for any combination of service and location. ED-?? The device SHOULD select the first valid mapping in a LoST response= if multiple mappings are present. --Martin From James.Winterbottom@commscope.com Thu Mar 17 21:37:56 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 993843A6A17 for ; Thu, 17 Mar 2011 21:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCox198UWEld for ; Thu, 17 Mar 2011 21:37:55 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id A2CB63A69D3 for ; Thu, 17 Mar 2011 21:37:55 -0700 (PDT) X-AuditID: 0a0404e9-b7ba5ae000000969-8e-4d82e1fcddda Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 73.C9.02409.CF1E28D4; Thu, 17 Mar 2011 23:39:24 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 17 Mar 2011 23:39:24 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 18 Mar 2011 12:39:19 +0800 From: "Winterbottom, James" To: "Thomson, Martin" , "Rosen, Brian" , "ecrit@ietf.org" Date: Fri, 18 Mar 2011 12:39:17 +0800 Thread-Topic: LoST and multiple responses -phone-bcp Thread-Index: AcvlJXpwnC+2zDhFRu+8qwnDqa1LnQAAKHhw Message-ID: <5A55A45AE77F5941B18E5457ECAC81880121003607C2@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F0400BEFF64@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0400BEFF64@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 04:37:56 -0000 Hey Martin, Just so I am clear on what you are saying. You could include just a basic sos service URN in the request to the LoST s= erver, but if you were in a jurisdiction that didn't have a single service = control point, but required separate service distinction for police, fire o= r ambulance, then you could get back 3 service mapping response. But it is = bad form to allow three service mappings all for police. Is that what you a= re saying? Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Thomson, Martin > Sent: Friday, 18 March 2011 3:32 PM > To: Rosen, Brian; ecrit@ietf.org > Subject: [Ecrit] LoST and multiple responses -phone-bcp >=20 > I was always under the impression that RFC5222 didn't allow for multiple > responses. Andrea corrected me on this, but it made me think: >=20 > Shouldn't -phone-bcp say something about a LoST server offering multiple > routes? I looked, and Section 8 seemed to be the right place, but there > isn't anything on it. >=20 > The argument is exactly the same as for multiple locations: >=20 > AN/SP-?? A LoST server SHOULD provide at most one emergency service > mapping for any combination of service and location. >=20 > ED-?? The device SHOULD select the first valid mapping in a LoST > response if multiple mappings are present. >=20 > --Martin > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From Martin.Thomson@commscope.com Thu Mar 17 21:46:48 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86E123A6AA3 for ; Thu, 17 Mar 2011 21:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1DtGtgaIEHE for ; Thu, 17 Mar 2011 21:46:47 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id 7445F3A6A7B for ; Thu, 17 Mar 2011 21:46:47 -0700 (PDT) X-AuditID: 0a0404e9-b7ba5ae000000969-42-4d82e40f47f2 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id DF.D9.02409.F04E28D4; Thu, 17 Mar 2011 23:48:16 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 17 Mar 2011 23:48:15 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 18 Mar 2011 12:48:12 +0800 From: "Thomson, Martin" To: "Winterbottom, James" , "Rosen, Brian" , "ecrit@ietf.org" Date: Fri, 18 Mar 2011 12:48:10 +0800 Thread-Topic: LoST and multiple responses -phone-bcp Thread-Index: AcvlJXpwnC+2zDhFRu+8qwnDqa1LnQAAKHhwAABDsXA= Message-ID: <8B0A9FCBB9832F43971E38010638454F0400BEFF6A@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F0400BEFF64@SISPE7MB1.commscope.com> <5A55A45AE77F5941B18E5457ECAC81880121003607C2@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880121003607C2@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 04:46:48 -0000 On 2011-03-18 at 15:39:17, Winterbottom, James wrote: > Hey Martin, >=20 > Just so I am clear on what you are saying. > You could include just a basic sos service URN in the request to the=20 > LoST server, but if you were in a jurisdiction that didn't have a=20 > single service control point, but required separate service=20 > distinction for police, fire or ambulance, then you could get back 3=20 > service mapping response. But it is bad form to allow three service=20 > mappings all for police. Is that what you are saying? Right. Given one location and one service, then you should get one mapping. If you could ask for police, fire and ambulance all at once, then I'd expec= t a mapping for each (even if all were the same mapping). But I don't thin= k you can't do that. --Martin From Martin.Thomson@commscope.com Thu Mar 17 21:57:52 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0191D3A68A2 for ; Thu, 17 Mar 2011 21:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.128 X-Spam-Level: X-Spam-Status: No, score=-3.128 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYo+p1VVS1-s for ; Thu, 17 Mar 2011 21:57:50 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id BBA9D3A672E for ; Thu, 17 Mar 2011 21:57:50 -0700 (PDT) X-AuditID: 0a0404e8-b7b25ae000007eb9-88-4d82e6a7460c Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id C3.EB.32441.7A6E28D4; Thu, 17 Mar 2011 23:59:19 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 17 Mar 2011 23:59:18 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 18 Mar 2011 12:59:15 +0800 From: "Thomson, Martin" To: "Andrea G. Forte" Date: Fri, 18 Mar 2011 12:59:13 +0800 Thread-Topic: [RAI] Review of draft-forte-lost-extensions-02 Thread-Index: Acvc52ysA4FTKO+cRnSv4hObBBQ7agIO/47w Message-ID: <8B0A9FCBB9832F43971E38010638454F0400BEFF6D@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [RAI] Review of draft-forte-lost-extensions-02 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 04:57:52 -0000 Hi Andrea, I'll go through those parts that I think need clarification. I think that I understand where the disconnect is occurring. We need to fi= x that. Regrettably, it's looking more like a fault in RFC5222 than any sp= ecial fault in your document. On 2011-03-08 at 03:47:24, Andrea G. Forte wrote: > Martin, >=20 > Thank you for your comments and apologize for my late reply. Please=20 > read my responses inline. > (Sorry for the duplicate, I forgot to include the ECRIT mailing list=20 > in my previous email). >=20 > -Andrea >=20 [...] > of multiple services. I have inferred that the idea is that the=20 > LoST > server picks the single best choice, because that makes the most=20 > sense > for emergency uses (no good comes from presenting a choice in these > cases). >=20 >=20 > [AGF] > What you infer is not correct. > The LoST protocol has been designed to support both emergency and non-=20 > emergency services. > You can read in RFC5222, Section 12.2 the following: "A server MAY=20 > return multiple elements if the shape extends across=20 > multiple service areas.". I know of some LoST servers behaving like=20 > this also for emergency services so that when the user location=20 > overlaps between two PSAP boundaries, both PSAPs are returned by the LoST= server. Thanks for finding that, I looked twice and couldn't find it. We should do= something about that in -phone-bcp - it's a real problem. > What this draft proposes for "within X" relies on some sort of=20 > implicit > processing that is inconsistent with RFC5222. It relies on the fact=20 > that > the LoST server knows that a particular service is somehow special. >=20 >=20 > [AGF] > Currently the "within X" query is the default query so that unless you=20 > specify the element to be true it will treat it as "within X" > query. > The LoST server does not need > to have some implicit knowledge. > I think it is a good idea though to assume that when the =20 > element is missing, it is assumed to be true rather than false. This=20 > will make the default query a "served by" query thus making the=20 > behavior consistent with RFC 5222 for emergency services (which use a=20 > "served by" > query). That's where we'll have to disagree. There is an implicit assumption here = that a location with uncertainty (the circle that you attempt to use) does = not get a choice between the two implicit (existing) behaviours: 1 - Pick the best match for my location 2 - Show me all possible matches for my location And the new option (subtle difference) =20 3 - Show me all possible matches for this area I can live with 2 and 3 being collapsed, but the protocol semantics need to= be clear about this, or we end up in a mess. I think that the document makes a reasonable case for 2, but I'd like to ke= ep 1 for emergency services and keep the two distinct. My previous comments about recursive resolution still apply. An in-band in= dication is even more necessary when recursion occurs. >=20 >=20 > The location profile can be used to identify which location you want=20 > to > use if the content of the element is not sufficient. >=20 > [AGF] > I am not sure what you mean by this. This is related to the above problem. > The reason given for these recommendations: >=20 > [...] as the computation of the distance, route and other metrics > would at some point require geocoding of the civic address in > geodetic coordinates. Because of this, the position specified in > SHOULD be represented by using the =20 > element. >=20 > ... is not necessary for interoperability. This seems more for the > convenience of LoST server implementations. Wouldn't these reasons=20 > be > better suited to a LoST server provisioning guide? >=20 > A better reason might be that a recipient of the mapping information > might need to use this information without the necessary context to > understand the civic address. However, the same reason doesn't=20 > support > the recommendation for using a . >=20 > [AGF] > There might be situations where the client would want to perform some=20 > light computations on location information but without having enough=20 > "power" to do geo encoding/decoding. How does that support the use of Point over other types? I assume that a c= lient just uses the location that it has. That only requires whatever comp= utations the client has to do in order to get the location (GPS, HELD, DHCP= , whatever). > Iterative Responses > The use of iterative resolution in LoST is a weak point that the=20 > ability > to provide multiple mappings does not help. In the case where a=20 > server > is able to provide only some answers, there is no facility for the=20 > server > to indicate where the remainder of the answers are found (that is,=20 > the > referral). >=20 > [AGF] > I am not sure I follow. The authoritative server for that region and=20 > for that class of service will reply with the results. Iteration=20 > continues only until an authoritative server is found. It's not possible, with a location shape that overlaps with the serving are= as of multiple LoST servers to have the first LoST server provide some mapp= ings and some referrals. =20 > Security > The security section could use some expansion. It's not sufficient=20 > to > just refer to RFC5222. >=20 > The denial of service concerns that Shida raised in his review are=20 > worth > discussing. A LoST server is discovered using the same means=20 > whether it > be for emergency or commercial uses. The possibility that=20 > commercial > uses could interfere with public safety is a significant concern. =20 > As > Shida notes, scaling is probably trivial to address, but that's not=20 > the > whole story. >=20 > [AGF] > I am very skeptical about this. >=20 > From a regulatory perspective: the NG911 infrastructure is mostly paid=20 > and maintained by collecting 911 fees that tax payers have to pay. I=20 > do not think LoST servers paid with tax payers money for > 911 can be used for supporting non-911 services. >=20 > From a security perspective: in the most general case, let's assume=20 > we have two different LoST servers, one used by the NG911 client to=20 > discover the correct ESRP and one used by the ESRP to discover the=20 > correct PSAP. The second LoST server would be inside the ESInet thus=20 > behind a firewall. Access to this LoST server would be granted only to=20 > known ESRPs via access control lists (this is how many vendors have it=20 > implemented) or similar. The first LoST server will be more reachable=20 > than the second one as it does not have to be necessarily in the=20 > ESInet. This, however, can be configured to only support=20 > urn:service:sos as type of service and will be an authoritative server=20 > for this type of service only (given the regulatory issues mentioned=20 > above and security concerns). > At this point, the same security considerations as in RFC5222 apply. This isn't a regulatory issue or anything related to a particular deploymen= t. It's a problem that you discover a LoST server in the same way regardle= ss of whether your service URI is "urn:service:sos" or "http://www.pizza-re= staurant.example/" Unless you change the way that a value-add LoST is disc= overed, the same server is contacted. Therefore, the same server needs to = handle ESRP requests and coffee shop requests. --Martin From forte@att.com Fri Mar 18 09:21:09 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5394D3A69A1 for ; Fri, 18 Mar 2011 09:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.901 X-Spam-Level: X-Spam-Status: No, score=-105.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89t6isjmJK7K for ; Fri, 18 Mar 2011 09:21:07 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id C6F613A6986 for ; Fri, 18 Mar 2011 09:21:06 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: forte@att.com X-Msg-Ref: server-2.tower-119.messagelabs.com!1300465346!6530102!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 26046 invoked from network); 18 Mar 2011 16:22:27 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-2.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Mar 2011 16:22:27 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p2IGMogF013092; Fri, 18 Mar 2011 12:22:50 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p2IGMkUI013035; Fri, 18 Mar 2011 12:22:46 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p2IGMLw9007967; Fri, 18 Mar 2011 12:22:22 -0400 Received: from [151.109.8.240] (ds151-109-8-240.dhcps.ugn.att.com [151.109.8.240]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p2IGMGRP007829; Fri, 18 Mar 2011 12:22:17 -0400 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Fri, 18 Mar 2011 12:22:15 -0400 From: "Andrea G. Forte" To: "Thomson, Martin" , "Winterbottom, James" , "Rosen, Brian" , "ecrit@ietf.org" Message-ID: Thread-Topic: [Ecrit] LoST and multiple responses -phone-bcp In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0400BEFF6A@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 16:21:10 -0000 So, are we saying that for emergency services only, the LoST server will pick and return one result all the time? If so, how do we account for a wrong decision on the LoST server part? Are we just leaving that to "human intervention"? There should be at least a level of confidence on the location of the user falling within some PSAP boundaries. Again, I am assuming this would apply to emergency services only. -Andrea On 3/18/11 12:48 AM, "Thomson, Martin" wrote: >On 2011-03-18 at 15:39:17, Winterbottom, James wrote: >> Hey Martin, >> >> Just so I am clear on what you are saying. >> You could include just a basic sos service URN in the request to the >> LoST server, but if you were in a jurisdiction that didn't have a >> single service control point, but required separate service >> distinction for police, fire or ambulance, then you could get back 3 >> service mapping response. But it is bad form to allow three service >> mappings all for police. Is that what you are saying? > >Right. > >Given one location and one service, then you should get one mapping. > >If you could ask for police, fire and ambulance all at once, then I'd >expect a mapping for each (even if all were the same mapping). But I >don't think you can't do that. > >--Martin >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From brian.rosen@neustar.biz Fri Mar 18 09:28:35 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D340D3A6926 for ; Fri, 18 Mar 2011 09:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5tA7XZ52RbI for ; Fri, 18 Mar 2011 09:28:34 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by core3.amsl.com (Postfix) with ESMTP id 3BC3C3A6953 for ; Fri, 18 Mar 2011 09:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1300465797; x=1615822053; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=IyWQRR/BT//FMa6Sn6CqS RM7ffpFdkjXJR+xP+xHj54=; b=U/rJwaicu/m+IEvUJFjfsIRTTj/Ug35Z9pXFf C8fFjZrDzrJ03HQn8Vm0KAIREqOwtXVj0hDBBNJzDtZlvO6xw== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.43386027; Fri, 18 Mar 2011 12:29:56 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Fri, 18 Mar 2011 12:29:55 -0400 From: "Rosen, Brian" To: "Andrea G. Forte" Date: Fri, 18 Mar 2011 12:29:55 -0400 Thread-Topic: [Ecrit] LoST and multiple responses -phone-bcp Thread-Index: Acvlibbdi8ozNv2tSK63BxNq3ZtnoQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: TVtSq6KQYp9KfiViW7CFOg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Thomson, Martin" , "ecrit@ietf.org" Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 16:28:36 -0000 My general advice for this kind of thing is that the querier has no way to = figure out which of a set of choices is correct. The LoST server at least = has a shot of picking out the best one. Brian On Mar 18, 2011, at 12:22 PM, Andrea G. Forte wrote: > So, are we saying that for emergency services only, the LoST server will > pick and return one result all the time? If so, how do we account for a > wrong decision on the LoST server part? Are we just leaving that to "huma= n > intervention"?=20 > There should be at least a level of confidence on the location of the use= r > falling within some PSAP boundaries. >=20 > Again, I am assuming this would apply to emergency services only. >=20 > -Andrea >=20 >=20 > On 3/18/11 12:48 AM, "Thomson, Martin" > wrote: >=20 >> On 2011-03-18 at 15:39:17, Winterbottom, James wrote: >>> Hey Martin, >>>=20 >>> Just so I am clear on what you are saying. >>> You could include just a basic sos service URN in the request to the >>> LoST server, but if you were in a jurisdiction that didn't have a >>> single service control point, but required separate service >>> distinction for police, fire or ambulance, then you could get back 3 >>> service mapping response. But it is bad form to allow three service >>> mappings all for police. Is that what you are saying? >>=20 >> Right. >>=20 >> Given one location and one service, then you should get one mapping. >>=20 >> If you could ask for police, fire and ambulance all at once, then I'd >> expect a mapping for each (even if all were the same mapping). But I >> don't think you can't do that. >>=20 >> --Martin >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From rbarnes@bbn.com Fri Mar 18 10:05:16 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 646EF3A6986 for ; Fri, 18 Mar 2011 10:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.383 X-Spam-Level: X-Spam-Status: No, score=-102.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kn+WScMBk5Mi for ; Fri, 18 Mar 2011 10:05:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 889413A6955 for ; Fri, 18 Mar 2011 10:05:15 -0700 (PDT) Received: from [192.1.255.181] (port=64293 helo=col-raltmann-l1.nira.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q0d8N-0003EV-Ux; Fri, 18 Mar 2011 13:06:44 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Fri, 18 Mar 2011 13:06:42 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Rosen, Brian" X-Mailer: Apple Mail (2.1082) Cc: "Thomson, Martin" , "ecrit@ietf.org" Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 17:05:16 -0000 That might not be categorically true, right? If there are service = boundaries included, then a human has a chance of saying "I'm in this = one". On Mar 18, 2011, at 12:29 PM, Rosen, Brian wrote: > My general advice for this kind of thing is that the querier has no = way to figure out which of a set of choices is correct. The LoST server = at least has a shot of picking out the best one. >=20 > Brian >=20 > On Mar 18, 2011, at 12:22 PM, Andrea G. Forte wrote: >=20 >> So, are we saying that for emergency services only, the LoST server = will >> pick and return one result all the time? If so, how do we account for = a >> wrong decision on the LoST server part? Are we just leaving that to = "human >> intervention"?=20 >> There should be at least a level of confidence on the location of the = user >> falling within some PSAP boundaries. >>=20 >> Again, I am assuming this would apply to emergency services only. >>=20 >> -Andrea >>=20 >>=20 >> On 3/18/11 12:48 AM, "Thomson, Martin" >> wrote: >>=20 >>> On 2011-03-18 at 15:39:17, Winterbottom, James wrote: >>>> Hey Martin, >>>>=20 >>>> Just so I am clear on what you are saying. >>>> You could include just a basic sos service URN in the request to = the >>>> LoST server, but if you were in a jurisdiction that didn't have a >>>> single service control point, but required separate service >>>> distinction for police, fire or ambulance, then you could get back = 3 >>>> service mapping response. But it is bad form to allow three service >>>> mappings all for police. Is that what you are saying? >>>=20 >>> Right. >>>=20 >>> Given one location and one service, then you should get one mapping. >>>=20 >>> If you could ask for police, fire and ambulance all at once, then = I'd >>> expect a mapping for each (even if all were the same mapping). But = I >>> don't think you can't do that. >>>=20 >>> --Martin >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From brian.rosen@neustar.biz Fri Mar 18 10:13:36 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34A3D3A6986 for ; Fri, 18 Mar 2011 10:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQuJuZ1kCbjS for ; Fri, 18 Mar 2011 10:13:35 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by core3.amsl.com (Postfix) with ESMTP id D41023A696F for ; Fri, 18 Mar 2011 10:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1300468438; x=1615814944; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=s969IA6pHUms9cZIPZVLw kc5yQll8lZQuBWrW9TJgUo=; b=fu2wx7GylQzWnp/BYmiLimz68mHrDl8TCAlQu h5AMkkUprMr2Nc6rQq4+jL9Cu97IkmALf7mYTRIpCB43RR98g== Received: from ([10.31.13.242]) by chihiron1.nc.neustar.com with ESMTP with TLS id 5202942.37352693; Fri, 18 Mar 2011 13:13:57 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Fri, 18 Mar 2011 13:13:56 -0400 From: "Rosen, Brian" To: "Richard L. Barnes" Date: Fri, 18 Mar 2011 13:13:56 -0400 Thread-Topic: [Ecrit] LoST and multiple responses -phone-bcp Thread-Index: Acvlj9zo945ouoqLQsK9FcLc3FvKRA== Message-ID: <98F624CC-F575-42F1-A747-D02F935FB724@neustar.biz> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: XaoYNKae0ApYINg/FtUvqA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Thomson, Martin" , "ecrit@ietf.org" Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 17:13:36 -0000 Based on what knowledge the human has that the LoST server doesn't? In general, I think this case only occurs due to a provisioning error (over= lap of service boundaries). If it does, the LoST server is probably better= at figuring it out. Brian On Mar 18, 2011, at 1:06 PM, Richard L. Barnes wrote: > That might not be categorically true, right? If there are service bounda= ries included, then a human has a chance of saying "I'm in this one". >=20 >=20 > On Mar 18, 2011, at 12:29 PM, Rosen, Brian wrote: >=20 >> My general advice for this kind of thing is that the querier has no way = to figure out which of a set of choices is correct. The LoST server at lea= st has a shot of picking out the best one. >>=20 >> Brian >>=20 >> On Mar 18, 2011, at 12:22 PM, Andrea G. Forte wrote: >>=20 >>> So, are we saying that for emergency services only, the LoST server wil= l >>> pick and return one result all the time? If so, how do we account for a >>> wrong decision on the LoST server part? Are we just leaving that to "hu= man >>> intervention"?=20 >>> There should be at least a level of confidence on the location of the u= ser >>> falling within some PSAP boundaries. >>>=20 >>> Again, I am assuming this would apply to emergency services only. >>>=20 >>> -Andrea >>>=20 >>>=20 >>> On 3/18/11 12:48 AM, "Thomson, Martin" >>> wrote: >>>=20 >>>> On 2011-03-18 at 15:39:17, Winterbottom, James wrote: >>>>> Hey Martin, >>>>>=20 >>>>> Just so I am clear on what you are saying. >>>>> You could include just a basic sos service URN in the request to the >>>>> LoST server, but if you were in a jurisdiction that didn't have a >>>>> single service control point, but required separate service >>>>> distinction for police, fire or ambulance, then you could get back 3 >>>>> service mapping response. But it is bad form to allow three service >>>>> mappings all for police. Is that what you are saying? >>>>=20 >>>> Right. >>>>=20 >>>> Given one location and one service, then you should get one mapping. >>>>=20 >>>> If you could ask for police, fire and ambulance all at once, then I'd >>>> expect a mapping for each (even if all were the same mapping). But I >>>> don't think you can't do that. >>>>=20 >>>> --Martin >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From rbarnes@bbn.com Fri Mar 18 10:51:03 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82C713A69D0 for ; Fri, 18 Mar 2011 10:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VLyFtIvLqQf for ; Fri, 18 Mar 2011 10:51:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 9D8553A69CD for ; Fri, 18 Mar 2011 10:51:02 -0700 (PDT) Received: from [192.1.255.181] (port=64478 helo=col-raltmann-l1.nira.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q0dqh-0003nN-En; Fri, 18 Mar 2011 13:52:31 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <98F624CC-F575-42F1-A747-D02F935FB724@neustar.biz> Date: Fri, 18 Mar 2011 13:52:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1094E783-5D92-4DAE-8DEB-0B80146EAD27@bbn.com> References: <98F624CC-F575-42F1-A747-D02F935FB724@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1082) Cc: "Thomson, Martin" , "ecrit@ietf.org" Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 17:51:03 -0000 I'm imagining cases with imprecise location. If I'm in Luxembourg and = located to cell tower level accuracy, then my location value could = overlap PSAP boundaries in France and Belgium. But if I get back = mappings for Belgian, French, and Luxemburgish PSAPs, then I can say, = "Yes, I'm in Luxembourg". --Richard On Mar 18, 2011, at 1:13 PM, Rosen, Brian wrote: > Based on what knowledge the human has that the LoST server doesn't? >=20 > In general, I think this case only occurs due to a provisioning error = (overlap of service boundaries). If it does, the LoST server is = probably better at figuring it out. >=20 > Brian >=20 > On Mar 18, 2011, at 1:06 PM, Richard L. Barnes wrote: >=20 >> That might not be categorically true, right? If there are service = boundaries included, then a human has a chance of saying "I'm in this = one". >>=20 >>=20 >> On Mar 18, 2011, at 12:29 PM, Rosen, Brian wrote: >>=20 >>> My general advice for this kind of thing is that the querier has no = way to figure out which of a set of choices is correct. The LoST server = at least has a shot of picking out the best one. >>>=20 >>> Brian >>>=20 >>> On Mar 18, 2011, at 12:22 PM, Andrea G. Forte wrote: >>>=20 >>>> So, are we saying that for emergency services only, the LoST server = will >>>> pick and return one result all the time? If so, how do we account = for a >>>> wrong decision on the LoST server part? Are we just leaving that to = "human >>>> intervention"?=20 >>>> There should be at least a level of confidence on the location of = the user >>>> falling within some PSAP boundaries. >>>>=20 >>>> Again, I am assuming this would apply to emergency services only. >>>>=20 >>>> -Andrea >>>>=20 >>>>=20 >>>> On 3/18/11 12:48 AM, "Thomson, Martin" = >>>> wrote: >>>>=20 >>>>> On 2011-03-18 at 15:39:17, Winterbottom, James wrote: >>>>>> Hey Martin, >>>>>>=20 >>>>>> Just so I am clear on what you are saying. >>>>>> You could include just a basic sos service URN in the request to = the >>>>>> LoST server, but if you were in a jurisdiction that didn't have a >>>>>> single service control point, but required separate service >>>>>> distinction for police, fire or ambulance, then you could get = back 3 >>>>>> service mapping response. But it is bad form to allow three = service >>>>>> mappings all for police. Is that what you are saying? >>>>>=20 >>>>> Right. >>>>>=20 >>>>> Given one location and one service, then you should get one = mapping. >>>>>=20 >>>>> If you could ask for police, fire and ambulance all at once, then = I'd >>>>> expect a mapping for each (even if all were the same mapping). = But I >>>>> don't think you can't do that. >>>>>=20 >>>>> --Martin >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 From brian.rosen@neustar.biz Fri Mar 18 11:17:40 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A74813A69B7 for ; Fri, 18 Mar 2011 11:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lScwW3GsPnfJ for ; Fri, 18 Mar 2011 11:17:39 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by core3.amsl.com (Postfix) with ESMTP id 083FD3A6995 for ; Fri, 18 Mar 2011 11:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1300472268; x=1615825669; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=ontQEnI15lEkK6VSyfF7k tZIEKkS5g3Gb8wrx/i/y6Y=; b=mTLlGpknkA5oEjZ/CSODnnAupRZoBxQs6b2+O nj9HG8YTocIOoLOL0sTDy6Mv0JGelB+6ztZIJ0/qJN0Ig4ynw== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id G6K7MJ1.20783116; Fri, 18 Mar 2011 14:17:47 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Fri, 18 Mar 2011 14:17:46 -0400 From: "Rosen, Brian" To: "Richard L. Barnes" Date: Fri, 18 Mar 2011 14:17:46 -0400 Thread-Topic: [Ecrit] LoST and multiple responses -phone-bcp Thread-Index: AcvlmMf+OzWZemZHQsOSMgr8MbRjsg== Message-ID: References: <98F624CC-F575-42F1-A747-D02F935FB724@neustar.biz> <1094E783-5D92-4DAE-8DEB-0B80146EAD27@bbn.com> In-Reply-To: <1094E783-5D92-4DAE-8DEB-0B80146EAD27@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: e4QOoXQEGzH0sqzvzyR49A== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Thomson, Martin" , "ecrit@ietf.org" Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 18:17:40 -0000 Today, these are decided by cell tower. Calls from a given sector route to= a specific PSAP. =20 Generally, asking for user input during a call is frowned upon. Brian On Mar 18, 2011, at 1:52 PM, Richard L. Barnes wrote: > I'm imagining cases with imprecise location. If I'm in Luxembourg and lo= cated to cell tower level accuracy, then my location value could overlap PS= AP boundaries in France and Belgium. But if I get back mappings for Belgia= n, French, and Luxemburgish PSAPs, then I can say, "Yes, I'm in Luxembourg"= . >=20 > --Richard >=20 >=20 > On Mar 18, 2011, at 1:13 PM, Rosen, Brian wrote: >=20 >> Based on what knowledge the human has that the LoST server doesn't? >>=20 >> In general, I think this case only occurs due to a provisioning error (o= verlap of service boundaries). If it does, the LoST server is probably bet= ter at figuring it out. >>=20 >> Brian >>=20 >> On Mar 18, 2011, at 1:06 PM, Richard L. Barnes wrote: >>=20 >>> That might not be categorically true, right? If there are service boun= daries included, then a human has a chance of saying "I'm in this one". >>>=20 >>>=20 >>> On Mar 18, 2011, at 12:29 PM, Rosen, Brian wrote: >>>=20 >>>> My general advice for this kind of thing is that the querier has no wa= y to figure out which of a set of choices is correct. The LoST server at l= east has a shot of picking out the best one. >>>>=20 >>>> Brian >>>>=20 >>>> On Mar 18, 2011, at 12:22 PM, Andrea G. Forte wrote: >>>>=20 >>>>> So, are we saying that for emergency services only, the LoST server w= ill >>>>> pick and return one result all the time? If so, how do we account for= a >>>>> wrong decision on the LoST server part? Are we just leaving that to "= human >>>>> intervention"?=20 >>>>> There should be at least a level of confidence on the location of the= user >>>>> falling within some PSAP boundaries. >>>>>=20 >>>>> Again, I am assuming this would apply to emergency services only. >>>>>=20 >>>>> -Andrea >>>>>=20 >>>>>=20 >>>>> On 3/18/11 12:48 AM, "Thomson, Martin" >>>>> wrote: >>>>>=20 >>>>>> On 2011-03-18 at 15:39:17, Winterbottom, James wrote: >>>>>>> Hey Martin, >>>>>>>=20 >>>>>>> Just so I am clear on what you are saying. >>>>>>> You could include just a basic sos service URN in the request to th= e >>>>>>> LoST server, but if you were in a jurisdiction that didn't have a >>>>>>> single service control point, but required separate service >>>>>>> distinction for police, fire or ambulance, then you could get back = 3 >>>>>>> service mapping response. But it is bad form to allow three service >>>>>>> mappings all for police. Is that what you are saying? >>>>>>=20 >>>>>> Right. >>>>>>=20 >>>>>> Given one location and one service, then you should get one mapping. >>>>>>=20 >>>>>> If you could ask for police, fire and ambulance all at once, then I'= d >>>>>> expect a mapping for each (even if all were the same mapping). But = I >>>>>> don't think you can't do that. >>>>>>=20 >>>>>> --Martin >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>=20 >=20 From hgs@cs.columbia.edu Fri Mar 18 13:28:48 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0429F3A6A33 for ; Fri, 18 Mar 2011 13:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rECFW8yEcB0l for ; Fri, 18 Mar 2011 13:28:44 -0700 (PDT) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by core3.amsl.com (Postfix) with ESMTP id A708D3A6A29 for ; Fri, 18 Mar 2011 13:28:43 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p2IKTdsl003656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 18 Mar 2011 16:29:39 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: Date: Fri, 18 Mar 2011 16:29:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <85C7AED8-45D7-4540-983C-0DABEA2D8948@cs.columbia.edu> References: <98F624CC-F575-42F1-A747-D02F935FB724@neustar.biz> <1094E783-5D92-4DAE-8DEB-0B80146EAD27@bbn.com> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1082) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: "Thomson, Martin" , "ecrit@ietf.org" Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 20:28:48 -0000 See = http://www.policechiefmagazine.org/magazine/index.cfm?fuseaction=3Ddisplay= _arch&article_id=3D2069&issue_id=3D42010 for a similar solution: The caller is asked to input a zip code or city = name. On Mar 18, 2011, at 2:17 PM, Rosen, Brian wrote: > Today, these are decided by cell tower. Calls from a given sector = route to a specific PSAP. =20 > Generally, asking for user input during a call is frowned upon. >=20 > Brian From brian.rosen@neustar.biz Fri Mar 18 13:38:59 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F15553A69B3 for ; Fri, 18 Mar 2011 13:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Stt+eSCOWKrw for ; Fri, 18 Mar 2011 13:38:57 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by core3.amsl.com (Postfix) with ESMTP id 901873A69E0 for ; Fri, 18 Mar 2011 13:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1300480731; x=1615838285; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=IqeitRhNTmhxgQwe65TDn zxlHOPxxf9LSZFHrjE1Vqg=; b=qXejKUUEJSijAqHHFoaqN/1+4vO4pDXu8reYN PQFc915tIoOMRwS/hn7yk4ZkZPy1kMXWp5diIHXzInu/qrrBg== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id G6K7MJ1.20788803; Fri, 18 Mar 2011 16:38:50 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Fri, 18 Mar 2011 16:38:49 -0400 From: "Rosen, Brian" To: Henning Schulzrinne Date: Fri, 18 Mar 2011 16:38:48 -0400 Thread-Topic: [Ecrit] LoST and multiple responses -phone-bcp Thread-Index: AcvlrHxPZEJ0rZSuRpCu8Neua64WWA== Message-ID: <94E28E6F-D1A9-4354-B0BC-0C668C93F69E@neustar.biz> References: <98F624CC-F575-42F1-A747-D02F935FB724@neustar.biz> <1094E783-5D92-4DAE-8DEB-0B80146EAD27@bbn.com> <85C7AED8-45D7-4540-983C-0DABEA2D8948@cs.columbia.edu> In-Reply-To: <85C7AED8-45D7-4540-983C-0DABEA2D8948@cs.columbia.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: R8q1nPdqYX+SDvLgBZp7Bw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Thomson, Martin" , "ecrit@ietf.org" Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 20:38:59 -0000 I'm familiar with this. It's really a bad solution in my opinion, given th= at the cellid comes in the SMS messaging protocol and we already have mappi= ng from cell id to PSAP in current systems. =20 You send a message to the short code. It replies with a request to text yo= ur address (as a civic). It then forwards the text to the PSAP. Brian On Mar 18, 2011, at 4:29 PM, Henning Schulzrinne wrote: > See > http://www.policechiefmagazine.org/magazine/index.cfm?fuseaction=3Ddispla= y_arch&article_id=3D2069&issue_id=3D42010 > for a similar solution: The caller is asked to input a zip code or city n= ame. >=20 > On Mar 18, 2011, at 2:17 PM, Rosen, Brian wrote: >=20 >> Today, these are decided by cell tower. Calls from a given sector route= to a specific PSAP. =20 >> Generally, asking for user input during a call is frowned upon. >>=20 >> Brian >=20 From forte@att.com Fri Mar 18 13:59:40 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1557B3A6A19 for ; Fri, 18 Mar 2011 13:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.133 X-Spam-Level: X-Spam-Status: No, score=-106.133 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ja64Haacw+rT for ; Fri, 18 Mar 2011 13:59:39 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id E36B03A69A7 for ; Fri, 18 Mar 2011 13:59:38 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: forte@att.com X-Msg-Ref: server-15.tower-120.messagelabs.com!1300482067!8587128!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 21249 invoked from network); 18 Mar 2011 21:01:08 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-15.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Mar 2011 21:01:08 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p2IL1V3I032357; Fri, 18 Mar 2011 17:01:31 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p2IL1Sn0032343; Fri, 18 Mar 2011 17:01:28 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p2IL14UN022980; Fri, 18 Mar 2011 17:01:04 -0400 Received: from [151.109.8.240] (ds151-109-8-240.dhcps.ugn.att.com [151.109.8.240]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p2IL0uG8022548; Fri, 18 Mar 2011 17:00:58 -0400 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Fri, 18 Mar 2011 17:00:56 -0400 From: "Andrea G. Forte" To: "Rosen, Brian" , Henning Schulzrinne Message-ID: Thread-Topic: [Ecrit] LoST and multiple responses -phone-bcp In-Reply-To: <94E28E6F-D1A9-4354-B0BC-0C668C93F69E@neustar.biz> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "Thomson, Martin" , "ecrit@ietf.org" Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 20:59:40 -0000 If the LoST server decides wrong and routes my call to the wrong PSAP, the 9-1-1 operator will have to "discover" that a wrong routing has taken place, will have to find the correct PSAP and will have to transfer the call to the correct PSAP. All of this while I am on the call. As a user I would rather "select" one of the returned multiple mappings when making the call in the first place. -Andrea On 3/18/11 4:38 PM, "Rosen, Brian" wrote: >I'm familiar with this. It's really a bad solution in my opinion, given >that the cellid comes in the SMS messaging protocol and we already have >mapping from cell id to PSAP in current systems. > >You send a message to the short code. It replies with a request to text >your address (as a civic). It then forwards the text to the PSAP. > >Brian > >On Mar 18, 2011, at 4:29 PM, Henning Schulzrinne wrote: > >> See >> >>http://www.policechiefmagazine.org/magazine/index.cfm?fuseaction=display_ >>arch&article_id=2069&issue_id=42010 >> for a similar solution: The caller is asked to input a zip code or city >>name. >> >> On Mar 18, 2011, at 2:17 PM, Rosen, Brian wrote: >> >>> Today, these are decided by cell tower. Calls from a given sector >>>route to a specific PSAP. >>> Generally, asking for user input during a call is frowned upon. >>> >>> Brian >> > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From James.Winterbottom@commscope.com Fri Mar 18 14:33:12 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7DC3A699A for ; Fri, 18 Mar 2011 14:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrH5lkkRih7g for ; Fri, 18 Mar 2011 14:33:10 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id B9F063A68FE for ; Fri, 18 Mar 2011 14:33:10 -0700 (PDT) X-AuditID: 0a0404e9-b7ba5ae000000969-f4-4d83cfef10fe Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 80.76.02409.FEFC38D4; Fri, 18 Mar 2011 16:34:39 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Fri, 18 Mar 2011 16:34:39 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Sat, 19 Mar 2011 05:34:35 +0800 From: "Winterbottom, James" To: "Andrea G. Forte" , "Rosen, Brian" , Henning Schulzrinne Date: Sat, 19 Mar 2011 05:32:44 +0800 Thread-Topic: [Ecrit] LoST and multiple responses -phone-bcp Thread-Index: Acvlr6Gn1sf9ExO5RZmaIjnjCee7XgABGNHK Message-ID: <5A55A45AE77F5941B18E5457ECAC818801210020D6AA@SISPE7MB1.commscope.com> References: <94E28E6F-D1A9-4354-B0BC-0C668C93F69E@neustar.biz>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "Thomson, Martin" , "ecrit@ietf.org" Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 21:33:12 -0000 I think that it is also important to note, that PSAP to which the call was = directed will likely only have access to exactly the same information that = the original routing decision was made on. Consequently if it was the wrong= PSAP that was picked, and only one result can be returned from LoST, how w= ithout something very manual can this problem be rectified? Cheers James ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Andrea G= . Forte [forte@att.com] Sent: Friday, March 18, 2011 4:00 PM To: Rosen, Brian; Henning Schulzrinne Cc: Thomson, Martin; ecrit@ietf.org Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp If the LoST server decides wrong and routes my call to the wrong PSAP, the 9-1-1 operator will have to "discover" that a wrong routing has taken place, will have to find the correct PSAP and will have to transfer the call to the correct PSAP. All of this while I am on the call. As a user I would rather "select" one of the returned multiple mappings when making the call in the first place. -Andrea On 3/18/11 4:38 PM, "Rosen, Brian" wrote: >I'm familiar with this. It's really a bad solution in my opinion, given >that the cellid comes in the SMS messaging protocol and we already have >mapping from cell id to PSAP in current systems. > >You send a message to the short code. It replies with a request to text >your address (as a civic). It then forwards the text to the PSAP. > >Brian > >On Mar 18, 2011, at 4:29 PM, Henning Schulzrinne wrote: > >> See >> >>http://www.policechiefmagazine.org/magazine/index.cfm?fuseaction=3Ddispla= y_ >>arch&article_id=3D2069&issue_id=3D42010 >> for a similar solution: The caller is asked to input a zip code or city >>name. >> >> On Mar 18, 2011, at 2:17 PM, Rosen, Brian wrote: >> >>> Today, these are decided by cell tower. Calls from a given sector >>>route to a specific PSAP. >>> Generally, asking for user input during a call is frowned upon. >>> >>> Brian >> > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From hgs@cs.columbia.edu Fri Mar 18 14:41:34 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5A33A6A2E for ; Fri, 18 Mar 2011 14:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tFIBK7otmno for ; Fri, 18 Mar 2011 14:41:33 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 1C27B3A6A28 for ; Fri, 18 Mar 2011 14:41:33 -0700 (PDT) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p2ILh1JJ004446 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 18 Mar 2011 17:43:01 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: Date: Fri, 18 Mar 2011 17:43:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4A3F6073-CFE6-4B28-9FC3-5F5E7C26F11E@cs.columbia.edu> References: To: "Andrea G. Forte" X-Mailer: Apple Mail (2.1082) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: "Thomson, Martin" , "ecrit@ietf.org" , "Rosen, Brian" Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 21:41:34 -0000 According to some local politicians that have watched too many Ayn Rand = movies, government services should be privatized. Thus, we'll soon get a = choice between McPolice and PoliceKing when dialing 9-1-1, both returned = by LoST. (Obviously, you will only be connected to the dispatcher after = leaving your credit card number at the prompt.) Henning (not completely serious) More seriously, there seem to be three options: (1) always prevent RFC 5222 from returning more than one answer, = regardless of service (emergency or otherwise) (2) one answer only, but only for sos (3) leave such restriction to the local jurisdiction, depending on the = state of mountain rescue competition and other factors There seems to be no reason for option (1), but I wonder if there's a = great advantage for (2) over (3)? (I can see the user interface = interface - if you know, that you don't need to choose, you don't have = to build in that functionality.) Henning On Mar 18, 2011, at 12:22 PM, Andrea G. Forte wrote: > So, are we saying that for emergency services only, the LoST server = will > pick and return one result all the time? If so, how do we account for = a > wrong decision on the LoST server part? Are we just leaving that to = "human > intervention"?=20 > There should be at least a level of confidence on the location of the = user > falling within some PSAP boundaries. >=20 > Again, I am assuming this would apply to emergency services only. >=20 > -Andrea >=20 >=20 > On 3/18/11 12:48 AM, "Thomson, Martin" > wrote: >=20 >> On 2011-03-18 at 15:39:17, Winterbottom, James wrote: >>> Hey Martin, >>>=20 >>> Just so I am clear on what you are saying. >>> You could include just a basic sos service URN in the request to the >>> LoST server, but if you were in a jurisdiction that didn't have a >>> single service control point, but required separate service >>> distinction for police, fire or ambulance, then you could get back 3 >>> service mapping response. But it is bad form to allow three service >>> mappings all for police. Is that what you are saying? >>=20 >> Right. >>=20 >> Given one location and one service, then you should get one mapping. >>=20 >> If you could ask for police, fire and ambulance all at once, then I'd >> expect a mapping for each (even if all were the same mapping). But I >> don't think you can't do that. >>=20 >> --Martin >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From forte@att.com Fri Mar 18 15:02:13 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C889F3A6A76 for ; Fri, 18 Mar 2011 15:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.25 X-Spam-Level: X-Spam-Status: No, score=-106.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ne6xeSTbasVM for ; Fri, 18 Mar 2011 15:02:12 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 279153A6A33 for ; Fri, 18 Mar 2011 15:02:12 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: forte@att.com X-Msg-Ref: server-10.tower-119.messagelabs.com!1300485821!9704899!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 21283 invoked from network); 18 Mar 2011 22:03:41 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-10.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Mar 2011 22:03:41 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p2IM44J9032191; Fri, 18 Mar 2011 18:04:05 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p2IM3x03032056; Fri, 18 Mar 2011 18:03:59 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p2IM3Xb8028752; Fri, 18 Mar 2011 18:03:34 -0400 Received: from [151.109.8.240] (ds151-109-8-240.dhcps.ugn.att.com [151.109.8.240]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id p2IM3Ubr028679; Fri, 18 Mar 2011 18:03:32 -0400 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Fri, 18 Mar 2011 18:03:30 -0400 From: "Andrea G. Forte" To: "Thomson, Martin" Message-ID: Thread-Topic: [RAI] Review of draft-forte-lost-extensions-02 In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0400BEFF6D@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [RAI] Review of draft-forte-lost-extensions-02 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 22:02:13 -0000 Martin, Again thank you for the comments. A few more inline. -Andrea On 3/18/11 12:59 AM, "Thomson, Martin" wrote: >> What this draft proposes for "within X" relies on some sort of >> implicit >> processing that is inconsistent with RFC5222. It relies on the >>fact >> that >> the LoST server knows that a particular service is somehow special. >> >> >> [AGF] >> Currently the "within X" query is the default query so that unless you >> specify the element to be true it will treat it as "within X" >> query. >> The LoST server does not need >> to have some implicit knowledge. >> I think it is a good idea though to assume that when the >> element is missing, it is assumed to be true rather than false. This >> will make the default query a "served by" query thus making the >> behavior consistent with RFC 5222 for emergency services (which use a >> "served by" >> query). > >That's where we'll have to disagree. There is an implicit assumption >here that a location with uncertainty (the circle that you attempt to >use) does not get a choice between the two implicit (existing) behaviours: > > 1 - Pick the best match for my location > 2 - Show me all possible matches for my location > >And the new option (subtle difference) > > 3 - Show me all possible matches for this area > >I can live with 2 and 3 being collapsed, but the protocol semantics need >to be clear about this, or we end up in a mess. > >I think that the document makes a reasonable case for 2, but I'd like to >keep 1 for emergency services and keep the two distinct. > >My previous comments about recursive resolution still apply. An in-band >indication is even more necessary when recursion occurs. [AGF] For case 1, that would be a "served by" query ( equal to true or missing) with a of 1. As I mentioned before, since LoST by default may return any number of , you must explicitly tell it to return just one, the best. In case of PSAPs, however, since we only have one PSAP per service area, the LoST server will return always one PSAP except for overlapping areas, in which case it MAY return multiple PSAPs. This is consistent with a "served by" query with no tag specified. I guess this last point is what you want to address in phone-bcp. I leave further comments on this for the new thread in the mailing list. I just want to point out that the draft is consistent with the protocol semantics defined in RFC 5222. > >> >> >> The location profile can be used to identify which location you >>want >> to >> use if the content of the element is not sufficient. >> >> [AGF] >> I am not sure what you mean by this. > >This is related to the above problem. > >> The reason given for these recommendations: >> >> [...] as the computation of the distance, route and other metrics >> would at some point require geocoding of the civic address in >> geodetic coordinates. Because of this, the position specified in >> SHOULD be represented by using the >> element. >> >> ... is not necessary for interoperability. This seems more for the >> convenience of LoST server implementations. Wouldn't these >>reasons >> be >> better suited to a LoST server provisioning guide? >> >> A better reason might be that a recipient of the mapping >>information >> might need to use this information without the necessary context to >> understand the civic address. However, the same reason doesn't >> support >> the recommendation for using a . >> >> [AGF] >> There might be situations where the client would want to perform some >> light computations on location information but without having enough >> "power" to do geo encoding/decoding. > >How does that support the use of Point over other types? I assume that a >client just uses the location that it has. That only requires whatever >computations the client has to do in order to get the location (GPS, >HELD, DHCP, whatever). [AGF] Maybe I was not clear enough earlier. Here I am talking about the point of service location, not the location of the client. We are talking about the tag. > >> Iterative Responses >> The use of iterative resolution in LoST is a weak point that the >> ability >> to provide multiple mappings does not help. In the case where a >> server >> is able to provide only some answers, there is no facility for the >> server >> to indicate where the remainder of the answers are found (that is, >> the >> referral). >> >> [AGF] >> I am not sure I follow. The authoritative server for that region and >> for that class of service will reply with the results. Iteration >> continues only until an authoritative server is found. > >It's not possible, with a location shape that overlaps with the serving >areas of multiple LoST servers to have the first LoST server provide some >mappings and some referrals. [AGF] I do not understand why we cannot just use what is already defined in RFC 5582. In RFC 5582, Section 7.3 we read: "[...] The solution for overlapping coverage regions is relatively simple. If a query matches multiple coverage regions, the node returns all URLs or server names, in redirection mode, or queries both children, if in recursive mode. If the overlapping coverage is caused by imprecise coverage maps, only one will return a result and the others will return an error indication. If the particular location is disputed territory, the response will contain all answers, leaving it to the querier to choose the preferred solution or try to contact all services in turn." > >> Security >> The security section could use some expansion. It's not >>sufficient >> to >> just refer to RFC5222. >> >> The denial of service concerns that Shida raised in his review are >> worth >> discussing. A LoST server is discovered using the same means >> whether it >> be for emergency or commercial uses. The possibility that >> commercial >> uses could interfere with public safety is a significant concern. >> As >> Shida notes, scaling is probably trivial to address, but that's >>not >> the >> whole story. >> >> [AGF] >> I am very skeptical about this. >> >> From a regulatory perspective: the NG911 infrastructure is mostly paid >> and maintained by collecting 911 fees that tax payers have to pay. I >> do not think LoST servers paid with tax payers money for >> 911 can be used for supporting non-911 services. >> >> From a security perspective: in the most general case, let's assume >> we have two different LoST servers, one used by the NG911 client to >> discover the correct ESRP and one used by the ESRP to discover the >> correct PSAP. The second LoST server would be inside the ESInet thus >> behind a firewall. Access to this LoST server would be granted only to >> known ESRPs via access control lists (this is how many vendors have it >> implemented) or similar. The first LoST server will be more reachable >> than the second one as it does not have to be necessarily in the >> ESInet. This, however, can be configured to only support >> urn:service:sos as type of service and will be an authoritative server >> for this type of service only (given the regulatory issues mentioned >> above and security concerns). >> At this point, the same security considerations as in RFC5222 apply. > >This isn't a regulatory issue or anything related to a particular >deployment. It's a problem that you discover a LoST server in the same >way regardless of whether your service URI is "urn:service:sos" or >"http://www.pizza-restaurant.example/" Unless you change the way that a >value-add LoST is discovered, the same server is contacted. Therefore, >the same server needs to handle ESRP requests and coffee shop requests. [AGF] I see your point. However, aside from scalability issues, right now I cannot think of any other additional issues we would have in this case when compared to the emergency-only case. I will do more thinking on this but if you have a clear example please send it along. I have not gone through the lost discovery RFCs yet. Is there anything that prevents from provisioning the client with more than one LoST server? Not that I am saying that this should be the way to go. > >--Martin > From ted.ietf@gmail.com Fri Mar 18 20:39:57 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D67D43A69B5 for ; Fri, 18 Mar 2011 20:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzluKXH6nsyP for ; Fri, 18 Mar 2011 20:39:56 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 9FBE43A6975 for ; Fri, 18 Mar 2011 20:39:56 -0700 (PDT) Received: by qyk29 with SMTP id 29so1145095qyk.10 for ; Fri, 18 Mar 2011 20:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qdSv04ns4IXJf1tFj+s6tmamwXjrQvDA9tXQds2q8Ao=; b=hat2ulhtXCY/gcDNnGGusgicHerQvTSB7HtzQqqVmdiIRkNuNDn3vWRiq27on4HEzZ fBWEre6xcrPZnEhtmhTG5r6n5BBZXddQnQZXVONg/u3BMbhBY7+EL9R9yLx97dPIy8Gs i4Gc6MD5X+nD7ftm/9dSgJ0doDvxF0xa3GDns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eAoXAOzm2xYXLOE+s7IxTfgIBAA69oA4whazXJQ2E/QE6wwFCTwPoWU5ZNKRhdWwnb 8sdNXGjVO2K3ajds6qGDJ4BAcnQFWXmTi9izlw4JO/LNKdwGLp1xdFtN7K87j8ZV9tsM Gyz7oSPQZjcgraLLxrnNYDEkuJIOEWB38vzPw= MIME-Version: 1.0 Received: by 10.229.62.198 with SMTP id y6mr1501011qch.290.1300506086372; Fri, 18 Mar 2011 20:41:26 -0700 (PDT) Received: by 10.229.11.74 with HTTP; Fri, 18 Mar 2011 20:41:26 -0700 (PDT) In-Reply-To: <4A3F6073-CFE6-4B28-9FC3-5F5E7C26F11E@cs.columbia.edu> References: <4A3F6073-CFE6-4B28-9FC3-5F5E7C26F11E@cs.columbia.edu> Date: Fri, 18 Mar 2011 20:41:26 -0700 Message-ID: From: Ted Hardie To: Henning Schulzrinne Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Rosen, Brian" , "Thomson, Martin" , "ecrit@ietf.org" Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2011 03:39:58 -0000 On Fri, Mar 18, 2011 at 2:43 PM, Henning Schulzrinne wrote: > According to some local politicians that have watched too many Ayn Rand m= ovies, government services should be privatized. Thus, we'll soon get a cho= ice between McPolice and PoliceKing when dialing 9-1-1, both returned by Lo= ST. (Obviously, you will only be connected to the dispatcher after leaving = your credit card number at the prompt.) > > Henning > (not completely serious) This can happen, pretty easily, in situations on the border of emergency--like calling for ambulance service to transport someone between hospitals or to a hospital in a non-emergency situation. I suspect that it will only get easier in countries with private health care. > > More seriously, there seem to be three options: > > (1) always prevent RFC 5222 from returning more than one answer, regardle= ss of service (emergency or otherwise) > (2) one answer only, but only for sos > (3) leave such restriction to the local jurisdiction, depending on the st= ate of mountain rescue competition and other factors > I personally think that the protocol answer is 3 and that the jurisdictional answer should be "force it to be a single answer to avoid choice in panic situations". But if we make that policy decision in the protocol, we're only likely to get in trouble--especially if it is a special case in RFC 5222. Just my two cents, Ted > There seems to be no reason for option (1), but I wonder if there's a gre= at advantage for (2) over (3)? (I can see the user interface interface - if= you know, that you don't need to choose, you don't have to build in that f= unctionality.) > > Henning > > > On Mar 18, 2011, at 12:22 PM, Andrea G. Forte wrote: > >> So, are we saying that for emergency services only, the LoST server will >> pick and return one result all the time? If so, how do we account for a >> wrong decision on the LoST server part? Are we just leaving that to "hum= an >> intervention"? >> There should be at least a level of confidence on the location of the us= er >> falling within some PSAP boundaries. >> >> Again, I am assuming this would apply to emergency services only. >> >> -Andrea >> >> >> On 3/18/11 12:48 AM, "Thomson, Martin" >> wrote: >> >>> On 2011-03-18 at 15:39:17, Winterbottom, James wrote: >>>> Hey Martin, >>>> >>>> Just so I am clear on what you are saying. >>>> You could include just a basic sos service URN in the request to the >>>> LoST server, but if you were in a jurisdiction that didn't have a >>>> single service control point, but required separate service >>>> distinction for police, fire or ambulance, then you could get back 3 >>>> service mapping response. But it is bad form to allow three service >>>> mappings all for police. Is that what you are saying? >>> >>> Right. >>> >>> Given one location and one service, then you should get one mapping. >>> >>> If you could ask for police, fire and ambulance all at once, then I'd >>> expect a mapping for each (even if all were the same mapping). =A0But I >>> don't think you can't do that. >>> >>> --Martin >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From James.Winterbottom@commscope.com Fri Mar 18 21:16:23 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EEC93A6969 for ; Fri, 18 Mar 2011 21:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgPuUJvWKmGQ for ; Fri, 18 Mar 2011 21:16:22 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id 655623A6975 for ; Fri, 18 Mar 2011 21:16:22 -0700 (PDT) X-AuditID: 0a0404e8-b7b25ae000007eb9-fb-4d842e7000a4 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 6E.AE.32441.07E248D4; Fri, 18 Mar 2011 23:17:52 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Fri, 18 Mar 2011 23:17:51 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Sat, 19 Mar 2011 12:17:49 +0800 From: "Winterbottom, James" To: Ted Hardie , Henning Schulzrinne Date: Sat, 19 Mar 2011 12:17:23 +0800 Thread-Topic: [Ecrit] LoST and multiple responses -phone-bcp Thread-Index: Acvl54s2XOkatBkoSbqt5IO0XHKuLwABQCx2 Message-ID: <5A55A45AE77F5941B18E5457ECAC818801210020D6AB@SISPE7MB1.commscope.com> References: <4A3F6073-CFE6-4B28-9FC3-5F5E7C26F11E@cs.columbia.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "Rosen, Brian" , "Thomson, Martin" , "ecrit@ietf.org" Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2011 04:16:23 -0000 Perhaps some guidance text in phonebcp would help people think about this a= bit then? Cheers James ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Ted Hard= ie [ted.ietf@gmail.com] Sent: Friday, March 18, 2011 10:41 PM To: Henning Schulzrinne Cc: Rosen, Brian; Thomson, Martin; ecrit@ietf.org Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp On Fri, Mar 18, 2011 at 2:43 PM, Henning Schulzrinne wrote: > According to some local politicians that have watched too many Ayn Rand m= ovies, government services should be privatized. Thus, we'll soon get a cho= ice between McPolice and PoliceKing when dialing 9-1-1, both returned by Lo= ST. (Obviously, you will only be connected to the dispatcher after leaving = your credit card number at the prompt.) > > Henning > (not completely serious) This can happen, pretty easily, in situations on the border of emergency--like calling for ambulance service to transport someone between hospitals or to a hospital in a non-emergency situation. I suspect that it will only get easier in countries with private health care. > > More seriously, there seem to be three options: > > (1) always prevent RFC 5222 from returning more than one answer, regardle= ss of service (emergency or otherwise) > (2) one answer only, but only for sos > (3) leave such restriction to the local jurisdiction, depending on the st= ate of mountain rescue competition and other factors > I personally think that the protocol answer is 3 and that the jurisdictional answer should be "force it to be a single answer to avoid choice in panic situations". But if we make that policy decision in the protocol, we're only likely to get in trouble--especially if it is a special case in RFC 5222. Just my two cents, Ted > There seems to be no reason for option (1), but I wonder if there's a gre= at advantage for (2) over (3)? (I can see the user interface interface - if= you know, that you don't need to choose, you don't have to build in that f= unctionality.) > > Henning > > > On Mar 18, 2011, at 12:22 PM, Andrea G. Forte wrote: > >> So, are we saying that for emergency services only, the LoST server will >> pick and return one result all the time? If so, how do we account for a >> wrong decision on the LoST server part? Are we just leaving that to "hum= an >> intervention"? >> There should be at least a level of confidence on the location of the us= er >> falling within some PSAP boundaries. >> >> Again, I am assuming this would apply to emergency services only. >> >> -Andrea >> >> >> On 3/18/11 12:48 AM, "Thomson, Martin" >> wrote: >> >>> On 2011-03-18 at 15:39:17, Winterbottom, James wrote: >>>> Hey Martin, >>>> >>>> Just so I am clear on what you are saying. >>>> You could include just a basic sos service URN in the request to the >>>> LoST server, but if you were in a jurisdiction that didn't have a >>>> single service control point, but required separate service >>>> distinction for police, fire or ambulance, then you could get back 3 >>>> service mapping response. But it is bad form to allow three service >>>> mappings all for police. Is that what you are saying? >>> >>> Right. >>> >>> Given one location and one service, then you should get one mapping. >>> >>> If you could ask for police, fire and ambulance all at once, then I'd >>> expect a mapping for each (even if all were the same mapping). But I >>> don't think you can't do that. >>> >>> --Martin >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From brian.rosen@neustar.biz Sat Mar 19 06:01:45 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1803D3A6AA6 for ; Sat, 19 Mar 2011 06:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1X0wiNs0s8Z for ; Sat, 19 Mar 2011 06:01:44 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by core3.amsl.com (Postfix) with ESMTP id 0013D3A68ED for ; Sat, 19 Mar 2011 06:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1300539785; x=1615877866; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=qIObqtEWp9Ju3nvbS/VXP PiutMQt3wrSww0j+XFdbO8=; b=nmRuy44BQr0fJJyQK5eEyfbbb/x5S4LDm14Cv InMAbXLSu/1oJB+Ccotg+T38035jrtwu8Z54Yzuz8aQTi3QVw== Received: from ([10.31.13.229]) by chihiron2.nc.neustar.com with ESMTP with TLS id 5202415.35778712; Sat, 19 Mar 2011 09:03:04 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Sat, 19 Mar 2011 09:03:04 -0400 From: "Rosen, Brian" To: Ted Hardie Date: Sat, 19 Mar 2011 09:03:02 -0400 Thread-Topic: [Ecrit] LoST and multiple responses -phone-bcp Thread-Index: AcvmNfs34e/cD8bARH+WVZz3l8t6GQ== Message-ID: References: <4A3F6073-CFE6-4B28-9FC3-5F5E7C26F11E@cs.columbia.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: Noj+QYZeJkIsCPWqjXYfQg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Thomson, Martin" , "ecrit@ietf.org" Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2011 13:01:45 -0000 >> More seriously, there seem to be three options: >>=20 >> (1) always prevent RFC 5222 from returning more than one answer, regardl= ess of service (emergency or otherwise) >> (2) one answer only, but only for sos >> (3) leave such restriction to the local jurisdiction, depending on the s= tate of mountain rescue competition and other factors >>=20 > I personally think that the protocol answer is 3 and that the > jurisdictional answer should be "force it to be a single answer to > avoid choice in panic situations". But if we make that policy > decision in the protocol, we're only likely to get in > trouble--especially if it is a special case in RFC 5222. >=20 That Works For Me= From Martin.Thomson@commscope.com Sun Mar 20 15:46:23 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035C228C0FD for ; Sun, 20 Mar 2011 15:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.062 X-Spam-Level: X-Spam-Status: No, score=-3.062 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibiLLr50h0Ml for ; Sun, 20 Mar 2011 15:46:22 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id ECCA728B23E for ; Sun, 20 Mar 2011 15:46:21 -0700 (PDT) X-AuditID: 0a0404e9-b7ba5ae000000969-1a-4d86841949e4 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 46.AC.02409.914868D4; Sun, 20 Mar 2011 17:47:53 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Sun, 20 Mar 2011 17:47:53 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 21 Mar 2011 06:47:50 +0800 From: "Thomson, Martin" To: "Rosen, Brian" , "Richard L. Barnes" Date: Mon, 21 Mar 2011 06:47:48 +0800 Thread-Topic: [Ecrit] LoST and multiple responses -phone-bcp Thread-Index: Acvlj9zo945ouoqLQsK9FcLc3FvKRABwNw8Q Message-ID: <8B0A9FCBB9832F43971E38010638454F0400BF00EC@SISPE7MB1.commscope.com> References: <98F624CC-F575-42F1-A747-D02F935FB724@neustar.biz> In-Reply-To: <98F624CC-F575-42F1-A747-D02F935FB724@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 22:46:23 -0000 On 2011-03-19 at 04:13:56, Rosen, Brian wrote: > In general, I think this case only occurs due to a provisioning error=20 > (overlap of service boundaries). If it does, the LoST server is=20 > probably better at figuring it out. Not so. I've been looking at the lost-extensions draft and that suggests a= different case: where the input location has uncertainty that overlaps dif= ferent boundaries. --Martin From Martin.Thomson@commscope.com Sun Mar 20 15:48:46 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 576C73A69C7 for ; Sun, 20 Mar 2011 15:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[AWL=-0.411, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TEDv3JIDB3o for ; Sun, 20 Mar 2011 15:48:45 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id 87D2028C105 for ; Sun, 20 Mar 2011 15:48:45 -0700 (PDT) X-AuditID: 0a0404e8-b7b25ae000007eb9-a7-4d8684a998b1 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 5A.F1.32441.9A4868D4; Sun, 20 Mar 2011 17:50:17 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Sun, 20 Mar 2011 17:50:17 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 21 Mar 2011 06:50:14 +0800 From: "Thomson, Martin" To: "Rosen, Brian" , "Richard L. Barnes" Date: Mon, 21 Mar 2011 06:50:13 +0800 Thread-Topic: [Ecrit] LoST and multiple responses -phone-bcp Thread-Index: AcvlmMf+OzWZemZHQsOSMgr8MbRjsgBuBWeg Message-ID: <8B0A9FCBB9832F43971E38010638454F0400BF00EF@SISPE7MB1.commscope.com> References: <98F624CC-F575-42F1-A747-D02F935FB724@neustar.biz> <1094E783-5D92-4DAE-8DEB-0B80146EAD27@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 22:48:46 -0000 On 2011-03-19 at 05:17:46, Rosen, Brian wrote: > Today, these are decided by cell tower. Calls from a given sector=20 > route to a specific PSAP. While I appreciate all the reasons for this decision, that's a practice tha= t I'd like to see ended. There are better criterion than serving cell. > Generally, asking for user input during a call is frowned upon. I agree. Particularly if the question is exceptional. If 90% of calls don= 't need human input, it's even worse when the exception occurs. (Not that = many people regularly make emergency calls.) From john.medland@bt.com Sun Mar 20 16:57:39 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 198BE3A6C06 for ; Sun, 20 Mar 2011 16:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBw08qcvzrRx for ; Sun, 20 Mar 2011 16:57:38 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by core3.amsl.com (Postfix) with ESMTP id 138B53A69CD for ; Sun, 20 Mar 2011 16:57:37 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.106.1; Sun, 20 Mar 2011 23:59:09 +0000 Received: from emv66-ukrd.domain1.systemhost.net ([169.254.1.71]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Sun, 20 Mar 2011 23:59:09 +0000 From: To: , , Date: Sun, 20 Mar 2011 23:59:07 +0000 Thread-Topic: [Ecrit] LoST and multiple responses -phone-bcp Thread-Index: AcvlmMf+OzWZemZHQsOSMgr8MbRjsgBuBWegAAIC/gA= Message-ID: References: <98F624CC-F575-42F1-A747-D02F935FB724@neustar.biz> <1094E783-5D92-4DAE-8DEB-0B80146EAD27@bbn.com> <8B0A9FCBB9832F43971E38010638454F0400BF00EF@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0400BF00EF@SISPE7MB1.commscope.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 23:57:39 -0000 Hopefully I'm not missing the point as I've not followed the thread closely= , but responding on comments below, end-users making emergency calls are us= ually asked to verbally give or confirm their location by UK PSAPs as stand= ard procedure. =20 For fixed single line callers this should just be confirmation of address a= utomatically provided, but for multiline callers within enterprise/corporat= e networks or callers reporting incidents at another location, it could req= uire more than just confirmation. For mobile callers it will be to pinpoi= nt a location within the cell coverage areas automatically provided (and sa= dly no sign of more precise locations from our networks in near future). Regards John =20 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of T= homson, Martin Sent: 20 March 2011 22:50 To: Rosen, Brian; Richard L. Barnes Cc: ecrit@ietf.org Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp On 2011-03-19 at 05:17:46, Rosen, Brian wrote: > Today, these are decided by cell tower. Calls from a given sector=20 > route to a specific PSAP. While I appreciate all the reasons for this decision, that's a practice tha= t I'd like to see ended. There are better criterion than serving cell. > Generally, asking for user input during a call is frowned upon. I agree. Particularly if the question is exceptional. If 90% of calls don= 't need human input, it's even worse when the exception occurs. (Not that = many people regularly make emergency calls.) _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From Martin.Thomson@commscope.com Sun Mar 20 17:01:51 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF2D28C107 for ; Sun, 20 Mar 2011 17:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.969 X-Spam-Level: X-Spam-Status: No, score=-2.969 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnPUT0fIZ-Xn for ; Sun, 20 Mar 2011 17:01:50 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id 6402928C100 for ; Sun, 20 Mar 2011 17:01:50 -0700 (PDT) X-AuditID: 0a0404e8-b7b25ae000007eb9-7f-4d8695cae131 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 09.72.32441.AC5968D4; Sun, 20 Mar 2011 19:03:22 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Sun, 20 Mar 2011 19:03:21 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 21 Mar 2011 08:03:19 +0800 From: "Thomson, Martin" To: "john.medland@bt.com" , "Brian.Rosen@neustar.biz" , "rbarnes@bbn.com" Date: Mon, 21 Mar 2011 08:03:18 +0800 Thread-Topic: [Ecrit] LoST and multiple responses -phone-bcp Thread-Index: AcvlmMf+OzWZemZHQsOSMgr8MbRjsgBuBWegAAIC/gAAAIjpAA== Message-ID: <8B0A9FCBB9832F43971E38010638454F0400BF0100@SISPE7MB1.commscope.com> References: <98F624CC-F575-42F1-A747-D02F935FB724@neustar.biz> <1094E783-5D92-4DAE-8DEB-0B80146EAD27@bbn.com> <8B0A9FCBB9832F43971E38010638454F0400BF00EF@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] LoST and multiple responses -phone-bcp X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 00:01:51 -0000 On 2011-03-21 at 10:59:07, john.medland@bt.com wrote: > Hopefully I'm not missing the point as I've not followed the thread=20 > closely, but responding on comments below, end-users making emergency=20 > calls are usually asked to verbally give or confirm their location by=20 > UK PSAPs as standard procedure. >=20 > For fixed single line callers this should just be confirmation of=20 > address automatically provided, but for multiline callers within=20 > enterprise/corporate networks or callers reporting incidents at=20 > another location, it could require more than just confirmation. For =20 > mobile callers it will be to pinpoint a location within the cell=20 > coverage areas automatically provided (and sadly no sign of more=20 > precise locations from our networks in near future). >=20 > Regards >=20 > John Hi John, I think that Ted's suggestion is the one we're going with: let the jurisdic= tion decide. Those sorts of standard procedures are not the concern - though I'd like fo= r that sort of questioning to be made redundant, it's entirely a policy dec= ision for the jurisdiction. --Martin From trac+ecrit@trac.tools.ietf.org Sat Mar 19 17:55:41 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A81393A6A8D for ; Sat, 19 Mar 2011 17:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkaABVi3AK55 for ; Sat, 19 Mar 2011 17:55:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0B9B73A6A82 for ; Sat, 19 Mar 2011 17:55:41 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q16xD-0004O1-D9; Sat, 19 Mar 2011 17:57:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ecrit issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Sun, 20 Mar 2011 00:57:11 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/2#comment:1 Message-ID: <074.fe314dcd4545a455ef7c22f3f7d3e0be@trac.tools.ietf.org> References: <065.6a5cb9a88adb7aeeff739133ff1b2a3b@trac.tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <065.6a5cb9a88adb7aeeff739133ff1b2a3b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Mon, 21 Mar 2011 05:19:55 -0700 Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #2: Trustworthy Location, Identity and Accountability X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 00:55:41 -0000 #2: Trustworthy Location, Identity and Accountability Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: Bernard_Aboba@… | Owner: Type: defect | Status: closed Priority: blocker | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Sat Mar 19 17:59:28 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D513A6A94 for ; Sat, 19 Mar 2011 17:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6QlkPgeCO0l for ; Sat, 19 Mar 2011 17:59:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 84C383A69D2 for ; Sat, 19 Mar 2011 17:59:27 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q170t-0001oS-8O; Sat, 19 Mar 2011 18:00:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ecrit issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Sun, 20 Mar 2011 01:00:59 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/1#comment:1 Message-ID: <074.32e1bdb954543fcd4544b86c799634c1@trac.tools.ietf.org> References: <065.d0d0f1d0bb2875663c42cb464986f6a8@trac.tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <065.d0d0f1d0bb2875663c42cb464986f6a8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Mon, 21 Mar 2011 05:19:55 -0700 Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #1: Threat Analysis: Missing Context X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 00:59:28 -0000 #1: Threat Analysis: Missing Context Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: Bernard_Aboba@… | Owner: Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Sat Mar 19 18:13:16 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F8213A6AB6 for ; Sat, 19 Mar 2011 18:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCMSczkS8I8f for ; Sat, 19 Mar 2011 18:13:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id EC10C3A6AA4 for ; Sat, 19 Mar 2011 18:13:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q17EE-0002r2-MR; Sat, 19 Mar 2011 18:14:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ecrit issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Sun, 20 Mar 2011 01:14:46 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/ecrit/trac/ticket/3 Message-ID: <065.33bb6c2ac204e1ea89a3d76a7ac43756@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Mon, 21 Mar 2011 05:19:55 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] [ecrit] #3: Out-of-date References X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 01:13:16 -0000 #3: Out-of-date References A number of the references are out of date, including references to location hiding, location conveyance, location dependability, HELD deref, etc. Proposed resolution is to change Section 9.1 to the following: 9.1. Informative References [GPSCounter] Warner, J. S. and R. G. Johnston, "GPS Spoofing Countermeasures", Los Alamos research paper LAUR-03-6163, December 2003. [I-D.ietf-ecrit-location-hiding-req] Schulzrinne, H., Liess, L., Tschofenig, H., Stark, B., and A. Kuett, "Location Hiding: Problem Statement and Requirements", draft-ietf-ecrit-location-hiding-req-04 (work in progress), February 2010. [I-D.ietf-sipcore-location-conveyance] Polk, J. and B. Rosen, "Location Conveyance for the Session Initiation Protocol", draft-ietf-sipcore-location- conveyance-06.txt (work in progress), February 2011. [I-D.thomson-geopriv-location-dependability] Thomson, M. and J. Winterbottom, "Digital Signature Methods for Location Dependability", draft-thomson-geopriv-location- dependability-07 (work in progress), March 2011. [I-D.winterbottom-geopriv-deref-protocol] Winterbottom, J., Tschofenig, H., Schulzrinne, H., Thomson, M., and M. Dawson, "A Location Dereferencing Protocol Using HELD", draft-ietf-geopriv-deref-protocol-02 (work in progress), December 2010. [IEEE-802.11y] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 3: 3650-3700 MHz Operation in USA, November 2008. [LLDP-MED] "Telecommunications: IP Telephony Infrastructure: Link Layer Discovery Protocol for Media Endpoint Devices, ANSI/ TIA-1057-2006", April 2006. [NENA-i2] "08-001 NENA Interim VoIP Architecture for Enhanced 9-1-1 Services (i2)", December 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [RFC3694] Danley, M., Mulligan, D., Morris, J. and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC3825bis] Polk, J., Linsner, M., Thomson, M. and B. Aboba, "Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information", draft-ietf-geopriv- rfc3825bis-17.txt (work in progress), February 2011. [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005. [RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects for Bridges", RFC 4188, September 2005. [RFC4293] Routhier, S., "Management Information Base for the Internet Protocol (IP)", RFC 4293, April 2006. [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006. [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., Canales- Valenzuela, C., and K. Tammi, "Diameter Session Initiation Protocol (SIP) Application", RFC 4740, November 2006. [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008. [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H. and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008. [RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", RFC 5582, September 2009. [RFC5985] Barnes, M., "HTTP Enabled Location Delivery (HELD)", RFC 5985, September 2010. [SA] "Saudi Arabia - Illegal sale of SIMs blamed for surge in prank calls", Arab News, May 4, 2010, http://www.menafn.com/qn_news_story_s.asp?StoryId=1093319384 [Swatting] "Don't Make the Call: The New Phenomenon of 'Swatting', Federal Bureau of Investigation, February 4, 2008, http://www.fbi.gov/news/stories/2008/february/swatting020408 [TASMANIA] "Emergency services seek SIM-less calls block", ABC News Online, August 18, 2006, [UK] "Rapper makes thousands of prank 999 emergency calls to UK police", Digital Journal, June 24, 2010, http://www.digitaljournal.com/article/293796?tp=1 -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Sat Mar 19 18:45:26 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7316C3A6A0F for ; Sat, 19 Mar 2011 18:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyZVplklDLCS for ; Sat, 19 Mar 2011 18:45:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AD3773A69DE for ; Sat, 19 Mar 2011 18:45:25 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q17jN-0007P5-Bl; Sat, 19 Mar 2011 18:46:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ecrit issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Sun, 20 Mar 2011 01:46:57 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/ecrit/trac/ticket/4 Message-ID: <065.2714ac9a8b39105b6514f2472e116155@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false X-Mailman-Approved-At: Mon, 21 Mar 2011 05:19:55 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] [ecrit] #4: Untrusted location and provider intent X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 01:45:26 -0000 #4: Untrusted location and provider intent A location cannot be considered trusted for emergency services use if the location provider doesn't warrant its use for that purpose. The document currently does not discuss this point, but it seems like a quite important issue. For example, "location based services" which might provide location via a platform or Javascript API will not necessarily meet the reliability or accuracy requirements for emergency location. In fact, the terms of service might explicitly disclaim the fitness for such uses. Yet existing location APIs typically do not make a distinction between location providers who consider their location data unfit for use in an emergency, and an enterprise or carrier LIS that might be deployed specifically for the purpose of providing location for use in an emergency. Thus while it might be possible to construst a PIDF-LO by calling such an API, the validity of conveying such a PIDF-LO to the PSAP might be suspect. If an application can determine that a location is not warranted for use in an emergency, a number of workarounds might be possible. For example, the location might not be automatically conveyed without confirmation, or might be flagged as potentially suspect, or the uncertainty might be set to a very high value. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: blocker | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: ecrit From br@brianrosen.net Mon Mar 21 06:01:00 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25DEB28C132 for ; Mon, 21 Mar 2011 06:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FGuaWTBI9bb for ; Mon, 21 Mar 2011 06:00:59 -0700 (PDT) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by core3.amsl.com (Postfix) with ESMTP id 3C4313A6846 for ; Mon, 21 Mar 2011 06:00:59 -0700 (PDT) X-ASG-Debug-ID: 1300712551-011a9f1d2346e10001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id GSAMg3f5ACYNixsR; Mon, 21 Mar 2011 06:02:31 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=aleo-lt500.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Q1ekf-0005Oi-5R; Mon, 21 Mar 2011 06:02:30 -0700 Mime-Version: 1.0 (Apple Message framework v1082) X-ASG-Orig-Subj: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent Content-Type: text/plain; charset=windows-1252 From: Brian Rosen In-Reply-To: <065.2714ac9a8b39105b6514f2472e116155@trac.tools.ietf.org> Date: Mon, 21 Mar 2011 09:02:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <33EF0B53-763B-4FE8-8CAE-3F5809D5D95B@brianrosen.net> References: <065.2714ac9a8b39105b6514f2472e116155@trac.tools.ietf.org> To: ecrit@ietf.org X-Mailer: Apple Mail (2.1082) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1300712551 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.58542 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 13:01:00 -0000 The general rule I have for this is "send it, but let us know what you = know about it". No entity should withhold location information unless it is certain that = the information it is withholding is fraudulent. While the PSAP doesn't like having to decide what to do, it's better = that it has the information and knows that some of it MAY be suspect. Let me cite an example: a telematics equipped car with an accurate GPS, = large antenna, always on, can provide far superior location than the = cell phone through which an emergency call is placed. We want the GPS = from the car. What we get is what the network thinks. It's okay that the network use its location to route. The PSAP would = prefer that it used the telematics location, but it's acceptable to use = the network location. It's certainly acceptable to send the network = location. However, we also want the telematics location. Of course, we want whatever location to be accurately labeled (source, = method, uncertainty). Brian On Mar 19, 2011, at 9:46 PM, ecrit issue tracker wrote: > #4: Untrusted location and provider intent >=20 > A location cannot be considered trusted for emergency services use if = the > location provider doesn't warrant its use for that purpose. The = document > currently does not discuss this point, but it seems like a quite = important > issue. >=20 > For example, "location based services" which might provide location = via a > platform or Javascript API will not necessarily meet the reliability = or > accuracy requirements for emergency location. In fact, the terms of > service might explicitly disclaim the fitness for such uses. >=20 > Yet existing location APIs typically do not make a distinction between > location providers who consider their location data unfit for use in = an > emergency, and an enterprise or carrier LIS that might be deployed > specifically for the purpose of providing location for use in an > emergency. Thus while it might be possible to construst a PIDF-LO by > calling such an API, the validity of conveying such a PIDF-LO to the = PSAP > might be suspect. >=20 > If an application can determine that a location is not warranted for = use > in an emergency, a number of workarounds might be possible. For = example, > the location might not be automatically conveyed without confirmation, = or > might be flagged as potentially suspect, or the uncertainty might be = set > to a very high value. >=20 > --=20 > = ---------------------------------------+----------------------------------= -- > Reporter: bernard_aboba@=85 | Owner: =20 > Type: defect | Status: new =20 > Priority: blocker | Milestone: milestone1 > Component: trustworthy-location | Version: 1.0 =20 > Severity: Active WG Document | Keywords: =20 > = ---------------------------------------+----------------------------------= -- >=20 > Ticket URL: > ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From bernard_aboba@hotmail.com Mon Mar 21 16:48:08 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A62C53A690B for ; Mon, 21 Mar 2011 16:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7Iv6JqM3bz2 for ; Mon, 21 Mar 2011 16:48:01 -0700 (PDT) Received: from blu0-omc2-s26.blu0.hotmail.com (blu0-omc2-s26.blu0.hotmail.com [65.55.111.101]) by core3.amsl.com (Postfix) with ESMTP id 46BE93A6909 for ; Mon, 21 Mar 2011 16:48:01 -0700 (PDT) Received: from BLU152-W57 ([65.55.111.71]) by blu0-omc2-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Mar 2011 16:49:33 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_634de290-9d9c-4548-ba31-f4994848700b_" X-Originating-IP: [72.11.66.126] From: Bernard Aboba To: , Date: Mon, 21 Mar 2011 16:49:32 -0700 Importance: Normal In-Reply-To: <33EF0B53-763B-4FE8-8CAE-3F5809D5D95B@brianrosen.net> References: <065.2714ac9a8b39105b6514f2472e116155@trac.tools.ietf.org>, <33EF0B53-763B-4FE8-8CAE-3F5809D5D95B@brianrosen.net> MIME-Version: 1.0 X-OriginalArrivalTime: 21 Mar 2011 23:49:33.0659 (UTC) FILETIME=[A0ECB2B0:01CBE822] Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 23:48:08 -0000 --_634de290-9d9c-4548-ba31-f4994848700b_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This seems reasonable. Any recommendations on how we might ensure that loc= ation would be accurately labeled in situations where it originates from a = "location based service" that might be designed for use within the ECRIT ar= chitecture? Also=2C any thoughts on the circumstances in which user confirm= ation might make sense?=20 I am reminded of an experience at the IETF meeting in Stockholm where one o= f the "location based services" which shall remain nameless identified the = IETF meeting as being located in San Francisco because the IETF access poin= ts were scanned during the previous IETF meeting. If you were looking for= a pizza restaurant that might be humorous=2C but maybe not so much if you = were using the location for routing to the PSAP. =20 > Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent > From: br@brianrosen.net > Date: Mon=2C 21 Mar 2011 09:02:24 -0400 > CC: bernard_aboba@hotmail.com > To: ecrit@ietf.org >=20 > The general rule I have for this is "send it=2C but let us know what you = know about it". > No entity should withhold location information unless it is certain that = the information it is withholding is fraudulent. > While the PSAP doesn't like having to decide what to do=2C it's better th= at it has the information and knows that some of it MAY be suspect. >=20 > Let me cite an example: a telematics equipped car with an accurate GPS=2C= large antenna=2C always on=2C can provide far superior location than the c= ell phone through which an emergency call is placed. We want the GPS from = the car. What we get is what the network thinks. >=20 > It's okay that the network use its location to route. The PSAP would pre= fer that it used the telematics location=2C but it's acceptable to use the = network location. It's certainly acceptable to send the network location. = However=2C we also want the telematics location. >=20 > Of course=2C we want whatever location to be accurately labeled (source= =2C method=2C uncertainty). >=20 > Brian >=20 > On Mar 19=2C 2011=2C at 9:46 PM=2C ecrit issue tracker wrote: >=20 > > #4: Untrusted location and provider intent > >=20 > > A location cannot be considered trusted for emergency services use if t= he > > location provider doesn't warrant its use for that purpose. The docume= nt > > currently does not discuss this point=2C but it seems like a quite impo= rtant > > issue. > >=20 > > For example=2C "location based services" which might provide location v= ia a > > platform or Javascript API will not necessarily meet the reliability or > > accuracy requirements for emergency location. In fact=2C the terms of > > service might explicitly disclaim the fitness for such uses. > >=20 > > Yet existing location APIs typically do not make a distinction between > > location providers who consider their location data unfit for use in an > > emergency=2C and an enterprise or carrier LIS that might be deployed > > specifically for the purpose of providing location for use in an > > emergency. Thus while it might be possible to construst a PIDF-LO by > > calling such an API=2C the validity of conveying such a PIDF-LO to the = PSAP > > might be suspect. > >=20 > > If an application can determine that a location is not warranted for us= e > > in an emergency=2C a number of workarounds might be possible. For exam= ple=2C > > the location might not be automatically conveyed without confirmation= =2C or > > might be flagged as potentially suspect=2C or the uncertainty might be = set > > to a very high value. > >=20 > > --=20 > > ---------------------------------------+-------------------------------= ----- > > Reporter: bernard_aboba@=85 | Owner: =20 > > Type: defect | Status: new =20 > > Priority: blocker | Milestone: milestone1 > > Component: trustworthy-location | Version: 1.0 =20 > > Severity: Active WG Document | Keywords: =20 > > ---------------------------------------+-------------------------------= ----- > >=20 > > Ticket URL: > > ecrit > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 = --_634de290-9d9c-4548-ba31-f4994848700b_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This seems reasonable. =3B Any recommendations on how we might ensure t= hat location would be accurately labeled in situations where it originates = from a "location based service" that might be designed for use within the E= CRIT architecture? Also=2C any thoughts on the circumstances in which user = confirmation might make sense?

I am reminded of an experience at th= e IETF meeting in Stockholm where one of the "location based services" whic= h shall remain nameless identified the IETF meeting as being located in San= Francisco because the IETF access points were scanned during the previous = IETF meeting. =3B =3B If you were looking for a pizza restaurant th= at might be humorous=2C but maybe not so much if you were using the locatio= n for routing to the PSAP. =3B

>=3B Subject: Re: [Ecrit] [ecr= it] #4: Untrusted location and provider intent
>=3B From: br@brianrose= n.net
>=3B Date: Mon=2C 21 Mar 2011 09:02:24 -0400
>=3B CC: berna= rd_aboba@hotmail.com
>=3B To: ecrit@ietf.org
>=3B
>=3B The = general rule I have for this is "send it=2C but let us know what you know a= bout it".
>=3B No entity should withhold location information unless i= t is certain that the information it is withholding is fraudulent.
>= =3B While the PSAP doesn't like having to decide what to do=2C it's better = that it has the information and knows that some of it MAY be suspect.
&g= t=3B
>=3B Let me cite an example: a telematics equipped car with an a= ccurate GPS=2C large antenna=2C always on=2C can provide far superior locat= ion than the cell phone through which an emergency call is placed. We want= the GPS from the car. What we get is what the network thinks.
>=3B <= br>>=3B It's okay that the network use its location to route. The PSAP w= ould prefer that it used the telematics location=2C but it's acceptable to = use the network location. It's certainly acceptable to send the network lo= cation. However=2C we also want the telematics location.
>=3B
>= =3B Of course=2C we want whatever location to be accurately labeled (source= =2C method=2C uncertainty).
>=3B
>=3B Brian
>=3B
>=3B= On Mar 19=2C 2011=2C at 9:46 PM=2C ecrit issue tracker wrote:
>=3B >=3B >=3B #4: Untrusted location and provider intent
>=3B >=3B=
>=3B >=3B A location cannot be considered trusted for emergency se= rvices use if the
>=3B >=3B location provider doesn't warrant its us= e for that purpose. The document
>=3B >=3B currently does not discu= ss this point=2C but it seems like a quite important
>=3B >=3B issue= .
>=3B >=3B
>=3B >=3B For example=2C "location based service= s" which might provide location via a
>=3B >=3B platform or Javascri= pt API will not necessarily meet the reliability or
>=3B >=3B accura= cy requirements for emergency location. In fact=2C the terms of
>=3B = >=3B service might explicitly disclaim the fitness for such uses.
>= =3B >=3B
>=3B >=3B Yet existing location APIs typically do not ma= ke a distinction between
>=3B >=3B location providers who consider t= heir location data unfit for use in an
>=3B >=3B emergency=2C and an= enterprise or carrier LIS that might be deployed
>=3B >=3B specific= ally for the purpose of providing location for use in an
>=3B >=3B e= mergency. Thus while it might be possible to construst a PIDF-LO by
>= =3B >=3B calling such an API=2C the validity of conveying such a PIDF-LO = to the PSAP
>=3B >=3B might be suspect.
>=3B >=3B
>=3B = >=3B If an application can determine that a location is not warranted for= use
>=3B >=3B in an emergency=2C a number of workarounds might be p= ossible. For example=2C
>=3B >=3B the location might not be automat= ically conveyed without confirmation=2C or
>=3B >=3B might be flagge= d as potentially suspect=2C or the uncertainty might be set
>=3B >= =3B to a very high value.
>=3B >=3B
>=3B >=3B --
>=3B = >=3B ---------------------------------------+----------------------------= --------
>=3B >=3B Reporter: bernard_aboba@=85 | O= wner:
>=3B >=3B Type: defect | = Status: new
>=3B >=3B Priority: blocker = | Milestone: milestone1
>=3B >=3B Component: trustworthy-lo= cation | Version: 1.0
>=3B >=3B Severity: Active = WG Document | Keywords:
>=3B >=3B -----------= ----------------------------+------------------------------------
>=3B= >=3B
>=3B >=3B Ticket URL: <=3Bhttp://wiki.tools.ietf.org/wg/e= crit/trac/ticket/4>=3B
>=3B >=3B ecrit <=3Bhttp://tools.ietf.org= /ecrit/>=3B
>=3B >=3B
>=3B >=3B __________________________= _____________________
>=3B >=3B Ecrit mailing list
>=3B >=3B = Ecrit@ietf.org
>=3B >=3B https://www.ietf.org/mailman/listinfo/ecrit=
>=3B
= --_634de290-9d9c-4548-ba31-f4994848700b_-- From bernard_aboba@hotmail.com Mon Mar 21 16:51:25 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C68D428C1B7 for ; Mon, 21 Mar 2011 16:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6qg6XBsix0X for ; Mon, 21 Mar 2011 16:51:18 -0700 (PDT) Received: from blu0-omc2-s18.blu0.hotmail.com (blu0-omc2-s18.blu0.hotmail.com [65.55.111.93]) by core3.amsl.com (Postfix) with ESMTP id 54E7C28C175 for ; Mon, 21 Mar 2011 16:51:18 -0700 (PDT) Received: from BLU152-W28 ([65.55.111.73]) by blu0-omc2-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Mar 2011 16:52:50 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_935d2c72-01f6-4ffb-8a52-fcc3161d8604_" X-Originating-IP: [72.11.66.126] From: Bernard Aboba To: , Date: Mon, 21 Mar 2011 16:52:49 -0700 Importance: Normal In-Reply-To: References: <065.2714ac9a8b39105b6514f2472e116155@trac.tools.ietf.org>, , <33EF0B53-763B-4FE8-8CAE-3F5809D5D95B@brianrosen.net>, MIME-Version: 1.0 X-OriginalArrivalTime: 21 Mar 2011 23:52:50.0806 (UTC) FILETIME=[166EF160:01CBE823] Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 23:51:25 -0000 --_935d2c72-01f6-4ffb-8a52-fcc3161d8604_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sorry=2C I meant "not designed for use within the ECRIT architecture".=20 From: bernard_aboba@hotmail.com To: br@brianrosen.net=3B ecrit@ietf.org Date: Mon=2C 21 Mar 2011 16:49:32 -0700 Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent This seems reasonable. Any recommendations on how we might ensure that loc= ation would be accurately labeled in situations where it originates from a = "location based service" that might be designed for use within the ECRIT ar= chitecture? Also=2C any thoughts on the circumstances in which user confirm= ation might make sense?=20 I am reminded of an experience at the IETF meeting in Stockholm where one o= f the "location based services" which shall remain nameless identified the = IETF meeting as being located in San Francisco because the IETF access poin= ts were scanned during the previous IETF meeting. If you were looking for= a pizza restaurant that might be humorous=2C but maybe not so much if you = were using the location for routing to the PSAP. =20 > Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent > From: br@brianrosen.net > Date: Mon=2C 21 Mar 2011 09:02:24 -0400 > CC: bernard_aboba@hotmail.com > To: ecrit@ietf.org >=20 > The general rule I have for this is "send it=2C but let us know what you = know about it". > No entity should withhold location information unless it is certain that = the information it is withholding is fraudulent. > While the PSAP doesn't like having to decide what to do=2C it's better th= at it has the information and knows that some of it MAY be suspect. >=20 > Let me cite an example: a telematics equipped car with an accurate GPS=2C= large antenna=2C always on=2C can provide far superior location than the c= ell phone through which an emergency call is placed. We want the GPS from = the car. What we get is what the network thinks. >=20 > It's okay that the network use its location to route. The PSAP would pre= fer that it used the telematics location=2C but it's acceptable to use the = network location. It's certainly acceptable to send the network location. = However=2C we also want the telematics location. >=20 > Of course=2C we want whatever location to be accurately labeled (source= =2C method=2C uncertainty). >=20 > Brian >=20 > On Mar 19=2C 2011=2C at 9:46 PM=2C ecrit issue tracker wrote: >=20 > > #4: Untrusted location and provider intent > >=20 > > A location cannot be considered trusted for emergency services use if t= he > > location provider doesn't warrant its use for that purpose. The docume= nt > > currently does not discuss this point=2C but it seems like a quite impo= rtant > > issue. > >=20 > > For example=2C "location based services" which might provide location v= ia a > > platform or Javascript API will not necessarily meet the reliability or > > accuracy requirements for emergency location. In fact=2C the terms of > > service might explicitly disclaim the fitness for such uses. > >=20 > > Yet existing location APIs typically do not make a distinction between > > location providers who consider their location data unfit for use in an > > emergency=2C and an enterprise or carrier LIS that might be deployed > > specifically for the purpose of providing location for use in an > > emergency. Thus while it might be possible to construst a PIDF-LO by > > calling such an API=2C the validity of conveying such a PIDF-LO to the = PSAP > > might be suspect. > >=20 > > If an application can determine that a location is not warranted for us= e > > in an emergency=2C a number of workarounds might be possible. For exam= ple=2C > > the location might not be automatically conveyed without confirmation= =2C or > > might be flagged as potentially suspect=2C or the uncertainty might be = set > > to a very high value. > >=20 > > --=20 > > ---------------------------------------+-------------------------------= ----- > > Reporter: bernard_aboba@=85 | Owner: =20 > > Type: defect | Status: new =20 > > Priority: blocker | Milestone: milestone1 > > Component: trustworthy-location | Version: 1.0 =20 > > Severity: Active WG Document | Keywords: =20 > > ---------------------------------------+-------------------------------= ----- > >=20 > > Ticket URL: > > ecrit > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit = --_935d2c72-01f6-4ffb-8a52-fcc3161d8604_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sorry=2C I meant "not designed for use within the ECRIT architecture".
=
From: bernard_aboba@hotmail.com
To: br@brian= rosen.net=3B ecrit@ietf.org
Date: Mon=2C 21 Mar 2011 16:49:32 -0700
S= ubject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent
<= br> This seems reasonable. =3B Any recommendations on how we might ensure t= hat location would be accurately labeled in situations where it originates = from a "location based service" that might be designed for use within the E= CRIT architecture? Also=2C any thoughts on the circumstances in which user = confirmation might make sense?

I am reminded of an experience at th= e IETF meeting in Stockholm where one of the "location based services" whic= h shall remain nameless identified the IETF meeting as being located in San= Francisco because the IETF access points were scanned during the previous = IETF meeting. =3B =3B If you were looking for a pizza restaurant th= at might be humorous=2C but maybe not so much if you were using the locatio= n for routing to the PSAP. =3B

>=3B Subject: Re: [Ecrit] [ecr= it] #4: Untrusted location and provider intent
>=3B From: br@brianrose= n.net
>=3B Date: Mon=2C 21 Mar 2011 09:02:24 -0400
>=3B CC: berna= rd_aboba@hotmail.com
>=3B To: ecrit@ietf.org
>=3B
>=3B The = general rule I have for this is "send it=2C but let us know what you know a= bout it".
>=3B No entity should withhold location information unless i= t is certain that the information it is withholding is fraudulent.
>= =3B While the PSAP doesn't like having to decide what to do=2C it's better = that it has the information and knows that some of it MAY be suspect.
&g= t=3B
>=3B Let me cite an example: a telematics equipped car with an a= ccurate GPS=2C large antenna=2C always on=2C can provide far superior locat= ion than the cell phone through which an emergency call is placed. We want= the GPS from the car. What we get is what the network thinks.
>=3B <= br>>=3B It's okay that the network use its location to route. The PSAP w= ould prefer that it used the telematics location=2C but it's acceptable to = use the network location. It's certainly acceptable to send the network lo= cation. However=2C we also want the telematics location.
>=3B
>= =3B Of course=2C we want whatever location to be accurately labeled (source= =2C method=2C uncertainty).
>=3B
>=3B Brian
>=3B
>=3B= On Mar 19=2C 2011=2C at 9:46 PM=2C ecrit issue tracker wrote:
>=3B >=3B >=3B #4: Untrusted location and provider intent
>=3B >=3B=
>=3B >=3B A location cannot be considered trusted for emergency se= rvices use if the
>=3B >=3B location provider doesn't warrant its us= e for that purpose. The document
>=3B >=3B currently does not discu= ss this point=2C but it seems like a quite important
>=3B >=3B issue= .
>=3B >=3B
>=3B >=3B For example=2C "location based service= s" which might provide location via a
>=3B >=3B platform or Javascri= pt API will not necessarily meet the reliability or
>=3B >=3B accura= cy requirements for emergency location. In fact=2C the terms of
>=3B = >=3B service might explicitly disclaim the fitness for such uses.
>= =3B >=3B
>=3B >=3B Yet existing location APIs typically do not ma= ke a distinction between
>=3B >=3B location providers who consider t= heir location data unfit for use in an
>=3B >=3B emergency=2C and an= enterprise or carrier LIS that might be deployed
>=3B >=3B specific= ally for the purpose of providing location for use in an
>=3B >=3B e= mergency. Thus while it might be possible to construst a PIDF-LO by
>= =3B >=3B calling such an API=2C the validity of conveying such a PIDF-LO = to the PSAP
>=3B >=3B might be suspect.
>=3B >=3B
>=3B = >=3B If an application can determine that a location is not warranted for= use
>=3B >=3B in an emergency=2C a number of workarounds might be p= ossible. For example=2C
>=3B >=3B the location might not be automat= ically conveyed without confirmation=2C or
>=3B >=3B might be flagge= d as potentially suspect=2C or the uncertainty might be set
>=3B >= =3B to a very high value.
>=3B >=3B
>=3B >=3B --
>=3B = >=3B ---------------------------------------+----------------------------= --------
>=3B >=3B Reporter: bernard_aboba@=85 | O= wner:
>=3B >=3B Type: defect | = Status: new
>=3B >=3B Priority: blocker = | Milestone: milestone1
>=3B >=3B Component: trustworthy-lo= cation | Version: 1.0
>=3B >=3B Severity: Active = WG Document | Keywords:
>=3B >=3B -----------= ----------------------------+------------------------------------
>=3B= >=3B
>=3B >=3B Ticket URL: <=3Bhttp://wiki.tools.ietf.org/wg/e= crit/trac/ticket/4>=3B
>=3B >=3B ecrit <=3Bhttp://tools.ietf.org= /ecrit/>=3B
>=3B >=3B
>=3B >=3B __________________________= _____________________
>=3B >=3B Ecrit mailing list
>=3B >=3B = Ecrit@ietf.org
>=3B >=3B https://www.ietf.org/mailman/listinfo/ecrit=
>=3B
=20
_______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit = --_935d2c72-01f6-4ffb-8a52-fcc3161d8604_-- From br@brianrosen.net Mon Mar 21 17:00:13 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C121C28C175 for ; Mon, 21 Mar 2011 17:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+Lc9-lj37WT for ; Mon, 21 Mar 2011 17:00:06 -0700 (PDT) Received: from barmail5.idig.net (barmail5.idig.net [64.34.111.236]) by core3.amsl.com (Postfix) with ESMTP id 5C24B28C102 for ; Mon, 21 Mar 2011 17:00:06 -0700 (PDT) X-ASG-Debug-ID: 1300752097-00f27e25711063b0001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail5.idig.net with ESMTP id 5eL4In7QC1DMucrj; Mon, 21 Mar 2011 17:01:37 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.129.88]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Q1p2R-0002AU-Fu; Mon, 21 Mar 2011 17:01:38 -0700 Mime-Version: 1.0 (Apple Message framework v1082) X-ASG-Orig-Subj: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent Content-Type: multipart/alternative; boundary=Apple-Mail-10-322338644 From: Brian Rosen In-Reply-To: Date: Mon, 21 Mar 2011 20:01:25 -0400 Message-Id: <7ECD0153-FB83-4326-87D7-1817A3C8018F@brianrosen.net> References: <065.2714ac9a8b39105b6514f2472e116155@trac.tools.ietf.org>, , <33EF0B53-763B-4FE8-8CAE-3F5809D5D95B@brianrosen.net>, To: Bernard Aboba X-Mailer: Apple Mail (2.1082) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1300752097 X-Barracuda-URL: http://64.34.111.236:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.12 X-Barracuda-Spam-Status: No, SCORE=0.12 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.58587 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 0.00 HTML_MESSAGE BODY: HTML included in message Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 00:00:13 -0000 --Apple-Mail-10-322338644 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The PIDF contains fields for method and source, and mechanisms to = indicate uncertainty. That will do. Brian On Mar 21, 2011, at 7:52 PM, Bernard Aboba wrote: > Sorry, I meant "not designed for use within the ECRIT architecture".=20= >=20 > From: bernard_aboba@hotmail.com > To: br@brianrosen.net; ecrit@ietf.org > Date: Mon, 21 Mar 2011 16:49:32 -0700 > Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider = intent >=20 > This seems reasonable. Any recommendations on how we might ensure = that location would be accurately labeled in situations where it = originates from a "location based service" that might be designed for = use within the ECRIT architecture? Also, any thoughts on the = circumstances in which user confirmation might make sense?=20 >=20 > I am reminded of an experience at the IETF meeting in Stockholm where = one of the "location based services" which shall remain nameless = identified the IETF meeting as being located in San Francisco because = the IETF access points were scanned during the previous IETF meeting. = If you were looking for a pizza restaurant that might be humorous, but = maybe not so much if you were using the location for routing to the = PSAP. =20 >=20 > > Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider = intent > > From: br@brianrosen.net > > Date: Mon, 21 Mar 2011 09:02:24 -0400 > > CC: bernard_aboba@hotmail.com > > To: ecrit@ietf.org > >=20 > > The general rule I have for this is "send it, but let us know what = you know about it". > > No entity should withhold location information unless it is certain = that the information it is withholding is fraudulent. > > While the PSAP doesn't like having to decide what to do, it's better = that it has the information and knows that some of it MAY be suspect. > >=20 > > Let me cite an example: a telematics equipped car with an accurate = GPS, large antenna, always on, can provide far superior location than = the cell phone through which an emergency call is placed. We want the = GPS from the car. What we get is what the network thinks. > >=20 > > It's okay that the network use its location to route. The PSAP would = prefer that it used the telematics location, but it's acceptable to use = the network location. It's certainly acceptable to send the network = location. However, we also want the telematics location. > >=20 > > Of course, we want whatever location to be accurately labeled = (source, method, uncertainty). > >=20 > > Brian > >=20 > > On Mar 19, 2011, at 9:46 PM, ecrit issue tracker wrote: > >=20 > > > #4: Untrusted location and provider intent > > >=20 > > > A location cannot be considered trusted for emergency services use = if the > > > location provider doesn't warrant its use for that purpose. The = document > > > currently does not discuss this point, but it seems like a quite = important > > > issue. > > >=20 > > > For example, "location based services" which might provide = location via a > > > platform or Javascript API will not necessarily meet the = reliability or > > > accuracy requirements for emergency location. In fact, the terms = of > > > service might explicitly disclaim the fitness for such uses. > > >=20 > > > Yet existing location APIs typically do not make a distinction = between > > > location providers who consider their location data unfit for use = in an > > > emergency, and an enterprise or carrier LIS that might be deployed > > > specifically for the purpose of providing location for use in an > > > emergency. Thus while it might be possible to construst a PIDF-LO = by > > > calling such an API, the validity of conveying such a PIDF-LO to = the PSAP > > > might be suspect. > > >=20 > > > If an application can determine that a location is not warranted = for use > > > in an emergency, a number of workarounds might be possible. For = example, > > > the location might not be automatically conveyed without = confirmation, or > > > might be flagged as potentially suspect, or the uncertainty might = be set > > > to a very high value. > > >=20 > > > --=20 > > > = ---------------------------------------+----------------------------------= -- > > > Reporter: bernard_aboba@=85 | Owner:=20 > > > Type: defect | Status: new=20 > > > Priority: blocker | Milestone: milestone1 > > > Component: trustworthy-location | Version: 1.0=20 > > > Severity: Active WG Document | Keywords:=20 > > > = ---------------------------------------+----------------------------------= -- > > >=20 > > > Ticket URL: > > > ecrit > > >=20 > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > >=20 >=20 > _______________________________________________ Ecrit mailing list = Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail-10-322338644 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The PIDF contains fields for method and source, and = mechanisms to indicate uncertainty.  That will = do.

Brian

On Mar 21, 2011, at = 7:52 PM, Bernard Aboba wrote:

 

From: bernard_aboba@hotmail.comTo: br@brianrosen.net; ecrit@ietf.org
Date: Mon, 21 Mar = 2011 16:49:32 -0700
Subject: Re: [Ecrit] [ecrit] #4: Untrusted = location and provider intent

This seems reasonable.  Any = recommendations on how we might ensure that location would be accurately = labeled in situations where it originates from a "location based = service" that might be designed for use within the ECRIT architecture? = Also, any thoughts on the circumstances in which user confirmation might = make sense? 

I = am reminded of an experience at the IETF meeting in Stockholm where one = of the "location based services" which shall remain nameless identified = the IETF meeting as being located in San Francisco because the IETF = access points were scanned during the previous IETF meeting.   = If you were looking for a pizza restaurant that might be humorous, but = maybe not so much if you were using the location for routing to the = PSAP.  

>= Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider = intent
> From: br@brianrosen.net
> Date: = Mon, 21 Mar 2011 09:02:24 -0400
> CC: bernard_aboba@hotmail.com> To: ecrit@ietf.org
> 
> The general rule I = have for this is "send it, but let us know what you know about = it".
> No entity should withhold location information unless it is = certain that the information it is withholding is fraudulent.
> = While the PSAP doesn't like having to decide what to do, it's better = that it has the information and knows that some of it MAY be = suspect.
> 
> Let me cite an = example: a telematics equipped car with an accurate GPS, large antenna, = always on, can provide far superior location than the cell phone through = which an emergency call is placed. We want the GPS from the car. What we = get is what the network thinks.
> 
> It's okay that the = network use its location to route. The PSAP would prefer that it used = the telematics location, but it's acceptable to use the network = location. It's certainly acceptable to send the network location. = However, we also want the telematics location.
> 
> Of course, we want = whatever location to be accurately labeled (source, method, = uncertainty).
> 
> Brian
> 
> On Mar 19, 2011, = at 9:46 PM, ecrit issue tracker wrote:
> 
> > #4: Untrusted = location and provider intent
> > 
> > A location = cannot be considered trusted for emergency services use if the
> = > location provider doesn't warrant its use for that purpose. The = document
> > currently does not discuss this point, but it = seems like a quite important
> > issue.
> > 
> > For example, = "location based services" which might provide location via a
> = > platform or Javascript API will not necessarily meet the = reliability or
> > accuracy requirements for emergency = location. In fact, the terms of
> > service might explicitly = disclaim the fitness for such uses.
> > 
> > Yet existing = location APIs typically do not make a distinction between
> > = location providers who consider their location data unfit for use in = an
> > emergency, and an enterprise or carrier LIS that might = be deployed
> > specifically for the purpose of providing = location for use in an
> > emergency. Thus while it might be = possible to construst a PIDF-LO by
> > calling such an API, the = validity of conveying such a PIDF-LO to the PSAP
> > might be = suspect.
> > 
> > If an = application can determine that a location is not warranted for = use
> > in an emergency, a number of workarounds might be = possible. For example,
> > the location might not be = automatically conveyed without confirmation, or
> > might be = flagged as potentially suspect, or the uncertainty might be set
> = > to a very high value.
> > 
> > -- 
> > = ---------------------------------------+----------------------------------= --
> > Reporter: bernard_aboba@=85 | Owner: 
> > Type: defect = | Status: new 
> = > Priority: blocker | Milestone: milestone1
> > Component: = trustworthy-location | Version: 1.0 
> > Severity: = Active WG Document | Keywords: 
> > = ---------------------------------------+----------------------------------= --
> > 
>= > Ticket URL: <http://wiki.too= ls.ietf.org/wg/ecrit/trac/ticket/4>
> > ecrit <http://tools.ietf.org/ecrit/>=
> > 
> = > _______________________________________________
> > Ecrit = mailing list
> > Ecrit@ietf.org
> > https://www.ietf.org/= mailman/listinfo/ecrit
> 

_____________________= __________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/= mailman/listinfo/ecrit

= --Apple-Mail-10-322338644-- From Martin.Dawson@commscope.com Mon Mar 21 18:58:55 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A48128C1A0 for ; Mon, 21 Mar 2011 18:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7rd4-ZAjTXY for ; Mon, 21 Mar 2011 18:58:46 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id 3F53B3A6911 for ; Mon, 21 Mar 2011 18:58:46 -0700 (PDT) X-AuditID: 0a0404e9-b7c0fae000001e9f-5e-4d8802b2d1c5 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 2C.E5.07839.2B2088D4; Mon, 21 Mar 2011 21:00:18 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Mon, 21 Mar 2011 21:00:16 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 22 Mar 2011 10:00:13 +0800 From: "Dawson, Martin" To: Brian Rosen , Bernard Aboba Date: Tue, 22 Mar 2011 10:00:11 +0800 Thread-Topic: [Ecrit] [ecrit] #4: Untrusted location and provider intent Thread-Index: AcvoJFkBM2IOzkPqSGuOyHcN0K8aMAADq49g Message-ID: <8B0A9FCBB9832F43971E38010638454F0400BF030E@SISPE7MB1.commscope.com> References: <065.2714ac9a8b39105b6514f2472e116155@trac.tools.ietf.org>, , <33EF0B53-763B-4FE8-8CAE-3F5809D5D95B@brianrosen.net>, <7ECD0153-FB83-4326-87D7-1817A3C8018F@brianrosen.net> In-Reply-To: <7ECD0153-FB83-4326-87D7-1817A3C8018F@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8B0A9FCBB9832F43971E38010638454F0400BF030ESISPE7MB1comm_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 01:58:55 -0000 --_000_8B0A9FCBB9832F43971E38010638454F0400BF030ESISPE7MB1comm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >From the location service perspective, the response time attribute in the H= ELD location request allows the client to indicate that the intent is to us= e the location for emergency services (routing and/or dispatch). Depending = on jurisdiction policy then the LIS may choose to provide a location or not= depending on whether the operator is required to warrant such information.= The client still has the opportunity to ask for location without these qua= lifiers if it wants to proceed on that basis; in that situation the operato= r does not know that the intent is to use the location for emergencies. When it comes to a de-reference between the local emergency service and the= network operator, there should be a clear understanding of obligations and= undertakings outside the scope of the protocols anyway. I think that de-re= ferencing is always valuable for this sort of validation and it's good poli= cy to always provide and convey a reference for this purpose. In any case, Bernard's anecdote below helps to underscore why it's importan= t to include the network operator in the process and not rely on locations = independently determined and reported by the device. Cheers, Martin From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of B= rian Rosen Sent: Tuesday, 22 March 2011 11:01 AM To: Bernard Aboba Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent The PIDF contains fields for method and source, and mechanisms to indicate = uncertainty. That will do. Brian On Mar 21, 2011, at 7:52 PM, Bernard Aboba wrote: Sorry, I meant "not designed for use within the ECRIT architecture". ________________________________ From: bernard_aboba@hotmail.com To: br@brianrosen.net; ecrit@ietf.org Date: Mon, 21 Mar 2011 16:49:32 -0700 Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent This seems reasonable. Any recommendations on how we might ensure that loc= ation would be accurately labeled in situations where it originates from a = "location based service" that might be designed for use within the ECRIT ar= chitecture? Also, any thoughts on the circumstances in which user confirmat= ion might make sense? I am reminded of an experience at the IETF meeting in Stockholm where one o= f the "location based services" which shall remain nameless identified the = IETF meeting as being located in San Francisco because the IETF access poin= ts were scanned during the previous IETF meeting. If you were looking for= a pizza restaurant that might be humorous, but maybe not so much if you we= re using the location for routing to the PSAP. > Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent > From: br@brianrosen.net > Date: Mon, 21 Mar 2011 09:02:24 -0400 > CC: bernard_aboba@hotmail.com > To: ecrit@ietf.org > > The general rule I have for this is "send it, but let us know what you kn= ow about it". > No entity should withhold location information unless it is certain that = the information it is withholding is fraudulent. > While the PSAP doesn't like having to decide what to do, it's better that= it has the information and knows that some of it MAY be suspect. > > Let me cite an example: a telematics equipped car with an accurate GPS, l= arge antenna, always on, can provide far superior location than the cell ph= one through which an emergency call is placed. We want the GPS from the car= . What we get is what the network thinks. > > It's okay that the network use its location to route. The PSAP would pref= er that it used the telematics location, but it's acceptable to use the net= work location. It's certainly acceptable to send the network location. Howe= ver, we also want the telematics location. > > Of course, we want whatever location to be accurately labeled (source, me= thod, uncertainty). > > Brian > > On Mar 19, 2011, at 9:46 PM, ecrit issue tracker wrote: > > > #4: Untrusted location and provider intent > > > > A location cannot be considered trusted for emergency services use if t= he > > location provider doesn't warrant its use for that purpose. The documen= t > > currently does not discuss this point, but it seems like a quite import= ant > > issue. > > > > For example, "location based services" which might provide location via= a > > platform or Javascript API will not necessarily meet the reliability or > > accuracy requirements for emergency location. In fact, the terms of > > service might explicitly disclaim the fitness for such uses. > > > > Yet existing location APIs typically do not make a distinction between > > location providers who consider their location data unfit for use in an > > emergency, and an enterprise or carrier LIS that might be deployed > > specifically for the purpose of providing location for use in an > > emergency. Thus while it might be possible to construst a PIDF-LO by > > calling such an API, the validity of conveying such a PIDF-LO to the PS= AP > > might be suspect. > > > > If an application can determine that a location is not warranted for us= e > > in an emergency, a number of workarounds might be possible. For example= , > > the location might not be automatically conveyed without confirmation, = or > > might be flagged as potentially suspect, or the uncertainty might be se= t > > to a very high value. > > > > -- > > ---------------------------------------+-------------------------------= ----- > > Reporter: bernard_aboba@... | Owner: > > Type: defect | Status: new > > Priority: blocker | Milestone: milestone1 > > Component: trustworthy-location | Version: 1.0 > > Severity: Active WG Document | Keywords: > > ---------------------------------------+-------------------------------= ----- > > > > Ticket URL: > > ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ie= tf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_8B0A9FCBB9832F43971E38010638454F0400BF030ESISPE7MB1comm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From the location service perspective, the response time attribute in the HELD location request allows the client to indicate that t= he intent is to use the location for emergency services (routing and/or dispat= ch). Depending on jurisdiction policy then the LIS may choose to provide a locat= ion or not depending on whether the operator is required to warrant such inform= ation. The client still has the opportunity to ask for location without these qual= ifiers if it wants to proceed on that basis; in that situation the operator does n= ot know that the intent is to use the location for emergencies.

 

When it comes to a de-reference between the local emergency service and the network operator, there should be a clear understanding of obligations and undertakings outside the scope of the protocols anyway. I t= hink that de-referencing is always valuable for this sort of validation and it&#= 8217;s good policy to always provide and convey a reference for this purpose.=

 

In any case, Bernard’s anecdote below helps to undersc= ore why it’s important to include the network operator in the process and= not rely on locations independently determined and reported by the device.=

 

Cheers,

Martin

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Brian Rosen
Sent: Tuesday, 22 March 2011 11:01 AM
To: Bernard Aboba
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider int= ent

 

The PIDF contains fields for method and source, and mechanisms to indicate uncertainty.  That will do.

 

Brian

 

On Mar 21, 2011, at 7:52 PM, Bernard Aboba wrote:=



Sorry, I meant "not designed for us= e within the ECRIT architecture".&nb= sp;

From: bernard_aboba@hotmail.com
To: br@brianrosen.net; ecrit@ietf.org
Date: Mon, 21 Mar 2011 16:49:32 -0700
Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent

This seems reasonable.  Any recommendations on how we might ensure tha= t location would be accurately labeled in situations where it originates from= a "location based service" that might be designed for use within th= e ECRIT architecture? Also, any thoughts on the circumstances in which user confirmation might make sense? 

I am reminded of an experience at the IETF meeting in Stockholm where one o= f the "location based services" which shall remain nameless identif= ied the IETF meeting as being located in San Francisco because the IETF access points were scanned during the previous IETF meeting.   If you we= re looking for a pizza restaurant that might be humorous, but maybe not so muc= h if you were using the location for routing to the PSAP.  

> Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider inten= t
> From: br@brianrosen.net
> Date: Mon, 21 Mar 2011 09:02:24 -0400
> CC: bernard_aboba@hotmail.com
> To: ecrit@ietf.org
> 
> The general rule I have for this is "send it, but let us know wha= t you know about it".
> No entity should withhold location information unless it is certain th= at the information it is withholding is fraudulent.
> While the PSAP doesn't like having to decide what to do, it's better t= hat it has the information and knows that some of it MAY be suspect.
> 
> Let me cite an example: a telematics equipped car with an accurate GPS= , large antenna, always on, can provide far superior location than the cell p= hone through which an emergency call is placed. We want the GPS from the car. Wh= at we get is what the network thinks.
> 
> It's okay that the network use its location to route. The PSAP would prefer that it used the telematics location, but it's acceptable to use the network location. It's certainly acceptable to send the network location. However, we also want the telematics location.
> 
> Of course, we want whatever location to be accurately labeled (source, method, uncertainty).
> 
> Brian
> 
> On Mar 19, 2011, at 9:46 PM, ecrit issue tracker wrote:
> 
> > #4: Untrusted location and provider intent
> > 
> > A location cannot be considered trusted for emergency services us= e if the
> > location provider doesn't warrant its use for that purpose. The document
> > currently does not discuss this point, but it seems like a quite important
> > issue.
> > 
> > For example, "location based services" which might prov= ide location via a
> > platform or Javascript API will not necessarily meet the reliabil= ity or
> > accuracy requirements for emergency location. In fact, the terms = of
> > service might explicitly disclaim the fitness for such uses.
> > 
> > Yet existing location APIs typically do not make a distinction between
> > location providers who consider their location data unfit for use= in an
> > emergency, and an enterprise or carrier LIS that might be deploye= d
> > specifically for the purpose of providing location for use in an<= br> > > emergency. Thus while it might be possible to construst a PIDF-LO= by
> > calling such an API, the validity of conveying such a PIDF-LO to = the PSAP
> > might be suspect.
> > 
> > If an application can determine that a location is not warranted = for use
> > in an emergency, a number of workarounds might be possible. For example,
> > the location might not be automatically conveyed without confirmation, or
> > might be flagged as potentially suspect, or the uncertainty might= be set
> > to a very high value.
> > 
> > -- 
> > ---------------------------------------+-----------------------------------= -
> > Reporter: bernard_aboba@… | Owner: 
> > Type: defect | Status: new&nb= sp;
> > Priority: blocker | Milestone: milestone1
> > Component: trustworthy-location | Version: 1.0 
> > Severity: Active WG Document | Keywords: 
> > ---------------------------------------+-----------------------------------= -
> > 
> > Ticket URL: <http://wiki.tool= s.ietf.org/wg/ecrit/trac/ticket/4>
> > ecrit <http://tools.i= etf.org/ecrit/>
> > 
> > _______________________________________________
> > Ecrit mailing list
> > Ecrit@ietf.org
> > https://www.ietf.org/m= ailman/listinfo/ecrit
> 

_______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/m= ailman/listinfo/ecrit

 

--_000_8B0A9FCBB9832F43971E38010638454F0400BF030ESISPE7MB1comm_-- From mlinsner@cisco.com Tue Mar 22 06:59:37 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932B228C0F4 for ; Tue, 22 Mar 2011 06:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.901 X-Spam-Level: X-Spam-Status: No, score=-9.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id On1mdfFHBlR4 for ; Tue, 22 Mar 2011 06:59:35 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6CFAC28C0D0 for ; Tue, 22 Mar 2011 06:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=5860; q=dns/txt; s=iport; t=1300802468; x=1302012068; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=wRYvXGIcdr+mXuFZzuZqGQIuho5/DMJeb5TqRc6M7d8=; b=iPJcpQpoeDDiwRdq+wQxh9Tl22Zn2LA1R6vOS4H3+cv88iK15hdX8wmU hCa18ZHa3Jzkyb4AkNLtvxU5pqJJjTkISqtcET1eY0U5XqB6R5BjoTiTS otwM1YzuDU95Fjw0Y73hK0BKWsVCSHHaJ/kysi3JPYH5rzSw0OYtqhRY2 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAJIiE2rRDoJ/2dsb2JhbACCYaIEVnemSZxqhWgEjGuDUg X-IronPort-AV: E=Sophos;i="4.63,224,1299456000"; d="scan'208,217";a="350549553" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-5.cisco.com with ESMTP; 22 Mar 2011 14:01:08 +0000 Received: from [10.116.195.125] (rtp-mlinsner-87112.cisco.com [10.116.195.125]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2ME1592004306; Tue, 22 Mar 2011 14:01:07 GMT User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Tue, 22 Mar 2011 10:01:05 -0400 From: Marc Linsner To: "Dawson, Martin" Message-ID: Thread-Topic: [Ecrit] [ecrit] #4: Untrusted location and provider intent In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0400BF030E@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3383632868_461307" Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 13:59:37 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3383632868_461307 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Martin, >=20 >=20 > In any case, Bernard=B9s anecdote below helps to underscore why it=B9s import= ant > to include the network operator in the process and not rely on locations > independently determined and reported by the device. > =20 Have any SPs entertained offering a general location discovery service? I've only seen full location-based services/apps being offered to date. It makes one think that the end device using the cell tower db, 802.11 AP db, and gps may remain the predominant location discovery mechanism. -Marc-=20 --B_3383632868_461307 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Martin,


In any case, Bernard’s anecdote below help= s to underscore why it’s important to include the network operator in the process and= not rely on locations independently determined and reported by the device.=

 

Have any SPs entertained off= ering a general location discovery service?  

= I've only seen full location-based services/apps being offered to date. &nbs= p;It makes one think that the end device using the cell tower db, 802.11 AP = db, and gps may remain the predominant location discovery mechanism.

-Marc- 
--B_3383632868_461307-- From rbarnes@bbn.com Tue Mar 22 07:24:10 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3E0D28C11D for ; Tue, 22 Mar 2011 07:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtB+U2hIfV1v for ; Tue, 22 Mar 2011 07:24:08 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id AB4FD28C0D0 for ; Tue, 22 Mar 2011 07:24:08 -0700 (PDT) Received: from [192.1.255.181] (port=50019 helo=col-raltmann-l1.nira.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q22Wj-000Hgr-7b; Tue, 22 Mar 2011 10:25:41 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: Date: Tue, 22 Mar 2011 10:25:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Marc Linsner X-Mailer: Apple Mail (2.1082) Cc: "ecrit@ietf.org" , "Dawson, Martin" Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 14:24:10 -0000 I think the answer is "Yes, kinda". Multiple carriers are offering up = location access via third-party services, such as LocationLabs [1] and = LOC-AID [2]. There's also an effort in GSMA to standardize a similar = API, under the aegis of the OneAPI effort [3]. Also lacking in = discoverability. Differences relative to ECRIT/GEOPRIV: -- Not provided directly to subscriber devices -- Not discoverable through automated means -- Limited to cellular networks -- Each service uses its own interface/API/protocol All of which means serious headaches for a device that wants to roam = across multiple networks, especially if those networks include = non-cellular networks. --Richard [1] [2] [3] On Mar 22, 2011, at 10:01 AM, Marc Linsner wrote: > Martin, >>=20 >> In any case, Bernard=92s anecdote below helps to underscore why it=92s = important to include the network operator in the process and not rely on = locations independently determined and reported by the device. >> =20 > Have any SPs entertained offering a general location discovery = service? =20 >=20 > I've only seen full location-based services/apps being offered to = date. It makes one think that the end device using the cell tower db, = 802.11 AP db, and gps may remain the predominant location discovery = mechanism. >=20 > -Marc-=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Tue Mar 22 08:05:16 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7996B28C170 for ; Tue, 22 Mar 2011 08:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92BlQEorascI for ; Tue, 22 Mar 2011 08:05:15 -0700 (PDT) Received: from barmail5.idig.net (barmail5.idig.net [64.34.111.236]) by core3.amsl.com (Postfix) with ESMTP id B29BC28C165 for ; Tue, 22 Mar 2011 08:05:15 -0700 (PDT) X-ASG-Debug-ID: 1300806408-00f27e257011f020001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail5.idig.net with ESMTP id XBGgJUu8uQmcwNAD; Tue, 22 Mar 2011 08:06:48 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.129.88]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Q23AR-0005Nc-NF; Tue, 22 Mar 2011 08:06:47 -0700 Mime-Version: 1.0 (Apple Message framework v1082) X-ASG-Orig-Subj: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent Content-Type: multipart/alternative; boundary=Apple-Mail-13-376651011 From: Brian Rosen In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0400BF030E@SISPE7MB1.commscope.com> Date: Tue, 22 Mar 2011 11:06:38 -0400 Message-Id: <771B6A89-1BF4-40B9-889C-D9BD40EB051C@brianrosen.net> References: <065.2714ac9a8b39105b6514f2472e116155@trac.tools.ietf.org>, , <33EF0B53-763B-4FE8-8CAE-3F5809D5D95B@brianrosen.net>, <7ECD0153-FB83-4326-87D7-1817A3C8018F@brianrosen.net> <8B0A9FCBB9832F43971E38010638454F0400BF030E@SISPE7MB1.commscope.com> To: "Dawson, Martin" X-Mailer: Apple Mail (2.1082) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1300806408 X-Barracuda-URL: http://64.34.111.236:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.58647 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 15:05:16 -0000 --Apple-Mail-13-376651011 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > In any case, Bernard=92s anecdote below helps to underscore why it=92s = important to include the network operator in the process and not rely on = locations independently determined and reported by the device. Sure, if the network operator location is wildly different from some = other location, then perhaps the network's location might be better to = route on.=20 On the other hand, if the device has an on-board GPS that had been on = for a long time and tracking, then the cell based is far inferior to the = on board GPS. You use the best data you can get, as long as there isn't = a really serious conflict. Mark it with where it came from, and how it was determined, and keep the = uncertainty accurate, and we'll figure it out. Brian --Apple-Mail-13-376651011 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
In any case, Bernard=92s = anecdote below helps to underscore why it=92s important to include the = network operator in the process and not rely on locations independently = determined and reported by the = device.
Sure,= if the network operator location is wildly different from some other = location, then perhaps the network's location might be better to route = on. 

On the other hand, if the device has an = on-board GPS that had been on for a long time and tracking, then the = cell based is far inferior to the on board GPS.  You use the best = data you can get, as long as there isn't a really serious = conflict.

Mark it with where it came from, and = how it was determined, and keep the uncertainty accurate, and we'll = figure it = out.

Brian


= --Apple-Mail-13-376651011-- From Martin.Dawson@commscope.com Tue Mar 22 17:25:42 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 053AE28C105 for ; Tue, 22 Mar 2011 17:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xk1vF+U8oZbd for ; Tue, 22 Mar 2011 17:25:37 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id 509CF28C0F8 for ; Tue, 22 Mar 2011 17:25:37 -0700 (PDT) X-AuditID: 0a0404e8-b7bd2ae0000014c1-ec-4d893e5db2ab Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id D1.9E.05313.D5E398D4; Tue, 22 Mar 2011 19:27:10 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Tue, 22 Mar 2011 19:27:09 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 23 Mar 2011 08:27:06 +0800 From: "Dawson, Martin" To: Brian Rosen Date: Wed, 23 Mar 2011 08:27:04 +0800 Thread-Topic: [Ecrit] [ecrit] #4: Untrusted location and provider intent Thread-Index: AcvootYsvPcyO8Y+SaSuEMEBuirLWQATb7tg Message-ID: <8B0A9FCBB9832F43971E38010638454F0400BF042F@SISPE7MB1.commscope.com> References: <065.2714ac9a8b39105b6514f2472e116155@trac.tools.ietf.org>, , <33EF0B53-763B-4FE8-8CAE-3F5809D5D95B@brianrosen.net>, <7ECD0153-FB83-4326-87D7-1817A3C8018F@brianrosen.net> <8B0A9FCBB9832F43971E38010638454F0400BF030E@SISPE7MB1.commscope.com> <771B6A89-1BF4-40B9-889C-D9BD40EB051C@brianrosen.net> In-Reply-To: <771B6A89-1BF4-40B9-889C-D9BD40EB051C@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8B0A9FCBB9832F43971E38010638454F0400BF042FSISPE7MB1comm_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 00:25:42 -0000 --_000_8B0A9FCBB9832F43971E38010638454F0400BF042FSISPE7MB1comm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agreed - and this comes down to nuances of policy as well. Do you trust a precise location from a device if the network reference sugg= ests they are in a different country? Well, maybe not. Do you trust the pre= cise location of the device if it falls within the uncertainty indicated by= the network location - well, maybe you do. The key point is that the network location should be a key arbitration para= meter. We don't have to wheel out the anecdotes about swatting again do we. Cheers, Martin From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, 23 March 2011 2:07 AM To: Dawson, Martin Cc: Bernard Aboba; ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent In any case, Bernard's anecdote below helps to underscore why it's importan= t to include the network operator in the process and not rely on locations = independently determined and reported by the device. Sure, if the network operator location is wildly different from some other = location, then perhaps the network's location might be better to route on. On the other hand, if the device has an on-board GPS that had been on for a= long time and tracking, then the cell based is far inferior to the on boar= d GPS. You use the best data you can get, as long as there isn't a really = serious conflict. Mark it with where it came from, and how it was determined, and keep the un= certainty accurate, and we'll figure it out. Brian --_000_8B0A9FCBB9832F43971E38010638454F0400BF042FSISPE7MB1comm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agreed – and this comes down to nuances of policy as w= ell.

 

Do you trust a precise location from a device if the network reference suggests they are in a different country? Well, maybe not. Do you trust the precise location of the device if it falls within the uncertainty indicated by the network location – well, maybe you do.

 

The key point is that the network location should be a key arbitration parameter. We don’t have to wheel out the anecdotes about= swatting again do we.

 

Cheers,

Martin

 

From: Brian Rosen [mailto:br@brianrosen.net] =
Sent: Wednesday, 23 March 2011 2:07 AM
To: Dawson, Martin
Cc: Bernard Aboba; ecrit@ietf.org
Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider int= ent

 

In any case, Bernard’s anecdote below helps to undersc= ore why it’s important to include the network operator in the process and not= rely on locations independently determined and reported by the device.<= /o:p>

Sure, if the network operator location is wildly diffe= rent from some other location, then perhaps the network's location might be bett= er to route on. 

 

On the other hand, if the device has an on-board GPS t= hat had been on for a long time and tracking, then the cell based is far inferi= or to the on board GPS.  You use the best data you can get, as long as there isn't a really serious conflict.

 

Mark it with where it came from, and how it was determ= ined, and keep the uncertainty accurate, and we'll figure it out.

 

Brian

 

 

--_000_8B0A9FCBB9832F43971E38010638454F0400BF042FSISPE7MB1comm_-- From mlinsner@cisco.com Wed Mar 23 06:06:30 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73BE73A6868 for ; Wed, 23 Mar 2011 06:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.551 X-Spam-Level: X-Spam-Status: No, score=-9.551 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsIE4mUpwLiU for ; Wed, 23 Mar 2011 06:06:27 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 961E73A6859 for ; Wed, 23 Mar 2011 06:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=5393; q=dns/txt; s=iport; t=1300885681; x=1302095281; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=7l33HRUXlvVWDITCZ45EvB8BT0vNXYD3AXzEoWpSuNY=; b=C5fAdDJ82PYJuUjEhQsn+wE6Gyk3HbMyGZQKVbkyD0p3zEAgTpU+/hql bi4sk91nzqFmhg3+jh96wLY0/Tq2C0APM6sLPatskwV6OgKnSLFok/8xy k+LguXNJwkSF07WV2lEci/+K9RWGWcdYmGtjvryKunwLPU67SqHWs6iuu w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANWNiU2rRDoH/2dsb2JhbACCYaIKWHeITZ8VnBaFaQSMb4NS X-IronPort-AV: E=Sophos;i="4.63,231,1299456000"; d="scan'208,217";a="323450006" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 23 Mar 2011 13:08:01 +0000 Received: from [10.116.195.125] (rtp-mlinsner-87112.cisco.com [10.116.195.125]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2ND7wAf010430; Wed, 23 Mar 2011 13:07:59 GMT User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Wed, 23 Mar 2011 09:07:56 -0400 From: Marc Linsner To: "Dawson, Martin" Message-ID: Thread-Topic: [Ecrit] [ecrit] #4: Untrusted location and provider intent In-Reply-To: <8B0A9FCBB9832F43971E38010638454F0400BF042F@SISPE7MB1.commscope.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3383716079_225095" Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 13:06:30 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3383716079_225095 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable >=20 > =20 > The key point is that the network location should be a key arbitration > parameter. We don=B9t have to wheel out the anecdotes about swatting again = do > we. > =20 Until the network location is made available, it has no value. If location data is going to be held hostage to utilizing only SP provided apps, OTT providers will continue to use device discovered location information. -Marc- --B_3383716079_225095 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable <= blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT: #b5c4= df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">


 

The key point is that the network= location should be a key arbitration parameter. We don’t have to wheel out the anecdotes about= swatting again do we.

=  

Until the = network location is made available, it has no value.

If location data is going to be held hostage to utilizing only SP provided= apps, OTT providers will continue to use device discovered location informa= tion.

-Marc-
--B_3383716079_225095-- From rbarnes@bbn.com Wed Mar 23 07:34:31 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84FDE3A6919 for ; Wed, 23 Mar 2011 07:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlkYPoM4dttb for ; Wed, 23 Mar 2011 07:34:30 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 9472E3A6918 for ; Wed, 23 Mar 2011 07:34:30 -0700 (PDT) Received: from [192.1.255.181] (port=58082 helo=col-raltmann-l1.nira.bbn.com) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q2PAJ-000G9Y-3m; Wed, 23 Mar 2011 10:36:03 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: Date: Wed, 23 Mar 2011 09:24:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Marc Linsner X-Mailer: Apple Mail (2.1082) Cc: "ecrit@ietf.org" , "Dawson, Martin" Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 14:34:31 -0000 I think you guys are talking past each other, in two ways: 1. On the one hand, what Martin is saying is yet another argument that = SPs should provide location to OTT applications -- by reference if = nothing else. So he's arguing your point. 2. On the other hand, it kind of doesn't matter what location an OTT = application uses. The PSAP can also perform the verification using = location information it acquires directly from the SP, third-party-query = style. =20 The approach of draft-ietf-ecrit-rough-loc is relevant here: The SP can = provide the OTT application with a degraded value, as long as there's a = reference that the PSAP can use to obtain the real goods. --Richard On Mar 23, 2011, at 9:07 AM, Marc Linsner wrote: >>=20 >> =20 >> The key point is that the network location should be a key = arbitration parameter. We don=92t have to wheel out the anecdotes about = swatting again do we. >> =20 > Until the network location is made available, it has no value. >=20 > If location data is going to be held hostage to utilizing only SP = provided apps, OTT providers will continue to use device discovered = location information. >=20 > -Marc- > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From Martin.Dawson@commscope.com Wed Mar 23 15:17:29 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AF3C3A63CA for ; Wed, 23 Mar 2011 15:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-ld4DTQw5Jb for ; Wed, 23 Mar 2011 15:17:28 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id A13B83A6359 for ; Wed, 23 Mar 2011 15:17:28 -0700 (PDT) X-AuditID: 0a0404e8-b7bd2ae0000014c1-cb-4d8a71d6bacb Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 56.25.05313.6D17A8D4; Wed, 23 Mar 2011 17:19:02 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Wed, 23 Mar 2011 17:19:01 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 24 Mar 2011 06:18:59 +0800 From: "Dawson, Martin" To: "Richard L. Barnes" , Marc Linsner Date: Thu, 24 Mar 2011 06:18:56 +0800 Thread-Topic: [Ecrit] [ecrit] #4: Untrusted location and provider intent Thread-Index: AcvpZ6byxFxiGDRYSxq4wjyjrO37bgAP+MyA Message-ID: <8B0A9FCBB9832F43971E38010638454F0400BF056C@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 22:17:29 -0000 Yeah - what he said. I'm concerned that there's a mechanism for independently verifiable locatio= n for emergency calls; I think we have the mechanisms for that. I thought t= his was an ECRIT discussion - but if we're talking about other kinds of app= s, my actual view is that it would be good for OTT providers to have access= to both sources of location information. Conventional (generally just mobi= le) location architectures make that difficult but the geopriv architecture= makes it much more straightforward. Cheers, Martin -----Original Message----- From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 Sent: Thursday, 24 March 2011 12:24 AM To: Marc Linsner Cc: Dawson, Martin; ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #4: Untrusted location and provider intent I think you guys are talking past each other, in two ways: 1. On the one hand, what Martin is saying is yet another argument that SPs = should provide location to OTT applications -- by reference if nothing else= . So he's arguing your point. 2. On the other hand, it kind of doesn't matter what location an OTT applic= ation uses. The PSAP can also perform the verification using location info= rmation it acquires directly from the SP, third-party-query style. =20 The approach of draft-ietf-ecrit-rough-loc is relevant here: The SP can pro= vide the OTT application with a degraded value, as long as there's a refere= nce that the PSAP can use to obtain the real goods. --Richard On Mar 23, 2011, at 9:07 AM, Marc Linsner wrote: >>=20 >> =20 >> The key point is that the network location should be a key arbitration p= arameter. We don't have to wheel out the anecdotes about swatting again do = we. >> =20 > Until the network location is made available, it has no value. >=20 > If location data is going to be held hostage to utilizing only SP provide= d apps, OTT providers will continue to use device discovered location infor= mation. >=20 > -Marc- > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From mlinsner@cisco.com Fri Mar 25 05:07:01 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54AAE28B56A for ; Fri, 25 Mar 2011 05:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.435 X-Spam-Level: X-Spam-Status: No, score=-9.435 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsatWu2c0EYl for ; Fri, 25 Mar 2011 05:06:58 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 2282C3A680F for ; Fri, 25 Mar 2011 05:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=2955; q=dns/txt; s=iport; t=1301054913; x=1302264513; h=date:subject:from:to:message-id:mime-version; bh=Gxm+6V4wn5OiLrIVa6V/n4wfdRELVI/pkJviOVM63Jk=; b=FBN/OdJFHwGBjjB+daeM8VZAAWFPR7GZxHFHl5Jcfz5pVtA9V6bCEghn n1iDoEARGCgBgxn5SpFWDInlSDs9LMDZra8ere/2tH7KYkGsouy4UNJ4H eBw/42FRQM0bcBNHfE1EyceCzKLYA2nxv4JH1YO1vde5DcOsmK+evqdwk U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMyEjE2rRDoJ/2dsb2JhbACCX6IXXXenTJxfhWkEjHWDVA X-IronPort-AV: E=Sophos;i="4.63,242,1299456000"; d="scan'208,217";a="281150305" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-4.cisco.com with ESMTP; 25 Mar 2011 12:08:33 +0000 Received: from [10.116.195.125] (rtp-mlinsner-87112.cisco.com [10.116.195.125]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2PC8VFe029940 for ; Fri, 25 Mar 2011 12:08:32 GMT User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Fri, 25 Mar 2011 08:08:26 -0400 From: Marc Linsner To: "ecrit@ietf.org" Message-ID: Thread-Topic: Updated Agenda Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3383885312_51974" Subject: [Ecrit] Updated Agenda X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 12:07:01 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3383885312_51974 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 10 min * Agenda Bashing, Draft Status Update (Marc Linsner, Richard Barnes, Roger Marshall) 10 min * Similar Location (Roger Marshall) http://tools.ietf.org/id/draft-marshall-ecrit-similar-location-00.txt Intention: Discuss possibility for wg item 10 min * Additional Data related to an Emergency Call (Brian/Hannes) http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ Intention: Discuss open issues 30 min. * Public Safety Answering Point (PSAP) Callbacks (Hannes/Milan?) http://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback/ Intention: Discuss issues/differences 30 min. * Trustworthy Location Information (Hannes) http://datatracker.ietf.org/doc/draft-ietf-ecrit-trustworthy-location/ Intention: Discuss issues/differences 30 min. * Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices (Dirk) http://datatracker.ietf.org/doc/draft-ietf-ecrit-unauthenticated-access/ Intention: Discuss issues and differences --B_3383885312_51974 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
10 min * Agenda Bashing= , Draft Status Update (Marc Linsner,
Richard Barnes, Roger Marshal= l)

10 min * Similar Location (Roger Marshall)
=
http://tools.ietf.org/id/draft-marshall-ecrit-similar-location-00.txt
Intention: Discuss possibility for wg item

10 min * Additional Data related to an Emergency Call (Brian/Hannes)
<= div>http://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/
<= div>Intention: Discuss open issues

30 min. * Public= Safety Answering Point (PSAP) Callbacks (Hannes/Milan?)
http://da= tatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback/
Intention: = Discuss issues/differences

30 min. * Trustworthy Lo= cation Information (Hannes)
http://datatracker.ietf.org/doc/draft-= ietf-ecrit-trustworthy-location/
Intention: Discuss issues/differe= nces

30 min. * Extensions to the Emergency Services= Architecture for dealing with
Unauthenticated and Unauthorized De= vices (Dirk)
http://datatracker.ietf.org/doc/draft-ietf-ecrit-unau= thenticated-access/
Intention: Discuss issues and differences

--B_3383885312_51974-- From Internet-Drafts@ietf.org Mon Mar 28 13:45:05 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D929F3A6902; Mon, 28 Mar 2011 13:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4Hw9k3ApWdM; Mon, 28 Mar 2011 13:45:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE21028B23E; Mon, 28 Mar 2011 13:45:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110328204501.13255.68838.idtracker@localhost> Date: Mon, 28 Mar 2011 13:45:01 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-17.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 20:45:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Best Current Practice for Communications Services in support of Emergency Calling Author(s) : B. Rosen, J. Polk Filename : draft-ietf-ecrit-phonebcp-17.txt Pages : 26 Date : 2011-03-28 The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services should use such standards to make emergency calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-phonebcp-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-28134131.I-D@ietf.org> --NextPart-- From br@brianrosen.net Mon Mar 28 13:54:21 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADDB83A6A6F for ; Mon, 28 Mar 2011 13:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-QyGAz9-k7J for ; Mon, 28 Mar 2011 13:54:20 -0700 (PDT) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by core3.amsl.com (Postfix) with ESMTP id 9C8C628B23E for ; Mon, 28 Mar 2011 13:54:20 -0700 (PDT) X-ASG-Debug-ID: 1301345750-011a9f237c13a340001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id 2FCCGFWqKimF8UjU for ; Mon, 28 Mar 2011 13:55:50 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=ndont-61.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Q4JTT-0006cD-Va for ecrit@ietf.org; Mon, 28 Mar 2011 13:55:50 -0700 From: Brian Rosen Content-Type: multipart/alternative; boundary=Apple-Mail-23-915992949 Date: Mon, 28 Mar 2011 22:55:39 +0200 X-ASG-Orig-Subj: Fwd: I-D Action:draft-ietf-ecrit-phonebcp-17.txt References: <20110328204501.13255.68838.idtracker@localhost> To: "ecrit@ietf.org Org" Message-Id: <046E674E-10C1-4EED-858D-728B081C6AFA@brianrosen.net> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1301345750 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.13 X-Barracuda-Spam-Status: No, SCORE=0.13 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=CN_BODY_332, HTML_MESSAGE, MIME_HTML_MOSTLY X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.59246 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.12 CN_BODY_332 BODY: CN_BODY_332 0.00 MIME_HTML_MOSTLY BODY: Multipart message mostly text/html MIME 0.00 HTML_MESSAGE BODY: HTML included in message Subject: [Ecrit] Fwd: I-D Action:draft-ietf-ecrit-phonebcp-17.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 20:54:21 -0000 --Apple-Mail-23-915992949 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have submitted a new draft that: addresses several comments received, none of which change the substance = of the document update the reference to -conveyance and fix the document to conform to = the latest version of -conveyance attempts to close the discussion on media by explicitly allowing a = transcoder Adds IANA actions to define the test service urn stuff Brian Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: March 28, 2011 10:45:01 PM GMT+02:00 > To: i-d-announce@ietf.org > Cc: ecrit@ietf.org > Subject: I-D Action:draft-ietf-ecrit-phonebcp-17.txt > Reply-To: internet-drafts@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Emergency Context Resolution with = Internet Technologies Working Group of the IETF. >=20 >=20 > Title : Best Current Practice for Communications = Services in support of Emergency Calling > Author(s) : B. Rosen, J. Polk > Filename : draft-ietf-ecrit-phonebcp-17.txt > Pages : 26 > Date : 2011-03-28 >=20 > The IETF and other standards organization have efforts targeted at > standardizing various aspects of placing emergency calls on IP > networks. This memo describes best current practice on how devices, > networks and services should use such standards to make emergency > calls. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-17.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-23-915992949 Content-Type: multipart/mixed; boundary=Apple-Mail-24-915992949 --Apple-Mail-24-915992949 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = have submitted a new draft that:
addresses several comments = received, none of which change the substance of the = document
update the reference to -conveyance and fix the = document to conform to the latest version of = -conveyance
attempts to close the discussion on media by = explicitly allowing a transcoder
Adds IANA actions to define = the test service urn = stuff

Brian

Begin forwarded = message:

Date: March 28, 2011 10:45:01 PM = GMT+02:00
Subject: I-D = Action:draft-ietf-ecrit-phonebcp-17.txt
Reply-To: internet-drafts@ietf.org
<= /span>

A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of the = Emergency Context Resolution with Internet Technologies Working Group of = the IETF.


Title =           : Best = Current Practice for Communications Services in support of Emergency = Calling
= Author(s)       : B. Rosen, J. = Polk
= Filename        : = draft-ietf-ecrit-phonebcp-17.txt
Pages =           : = 26
= Date =            : = 2011-03-28

The IETF and other standards organization have efforts = targeted at
standardizing various aspects of placing emergency calls = on IP
networks.  This memo describes best current practice on = how devices,
networks and services should use such standards to make = emergency
calls.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-17.txt

Internet-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data = which will enable a MIME compliant mail reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-24-915992949 Content-Disposition: attachment; filename="Mail Attachment" Content-Type: message/external-body; name="Mail Attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2011-03-28134131.I-D@ietf.org>

--Apple-Mail-24-915992949 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--Apple-Mail-24-915992949-- --Apple-Mail-23-915992949-- From hannes.tschofenig@gmx.net Tue Mar 29 04:25:21 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7362F3A6767 for ; Tue, 29 Mar 2011 04:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2WiBxyyzNjq for ; Tue, 29 Mar 2011 04:25:20 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 268D728C12B for ; Tue, 29 Mar 2011 04:25:19 -0700 (PDT) Received: (qmail invoked by alias); 29 Mar 2011 11:26:56 -0000 Received: from unknown (EHLO dhcp-9039.meeting.ietf.org) [130.129.8.57] by mail.gmx.net (mp007) with SMTP; 29 Mar 2011 13:26:56 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+KY71C31GKQ2AnyuUxTVqcK8UGzIsWkbcP91SEDG 5Erjx2u9p/zJ3J From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Mar 2011 13:26:51 +0200 Message-Id: <9860DD9F-5FCF-41D3-AA1E-DC291EEB2DC5@gmx.net> To: ecrit Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Hannes Tschofenig Subject: [Ecrit] Location Hiding Requirements Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 11:25:21 -0000 During the meeting I had said that maybe we can move the blocking = normative reference to the informative reference section.=20 I took a look at the draft again and I believe we cannot do that. So, my = suggestion does not work. We need to wait till the ECRIT framework = document is published.=20 Ciao Hannes From rbarnes@bbn.com Tue Mar 29 04:29:55 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A38628C153 for ; Tue, 29 Mar 2011 04:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THSHfGQ3sE6s for ; Tue, 29 Mar 2011 04:29:54 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id B8B5128C0FB for ; Tue, 29 Mar 2011 04:29:54 -0700 (PDT) Received: from [128.89.255.96] (port=53809 helo=[130.129.17.55]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q4X92-0004RI-G1 for ecrit@ietf.org; Tue, 29 Mar 2011 07:31:32 -0400 From: "Richard L. Barnes" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Mar 2011 13:31:28 +0200 References: <20110329112500.2086C28C0EE@core3.amsl.com> To: "ecrit@ietf.org Org" Message-Id: Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [Ecrit] Fwd: New Version Notification for draft-ietf-ecrit-rough-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 11:29:55 -0000 This revision is mostly just to revive this draft from the Expired state = so that it can have a WGLC.=20 I did make one change to the filterRegion(X) routine that removes a = downref to draft-ietf-ecrit-servicelistboundary. --Richard Begin forwarded message: > From: IETF I-D Submission Tool > Date: March 29, 2011 1:25:00 PM GMT+02:00 > To: rbarnes@bbn.com > Cc: mlepinski@bbn.com > Subject: New Version Notification for draft-ietf-ecrit-rough-loc-04=20 >=20 >=20 > A new version of I-D, draft-ietf-ecrit-rough-loc-04.txt has been = successfully submitted by Richard Barnes and posted to the IETF = repository. >=20 > Filename: draft-ietf-ecrit-rough-loc > Revision: 04 > Title: Using Imprecise Location for Emergency Context = Resolution > Creation_date: 2011-03-29 > WG ID: ecrit > Number_of_pages: 18 >=20 > Abstract: > Emergency calling works best when precise location is available for > emergency call routing. However, there are situations in which a > location provider is unable or unwilling to provide precise location, > yet still wishes to enable subscribers to make emergency calls. This > document describes the level of location accuracy that providers must > provide to enable emergency call routing. In addition, we descibe > how emergency services and non-emergency services can be invoked by > an endpoint that does not have access to its precise location. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 From Internet-Drafts@ietf.org Tue Mar 29 04:30:04 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49B9A28C15B; Tue, 29 Mar 2011 04:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxBN1Nm4QyMw; Tue, 29 Mar 2011 04:30:03 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3E3928C0FB; Tue, 29 Mar 2011 04:30:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110329113002.28370.2259.idtracker@localhost> Date: Tue, 29 Mar 2011 04:30:02 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-lost-sync-10.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 11:30:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements Author(s) : H. Schulzrinne, H. Tschofenig Filename : draft-ietf-ecrit-lost-sync-10.txt Pages : 28 Date : 2011-03-29 The Location-to-Service Translation (LoST) protocol is an XML-based protocol for mapping service identifiers and geodetic or civic location information to service URIs and service boundaries. In particular, it can be used to determine the location-appropriate Public Safety Answering Point (PSAP) for emergency services. The main data structure, the element, used for encapsulating information about service boundaries is defined in the LoST protocol specification and circumscribes the region within which all locations map to the same service Uniform Resource Identifier (URI) or set of URIs for a given service. This document defines an XML protocol to exchange these mappings between two nodes. This mechanism is designed for the exchange of authoritative elements between two entities. Exchanging cached elements, i.e. non-authoritative elements, is possible but not envisioned. In any case, this document can also be used without the LoST protocol even though the format of the element is re-used from the LoST specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-sync-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-lost-sync-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-29042636.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Tue Mar 29 04:30:06 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACD3528C15E; Tue, 29 Mar 2011 04:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oK3kMmYRuJVp; Tue, 29 Mar 2011 04:30:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7756528C15A; Tue, 29 Mar 2011 04:30:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110329113002.28370.23216.idtracker@localhost> Date: Tue, 29 Mar 2011 04:30:02 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-rough-loc-04.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 11:30:06 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Using Imprecise Location for Emergency Context Resolution Author(s) : R. Barnes, M. Lepinski Filename : draft-ietf-ecrit-rough-loc-04.txt Pages : 18 Date : 2011-03-29 Emergency calling works best when precise location is available for emergency call routing. However, there are situations in which a location provider is unable or unwilling to provide precise location, yet still wishes to enable subscribers to make emergency calls. This document describes the level of location accuracy that providers must provide to enable emergency call routing. In addition, we descibe how emergency services and non-emergency services can be invoked by an endpoint that does not have access to its precise location. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-rough-loc-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-rough-loc-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-29042459.I-D@ietf.org> --NextPart-- From hannes.tschofenig@gmx.net Tue Mar 29 04:30:33 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A54FE28C169 for ; Tue, 29 Mar 2011 04:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oxmR2BIywec for ; Tue, 29 Mar 2011 04:30:33 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 88CD828C13D for ; Tue, 29 Mar 2011 04:30:31 -0700 (PDT) Received: (qmail invoked by alias); 29 Mar 2011 11:32:08 -0000 Received: from unknown (EHLO dhcp-9039.meeting.ietf.org) [130.129.8.57] by mail.gmx.net (mp063) with SMTP; 29 Mar 2011 13:32:08 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/IELZdd07I3NhdMcP109aowe7zUEqeeZoN/mcps8 vl4zxauJRNSBG4 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Mar 2011 13:32:08 +0200 Message-Id: To: ecrit Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Hannes Tschofenig Subject: [Ecrit] LoST Sync X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 11:30:33 -0000 I just re-submitted the (expired) LoST sync draft.=20 As mentioned during the meeting the document is waiting for a review = from the XML directorate. I may get hold of someone from that = directorate during this week in order to move this forward.=20 Ciao Hannes From br@brianrosen.net Tue Mar 29 05:00:50 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A485D3A6A33 for ; Tue, 29 Mar 2011 05:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJ6FiaR1aQlZ for ; Tue, 29 Mar 2011 05:00:49 -0700 (PDT) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by core3.amsl.com (Postfix) with ESMTP id 935B83A6A30 for ; Tue, 29 Mar 2011 05:00:49 -0700 (PDT) X-ASG-Debug-ID: 1301400146-011a9f4f7a172e0001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id EeGGr4cYbDMDuTv7 for ; Tue, 29 Mar 2011 05:02:26 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=ndont-61.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Q4Xcs-0005tx-5W for ecrit@ietf.org; Tue, 29 Mar 2011 05:02:25 -0700 From: Brian Rosen Content-Type: multipart/alternative; boundary=Apple-Mail-33-970389570 Date: Tue, 29 Mar 2011 14:02:16 +0200 X-ASG-Orig-Subj: Fwd: New Version Notification for draft-rosen-ecrit-lost-return-li-00 References: <20110329112734.A0B623A681B@core3.amsl.com> To: "ecrit@ietf.org Org" Message-Id: <333B3219-AAF2-4A2F-9E3B-EB372D233164@brianrosen.net> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1301400146 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.59306 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Subject: [Ecrit] Fwd: New Version Notification for draft-rosen-ecrit-lost-return-li-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:00:50 -0000 --Apple-Mail-33-970389570 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have just submitted a new draft that does one simple thing: allow = location information to be returned in a , when = validation is requested, the LI in the request was valid, but the LoST = server knew more CAtypes for the location than were in the request. A simple example is an address with a postal code, but without an A1, A2 = or A3 CAtypes. The LoST server may discover that it knows precisely = where the the LI is, but it would be helpful for the querier to get the = A1, A2 and A3 values back from the server. This allows the LoST sever = to return LI. Please forgive the RELAX stuff. I am clueless, and need to find someone = to help me do it right. Brian Begin forwarded message: > From: IETF I-D Submission Tool > Date: March 29, 2011 1:27:34 PM GMT+02:00 > To: br@brianrosen.net > Subject: New Version Notification for = draft-rosen-ecrit-lost-return-li-00=20 >=20 >=20 > A new version of I-D, draft-rosen-ecrit-lost-return-li-00.txt has been = successfully submitted by Brian Rosen and posted to the IETF repository. >=20 > Filename: draft-rosen-ecrit-lost-return-li > Revision: 00 > Title: Returning a Location Information in a Location = to Service Translation query > Creation_date: 2011-03-29 > WG ID: Independent Submission > Number_of_pages: 7 >=20 > Abstract: > This document defines an extension to LoST (RFC5222) to permit a > location information to be returned in a findservice response. When > the validation is requested in the findservice request, the location > information supplied in the request may have enough valid address > components (CAtypes) to be considered valid, but the LoST server may > wish to return address components CAtypes not found in the query. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 --Apple-Mail-33-970389570 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = have just submitted a new draft that does one simple thing: allow = location information to be returned in a <findServiceResponse>, = when validation is requested, the LI in the request was valid, but the = LoST server knew more CAtypes for the location than were in the = request.

A simple example is an address with a postal = code, but without an A1, A2 or A3 CAtypes.  The LoST server may = discover that it knows precisely where the the LI is, but it would be = helpful for the querier to get the A1, A2 and A3 values back from the = server.  This allows the LoST sever to return = LI.

Please forgive the RELAX stuff.  I am = clueless, and need to find someone to help me do it = right.

Brian

Begin forwarded = message:

Date: March 29, 2011 1:27:34 PM = GMT+02:00
Subject: New Version = Notification for draft-rosen-ecrit-lost-return-li-00 =


A new version of I-D, = draft-rosen-ecrit-lost-return-li-00.txt has been successfully submitted = by Brian Rosen and posted to the IETF repository.

Filename: = draft-rosen-ecrit-lost-return-li
Revision: = 00
Title: = = Returning a Location Information in a Location to Service = Translation query
Creation_date: 2011-03-29
WG ID: = Independent Submission
Number_of_pages: 7

Abstract:
This = document defines an extension to LoST (RFC5222) to permit a
location = information to be returned in a findservice response.  When
the = validation is requested in the findservice request, the = location
information supplied in the request may have enough valid = address
components (CAtypes) to be considered valid, but the LoST = server may
wish to return address components CAtypes not found in the = query.



The IETF = Secretariat.



= --Apple-Mail-33-970389570-- From randy@qualcomm.com Tue Mar 29 05:09:17 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EF213A67B0 for ; Tue, 29 Mar 2011 05:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9y2goUVYjUi for ; Tue, 29 Mar 2011 05:09:16 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 2824C3A6784 for ; Tue, 29 Mar 2011 05:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1301400654; x=1332936654; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:mime-version:content-type:x-random-sig-tag: x-originating-ip; z=Message-ID:=20|In-Reply-To:=20<4163F28B-4861-4E94-9751-099AE3AE 3DAC@brianrosen.net>|References:=20<8C2A715A-2F04-445E-B5 11-392F434F515F@cisco.com>=0D=0A=20<4163F28B-4861-4E94-97 51-099AE3AE3DAC@brianrosen.net>|X-Mailer:=20Eudora=20for =20Mac=20OS=20X|Date:=20Tue,=2029=20Mar=202011=2005:07:00 =20-0700|To:=20Brian=20Rosen=20,=20ECR IT=20|From:=20Randall=20Gellens=20|Subject:=20Client-known=20vs.=20server-know n=20data=20in=0D=0A=20draft-ietf-ecrit-additional-data |MIME-Version:=201.0|Content-Type:=20text/plain=3B=20char set=3D"us-ascii"=3B=20format=3Dflowed|X-Random-Sig-Tag: =201.0b28|X-Originating-IP:=20[172.30.48.1]; bh=nivfNLXoL+FPdPy2aYNB0Vn9aw/SnolEfLM7dggtTf0=; b=Pt2fDwqOJM/UJp6tAZ8NtcbqRRmwpxcCS8fiVXF8iWS2NpgYOQvrjY7v zI4UkO0ufGl+lPTEF5e03q6WybKoq9yWMhd7k58UIwspiFICSZyEWTVEr cnVsjWl+W1bXKwgm0dDVOhBMOgiC+MTfbZn4JtpiS/k2vKB++XySV1vqH 4=; X-IronPort-AV: E=McAfee;i="5400,1158,6299"; a="82666030" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 29 Mar 2011 05:10:54 -0700 X-IronPort-AV: E=Sophos;i="4.63,259,1299484800"; d="scan'208";a="128826434" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 29 Mar 2011 05:10:54 -0700 Received: from dhcp-17ef.meeting.ietf.org (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 29 Mar 2011 05:10:53 -0700 Message-ID: In-Reply-To: <4163F28B-4861-4E94-9751-099AE3AE3DAC@brianrosen.net> References: <8C2A715A-2F04-445E-B511-392F434F515F@cisco.com> <4163F28B-4861-4E94-9751-099AE3AE3DAC@brianrosen.net> X-Mailer: Eudora for Mac OS X Date: Tue, 29 Mar 2011 05:07:00 -0700 To: Brian Rosen , ECRIT From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.48.1] Subject: [Ecrit] Client-known vs. server-known data in draft-ietf-ecrit-additional-data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:09:17 -0000 As discussed in today's meeting, I think it's useful to consider two broad categories of additional data: that which is known by a server, and that which only the device knows. If the server knows the data, then the mechanism in the draft (inserting an HTTPS URI into a Call-Info header) is fine. But if only the device knows the data, this mechanism requires the device to first upload the data to a server and obtain a URL, before attempting call setup. A better approach would be to allow data known by the client to be transmitted by the client as a MIME body part. In theory, this can be done either in the call-setup (as a body part in the INVITE, similar to how location-by-value is transmitted), or in a subsequent SIP method after call setup. I suggest the latter, using SIP MESSAGE method for this. Especially for telematics data, which could grow to be fairly large, this seems useful. New MIME subtypes can be registered, with whatever granularity we want. For example, under the application subtype (or text, but I'm leaning towards application), we can define subtypes for various forms of additional-data for emergency calls, such as telematics, device-info, etc. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The trouble with the world is not that people know too little, but that they know so many things that ain't so. --Mark Twain From rbarnes@bbn.com Tue Mar 29 05:12:10 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74AB43A683D for ; Tue, 29 Mar 2011 05:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWLL5Rr8LAcg for ; Tue, 29 Mar 2011 05:12:08 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 1CE8E3A6783 for ; Tue, 29 Mar 2011 05:12:08 -0700 (PDT) Received: from [128.89.255.96] (port=53947 helo=[130.129.17.55]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q4Xnt-0004mp-Ui; Tue, 29 Mar 2011 08:13:46 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <333B3219-AAF2-4A2F-9E3B-EB372D233164@brianrosen.net> Date: Tue, 29 Mar 2011 14:13:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4128CD8B-2E13-45D9-B1FF-ABFEE5C2834F@bbn.com> References: <20110329112734.A0B623A681B@core3.amsl.com> <333B3219-AAF2-4A2F-9E3B-EB372D233164@brianrosen.net> To: Brian Rosen X-Mailer: Apple Mail (2.1082) Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Fwd: New Version Notification for draft-rosen-ecrit-lost-return-li-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:12:10 -0000 How does this relate to Roger's "similar location" draft? --Richard On Mar 29, 2011, at 2:02 PM, Brian Rosen wrote: > I have just submitted a new draft that does one simple thing: allow = location information to be returned in a , when = validation is requested, the LI in the request was valid, but the LoST = server knew more CAtypes for the location than were in the request. >=20 > A simple example is an address with a postal code, but without an A1, = A2 or A3 CAtypes. The LoST server may discover that it knows precisely = where the the LI is, but it would be helpful for the querier to get the = A1, A2 and A3 values back from the server. This allows the LoST sever = to return LI. >=20 > Please forgive the RELAX stuff. I am clueless, and need to find = someone to help me do it right. >=20 > Brian >=20 > Begin forwarded message: >=20 >> From: IETF I-D Submission Tool >> Date: March 29, 2011 1:27:34 PM GMT+02:00 >> To: br@brianrosen.net >> Subject: New Version Notification for = draft-rosen-ecrit-lost-return-li-00=20 >>=20 >>=20 >> A new version of I-D, draft-rosen-ecrit-lost-return-li-00.txt has = been successfully submitted by Brian Rosen and posted to the IETF = repository. >>=20 >> Filename: draft-rosen-ecrit-lost-return-li >> Revision: 00 >> Title: Returning a Location Information in a Location = to Service Translation query >> Creation_date: 2011-03-29 >> WG ID: Independent Submission >> Number_of_pages: 7 >>=20 >> Abstract: >> This document defines an extension to LoST (RFC5222) to permit a >> location information to be returned in a findservice response. When >> the validation is requested in the findservice request, the location >> information supplied in the request may have enough valid address >> components (CAtypes) to be considered valid, but the LoST server may >> wish to return address components CAtypes not found in the query. >>=20 >>=20 >>=20 >> The IETF Secretariat. >>=20 >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Tue Mar 29 05:15:44 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4E03A6784 for ; Tue, 29 Mar 2011 05:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W04J5vp9xMOC for ; Tue, 29 Mar 2011 05:15:43 -0700 (PDT) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by core3.amsl.com (Postfix) with ESMTP id 2D2893A697F for ; Tue, 29 Mar 2011 05:15:41 -0700 (PDT) X-ASG-Debug-ID: 1301401038-011a9f4f7a18560001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id Bj9no4ykM5ZlCVuH; Tue, 29 Mar 2011 05:17:18 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=ndont-61.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Q4XrE-0002gT-Hz; Tue, 29 Mar 2011 05:17:14 -0700 Mime-Version: 1.0 (Apple Message framework v1084) X-ASG-Orig-Subj: Re: Client-known vs. server-known data in draft-ietf-ecrit-additional-data Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: Date: Tue, 29 Mar 2011 14:17:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <33D2DD54-77E2-4F21-8D1F-8A22963D1D09@brianrosen.net> References: <8C2A715A-2F04-445E-B511-392F434F515F@cisco.com> <4163F28B-4861-4E94-9751-099AE3AE3DAC@brianrosen.net> To: Randall Gellens X-Mailer: Apple Mail (2.1084) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1301401038 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.59308 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: ECRIT Subject: Re: [Ecrit] Client-known vs. server-known data in draft-ietf-ecrit-additional-data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:15:44 -0000 Subject to what Martin is thinking, I was imagining that in both the = Call Info header and the hook where telematics info goes could be a CID, = which could be found in the body. Brian On Mar 29, 2011, at 2:07 PM, Randall Gellens wrote: > As discussed in today's meeting, I think it's useful to consider two = broad categories of additional data: that which is known by a server, = and that which only the device knows. >=20 > If the server knows the data, then the mechanism in the draft = (inserting an HTTPS URI into a Call-Info header) is fine. But if only = the device knows the data, this mechanism requires the device to first = upload the data to a server and obtain a URL, before attempting call = setup. A better approach would be to allow data known by the client to = be transmitted by the client as a MIME body part. In theory, this can = be done either in the call-setup (as a body part in the INVITE, similar = to how location-by-value is transmitted), or in a subsequent SIP method = after call setup. I suggest the latter, using SIP MESSAGE method for = this. Especially for telematics data, which could grow to be fairly = large, this seems useful. >=20 > New MIME subtypes can be registered, with whatever granularity we = want. For example, under the application subtype (or text, but I'm = leaning towards application), we can define subtypes for various forms = of additional-data for emergency calls, such as telematics, device-info, = etc. >=20 > --=20 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > The trouble with the world is not that people know too little, but > that they know so many things that ain't so. > --Mark Twain From rbarnes@bbn.com Tue Mar 29 05:16:18 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0468B3A67FC for ; Tue, 29 Mar 2011 05:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PH9JOhwKDcjS for ; Tue, 29 Mar 2011 05:16:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 2BFEB3A67A8 for ; Tue, 29 Mar 2011 05:16:17 -0700 (PDT) Received: from [128.89.255.96] (port=53951 helo=[130.129.17.55]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q4Xrt-0004pZ-Ia; Tue, 29 Mar 2011 08:17:53 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Tue, 29 Mar 2011 14:17:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3A91A848-4C13-439B-8CC9-F238C6E11A2B@bbn.com> References: <8C2A715A-2F04-445E-B511-392F434F515F@cisco.com> <4163F28B-4861-4E94-9751-099AE3AE3DAC@brianrosen.net> To: Randall Gellens X-Mailer: Apple Mail (2.1082) Cc: ECRIT Subject: Re: [Ecrit] Client-known vs. server-known data in draft-ietf-ecrit-additional-data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:16:18 -0000 I agree that HTTPS access is a pain for device-included information. = But it also seems like using MESSAGE would prevent this information from = being used for call routing. If there's few enough things to include, maybe it could go in a SIP = header? Could be helpful to specify which data items are likely to be = sourced from the client? --Richard On Mar 29, 2011, at 2:07 PM, Randall Gellens wrote: > As discussed in today's meeting, I think it's useful to consider two = broad categories of additional data: that which is known by a server, = and that which only the device knows. >=20 > If the server knows the data, then the mechanism in the draft = (inserting an HTTPS URI into a Call-Info header) is fine. But if only = the device knows the data, this mechanism requires the device to first = upload the data to a server and obtain a URL, before attempting call = setup. A better approach would be to allow data known by the client to = be transmitted by the client as a MIME body part. In theory, this can = be done either in the call-setup (as a body part in the INVITE, similar = to how location-by-value is transmitted), or in a subsequent SIP method = after call setup. I suggest the latter, using SIP MESSAGE method for = this. Especially for telematics data, which could grow to be fairly = large, this seems useful. >=20 > New MIME subtypes can be registered, with whatever granularity we = want. For example, under the application subtype (or text, but I'm = leaning towards application), we can define subtypes for various forms = of additional-data for emergency calls, such as telematics, device-info, = etc. >=20 > --=20 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself = only > -------------- Randomly selected tag: --------------- > The trouble with the world is not that people know too little, but > that they know so many things that ain't so. > --Mark Twain > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Tue Mar 29 05:16:36 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87FCC3A67A8 for ; Tue, 29 Mar 2011 05:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1PfiazPIpVZ for ; Tue, 29 Mar 2011 05:16:35 -0700 (PDT) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by core3.amsl.com (Postfix) with ESMTP id A46F53A63CA for ; Tue, 29 Mar 2011 05:16:35 -0700 (PDT) X-ASG-Debug-ID: 1301401093-011a9f4f7b185f0001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id gv2jnZyjmDzqJKFp; Tue, 29 Mar 2011 05:18:13 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=ndont-61.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Q4Xs9-0002gT-B1; Tue, 29 Mar 2011 05:18:11 -0700 Mime-Version: 1.0 (Apple Message framework v1084) X-ASG-Orig-Subj: Re: [Ecrit] Fwd: New Version Notification for draft-rosen-ecrit-lost-return-li-00 Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <4128CD8B-2E13-45D9-B1FF-ABFEE5C2834F@bbn.com> Date: Tue, 29 Mar 2011 14:18:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110329112734.A0B623A681B@core3.amsl.com> <333B3219-AAF2-4A2F-9E3B-EB372D233164@brianrosen.net> <4128CD8B-2E13-45D9-B1FF-ABFEE5C2834F@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1084) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1301401093 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.59308 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Fwd: New Version Notification for draft-rosen-ecrit-lost-return-li-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:16:36 -0000 He sends LI when the input LI is invalid. This sends LI when the input = LI is valid. Brian On Mar 29, 2011, at 2:13 PM, Richard L. Barnes wrote: > How does this relate to Roger's "similar location" draft? > --Richard >=20 >=20 > On Mar 29, 2011, at 2:02 PM, Brian Rosen wrote: >=20 >> I have just submitted a new draft that does one simple thing: allow = location information to be returned in a , when = validation is requested, the LI in the request was valid, but the LoST = server knew more CAtypes for the location than were in the request. >>=20 >> A simple example is an address with a postal code, but without an A1, = A2 or A3 CAtypes. The LoST server may discover that it knows precisely = where the the LI is, but it would be helpful for the querier to get the = A1, A2 and A3 values back from the server. This allows the LoST sever = to return LI. >>=20 >> Please forgive the RELAX stuff. I am clueless, and need to find = someone to help me do it right. >>=20 >> Brian >>=20 >> Begin forwarded message: >>=20 >>> From: IETF I-D Submission Tool >>> Date: March 29, 2011 1:27:34 PM GMT+02:00 >>> To: br@brianrosen.net >>> Subject: New Version Notification for = draft-rosen-ecrit-lost-return-li-00=20 >>>=20 >>>=20 >>> A new version of I-D, draft-rosen-ecrit-lost-return-li-00.txt has = been successfully submitted by Brian Rosen and posted to the IETF = repository. >>>=20 >>> Filename: draft-rosen-ecrit-lost-return-li >>> Revision: 00 >>> Title: Returning a Location Information in a Location = to Service Translation query >>> Creation_date: 2011-03-29 >>> WG ID: Independent Submission >>> Number_of_pages: 7 >>>=20 >>> Abstract: >>> This document defines an extension to LoST (RFC5222) to permit a >>> location information to be returned in a findservice response. When >>> the validation is requested in the findservice request, the location >>> information supplied in the request may have enough valid address >>> components (CAtypes) to be considered valid, but the LoST server may >>> wish to return address components CAtypes not found in the query. >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat. >>>=20 >>>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From br@brianrosen.net Tue Mar 29 05:18:33 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3ACD3A67B0 for ; Tue, 29 Mar 2011 05:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgUTpGdrHfJe for ; Tue, 29 Mar 2011 05:18:30 -0700 (PDT) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by core3.amsl.com (Postfix) with ESMTP id 65E723A63CA for ; Tue, 29 Mar 2011 05:18:30 -0700 (PDT) X-ASG-Debug-ID: 1301401207-011a9f4f7918790001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id 9lHrNJpskppbR61y; Tue, 29 Mar 2011 05:20:07 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=ndont-61.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Q4Xu1-0003lm-5F; Tue, 29 Mar 2011 05:20:07 -0700 Mime-Version: 1.0 (Apple Message framework v1084) X-ASG-Orig-Subj: Re: [Ecrit] Fwd: New Version Notification for draft-rosen-ecrit-lost-return-li-00 Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <4128CD8B-2E13-45D9-B1FF-ABFEE5C2834F@bbn.com> Date: Tue, 29 Mar 2011 14:19:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110329112734.A0B623A681B@core3.amsl.com> <333B3219-AAF2-4A2F-9E3B-EB372D233164@brianrosen.net> <4128CD8B-2E13-45D9-B1FF-ABFEE5C2834F@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1084) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1301401207 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.59308 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Fwd: New Version Notification for draft-rosen-ecrit-lost-return-li-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:18:33 -0000 Also, his may have one or more CAtypes that are different from the input = LI. Brian On Mar 29, 2011, at 2:13 PM, Richard L. Barnes wrote: > How does this relate to Roger's "similar location" draft? > --Richard >=20 >=20 > On Mar 29, 2011, at 2:02 PM, Brian Rosen wrote: >=20 >> I have just submitted a new draft that does one simple thing: allow = location information to be returned in a , when = validation is requested, the LI in the request was valid, but the LoST = server knew more CAtypes for the location than were in the request. >>=20 >> A simple example is an address with a postal code, but without an A1, = A2 or A3 CAtypes. The LoST server may discover that it knows precisely = where the the LI is, but it would be helpful for the querier to get the = A1, A2 and A3 values back from the server. This allows the LoST sever = to return LI. >>=20 >> Please forgive the RELAX stuff. I am clueless, and need to find = someone to help me do it right. >>=20 >> Brian >>=20 >> Begin forwarded message: >>=20 >>> From: IETF I-D Submission Tool >>> Date: March 29, 2011 1:27:34 PM GMT+02:00 >>> To: br@brianrosen.net >>> Subject: New Version Notification for = draft-rosen-ecrit-lost-return-li-00=20 >>>=20 >>>=20 >>> A new version of I-D, draft-rosen-ecrit-lost-return-li-00.txt has = been successfully submitted by Brian Rosen and posted to the IETF = repository. >>>=20 >>> Filename: draft-rosen-ecrit-lost-return-li >>> Revision: 00 >>> Title: Returning a Location Information in a Location = to Service Translation query >>> Creation_date: 2011-03-29 >>> WG ID: Independent Submission >>> Number_of_pages: 7 >>>=20 >>> Abstract: >>> This document defines an extension to LoST (RFC5222) to permit a >>> location information to be returned in a findservice response. When >>> the validation is requested in the findservice request, the location >>> information supplied in the request may have enough valid address >>> components (CAtypes) to be considered valid, but the LoST server may >>> wish to return address components CAtypes not found in the query. >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat. >>>=20 >>>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From rbarnes@bbn.com Tue Mar 29 05:20:02 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58A2C3A67B6 for ; Tue, 29 Mar 2011 05:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyje3bl9TC7c for ; Tue, 29 Mar 2011 05:20:01 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 035F93A63CA for ; Tue, 29 Mar 2011 05:20:01 -0700 (PDT) Received: from [128.89.255.96] (port=53976 helo=[130.129.17.55]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Q4XvW-0004rX-Rw; Tue, 29 Mar 2011 08:21:39 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Tue, 29 Mar 2011 14:21:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <13701B78-7BF0-4A82-BA86-55ADBE41C736@bbn.com> References: <20110329112734.A0B623A681B@core3.amsl.com> <333B3219-AAF2-4A2F-9E3B-EB372D233164@brianrosen.net> <4128CD8B-2E13-45D9-B1FF-ABFEE5C2834F@bbn.com> To: Brian Rosen X-Mailer: Apple Mail (2.1082) Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Fwd: New Version Notification for draft-rosen-ecrit-lost-return-li-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:20:02 -0000 So couldn't we just merge the two and send LI the same way regardless? = Maybe with a tag to say whether the input LI is valid or not? --Richard On Mar 29, 2011, at 2:18 PM, Brian Rosen wrote: > He sends LI when the input LI is invalid. This sends LI when the = input LI is valid. >=20 > Brian >=20 > On Mar 29, 2011, at 2:13 PM, Richard L. Barnes wrote: >=20 >> How does this relate to Roger's "similar location" draft? >> --Richard >>=20 >>=20 >> On Mar 29, 2011, at 2:02 PM, Brian Rosen wrote: >>=20 >>> I have just submitted a new draft that does one simple thing: allow = location information to be returned in a , when = validation is requested, the LI in the request was valid, but the LoST = server knew more CAtypes for the location than were in the request. >>>=20 >>> A simple example is an address with a postal code, but without an = A1, A2 or A3 CAtypes. The LoST server may discover that it knows = precisely where the the LI is, but it would be helpful for the querier = to get the A1, A2 and A3 values back from the server. This allows the = LoST sever to return LI. >>>=20 >>> Please forgive the RELAX stuff. I am clueless, and need to find = someone to help me do it right. >>>=20 >>> Brian >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: IETF I-D Submission Tool >>>> Date: March 29, 2011 1:27:34 PM GMT+02:00 >>>> To: br@brianrosen.net >>>> Subject: New Version Notification for = draft-rosen-ecrit-lost-return-li-00=20 >>>>=20 >>>>=20 >>>> A new version of I-D, draft-rosen-ecrit-lost-return-li-00.txt has = been successfully submitted by Brian Rosen and posted to the IETF = repository. >>>>=20 >>>> Filename: draft-rosen-ecrit-lost-return-li >>>> Revision: 00 >>>> Title: Returning a Location Information in a Location = to Service Translation query >>>> Creation_date: 2011-03-29 >>>> WG ID: Independent Submission >>>> Number_of_pages: 7 >>>>=20 >>>> Abstract: >>>> This document defines an extension to LoST (RFC5222) to permit a >>>> location information to be returned in a findservice response. = When >>>> the validation is requested in the findservice request, the = location >>>> information supplied in the request may have enough valid address >>>> components (CAtypes) to be considered valid, but the LoST server = may >>>> wish to return address components CAtypes not found in the query. >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat. >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 From James.Winterbottom@commscope.com Tue Mar 29 05:21:26 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 798CE3A6783 for ; Tue, 29 Mar 2011 05:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4Zhe3QEzefm for ; Tue, 29 Mar 2011 05:21:25 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id 43E4B3A63CA for ; Tue, 29 Mar 2011 05:21:25 -0700 (PDT) X-AuditID: 0a0404e9-b7c0fae000001e9f-36-4d91cf274ec0 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id E6.82.07839.72FC19D4; Tue, 29 Mar 2011 07:23:03 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Tue, 29 Mar 2011 07:23:02 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 29 Mar 2011 20:22:58 +0800 From: "Winterbottom, James" To: Randall Gellens , Brian Rosen , ECRIT Date: Tue, 29 Mar 2011 20:22:56 +0800 Thread-Topic: [Ecrit] Client-known vs. server-known data in draft-ietf-ecrit-additional-data Thread-Index: AcvuCmBxgeNWIQfzSZKg6mblcTOR1QAANpbw Message-ID: <5A55A45AE77F5941B18E5457ECAC81880121022577F8@SISPE7MB1.commscope.com> References: <8C2A715A-2F04-445E-B511-392F434F515F@cisco.com> <4163F28B-4861-4E94-9751-099AE3AE3DAC@brianrosen.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] Client-known vs. server-known data in draft-ietf-ecrit-additional-data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:21:26 -0000 I see a couple of problems with the statements below. Firstly, there are several classification of server that can provide additi= onal data, and not all are directly in the call path or necessarily communi= cate using SIP, so inserting a URI into a SIP header isn't a ubiquitous sol= ution. I also think that quite a lot of "device-knows" data as being quite sensiti= ve. If this is sent in a MIME body, we to make sure that nothing that shoul= d be able to have it can have it, and that include all the SIP intermediari= es along the way to the thing that is finally entitled to have it. This was= one of the reasons for using HTTPS and having registries in which this dat= a was placed. Cheers James > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Randall Gellens > Sent: Tuesday, 29 March 2011 11:07 PM > To: Brian Rosen; ECRIT > Subject: [Ecrit] Client-known vs. server-known data in draft-ietf-ecrit- > additional-data >=20 > As discussed in today's meeting, I think it's useful to consider two > broad categories of additional data: that which is known by a server, > and that which only the device knows. >=20 > If the server knows the data, then the mechanism in the draft > (inserting an HTTPS URI into a Call-Info header) is fine. But if > only the device knows the data, this mechanism requires the device to > first upload the data to a server and obtain a URL, before attempting > call setup. A better approach would be to allow data known by the > client to be transmitted by the client as a MIME body part. In > theory, this can be done either in the call-setup (as a body part in > the INVITE, similar to how location-by-value is transmitted), or in a > subsequent SIP method after call setup. I suggest the latter, using > SIP MESSAGE method for this. Especially for telematics data, which > could grow to be fairly large, this seems useful. >=20 > New MIME subtypes can be registered, with whatever granularity we > want. For example, under the application subtype (or text, but I'm > leaning towards application), we can define subtypes for various > forms of additional-data for emergency calls, such as telematics, > device-info, etc. >=20 > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > The trouble with the world is not that people know too little, but > that they know so many things that ain't so. > --Mark Twain > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Tue Mar 29 05:29:13 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBEC23A6868 for ; Tue, 29 Mar 2011 05:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yT9-eylOX8Sp for ; Tue, 29 Mar 2011 05:29:11 -0700 (PDT) Received: from barmail5.idig.net (barmail5.idig.net [64.34.111.236]) by core3.amsl.com (Postfix) with ESMTP id 8FE653A6874 for ; Tue, 29 Mar 2011 05:29:10 -0700 (PDT) X-ASG-Debug-ID: 1301401846-00f27e0a9f0fb70001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail5.idig.net with ESMTP id 0z9N9BTiqNswvLR2; Tue, 29 Mar 2011 05:30:46 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=ndont-61.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Q4Y4J-00086k-Fa; Tue, 29 Mar 2011 05:30:45 -0700 Mime-Version: 1.0 (Apple Message framework v1084) X-ASG-Orig-Subj: Re: [Ecrit] Fwd: New Version Notification for draft-rosen-ecrit-lost-return-li-00 Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <13701B78-7BF0-4A82-BA86-55ADBE41C736@bbn.com> Date: Tue, 29 Mar 2011 14:30:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110329112734.A0B623A681B@core3.amsl.com> <333B3219-AAF2-4A2F-9E3B-EB372D233164@brianrosen.net> <4128CD8B-2E13-45D9-B1FF-ABFEE5C2834F@bbn.com> <13701B78-7BF0-4A82-BA86-55ADBE41C736@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1084) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1301401846 X-Barracuda-URL: http://64.34.111.236:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.59309 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Fwd: New Version Notification for draft-rosen-ecrit-lost-return-li-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:29:13 -0000 The thought occurred to me. You get the validity tag already. They = really are different things, but it terms of extensions, it's very close = (adding LI in the findserviceresponse). Brian On Mar 29, 2011, at 2:21 PM, Richard L. Barnes wrote: > So couldn't we just merge the two and send LI the same way regardless? = Maybe with a tag to say whether the input LI is valid or not? > --Richard >=20 >=20 > On Mar 29, 2011, at 2:18 PM, Brian Rosen wrote: >=20 >> He sends LI when the input LI is invalid. This sends LI when the = input LI is valid. >>=20 >> Brian >>=20 >> On Mar 29, 2011, at 2:13 PM, Richard L. Barnes wrote: >>=20 >>> How does this relate to Roger's "similar location" draft? >>> --Richard >>>=20 >>>=20 >>> On Mar 29, 2011, at 2:02 PM, Brian Rosen wrote: >>>=20 >>>> I have just submitted a new draft that does one simple thing: allow = location information to be returned in a , when = validation is requested, the LI in the request was valid, but the LoST = server knew more CAtypes for the location than were in the request. >>>>=20 >>>> A simple example is an address with a postal code, but without an = A1, A2 or A3 CAtypes. The LoST server may discover that it knows = precisely where the the LI is, but it would be helpful for the querier = to get the A1, A2 and A3 values back from the server. This allows the = LoST sever to return LI. >>>>=20 >>>> Please forgive the RELAX stuff. I am clueless, and need to find = someone to help me do it right. >>>>=20 >>>> Brian >>>>=20 >>>> Begin forwarded message: >>>>=20 >>>>> From: IETF I-D Submission Tool >>>>> Date: March 29, 2011 1:27:34 PM GMT+02:00 >>>>> To: br@brianrosen.net >>>>> Subject: New Version Notification for = draft-rosen-ecrit-lost-return-li-00=20 >>>>>=20 >>>>>=20 >>>>> A new version of I-D, draft-rosen-ecrit-lost-return-li-00.txt has = been successfully submitted by Brian Rosen and posted to the IETF = repository. >>>>>=20 >>>>> Filename: draft-rosen-ecrit-lost-return-li >>>>> Revision: 00 >>>>> Title: Returning a Location Information in a Location = to Service Translation query >>>>> Creation_date: 2011-03-29 >>>>> WG ID: Independent Submission >>>>> Number_of_pages: 7 >>>>>=20 >>>>> Abstract: >>>>> This document defines an extension to LoST (RFC5222) to permit a >>>>> location information to be returned in a findservice response. = When >>>>> the validation is requested in the findservice request, the = location >>>>> information supplied in the request may have enough valid address >>>>> components (CAtypes) to be considered valid, but the LoST server = may >>>>> wish to return address components CAtypes not found in the query. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> The IETF Secretariat. >>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>=20 >=20 From Martin.Thomson@commscope.com Tue Mar 29 07:48:22 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CB6A3A682B for ; Tue, 29 Mar 2011 07:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.073 X-Spam-Level: X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xL3xvILPzGb0 for ; Tue, 29 Mar 2011 07:48:21 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id D0ED03A67D3 for ; Tue, 29 Mar 2011 07:48:18 -0700 (PDT) X-AuditID: 0a0404e9-b7c0fae000001e9f-f3-4d91f194736c Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id C2.59.07839.491F19D4; Tue, 29 Mar 2011 09:49:56 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Tue, 29 Mar 2011 09:49:56 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 29 Mar 2011 22:49:53 +0800 From: "Thomson, Martin" To: Brian Rosen , Richard L.Barnes Date: Tue, 29 Mar 2011 22:49:51 +0800 Thread-Topic: [Ecrit] Fwd: New Version Notification for draft-rosen-ecrit-lost-return-li-00 Thread-Index: AcvuDSuXZlHYvKuxTUyRmjY1Uf5YbQAE01zg Message-ID: <8B0A9FCBB9832F43971E38010638454F04027B9496@SISPE7MB1.commscope.com> References: <20110329112734.A0B623A681B@core3.amsl.com> <333B3219-AAF2-4A2F-9E3B-EB372D233164@brianrosen.net> <4128CD8B-2E13-45D9-B1FF-ABFEE5C2834F@bbn.com> <13701B78-7BF0-4A82-BA86-55ADBE41C736@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Fwd: New Version Notification for draft-rosen-ecrit-lost-return-li-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 14:48:22 -0000 I think that you could probably merge the two even if they aren't precisely= the same thing. On 2011-03-29 at 14:30:36, Brian Rosen wrote: > The thought occurred to me. You get the validity tag already. They=20 > really are different things, but it terms of extensions, it's very=20 > close (adding LI in the findserviceresponse). >=20 > Brian >=20 > On Mar 29, 2011, at 2:21 PM, Richard L. Barnes wrote: >=20 > > So couldn't we just merge the two and send LI the same way > regardless? Maybe with a tag to say whether the input LI is valid or=20 > not? > > --Richard > > > > > > On Mar 29, 2011, at 2:18 PM, Brian Rosen wrote: > > > >> He sends LI when the input LI is invalid. This sends LI when the > input LI is valid. > >> > >> Brian > >> > >> On Mar 29, 2011, at 2:13 PM, Richard L. Barnes wrote: > >> > >>> How does this relate to Roger's "similar location" draft? > >>> --Richard > >>> > >>> > >>> On Mar 29, 2011, at 2:02 PM, Brian Rosen wrote: > >>> > >>>> I have just submitted a new draft that does one simple thing: > allow location information to be returned in a ,=20 > when validation is requested, the LI in the request was valid, but the=20 > LoST server knew more CAtypes for the location than were in the=20 > request. > >>>> > >>>> A simple example is an address with a postal code, but without an > A1, A2 or A3 CAtypes. The LoST server may discover that it knows=20 > precisely where the the LI is, but it would be helpful for the querier=20 > to get the A1, A2 and A3 values back from the server. This allows the=20 > LoST sever to return LI. > >>>> > >>>> Please forgive the RELAX stuff. I am clueless, and need to find > someone to help me do it right. > >>>> > >>>> Brian > >>>> > >>>> Begin forwarded message: > >>>> > >>>>> From: IETF I-D Submission Tool > >>>>> Date: March 29, 2011 1:27:34 PM GMT+02:00 > >>>>> To: br@brianrosen.net > >>>>> Subject: New Version Notification for=20 > >>>>> draft-rosen-ecrit-lost-return-li-00 > >>>>> > >>>>> > >>>>> A new version of I-D, draft-rosen-ecrit-lost-return-li-00.txt=20 > >>>>> has > been successfully submitted by Brian Rosen and posted to the IETF=20 > repository. > >>>>> > >>>>> Filename: draft-rosen-ecrit-lost-return-li > >>>>> Revision: 00 > >>>>> Title: Returning a Location Information in a Location > to Service Translation query > >>>>> Creation_date: 2011-03-29 > >>>>> WG ID: Independent Submission > >>>>> Number_of_pages: 7 > >>>>> > >>>>> Abstract: > >>>>> This document defines an extension to LoST (RFC5222) to permit a=20 > >>>>> location information to be returned in a findservice response. > >>>>> When the validation is requested in the findservice request, the=20 > >>>>> location information supplied in the request may have enough > valid > >>>>> address components (CAtypes) to be considered valid, but the=20 > >>>>> LoST server may wish to return address components CAtypes not=20 > >>>>> found in > the query. > >>>>> > >>>>> > >>>>> > >>>>> The IETF Secretariat. > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ecrit > >>> > >> > > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From Martin.Thomson@commscope.com Tue Mar 29 07:52:08 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C39953A682B for ; Tue, 29 Mar 2011 07:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.051 X-Spam-Level: X-Spam-Status: No, score=-3.051 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmFr0Dmh-7-w for ; Tue, 29 Mar 2011 07:52:07 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id C80963A67AB for ; Tue, 29 Mar 2011 07:52:07 -0700 (PDT) X-AuditID: 0a0404e8-b7bd2ae0000014c1-bc-4d91f2790308 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id F1.E5.05313.972F19D4; Tue, 29 Mar 2011 09:53:46 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Tue, 29 Mar 2011 09:53:44 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 29 Mar 2011 22:53:33 +0800 From: "Thomson, Martin" To: "Winterbottom, James" , Randall Gellens , Brian Rosen , ECRIT Date: Tue, 29 Mar 2011 22:53:31 +0800 Thread-Topic: [Ecrit] Client-known vs. server-known data in draft-ietf-ecrit-additional-data Thread-Index: AcvuCmBxgeNWIQfzSZKg6mblcTOR1QAANpbwAAVmo3A= Message-ID: <8B0A9FCBB9832F43971E38010638454F04027B9498@SISPE7MB1.commscope.com> References: <8C2A715A-2F04-445E-B511-392F434F515F@cisco.com> <4163F28B-4861-4E94-9751-099AE3AE3DAC@brianrosen.net> <5A55A45AE77F5941B18E5457ECAC81880121022577F8@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880121022577F8@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] Client-known vs. server-known data in draft-ietf-ecrit-additional-data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 14:52:08 -0000 The statement that the device needs to upload the data is only a problem fo= r the data that is only pertinent/generated at call time. Some of this dat= a (in fact a goodly portion of it) is fairly static and it can be establish= ed ahead of the call, probably LONG ahead. On 2011-03-29 at 14:22:56, Winterbottom, James wrote: > I see a couple of problems with the statements below. > Firstly, there are several classification of server that can provide=20 > additional data, and not all are directly in the call path or=20 > necessarily communicate using SIP, so inserting a URI into a SIP=20 > header isn't a ubiquitous solution. >=20 > I also think that quite a lot of "device-knows" data as being quite=20 > sensitive. If this is sent in a MIME body, we to make sure that=20 > nothing that should be able to have it can have it, and that include=20 > all the SIP intermediaries along the way to the thing that is finally=20 > entitled to have it. This was one of the reasons for using HTTPS and=20 > having registries in which this data was placed. >=20 > Cheers > James >=20 >=20 >=20 > > -----Original Message----- > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On > Behalf > > Of Randall Gellens > > Sent: Tuesday, 29 March 2011 11:07 PM > > To: Brian Rosen; ECRIT > > Subject: [Ecrit] Client-known vs. server-known data in > > draft-ietf-ecrit- additional-data > > > > As discussed in today's meeting, I think it's useful to consider two=20 > > broad categories of additional data: that which is known by a=20 > > server, and that which only the device knows. > > > > If the server knows the data, then the mechanism in the draft=20 > > (inserting an HTTPS URI into a Call-Info header) is fine. But if > only > > the device knows the data, this mechanism requires the device to > first > > upload the data to a server and obtain a URL, before attempting call=20 > > setup. A better approach would be to allow data known by the client=20 > > to be transmitted by the client as a MIME body part. In theory,=20 > > this can be done either in the call-setup (as a body part in the=20 > > INVITE, similar to how location-by-value is transmitted), or in a=20 > > subsequent SIP method after call setup. I suggest the latter, using=20 > > SIP MESSAGE method for this. Especially for telematics data, which=20 > > could grow to be fairly large, this seems useful. > > > > New MIME subtypes can be registered, with whatever granularity we=20 > > want. For example, under the application subtype (or text, but I'm=20 > > leaning towards application), we can define subtypes for various > forms > > of additional-data for emergency calls, such as telematics,=20 > > device-info, etc. > > > > -- > > Randall Gellens > > Opinions are personal; facts are suspect; I speak for myself > only > > -------------- Randomly selected tag: --------------- The trouble > with > > the world is not that people know too little, but that they know so=20 > > many things that ain't so. > > --Mark Twain > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From br@brianrosen.net Tue Mar 29 07:52:22 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74F773A6927 for ; Tue, 29 Mar 2011 07:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eo1zSTf2Q7B1 for ; Tue, 29 Mar 2011 07:52:21 -0700 (PDT) Received: from barmail5.idig.net (barmail5.idig.net [64.34.111.236]) by core3.amsl.com (Postfix) with ESMTP id 330E93A6921 for ; Tue, 29 Mar 2011 07:52:21 -0700 (PDT) X-ASG-Debug-ID: 1301410435-00f27e0aa218060001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail5.idig.net with ESMTP id 7MYJ18r78FUilESJ; Tue, 29 Mar 2011 07:53:55 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=ndont-61.cis.neustar.com) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Q4aIp-0005ST-9A; Tue, 29 Mar 2011 07:53:54 -0700 Mime-Version: 1.0 (Apple Message framework v1084) X-ASG-Orig-Subj: Re: [Ecrit] Fwd: New Version Notification for draft-rosen-ecrit-lost-return-li-00 Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <8B0A9FCBB9832F43971E38010638454F04027B9496@SISPE7MB1.commscope.com> Date: Tue, 29 Mar 2011 16:53:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110329112734.A0B623A681B@core3.amsl.com> <333B3219-AAF2-4A2F-9E3B-EB372D233164@brianrosen.net> <4128CD8B-2E13-45D9-B1FF-ABFEE5C2834F@bbn.com> <13701B78-7BF0-4A82-BA86-55ADBE41C736@bbn.com> <8B0A9FCBB9832F43971E38010638454F04027B9496@SISPE7MB1.commscope.com> To: "Thomson, Martin" X-Mailer: Apple Mail (2.1084) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1301410435 X-Barracuda-URL: http://64.34.111.236:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.59319 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "ecrit@ietf.org Org" Subject: Re: [Ecrit] Fwd: New Version Notification for draft-rosen-ecrit-lost-return-li-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 14:52:22 -0000 Authors have concluded merging makes sense.=20 Brian On Mar 29, 2011, at 4:49 PM, Thomson, Martin wrote: > I think that you could probably merge the two even if they aren't = precisely the same thing. >=20 > On 2011-03-29 at 14:30:36, Brian Rosen wrote: >> The thought occurred to me. You get the validity tag already. They=20= >> really are different things, but it terms of extensions, it's very=20 >> close (adding LI in the findserviceresponse). >>=20 >> Brian >>=20 >> On Mar 29, 2011, at 2:21 PM, Richard L. Barnes wrote: >>=20 >>> So couldn't we just merge the two and send LI the same way >> regardless? Maybe with a tag to say whether the input LI is valid or=20= >> not? >>> --Richard >>>=20 >>>=20 >>> On Mar 29, 2011, at 2:18 PM, Brian Rosen wrote: >>>=20 >>>> He sends LI when the input LI is invalid. This sends LI when the >> input LI is valid. >>>>=20 >>>> Brian >>>>=20 >>>> On Mar 29, 2011, at 2:13 PM, Richard L. Barnes wrote: >>>>=20 >>>>> How does this relate to Roger's "similar location" draft? >>>>> --Richard >>>>>=20 >>>>>=20 >>>>> On Mar 29, 2011, at 2:02 PM, Brian Rosen wrote: >>>>>=20 >>>>>> I have just submitted a new draft that does one simple thing: >> allow location information to be returned in a ,=20= >> when validation is requested, the LI in the request was valid, but = the=20 >> LoST server knew more CAtypes for the location than were in the=20 >> request. >>>>>>=20 >>>>>> A simple example is an address with a postal code, but without an >> A1, A2 or A3 CAtypes. The LoST server may discover that it knows=20 >> precisely where the the LI is, but it would be helpful for the = querier=20 >> to get the A1, A2 and A3 values back from the server. This allows = the=20 >> LoST sever to return LI. >>>>>>=20 >>>>>> Please forgive the RELAX stuff. I am clueless, and need to find >> someone to help me do it right. >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> Begin forwarded message: >>>>>>=20 >>>>>>> From: IETF I-D Submission Tool >>>>>>> Date: March 29, 2011 1:27:34 PM GMT+02:00 >>>>>>> To: br@brianrosen.net >>>>>>> Subject: New Version Notification for=20 >>>>>>> draft-rosen-ecrit-lost-return-li-00 >>>>>>>=20 >>>>>>>=20 >>>>>>> A new version of I-D, draft-rosen-ecrit-lost-return-li-00.txt=20 >>>>>>> has >> been successfully submitted by Brian Rosen and posted to the IETF=20 >> repository. >>>>>>>=20 >>>>>>> Filename: draft-rosen-ecrit-lost-return-li >>>>>>> Revision: 00 >>>>>>> Title: Returning a Location Information in a Location >> to Service Translation query >>>>>>> Creation_date: 2011-03-29 >>>>>>> WG ID: Independent Submission >>>>>>> Number_of_pages: 7 >>>>>>>=20 >>>>>>> Abstract: >>>>>>> This document defines an extension to LoST (RFC5222) to permit a=20= >>>>>>> location information to be returned in a findservice response. >>>>>>> When the validation is requested in the findservice request, the=20= >>>>>>> location information supplied in the request may have enough >> valid >>>>>>> address components (CAtypes) to be considered valid, but the=20 >>>>>>> LoST server may wish to return address components CAtypes not=20 >>>>>>> found in >> the query. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> The IETF Secretariat. >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 From Martin.Thomson@commscope.com Tue Mar 29 07:53:15 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 956823A682B for ; Tue, 29 Mar 2011 07:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.032 X-Spam-Level: X-Spam-Status: No, score=-3.032 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDEG+0n9FI4s for ; Tue, 29 Mar 2011 07:53:14 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by core3.amsl.com (Postfix) with ESMTP id 479803A67AB for ; Tue, 29 Mar 2011 07:53:14 -0700 (PDT) X-AuditID: 0a0404e9-b7c0fae000001e9f-e6-4d91f2bc0fef Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 08.89.07839.CB2F19D4; Tue, 29 Mar 2011 09:54:52 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Tue, 29 Mar 2011 09:54:52 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 29 Mar 2011 22:54:48 +0800 From: "Thomson, Martin" To: Brian Rosen , Randall Gellens Date: Tue, 29 Mar 2011 22:54:46 +0800 Thread-Topic: [Ecrit] Client-known vs. server-known data in draft-ietf-ecrit-additional-data Thread-Index: AcvuC019M7OuMds7Taue0/DgXelpXwAFdcQg Message-ID: <8B0A9FCBB9832F43971E38010638454F04027B9499@SISPE7MB1.commscope.com> References: <8C2A715A-2F04-445E-B511-392F434F515F@cisco.com> <4163F28B-4861-4E94-9751-099AE3AE3DAC@brianrosen.net> <33D2DD54-77E2-4F21-8D1F-8A22963D1D09@brianrosen.net> In-Reply-To: <33D2DD54-77E2-4F21-8D1F-8A22963D1D09@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: ECRIT Subject: Re: [Ecrit] Client-known vs. server-known data in draft-ietf-ecrit-additional-data X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 14:53:15 -0000 Bingo. Just what I was thinking. How the information is included will dep= end on the dynamics of the data. On 2011-03-29 at 14:17:04, Brian Rosen wrote: > Subject to what Martin is thinking, I was imagining that in both the=20 > Call Info header and the hook where telematics info goes could be a=20 > CID, which could be found in the body. >=20 > Brian >=20 > On Mar 29, 2011, at 2:07 PM, Randall Gellens wrote: >=20 > > As discussed in today's meeting, I think it's useful to consider two > broad categories of additional data: that which is known by a server,=20 > and that which only the device knows. > > > > If the server knows the data, then the mechanism in the draft > (inserting an HTTPS URI into a Call-Info header) is fine. But if only=20 > the device knows the data, this mechanism requires the device to first=20 > upload the data to a server and obtain a URL, before attempting call=20 > setup. A better approach would be to allow data known by the client=20 > to be transmitted by the client as a MIME body part. In theory, this=20 > can be done either in the call-setup (as a body part in the INVITE,=20 > similar to how location-by-value is transmitted), or in a subsequent=20 > SIP method after call setup. I suggest the latter, using SIP MESSAGE=20 > method for this. Especially for telematics data, which could grow to=20 > be fairly large, this seems useful. > > > > New MIME subtypes can be registered, with whatever granularity we > want. For example, under the application subtype (or text, but I'm=20 > leaning towards application), we can define subtypes for various forms=20 > of additional-data for emergency calls, such as telematics, device-=20 > info, etc. > > > > -- > > Randall Gellens > > Opinions are personal; facts are suspect; I speak for myself > only > > -------------- Randomly selected tag: --------------- The trouble > with > > the world is not that people know too little, but that they know so=20 > > many things that ain't so. > > --Mark Twain >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From Internet-Drafts@ietf.org Tue Mar 29 12:00:02 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A76473A6A1E; Tue, 29 Mar 2011 12:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5iCMOYCayzZ; Tue, 29 Mar 2011 12:00:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B34763A68E7; Tue, 29 Mar 2011 12:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110329190001.8357.90314.idtracker@localhost> Date: Tue, 29 Mar 2011 12:00:01 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-unauthenticated-access-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 19:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices Author(s) : H. Schulzrinne, et al. Filename : draft-ietf-ecrit-unauthenticated-access-02.txt Pages : 27 Date : 2011-03-29 The IETF emergency services architecture assumes that the calling device has acquired rights to use the access network or that no authentication is required for the access network, such as for public wireless access points. Subsequent protocol interactions, such as obtaining location information, learning the address of the Public Safety Answering Point (PSAP) and the emergency call itself are largely decoupled from the underlying network access procedures. In some cases, however, the device does not have these credentials for network access, does not have a VoIP service provider, or the credentials have become invalid, e.g., because the user has exhausted their prepaid balance or the account has expired. This document provides a problem statement, introduces terminology and describes an extension for the base IETF emergency services architecture to address these scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-unauthenticated-access-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-unauthenticated-access-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-29114738.I-D@ietf.org> --NextPart-- From mlinsner@cisco.com Wed Mar 30 01:22:36 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04F703A6AFD for ; Wed, 30 Mar 2011 01:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.377 X-Spam-Level: X-Spam-Status: No, score=-9.377 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPESKvFQocIH for ; Wed, 30 Mar 2011 01:22:34 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B76393A6B0E for ; Wed, 30 Mar 2011 01:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=3570; q=dns/txt; s=iport; t=1301473453; x=1302683053; h=date:subject:from:to:message-id:mime-version; bh=lgCmcWChVfe4uTC93F+Q02H2oWyScGYRkCbe/JZ7SJI=; b=hKFkJkB5kFJ7jGhCxhjNUpCcySuueZugG7RhsRabverJWP7FnEKc4vY+ 518uoHPGjxmt2jeBq5WNlvcTlk2+Yj2abbyAahNo8qjktxVtYbKGnvAL9 cV5dcXS/8UqDZJgWsw/j0ti5XmY1PIvkbdyQtn2nWRdQ5PRx0S/gjJyBU o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsGAJHnkk2rRDoH/2dsb2JhbACCXpt6AYYYW3egZZxNhWoEjQaDVQ X-IronPort-AV: E=Sophos;i="4.63,267,1299456000"; d="scan'208,217";a="327268518" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 30 Mar 2011 08:24:13 +0000 Received: from [130.129.68.179] (sjc-vpn7-183.cisco.com [10.21.144.183]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2U8OB4i008347 for ; Wed, 30 Mar 2011 08:24:12 GMT User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Wed, 30 Mar 2011 10:24:10 +0200 From: Marc Linsner To: "ecrit@ietf.org" Message-ID: Thread-Topic: WGLC - draft-ietf-ecrit-rough-loc-04 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3384325453_303469" Subject: [Ecrit] WGLC - draft-ietf-ecrit-rough-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 08:22:36 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3384325453_303469 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit This message starts the Working Group Last Call for draft "Using Imprecise Location for Emergency Call Routing" (http://tools.ietf.org/html/draft-ietf-ecrit-rough-loc-04). This draft fulfills the WG milestone: Nov 2010Submit 'Using Imprecise Location for Emergency Call Routing' to the IESG for consideration as an Informational RFC Please submit comments to the list by COB on Friday April 15, 2011. Thanks, -Marc Linsner- --B_3384325453_303469 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
This message starts the Working Group Last Call for draft "Usin= g Imprecise Location for Emergency Call Routing"  (http://tools.ietf.org/html/dr= aft-ietf-ecrit-rough-loc-04).

This draft fulfills the WG milestone:<= /span>
Nov 2010Submit 'Using Imprecise Locati= on for Emergency Call Routing' to the IESG for consideration as an Informati= onal RFC

Please submit comments to the = list by COB on Friday April 15, 2011.

Thanks,

-Marc Linsner-
--B_3384325453_303469-- From mlinsner@cisco.com Wed Mar 30 01:35:05 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5365F3A6969 for ; Wed, 30 Mar 2011 01:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.342 X-Spam-Level: X-Spam-Status: No, score=-9.342 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmWnHSiek39C for ; Wed, 30 Mar 2011 01:35:01 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 9A22E3A6919 for ; Wed, 30 Mar 2011 01:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=1184; q=dns/txt; s=iport; t=1301474200; x=1302683800; h=date:subject:from:to:message-id:mime-version; bh=6BzdBvX+z2OxBNB80rlYlSNkStvyKOFBRvAgBhTHGDQ=; b=IitS3SGGOv4necYFAQpV+AbR0iZa6sAuTm9jwtmxAIOjX8KjN1CanYUm 1O8UHE2jQ8/opmITEZQ7KcAlAa3UsayWSsLWSk4gqW1RpqBvhOxcT31su H27Csms3hMwFZOebKoRtSXxvSy2l90TJxbjGIAs81V7lx0RG7iF5mdyGD Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABXrkk2rRDoJ/2dsb2JhbACCXqITW3egaZxOhWoEjQaDVQ X-IronPort-AV: E=Sophos;i="4.63,267,1299456000"; d="scan'208,217";a="327274120" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 30 Mar 2011 08:36:40 +0000 Received: from [130.129.68.179] (sjc-vpn7-183.cisco.com [10.21.144.183]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2U8aadm029647 for ; Wed, 30 Mar 2011 08:36:39 GMT User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Wed, 30 Mar 2011 10:36:35 +0200 From: Marc Linsner To: "ecrit@ietf.org" Message-ID: Thread-Topic: draft-ietf-ecrit-rough-loc-04 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3384326199_313527" Subject: [Ecrit] draft-ietf-ecrit-rough-loc-04 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 08:35:05 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3384326199_313527 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Richard, Matt, The WG milestone for this draft is 'Informational', but the draft states intended status as 'Standards Track'. Please refresh my memory on the WG intentions for this draft=8A. Thanks, -Marc- --B_3384326199_313527 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Richard, Matt,
The WG milestone for this draft is 'Informational', but the draf= t states intended status as 'Standards Track'.

Plea= se refresh my memory on the WG intentions for this draft….
<= br>
Thanks,

-Marc-
--B_3384326199_313527-- From Hannes.Tschofenig@gmx.net Wed Mar 30 04:09:35 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3F3028C147 for ; Wed, 30 Mar 2011 04:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKijBzMbMhbz for ; Wed, 30 Mar 2011 04:09:35 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 7B3E63A6947 for ; Wed, 30 Mar 2011 04:09:34 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2011 11:11:12 -0000 Received: from dhcp-924f.meeting.ietf.org (EHLO dhcp-924f.meeting.ietf.org) [130.129.10.79] by mail.gmx.net (mp022) with SMTP; 30 Mar 2011 13:11:12 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18rQPkU7xUrOCAkyKRh7nPmzoIj65kJ2AHYTVihXN qkPL7Sz9GZkvWX From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Mar 2011 13:11:10 +0200 Message-Id: To: ecrit Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [Ecrit] Unauthenticated Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 11:09:35 -0000 I worked with Gabor on the draft update based on today's feedback.=20 Please find the updated draft here:=20 = http://www.ietf.org/internet-drafts/draft-ietf-ecrit-unauthenticated-acces= s-02.txt I believe it captures the discussion we had during the ECRIT working = group meeting. Ciao Hannes From mlinsner@cisco.com Wed Mar 30 07:48:12 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94F463A6909 for ; Wed, 30 Mar 2011 07:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.318 X-Spam-Level: X-Spam-Status: No, score=-9.318 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhc21SiPP+xL for ; Wed, 30 Mar 2011 07:48:11 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 9FCC43A6821 for ; Wed, 30 Mar 2011 07:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=3847; q=dns/txt; s=iport; t=1301496590; x=1302706190; h=date:subject:from:to:message-id:mime-version; bh=HBB/eI75eqXtJFWAU0nGAGxddauB1De5a6Dcrqa38vs=; b=FMwvTHhixc2wppaPzdhfK7mMS9kiwLSiV4wyvssXjKF4dPaXJV4Nx5QF eS80lSazytEkDJF/9n50+LSbkA6DGDMv3ErWbg75oNZl/VwYTjILbcu1f Z73aUoJlEyjBaBbrX3ecV6BNLpqEvJQNgv6OvXPRgpvdTENKYEa0r6685 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAA1Ck02rRDoJ/2dsb2JhbACCXqIVXnehApxhhWoEjQaDVQ X-IronPort-AV: E=Sophos;i="4.63,269,1299456000"; d="scan'208,217";a="420957325" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 30 Mar 2011 14:49:50 +0000 Received: from [130.129.68.179] (sjc-vpn7-1262.cisco.com [10.21.148.238]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2UEnmpn009530 for ; Wed, 30 Mar 2011 14:49:49 GMT User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Wed, 30 Mar 2011 16:49:46 +0200 From: Marc Linsner To: "ecrit@ietf.org" Message-ID: Thread-Topic: WGLC - draft-ietf-ecrit-data-only-ea-01 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3384348589_1389794" Subject: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 14:48:12 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3384348589_1389794 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit This message starts the Working Group Last Call for draft "Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP) " (http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-01). This draft fulfills the WG milestone: Apr 2011 Submit 'Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)' Please submit comments to the list by COB on Friday April 15, 2011. Thanks, -Marc Linsner- --B_3384348589_1389794 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
This message starts the Working Group Last Call for draf= t "Common Alerting Protocol (CAP) based = Data-Only Emergency Alerts using

http://tools.ietf.org/html/draft-ietf-ecrit-data-= only-ea-01).


This draft fulfills the WG milestone:<= /div>

Apr 2011 Submit 'Common Alerting Protocol (CAP) bas= ed Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)'

= Please submit comments to the list by COB on Friday April 15, 2011.

Thanks,

-Marc Linsner-
--B_3384348589_1389794-- From mlinsner@cisco.com Wed Mar 30 08:02:38 2011 Return-Path: X-Original-To: ecrit@core3.amsl.com Delivered-To: ecrit@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E14393A6983 for ; Wed, 30 Mar 2011 08:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.302 X-Spam-Level: X-Spam-Status: No, score=-9.302 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYNgXpW+LQ9N for ; Wed, 30 Mar 2011 08:02:35 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id B00CF3A6847 for ; Wed, 30 Mar 2011 08:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=3368; q=dns/txt; s=iport; t=1301497455; x=1302707055; h=date:subject:from:to:message-id:mime-version; bh=6g/yJBFAEcZE/yzCwvd/iJOE2oST5zMYzUw41uQOdIw=; b=mdAefVwSEy2rA7GodnenfX88QNm0ZWERiDQYyDaUR0xFBpB+wLMWxo/+ yZ22bhvn5PBySlUDQln+2k3tIZxFdU1tTEOQRqKHWbTGYGpR5pIGePzaA mw8010zEIEo5ylRH5jG9e0W3f5HY2OF6rAXhc1OlK7fX6nWEM+Tm57yaL M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFdFk02rRDoJ/2dsb2JhbACCXqIVXnehBpxihWoEjQaDVQ X-IronPort-AV: E=Sophos;i="4.63,269,1299456000"; d="scan'208,217";a="285791175" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 30 Mar 2011 15:04:14 +0000 Received: from [130.129.68.179] (sjc-vpn7-1262.cisco.com [10.21.148.238]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2UF4CO5020508 for ; Wed, 30 Mar 2011 15:04:14 GMT User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Wed, 30 Mar 2011 17:04:11 +0200 From: Marc Linsner To: "ecrit@ietf.org" Message-ID: Thread-Topic: draft-ietf-ecrit-data-only-ea-01 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3384349454_1453289" Subject: [Ecrit] draft-ietf-ecrit-data-only-ea-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 15:02:39 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3384349454_1453289 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Brian, Hannes, I find the scenario describing figure 2, bottom of page 5, in the draft confusing (it could be just me), "In case the LoST resolution is done at an emergency services routing proxy rather than at the entity issuing the alert since it may not know the address of the receiver." 1. I believe it should read: "In this case=8A=8A" 2. LoST resolves finding the target uri given location & desired service. So I don't understand 'since it may not know the address of the receiver.' Assuming the 'address of the receiver' is synonymous with the location of the intended target of the alert, if the sender doesn't know the intended target location for the alert, how would the proxy? Thanks, -Marc- --B_3384349454_1453289 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Brian, Hannes,
I find the scenario describing figure 2, bottom of page 5, in th= e draft confusing (it could be just me),

"In ca= se the LoST resolution is done at an emergency services routing p= roxy rather than at the entity issuing the alert since it may not= know the address of the receiver."

  1. I believe it should read: "In this case……"<= /span>
  2. LoST resolves finding the target uri given location &= desired service. So I don't understand 'since it may not know the address = of the receiver.' Assuming the 'address of the receiver' is synonymous with= the location of the intended target of the alert, if the sender doesn't kno= w the intended target location for the alert, how would the proxy?
T= hanks,

-Marc-
--B_3384349454_1453289--