From ecrit-bounces@ietf.org Fri Jun 01 00:49:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htz5H-0007Zh-Ln; Fri, 01 Jun 2007 00:49:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htz5G-0007YP-Up for ecrit@ietf.org; Fri, 01 Jun 2007 00:49:54 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Htz5G-0007j6-D4 for ecrit@ietf.org; Fri, 01 Jun 2007 00:49:54 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Htz5D-0004Tr-5a; Fri, 01 Jun 2007 00:49:51 -0400 Message-ID: <465FA53B.80802@bbn.com> Date: Fri, 01 Jun 2007 00:48:59 -0400 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ECRIT , "James M. Polk" , br@brianrosen.net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.3 (++) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 Cc: Subject: [Ecrit] Comments on: draft-ietf-ecrit-phonebcp-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian and James: First, two very high level questions. A) [Is this document supposed to be SIP-Centric?] It is unclear to me whether the document is intended as a BCP for SIP User Agents and SIP proxies, or whether it is more generally a BCP for end points and signaling-path devices which may or may not use SIP. For instance, Section 6.4 is written as though SIP signaling were a special case, and yet paragraph four of Section 5 indicates that all emergency calls on the wire should contain a Route header (which is a SIP-specific signaling component). Personally, I don't care whether or not the document is SIP centric, or whether SIP is a special case, as long as the document is consistent. B) [Is there consensus on how to mark emergency calls?] The current version of phonebcp indicates that (in the normal case when end-points perform the LoST mapping) emergency calls are marked by putting the URN in a Route header (with a "loose" parameter that I'm not familiar with ... can someone provide me with a reference) and that the URN is placed in the Request-URI when the end-point is unable to perform the LoST mapping). Personally, I don't understand the current mechanism because I'm not sure what an "ordinary" (RFC3261-compliant) proxy does when it sees a service URN in the top Route header. However, given the long discussion that occured on call marking in January (See: http://www1.ietf.org/mail-archive/web/ecrit/current/msg02963.html), perhaps the more important question is "Has consensus been reached that (something like) the current mechanism is an appropriate way to mark messages?" --------------------------------- More detailed comments: Section 2: (paragraph 3 - number 2) Is it clear what the "visited location's emergency number" means in this context? Consider changing to "the local emergency number for its current location" or providing a forward reference to the discussion of dial-strings in Section 5. Section 2: (paragraph 4) I agree with Barbara that if this is intended to an overview of call setup for the special case of an Ethernet connected phone then the bullets should match up more clearly with the numbered items in the previous paragraph. Section 2: (last paragraph) It is unclear whether the antecedent of "it" in the last paragraph is [RFC4103] or [RFC4504]. Section 3: Consider changing "should support" to "SHOULD support" Section 3: (paragraph 2) It seems that the point of this paragraph is to say that a certain class of devices that communicates over IP networks should support emergency calls. However, I find the phrase "using current (evolving) standards" to be unclear and in particular I'm not sure what the phrase modifies. (E.g. Do you mean "Devices that create media sessions using current (evolving) standards and exchange audio ...") Section 4: (first paragraph) Consider replacing "the norm" with "required" (or a similar word). I think the point is not that automatic location is common/normal but that it is necessary since most users are unable to provide accurate location. Section 4.1: (first paragraph) I think "cellular" (or "traditional wireless") is more precise than "mobile". Section 4.2: (first paragraph ... also, the last paragraph) Consider changing the phrase "the desired result" to something like "an equivalent result", or perhaps something even more explicit. Section 4.2: (first paragraph) Consider addition a phrase to the last sentence indicating why it is recommended that the network support a standardized LCP. (This may not be obvious to the reader). Also, consider changing "recommended" to "RECOMMENDED". Section 4.2: (paragraph 2) Given that the paragraph covers what both devices and access networks MUST support, consider changing "For all other devices" to "In all other scenarios". Section 4.3: (paragraph 3) The term "geo-location" is not used in RFC 3825 to describe a lat/lon/alt - style location. (Instead it uses terms like a "coordinate-based geolocation"). Also, given that the "geolocation" header allows for civic locations, I think using geo-location here is potentially confusing. Note: This comment also applies to the use of "geo reported" in the third paragraph of Section 6.3 Section 4.4: (last paragraph) Consider re-writing the second-to-the-last sentence as: "Certain commonly-used techniques for measuring location create a conflict between the time it takes to generate a precise location and the desire to route the call quickly." (Also, in the following sentence I think "precise" is a better word than "accurate") Section 5: (paragraphs 5 and 6) Paragraph 5 says that devices MUST mark calls using a service:sos URN. However, paragraph 6 says that mapping from dialstring to URN SHOULD be done by the endpoint. Either both paragraphs should use "MUST" or else they should both use "SHOULD". Section 5: (paragraph 8) I don't understand what it means to be "roaming" or "nomadic" in a system where there is no "visited network" Section 5: (last paragraph) The last sentence of this paragraph seems to be redundent. Consider deleting it. Section 6.1: I agree with Barbara that the use of IPSec should not be prohibited by this BCP. Section 6.1: (number 6) These instructions are for the User Agent, P-Asserted-Identity headers and Identity headers should not be inserted by the UA Section 6.1: (number 10) This item is unclear to me. Is the author's intention that this item handles the case where a UA does not know its own location? If so, I guess that updating this item should be deferred until consensus is reached on location-hiding. Section 6.1: Consider Re-ordering the items as: 11, 10, 12, 14, 15, 13 Also, consider deleting 12, I believe it is redundent given 9, 10 and 11. Section 6.2: (number 1) Consider adding an example after "... URN appropriate for the emergency dialstring." That is, consider adding (e.g., ...) Section 6.2: (number 3) I'm afraid that I don't understand the meaning of this sentence. Section 6.3: (paragraph 3) The sentence that begins "This can be an enclosing ..." is unclear to me. Are you suggesting that when a PSAP coverage region is complex, that a LoST server SHOULD return a simple polygon that (a) contains the location of the device; and (b) is entirely contained within the PSAP coverage region? Section 6.5: (number 3) This seems to imply that proxies should expect to SUBSCRIBE to Presence. Do you mean that proxies should expect the PSAP to SUBSCRIBE to Presence? Section 6.5: (number 4) I'm not very familiar with Session Timers, can you provide a reference. Section 6.6: I'm afraid I don't understand the parenthetical remark after the "Call Forward" bullet. (Consider removing the remark or re-wording it if it is important). Section 7: Given the text in Section 4.4 it seems to me that the first paragraph of Section 7 is redundent and should be deleted. Section 10.2: Given the difficulty of implementing location signing in a useful manner, I think that that either paragraph 2 should either be removed or else it should reference some other document that explains location signing in more detail. (That is, one paragraph does not do location signing justice and it seems irresponsible to strongly recommend location signing without providing additionaly guidence to the implementor). ------------------------------------------------------------------- Minor Nits: (That don't change the meaning of the text) Section 2: (last paragraph) Put a space between [RFC4103] and "media" Section 3: (paragraph 1) Add commas to second sentence "Future PSAPs will, however, support ..." and remove the extra period at the end of the sentence Section 4.1: (paragraph 2) Change "... where it is the access network that knows the location ..." to "... when only the access network knows the location ..." Section 4.4: (paragraph 1) Change "... process engaged from establishing a VPN ... " to "... process engaged by establishing a VPN ..." Section 4.4: (paragraph 2) Change "... related to the mobility of the device and ..." to "... related to the degree of device mobility and ..." Section 4.4: (paragraph 2) Combine the final 2 sentances as follows: "When a device is aware that it has moved, for instance when it changes access points, the device SHOULD refresh its location." Section 4.4: (last paragraph) Change "... getting more recent location ..." to "... getting updated location ..." or "... obtaining a fresh location" Section 5: (first paragraph) Consider re-writing as: "A device (or a downstream signaling element) identifies an emergency call by an "address", which in most cases is a dialstring, although other user interfaces may be used." Section 5: (paragraph 2) First sentence has too many words modifying the word "element". Consider: "Note: It is undesirable for a user-interface to enable a user to place an emergency call by pressing a single button." Section 5: (paragraph 3) Consider changing the first sentence: "... in other countries there are several 3 digit numbers used for different types of emergency calls." Section 5: (paragraph 6) Change "... some entity needs to ..." to "... some entity on the signaling path must ..." Section 5: (paragraph 9) Change "... from North America, the home ..." to "... from North America, then while in North America the home ..." Section 5: (last paragraph) Add a close parenthesis ")" after "dialstrings." Section 6: Change "... is expected be supported ..." to "... is expected to be supported ..." Section 6.1: Change "signaling Method" to "signaling method" (lower case). Section 6.1: (number 1) Change "To: SHOULD" to "Request-URI: SHOULD" Section 6.1: (number 2) Add a space between [I-D.rosen-iptel-dialstring] and "with" Also change "sips MUST be ..." to "a sips URI MUST be ..." Section 6.2: (number 1) Change "If it finds it it MUST:" to "If it finds the dialstring it MUST:" Also, change "... for the endpoint" to "... of the end device." (note that period was missing) Section 6.3: (paragraph 3) Non-parallel sentence structure. Consider re-writing the last sentence as: "In the case of civic location, the LoST server SHOULD report that the same mapping is good within a community name or even a street, as this is helpful for WiFi connected devices that roam and obtain civic location from the AP to which they connect." (Or perhaps "Despite the fact that civic location is uncommon for mobile devices, the LoST server SHOULD ...") Section 6.3: (paragraph 4) Change "... URI of the service URN ..." to "... URI of a service URN ..." Section 6.3: (last paragraph) Re-write the last sentence as: "The proxy then replaces the Request-URI with the resulting PSAP URI." Or perhaps "The resulting PSAP URI then replaces the Request-URI" Section 6.4: (first paragraph) Consider adding the phrase "Once the mapping to a PSAP URI has been performed," to the begining of the paragraph (to improve the flow of the document). Section 6.6: Change "The emergency dialstrings ..." to "Emergency dialstrings ..." Section 7: (paragraph 3) Change "For calls send with ..." to "For calls sent with ..." Section 8: (paragraph 1) Change "... media streams on RTP ... " to "... media stream using RTP ..." or perhaps "... media streams via RTP ..." Also, consider re-writing the 4th sentence as: "Future IP-enabled PSAPs should accept a wider array of potential media types." Section 8: (paragraph 2) Add a period between "the offer" and "Silence suppression". Section 10: Change "... it specifies use of several ..." to "... it specifies the use of several ..." Section 10.1: (paragraph 2) Change "... DHCP is the LCP [RFC3118] ..." to "... DHCP is the LCP, [RFC3118] ..." (add a comma) Also, change "... spoofing would be ..." to "... spoofing is ..." Section 10.1: (last paragraph) Add an 's' to change "Client SHOULD" to "Clients SHOULD" Section 10.2: (last paragraph) Change "... signaling would help significantly." to "... signaling helps significantly." _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 01 08:36:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu6MM-0000Hm-4o; Fri, 01 Jun 2007 08:36:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu6MK-00009n-PX for ecrit@ietf.org; Fri, 01 Jun 2007 08:36:00 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu6MK-0000tL-3B for ecrit@ietf.org; Fri, 01 Jun 2007 08:36:00 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1Hu6MC-0006Zz-81; Fri, 01 Jun 2007 07:35:52 -0500 From: "Brian Rosen" To: "'Matt Lepinski'" , "'ECRIT'" , "'James M. Polk'" References: <465FA53B.80802@bbn.com> Date: Fri, 1 Jun 2007 08:35:55 -0400 Message-ID: <0add01c7a449$6846b260$6601a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <465FA53B.80802@bbn.com> Thread-Index: AcekCFEPcS0iQckvRVWGxa+1mAstOgAQAffg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 Cc: Subject: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Thanks for your comments. The BCP really shouldn't be SIP specific. We need to broaden it to, for example, XMPP. We can have SIP specific information, but it should be discussed as just that. There is a consensus, I believe, on how to mark emergency calls, represented by the thread, but chairs have to call consensus, not me. I think there are three cases: 1. The endpoint recognizes it's an emergency call, does the LoST routing, and passes the call to its outbound proxy server. In this case the Request URI will be the PSAP URI from LoST, and adds a Route header with the service URN. 2. The endpoint recognizes it's an emergency call, but doesn't LoST route it. In this case the Request URI would be the service URN. The outbound proxy server would do the LoST routing, put the Route header with the service URN in and change the Request URI to the PSAP URI. 3. The endpoint doesn't even recognize it's an emergency call. In this case, the endpoint would put the dialstring in the Request URI. The outbound proxy would behave as in 2 above. When the PSAP gets the call, it will always have its URI in the Request URI, and there will be a service URN in a Route header. Probably, phonebcp should say that more clearly. Brian > -----Original Message----- > From: Matt Lepinski [mailto:mlepinski@bbn.com] > Sent: Friday, June 01, 2007 12:49 AM > To: ECRIT; James M. Polk; br@brianrosen.net > Subject: Comments on: draft-ietf-ecrit-phonebcp-01 > > Brian and James: > > First, two very high level questions. > > A) [Is this document supposed to be SIP-Centric?] It is unclear to me > whether the document is intended as a BCP for SIP User Agents and SIP > proxies, or whether it is more generally a BCP for end points and > signaling-path devices which may or may not use SIP. For instance, > Section 6.4 is written as though SIP signaling were a special case, and > yet paragraph four of Section 5 indicates that all emergency calls on > the wire should contain a Route header (which is a SIP-specific > signaling component). Personally, I don't care whether or not the > document is SIP centric, or whether SIP is a special case, as long as > the document is consistent. > > B) [Is there consensus on how to mark emergency calls?] The current > version of phonebcp indicates that (in the normal case when end-points > perform the LoST mapping) emergency calls are marked by putting the URN > in a Route header (with a "loose" parameter that I'm not familiar with > ... can someone provide me with a reference) and that the URN is placed > in the Request-URI when the end-point is unable to perform the LoST > mapping). Personally, I don't understand the current mechanism because > I'm not sure what an "ordinary" (RFC3261-compliant) proxy does when it > sees a service URN in the top Route header. However, given the long > discussion that occured on call marking in January (See: > http://www1.ietf.org/mail-archive/web/ecrit/current/msg02963.html), > perhaps the more important question is "Has consensus been reached that > (something like) the current mechanism is an appropriate way to mark > messages?" > > --------------------------------- > More detailed comments: > > Section 2: (paragraph 3 - number 2) > Is it clear what the "visited location's emergency number" means in this > context? > Consider changing to "the local emergency number for its current > location" or providing a forward reference to the discussion of > dial-strings in Section 5. > > Section 2: (paragraph 4) > I agree with Barbara that if this is intended to an overview of call > setup for the special case of an Ethernet connected phone then the > bullets should match up more clearly with the numbered items in the > previous paragraph. > > Section 2: (last paragraph) > It is unclear whether the antecedent of "it" in the last paragraph is > [RFC4103] or [RFC4504]. > > Section 3: > Consider changing "should support" to "SHOULD support" > > Section 3: (paragraph 2) > It seems that the point of this paragraph is to say that a certain class > of devices that communicates over IP networks should support emergency > calls. However, I find the phrase "using current (evolving) standards" > to be unclear and in particular I'm not sure what the phrase modifies. > (E.g. Do you mean "Devices that create media sessions using current > (evolving) standards and exchange audio ...") > > Section 4: (first paragraph) > Consider replacing "the norm" with "required" (or a similar word). I > think the point is not that automatic location is common/normal but that > it is necessary since most users are unable to provide accurate location. > > Section 4.1: (first paragraph) > I think "cellular" (or "traditional wireless") is more precise than > "mobile". > > Section 4.2: (first paragraph ... also, the last paragraph) > Consider changing the phrase "the desired result" to something like "an > equivalent result", or perhaps something even more explicit. > > Section 4.2: (first paragraph) > Consider addition a phrase to the last sentence indicating why it is > recommended that the network support a standardized LCP. (This may not > be obvious to the reader). Also, consider changing "recommended" to > "RECOMMENDED". > > Section 4.2: (paragraph 2) > Given that the paragraph covers what both devices and access networks > MUST support, consider changing "For all other devices" to "In all other > scenarios". > > Section 4.3: (paragraph 3) > The term "geo-location" is not used in RFC 3825 to describe a > lat/lon/alt - style location. (Instead it uses terms like a > "coordinate-based geolocation"). Also, given that the "geolocation" > header allows for civic locations, I think using geo-location here is > potentially confusing. > Note: This comment also applies to the use of "geo reported" in the > third paragraph of Section 6.3 > > Section 4.4: (last paragraph) > Consider re-writing the second-to-the-last sentence as: "Certain > commonly-used techniques for measuring location create a conflict > between the time it takes to generate a precise location and the desire > to route the call quickly." (Also, in the following sentence I think > "precise" is a better word than "accurate") > > Section 5: (paragraphs 5 and 6) > Paragraph 5 says that devices MUST mark calls using a service:sos URN. > However, paragraph 6 says that mapping from dialstring to URN SHOULD be > done by the endpoint. Either both paragraphs should use "MUST" or else > they should both use "SHOULD". > > Section 5: (paragraph 8) > I don't understand what it means to be "roaming" or "nomadic" in a > system where there is no "visited network" > > Section 5: (last paragraph) > The last sentence of this paragraph seems to be redundent. Consider > deleting it. > > Section 6.1: > I agree with Barbara that the use of IPSec should not be prohibited by > this BCP. > > Section 6.1: (number 6) > These instructions are for the User Agent, P-Asserted-Identity headers > and Identity headers should not be inserted by the UA > > Section 6.1: (number 10) > This item is unclear to me. Is the author's intention that this item > handles the case where a UA does not know its own location? If so, I > guess that updating this item should be deferred until consensus is > reached on location-hiding. > > Section 6.1: > Consider Re-ordering the items as: > 11, 10, 12, 14, 15, 13 > Also, consider deleting 12, I believe it is redundent given 9, 10 and 11. > > Section 6.2: (number 1) > Consider adding an example after "... URN appropriate for the emergency > dialstring." That is, consider adding (e.g., ...) > > Section 6.2: (number 3) > I'm afraid that I don't understand the meaning of this sentence. > > Section 6.3: (paragraph 3) > The sentence that begins "This can be an enclosing ..." is unclear to > me. Are you suggesting that when a PSAP coverage region is complex, that > a LoST server SHOULD return a simple polygon that (a) contains the > location of the device; and (b) is entirely contained within the PSAP > coverage region? > > Section 6.5: (number 3) > This seems to imply that proxies should expect to SUBSCRIBE to Presence. > Do you mean that proxies should expect the PSAP to SUBSCRIBE to Presence? > > Section 6.5: (number 4) > I'm not very familiar with Session Timers, can you provide a reference. > > Section 6.6: > I'm afraid I don't understand the parenthetical remark after the "Call > Forward" bullet. (Consider removing the remark or re-wording it if it is > important). > > Section 7: > Given the text in Section 4.4 it seems to me that the first paragraph of > Section 7 is redundent and should be deleted. > > Section 10.2: > Given the difficulty of implementing location signing in a useful > manner, I think that that either paragraph 2 should either be removed or > else it should reference some other document that explains location > signing in more detail. (That is, one paragraph does not do location > signing justice and it seems irresponsible to strongly recommend > location signing without providing additionaly guidence to the > implementor). > > ------------------------------------------------------------------- > Minor Nits: (That don't change the meaning of the text) > > Section 2: (last paragraph) > Put a space between [RFC4103] and "media" > > Section 3: (paragraph 1) > Add commas to second sentence "Future PSAPs will, however, support ..." > and remove the extra period at the end of the sentence > > Section 4.1: (paragraph 2) > Change "... where it is the access network that knows the location ..." > to "... when only the access network knows the location ..." > > Section 4.4: (paragraph 1) > Change "... process engaged from establishing a VPN ... " to "... > process engaged by establishing a VPN ..." > > Section 4.4: (paragraph 2) > Change "... related to the mobility of the device and ..." to "... > related to the degree of device mobility and ..." > > Section 4.4: (paragraph 2) > Combine the final 2 sentances as follows: > "When a device is aware that it has moved, for instance when it changes > access points, the device SHOULD refresh its location." > > Section 4.4: (last paragraph) > Change "... getting more recent location ..." to "... getting updated > location ..." or "... obtaining a fresh location" > > Section 5: (first paragraph) > Consider re-writing as: > "A device (or a downstream signaling element) identifies an emergency > call by an "address", which in most cases is a dialstring, although > other user interfaces may be used." > > Section 5: (paragraph 2) > First sentence has too many words modifying the word "element". Consider: > "Note: It is undesirable for a user-interface to enable a user to place > an emergency call by pressing a single button." > > Section 5: (paragraph 3) > Consider changing the first sentence: > "... in other countries there are several 3 digit numbers used for > different types of emergency calls." > > Section 5: (paragraph 6) > Change "... some entity needs to ..." to "... some entity on the > signaling path must ..." > > Section 5: (paragraph 9) > Change "... from North America, the home ..." to "... from North > America, then while in North America the home ..." > > Section 5: (last paragraph) > Add a close parenthesis ")" after "dialstrings." > > Section 6: > Change "... is expected be supported ..." to "... is expected to be > supported ..." > > Section 6.1: > Change "signaling Method" to "signaling method" (lower case). > > Section 6.1: (number 1) > Change "To: SHOULD" to "Request-URI: SHOULD" > > Section 6.1: (number 2) > Add a space between [I-D.rosen-iptel-dialstring] and "with" > Also change "sips MUST be ..." to "a sips URI MUST be ..." > > Section 6.2: (number 1) > Change "If it finds it it MUST:" to "If it finds the dialstring it MUST:" > Also, change "... for the endpoint" to "... of the end device." (note > that period was missing) > > Section 6.3: (paragraph 3) > Non-parallel sentence structure. Consider re-writing the last sentence as: > "In the case of civic location, the LoST server SHOULD report that the > same mapping is good within a community name or even a street, as this > is helpful for WiFi connected devices that roam and obtain civic > location from the AP to which they connect." > (Or perhaps "Despite the fact that civic location is uncommon for mobile > devices, the LoST server SHOULD ...") > > Section 6.3: (paragraph 4) > Change "... URI of the service URN ..." to "... URI of a service URN ..." > > Section 6.3: (last paragraph) > Re-write the last sentence as: "The proxy then replaces the Request-URI > with the resulting PSAP URI." > Or perhaps "The resulting PSAP URI then replaces the Request-URI" > > Section 6.4: (first paragraph) > Consider adding the phrase "Once the mapping to a PSAP URI has been > performed," to the begining of the paragraph (to improve the flow of the > document). > > Section 6.6: > Change "The emergency dialstrings ..." to "Emergency dialstrings ..." > > Section 7: (paragraph 3) > Change "For calls send with ..." to "For calls sent with ..." > > Section 8: (paragraph 1) > Change "... media streams on RTP ... " to "... media stream using RTP ..." > or perhaps "... media streams via RTP ..." > Also, consider re-writing the 4th sentence as: > "Future IP-enabled PSAPs should accept a wider array of potential media > types." > > Section 8: (paragraph 2) > Add a period between "the offer" and "Silence suppression". > > Section 10: > Change "... it specifies use of several ..." to "... it specifies the > use of several ..." > > Section 10.1: (paragraph 2) > Change "... DHCP is the LCP [RFC3118] ..." to "... DHCP is the LCP, > [RFC3118] ..." (add a comma) > Also, change "... spoofing would be ..." to "... spoofing is ..." > > Section 10.1: (last paragraph) > Add an 's' to change "Client SHOULD" to "Clients SHOULD" > > Section 10.2: (last paragraph) > Change "... signaling would help significantly." to "... signaling helps > significantly." _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 01 17:35:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuEmN-00083j-5o; Fri, 01 Jun 2007 17:35:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuEmL-0007zG-PF for ecrit@ietf.org; Fri, 01 Jun 2007 17:35:25 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuEmL-0001jB-3p for ecrit@ietf.org; Fri, 01 Jun 2007 17:35:25 -0400 X-SEF-Processed: 5_0_0_910__2007_06_01_16_42_46 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 01 Jun 2007 16:42:46 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Jun 2007 16:35:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 Date: Fri, 1 Jun 2007 16:35:14 -0500 Message-ID: In-Reply-To: <0add01c7a449$6846b260$6601a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 Thread-Index: AcekCFEPcS0iQckvRVWGxa+1mAstOgAQAffgABMPLZA= References: <465FA53B.80802@bbn.com> <0add01c7a449$6846b260$6601a8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Matt Lepinski" , "ECRIT" , "James M. Polk" X-OriginalArrivalTime: 01 Jun 2007 21:35:19.0906 (UTC) FILETIME=[C0BCC420:01C7A494] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think that there is one other variant on two.=0D=0A=0D=0AThe End-point ma= kes the call the service URN and includes a provided=0D=0AlocationURI. Outb= ound-proxy does nothing special.=0D=0A=0D=0A> -----Original Message-----=0D= =0A> From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> Sent: Friday, 1 Ju= ne 2007 10:36 PM=0D=0A> To: 'Matt Lepinski'; 'ECRIT'; 'James M. Polk'=0D=0A= > Subject: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01=0D=0A>=20=0D= =0A> Thanks for your comments.=0D=0A>=20=0D=0A> The BCP really shouldn't be= SIP specific. We need to broaden it to,=0D=0Afor=0D=0A> example, XMPP. W= e can have SIP specific information, but it should be=0D=0A> discussed as j= ust that.=0D=0A>=20=0D=0A> There is a consensus, I believe, on how to mark = emergency calls,=0D=0A> represented=0D=0A> by the thread, but chairs have t= o call consensus, not me. I think=0D=0Athere=0D=0A> are=0D=0A> three cases= :=0D=0A> 1. The endpoint recognizes it's an emergency call, does the LoST=0D= =0Arouting,=0D=0A> and passes the call to its outbound proxy server. In th= is case the=0D=0A> Request=0D=0A> URI will be the PSAP URI from LoST, and a= dds a Route header with the=0D=0A> service=0D=0A> URN.=0D=0A> 2. The endpoi= nt recognizes it's an emergency call, but doesn't LoST=0D=0Aroute=0D=0A> it= =2E In this case the Request URI would be the service URN. The=0D=0Aoutbo= und=0D=0A> proxy server would do the LoST routing, put the Route header wit= h the=0D=0A> service URN in and change the Request URI to the PSAP URI.=0D=0A= > 3. The endpoint doesn't even recognize it's an emergency call. In=0D=0At= his=0D=0A> case, the endpoint would put the dialstring in the Request URI. = The=0D=0A> outbound proxy would behave as in 2 above.=0D=0A>=20=0D=0A> Whe= n the PSAP gets the call, it will always have its URI in the=0D=0ARequest=0D= =0A> URI,=0D=0A> and there will be a service URN in a Route header.=0D=0A> =0D= =0A> Probably, phonebcp should say that more clearly.=0D=0A>=20=0D=0A> Bria= n=0D=0A>=20=0D=0A> > -----Original Message-----=0D=0A> > From: Matt Lepinsk= i [mailto:mlepinski@bbn.com]=0D=0A> > Sent: Friday, June 01, 2007 12:49 AM=0D= =0A> > To: ECRIT; James M. Polk; br@brianrosen.net=0D=0A> > Subject: Commen= ts on: draft-ietf-ecrit-phonebcp-01=0D=0A> >=0D=0A> > Brian and James:=0D=0A= > >=0D=0A> > First, two very high level questions.=0D=0A> >=0D=0A> > A) [Is= this document supposed to be SIP-Centric=3F] It is unclear to=0D=0Ame=0D=0A= > > whether the document is intended as a BCP for SIP User Agents and=0D=0A= SIP=0D=0A> > proxies, or whether it is more generally a BCP for end points = and=0D=0A> > signaling-path devices which may or may not use SIP. For insta= nce,=0D=0A> > Section 6.4 is written as though SIP signaling were a special= case,=0D=0Aand=0D=0A> > yet paragraph four of Section 5 indicates that all= emergency calls=0D=0Aon=0D=0A> > the wire should contain a Route header (w= hich is a SIP-specific=0D=0A> > signaling component). Personally, I don't c= are whether or not the=0D=0A> > document is SIP centric, or whether SIP is = a special case, as long=0D=0Aas=0D=0A> > the document is consistent.=0D=0A>= >=0D=0A> > B) [Is there consensus on how to mark emergency calls=3F] The c= urrent=0D=0A> > version of phonebcp indicates that (in the normal case when=0D= =0Aend-points=0D=0A> > perform the LoST mapping) emergency calls are marked= by putting the=0D=0AURN=0D=0A> > in a Route header (with a "loose" paramet= er that I'm not familiar=0D=0Awith=0D=0A> > ... can someone provide me with= a reference) and that the URN is=0D=0Aplaced=0D=0A> > in the Request-URI w= hen the end-point is unable to perform the LoST=0D=0A> > mapping). Personal= ly, I don't understand the current mechanism=0D=0Abecause=0D=0A> > I'm not = sure what an "ordinary" (RFC3261-compliant) proxy does when=0D=0Ait=0D=0A> = > sees a service URN in the top Route header. However, given the long=0D=0A= > > discussion that occured on call marking in January (See:=0D=0A> > http:= //www1.ietf.org/mail-archive/web/ecrit/current/msg02963.html),=0D=0A> > per= haps the more important question is "Has consensus been reached=0D=0Athat=0D= =0A> > (something like) the current mechanism is an appropriate way to mark=0D= =0A> > messages=3F"=0D=0A> >=0D=0A> > ---------------------------------=0D=0A= > > More detailed comments:=0D=0A> >=0D=0A> > Section 2: (paragraph 3 - num= ber 2)=0D=0A> > Is it clear what the "visited location's emergency number" = means in=0D=0Athis=0D=0A> > context=3F=0D=0A> > Consider changing to "the l= ocal emergency number for its current=0D=0A> > location" or providing a for= ward reference to the discussion of=0D=0A> > dial-strings in Section 5.=0D=0A= > >=0D=0A> > Section 2: (paragraph 4)=0D=0A> > I agree with Barbara that if= this is intended to an overview of call=0D=0A> > setup for the special cas= e of an Ethernet connected phone then the=0D=0A> > bullets should match up = more clearly with the numbered items in the=0D=0A> > previous paragraph.=0D= =0A> >=0D=0A> > Section 2: (last paragraph)=0D=0A> > It is unclear whether = the antecedent of "it" in the last paragraph=0D=0Ais=0D=0A> > [RFC4103] or = [RFC4504].=0D=0A> >=0D=0A> > Section 3:=0D=0A> > Consider changing "should = support" to "SHOULD support"=0D=0A> >=0D=0A> > Section 3: (paragraph 2)=0D=0A= > > It seems that the point of this paragraph is to say that a certain=0D=0A= class=0D=0A> > of devices that communicates over IP networks should support=0D= =0Aemergency=0D=0A> > calls. However, I find the phrase "using current (evo= lving)=0D=0Astandards"=0D=0A> > to be unclear and in particular I'm not sur= e what the phrase=0D=0Amodifies.=0D=0A> > (E.g. Do you mean "Devices that c= reate media sessions using current=0D=0A> > (evolving) standards and exchan= ge audio ...")=0D=0A> >=0D=0A> > Section 4: (first paragraph)=0D=0A> > Cons= ider replacing "the norm" with "required" (or a similar word). I=0D=0A> > t= hink the point is not that automatic location is common/normal but=0D=0Atha= t=0D=0A> > it is necessary since most users are unable to provide accurate=0D= =0A> location.=0D=0A> >=0D=0A> > Section 4.1: (first paragraph)=0D=0A> > I = think "cellular" (or "traditional wireless") is more precise than=0D=0A> >= "mobile".=0D=0A> >=0D=0A> > Section 4.2: (first paragraph ... also, the la= st paragraph)=0D=0A> > Consider changing the phrase "the desired result" to= something like=0D=0A"an=0D=0A> > equivalent result", or perhaps something = even more explicit.=0D=0A> >=0D=0A> > Section 4.2: (first paragraph)=0D=0A>= > Consider addition a phrase to the last sentence indicating why it is=0D=0A= > > recommended that the network support a standardized LCP. (This may=0D=0A= not=0D=0A> > be obvious to the reader). Also, consider changing "recommende= d" to=0D=0A> > "RECOMMENDED".=0D=0A> >=0D=0A> > Section 4.2: (paragraph 2)=0D= =0A> > Given that the paragraph covers what both devices and access=0D=0Ane= tworks=0D=0A> > MUST support, consider changing "For all other devices" to = "In all=0D=0Aother=0D=0A> > scenarios".=0D=0A> >=0D=0A> > Section 4.3: (par= agraph 3)=0D=0A> > The term "geo-location" is not used in RFC 3825 to descr= ibe a=0D=0A> > lat/lon/alt - style location. (Instead it uses terms like a=0D= =0A> > "coordinate-based geolocation"). Also, given that the "geolocation"=0D= =0A> > header allows for civic locations, I think using geo-location here=0D= =0Ais=0D=0A> > potentially confusing.=0D=0A> > Note: This comment also appl= ies to the use of "geo reported" in the=0D=0A> > third paragraph of Section= 6.3=0D=0A> >=0D=0A> > Section 4.4: (last paragraph)=0D=0A> > Consider re-= writing the second-to-the-last sentence as: "Certain=0D=0A> > commonly-used= techniques for measuring location create a conflict=0D=0A> > between the t= ime it takes to generate a precise location and the=0D=0Adesire=0D=0A> > to= route the call quickly." (Also, in the following sentence I think=0D=0A> >= "precise" is a better word than "accurate")=0D=0A> >=0D=0A> > Section 5: (= paragraphs 5 and 6)=0D=0A> > Paragraph 5 says that devices MUST mark calls = using a service:sos=0D=0AURN.=0D=0A> > However, paragraph 6 says that mappi= ng from dialstring to URN SHOULD=0D=0Abe=0D=0A> > done by the endpoint. Eit= her both paragraphs should use "MUST" or=0D=0Aelse=0D=0A> > they should bot= h use "SHOULD".=0D=0A> >=0D=0A> > Section 5: (paragraph 8)=0D=0A> > I don't= understand what it means to be "roaming" or "nomadic" in a=0D=0A> > system= where there is no "visited network"=0D=0A> >=0D=0A> > Section 5: (last par= agraph)=0D=0A> > The last sentence of this paragraph seems to be redundent.= Consider=0D=0A> > deleting it.=0D=0A> >=0D=0A> > Section 6.1:=0D=0A> > I a= gree with Barbara that the use of IPSec should not be prohibited=0D=0Aby=0D= =0A> > this BCP.=0D=0A> >=0D=0A> > Section 6.1: (number 6)=0D=0A> > These i= nstructions are for the User Agent, P-Asserted-Identity=0D=0Aheaders=0D=0A= > > and Identity headers should not be inserted by the UA=0D=0A> >=0D=0A> >= Section 6.1: (number 10)=0D=0A> > This item is unclear to me. Is the autho= r's intention that this item=0D=0A> > handles the case where a UA does not = know its own location=3F If so, I=0D=0A> > guess that updating this item sh= ould be deferred until consensus is=0D=0A> > reached on location-hiding.=0D= =0A> >=0D=0A> > Section 6.1:=0D=0A> > Consider Re-ordering the items as:=0D= =0A> > 11, 10, 12, 14, 15, 13=0D=0A> > Also, consider deleting 12, I believ= e it is redundent given 9, 10=0D=0Aand=0D=0A> 11.=0D=0A> >=0D=0A> > Section= 6.2: (number 1)=0D=0A> > Consider adding an example after "... URN appropr= iate for the=0D=0Aemergency=0D=0A> > dialstring." That is, consider adding = (e.g., ...)=0D=0A> >=0D=0A> > Section 6.2: (number 3)=0D=0A> > I'm afraid t= hat I don't understand the meaning of this sentence.=0D=0A> >=0D=0A> > Sect= ion 6.3: (paragraph 3)=0D=0A> > The sentence that begins "This can be an en= closing ..." is unclear=0D=0Ato=0D=0A> > me. Are you suggesting that when a= PSAP coverage region is complex,=0D=0Athat=0D=0A> > a LoST server SHOULD r= eturn a simple polygon that (a) contains the=0D=0A> > location of the devic= e; and (b) is entirely contained within the=0D=0APSAP=0D=0A> > coverage reg= ion=3F=0D=0A> >=0D=0A> > Section 6.5: (number 3)=0D=0A> > This seems to imp= ly that proxies should expect to SUBSCRIBE to=0D=0APresence.=0D=0A> > Do yo= u mean that proxies should expect the PSAP to SUBSCRIBE to=0D=0A> Presence=3F=0D= =0A> >=0D=0A> > Section 6.5: (number 4)=0D=0A> > I'm not very familiar with= Session Timers, can you provide a=0D=0Areference.=0D=0A> >=0D=0A> > Sectio= n 6.6:=0D=0A> > I'm afraid I don't understand the parenthetical remark afte= r the=0D=0A"Call=0D=0A> > Forward" bullet. (Consider removing the remark or= re-wording it if=0D=0Ait is=0D=0A> > important).=0D=0A> >=0D=0A> > Section= 7:=0D=0A> > Given the text in Section 4.4 it seems to me that the first=0D= =0Aparagraph of=0D=0A> > Section 7 is redundent and should be deleted.=0D=0A= > >=0D=0A> > Section 10.2:=0D=0A> > Given the difficulty of implementing lo= cation signing in a useful=0D=0A> > manner, I think that that either paragr= aph 2 should either be=0D=0Aremoved or=0D=0A> > else it should reference so= me other document that explains location=0D=0A> > signing in more detail. (= That is, one paragraph does not do location=0D=0A> > signing justice and it= seems irresponsible to strongly recommend=0D=0A> > location signing withou= t providing additionaly guidence to the=0D=0A> > implementor).=0D=0A> >=0D=0A= > > -------------------------------------------------------------------=0D=0A= > > Minor Nits: (That don't change the meaning of the text)=0D=0A> >=0D=0A>= > Section 2: (last paragraph)=0D=0A> > Put a space between [RFC4103] and "= media"=0D=0A> >=0D=0A> > Section 3: (paragraph 1)=0D=0A> > Add commas to se= cond sentence "Future PSAPs will, however, support=0D=0A..."=0D=0A> > and r= emove the extra period at the end of the sentence=0D=0A> >=0D=0A> > Section= 4.1: (paragraph 2)=0D=0A> > Change "... where it is the access network tha= t knows the location=0D=0A..."=0D=0A> > to "... when only the access networ= k knows the location ..."=0D=0A> >=0D=0A> > Section 4.4: (paragraph 1)=0D=0A= > > Change "... process engaged from establishing a VPN ... " to "...=0D=0A= > > process engaged by establishing a VPN ..."=0D=0A> >=0D=0A> > Section 4.= 4: (paragraph 2)=0D=0A> > Change "... related to the mobility of the device= and ..." to "...=0D=0A> > related to the degree of device mobility and ...= "=0D=0A> >=0D=0A> > Section 4.4: (paragraph 2)=0D=0A> > Combine the final 2= sentances as follows:=0D=0A> > "When a device is aware that it has moved, = for instance when it=0D=0Achanges=0D=0A> > access points, the device SHOULD= refresh its location."=0D=0A> >=0D=0A> > Section 4.4: (last paragraph)=0D=0A= > > Change "... getting more recent location ..." to "... getting=0D=0Aupda= ted=0D=0A> > location ..." or "... obtaining a fresh location"=0D=0A> >=0D=0A= > > Section 5: (first paragraph)=0D=0A> > Consider re-writing as:=0D=0A> > = "A device (or a downstream signaling element) identifies an=0D=0Aemergency=0D= =0A> > call by an "address", which in most cases is a dialstring, although=0D= =0A> > other user interfaces may be used."=0D=0A> >=0D=0A> > Section 5: (pa= ragraph 2)=0D=0A> > First sentence has too many words modifying the word "e= lement".=0D=0A> Consider:=0D=0A> > "Note: It is undesirable for a user-inte= rface to enable a user to=0D=0Aplace=0D=0A> > an emergency call by pressing= a single button."=0D=0A> >=0D=0A> > Section 5: (paragraph 3)=0D=0A> > Cons= ider changing the first sentence:=0D=0A> > "... in other countries there ar= e several 3 digit numbers used for=0D=0A> > different types of emergency ca= lls."=0D=0A> >=0D=0A> > Section 5: (paragraph 6)=0D=0A> > Change "... some = entity needs to ..." to "... some entity on the=0D=0A> > signaling path mus= t ..."=0D=0A> >=0D=0A> > Section 5: (paragraph 9)=0D=0A> > Change "... from= North America, the home ..." to "... from North=0D=0A> > America, then whi= le in North America the home ..."=0D=0A> >=0D=0A> > Section 5: (last paragr= aph)=0D=0A> > Add a close parenthesis ")" after "dialstrings."=0D=0A> >=0D=0A= > > Section 6:=0D=0A> > Change "... is expected be supported ..." to "... i= s expected to be=0D=0A> > supported ..."=0D=0A> >=0D=0A> > Section 6.1:=0D=0A= > > Change "signaling Method" to "signaling method" (lower case).=0D=0A> >=0D= =0A> > Section 6.1: (number 1)=0D=0A> > Change "To: SHOULD" to "Request-URI= : SHOULD"=0D=0A> >=0D=0A> > Section 6.1: (number 2)=0D=0A> > Add a space be= tween [I-D.rosen-iptel-dialstring] and "with"=0D=0A> > Also change "sips MU= ST be ..." to "a sips URI MUST be ..."=0D=0A> >=0D=0A> > Section 6.2: (numb= er 1)=0D=0A> > Change "If it finds it it MUST:" to "If it finds the dialstr= ing it=0D=0A> MUST:"=0D=0A> > Also, change "... for the endpoint" to "... o= f the end device."=0D=0A(note=0D=0A> > that period was missing)=0D=0A> >=0D= =0A> > Section 6.3: (paragraph 3)=0D=0A> > Non-parallel sentence structure.= Consider re-writing the last=0D=0Asentence=0D=0A> as:=0D=0A> > "In the cas= e of civic location, the LoST server SHOULD report that=0D=0Athe=0D=0A> > s= ame mapping is good within a community name or even a street, as=0D=0Athis=0D= =0A> > is helpful for WiFi connected devices that roam and obtain civic=0D=0A= > > location from the AP to which they connect."=0D=0A> > (Or perhaps "Desp= ite the fact that civic location is uncommon for=0D=0Amobile=0D=0A> > devic= es, the LoST server SHOULD ...")=0D=0A> >=0D=0A> > Section 6.3: (paragraph = 4)=0D=0A> > Change "... URI of the service URN ..." to "... URI of a servic= e URN=0D=0A> ..."=0D=0A> >=0D=0A> > Section 6.3: (last paragraph)=0D=0A> > = Re-write the last sentence as: "The proxy then replaces the=0D=0ARequest-UR= I=0D=0A> > with the resulting PSAP URI."=0D=0A> > Or perhaps "The resulting= PSAP URI then replaces the Request-URI"=0D=0A> >=0D=0A> > Section 6.4: (fi= rst paragraph)=0D=0A> > Consider adding the phrase "Once the mapping to a P= SAP URI has been=0D=0A> > performed," to the begining of the paragraph (to = improve the flow of=0D=0Athe=0D=0A> > document).=0D=0A> >=0D=0A> > Section = 6.6:=0D=0A> > Change "The emergency dialstrings ..." to "Emergency dialstri= ngs=0D=0A..."=0D=0A> >=0D=0A> > Section 7: (paragraph 3)=0D=0A> > Change "F= or calls send with ..." to "For calls sent with ..."=0D=0A> >=0D=0A> > Sect= ion 8: (paragraph 1)=0D=0A> > Change "... media streams on RTP ... " to "..= =2E media stream using=0D=0ARTP=0D=0A> ..."=0D=0A> > or perhaps "... media = streams via RTP ..."=0D=0A> > Also, consider re-writing the 4th sentence as= :=0D=0A> > "Future IP-enabled PSAPs should accept a wider array of potentia= l=0D=0Amedia=0D=0A> > types."=0D=0A> >=0D=0A> > Section 8: (paragraph 2)=0D= =0A> > Add a period between "the offer" and "Silence suppression".=0D=0A> >=0D= =0A> > Section 10:=0D=0A> > Change "... it specifies use of several ..." to= "... it specifies=0D=0Athe=0D=0A> > use of several ..."=0D=0A> >=0D=0A> > = Section 10.1: (paragraph 2)=0D=0A> > Change "... DHCP is the LCP [RFC3118] = =2E.." to "... DHCP is the LCP,=0D=0A> > [RFC3118] ..." (add a comma)=0D=0A= > > Also, change "... spoofing would be ..." to "... spoofing is ..."=0D=0A= > >=0D=0A> > Section 10.1: (last paragraph)=0D=0A> > Add an 's' to change "= Client SHOULD" to "Clients SHOULD"=0D=0A> >=0D=0A> > Section 10.2: (last pa= ragraph)=0D=0A> > Change "... signaling would help significantly." to "... = signaling=0D=0Ahelps=0D=0A> > significantly."=0D=0A>=20=0D=0A>=20=0D=0A> =0D= =0A> _______________________________________________=0D=0A> Ecrit mailing l= ist=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/ecr= it=0D=0A=0D=0A-------------------------------------------------------------= -----------------------------------=0D=0AThis message is for the designated= recipient only and may=0D=0Acontain privileged, proprietary, or otherwise = private information. =20=0D=0AIf you have received it in error, please noti= fy the sender=0D=0Aimmediately and delete the original. Any unauthorized u= se of=0D=0Athis email is prohibited.=0D=0A---------------------------------= ---------------------------------------------------------------=0D=0A[mf2]=0D= =0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 01 18:18:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFRW-0005Xa-84; Fri, 01 Jun 2007 18:17:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFRU-0005Sp-Uh for ecrit@ietf.org; Fri, 01 Jun 2007 18:17:56 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuFRS-0006k0-5J for ecrit@ietf.org; Fri, 01 Jun 2007 18:17:56 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HuFPL-0004Te-G4; Fri, 01 Jun 2007 17:15:44 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Matt Lepinski'" , "'ECRIT'" , "'James M. Polk'" References: <465FA53B.80802@bbn.com> <0add01c7a449$6846b260$6601a8c0@cis.neustar.com> Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 Date: Fri, 1 Jun 2007 18:17:49 -0400 Message-ID: <0cb001c7a49a$b2844440$6601a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcekCFEPcS0iQckvRVWGxa+1mAstOgAQAffgABMPLZAAAWw9QA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: c375f2012a4f820b0c0fd6fb14a28357 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org If by that you mean the endpoint gets location, recognizes an emergency call, but does not route, then the proxy server has to route. That case is complex because without the LoST query, the endpoint doesn't have the local dialstring(s). If that was not what you mean, then who routes? Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Friday, June 01, 2007 5:35 PM > To: Brian Rosen; Matt Lepinski; ECRIT; James M. Polk > Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 > > I think that there is one other variant on two. > > The End-point makes the call the service URN and includes a provided > locationURI. Outbound-proxy does nothing special. > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, 1 June 2007 10:36 PM > > To: 'Matt Lepinski'; 'ECRIT'; 'James M. Polk' > > Subject: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 > > > > Thanks for your comments. > > > > The BCP really shouldn't be SIP specific. We need to broaden it to, > for > > example, XMPP. We can have SIP specific information, but it should be > > discussed as just that. > > > > There is a consensus, I believe, on how to mark emergency calls, > > represented > > by the thread, but chairs have to call consensus, not me. I think > there > > are > > three cases: > > 1. The endpoint recognizes it's an emergency call, does the LoST > routing, > > and passes the call to its outbound proxy server. In this case the > > Request > > URI will be the PSAP URI from LoST, and adds a Route header with the > > service > > URN. > > 2. The endpoint recognizes it's an emergency call, but doesn't LoST > route > > it. In this case the Request URI would be the service URN. The > outbound > > proxy server would do the LoST routing, put the Route header with the > > service URN in and change the Request URI to the PSAP URI. > > 3. The endpoint doesn't even recognize it's an emergency call. In > this > > case, the endpoint would put the dialstring in the Request URI. The > > outbound proxy would behave as in 2 above. > > > > When the PSAP gets the call, it will always have its URI in the > Request > > URI, > > and there will be a service URN in a Route header. > > > > Probably, phonebcp should say that more clearly. > > > > Brian > > > > > -----Original Message----- > > > From: Matt Lepinski [mailto:mlepinski@bbn.com] > > > Sent: Friday, June 01, 2007 12:49 AM > > > To: ECRIT; James M. Polk; br@brianrosen.net > > > Subject: Comments on: draft-ietf-ecrit-phonebcp-01 > > > > > > Brian and James: > > > > > > First, two very high level questions. > > > > > > A) [Is this document supposed to be SIP-Centric?] It is unclear to > me > > > whether the document is intended as a BCP for SIP User Agents and > SIP > > > proxies, or whether it is more generally a BCP for end points and > > > signaling-path devices which may or may not use SIP. For instance, > > > Section 6.4 is written as though SIP signaling were a special case, > and > > > yet paragraph four of Section 5 indicates that all emergency calls > on > > > the wire should contain a Route header (which is a SIP-specific > > > signaling component). Personally, I don't care whether or not the > > > document is SIP centric, or whether SIP is a special case, as long > as > > > the document is consistent. > > > > > > B) [Is there consensus on how to mark emergency calls?] The current > > > version of phonebcp indicates that (in the normal case when > end-points > > > perform the LoST mapping) emergency calls are marked by putting the > URN > > > in a Route header (with a "loose" parameter that I'm not familiar > with > > > ... can someone provide me with a reference) and that the URN is > placed > > > in the Request-URI when the end-point is unable to perform the LoST > > > mapping). Personally, I don't understand the current mechanism > because > > > I'm not sure what an "ordinary" (RFC3261-compliant) proxy does when > it > > > sees a service URN in the top Route header. However, given the long > > > discussion that occured on call marking in January (See: > > > http://www1.ietf.org/mail-archive/web/ecrit/current/msg02963.html), > > > perhaps the more important question is "Has consensus been reached > that > > > (something like) the current mechanism is an appropriate way to mark > > > messages?" > > > > > > --------------------------------- > > > More detailed comments: > > > > > > Section 2: (paragraph 3 - number 2) > > > Is it clear what the "visited location's emergency number" means in > this > > > context? > > > Consider changing to "the local emergency number for its current > > > location" or providing a forward reference to the discussion of > > > dial-strings in Section 5. > > > > > > Section 2: (paragraph 4) > > > I agree with Barbara that if this is intended to an overview of call > > > setup for the special case of an Ethernet connected phone then the > > > bullets should match up more clearly with the numbered items in the > > > previous paragraph. > > > > > > Section 2: (last paragraph) > > > It is unclear whether the antecedent of "it" in the last paragraph > is > > > [RFC4103] or [RFC4504]. > > > > > > Section 3: > > > Consider changing "should support" to "SHOULD support" > > > > > > Section 3: (paragraph 2) > > > It seems that the point of this paragraph is to say that a certain > class > > > of devices that communicates over IP networks should support > emergency > > > calls. However, I find the phrase "using current (evolving) > standards" > > > to be unclear and in particular I'm not sure what the phrase > modifies. > > > (E.g. Do you mean "Devices that create media sessions using current > > > (evolving) standards and exchange audio ...") > > > > > > Section 4: (first paragraph) > > > Consider replacing "the norm" with "required" (or a similar word). I > > > think the point is not that automatic location is common/normal but > that > > > it is necessary since most users are unable to provide accurate > > location. > > > > > > Section 4.1: (first paragraph) > > > I think "cellular" (or "traditional wireless") is more precise than > > > "mobile". > > > > > > Section 4.2: (first paragraph ... also, the last paragraph) > > > Consider changing the phrase "the desired result" to something like > "an > > > equivalent result", or perhaps something even more explicit. > > > > > > Section 4.2: (first paragraph) > > > Consider addition a phrase to the last sentence indicating why it is > > > recommended that the network support a standardized LCP. (This may > not > > > be obvious to the reader). Also, consider changing "recommended" to > > > "RECOMMENDED". > > > > > > Section 4.2: (paragraph 2) > > > Given that the paragraph covers what both devices and access > networks > > > MUST support, consider changing "For all other devices" to "In all > other > > > scenarios". > > > > > > Section 4.3: (paragraph 3) > > > The term "geo-location" is not used in RFC 3825 to describe a > > > lat/lon/alt - style location. (Instead it uses terms like a > > > "coordinate-based geolocation"). Also, given that the "geolocation" > > > header allows for civic locations, I think using geo-location here > is > > > potentially confusing. > > > Note: This comment also applies to the use of "geo reported" in the > > > third paragraph of Section 6.3 > > > > > > Section 4.4: (last paragraph) > > > Consider re-writing the second-to-the-last sentence as: "Certain > > > commonly-used techniques for measuring location create a conflict > > > between the time it takes to generate a precise location and the > desire > > > to route the call quickly." (Also, in the following sentence I think > > > "precise" is a better word than "accurate") > > > > > > Section 5: (paragraphs 5 and 6) > > > Paragraph 5 says that devices MUST mark calls using a service:sos > URN. > > > However, paragraph 6 says that mapping from dialstring to URN SHOULD > be > > > done by the endpoint. Either both paragraphs should use "MUST" or > else > > > they should both use "SHOULD". > > > > > > Section 5: (paragraph 8) > > > I don't understand what it means to be "roaming" or "nomadic" in a > > > system where there is no "visited network" > > > > > > Section 5: (last paragraph) > > > The last sentence of this paragraph seems to be redundent. Consider > > > deleting it. > > > > > > Section 6.1: > > > I agree with Barbara that the use of IPSec should not be prohibited > by > > > this BCP. > > > > > > Section 6.1: (number 6) > > > These instructions are for the User Agent, P-Asserted-Identity > headers > > > and Identity headers should not be inserted by the UA > > > > > > Section 6.1: (number 10) > > > This item is unclear to me. Is the author's intention that this item > > > handles the case where a UA does not know its own location? If so, I > > > guess that updating this item should be deferred until consensus is > > > reached on location-hiding. > > > > > > Section 6.1: > > > Consider Re-ordering the items as: > > > 11, 10, 12, 14, 15, 13 > > > Also, consider deleting 12, I believe it is redundent given 9, 10 > and > > 11. > > > > > > Section 6.2: (number 1) > > > Consider adding an example after "... URN appropriate for the > emergency > > > dialstring." That is, consider adding (e.g., ...) > > > > > > Section 6.2: (number 3) > > > I'm afraid that I don't understand the meaning of this sentence. > > > > > > Section 6.3: (paragraph 3) > > > The sentence that begins "This can be an enclosing ..." is unclear > to > > > me. Are you suggesting that when a PSAP coverage region is complex, > that > > > a LoST server SHOULD return a simple polygon that (a) contains the > > > location of the device; and (b) is entirely contained within the > PSAP > > > coverage region? > > > > > > Section 6.5: (number 3) > > > This seems to imply that proxies should expect to SUBSCRIBE to > Presence. > > > Do you mean that proxies should expect the PSAP to SUBSCRIBE to > > Presence? > > > > > > Section 6.5: (number 4) > > > I'm not very familiar with Session Timers, can you provide a > reference. > > > > > > Section 6.6: > > > I'm afraid I don't understand the parenthetical remark after the > "Call > > > Forward" bullet. (Consider removing the remark or re-wording it if > it is > > > important). > > > > > > Section 7: > > > Given the text in Section 4.4 it seems to me that the first > paragraph of > > > Section 7 is redundent and should be deleted. > > > > > > Section 10.2: > > > Given the difficulty of implementing location signing in a useful > > > manner, I think that that either paragraph 2 should either be > removed or > > > else it should reference some other document that explains location > > > signing in more detail. (That is, one paragraph does not do location > > > signing justice and it seems irresponsible to strongly recommend > > > location signing without providing additionaly guidence to the > > > implementor). > > > > > > ------------------------------------------------------------------- > > > Minor Nits: (That don't change the meaning of the text) > > > > > > Section 2: (last paragraph) > > > Put a space between [RFC4103] and "media" > > > > > > Section 3: (paragraph 1) > > > Add commas to second sentence "Future PSAPs will, however, support > ..." > > > and remove the extra period at the end of the sentence > > > > > > Section 4.1: (paragraph 2) > > > Change "... where it is the access network that knows the location > ..." > > > to "... when only the access network knows the location ..." > > > > > > Section 4.4: (paragraph 1) > > > Change "... process engaged from establishing a VPN ... " to "... > > > process engaged by establishing a VPN ..." > > > > > > Section 4.4: (paragraph 2) > > > Change "... related to the mobility of the device and ..." to "... > > > related to the degree of device mobility and ..." > > > > > > Section 4.4: (paragraph 2) > > > Combine the final 2 sentances as follows: > > > "When a device is aware that it has moved, for instance when it > changes > > > access points, the device SHOULD refresh its location." > > > > > > Section 4.4: (last paragraph) > > > Change "... getting more recent location ..." to "... getting > updated > > > location ..." or "... obtaining a fresh location" > > > > > > Section 5: (first paragraph) > > > Consider re-writing as: > > > "A device (or a downstream signaling element) identifies an > emergency > > > call by an "address", which in most cases is a dialstring, although > > > other user interfaces may be used." > > > > > > Section 5: (paragraph 2) > > > First sentence has too many words modifying the word "element". > > Consider: > > > "Note: It is undesirable for a user-interface to enable a user to > place > > > an emergency call by pressing a single button." > > > > > > Section 5: (paragraph 3) > > > Consider changing the first sentence: > > > "... in other countries there are several 3 digit numbers used for > > > different types of emergency calls." > > > > > > Section 5: (paragraph 6) > > > Change "... some entity needs to ..." to "... some entity on the > > > signaling path must ..." > > > > > > Section 5: (paragraph 9) > > > Change "... from North America, the home ..." to "... from North > > > America, then while in North America the home ..." > > > > > > Section 5: (last paragraph) > > > Add a close parenthesis ")" after "dialstrings." > > > > > > Section 6: > > > Change "... is expected be supported ..." to "... is expected to be > > > supported ..." > > > > > > Section 6.1: > > > Change "signaling Method" to "signaling method" (lower case). > > > > > > Section 6.1: (number 1) > > > Change "To: SHOULD" to "Request-URI: SHOULD" > > > > > > Section 6.1: (number 2) > > > Add a space between [I-D.rosen-iptel-dialstring] and "with" > > > Also change "sips MUST be ..." to "a sips URI MUST be ..." > > > > > > Section 6.2: (number 1) > > > Change "If it finds it it MUST:" to "If it finds the dialstring it > > MUST:" > > > Also, change "... for the endpoint" to "... of the end device." > (note > > > that period was missing) > > > > > > Section 6.3: (paragraph 3) > > > Non-parallel sentence structure. Consider re-writing the last > sentence > > as: > > > "In the case of civic location, the LoST server SHOULD report that > the > > > same mapping is good within a community name or even a street, as > this > > > is helpful for WiFi connected devices that roam and obtain civic > > > location from the AP to which they connect." > > > (Or perhaps "Despite the fact that civic location is uncommon for > mobile > > > devices, the LoST server SHOULD ...") > > > > > > Section 6.3: (paragraph 4) > > > Change "... URI of the service URN ..." to "... URI of a service URN > > ..." > > > > > > Section 6.3: (last paragraph) > > > Re-write the last sentence as: "The proxy then replaces the > Request-URI > > > with the resulting PSAP URI." > > > Or perhaps "The resulting PSAP URI then replaces the Request-URI" > > > > > > Section 6.4: (first paragraph) > > > Consider adding the phrase "Once the mapping to a PSAP URI has been > > > performed," to the begining of the paragraph (to improve the flow of > the > > > document). > > > > > > Section 6.6: > > > Change "The emergency dialstrings ..." to "Emergency dialstrings > ..." > > > > > > Section 7: (paragraph 3) > > > Change "For calls send with ..." to "For calls sent with ..." > > > > > > Section 8: (paragraph 1) > > > Change "... media streams on RTP ... " to "... media stream using > RTP > > ..." > > > or perhaps "... media streams via RTP ..." > > > Also, consider re-writing the 4th sentence as: > > > "Future IP-enabled PSAPs should accept a wider array of potential > media > > > types." > > > > > > Section 8: (paragraph 2) > > > Add a period between "the offer" and "Silence suppression". > > > > > > Section 10: > > > Change "... it specifies use of several ..." to "... it specifies > the > > > use of several ..." > > > > > > Section 10.1: (paragraph 2) > > > Change "... DHCP is the LCP [RFC3118] ..." to "... DHCP is the LCP, > > > [RFC3118] ..." (add a comma) > > > Also, change "... spoofing would be ..." to "... spoofing is ..." > > > > > > Section 10.1: (last paragraph) > > > Add an 's' to change "Client SHOULD" to "Clients SHOULD" > > > > > > Section 10.2: (last paragraph) > > > Change "... signaling would help significantly." to "... signaling > helps > > > significantly." > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 01 18:24:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFXL-00044y-1q; Fri, 01 Jun 2007 18:23:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFXJ-00044t-U6 for ecrit@ietf.org; Fri, 01 Jun 2007 18:23:57 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuFXJ-0008Ee-68 for ecrit@ietf.org; Fri, 01 Jun 2007 18:23:57 -0400 X-SEF-Processed: 5_0_0_910__2007_06_01_17_31_23 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 01 Jun 2007 17:31:23 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 17:23:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 Date: Fri, 1 Jun 2007 17:23:55 -0500 Message-ID: In-Reply-To: <0cb001c7a49a$b2844440$6601a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 Thread-Index: AcekCFEPcS0iQckvRVWGxa+1mAstOgAQAffgABMPLZAAAWw9QAAAS3KA References: <465FA53B.80802@bbn.com> <0add01c7a449$6846b260$6601a8c0@cis.neustar.com> <0cb001c7a49a$b2844440$6601a8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Matt Lepinski" , "ECRIT" , "James M. Polk" X-OriginalArrivalTime: 01 Jun 2007 22:23:56.0820 (UTC) FILETIME=[8B5A8540:01C7A49B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I was assuming that the end-point is given a location URI, local=0D=0Adials= ring, and service URNs. Say in the location hiding case.=0D=0A=0D=0A=0D=0A>= -----Original Message-----=0D=0A> From: Brian Rosen [mailto:br@brianrosen.= net]=0D=0A> Sent: Saturday, 2 June 2007 8:18 AM=0D=0A> To: Winterbottom, Ja= mes; 'Matt Lepinski'; 'ECRIT'; 'James M. Polk'=0D=0A> Subject: RE: [Ecrit] = RE: Comments on: draft-ietf-ecrit-phonebcp-01=0D=0A>=20=0D=0A> If by that y= ou mean the endpoint gets location, recognizes an=0D=0Aemergency=0D=0A> cal= l, but does not route, then the proxy server has to route. That=0D=0Acase=0D= =0A> is=0D=0A> complex because without the LoST query, the endpoint doesn't= have the=0D=0A> local=0D=0A> dialstring(s).=0D=0A>=20=0D=0A> If that was n= ot what you mean, then who routes=3F=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A= > > -----Original Message-----=0D=0A> > From: Winterbottom, James [mailto:J= ames.Winterbottom@andrew.com]=0D=0A> > Sent: Friday, June 01, 2007 5:35 PM=0D= =0A> > To: Brian Rosen; Matt Lepinski; ECRIT; James M. Polk=0D=0A> > Subjec= t: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01=0D=0A> >=0D=0A= > > I think that there is one other variant on two.=0D=0A> >=0D=0A> > The E= nd-point makes the call the service URN and includes a provided=0D=0A> > lo= cationURI. Outbound-proxy does nothing special.=0D=0A> >=0D=0A> > > -----Or= iginal Message-----=0D=0A> > > From: Brian Rosen [mailto:br@brianrosen.net]=0D= =0A> > > Sent: Friday, 1 June 2007 10:36 PM=0D=0A> > > To: 'Matt Lepinski';= 'ECRIT'; 'James M. Polk'=0D=0A> > > Subject: [Ecrit] RE: Comments on: draf= t-ietf-ecrit-phonebcp-01=0D=0A> > >=0D=0A> > > Thanks for your comments.=0D= =0A> > >=0D=0A> > > The BCP really shouldn't be SIP specific. We need to b= roaden it=0D=0Ato,=0D=0A> > for=0D=0A> > > example, XMPP. We can have SIP = specific information, but it=0D=0Ashould be=0D=0A> > > discussed as just th= at.=0D=0A> > >=0D=0A> > > There is a consensus, I believe, on how to mark e= mergency calls,=0D=0A> > > represented=0D=0A> > > by the thread, but chairs= have to call consensus, not me. I think=0D=0A> > there=0D=0A> > > are=0D=0A= > > > three cases:=0D=0A> > > 1. The endpoint recognizes it's an emergency = call, does the LoST=0D=0A> > routing,=0D=0A> > > and passes the call to its= outbound proxy server. In this case=0D=0Athe=0D=0A> > > Request=0D=0A> > = > URI will be the PSAP URI from LoST, and adds a Route header with=0D=0Athe=0D= =0A> > > service=0D=0A> > > URN.=0D=0A> > > 2. The endpoint recognizes it's= an emergency call, but doesn't=0D=0ALoST=0D=0A> > route=0D=0A> > > it. In= this case the Request URI would be the service URN. The=0D=0A> > outbound=0D= =0A> > > proxy server would do the LoST routing, put the Route header with=0D= =0Athe=0D=0A> > > service URN in and change the Request URI to the PSAP URI= =2E=0D=0A> > > 3. The endpoint doesn't even recognize it's an emergency cal= l. In=0D=0A> > this=0D=0A> > > case, the endpoint would put the dialstring= in the Request URI.=0D=0AThe=0D=0A> > > outbound proxy would behave as in = 2 above.=0D=0A> > >=0D=0A> > > When the PSAP gets the call, it will always = have its URI in the=0D=0A> > Request=0D=0A> > > URI,=0D=0A> > > and there w= ill be a service URN in a Route header.=0D=0A> > >=0D=0A> > > Probably, pho= nebcp should say that more clearly.=0D=0A> > >=0D=0A> > > Brian=0D=0A> > >=0D= =0A> > > > -----Original Message-----=0D=0A> > > > From: Matt Lepinski [mai= lto:mlepinski@bbn.com]=0D=0A> > > > Sent: Friday, June 01, 2007 12:49 AM=0D= =0A> > > > To: ECRIT; James M. Polk; br@brianrosen.net=0D=0A> > > > Subject= : Comments on: draft-ietf-ecrit-phonebcp-01=0D=0A> > > >=0D=0A> > > > Brian= and James:=0D=0A> > > >=0D=0A> > > > First, two very high level questions.=0D= =0A> > > >=0D=0A> > > > A) [Is this document supposed to be SIP-Centric=3F]= It is unclear=0D=0Ato=0D=0A> > me=0D=0A> > > > whether the document is int= ended as a BCP for SIP User Agents=0D=0Aand=0D=0A> > SIP=0D=0A> > > > proxi= es, or whether it is more generally a BCP for end points=0D=0Aand=0D=0A> > = > > signaling-path devices which may or may not use SIP. For=0D=0Ainstance,=0D= =0A> > > > Section 6.4 is written as though SIP signaling were a special=0D= =0Acase,=0D=0A> > and=0D=0A> > > > yet paragraph four of Section 5 indicate= s that all emergency=0D=0Acalls=0D=0A> > on=0D=0A> > > > the wire should co= ntain a Route header (which is a SIP-specific=0D=0A> > > > signaling compon= ent). Personally, I don't care whether or not=0D=0Athe=0D=0A> > > > documen= t is SIP centric, or whether SIP is a special case, as=0D=0Along=0D=0A> > a= s=0D=0A> > > > the document is consistent.=0D=0A> > > >=0D=0A> > > > B) [Is= there consensus on how to mark emergency calls=3F] The=0D=0Acurrent=0D=0A>= > > > version of phonebcp indicates that (in the normal case when=0D=0A> >= end-points=0D=0A> > > > perform the LoST mapping) emergency calls are mark= ed by putting=0D=0Athe=0D=0A> > URN=0D=0A> > > > in a Route header (with a = "loose" parameter that I'm not=0D=0Afamiliar=0D=0A> > with=0D=0A> > > > ...= can someone provide me with a reference) and that the URN is=0D=0A> > plac= ed=0D=0A> > > > in the Request-URI when the end-point is unable to perform = the=0D=0ALoST=0D=0A> > > > mapping). Personally, I don't understand the cur= rent mechanism=0D=0A> > because=0D=0A> > > > I'm not sure what an "ordinary= " (RFC3261-compliant) proxy does=0D=0Awhen=0D=0A> > it=0D=0A> > > > sees a = service URN in the top Route header. However, given the=0D=0Along=0D=0A> > = > > discussion that occured on call marking in January (See:=0D=0A> > > >=0D= =0Ahttp://www1.ietf.org/mail-archive/web/ecrit/current/msg02963.html),=0D=0A= > > > > perhaps the more important question is "Has consensus been=0D=0Area= ched=0D=0A> > that=0D=0A> > > > (something like) the current mechanism is a= n appropriate way to=0D=0Amark=0D=0A> > > > messages=3F"=0D=0A> > > >=0D=0A= > > > > ---------------------------------=0D=0A> > > > More detailed commen= ts:=0D=0A> > > >=0D=0A> > > > Section 2: (paragraph 3 - number 2)=0D=0A> > = > > Is it clear what the "visited location's emergency number" means=0D=0Ai= n=0D=0A> > this=0D=0A> > > > context=3F=0D=0A> > > > Consider changing to "= the local emergency number for its current=0D=0A> > > > location" or provid= ing a forward reference to the discussion of=0D=0A> > > > dial-strings in S= ection 5.=0D=0A> > > >=0D=0A> > > > Section 2: (paragraph 4)=0D=0A> > > > I= agree with Barbara that if this is intended to an overview of=0D=0Acall=0D= =0A> > > > setup for the special case of an Ethernet connected phone then=0D= =0Athe=0D=0A> > > > bullets should match up more clearly with the numbered = items in=0D=0Athe=0D=0A> > > > previous paragraph.=0D=0A> > > >=0D=0A> > > = > Section 2: (last paragraph)=0D=0A> > > > It is unclear whether the antece= dent of "it" in the last=0D=0Aparagraph=0D=0A> > is=0D=0A> > > > [RFC4103] = or [RFC4504].=0D=0A> > > >=0D=0A> > > > Section 3:=0D=0A> > > > Consider ch= anging "should support" to "SHOULD support"=0D=0A> > > >=0D=0A> > > > Secti= on 3: (paragraph 2)=0D=0A> > > > It seems that the point of this paragraph = is to say that a=0D=0Acertain=0D=0A> > class=0D=0A> > > > of devices that c= ommunicates over IP networks should support=0D=0A> > emergency=0D=0A> > > >= calls. However, I find the phrase "using current (evolving)=0D=0A> > stand= ards"=0D=0A> > > > to be unclear and in particular I'm not sure what the ph= rase=0D=0A> > modifies.=0D=0A> > > > (E.g. Do you mean "Devices that create= media sessions using=0D=0Acurrent=0D=0A> > > > (evolving) standards and ex= change audio ...")=0D=0A> > > >=0D=0A> > > > Section 4: (first paragraph)=0D= =0A> > > > Consider replacing "the norm" with "required" (or a similar=0D=0A= word). I=0D=0A> > > > think the point is not that automatic location is com= mon/normal=0D=0Abut=0D=0A> > that=0D=0A> > > > it is necessary since most u= sers are unable to provide accurate=0D=0A> > > location.=0D=0A> > > >=0D=0A= > > > > Section 4.1: (first paragraph)=0D=0A> > > > I think "cellular" (or = "traditional wireless") is more precise=0D=0Athan=0D=0A> > > > "mobile".=0D= =0A> > > >=0D=0A> > > > Section 4.2: (first paragraph ... also, the last pa= ragraph)=0D=0A> > > > Consider changing the phrase "the desired result" to = something=0D=0Alike=0D=0A> > "an=0D=0A> > > > equivalent result", or perhap= s something even more explicit.=0D=0A> > > >=0D=0A> > > > Section 4.2: (fir= st paragraph)=0D=0A> > > > Consider addition a phrase to the last sentence = indicating why=0D=0Ait is=0D=0A> > > > recommended that the network support= a standardized LCP. (This=0D=0Amay=0D=0A> > not=0D=0A> > > > be obvious to= the reader). Also, consider changing "recommended"=0D=0Ato=0D=0A> > > > "R= ECOMMENDED".=0D=0A> > > >=0D=0A> > > > Section 4.2: (paragraph 2)=0D=0A> > = > > Given that the paragraph covers what both devices and access=0D=0A> > n= etworks=0D=0A> > > > MUST support, consider changing "For all other devices= " to "In=0D=0Aall=0D=0A> > other=0D=0A> > > > scenarios".=0D=0A> > > >=0D=0A= > > > > Section 4.3: (paragraph 3)=0D=0A> > > > The term "geo-location" is = not used in RFC 3825 to describe a=0D=0A> > > > lat/lon/alt - style locatio= n. (Instead it uses terms like a=0D=0A> > > > "coordinate-based geolocation= "). Also, given that the=0D=0A"geolocation"=0D=0A> > > > header allows for = civic locations, I think using geo-location=0D=0Ahere=0D=0A> > is=0D=0A> > = > > potentially confusing.=0D=0A> > > > Note: This comment also applies to = the use of "geo reported" in=0D=0Athe=0D=0A> > > > third paragraph of Secti= on 6.3=0D=0A> > > >=0D=0A> > > > Section 4.4: (last paragraph)=0D=0A> > > = > Consider re-writing the second-to-the-last sentence as: "Certain=0D=0A> >= > > commonly-used techniques for measuring location create a=0D=0Aconflict=0D= =0A> > > > between the time it takes to generate a precise location and the=0D= =0A> > desire=0D=0A> > > > to route the call quickly." (Also, in the follow= ing sentence I=0D=0Athink=0D=0A> > > > "precise" is a better word than "acc= urate")=0D=0A> > > >=0D=0A> > > > Section 5: (paragraphs 5 and 6)=0D=0A> > = > > Paragraph 5 says that devices MUST mark calls using a=0D=0Aservice:sos=0D= =0A> > URN.=0D=0A> > > > However, paragraph 6 says that mapping from dialst= ring to URN=0D=0ASHOULD=0D=0A> > be=0D=0A> > > > done by the endpoint. Eith= er both paragraphs should use "MUST"=0D=0Aor=0D=0A> > else=0D=0A> > > > the= y should both use "SHOULD".=0D=0A> > > >=0D=0A> > > > Section 5: (paragraph= 8)=0D=0A> > > > I don't understand what it means to be "roaming" or "nomad= ic" in=0D=0Aa=0D=0A> > > > system where there is no "visited network"=0D=0A= > > > >=0D=0A> > > > Section 5: (last paragraph)=0D=0A> > > > The last sent= ence of this paragraph seems to be redundent.=0D=0AConsider=0D=0A> > > > de= leting it.=0D=0A> > > >=0D=0A> > > > Section 6.1:=0D=0A> > > > I agree with= Barbara that the use of IPSec should not be=0D=0Aprohibited=0D=0A> > by=0D= =0A> > > > this BCP.=0D=0A> > > >=0D=0A> > > > Section 6.1: (number 6)=0D=0A= > > > > These instructions are for the User Agent, P-Asserted-Identity=0D=0A= > > headers=0D=0A> > > > and Identity headers should not be inserted by the= UA=0D=0A> > > >=0D=0A> > > > Section 6.1: (number 10)=0D=0A> > > > This it= em is unclear to me. Is the author's intention that this=0D=0Aitem=0D=0A> >= > > handles the case where a UA does not know its own location=3F If=0D=0A= so, I=0D=0A> > > > guess that updating this item should be deferred until c= onsensus=0D=0Ais=0D=0A> > > > reached on location-hiding.=0D=0A> > > >=0D=0A= > > > > Section 6.1:=0D=0A> > > > Consider Re-ordering the items as:=0D=0A>= > > > 11, 10, 12, 14, 15, 13=0D=0A> > > > Also, consider deleting 12, I be= lieve it is redundent given 9,=0D=0A10=0D=0A> > and=0D=0A> > > 11.=0D=0A> >= > >=0D=0A> > > > Section 6.2: (number 1)=0D=0A> > > > Consider adding an e= xample after "... URN appropriate for the=0D=0A> > emergency=0D=0A> > > > d= ialstring." That is, consider adding (e.g., ...)=0D=0A> > > >=0D=0A> > > > = Section 6.2: (number 3)=0D=0A> > > > I'm afraid that I don't understand the= meaning of this sentence.=0D=0A> > > >=0D=0A> > > > Section 6.3: (paragrap= h 3)=0D=0A> > > > The sentence that begins "This can be an enclosing ..." i= s=0D=0Aunclear=0D=0A> > to=0D=0A> > > > me. Are you suggesting that when a = PSAP coverage region is=0D=0Acomplex,=0D=0A> > that=0D=0A> > > > a LoST ser= ver SHOULD return a simple polygon that (a) contains=0D=0Athe=0D=0A> > > > = location of the device; and (b) is entirely contained within the=0D=0A> > P= SAP=0D=0A> > > > coverage region=3F=0D=0A> > > >=0D=0A> > > > Section 6.5: = (number 3)=0D=0A> > > > This seems to imply that proxies should expect to S= UBSCRIBE to=0D=0A> > Presence.=0D=0A> > > > Do you mean that proxies should= expect the PSAP to SUBSCRIBE to=0D=0A> > > Presence=3F=0D=0A> > > >=0D=0A>= > > > Section 6.5: (number 4)=0D=0A> > > > I'm not very familiar with Sess= ion Timers, can you provide a=0D=0A> > reference.=0D=0A> > > >=0D=0A> > > >= Section 6.6:=0D=0A> > > > I'm afraid I don't understand the parenthetical = remark after the=0D=0A> > "Call=0D=0A> > > > Forward" bullet. (Consider rem= oving the remark or re-wording it=0D=0Aif=0D=0A> > it is=0D=0A> > > > impor= tant).=0D=0A> > > >=0D=0A> > > > Section 7:=0D=0A> > > > Given the text in = Section 4.4 it seems to me that the first=0D=0A> > paragraph of=0D=0A> > > = > Section 7 is redundent and should be deleted.=0D=0A> > > >=0D=0A> > > > S= ection 10.2:=0D=0A> > > > Given the difficulty of implementing location sig= ning in a=0D=0Auseful=0D=0A> > > > manner, I think that that either paragra= ph 2 should either be=0D=0A> > removed or=0D=0A> > > > else it should refer= ence some other document that explains=0D=0Alocation=0D=0A> > > > signing i= n more detail. (That is, one paragraph does not do=0D=0Alocation=0D=0A> > >= > signing justice and it seems irresponsible to strongly recommend=0D=0A> = > > > location signing without providing additionaly guidence to the=0D=0A>= > > > implementor).=0D=0A> > > >=0D=0A> > > >=0D=0A-----------------------= --------------------------------------------=0D=0A> > > > Minor Nits: (That= don't change the meaning of the text)=0D=0A> > > >=0D=0A> > > > Section 2:= (last paragraph)=0D=0A> > > > Put a space between [RFC4103] and "media"=0D= =0A> > > >=0D=0A> > > > Section 3: (paragraph 1)=0D=0A> > > > Add commas to= second sentence "Future PSAPs will, however,=0D=0Asupport=0D=0A> > ..."=0D= =0A> > > > and remove the extra period at the end of the sentence=0D=0A> > = > >=0D=0A> > > > Section 4.1: (paragraph 2)=0D=0A> > > > Change "... where = it is the access network that knows the=0D=0Alocation=0D=0A> > ..."=0D=0A> = > > > to "... when only the access network knows the location ..."=0D=0A> >= > >=0D=0A> > > > Section 4.4: (paragraph 1)=0D=0A> > > > Change "... proce= ss engaged from establishing a VPN ... " to=0D=0A"...=0D=0A> > > > process = engaged by establishing a VPN ..."=0D=0A> > > >=0D=0A> > > > Section 4.4: (= paragraph 2)=0D=0A> > > > Change "... related to the mobility of the device= and ..." to=0D=0A"...=0D=0A> > > > related to the degree of device mobilit= y and ..."=0D=0A> > > >=0D=0A> > > > Section 4.4: (paragraph 2)=0D=0A> > > = > Combine the final 2 sentances as follows:=0D=0A> > > > "When a device is = aware that it has moved, for instance when it=0D=0A> > changes=0D=0A> > > >= access points, the device SHOULD refresh its location."=0D=0A> > > >=0D=0A= > > > > Section 4.4: (last paragraph)=0D=0A> > > > Change "... getting more= recent location ..." to "... getting=0D=0A> > updated=0D=0A> > > > locatio= n ..." or "... obtaining a fresh location"=0D=0A> > > >=0D=0A> > > > Sectio= n 5: (first paragraph)=0D=0A> > > > Consider re-writing as:=0D=0A> > > > "A= device (or a downstream signaling element) identifies an=0D=0A> > emergenc= y=0D=0A> > > > call by an "address", which in most cases is a dialstring,=0D= =0Aalthough=0D=0A> > > > other user interfaces may be used."=0D=0A> > > >=0D= =0A> > > > Section 5: (paragraph 2)=0D=0A> > > > First sentence has too man= y words modifying the word "element".=0D=0A> > > Consider:=0D=0A> > > > "No= te: It is undesirable for a user-interface to enable a user=0D=0Ato=0D=0A> = > place=0D=0A> > > > an emergency call by pressing a single button."=0D=0A>= > > >=0D=0A> > > > Section 5: (paragraph 3)=0D=0A> > > > Consider changing= the first sentence:=0D=0A> > > > "... in other countries there are several= 3 digit numbers used=0D=0Afor=0D=0A> > > > different types of emergency ca= lls."=0D=0A> > > >=0D=0A> > > > Section 5: (paragraph 6)=0D=0A> > > > Chang= e "... some entity needs to ..." to "... some entity on the=0D=0A> > > > si= gnaling path must ..."=0D=0A> > > >=0D=0A> > > > Section 5: (paragraph 9)=0D= =0A> > > > Change "... from North America, the home ..." to "... from North=0D= =0A> > > > America, then while in North America the home ..."=0D=0A> > > >=0D= =0A> > > > Section 5: (last paragraph)=0D=0A> > > > Add a close parenthesis= ")" after "dialstrings."=0D=0A> > > >=0D=0A> > > > Section 6:=0D=0A> > > >= Change "... is expected be supported ..." to "... is expected to=0D=0Abe=0D= =0A> > > > supported ..."=0D=0A> > > >=0D=0A> > > > Section 6.1:=0D=0A> > >= > Change "signaling Method" to "signaling method" (lower case).=0D=0A> > >= >=0D=0A> > > > Section 6.1: (number 1)=0D=0A> > > > Change "To: SHOULD" to= "Request-URI: SHOULD"=0D=0A> > > >=0D=0A> > > > Section 6.1: (number 2)=0D= =0A> > > > Add a space between [I-D.rosen-iptel-dialstring] and "with"=0D=0A= > > > > Also change "sips MUST be ..." to "a sips URI MUST be ..."=0D=0A> >= > >=0D=0A> > > > Section 6.2: (number 1)=0D=0A> > > > Change "If it finds = it it MUST:" to "If it finds the dialstring=0D=0Ait=0D=0A> > > MUST:"=0D=0A= > > > > Also, change "... for the endpoint" to "... of the end device."=0D=0A= > > (note=0D=0A> > > > that period was missing)=0D=0A> > > >=0D=0A> > > > S= ection 6.3: (paragraph 3)=0D=0A> > > > Non-parallel sentence structure. Con= sider re-writing the last=0D=0A> > sentence=0D=0A> > > as:=0D=0A> > > > "In= the case of civic location, the LoST server SHOULD report=0D=0Athat=0D=0A>= > the=0D=0A> > > > same mapping is good within a community name or even a = street,=0D=0Aas=0D=0A> > this=0D=0A> > > > is helpful for WiFi connected de= vices that roam and obtain civic=0D=0A> > > > location from the AP to which= they connect."=0D=0A> > > > (Or perhaps "Despite the fact that civic locat= ion is uncommon=0D=0Afor=0D=0A> > mobile=0D=0A> > > > devices, the LoST ser= ver SHOULD ...")=0D=0A> > > >=0D=0A> > > > Section 6.3: (paragraph 4)=0D=0A= > > > > Change "... URI of the service URN ..." to "... URI of a service=0D= =0AURN=0D=0A> > > ..."=0D=0A> > > >=0D=0A> > > > Section 6.3: (last paragra= ph)=0D=0A> > > > Re-write the last sentence as: "The proxy then replaces th= e=0D=0A> > Request-URI=0D=0A> > > > with the resulting PSAP URI."=0D=0A> > = > > Or perhaps "The resulting PSAP URI then replaces the=0D=0ARequest-URI"=0D= =0A> > > >=0D=0A> > > > Section 6.4: (first paragraph)=0D=0A> > > > Conside= r adding the phrase "Once the mapping to a PSAP URI has=0D=0Abeen=0D=0A> > = > > performed," to the begining of the paragraph (to improve the=0D=0Aflow = of=0D=0A> > the=0D=0A> > > > document).=0D=0A> > > >=0D=0A> > > > Section 6= =2E6:=0D=0A> > > > Change "The emergency dialstrings ..." to "Emergency dia= lstrings=0D=0A> > ..."=0D=0A> > > >=0D=0A> > > > Section 7: (paragraph 3)=0D= =0A> > > > Change "For calls send with ..." to "For calls sent with ..."=0D= =0A> > > >=0D=0A> > > > Section 8: (paragraph 1)=0D=0A> > > > Change "... m= edia streams on RTP ... " to "... media stream=0D=0Ausing=0D=0A> > RTP=0D=0A= > > > ..."=0D=0A> > > > or perhaps "... media streams via RTP ..."=0D=0A> >= > > Also, consider re-writing the 4th sentence as:=0D=0A> > > > "Future IP= -enabled PSAPs should accept a wider array of=0D=0Apotential=0D=0A> > media=0D= =0A> > > > types."=0D=0A> > > >=0D=0A> > > > Section 8: (paragraph 2)=0D=0A= > > > > Add a period between "the offer" and "Silence suppression".=0D=0A> = > > >=0D=0A> > > > Section 10:=0D=0A> > > > Change "... it specifies use of= several ..." to "... it=0D=0Aspecifies=0D=0A> > the=0D=0A> > > > use of se= veral ..."=0D=0A> > > >=0D=0A> > > > Section 10.1: (paragraph 2)=0D=0A> > >= > Change "... DHCP is the LCP [RFC3118] ..." to "... DHCP is the=0D=0ALCP,=0D= =0A> > > > [RFC3118] ..." (add a comma)=0D=0A> > > > Also, change "... spoo= fing would be ..." to "... spoofing is=0D=0A..."=0D=0A> > > >=0D=0A> > > > = Section 10.1: (last paragraph)=0D=0A> > > > Add an 's' to change "Client SH= OULD" to "Clients SHOULD"=0D=0A> > > >=0D=0A> > > > Section 10.2: (last par= agraph)=0D=0A> > > > Change "... signaling would help significantly." to ".= =2E.=0D=0Asignaling=0D=0A> > helps=0D=0A> > > > significantly."=0D=0A> > >=0D= =0A> > >=0D=0A> > >=0D=0A> > > ____________________________________________= ___=0D=0A> > > Ecrit mailing list=0D=0A> > > Ecrit@ietf.org=0D=0A> > > http= s://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> >=0D=0A> >=0D=0A-----------= -------------------------------------------------------------=0D=0A> --=0D=0A= > > ----------------------=0D=0A> > This message is for the designated reci= pient only and may=0D=0A> > contain privileged, proprietary, or otherwise p= rivate information.=0D=0A> > If you have received it in error, please notif= y the sender=0D=0A> > immediately and delete the original. Any unauthorize= d use of=0D=0A> > this email is prohibited.=0D=0A> >=0D=0A-----------------= -------------------------------------------------------=0D=0A> --=0D=0A> > = ----------------------=0D=0A> > [mf2]=0D=0A>=20=0D=0A=0D=0A----------------= ---------------------------------------------------------------------------= -----=0D=0AThis message is for the designated recipient only and may=0D=0Ac= ontain privileged, proprietary, or otherwise private information. =20=0D=0A= If you have received it in error, please notify the sender=0D=0Aimmediately= and delete the original. Any unauthorized use of=0D=0Athis email is prohi= bited.=0D=0A---------------------------------------------------------------= ---------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 01 18:28:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFbp-0005pF-Tv; Fri, 01 Jun 2007 18:28:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFbo-0005nj-TE for ecrit@ietf.org; Fri, 01 Jun 2007 18:28:36 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuFbo-0000d3-2X for ecrit@ietf.org; Fri, 01 Jun 2007 18:28:36 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HuFZh-0006Wt-I8; Fri, 01 Jun 2007 17:26:26 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Matt Lepinski'" , "'ECRIT'" , "'James M. Polk'" References: <465FA53B.80802@bbn.com> <0add01c7a449$6846b260$6601a8c0@cis.neustar.com> <0cb001c7a49a$b2844440$6601a8c0@cis.neustar.com> Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 Date: Fri, 1 Jun 2007 18:28:32 -0400 Message-ID: <0cb301c7a49c$31472cb0$6601a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcekCFEPcS0iQckvRVWGxa+1mAstOgAQAffgABMPLZAAAWw9QAAAS3KAAAAtGGA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ed37b243475b9c4ffb6a3f90050819d Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org But that is case 1 > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Friday, June 01, 2007 6:24 PM > To: Brian Rosen; Matt Lepinski; ECRIT; James M. Polk > Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 > > I was assuming that the end-point is given a location URI, local > dialsring, and service URNs. Say in the location hiding case. > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Saturday, 2 June 2007 8:18 AM > > To: Winterbottom, James; 'Matt Lepinski'; 'ECRIT'; 'James M. Polk' > > Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 > > > > If by that you mean the endpoint gets location, recognizes an > emergency > > call, but does not route, then the proxy server has to route. That > case > > is > > complex because without the LoST query, the endpoint doesn't have the > > local > > dialstring(s). > > > > If that was not what you mean, then who routes? > > > > Brian > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Friday, June 01, 2007 5:35 PM > > > To: Brian Rosen; Matt Lepinski; ECRIT; James M. Polk > > > Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 > > > > > > I think that there is one other variant on two. > > > > > > The End-point makes the call the service URN and includes a provided > > > locationURI. Outbound-proxy does nothing special. > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Friday, 1 June 2007 10:36 PM > > > > To: 'Matt Lepinski'; 'ECRIT'; 'James M. Polk' > > > > Subject: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 > > > > > > > > Thanks for your comments. > > > > > > > > The BCP really shouldn't be SIP specific. We need to broaden it > to, > > > for > > > > example, XMPP. We can have SIP specific information, but it > should be > > > > discussed as just that. > > > > > > > > There is a consensus, I believe, on how to mark emergency calls, > > > > represented > > > > by the thread, but chairs have to call consensus, not me. I think > > > there > > > > are > > > > three cases: > > > > 1. The endpoint recognizes it's an emergency call, does the LoST > > > routing, > > > > and passes the call to its outbound proxy server. In this case > the > > > > Request > > > > URI will be the PSAP URI from LoST, and adds a Route header with > the > > > > service > > > > URN. > > > > 2. The endpoint recognizes it's an emergency call, but doesn't > LoST > > > route > > > > it. In this case the Request URI would be the service URN. The > > > outbound > > > > proxy server would do the LoST routing, put the Route header with > the > > > > service URN in and change the Request URI to the PSAP URI. > > > > 3. The endpoint doesn't even recognize it's an emergency call. In > > > this > > > > case, the endpoint would put the dialstring in the Request URI. > The > > > > outbound proxy would behave as in 2 above. > > > > > > > > When the PSAP gets the call, it will always have its URI in the > > > Request > > > > URI, > > > > and there will be a service URN in a Route header. > > > > > > > > Probably, phonebcp should say that more clearly. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Matt Lepinski [mailto:mlepinski@bbn.com] > > > > > Sent: Friday, June 01, 2007 12:49 AM > > > > > To: ECRIT; James M. Polk; br@brianrosen.net > > > > > Subject: Comments on: draft-ietf-ecrit-phonebcp-01 > > > > > > > > > > Brian and James: > > > > > > > > > > First, two very high level questions. > > > > > > > > > > A) [Is this document supposed to be SIP-Centric?] It is unclear > to > > > me > > > > > whether the document is intended as a BCP for SIP User Agents > and > > > SIP > > > > > proxies, or whether it is more generally a BCP for end points > and > > > > > signaling-path devices which may or may not use SIP. For > instance, > > > > > Section 6.4 is written as though SIP signaling were a special > case, > > > and > > > > > yet paragraph four of Section 5 indicates that all emergency > calls > > > on > > > > > the wire should contain a Route header (which is a SIP-specific > > > > > signaling component). Personally, I don't care whether or not > the > > > > > document is SIP centric, or whether SIP is a special case, as > long > > > as > > > > > the document is consistent. > > > > > > > > > > B) [Is there consensus on how to mark emergency calls?] The > current > > > > > version of phonebcp indicates that (in the normal case when > > > end-points > > > > > perform the LoST mapping) emergency calls are marked by putting > the > > > URN > > > > > in a Route header (with a "loose" parameter that I'm not > familiar > > > with > > > > > ... can someone provide me with a reference) and that the URN is > > > placed > > > > > in the Request-URI when the end-point is unable to perform the > LoST > > > > > mapping). Personally, I don't understand the current mechanism > > > because > > > > > I'm not sure what an "ordinary" (RFC3261-compliant) proxy does > when > > > it > > > > > sees a service URN in the top Route header. However, given the > long > > > > > discussion that occured on call marking in January (See: > > > > > > http://www1.ietf.org/mail-archive/web/ecrit/current/msg02963.html), > > > > > perhaps the more important question is "Has consensus been > reached > > > that > > > > > (something like) the current mechanism is an appropriate way to > mark > > > > > messages?" > > > > > > > > > > --------------------------------- > > > > > More detailed comments: > > > > > > > > > > Section 2: (paragraph 3 - number 2) > > > > > Is it clear what the "visited location's emergency number" means > in > > > this > > > > > context? > > > > > Consider changing to "the local emergency number for its current > > > > > location" or providing a forward reference to the discussion of > > > > > dial-strings in Section 5. > > > > > > > > > > Section 2: (paragraph 4) > > > > > I agree with Barbara that if this is intended to an overview of > call > > > > > setup for the special case of an Ethernet connected phone then > the > > > > > bullets should match up more clearly with the numbered items in > the > > > > > previous paragraph. > > > > > > > > > > Section 2: (last paragraph) > > > > > It is unclear whether the antecedent of "it" in the last > paragraph > > > is > > > > > [RFC4103] or [RFC4504]. > > > > > > > > > > Section 3: > > > > > Consider changing "should support" to "SHOULD support" > > > > > > > > > > Section 3: (paragraph 2) > > > > > It seems that the point of this paragraph is to say that a > certain > > > class > > > > > of devices that communicates over IP networks should support > > > emergency > > > > > calls. However, I find the phrase "using current (evolving) > > > standards" > > > > > to be unclear and in particular I'm not sure what the phrase > > > modifies. > > > > > (E.g. Do you mean "Devices that create media sessions using > current > > > > > (evolving) standards and exchange audio ...") > > > > > > > > > > Section 4: (first paragraph) > > > > > Consider replacing "the norm" with "required" (or a similar > word). I > > > > > think the point is not that automatic location is common/normal > but > > > that > > > > > it is necessary since most users are unable to provide accurate > > > > location. > > > > > > > > > > Section 4.1: (first paragraph) > > > > > I think "cellular" (or "traditional wireless") is more precise > than > > > > > "mobile". > > > > > > > > > > Section 4.2: (first paragraph ... also, the last paragraph) > > > > > Consider changing the phrase "the desired result" to something > like > > > "an > > > > > equivalent result", or perhaps something even more explicit. > > > > > > > > > > Section 4.2: (first paragraph) > > > > > Consider addition a phrase to the last sentence indicating why > it is > > > > > recommended that the network support a standardized LCP. (This > may > > > not > > > > > be obvious to the reader). Also, consider changing "recommended" > to > > > > > "RECOMMENDED". > > > > > > > > > > Section 4.2: (paragraph 2) > > > > > Given that the paragraph covers what both devices and access > > > networks > > > > > MUST support, consider changing "For all other devices" to "In > all > > > other > > > > > scenarios". > > > > > > > > > > Section 4.3: (paragraph 3) > > > > > The term "geo-location" is not used in RFC 3825 to describe a > > > > > lat/lon/alt - style location. (Instead it uses terms like a > > > > > "coordinate-based geolocation"). Also, given that the > "geolocation" > > > > > header allows for civic locations, I think using geo-location > here > > > is > > > > > potentially confusing. > > > > > Note: This comment also applies to the use of "geo reported" in > the > > > > > third paragraph of Section 6.3 > > > > > > > > > > Section 4.4: (last paragraph) > > > > > Consider re-writing the second-to-the-last sentence as: "Certain > > > > > commonly-used techniques for measuring location create a > conflict > > > > > between the time it takes to generate a precise location and the > > > desire > > > > > to route the call quickly." (Also, in the following sentence I > think > > > > > "precise" is a better word than "accurate") > > > > > > > > > > Section 5: (paragraphs 5 and 6) > > > > > Paragraph 5 says that devices MUST mark calls using a > service:sos > > > URN. > > > > > However, paragraph 6 says that mapping from dialstring to URN > SHOULD > > > be > > > > > done by the endpoint. Either both paragraphs should use "MUST" > or > > > else > > > > > they should both use "SHOULD". > > > > > > > > > > Section 5: (paragraph 8) > > > > > I don't understand what it means to be "roaming" or "nomadic" in > a > > > > > system where there is no "visited network" > > > > > > > > > > Section 5: (last paragraph) > > > > > The last sentence of this paragraph seems to be redundent. > Consider > > > > > deleting it. > > > > > > > > > > Section 6.1: > > > > > I agree with Barbara that the use of IPSec should not be > prohibited > > > by > > > > > this BCP. > > > > > > > > > > Section 6.1: (number 6) > > > > > These instructions are for the User Agent, P-Asserted-Identity > > > headers > > > > > and Identity headers should not be inserted by the UA > > > > > > > > > > Section 6.1: (number 10) > > > > > This item is unclear to me. Is the author's intention that this > item > > > > > handles the case where a UA does not know its own location? If > so, I > > > > > guess that updating this item should be deferred until consensus > is > > > > > reached on location-hiding. > > > > > > > > > > Section 6.1: > > > > > Consider Re-ordering the items as: > > > > > 11, 10, 12, 14, 15, 13 > > > > > Also, consider deleting 12, I believe it is redundent given 9, > 10 > > > and > > > > 11. > > > > > > > > > > Section 6.2: (number 1) > > > > > Consider adding an example after "... URN appropriate for the > > > emergency > > > > > dialstring." That is, consider adding (e.g., ...) > > > > > > > > > > Section 6.2: (number 3) > > > > > I'm afraid that I don't understand the meaning of this sentence. > > > > > > > > > > Section 6.3: (paragraph 3) > > > > > The sentence that begins "This can be an enclosing ..." is > unclear > > > to > > > > > me. Are you suggesting that when a PSAP coverage region is > complex, > > > that > > > > > a LoST server SHOULD return a simple polygon that (a) contains > the > > > > > location of the device; and (b) is entirely contained within the > > > PSAP > > > > > coverage region? > > > > > > > > > > Section 6.5: (number 3) > > > > > This seems to imply that proxies should expect to SUBSCRIBE to > > > Presence. > > > > > Do you mean that proxies should expect the PSAP to SUBSCRIBE to > > > > Presence? > > > > > > > > > > Section 6.5: (number 4) > > > > > I'm not very familiar with Session Timers, can you provide a > > > reference. > > > > > > > > > > Section 6.6: > > > > > I'm afraid I don't understand the parenthetical remark after the > > > "Call > > > > > Forward" bullet. (Consider removing the remark or re-wording it > if > > > it is > > > > > important). > > > > > > > > > > Section 7: > > > > > Given the text in Section 4.4 it seems to me that the first > > > paragraph of > > > > > Section 7 is redundent and should be deleted. > > > > > > > > > > Section 10.2: > > > > > Given the difficulty of implementing location signing in a > useful > > > > > manner, I think that that either paragraph 2 should either be > > > removed or > > > > > else it should reference some other document that explains > location > > > > > signing in more detail. (That is, one paragraph does not do > location > > > > > signing justice and it seems irresponsible to strongly recommend > > > > > location signing without providing additionaly guidence to the > > > > > implementor). > > > > > > > > > > > ------------------------------------------------------------------- > > > > > Minor Nits: (That don't change the meaning of the text) > > > > > > > > > > Section 2: (last paragraph) > > > > > Put a space between [RFC4103] and "media" > > > > > > > > > > Section 3: (paragraph 1) > > > > > Add commas to second sentence "Future PSAPs will, however, > support > > > ..." > > > > > and remove the extra period at the end of the sentence > > > > > > > > > > Section 4.1: (paragraph 2) > > > > > Change "... where it is the access network that knows the > location > > > ..." > > > > > to "... when only the access network knows the location ..." > > > > > > > > > > Section 4.4: (paragraph 1) > > > > > Change "... process engaged from establishing a VPN ... " to > "... > > > > > process engaged by establishing a VPN ..." > > > > > > > > > > Section 4.4: (paragraph 2) > > > > > Change "... related to the mobility of the device and ..." to > "... > > > > > related to the degree of device mobility and ..." > > > > > > > > > > Section 4.4: (paragraph 2) > > > > > Combine the final 2 sentances as follows: > > > > > "When a device is aware that it has moved, for instance when it > > > changes > > > > > access points, the device SHOULD refresh its location." > > > > > > > > > > Section 4.4: (last paragraph) > > > > > Change "... getting more recent location ..." to "... getting > > > updated > > > > > location ..." or "... obtaining a fresh location" > > > > > > > > > > Section 5: (first paragraph) > > > > > Consider re-writing as: > > > > > "A device (or a downstream signaling element) identifies an > > > emergency > > > > > call by an "address", which in most cases is a dialstring, > although > > > > > other user interfaces may be used." > > > > > > > > > > Section 5: (paragraph 2) > > > > > First sentence has too many words modifying the word "element". > > > > Consider: > > > > > "Note: It is undesirable for a user-interface to enable a user > to > > > place > > > > > an emergency call by pressing a single button." > > > > > > > > > > Section 5: (paragraph 3) > > > > > Consider changing the first sentence: > > > > > "... in other countries there are several 3 digit numbers used > for > > > > > different types of emergency calls." > > > > > > > > > > Section 5: (paragraph 6) > > > > > Change "... some entity needs to ..." to "... some entity on the > > > > > signaling path must ..." > > > > > > > > > > Section 5: (paragraph 9) > > > > > Change "... from North America, the home ..." to "... from North > > > > > America, then while in North America the home ..." > > > > > > > > > > Section 5: (last paragraph) > > > > > Add a close parenthesis ")" after "dialstrings." > > > > > > > > > > Section 6: > > > > > Change "... is expected be supported ..." to "... is expected to > be > > > > > supported ..." > > > > > > > > > > Section 6.1: > > > > > Change "signaling Method" to "signaling method" (lower case). > > > > > > > > > > Section 6.1: (number 1) > > > > > Change "To: SHOULD" to "Request-URI: SHOULD" > > > > > > > > > > Section 6.1: (number 2) > > > > > Add a space between [I-D.rosen-iptel-dialstring] and "with" > > > > > Also change "sips MUST be ..." to "a sips URI MUST be ..." > > > > > > > > > > Section 6.2: (number 1) > > > > > Change "If it finds it it MUST:" to "If it finds the dialstring > it > > > > MUST:" > > > > > Also, change "... for the endpoint" to "... of the end device." > > > (note > > > > > that period was missing) > > > > > > > > > > Section 6.3: (paragraph 3) > > > > > Non-parallel sentence structure. Consider re-writing the last > > > sentence > > > > as: > > > > > "In the case of civic location, the LoST server SHOULD report > that > > > the > > > > > same mapping is good within a community name or even a street, > as > > > this > > > > > is helpful for WiFi connected devices that roam and obtain civic > > > > > location from the AP to which they connect." > > > > > (Or perhaps "Despite the fact that civic location is uncommon > for > > > mobile > > > > > devices, the LoST server SHOULD ...") > > > > > > > > > > Section 6.3: (paragraph 4) > > > > > Change "... URI of the service URN ..." to "... URI of a service > URN > > > > ..." > > > > > > > > > > Section 6.3: (last paragraph) > > > > > Re-write the last sentence as: "The proxy then replaces the > > > Request-URI > > > > > with the resulting PSAP URI." > > > > > Or perhaps "The resulting PSAP URI then replaces the > Request-URI" > > > > > > > > > > Section 6.4: (first paragraph) > > > > > Consider adding the phrase "Once the mapping to a PSAP URI has > been > > > > > performed," to the begining of the paragraph (to improve the > flow of > > > the > > > > > document). > > > > > > > > > > Section 6.6: > > > > > Change "The emergency dialstrings ..." to "Emergency dialstrings > > > ..." > > > > > > > > > > Section 7: (paragraph 3) > > > > > Change "For calls send with ..." to "For calls sent with ..." > > > > > > > > > > Section 8: (paragraph 1) > > > > > Change "... media streams on RTP ... " to "... media stream > using > > > RTP > > > > ..." > > > > > or perhaps "... media streams via RTP ..." > > > > > Also, consider re-writing the 4th sentence as: > > > > > "Future IP-enabled PSAPs should accept a wider array of > potential > > > media > > > > > types." > > > > > > > > > > Section 8: (paragraph 2) > > > > > Add a period between "the offer" and "Silence suppression". > > > > > > > > > > Section 10: > > > > > Change "... it specifies use of several ..." to "... it > specifies > > > the > > > > > use of several ..." > > > > > > > > > > Section 10.1: (paragraph 2) > > > > > Change "... DHCP is the LCP [RFC3118] ..." to "... DHCP is the > LCP, > > > > > [RFC3118] ..." (add a comma) > > > > > Also, change "... spoofing would be ..." to "... spoofing is > ..." > > > > > > > > > > Section 10.1: (last paragraph) > > > > > Add an 's' to change "Client SHOULD" to "Clients SHOULD" > > > > > > > > > > Section 10.2: (last paragraph) > > > > > Change "... signaling would help significantly." to "... > signaling > > > helps > > > > > significantly." > > > > > > > > > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > [mf2] > > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 01 18:30:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFdT-0006MH-1H; Fri, 01 Jun 2007 18:30:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFdS-0006M7-FX for ecrit@ietf.org; Fri, 01 Jun 2007 18:30:18 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuFdR-0000uA-Ln for ecrit@ietf.org; Fri, 01 Jun 2007 18:30:18 -0400 X-SEF-Processed: 5_0_0_910__2007_06_01_17_37_43 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 01 Jun 2007 17:37:43 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Jun 2007 17:30:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 Date: Fri, 1 Jun 2007 17:30:16 -0500 Message-ID: In-Reply-To: <0cb301c7a49c$31472cb0$6601a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 Thread-Index: AcekCFEPcS0iQckvRVWGxa+1mAstOgAQAffgABMPLZAAAWw9QAAAS3KAAAAtGGAAAA9IoA== References: <465FA53B.80802@bbn.com> <0add01c7a449$6846b260$6601a8c0@cis.neustar.com> <0cb001c7a49a$b2844440$6601a8c0@cis.neustar.com> <0cb301c7a49c$31472cb0$6601a8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Matt Lepinski" , "ECRIT" , "James M. Polk" X-OriginalArrivalTime: 01 Jun 2007 22:30:17.0291 (UTC) FILETIME=[6E21C9B0:01C7A49C] X-Spam-Score: 0.0 (/) X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Except that the end-point doesn't do the LoST thing=0D=0A=0D=0A=0D=0A> ----= -Original Message-----=0D=0A> From: Brian Rosen [mailto:br@brianrosen.net]=0D= =0A> Sent: Saturday, 2 June 2007 8:29 AM=0D=0A> To: Winterbottom, James; 'M= att Lepinski'; 'ECRIT'; 'James M. Polk'=0D=0A> Subject: RE: [Ecrit] RE: Com= ments on: draft-ietf-ecrit-phonebcp-01=0D=0A>=20=0D=0A> But that is case 1=0D= =0A>=20=0D=0A> > -----Original Message-----=0D=0A> > From: Winterbottom, Ja= mes [mailto:James.Winterbottom@andrew.com]=0D=0A> > Sent: Friday, June 01, = 2007 6:24 PM=0D=0A> > To: Brian Rosen; Matt Lepinski; ECRIT; James M. Polk=0D= =0A> > Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01=0D= =0A> >=0D=0A> > I was assuming that the end-point is given a location URI, = local=0D=0A> > dialsring, and service URNs. Say in the location hiding case= =2E=0D=0A> >=0D=0A> >=0D=0A> > > -----Original Message-----=0D=0A> > > From= : Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > > Sent: Saturday, 2 June = 2007 8:18 AM=0D=0A> > > To: Winterbottom, James; 'Matt Lepinski'; 'ECRIT'; = 'James M. Polk'=0D=0A> > > Subject: RE: [Ecrit] RE: Comments on: draft-ietf= -ecrit-phonebcp-01=0D=0A> > >=0D=0A> > > If by that you mean the endpoint g= ets location, recognizes an=0D=0A> > emergency=0D=0A> > > call, but does no= t route, then the proxy server has to route.=0D=0AThat=0D=0A> > case=0D=0A>= > > is=0D=0A> > > complex because without the LoST query, the endpoint doe= sn't have=0D=0Athe=0D=0A> > > local=0D=0A> > > dialstring(s).=0D=0A> > >=0D= =0A> > > If that was not what you mean, then who routes=3F=0D=0A> > >=0D=0A= > > > Brian=0D=0A> > >=0D=0A> > > > -----Original Message-----=0D=0A> > > >= From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=0D=0A> > = > > Sent: Friday, June 01, 2007 5:35 PM=0D=0A> > > > To: Brian Rosen; Matt = Lepinski; ECRIT; James M. Polk=0D=0A> > > > Subject: RE: [Ecrit] RE: Commen= ts on:=0D=0Adraft-ietf-ecrit-phonebcp-01=0D=0A> > > >=0D=0A> > > > I think = that there is one other variant on two.=0D=0A> > > >=0D=0A> > > > The End-p= oint makes the call the service URN and includes a=0D=0Aprovided=0D=0A> > >= > locationURI. Outbound-proxy does nothing special.=0D=0A> > > >=0D=0A> > = > > > -----Original Message-----=0D=0A> > > > > From: Brian Rosen [mailto:b= r@brianrosen.net]=0D=0A> > > > > Sent: Friday, 1 June 2007 10:36 PM=0D=0A> = > > > > To: 'Matt Lepinski'; 'ECRIT'; 'James M. Polk'=0D=0A> > > > > Subjec= t: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01=0D=0A> > > > >=0D=0A= > > > > > Thanks for your comments.=0D=0A> > > > >=0D=0A> > > > > The BCP r= eally shouldn't be SIP specific. We need to broaden=0D=0Ait=0D=0A> > to,=0D= =0A> > > > for=0D=0A> > > > > example, XMPP. We can have SIP specific info= rmation, but it=0D=0A> > should be=0D=0A> > > > > discussed as just that.=0D= =0A> > > > >=0D=0A> > > > > There is a consensus, I believe, on how to mark= emergency=0D=0Acalls,=0D=0A> > > > > represented=0D=0A> > > > > by the thr= ead, but chairs have to call consensus, not me. I=0D=0Athink=0D=0A> > > > = there=0D=0A> > > > > are=0D=0A> > > > > three cases:=0D=0A> > > > > 1. The = endpoint recognizes it's an emergency call, does the=0D=0ALoST=0D=0A> > > >= routing,=0D=0A> > > > > and passes the call to its outbound proxy server. = In this=0D=0Acase=0D=0A> > the=0D=0A> > > > > Request=0D=0A> > > > > URI w= ill be the PSAP URI from LoST, and adds a Route header=0D=0Awith=0D=0A> > t= he=0D=0A> > > > > service=0D=0A> > > > > URN.=0D=0A> > > > > 2. The endpoin= t recognizes it's an emergency call, but doesn't=0D=0A> > LoST=0D=0A> > > >= route=0D=0A> > > > > it. In this case the Request URI would be the servic= e URN.=0D=0AThe=0D=0A> > > > outbound=0D=0A> > > > > proxy server would do = the LoST routing, put the Route header=0D=0Awith=0D=0A> > the=0D=0A> > > > = > service URN in and change the Request URI to the PSAP URI.=0D=0A> > > > >= 3. The endpoint doesn't even recognize it's an emergency call.=0D=0AIn=0D=0A= > > > > this=0D=0A> > > > > case, the endpoint would put the dialstring in = the Request=0D=0AURI.=0D=0A> > The=0D=0A> > > > > outbound proxy would beha= ve as in 2 above.=0D=0A> > > > >=0D=0A> > > > > When the PSAP gets the call= , it will always have its URI in=0D=0Athe=0D=0A> > > > Request=0D=0A> > > >= > URI,=0D=0A> > > > > and there will be a service URN in a Route header.=0D= =0A> > > > >=0D=0A> > > > > Probably, phonebcp should say that more clearly= =2E=0D=0A> > > > >=0D=0A> > > > > Brian=0D=0A> > > > >=0D=0A> > > > > > ---= --Original Message-----=0D=0A> > > > > > From: Matt Lepinski [mailto:mlepin= ski@bbn.com]=0D=0A> > > > > > Sent: Friday, June 01, 2007 12:49 AM=0D=0A> >= > > > > To: ECRIT; James M. Polk; br@brianrosen.net=0D=0A> > > > > > Subje= ct: Comments on: draft-ietf-ecrit-phonebcp-01=0D=0A> > > > > >=0D=0A> > > >= > > Brian and James:=0D=0A> > > > > >=0D=0A> > > > > > First, two very hig= h level questions.=0D=0A> > > > > >=0D=0A> > > > > > A) [Is this document s= upposed to be SIP-Centric=3F] It is=0D=0Aunclear=0D=0A> > to=0D=0A> > > > m= e=0D=0A> > > > > > whether the document is intended as a BCP for SIP User=0D= =0AAgents=0D=0A> > and=0D=0A> > > > SIP=0D=0A> > > > > > proxies, or whethe= r it is more generally a BCP for end=0D=0Apoints=0D=0A> > and=0D=0A> > > > = > > signaling-path devices which may or may not use SIP. For=0D=0A> > insta= nce,=0D=0A> > > > > > Section 6.4 is written as though SIP signaling were a=0D= =0Aspecial=0D=0A> > case,=0D=0A> > > > and=0D=0A> > > > > > yet paragraph f= our of Section 5 indicates that all emergency=0D=0A> > calls=0D=0A> > > > o= n=0D=0A> > > > > > the wire should contain a Route header (which is a=0D=0A= SIP-specific=0D=0A> > > > > > signaling component). Personally, I don't car= e whether or=0D=0Anot=0D=0A> > the=0D=0A> > > > > > document is SIP centric= , or whether SIP is a special case,=0D=0Aas=0D=0A> > long=0D=0A> > > > as=0D= =0A> > > > > > the document is consistent.=0D=0A> > > > > >=0D=0A> > > > > = > B) [Is there consensus on how to mark emergency calls=3F] The=0D=0A> > cu= rrent=0D=0A> > > > > > version of phonebcp indicates that (in the normal ca= se when=0D=0A> > > > end-points=0D=0A> > > > > > perform the LoST mapping) = emergency calls are marked by=0D=0Aputting=0D=0A> > the=0D=0A> > > > URN=0D= =0A> > > > > > in a Route header (with a "loose" parameter that I'm not=0D=0A= > > familiar=0D=0A> > > > with=0D=0A> > > > > > ... can someone provide me = with a reference) and that the=0D=0AURN is=0D=0A> > > > placed=0D=0A> > > >= > > in the Request-URI when the end-point is unable to perform=0D=0Athe=0D= =0A> > LoST=0D=0A> > > > > > mapping). Personally, I don't understand the c= urrent=0D=0Amechanism=0D=0A> > > > because=0D=0A> > > > > > I'm not sure wh= at an "ordinary" (RFC3261-compliant) proxy=0D=0Adoes=0D=0A> > when=0D=0A> >= > > it=0D=0A> > > > > > sees a service URN in the top Route header. Howeve= r, given=0D=0Athe=0D=0A> > long=0D=0A> > > > > > discussion that occured on= call marking in January (See:=0D=0A> > > > > >=0D=0A> > http://www1.ietf.o= rg/mail-archive/web/ecrit/current/msg02963.html),=0D=0A> > > > > > perhaps = the more important question is "Has consensus been=0D=0A> > reached=0D=0A> = > > > that=0D=0A> > > > > > (something like) the current mechanism is an ap= propriate way=0D=0Ato=0D=0A> > mark=0D=0A> > > > > > messages=3F"=0D=0A> > = > > > >=0D=0A> > > > > > ---------------------------------=0D=0A> > > > > >= More detailed comments:=0D=0A> > > > > >=0D=0A> > > > > > Section 2: (para= graph 3 - number 2)=0D=0A> > > > > > Is it clear what the "visited location= 's emergency number"=0D=0Ameans=0D=0A> > in=0D=0A> > > > this=0D=0A> > > > = > > context=3F=0D=0A> > > > > > Consider changing to "the local emergency n= umber for its=0D=0Acurrent=0D=0A> > > > > > location" or providing a forwar= d reference to the discussion=0D=0Aof=0D=0A> > > > > > dial-strings in Sect= ion 5.=0D=0A> > > > > >=0D=0A> > > > > > Section 2: (paragraph 4)=0D=0A> > = > > > > I agree with Barbara that if this is intended to an overview=0D=0Ao= f=0D=0A> > call=0D=0A> > > > > > setup for the special case of an Ethernet = connected phone=0D=0Athen=0D=0A> > the=0D=0A> > > > > > bullets should matc= h up more clearly with the numbered items=0D=0Ain=0D=0A> > the=0D=0A> > > >= > > previous paragraph.=0D=0A> > > > > >=0D=0A> > > > > > Section 2: (last= paragraph)=0D=0A> > > > > > It is unclear whether the antecedent of "it" i= n the last=0D=0A> > paragraph=0D=0A> > > > is=0D=0A> > > > > > [RFC4103] or= [RFC4504].=0D=0A> > > > > >=0D=0A> > > > > > Section 3:=0D=0A> > > > > > C= onsider changing "should support" to "SHOULD support"=0D=0A> > > > > >=0D=0A= > > > > > > Section 3: (paragraph 2)=0D=0A> > > > > > It seems that the poi= nt of this paragraph is to say that a=0D=0A> > certain=0D=0A> > > > class=0D= =0A> > > > > > of devices that communicates over IP networks should support=0D= =0A> > > > emergency=0D=0A> > > > > > calls. However, I find the phrase "us= ing current (evolving)=0D=0A> > > > standards"=0D=0A> > > > > > to be uncle= ar and in particular I'm not sure what the phrase=0D=0A> > > > modifies.=0D= =0A> > > > > > (E.g. Do you mean "Devices that create media sessions using=0D= =0A> > current=0D=0A> > > > > > (evolving) standards and exchange audio ...= ")=0D=0A> > > > > >=0D=0A> > > > > > Section 4: (first paragraph)=0D=0A> > = > > > > Consider replacing "the norm" with "required" (or a similar=0D=0A> = > word). I=0D=0A> > > > > > think the point is not that automatic location = is=0D=0Acommon/normal=0D=0A> > but=0D=0A> > > > that=0D=0A> > > > > > it is= necessary since most users are unable to provide=0D=0Aaccurate=0D=0A> > > = > > location.=0D=0A> > > > > >=0D=0A> > > > > > Section 4.1: (first paragra= ph)=0D=0A> > > > > > I think "cellular" (or "traditional wireless") is mor= e=0D=0Aprecise=0D=0A> > than=0D=0A> > > > > > "mobile".=0D=0A> > > > > >=0D= =0A> > > > > > Section 4.2: (first paragraph ... also, the last paragraph)=0D= =0A> > > > > > Consider changing the phrase "the desired result" to=0D=0Aso= mething=0D=0A> > like=0D=0A> > > > "an=0D=0A> > > > > > equivalent result",= or perhaps something even more explicit.=0D=0A> > > > > >=0D=0A> > > > > >= Section 4.2: (first paragraph)=0D=0A> > > > > > Consider addition a phrase= to the last sentence indicating=0D=0Awhy=0D=0A> > it is=0D=0A> > > > > > r= ecommended that the network support a standardized LCP.=0D=0A(This=0D=0A> >= may=0D=0A> > > > not=0D=0A> > > > > > be obvious to the reader). Also, con= sider changing=0D=0A"recommended"=0D=0A> > to=0D=0A> > > > > > "RECOMMENDED= ".=0D=0A> > > > > >=0D=0A> > > > > > Section 4.2: (paragraph 2)=0D=0A> > > = > > > Given that the paragraph covers what both devices and access=0D=0A> >= > > networks=0D=0A> > > > > > MUST support, consider changing "For all oth= er devices" to=0D=0A"In=0D=0A> > all=0D=0A> > > > other=0D=0A> > > > > > sc= enarios".=0D=0A> > > > > >=0D=0A> > > > > > Section 4.3: (paragraph 3)=0D=0A= > > > > > > The term "geo-location" is not used in RFC 3825 to describe=0D=0A= a=0D=0A> > > > > > lat/lon/alt - style location. (Instead it uses terms lik= e a=0D=0A> > > > > > "coordinate-based geolocation"). Also, given that the=0D= =0A> > "geolocation"=0D=0A> > > > > > header allows for civic locations, I = think using=0D=0Ageo-location=0D=0A> > here=0D=0A> > > > is=0D=0A> > > > > = > potentially confusing.=0D=0A> > > > > > Note: This comment also applies t= o the use of "geo reported"=0D=0Ain=0D=0A> > the=0D=0A> > > > > > third par= agraph of Section 6.3=0D=0A> > > > > >=0D=0A> > > > > > Section 4.4: (last= paragraph)=0D=0A> > > > > > Consider re-writing the second-to-the-last sen= tence as:=0D=0A"Certain=0D=0A> > > > > > commonly-used techniques for measu= ring location create a=0D=0A> > conflict=0D=0A> > > > > > between the time = it takes to generate a precise location and=0D=0Athe=0D=0A> > > > desire=0D= =0A> > > > > > to route the call quickly." (Also, in the following sentence=0D= =0AI=0D=0A> > think=0D=0A> > > > > > "precise" is a better word than "accur= ate")=0D=0A> > > > > >=0D=0A> > > > > > Section 5: (paragraphs 5 and 6)=0D=0A= > > > > > > Paragraph 5 says that devices MUST mark calls using a=0D=0A> > = service:sos=0D=0A> > > > URN.=0D=0A> > > > > > However, paragraph 6 says th= at mapping from dialstring to=0D=0AURN=0D=0A> > SHOULD=0D=0A> > > > be=0D=0A= > > > > > > done by the endpoint. Either both paragraphs should use=0D=0A"M= UST"=0D=0A> > or=0D=0A> > > > else=0D=0A> > > > > > they should both use "S= HOULD".=0D=0A> > > > > >=0D=0A> > > > > > Section 5: (paragraph 8)=0D=0A> >= > > > > I don't understand what it means to be "roaming" or=0D=0A"nomadic"= in=0D=0A> > a=0D=0A> > > > > > system where there is no "visited network"=0D= =0A> > > > > >=0D=0A> > > > > > Section 5: (last paragraph)=0D=0A> > > > > = > The last sentence of this paragraph seems to be redundent.=0D=0A> > Consi= der=0D=0A> > > > > > deleting it.=0D=0A> > > > > >=0D=0A> > > > > > Section= 6.1:=0D=0A> > > > > > I agree with Barbara that the use of IPSec should no= t be=0D=0A> > prohibited=0D=0A> > > > by=0D=0A> > > > > > this BCP.=0D=0A> = > > > > >=0D=0A> > > > > > Section 6.1: (number 6)=0D=0A> > > > > > These i= nstructions are for the User Agent,=0D=0AP-Asserted-Identity=0D=0A> > > > h= eaders=0D=0A> > > > > > and Identity headers should not be inserted by the = UA=0D=0A> > > > > >=0D=0A> > > > > > Section 6.1: (number 10)=0D=0A> > > > = > > This item is unclear to me. Is the author's intention that=0D=0Athis=0D= =0A> > item=0D=0A> > > > > > handles the case where a UA does not know its = own location=3F=0D=0AIf=0D=0A> > so, I=0D=0A> > > > > > guess that updating= this item should be deferred until=0D=0Aconsensus=0D=0A> > is=0D=0A> > > >= > > reached on location-hiding.=0D=0A> > > > > >=0D=0A> > > > > > Section = 6.1:=0D=0A> > > > > > Consider Re-ordering the items as:=0D=0A> > > > > > 1= 1, 10, 12, 14, 15, 13=0D=0A> > > > > > Also, consider deleting 12, I believ= e it is redundent given=0D=0A9,=0D=0A> > 10=0D=0A> > > > and=0D=0A> > > > >= 11.=0D=0A> > > > > >=0D=0A> > > > > > Section 6.2: (number 1)=0D=0A> > > >= > > Consider adding an example after "... URN appropriate for=0D=0Athe=0D=0A= > > > > emergency=0D=0A> > > > > > dialstring." That is, consider adding (e= =2Eg., ...)=0D=0A> > > > > >=0D=0A> > > > > > Section 6.2: (number 3)=0D=0A= > > > > > > I'm afraid that I don't understand the meaning of this=0D=0Asen= tence.=0D=0A> > > > > >=0D=0A> > > > > > Section 6.3: (paragraph 3)=0D=0A> = > > > > > The sentence that begins "This can be an enclosing ..." is=0D=0A>= > unclear=0D=0A> > > > to=0D=0A> > > > > > me. Are you suggesting that whe= n a PSAP coverage region is=0D=0A> > complex,=0D=0A> > > > that=0D=0A> > > = > > > a LoST server SHOULD return a simple polygon that (a)=0D=0Acontains=0D= =0A> > the=0D=0A> > > > > > location of the device; and (b) is entirely con= tained within=0D=0Athe=0D=0A> > > > PSAP=0D=0A> > > > > > coverage region=3F=0D= =0A> > > > > >=0D=0A> > > > > > Section 6.5: (number 3)=0D=0A> > > > > > Th= is seems to imply that proxies should expect to SUBSCRIBE=0D=0Ato=0D=0A> > = > > Presence.=0D=0A> > > > > > Do you mean that proxies should expect the P= SAP to SUBSCRIBE=0D=0Ato=0D=0A> > > > > Presence=3F=0D=0A> > > > > >=0D=0A>= > > > > > Section 6.5: (number 4)=0D=0A> > > > > > I'm not very familiar w= ith Session Timers, can you provide a=0D=0A> > > > reference.=0D=0A> > > > = > >=0D=0A> > > > > > Section 6.6:=0D=0A> > > > > > I'm afraid I don't under= stand the parenthetical remark after=0D=0Athe=0D=0A> > > > "Call=0D=0A> > >= > > > Forward" bullet. (Consider removing the remark or re-wording=0D=0Ait=0D= =0A> > if=0D=0A> > > > it is=0D=0A> > > > > > important).=0D=0A> > > > > >=0D= =0A> > > > > > Section 7:=0D=0A> > > > > > Given the text in Section 4.4 it= seems to me that the first=0D=0A> > > > paragraph of=0D=0A> > > > > > Sect= ion 7 is redundent and should be deleted.=0D=0A> > > > > >=0D=0A> > > > > >= Section 10.2:=0D=0A> > > > > > Given the difficulty of implementing locati= on signing in a=0D=0A> > useful=0D=0A> > > > > > manner, I think that that = either paragraph 2 should either=0D=0Abe=0D=0A> > > > removed or=0D=0A> > >= > > > else it should reference some other document that explains=0D=0A> > = location=0D=0A> > > > > > signing in more detail. (That is, one paragraph d= oes not do=0D=0A> > location=0D=0A> > > > > > signing justice and it seems = irresponsible to strongly=0D=0Arecommend=0D=0A> > > > > > location signing = without providing additionaly guidence to=0D=0Athe=0D=0A> > > > > > impleme= ntor).=0D=0A> > > > > >=0D=0A> > > > > >=0D=0A> > -------------------------= ------------------------------------------=0D=0A> > > > > > Minor Nits: (Th= at don't change the meaning of the text)=0D=0A> > > > > >=0D=0A> > > > > > = Section 2: (last paragraph)=0D=0A> > > > > > Put a space between [RFC4103] = and "media"=0D=0A> > > > > >=0D=0A> > > > > > Section 3: (paragraph 1)=0D=0A= > > > > > > Add commas to second sentence "Future PSAPs will, however,=0D=0A= > > support=0D=0A> > > > ..."=0D=0A> > > > > > and remove the extra period = at the end of the sentence=0D=0A> > > > > >=0D=0A> > > > > > Section 4.1: (= paragraph 2)=0D=0A> > > > > > Change "... where it is the access network th= at knows the=0D=0A> > location=0D=0A> > > > ..."=0D=0A> > > > > > to "... w= hen only the access network knows the location ..."=0D=0A> > > > > >=0D=0A>= > > > > > Section 4.4: (paragraph 1)=0D=0A> > > > > > Change "... process = engaged from establishing a VPN ... " to=0D=0A> > "...=0D=0A> > > > > > pro= cess engaged by establishing a VPN ..."=0D=0A> > > > > >=0D=0A> > > > > > S= ection 4.4: (paragraph 2)=0D=0A> > > > > > Change "... related to the mobil= ity of the device and ..."=0D=0Ato=0D=0A> > "...=0D=0A> > > > > > related t= o the degree of device mobility and ..."=0D=0A> > > > > >=0D=0A> > > > > > = Section 4.4: (paragraph 2)=0D=0A> > > > > > Combine the final 2 sentances a= s follows:=0D=0A> > > > > > "When a device is aware that it has moved, for = instance when=0D=0Ait=0D=0A> > > > changes=0D=0A> > > > > > access points, = the device SHOULD refresh its location."=0D=0A> > > > > >=0D=0A> > > > > > = Section 4.4: (last paragraph)=0D=0A> > > > > > Change "... getting more rec= ent location ..." to "...=0D=0Agetting=0D=0A> > > > updated=0D=0A> > > > > = > location ..." or "... obtaining a fresh location"=0D=0A> > > > > >=0D=0A>= > > > > > Section 5: (first paragraph)=0D=0A> > > > > > Consider re-writin= g as:=0D=0A> > > > > > "A device (or a downstream signaling element) identi= fies an=0D=0A> > > > emergency=0D=0A> > > > > > call by an "address", which= in most cases is a dialstring,=0D=0A> > although=0D=0A> > > > > > other us= er interfaces may be used."=0D=0A> > > > > >=0D=0A> > > > > > Section 5: (p= aragraph 2)=0D=0A> > > > > > First sentence has too many words modifying th= e word=0D=0A"element".=0D=0A> > > > > Consider:=0D=0A> > > > > > "Note: It = is undesirable for a user-interface to enable a=0D=0Auser=0D=0A> > to=0D=0A= > > > > place=0D=0A> > > > > > an emergency call by pressing a single butto= n."=0D=0A> > > > > >=0D=0A> > > > > > Section 5: (paragraph 3)=0D=0A> > > >= > > Consider changing the first sentence:=0D=0A> > > > > > "... in other c= ountries there are several 3 digit numbers=0D=0Aused=0D=0A> > for=0D=0A> > = > > > > different types of emergency calls."=0D=0A> > > > > >=0D=0A> > > > = > > Section 5: (paragraph 6)=0D=0A> > > > > > Change "... some entity needs= to ..." to "... some entity on=0D=0Athe=0D=0A> > > > > > signaling path mu= st ..."=0D=0A> > > > > >=0D=0A> > > > > > Section 5: (paragraph 9)=0D=0A> >= > > > > Change "... from North America, the home ..." to "... from=0D=0ANo= rth=0D=0A> > > > > > America, then while in North America the home ..."=0D=0A= > > > > > >=0D=0A> > > > > > Section 5: (last paragraph)=0D=0A> > > > > > A= dd a close parenthesis ")" after "dialstrings."=0D=0A> > > > > >=0D=0A> > >= > > > Section 6:=0D=0A> > > > > > Change "... is expected be supported ...= " to "... is=0D=0Aexpected to=0D=0A> > be=0D=0A> > > > > > supported ..."=0D= =0A> > > > > >=0D=0A> > > > > > Section 6.1:=0D=0A> > > > > > Change "signa= ling Method" to "signaling method" (lower=0D=0Acase).=0D=0A> > > > > >=0D=0A= > > > > > > Section 6.1: (number 1)=0D=0A> > > > > > Change "To: SHOULD" to= "Request-URI: SHOULD"=0D=0A> > > > > >=0D=0A> > > > > > Section 6.1: (numb= er 2)=0D=0A> > > > > > Add a space between [I-D.rosen-iptel-dialstring] and= "with"=0D=0A> > > > > > Also change "sips MUST be ..." to "a sips URI MUST= be ..."=0D=0A> > > > > >=0D=0A> > > > > > Section 6.2: (number 1)=0D=0A> >= > > > > Change "If it finds it it MUST:" to "If it finds the=0D=0Adialstri= ng=0D=0A> > it=0D=0A> > > > > MUST:"=0D=0A> > > > > > Also, change "... for= the endpoint" to "... of the end=0D=0Adevice."=0D=0A> > > > (note=0D=0A> >= > > > > that period was missing)=0D=0A> > > > > >=0D=0A> > > > > > Section= 6.3: (paragraph 3)=0D=0A> > > > > > Non-parallel sentence structure. Consi= der re-writing the=0D=0Alast=0D=0A> > > > sentence=0D=0A> > > > > as:=0D=0A= > > > > > > "In the case of civic location, the LoST server SHOULD=0D=0Arep= ort=0D=0A> > that=0D=0A> > > > the=0D=0A> > > > > > same mapping is good wi= thin a community name or even a=0D=0Astreet,=0D=0A> > as=0D=0A> > > > this=0D= =0A> > > > > > is helpful for WiFi connected devices that roam and obtain=0D= =0Acivic=0D=0A> > > > > > location from the AP to which they connect."=0D=0A= > > > > > > (Or perhaps "Despite the fact that civic location is=0D=0Auncom= mon=0D=0A> > for=0D=0A> > > > mobile=0D=0A> > > > > > devices, the LoST ser= ver SHOULD ...")=0D=0A> > > > > >=0D=0A> > > > > > Section 6.3: (paragraph = 4)=0D=0A> > > > > > Change "... URI of the service URN ..." to "... URI of = a=0D=0Aservice=0D=0A> > URN=0D=0A> > > > > ..."=0D=0A> > > > > >=0D=0A> > >= > > > Section 6.3: (last paragraph)=0D=0A> > > > > > Re-write the last sen= tence as: "The proxy then replaces the=0D=0A> > > > Request-URI=0D=0A> > > = > > > with the resulting PSAP URI."=0D=0A> > > > > > Or perhaps "The result= ing PSAP URI then replaces the=0D=0A> > Request-URI"=0D=0A> > > > > >=0D=0A= > > > > > > Section 6.4: (first paragraph)=0D=0A> > > > > > Consider adding= the phrase "Once the mapping to a PSAP URI=0D=0Ahas=0D=0A> > been=0D=0A> >= > > > > performed," to the begining of the paragraph (to improve the=0D=0A= > > flow of=0D=0A> > > > the=0D=0A> > > > > > document).=0D=0A> > > > > >=0D= =0A> > > > > > Section 6.6:=0D=0A> > > > > > Change "The emergency dialstri= ngs ..." to "Emergency=0D=0Adialstrings=0D=0A> > > > ..."=0D=0A> > > > > >=0D= =0A> > > > > > Section 7: (paragraph 3)=0D=0A> > > > > > Change "For calls = send with ..." to "For calls sent with=0D=0A..."=0D=0A> > > > > >=0D=0A> > = > > > > Section 8: (paragraph 1)=0D=0A> > > > > > Change "... media streams= on RTP ... " to "... media stream=0D=0A> > using=0D=0A> > > > RTP=0D=0A> >= > > > ..."=0D=0A> > > > > > or perhaps "... media streams via RTP ..."=0D=0A= > > > > > > Also, consider re-writing the 4th sentence as:=0D=0A> > > > > >= "Future IP-enabled PSAPs should accept a wider array of=0D=0A> > potential=0D= =0A> > > > media=0D=0A> > > > > > types."=0D=0A> > > > > >=0D=0A> > > > > >= Section 8: (paragraph 2)=0D=0A> > > > > > Add a period between "the offer"= and "Silence suppression".=0D=0A> > > > > >=0D=0A> > > > > > Section 10:=0D= =0A> > > > > > Change "... it specifies use of several ..." to "... it=0D=0A= > > specifies=0D=0A> > > > the=0D=0A> > > > > > use of several ..."=0D=0A> = > > > > >=0D=0A> > > > > > Section 10.1: (paragraph 2)=0D=0A> > > > > > Cha= nge "... DHCP is the LCP [RFC3118] ..." to "... DHCP is=0D=0Athe=0D=0A> > L= CP,=0D=0A> > > > > > [RFC3118] ..." (add a comma)=0D=0A> > > > > > Also, ch= ange "... spoofing would be ..." to "... spoofing is=0D=0A> > ..."=0D=0A> >= > > > >=0D=0A> > > > > > Section 10.1: (last paragraph)=0D=0A> > > > > > A= dd an 's' to change "Client SHOULD" to "Clients SHOULD"=0D=0A> > > > > >=0D= =0A> > > > > > Section 10.2: (last paragraph)=0D=0A> > > > > > Change "... = signaling would help significantly." to "...=0D=0A> > signaling=0D=0A> > > = > helps=0D=0A> > > > > > significantly."=0D=0A> > > > >=0D=0A> > > > >=0D=0A= > > > > >=0D=0A> > > > > _______________________________________________=0D= =0A> > > > > Ecrit mailing list=0D=0A> > > > > Ecrit@ietf.org=0D=0A> > > > = > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > > >=0D=0A> > > >=0D= =0A> >=0D=0A---------------------------------------------------------------= ---------=0D=0A> > > --=0D=0A> > > > ----------------------=0D=0A> > > > Th= is message is for the designated recipient only and may=0D=0A> > > > contai= n privileged, proprietary, or otherwise private=0D=0Ainformation.=0D=0A> > = > > If you have received it in error, please notify the sender=0D=0A> > > >= immediately and delete the original. Any unauthorized use of=0D=0A> > > >= this email is prohibited.=0D=0A> > > >=0D=0A> >=0D=0A---------------------= ---------------------------------------------------=0D=0A> > > --=0D=0A> > = > > ----------------------=0D=0A> > > > [mf2]=0D=0A> > >=0D=0A> >=0D=0A> >=0D= =0A------------------------------------------------------------------------=0D= =0A> --=0D=0A> > ----------------------=0D=0A> > This message is for the de= signated recipient only and may=0D=0A> > contain privileged, proprietary, o= r otherwise private information.=0D=0A> > If you have received it in error,= please notify the sender=0D=0A> > immediately and delete the original. An= y unauthorized use of=0D=0A> > this email is prohibited.=0D=0A> >=0D=0A----= --------------------------------------------------------------------=0D=0A>= --=0D=0A> > ----------------------=0D=0A> > [mf2]=0D=0A>=20=0D=0A=0D=0A---= ---------------------------------------------------------------------------= ------------------=0D=0AThis message is for the designated recipient only a= nd may=0D=0Acontain privileged, proprietary, or otherwise private informati= on. =20=0D=0AIf you have received it in error, please notify the sender=0D=0A= immediately and delete the original. Any unauthorized use of=0D=0Athis ema= il is prohibited.=0D=0A----------------------------------------------------= --------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 01 18:39:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFml-0003hO-Lf; Fri, 01 Jun 2007 18:39:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFmk-0003hA-F4 for ecrit@ietf.org; Fri, 01 Jun 2007 18:39:54 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuFmf-0002fU-4w for ecrit@ietf.org; Fri, 01 Jun 2007 18:39:54 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HuFkY-0000Pc-9f; Fri, 01 Jun 2007 17:37:39 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Matt Lepinski'" , "'ECRIT'" , "'James M. Polk'" References: <465FA53B.80802@bbn.com> <0add01c7a449$6846b260$6601a8c0@cis.neustar.com> <0cb001c7a49a$b2844440$6601a8c0@cis.neustar.com> <0cb301c7a49c$31472cb0$6601a8c0@cis.neustar.com> Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 Date: Fri, 1 Jun 2007 18:39:44 -0400 Message-ID: <0cb601c7a49d$c25ec540$6601a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcekCFEPcS0iQckvRVWGxa+1mAstOgAQAffgABMPLZAAAWw9QAAAS3KAAAAtGGAAAA9IoAAAR+PQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7b4956e5f2f9c5fe16a8fbd4ddb538bc Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org So far, the location hiding thing is you get coarse location and you LoST route with it. There are people unhappy with that, who want the LCP to return LoST data, or LoST to do dereference. My read of rough consensus was coarse location, but chairs have to call that one. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Friday, June 01, 2007 6:30 PM > To: Brian Rosen; Matt Lepinski; ECRIT; James M. Polk > Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 > > Except that the end-point doesn't do the LoST thing > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Saturday, 2 June 2007 8:29 AM > > To: Winterbottom, James; 'Matt Lepinski'; 'ECRIT'; 'James M. Polk' > > Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 > > > > But that is case 1 > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Friday, June 01, 2007 6:24 PM > > > To: Brian Rosen; Matt Lepinski; ECRIT; James M. Polk > > > Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 > > > > > > I was assuming that the end-point is given a location URI, local > > > dialsring, and service URNs. Say in the location hiding case. > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Saturday, 2 June 2007 8:18 AM > > > > To: Winterbottom, James; 'Matt Lepinski'; 'ECRIT'; 'James M. Polk' > > > > Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 > > > > > > > > If by that you mean the endpoint gets location, recognizes an > > > emergency > > > > call, but does not route, then the proxy server has to route. > That > > > case > > > > is > > > > complex because without the LoST query, the endpoint doesn't have > the > > > > local > > > > dialstring(s). > > > > > > > > If that was not what you mean, then who routes? > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > > > Sent: Friday, June 01, 2007 5:35 PM > > > > > To: Brian Rosen; Matt Lepinski; ECRIT; James M. Polk > > > > > Subject: RE: [Ecrit] RE: Comments on: > draft-ietf-ecrit-phonebcp-01 > > > > > > > > > > I think that there is one other variant on two. > > > > > > > > > > The End-point makes the call the service URN and includes a > provided > > > > > locationURI. Outbound-proxy does nothing special. > > > > > > > > > > > -----Original Message----- > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > Sent: Friday, 1 June 2007 10:36 PM > > > > > > To: 'Matt Lepinski'; 'ECRIT'; 'James M. Polk' > > > > > > Subject: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 > > > > > > > > > > > > Thanks for your comments. > > > > > > > > > > > > The BCP really shouldn't be SIP specific. We need to broaden > it > > > to, > > > > > for > > > > > > example, XMPP. We can have SIP specific information, but it > > > should be > > > > > > discussed as just that. > > > > > > > > > > > > There is a consensus, I believe, on how to mark emergency > calls, > > > > > > represented > > > > > > by the thread, but chairs have to call consensus, not me. I > think > > > > > there > > > > > > are > > > > > > three cases: > > > > > > 1. The endpoint recognizes it's an emergency call, does the > LoST > > > > > routing, > > > > > > and passes the call to its outbound proxy server. In this > case > > > the > > > > > > Request > > > > > > URI will be the PSAP URI from LoST, and adds a Route header > with > > > the > > > > > > service > > > > > > URN. > > > > > > 2. The endpoint recognizes it's an emergency call, but doesn't > > > LoST > > > > > route > > > > > > it. In this case the Request URI would be the service URN. > The > > > > > outbound > > > > > > proxy server would do the LoST routing, put the Route header > with > > > the > > > > > > service URN in and change the Request URI to the PSAP URI. > > > > > > 3. The endpoint doesn't even recognize it's an emergency call. > In > > > > > this > > > > > > case, the endpoint would put the dialstring in the Request > URI. > > > The > > > > > > outbound proxy would behave as in 2 above. > > > > > > > > > > > > When the PSAP gets the call, it will always have its URI in > the > > > > > Request > > > > > > URI, > > > > > > and there will be a service URN in a Route header. > > > > > > > > > > > > Probably, phonebcp should say that more clearly. > > > > > > > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Matt Lepinski [mailto:mlepinski@bbn.com] > > > > > > > Sent: Friday, June 01, 2007 12:49 AM > > > > > > > To: ECRIT; James M. Polk; br@brianrosen.net > > > > > > > Subject: Comments on: draft-ietf-ecrit-phonebcp-01 > > > > > > > > > > > > > > Brian and James: > > > > > > > > > > > > > > First, two very high level questions. > > > > > > > > > > > > > > A) [Is this document supposed to be SIP-Centric?] It is > unclear > > > to > > > > > me > > > > > > > whether the document is intended as a BCP for SIP User > Agents > > > and > > > > > SIP > > > > > > > proxies, or whether it is more generally a BCP for end > points > > > and > > > > > > > signaling-path devices which may or may not use SIP. For > > > instance, > > > > > > > Section 6.4 is written as though SIP signaling were a > special > > > case, > > > > > and > > > > > > > yet paragraph four of Section 5 indicates that all emergency > > > calls > > > > > on > > > > > > > the wire should contain a Route header (which is a > SIP-specific > > > > > > > signaling component). Personally, I don't care whether or > not > > > the > > > > > > > document is SIP centric, or whether SIP is a special case, > as > > > long > > > > > as > > > > > > > the document is consistent. > > > > > > > > > > > > > > B) [Is there consensus on how to mark emergency calls?] The > > > current > > > > > > > version of phonebcp indicates that (in the normal case when > > > > > end-points > > > > > > > perform the LoST mapping) emergency calls are marked by > putting > > > the > > > > > URN > > > > > > > in a Route header (with a "loose" parameter that I'm not > > > familiar > > > > > with > > > > > > > ... can someone provide me with a reference) and that the > URN is > > > > > placed > > > > > > > in the Request-URI when the end-point is unable to perform > the > > > LoST > > > > > > > mapping). Personally, I don't understand the current > mechanism > > > > > because > > > > > > > I'm not sure what an "ordinary" (RFC3261-compliant) proxy > does > > > when > > > > > it > > > > > > > sees a service URN in the top Route header. However, given > the > > > long > > > > > > > discussion that occured on call marking in January (See: > > > > > > > > > > http://www1.ietf.org/mail-archive/web/ecrit/current/msg02963.html), > > > > > > > perhaps the more important question is "Has consensus been > > > reached > > > > > that > > > > > > > (something like) the current mechanism is an appropriate way > to > > > mark > > > > > > > messages?" > > > > > > > > > > > > > > --------------------------------- > > > > > > > More detailed comments: > > > > > > > > > > > > > > Section 2: (paragraph 3 - number 2) > > > > > > > Is it clear what the "visited location's emergency number" > means > > > in > > > > > this > > > > > > > context? > > > > > > > Consider changing to "the local emergency number for its > current > > > > > > > location" or providing a forward reference to the discussion > of > > > > > > > dial-strings in Section 5. > > > > > > > > > > > > > > Section 2: (paragraph 4) > > > > > > > I agree with Barbara that if this is intended to an overview > of > > > call > > > > > > > setup for the special case of an Ethernet connected phone > then > > > the > > > > > > > bullets should match up more clearly with the numbered items > in > > > the > > > > > > > previous paragraph. > > > > > > > > > > > > > > Section 2: (last paragraph) > > > > > > > It is unclear whether the antecedent of "it" in the last > > > paragraph > > > > > is > > > > > > > [RFC4103] or [RFC4504]. > > > > > > > > > > > > > > Section 3: > > > > > > > Consider changing "should support" to "SHOULD support" > > > > > > > > > > > > > > Section 3: (paragraph 2) > > > > > > > It seems that the point of this paragraph is to say that a > > > certain > > > > > class > > > > > > > of devices that communicates over IP networks should support > > > > > emergency > > > > > > > calls. However, I find the phrase "using current (evolving) > > > > > standards" > > > > > > > to be unclear and in particular I'm not sure what the phrase > > > > > modifies. > > > > > > > (E.g. Do you mean "Devices that create media sessions using > > > current > > > > > > > (evolving) standards and exchange audio ...") > > > > > > > > > > > > > > Section 4: (first paragraph) > > > > > > > Consider replacing "the norm" with "required" (or a similar > > > word). I > > > > > > > think the point is not that automatic location is > common/normal > > > but > > > > > that > > > > > > > it is necessary since most users are unable to provide > accurate > > > > > > location. > > > > > > > > > > > > > > Section 4.1: (first paragraph) > > > > > > > I think "cellular" (or "traditional wireless") is more > precise > > > than > > > > > > > "mobile". > > > > > > > > > > > > > > Section 4.2: (first paragraph ... also, the last paragraph) > > > > > > > Consider changing the phrase "the desired result" to > something > > > like > > > > > "an > > > > > > > equivalent result", or perhaps something even more explicit. > > > > > > > > > > > > > > Section 4.2: (first paragraph) > > > > > > > Consider addition a phrase to the last sentence indicating > why > > > it is > > > > > > > recommended that the network support a standardized LCP. > (This > > > may > > > > > not > > > > > > > be obvious to the reader). Also, consider changing > "recommended" > > > to > > > > > > > "RECOMMENDED". > > > > > > > > > > > > > > Section 4.2: (paragraph 2) > > > > > > > Given that the paragraph covers what both devices and access > > > > > networks > > > > > > > MUST support, consider changing "For all other devices" to > "In > > > all > > > > > other > > > > > > > scenarios". > > > > > > > > > > > > > > Section 4.3: (paragraph 3) > > > > > > > The term "geo-location" is not used in RFC 3825 to describe > a > > > > > > > lat/lon/alt - style location. (Instead it uses terms like a > > > > > > > "coordinate-based geolocation"). Also, given that the > > > "geolocation" > > > > > > > header allows for civic locations, I think using > geo-location > > > here > > > > > is > > > > > > > potentially confusing. > > > > > > > Note: This comment also applies to the use of "geo reported" > in > > > the > > > > > > > third paragraph of Section 6.3 > > > > > > > > > > > > > > Section 4.4: (last paragraph) > > > > > > > Consider re-writing the second-to-the-last sentence as: > "Certain > > > > > > > commonly-used techniques for measuring location create a > > > conflict > > > > > > > between the time it takes to generate a precise location and > the > > > > > desire > > > > > > > to route the call quickly." (Also, in the following sentence > I > > > think > > > > > > > "precise" is a better word than "accurate") > > > > > > > > > > > > > > Section 5: (paragraphs 5 and 6) > > > > > > > Paragraph 5 says that devices MUST mark calls using a > > > service:sos > > > > > URN. > > > > > > > However, paragraph 6 says that mapping from dialstring to > URN > > > SHOULD > > > > > be > > > > > > > done by the endpoint. Either both paragraphs should use > "MUST" > > > or > > > > > else > > > > > > > they should both use "SHOULD". > > > > > > > > > > > > > > Section 5: (paragraph 8) > > > > > > > I don't understand what it means to be "roaming" or > "nomadic" in > > > a > > > > > > > system where there is no "visited network" > > > > > > > > > > > > > > Section 5: (last paragraph) > > > > > > > The last sentence of this paragraph seems to be redundent. > > > Consider > > > > > > > deleting it. > > > > > > > > > > > > > > Section 6.1: > > > > > > > I agree with Barbara that the use of IPSec should not be > > > prohibited > > > > > by > > > > > > > this BCP. > > > > > > > > > > > > > > Section 6.1: (number 6) > > > > > > > These instructions are for the User Agent, > P-Asserted-Identity > > > > > headers > > > > > > > and Identity headers should not be inserted by the UA > > > > > > > > > > > > > > Section 6.1: (number 10) > > > > > > > This item is unclear to me. Is the author's intention that > this > > > item > > > > > > > handles the case where a UA does not know its own location? > If > > > so, I > > > > > > > guess that updating this item should be deferred until > consensus > > > is > > > > > > > reached on location-hiding. > > > > > > > > > > > > > > Section 6.1: > > > > > > > Consider Re-ordering the items as: > > > > > > > 11, 10, 12, 14, 15, 13 > > > > > > > Also, consider deleting 12, I believe it is redundent given > 9, > > > 10 > > > > > and > > > > > > 11. > > > > > > > > > > > > > > Section 6.2: (number 1) > > > > > > > Consider adding an example after "... URN appropriate for > the > > > > > emergency > > > > > > > dialstring." That is, consider adding (e.g., ...) > > > > > > > > > > > > > > Section 6.2: (number 3) > > > > > > > I'm afraid that I don't understand the meaning of this > sentence. > > > > > > > > > > > > > > Section 6.3: (paragraph 3) > > > > > > > The sentence that begins "This can be an enclosing ..." is > > > unclear > > > > > to > > > > > > > me. Are you suggesting that when a PSAP coverage region is > > > complex, > > > > > that > > > > > > > a LoST server SHOULD return a simple polygon that (a) > contains > > > the > > > > > > > location of the device; and (b) is entirely contained within > the > > > > > PSAP > > > > > > > coverage region? > > > > > > > > > > > > > > Section 6.5: (number 3) > > > > > > > This seems to imply that proxies should expect to SUBSCRIBE > to > > > > > Presence. > > > > > > > Do you mean that proxies should expect the PSAP to SUBSCRIBE > to > > > > > > Presence? > > > > > > > > > > > > > > Section 6.5: (number 4) > > > > > > > I'm not very familiar with Session Timers, can you provide a > > > > > reference. > > > > > > > > > > > > > > Section 6.6: > > > > > > > I'm afraid I don't understand the parenthetical remark after > the > > > > > "Call > > > > > > > Forward" bullet. (Consider removing the remark or re-wording > it > > > if > > > > > it is > > > > > > > important). > > > > > > > > > > > > > > Section 7: > > > > > > > Given the text in Section 4.4 it seems to me that the first > > > > > paragraph of > > > > > > > Section 7 is redundent and should be deleted. > > > > > > > > > > > > > > Section 10.2: > > > > > > > Given the difficulty of implementing location signing in a > > > useful > > > > > > > manner, I think that that either paragraph 2 should either > be > > > > > removed or > > > > > > > else it should reference some other document that explains > > > location > > > > > > > signing in more detail. (That is, one paragraph does not do > > > location > > > > > > > signing justice and it seems irresponsible to strongly > recommend > > > > > > > location signing without providing additionaly guidence to > the > > > > > > > implementor). > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > > Minor Nits: (That don't change the meaning of the text) > > > > > > > > > > > > > > Section 2: (last paragraph) > > > > > > > Put a space between [RFC4103] and "media" > > > > > > > > > > > > > > Section 3: (paragraph 1) > > > > > > > Add commas to second sentence "Future PSAPs will, however, > > > support > > > > > ..." > > > > > > > and remove the extra period at the end of the sentence > > > > > > > > > > > > > > Section 4.1: (paragraph 2) > > > > > > > Change "... where it is the access network that knows the > > > location > > > > > ..." > > > > > > > to "... when only the access network knows the location ..." > > > > > > > > > > > > > > Section 4.4: (paragraph 1) > > > > > > > Change "... process engaged from establishing a VPN ... " to > > > "... > > > > > > > process engaged by establishing a VPN ..." > > > > > > > > > > > > > > Section 4.4: (paragraph 2) > > > > > > > Change "... related to the mobility of the device and ..." > to > > > "... > > > > > > > related to the degree of device mobility and ..." > > > > > > > > > > > > > > Section 4.4: (paragraph 2) > > > > > > > Combine the final 2 sentances as follows: > > > > > > > "When a device is aware that it has moved, for instance when > it > > > > > changes > > > > > > > access points, the device SHOULD refresh its location." > > > > > > > > > > > > > > Section 4.4: (last paragraph) > > > > > > > Change "... getting more recent location ..." to "... > getting > > > > > updated > > > > > > > location ..." or "... obtaining a fresh location" > > > > > > > > > > > > > > Section 5: (first paragraph) > > > > > > > Consider re-writing as: > > > > > > > "A device (or a downstream signaling element) identifies an > > > > > emergency > > > > > > > call by an "address", which in most cases is a dialstring, > > > although > > > > > > > other user interfaces may be used." > > > > > > > > > > > > > > Section 5: (paragraph 2) > > > > > > > First sentence has too many words modifying the word > "element". > > > > > > Consider: > > > > > > > "Note: It is undesirable for a user-interface to enable a > user > > > to > > > > > place > > > > > > > an emergency call by pressing a single button." > > > > > > > > > > > > > > Section 5: (paragraph 3) > > > > > > > Consider changing the first sentence: > > > > > > > "... in other countries there are several 3 digit numbers > used > > > for > > > > > > > different types of emergency calls." > > > > > > > > > > > > > > Section 5: (paragraph 6) > > > > > > > Change "... some entity needs to ..." to "... some entity on > the > > > > > > > signaling path must ..." > > > > > > > > > > > > > > Section 5: (paragraph 9) > > > > > > > Change "... from North America, the home ..." to "... from > North > > > > > > > America, then while in North America the home ..." > > > > > > > > > > > > > > Section 5: (last paragraph) > > > > > > > Add a close parenthesis ")" after "dialstrings." > > > > > > > > > > > > > > Section 6: > > > > > > > Change "... is expected be supported ..." to "... is > expected to > > > be > > > > > > > supported ..." > > > > > > > > > > > > > > Section 6.1: > > > > > > > Change "signaling Method" to "signaling method" (lower > case). > > > > > > > > > > > > > > Section 6.1: (number 1) > > > > > > > Change "To: SHOULD" to "Request-URI: SHOULD" > > > > > > > > > > > > > > Section 6.1: (number 2) > > > > > > > Add a space between [I-D.rosen-iptel-dialstring] and "with" > > > > > > > Also change "sips MUST be ..." to "a sips URI MUST be ..." > > > > > > > > > > > > > > Section 6.2: (number 1) > > > > > > > Change "If it finds it it MUST:" to "If it finds the > dialstring > > > it > > > > > > MUST:" > > > > > > > Also, change "... for the endpoint" to "... of the end > device." > > > > > (note > > > > > > > that period was missing) > > > > > > > > > > > > > > Section 6.3: (paragraph 3) > > > > > > > Non-parallel sentence structure. Consider re-writing the > last > > > > > sentence > > > > > > as: > > > > > > > "In the case of civic location, the LoST server SHOULD > report > > > that > > > > > the > > > > > > > same mapping is good within a community name or even a > street, > > > as > > > > > this > > > > > > > is helpful for WiFi connected devices that roam and obtain > civic > > > > > > > location from the AP to which they connect." > > > > > > > (Or perhaps "Despite the fact that civic location is > uncommon > > > for > > > > > mobile > > > > > > > devices, the LoST server SHOULD ...") > > > > > > > > > > > > > > Section 6.3: (paragraph 4) > > > > > > > Change "... URI of the service URN ..." to "... URI of a > service > > > URN > > > > > > ..." > > > > > > > > > > > > > > Section 6.3: (last paragraph) > > > > > > > Re-write the last sentence as: "The proxy then replaces the > > > > > Request-URI > > > > > > > with the resulting PSAP URI." > > > > > > > Or perhaps "The resulting PSAP URI then replaces the > > > Request-URI" > > > > > > > > > > > > > > Section 6.4: (first paragraph) > > > > > > > Consider adding the phrase "Once the mapping to a PSAP URI > has > > > been > > > > > > > performed," to the begining of the paragraph (to improve the > > > flow of > > > > > the > > > > > > > document). > > > > > > > > > > > > > > Section 6.6: > > > > > > > Change "The emergency dialstrings ..." to "Emergency > dialstrings > > > > > ..." > > > > > > > > > > > > > > Section 7: (paragraph 3) > > > > > > > Change "For calls send with ..." to "For calls sent with > ..." > > > > > > > > > > > > > > Section 8: (paragraph 1) > > > > > > > Change "... media streams on RTP ... " to "... media stream > > > using > > > > > RTP > > > > > > ..." > > > > > > > or perhaps "... media streams via RTP ..." > > > > > > > Also, consider re-writing the 4th sentence as: > > > > > > > "Future IP-enabled PSAPs should accept a wider array of > > > potential > > > > > media > > > > > > > types." > > > > > > > > > > > > > > Section 8: (paragraph 2) > > > > > > > Add a period between "the offer" and "Silence suppression". > > > > > > > > > > > > > > Section 10: > > > > > > > Change "... it specifies use of several ..." to "... it > > > specifies > > > > > the > > > > > > > use of several ..." > > > > > > > > > > > > > > Section 10.1: (paragraph 2) > > > > > > > Change "... DHCP is the LCP [RFC3118] ..." to "... DHCP is > the > > > LCP, > > > > > > > [RFC3118] ..." (add a comma) > > > > > > > Also, change "... spoofing would be ..." to "... spoofing is > > > ..." > > > > > > > > > > > > > > Section 10.1: (last paragraph) > > > > > > > Add an 's' to change "Client SHOULD" to "Clients SHOULD" > > > > > > > > > > > > > > Section 10.2: (last paragraph) > > > > > > > Change "... signaling would help significantly." to "... > > > signaling > > > > > helps > > > > > > > significantly." > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Ecrit mailing list > > > > > > Ecrit@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > ---------------------- > > > > > This message is for the designated recipient only and may > > > > > contain privileged, proprietary, or otherwise private > information. > > > > > If you have received it in error, please notify the sender > > > > > immediately and delete the original. Any unauthorized use of > > > > > this email is prohibited. > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > ---------------------- > > > > > [mf2] > > > > > > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > [mf2] > > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 01 18:42:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFpF-0004ez-OW; Fri, 01 Jun 2007 18:42:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFpE-0004es-Iz for ecrit@ietf.org; Fri, 01 Jun 2007 18:42:28 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuFp9-0003eG-Kd for ecrit@ietf.org; Fri, 01 Jun 2007 18:42:28 -0400 X-SEF-Processed: 5_0_0_910__2007_06_01_17_49_47 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 01 Jun 2007 17:49:47 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Jun 2007 17:42:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 Date: Fri, 1 Jun 2007 17:42:16 -0500 Message-ID: In-Reply-To: <0cb601c7a49d$c25ec540$6601a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 Thread-Index: AcekCFEPcS0iQckvRVWGxa+1mAstOgAQAffgABMPLZAAAWw9QAAAS3KAAAAtGGAAAA9IoAAAR+PQAAAVaoA= References: <465FA53B.80802@bbn.com> <0add01c7a449$6846b260$6601a8c0@cis.neustar.com> <0cb001c7a49a$b2844440$6601a8c0@cis.neustar.com> <0cb301c7a49c$31472cb0$6601a8c0@cis.neustar.com> <0cb601c7a49d$c25ec540$6601a8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Matt Lepinski" , "ECRIT" , "James M. Polk" X-OriginalArrivalTime: 01 Jun 2007 22:42:21.0182 (UTC) FILETIME=[1D9AC9E0:01C7A49E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4ec58ef3f343ebf5ac40a04538f9a6fc Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I don't think so.=0D=0AThe carriers have largely said that they prefer solu= tion 3, but COULD=0D=0Awork with solution 1. That to me is not consensus on= solution 1 but more=0D=0Aconsensus on solution 3. I am yet to see anyone s= uggest how solution 1=0D=0Acould possibly be done with civic locations. Sol= ution 3 will work with=0D=0Aboth civic and geo without any problems.=0D=0A=0D= =0ASo I think this is where the disagreement comes from.=0D=0A=0D=0A=0D=0A=0D= =0A> -----Original Message-----=0D=0A> From: Brian Rosen [mailto:br@brianro= sen.net]=0D=0A> Sent: Saturday, 2 June 2007 8:40 AM=0D=0A> To: Winterbottom= , James; 'Matt Lepinski'; 'ECRIT'; 'James M. Polk'=0D=0A> Subject: RE: [Ecr= it] RE: Comments on: draft-ietf-ecrit-phonebcp-01=0D=0A>=20=0D=0A> So far, = the location hiding thing is you get coarse location and you=0D=0ALoST=0D=0A= > route with it. There are people unhappy with that, who want the LCP=0D=0A= to=0D=0A> return LoST data, or LoST to do dereference. My read of rough=0D= =0Aconsensus=0D=0A> was=0D=0A> coarse location, but chairs have to call tha= t one.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A> > -----Original Message-----=0D= =0A> > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=0D=0A= > > Sent: Friday, June 01, 2007 6:30 PM=0D=0A> > To: Brian Rosen; Matt Lepi= nski; ECRIT; James M. Polk=0D=0A> > Subject: RE: [Ecrit] RE: Comments on: d= raft-ietf-ecrit-phonebcp-01=0D=0A> >=0D=0A> > Except that the end-point doe= sn't do the LoST thing=0D=0A> >=0D=0A> >=0D=0A> > > -----Original Message--= ---=0D=0A> > > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > > Sent= : Saturday, 2 June 2007 8:29 AM=0D=0A> > > To: Winterbottom, James; 'Matt L= epinski'; 'ECRIT'; 'James M. Polk'=0D=0A> > > Subject: RE: [Ecrit] RE: Comm= ents on: draft-ietf-ecrit-phonebcp-01=0D=0A> > >=0D=0A> > > But that is cas= e 1=0D=0A> > >=0D=0A> > > > -----Original Message-----=0D=0A> > > > From: W= interbottom, James [mailto:James.Winterbottom@andrew.com]=0D=0A> > > > Sent= : Friday, June 01, 2007 6:24 PM=0D=0A> > > > To: Brian Rosen; Matt Lepinski= ; ECRIT; James M. Polk=0D=0A> > > > Subject: RE: [Ecrit] RE: Comments on:=0D= =0Adraft-ietf-ecrit-phonebcp-01=0D=0A> > > >=0D=0A> > > > I was assuming th= at the end-point is given a location URI, local=0D=0A> > > > dialsring, and= service URNs. Say in the location hiding case.=0D=0A> > > >=0D=0A> > > >=0D= =0A> > > > > -----Original Message-----=0D=0A> > > > > From: Brian Rosen [m= ailto:br@brianrosen.net]=0D=0A> > > > > Sent: Saturday, 2 June 2007 8:18 AM=0D= =0A> > > > > To: Winterbottom, James; 'Matt Lepinski'; 'ECRIT'; 'James M.=0D= =0APolk'=0D=0A> > > > > Subject: RE: [Ecrit] RE: Comments on:=0D=0Adraft-ie= tf-ecrit-phonebcp-01=0D=0A> > > > >=0D=0A> > > > > If by that you mean the = endpoint gets location, recognizes an=0D=0A> > > > emergency=0D=0A> > > > >= call, but does not route, then the proxy server has to route.=0D=0A> > Tha= t=0D=0A> > > > case=0D=0A> > > > > is=0D=0A> > > > > complex because withou= t the LoST query, the endpoint doesn't=0D=0Ahave=0D=0A> > the=0D=0A> > > > = > local=0D=0A> > > > > dialstring(s).=0D=0A> > > > >=0D=0A> > > > > If that= was not what you mean, then who routes=3F=0D=0A> > > > >=0D=0A> > > > > Br= ian=0D=0A> > > > >=0D=0A> > > > > > -----Original Message-----=0D=0A> > > >= > > From: Winterbottom, James=0D=0A[mailto:James.Winterbottom@andrew.com]=0D= =0A> > > > > > Sent: Friday, June 01, 2007 5:35 PM=0D=0A> > > > > > To: Bri= an Rosen; Matt Lepinski; ECRIT; James M. Polk=0D=0A> > > > > > Subject: RE:= [Ecrit] RE: Comments on:=0D=0A> > draft-ietf-ecrit-phonebcp-01=0D=0A> > > = > > >=0D=0A> > > > > > I think that there is one other variant on two.=0D=0A= > > > > > >=0D=0A> > > > > > The End-point makes the call the service URN a= nd includes a=0D=0A> > provided=0D=0A> > > > > > locationURI. Outbound-prox= y does nothing special.=0D=0A> > > > > >=0D=0A> > > > > > > -----Original M= essage-----=0D=0A> > > > > > > From: Brian Rosen [mailto:br@brianrosen.net]=0D= =0A> > > > > > > Sent: Friday, 1 June 2007 10:36 PM=0D=0A> > > > > > > To: = 'Matt Lepinski'; 'ECRIT'; 'James M. Polk'=0D=0A> > > > > > > Subject: [Ecri= t] RE: Comments on:=0D=0Adraft-ietf-ecrit-phonebcp-01=0D=0A> > > > > > >=0D= =0A> > > > > > > Thanks for your comments.=0D=0A> > > > > > >=0D=0A> > > > = > > > The BCP really shouldn't be SIP specific. We need to=0D=0Abroaden=0D= =0A> > it=0D=0A> > > > to,=0D=0A> > > > > > for=0D=0A> > > > > > > example,= XMPP. We can have SIP specific information, but=0D=0Ait=0D=0A> > > > shou= ld be=0D=0A> > > > > > > discussed as just that.=0D=0A> > > > > > >=0D=0A> = > > > > > > There is a consensus, I believe, on how to mark emergency=0D=0A= > > calls,=0D=0A> > > > > > > represented=0D=0A> > > > > > > by the thread,= but chairs have to call consensus, not me.=0D=0AI=0D=0A> > think=0D=0A> > = > > > > there=0D=0A> > > > > > > are=0D=0A> > > > > > > three cases:=0D=0A>= > > > > > > 1. The endpoint recognizes it's an emergency call, does=0D=0At= he=0D=0A> > LoST=0D=0A> > > > > > routing,=0D=0A> > > > > > > and passes th= e call to its outbound proxy server. In this=0D=0A> > case=0D=0A> > > > th= e=0D=0A> > > > > > > Request=0D=0A> > > > > > > URI will be the PSAP URI fr= om LoST, and adds a Route=0D=0Aheader=0D=0A> > with=0D=0A> > > > the=0D=0A>= > > > > > > service=0D=0A> > > > > > > URN.=0D=0A> > > > > > > 2. The endp= oint recognizes it's an emergency call, but=0D=0Adoesn't=0D=0A> > > > LoST=0D= =0A> > > > > > route=0D=0A> > > > > > > it. In this case the Request URI w= ould be the service=0D=0AURN.=0D=0A> > The=0D=0A> > > > > > outbound=0D=0A>= > > > > > > proxy server would do the LoST routing, put the Route=0D=0Ahea= der=0D=0A> > with=0D=0A> > > > the=0D=0A> > > > > > > service URN in and ch= ange the Request URI to the PSAP URI.=0D=0A> > > > > > > 3. The endpoint do= esn't even recognize it's an emergency=0D=0Acall.=0D=0A> > In=0D=0A> > > > = > > this=0D=0A> > > > > > > case, the endpoint would put the dialstring in = the Request=0D=0A> > URI.=0D=0A> > > > The=0D=0A> > > > > > > outbound prox= y would behave as in 2 above.=0D=0A> > > > > > >=0D=0A> > > > > > > When th= e PSAP gets the call, it will always have its URI=0D=0Ain=0D=0A> > the=0D=0A= > > > > > > Request=0D=0A> > > > > > > URI,=0D=0A> > > > > > > and there wi= ll be a service URN in a Route header.=0D=0A> > > > > > >=0D=0A> > > > > > = > Probably, phonebcp should say that more clearly.=0D=0A> > > > > > >=0D=0A= > > > > > > > Brian=0D=0A> > > > > > >=0D=0A> > > > > > > > -----Original M= essage-----=0D=0A> > > > > > > > From: Matt Lepinski [mailto:mlepinski@bbn.= com]=0D=0A> > > > > > > > Sent: Friday, June 01, 2007 12:49 AM=0D=0A> > > >= > > > > To: ECRIT; James M. Polk; br@brianrosen.net=0D=0A> > > > > > > > S= ubject: Comments on: draft-ietf-ecrit-phonebcp-01=0D=0A> > > > > > > >=0D=0A= > > > > > > > > Brian and James:=0D=0A> > > > > > > >=0D=0A> > > > > > > > = First, two very high level questions.=0D=0A> > > > > > > >=0D=0A> > > > > >= > > A) [Is this document supposed to be SIP-Centric=3F] It is=0D=0A> > unc= lear=0D=0A> > > > to=0D=0A> > > > > > me=0D=0A> > > > > > > > whether the d= ocument is intended as a BCP for SIP User=0D=0A> > Agents=0D=0A> > > > and=0D= =0A> > > > > > SIP=0D=0A> > > > > > > > proxies, or whether it is more gene= rally a BCP for end=0D=0A> > points=0D=0A> > > > and=0D=0A> > > > > > > > s= ignaling-path devices which may or may not use SIP. For=0D=0A> > > > instan= ce,=0D=0A> > > > > > > > Section 6.4 is written as though SIP signaling wer= e a=0D=0A> > special=0D=0A> > > > case,=0D=0A> > > > > > and=0D=0A> > > > >= > > > yet paragraph four of Section 5 indicates that all=0D=0Aemergency=0D= =0A> > > > calls=0D=0A> > > > > > on=0D=0A> > > > > > > > the wire should c= ontain a Route header (which is a=0D=0A> > SIP-specific=0D=0A> > > > > > > = > signaling component). Personally, I don't care whether=0D=0Aor=0D=0A> > n= ot=0D=0A> > > > the=0D=0A> > > > > > > > document is SIP centric, or whethe= r SIP is a special=0D=0Acase,=0D=0A> > as=0D=0A> > > > long=0D=0A> > > > > = > as=0D=0A> > > > > > > > the document is consistent.=0D=0A> > > > > > > >=0D= =0A> > > > > > > > B) [Is there consensus on how to mark emergency calls=3F= ]=0D=0AThe=0D=0A> > > > current=0D=0A> > > > > > > > version of phonebcp in= dicates that (in the normal case=0D=0Awhen=0D=0A> > > > > > end-points=0D=0A= > > > > > > > > perform the LoST mapping) emergency calls are marked by=0D=0A= > > putting=0D=0A> > > > the=0D=0A> > > > > > URN=0D=0A> > > > > > > > in a= Route header (with a "loose" parameter that I'm not=0D=0A> > > > familiar=0D= =0A> > > > > > with=0D=0A> > > > > > > > ... can someone provide me with a = reference) and that=0D=0Athe=0D=0A> > URN is=0D=0A> > > > > > placed=0D=0A>= > > > > > > > in the Request-URI when the end-point is unable to=0D=0Aperf= orm=0D=0A> > the=0D=0A> > > > LoST=0D=0A> > > > > > > > mapping). Personall= y, I don't understand the current=0D=0A> > mechanism=0D=0A> > > > > > becau= se=0D=0A> > > > > > > > I'm not sure what an "ordinary" (RFC3261-compliant)=0D= =0Aproxy=0D=0A> > does=0D=0A> > > > when=0D=0A> > > > > > it=0D=0A> > > > >= > > > sees a service URN in the top Route header. However,=0D=0Agiven=0D=0A= > > the=0D=0A> > > > long=0D=0A> > > > > > > > discussion that occured on c= all marking in January (See:=0D=0A> > > > > > > >=0D=0A> > > >=0D=0Ahttp://= www1.ietf.org/mail-archive/web/ecrit/current/msg02963.html),=0D=0A> > > > >= > > > perhaps the more important question is "Has consensus=0D=0Abeen=0D=0A= > > > > reached=0D=0A> > > > > > that=0D=0A> > > > > > > > (something like)= the current mechanism is an appropriate=0D=0Away=0D=0A> > to=0D=0A> > > > = mark=0D=0A> > > > > > > > messages=3F"=0D=0A> > > > > > > >=0D=0A> > > > > = > > > ---------------------------------=0D=0A> > > > > > > > More detailed = comments:=0D=0A> > > > > > > >=0D=0A> > > > > > > > Section 2: (paragraph 3= - number 2)=0D=0A> > > > > > > > Is it clear what the "visited location's = emergency=0D=0Anumber"=0D=0A> > means=0D=0A> > > > in=0D=0A> > > > > > this=0D= =0A> > > > > > > > context=3F=0D=0A> > > > > > > > Consider changing to "th= e local emergency number for its=0D=0A> > current=0D=0A> > > > > > > > loca= tion" or providing a forward reference to the=0D=0Adiscussion=0D=0A> > of=0D= =0A> > > > > > > > dial-strings in Section 5.=0D=0A> > > > > > > >=0D=0A> >= > > > > > > Section 2: (paragraph 4)=0D=0A> > > > > > > > I agree with Bar= bara that if this is intended to an=0D=0Aoverview=0D=0A> > of=0D=0A> > > > = call=0D=0A> > > > > > > > setup for the special case of an Ethernet connect= ed=0D=0Aphone=0D=0A> > then=0D=0A> > > > the=0D=0A> > > > > > > > bullets s= hould match up more clearly with the numbered=0D=0Aitems=0D=0A> > in=0D=0A>= > > > the=0D=0A> > > > > > > > previous paragraph.=0D=0A> > > > > > > >=0D= =0A> > > > > > > > Section 2: (last paragraph)=0D=0A> > > > > > > > It is u= nclear whether the antecedent of "it" in the last=0D=0A> > > > paragraph=0D= =0A> > > > > > is=0D=0A> > > > > > > > [RFC4103] or [RFC4504].=0D=0A> > > >= > > > >=0D=0A> > > > > > > > Section 3:=0D=0A> > > > > > > > Consider chan= ging "should support" to "SHOULD support"=0D=0A> > > > > > > >=0D=0A> > > >= > > > > Section 3: (paragraph 2)=0D=0A> > > > > > > > It seems that the po= int of this paragraph is to say that=0D=0Aa=0D=0A> > > > certain=0D=0A> > >= > > > class=0D=0A> > > > > > > > of devices that communicates over IP netw= orks should=0D=0Asupport=0D=0A> > > > > > emergency=0D=0A> > > > > > > > ca= lls. However, I find the phrase "using current=0D=0A(evolving)=0D=0A> > > >= > > standards"=0D=0A> > > > > > > > to be unclear and in particular I'm no= t sure what the=0D=0Aphrase=0D=0A> > > > > > modifies.=0D=0A> > > > > > > >= (E.g. Do you mean "Devices that create media sessions=0D=0Ausing=0D=0A> > = > > current=0D=0A> > > > > > > > (evolving) standards and exchange audio ..= =2E")=0D=0A> > > > > > > >=0D=0A> > > > > > > > Section 4: (first paragraph= )=0D=0A> > > > > > > > Consider replacing "the norm" with "required" (or a=0D= =0Asimilar=0D=0A> > > > word). I=0D=0A> > > > > > > > think the point is no= t that automatic location is=0D=0A> > common/normal=0D=0A> > > > but=0D=0A>= > > > > > that=0D=0A> > > > > > > > it is necessary since most users are u= nable to provide=0D=0A> > accurate=0D=0A> > > > > > > location.=0D=0A> > > = > > > > >=0D=0A> > > > > > > > Section 4.1: (first paragraph)=0D=0A> > > > = > > > > I think "cellular" (or "traditional wireless") is more=0D=0A> > pr= ecise=0D=0A> > > > than=0D=0A> > > > > > > > "mobile".=0D=0A> > > > > > > >=0D= =0A> > > > > > > > Section 4.2: (first paragraph ... also, the last=0D=0Apa= ragraph)=0D=0A> > > > > > > > Consider changing the phrase "the desired res= ult" to=0D=0A> > something=0D=0A> > > > like=0D=0A> > > > > > "an=0D=0A> > = > > > > > > equivalent result", or perhaps something even more=0D=0Aexplici= t.=0D=0A> > > > > > > >=0D=0A> > > > > > > > Section 4.2: (first paragraph)=0D= =0A> > > > > > > > Consider addition a phrase to the last sentence=0D=0Aind= icating=0D=0A> > why=0D=0A> > > > it is=0D=0A> > > > > > > > recommended th= at the network support a standardized LCP.=0D=0A> > (This=0D=0A> > > > may=0D= =0A> > > > > > not=0D=0A> > > > > > > > be obvious to the reader). Also, co= nsider changing=0D=0A> > "recommended"=0D=0A> > > > to=0D=0A> > > > > > > >= "RECOMMENDED".=0D=0A> > > > > > > >=0D=0A> > > > > > > > Section 4.2: (par= agraph 2)=0D=0A> > > > > > > > Given that the paragraph covers what both de= vices and=0D=0Aaccess=0D=0A> > > > > > networks=0D=0A> > > > > > > > MUST s= upport, consider changing "For all other devices"=0D=0Ato=0D=0A> > "In=0D=0A= > > > > all=0D=0A> > > > > > other=0D=0A> > > > > > > > scenarios".=0D=0A> = > > > > > > >=0D=0A> > > > > > > > Section 4.3: (paragraph 3)=0D=0A> > > > = > > > > The term "geo-location" is not used in RFC 3825 to=0D=0Adescribe=0D= =0A> > a=0D=0A> > > > > > > > lat/lon/alt - style location. (Instead it use= s terms=0D=0Alike a=0D=0A> > > > > > > > "coordinate-based geolocation"). A= lso, given that the=0D=0A> > > > "geolocation"=0D=0A> > > > > > > > header = allows for civic locations, I think using=0D=0A> > geo-location=0D=0A> > > = > here=0D=0A> > > > > > is=0D=0A> > > > > > > > potentially confusing.=0D=0A= > > > > > > > > Note: This comment also applies to the use of "geo=0D=0Arep= orted"=0D=0A> > in=0D=0A> > > > the=0D=0A> > > > > > > > third paragraph of= Section 6.3=0D=0A> > > > > > > >=0D=0A> > > > > > > > Section 4.4: (last = paragraph)=0D=0A> > > > > > > > Consider re-writing the second-to-the-last = sentence as:=0D=0A> > "Certain=0D=0A> > > > > > > > commonly-used technique= s for measuring location create a=0D=0A> > > > conflict=0D=0A> > > > > > > = > between the time it takes to generate a precise location=0D=0Aand=0D=0A> = > the=0D=0A> > > > > > desire=0D=0A> > > > > > > > to route the call quickl= y." (Also, in the following=0D=0Asentence=0D=0A> > I=0D=0A> > > > think=0D=0A= > > > > > > > > "precise" is a better word than "accurate")=0D=0A> > > > > = > > >=0D=0A> > > > > > > > Section 5: (paragraphs 5 and 6)=0D=0A> > > > > >= > > Paragraph 5 says that devices MUST mark calls using a=0D=0A> > > > ser= vice:sos=0D=0A> > > > > > URN.=0D=0A> > > > > > > > However, paragraph 6 sa= ys that mapping from dialstring=0D=0Ato=0D=0A> > URN=0D=0A> > > > SHOULD=0D= =0A> > > > > > be=0D=0A> > > > > > > > done by the endpoint. Either both pa= ragraphs should use=0D=0A> > "MUST"=0D=0A> > > > or=0D=0A> > > > > > else=0D= =0A> > > > > > > > they should both use "SHOULD".=0D=0A> > > > > > > >=0D=0A= > > > > > > > > Section 5: (paragraph 8)=0D=0A> > > > > > > > I don't under= stand what it means to be "roaming" or=0D=0A> > "nomadic" in=0D=0A> > > > a=0D= =0A> > > > > > > > system where there is no "visited network"=0D=0A> > > > = > > > >=0D=0A> > > > > > > > Section 5: (last paragraph)=0D=0A> > > > > > >= > The last sentence of this paragraph seems to be=0D=0Aredundent.=0D=0A> >= > > Consider=0D=0A> > > > > > > > deleting it.=0D=0A> > > > > > > >=0D=0A>= > > > > > > > Section 6.1:=0D=0A> > > > > > > > I agree with Barbara that = the use of IPSec should not be=0D=0A> > > > prohibited=0D=0A> > > > > > by=0D= =0A> > > > > > > > this BCP.=0D=0A> > > > > > > >=0D=0A> > > > > > > > Sect= ion 6.1: (number 6)=0D=0A> > > > > > > > These instructions are for the Use= r Agent,=0D=0A> > P-Asserted-Identity=0D=0A> > > > > > headers=0D=0A> > > >= > > > > and Identity headers should not be inserted by the UA=0D=0A> > > >= > > > >=0D=0A> > > > > > > > Section 6.1: (number 10)=0D=0A> > > > > > > >= This item is unclear to me. Is the author's intention=0D=0Athat=0D=0A> > t= his=0D=0A> > > > item=0D=0A> > > > > > > > handles the case where a UA does= not know its own=0D=0Alocation=3F=0D=0A> > If=0D=0A> > > > so, I=0D=0A> > = > > > > > > guess that updating this item should be deferred until=0D=0A> >= consensus=0D=0A> > > > is=0D=0A> > > > > > > > reached on location-hiding.=0D= =0A> > > > > > > >=0D=0A> > > > > > > > Section 6.1:=0D=0A> > > > > > > > C= onsider Re-ordering the items as:=0D=0A> > > > > > > > 11, 10, 12, 14, 15, = 13=0D=0A> > > > > > > > Also, consider deleting 12, I believe it is redunde= nt=0D=0Agiven=0D=0A> > 9,=0D=0A> > > > 10=0D=0A> > > > > > and=0D=0A> > > >= > > > 11.=0D=0A> > > > > > > >=0D=0A> > > > > > > > Section 6.2: (number 1= )=0D=0A> > > > > > > > Consider adding an example after "... URN appropriat= e=0D=0Afor=0D=0A> > the=0D=0A> > > > > > emergency=0D=0A> > > > > > > > dia= lstring." That is, consider adding (e.g., ...)=0D=0A> > > > > > > >=0D=0A> = > > > > > > > Section 6.2: (number 3)=0D=0A> > > > > > > > I'm afraid that = I don't understand the meaning of this=0D=0A> > sentence.=0D=0A> > > > > > = > >=0D=0A> > > > > > > > Section 6.3: (paragraph 3)=0D=0A> > > > > > > > Th= e sentence that begins "This can be an enclosing ..."=0D=0Ais=0D=0A> > > > = unclear=0D=0A> > > > > > to=0D=0A> > > > > > > > me. Are you suggesting tha= t when a PSAP coverage region=0D=0Ais=0D=0A> > > > complex,=0D=0A> > > > > = > that=0D=0A> > > > > > > > a LoST server SHOULD return a simple polygon th= at (a)=0D=0A> > contains=0D=0A> > > > the=0D=0A> > > > > > > > location of = the device; and (b) is entirely contained=0D=0Awithin=0D=0A> > the=0D=0A> >= > > > > PSAP=0D=0A> > > > > > > > coverage region=3F=0D=0A> > > > > > > >=0D= =0A> > > > > > > > Section 6.5: (number 3)=0D=0A> > > > > > > > This seems = to imply that proxies should expect to=0D=0ASUBSCRIBE=0D=0A> > to=0D=0A> > = > > > > Presence.=0D=0A> > > > > > > > Do you mean that proxies should expe= ct the PSAP to=0D=0ASUBSCRIBE=0D=0A> > to=0D=0A> > > > > > > Presence=3F=0D= =0A> > > > > > > >=0D=0A> > > > > > > > Section 6.5: (number 4)=0D=0A> > > = > > > > > I'm not very familiar with Session Timers, can you=0D=0Aprovide a=0D= =0A> > > > > > reference.=0D=0A> > > > > > > >=0D=0A> > > > > > > > Section= 6.6:=0D=0A> > > > > > > > I'm afraid I don't understand the parenthetical = remark=0D=0Aafter=0D=0A> > the=0D=0A> > > > > > "Call=0D=0A> > > > > > > > = Forward" bullet. (Consider removing the remark or=0D=0Are-wording=0D=0A> > = it=0D=0A> > > > if=0D=0A> > > > > > it is=0D=0A> > > > > > > > important).=0D= =0A> > > > > > > >=0D=0A> > > > > > > > Section 7:=0D=0A> > > > > > > > Giv= en the text in Section 4.4 it seems to me that the=0D=0Afirst=0D=0A> > > > = > > paragraph of=0D=0A> > > > > > > > Section 7 is redundent and should be = deleted.=0D=0A> > > > > > > >=0D=0A> > > > > > > > Section 10.2:=0D=0A> > >= > > > > > Given the difficulty of implementing location signing in=0D=0Aa=0D= =0A> > > > useful=0D=0A> > > > > > > > manner, I think that that either par= agraph 2 should=0D=0Aeither=0D=0A> > be=0D=0A> > > > > > removed or=0D=0A> = > > > > > > > else it should reference some other document that=0D=0Aexplai= ns=0D=0A> > > > location=0D=0A> > > > > > > > signing in more detail. (That= is, one paragraph does not=0D=0Ado=0D=0A> > > > location=0D=0A> > > > > > = > > signing justice and it seems irresponsible to strongly=0D=0A> > recomme= nd=0D=0A> > > > > > > > location signing without providing additionaly guid= ence=0D=0Ato=0D=0A> > the=0D=0A> > > > > > > > implementor).=0D=0A> > > > >= > > >=0D=0A> > > > > > > >=0D=0A> > > >=0D=0A-----------------------------= --------------------------------------=0D=0A> > > > > > > > Minor Nits: (Th= at don't change the meaning of the text)=0D=0A> > > > > > > >=0D=0A> > > > = > > > > Section 2: (last paragraph)=0D=0A> > > > > > > > Put a space betwee= n [RFC4103] and "media"=0D=0A> > > > > > > >=0D=0A> > > > > > > > Section 3= : (paragraph 1)=0D=0A> > > > > > > > Add commas to second sentence "Future = PSAPs will,=0D=0Ahowever,=0D=0A> > > > support=0D=0A> > > > > > ..."=0D=0A>= > > > > > > > and remove the extra period at the end of the sentence=0D=0A= > > > > > > > >=0D=0A> > > > > > > > Section 4.1: (paragraph 2)=0D=0A> > > = > > > > > Change "... where it is the access network that knows=0D=0Athe=0D= =0A> > > > location=0D=0A> > > > > > ..."=0D=0A> > > > > > > > to "... when= only the access network knows the location=0D=0A..."=0D=0A> > > > > > > >=0D= =0A> > > > > > > > Section 4.4: (paragraph 1)=0D=0A> > > > > > > > Change "= =2E.. process engaged from establishing a VPN ...=0D=0A" to=0D=0A> > > > ".= =2E.=0D=0A> > > > > > > > process engaged by establishing a VPN ..."=0D=0A>= > > > > > > >=0D=0A> > > > > > > > Section 4.4: (paragraph 2)=0D=0A> > > >= > > > > Change "... related to the mobility of the device and=0D=0A..."=0D= =0A> > to=0D=0A> > > > "...=0D=0A> > > > > > > > related to the degree of d= evice mobility and ..."=0D=0A> > > > > > > >=0D=0A> > > > > > > > Section 4= =2E4: (paragraph 2)=0D=0A> > > > > > > > Combine the final 2 sentances as f= ollows:=0D=0A> > > > > > > > "When a device is aware that it has moved, for= instance=0D=0Awhen=0D=0A> > it=0D=0A> > > > > > changes=0D=0A> > > > > > >= > access points, the device SHOULD refresh its location."=0D=0A> > > > > >= > >=0D=0A> > > > > > > > Section 4.4: (last paragraph)=0D=0A> > > > > > > = > Change "... getting more recent location ..." to "...=0D=0A> > getting=0D= =0A> > > > > > updated=0D=0A> > > > > > > > location ..." or "... obtaining= a fresh location"=0D=0A> > > > > > > >=0D=0A> > > > > > > > Section 5: (fi= rst paragraph)=0D=0A> > > > > > > > Consider re-writing as:=0D=0A> > > > > = > > > "A device (or a downstream signaling element) identifies=0D=0Aan=0D=0A= > > > > > > emergency=0D=0A> > > > > > > > call by an "address", which in m= ost cases is a=0D=0Adialstring,=0D=0A> > > > although=0D=0A> > > > > > > > = other user interfaces may be used."=0D=0A> > > > > > > >=0D=0A> > > > > > >= > Section 5: (paragraph 2)=0D=0A> > > > > > > > First sentence has too man= y words modifying the word=0D=0A> > "element".=0D=0A> > > > > > > Consider:=0D= =0A> > > > > > > > "Note: It is undesirable for a user-interface to enable=0D= =0Aa=0D=0A> > user=0D=0A> > > > to=0D=0A> > > > > > place=0D=0A> > > > > > = > > an emergency call by pressing a single button."=0D=0A> > > > > > > >=0D= =0A> > > > > > > > Section 5: (paragraph 3)=0D=0A> > > > > > > > Consider c= hanging the first sentence:=0D=0A> > > > > > > > "... in other countries th= ere are several 3 digit=0D=0Anumbers=0D=0A> > used=0D=0A> > > > for=0D=0A> = > > > > > > > different types of emergency calls."=0D=0A> > > > > > > >=0D=0A= > > > > > > > > Section 5: (paragraph 6)=0D=0A> > > > > > > > Change "... s= ome entity needs to ..." to "... some=0D=0Aentity on=0D=0A> > the=0D=0A> > = > > > > > > signaling path must ..."=0D=0A> > > > > > > >=0D=0A> > > > > > = > > Section 5: (paragraph 9)=0D=0A> > > > > > > > Change "... from North Am= erica, the home ..." to "...=0D=0Afrom=0D=0A> > North=0D=0A> > > > > > > > = America, then while in North America the home ..."=0D=0A> > > > > > > >=0D=0A= > > > > > > > > Section 5: (last paragraph)=0D=0A> > > > > > > > Add a clos= e parenthesis ")" after "dialstrings."=0D=0A> > > > > > > >=0D=0A> > > > > = > > > Section 6:=0D=0A> > > > > > > > Change "... is expected be supported = =2E.." to "... is=0D=0A> > expected to=0D=0A> > > > be=0D=0A> > > > > > > >= supported ..."=0D=0A> > > > > > > >=0D=0A> > > > > > > > Section 6.1:=0D=0A= > > > > > > > > Change "signaling Method" to "signaling method" (lower=0D=0A= > > case).=0D=0A> > > > > > > >=0D=0A> > > > > > > > Section 6.1: (number 1= )=0D=0A> > > > > > > > Change "To: SHOULD" to "Request-URI: SHOULD"=0D=0A> = > > > > > > >=0D=0A> > > > > > > > Section 6.1: (number 2)=0D=0A> > > > > >= > > Add a space between [I-D.rosen-iptel-dialstring] and=0D=0A"with"=0D=0A= > > > > > > > > Also change "sips MUST be ..." to "a sips URI MUST be=0D=0A= =2E.."=0D=0A> > > > > > > >=0D=0A> > > > > > > > Section 6.2: (number 1)=0D= =0A> > > > > > > > Change "If it finds it it MUST:" to "If it finds the=0D=0A= > > dialstring=0D=0A> > > > it=0D=0A> > > > > > > MUST:"=0D=0A> > > > > > >= > Also, change "... for the endpoint" to "... of the end=0D=0A> > device."=0D= =0A> > > > > > (note=0D=0A> > > > > > > > that period was missing)=0D=0A> >= > > > > > >=0D=0A> > > > > > > > Section 6.3: (paragraph 3)=0D=0A> > > > >= > > > Non-parallel sentence structure. Consider re-writing the=0D=0A> > la= st=0D=0A> > > > > > sentence=0D=0A> > > > > > > as:=0D=0A> > > > > > > > "I= n the case of civic location, the LoST server SHOULD=0D=0A> > report=0D=0A>= > > > that=0D=0A> > > > > > the=0D=0A> > > > > > > > same mapping is good = within a community name or even a=0D=0A> > street,=0D=0A> > > > as=0D=0A> >= > > > > this=0D=0A> > > > > > > > is helpful for WiFi connected devices th= at roam and=0D=0Aobtain=0D=0A> > civic=0D=0A> > > > > > > > location from t= he AP to which they connect."=0D=0A> > > > > > > > (Or perhaps "Despite the= fact that civic location is=0D=0A> > uncommon=0D=0A> > > > for=0D=0A> > > = > > > mobile=0D=0A> > > > > > > > devices, the LoST server SHOULD ...")=0D=0A= > > > > > > > >=0D=0A> > > > > > > > Section 6.3: (paragraph 4)=0D=0A> > > = > > > > > Change "... URI of the service URN ..." to "... URI of a=0D=0A> >= service=0D=0A> > > > URN=0D=0A> > > > > > > ..."=0D=0A> > > > > > > >=0D=0A= > > > > > > > > Section 6.3: (last paragraph)=0D=0A> > > > > > > > Re-write= the last sentence as: "The proxy then replaces=0D=0Athe=0D=0A> > > > > > R= equest-URI=0D=0A> > > > > > > > with the resulting PSAP URI."=0D=0A> > > > = > > > > Or perhaps "The resulting PSAP URI then replaces the=0D=0A> > > > R= equest-URI"=0D=0A> > > > > > > >=0D=0A> > > > > > > > Section 6.4: (first p= aragraph)=0D=0A> > > > > > > > Consider adding the phrase "Once the mapping= to a PSAP=0D=0AURI=0D=0A> > has=0D=0A> > > > been=0D=0A> > > > > > > > per= formed," to the begining of the paragraph (to improve=0D=0Athe=0D=0A> > > >= flow of=0D=0A> > > > > > the=0D=0A> > > > > > > > document).=0D=0A> > > > = > > > >=0D=0A> > > > > > > > Section 6.6:=0D=0A> > > > > > > > Change "The = emergency dialstrings ..." to "Emergency=0D=0A> > dialstrings=0D=0A> > > > = > > ..."=0D=0A> > > > > > > >=0D=0A> > > > > > > > Section 7: (paragraph 3)=0D= =0A> > > > > > > > Change "For calls send with ..." to "For calls sent with=0D= =0A> > ..."=0D=0A> > > > > > > >=0D=0A> > > > > > > > Section 8: (paragraph= 1)=0D=0A> > > > > > > > Change "... media streams on RTP ... " to "... med= ia=0D=0Astream=0D=0A> > > > using=0D=0A> > > > > > RTP=0D=0A> > > > > > > .= =2E."=0D=0A> > > > > > > > or perhaps "... media streams via RTP ..."=0D=0A= > > > > > > > > Also, consider re-writing the 4th sentence as:=0D=0A> > > >= > > > > "Future IP-enabled PSAPs should accept a wider array of=0D=0A> > >= > potential=0D=0A> > > > > > media=0D=0A> > > > > > > > types."=0D=0A> > >= > > > > >=0D=0A> > > > > > > > Section 8: (paragraph 2)=0D=0A> > > > > > >= > Add a period between "the offer" and "Silence=0D=0Asuppression".=0D=0A> = > > > > > > >=0D=0A> > > > > > > > Section 10:=0D=0A> > > > > > > > Change = "... it specifies use of several ..." to "... it=0D=0A> > > > specifies=0D=0A= > > > > > > the=0D=0A> > > > > > > > use of several ..."=0D=0A> > > > > > >= >=0D=0A> > > > > > > > Section 10.1: (paragraph 2)=0D=0A> > > > > > > > Ch= ange "... DHCP is the LCP [RFC3118] ..." to "... DHCP=0D=0Ais=0D=0A> > the=0D= =0A> > > > LCP,=0D=0A> > > > > > > > [RFC3118] ..." (add a comma)=0D=0A> > = > > > > > > Also, change "... spoofing would be ..." to "...=0D=0Aspoofing = is=0D=0A> > > > ..."=0D=0A> > > > > > > >=0D=0A> > > > > > > > Section 10.1= : (last paragraph)=0D=0A> > > > > > > > Add an 's' to change "Client SHOULD= " to "Clients SHOULD"=0D=0A> > > > > > > >=0D=0A> > > > > > > > Section 10.= 2: (last paragraph)=0D=0A> > > > > > > > Change "... signaling would help s= ignificantly." to "...=0D=0A> > > > signaling=0D=0A> > > > > > helps=0D=0A>= > > > > > > > significantly."=0D=0A> > > > > > >=0D=0A> > > > > > >=0D=0A>= > > > > > >=0D=0A> > > > > > > ___________________________________________= ____=0D=0A> > > > > > > Ecrit mailing list=0D=0A> > > > > > > Ecrit@ietf.or= g=0D=0A> > > > > > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > = > > > >=0D=0A> > > > > >=0D=0A> > > >=0D=0A> >=0D=0A-----------------------= -------------------------------------------------=0D=0A> > > > > --=0D=0A> = > > > > > ----------------------=0D=0A> > > > > > This message is for the d= esignated recipient only and may=0D=0A> > > > > > contain privileged, propr= ietary, or otherwise private=0D=0A> > information.=0D=0A> > > > > > If you = have received it in error, please notify the sender=0D=0A> > > > > > immedi= ately and delete the original. Any unauthorized use=0D=0Aof=0D=0A> > > > >= > this email is prohibited.=0D=0A> > > > > >=0D=0A> > > >=0D=0A> >=0D=0A--= ----------------------------------------------------------------------=0D=0A= > > > > > --=0D=0A> > > > > > ----------------------=0D=0A> > > > > > [mf2]=0D= =0A> > > > >=0D=0A> > > >=0D=0A> > > >=0D=0A> >=0D=0A----------------------= --------------------------------------------------=0D=0A> > > --=0D=0A> > >= > ----------------------=0D=0A> > > > This message is for the designated r= ecipient only and may=0D=0A> > > > contain privileged, proprietary, or othe= rwise private=0D=0Ainformation.=0D=0A> > > > If you have received it in err= or, please notify the sender=0D=0A> > > > immediately and delete the origin= al. Any unauthorized use of=0D=0A> > > > this email is prohibited.=0D=0A> = > > >=0D=0A> >=0D=0A-------------------------------------------------------= -----------------=0D=0A> > > --=0D=0A> > > > ----------------------=0D=0A> = > > > [mf2]=0D=0A> > >=0D=0A> >=0D=0A> >=0D=0A-----------------------------= -------------------------------------------=0D=0A> --=0D=0A> > ------------= ----------=0D=0A> > This message is for the designated recipient only and m= ay=0D=0A> > contain privileged, proprietary, or otherwise private informati= on.=0D=0A> > If you have received it in error, please notify the sender=0D=0A= > > immediately and delete the original. Any unauthorized use of=0D=0A> > = this email is prohibited.=0D=0A> >=0D=0A-----------------------------------= -------------------------------------=0D=0A> --=0D=0A> > ------------------= ----=0D=0A> > [mf2]=0D=0A>=20=0D=0A=0D=0A----------------------------------= --------------------------------------------------------------=0D=0AThis me= ssage is for the designated recipient only and may=0D=0Acontain privileged,= proprietary, or otherwise private information. =20=0D=0AIf you have receiv= ed it in error, please notify the sender=0D=0Aimmediately and delete the or= iginal. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A------= ---------------------------------------------------------------------------= ---------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 01 18:47:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFuX-0007C1-Es; Fri, 01 Jun 2007 18:47:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFuW-0007Bh-9v for ecrit@ietf.org; Fri, 01 Jun 2007 18:47:56 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuFuO-0005fg-8l for ecrit@ietf.org; Fri, 01 Jun 2007 18:47:56 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HuFsH-0002JS-DH; Fri, 01 Jun 2007 17:45:38 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Matt Lepinski'" , "'ECRIT'" , "'James M. Polk'" References: <465FA53B.80802@bbn.com> <0add01c7a449$6846b260$6601a8c0@cis.neustar.com> <0cb001c7a49a$b2844440$6601a8c0@cis.neustar.com> <0cb301c7a49c$31472cb0$6601a8c0@cis.neustar.com> <0cb601c7a49d$c25ec540$6601a8c0@cis.neustar.com> Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 Date: Fri, 1 Jun 2007 18:47:44 -0400 Message-ID: <0cba01c7a49e$dff4d120$6601a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcekCFEPcS0iQckvRVWGxa+1mAstOgAQAffgABMPLZAAAWw9QAAAS3KAAAAtGGAAAA9IoAAAR+PQAAAVaoAAADC5YA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3595bc30ac813b19f4968b890e13ed6a Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'll let the chairs decide, and -phonebcp will follow. You can choose any civic location in the service area to return as a "coarse" location. For example, pick a street that lies within the service boundary, and return it with no house number. Of course, in the majority of cases, the community name will do. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Friday, June 01, 2007 6:42 PM > To: Brian Rosen; Matt Lepinski; ECRIT; James M. Polk > Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 > > I don't think so. > The carriers have largely said that they prefer solution 3, but COULD > work with solution 1. That to me is not consensus on solution 1 but more > consensus on solution 3. I am yet to see anyone suggest how solution 1 > could possibly be done with civic locations. Solution 3 will work with > both civic and geo without any problems. > > So I think this is where the disagreement comes from. > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Saturday, 2 June 2007 8:40 AM > > To: Winterbottom, James; 'Matt Lepinski'; 'ECRIT'; 'James M. Polk' > > Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 > > > > So far, the location hiding thing is you get coarse location and you > LoST > > route with it. There are people unhappy with that, who want the LCP > to > > return LoST data, or LoST to do dereference. My read of rough > consensus > > was > > coarse location, but chairs have to call that one. > > > > Brian > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Friday, June 01, 2007 6:30 PM > > > To: Brian Rosen; Matt Lepinski; ECRIT; James M. Polk > > > Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 > > > > > > Except that the end-point doesn't do the LoST thing > > > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Saturday, 2 June 2007 8:29 AM > > > > To: Winterbottom, James; 'Matt Lepinski'; 'ECRIT'; 'James M. Polk' > > > > Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 > > > > > > > > But that is case 1 > > > > > > > > > -----Original Message----- > > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > > > Sent: Friday, June 01, 2007 6:24 PM > > > > > To: Brian Rosen; Matt Lepinski; ECRIT; James M. Polk > > > > > Subject: RE: [Ecrit] RE: Comments on: > draft-ietf-ecrit-phonebcp-01 > > > > > > > > > > I was assuming that the end-point is given a location URI, local > > > > > dialsring, and service URNs. Say in the location hiding case. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > Sent: Saturday, 2 June 2007 8:18 AM > > > > > > To: Winterbottom, James; 'Matt Lepinski'; 'ECRIT'; 'James M. > Polk' > > > > > > Subject: RE: [Ecrit] RE: Comments on: > draft-ietf-ecrit-phonebcp-01 > > > > > > > > > > > > If by that you mean the endpoint gets location, recognizes an > > > > > emergency > > > > > > call, but does not route, then the proxy server has to route. > > > That > > > > > case > > > > > > is > > > > > > complex because without the LoST query, the endpoint doesn't > have > > > the > > > > > > local > > > > > > dialstring(s). > > > > > > > > > > > > If that was not what you mean, then who routes? > > > > > > > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Winterbottom, James > [mailto:James.Winterbottom@andrew.com] > > > > > > > Sent: Friday, June 01, 2007 5:35 PM > > > > > > > To: Brian Rosen; Matt Lepinski; ECRIT; James M. Polk > > > > > > > Subject: RE: [Ecrit] RE: Comments on: > > > draft-ietf-ecrit-phonebcp-01 > > > > > > > > > > > > > > I think that there is one other variant on two. > > > > > > > > > > > > > > The End-point makes the call the service URN and includes a > > > provided > > > > > > > locationURI. Outbound-proxy does nothing special. > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > > > Sent: Friday, 1 June 2007 10:36 PM > > > > > > > > To: 'Matt Lepinski'; 'ECRIT'; 'James M. Polk' > > > > > > > > Subject: [Ecrit] RE: Comments on: > draft-ietf-ecrit-phonebcp-01 > > > > > > > > > > > > > > > > Thanks for your comments. > > > > > > > > > > > > > > > > The BCP really shouldn't be SIP specific. We need to > broaden > > > it > > > > > to, > > > > > > > for > > > > > > > > example, XMPP. We can have SIP specific information, but > it > > > > > should be > > > > > > > > discussed as just that. > > > > > > > > > > > > > > > > There is a consensus, I believe, on how to mark emergency > > > calls, > > > > > > > > represented > > > > > > > > by the thread, but chairs have to call consensus, not me. > I > > > think > > > > > > > there > > > > > > > > are > > > > > > > > three cases: > > > > > > > > 1. The endpoint recognizes it's an emergency call, does > the > > > LoST > > > > > > > routing, > > > > > > > > and passes the call to its outbound proxy server. In this > > > case > > > > > the > > > > > > > > Request > > > > > > > > URI will be the PSAP URI from LoST, and adds a Route > header > > > with > > > > > the > > > > > > > > service > > > > > > > > URN. > > > > > > > > 2. The endpoint recognizes it's an emergency call, but > doesn't > > > > > LoST > > > > > > > route > > > > > > > > it. In this case the Request URI would be the service > URN. > > > The > > > > > > > outbound > > > > > > > > proxy server would do the LoST routing, put the Route > header > > > with > > > > > the > > > > > > > > service URN in and change the Request URI to the PSAP URI. > > > > > > > > 3. The endpoint doesn't even recognize it's an emergency > call. > > > In > > > > > > > this > > > > > > > > case, the endpoint would put the dialstring in the Request > > > URI. > > > > > The > > > > > > > > outbound proxy would behave as in 2 above. > > > > > > > > > > > > > > > > When the PSAP gets the call, it will always have its URI > in > > > the > > > > > > > Request > > > > > > > > URI, > > > > > > > > and there will be a service URN in a Route header. > > > > > > > > > > > > > > > > Probably, phonebcp should say that more clearly. > > > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Matt Lepinski [mailto:mlepinski@bbn.com] > > > > > > > > > Sent: Friday, June 01, 2007 12:49 AM > > > > > > > > > To: ECRIT; James M. Polk; br@brianrosen.net > > > > > > > > > Subject: Comments on: draft-ietf-ecrit-phonebcp-01 > > > > > > > > > > > > > > > > > > Brian and James: > > > > > > > > > > > > > > > > > > First, two very high level questions. > > > > > > > > > > > > > > > > > > A) [Is this document supposed to be SIP-Centric?] It is > > > unclear > > > > > to > > > > > > > me > > > > > > > > > whether the document is intended as a BCP for SIP User > > > Agents > > > > > and > > > > > > > SIP > > > > > > > > > proxies, or whether it is more generally a BCP for end > > > points > > > > > and > > > > > > > > > signaling-path devices which may or may not use SIP. For > > > > > instance, > > > > > > > > > Section 6.4 is written as though SIP signaling were a > > > special > > > > > case, > > > > > > > and > > > > > > > > > yet paragraph four of Section 5 indicates that all > emergency > > > > > calls > > > > > > > on > > > > > > > > > the wire should contain a Route header (which is a > > > SIP-specific > > > > > > > > > signaling component). Personally, I don't care whether > or > > > not > > > > > the > > > > > > > > > document is SIP centric, or whether SIP is a special > case, > > > as > > > > > long > > > > > > > as > > > > > > > > > the document is consistent. > > > > > > > > > > > > > > > > > > B) [Is there consensus on how to mark emergency calls?] > The > > > > > current > > > > > > > > > version of phonebcp indicates that (in the normal case > when > > > > > > > end-points > > > > > > > > > perform the LoST mapping) emergency calls are marked by > > > putting > > > > > the > > > > > > > URN > > > > > > > > > in a Route header (with a "loose" parameter that I'm not > > > > > familiar > > > > > > > with > > > > > > > > > ... can someone provide me with a reference) and that > the > > > URN is > > > > > > > placed > > > > > > > > > in the Request-URI when the end-point is unable to > perform > > > the > > > > > LoST > > > > > > > > > mapping). Personally, I don't understand the current > > > mechanism > > > > > > > because > > > > > > > > > I'm not sure what an "ordinary" (RFC3261-compliant) > proxy > > > does > > > > > when > > > > > > > it > > > > > > > > > sees a service URN in the top Route header. However, > given > > > the > > > > > long > > > > > > > > > discussion that occured on call marking in January (See: > > > > > > > > > > > > > > > http://www1.ietf.org/mail-archive/web/ecrit/current/msg02963.html), > > > > > > > > > perhaps the more important question is "Has consensus > been > > > > > reached > > > > > > > that > > > > > > > > > (something like) the current mechanism is an appropriate > way > > > to > > > > > mark > > > > > > > > > messages?" > > > > > > > > > > > > > > > > > > --------------------------------- > > > > > > > > > More detailed comments: > > > > > > > > > > > > > > > > > > Section 2: (paragraph 3 - number 2) > > > > > > > > > Is it clear what the "visited location's emergency > number" > > > means > > > > > in > > > > > > > this > > > > > > > > > context? > > > > > > > > > Consider changing to "the local emergency number for its > > > current > > > > > > > > > location" or providing a forward reference to the > discussion > > > of > > > > > > > > > dial-strings in Section 5. > > > > > > > > > > > > > > > > > > Section 2: (paragraph 4) > > > > > > > > > I agree with Barbara that if this is intended to an > overview > > > of > > > > > call > > > > > > > > > setup for the special case of an Ethernet connected > phone > > > then > > > > > the > > > > > > > > > bullets should match up more clearly with the numbered > items > > > in > > > > > the > > > > > > > > > previous paragraph. > > > > > > > > > > > > > > > > > > Section 2: (last paragraph) > > > > > > > > > It is unclear whether the antecedent of "it" in the last > > > > > paragraph > > > > > > > is > > > > > > > > > [RFC4103] or [RFC4504]. > > > > > > > > > > > > > > > > > > Section 3: > > > > > > > > > Consider changing "should support" to "SHOULD support" > > > > > > > > > > > > > > > > > > Section 3: (paragraph 2) > > > > > > > > > It seems that the point of this paragraph is to say that > a > > > > > certain > > > > > > > class > > > > > > > > > of devices that communicates over IP networks should > support > > > > > > > emergency > > > > > > > > > calls. However, I find the phrase "using current > (evolving) > > > > > > > standards" > > > > > > > > > to be unclear and in particular I'm not sure what the > phrase > > > > > > > modifies. > > > > > > > > > (E.g. Do you mean "Devices that create media sessions > using > > > > > current > > > > > > > > > (evolving) standards and exchange audio ...") > > > > > > > > > > > > > > > > > > Section 4: (first paragraph) > > > > > > > > > Consider replacing "the norm" with "required" (or a > similar > > > > > word). I > > > > > > > > > think the point is not that automatic location is > > > common/normal > > > > > but > > > > > > > that > > > > > > > > > it is necessary since most users are unable to provide > > > accurate > > > > > > > > location. > > > > > > > > > > > > > > > > > > Section 4.1: (first paragraph) > > > > > > > > > I think "cellular" (or "traditional wireless") is more > > > precise > > > > > than > > > > > > > > > "mobile". > > > > > > > > > > > > > > > > > > Section 4.2: (first paragraph ... also, the last > paragraph) > > > > > > > > > Consider changing the phrase "the desired result" to > > > something > > > > > like > > > > > > > "an > > > > > > > > > equivalent result", or perhaps something even more > explicit. > > > > > > > > > > > > > > > > > > Section 4.2: (first paragraph) > > > > > > > > > Consider addition a phrase to the last sentence > indicating > > > why > > > > > it is > > > > > > > > > recommended that the network support a standardized LCP. > > > (This > > > > > may > > > > > > > not > > > > > > > > > be obvious to the reader). Also, consider changing > > > "recommended" > > > > > to > > > > > > > > > "RECOMMENDED". > > > > > > > > > > > > > > > > > > Section 4.2: (paragraph 2) > > > > > > > > > Given that the paragraph covers what both devices and > access > > > > > > > networks > > > > > > > > > MUST support, consider changing "For all other devices" > to > > > "In > > > > > all > > > > > > > other > > > > > > > > > scenarios". > > > > > > > > > > > > > > > > > > Section 4.3: (paragraph 3) > > > > > > > > > The term "geo-location" is not used in RFC 3825 to > describe > > > a > > > > > > > > > lat/lon/alt - style location. (Instead it uses terms > like a > > > > > > > > > "coordinate-based geolocation"). Also, given that the > > > > > "geolocation" > > > > > > > > > header allows for civic locations, I think using > > > geo-location > > > > > here > > > > > > > is > > > > > > > > > potentially confusing. > > > > > > > > > Note: This comment also applies to the use of "geo > reported" > > > in > > > > > the > > > > > > > > > third paragraph of Section 6.3 > > > > > > > > > > > > > > > > > > Section 4.4: (last paragraph) > > > > > > > > > Consider re-writing the second-to-the-last sentence as: > > > "Certain > > > > > > > > > commonly-used techniques for measuring location create a > > > > > conflict > > > > > > > > > between the time it takes to generate a precise location > and > > > the > > > > > > > desire > > > > > > > > > to route the call quickly." (Also, in the following > sentence > > > I > > > > > think > > > > > > > > > "precise" is a better word than "accurate") > > > > > > > > > > > > > > > > > > Section 5: (paragraphs 5 and 6) > > > > > > > > > Paragraph 5 says that devices MUST mark calls using a > > > > > service:sos > > > > > > > URN. > > > > > > > > > However, paragraph 6 says that mapping from dialstring > to > > > URN > > > > > SHOULD > > > > > > > be > > > > > > > > > done by the endpoint. Either both paragraphs should use > > > "MUST" > > > > > or > > > > > > > else > > > > > > > > > they should both use "SHOULD". > > > > > > > > > > > > > > > > > > Section 5: (paragraph 8) > > > > > > > > > I don't understand what it means to be "roaming" or > > > "nomadic" in > > > > > a > > > > > > > > > system where there is no "visited network" > > > > > > > > > > > > > > > > > > Section 5: (last paragraph) > > > > > > > > > The last sentence of this paragraph seems to be > redundent. > > > > > Consider > > > > > > > > > deleting it. > > > > > > > > > > > > > > > > > > Section 6.1: > > > > > > > > > I agree with Barbara that the use of IPSec should not be > > > > > prohibited > > > > > > > by > > > > > > > > > this BCP. > > > > > > > > > > > > > > > > > > Section 6.1: (number 6) > > > > > > > > > These instructions are for the User Agent, > > > P-Asserted-Identity > > > > > > > headers > > > > > > > > > and Identity headers should not be inserted by the UA > > > > > > > > > > > > > > > > > > Section 6.1: (number 10) > > > > > > > > > This item is unclear to me. Is the author's intention > that > > > this > > > > > item > > > > > > > > > handles the case where a UA does not know its own > location? > > > If > > > > > so, I > > > > > > > > > guess that updating this item should be deferred until > > > consensus > > > > > is > > > > > > > > > reached on location-hiding. > > > > > > > > > > > > > > > > > > Section 6.1: > > > > > > > > > Consider Re-ordering the items as: > > > > > > > > > 11, 10, 12, 14, 15, 13 > > > > > > > > > Also, consider deleting 12, I believe it is redundent > given > > > 9, > > > > > 10 > > > > > > > and > > > > > > > > 11. > > > > > > > > > > > > > > > > > > Section 6.2: (number 1) > > > > > > > > > Consider adding an example after "... URN appropriate > for > > > the > > > > > > > emergency > > > > > > > > > dialstring." That is, consider adding (e.g., ...) > > > > > > > > > > > > > > > > > > Section 6.2: (number 3) > > > > > > > > > I'm afraid that I don't understand the meaning of this > > > sentence. > > > > > > > > > > > > > > > > > > Section 6.3: (paragraph 3) > > > > > > > > > The sentence that begins "This can be an enclosing ..." > is > > > > > unclear > > > > > > > to > > > > > > > > > me. Are you suggesting that when a PSAP coverage region > is > > > > > complex, > > > > > > > that > > > > > > > > > a LoST server SHOULD return a simple polygon that (a) > > > contains > > > > > the > > > > > > > > > location of the device; and (b) is entirely contained > within > > > the > > > > > > > PSAP > > > > > > > > > coverage region? > > > > > > > > > > > > > > > > > > Section 6.5: (number 3) > > > > > > > > > This seems to imply that proxies should expect to > SUBSCRIBE > > > to > > > > > > > Presence. > > > > > > > > > Do you mean that proxies should expect the PSAP to > SUBSCRIBE > > > to > > > > > > > > Presence? > > > > > > > > > > > > > > > > > > Section 6.5: (number 4) > > > > > > > > > I'm not very familiar with Session Timers, can you > provide a > > > > > > > reference. > > > > > > > > > > > > > > > > > > Section 6.6: > > > > > > > > > I'm afraid I don't understand the parenthetical remark > after > > > the > > > > > > > "Call > > > > > > > > > Forward" bullet. (Consider removing the remark or > re-wording > > > it > > > > > if > > > > > > > it is > > > > > > > > > important). > > > > > > > > > > > > > > > > > > Section 7: > > > > > > > > > Given the text in Section 4.4 it seems to me that the > first > > > > > > > paragraph of > > > > > > > > > Section 7 is redundent and should be deleted. > > > > > > > > > > > > > > > > > > Section 10.2: > > > > > > > > > Given the difficulty of implementing location signing in > a > > > > > useful > > > > > > > > > manner, I think that that either paragraph 2 should > either > > > be > > > > > > > removed or > > > > > > > > > else it should reference some other document that > explains > > > > > location > > > > > > > > > signing in more detail. (That is, one paragraph does not > do > > > > > location > > > > > > > > > signing justice and it seems irresponsible to strongly > > > recommend > > > > > > > > > location signing without providing additionaly guidence > to > > > the > > > > > > > > > implementor). > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > > > > Minor Nits: (That don't change the meaning of the text) > > > > > > > > > > > > > > > > > > Section 2: (last paragraph) > > > > > > > > > Put a space between [RFC4103] and "media" > > > > > > > > > > > > > > > > > > Section 3: (paragraph 1) > > > > > > > > > Add commas to second sentence "Future PSAPs will, > however, > > > > > support > > > > > > > ..." > > > > > > > > > and remove the extra period at the end of the sentence > > > > > > > > > > > > > > > > > > Section 4.1: (paragraph 2) > > > > > > > > > Change "... where it is the access network that knows > the > > > > > location > > > > > > > ..." > > > > > > > > > to "... when only the access network knows the location > ..." > > > > > > > > > > > > > > > > > > Section 4.4: (paragraph 1) > > > > > > > > > Change "... process engaged from establishing a VPN ... > " to > > > > > "... > > > > > > > > > process engaged by establishing a VPN ..." > > > > > > > > > > > > > > > > > > Section 4.4: (paragraph 2) > > > > > > > > > Change "... related to the mobility of the device and > ..." > > > to > > > > > "... > > > > > > > > > related to the degree of device mobility and ..." > > > > > > > > > > > > > > > > > > Section 4.4: (paragraph 2) > > > > > > > > > Combine the final 2 sentances as follows: > > > > > > > > > "When a device is aware that it has moved, for instance > when > > > it > > > > > > > changes > > > > > > > > > access points, the device SHOULD refresh its location." > > > > > > > > > > > > > > > > > > Section 4.4: (last paragraph) > > > > > > > > > Change "... getting more recent location ..." to "... > > > getting > > > > > > > updated > > > > > > > > > location ..." or "... obtaining a fresh location" > > > > > > > > > > > > > > > > > > Section 5: (first paragraph) > > > > > > > > > Consider re-writing as: > > > > > > > > > "A device (or a downstream signaling element) identifies > an > > > > > > > emergency > > > > > > > > > call by an "address", which in most cases is a > dialstring, > > > > > although > > > > > > > > > other user interfaces may be used." > > > > > > > > > > > > > > > > > > Section 5: (paragraph 2) > > > > > > > > > First sentence has too many words modifying the word > > > "element". > > > > > > > > Consider: > > > > > > > > > "Note: It is undesirable for a user-interface to enable > a > > > user > > > > > to > > > > > > > place > > > > > > > > > an emergency call by pressing a single button." > > > > > > > > > > > > > > > > > > Section 5: (paragraph 3) > > > > > > > > > Consider changing the first sentence: > > > > > > > > > "... in other countries there are several 3 digit > numbers > > > used > > > > > for > > > > > > > > > different types of emergency calls." > > > > > > > > > > > > > > > > > > Section 5: (paragraph 6) > > > > > > > > > Change "... some entity needs to ..." to "... some > entity on > > > the > > > > > > > > > signaling path must ..." > > > > > > > > > > > > > > > > > > Section 5: (paragraph 9) > > > > > > > > > Change "... from North America, the home ..." to "... > from > > > North > > > > > > > > > America, then while in North America the home ..." > > > > > > > > > > > > > > > > > > Section 5: (last paragraph) > > > > > > > > > Add a close parenthesis ")" after "dialstrings." > > > > > > > > > > > > > > > > > > Section 6: > > > > > > > > > Change "... is expected be supported ..." to "... is > > > expected to > > > > > be > > > > > > > > > supported ..." > > > > > > > > > > > > > > > > > > Section 6.1: > > > > > > > > > Change "signaling Method" to "signaling method" (lower > > > case). > > > > > > > > > > > > > > > > > > Section 6.1: (number 1) > > > > > > > > > Change "To: SHOULD" to "Request-URI: SHOULD" > > > > > > > > > > > > > > > > > > Section 6.1: (number 2) > > > > > > > > > Add a space between [I-D.rosen-iptel-dialstring] and > "with" > > > > > > > > > Also change "sips MUST be ..." to "a sips URI MUST be > ..." > > > > > > > > > > > > > > > > > > Section 6.2: (number 1) > > > > > > > > > Change "If it finds it it MUST:" to "If it finds the > > > dialstring > > > > > it > > > > > > > > MUST:" > > > > > > > > > Also, change "... for the endpoint" to "... of the end > > > device." > > > > > > > (note > > > > > > > > > that period was missing) > > > > > > > > > > > > > > > > > > Section 6.3: (paragraph 3) > > > > > > > > > Non-parallel sentence structure. Consider re-writing the > > > last > > > > > > > sentence > > > > > > > > as: > > > > > > > > > "In the case of civic location, the LoST server SHOULD > > > report > > > > > that > > > > > > > the > > > > > > > > > same mapping is good within a community name or even a > > > street, > > > > > as > > > > > > > this > > > > > > > > > is helpful for WiFi connected devices that roam and > obtain > > > civic > > > > > > > > > location from the AP to which they connect." > > > > > > > > > (Or perhaps "Despite the fact that civic location is > > > uncommon > > > > > for > > > > > > > mobile > > > > > > > > > devices, the LoST server SHOULD ...") > > > > > > > > > > > > > > > > > > Section 6.3: (paragraph 4) > > > > > > > > > Change "... URI of the service URN ..." to "... URI of a > > > service > > > > > URN > > > > > > > > ..." > > > > > > > > > > > > > > > > > > Section 6.3: (last paragraph) > > > > > > > > > Re-write the last sentence as: "The proxy then replaces > the > > > > > > > Request-URI > > > > > > > > > with the resulting PSAP URI." > > > > > > > > > Or perhaps "The resulting PSAP URI then replaces the > > > > > Request-URI" > > > > > > > > > > > > > > > > > > Section 6.4: (first paragraph) > > > > > > > > > Consider adding the phrase "Once the mapping to a PSAP > URI > > > has > > > > > been > > > > > > > > > performed," to the begining of the paragraph (to improve > the > > > > > flow of > > > > > > > the > > > > > > > > > document). > > > > > > > > > > > > > > > > > > Section 6.6: > > > > > > > > > Change "The emergency dialstrings ..." to "Emergency > > > dialstrings > > > > > > > ..." > > > > > > > > > > > > > > > > > > Section 7: (paragraph 3) > > > > > > > > > Change "For calls send with ..." to "For calls sent with > > > ..." > > > > > > > > > > > > > > > > > > Section 8: (paragraph 1) > > > > > > > > > Change "... media streams on RTP ... " to "... media > stream > > > > > using > > > > > > > RTP > > > > > > > > ..." > > > > > > > > > or perhaps "... media streams via RTP ..." > > > > > > > > > Also, consider re-writing the 4th sentence as: > > > > > > > > > "Future IP-enabled PSAPs should accept a wider array of > > > > > potential > > > > > > > media > > > > > > > > > types." > > > > > > > > > > > > > > > > > > Section 8: (paragraph 2) > > > > > > > > > Add a period between "the offer" and "Silence > suppression". > > > > > > > > > > > > > > > > > > Section 10: > > > > > > > > > Change "... it specifies use of several ..." to "... it > > > > > specifies > > > > > > > the > > > > > > > > > use of several ..." > > > > > > > > > > > > > > > > > > Section 10.1: (paragraph 2) > > > > > > > > > Change "... DHCP is the LCP [RFC3118] ..." to "... DHCP > is > > > the > > > > > LCP, > > > > > > > > > [RFC3118] ..." (add a comma) > > > > > > > > > Also, change "... spoofing would be ..." to "... > spoofing is > > > > > ..." > > > > > > > > > > > > > > > > > > Section 10.1: (last paragraph) > > > > > > > > > Add an 's' to change "Client SHOULD" to "Clients SHOULD" > > > > > > > > > > > > > > > > > > Section 10.2: (last paragraph) > > > > > > > > > Change "... signaling would help significantly." to "... > > > > > signaling > > > > > > > helps > > > > > > > > > significantly." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Ecrit mailing list > > > > > > > > Ecrit@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > -- > > > > > > > ---------------------- > > > > > > > This message is for the designated recipient only and may > > > > > > > contain privileged, proprietary, or otherwise private > > > information. > > > > > > > If you have received it in error, please notify the sender > > > > > > > immediately and delete the original. Any unauthorized use > of > > > > > > > this email is prohibited. > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > -- > > > > > > > ---------------------- > > > > > > > [mf2] > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > ---------------------- > > > > > This message is for the designated recipient only and may > > > > > contain privileged, proprietary, or otherwise private > information. > > > > > If you have received it in error, please notify the sender > > > > > immediately and delete the original. Any unauthorized use of > > > > > this email is prohibited. > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > ---------------------- > > > > > [mf2] > > > > > > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > [mf2] > > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 01 18:49:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFwV-00086y-6w; Fri, 01 Jun 2007 18:49:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFwU-00086t-P3 for ecrit@ietf.org; Fri, 01 Jun 2007 18:49:58 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuFwT-0006KS-P1 for ecrit@ietf.org; Fri, 01 Jun 2007 18:49:58 -0400 X-SEF-Processed: 5_0_0_910__2007_06_01_17_57_24 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 01 Jun 2007 17:57:23 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Jun 2007 17:49:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 Date: Fri, 1 Jun 2007 17:49:53 -0500 Message-ID: In-Reply-To: <0cba01c7a49e$dff4d120$6601a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 Thread-Index: AcekCFEPcS0iQckvRVWGxa+1mAstOgAQAffgABMPLZAAAWw9QAAAS3KAAAAtGGAAAA9IoAAAR+PQAAAVaoAAADC5YAAAHo0g References: <465FA53B.80802@bbn.com> <0add01c7a449$6846b260$6601a8c0@cis.neustar.com> <0cb001c7a49a$b2844440$6601a8c0@cis.neustar.com> <0cb301c7a49c$31472cb0$6601a8c0@cis.neustar.com> <0cb601c7a49d$c25ec540$6601a8c0@cis.neustar.com> <0cba01c7a49e$dff4d120$6601a8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Matt Lepinski" , "ECRIT" , "James M. Polk" X-OriginalArrivalTime: 01 Jun 2007 22:49:57.0291 (UTC) FILETIME=[2D777FB0:01C7A49F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f3b9db08b8c0fe2301a77f547096e31 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think that it would do very well to again re-canvas the group before=0D=0A= we make a decision there.=0D=0ASo that it is very clear what people want.=0D= =0A=0D=0A> -----Original Message-----=0D=0A> From: Brian Rosen [mailto:br@b= rianrosen.net]=0D=0A> Sent: Saturday, 2 June 2007 8:48 AM=0D=0A> To: Winter= bottom, James; 'Matt Lepinski'; 'ECRIT'; 'James M. Polk'=0D=0A> Subject: RE= : [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01=0D=0A>=20=0D=0A> I'= ll let the chairs decide, and -phonebcp will follow.=0D=0A>=20=0D=0A> You c= an choose any civic location in the service area to return as a=0D=0A> "coa= rse" location. For example, pick a street that lies within the=0D=0A> serv= ice=0D=0A> boundary, and return it with no house number. Of course, in the=0D= =0Amajority=0D=0A> of=0D=0A> cases, the community name will do.=0D=0A>=20=0D= =0A> Brian=0D=0A>=20=0D=0A> > -----Original Message-----=0D=0A> > From: Win= terbottom, James [mailto:James.Winterbottom@andrew.com]=0D=0A> > Sent: Frid= ay, June 01, 2007 6:42 PM=0D=0A> > To: Brian Rosen; Matt Lepinski; ECRIT; J= ames M. Polk=0D=0A> > Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecri= t-phonebcp-01=0D=0A> >=0D=0A> > I don't think so.=0D=0A> > The carriers hav= e largely said that they prefer solution 3, but=0D=0ACOULD=0D=0A> > work wi= th solution 1. That to me is not consensus on solution 1 but=0D=0Amore=0D=0A= > > consensus on solution 3. I am yet to see anyone suggest how solution=0D= =0A1=0D=0A> > could possibly be done with civic locations. Solution 3 will = work=0D=0Awith=0D=0A> > both civic and geo without any problems.=0D=0A> >=0D= =0A> > So I think this is where the disagreement comes from.=0D=0A> >=0D=0A= > >=0D=0A> >=0D=0A> > > -----Original Message-----=0D=0A> > > From: Brian R= osen [mailto:br@brianrosen.net]=0D=0A> > > Sent: Saturday, 2 June 2007 8:40= AM=0D=0A> > > To: Winterbottom, James; 'Matt Lepinski'; 'ECRIT'; 'James M.= Polk'=0D=0A> > > Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-ph= onebcp-01=0D=0A> > >=0D=0A> > > So far, the location hiding thing is you ge= t coarse location and=0D=0Ayou=0D=0A> > LoST=0D=0A> > > route with it. The= re are people unhappy with that, who want the=0D=0ALCP=0D=0A> > to=0D=0A> >= > return LoST data, or LoST to do dereference. My read of rough=0D=0A> > = consensus=0D=0A> > > was=0D=0A> > > coarse location, but chairs have to cal= l that one.=0D=0A> > >=0D=0A> > > Brian=0D=0A> > >=0D=0A> > > > -----Origin= al Message-----=0D=0A> > > > From: Winterbottom, James [mailto:James.Winter= bottom@andrew.com]=0D=0A> > > > Sent: Friday, June 01, 2007 6:30 PM=0D=0A> = > > > To: Brian Rosen; Matt Lepinski; ECRIT; James M. Polk=0D=0A> > > > Sub= ject: RE: [Ecrit] RE: Comments on:=0D=0Adraft-ietf-ecrit-phonebcp-01=0D=0A>= > > >=0D=0A> > > > Except that the end-point doesn't do the LoST thing=0D=0A= > > > >=0D=0A> > > >=0D=0A> > > > > -----Original Message-----=0D=0A> > > >= > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > > > > Sent: Saturd= ay, 2 June 2007 8:29 AM=0D=0A> > > > > To: Winterbottom, James; 'Matt Lepin= ski'; 'ECRIT'; 'James M.=0D=0APolk'=0D=0A> > > > > Subject: RE: [Ecrit] RE:= Comments on:=0D=0Adraft-ietf-ecrit-phonebcp-01=0D=0A> > > > >=0D=0A> > > >= > But that is case 1=0D=0A> > > > >=0D=0A> > > > > > -----Original Message= -----=0D=0A> > > > > > From: Winterbottom, James=0D=0A[mailto:James.Winterb= ottom@andrew.com]=0D=0A> > > > > > Sent: Friday, June 01, 2007 6:24 PM=0D=0A= > > > > > > To: Brian Rosen; Matt Lepinski; ECRIT; James M. Polk=0D=0A> > >= > > > Subject: RE: [Ecrit] RE: Comments on:=0D=0A> > draft-ietf-ecrit-phon= ebcp-01=0D=0A> > > > > >=0D=0A> > > > > > I was assuming that the end-point= is given a location URI,=0D=0Alocal=0D=0A> > > > > > dialsring, and servic= e URNs. Say in the location hiding=0D=0Acase.=0D=0A> > > > > >=0D=0A> > > >= > >=0D=0A> > > > > > > -----Original Message-----=0D=0A> > > > > > > From:= Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > > > > > > Sent: Saturday, = 2 June 2007 8:18 AM=0D=0A> > > > > > > To: Winterbottom, James; 'Matt Lepin= ski'; 'ECRIT'; 'James=0D=0AM.=0D=0A> > Polk'=0D=0A> > > > > > > Subject: RE= : [Ecrit] RE: Comments on:=0D=0A> > draft-ietf-ecrit-phonebcp-01=0D=0A> > >= > > > >=0D=0A> > > > > > > If by that you mean the endpoint gets location,= recognizes=0D=0Aan=0D=0A> > > > > > emergency=0D=0A> > > > > > > call, but= does not route, then the proxy server has to=0D=0Aroute.=0D=0A> > > > That=0D= =0A> > > > > > case=0D=0A> > > > > > > is=0D=0A> > > > > > > complex becaus= e without the LoST query, the endpoint=0D=0Adoesn't=0D=0A> > have=0D=0A> > = > > the=0D=0A> > > > > > > local=0D=0A> > > > > > > dialstring(s).=0D=0A> >= > > > > >=0D=0A> > > > > > > If that was not what you mean, then who route= s=3F=0D=0A> > > > > > >=0D=0A> > > > > > > Brian=0D=0A> > > > > > >=0D=0A> = > > > > > > > -----Original Message-----=0D=0A> > > > > > > > From: Winterb= ottom, James=0D=0A> > [mailto:James.Winterbottom@andrew.com]=0D=0A> > > > >= > > > Sent: Friday, June 01, 2007 5:35 PM=0D=0A> > > > > > > > To: Brian R= osen; Matt Lepinski; ECRIT; James M. Polk=0D=0A> > > > > > > > Subject: RE:= [Ecrit] RE: Comments on:=0D=0A> > > > draft-ietf-ecrit-phonebcp-01=0D=0A> = > > > > > > >=0D=0A> > > > > > > > I think that there is one other variant = on two.=0D=0A> > > > > > > >=0D=0A> > > > > > > > The End-point makes the c= all the service URN and=0D=0Aincludes a=0D=0A> > > > provided=0D=0A> > > > = > > > > locationURI. Outbound-proxy does nothing special.=0D=0A> > > > > > = > >=0D=0A> > > > > > > > > -----Original Message-----=0D=0A> > > > > > > > = > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > > > > > > > > Sent:= Friday, 1 June 2007 10:36 PM=0D=0A> > > > > > > > > To: 'Matt Lepinski'; '= ECRIT'; 'James M. Polk'=0D=0A> > > > > > > > > Subject: [Ecrit] RE: Comment= s on:=0D=0A> > draft-ietf-ecrit-phonebcp-01=0D=0A> > > > > > > > >=0D=0A> >= > > > > > > > Thanks for your comments.=0D=0A> > > > > > > > >=0D=0A> > > = > > > > > > The BCP really shouldn't be SIP specific. We need to=0D=0A> > = broaden=0D=0A> > > > it=0D=0A> > > > > > to,=0D=0A> > > > > > > > for=0D=0A= > > > > > > > > > example, XMPP. We can have SIP specific information,=0D=0A= but=0D=0A> > it=0D=0A> > > > > > should be=0D=0A> > > > > > > > > discussed= as just that.=0D=0A> > > > > > > > >=0D=0A> > > > > > > > > There is a con= sensus, I believe, on how to mark=0D=0Aemergency=0D=0A> > > > calls,=0D=0A>= > > > > > > > > represented=0D=0A> > > > > > > > > by the thread, but chai= rs have to call consensus, not=0D=0Ame.=0D=0A> > I=0D=0A> > > > think=0D=0A= > > > > > > > > there=0D=0A> > > > > > > > > are=0D=0A> > > > > > > > > thr= ee cases:=0D=0A> > > > > > > > > 1. The endpoint recognizes it's an emergen= cy call,=0D=0Adoes=0D=0A> > the=0D=0A> > > > LoST=0D=0A> > > > > > > > rout= ing,=0D=0A> > > > > > > > > and passes the call to its outbound proxy serve= r. In=0D=0Athis=0D=0A> > > > case=0D=0A> > > > > > the=0D=0A> > > > > > > = > > Request=0D=0A> > > > > > > > > URI will be the PSAP URI from LoST, and = adds a Route=0D=0A> > header=0D=0A> > > > with=0D=0A> > > > > > the=0D=0A> = > > > > > > > > service=0D=0A> > > > > > > > > URN.=0D=0A> > > > > > > > > = 2. The endpoint recognizes it's an emergency call, but=0D=0A> > doesn't=0D=0A= > > > > > > LoST=0D=0A> > > > > > > > route=0D=0A> > > > > > > > > it. In = this case the Request URI would be the service=0D=0A> > URN.=0D=0A> > > > T= he=0D=0A> > > > > > > > outbound=0D=0A> > > > > > > > > proxy server would = do the LoST routing, put the Route=0D=0A> > header=0D=0A> > > > with=0D=0A>= > > > > > the=0D=0A> > > > > > > > > service URN in and change the Request= URI to the PSAP=0D=0AURI.=0D=0A> > > > > > > > > 3. The endpoint doesn't e= ven recognize it's an=0D=0Aemergency=0D=0A> > call.=0D=0A> > > > In=0D=0A> = > > > > > > > this=0D=0A> > > > > > > > > case, the endpoint would put the = dialstring in the=0D=0ARequest=0D=0A> > > > URI.=0D=0A> > > > > > The=0D=0A= > > > > > > > > > outbound proxy would behave as in 2 above.=0D=0A> > > > >= > > > >=0D=0A> > > > > > > > > When the PSAP gets the call, it will always= have its=0D=0AURI=0D=0A> > in=0D=0A> > > > the=0D=0A> > > > > > > > Reques= t=0D=0A> > > > > > > > > URI,=0D=0A> > > > > > > > > and there will be a se= rvice URN in a Route header.=0D=0A> > > > > > > > >=0D=0A> > > > > > > > > = Probably, phonebcp should say that more clearly.=0D=0A> > > > > > > > >=0D=0A= > > > > > > > > > Brian=0D=0A> > > > > > > > >=0D=0A> > > > > > > > > > ---= --Original Message-----=0D=0A> > > > > > > > > > From: Matt Lepinski [mailt= o:mlepinski@bbn.com]=0D=0A> > > > > > > > > > Sent: Friday, June 01, 2007 1= 2:49 AM=0D=0A> > > > > > > > > > To: ECRIT; James M. Polk; br@brianrosen.ne= t=0D=0A> > > > > > > > > > Subject: Comments on: draft-ietf-ecrit-phonebcp-= 01=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Brian and James:=0D=0A= > > > > > > > > > >=0D=0A> > > > > > > > > > First, two very high level que= stions.=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > A) [Is this docum= ent supposed to be SIP-Centric=3F] It=0D=0Ais=0D=0A> > > > unclear=0D=0A> >= > > > > to=0D=0A> > > > > > > > me=0D=0A> > > > > > > > > > whether the do= cument is intended as a BCP for SIP=0D=0AUser=0D=0A> > > > Agents=0D=0A> > = > > > > and=0D=0A> > > > > > > > SIP=0D=0A> > > > > > > > > > proxies, or w= hether it is more generally a BCP for=0D=0Aend=0D=0A> > > > points=0D=0A> >= > > > > and=0D=0A> > > > > > > > > > signaling-path devices which may or m= ay not use SIP.=0D=0AFor=0D=0A> > > > > > instance,=0D=0A> > > > > > > > > = > Section 6.4 is written as though SIP signaling were=0D=0Aa=0D=0A> > > > s= pecial=0D=0A> > > > > > case,=0D=0A> > > > > > > > and=0D=0A> > > > > > > >= > > yet paragraph four of Section 5 indicates that all=0D=0A> > emergency=0D= =0A> > > > > > calls=0D=0A> > > > > > > > on=0D=0A> > > > > > > > > > the w= ire should contain a Route header (which is a=0D=0A> > > > SIP-specific=0D=0A= > > > > > > > > > > signaling component). Personally, I don't care=0D=0Awhe= ther=0D=0A> > or=0D=0A> > > > not=0D=0A> > > > > > the=0D=0A> > > > > > > >= > > document is SIP centric, or whether SIP is a special=0D=0A> > case,=0D= =0A> > > > as=0D=0A> > > > > > long=0D=0A> > > > > > > > as=0D=0A> > > > > = > > > > > the document is consistent.=0D=0A> > > > > > > > > >=0D=0A> > > >= > > > > > > B) [Is there consensus on how to mark emergency=0D=0Acalls=3F]=0D= =0A> > The=0D=0A> > > > > > current=0D=0A> > > > > > > > > > version of pho= nebcp indicates that (in the normal=0D=0Acase=0D=0A> > when=0D=0A> > > > > = > > > end-points=0D=0A> > > > > > > > > > perform the LoST mapping) emergen= cy calls are marked=0D=0Aby=0D=0A> > > > putting=0D=0A> > > > > > the=0D=0A= > > > > > > > > URN=0D=0A> > > > > > > > > > in a Route header (with a "loo= se" parameter that I'm=0D=0Anot=0D=0A> > > > > > familiar=0D=0A> > > > > > = > > with=0D=0A> > > > > > > > > > ... can someone provide me with a referen= ce) and=0D=0Athat=0D=0A> > the=0D=0A> > > > URN is=0D=0A> > > > > > > > pla= ced=0D=0A> > > > > > > > > > in the Request-URI when the end-point is unabl= e to=0D=0A> > perform=0D=0A> > > > the=0D=0A> > > > > > LoST=0D=0A> > > > >= > > > > > mapping). Personally, I don't understand the current=0D=0A> > > = > mechanism=0D=0A> > > > > > > > because=0D=0A> > > > > > > > > > I'm not s= ure what an "ordinary" (RFC3261-compliant)=0D=0A> > proxy=0D=0A> > > > does=0D= =0A> > > > > > when=0D=0A> > > > > > > > it=0D=0A> > > > > > > > > > sees a= service URN in the top Route header. However,=0D=0A> > given=0D=0A> > > > = the=0D=0A> > > > > > long=0D=0A> > > > > > > > > > discussion that occured = on call marking in January=0D=0A(See:=0D=0A> > > > > > > > > >=0D=0A> > > >= > >=0D=0A> > http://www1.ietf.org/mail-archive/web/ecrit/current/msg02963.= html),=0D=0A> > > > > > > > > > perhaps the more important question is "Has=0D= =0Aconsensus=0D=0A> > been=0D=0A> > > > > > reached=0D=0A> > > > > > > > th= at=0D=0A> > > > > > > > > > (something like) the current mechanism is an=0D= =0Aappropriate=0D=0A> > way=0D=0A> > > > to=0D=0A> > > > > > mark=0D=0A> > = > > > > > > > > messages=3F"=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > = > > ---------------------------------=0D=0A> > > > > > > > > > More detaile= d comments:=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 2: (p= aragraph 3 - number 2)=0D=0A> > > > > > > > > > Is it clear what the "visit= ed location's emergency=0D=0A> > number"=0D=0A> > > > means=0D=0A> > > > > = > in=0D=0A> > > > > > > > this=0D=0A> > > > > > > > > > context=3F=0D=0A> >= > > > > > > > > Consider changing to "the local emergency number for=0D=0A= its=0D=0A> > > > current=0D=0A> > > > > > > > > > location" or providing a = forward reference to the=0D=0A> > discussion=0D=0A> > > > of=0D=0A> > > > >= > > > > > dial-strings in Section 5.=0D=0A> > > > > > > > > >=0D=0A> > > >= > > > > > > Section 2: (paragraph 4)=0D=0A> > > > > > > > > > I agree with= Barbara that if this is intended to an=0D=0A> > overview=0D=0A> > > > of=0D= =0A> > > > > > call=0D=0A> > > > > > > > > > setup for the special case of = an Ethernet connected=0D=0A> > phone=0D=0A> > > > then=0D=0A> > > > > > the=0D= =0A> > > > > > > > > > bullets should match up more clearly with the=0D=0An= umbered=0D=0A> > items=0D=0A> > > > in=0D=0A> > > > > > the=0D=0A> > > > > = > > > > > previous paragraph.=0D=0A> > > > > > > > > >=0D=0A> > > > > > > >= > > Section 2: (last paragraph)=0D=0A> > > > > > > > > > It is unclear whe= ther the antecedent of "it" in the=0D=0Alast=0D=0A> > > > > > paragraph=0D=0A= > > > > > > > > is=0D=0A> > > > > > > > > > [RFC4103] or [RFC4504].=0D=0A> = > > > > > > > > >=0D=0A> > > > > > > > > > Section 3:=0D=0A> > > > > > > > = > > Consider changing "should support" to "SHOULD=0D=0Asupport"=0D=0A> > > = > > > > > > >=0D=0A> > > > > > > > > > Section 3: (paragraph 2)=0D=0A> > > = > > > > > > > It seems that the point of this paragraph is to say=0D=0Athat=0D= =0A> > a=0D=0A> > > > > > certain=0D=0A> > > > > > > > class=0D=0A> > > > >= > > > > > of devices that communicates over IP networks should=0D=0A> > su= pport=0D=0A> > > > > > > > emergency=0D=0A> > > > > > > > > > calls. Howeve= r, I find the phrase "using current=0D=0A> > (evolving)=0D=0A> > > > > > > = > standards"=0D=0A> > > > > > > > > > to be unclear and in particular I'm n= ot sure what=0D=0Athe=0D=0A> > phrase=0D=0A> > > > > > > > modifies.=0D=0A>= > > > > > > > > > (E.g. Do you mean "Devices that create media=0D=0Asessio= ns=0D=0A> > using=0D=0A> > > > > > current=0D=0A> > > > > > > > > > (evolvi= ng) standards and exchange audio ...")=0D=0A> > > > > > > > > >=0D=0A> > > = > > > > > > > Section 4: (first paragraph)=0D=0A> > > > > > > > > > Conside= r replacing "the norm" with "required" (or a=0D=0A> > similar=0D=0A> > > > = > > word). I=0D=0A> > > > > > > > > > think the point is not that automatic= location is=0D=0A> > > > common/normal=0D=0A> > > > > > but=0D=0A> > > > >= > > > that=0D=0A> > > > > > > > > > it is necessary since most users are u= nable to=0D=0Aprovide=0D=0A> > > > accurate=0D=0A> > > > > > > > > location= =2E=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 4.1: (first p= aragraph)=0D=0A> > > > > > > > > > I think "cellular" (or "traditional wire= less") is=0D=0Amore=0D=0A> > > > precise=0D=0A> > > > > > than=0D=0A> > > = > > > > > > > "mobile".=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > S= ection 4.2: (first paragraph ... also, the last=0D=0A> > paragraph)=0D=0A> = > > > > > > > > > Consider changing the phrase "the desired result" to=0D=0A= > > > > something=0D=0A> > > > > > like=0D=0A> > > > > > > > "an=0D=0A> > >= > > > > > > > equivalent result", or perhaps something even more=0D=0A> > = explicit.=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 4.2: (f= irst paragraph)=0D=0A> > > > > > > > > > Consider addition a phrase to the = last sentence=0D=0A> > indicating=0D=0A> > > > why=0D=0A> > > > > > it is=0D= =0A> > > > > > > > > > recommended that the network support a standardized=0D= =0ALCP.=0D=0A> > > > (This=0D=0A> > > > > > may=0D=0A> > > > > > > > not=0D= =0A> > > > > > > > > > be obvious to the reader). Also, consider changing=0D= =0A> > > > "recommended"=0D=0A> > > > > > to=0D=0A> > > > > > > > > > "RECO= MMENDED".=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 4.2: (p= aragraph 2)=0D=0A> > > > > > > > > > Given that the paragraph covers what b= oth devices=0D=0Aand=0D=0A> > access=0D=0A> > > > > > > > networks=0D=0A> >= > > > > > > > > MUST support, consider changing "For all other=0D=0Adevice= s"=0D=0A> > to=0D=0A> > > > "In=0D=0A> > > > > > all=0D=0A> > > > > > > > o= ther=0D=0A> > > > > > > > > > scenarios".=0D=0A> > > > > > > > > >=0D=0A> >= > > > > > > > > Section 4.3: (paragraph 3)=0D=0A> > > > > > > > > > The te= rm "geo-location" is not used in RFC 3825 to=0D=0A> > describe=0D=0A> > > >= a=0D=0A> > > > > > > > > > lat/lon/alt - style location. (Instead it uses = terms=0D=0A> > like a=0D=0A> > > > > > > > > > "coordinate-based geolocatio= n"). Also, given that=0D=0Athe=0D=0A> > > > > > "geolocation"=0D=0A> > > > = > > > > > > header allows for civic locations, I think using=0D=0A> > > > g= eo-location=0D=0A> > > > > > here=0D=0A> > > > > > > > is=0D=0A> > > > > > = > > > > potentially confusing.=0D=0A> > > > > > > > > > Note: This comment = also applies to the use of "geo=0D=0A> > reported"=0D=0A> > > > in=0D=0A> >= > > > > the=0D=0A> > > > > > > > > > third paragraph of Section 6.3=0D=0A>= > > > > > > > > >=0D=0A> > > > > > > > > > Section 4.4: (last paragraph)=0D= =0A> > > > > > > > > > Consider re-writing the second-to-the-last sentence=0D= =0Aas:=0D=0A> > > > "Certain=0D=0A> > > > > > > > > > commonly-used techniq= ues for measuring location=0D=0Acreate a=0D=0A> > > > > > conflict=0D=0A> >= > > > > > > > > between the time it takes to generate a precise=0D=0Alocat= ion=0D=0A> > and=0D=0A> > > > the=0D=0A> > > > > > > > desire=0D=0A> > > > = > > > > > > to route the call quickly." (Also, in the following=0D=0A> > se= ntence=0D=0A> > > > I=0D=0A> > > > > > think=0D=0A> > > > > > > > > > "prec= ise" is a better word than "accurate")=0D=0A> > > > > > > > > >=0D=0A> > > = > > > > > > > Section 5: (paragraphs 5 and 6)=0D=0A> > > > > > > > > > Para= graph 5 says that devices MUST mark calls using=0D=0Aa=0D=0A> > > > > > ser= vice:sos=0D=0A> > > > > > > > URN.=0D=0A> > > > > > > > > > However, paragr= aph 6 says that mapping from=0D=0Adialstring=0D=0A> > to=0D=0A> > > > URN=0D= =0A> > > > > > SHOULD=0D=0A> > > > > > > > be=0D=0A> > > > > > > > > > done= by the endpoint. Either both paragraphs should=0D=0Ause=0D=0A> > > > "MUST= "=0D=0A> > > > > > or=0D=0A> > > > > > > > else=0D=0A> > > > > > > > > > th= ey should both use "SHOULD".=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > = > > Section 5: (paragraph 8)=0D=0A> > > > > > > > > > I don't understand wh= at it means to be "roaming" or=0D=0A> > > > "nomadic" in=0D=0A> > > > > > a=0D= =0A> > > > > > > > > > system where there is no "visited network"=0D=0A> > = > > > > > > > >=0D=0A> > > > > > > > > > Section 5: (last paragraph)=0D=0A>= > > > > > > > > > The last sentence of this paragraph seems to be=0D=0A> >= redundent.=0D=0A> > > > > > Consider=0D=0A> > > > > > > > > > deleting it.=0D= =0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 6.1:=0D=0A> > > > >= > > > > > I agree with Barbara that the use of IPSec should=0D=0Anot be=0D= =0A> > > > > > prohibited=0D=0A> > > > > > > > by=0D=0A> > > > > > > > > > = this BCP.=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 6.1: (n= umber 6)=0D=0A> > > > > > > > > > These instructions are for the User Agent= ,=0D=0A> > > > P-Asserted-Identity=0D=0A> > > > > > > > headers=0D=0A> > > = > > > > > > > and Identity headers should not be inserted by the=0D=0AUA=0D= =0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 6.1: (number 10)=0D= =0A> > > > > > > > > > This item is unclear to me. Is the author's=0D=0Aint= ention=0D=0A> > that=0D=0A> > > > this=0D=0A> > > > > > item=0D=0A> > > > >= > > > > > handles the case where a UA does not know its own=0D=0A> > locat= ion=3F=0D=0A> > > > If=0D=0A> > > > > > so, I=0D=0A> > > > > > > > > > gues= s that updating this item should be deferred=0D=0Auntil=0D=0A> > > > consen= sus=0D=0A> > > > > > is=0D=0A> > > > > > > > > > reached on location-hiding= =2E=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 6.1:=0D=0A> >= > > > > > > > > Consider Re-ordering the items as:=0D=0A> > > > > > > > > = > 11, 10, 12, 14, 15, 13=0D=0A> > > > > > > > > > Also, consider deleting 1= 2, I believe it is=0D=0Aredundent=0D=0A> > given=0D=0A> > > > 9,=0D=0A> > >= > > > 10=0D=0A> > > > > > > > and=0D=0A> > > > > > > > > 11.=0D=0A> > > > = > > > > > >=0D=0A> > > > > > > > > > Section 6.2: (number 1)=0D=0A> > > > >= > > > > > Consider adding an example after "... URN=0D=0Aappropriate=0D=0A= > > for=0D=0A> > > > the=0D=0A> > > > > > > > emergency=0D=0A> > > > > > > = > > > dialstring." That is, consider adding (e.g., ...)=0D=0A> > > > > > > = > > >=0D=0A> > > > > > > > > > Section 6.2: (number 3)=0D=0A> > > > > > > >= > > I'm afraid that I don't understand the meaning of=0D=0Athis=0D=0A> > >= > sentence.=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 6.3:= (paragraph 3)=0D=0A> > > > > > > > > > The sentence that begins "This can = be an enclosing=0D=0A..."=0D=0A> > is=0D=0A> > > > > > unclear=0D=0A> > > >= > > > > to=0D=0A> > > > > > > > > > me. Are you suggesting that when a PSA= P coverage=0D=0Aregion=0D=0A> > is=0D=0A> > > > > > complex,=0D=0A> > > > >= > > > that=0D=0A> > > > > > > > > > a LoST server SHOULD return a simple p= olygon that=0D=0A(a)=0D=0A> > > > contains=0D=0A> > > > > > the=0D=0A> > > = > > > > > > > location of the device; and (b) is entirely=0D=0Acontained=0D= =0A> > within=0D=0A> > > > the=0D=0A> > > > > > > > PSAP=0D=0A> > > > > > >= > > > coverage region=3F=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > >= Section 6.5: (number 3)=0D=0A> > > > > > > > > > This seems to imply that = proxies should expect to=0D=0A> > SUBSCRIBE=0D=0A> > > > to=0D=0A> > > > > = > > > Presence.=0D=0A> > > > > > > > > > Do you mean that proxies should ex= pect the PSAP to=0D=0A> > SUBSCRIBE=0D=0A> > > > to=0D=0A> > > > > > > > > = Presence=3F=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 6.5: = (number 4)=0D=0A> > > > > > > > > > I'm not very familiar with Session Time= rs, can you=0D=0A> > provide a=0D=0A> > > > > > > > reference.=0D=0A> > > >= > > > > > >=0D=0A> > > > > > > > > > Section 6.6:=0D=0A> > > > > > > > > >= I'm afraid I don't understand the parenthetical=0D=0Aremark=0D=0A> > after=0D= =0A> > > > the=0D=0A> > > > > > > > "Call=0D=0A> > > > > > > > > > Forward"= bullet. (Consider removing the remark or=0D=0A> > re-wording=0D=0A> > > > = it=0D=0A> > > > > > if=0D=0A> > > > > > > > it is=0D=0A> > > > > > > > > > = important).=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 7:=0D= =0A> > > > > > > > > > Given the text in Section 4.4 it seems to me that=0D= =0Athe=0D=0A> > first=0D=0A> > > > > > > > paragraph of=0D=0A> > > > > > > = > > > Section 7 is redundent and should be deleted.=0D=0A> > > > > > > > > = >=0D=0A> > > > > > > > > > Section 10.2:=0D=0A> > > > > > > > > > Given the= difficulty of implementing location=0D=0Asigning in=0D=0A> > a=0D=0A> > > = > > > useful=0D=0A> > > > > > > > > > manner, I think that that either para= graph 2 should=0D=0A> > either=0D=0A> > > > be=0D=0A> > > > > > > > removed= or=0D=0A> > > > > > > > > > else it should reference some other document t= hat=0D=0A> > explains=0D=0A> > > > > > location=0D=0A> > > > > > > > > > si= gning in more detail. (That is, one paragraph does=0D=0Anot=0D=0A> > do=0D=0A= > > > > > > location=0D=0A> > > > > > > > > > signing justice and it seems = irresponsible to=0D=0Astrongly=0D=0A> > > > recommend=0D=0A> > > > > > > > = > > location signing without providing additionaly=0D=0Aguidence=0D=0A> > t= o=0D=0A> > > > the=0D=0A> > > > > > > > > > implementor).=0D=0A> > > > > > = > > > >=0D=0A> > > > > > > > > >=0D=0A> > > > > >=0D=0A> > ----------------= ---------------------------------------------------=0D=0A> > > > > > > > > = > Minor Nits: (That don't change the meaning of the=0D=0Atext)=0D=0A> > > >= > > > > > >=0D=0A> > > > > > > > > > Section 2: (last paragraph)=0D=0A> > = > > > > > > > > Put a space between [RFC4103] and "media"=0D=0A> > > > > > = > > > >=0D=0A> > > > > > > > > > Section 3: (paragraph 1)=0D=0A> > > > > > = > > > > Add commas to second sentence "Future PSAPs will,=0D=0A> > however,=0D= =0A> > > > > > support=0D=0A> > > > > > > > ..."=0D=0A> > > > > > > > > > a= nd remove the extra period at the end of the=0D=0Asentence=0D=0A> > > > > >= > > > >=0D=0A> > > > > > > > > > Section 4.1: (paragraph 2)=0D=0A> > > > >= > > > > > Change "... where it is the access network that=0D=0Aknows=0D=0A= > > the=0D=0A> > > > > > location=0D=0A> > > > > > > > ..."=0D=0A> > > > > = > > > > > to "... when only the access network knows the=0D=0Alocation=0D=0A= > > ..."=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 4.4: (pa= ragraph 1)=0D=0A> > > > > > > > > > Change "... process engaged from establ= ishing a VPN=0D=0A...=0D=0A> > " to=0D=0A> > > > > > "...=0D=0A> > > > > > = > > > > process engaged by establishing a VPN ..."=0D=0A> > > > > > > > > >=0D= =0A> > > > > > > > > > Section 4.4: (paragraph 2)=0D=0A> > > > > > > > > > = Change "... related to the mobility of the device=0D=0Aand=0D=0A> > ..."=0D= =0A> > > > to=0D=0A> > > > > > "...=0D=0A> > > > > > > > > > related to the= degree of device mobility and ..."=0D=0A> > > > > > > > > >=0D=0A> > > > >= > > > > > Section 4.4: (paragraph 2)=0D=0A> > > > > > > > > > Combine the = final 2 sentances as follows:=0D=0A> > > > > > > > > > "When a device is aw= are that it has moved, for=0D=0Ainstance=0D=0A> > when=0D=0A> > > > it=0D=0A= > > > > > > > > changes=0D=0A> > > > > > > > > > access points, the device = SHOULD refresh its=0D=0Alocation."=0D=0A> > > > > > > > > >=0D=0A> > > > > = > > > > > Section 4.4: (last paragraph)=0D=0A> > > > > > > > > > Change "..= =2E getting more recent location ..." to=0D=0A"...=0D=0A> > > > getting=0D=0A= > > > > > > > > updated=0D=0A> > > > > > > > > > location ..." or "... obta= ining a fresh location"=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > S= ection 5: (first paragraph)=0D=0A> > > > > > > > > > Consider re-writing as= :=0D=0A> > > > > > > > > > "A device (or a downstream signaling element)=0D= =0Aidentifies=0D=0A> > an=0D=0A> > > > > > > > emergency=0D=0A> > > > > > >= > > > call by an "address", which in most cases is a=0D=0A> > dialstring,=0D= =0A> > > > > > although=0D=0A> > > > > > > > > > other user interfaces may = be used."=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 5: (par= agraph 2)=0D=0A> > > > > > > > > > First sentence has too many words modify= ing the word=0D=0A> > > > "element".=0D=0A> > > > > > > > > Consider:=0D=0A= > > > > > > > > > > "Note: It is undesirable for a user-interface to=0D=0Ae= nable=0D=0A> > a=0D=0A> > > > user=0D=0A> > > > > > to=0D=0A> > > > > > > >= place=0D=0A> > > > > > > > > > an emergency call by pressing a single butt= on."=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 5: (paragrap= h 3)=0D=0A> > > > > > > > > > Consider changing the first sentence:=0D=0A> = > > > > > > > > > "... in other countries there are several 3 digit=0D=0A> = > numbers=0D=0A> > > > used=0D=0A> > > > > > for=0D=0A> > > > > > > > > > d= ifferent types of emergency calls."=0D=0A> > > > > > > > > >=0D=0A> > > > >= > > > > > Section 5: (paragraph 6)=0D=0A> > > > > > > > > > Change "... so= me entity needs to ..." to "... some=0D=0A> > entity on=0D=0A> > > > the=0D= =0A> > > > > > > > > > signaling path must ..."=0D=0A> > > > > > > > > >=0D= =0A> > > > > > > > > > Section 5: (paragraph 9)=0D=0A> > > > > > > > > > Ch= ange "... from North America, the home ..." to=0D=0A"...=0D=0A> > from=0D=0A= > > > > North=0D=0A> > > > > > > > > > America, then while in North America= the home ..."=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 5:= (last paragraph)=0D=0A> > > > > > > > > > Add a close parenthesis ")" afte= r "dialstrings."=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section = 6:=0D=0A> > > > > > > > > > Change "... is expected be supported ..." to ".= =2E. is=0D=0A> > > > expected to=0D=0A> > > > > > be=0D=0A> > > > > > > > >= > supported ..."=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section= 6.1:=0D=0A> > > > > > > > > > Change "signaling Method" to "signaling meth= od"=0D=0A(lower=0D=0A> > > > case).=0D=0A> > > > > > > > > >=0D=0A> > > > >= > > > > > Section 6.1: (number 1)=0D=0A> > > > > > > > > > Change "To: SHO= ULD" to "Request-URI: SHOULD"=0D=0A> > > > > > > > > >=0D=0A> > > > > > > >= > > Section 6.1: (number 2)=0D=0A> > > > > > > > > > Add a space between [= I-D.rosen-iptel-dialstring] and=0D=0A> > "with"=0D=0A> > > > > > > > > > Al= so change "sips MUST be ..." to "a sips URI MUST=0D=0Abe=0D=0A> > ..."=0D=0A= > > > > > > > > > >=0D=0A> > > > > > > > > > Section 6.2: (number 1)=0D=0A>= > > > > > > > > > Change "If it finds it it MUST:" to "If it finds the=0D=0A= > > > > dialstring=0D=0A> > > > > > it=0D=0A> > > > > > > > > MUST:"=0D=0A>= > > > > > > > > > Also, change "... for the endpoint" to "... of the=0D=0A= end=0D=0A> > > > device."=0D=0A> > > > > > > > (note=0D=0A> > > > > > > > >= > that period was missing)=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > >= > Section 6.3: (paragraph 3)=0D=0A> > > > > > > > > > Non-parallel sentenc= e structure. Consider re-writing=0D=0Athe=0D=0A> > > > last=0D=0A> > > > > = > > > sentence=0D=0A> > > > > > > > > as:=0D=0A> > > > > > > > > > "In the = case of civic location, the LoST server=0D=0ASHOULD=0D=0A> > > > report=0D=0A= > > > > > > that=0D=0A> > > > > > > > the=0D=0A> > > > > > > > > > same map= ping is good within a community name or even=0D=0Aa=0D=0A> > > > street,=0D= =0A> > > > > > as=0D=0A> > > > > > > > this=0D=0A> > > > > > > > > > is hel= pful for WiFi connected devices that roam and=0D=0A> > obtain=0D=0A> > > > = civic=0D=0A> > > > > > > > > > location from the AP to which they connect."=0D= =0A> > > > > > > > > > (Or perhaps "Despite the fact that civic location is=0D= =0A> > > > uncommon=0D=0A> > > > > > for=0D=0A> > > > > > > > mobile=0D=0A>= > > > > > > > > > devices, the LoST server SHOULD ...")=0D=0A> > > > > > >= > > >=0D=0A> > > > > > > > > > Section 6.3: (paragraph 4)=0D=0A> > > > > >= > > > > Change "... URI of the service URN ..." to "... URI=0D=0Aof a=0D=0A= > > > > service=0D=0A> > > > > > URN=0D=0A> > > > > > > > > ..."=0D=0A> > >= > > > > > > >=0D=0A> > > > > > > > > > Section 6.3: (last paragraph)=0D=0A= > > > > > > > > > > Re-write the last sentence as: "The proxy then=0D=0Arep= laces=0D=0A> > the=0D=0A> > > > > > > > Request-URI=0D=0A> > > > > > > > > = > with the resulting PSAP URI."=0D=0A> > > > > > > > > > Or perhaps "The re= sulting PSAP URI then replaces the=0D=0A> > > > > > Request-URI"=0D=0A> > >= > > > > > > >=0D=0A> > > > > > > > > > Section 6.4: (first paragraph)=0D=0A= > > > > > > > > > > Consider adding the phrase "Once the mapping to a=0D=0A= PSAP=0D=0A> > URI=0D=0A> > > > has=0D=0A> > > > > > been=0D=0A> > > > > > >= > > > performed," to the begining of the paragraph (to=0D=0Aimprove=0D=0A>= > the=0D=0A> > > > > > flow of=0D=0A> > > > > > > > the=0D=0A> > > > > > >= > > > document).=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section= 6.6:=0D=0A> > > > > > > > > > Change "The emergency dialstrings ..." to "E= mergency=0D=0A> > > > dialstrings=0D=0A> > > > > > > > ..."=0D=0A> > > > > = > > > > >=0D=0A> > > > > > > > > > Section 7: (paragraph 3)=0D=0A> > > > > = > > > > > Change "For calls send with ..." to "For calls sent=0D=0Awith=0D=0A= > > > > ..."=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 8: (= paragraph 1)=0D=0A> > > > > > > > > > Change "... media streams on RTP ... = " to "... media=0D=0A> > stream=0D=0A> > > > > > using=0D=0A> > > > > > > >= RTP=0D=0A> > > > > > > > > ..."=0D=0A> > > > > > > > > > or perhaps "... m= edia streams via RTP ..."=0D=0A> > > > > > > > > > Also, consider re-writin= g the 4th sentence as:=0D=0A> > > > > > > > > > "Future IP-enabled PSAPs sh= ould accept a wider array=0D=0Aof=0D=0A> > > > > > potential=0D=0A> > > > >= > > > media=0D=0A> > > > > > > > > > types."=0D=0A> > > > > > > > > >=0D=0A= > > > > > > > > > > Section 8: (paragraph 2)=0D=0A> > > > > > > > > > Add a= period between "the offer" and "Silence=0D=0A> > suppression".=0D=0A> > > = > > > > > > >=0D=0A> > > > > > > > > > Section 10:=0D=0A> > > > > > > > > >= Change "... it specifies use of several ..." to "...=0D=0Ait=0D=0A> > > > = > > specifies=0D=0A> > > > > > > > the=0D=0A> > > > > > > > > > use of seve= ral ..."=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 10.1: (p= aragraph 2)=0D=0A> > > > > > > > > > Change "... DHCP is the LCP [RFC3118] = =2E.." to "...=0D=0ADHCP=0D=0A> > is=0D=0A> > > > the=0D=0A> > > > > > LCP,=0D= =0A> > > > > > > > > > [RFC3118] ..." (add a comma)=0D=0A> > > > > > > > > = > Also, change "... spoofing would be ..." to "...=0D=0A> > spoofing is=0D=0A= > > > > > > ..."=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section = 10.1: (last paragraph)=0D=0A> > > > > > > > > > Add an 's' to change "Clien= t SHOULD" to "Clients=0D=0ASHOULD"=0D=0A> > > > > > > > > >=0D=0A> > > > > = > > > > > Section 10.2: (last paragraph)=0D=0A> > > > > > > > > > Change ".= =2E. signaling would help significantly." to=0D=0A"...=0D=0A> > > > > > sig= naling=0D=0A> > > > > > > > helps=0D=0A> > > > > > > > > > significantly."=0D= =0A> > > > > > > > >=0D=0A> > > > > > > > >=0D=0A> > > > > > > > >=0D=0A> >= > > > > > > > _______________________________________________=0D=0A> > > >= > > > > > Ecrit mailing list=0D=0A> > > > > > > > > Ecrit@ietf.org=0D=0A> = > > > > > > > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > > > >= > > >=0D=0A> > > > > > > >=0D=0A> > > > > >=0D=0A> > > >=0D=0A> >=0D=0A---= ---------------------------------------------------------------------=0D=0A= > > > > > > > --=0D=0A> > > > > > > > ----------------------=0D=0A> > > > >= > > > This message is for the designated recipient only and=0D=0Amay=0D=0A= > > > > > > > > contain privileged, proprietary, or otherwise private=0D=0A= > > > > information.=0D=0A> > > > > > > > If you have received it in error,= please notify the=0D=0Asender=0D=0A> > > > > > > > immediately and delete = the original. Any unauthorized=0D=0Ause=0D=0A> > of=0D=0A> > > > > > > > t= his email is prohibited.=0D=0A> > > > > > > >=0D=0A> > > > > >=0D=0A> > > >=0D= =0A> >=0D=0A---------------------------------------------------------------= ---------=0D=0A> > > > > > > --=0D=0A> > > > > > > > ----------------------=0D= =0A> > > > > > > > [mf2]=0D=0A> > > > > > >=0D=0A> > > > > >=0D=0A> > > > >= >=0D=0A> > > >=0D=0A> >=0D=0A---------------------------------------------= ---------------------------=0D=0A> > > > > --=0D=0A> > > > > > ------------= ----------=0D=0A> > > > > > This message is for the designated recipient on= ly and may=0D=0A> > > > > > contain privileged, proprietary, or otherwise p= rivate=0D=0A> > information.=0D=0A> > > > > > If you have received it in er= ror, please notify the sender=0D=0A> > > > > > immediately and delete the o= riginal. Any unauthorized use=0D=0Aof=0D=0A> > > > > > this email is prohi= bited.=0D=0A> > > > > >=0D=0A> > > >=0D=0A> >=0D=0A------------------------= ------------------------------------------------=0D=0A> > > > > --=0D=0A> >= > > > > ----------------------=0D=0A> > > > > > [mf2]=0D=0A> > > > >=0D=0A= > > > >=0D=0A> > > >=0D=0A> >=0D=0A----------------------------------------= --------------------------------=0D=0A> > > --=0D=0A> > > > ---------------= -------=0D=0A> > > > This message is for the designated recipient only and = may=0D=0A> > > > contain privileged, proprietary, or otherwise private=0D=0A= information.=0D=0A> > > > If you have received it in error, please notify t= he sender=0D=0A> > > > immediately and delete the original. Any unauthoriz= ed use of=0D=0A> > > > this email is prohibited.=0D=0A> > > >=0D=0A> >=0D=0A= ------------------------------------------------------------------------=0D= =0A> > > --=0D=0A> > > > ----------------------=0D=0A> > > > [mf2]=0D=0A> >= >=0D=0A> >=0D=0A> >=0D=0A-------------------------------------------------= -----------------------=0D=0A> --=0D=0A> > ----------------------=0D=0A> > = This message is for the designated recipient only and may=0D=0A> > contain = privileged, proprietary, or otherwise private information.=0D=0A> > If you = have received it in error, please notify the sender=0D=0A> > immediately an= d delete the original. Any unauthorized use of=0D=0A> > this email is proh= ibited.=0D=0A> >=0D=0A-----------------------------------------------------= -------------------=0D=0A> --=0D=0A> > ----------------------=0D=0A> > [mf2= ]=0D=0A>=20=0D=0A=0D=0A----------------------------------------------------= --------------------------------------------=0D=0AThis message is for the d= esignated recipient only and may=0D=0Acontain privileged, proprietary, or o= therwise private information. =20=0D=0AIf you have received it in error, pl= ease notify the sender=0D=0Aimmediately and delete the original. Any unaut= horized use of=0D=0Athis email is prohibited.=0D=0A------------------------= ------------------------------------------------------------------------=0D= =0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 01 18:52:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFzO-00051U-84; Fri, 01 Jun 2007 18:52:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuFzN-00051J-4Z for ecrit@ietf.org; Fri, 01 Jun 2007 18:52:57 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuFzM-0007SP-12 for ecrit@ietf.org; Fri, 01 Jun 2007 18:52:57 -0400 X-SEF-Processed: 5_0_0_910__2007_06_01_18_00_22 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 01 Jun 2007 18:00:22 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 17:52:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 Date: Fri, 1 Jun 2007 17:52:52 -0500 Message-ID: In-Reply-To: <0cba01c7a49e$dff4d120$6601a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RE: Comments on: draft-ietf-ecrit-phonebcp-01 Thread-Index: AcekCFEPcS0iQckvRVWGxa+1mAstOgAQAffgABMPLZAAAWw9QAAAS3KAAAAtGGAAAA9IoAAAR+PQAAAVaoAAADC5YAAAL+Vw References: <465FA53B.80802@bbn.com> <0add01c7a449$6846b260$6601a8c0@cis.neustar.com> <0cb001c7a49a$b2844440$6601a8c0@cis.neustar.com> <0cb301c7a49c$31472cb0$6601a8c0@cis.neustar.com> <0cb601c7a49d$c25ec540$6601a8c0@cis.neustar.com> <0cba01c7a49e$dff4d120$6601a8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Matt Lepinski" , "ECRIT" , "James M. Polk" X-OriginalArrivalTime: 01 Jun 2007 22:52:55.0657 (UTC) FILETIME=[97C7FD90:01C7A49F] X-Spam-Score: 0.0 (/) X-Scan-Signature: c40ff0c70161549dbde2f89c7946385a Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian,=0D=0A=0D=0AI actually think that the only difference is who does the= LoST lookup,=0D=0Aso adding the extra function to LoST and allowing more t= han one=0D=0Atechnique for location hiding if probably not a bad idea. Ulit= mately I=0D=0Asuspect that only one will end up being deployed, and that wi= ll be the=0D=0Aone that is easiest for the location providers to deploy.=0D= =0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A> -----Original Message-----=0D=0A> F= rom: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> Sent: Saturday, 2 June 2= 007 8:48 AM=0D=0A> To: Winterbottom, James; 'Matt Lepinski'; 'ECRIT'; 'Jame= s M. Polk'=0D=0A> Subject: RE: [Ecrit] RE: Comments on: draft-ietf-ecrit-ph= onebcp-01=0D=0A>=20=0D=0A> I'll let the chairs decide, and -phonebcp will f= ollow.=0D=0A>=20=0D=0A> You can choose any civic location in the service ar= ea to return as a=0D=0A> "coarse" location. For example, pick a street tha= t lies within the=0D=0A> service=0D=0A> boundary, and return it with no hou= se number. Of course, in the=0D=0Amajority=0D=0A> of=0D=0A> cases, the com= munity name will do.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A> > -----Origina= l Message-----=0D=0A> > From: Winterbottom, James [mailto:James.Winterbotto= m@andrew.com]=0D=0A> > Sent: Friday, June 01, 2007 6:42 PM=0D=0A> > To: Bri= an Rosen; Matt Lepinski; ECRIT; James M. Polk=0D=0A> > Subject: RE: [Ecrit]= RE: Comments on: draft-ietf-ecrit-phonebcp-01=0D=0A> >=0D=0A> > I don't th= ink so.=0D=0A> > The carriers have largely said that they prefer solution 3= , but=0D=0ACOULD=0D=0A> > work with solution 1. That to me is not consensus= on solution 1 but=0D=0Amore=0D=0A> > consensus on solution 3. I am yet to = see anyone suggest how solution=0D=0A1=0D=0A> > could possibly be done with= civic locations. Solution 3 will work=0D=0Awith=0D=0A> > both civic and ge= o without any problems.=0D=0A> >=0D=0A> > So I think this is where the disa= greement comes from.=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> > > -----Original Me= ssage-----=0D=0A> > > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> >= > Sent: Saturday, 2 June 2007 8:40 AM=0D=0A> > > To: Winterbottom, James; = 'Matt Lepinski'; 'ECRIT'; 'James M. Polk'=0D=0A> > > Subject: RE: [Ecrit] R= E: Comments on: draft-ietf-ecrit-phonebcp-01=0D=0A> > >=0D=0A> > > So far, = the location hiding thing is you get coarse location and=0D=0Ayou=0D=0A> > = LoST=0D=0A> > > route with it. There are people unhappy with that, who wan= t the=0D=0ALCP=0D=0A> > to=0D=0A> > > return LoST data, or LoST to do deref= erence. My read of rough=0D=0A> > consensus=0D=0A> > > was=0D=0A> > > coar= se location, but chairs have to call that one.=0D=0A> > >=0D=0A> > > Brian=0D= =0A> > >=0D=0A> > > > -----Original Message-----=0D=0A> > > > From: Winterb= ottom, James [mailto:James.Winterbottom@andrew.com]=0D=0A> > > > Sent: Frid= ay, June 01, 2007 6:30 PM=0D=0A> > > > To: Brian Rosen; Matt Lepinski; ECRI= T; James M. Polk=0D=0A> > > > Subject: RE: [Ecrit] RE: Comments on:=0D=0Adr= aft-ietf-ecrit-phonebcp-01=0D=0A> > > >=0D=0A> > > > Except that the end-po= int doesn't do the LoST thing=0D=0A> > > >=0D=0A> > > >=0D=0A> > > > > ----= -Original Message-----=0D=0A> > > > > From: Brian Rosen [mailto:br@brianros= en.net]=0D=0A> > > > > Sent: Saturday, 2 June 2007 8:29 AM=0D=0A> > > > > T= o: Winterbottom, James; 'Matt Lepinski'; 'ECRIT'; 'James M.=0D=0APolk'=0D=0A= > > > > > Subject: RE: [Ecrit] RE: Comments on:=0D=0Adraft-ietf-ecrit-phone= bcp-01=0D=0A> > > > >=0D=0A> > > > > But that is case 1=0D=0A> > > > >=0D=0A= > > > > > > -----Original Message-----=0D=0A> > > > > > From: Winterbottom,= James=0D=0A[mailto:James.Winterbottom@andrew.com]=0D=0A> > > > > > Sent: F= riday, June 01, 2007 6:24 PM=0D=0A> > > > > > To: Brian Rosen; Matt Lepinsk= i; ECRIT; James M. Polk=0D=0A> > > > > > Subject: RE: [Ecrit] RE: Comments = on:=0D=0A> > draft-ietf-ecrit-phonebcp-01=0D=0A> > > > > >=0D=0A> > > > > >= I was assuming that the end-point is given a location URI,=0D=0Alocal=0D=0A= > > > > > > dialsring, and service URNs. Say in the location hiding=0D=0Aca= se.=0D=0A> > > > > >=0D=0A> > > > > >=0D=0A> > > > > > > -----Original Mess= age-----=0D=0A> > > > > > > From: Brian Rosen [mailto:br@brianrosen.net]=0D= =0A> > > > > > > Sent: Saturday, 2 June 2007 8:18 AM=0D=0A> > > > > > > To:= Winterbottom, James; 'Matt Lepinski'; 'ECRIT'; 'James=0D=0AM.=0D=0A> > Pol= k'=0D=0A> > > > > > > Subject: RE: [Ecrit] RE: Comments on:=0D=0A> > draft-= ietf-ecrit-phonebcp-01=0D=0A> > > > > > >=0D=0A> > > > > > > If by that you= mean the endpoint gets location, recognizes=0D=0Aan=0D=0A> > > > > > emerg= ency=0D=0A> > > > > > > call, but does not route, then the proxy server has= to=0D=0Aroute.=0D=0A> > > > That=0D=0A> > > > > > case=0D=0A> > > > > > > = is=0D=0A> > > > > > > complex because without the LoST query, the endpoint=0D= =0Adoesn't=0D=0A> > have=0D=0A> > > > the=0D=0A> > > > > > > local=0D=0A> >= > > > > > dialstring(s).=0D=0A> > > > > > >=0D=0A> > > > > > > If that was= not what you mean, then who routes=3F=0D=0A> > > > > > >=0D=0A> > > > > > = > Brian=0D=0A> > > > > > >=0D=0A> > > > > > > > -----Original Message-----=0D= =0A> > > > > > > > From: Winterbottom, James=0D=0A> > [mailto:James.Winterb= ottom@andrew.com]=0D=0A> > > > > > > > Sent: Friday, June 01, 2007 5:35 PM=0D= =0A> > > > > > > > To: Brian Rosen; Matt Lepinski; ECRIT; James M. Polk=0D=0A= > > > > > > > > Subject: RE: [Ecrit] RE: Comments on:=0D=0A> > > > draft-ie= tf-ecrit-phonebcp-01=0D=0A> > > > > > > >=0D=0A> > > > > > > > I think that= there is one other variant on two.=0D=0A> > > > > > > >=0D=0A> > > > > > >= > The End-point makes the call the service URN and=0D=0Aincludes a=0D=0A> = > > > provided=0D=0A> > > > > > > > locationURI. Outbound-proxy does nothin= g special.=0D=0A> > > > > > > >=0D=0A> > > > > > > > > -----Original Messag= e-----=0D=0A> > > > > > > > > From: Brian Rosen [mailto:br@brianrosen.net]=0D= =0A> > > > > > > > > Sent: Friday, 1 June 2007 10:36 PM=0D=0A> > > > > > > = > > To: 'Matt Lepinski'; 'ECRIT'; 'James M. Polk'=0D=0A> > > > > > > > > Su= bject: [Ecrit] RE: Comments on:=0D=0A> > draft-ietf-ecrit-phonebcp-01=0D=0A= > > > > > > > > >=0D=0A> > > > > > > > > Thanks for your comments.=0D=0A> >= > > > > > > >=0D=0A> > > > > > > > > The BCP really shouldn't be SIP speci= fic. We need to=0D=0A> > broaden=0D=0A> > > > it=0D=0A> > > > > > to,=0D=0A= > > > > > > > > for=0D=0A> > > > > > > > > example, XMPP. We can have SIP = specific information,=0D=0Abut=0D=0A> > it=0D=0A> > > > > > should be=0D=0A= > > > > > > > > > discussed as just that.=0D=0A> > > > > > > > >=0D=0A> > >= > > > > > > There is a consensus, I believe, on how to mark=0D=0Aemergency=0D= =0A> > > > calls,=0D=0A> > > > > > > > > represented=0D=0A> > > > > > > > >= by the thread, but chairs have to call consensus, not=0D=0Ame.=0D=0A> > I=0D= =0A> > > > think=0D=0A> > > > > > > > there=0D=0A> > > > > > > > > are=0D=0A= > > > > > > > > > three cases:=0D=0A> > > > > > > > > 1. The endpoint recog= nizes it's an emergency call,=0D=0Adoes=0D=0A> > the=0D=0A> > > > LoST=0D=0A= > > > > > > > > routing,=0D=0A> > > > > > > > > and passes the call to its = outbound proxy server. In=0D=0Athis=0D=0A> > > > case=0D=0A> > > > > > the=0D= =0A> > > > > > > > > Request=0D=0A> > > > > > > > > URI will be the PSAP UR= I from LoST, and adds a Route=0D=0A> > header=0D=0A> > > > with=0D=0A> > > = > > > the=0D=0A> > > > > > > > > service=0D=0A> > > > > > > > > URN.=0D=0A>= > > > > > > > > 2. The endpoint recognizes it's an emergency call, but=0D=0A= > > doesn't=0D=0A> > > > > > LoST=0D=0A> > > > > > > > route=0D=0A> > > > >= > > > > it. In this case the Request URI would be the service=0D=0A> > UR= N.=0D=0A> > > > The=0D=0A> > > > > > > > outbound=0D=0A> > > > > > > > > pr= oxy server would do the LoST routing, put the Route=0D=0A> > header=0D=0A> = > > > with=0D=0A> > > > > > the=0D=0A> > > > > > > > > service URN in and c= hange the Request URI to the PSAP=0D=0AURI.=0D=0A> > > > > > > > > 3. The e= ndpoint doesn't even recognize it's an=0D=0Aemergency=0D=0A> > call.=0D=0A>= > > > In=0D=0A> > > > > > > > this=0D=0A> > > > > > > > > case, the endpoi= nt would put the dialstring in the=0D=0ARequest=0D=0A> > > > URI.=0D=0A> > = > > > > The=0D=0A> > > > > > > > > outbound proxy would behave as in 2 abov= e.=0D=0A> > > > > > > > >=0D=0A> > > > > > > > > When the PSAP gets the cal= l, it will always have its=0D=0AURI=0D=0A> > in=0D=0A> > > > the=0D=0A> > >= > > > > > Request=0D=0A> > > > > > > > > URI,=0D=0A> > > > > > > > > and t= here will be a service URN in a Route header.=0D=0A> > > > > > > > >=0D=0A>= > > > > > > > > Probably, phonebcp should say that more clearly.=0D=0A> > = > > > > > > >=0D=0A> > > > > > > > > Brian=0D=0A> > > > > > > > >=0D=0A> > = > > > > > > > > -----Original Message-----=0D=0A> > > > > > > > > > From: M= att Lepinski [mailto:mlepinski@bbn.com]=0D=0A> > > > > > > > > > Sent: Frid= ay, June 01, 2007 12:49 AM=0D=0A> > > > > > > > > > To: ECRIT; James M. Pol= k; br@brianrosen.net=0D=0A> > > > > > > > > > Subject: Comments on: draft-i= etf-ecrit-phonebcp-01=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Bri= an and James:=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > First, two = very high level questions.=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > = > A) [Is this document supposed to be SIP-Centric=3F] It=0D=0Ais=0D=0A> > >= > unclear=0D=0A> > > > > > to=0D=0A> > > > > > > > me=0D=0A> > > > > > > >= > > whether the document is intended as a BCP for SIP=0D=0AUser=0D=0A> > >= > Agents=0D=0A> > > > > > and=0D=0A> > > > > > > > SIP=0D=0A> > > > > > > = > > > proxies, or whether it is more generally a BCP for=0D=0Aend=0D=0A> > = > > points=0D=0A> > > > > > and=0D=0A> > > > > > > > > > signaling-path dev= ices which may or may not use SIP.=0D=0AFor=0D=0A> > > > > > instance,=0D=0A= > > > > > > > > > > Section 6.4 is written as though SIP signaling were=0D=0A= a=0D=0A> > > > special=0D=0A> > > > > > case,=0D=0A> > > > > > > > and=0D=0A= > > > > > > > > > > yet paragraph four of Section 5 indicates that all=0D=0A= > > emergency=0D=0A> > > > > > calls=0D=0A> > > > > > > > on=0D=0A> > > > >= > > > > > the wire should contain a Route header (which is a=0D=0A> > > > = SIP-specific=0D=0A> > > > > > > > > > signaling component). Personally, I d= on't care=0D=0Awhether=0D=0A> > or=0D=0A> > > > not=0D=0A> > > > > > the=0D= =0A> > > > > > > > > > document is SIP centric, or whether SIP is a special=0D= =0A> > case,=0D=0A> > > > as=0D=0A> > > > > > long=0D=0A> > > > > > > > as=0D= =0A> > > > > > > > > > the document is consistent.=0D=0A> > > > > > > > > >=0D= =0A> > > > > > > > > > B) [Is there consensus on how to mark emergency=0D=0A= calls=3F]=0D=0A> > The=0D=0A> > > > > > current=0D=0A> > > > > > > > > > ve= rsion of phonebcp indicates that (in the normal=0D=0Acase=0D=0A> > when=0D=0A= > > > > > > > > end-points=0D=0A> > > > > > > > > > perform the LoST mappin= g) emergency calls are marked=0D=0Aby=0D=0A> > > > putting=0D=0A> > > > > >= the=0D=0A> > > > > > > > URN=0D=0A> > > > > > > > > > in a Route header (w= ith a "loose" parameter that I'm=0D=0Anot=0D=0A> > > > > > familiar=0D=0A> = > > > > > > > with=0D=0A> > > > > > > > > > ... can someone provide me with= a reference) and=0D=0Athat=0D=0A> > the=0D=0A> > > > URN is=0D=0A> > > > >= > > > placed=0D=0A> > > > > > > > > > in the Request-URI when the end-poin= t is unable to=0D=0A> > perform=0D=0A> > > > the=0D=0A> > > > > > LoST=0D=0A= > > > > > > > > > > mapping). Personally, I don't understand the current=0D= =0A> > > > mechanism=0D=0A> > > > > > > > because=0D=0A> > > > > > > > > > = I'm not sure what an "ordinary" (RFC3261-compliant)=0D=0A> > proxy=0D=0A> >= > > does=0D=0A> > > > > > when=0D=0A> > > > > > > > it=0D=0A> > > > > > > = > > > sees a service URN in the top Route header. However,=0D=0A> > given=0D= =0A> > > > the=0D=0A> > > > > > long=0D=0A> > > > > > > > > > discussion th= at occured on call marking in January=0D=0A(See:=0D=0A> > > > > > > > > >=0D= =0A> > > > > >=0D=0A> > http://www1.ietf.org/mail-archive/web/ecrit/current= /msg02963.html),=0D=0A> > > > > > > > > > perhaps the more important questi= on is "Has=0D=0Aconsensus=0D=0A> > been=0D=0A> > > > > > reached=0D=0A> > >= > > > > > that=0D=0A> > > > > > > > > > (something like) the current mecha= nism is an=0D=0Aappropriate=0D=0A> > way=0D=0A> > > > to=0D=0A> > > > > > m= ark=0D=0A> > > > > > > > > > messages=3F"=0D=0A> > > > > > > > > >=0D=0A> >= > > > > > > > > ---------------------------------=0D=0A> > > > > > > > > >= More detailed comments:=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > = Section 2: (paragraph 3 - number 2)=0D=0A> > > > > > > > > > Is it clear wh= at the "visited location's emergency=0D=0A> > number"=0D=0A> > > > means=0D= =0A> > > > > > in=0D=0A> > > > > > > > this=0D=0A> > > > > > > > > > contex= t=3F=0D=0A> > > > > > > > > > Consider changing to "the local emergency num= ber for=0D=0Aits=0D=0A> > > > current=0D=0A> > > > > > > > > > location" or= providing a forward reference to the=0D=0A> > discussion=0D=0A> > > > of=0D= =0A> > > > > > > > > > dial-strings in Section 5.=0D=0A> > > > > > > > > >=0D= =0A> > > > > > > > > > Section 2: (paragraph 4)=0D=0A> > > > > > > > > > I = agree with Barbara that if this is intended to an=0D=0A> > overview=0D=0A> = > > > of=0D=0A> > > > > > call=0D=0A> > > > > > > > > > setup for the speci= al case of an Ethernet connected=0D=0A> > phone=0D=0A> > > > then=0D=0A> > = > > > > the=0D=0A> > > > > > > > > > bullets should match up more clearly w= ith the=0D=0Anumbered=0D=0A> > items=0D=0A> > > > in=0D=0A> > > > > > the=0D= =0A> > > > > > > > > > previous paragraph.=0D=0A> > > > > > > > > >=0D=0A> = > > > > > > > > > Section 2: (last paragraph)=0D=0A> > > > > > > > > > It i= s unclear whether the antecedent of "it" in the=0D=0Alast=0D=0A> > > > > > = paragraph=0D=0A> > > > > > > > is=0D=0A> > > > > > > > > > [RFC4103] or [RF= C4504].=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 3:=0D=0A>= > > > > > > > > > Consider changing "should support" to "SHOULD=0D=0Asuppo= rt"=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 3: (paragraph= 2)=0D=0A> > > > > > > > > > It seems that the point of this paragraph is t= o say=0D=0Athat=0D=0A> > a=0D=0A> > > > > > certain=0D=0A> > > > > > > > cl= ass=0D=0A> > > > > > > > > > of devices that communicates over IP networks = should=0D=0A> > support=0D=0A> > > > > > > > emergency=0D=0A> > > > > > > >= > > calls. However, I find the phrase "using current=0D=0A> > (evolving)=0D= =0A> > > > > > > > standards"=0D=0A> > > > > > > > > > to be unclear and in= particular I'm not sure what=0D=0Athe=0D=0A> > phrase=0D=0A> > > > > > > >= modifies.=0D=0A> > > > > > > > > > (E.g. Do you mean "Devices that create = media=0D=0Asessions=0D=0A> > using=0D=0A> > > > > > current=0D=0A> > > > > = > > > > > (evolving) standards and exchange audio ...")=0D=0A> > > > > > > = > > >=0D=0A> > > > > > > > > > Section 4: (first paragraph)=0D=0A> > > > > = > > > > > Consider replacing "the norm" with "required" (or a=0D=0A> > simi= lar=0D=0A> > > > > > word). I=0D=0A> > > > > > > > > > think the point is n= ot that automatic location is=0D=0A> > > > common/normal=0D=0A> > > > > > b= ut=0D=0A> > > > > > > > that=0D=0A> > > > > > > > > > it is necessary since= most users are unable to=0D=0Aprovide=0D=0A> > > > accurate=0D=0A> > > > >= > > > > location.=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Sectio= n 4.1: (first paragraph)=0D=0A> > > > > > > > > > I think "cellular" (or "t= raditional wireless") is=0D=0Amore=0D=0A> > > > precise=0D=0A> > > > > > t= han=0D=0A> > > > > > > > > > "mobile".=0D=0A> > > > > > > > > >=0D=0A> > > = > > > > > > > Section 4.2: (first paragraph ... also, the last=0D=0A> > par= agraph)=0D=0A> > > > > > > > > > Consider changing the phrase "the desired = result" to=0D=0A> > > > something=0D=0A> > > > > > like=0D=0A> > > > > > > = > "an=0D=0A> > > > > > > > > > equivalent result", or perhaps something eve= n more=0D=0A> > explicit.=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > >= Section 4.2: (first paragraph)=0D=0A> > > > > > > > > > Consider addition = a phrase to the last sentence=0D=0A> > indicating=0D=0A> > > > why=0D=0A> >= > > > > it is=0D=0A> > > > > > > > > > recommended that the network suppor= t a standardized=0D=0ALCP.=0D=0A> > > > (This=0D=0A> > > > > > may=0D=0A> >= > > > > > > not=0D=0A> > > > > > > > > > be obvious to the reader). Also, = consider changing=0D=0A> > > > "recommended"=0D=0A> > > > > > to=0D=0A> > >= > > > > > > > "RECOMMENDED".=0D=0A> > > > > > > > > >=0D=0A> > > > > > > >= > > Section 4.2: (paragraph 2)=0D=0A> > > > > > > > > > Given that the par= agraph covers what both devices=0D=0Aand=0D=0A> > access=0D=0A> > > > > > >= > networks=0D=0A> > > > > > > > > > MUST support, consider changing "For a= ll other=0D=0Adevices"=0D=0A> > to=0D=0A> > > > "In=0D=0A> > > > > > all=0D= =0A> > > > > > > > other=0D=0A> > > > > > > > > > scenarios".=0D=0A> > > > = > > > > > >=0D=0A> > > > > > > > > > Section 4.3: (paragraph 3)=0D=0A> > > = > > > > > > > The term "geo-location" is not used in RFC 3825 to=0D=0A> > d= escribe=0D=0A> > > > a=0D=0A> > > > > > > > > > lat/lon/alt - style locatio= n. (Instead it uses terms=0D=0A> > like a=0D=0A> > > > > > > > > > "coordin= ate-based geolocation"). Also, given that=0D=0Athe=0D=0A> > > > > > "geoloc= ation"=0D=0A> > > > > > > > > > header allows for civic locations, I think = using=0D=0A> > > > geo-location=0D=0A> > > > > > here=0D=0A> > > > > > > > = is=0D=0A> > > > > > > > > > potentially confusing.=0D=0A> > > > > > > > > >= Note: This comment also applies to the use of "geo=0D=0A> > reported"=0D=0A= > > > > in=0D=0A> > > > > > the=0D=0A> > > > > > > > > > third paragraph of= Section 6.3=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 4.4:= (last paragraph)=0D=0A> > > > > > > > > > Consider re-writing the second-= to-the-last sentence=0D=0Aas:=0D=0A> > > > "Certain=0D=0A> > > > > > > > > = > commonly-used techniques for measuring location=0D=0Acreate a=0D=0A> > > = > > > conflict=0D=0A> > > > > > > > > > between the time it takes to genera= te a precise=0D=0Alocation=0D=0A> > and=0D=0A> > > > the=0D=0A> > > > > > >= > desire=0D=0A> > > > > > > > > > to route the call quickly." (Also, in th= e following=0D=0A> > sentence=0D=0A> > > > I=0D=0A> > > > > > think=0D=0A> = > > > > > > > > > "precise" is a better word than "accurate")=0D=0A> > > > = > > > > > >=0D=0A> > > > > > > > > > Section 5: (paragraphs 5 and 6)=0D=0A>= > > > > > > > > > Paragraph 5 says that devices MUST mark calls using=0D=0A= a=0D=0A> > > > > > service:sos=0D=0A> > > > > > > > URN.=0D=0A> > > > > > >= > > > However, paragraph 6 says that mapping from=0D=0Adialstring=0D=0A> >= to=0D=0A> > > > URN=0D=0A> > > > > > SHOULD=0D=0A> > > > > > > > be=0D=0A>= > > > > > > > > > done by the endpoint. Either both paragraphs should=0D=0A= use=0D=0A> > > > "MUST"=0D=0A> > > > > > or=0D=0A> > > > > > > > else=0D=0A= > > > > > > > > > > they should both use "SHOULD".=0D=0A> > > > > > > > > >=0D= =0A> > > > > > > > > > Section 5: (paragraph 8)=0D=0A> > > > > > > > > > I = don't understand what it means to be "roaming" or=0D=0A> > > > "nomadic" in=0D= =0A> > > > > > a=0D=0A> > > > > > > > > > system where there is no "visited= network"=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 5: (las= t paragraph)=0D=0A> > > > > > > > > > The last sentence of this paragraph s= eems to be=0D=0A> > redundent.=0D=0A> > > > > > Consider=0D=0A> > > > > > >= > > > deleting it.=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Secti= on 6.1:=0D=0A> > > > > > > > > > I agree with Barbara that the use of IPSec= should=0D=0Anot be=0D=0A> > > > > > prohibited=0D=0A> > > > > > > > by=0D=0A= > > > > > > > > > > this BCP.=0D=0A> > > > > > > > > >=0D=0A> > > > > > > >= > > Section 6.1: (number 6)=0D=0A> > > > > > > > > > These instructions ar= e for the User Agent,=0D=0A> > > > P-Asserted-Identity=0D=0A> > > > > > > >= headers=0D=0A> > > > > > > > > > and Identity headers should not be insert= ed by the=0D=0AUA=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section= 6.1: (number 10)=0D=0A> > > > > > > > > > This item is unclear to me. Is t= he author's=0D=0Aintention=0D=0A> > that=0D=0A> > > > this=0D=0A> > > > > >= item=0D=0A> > > > > > > > > > handles the case where a UA does not know it= s own=0D=0A> > location=3F=0D=0A> > > > If=0D=0A> > > > > > so, I=0D=0A> > = > > > > > > > > guess that updating this item should be deferred=0D=0Auntil=0D= =0A> > > > consensus=0D=0A> > > > > > is=0D=0A> > > > > > > > > > reached o= n location-hiding.=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Sectio= n 6.1:=0D=0A> > > > > > > > > > Consider Re-ordering the items as:=0D=0A> >= > > > > > > > > 11, 10, 12, 14, 15, 13=0D=0A> > > > > > > > > > Also, cons= ider deleting 12, I believe it is=0D=0Aredundent=0D=0A> > given=0D=0A> > > = > 9,=0D=0A> > > > > > 10=0D=0A> > > > > > > > and=0D=0A> > > > > > > > > 11= =2E=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 6.2: (number = 1)=0D=0A> > > > > > > > > > Consider adding an example after "... URN=0D=0A= appropriate=0D=0A> > for=0D=0A> > > > the=0D=0A> > > > > > > > emergency=0D= =0A> > > > > > > > > > dialstring." That is, consider adding (e.g., ...)=0D= =0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 6.2: (number 3)=0D=0A= > > > > > > > > > > I'm afraid that I don't understand the meaning of=0D=0A= this=0D=0A> > > > sentence.=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > >= > Section 6.3: (paragraph 3)=0D=0A> > > > > > > > > > The sentence that be= gins "This can be an enclosing=0D=0A..."=0D=0A> > is=0D=0A> > > > > > uncle= ar=0D=0A> > > > > > > > to=0D=0A> > > > > > > > > > me. Are you suggesting = that when a PSAP coverage=0D=0Aregion=0D=0A> > is=0D=0A> > > > > > complex,=0D= =0A> > > > > > > > that=0D=0A> > > > > > > > > > a LoST server SHOULD retur= n a simple polygon that=0D=0A(a)=0D=0A> > > > contains=0D=0A> > > > > > the=0D= =0A> > > > > > > > > > location of the device; and (b) is entirely=0D=0Acon= tained=0D=0A> > within=0D=0A> > > > the=0D=0A> > > > > > > > PSAP=0D=0A> > = > > > > > > > > coverage region=3F=0D=0A> > > > > > > > > >=0D=0A> > > > > = > > > > > Section 6.5: (number 3)=0D=0A> > > > > > > > > > This seems to im= ply that proxies should expect to=0D=0A> > SUBSCRIBE=0D=0A> > > > to=0D=0A>= > > > > > > > Presence.=0D=0A> > > > > > > > > > Do you mean that proxies = should expect the PSAP to=0D=0A> > SUBSCRIBE=0D=0A> > > > to=0D=0A> > > > >= > > > > Presence=3F=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Sect= ion 6.5: (number 4)=0D=0A> > > > > > > > > > I'm not very familiar with Ses= sion Timers, can you=0D=0A> > provide a=0D=0A> > > > > > > > reference.=0D=0A= > > > > > > > > > >=0D=0A> > > > > > > > > > Section 6.6:=0D=0A> > > > > > = > > > > I'm afraid I don't understand the parenthetical=0D=0Aremark=0D=0A> = > after=0D=0A> > > > the=0D=0A> > > > > > > > "Call=0D=0A> > > > > > > > > = > Forward" bullet. (Consider removing the remark or=0D=0A> > re-wording=0D=0A= > > > > it=0D=0A> > > > > > if=0D=0A> > > > > > > > it is=0D=0A> > > > > > = > > > > important).=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Secti= on 7:=0D=0A> > > > > > > > > > Given the text in Section 4.4 it seems to me= that=0D=0Athe=0D=0A> > first=0D=0A> > > > > > > > paragraph of=0D=0A> > > = > > > > > > > Section 7 is redundent and should be deleted.=0D=0A> > > > > = > > > > >=0D=0A> > > > > > > > > > Section 10.2:=0D=0A> > > > > > > > > > G= iven the difficulty of implementing location=0D=0Asigning in=0D=0A> > a=0D=0A= > > > > > > useful=0D=0A> > > > > > > > > > manner, I think that that eithe= r paragraph 2 should=0D=0A> > either=0D=0A> > > > be=0D=0A> > > > > > > > r= emoved or=0D=0A> > > > > > > > > > else it should reference some other docu= ment that=0D=0A> > explains=0D=0A> > > > > > location=0D=0A> > > > > > > > = > > signing in more detail. (That is, one paragraph does=0D=0Anot=0D=0A> > = do=0D=0A> > > > > > location=0D=0A> > > > > > > > > > signing justice and i= t seems irresponsible to=0D=0Astrongly=0D=0A> > > > recommend=0D=0A> > > > = > > > > > > location signing without providing additionaly=0D=0Aguidence=0D= =0A> > to=0D=0A> > > > the=0D=0A> > > > > > > > > > implementor).=0D=0A> > = > > > > > > > >=0D=0A> > > > > > > > > >=0D=0A> > > > > >=0D=0A> > --------= -----------------------------------------------------------=0D=0A> > > > > = > > > > > Minor Nits: (That don't change the meaning of the=0D=0Atext)=0D=0A= > > > > > > > > > >=0D=0A> > > > > > > > > > Section 2: (last paragraph)=0D= =0A> > > > > > > > > > Put a space between [RFC4103] and "media"=0D=0A> > >= > > > > > > >=0D=0A> > > > > > > > > > Section 3: (paragraph 1)=0D=0A> > >= > > > > > > > Add commas to second sentence "Future PSAPs will,=0D=0A> > h= owever,=0D=0A> > > > > > support=0D=0A> > > > > > > > ..."=0D=0A> > > > > >= > > > > and remove the extra period at the end of the=0D=0Asentence=0D=0A>= > > > > > > > > >=0D=0A> > > > > > > > > > Section 4.1: (paragraph 2)=0D=0A= > > > > > > > > > > Change "... where it is the access network that=0D=0Akn= ows=0D=0A> > the=0D=0A> > > > > > location=0D=0A> > > > > > > > ..."=0D=0A>= > > > > > > > > > to "... when only the access network knows the=0D=0Aloca= tion=0D=0A> > ..."=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Sectio= n 4.4: (paragraph 1)=0D=0A> > > > > > > > > > Change "... process engaged f= rom establishing a VPN=0D=0A...=0D=0A> > " to=0D=0A> > > > > > "...=0D=0A> = > > > > > > > > > process engaged by establishing a VPN ..."=0D=0A> > > > >= > > > > >=0D=0A> > > > > > > > > > Section 4.4: (paragraph 2)=0D=0A> > > >= > > > > > > Change "... related to the mobility of the device=0D=0Aand=0D=0A= > > ..."=0D=0A> > > > to=0D=0A> > > > > > "...=0D=0A> > > > > > > > > > rel= ated to the degree of device mobility and ..."=0D=0A> > > > > > > > > >=0D=0A= > > > > > > > > > > Section 4.4: (paragraph 2)=0D=0A> > > > > > > > > > Com= bine the final 2 sentances as follows:=0D=0A> > > > > > > > > > "When a dev= ice is aware that it has moved, for=0D=0Ainstance=0D=0A> > when=0D=0A> > > = > it=0D=0A> > > > > > > > changes=0D=0A> > > > > > > > > > access points, t= he device SHOULD refresh its=0D=0Alocation."=0D=0A> > > > > > > > > >=0D=0A= > > > > > > > > > > Section 4.4: (last paragraph)=0D=0A> > > > > > > > > > = Change "... getting more recent location ..." to=0D=0A"...=0D=0A> > > > get= ting=0D=0A> > > > > > > > updated=0D=0A> > > > > > > > > > location ..." or= "... obtaining a fresh location"=0D=0A> > > > > > > > > >=0D=0A> > > > > >= > > > > Section 5: (first paragraph)=0D=0A> > > > > > > > > > Consider re-= writing as:=0D=0A> > > > > > > > > > "A device (or a downstream signaling e= lement)=0D=0Aidentifies=0D=0A> > an=0D=0A> > > > > > > > emergency=0D=0A> >= > > > > > > > > call by an "address", which in most cases is a=0D=0A> > di= alstring,=0D=0A> > > > > > although=0D=0A> > > > > > > > > > other user int= erfaces may be used."=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Sec= tion 5: (paragraph 2)=0D=0A> > > > > > > > > > First sentence has too many = words modifying the word=0D=0A> > > > "element".=0D=0A> > > > > > > > > Con= sider:=0D=0A> > > > > > > > > > "Note: It is undesirable for a user-interfa= ce to=0D=0Aenable=0D=0A> > a=0D=0A> > > > user=0D=0A> > > > > > to=0D=0A> >= > > > > > > place=0D=0A> > > > > > > > > > an emergency call by pressing a= single button."=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section = 5: (paragraph 3)=0D=0A> > > > > > > > > > Consider changing the first sente= nce:=0D=0A> > > > > > > > > > "... in other countries there are several 3 d= igit=0D=0A> > numbers=0D=0A> > > > used=0D=0A> > > > > > for=0D=0A> > > > >= > > > > > different types of emergency calls."=0D=0A> > > > > > > > > >=0D= =0A> > > > > > > > > > Section 5: (paragraph 6)=0D=0A> > > > > > > > > > Ch= ange "... some entity needs to ..." to "... some=0D=0A> > entity on=0D=0A> = > > > the=0D=0A> > > > > > > > > > signaling path must ..."=0D=0A> > > > > = > > > > >=0D=0A> > > > > > > > > > Section 5: (paragraph 9)=0D=0A> > > > > = > > > > > Change "... from North America, the home ..." to=0D=0A"...=0D=0A>= > from=0D=0A> > > > North=0D=0A> > > > > > > > > > America, then while in = North America the home ..."=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > >= > Section 5: (last paragraph)=0D=0A> > > > > > > > > > Add a close parenth= esis ")" after "dialstrings."=0D=0A> > > > > > > > > >=0D=0A> > > > > > > >= > > Section 6:=0D=0A> > > > > > > > > > Change "... is expected be support= ed ..." to "... is=0D=0A> > > > expected to=0D=0A> > > > > > be=0D=0A> > > = > > > > > > > supported ..."=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > = > > Section 6.1:=0D=0A> > > > > > > > > > Change "signaling Method" to "sig= naling method"=0D=0A(lower=0D=0A> > > > case).=0D=0A> > > > > > > > > >=0D=0A= > > > > > > > > > > Section 6.1: (number 1)=0D=0A> > > > > > > > > > Change= "To: SHOULD" to "Request-URI: SHOULD"=0D=0A> > > > > > > > > >=0D=0A> > > = > > > > > > > Section 6.1: (number 2)=0D=0A> > > > > > > > > > Add a space = between [I-D.rosen-iptel-dialstring] and=0D=0A> > "with"=0D=0A> > > > > > >= > > > Also change "sips MUST be ..." to "a sips URI MUST=0D=0Abe=0D=0A> > = =2E.."=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 6.2: (numb= er 1)=0D=0A> > > > > > > > > > Change "If it finds it it MUST:" to "If it f= inds the=0D=0A> > > > dialstring=0D=0A> > > > > > it=0D=0A> > > > > > > > >= MUST:"=0D=0A> > > > > > > > > > Also, change "... for the endpoint" to "..= =2E of the=0D=0Aend=0D=0A> > > > device."=0D=0A> > > > > > > > (note=0D=0A>= > > > > > > > > > that period was missing)=0D=0A> > > > > > > > > >=0D=0A>= > > > > > > > > > Section 6.3: (paragraph 3)=0D=0A> > > > > > > > > > Non-= parallel sentence structure. Consider re-writing=0D=0Athe=0D=0A> > > > last=0D= =0A> > > > > > > > sentence=0D=0A> > > > > > > > > as:=0D=0A> > > > > > > >= > > "In the case of civic location, the LoST server=0D=0ASHOULD=0D=0A> > >= > report=0D=0A> > > > > > that=0D=0A> > > > > > > > the=0D=0A> > > > > > >= > > > same mapping is good within a community name or even=0D=0Aa=0D=0A> >= > > street,=0D=0A> > > > > > as=0D=0A> > > > > > > > this=0D=0A> > > > > >= > > > > is helpful for WiFi connected devices that roam and=0D=0A> > obtai= n=0D=0A> > > > civic=0D=0A> > > > > > > > > > location from the AP to which= they connect."=0D=0A> > > > > > > > > > (Or perhaps "Despite the fact that= civic location is=0D=0A> > > > uncommon=0D=0A> > > > > > for=0D=0A> > > > = > > > > mobile=0D=0A> > > > > > > > > > devices, the LoST server SHOULD ...= ")=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 6.3: (paragrap= h 4)=0D=0A> > > > > > > > > > Change "... URI of the service URN ..." to ".= =2E. URI=0D=0Aof a=0D=0A> > > > service=0D=0A> > > > > > URN=0D=0A> > > > >= > > > > ..."=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 6.3= : (last paragraph)=0D=0A> > > > > > > > > > Re-write the last sentence as: = "The proxy then=0D=0Areplaces=0D=0A> > the=0D=0A> > > > > > > > Request-URI=0D= =0A> > > > > > > > > > with the resulting PSAP URI."=0D=0A> > > > > > > > >= > Or perhaps "The resulting PSAP URI then replaces the=0D=0A> > > > > > Re= quest-URI"=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 6.4: (= first paragraph)=0D=0A> > > > > > > > > > Consider adding the phrase "Once = the mapping to a=0D=0APSAP=0D=0A> > URI=0D=0A> > > > has=0D=0A> > > > > > b= een=0D=0A> > > > > > > > > > performed," to the begining of the paragraph (= to=0D=0Aimprove=0D=0A> > the=0D=0A> > > > > > flow of=0D=0A> > > > > > > > = the=0D=0A> > > > > > > > > > document).=0D=0A> > > > > > > > > >=0D=0A> > >= > > > > > > > Section 6.6:=0D=0A> > > > > > > > > > Change "The emergency = dialstrings ..." to "Emergency=0D=0A> > > > dialstrings=0D=0A> > > > > > > = > ..."=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 7: (paragr= aph 3)=0D=0A> > > > > > > > > > Change "For calls send with ..." to "For ca= lls sent=0D=0Awith=0D=0A> > > > ..."=0D=0A> > > > > > > > > >=0D=0A> > > > = > > > > > > Section 8: (paragraph 1)=0D=0A> > > > > > > > > > Change "... m= edia streams on RTP ... " to "... media=0D=0A> > stream=0D=0A> > > > > > us= ing=0D=0A> > > > > > > > RTP=0D=0A> > > > > > > > > ..."=0D=0A> > > > > > >= > > > or perhaps "... media streams via RTP ..."=0D=0A> > > > > > > > > > = Also, consider re-writing the 4th sentence as:=0D=0A> > > > > > > > > > "Fu= ture IP-enabled PSAPs should accept a wider array=0D=0Aof=0D=0A> > > > > > = potential=0D=0A> > > > > > > > media=0D=0A> > > > > > > > > > types."=0D=0A= > > > > > > > > > >=0D=0A> > > > > > > > > > Section 8: (paragraph 2)=0D=0A= > > > > > > > > > > Add a period between "the offer" and "Silence=0D=0A> > = suppression".=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > > > Section 10:=0D= =0A> > > > > > > > > > Change "... it specifies use of several ..." to "...=0D= =0Ait=0D=0A> > > > > > specifies=0D=0A> > > > > > > > the=0D=0A> > > > > > = > > > > use of several ..."=0D=0A> > > > > > > > > >=0D=0A> > > > > > > > >= > Section 10.1: (paragraph 2)=0D=0A> > > > > > > > > > Change "... DHCP is= the LCP [RFC3118] ..." to "...=0D=0ADHCP=0D=0A> > is=0D=0A> > > > the=0D=0A= > > > > > > LCP,=0D=0A> > > > > > > > > > [RFC3118] ..." (add a comma)=0D=0A= > > > > > > > > > > Also, change "... spoofing would be ..." to "...=0D=0A>= > spoofing is=0D=0A> > > > > > ..."=0D=0A> > > > > > > > > >=0D=0A> > > > = > > > > > > Section 10.1: (last paragraph)=0D=0A> > > > > > > > > > Add an = 's' to change "Client SHOULD" to "Clients=0D=0ASHOULD"=0D=0A> > > > > > > >= > >=0D=0A> > > > > > > > > > Section 10.2: (last paragraph)=0D=0A> > > > >= > > > > > Change "... signaling would help significantly." to=0D=0A"...=0D= =0A> > > > > > signaling=0D=0A> > > > > > > > helps=0D=0A> > > > > > > > > = > significantly."=0D=0A> > > > > > > > >=0D=0A> > > > > > > > >=0D=0A> > > = > > > > > >=0D=0A> > > > > > > > > ________________________________________= _______=0D=0A> > > > > > > > > Ecrit mailing list=0D=0A> > > > > > > > > Ec= rit@ietf.org=0D=0A> > > > > > > > > https://www1.ietf.org/mailman/listinfo/= ecrit=0D=0A> > > > > > > >=0D=0A> > > > > > > >=0D=0A> > > > > >=0D=0A> > >= >=0D=0A> >=0D=0A----------------------------------------------------------= --------------=0D=0A> > > > > > > --=0D=0A> > > > > > > > -----------------= -----=0D=0A> > > > > > > > This message is for the designated recipient onl= y and=0D=0Amay=0D=0A> > > > > > > > contain privileged, proprietary, or oth= erwise private=0D=0A> > > > information.=0D=0A> > > > > > > > If you have r= eceived it in error, please notify the=0D=0Asender=0D=0A> > > > > > > > imm= ediately and delete the original. Any unauthorized=0D=0Ause=0D=0A> > of=0D= =0A> > > > > > > > this email is prohibited.=0D=0A> > > > > > > >=0D=0A> > = > > > >=0D=0A> > > >=0D=0A> >=0D=0A----------------------------------------= --------------------------------=0D=0A> > > > > > > --=0D=0A> > > > > > > >= ----------------------=0D=0A> > > > > > > > [mf2]=0D=0A> > > > > > >=0D=0A= > > > > > >=0D=0A> > > > > >=0D=0A> > > >=0D=0A> >=0D=0A-------------------= -----------------------------------------------------=0D=0A> > > > > --=0D=0A= > > > > > > ----------------------=0D=0A> > > > > > This message is for the= designated recipient only and may=0D=0A> > > > > > contain privileged, pro= prietary, or otherwise private=0D=0A> > information.=0D=0A> > > > > > If yo= u have received it in error, please notify the sender=0D=0A> > > > > > imme= diately and delete the original. Any unauthorized use=0D=0Aof=0D=0A> > > >= > > this email is prohibited.=0D=0A> > > > > >=0D=0A> > > >=0D=0A> >=0D=0A= ------------------------------------------------------------------------=0D= =0A> > > > > --=0D=0A> > > > > > ----------------------=0D=0A> > > > > > [m= f2]=0D=0A> > > > >=0D=0A> > > >=0D=0A> > > >=0D=0A> >=0D=0A----------------= --------------------------------------------------------=0D=0A> > > --=0D=0A= > > > > ----------------------=0D=0A> > > > This message is for the designa= ted recipient only and may=0D=0A> > > > contain privileged, proprietary, or= otherwise private=0D=0Ainformation.=0D=0A> > > > If you have received it i= n error, please notify the sender=0D=0A> > > > immediately and delete the o= riginal. Any unauthorized use of=0D=0A> > > > this email is prohibited.=0D= =0A> > > >=0D=0A> >=0D=0A--------------------------------------------------= ----------------------=0D=0A> > > --=0D=0A> > > > ----------------------=0D= =0A> > > > [mf2]=0D=0A> > >=0D=0A> >=0D=0A> >=0D=0A------------------------= ------------------------------------------------=0D=0A> --=0D=0A> > -------= ---------------=0D=0A> > This message is for the designated recipient only = and may=0D=0A> > contain privileged, proprietary, or otherwise private info= rmation.=0D=0A> > If you have received it in error, please notify the sende= r=0D=0A> > immediately and delete the original. Any unauthorized use of=0D= =0A> > this email is prohibited.=0D=0A> >=0D=0A----------------------------= --------------------------------------------=0D=0A> --=0D=0A> > -----------= -----------=0D=0A> > [mf2]=0D=0A>=20=0D=0A=0D=0A---------------------------= ---------------------------------------------------------------------=0D=0A= This message is for the designated recipient only and may=0D=0Acontain priv= ileged, proprietary, or otherwise private information. =20=0D=0AIf you have= received it in error, please notify the sender=0D=0Aimmediately and delete= the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jun 02 04:54:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuPNY-0001Ly-Ph; Sat, 02 Jun 2007 04:54:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuPNX-0001JL-Kv for ecrit@ietf.org; Sat, 02 Jun 2007 04:54:31 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HuPNV-00011P-6U for ecrit@ietf.org; Sat, 02 Jun 2007 04:54:31 -0400 Received: (qmail invoked by alias); 02 Jun 2007 08:54:28 -0000 Received: from p54984595.dip.t-dialin.net (EHLO [192.168.178.24]) [84.152.69.149] by mail.gmx.net (mp024) with SMTP; 02 Jun 2007 10:54:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19hJu9K8zdhWl3uUF5DOEbL6qoD9htDFIarO3hUoe 3IIO6oCFk1AJdi Message-ID: <46613043.3030801@gmx.net> Date: Sat, 02 Jun 2007 10:54:27 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [Ecrit] ECRIT WG Status Update (June 2007) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, We have been sleeping now for a month. Now it is time to start our work again. This write-up can also be found here: http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/EcritStatusUpdate There are essentially the following major items to talk about: * Working Group Items The requirements draft, the service URN draft and the security threats draft are in IESG processing and doing fine. LoST is essentially done (unless we want to add a new location profile to provide the location hiding aspect). The phone BCP, mapping architecture and the framework documents are impacted by the ongoing architecture discussions. We could finish these documents based on our current understanding of the architecture and work on documents covering the other aspects later (also since extensions are potentially outside the current charter). * Location Hiding This aspect has caused a lot of discussion and we have seen many, many solution proposals. At the end the group focused on a small number of them that can be found here: http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/LocationHiding To restart the discussion Henning and myself have written a short draft that can be found here: http://www.tschofenig.priv.at/twiki/pub/EmergencyServices/LocationHiding/draft-schulzrinne-ecrit-lost-in-held-00.txt We intentially did not publish the draft for the following reasons: * Many working group members have very actively contributed to the discussions and it would be unfair to publish the document with our names on it only. * There are many solutions and many variations of the solutions possible. We would like to avoid 15+ draft submissions to the working group since this would only slow down the progress. Given that more discussions are necessary I would suggest to finish LoST as is and then deal with this aspect as an extension. After the discussions progress sufficiently the chairs will pick some draft authors to compile a write-up of the discussion. * Unauthenticated Network Access This topic has not seen enough attention from the group. I have sent two mails about it in the past to raise a discussion. It seems that many SDOs develop solutions for the unauthenticated network access case, including IEEE, 3GPP, 3GPP2 and TISPAN. We believe we should also have a story for it. Since it will take some time to discuss these aspects it might be reasonable to decouple them from the current framework and phone BCP discussion. It is also not sure whether the regulator will demand support for it. * Liaisons and Interworking with other SDOs 3GPP: It would be good to figure out how to align our work with the 3GPP emergency architecture work, if possible. IEEE: We need reviewers for their documents: http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/ReviewIEEEDocuments A discussion about the open issues from the IETF ECRIT / IEEE Information Sharing Event @ IETF#68 is also needed. I will ping Stephen McCann about this issue. ATIS ESIF: We haven't responded to the ATIS ESIF document liaison request. The last two items need to be done in coorperation with the GEOPRIV working group. * Next SDO Emergency Services Workshop Planning for the next workshop will start soon. Status updates will be sent to this mailing list https://lists.cs.columbia.edu/cucslists/listinfo/es-coordination. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jun 02 05:02:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuPV0-00012u-Fx; Sat, 02 Jun 2007 05:02:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuPUz-00012m-US for ecrit@ietf.org; Sat, 02 Jun 2007 05:02:13 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HuPUz-0002Br-Gk for ecrit@ietf.org; Sat, 02 Jun 2007 05:02:13 -0400 Received: (qmail invoked by alias); 02 Jun 2007 09:02:12 -0000 Received: from p54984595.dip.t-dialin.net (EHLO [192.168.178.24]) [84.152.69.149] by mail.gmx.net (mp043) with SMTP; 02 Jun 2007 11:02:12 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19HBspBA0BHPkHQVen0rGtsYoXWJ7O+nU/7nMq8pM ok7tMhyhBTXJTH Message-ID: <46613214.5030202@gmx.net> Date: Sat, 02 Jun 2007 11:02:12 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Ecrit] Location Hiding: Let's Make some Progress X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, we have had many discussions about this topic but we did not come to a conclusion. At the end it seems to me that we have focused on a small number of potential solutions. They are listed at this Wiki page: http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/LocationHiding To restart the discussion Henning and myself have written a short draft about solution#3: http://www.tschofenig.priv.at/twiki/pub/EmergencyServices/LocationHiding/draft-schulzrinne-ecrit-lost-in-held-00.txt Solution#1 does not require too many extensions, only a new location profile in LoST to support polygons (from an extension point of view). We intentially did not publish the above-mentioned draft for the following reasons: * Many working group members have very actively contributed to the discussions and it would be unfair to publish the document with our names on it only. * There are many solutions and many variations of the solutions possible. We would like to avoid 15+ draft submissions to the working group since this would only slow down the progress. There is potentially an impact for LoST. Hence, it prevents us from finishing LoST. From a procedural point of view we can do two things: (1) Finish LoST as is and add potential extensions later. (2) Wait for the conclusion of the discussion on location hiding, potentially update LoST Today, I personally would lean towards (1) given that more discussions are necessary. I would, however, like to understand what other people think. I would also like to know what the solution preferences are. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jun 02 07:28:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuRma-0003xw-Eh; Sat, 02 Jun 2007 07:28:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuRmZ-0003xq-Ft for ecrit@ietf.org; Sat, 02 Jun 2007 07:28:31 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuRmY-0006iJ-3t for ecrit@ietf.org; Sat, 02 Jun 2007 07:28:31 -0400 X-SEF-Processed: 5_0_0_910__2007_06_02_06_35_51 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sat, 02 Jun 2007 06:35:51 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Jun 2007 06:28:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Location Hiding: Let's Make some Progress Date: Sat, 2 Jun 2007 06:28:20 -0500 Message-ID: In-Reply-To: <46613214.5030202@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Hiding: Let's Make some Progress Thread-Index: Acek9LerW7ff7lTSTMqTucd58RihxAAEUGkw References: <46613214.5030202@gmx.net> From: "Winterbottom, James" To: "Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 02 Jun 2007 11:28:24.0559 (UTC) FILETIME=[21E987F0:01C7A509] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I personally think that these two discussions are mutually exclusive,=0D=0A= with one problem residing in the geopriv space and the other in ecrit.=0D=0A=0D= =0AWhat an end-point needs to route is a service URN, a local dial string=0D= =0Aand/or PSAP URI. Location is a means to an end. That is, it allows=0D=0A= discovery the URI. If the URI is provided, then location isn't required=0D=0A= by the end-point. ECRIT's charter is to route calls to a PSAP. Providing=0D= =0Athe end-point can do that ecrit should be happy.=0D=0A=0D=0AHow an end-p= oint learns location is geopriv space. The blur seems to=0D=0Aoccur around = what happens if the location provider won't provide=0D=0Alocation directly = to the end-point.=20=0D=0A=0D=0AHaving read the draft below, it suggest tha= t changes to LoST are=0D=0Arequired if location is not provided to end-poin= ts. This is not=0D=0Anecessarily true. It is true certainly under certain b= usiness models,=0D=0Abut not true under others. Let us also be clear, locat= ion hiding is the=0D=0Aprerogative of the location provider, and providing = the end-point is=0D=0Aable to route an emergency call the location provider= 's obligation is=0D=0Amet. Changes to LoST are ONLY required, IF the voice = service provide=0D=0Arequires proof that the call is to an emergency URI. I= f this is not the=0D=0Acase, then NO CHANGES to LoST are required. This dra= ft does not point=0D=0Athis out. In fact it does not even consider it.=0D=0A=0D= =0AThe issue of destination URI based on location, and the issue of=0D=0Ade= stination URI and service are totally orthogonal and that neither are=0D=0A= directly in the realm of ECRIT.=0D=0A=0D=0AIf a location provider elects to= provide a list of location URIs, a=0D=0Aservice URNs and corresponding ser= vice URIs, and possibly dial strings,=0D=0Athen this is sufficient for the = end-point to launch an emergency call.=0D=0ASo it is a valid solution that = requires no changes to LoST.=0D=0A=0D=0AI think that the location hiding ca= se has several ways to skin the cat,=0D=0Aand I do not thing that supportin= g both solution 1 and 3 from an=0D=0Aend-point position is hard. On the oth= er hand restricting location=0D=0Aproviders to solution 1 only I think will= make location hiding difficult=0D=0Aand expensive to provide, which will r= esult in very non-consistent ways=0D=0Aof implementing it.=0D=0A=0D=0A=0D=0A= Cheers=0D=0AJames=20=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: H= annes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> Sent: Saturday, = 2 June 2007 7:02 PM=0D=0A> To: ECRIT=0D=0A> Subject: [Ecrit] Location Hidin= g: Let's Make some Progress=0D=0A>=20=0D=0A> Hi all,=0D=0A>=20=0D=0A> we ha= ve had many discussions about this topic but we did not come to a=0D=0A> co= nclusion.=0D=0A>=20=0D=0A> At the end it seems to me that we have focused o= n a small number of=0D=0A> potential solutions. They are listed at this Wik= i page:=0D=0A>=0D=0Ahttp://www.tschofenig.priv.at/twiki/bin/view/EmergencyServi= ces/LocationHidin=0D=0Ag=0D=0A>=20=0D=0A> To restart the discussion Henning= and myself have written a short=0D=0Adraft=0D=0A> about solution#3:=0D=0A>=0D= =0Ahttp://www.tschofenig.priv.at/twiki/pub/EmergencyServices/LocationHiding/dra=0D= =0Aft=0D=0A> -schulzrinne-ecrit-lost-in-held-00.txt=0D=0A>=20=0D=0A> Soluti= on#1 does not require too many extensions, only a new location=0D=0A> profi= le in LoST to support polygons (from an extension point of view).=0D=0A> =0D= =0A> We intentially did not publish the above-mentioned draft for the=0D=0A= > following reasons:=0D=0A> * Many working group members have very actively= contributed to the=0D=0A> discussions and it would be unfair to publish th= e document with our=0D=0A> names on it only.=0D=0A> * There are many soluti= ons and many variations of the solutions=0D=0A> possible. We would like to = avoid 15+ draft submissions to the working=0D=0A> group since this would on= ly slow down the progress.=0D=0A>=20=0D=0A> There is potentially an impact = for LoST. Hence, it prevents us from=0D=0A> finishing LoST.=0D=0A>=20=0D=0A= > From a procedural point of view we can do two things:=0D=0A>=20=0D=0A> (= 1) Finish LoST as is and add potential extensions later.=0D=0A> (2) Wait fo= r the conclusion of the discussion on location hiding,=0D=0A> potentially u= pdate LoST=0D=0A>=20=0D=0A> Today, I personally would lean towards (1) give= n that more discussions=0D=0A> are necessary.=0D=0A>=20=0D=0A> I would, how= ever, like to understand what other people think.=0D=0A>=20=0D=0A> I would = also like to know what the solution preferences are.=0D=0A>=20=0D=0A> Ciao=0D= =0A> Hannes=0D=0A>=20=0D=0A>=20=0D=0A> ____________________________________= ___________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://= www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A---------------------------= ---------------------------------------------------------------------=0D=0A= This message is for the designated recipient only and may=0D=0Acontain priv= ileged, proprietary, or otherwise private information. =20=0D=0AIf you have= received it in error, please notify the sender=0D=0Aimmediately and delete= the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jun 02 08:14:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuSV2-0004Fx-KK; Sat, 02 Jun 2007 08:14:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuSV0-0004Ff-Pm for ecrit@ietf.org; Sat, 02 Jun 2007 08:14:26 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HuSV0-0003rI-5C for ecrit@ietf.org; Sat, 02 Jun 2007 08:14:26 -0400 Received: (qmail invoked by alias); 02 Jun 2007 12:14:24 -0000 Received: from p54984595.dip.t-dialin.net (EHLO [192.168.178.24]) [84.152.69.149] by mail.gmx.net (mp023) with SMTP; 02 Jun 2007 14:14:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19XFh1Tf+lXXk1suKExcNd4R9mt9jm6D/pcv2t4oM h8KYLkg8VBKjSw Message-ID: <46615F20.1050103@gmx.net> Date: Sat, 02 Jun 2007 14:14:24 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Ecrit] Location Hiding: Let's Make some Progress References: <46613214.5030202@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi James, Winterbottom, James wrote: > I personally think that these two discussions are mutually exclusive, > with one problem residing in the geopriv space and the other in ecrit. > Which two discussions? > What an end-point needs to route is a service URN, a local dial string > and/or PSAP URI. It depends on the architecture whether this is true. > Location is a means to an end. That's not quite right since location is used in multiple places for the emergency services architecture. This again depends on the architecture. > That is, it allows > discovery the URI. If the URI is provided, then location isn't required > by the end-point. That's true. > ECRIT's charter is to route calls to a PSAP. Providing > the end-point can do that ecrit should be happy. > You understand that the entire story is a bit more complicated. > How an end-point learns location is geopriv space. The blur seems to > occur around what happens if the location provider won't provide > location directly to the end-point. > We all know that the boundary between different working groups regarding this subject is fuzzy. No problem > Having read the draft below, it suggest that changes to LoST are > required if location is not provided to end-points. No. That's not true. > This is not > necessarily true. It is true certainly under certain business models, > but not true under others. Let us also be clear, location hiding is the > prerogative of the location provider, and providing the end-point is > able to route an emergency call the location provider's obligation is > met. Changes to LoST are ONLY required, IF the voice service provide > requires proof that the call is to an emergency URI. There are no changes required in that case either. The VSP could use imprecise location information and use it as input to LoST > If this is not the > case, then NO CHANGES to LoST are required. This draft does not point > this out. In fact it does not even consider it. > I believe it does and we discussed this aspect already on the mailing list. Changes are required if we implement a reverse resolution mechanism into LoST. Nobody wanted todo that. > The issue of destination URI based on location, and the issue of > destination URI and service are totally orthogonal and that neither are > directly in the realm of ECRIT. > > If a location provider elects to provide a list of location URIs, a > service URNs and corresponding service URIs, and possibly dial strings, > then this is sufficient for the end-point to launch an emergency call. > So it is a valid solution that requires no changes to LoST. > > Why does it provide a list of location URIs? Still, this does not provide the entire picture since the VSP still has to ensure that this is really a PSAP URI.; > I think that the location hiding case has several ways to skin the cat, > and I do not thing that supporting both solution 1 and 3 from an > end-point position is hard. Having more solutions in an emergency case is not a great thing. > On the other hand restricting location > providers to solution 1 only I think will make location hiding difficult > and expensive to provide, which will result in very non-consistent ways > of implementing it. > I wonder why this is the case. Ciao Hannes > > Cheers > James > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Saturday, 2 June 2007 7:02 PM >> To: ECRIT >> Subject: [Ecrit] Location Hiding: Let's Make some Progress >> >> Hi all, >> >> we have had many discussions about this topic but we did not come to a >> conclusion. >> >> At the end it seems to me that we have focused on a small number of >> potential solutions. They are listed at this Wiki page: >> >> > http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/LocationHidin > g > >> To restart the discussion Henning and myself have written a short >> > draft > >> about solution#3: >> >> > http://www.tschofenig.priv.at/twiki/pub/EmergencyServices/LocationHiding/dra > ft > >> -schulzrinne-ecrit-lost-in-held-00.txt >> >> Solution#1 does not require too many extensions, only a new location >> profile in LoST to support polygons (from an extension point of view). >> >> We intentially did not publish the above-mentioned draft for the >> following reasons: >> * Many working group members have very actively contributed to the >> discussions and it would be unfair to publish the document with our >> names on it only. >> * There are many solutions and many variations of the solutions >> possible. We would like to avoid 15+ draft submissions to the working >> group since this would only slow down the progress. >> >> There is potentially an impact for LoST. Hence, it prevents us from >> finishing LoST. >> >> From a procedural point of view we can do two things: >> >> (1) Finish LoST as is and add potential extensions later. >> (2) Wait for the conclusion of the discussion on location hiding, >> potentially update LoST >> >> Today, I personally would lean towards (1) given that more discussions >> are necessary. >> >> I would, however, like to understand what other people think. >> >> I would also like to know what the solution preferences are. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jun 02 11:29:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuVXa-00005J-0V; Sat, 02 Jun 2007 11:29:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuVXY-000052-Jo for ecrit@ietf.org; Sat, 02 Jun 2007 11:29:16 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HuVXV-0004HA-UJ for ecrit@ietf.org; Sat, 02 Jun 2007 11:29:16 -0400 Received: (qmail invoked by alias); 02 Jun 2007 15:29:12 -0000 Received: from p54984595.dip.t-dialin.net (EHLO [192.168.178.24]) [84.152.69.149] by mail.gmx.net (mp044) with SMTP; 02 Jun 2007 17:29:12 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Hf+wxR5EHy8CpmKJHqTiV4kdBH5OPrXhCM2uSyP xPIAApV8T+7vhp Message-ID: <46618CC7.2050608@gmx.net> Date: Sat, 02 Jun 2007 17:29:11 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Ecrit] Location Hiding: Let's Make some Progress References: <46613214.5030202@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi James, I have to respond to you again about the architectural aspects. I think it is fair to say that a solution needs to consider the case where the VSP wants to verify whether the emergency call is indeed traveling towards a PSAP or not. Additionally, the VSP can never be sure whether all end hosts are able to obtain the PSAP URI (for whatever reason). For the case where the ISP/ASP is not the same as the VSP then all they have to assume is that they get location information in some form, either an LbyR or an LbyV. So, given this the VSP has to run LoST and there has to be a LoST mapping infrastructure otherwise the IETF ECRIT emergency service architecture just does not work. The end host might run LoST. If it does so, then there are benefits since the resolution step can be done ahead of time before the actual emergency call starts. With respect to the message exchanges shown in Figure 1 of http://www.tschofenig.priv.at/twiki/pub/EmergencyServices/LocationHiding/draft-schulzrinne-ecrit-lost-in-held-00.txt a few variations are possible but they do not change the entire picture a lot. For example, it is possible that the LCS provides LbyR and LbyV whereby the LbyV can only be used for routing. In that case the VSP does not need to get in contact with the ISP/ASP. It might also be possible that the VSP does not do the LoST verification step (for whatever reason). Step (4) could in that case omitted. If you additionally consider Figure 2 of the draft than you can have end hosts that do not need to obtain location information nor need to perform LoST queries. In fact that architecture even allows you to move all these functions into the ISP/ASP/VSP operators network and a standardized protocol for these interactions may not be needed. Was that description helpful? Ciao Hannes Winterbottom, James wrote: > I personally think that these two discussions are mutually exclusive, > with one problem residing in the geopriv space and the other in ecrit. > > What an end-point needs to route is a service URN, a local dial string > and/or PSAP URI. Location is a means to an end. That is, it allows > discovery the URI. If the URI is provided, then location isn't required > by the end-point. ECRIT's charter is to route calls to a PSAP. Providing > the end-point can do that ecrit should be happy. > > How an end-point learns location is geopriv space. The blur seems to > occur around what happens if the location provider won't provide > location directly to the end-point. > > Having read the draft below, it suggest that changes to LoST are > required if location is not provided to end-points. This is not > necessarily true. It is true certainly under certain business models, > but not true under others. Let us also be clear, location hiding is the > prerogative of the location provider, and providing the end-point is > able to route an emergency call the location provider's obligation is > met. Changes to LoST are ONLY required, IF the voice service provide > requires proof that the call is to an emergency URI. If this is not the > case, then NO CHANGES to LoST are required. This draft does not point > this out. In fact it does not even consider it. > > The issue of destination URI based on location, and the issue of > destination URI and service are totally orthogonal and that neither are > directly in the realm of ECRIT. > > If a location provider elects to provide a list of location URIs, a > service URNs and corresponding service URIs, and possibly dial strings, > then this is sufficient for the end-point to launch an emergency call. > So it is a valid solution that requires no changes to LoST. > > I think that the location hiding case has several ways to skin the cat, > and I do not thing that supporting both solution 1 and 3 from an > end-point position is hard. On the other hand restricting location > providers to solution 1 only I think will make location hiding difficult > and expensive to provide, which will result in very non-consistent ways > of implementing it. > > > Cheers > James > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Saturday, 2 June 2007 7:02 PM >> To: ECRIT >> Subject: [Ecrit] Location Hiding: Let's Make some Progress >> >> Hi all, >> >> we have had many discussions about this topic but we did not come to a >> conclusion. >> >> At the end it seems to me that we have focused on a small number of >> potential solutions. They are listed at this Wiki page: >> >> > http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/LocationHidin > g > >> To restart the discussion Henning and myself have written a short >> > draft > >> about solution#3: >> >> > http://www.tschofenig.priv.at/twiki/pub/EmergencyServices/LocationHiding/dra > ft > >> -schulzrinne-ecrit-lost-in-held-00.txt >> >> Solution#1 does not require too many extensions, only a new location >> profile in LoST to support polygons (from an extension point of view). >> >> We intentially did not publish the above-mentioned draft for the >> following reasons: >> * Many working group members have very actively contributed to the >> discussions and it would be unfair to publish the document with our >> names on it only. >> * There are many solutions and many variations of the solutions >> possible. We would like to avoid 15+ draft submissions to the working >> group since this would only slow down the progress. >> >> There is potentially an impact for LoST. Hence, it prevents us from >> finishing LoST. >> >> From a procedural point of view we can do two things: >> >> (1) Finish LoST as is and add potential extensions later. >> (2) Wait for the conclusion of the discussion on location hiding, >> potentially update LoST >> >> Today, I personally would lean towards (1) given that more discussions >> are necessary. >> >> I would, however, like to understand what other people think. >> >> I would also like to know what the solution preferences are. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jun 02 16:54:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huabp-0007u8-KM; Sat, 02 Jun 2007 16:54:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Huabo-0007ty-CZ for ecrit@ietf.org; Sat, 02 Jun 2007 16:54:00 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Huabn-000106-2K for ecrit@ietf.org; Sat, 02 Jun 2007 16:54:00 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 02 Jun 2007 13:53:58 -0700 X-IronPort-AV: i="4.16,376,1175497200"; d="scan'208"; a="158020606:sNHT46153026" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l52KrwnL005208; Sat, 2 Jun 2007 13:53:58 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l52Krw20006774; Sat, 2 Jun 2007 20:53:58 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Jun 2007 13:53:57 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.95.82]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Jun 2007 13:53:57 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 02 Jun 2007 15:53:56 -0500 To: Hannes Tschofenig , ECRIT From: "James M. Polk" Subject: Re: [Ecrit] Location Hiding: Let's Make some Progress In-Reply-To: <46613214.5030202@gmx.net> References: <46613214.5030202@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 02 Jun 2007 20:53:57.0743 (UTC) FILETIME=[23AA7FF0:01C7A558] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1586; t=1180817638; x=1181681638; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Location=20Hiding=3A=20Let's=20Make=20some= 20Progress |Sender:=20; bh=m92KpSQIRddczlBEJHvoLci47Mvyv0SijKqL5M/W7CE=; b=W7ZO+jkPgfJuEDrV0WIDovGRcbGqhrYRGDnByL/DeStZv8x/+6XYYAk6LVJLM/h4w4Wy+RrF QMRPUiQkvofUlW+K7qPKHTp0wmWdMA8Rm5mMFABqoYrHg6BYzwxjvBnV; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 04:02 AM 6/2/2007, Hannes Tschofenig wrote: >There is potentially an impact for LoST. Hence, it prevents us from >finishing LoST. > > From a procedural point of view we can do two things: > >(1) Finish LoST as is and add potential extensions later. Let's PLEASE finish LoST, and have location hiding left for a future extension - if there is WG consensus. This offers a very pragmatic (and realistic) approach in a number of ways: #1 - It finishes LoST #2 - see #1 (just kidding. well... not really ;-) #3 - It prevents someone in the future from stating in an RFP (most of us know that is, right?) that supporting LoST mandates support for Location Hiding. This will not be necessary in all cases. Some of us don't think it will be that popular in time; however, it could be. Allowing Location Hiding to the sole topic of a new ID (and eventually an RFC) gives the industry a singular pointer to vendors and SPs to support, without the ability to say they support "LoST" (even though they don't do the hiding part of that RFC (to-be)). #4 - #3 cannot be under-emphasized. An RFP stating full support for Location Hiding (for example, it's RFC 5201), cannot then be avoided, or fudged really. But stating full support for LoST (for example, RFC 5010) could have implementations do everything within the RFC except for the Hiding part. Don't laugh or smirk... this happens ALL THE TIME... Location Hiding, IMO, is a unique idea within ECRIT, therefore it should be it's own RFC - with no other unique ideas. James _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jun 02 20:34:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hue34-0003dF-4o; Sat, 02 Jun 2007 20:34:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hue32-0003dA-Lh for ecrit@ietf.org; Sat, 02 Jun 2007 20:34:20 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hue32-0005zv-CF for ecrit@ietf.org; Sat, 02 Jun 2007 20:34:20 -0400 X-SEF-Processed: 5_0_0_910__2007_06_02_19_41_45 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sat, 02 Jun 2007 19:41:45 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Jun 2007 19:34:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Location Hiding: Let's Make some Progress Date: Sat, 2 Jun 2007 19:34:15 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Hiding: Let's Make some Progress Thread-Index: AcelWCwx2QoCToMtQQqe57zimW5/PQAHlWog References: <46613214.5030202@gmx.net> From: "Winterbottom, James" To: "James M. Polk" , "Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 03 Jun 2007 00:34:17.0963 (UTC) FILETIME=[EB87FBB0:01C7A576] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi James,=0D=0A=0D=0AThe only thing I want in ECRIT to do with location hid= ing is for=0D=0Aphone-bcp to say that if the end-point gets give location U= RIs (one or=0D=0Amore), is given service URN to URI mappings that it can ju= st send to=0D=0Athose. I see no need to change LoST at this time, and possi= bly no tin=0D=0Athe future either.=0D=0A=0D=0AThe only case I have heard fo= r changing LoST is so that a VSP somewhere=0D=0Acan check whether to bill f= or a call or not. I don't think this is=0D=0Arequired for iteration one of = LoST and may never be required.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D= =0A=0D=0A> -----Original Message-----=0D=0A> From: James M. Polk [mailto:jm= polk@cisco.com]=0D=0A> Sent: Sunday, 3 June 2007 6:54 AM=0D=0A> To: Hannes = Tschofenig; ECRIT=0D=0A> Subject: Re: [Ecrit] Location Hiding: Let's Make s= ome Progress=0D=0A>=20=0D=0A> At 04:02 AM 6/2/2007, Hannes Tschofenig wrote= :=0D=0A> >There is potentially an impact for LoST. Hence, it prevents us fr= om=0D=0A> >finishing LoST.=0D=0A> >=0D=0A> > From a procedural point of vie= w we can do two things:=0D=0A> >=0D=0A> >(1) Finish LoST as is and add pote= ntial extensions later.=0D=0A>=20=0D=0A> Let's PLEASE finish LoST, and have= location hiding left for a future=0D=0A> extension - if there is WG consen= sus. This offers a very pragmatic=0D=0A> (and realistic) approach in a num= ber of ways:=0D=0A>=20=0D=0A> #1 - It finishes LoST=0D=0A>=20=0D=0A> #2 - s= ee #1=0D=0A>=20=0D=0A> (just kidding. well... not really ;-)=0D=0A>=20=0D= =0A> #3 - It prevents someone in the future from stating in an RFP (most=0D= =0A> of us know that is, right=3F) that supporting LoST mandates support fo= r=0D=0A> Location Hiding. This will not be necessary in all cases. Some of= us=0D=0A> don't think it will be that popular in time; however, it could=0D= =0A> be. Allowing Location Hiding to the sole topic of a new ID (and=0D=0A= > eventually an RFC) gives the industry a singular pointer to vendors=0D=0A= > and SPs to support, without the ability to say they support "LoST"=0D=0A>= (even though they don't do the hiding part of that RFC (to-be)).=0D=0A> =0D= =0A> #4 - #3 cannot be under-emphasized. An RFP stating full support for=0D= =0A> Location Hiding (for example, it's RFC 5201), cannot then be avoided,=0D= =0A> or fudged really. But stating full support for LoST (for example,=0D=0A= > RFC 5010) could have implementations do everything within the RFC=0D=0A> = except for the Hiding part. Don't laugh or smirk... this happens ALL=0D=0A= > THE TIME...=0D=0A>=20=0D=0A> Location Hiding, IMO, is a unique idea withi= n ECRIT, therefore it=0D=0A> should be it's own RFC - with no other unique = ideas.=0D=0A>=20=0D=0A> James=0D=0A>=20=0D=0A> ____________________________= ___________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> = https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A-------------------= ---------------------------------------------------------------------------= --=0D=0AThis message is for the designated recipient only and may=0D=0Acont= ain privileged, proprietary, or otherwise private information. =20=0D=0AIf = you have received it in error, please notify the sender=0D=0Aimmediately an= d delete the original. Any unauthorized use of=0D=0Athis email is prohibit= ed.=0D=0A------------------------------------------------------------------= ------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jun 03 22:15:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv26g-0001OV-Bx; Sun, 03 Jun 2007 22:15:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv26f-0001OL-BX for ecrit@ietf.org; Sun, 03 Jun 2007 22:15:41 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv26d-0004aT-Og for ecrit@ietf.org; Sun, 03 Jun 2007 22:15:41 -0400 X-SEF-Processed: 5_0_0_910__2007_06_03_21_23_04 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 03 Jun 2007 21:23:04 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 3 Jun 2007 21:15:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Location Hiding: Let's Make some Progress Date: Sun, 3 Jun 2007 21:15:32 -0500 Message-ID: In-Reply-To: <46615F20.1050103@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Hiding: Let's Make some Progress Thread-Index: AcelD5CElCiHTr4+RW6V+RAvw/e5lwBOichQ References: <46613214.5030202@gmx.net> <46615F20.1050103@gmx.net> From: "Winterbottom, James" To: "Hannes Tschofenig" X-OriginalArrivalTime: 04 Jun 2007 02:15:35.0082 (UTC) FILETIME=[3C3080A0:01C7A64E] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Hannes,=0D=0A=0D=0APlease see responses inline:=0D=0A=0D=0A=0D=0A> -----= Original Message-----=0D=0A> From: Hannes Tschofenig [mailto:Hannes.Tschofe= nig@gmx.net]=0D=0A> Sent: Saturday, 2 June 2007 10:14 PM=0D=0A> To: Winterb= ottom, James=0D=0A> Cc: ECRIT=0D=0A> Subject: Re: [Ecrit] Location Hiding: = Let's Make some Progress=0D=0A>=20=0D=0A> Hi James,=0D=0A>=20=0D=0A> Winter= bottom, James wrote:=0D=0A> > I personally think that these two discussions= are mutually=0D=0Aexclusive,=0D=0A> > with one problem residing in the geo= priv space and the other in=0D=0Aecrit.=0D=0A> >=0D=0A> Which two discussio= ns=3F=0D=0A>=20=0D=0A[AJW] There are two clear and distinct parts to soluti= on 3. The first=0D=0Apart consists of the end-point being able to obtain lo= cation URIs,=0D=0Aservice URNs and their corresponding service URIs, and po= ssibly matching=0D=0Adial strings. This functionality is required to enable= the end-point to=0D=0Amake an emergency call.=0D=0A=0D=0AThe second quite = different part is to do with how a VSP, no matter where=0D=0Ait is, is able= to tell that the call is destined for emergency services=0D=0AURI. And thi= s, as far as I can tell is done ONLY so that the VSP won't=0D=0Abill for th= e call. It is only this part that has bearing in ECRIT, how=0D=0Aan end-poi= nt obtains LI is out of scope for ECRIT.=0D=0A=0D=0A=0D=0A>=20=0D=0A> > Wha= t an end-point needs to route is a service URN, a local dial=0D=0Astring=0D= =0A> > and/or PSAP URI.=0D=0A>=20=0D=0A> It depends on the architecture whe= ther this is true.=0D=0A>=20=0D=0A=0D=0A[AJW] The end-point needs to have s= omething to send the call to, either=0D=0Aa URI or a dial string. Presumabl= y also the persona making the call=0D=0Aknows that they want a specific ser= vice, even if they don't know how=0D=0Athat specific service defined under = the covers.=20=0D=0A=0D=0A>=20=0D=0A> > Location is a means to an end.=0D=0A= >=20=0D=0A> That's not quite right since location is used in multiple place= s for=0D=0Athe=0D=0A> emergency services architecture. This again depends o= n the=0D=0Aarchitecture.=0D=0A>=0D=0A=0D=0A[AJW] My comment here is that lo= cation is that means by which an=0D=0Aend-point gets the service/help they = want. In and to itself, location is=0D=0Anot what the end-point wants.=0D=0A= =20=0D=0A>=20=0D=0A> > That is, it allows=0D=0A> > discovery the URI. If t= he URI is provided, then location isn't=0D=0Arequired=0D=0A> > by the end-p= oint.=0D=0A> That's true.=0D=0A>=20=0D=0A> > ECRIT's charter is to route c= alls to a PSAP. Providing=0D=0A> > the end-point can do that ecrit should b= e happy.=0D=0A> >=0D=0A>=20=0D=0A> You understand that the entire story is = a bit more complicated.=0D=0A>=0D=0A=0D=0A[AJW] I do, but I want the scopes= kept clear. If ECRIT needs work added=0D=0Ato Georpiv then I would prefer = that it does that, rather than expanding=0D=0Athe ECRIT scope. If location = providers don't provide a literal location=0D=0A(obscured or otherwise) to = the end-point, and this impacts ECRIT, then=0D=0AECRIT need to ask georpiv = to address this issue.=0D=0A=20=0D=0A> > How an end-point learns location i= s geopriv space. The blur seems to=0D=0A> > occur around what happens if th= e location provider won't provide=0D=0A> > location directly to the end-poi= nt.=0D=0A> >=0D=0A> We all know that the boundary between different working= groups=0D=0Aregarding=0D=0A> this subject is fuzzy.=0D=0A> No problem=0D=0A= >=0D=0A=0D=0A[AJW] See previous comment, I think that it can be unfuzzed a = bit.=0D=0A=20=0D=0A> > Having read the draft below, it suggest that changes= to LoST are=0D=0A> > required if location is not provided to end-points.=0D= =0A> No. That's not true.=0D=0A>=20=0D=0A> > This is not=0D=0A> > necessar= ily true. It is true certainly under certain business=0D=0Amodels,=0D=0A> >= but not true under others. Let us also be clear, location hiding is=0D=0At= he=0D=0A> > prerogative of the location provider, and providing the end-poi= nt is=0D=0A> > able to route an emergency call the location provider's obli= gation=0D=0Ais=0D=0A> > met. Changes to LoST are ONLY required, IF the voic= e service provide=0D=0A> > requires proof that the call is to an emergency = URI.=0D=0A> There are no changes required in that case either. The VSP coul= d use=0D=0A> imprecise location information and use it as input to LoST=0D=0A= >=20=0D=0A> > If this is not the=0D=0A> > case, then NO CHANGES to LoST ar= e required. This draft does not=0D=0Apoint=0D=0A> > this out. In fact it do= es not even consider it.=0D=0A> >=0D=0A> I believe it does and we discussed= this aspect already on the mailing=0D=0A> list.=0D=0A> Changes are require= d if we implement a reverse resolution mechanism=0D=0Ainto=0D=0A> LoST. Nob= ody wanted todo that.=0D=0A=0D=0A[AJW] My point is that we only have to do = this if the VSP billing is an=0D=0Aissue. Looking at two prominent Internet= VSPs this to me seems like a=0D=0Aridiculous requirement. Many of these ar= e providing international call=0D=0Arates of like 1 cent per minute for bet= ween $17 and $25 a month, with=0D=0Afree national calls, and some internati= onal calls also free. I think=0D=0Athat this billing issue is almost not an= issue, and so I see little need=0D=0Afor the proposed changes to LoST, mak= ing the problem totally in the=0D=0Alocation acquisition space.=0D=0A=0D=0A= >=20=0D=0A> > The issue of destination URI based on location, and the issue= of=0D=0A> > destination URI and service are totally orthogonal and that ne= ither=0D=0Aare=0D=0A> > directly in the realm of ECRIT.=0D=0A> >=0D=0A> > I= f a location provider elects to provide a list of location URIs, a=0D=0A> >= service URNs and corresponding service URIs, and possibly dial=0D=0Astring= s,=0D=0A> > then this is sufficient for the end-point to launch an emergenc= y=0D=0Acall.=0D=0A> > So it is a valid solution that requires no changes to= LoST.=0D=0A> >=0D=0A> >=0D=0A> Why does it provide a list of location URIs= =3F=0D=0A>=0D=0A=0D=0A[AJW] It provides a list of location URIs as the LIS = may support more=0D=0Athan one URI scheme for dereferencing. See=0D=0Ahttp:= //tools.ietf.org/html/draft-winterbottom-http-location-delivery-05=0D=0Asec= tion 5.10.1=0D=0A=0D=0A=20=0D=0A> Still, this does not provide the entire p= icture since the VSP still=0D=0Ahas=0D=0A> to ensure that this is really a = PSAP URI.;=0D=0A>=0D=0A[AJW] Only for billing purposes. There are several o= ther ways to skin=0D=0Athis cat. The first is to just bill anyway, at 1c a = minute I am not=0D=0Areally going to care if I am bleeding on the floor, an= d if I care later=0D=0AI can debate the charge with my VSP. The second is f= or the VSP to simply=0D=0Acharge a single flat monthly fee rather than have= any per-call charging.=0D=0AThere are probably several others that can be = thought up by more=0D=0Acreative minds in this area than my own.=0D=0A=0D=0A= =20=0D=0A> > I think that the location hiding case has several ways to skin= the=0D=0Acat,=0D=0A> > and I do not thing that supporting both solution 1 = and 3 from an=0D=0A> > end-point position is hard.=0D=0A> Having more solut= ions in an emergency case is not a great thing.=0D=0A>=20=0D=0A[AJW] I gene= rally agree, though this solution is actually very simple.=0D=0A=0D=0A> > = On the other hand restricting location=0D=0A> > providers to solution 1 onl= y I think will make location hiding=0D=0Adifficult=0D=0A> > and expensive t= o provide, which will result in very non-consistent=0D=0Aways=0D=0A> > of i= mplementing it.=0D=0A> >=0D=0A> I wonder why this is the case.=0D=0A=0D=0A[= AJW] I seriously think that you need to look at what solution 1 is=0D=0Apro= posing from a deployment standpoint. We are not talking about small=0D=0Asy= stems with say a couple of thousand users, we are talking single=0D=0Asyste= ms with several million users. Requiring polygon boundary mappings=0D=0Aper= location request is going to be very expensive. I simply don't=0D=0Abeliev= e that a civic solution is even possible (community name won't=0D=0Awork in= a huge many places) in many cases.=0D=0A=0D=0A=0D=0A[AJW] My proposal to m= ove this forward would be:=0D=0A1) Leave LoST as it is.=0D=0A2) Adapt Phone= BCP to say something along the lines of if the end-point=0D=0Ais provided = location URIs and routing data, send the call. A motherhood=0D=0Astatement = to the effect that it should request updated information at=0D=0Acall time = is fine.=0D=0A3) Ask Geopriv to pick up the extra piece required in HELD.=0D= =0A=0D=0A>=20=0D=0A> Ciao=0D=0A> Hannes=0D=0A>=20=0D=0A> >=0D=0A> > Cheers=0D= =0A> > James=0D=0A> >=0D=0A> >=0D=0A> >> -----Original Message-----=0D=0A> = >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> >> Sen= t: Saturday, 2 June 2007 7:02 PM=0D=0A> >> To: ECRIT=0D=0A> >> Subject: [Ec= rit] Location Hiding: Let's Make some Progress=0D=0A> >>=0D=0A> >> Hi all,=0D= =0A> >>=0D=0A> >> we have had many discussions about this topic but we did = not come=0D=0Ato a=0D=0A> >> conclusion.=0D=0A> >>=0D=0A> >> At the end it = seems to me that we have focused on a small number of=0D=0A> >> potential s= olutions. They are listed at this Wiki page:=0D=0A> >>=0D=0A> >>=0D=0A> >=0D= =0Ahttp://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/LocationHidin=0D= =0A> > g=0D=0A> >=0D=0A> >> To restart the discussion Henning and myself ha= ve written a short=0D=0A> >>=0D=0A> > draft=0D=0A> >=0D=0A> >> about soluti= on#3:=0D=0A> >>=0D=0A> >>=0D=0A> >=0D=0Ahttp://www.tschofenig.priv.at/twiki/pub= /EmergencyServices/LocationHiding/dra=0D=0A> > ft=0D=0A> >=0D=0A> >> -schul= zrinne-ecrit-lost-in-held-00.txt=0D=0A> >>=0D=0A> >> Solution#1 does not re= quire too many extensions, only a new=0D=0Alocation=0D=0A> >> profile in Lo= ST to support polygons (from an extension point of=0D=0Aview).=0D=0A> >>=0D= =0A> >> We intentially did not publish the above-mentioned draft for the=0D= =0A> >> following reasons:=0D=0A> >> * Many working group members have very= actively contributed to the=0D=0A> >> discussions and it would be unfair t= o publish the document with our=0D=0A> >> names on it only.=0D=0A> >> * The= re are many solutions and many variations of the solutions=0D=0A> >> possib= le. We would like to avoid 15+ draft submissions to the=0D=0Aworking=0D=0A>= >> group since this would only slow down the progress.=0D=0A> >>=0D=0A> >>= There is potentially an impact for LoST. Hence, it prevents us from=0D=0A>= >> finishing LoST.=0D=0A> >>=0D=0A> >> From a procedural point of view we= can do two things:=0D=0A> >>=0D=0A> >> (1) Finish LoST as is and add poten= tial extensions later.=0D=0A> >> (2) Wait for the conclusion of the discuss= ion on location hiding,=0D=0A> >> potentially update LoST=0D=0A> >>=0D=0A> = >> Today, I personally would lean towards (1) given that more=0D=0Adiscussi= ons=0D=0A> >> are necessary.=0D=0A> >>=0D=0A> >> I would, however, like to = understand what other people think.=0D=0A> >>=0D=0A> >> I would also like t= o know what the solution preferences are.=0D=0A> >>=0D=0A> >> Ciao=0D=0A> >= > Hannes=0D=0A> >>=0D=0A> >>=0D=0A> >> ____________________________________= ___________=0D=0A> >> Ecrit mailing list=0D=0A> >> Ecrit@ietf.org=0D=0A> >>= https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> >>=0D=0A> >=0D=0A> >=0D= =0A------------------------------------------------------------------------=0D= =0A> ------------------------=0D=0A> > This message is for the designated r= ecipient only and may=0D=0A> > contain privileged, proprietary, or otherwis= e private information.=0D=0A> > If you have received it in error, please no= tify the sender=0D=0A> > immediately and delete the original. Any unauthor= ized use of=0D=0A> > this email is prohibited.=0D=0A> >=0D=0A--------------= ----------------------------------------------------------=0D=0A> ---------= ---------------=0D=0A> > [mf2]=0D=0A> >=0D=0A> >=0D=0A>=20=0D=0A=0D=0A-----= ---------------------------------------------------------------------------= ----------------=0D=0AThis message is for the designated recipient only and= may=0D=0Acontain privileged, proprietary, or otherwise private information= =2E =20=0D=0AIf you have received it in error, please notify the sender=0D=0A= immediately and delete the original. Any unauthorized use of=0D=0Athis ema= il is prohibited.=0D=0A----------------------------------------------------= --------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jun 03 22:29:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv2KK-0006z5-3Z; Sun, 03 Jun 2007 22:29:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv2KJ-0006z0-GO for ecrit@ietf.org; Sun, 03 Jun 2007 22:29:47 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv2KI-0006Om-4V for ecrit@ietf.org; Sun, 03 Jun 2007 22:29:47 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1Hv2Ha-0001Tk-UU; Sun, 03 Jun 2007 21:27:01 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'James M. Polk'" , "'Hannes Tschofenig'" , "'ECRIT'" References: <46613214.5030202@gmx.net> Subject: RE: [Ecrit] Location Hiding: Let's Make some Progress Date: Sun, 3 Jun 2007 22:29:29 -0400 Message-ID: <11ca01c7a650$352a5630$6601a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcelWCwx2QoCToMtQQqe57zimW5/PQAHlWogADZgZsA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Solution 1 does not require changing anything in LoST, but needs some "BCP" words. Solution 3 doesn't require a change in LoST, but does require "changes" in LCP. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Saturday, June 02, 2007 8:34 PM > To: James M. Polk; Hannes Tschofenig; ECRIT > Subject: RE: [Ecrit] Location Hiding: Let's Make some Progress > > Hi James, > > The only thing I want in ECRIT to do with location hiding is for > phone-bcp to say that if the end-point gets give location URIs (one or > more), is given service URN to URI mappings that it can just send to > those. I see no need to change LoST at this time, and possibly no tin > the future either. > > The only case I have heard for changing LoST is so that a VSP somewhere > can check whether to bill for a call or not. I don't think this is > required for iteration one of LoST and may never be required. > > Cheers > James > > > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Sunday, 3 June 2007 6:54 AM > > To: Hannes Tschofenig; ECRIT > > Subject: Re: [Ecrit] Location Hiding: Let's Make some Progress > > > > At 04:02 AM 6/2/2007, Hannes Tschofenig wrote: > > >There is potentially an impact for LoST. Hence, it prevents us from > > >finishing LoST. > > > > > > From a procedural point of view we can do two things: > > > > > >(1) Finish LoST as is and add potential extensions later. > > > > Let's PLEASE finish LoST, and have location hiding left for a future > > extension - if there is WG consensus. This offers a very pragmatic > > (and realistic) approach in a number of ways: > > > > #1 - It finishes LoST > > > > #2 - see #1 > > > > (just kidding. well... not really ;-) > > > > #3 - It prevents someone in the future from stating in an RFP (most > > of us know that is, right?) that supporting LoST mandates support for > > Location Hiding. This will not be necessary in all cases. Some of us > > don't think it will be that popular in time; however, it could > > be. Allowing Location Hiding to the sole topic of a new ID (and > > eventually an RFC) gives the industry a singular pointer to vendors > > and SPs to support, without the ability to say they support "LoST" > > (even though they don't do the hiding part of that RFC (to-be)). > > > > #4 - #3 cannot be under-emphasized. An RFP stating full support for > > Location Hiding (for example, it's RFC 5201), cannot then be avoided, > > or fudged really. But stating full support for LoST (for example, > > RFC 5010) could have implementations do everything within the RFC > > except for the Hiding part. Don't laugh or smirk... this happens ALL > > THE TIME... > > > > Location Hiding, IMO, is a unique idea within ECRIT, therefore it > > should be it's own RFC - with no other unique ideas. > > > > James > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jun 03 23:20:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv37f-0004iu-Qn; Sun, 03 Jun 2007 23:20:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv37f-0004ip-G3 for ecrit@ietf.org; Sun, 03 Jun 2007 23:20:47 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv37f-0003wj-4g for ecrit@ietf.org; Sun, 03 Jun 2007 23:20:47 -0400 X-SEF-Processed: 5_0_0_910__2007_06_03_22_28_13 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 03 Jun 2007 22:28:13 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 3 Jun 2007 22:20:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Location Hiding: Let's Make some Progress Date: Sun, 3 Jun 2007 22:20:41 -0500 Message-ID: In-Reply-To: <11ca01c7a650$352a5630$6601a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Hiding: Let's Make some Progress Thread-Index: AcelWCwx2QoCToMtQQqe57zimW5/PQAHlWogADZgZsAAAc//AA== References: <46613214.5030202@gmx.net> <11ca01c7a650$352a5630$6601a8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "James M. Polk" , "Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 04 Jun 2007 03:20:44.0127 (UTC) FILETIME=[56296EF0:01C7A657] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Please see my not below with regards the operational cost so solution 1.=0D= =0AThey will be almost prohibitive!=0D=0A=0D=0A=0D=0A> -----Original Messag= e-----=0D=0A> From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> Sent: Mon= day, 4 June 2007 12:29 PM=0D=0A> To: Winterbottom, James; 'James M. Polk'; = 'Hannes Tschofenig'; 'ECRIT'=0D=0A> Subject: RE: [Ecrit] Location Hiding: L= et's Make some Progress=0D=0A>=20=0D=0A> Solution 1 does not require changi= ng anything in LoST, but needs some=0D=0A> "BCP"=0D=0A> words.=0D=0A>=20=0D= =0A> Solution 3 doesn't require a change in LoST, but does require=0D=0A"ch= anges" in=0D=0A> LCP.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A> > -----Origin= al Message-----=0D=0A> > From: Winterbottom, James [mailto:James.Winterbott= om@andrew.com]=0D=0A> > Sent: Saturday, June 02, 2007 8:34 PM=0D=0A> > To: = James M. Polk; Hannes Tschofenig; ECRIT=0D=0A> > Subject: RE: [Ecrit] Locat= ion Hiding: Let's Make some Progress=0D=0A> >=0D=0A> > Hi James,=0D=0A> >=0D= =0A> > The only thing I want in ECRIT to do with location hiding is for=0D=0A= > > phone-bcp to say that if the end-point gets give location URIs (one=0D=0A= or=0D=0A> > more), is given service URN to URI mappings that it can just se= nd to=0D=0A> > those. I see no need to change LoST at this time, and possib= ly no=0D=0Atin=0D=0A> > the future either.=0D=0A> >=0D=0A> > The only case = I have heard for changing LoST is so that a VSP=0D=0Asomewhere=0D=0A> > can= check whether to bill for a call or not. I don't think this is=0D=0A> > re= quired for iteration one of LoST and may never be required.=0D=0A> >=0D=0A>= > Cheers=0D=0A> > James=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> > > -----Origina= l Message-----=0D=0A> > > From: James M. Polk [mailto:jmpolk@cisco.com]=0D=0A= > > > Sent: Sunday, 3 June 2007 6:54 AM=0D=0A> > > To: Hannes Tschofenig; E= CRIT=0D=0A> > > Subject: Re: [Ecrit] Location Hiding: Let's Make some Progr= ess=0D=0A> > >=0D=0A> > > At 04:02 AM 6/2/2007, Hannes Tschofenig wrote:=0D= =0A> > > >There is potentially an impact for LoST. Hence, it prevents us=0D= =0Afrom=0D=0A> > > >finishing LoST.=0D=0A> > > >=0D=0A> > > > From a proced= ural point of view we can do two things:=0D=0A> > > >=0D=0A> > > >(1) Finis= h LoST as is and add potential extensions later.=0D=0A> > >=0D=0A> > > Let'= s PLEASE finish LoST, and have location hiding left for a=0D=0Afuture=0D=0A= > > > extension - if there is WG consensus. This offers a very=0D=0Apragma= tic=0D=0A> > > (and realistic) approach in a number of ways:=0D=0A> > >=0D=0A= > > > #1 - It finishes LoST=0D=0A> > >=0D=0A> > > #2 - see #1=0D=0A> > >=0D= =0A> > > (just kidding. well... not really ;-)=0D=0A> > >=0D=0A> > > #3 -= It prevents someone in the future from stating in an RFP=0D=0A(most=0D=0A>= > > of us know that is, right=3F) that supporting LoST mandates support=0D= =0Afor=0D=0A> > > Location Hiding. This will not be necessary in all cases= =2E Some of=0D=0Aus=0D=0A> > > don't think it will be that popular in time;= however, it could=0D=0A> > > be. Allowing Location Hiding to the sole top= ic of a new ID (and=0D=0A> > > eventually an RFC) gives the industry a sing= ular pointer to=0D=0Avendors=0D=0A> > > and SPs to support, without the abi= lity to say they support "LoST"=0D=0A> > > (even though they don't do the h= iding part of that RFC (to-be)).=0D=0A> > >=0D=0A> > > #4 - #3 cannot be un= der-emphasized. An RFP stating full support=0D=0Afor=0D=0A> > > Location H= iding (for example, it's RFC 5201), cannot then be=0D=0Aavoided,=0D=0A> > >= or fudged really. But stating full support for LoST (for example,=0D=0A> = > > RFC 5010) could have implementations do everything within the RFC=0D=0A= > > > except for the Hiding part. Don't laugh or smirk... this happens=0D=0A= ALL=0D=0A> > > THE TIME...=0D=0A> > >=0D=0A> > > Location Hiding, IMO, is a= unique idea within ECRIT, therefore it=0D=0A> > > should be it's own RFC -= with no other unique ideas.=0D=0A> > >=0D=0A> > > James=0D=0A> > >=0D=0A> = > > _______________________________________________=0D=0A> > > Ecrit mailin= g list=0D=0A> > > Ecrit@ietf.org=0D=0A> > > https://www1.ietf.org/mailman/l= istinfo/ecrit=0D=0A> >=0D=0A> >=0D=0A--------------------------------------= ----------------------------------=0D=0A> --=0D=0A> > ---------------------= -=0D=0A> > This message is for the designated recipient only and may=0D=0A>= > contain privileged, proprietary, or otherwise private information.=0D=0A= > > If you have received it in error, please notify the sender=0D=0A> > imm= ediately and delete the original. Any unauthorized use of=0D=0A> > this em= ail is prohibited.=0D=0A> >=0D=0A------------------------------------------= ------------------------------=0D=0A> --=0D=0A> > ----------------------=0D= =0A> > [mf2]=0D=0A> >=0D=0A> >=0D=0A> > ___________________________________= ____________=0D=0A> > Ecrit mailing list=0D=0A> > Ecrit@ietf.org=0D=0A> > h= ttps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A=0D=0A----------= ---------------------------------------------------------------------------= -----------=0D=0AThis message is for the designated recipient only and may=0D= =0Acontain privileged, proprietary, or otherwise private information. =20=0D= =0AIf you have received it in error, please notify the sender=0D=0Aimmediat= ely and delete the original. Any unauthorized use of=0D=0Athis email is pr= ohibited.=0D=0A------------------------------------------------------------= ------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jun 03 23:31:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv3Hz-0005WY-NS; Sun, 03 Jun 2007 23:31:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv3Hx-0005WQ-QI for ecrit@ietf.org; Sun, 03 Jun 2007 23:31:25 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv3Hw-00068c-Jx for ecrit@ietf.org; Sun, 03 Jun 2007 23:31:25 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sun, 03 Jun 2007 23:31:24 -0400 id 0158802D.4663878C.00005DFF In-Reply-To: <11ca01c7a650$352a5630$6601a8c0@cis.neustar.com> References: <46613214.5030202@gmx.net> <11ca01c7a650$352a5630$6601a8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Location Hiding: Let's Make some Progress Date: Sun, 3 Jun 2007 23:31:21 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 3, 2007, at 10:29 PM, Brian Rosen wrote: > Solution 1 does not require changing anything in LoST, but needs > some "BCP" > words. Actually, it does. But as Henning pointed out, it is a change that was requested for other reasons as well. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 04 05:40:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv939-0000az-Ak; Mon, 04 Jun 2007 05:40:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv937-0000an-Ou for ecrit@ietf.org; Mon, 04 Jun 2007 05:40:29 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hv936-00051n-CE for ecrit@ietf.org; Mon, 04 Jun 2007 05:40:29 -0400 Received: (qmail invoked by alias); 04 Jun 2007 09:40:27 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp027) with SMTP; 04 Jun 2007 11:40:27 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Pav1apjkPrhioANz2ZnjokLHA2nIp3hIArJZi2Y 0z4w/5DHgMT07z Message-ID: <4663DE0A.1050409@gmx.net> Date: Mon, 04 Jun 2007 11:40:26 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ecrit] Location Hiding - another look X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, with location hiding we assumed that the network operator does not want to provide information about the precise location information to the end point. A lot of discussions focused on the question how it can still obtain a PSAP URI in that case. There is, however, the question why the end point needs to obtain this PSAP URI in the location hiding case at all. Why cannot we just assume that the VSP has to obtain some location information from the ASP/ISP via LbyR and then it runs a LoST query as we specified it. DONE Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 04 05:57:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv9JT-0000dV-97; Mon, 04 Jun 2007 05:57:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv9JS-0000dP-Ly for ecrit@ietf.org; Mon, 04 Jun 2007 05:57:22 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv9JL-000742-9F for ecrit@ietf.org; Mon, 04 Jun 2007 05:57:22 -0400 X-SEF-Processed: 5_0_0_910__2007_06_04_05_04_42 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 04 Jun 2007 05:04:42 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Jun 2007 04:57:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Location Hiding - another look Date: Mon, 4 Jun 2007 04:57:10 -0500 Message-ID: In-Reply-To: <4663DE0A.1050409@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Hiding - another look Thread-Index: AcemjGijW5iv9Gq7S2qFAjPkkJbH/QAAfHlA References: <4663DE0A.1050409@gmx.net> From: "Winterbottom, James" To: "Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 04 Jun 2007 09:57:12.0767 (UTC) FILETIME=[B94BD4F0:01C7A68E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Hannes,=0D=0A=0D=0AI would prefer not to have an association between the= VSP and ISP/ASP if=0D=0Awe don't need to. If the end-point can obtain the = PSAP URI or the ESRP=0D=0AUri then the relationship between VSP and ISP doe= sn't need to exist. The=0D=0Arelationship is between the ISP/ASP and the lo= cal PSAP.=20=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A> -----Original = Message-----=0D=0A> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.n= et]=0D=0A> Sent: Monday, 4 June 2007 7:40 PM=0D=0A> To: ECRIT=0D=0A> Subjec= t: [Ecrit] Location Hiding - another look=0D=0A>=20=0D=0A> Hi all,=0D=0A> =0D= =0A> with location hiding we assumed that the network operator does not=0D=0A= want=0D=0A> to provide information about the precise location information t= o the=0D=0Aend=0D=0A> point.=0D=0A> A lot of discussions focused on the que= stion how it can still obtain a=0D=0A> PSAP URI in that case.=0D=0A>=20=0D=0A= > There is, however, the question why the end point needs to obtain this=0D= =0A> PSAP URI in the location hiding case at all.=0D=0A> Why cannot we just= assume that the VSP has to obtain some location=0D=0A> information from th= e ASP/ISP via LbyR and then it runs a LoST query as=0D=0A> we specified it.=0D= =0A>=20=0D=0A> DONE=0D=0A>=20=0D=0A> Ciao=0D=0A> Hannes=0D=0A>=20=0D=0A> =0D= =0A> _______________________________________________=0D=0A> Ecrit mailing l= ist=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/ecr= it=0D=0A=0D=0A-------------------------------------------------------------= -----------------------------------=0D=0AThis message is for the designated= recipient only and may=0D=0Acontain privileged, proprietary, or otherwise = private information. =20=0D=0AIf you have received it in error, please noti= fy the sender=0D=0Aimmediately and delete the original. Any unauthorized u= se of=0D=0Athis email is prohibited.=0D=0A---------------------------------= ---------------------------------------------------------------=0D=0A[mf2]=0D= =0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 04 06:01:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv9N0-0006iK-2G; Mon, 04 Jun 2007 06:01:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv9My-0006iD-PN for ecrit@ietf.org; Mon, 04 Jun 2007 06:01:00 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hv9My-0007PU-Ay for ecrit@ietf.org; Mon, 04 Jun 2007 06:01:00 -0400 Received: (qmail invoked by alias); 04 Jun 2007 10:00:59 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp001) with SMTP; 04 Jun 2007 12:00:59 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18rh4cAtmArC8gr3zLFCJA7fn1SBX7C5MdI4z6lfn Zl7lBPUlA9q0cf Message-ID: <4663E2DB.6080804@gmx.net> Date: Mon, 04 Jun 2007 12:00:59 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Ecrit] Location Hiding - another look References: <4663DE0A.1050409@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi James, what relationship do you mean? Is it because of the ability to obtain location information by the VSP such that call routing can take place? Didn't we discuss the ability of the ASP/ISP to differentiate a request and to return precise location only for authorized nodes where as unauthorized nodes would only obtain location information that is sufficient for emergency call routing. Ciao Hannes Winterbottom, James wrote: > Hi Hannes, > > I would prefer not to have an association between the VSP and ISP/ASP if > we don't need to. If the end-point can obtain the PSAP URI or the ESRP > Uri then the relationship between VSP and ISP doesn't need to exist. The > relationship is between the ISP/ASP and the local PSAP. > > Cheers > James > > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Monday, 4 June 2007 7:40 PM >> To: ECRIT >> Subject: [Ecrit] Location Hiding - another look >> >> Hi all, >> >> with location hiding we assumed that the network operator does not >> > want > >> to provide information about the precise location information to the >> > end > >> point. >> A lot of discussions focused on the question how it can still obtain a >> PSAP URI in that case. >> >> There is, however, the question why the end point needs to obtain this >> PSAP URI in the location hiding case at all. >> Why cannot we just assume that the VSP has to obtain some location >> information from the ASP/ISP via LbyR and then it runs a LoST query as >> we specified it. >> >> DONE >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 04 06:05:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv9RF-0003p0-G5; Mon, 04 Jun 2007 06:05:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv9RD-0003nh-SQ for ecrit@ietf.org; Mon, 04 Jun 2007 06:05:23 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv9RD-0007kt-Ib for ecrit@ietf.org; Mon, 04 Jun 2007 06:05:23 -0400 X-SEF-Processed: 5_0_0_910__2007_06_04_05_12_52 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 04 Jun 2007 05:12:52 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Jun 2007 05:05:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Location Hiding - another look Date: Mon, 4 Jun 2007 05:05:21 -0500 Message-ID: In-Reply-To: <4663E2DB.6080804@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Hiding - another look Thread-Index: Acemj0GFJ8uBVz+kS2+URdYt6X76rgAAEbsA References: <4663DE0A.1050409@gmx.net> <4663E2DB.6080804@gmx.net> From: "Winterbottom, James" To: "Hannes Tschofenig" X-OriginalArrivalTime: 04 Jun 2007 10:05:23.0102 (UTC) FILETIME=[DD8F03E0:01C7A68F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Hannes,=0D=0A=0D=0AKind of.=0D=0AA LIS that is providing location inform= ation in a local area is far more=0D=0Alikely to have a relationship with a= local emergency authority and be=0D=0Aable to determine that they are enti= tled to location information, than=0D=0Ait is to be able to determine that = a VSP in Sierra Leone is entitled to=0D=0Alocation information. To me there= is a very sizeable difference in these=0D=0Aapproaches.=0D=0A=0D=0AHope th= is helps=0D=0A=0D=0AJames=0D=0A=0D=0A> -----Original Message-----=0D=0A> Fr= om: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> Sent: Monda= y, 4 June 2007 8:01 PM=0D=0A> To: Winterbottom, James=0D=0A> Cc: ECRIT=0D=0A= > Subject: Re: [Ecrit] Location Hiding - another look=0D=0A>=20=0D=0A> Hi J= ames,=0D=0A>=20=0D=0A> what relationship do you mean=3F=0D=0A> Is it becaus= e of the ability to obtain location information by the VSP=0D=0A> such that= call routing can take place=3F=0D=0A> Didn't we discuss the ability of the= ASP/ISP to differentiate a=0D=0Arequest=0D=0A> and to return precise locat= ion only for authorized nodes where as=0D=0A> unauthorized nodes would only= obtain location information that is=0D=0A> sufficient for emergency call r= outing.=0D=0A>=20=0D=0A> Ciao=0D=0A> Hannes=0D=0A>=20=0D=0A> Winterbottom, = James wrote:=0D=0A> > Hi Hannes,=0D=0A> >=0D=0A> > I would prefer not to ha= ve an association between the VSP and=0D=0AISP/ASP if=0D=0A> > we don't nee= d to. If the end-point can obtain the PSAP URI or the=0D=0AESRP=0D=0A> > Ur= i then the relationship between VSP and ISP doesn't need to exist.=0D=0AThe=0D= =0A> > relationship is between the ISP/ASP and the local PSAP.=0D=0A> >=0D=0A= > > Cheers=0D=0A> > James=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> >> -----Origina= l Message-----=0D=0A> >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@= gmx.net]=0D=0A> >> Sent: Monday, 4 June 2007 7:40 PM=0D=0A> >> To: ECRIT=0D= =0A> >> Subject: [Ecrit] Location Hiding - another look=0D=0A> >>=0D=0A> >>= Hi all,=0D=0A> >>=0D=0A> >> with location hiding we assumed that the netwo= rk operator does not=0D=0A> >>=0D=0A> > want=0D=0A> >=0D=0A> >> to provide = information about the precise location information to=0D=0Athe=0D=0A> >>=0D= =0A> > end=0D=0A> >=0D=0A> >> point.=0D=0A> >> A lot of discussions focused= on the question how it can still=0D=0Aobtain a=0D=0A> >> PSAP URI in that = case.=0D=0A> >>=0D=0A> >> There is, however, the question why the end point= needs to obtain=0D=0Athis=0D=0A> >> PSAP URI in the location hiding case a= t all.=0D=0A> >> Why cannot we just assume that the VSP has to obtain some = location=0D=0A> >> information from the ASP/ISP via LbyR and then it runs a= LoST query=0D=0Aas=0D=0A> >> we specified it.=0D=0A> >>=0D=0A> >> DONE=0D=0A= > >>=0D=0A> >> Ciao=0D=0A> >> Hannes=0D=0A> >>=0D=0A> >>=0D=0A> >> ________= _______________________________________=0D=0A> >> Ecrit mailing list=0D=0A>= >> Ecrit@ietf.org=0D=0A> >> https://www1.ietf.org/mailman/listinfo/ecrit=0D= =0A> >>=0D=0A> >=0D=0A> >=0D=0A--------------------------------------------= ----------------------------=0D=0A> ------------------------=0D=0A> > This = message is for the designated recipient only and may=0D=0A> > contain privi= leged, proprietary, or otherwise private information.=0D=0A> > If you have = received it in error, please notify the sender=0D=0A> > immediately and del= ete the original. Any unauthorized use of=0D=0A> > this email is prohibite= d.=0D=0A> >=0D=0A----------------------------------------------------------= --------------=0D=0A> ------------------------=0D=0A> > [mf2]=0D=0A> >=0D=0A= > >=0D=0A>=20=0D=0A=0D=0A--------------------------------------------------= ----------------------------------------------=0D=0AThis message is for the= designated recipient only and may=0D=0Acontain privileged, proprietary, or= otherwise private information. =20=0D=0AIf you have received it in error, = please notify the sender=0D=0Aimmediately and delete the original. Any una= uthorized use of=0D=0Athis email is prohibited.=0D=0A----------------------= --------------------------------------------------------------------------=0D= =0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 04 07:03:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvALR-0008EB-Ts; Mon, 04 Jun 2007 07:03:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvALQ-0008Ag-Qj for ecrit@ietf.org; Mon, 04 Jun 2007 07:03:28 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvALQ-0005xs-By for ecrit@ietf.org; Mon, 04 Jun 2007 07:03:28 -0400 Received: (qmail invoked by alias); 04 Jun 2007 11:03:27 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp039) with SMTP; 04 Jun 2007 13:03:27 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18K+Mk1qioKPAO8JFgy2N7tmEch+OnnFwvy2JduRu qNMGr2JYX0iuoj Message-ID: <4663F180.6070808@gmx.net> Date: Mon, 04 Jun 2007 13:03:28 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Ecrit] Location Hiding - another look References: <4663DE0A.1050409@gmx.net> <4663E2DB.6080804@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Sounds like you envision that only authorized entities are allowed to resolve a LbyR regardless of the granularity of the requested information. Ciao Hannes Winterbottom, James wrote: > Hi Hannes, > > Kind of. > A LIS that is providing location information in a local area is far more > likely to have a relationship with a local emergency authority and be > able to determine that they are entitled to location information, than > it is to be able to determine that a VSP in Sierra Leone is entitled to > location information. To me there is a very sizeable difference in these > approaches. > > Hope this helps > > James > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Monday, 4 June 2007 8:01 PM >> To: Winterbottom, James >> Cc: ECRIT >> Subject: Re: [Ecrit] Location Hiding - another look >> >> Hi James, >> >> what relationship do you mean? >> Is it because of the ability to obtain location information by the VSP >> such that call routing can take place? >> Didn't we discuss the ability of the ASP/ISP to differentiate a >> > request > >> and to return precise location only for authorized nodes where as >> unauthorized nodes would only obtain location information that is >> sufficient for emergency call routing. >> >> Ciao >> Hannes >> >> Winterbottom, James wrote: >> >>> Hi Hannes, >>> >>> I would prefer not to have an association between the VSP and >>> > ISP/ASP if > >>> we don't need to. If the end-point can obtain the PSAP URI or the >>> > ESRP > >>> Uri then the relationship between VSP and ISP doesn't need to exist. >>> > The > >>> relationship is between the ISP/ASP and the local PSAP. >>> >>> Cheers >>> James >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Monday, 4 June 2007 7:40 PM >>>> To: ECRIT >>>> Subject: [Ecrit] Location Hiding - another look >>>> >>>> Hi all, >>>> >>>> with location hiding we assumed that the network operator does not >>>> >>>> >>> want >>> >>> >>>> to provide information about the precise location information to >>>> > the > >>> end >>> >>> >>>> point. >>>> A lot of discussions focused on the question how it can still >>>> > obtain a > >>>> PSAP URI in that case. >>>> >>>> There is, however, the question why the end point needs to obtain >>>> > this > >>>> PSAP URI in the location hiding case at all. >>>> Why cannot we just assume that the VSP has to obtain some location >>>> information from the ASP/ISP via LbyR and then it runs a LoST query >>>> > as > >>>> we specified it. >>>> >>>> DONE >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>> > ------------------------------------------------------------------------ > >> ------------------------ >> >>> This message is for the designated recipient only and may >>> contain privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender >>> immediately and delete the original. Any unauthorized use of >>> this email is prohibited. >>> >>> > ------------------------------------------------------------------------ > >> ------------------------ >> >>> [mf2] >>> >>> >>> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 04 07:48:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvB2n-0002pY-Dc; Mon, 04 Jun 2007 07:48:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvB2l-0002cm-BA for ecrit@ietf.org; Mon, 04 Jun 2007 07:48:15 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvB2k-0003cd-07 for ecrit@ietf.org; Mon, 04 Jun 2007 07:48:15 -0400 X-SEF-Processed: 5_0_0_910__2007_06_04_06_55_41 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 04 Jun 2007 06:55:40 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Jun 2007 06:48:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Location Hiding - another look Date: Mon, 4 Jun 2007 06:48:09 -0500 Message-ID: In-Reply-To: <4663F180.6070808@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Hiding - another look Thread-Index: Aceml/3ugZqv1bowRM6gPjKmLp9BMwAAx8pA References: <4663DE0A.1050409@gmx.net> <4663E2DB.6080804@gmx.net> <4663F180.6070808@gmx.net> From: "Winterbottom, James" To: "Hannes Tschofenig" X-OriginalArrivalTime: 04 Jun 2007 11:48:11.0503 (UTC) FILETIME=[3A364FF0:01C7A69E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Hannes,=0D=0A=0D=0AIn systems where I have to pre-provision locations, p= er user I only want=0D=0Aone level of granularity. If the location provider= wants to hide this,=0D=0Athen I think it reasonable that they will only gi= ve it to authorized=0D=0Aentities. The same may be true for systems that ne= ed to compute location=0D=0Aat request time. I think that this is a reasona= ble approach.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A> -----Original= Message-----=0D=0A> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.= net]=0D=0A> Sent: Monday, 4 June 2007 9:03 PM=0D=0A> To: Winterbottom, Jame= s=0D=0A> Cc: ECRIT=0D=0A> Subject: Re: [Ecrit] Location Hiding - another lo= ok=0D=0A>=20=0D=0A> Sounds like you envision that only authorized entities = are allowed to=0D=0A> resolve a LbyR regardless of the granularity of the r= equested=0D=0Ainformation.=0D=0A>=20=0D=0A> Ciao=0D=0A> Hannes=0D=0A>=20=0D= =0A> Winterbottom, James wrote:=0D=0A> > Hi Hannes,=0D=0A> >=0D=0A> > Kind = of.=0D=0A> > A LIS that is providing location information in a local area i= s far=0D=0Amore=0D=0A> > likely to have a relationship with a local emergen= cy authority and=0D=0Abe=0D=0A> > able to determine that they are entitled = to location information,=0D=0Athan=0D=0A> > it is to be able to determine t= hat a VSP in Sierra Leone is entitled=0D=0Ato=0D=0A> > location information= =2E To me there is a very sizeable difference in=0D=0Athese=0D=0A> > approa= ches.=0D=0A> >=0D=0A> > Hope this helps=0D=0A> >=0D=0A> > James=0D=0A> >=0D= =0A> >=0D=0A> >> -----Original Message-----=0D=0A> >> From: Hannes Tschofen= ig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> >> Sent: Monday, 4 June 2007 8= :01 PM=0D=0A> >> To: Winterbottom, James=0D=0A> >> Cc: ECRIT=0D=0A> >> Subj= ect: Re: [Ecrit] Location Hiding - another look=0D=0A> >>=0D=0A> >> Hi Jame= s,=0D=0A> >>=0D=0A> >> what relationship do you mean=3F=0D=0A> >> Is it bec= ause of the ability to obtain location information by the=0D=0AVSP=0D=0A> >= > such that call routing can take place=3F=0D=0A> >> Didn't we discuss the = ability of the ASP/ISP to differentiate a=0D=0A> >>=0D=0A> > request=0D=0A>= >=0D=0A> >> and to return precise location only for authorized nodes where= as=0D=0A> >> unauthorized nodes would only obtain location information tha= t is=0D=0A> >> sufficient for emergency call routing.=0D=0A> >>=0D=0A> >> C= iao=0D=0A> >> Hannes=0D=0A> >>=0D=0A> >> Winterbottom, James wrote:=0D=0A> = >>=0D=0A> >>> Hi Hannes,=0D=0A> >>>=0D=0A> >>> I would prefer not to have a= n association between the VSP and=0D=0A> >>>=0D=0A> > ISP/ASP if=0D=0A> >=0D= =0A> >>> we don't need to. If the end-point can obtain the PSAP URI or the=0D= =0A> >>>=0D=0A> > ESRP=0D=0A> >=0D=0A> >>> Uri then the relationship betwee= n VSP and ISP doesn't need to=0D=0Aexist.=0D=0A> >>>=0D=0A> > The=0D=0A> >=0D= =0A> >>> relationship is between the ISP/ASP and the local PSAP.=0D=0A> >>>=0D= =0A> >>> Cheers=0D=0A> >>> James=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>=0D=0A> >>= >=0D=0A> >>>> -----Original Message-----=0D=0A> >>>> From: Hannes Tschofeni= g [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> >>>> Sent: Monday, 4 June 2007 = 7:40 PM=0D=0A> >>>> To: ECRIT=0D=0A> >>>> Subject: [Ecrit] Location Hiding = - another look=0D=0A> >>>>=0D=0A> >>>> Hi all,=0D=0A> >>>>=0D=0A> >>>> with= location hiding we assumed that the network operator does=0D=0Anot=0D=0A> = >>>>=0D=0A> >>>>=0D=0A> >>> want=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>> to provi= de information about the precise location information to=0D=0A> >>>>=0D=0A>= > the=0D=0A> >=0D=0A> >>> end=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>> point.=0D=0A= > >>>> A lot of discussions focused on the question how it can still=0D=0A>= >>>>=0D=0A> > obtain a=0D=0A> >=0D=0A> >>>> PSAP URI in that case.=0D=0A> = >>>>=0D=0A> >>>> There is, however, the question why the end point needs to= obtain=0D=0A> >>>>=0D=0A> > this=0D=0A> >=0D=0A> >>>> PSAP URI in the loca= tion hiding case at all.=0D=0A> >>>> Why cannot we just assume that the VSP= has to obtain some=0D=0Alocation=0D=0A> >>>> information from the ASP/ISP = via LbyR and then it runs a LoST=0D=0Aquery=0D=0A> >>>>=0D=0A> > as=0D=0A> = >=0D=0A> >>>> we specified it.=0D=0A> >>>>=0D=0A> >>>> DONE=0D=0A> >>>>=0D=0A= > >>>> Ciao=0D=0A> >>>> Hannes=0D=0A> >>>>=0D=0A> >>>>=0D=0A> >>>> ________= _______________________________________=0D=0A> >>>> Ecrit mailing list=0D=0A= > >>>> Ecrit@ietf.org=0D=0A> >>>> https://www1.ietf.org/mailman/listinfo/ec= rit=0D=0A> >>>>=0D=0A> >>>>=0D=0A> >>>=0D=0A> >=0D=0A----------------------= --------------------------------------------------=0D=0A> >=0D=0A> >> -----= -------------------=0D=0A> >>=0D=0A> >>> This message is for the designated= recipient only and may=0D=0A> >>> contain privileged, proprietary, or othe= rwise private information.=0D=0A> >>> If you have received it in error, ple= ase notify the sender=0D=0A> >>> immediately and delete the original. Any = unauthorized use of=0D=0A> >>> this email is prohibited.=0D=0A> >>>=0D=0A> = >>>=0D=0A> >=0D=0A---------------------------------------------------------= ---------------=0D=0A> >=0D=0A> >> ------------------------=0D=0A> >>=0D=0A= > >>> [mf2]=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>=0D=0A> >=0D=0A> >=0D=0A-------= -----------------------------------------------------------------=0D=0A> --= ----------------------=0D=0A> > This message is for the designated recipien= t only and may=0D=0A> > contain privileged, proprietary, or otherwise priva= te information.=0D=0A> > If you have received it in error, please notify th= e sender=0D=0A> > immediately and delete the original. Any unauthorized us= e of=0D=0A> > this email is prohibited.=0D=0A> >=0D=0A---------------------= ---------------------------------------------------=0D=0A> ----------------= --------=0D=0A> > [mf2]=0D=0A> >=0D=0A> >=0D=0A>=20=0D=0A=0D=0A------------= ---------------------------------------------------------------------------= ---------=0D=0AThis message is for the designated recipient only and may=0D= =0Acontain privileged, proprietary, or otherwise private information. =20=0D= =0AIf you have received it in error, please notify the sender=0D=0Aimmediat= ely and delete the original. Any unauthorized use of=0D=0Athis email is pr= ohibited.=0D=0A------------------------------------------------------------= ------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 04 07:57:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvBBF-0004oG-VD; Mon, 04 Jun 2007 07:57:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvBBE-0004o3-Rj for ecrit@ietf.org; Mon, 04 Jun 2007 07:57:00 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvBBE-0004xO-8O for ecrit@ietf.org; Mon, 04 Jun 2007 07:57:00 -0400 Received: (qmail invoked by alias); 04 Jun 2007 11:56:59 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp034) with SMTP; 04 Jun 2007 13:56:59 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+lncp3ptmlZV5KPrBgq+r4FRs1TXnFkCUTLk8yut /r9zgHsWb2d1Ck Message-ID: <4663FE01.6040409@gmx.net> Date: Mon, 04 Jun 2007 13:56:49 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Ecrit] Location Hiding - another look References: <4663DE0A.1050409@gmx.net> <4663E2DB.6080804@gmx.net> <4663F180.6070808@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org It would obviously be fairly trivial to reduce the granularity, particularly within a DSL environment where civic location is used. Ciao Hannes Winterbottom, James wrote: > Hi Hannes, > > In systems where I have to pre-provision locations, per user I only want > one level of granularity. If the location provider wants to hide this, > then I think it reasonable that they will only give it to authorized > entities. The same may be true for systems that need to compute location > at request time. I think that this is a reasonable approach. > > Cheers > James > > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Monday, 4 June 2007 9:03 PM >> To: Winterbottom, James >> Cc: ECRIT >> Subject: Re: [Ecrit] Location Hiding - another look >> >> Sounds like you envision that only authorized entities are allowed to >> resolve a LbyR regardless of the granularity of the requested >> > information. > >> Ciao >> Hannes >> >> Winterbottom, James wrote: >> >>> Hi Hannes, >>> >>> Kind of. >>> A LIS that is providing location information in a local area is far >>> > more > >>> likely to have a relationship with a local emergency authority and >>> > be > >>> able to determine that they are entitled to location information, >>> > than > >>> it is to be able to determine that a VSP in Sierra Leone is entitled >>> > to > >>> location information. To me there is a very sizeable difference in >>> > these > >>> approaches. >>> >>> Hope this helps >>> >>> James >>> >>> >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Monday, 4 June 2007 8:01 PM >>>> To: Winterbottom, James >>>> Cc: ECRIT >>>> Subject: Re: [Ecrit] Location Hiding - another look >>>> >>>> Hi James, >>>> >>>> what relationship do you mean? >>>> Is it because of the ability to obtain location information by the >>>> > VSP > >>>> such that call routing can take place? >>>> Didn't we discuss the ability of the ASP/ISP to differentiate a >>>> >>>> >>> request >>> >>> >>>> and to return precise location only for authorized nodes where as >>>> unauthorized nodes would only obtain location information that is >>>> sufficient for emergency call routing. >>>> >>>> Ciao >>>> Hannes >>>> >>>> Winterbottom, James wrote: >>>> >>>> >>>>> Hi Hannes, >>>>> >>>>> I would prefer not to have an association between the VSP and >>>>> >>>>> >>> ISP/ASP if >>> >>> >>>>> we don't need to. If the end-point can obtain the PSAP URI or the >>>>> >>>>> >>> ESRP >>> >>> >>>>> Uri then the relationship between VSP and ISP doesn't need to >>>>> > exist. > >>> The >>> >>> >>>>> relationship is between the ISP/ASP and the local PSAP. >>>>> >>>>> Cheers >>>>> James >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>> Sent: Monday, 4 June 2007 7:40 PM >>>>>> To: ECRIT >>>>>> Subject: [Ecrit] Location Hiding - another look >>>>>> >>>>>> Hi all, >>>>>> >>>>>> with location hiding we assumed that the network operator does >>>>>> > not > >>>>>> >>>>> want >>>>> >>>>> >>>>> >>>>>> to provide information about the precise location information to >>>>>> >>>>>> >>> the >>> >>> >>>>> end >>>>> >>>>> >>>>> >>>>>> point. >>>>>> A lot of discussions focused on the question how it can still >>>>>> >>>>>> >>> obtain a >>> >>> >>>>>> PSAP URI in that case. >>>>>> >>>>>> There is, however, the question why the end point needs to obtain >>>>>> >>>>>> >>> this >>> >>> >>>>>> PSAP URI in the location hiding case at all. >>>>>> Why cannot we just assume that the VSP has to obtain some >>>>>> > location > >>>>>> information from the ASP/ISP via LbyR and then it runs a LoST >>>>>> > query > >>> as >>> >>> >>>>>> we specified it. >>>>>> >>>>>> DONE >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> >>>>>> > ------------------------------------------------------------------------ > >>>> ------------------------ >>>> >>>> >>>>> This message is for the designated recipient only and may >>>>> contain privileged, proprietary, or otherwise private information. >>>>> If you have received it in error, please notify the sender >>>>> immediately and delete the original. Any unauthorized use of >>>>> this email is prohibited. >>>>> >>>>> >>>>> > ------------------------------------------------------------------------ > >>>> ------------------------ >>>> >>>> >>>>> [mf2] >>>>> >>>>> >>>>> >>>>> >>> > ------------------------------------------------------------------------ > >> ------------------------ >> >>> This message is for the designated recipient only and may >>> contain privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender >>> immediately and delete the original. Any unauthorized use of >>> this email is prohibited. >>> >>> > ------------------------------------------------------------------------ > >> ------------------------ >> >>> [mf2] >>> >>> >>> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 04 07:59:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvBDG-0005iY-2c; Mon, 04 Jun 2007 07:59:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvBDF-0005iT-2E for ecrit@ietf.org; Mon, 04 Jun 2007 07:59:05 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvBDE-0005ep-MS for ecrit@ietf.org; Mon, 04 Jun 2007 07:59:05 -0400 X-SEF-Processed: 5_0_0_910__2007_06_04_07_06_33 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 04 Jun 2007 07:06:33 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Jun 2007 06:59:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Location Hiding - another look Date: Mon, 4 Jun 2007 06:59:02 -0500 Message-ID: In-Reply-To: <4663FE01.6040409@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Hiding - another look Thread-Index: Acemn3ZrGWkywy9cTVK8ieE2/Xd9oAAAB+RQ References: <4663DE0A.1050409@gmx.net> <4663E2DB.6080804@gmx.net> <4663F180.6070808@gmx.net> <4663FE01.6040409@gmx.net> From: "Winterbottom, James" To: "Hannes Tschofenig" X-OriginalArrivalTime: 04 Jun 2007 11:59:04.0162 (UTC) FILETIME=[BF3A2C20:01C7A69F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org To what level though=3F=0D=0AAnd it does mean that I have to have at least = a ruleset for describing=0D=0Ahow to dumb down location in some areas. I pr= efer a solution that does=0D=0Anot require this.=0D=0A=0D=0A> -----Original= Message-----=0D=0A> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.= net]=0D=0A> Sent: Monday, 4 June 2007 9:57 PM=0D=0A> To: Winterbottom, Jame= s=0D=0A> Cc: ECRIT=0D=0A> Subject: Re: [Ecrit] Location Hiding - another lo= ok=0D=0A>=20=0D=0A> It would obviously be fairly trivial to reduce the gran= ularity,=0D=0A> particularly within a DSL environment where civic location = is used.=0D=0A>=20=0D=0A> Ciao=0D=0A> Hannes=0D=0A>=20=0D=0A> Winterbottom,= James wrote:=0D=0A> > Hi Hannes,=0D=0A> >=0D=0A> > In systems where I have= to pre-provision locations, per user I only=0D=0Awant=0D=0A> > one level o= f granularity. If the location provider wants to hide=0D=0Athis,=0D=0A> > t= hen I think it reasonable that they will only give it to authorized=0D=0A> = > entities. The same may be true for systems that need to compute=0D=0Aloca= tion=0D=0A> > at request time. I think that this is a reasonable approach.=0D= =0A> >=0D=0A> > Cheers=0D=0A> > James=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> >> = -----Original Message-----=0D=0A> >> From: Hannes Tschofenig [mailto:Hannes= =2ETschofenig@gmx.net]=0D=0A> >> Sent: Monday, 4 June 2007 9:03 PM=0D=0A> >= > To: Winterbottom, James=0D=0A> >> Cc: ECRIT=0D=0A> >> Subject: Re: [Ecrit= ] Location Hiding - another look=0D=0A> >>=0D=0A> >> Sounds like you envisi= on that only authorized entities are allowed=0D=0Ato=0D=0A> >> resolve a Lb= yR regardless of the granularity of the requested=0D=0A> >>=0D=0A> > inform= ation.=0D=0A> >=0D=0A> >> Ciao=0D=0A> >> Hannes=0D=0A> >>=0D=0A> >> Winterb= ottom, James wrote:=0D=0A> >>=0D=0A> >>> Hi Hannes,=0D=0A> >>>=0D=0A> >>> K= ind of.=0D=0A> >>> A LIS that is providing location information in a local = area is=0D=0Afar=0D=0A> >>>=0D=0A> > more=0D=0A> >=0D=0A> >>> likely to hav= e a relationship with a local emergency authority and=0D=0A> >>>=0D=0A> > b= e=0D=0A> >=0D=0A> >>> able to determine that they are entitled to location = information,=0D=0A> >>>=0D=0A> > than=0D=0A> >=0D=0A> >>> it is to be able = to determine that a VSP in Sierra Leone is=0D=0Aentitled=0D=0A> >>>=0D=0A> = > to=0D=0A> >=0D=0A> >>> location information. To me there is a very sizeab= le difference in=0D=0A> >>>=0D=0A> > these=0D=0A> >=0D=0A> >>> approaches.=0D= =0A> >>>=0D=0A> >>> Hope this helps=0D=0A> >>>=0D=0A> >>> James=0D=0A> >>>=0D= =0A> >>>=0D=0A> >>>=0D=0A> >>>> -----Original Message-----=0D=0A> >>>> From= : Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> >>>> Sent: Mo= nday, 4 June 2007 8:01 PM=0D=0A> >>>> To: Winterbottom, James=0D=0A> >>>> C= c: ECRIT=0D=0A> >>>> Subject: Re: [Ecrit] Location Hiding - another look=0D= =0A> >>>>=0D=0A> >>>> Hi James,=0D=0A> >>>>=0D=0A> >>>> what relationship d= o you mean=3F=0D=0A> >>>> Is it because of the ability to obtain location i= nformation by=0D=0Athe=0D=0A> >>>>=0D=0A> > VSP=0D=0A> >=0D=0A> >>>> such t= hat call routing can take place=3F=0D=0A> >>>> Didn't we discuss the abilit= y of the ASP/ISP to differentiate a=0D=0A> >>>>=0D=0A> >>>>=0D=0A> >>> requ= est=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>> and to return precise location only f= or authorized nodes where as=0D=0A> >>>> unauthorized nodes would only obta= in location information that is=0D=0A> >>>> sufficient for emergency call r= outing.=0D=0A> >>>>=0D=0A> >>>> Ciao=0D=0A> >>>> Hannes=0D=0A> >>>>=0D=0A> = >>>> Winterbottom, James wrote:=0D=0A> >>>>=0D=0A> >>>>=0D=0A> >>>>> Hi Han= nes,=0D=0A> >>>>>=0D=0A> >>>>> I would prefer not to have an association be= tween the VSP and=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>> ISP/ASP if=0D=0A> >>= >=0D=0A> >>>=0D=0A> >>>>> we don't need to. If the end-point can obtain the= PSAP URI or=0D=0Athe=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>> ESRP=0D=0A> >>>=0D= =0A> >>>=0D=0A> >>>>> Uri then the relationship between VSP and ISP doesn't= need to=0D=0A> >>>>>=0D=0A> > exist.=0D=0A> >=0D=0A> >>> The=0D=0A> >>>=0D= =0A> >>>=0D=0A> >>>>> relationship is between the ISP/ASP and the local PSA= P.=0D=0A> >>>>>=0D=0A> >>>>> Cheers=0D=0A> >>>>> James=0D=0A> >>>>>=0D=0A> = >>>>>=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>>>>> -----Original Me= ssage-----=0D=0A> >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@= gmx.net]=0D=0A> >>>>>> Sent: Monday, 4 June 2007 7:40 PM=0D=0A> >>>>>> To: = ECRIT=0D=0A> >>>>>> Subject: [Ecrit] Location Hiding - another look=0D=0A> = >>>>>>=0D=0A> >>>>>> Hi all,=0D=0A> >>>>>>=0D=0A> >>>>>> with location hidi= ng we assumed that the network operator does=0D=0A> >>>>>>=0D=0A> > not=0D=0A= > >=0D=0A> >>>>>>=0D=0A> >>>>> want=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>>>>=0D= =0A> >>>>>> to provide information about the precise location information=0D= =0Ato=0D=0A> >>>>>>=0D=0A> >>>>>>=0D=0A> >>> the=0D=0A> >>>=0D=0A> >>>=0D=0A= > >>>>> end=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>>>>> point.=0D=0A= > >>>>>> A lot of discussions focused on the question how it can still=0D=0A= > >>>>>>=0D=0A> >>>>>>=0D=0A> >>> obtain a=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>= >>> PSAP URI in that case.=0D=0A> >>>>>>=0D=0A> >>>>>> There is, however, t= he question why the end point needs to=0D=0Aobtain=0D=0A> >>>>>>=0D=0A> >>>= >>>=0D=0A> >>> this=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>>>> PSAP URI in the loc= ation hiding case at all.=0D=0A> >>>>>> Why cannot we just assume that the = VSP has to obtain some=0D=0A> >>>>>>=0D=0A> > location=0D=0A> >=0D=0A> >>>>= >> information from the ASP/ISP via LbyR and then it runs a LoST=0D=0A> >>>= >>>=0D=0A> > query=0D=0A> >=0D=0A> >>> as=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>>= >> we specified it.=0D=0A> >>>>>>=0D=0A> >>>>>> DONE=0D=0A> >>>>>>=0D=0A> >= >>>>> Ciao=0D=0A> >>>>>> Hannes=0D=0A> >>>>>>=0D=0A> >>>>>>=0D=0A> >>>>>> _= ______________________________________________=0D=0A> >>>>>> Ecrit mailing = list=0D=0A> >>>>>> Ecrit@ietf.org=0D=0A> >>>>>> https://www1.ietf.org/mailm= an/listinfo/ecrit=0D=0A> >>>>>>=0D=0A> >>>>>>=0D=0A> >>>>>>=0D=0A> >=0D=0A-= -----------------------------------------------------------------------=0D=0A= > >=0D=0A> >>>> ------------------------=0D=0A> >>>>=0D=0A> >>>>=0D=0A> >>>= >> This message is for the designated recipient only and may=0D=0A> >>>>> c= ontain privileged, proprietary, or otherwise private=0D=0Ainformation.=0D=0A= > >>>>> If you have received it in error, please notify the sender=0D=0A> >= >>>> immediately and delete the original. Any unauthorized use of=0D=0A> >= >>>> this email is prohibited.=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A= > >=0D=0A------------------------------------------------------------------= ------=0D=0A> >=0D=0A> >>>> ------------------------=0D=0A> >>>>=0D=0A> >>>= >=0D=0A> >>>>> [mf2]=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>>>>=0D= =0A> >>>=0D=0A> >=0D=0A----------------------------------------------------= --------------------=0D=0A> >=0D=0A> >> ------------------------=0D=0A> >>=0D= =0A> >>> This message is for the designated recipient only and may=0D=0A> >= >> contain privileged, proprietary, or otherwise private information.=0D=0A= > >>> If you have received it in error, please notify the sender=0D=0A> >>>= immediately and delete the original. Any unauthorized use of=0D=0A> >>> t= his email is prohibited.=0D=0A> >>>=0D=0A> >>>=0D=0A> >=0D=0A--------------= ----------------------------------------------------------=0D=0A> >=0D=0A> = >> ------------------------=0D=0A> >>=0D=0A> >>> [mf2]=0D=0A> >>>=0D=0A> >>= >=0D=0A> >>>=0D=0A> >=0D=0A> >=0D=0A---------------------------------------= ---------------------------------=0D=0A> ------------------------=0D=0A> > = This message is for the designated recipient only and may=0D=0A> > contain = privileged, proprietary, or otherwise private information.=0D=0A> > If you = have received it in error, please notify the sender=0D=0A> > immediately an= d delete the original. Any unauthorized use of=0D=0A> > this email is proh= ibited.=0D=0A> >=0D=0A-----------------------------------------------------= -------------------=0D=0A> ------------------------=0D=0A> > [mf2]=0D=0A> >=0D= =0A> >=0D=0A>=20=0D=0A=0D=0A-----------------------------------------------= -------------------------------------------------=0D=0AThis message is for = the designated recipient only and may=0D=0Acontain privileged, proprietary,= or otherwise private information. =20=0D=0AIf you have received it in erro= r, please notify the sender=0D=0Aimmediately and delete the original. Any = unauthorized use of=0D=0Athis email is prohibited.=0D=0A-------------------= ---------------------------------------------------------------------------= --=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 04 08:02:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvBGH-00084V-Ft; Mon, 04 Jun 2007 08:02:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvBGG-00082e-A6 for ecrit@ietf.org; Mon, 04 Jun 2007 08:02:12 -0400 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvBGD-0006T3-G7 for ecrit@ietf.org; Mon, 04 Jun 2007 08:02:12 -0400 Received: from mail2.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id l54C25bH017033; Mon, 4 Jun 2007 14:02:05 +0200 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id l54C26iU000684; Mon, 4 Jun 2007 14:02:06 +0200 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 14:02:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Location Hiding - another look Date: Mon, 4 Jun 2007 14:01:55 +0200 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E701BEDFFA@MCHP7R6A.ww002.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Hiding - another look Thread-Index: Acemn3ZrGWkywy9cTVK8ieE2/Xd9oAAAB+RQAAAUKTA= From: "Tschofenig, Hannes" To: "ext Winterbottom, James" , "Hannes Tschofenig" X-OriginalArrivalTime: 04 Jun 2007 12:02:06.0103 (UTC) FILETIME=[2BAC2A70:01C7A6A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The level depends on the country.=20 As we learned a few months ago there is only a single PSAP in Australia. = Hence, the country code would be sufficient. The same is true for = Finland. In Norway, there are 4 PSAPs (or 5) and hence you need a bit = more than just the country level info.=20 Complicated? Not really. Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: ext Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 > Gesendet: Montag, 4. Juni 2007 13:59 > An: Hannes Tschofenig > Cc: ECRIT > Betreff: RE: [Ecrit] Location Hiding - another look >=20 > To what level though? > And it does mean that I have to have at least a ruleset for describing > how to dumb down location in some areas. I prefer a solution that does > not require this. >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Monday, 4 June 2007 9:57 PM > > To: Winterbottom, James > > Cc: ECRIT > > Subject: Re: [Ecrit] Location Hiding - another look > >=20 > > It would obviously be fairly trivial to reduce the granularity, > > particularly within a DSL environment where civic location is used. > >=20 > > Ciao > > Hannes > >=20 > > Winterbottom, James wrote: > > > Hi Hannes, > > > > > > In systems where I have to pre-provision locations, per=20 > user I only > want > > > one level of granularity. If the location provider wants to hide > this, > > > then I think it reasonable that they will only give it to=20 > authorized > > > entities. The same may be true for systems that need to compute > location > > > at request time. I think that this is a reasonable approach. > > > > > > Cheers > > > James > > > > > > > > > > > >> -----Original Message----- > > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > >> Sent: Monday, 4 June 2007 9:03 PM > > >> To: Winterbottom, James > > >> Cc: ECRIT > > >> Subject: Re: [Ecrit] Location Hiding - another look > > >> > > >> Sounds like you envision that only authorized entities=20 > are allowed > to > > >> resolve a LbyR regardless of the granularity of the requested > > >> > > > information. > > > > > >> Ciao > > >> Hannes > > >> > > >> Winterbottom, James wrote: > > >> > > >>> Hi Hannes, > > >>> > > >>> Kind of. > > >>> A LIS that is providing location information in a local area is > far > > >>> > > > more > > > > > >>> likely to have a relationship with a local emergency=20 > authority and > > >>> > > > be > > > > > >>> able to determine that they are entitled to location=20 > information, > > >>> > > > than > > > > > >>> it is to be able to determine that a VSP in Sierra Leone is > entitled > > >>> > > > to > > > > > >>> location information. To me there is a very sizeable=20 > difference in > > >>> > > > these > > > > > >>> approaches. > > >>> > > >>> Hope this helps > > >>> > > >>> James > > >>> > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > >>>> Sent: Monday, 4 June 2007 8:01 PM > > >>>> To: Winterbottom, James > > >>>> Cc: ECRIT > > >>>> Subject: Re: [Ecrit] Location Hiding - another look > > >>>> > > >>>> Hi James, > > >>>> > > >>>> what relationship do you mean? > > >>>> Is it because of the ability to obtain location information by > the > > >>>> > > > VSP > > > > > >>>> such that call routing can take place? > > >>>> Didn't we discuss the ability of the ASP/ISP to differentiate a > > >>>> > > >>>> > > >>> request > > >>> > > >>> > > >>>> and to return precise location only for authorized=20 > nodes where as > > >>>> unauthorized nodes would only obtain location=20 > information that is > > >>>> sufficient for emergency call routing. > > >>>> > > >>>> Ciao > > >>>> Hannes > > >>>> > > >>>> Winterbottom, James wrote: > > >>>> > > >>>> > > >>>>> Hi Hannes, > > >>>>> > > >>>>> I would prefer not to have an association between the VSP and > > >>>>> > > >>>>> > > >>> ISP/ASP if > > >>> > > >>> > > >>>>> we don't need to. If the end-point can obtain the PSAP URI or > the > > >>>>> > > >>>>> > > >>> ESRP > > >>> > > >>> > > >>>>> Uri then the relationship between VSP and ISP doesn't need to > > >>>>> > > > exist. > > > > > >>> The > > >>> > > >>> > > >>>>> relationship is between the ISP/ASP and the local PSAP. > > >>>>> > > >>>>> Cheers > > >>>>> James > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > >>>>>> Sent: Monday, 4 June 2007 7:40 PM > > >>>>>> To: ECRIT > > >>>>>> Subject: [Ecrit] Location Hiding - another look > > >>>>>> > > >>>>>> Hi all, > > >>>>>> > > >>>>>> with location hiding we assumed that the network=20 > operator does > > >>>>>> > > > not > > > > > >>>>>> > > >>>>> want > > >>>>> > > >>>>> > > >>>>> > > >>>>>> to provide information about the precise location information > to > > >>>>>> > > >>>>>> > > >>> the > > >>> > > >>> > > >>>>> end > > >>>>> > > >>>>> > > >>>>> > > >>>>>> point. > > >>>>>> A lot of discussions focused on the question how it can still > > >>>>>> > > >>>>>> > > >>> obtain a > > >>> > > >>> > > >>>>>> PSAP URI in that case. > > >>>>>> > > >>>>>> There is, however, the question why the end point needs to > obtain > > >>>>>> > > >>>>>> > > >>> this > > >>> > > >>> > > >>>>>> PSAP URI in the location hiding case at all. > > >>>>>> Why cannot we just assume that the VSP has to obtain some > > >>>>>> > > > location > > > > > >>>>>> information from the ASP/ISP via LbyR and then it runs a LoST > > >>>>>> > > > query > > > > > >>> as > > >>> > > >>> > > >>>>>> we specified it. > > >>>>>> > > >>>>>> DONE > > >>>>>> > > >>>>>> Ciao > > >>>>>> Hannes > > >>>>>> > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> Ecrit mailing list > > >>>>>> Ecrit@ietf.org > > >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > > >>>>>> > > >>>>>> > > >>>>>> > > > > -------------------------------------------------------------- > ---------- > > > > > >>>> ------------------------ > > >>>> > > >>>> > > >>>>> This message is for the designated recipient only and may > > >>>>> contain privileged, proprietary, or otherwise private > information. > > >>>>> If you have received it in error, please notify the sender > > >>>>> immediately and delete the original. Any unauthorized use of > > >>>>> this email is prohibited. > > >>>>> > > >>>>> > > >>>>> > > > > -------------------------------------------------------------- > ---------- > > > > > >>>> ------------------------ > > >>>> > > >>>> > > >>>>> [mf2] > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>> > > > > -------------------------------------------------------------- > ---------- > > > > > >> ------------------------ > > >> > > >>> This message is for the designated recipient only and may > > >>> contain privileged, proprietary, or otherwise private=20 > information. > > >>> If you have received it in error, please notify the sender > > >>> immediately and delete the original. Any unauthorized use of > > >>> this email is prohibited. > > >>> > > >>> > > > > -------------------------------------------------------------- > ---------- > > > > > >> ------------------------ > > >> > > >>> [mf2] > > >>> > > >>> > > >>> > > > > > > > -------------------------------------------------------------- > ---------- > > ------------------------ > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > -------------------------------------------------------------- > ---------- > > ------------------------ > > > [mf2] > > > > > > > >=20 >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 04 08:04:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvBIZ-0002Mm-Ax; Mon, 04 Jun 2007 08:04:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvBIY-0002Mh-5s for ecrit@ietf.org; Mon, 04 Jun 2007 08:04:34 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvBIW-0006hC-H9 for ecrit@ietf.org; Mon, 04 Jun 2007 08:04:34 -0400 Received: (qmail invoked by alias); 04 Jun 2007 12:04:31 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp018) with SMTP; 04 Jun 2007 14:04:31 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+nA/cZOgmnQxFxFodP/bX5UkSFMhQb22THurOUNo quLo2423uRBuyZ Message-ID: <4663FFC5.1070104@gmx.net> Date: Mon, 04 Jun 2007 14:04:21 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Ecrit] Location Hiding - another look References: <4663DE0A.1050409@gmx.net> <4663E2DB.6080804@gmx.net> <4663F180.6070808@gmx.net> <4663FE01.6040409@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e06437eb72f6703f11713d345be8298a Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Btw, in cellular systems I recall that we already said that the dereferencing request includes a parameter that indicates when and at what quality level the location info is needed. Hence, I think it is not really true that there is only one form of location. Winterbottom, James wrote: > To what level though? > And it does mean that I have to have at least a ruleset for describing > how to dumb down location in some areas. I prefer a solution that does > not require this. > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Monday, 4 June 2007 9:57 PM >> To: Winterbottom, James >> Cc: ECRIT >> Subject: Re: [Ecrit] Location Hiding - another look >> >> It would obviously be fairly trivial to reduce the granularity, >> particularly within a DSL environment where civic location is used. >> >> Ciao >> Hannes >> >> Winterbottom, James wrote: >> >>> Hi Hannes, >>> >>> In systems where I have to pre-provision locations, per user I only >>> > want > >>> one level of granularity. If the location provider wants to hide >>> > this, > >>> then I think it reasonable that they will only give it to authorized >>> entities. The same may be true for systems that need to compute >>> > location > >>> at request time. I think that this is a reasonable approach. >>> >>> Cheers >>> James >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Monday, 4 June 2007 9:03 PM >>>> To: Winterbottom, James >>>> Cc: ECRIT >>>> Subject: Re: [Ecrit] Location Hiding - another look >>>> >>>> Sounds like you envision that only authorized entities are allowed >>>> > to > >>>> resolve a LbyR regardless of the granularity of the requested >>>> >>>> >>> information. >>> >>> >>>> Ciao >>>> Hannes >>>> >>>> Winterbottom, James wrote: >>>> >>>> >>>>> Hi Hannes, >>>>> >>>>> Kind of. >>>>> A LIS that is providing location information in a local area is >>>>> > far > >>> more >>> >>> >>>>> likely to have a relationship with a local emergency authority and >>>>> >>>>> >>> be >>> >>> >>>>> able to determine that they are entitled to location information, >>>>> >>>>> >>> than >>> >>> >>>>> it is to be able to determine that a VSP in Sierra Leone is >>>>> > entitled > >>> to >>> >>> >>>>> location information. To me there is a very sizeable difference in >>>>> >>>>> >>> these >>> >>> >>>>> approaches. >>>>> >>>>> Hope this helps >>>>> >>>>> James >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>> Sent: Monday, 4 June 2007 8:01 PM >>>>>> To: Winterbottom, James >>>>>> Cc: ECRIT >>>>>> Subject: Re: [Ecrit] Location Hiding - another look >>>>>> >>>>>> Hi James, >>>>>> >>>>>> what relationship do you mean? >>>>>> Is it because of the ability to obtain location information by >>>>>> > the > >>> VSP >>> >>> >>>>>> such that call routing can take place? >>>>>> Didn't we discuss the ability of the ASP/ISP to differentiate a >>>>>> >>>>>> >>>>>> >>>>> request >>>>> >>>>> >>>>> >>>>>> and to return precise location only for authorized nodes where as >>>>>> unauthorized nodes would only obtain location information that is >>>>>> sufficient for emergency call routing. >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> Winterbottom, James wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Hi Hannes, >>>>>>> >>>>>>> I would prefer not to have an association between the VSP and >>>>>>> >>>>>>> >>>>>>> >>>>> ISP/ASP if >>>>> >>>>> >>>>> >>>>>>> we don't need to. If the end-point can obtain the PSAP URI or >>>>>>> > the > >>>>>>> >>>>> ESRP >>>>> >>>>> >>>>> >>>>>>> Uri then the relationship between VSP and ISP doesn't need to >>>>>>> >>>>>>> >>> exist. >>> >>> >>>>> The >>>>> >>>>> >>>>> >>>>>>> relationship is between the ISP/ASP and the local PSAP. >>>>>>> >>>>>>> Cheers >>>>>>> James >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>> Sent: Monday, 4 June 2007 7:40 PM >>>>>>>> To: ECRIT >>>>>>>> Subject: [Ecrit] Location Hiding - another look >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> with location hiding we assumed that the network operator does >>>>>>>> >>>>>>>> >>> not >>> >>> >>>>>>> want >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> to provide information about the precise location information >>>>>>>> > to > >>>>>>>> >>>>> the >>>>> >>>>> >>>>> >>>>>>> end >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> point. >>>>>>>> A lot of discussions focused on the question how it can still >>>>>>>> >>>>>>>> >>>>>>>> >>>>> obtain a >>>>> >>>>> >>>>> >>>>>>>> PSAP URI in that case. >>>>>>>> >>>>>>>> There is, however, the question why the end point needs to >>>>>>>> > obtain > >>>>>>>> >>>>> this >>>>> >>>>> >>>>> >>>>>>>> PSAP URI in the location hiding case at all. >>>>>>>> Why cannot we just assume that the VSP has to obtain some >>>>>>>> >>>>>>>> >>> location >>> >>> >>>>>>>> information from the ASP/ISP via LbyR and then it runs a LoST >>>>>>>> >>>>>>>> >>> query >>> >>> >>>>> as >>>>> >>>>> >>>>> >>>>>>>> we specified it. >>>>>>>> >>>>>>>> DONE >>>>>>>> >>>>>>>> Ciao >>>>>>>> Hannes >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Ecrit mailing list >>>>>>>> Ecrit@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > ------------------------------------------------------------------------ > >>>>>> ------------------------ >>>>>> >>>>>> >>>>>> >>>>>>> This message is for the designated recipient only and may >>>>>>> contain privileged, proprietary, or otherwise private >>>>>>> > information. > >>>>>>> If you have received it in error, please notify the sender >>>>>>> immediately and delete the original. Any unauthorized use of >>>>>>> this email is prohibited. >>>>>>> >>>>>>> >>>>>>> >>>>>>> > ------------------------------------------------------------------------ > >>>>>> ------------------------ >>>>>> >>>>>> >>>>>> >>>>>>> [mf2] >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> > ------------------------------------------------------------------------ > >>>> ------------------------ >>>> >>>> >>>>> This message is for the designated recipient only and may >>>>> contain privileged, proprietary, or otherwise private information. >>>>> If you have received it in error, please notify the sender >>>>> immediately and delete the original. Any unauthorized use of >>>>> this email is prohibited. >>>>> >>>>> >>>>> > ------------------------------------------------------------------------ > >>>> ------------------------ >>>> >>>> >>>>> [mf2] >>>>> >>>>> >>>>> >>>>> >>> > ------------------------------------------------------------------------ > >> ------------------------ >> >>> This message is for the designated recipient only and may >>> contain privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender >>> immediately and delete the original. Any unauthorized use of >>> this email is prohibited. >>> >>> > ------------------------------------------------------------------------ > >> ------------------------ >> >>> [mf2] >>> >>> >>> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 04 08:08:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvBLy-0005aP-V1; Mon, 04 Jun 2007 08:08:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvBLy-0005aK-3l for ecrit@ietf.org; Mon, 04 Jun 2007 08:08:06 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvBLx-0007NS-K0 for ecrit@ietf.org; Mon, 04 Jun 2007 08:08:06 -0400 X-SEF-Processed: 5_0_0_910__2007_06_04_07_15_34 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 04 Jun 2007 07:15:34 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Jun 2007 07:08:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Location Hiding - another look Date: Mon, 4 Jun 2007 07:08:03 -0500 Message-ID: In-Reply-To: <4663FFC5.1070104@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Hiding - another look Thread-Index: AcemoIPVGb7YR0fbTGaUt3EuVXF9FQAAC/XQ References: <4663DE0A.1050409@gmx.net> <4663E2DB.6080804@gmx.net> <4663F180.6070808@gmx.net> <4663FE01.6040409@gmx.net> <4663FFC5.1070104@gmx.net> From: "Winterbottom, James" To: "Hannes Tschofenig" X-OriginalArrivalTime: 04 Jun 2007 12:08:05.0162 (UTC) FILETIME=[01B038A0:01C7A6A1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Oh I entirely agree that where location needs to be calculated that=0D=0Ath= ere is not only one level. But there is a cost involved when it needs=0D=0A= to be calculated and that cost goes up the more precise the location=0D=0Ar= equired is. In these systems I generally only provision things like=0D=0Ace= ll-sites, I certainly don't provision discrete locations per-user.=0D=0A=0D= =0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Hannes Tschofenig = [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> Sent: Monday, 4 June 2007 10:04 P= M=0D=0A> To: Winterbottom, James=0D=0A> Cc: ECRIT=0D=0A> Subject: Re: [Ecri= t] Location Hiding - another look=0D=0A>=20=0D=0A> Btw, in cellular systems= I recall that we already said that the=0D=0A> dereferencing request includ= es a parameter that indicates when and at=0D=0A> what quality level the loc= ation info is needed. Hence, I think it is=0D=0Anot=0D=0A> really true that= there is only one form of location.=0D=0A>=20=0D=0A>=20=0D=0A> Winterbotto= m, James wrote:=0D=0A> > To what level though=3F=0D=0A> > And it does mean = that I have to have at least a ruleset for=0D=0Adescribing=0D=0A> > how to = dumb down location in some areas. I prefer a solution that=0D=0Adoes=0D=0A>= > not require this.=0D=0A> >=0D=0A> >=0D=0A> >> -----Original Message-----=0D= =0A> >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> >= > Sent: Monday, 4 June 2007 9:57 PM=0D=0A> >> To: Winterbottom, James=0D=0A= > >> Cc: ECRIT=0D=0A> >> Subject: Re: [Ecrit] Location Hiding - another loo= k=0D=0A> >>=0D=0A> >> It would obviously be fairly trivial to reduce the gr= anularity,=0D=0A> >> particularly within a DSL environment where civic loca= tion is used.=0D=0A> >>=0D=0A> >> Ciao=0D=0A> >> Hannes=0D=0A> >>=0D=0A> >>= Winterbottom, James wrote:=0D=0A> >>=0D=0A> >>> Hi Hannes,=0D=0A> >>>=0D=0A= > >>> In systems where I have to pre-provision locations, per user I=0D=0Ao= nly=0D=0A> >>>=0D=0A> > want=0D=0A> >=0D=0A> >>> one level of granularity. = If the location provider wants to hide=0D=0A> >>>=0D=0A> > this,=0D=0A> >=0D= =0A> >>> then I think it reasonable that they will only give it to=0D=0Aaut= horized=0D=0A> >>> entities. The same may be true for systems that need to = compute=0D=0A> >>>=0D=0A> > location=0D=0A> >=0D=0A> >>> at request time. I= think that this is a reasonable approach.=0D=0A> >>>=0D=0A> >>> Cheers=0D=0A= > >>> James=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>> -----Or= iginal Message-----=0D=0A> >>>> From: Hannes Tschofenig [mailto:Hannes.Tsch= ofenig@gmx.net]=0D=0A> >>>> Sent: Monday, 4 June 2007 9:03 PM=0D=0A> >>>> T= o: Winterbottom, James=0D=0A> >>>> Cc: ECRIT=0D=0A> >>>> Subject: Re: [Ecri= t] Location Hiding - another look=0D=0A> >>>>=0D=0A> >>>> Sounds like you e= nvision that only authorized entities are=0D=0Aallowed=0D=0A> >>>>=0D=0A> >= to=0D=0A> >=0D=0A> >>>> resolve a LbyR regardless of the granularity of th= e requested=0D=0A> >>>>=0D=0A> >>>>=0D=0A> >>> information.=0D=0A> >>>=0D=0A= > >>>=0D=0A> >>>> Ciao=0D=0A> >>>> Hannes=0D=0A> >>>>=0D=0A> >>>> Winterbot= tom, James wrote:=0D=0A> >>>>=0D=0A> >>>>=0D=0A> >>>>> Hi Hannes,=0D=0A> >>= >>>=0D=0A> >>>>> Kind of.=0D=0A> >>>>> A LIS that is providing location inf= ormation in a local area is=0D=0A> >>>>>=0D=0A> > far=0D=0A> >=0D=0A> >>> m= ore=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>>> likely to have a relationship with a= local emergency authority=0D=0Aand=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>> be=0D= =0A> >>>=0D=0A> >>>=0D=0A> >>>>> able to determine that they are entitled t= o location=0D=0Ainformation,=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>> than=0D=0A= > >>>=0D=0A> >>>=0D=0A> >>>>> it is to be able to determine that a VSP in S= ierra Leone is=0D=0A> >>>>>=0D=0A> > entitled=0D=0A> >=0D=0A> >>> to=0D=0A>= >>>=0D=0A> >>>=0D=0A> >>>>> location information. To me there is a very si= zeable difference=0D=0Ain=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>> these=0D=0A>= >>>=0D=0A> >>>=0D=0A> >>>>> approaches.=0D=0A> >>>>>=0D=0A> >>>>> Hope thi= s helps=0D=0A> >>>>>=0D=0A> >>>>> James=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>= >>>=0D=0A> >>>>>=0D=0A> >>>>>> -----Original Message-----=0D=0A> >>>>>> Fro= m: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> >>>>>> Sent:= Monday, 4 June 2007 8:01 PM=0D=0A> >>>>>> To: Winterbottom, James=0D=0A> >= >>>>> Cc: ECRIT=0D=0A> >>>>>> Subject: Re: [Ecrit] Location Hiding - anothe= r look=0D=0A> >>>>>>=0D=0A> >>>>>> Hi James,=0D=0A> >>>>>>=0D=0A> >>>>>> wh= at relationship do you mean=3F=0D=0A> >>>>>> Is it because of the ability t= o obtain location information by=0D=0A> >>>>>>=0D=0A> > the=0D=0A> >=0D=0A>= >>> VSP=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>>>> such that call routing can tak= e place=3F=0D=0A> >>>>>> Didn't we discuss the ability of the ASP/ISP to di= fferentiate a=0D=0A> >>>>>>=0D=0A> >>>>>>=0D=0A> >>>>>>=0D=0A> >>>>> reques= t=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>>>>> and to return precis= e location only for authorized nodes where=0D=0Aas=0D=0A> >>>>>> unauthoriz= ed nodes would only obtain location information that=0D=0Ais=0D=0A> >>>>>> = sufficient for emergency call routing.=0D=0A> >>>>>>=0D=0A> >>>>>> Ciao=0D=0A= > >>>>>> Hannes=0D=0A> >>>>>>=0D=0A> >>>>>> Winterbottom, James wrote:=0D=0A= > >>>>>>=0D=0A> >>>>>>=0D=0A> >>>>>>=0D=0A> >>>>>>> Hi Hannes,=0D=0A> >>>>>= >>=0D=0A> >>>>>>> I would prefer not to have an association between the VSP= and=0D=0A> >>>>>>>=0D=0A> >>>>>>>=0D=0A> >>>>>>>=0D=0A> >>>>> ISP/ASP if=0D= =0A> >>>>>=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>>>>>> we don't need to. If th= e end-point can obtain the PSAP URI or=0D=0A> >>>>>>>=0D=0A> > the=0D=0A> >=0D= =0A> >>>>>>>=0D=0A> >>>>> ESRP=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A= > >>>>>>> Uri then the relationship between VSP and ISP doesn't need to=0D=0A= > >>>>>>>=0D=0A> >>>>>>>=0D=0A> >>> exist.=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>= >> The=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>>>>>> relationship i= s between the ISP/ASP and the local PSAP.=0D=0A> >>>>>>>=0D=0A> >>>>>>> Che= ers=0D=0A> >>>>>>> James=0D=0A> >>>>>>>=0D=0A> >>>>>>>=0D=0A> >>>>>>>=0D=0A= > >>>>>>>=0D=0A> >>>>>>>=0D=0A> >>>>>>>=0D=0A> >>>>>>>> -----Original Messa= ge-----=0D=0A> >>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@g= mx.net]=0D=0A> >>>>>>>> Sent: Monday, 4 June 2007 7:40 PM=0D=0A> >>>>>>>> T= o: ECRIT=0D=0A> >>>>>>>> Subject: [Ecrit] Location Hiding - another look=0D= =0A> >>>>>>>>=0D=0A> >>>>>>>> Hi all,=0D=0A> >>>>>>>>=0D=0A> >>>>>>>> with = location hiding we assumed that the network operator=0D=0Adoes=0D=0A> >>>>>= >>>=0D=0A> >>>>>>>>=0D=0A> >>> not=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>>>>> wan= t=0D=0A> >>>>>>>=0D=0A> >>>>>>>=0D=0A> >>>>>>>=0D=0A> >>>>>>>=0D=0A> >>>>>>= >> to provide information about the precise location information=0D=0A> >>>= >>>>>=0D=0A> > to=0D=0A> >=0D=0A> >>>>>>>>=0D=0A> >>>>> the=0D=0A> >>>>>=0D= =0A> >>>>>=0D=0A> >>>>>=0D=0A> >>>>>>> end=0D=0A> >>>>>>>=0D=0A> >>>>>>>=0D= =0A> >>>>>>>=0D=0A> >>>>>>>=0D=0A> >>>>>>>> point.=0D=0A> >>>>>>>> A lot of= discussions focused on the question how it can still=0D=0A> >>>>>>>>=0D=0A= > >>>>>>>>=0D=0A> >>>>>>>>=0D=0A> >>>>> obtain a=0D=0A> >>>>>=0D=0A> >>>>>=0D= =0A> >>>>>=0D=0A> >>>>>>>> PSAP URI in that case.=0D=0A> >>>>>>>>=0D=0A> >>= >>>>>> There is, however, the question why the end point needs to=0D=0A> >>= >>>>>>=0D=0A> > obtain=0D=0A> >=0D=0A> >>>>>>>>=0D=0A> >>>>> this=0D=0A> >>= >>>=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>>>>>>> PSAP URI in the location hidi= ng case at all.=0D=0A> >>>>>>>> Why cannot we just assume that the VSP has = to obtain some=0D=0A> >>>>>>>>=0D=0A> >>>>>>>>=0D=0A> >>> location=0D=0A> >= >>=0D=0A> >>>=0D=0A> >>>>>>>> information from the ASP/ISP via LbyR and the= n it runs a LoST=0D=0A> >>>>>>>>=0D=0A> >>>>>>>>=0D=0A> >>> query=0D=0A> >>= >=0D=0A> >>>=0D=0A> >>>>> as=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> = >>>>>>>> we specified it.=0D=0A> >>>>>>>>=0D=0A> >>>>>>>> DONE=0D=0A> >>>>>= >>>=0D=0A> >>>>>>>> Ciao=0D=0A> >>>>>>>> Hannes=0D=0A> >>>>>>>>=0D=0A> >>>>= >>>>=0D=0A> >>>>>>>> _______________________________________________=0D=0A>= >>>>>>>> Ecrit mailing list=0D=0A> >>>>>>>> Ecrit@ietf.org=0D=0A> >>>>>>>>= https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> >>>>>>>>=0D=0A> >>>>>>= >>=0D=0A> >>>>>>>>=0D=0A> >>>>>>>>=0D=0A> >=0D=0A--------------------------= ----------------------------------------------=0D=0A> >=0D=0A> >>>>>> -----= -------------------=0D=0A> >>>>>>=0D=0A> >>>>>>=0D=0A> >>>>>>=0D=0A> >>>>>>= > This message is for the designated recipient only and may=0D=0A> >>>>>>> = contain privileged, proprietary, or otherwise private=0D=0A> >>>>>>>=0D=0A>= > information.=0D=0A> >=0D=0A> >>>>>>> If you have received it in error, p= lease notify the sender=0D=0A> >>>>>>> immediately and delete the original.= Any unauthorized use of=0D=0A> >>>>>>> this email is prohibited.=0D=0A> >= >>>>>>=0D=0A> >>>>>>>=0D=0A> >>>>>>>=0D=0A> >>>>>>>=0D=0A> >=0D=0A---------= ---------------------------------------------------------------=0D=0A> >=0D= =0A> >>>>>> ------------------------=0D=0A> >>>>>>=0D=0A> >>>>>>=0D=0A> >>>= >>>=0D=0A> >>>>>>> [mf2]=0D=0A> >>>>>>>=0D=0A> >>>>>>>=0D=0A> >>>>>>>=0D=0A= > >>>>>>>=0D=0A> >>>>>>>=0D=0A> >=0D=0A------------------------------------= ------------------------------------=0D=0A> >=0D=0A> >>>> -----------------= -------=0D=0A> >>>>=0D=0A> >>>>=0D=0A> >>>>> This message is for the design= ated recipient only and may=0D=0A> >>>>> contain privileged, proprietary, o= r otherwise private=0D=0Ainformation.=0D=0A> >>>>> If you have received it = in error, please notify the sender=0D=0A> >>>>> immediately and delete the = original. Any unauthorized use of=0D=0A> >>>>> this email is prohibited.=0D= =0A> >>>>>=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >=0D=0A------------------------= ------------------------------------------------=0D=0A> >=0D=0A> >>>> -----= -------------------=0D=0A> >>>>=0D=0A> >>>>=0D=0A> >>>>> [mf2]=0D=0A> >>>>>=0D= =0A> >>>>>=0D=0A> >>>>>=0D=0A> >>>>>=0D=0A> >>>=0D=0A> >=0D=0A-------------= -----------------------------------------------------------=0D=0A> >=0D=0A>= >> ------------------------=0D=0A> >>=0D=0A> >>> This message is for the d= esignated recipient only and may=0D=0A> >>> contain privileged, proprietary= , or otherwise private information.=0D=0A> >>> If you have received it in e= rror, please notify the sender=0D=0A> >>> immediately and delete the origin= al. Any unauthorized use of=0D=0A> >>> this email is prohibited.=0D=0A> >>= >=0D=0A> >>>=0D=0A> >=0D=0A------------------------------------------------= ------------------------=0D=0A> >=0D=0A> >> ------------------------=0D=0A>= >>=0D=0A> >>> [mf2]=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>=0D=0A> >=0D=0A> >=0D=0A= ------------------------------------------------------------------------=0D= =0A> ------------------------=0D=0A> > This message is for the designated r= ecipient only and may=0D=0A> > contain privileged, proprietary, or otherwis= e private information.=0D=0A> > If you have received it in error, please no= tify the sender=0D=0A> > immediately and delete the original. Any unauthor= ized use of=0D=0A> > this email is prohibited.=0D=0A> >=0D=0A--------------= ----------------------------------------------------------=0D=0A> ---------= ---------------=0D=0A> > [mf2]=0D=0A> >=0D=0A> >=0D=0A>=20=0D=0A=0D=0A-----= ---------------------------------------------------------------------------= ----------------=0D=0AThis message is for the designated recipient only and= may=0D=0Acontain privileged, proprietary, or otherwise private information= =2E =20=0D=0AIf you have received it in error, please notify the sender=0D=0A= immediately and delete the original. Any unauthorized use of=0D=0Athis ema= il is prohibited.=0D=0A----------------------------------------------------= --------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 04 11:28:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvETV-0005c4-4B; Mon, 04 Jun 2007 11:28:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvETT-0005WI-DB for ecrit@ietf.org; Mon, 04 Jun 2007 11:28:03 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvETR-0004sZ-W2 for ecrit@ietf.org; Mon, 04 Jun 2007 11:28:03 -0400 Received: from ([139.76.131.83]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.23351016; Mon, 04 Jun 2007 11:27:43 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 4 Jun 2007 11:27:17 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 4 Jun 2007 11:27:17 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Location Hiding - another look Date: Mon, 4 Jun 2007 11:27:16 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA043E833F@crexc41p> In-Reply-To: <4663DE0A.1050409@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Hiding - another look thread-index: AcemjGXktAvkSTKPQkWhB5FxX6pwaAAMF+8w References: <4663DE0A.1050409@gmx.net> From: "Stark, Barbara" To: "Hannes Tschofenig" ,"ECRIT" X-OriginalArrivalTime: 04 Jun 2007 15:27:17.0090 (UTC) FILETIME=[D597B420:01C7A6BC] X-Spam-Score: 0.6 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think it's important for the end point to be able to get the PSAP URI, because there may not be a VSP, at all. I don't think the architecture should require that there be a VSP in order to make a SIP call over the Internet. Certainly, VSPs are needed to get to PSAPs on the legacy phone network. But once PSAPs are reachable directly by VoIP, the architecture should allow end devices with open Internet access, but no VSP, to make emergency calls. Barbara=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Monday, June 04, 2007 5:40 AM To: ECRIT Subject: [Ecrit] Location Hiding - another look Hi all, with location hiding we assumed that the network operator does not want to provide information about the precise location information to the end point. A lot of discussions focused on the question how it can still obtain a PSAP URI in that case. There is, however, the question why the end point needs to obtain this PSAP URI in the location hiding case at all. Why cannot we just assume that the VSP has to obtain some location information from the ASP/ISP via LbyR and then it runs a LoST query as we specified it. DONE Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA622 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 04 16:12:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIv4-0005m7-N8; Mon, 04 Jun 2007 16:12:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvIv3-0005lj-Ja for ecrit@ietf.org; Mon, 04 Jun 2007 16:12:49 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvIv1-000886-BA for ecrit@ietf.org; Mon, 04 Jun 2007 16:12:49 -0400 Received: (qmail invoked by alias); 04 Jun 2007 20:12:41 -0000 Received: from p549860C3.dip.t-dialin.net (EHLO [192.168.178.24]) [84.152.96.195] by mail.gmx.net (mp044) with SMTP; 04 Jun 2007 22:12:41 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+/XYdKLMa/dUoPzG9CL8YVRzzHow2VAFzeVYbDv4 Jg+vw8mN1/SwNT Message-ID: <46647238.80808@gmx.net> Date: Mon, 04 Jun 2007 22:12:40 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Stark, Barbara" Subject: Re: [Ecrit] Location Hiding - another look References: <4663DE0A.1050409@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p> In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Barbara, Stark, Barbara wrote: > I think it's important for the end point to be able to get the PSAP URI, > because there may not be a VSP, at all. For the case where there is no VSP, also referred as the unauthenticated emergency service architecture, the access network provider has to provide emergency service support directly or indirectly (via a partnership with another emergency service infrastructure provider). You additionally have to consider the case where link layer authentication can also be bypassed since you might loose more than just the credentials of the VSP. > I don't think the architecture > should require that there be a VSP in order to make a SIP call over the > Internet. Certainly, VSPs are needed to get to PSAPs on the legacy phone > network. But once PSAPs are reachable directly by VoIP, the architecture > should allow end devices with open Internet access, but no VSP, to make > emergency calls. > Ciao Hannes > Barbara > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Monday, June 04, 2007 5:40 AM > To: ECRIT > Subject: [Ecrit] Location Hiding - another look > > Hi all, > > with location hiding we assumed that the network operator does not want > to provide information about the precise location information to the end > point. > A lot of discussions focused on the question how it can still obtain a > PSAP URI in that case. > > There is, however, the question why the end point needs to obtain this > PSAP URI in the location hiding case at all. > Why cannot we just assume that the VSP has to obtain some location > information from the ASP/ISP via LbyR and then it runs a LoST query as > we specified it. > > DONE > > Ciao > Hannes > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > ***** > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 04 16:42:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJNw-0004ac-3h; Mon, 04 Jun 2007 16:42:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvJNv-0004aX-Ck for ecrit@ietf.org; Mon, 04 Jun 2007 16:42:39 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvJNt-0004EB-TZ for ecrit@ietf.org; Mon, 04 Jun 2007 16:42:39 -0400 Received: (qmail invoked by alias); 04 Jun 2007 20:42:36 -0000 Received: from p549860c3.dip.t-dialin.net (EHLO [192.168.178.24]) [84.152.96.195] by mail.gmx.net (mp057) with SMTP; 04 Jun 2007 22:42:36 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19h3w9iS+9hZxr1LTC8sZfmokIKHyTexVwpi6mPIl 1BS3qVnahw9zdO Message-ID: <4664793A.10502@gmx.net> Date: Mon, 04 Jun 2007 22:42:34 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: ECRIT , GEOPRIV Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Ecrit] [Fwd: [Emu] Liaison statement from IEEE 802.11u on "EAP emergency method"] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org FYI -------- Original Message -------- Subject: [Emu] Liaison statement from IEEE 802.11u on "EAP emergency method" Date: Mon, 4 Jun 2007 10:26:51 -0700 From: Joseph Salowey (jsalowey) To: CC: eap@frascone.com The liaison statement from the IEEE 802.11u on "EAP emergency Method" is now available at https://datatracker.ietf.org/public/liaisons.cgi. One of the documents on requirements appears to be missing on the liaison page (the requirements presentation). I will work on getting this updated. Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 04 17:22:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvK0v-0004xl-E5; Mon, 04 Jun 2007 17:22:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvK0u-0004x6-4g for ecrit@ietf.org; Mon, 04 Jun 2007 17:22:56 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvK0t-0001pj-Rl for ecrit@ietf.org; Mon, 04 Jun 2007 17:22:56 -0400 Received: from [204.8.159.23] (temp-openyrless-dhcp23.bu.edu [204.8.159.23]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l54LMlGv014742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 4 Jun 2007 17:22:47 -0400 (EDT) In-Reply-To: <46647238.80808@gmx.net> References: <4663DE0A.1050409@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p> <46647238.80808@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8EF09A27-92D2-4590-A20F-31D377B576B3@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Location Hiding - another look Date: Mon, 4 Jun 2007 17:22:57 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'm confused. Having 'no VSP' seems like a completely different issue from 'no network authentication', which deals with access to the physical/link/network layer. I'm actually not even sure what 'no VSP' means. No outbound proxy? On Jun 4, 2007, at 4:12 PM, Hannes Tschofenig wrote: > Hi Barbara, > > Stark, Barbara wrote: >> I think it's important for the end point to be able to get the >> PSAP URI, >> because there may not be a VSP, at all. > > For the case where there is no VSP, also referred as the > unauthenticated emergency service architecture, the access network > provider has to provide emergency service support directly or > indirectly (via a partnership with another emergency service > infrastructure provider). > > You additionally have to consider the case where link layer > authentication can also be bypassed since you might loose more than > just the credentials of the VSP. > >> I don't think the architecture >> should require that there be a VSP in order to make a SIP call >> over the >> Internet. Certainly, VSPs are needed to get to PSAPs on the legacy >> phone >> network. But once PSAPs are reachable directly by VoIP, the >> architecture >> should allow end devices with open Internet access, but no VSP, to >> make >> emergency calls. >> > > Ciao > Hannes > >> Barbara >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: >> Monday, June 04, 2007 5:40 AM >> To: ECRIT >> Subject: [Ecrit] Location Hiding - another look >> >> Hi all, >> >> with location hiding we assumed that the network operator does not >> want >> to provide information about the precise location information to >> the end >> point. >> A lot of discussions focused on the question how it can still >> obtain a >> PSAP URI in that case. >> >> There is, however, the question why the end point needs to obtain >> this >> PSAP URI in the location hiding case at all. >> Why cannot we just assume that the VSP has to obtain some location >> information from the ASP/ISP via LbyR and then it runs a LoST >> query as >> we specified it. >> >> DONE >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> ***** >> >> The information transmitted is intended only for the person or >> entity to which it is addressed and may contain confidential, >> proprietary, and/or privileged material. Any review, >> retransmission, dissemination or other use of, or taking of any >> action in reliance upon this information by persons or entities >> other than the intended recipient is prohibited. If you received >> this in error, please contact the sender and delete the material >> from all computers. GA621 >> >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 04 21:42:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvO47-0007R4-2P; Mon, 04 Jun 2007 21:42:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvO45-0007Qz-Aj for ecrit@ietf.org; Mon, 04 Jun 2007 21:42:29 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvO44-000289-VQ for ecrit@ietf.org; Mon, 04 Jun 2007 21:42:29 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HvO1D-0005r7-0x; Mon, 04 Jun 2007 20:39:31 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'Stark, Barbara'" References: <4663DE0A.1050409@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p> <46647238.80808@gmx.net> Subject: RE: [Ecrit] Location Hiding - another look Date: Mon, 4 Jun 2007 21:42:23 -0400 Message-ID: <179e01c7a712$c557bd20$6601a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <46647238.80808@gmx.net> Thread-Index: Acem5FdBfGId6lFiQQa0B8ArOyWIwAALgoig X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I don't understand where this is going. If the access network supplies coarse location to a non-authenticated querier which is sufficient for routing or for validation, then it doesn't matter if it's the endpoint or the VSP that is doing the routing or the validating. Neither the VSP nor the endpoint is an authorized querier to the access network. They are of equal status, they get the same result. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Monday, June 04, 2007 4:13 PM > To: Stark, Barbara > Cc: ECRIT > Subject: Re: [Ecrit] Location Hiding - another look > > Hi Barbara, > > Stark, Barbara wrote: > > I think it's important for the end point to be able to get the PSAP URI, > > because there may not be a VSP, at all. > > For the case where there is no VSP, also referred as the unauthenticated > emergency service architecture, the access network provider has to > provide emergency service support directly or indirectly (via a > partnership with another emergency service infrastructure provider). > > You additionally have to consider the case where link layer > authentication can also be bypassed since you might loose more than just > the credentials of the VSP. > > > I don't think the architecture > > should require that there be a VSP in order to make a SIP call over the > > Internet. Certainly, VSPs are needed to get to PSAPs on the legacy phone > > network. But once PSAPs are reachable directly by VoIP, the architecture > > should allow end devices with open Internet access, but no VSP, to make > > emergency calls. > > > > Ciao > Hannes > > > Barbara > > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Monday, June 04, 2007 5:40 AM > > To: ECRIT > > Subject: [Ecrit] Location Hiding - another look > > > > Hi all, > > > > with location hiding we assumed that the network operator does not want > > to provide information about the precise location information to the end > > point. > > A lot of discussions focused on the question how it can still obtain a > > PSAP URI in that case. > > > > There is, however, the question why the end point needs to obtain this > > PSAP URI in the location hiding case at all. > > Why cannot we just assume that the VSP has to obtain some location > > information from the ASP/ISP via LbyR and then it runs a LoST query as > > we specified it. > > > > DONE > > > > Ciao > > Hannes > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > ***** > > > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential, proprietary, and/or > privileged material. Any review, retransmission, dissemination or other > use of, or taking of any action in reliance upon this information by > persons or entities other than the intended recipient is prohibited. If > you received this in error, please contact the sender and delete the > material from all computers. GA621 > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 04 23:07:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvPOA-0005rM-QB; Mon, 04 Jun 2007 23:07:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvPO9-0005o7-UF for ecrit@ietf.org; Mon, 04 Jun 2007 23:07:17 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvPO9-0004pV-J2 for ecrit@ietf.org; Mon, 04 Jun 2007 23:07:17 -0400 X-SEF-Processed: 5_0_0_910__2007_06_04_22_14_46 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 04 Jun 2007 22:14:46 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 4 Jun 2007 22:07:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Location Hiding - another look Date: Mon, 4 Jun 2007 22:07:11 -0500 Message-ID: In-Reply-To: <179e01c7a712$c557bd20$6601a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Hiding - another look Thread-Index: Acem5FdBfGId6lFiQQa0B8ArOyWIwAALgoigAAMGyzA= References: <4663DE0A.1050409@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p><46647238.80808@gmx.net> <179e01c7a712$c557bd20$6601a8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Hannes Tschofenig" , "Stark, Barbara" X-OriginalArrivalTime: 05 Jun 2007 03:07:16.0567 (UTC) FILETIME=[9F3B4E70:01C7A71E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I am at a loss to understand why either needs a coarse location if the=0D=0A= PSAP URI is provided directly to the end-point.=0D=0A=0D=0A> -----Original = Message-----=0D=0A> From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> Sen= t: Tuesday, 5 June 2007 11:42 AM=0D=0A> To: 'Hannes Tschofenig'; 'Stark, Ba= rbara'=0D=0A> Cc: 'ECRIT'=0D=0A> Subject: RE: [Ecrit] Location Hiding - ano= ther look=0D=0A>=20=0D=0A> I don't understand where this is going.=0D=0A> I= f the access network supplies coarse location to a non-authenticated=0D=0A>= querier which is sufficient for routing or for validation, then it=0D=0Ado= esn't=0D=0A> matter if it's the endpoint or the VSP that is doing the routi= ng or=0D=0Athe=0D=0A> validating.=0D=0A>=20=0D=0A> Neither the VSP nor the = endpoint is an authorized querier to the=0D=0Aaccess=0D=0A> network. They = are of equal status, they get the same result.=0D=0A>=20=0D=0A> Brian=0D=0A= >=20=0D=0A> > -----Original Message-----=0D=0A> > From: Hannes Tschofenig [= mailto:Hannes.Tschofenig@gmx.net]=0D=0A> > Sent: Monday, June 04, 2007 4:13= PM=0D=0A> > To: Stark, Barbara=0D=0A> > Cc: ECRIT=0D=0A> > Subject: Re: [E= crit] Location Hiding - another look=0D=0A> >=0D=0A> > Hi Barbara,=0D=0A> >=0D= =0A> > Stark, Barbara wrote:=0D=0A> > > I think it's important for the end = point to be able to get the=0D=0APSAP=0D=0A> URI,=0D=0A> > > because there = may not be a VSP, at all.=0D=0A> >=0D=0A> > For the case where there is no = VSP, also referred as the=0D=0Aunauthenticated=0D=0A> > emergency service a= rchitecture, the access network provider has to=0D=0A> > provide emergency = service support directly or indirectly (via a=0D=0A> > partnership with ano= ther emergency service infrastructure provider).=0D=0A> >=0D=0A> > You addi= tionally have to consider the case where link layer=0D=0A> > authentication= can also be bypassed since you might loose more than=0D=0Ajust=0D=0A> > th= e credentials of the VSP.=0D=0A> >=0D=0A> > > I don't think the architectu= re=0D=0A> > > should require that there be a VSP in order to make a SIP cal= l=0D=0Aover=0D=0A> the=0D=0A> > > Internet. Certainly, VSPs are needed to g= et to PSAPs on the legacy=0D=0A> phone=0D=0A> > > network. But once PSAPs a= re reachable directly by VoIP, the=0D=0A> architecture=0D=0A> > > should al= low end devices with open Internet access, but no VSP, to=0D=0A> make=0D=0A= > > > emergency calls.=0D=0A> > >=0D=0A> >=0D=0A> > Ciao=0D=0A> > Hannes=0D= =0A> >=0D=0A> > > Barbara=0D=0A> > >=0D=0A> > > -----Original Message-----=0D= =0A> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> = > > Sent: Monday, June 04, 2007 5:40 AM=0D=0A> > > To: ECRIT=0D=0A> > > Sub= ject: [Ecrit] Location Hiding - another look=0D=0A> > >=0D=0A> > > Hi all,=0D= =0A> > >=0D=0A> > > with location hiding we assumed that the network operat= or does not=0D=0A> want=0D=0A> > > to provide information about the precise= location information to=0D=0Athe=0D=0A> end=0D=0A> > > point.=0D=0A> > > A= lot of discussions focused on the question how it can still=0D=0Aobtain a=0D= =0A> > > PSAP URI in that case.=0D=0A> > >=0D=0A> > > There is, however, th= e question why the end point needs to obtain=0D=0Athis=0D=0A> > > PSAP URI = in the location hiding case at all.=0D=0A> > > Why cannot we just assume th= at the VSP has to obtain some location=0D=0A> > > information from the ASP/= ISP via LbyR and then it runs a LoST=0D=0Aquery as=0D=0A> > > we specified = it.=0D=0A> > >=0D=0A> > > DONE=0D=0A> > >=0D=0A> > > Ciao=0D=0A> > > Hannes=0D= =0A> > >=0D=0A> > >=0D=0A> > > ____________________________________________= ___=0D=0A> > > Ecrit mailing list=0D=0A> > > Ecrit@ietf.org=0D=0A> > > http= s://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > >=0D=0A> > > *****=0D=0A>= > >=0D=0A> > > The information transmitted is intended only for the person= or=0D=0Aentity=0D=0A> to=0D=0A> > which it is addressed and may contain co= nfidential, proprietary,=0D=0Aand/or=0D=0A> > privileged material. Any revi= ew, retransmission, dissemination or=0D=0Aother=0D=0A> > use of, or taking = of any action in reliance upon this information by=0D=0A> > persons or enti= ties other than the intended recipient is prohibited.=0D=0AIf=0D=0A> > you = received this in error, please contact the sender and delete the=0D=0A> > m= aterial from all computers. GA621=0D=0A> > >=0D=0A> > >=0D=0A> >=0D=0A> >=0D= =0A> > _______________________________________________=0D=0A> > Ecrit maili= ng list=0D=0A> > Ecrit@ietf.org=0D=0A> > https://www1.ietf.org/mailman/list= info/ecrit=0D=0A>=20=0D=0A>=20=0D=0A> _____________________________________= __________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://w= ww1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A----------------------------= --------------------------------------------------------------------=0D=0AT= his message is for the designated recipient only and may=0D=0Acontain privi= leged, proprietary, or otherwise private information. =20=0D=0AIf you have = received it in error, please notify the sender=0D=0Aimmediately and delete = the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 02:45:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvSnV-0002pq-Tl; Tue, 05 Jun 2007 02:45:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvSnV-0002pl-Dd for ecrit@ietf.org; Tue, 05 Jun 2007 02:45:41 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvSnU-00008R-VG for ecrit@ietf.org; Tue, 05 Jun 2007 02:45:41 -0400 Received: (qmail invoked by alias); 05 Jun 2007 06:45:39 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp056) with SMTP; 05 Jun 2007 08:45:39 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18MG2EbzsEMU7ZxJ6ouHedeS8ex91+xoq4OSJItO+ RfTIQuu13CAe5p Message-ID: <46650691.4040601@gmx.net> Date: Tue, 05 Jun 2007 08:45:37 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Location Hiding - another look References: <4663DE0A.1050409@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p> <46647238.80808@gmx.net> <8EF09A27-92D2-4590-A20F-31D377B576B3@cs.columbia.edu> In-Reply-To: <8EF09A27-92D2-4590-A20F-31D377B576B3@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org If you lost your credentials (or the configuration) then it could mean three things: a) You lost your credentials with your VSP b) You lost your ASP/ISP credentials c) You lost all your credentials including (VSP and ASP/ISP) Here is a past mail on this subject: http://www1.ietf.org/mail-archive/web/ecrit/current/msg03405.html Henning Schulzrinne wrote: > I'm confused. Having 'no VSP' seems like a completely different issue >> from 'no network authentication', which deals with access to the > physical/link/network layer. I'm actually not even sure what 'no VSP' > means. No outbound proxy? > > On Jun 4, 2007, at 4:12 PM, Hannes Tschofenig wrote: > >> Hi Barbara, >> >> Stark, Barbara wrote: >>> I think it's important for the end point to be able to get the PSAP >>> URI, >>> because there may not be a VSP, at all. >> >> For the case where there is no VSP, also referred as the >> unauthenticated emergency service architecture, the access network >> provider has to provide emergency service support directly or >> indirectly (via a partnership with another emergency service >> infrastructure provider). >> >> You additionally have to consider the case where link layer >> authentication can also be bypassed since you might loose more than >> just the credentials of the VSP. >> >>> I don't think the architecture >>> should require that there be a VSP in order to make a SIP call over the >>> Internet. Certainly, VSPs are needed to get to PSAPs on the legacy >>> phone >>> network. But once PSAPs are reachable directly by VoIP, the >>> architecture >>> should allow end devices with open Internet access, but no VSP, to make >>> emergency calls. >>> >> >> Ciao >> Hannes >> >>> Barbara >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: >>> Monday, June 04, 2007 5:40 AM >>> To: ECRIT >>> Subject: [Ecrit] Location Hiding - another look >>> >>> Hi all, >>> >>> with location hiding we assumed that the network operator does not want >>> to provide information about the precise location information to the >>> end >>> point. >>> A lot of discussions focused on the question how it can still obtain a >>> PSAP URI in that case. >>> >>> There is, however, the question why the end point needs to obtain this >>> PSAP URI in the location hiding case at all. >>> Why cannot we just assume that the VSP has to obtain some location >>> information from the ASP/ISP via LbyR and then it runs a LoST query as >>> we specified it. >>> >>> DONE >>> >>> Ciao >>> Hannes >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> ***** >>> >>> The information transmitted is intended only for the person or >>> entity to which it is addressed and may contain confidential, >>> proprietary, and/or privileged material. Any review, retransmission, >>> dissemination or other use of, or taking of any action in reliance >>> upon this information by persons or entities other than the intended >>> recipient is prohibited. If you received this in error, please >>> contact the sender and delete the material from all computers. GA621 >>> >>> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 02:52:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvSu5-0008CA-9L; Tue, 05 Jun 2007 02:52:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvSu3-0008Bt-Ep for ecrit@ietf.org; Tue, 05 Jun 2007 02:52:27 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvSu3-00019E-08 for ecrit@ietf.org; Tue, 05 Jun 2007 02:52:27 -0400 Received: (qmail invoked by alias); 05 Jun 2007 06:52:25 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp048) with SMTP; 05 Jun 2007 08:52:25 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX192nngj3Ah2GhJ4+ls6KrRBNjKR9MNsBr4DQYDHX4 i084CYLU+vDsVe Message-ID: <46650828.6050905@gmx.net> Date: Tue, 05 Jun 2007 08:52:24 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Location Hiding - another look References: <4663DE0A.1050409@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p> <46647238.80808@gmx.net> <179e01c7a712$c557bd20$6601a8c0@cis.neustar.com> In-Reply-To: <179e01c7a712$c557bd20$6601a8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian, Brian Rosen wrote: > I don't understand where this is going. > If the access network supplies coarse location to a non-authenticated > querier which is sufficient for routing or for validation, then it doesn't > matter if it's the endpoint or the VSP that is doing the routing or the > validating. > > It matters only that much that the end point has to implement LoST in this case. In the 3GPP case that also supports the SIM-less emergency call scenario they don't need LoST since the access network runs the P-CSCF and the E-CSCF. > Neither the VSP nor the endpoint is an authorized querier to the access > network. They are of equal status, they get the same result. > > Ciao Hannes > Brian > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Monday, June 04, 2007 4:13 PM >> To: Stark, Barbara >> Cc: ECRIT >> Subject: Re: [Ecrit] Location Hiding - another look >> >> Hi Barbara, >> >> Stark, Barbara wrote: >> >>> I think it's important for the end point to be able to get the PSAP URI, >>> because there may not be a VSP, at all. >>> >> For the case where there is no VSP, also referred as the unauthenticated >> emergency service architecture, the access network provider has to >> provide emergency service support directly or indirectly (via a >> partnership with another emergency service infrastructure provider). >> >> You additionally have to consider the case where link layer >> authentication can also be bypassed since you might loose more than just >> the credentials of the VSP. >> >> >>> I don't think the architecture >>> should require that there be a VSP in order to make a SIP call over the >>> Internet. Certainly, VSPs are needed to get to PSAPs on the legacy phone >>> network. But once PSAPs are reachable directly by VoIP, the architecture >>> should allow end devices with open Internet access, but no VSP, to make >>> emergency calls. >>> >>> >> Ciao >> Hannes >> >> >>> Barbara >>> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: Monday, June 04, 2007 5:40 AM >>> To: ECRIT >>> Subject: [Ecrit] Location Hiding - another look >>> >>> Hi all, >>> >>> with location hiding we assumed that the network operator does not want >>> to provide information about the precise location information to the end >>> point. >>> A lot of discussions focused on the question how it can still obtain a >>> PSAP URI in that case. >>> >>> There is, however, the question why the end point needs to obtain this >>> PSAP URI in the location hiding case at all. >>> Why cannot we just assume that the VSP has to obtain some location >>> information from the ASP/ISP via LbyR and then it runs a LoST query as >>> we specified it. >>> >>> DONE >>> >>> Ciao >>> Hannes >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> ***** >>> >>> The information transmitted is intended only for the person or entity to >>> >> which it is addressed and may contain confidential, proprietary, and/or >> privileged material. Any review, retransmission, dissemination or other >> use of, or taking of any action in reliance upon this information by >> persons or entities other than the intended recipient is prohibited. If >> you received this in error, please contact the sender and delete the >> material from all computers. GA621 >> >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 02:54:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvSve-0000xG-Lr; Tue, 05 Jun 2007 02:54:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvSvd-0000xB-D7 for ecrit@ietf.org; Tue, 05 Jun 2007 02:54:05 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvSvc-0001Wu-Tj for ecrit@ietf.org; Tue, 05 Jun 2007 02:54:05 -0400 Received: (qmail invoked by alias); 05 Jun 2007 06:54:04 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp012) with SMTP; 05 Jun 2007 08:54:04 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18WI3we2wIWy/7UYVPqMOj2ysIYOynOomnNyfGKwY 3pQXyc+V1lA5B9 Message-ID: <4665088B.4010104@gmx.net> Date: Tue, 05 Jun 2007 08:54:03 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Ecrit] Location Hiding - another look References: <4663DE0A.1050409@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p><46647238.80808@gmx.net> <179e01c7a712$c557bd20$6601a8c0@cis.neustar.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, the main discussion here is: * Some people want to enhance HELD by adding LoST functionality * Some others want to use LoST as is. Now we are at the stage where we try to find arguments when one solution is better than the other one. Ciao Hannes Winterbottom, James wrote: > I am at a loss to understand why either needs a coarse location if the > PSAP URI is provided directly to the end-point. > > >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Tuesday, 5 June 2007 11:42 AM >> To: 'Hannes Tschofenig'; 'Stark, Barbara' >> Cc: 'ECRIT' >> Subject: RE: [Ecrit] Location Hiding - another look >> >> I don't understand where this is going. >> If the access network supplies coarse location to a non-authenticated >> querier which is sufficient for routing or for validation, then it >> > doesn't > >> matter if it's the endpoint or the VSP that is doing the routing or >> > the > >> validating. >> >> Neither the VSP nor the endpoint is an authorized querier to the >> > access > >> network. They are of equal status, they get the same result. >> >> Brian >> >> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: Monday, June 04, 2007 4:13 PM >>> To: Stark, Barbara >>> Cc: ECRIT >>> Subject: Re: [Ecrit] Location Hiding - another look >>> >>> Hi Barbara, >>> >>> Stark, Barbara wrote: >>> >>>> I think it's important for the end point to be able to get the >>>> > PSAP > >> URI, >> >>>> because there may not be a VSP, at all. >>>> >>> For the case where there is no VSP, also referred as the >>> > unauthenticated > >>> emergency service architecture, the access network provider has to >>> provide emergency service support directly or indirectly (via a >>> partnership with another emergency service infrastructure provider). >>> >>> You additionally have to consider the case where link layer >>> authentication can also be bypassed since you might loose more than >>> > just > >>> the credentials of the VSP. >>> >>> >>>> I don't think the architecture >>>> should require that there be a VSP in order to make a SIP call >>>> > over > >> the >> >>>> Internet. Certainly, VSPs are needed to get to PSAPs on the legacy >>>> >> phone >> >>>> network. But once PSAPs are reachable directly by VoIP, the >>>> >> architecture >> >>>> should allow end devices with open Internet access, but no VSP, to >>>> >> make >> >>>> emergency calls. >>>> >>>> >>> Ciao >>> Hannes >>> >>> >>>> Barbara >>>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Monday, June 04, 2007 5:40 AM >>>> To: ECRIT >>>> Subject: [Ecrit] Location Hiding - another look >>>> >>>> Hi all, >>>> >>>> with location hiding we assumed that the network operator does not >>>> >> want >> >>>> to provide information about the precise location information to >>>> > the > >> end >> >>>> point. >>>> A lot of discussions focused on the question how it can still >>>> > obtain a > >>>> PSAP URI in that case. >>>> >>>> There is, however, the question why the end point needs to obtain >>>> > this > >>>> PSAP URI in the location hiding case at all. >>>> Why cannot we just assume that the VSP has to obtain some location >>>> information from the ASP/ISP via LbyR and then it runs a LoST >>>> > query as > >>>> we specified it. >>>> >>>> DONE >>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>> >>>> ***** >>>> >>>> The information transmitted is intended only for the person or >>>> > entity > >> to >> >>> which it is addressed and may contain confidential, proprietary, >>> > and/or > >>> privileged material. Any review, retransmission, dissemination or >>> > other > >>> use of, or taking of any action in reliance upon this information by >>> persons or entities other than the intended recipient is prohibited. >>> > If > >>> you received this in error, please contact the sender and delete the >>> material from all computers. GA621 >>> >>>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 03:00:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvT1t-0007H9-21; Tue, 05 Jun 2007 03:00:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvT1s-0007H4-5U for ecrit@ietf.org; Tue, 05 Jun 2007 03:00:32 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvT1r-0002FE-Pc for ecrit@ietf.org; Tue, 05 Jun 2007 03:00:32 -0400 X-SEF-Processed: 5_0_0_910__2007_06_05_02_08_01 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 05 Jun 2007 02:08:01 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jun 2007 02:00:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Location Hiding - another look Date: Tue, 5 Jun 2007 02:00:28 -0500 Message-ID: In-Reply-To: <4665088B.4010104@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Hiding - another look Thread-Index: AcenPk9oOAXLBxQvSXKz7f9dTeXvEwAAIGyg References: <4663DE0A.1050409@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p><46647238.80808@gmx.net> <179e01c7a712$c557bd20$6601a8c0@cis.neustar.com> <4665088B.4010104@gmx.net> From: "Winterbottom, James" To: "Hannes Tschofenig" X-OriginalArrivalTime: 05 Jun 2007 07:00:31.0164 (UTC) FILETIME=[34A957C0:01C7A73F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org =0D=0AI want to use LoST as is.=0D=0AI just don't see why HELD can't be use= d as a tool to hide locations from=0D=0Aservices that the location provider= does not want to offer.=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Message----= -=0D=0A> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> = Sent: Tuesday, 5 June 2007 4:54 PM=0D=0A> To: Winterbottom, James=0D=0A> Cc= : Brian Rosen; Stark, Barbara; ECRIT=0D=0A> Subject: Re: [Ecrit] Location H= iding - another look=0D=0A>=20=0D=0A> Brian,=0D=0A>=20=0D=0A> the main disc= ussion here is:=0D=0A>=20=0D=0A> * Some people want to enhance HELD by addi= ng LoST functionality=0D=0A> * Some others want to use LoST as is.=0D=0A> =0D= =0A> Now we are at the stage where we try to find arguments when one=0D=0As= olution=0D=0A> is better than the other one.=0D=0A>=20=0D=0A> Ciao=0D=0A> H= annes=0D=0A>=20=0D=0A> Winterbottom, James wrote:=0D=0A> > I am at a loss = to understand why either needs a coarse location if=0D=0Athe=0D=0A> > PSAP = URI is provided directly to the end-point.=0D=0A> >=0D=0A> >=0D=0A> >> ----= -Original Message-----=0D=0A> >> From: Brian Rosen [mailto:br@brianrosen.ne= t]=0D=0A> >> Sent: Tuesday, 5 June 2007 11:42 AM=0D=0A> >> To: 'Hannes Tsch= ofenig'; 'Stark, Barbara'=0D=0A> >> Cc: 'ECRIT'=0D=0A> >> Subject: RE: [Ecr= it] Location Hiding - another look=0D=0A> >>=0D=0A> >> I don't understand w= here this is going.=0D=0A> >> If the access network supplies coarse locatio= n to a=0D=0Anon-authenticated=0D=0A> >> querier which is sufficient for rou= ting or for validation, then it=0D=0A> >>=0D=0A> > doesn't=0D=0A> >=0D=0A> = >> matter if it's the endpoint or the VSP that is doing the routing or=0D=0A= > >>=0D=0A> > the=0D=0A> >=0D=0A> >> validating.=0D=0A> >>=0D=0A> >> Neithe= r the VSP nor the endpoint is an authorized querier to the=0D=0A> >>=0D=0A>= > access=0D=0A> >=0D=0A> >> network. They are of equal status, they get t= he same result.=0D=0A> >>=0D=0A> >> Brian=0D=0A> >>=0D=0A> >>=0D=0A> >>> --= ---Original Message-----=0D=0A> >>> From: Hannes Tschofenig [mailto:Hannes.= Tschofenig@gmx.net]=0D=0A> >>> Sent: Monday, June 04, 2007 4:13 PM=0D=0A> >= >> To: Stark, Barbara=0D=0A> >>> Cc: ECRIT=0D=0A> >>> Subject: Re: [Ecrit] = Location Hiding - another look=0D=0A> >>>=0D=0A> >>> Hi Barbara,=0D=0A> >>>=0D= =0A> >>> Stark, Barbara wrote:=0D=0A> >>>=0D=0A> >>>> I think it's importan= t for the end point to be able to get the=0D=0A> >>>>=0D=0A> > PSAP=0D=0A> = >=0D=0A> >> URI,=0D=0A> >>=0D=0A> >>>> because there may not be a VSP, at a= ll.=0D=0A> >>>>=0D=0A> >>> For the case where there is no VSP, also referre= d as the=0D=0A> >>>=0D=0A> > unauthenticated=0D=0A> >=0D=0A> >>> emergency = service architecture, the access network provider has to=0D=0A> >>> provide= emergency service support directly or indirectly (via a=0D=0A> >>> partner= ship with another emergency service infrastructure=0D=0Aprovider).=0D=0A> >= >>=0D=0A> >>> You additionally have to consider the case where link layer=0D= =0A> >>> authentication can also be bypassed since you might loose more=0D=0A= than=0D=0A> >>>=0D=0A> > just=0D=0A> >=0D=0A> >>> the credentials of the VS= P.=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>> I don't think the architecture=0D=0A>= >>>> should require that there be a VSP in order to make a SIP call=0D=0A>= >>>>=0D=0A> > over=0D=0A> >=0D=0A> >> the=0D=0A> >>=0D=0A> >>>> Internet. = Certainly, VSPs are needed to get to PSAPs on the=0D=0Alegacy=0D=0A> >>>>=0D= =0A> >> phone=0D=0A> >>=0D=0A> >>>> network. But once PSAPs are reachable d= irectly by VoIP, the=0D=0A> >>>>=0D=0A> >> architecture=0D=0A> >>=0D=0A> >>= >> should allow end devices with open Internet access, but no VSP,=0D=0Ato=0D= =0A> >>>>=0D=0A> >> make=0D=0A> >>=0D=0A> >>>> emergency calls.=0D=0A> >>>>=0D= =0A> >>>>=0D=0A> >>> Ciao=0D=0A> >>> Hannes=0D=0A> >>>=0D=0A> >>>=0D=0A> >>= >> Barbara=0D=0A> >>>>=0D=0A> >>>> -----Original Message-----=0D=0A> >>>> F= rom: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> >>>> Sent:= Monday, June 04, 2007 5:40 AM=0D=0A> >>>> To: ECRIT=0D=0A> >>>> Subject: [= Ecrit] Location Hiding - another look=0D=0A> >>>>=0D=0A> >>>> Hi all,=0D=0A= > >>>>=0D=0A> >>>> with location hiding we assumed that the network operato= r does=0D=0Anot=0D=0A> >>>>=0D=0A> >> want=0D=0A> >>=0D=0A> >>>> to provide= information about the precise location information to=0D=0A> >>>>=0D=0A> >= the=0D=0A> >=0D=0A> >> end=0D=0A> >>=0D=0A> >>>> point.=0D=0A> >>>> A lot = of discussions focused on the question how it can still=0D=0A> >>>>=0D=0A> = > obtain a=0D=0A> >=0D=0A> >>>> PSAP URI in that case.=0D=0A> >>>>=0D=0A> >= >>> There is, however, the question why the end point needs to obtain=0D=0A= > >>>>=0D=0A> > this=0D=0A> >=0D=0A> >>>> PSAP URI in the location hiding c= ase at all.=0D=0A> >>>> Why cannot we just assume that the VSP has to obtai= n some=0D=0Alocation=0D=0A> >>>> information from the ASP/ISP via LbyR and = then it runs a LoST=0D=0A> >>>>=0D=0A> > query as=0D=0A> >=0D=0A> >>>> we s= pecified it.=0D=0A> >>>>=0D=0A> >>>> DONE=0D=0A> >>>>=0D=0A> >>>> Ciao=0D=0A= > >>>> Hannes=0D=0A> >>>>=0D=0A> >>>>=0D=0A> >>>> _________________________= ______________________=0D=0A> >>>> Ecrit mailing list=0D=0A> >>>> Ecrit@iet= f.org=0D=0A> >>>> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> >>>>=0D= =0A> >>>> *****=0D=0A> >>>>=0D=0A> >>>> The information transmitted is inte= nded only for the person or=0D=0A> >>>>=0D=0A> > entity=0D=0A> >=0D=0A> >> = to=0D=0A> >>=0D=0A> >>> which it is addressed and may contain confidential,= proprietary,=0D=0A> >>>=0D=0A> > and/or=0D=0A> >=0D=0A> >>> privileged mat= erial. Any review, retransmission, dissemination or=0D=0A> >>>=0D=0A> > oth= er=0D=0A> >=0D=0A> >>> use of, or taking of any action in reliance upon thi= s information=0D=0Aby=0D=0A> >>> persons or entities other than the intende= d recipient is=0D=0Aprohibited.=0D=0A> >>>=0D=0A> > If=0D=0A> >=0D=0A> >>> = you received this in error, please contact the sender and delete=0D=0Athe=0D= =0A> >>> material from all computers. GA621=0D=0A> >>>=0D=0A> >>>>=0D=0A> >= >> _______________________________________________=0D=0A> >>> Ecrit mailing= list=0D=0A> >>> Ecrit@ietf.org=0D=0A> >>> https://www1.ietf.org/mailman/li= stinfo/ecrit=0D=0A> >>>=0D=0A> >> _________________________________________= ______=0D=0A> >> Ecrit mailing list=0D=0A> >> Ecrit@ietf.org=0D=0A> >> http= s://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> >>=0D=0A> >=0D=0A> >=0D=0A-= -----------------------------------------------------------------------=0D=0A= > ------------------------=0D=0A> > This message is for the designated reci= pient only and may=0D=0A> > contain privileged, proprietary, or otherwise p= rivate information.=0D=0A> > If you have received it in error, please notif= y the sender=0D=0A> > immediately and delete the original. Any unauthorize= d use of=0D=0A> > this email is prohibited.=0D=0A> >=0D=0A-----------------= -------------------------------------------------------=0D=0A> ------------= ------------=0D=0A> > [mf2]=0D=0A> >=0D=0A> >=0D=0A>=20=0D=0A=0D=0A--------= ---------------------------------------------------------------------------= -------------=0D=0AThis message is for the designated recipient only and ma= y=0D=0Acontain privileged, proprietary, or otherwise private information. =0D= =0AIf you have received it in error, please notify the sender=0D=0Aimmediat= ely and delete the original. Any unauthorized use of=0D=0Athis email is pr= ohibited.=0D=0A------------------------------------------------------------= ------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 03:01:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvT3C-0000RN-05; Tue, 05 Jun 2007 03:01:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvT3A-0000R1-Ej for ecrit@ietf.org; Tue, 05 Jun 2007 03:01:52 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvT39-0002Zo-Qj for ecrit@ietf.org; Tue, 05 Jun 2007 03:01:52 -0400 Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l5571neg014871; Tue, 5 Jun 2007 09:01:49 +0200 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id l5571npr001640; Tue, 5 Jun 2007 09:01:49 +0200 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 09:01:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Location Hiding - another look Date: Tue, 5 Jun 2007 09:01:48 +0200 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E701BEE1AA@MCHP7R6A.ww002.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Hiding - another look Thread-Index: AcenPk9oOAXLBxQvSXKz7f9dTeXvEwAAIGygAAAjBQA= From: "Tschofenig, Hannes" To: "ext Winterbottom, James" , "Hannes Tschofenig" X-OriginalArrivalTime: 05 Jun 2007 07:01:49.0549 (UTC) FILETIME=[6361F1D0:01C7A73F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Where is LoST used as is?=20 > I want to use LoST as is. > I just don't see why HELD can't be used as a tool to hide=20 > locations from > services that the location provider does not want to offer. >=20 >=20 >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Tuesday, 5 June 2007 4:54 PM > > To: Winterbottom, James > > Cc: Brian Rosen; Stark, Barbara; ECRIT > > Subject: Re: [Ecrit] Location Hiding - another look > >=20 > > Brian, > >=20 > > the main discussion here is: > >=20 > > * Some people want to enhance HELD by adding LoST functionality > > * Some others want to use LoST as is. > >=20 > > Now we are at the stage where we try to find arguments when one > solution > > is better than the other one. > >=20 > > Ciao > > Hannes > >=20 > > Winterbottom, James wrote: > > > I am at a loss to understand why either needs a coarse location if > the > > > PSAP URI is provided directly to the end-point. > > > > > > > > >> -----Original Message----- > > >> From: Brian Rosen [mailto:br@brianrosen.net] > > >> Sent: Tuesday, 5 June 2007 11:42 AM > > >> To: 'Hannes Tschofenig'; 'Stark, Barbara' > > >> Cc: 'ECRIT' > > >> Subject: RE: [Ecrit] Location Hiding - another look > > >> > > >> I don't understand where this is going. > > >> If the access network supplies coarse location to a > non-authenticated > > >> querier which is sufficient for routing or for=20 > validation, then it > > >> > > > doesn't > > > > > >> matter if it's the endpoint or the VSP that is doing the=20 > routing or > > >> > > > the > > > > > >> validating. > > >> > > >> Neither the VSP nor the endpoint is an authorized querier to the > > >> > > > access > > > > > >> network. They are of equal status, they get the same result. > > >> > > >> Brian > > >> > > >> > > >>> -----Original Message----- > > >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > >>> Sent: Monday, June 04, 2007 4:13 PM > > >>> To: Stark, Barbara > > >>> Cc: ECRIT > > >>> Subject: Re: [Ecrit] Location Hiding - another look > > >>> > > >>> Hi Barbara, > > >>> > > >>> Stark, Barbara wrote: > > >>> > > >>>> I think it's important for the end point to be able to get the > > >>>> > > > PSAP > > > > > >> URI, > > >> > > >>>> because there may not be a VSP, at all. > > >>>> > > >>> For the case where there is no VSP, also referred as the > > >>> > > > unauthenticated > > > > > >>> emergency service architecture, the access network=20 > provider has to > > >>> provide emergency service support directly or indirectly (via a > > >>> partnership with another emergency service infrastructure > provider). > > >>> > > >>> You additionally have to consider the case where link layer > > >>> authentication can also be bypassed since you might loose more > than > > >>> > > > just > > > > > >>> the credentials of the VSP. > > >>> > > >>> > > >>>> I don't think the architecture > > >>>> should require that there be a VSP in order to make a SIP call > > >>>> > > > over > > > > > >> the > > >> > > >>>> Internet. Certainly, VSPs are needed to get to PSAPs on the > legacy > > >>>> > > >> phone > > >> > > >>>> network. But once PSAPs are reachable directly by VoIP, the > > >>>> > > >> architecture > > >> > > >>>> should allow end devices with open Internet access, but no VSP, > to > > >>>> > > >> make > > >> > > >>>> emergency calls. > > >>>> > > >>>> > > >>> Ciao > > >>> Hannes > > >>> > > >>> > > >>>> Barbara > > >>>> > > >>>> -----Original Message----- > > >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > >>>> Sent: Monday, June 04, 2007 5:40 AM > > >>>> To: ECRIT > > >>>> Subject: [Ecrit] Location Hiding - another look > > >>>> > > >>>> Hi all, > > >>>> > > >>>> with location hiding we assumed that the network operator does > not > > >>>> > > >> want > > >> > > >>>> to provide information about the precise location=20 > information to > > >>>> > > > the > > > > > >> end > > >> > > >>>> point. > > >>>> A lot of discussions focused on the question how it can still > > >>>> > > > obtain a > > > > > >>>> PSAP URI in that case. > > >>>> > > >>>> There is, however, the question why the end point=20 > needs to obtain > > >>>> > > > this > > > > > >>>> PSAP URI in the location hiding case at all. > > >>>> Why cannot we just assume that the VSP has to obtain some > location > > >>>> information from the ASP/ISP via LbyR and then it runs a LoST > > >>>> > > > query as > > > > > >>>> we specified it. > > >>>> > > >>>> DONE > > >>>> > > >>>> Ciao > > >>>> Hannes > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Ecrit mailing list > > >>>> Ecrit@ietf.org > > >>>> https://www1.ietf.org/mailman/listinfo/ecrit > > >>>> > > >>>> ***** > > >>>> > > >>>> The information transmitted is intended only for the person or > > >>>> > > > entity > > > > > >> to > > >> > > >>> which it is addressed and may contain confidential, proprietary, > > >>> > > > and/or > > > > > >>> privileged material. Any review, retransmission,=20 > dissemination or > > >>> > > > other > > > > > >>> use of, or taking of any action in reliance upon this=20 > information > by > > >>> persons or entities other than the intended recipient is > prohibited. > > >>> > > > If > > > > > >>> you received this in error, please contact the sender and delete > the > > >>> material from all computers. GA621 > > >>> > > >>>> > > >>> _______________________________________________ > > >>> Ecrit mailing list > > >>> Ecrit@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/ecrit > > >>> > > >> _______________________________________________ > > >> Ecrit mailing list > > >> Ecrit@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/ecrit > > >> > > > > > > > -------------------------------------------------------------- > ---------- > > ------------------------ > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > -------------------------------------------------------------- > ---------- > > ------------------------ > > > [mf2] > > > > > > > >=20 >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 07:57:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvXbr-0007wv-Iu; Tue, 05 Jun 2007 07:53:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvXbq-0007wl-ES for ecrit@ietf.org; Tue, 05 Jun 2007 07:53:58 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvXbq-0005Td-13 for ecrit@ietf.org; Tue, 05 Jun 2007 07:53:58 -0400 Received: from ([139.76.131.31]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.23405838; Tue, 05 Jun 2007 07:53:34 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 5 Jun 2007 07:53:07 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 5 Jun 2007 07:53:07 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Location Hiding - another look Date: Tue, 5 Jun 2007 07:53:06 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA043E8473@crexc41p> In-Reply-To: <8EF09A27-92D2-4590-A20F-31D377B576B3@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Hiding - another look thread-index: Acem7oYVQ+F53g0BQKqGACFyV0x78AAeHhEw References: <4663DE0A.1050409@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p> <46647238.80808@gmx.net> <8EF09A27-92D2-4590-A20F-31D377B576B3@cs.columbia.edu> From: "Stark, Barbara" To: "Henning Schulzrinne" , "Hannes Tschofenig" X-OriginalArrivalTime: 05 Jun 2007 11:53:07.0865 (UTC) FILETIME=[15455090:01C7A768] X-Spam-Score: 0.6 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Sorry -- I didn't quote what I was responding to. I was responding to the statement: >> There is, however, the question why the end point needs to obtain=20 >> this PSAP URI in the location hiding case at all. >> Why cannot we just assume that the VSP has to obtain some location=20 >> information from the ASP/ISP via LbyR and then it runs a LoST query=20 >> as we specified it. I believe it's important for the end point to obtain the PSAP URI, because there may not be a VSP doing a LoST look-up. By VSP, I'm referring to the registration server, outbound proxy, etc. Or am I wrong on this point? If the endpoint has the PSAP URI, does it still need for these functions to exist between it and the PSAP URI? Barbara -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Monday, June 04, 2007 5:23 PM To: Hannes Tschofenig Cc: Stark, Barbara; ECRIT Subject: Re: [Ecrit] Location Hiding - another look I'm confused. Having 'no VSP' seems like a completely different issue from 'no network authentication', which deals with access to the physical/link/network layer. I'm actually not even sure what 'no VSP' =20 means. No outbound proxy? On Jun 4, 2007, at 4:12 PM, Hannes Tschofenig wrote: > Hi Barbara, > > Stark, Barbara wrote: >> I think it's important for the end point to be able to get the PSAP=20 >> URI, because there may not be a VSP, at all. > > For the case where there is no VSP, also referred as the=20 > unauthenticated emergency service architecture, the access network=20 > provider has to provide emergency service support directly or=20 > indirectly (via a partnership with another emergency service=20 > infrastructure provider). > > You additionally have to consider the case where link layer=20 > authentication can also be bypassed since you might loose more than=20 > just the credentials of the VSP. > >> I don't think the architecture >> should require that there be a VSP in order to make a SIP call over=20 >> the Internet. Certainly, VSPs are needed to get to PSAPs on the=20 >> legacy phone network. But once PSAPs are reachable directly by VoIP,=20 >> the architecture should allow end devices with open Internet access,=20 >> but no VSP, to make emergency calls. >> > > Ciao > Hannes > >> Barbara >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: =20 >> Monday, June 04, 2007 5:40 AM >> To: ECRIT >> Subject: [Ecrit] Location Hiding - another look >> >> Hi all, >> >> with location hiding we assumed that the network operator does not=20 >> want to provide information about the precise location information to >> the end point. >> A lot of discussions focused on the question how it can still obtain=20 >> a PSAP URI in that case. >> >> There is, however, the question why the end point needs to obtain=20 >> this PSAP URI in the location hiding case at all. >> Why cannot we just assume that the VSP has to obtain some location=20 >> information from the ASP/ISP via LbyR and then it runs a LoST query=20 >> as we specified it. >> >> DONE >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> ***** >> >> The information transmitted is intended only for the person or entity >> to which it is addressed and may contain confidential, proprietary,=20 >> and/or privileged material. Any review, retransmission, dissemination >> or other use of, or taking of any action in reliance upon this=20 >> information by persons or entities other than the intended recipient=20 >> is prohibited. If you received this in error, please contact the=20 >> sender and delete the material from all computers. GA621 >> >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA625 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 08:04:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvXlj-00088U-82; Tue, 05 Jun 2007 08:04:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvXli-00088H-19 for ecrit@ietf.org; Tue, 05 Jun 2007 08:04:10 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvXlg-0008L8-D1 for ecrit@ietf.org; Tue, 05 Jun 2007 08:04:09 -0400 Received: (qmail invoked by alias); 05 Jun 2007 12:04:07 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp047) with SMTP; 05 Jun 2007 14:04:07 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18lTMR2wvcl/BCqbvFPMsccPOqlgbtmRTnSc8JliW bTmbD+3LgNehyv Message-ID: <46655136.8090304@gmx.net> Date: Tue, 05 Jun 2007 14:04:06 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Stark, Barbara" Subject: Re: [Ecrit] Location Hiding - another look References: <4663DE0A.1050409@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p> <46647238.80808@gmx.net> <8EF09A27-92D2-4590-A20F-31D377B576B3@cs.columbia.edu> <7582BC68E4994F4ABF0BD4723975C3FA043E8473@crexc41p> In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA043E8473@crexc41p> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Barbara, > I believe it's important for the end point to obtain the PSAP URI, > because there may not be a VSP doing a LoST look-up. By VSP, I'm > referring to the registration server, outbound proxy, etc. > > Or am I wrong on this point? If the endpoint has the PSAP URI, does it > still need for these functions to exist between it and the PSAP URI? > Barbara > > These functions still have to exist since otherwise the end host would directly contact the PSAP and there wouldn't be an authenticated identity attached to the emergency call. This would be a serious security concern. Someone has to provide emergency service related functionality. From a deployment point of view it would be easier to have the VSP to support LoST than to have support for it at every end host. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 08:43:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvYNx-00073h-R5; Tue, 05 Jun 2007 08:43:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvYNw-0006uz-6x for ecrit@ietf.org; Tue, 05 Jun 2007 08:43:40 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvYNv-0005wN-M9 for ecrit@ietf.org; Tue, 05 Jun 2007 08:43:40 -0400 Received: (qmail invoked by alias); 05 Jun 2007 12:43:38 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp044) with SMTP; 05 Jun 2007 14:43:38 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+wPERxIbiwCOXwyouOTx46AJIJIW7387yiLwvWGB aWp6lj7Sr+z0lf Message-ID: <46655A78.4020206@gmx.net> Date: Tue, 05 Jun 2007 14:43:36 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Beyer, Loraine" Subject: Re: [Ecrit] Location Hiding - another look References: <4663DE0A.1050409@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p><46647238.80808@gmx.net> <179e01c7a712$c557bd20$6601a8c0@cis.neustar.com> <6FEBBDAA0B74D34E806D366A431F36B703A09C2D@brexc47p> In-Reply-To: <6FEBBDAA0B74D34E806D366A431F36B703A09C2D@brexc47p> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Since we have seen these type of messages from time-to-time I suggest everyone to take a look at https://www1.ietf.org/mailman//listinfo/ecrit when they want to unsubscribe. It does not help to send a mail to the list saying "Please unsubscribe me. I don't want to follow these confused discussions anymore.". Beyer, Loraine wrote: > Please remove my name from the distribution list. I have unsubscribed > >from ecrit@ietf.org. > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Monday, June 04, 2007 8:42 PM > To: 'Hannes Tschofenig'; Stark, Barbara > Cc: 'ECRIT' > Subject: RE: [Ecrit] Location Hiding - another look > > I don't understand where this is going. > If the access network supplies coarse location to a non-authenticated > querier which is sufficient for routing or for validation, then it > doesn't matter if it's the endpoint or the VSP that is doing the routing > or the validating. > > Neither the VSP nor the endpoint is an authorized querier to the access > network. They are of equal status, they get the same result. > > Brian > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Monday, June 04, 2007 4:13 PM >> To: Stark, Barbara >> Cc: ECRIT >> Subject: Re: [Ecrit] Location Hiding - another look >> >> Hi Barbara, >> >> Stark, Barbara wrote: >> >>> I think it's important for the end point to be able to get the PSAP >>> URI, because there may not be a VSP, at all. >>> >> For the case where there is no VSP, also referred as the >> unauthenticated emergency service architecture, the access network >> provider has to provide emergency service support directly or >> indirectly (via a partnership with another emergency service >> > infrastructure provider). > >> You additionally have to consider the case where link layer >> authentication can also be bypassed since you might loose more than >> just the credentials of the VSP. >> >> >>> I don't think the architecture >>> should require that there be a VSP in order to make a SIP call over >>> the Internet. Certainly, VSPs are needed to get to PSAPs on the >>> legacy phone network. But once PSAPs are reachable directly by VoIP, >>> > > >>> the architecture should allow end devices with open Internet access, >>> > > >>> but no VSP, to make emergency calls. >>> >>> >> Ciao >> Hannes >> >> >>> Barbara >>> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: Monday, June 04, 2007 5:40 AM >>> To: ECRIT >>> Subject: [Ecrit] Location Hiding - another look >>> >>> Hi all, >>> >>> with location hiding we assumed that the network operator does not >>> want to provide information about the precise location information >>> to the end point. >>> A lot of discussions focused on the question how it can still obtain >>> > > >>> a PSAP URI in that case. >>> >>> There is, however, the question why the end point needs to obtain >>> this PSAP URI in the location hiding case at all. >>> Why cannot we just assume that the VSP has to obtain some location >>> information from the ASP/ISP via LbyR and then it runs a LoST query >>> as we specified it. >>> >>> DONE >>> >>> Ciao >>> Hannes >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> ***** >>> >>> The information transmitted is intended only for the person or >>> entity to >>> >> which it is addressed and may contain confidential, proprietary, >> and/or privileged material. Any review, retransmission, dissemination >> or other use of, or taking of any action in reliance upon this >> information by persons or entities other than the intended recipient >> is prohibited. If you received this in error, please contact the >> sender and delete the material from all computers. GA621 >> >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > ***** > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623 > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 08:48:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvYT0-00009f-JJ; Tue, 05 Jun 2007 08:48:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvYT0-00009V-1k for ecrit@ietf.org; Tue, 05 Jun 2007 08:48:54 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvYSz-0006N6-Iv for ecrit@ietf.org; Tue, 05 Jun 2007 08:48:54 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HvYQ0-0002La-8Q; Tue, 05 Jun 2007 07:45:48 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Hannes Tschofenig'" References: <4663DE0A.1050409@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p><46647238.80808@gmx.net> <179e01c7a712$c557bd20$6601a8c0@cis.neustar.com> <4665088B.4010104@gmx.net> Subject: RE: [Ecrit] Location Hiding - another look Date: Tue, 5 Jun 2007 08:48:49 -0400 Message-ID: <18c101c7a76f$deb4fc80$6601a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcenPk9oOAXLBxQvSXKz7f9dTeXvEwAAIGygAAv37fA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Note that this function would have to also be added to the dereference mechanism so the VSP could validate the PSAP URI in solution 3. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Tuesday, June 05, 2007 3:00 AM > To: Hannes Tschofenig > Cc: Brian Rosen; Stark, Barbara; ECRIT > Subject: RE: [Ecrit] Location Hiding - another look > > > I want to use LoST as is. > I just don't see why HELD can't be used as a tool to hide locations from > services that the location provider does not want to offer. > > > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Tuesday, 5 June 2007 4:54 PM > > To: Winterbottom, James > > Cc: Brian Rosen; Stark, Barbara; ECRIT > > Subject: Re: [Ecrit] Location Hiding - another look > > > > Brian, > > > > the main discussion here is: > > > > * Some people want to enhance HELD by adding LoST functionality > > * Some others want to use LoST as is. > > > > Now we are at the stage where we try to find arguments when one > solution > > is better than the other one. > > > > Ciao > > Hannes > > > > Winterbottom, James wrote: > > > I am at a loss to understand why either needs a coarse location if > the > > > PSAP URI is provided directly to the end-point. > > > > > > > > >> -----Original Message----- > > >> From: Brian Rosen [mailto:br@brianrosen.net] > > >> Sent: Tuesday, 5 June 2007 11:42 AM > > >> To: 'Hannes Tschofenig'; 'Stark, Barbara' > > >> Cc: 'ECRIT' > > >> Subject: RE: [Ecrit] Location Hiding - another look > > >> > > >> I don't understand where this is going. > > >> If the access network supplies coarse location to a > non-authenticated > > >> querier which is sufficient for routing or for validation, then it > > >> > > > doesn't > > > > > >> matter if it's the endpoint or the VSP that is doing the routing or > > >> > > > the > > > > > >> validating. > > >> > > >> Neither the VSP nor the endpoint is an authorized querier to the > > >> > > > access > > > > > >> network. They are of equal status, they get the same result. > > >> > > >> Brian > > >> > > >> > > >>> -----Original Message----- > > >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > >>> Sent: Monday, June 04, 2007 4:13 PM > > >>> To: Stark, Barbara > > >>> Cc: ECRIT > > >>> Subject: Re: [Ecrit] Location Hiding - another look > > >>> > > >>> Hi Barbara, > > >>> > > >>> Stark, Barbara wrote: > > >>> > > >>>> I think it's important for the end point to be able to get the > > >>>> > > > PSAP > > > > > >> URI, > > >> > > >>>> because there may not be a VSP, at all. > > >>>> > > >>> For the case where there is no VSP, also referred as the > > >>> > > > unauthenticated > > > > > >>> emergency service architecture, the access network provider has to > > >>> provide emergency service support directly or indirectly (via a > > >>> partnership with another emergency service infrastructure > provider). > > >>> > > >>> You additionally have to consider the case where link layer > > >>> authentication can also be bypassed since you might loose more > than > > >>> > > > just > > > > > >>> the credentials of the VSP. > > >>> > > >>> > > >>>> I don't think the architecture > > >>>> should require that there be a VSP in order to make a SIP call > > >>>> > > > over > > > > > >> the > > >> > > >>>> Internet. Certainly, VSPs are needed to get to PSAPs on the > legacy > > >>>> > > >> phone > > >> > > >>>> network. But once PSAPs are reachable directly by VoIP, the > > >>>> > > >> architecture > > >> > > >>>> should allow end devices with open Internet access, but no VSP, > to > > >>>> > > >> make > > >> > > >>>> emergency calls. > > >>>> > > >>>> > > >>> Ciao > > >>> Hannes > > >>> > > >>> > > >>>> Barbara > > >>>> > > >>>> -----Original Message----- > > >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > >>>> Sent: Monday, June 04, 2007 5:40 AM > > >>>> To: ECRIT > > >>>> Subject: [Ecrit] Location Hiding - another look > > >>>> > > >>>> Hi all, > > >>>> > > >>>> with location hiding we assumed that the network operator does > not > > >>>> > > >> want > > >> > > >>>> to provide information about the precise location information to > > >>>> > > > the > > > > > >> end > > >> > > >>>> point. > > >>>> A lot of discussions focused on the question how it can still > > >>>> > > > obtain a > > > > > >>>> PSAP URI in that case. > > >>>> > > >>>> There is, however, the question why the end point needs to obtain > > >>>> > > > this > > > > > >>>> PSAP URI in the location hiding case at all. > > >>>> Why cannot we just assume that the VSP has to obtain some > location > > >>>> information from the ASP/ISP via LbyR and then it runs a LoST > > >>>> > > > query as > > > > > >>>> we specified it. > > >>>> > > >>>> DONE > > >>>> > > >>>> Ciao > > >>>> Hannes > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Ecrit mailing list > > >>>> Ecrit@ietf.org > > >>>> https://www1.ietf.org/mailman/listinfo/ecrit > > >>>> > > >>>> ***** > > >>>> > > >>>> The information transmitted is intended only for the person or > > >>>> > > > entity > > > > > >> to > > >> > > >>> which it is addressed and may contain confidential, proprietary, > > >>> > > > and/or > > > > > >>> privileged material. Any review, retransmission, dissemination or > > >>> > > > other > > > > > >>> use of, or taking of any action in reliance upon this information > by > > >>> persons or entities other than the intended recipient is > prohibited. > > >>> > > > If > > > > > >>> you received this in error, please contact the sender and delete > the > > >>> material from all computers. GA621 > > >>> > > >>>> > > >>> _______________________________________________ > > >>> Ecrit mailing list > > >>> Ecrit@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/ecrit > > >>> > > >> _______________________________________________ > > >> Ecrit mailing list > > >> Ecrit@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/ecrit > > >> > > > > > > > ------------------------------------------------------------------------ > > ------------------------ > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > ------------------------------------------------------------------------ > > ------------------------ > > > [mf2] > > > > > > > > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 09:02:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvYgO-0002WW-DL; Tue, 05 Jun 2007 09:02:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvYgN-0002WO-TK for ecrit@ietf.org; Tue, 05 Jun 2007 09:02:43 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvYgI-0008Eh-UK for ecrit@ietf.org; Tue, 05 Jun 2007 09:02:43 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HvYgG-0000ox-3t; Tue, 05 Jun 2007 09:02:36 -0400 Received: from [127.0.0.1] (col-dhcp33-244-154.bbn.com [128.33.244.154]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l55D2Xw04641; Tue, 5 Jun 2007 09:02:33 -0400 (EDT) Message-ID: <46655EE9.4010805@bbn.com> Date: Tue, 05 Jun 2007 09:02:33 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Location Hiding - another look References: <4663DE0A.1050409@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p> <46647238.80808@gmx.net> <8EF09A27-92D2-4590-A20F-31D377B576B3@cs.columbia.edu> <7582BC68E4994F4ABF0BD4723975C3FA043E8473@crexc41p> <46655136.8090304@gmx.net> In-Reply-To: <46655136.8090304@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > These functions still have to exist since otherwise the end host would > directly contact the PSAP and there wouldn't be an authenticated > identity attached to the emergency call. This would be a serious > security concern. From a security perspective, there's no difference between calling a PSAP through a proxy or directly: There's no more a relationship between the proxy/VSP and the PSAP than between the endpoint and the PSAP. E.g., a PSAP in Fairfax, VA has (probably) no way to authenticate a VSP Sierra Leone, or the "VSP" that I have running on a box in my basement, and likewise, no way to authenticate identities of callers from those VSPs. --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 09:10:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvYnk-0007tP-5R; Tue, 05 Jun 2007 09:10:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvYnj-0007px-28 for ecrit@ietf.org; Tue, 05 Jun 2007 09:10:19 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvYnh-0001td-S2 for ecrit@ietf.org; Tue, 05 Jun 2007 09:10:19 -0400 Received: from [204.8.159.23] (temp-openyrless-dhcp23.bu.edu [204.8.159.23]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l55DAABJ019662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 Jun 2007 09:10:14 -0400 (EDT) In-Reply-To: <4665088B.4010104@gmx.net> References: <4663DE0A.1050409@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p><46647238.80808@gmx.net> <179e01c7a712$c557bd20$6601a8c0@cis.neustar.com> <4665088B.4010104@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Location Hiding - another look Date: Tue, 5 Jun 2007 09:10:19 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Unless we agree whether VSP PSAP URI verification is a requirement or not, we are unlikely to make much progress. On Jun 5, 2007, at 2:54 AM, Hannes Tschofenig wrote: > Brian, > > the main discussion here is: > > * Some people want to enhance HELD by adding LoST functionality > * Some others want to use LoST as is. > > Now we are at the stage where we try to find arguments when one > solution is better than the other one. > > Ciao > Hannes > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 09:19:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvYwZ-0006AK-3P; Tue, 05 Jun 2007 09:19:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvYwX-00069G-GZ for ecrit@ietf.org; Tue, 05 Jun 2007 09:19:25 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvYwX-0002t7-5N for ecrit@ietf.org; Tue, 05 Jun 2007 09:19:25 -0400 Received: from [204.8.159.23] (temp-openyrless-dhcp23.bu.edu [204.8.159.23]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l55DJ6Pq021706 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 Jun 2007 09:19:07 -0400 (EDT) In-Reply-To: <46655EE9.4010805@bbn.com> References: <4663DE0A.1050409@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p> <46647238.80808@gmx.net> <8EF09A27-92D2-4590-A20F-31D377B576B3@cs.columbia.edu> <7582BC68E4994F4ABF0BD4723975C3FA043E8473@crexc41p> <46655136.8090304@gmx.net> <46655EE9.4010805@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Location Hiding - another look Date: Tue, 5 Jun 2007 09:19:17 -0400 To: Richard Barnes X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This goes back to an old debate we have had in several different instances (including L2 authentication and location signing): Namely, is the ability to verify the identity of some callers useful, even if not all legitimate callers can be verified? Brian, and probably others, have made the case that it is. I think we have to be consistent here, even if the percentages vary between the various authentication cases. We can only guess at these percentages in any event. I suspect that the vast majority of legitimate calls to a Fairfax PSAP will not come from a Sierra Leonian VSP. On Jun 5, 2007, at 9:02 AM, Richard Barnes wrote: >> These functions still have to exist since otherwise the end host >> would directly contact the PSAP and there wouldn't be an >> authenticated identity attached to the emergency call. This would >> be a serious security concern. > > From a security perspective, there's no difference between calling > a PSAP through a proxy or directly: There's no more a relationship > between the proxy/VSP and the PSAP than between the endpoint and > the PSAP. E.g., a PSAP in Fairfax, VA has (probably) no way to > authenticate a VSP Sierra Leone, or the "VSP" that I have running > on a box in my basement, and likewise, no way to authenticate > identities of callers from those VSPs. > > --Richard > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 09:28:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZ5L-00014m-Nt; Tue, 05 Jun 2007 09:28:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZ5I-0000tp-OX for ecrit@ietf.org; Tue, 05 Jun 2007 09:28:29 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvZ5H-0004dm-S6 for ecrit@ietf.org; Tue, 05 Jun 2007 09:28:28 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HvZ5F-000175-5W; Tue, 05 Jun 2007 09:28:25 -0400 Received: from [127.0.0.1] (col-dhcp33-244-154.bbn.com [128.33.244.154]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l55DSOw08891; Tue, 5 Jun 2007 09:28:24 -0400 (EDT) Message-ID: <466564F1.4070205@bbn.com> Date: Tue, 05 Jun 2007 09:28:17 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Location Hiding - another look References: <4663DE0A.1050409@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p><46647238.80808@gmx.net> <179e01c7a712$c557bd20$6601a8c0@cis.neustar.com> <4665088B.4010104@gmx.net> In-Reply-To: <4665088B.4010104@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes, I would frame the debate a little differently: * Some people want to provision rough LbyV to the endpoint so that it can do LoST queries --> Requires modification of LoST to handle rough locations (polygons) * Some people want the access network to do LoST on behalf of the endpoint --> Requires modification to LCP(s) or trusted LoST servers That said, I don't see why we can't offer both: As part of endpoint configuration (e.g., the LCP), the access network can specify which option it's using. For instance, suppose the LCP could return either 1. LbyR + Rough LbyV, or 2. LbyR + LoST elements (And phonebcp says it MUST do one of those two, not just LbyR). Then the endpoint could look at the LCP response and decide whether it needs to do LoST (in case 1) or just cache the returned mappings. This solution would require the most protocol changes (rough location in LoST and in LCPs), but I don't think it adds a whole lot of additional complexity. --Richard Hannes Tschofenig wrote: > Brian, > > the main discussion here is: > > * Some people want to enhance HELD by adding LoST functionality > * Some others want to use LoST as is. > > Now we are at the stage where we try to find arguments when one solution > is better than the other one. > > Ciao > Hannes > > Winterbottom, James wrote: >> I am at a loss to understand why either needs a coarse location if the >> PSAP URI is provided directly to the end-point. >> >> >>> -----Original Message----- >>> From: Brian Rosen [mailto:br@brianrosen.net] >>> Sent: Tuesday, 5 June 2007 11:42 AM >>> To: 'Hannes Tschofenig'; 'Stark, Barbara' >>> Cc: 'ECRIT' >>> Subject: RE: [Ecrit] Location Hiding - another look >>> >>> I don't understand where this is going. >>> If the access network supplies coarse location to a non-authenticated >>> querier which is sufficient for routing or for validation, then it >>> >> doesn't >> >>> matter if it's the endpoint or the VSP that is doing the routing or >>> >> the >> >>> validating. >>> >>> Neither the VSP nor the endpoint is an authorized querier to the >>> >> access >> >>> network. They are of equal status, they get the same result. >>> >>> Brian >>> >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Monday, June 04, 2007 4:13 PM >>>> To: Stark, Barbara >>>> Cc: ECRIT >>>> Subject: Re: [Ecrit] Location Hiding - another look >>>> >>>> Hi Barbara, >>>> >>>> Stark, Barbara wrote: >>>> >>>>> I think it's important for the end point to be able to get the >>>>> >> PSAP >> >>> URI, >>> >>>>> because there may not be a VSP, at all. >>>>> >>>> For the case where there is no VSP, also referred as the >>>> >> unauthenticated >> >>>> emergency service architecture, the access network provider has to >>>> provide emergency service support directly or indirectly (via a >>>> partnership with another emergency service infrastructure provider). >>>> >>>> You additionally have to consider the case where link layer >>>> authentication can also be bypassed since you might loose more than >>>> >> just >> >>>> the credentials of the VSP. >>>> >>>> >>>>> I don't think the architecture >>>>> should require that there be a VSP in order to make a SIP call >>>>> >> over >> >>> the >>> >>>>> Internet. Certainly, VSPs are needed to get to PSAPs on the legacy >>>>> >>> phone >>> >>>>> network. But once PSAPs are reachable directly by VoIP, the >>>>> >>> architecture >>> >>>>> should allow end devices with open Internet access, but no VSP, to >>>>> >>> make >>> >>>>> emergency calls. >>>>> >>>>> >>>> Ciao >>>> Hannes >>>> >>>> >>>>> Barbara >>>>> >>>>> -----Original Message----- >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> Sent: Monday, June 04, 2007 5:40 AM >>>>> To: ECRIT >>>>> Subject: [Ecrit] Location Hiding - another look >>>>> >>>>> Hi all, >>>>> >>>>> with location hiding we assumed that the network operator does not >>>>> >>> want >>> >>>>> to provide information about the precise location information to >>>>> >> the >> >>> end >>> >>>>> point. >>>>> A lot of discussions focused on the question how it can still >>>>> >> obtain a >> >>>>> PSAP URI in that case. >>>>> >>>>> There is, however, the question why the end point needs to obtain >>>>> >> this >> >>>>> PSAP URI in the location hiding case at all. >>>>> Why cannot we just assume that the VSP has to obtain some location >>>>> information from the ASP/ISP via LbyR and then it runs a LoST >>>>> >> query as >> >>>>> we specified it. >>>>> >>>>> DONE >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> ***** >>>>> >>>>> The information transmitted is intended only for the person or >>>>> >> entity >> >>> to >>> >>>> which it is addressed and may contain confidential, proprietary, >>>> >> and/or >> >>>> privileged material. Any review, retransmission, dissemination or >>>> >> other >> >>>> use of, or taking of any action in reliance upon this information by >>>> persons or entities other than the intended recipient is prohibited. >>>> >> If >> >>>> you received this in error, please contact the sender and delete the >>>> material from all computers. GA621 >>>> >>>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >> >> ------------------------------------------------------------------------------------------------ >> >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. If >> you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> ------------------------------------------------------------------------------------------------ >> >> [mf2] >> >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 09:37:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZDm-0002mh-Li; Tue, 05 Jun 2007 09:37:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZDm-0002mb-7x for ecrit@ietf.org; Tue, 05 Jun 2007 09:37:14 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvZDk-00063m-VH for ecrit@ietf.org; Tue, 05 Jun 2007 09:37:14 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 05 Jun 2007 09:37:10 -0400 id 01588132.46656706.0000297C In-Reply-To: <46613214.5030202@gmx.net> References: <46613214.5030202@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <97EF79AE-FF58-42BE-AC9A-680DC0EED3ED@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Location Hiding: Let's Make some Progress Date: Tue, 5 Jun 2007 09:37:04 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 2, 2007, at 5:02 AM, Hannes Tschofenig wrote: > To restart the discussion Henning and myself have written a short > draft about solution#3: > http://www.tschofenig.priv.at/twiki/pub/EmergencyServices/ > LocationHiding/draft-schulzrinne-ecrit-lost-in-held-00.txt Interesting... you have taken bits of ideas from various parts of these discussions and come up with a good proposal. I appreciate the collaborative spirit you and Henning have shown here. I like this approach. Here are my comments: 1) One point of the ECRIT architecture is not covered, and that is getting LoST information at call time. The could be done via an update from/to the LCS. 2) Perhaps this draft could be made general to all LCPs instead of just HELD, or at-least to all XML carrying LCPs. Even DHCP might be able to carry this information in a binary form of XML (perhaps). To do this, maybe a _short_ list of LCP protocol requirements should be stated. Something like this (just a strawman, I'm not wed to it): For an LCP to LoST compliant/capable, it must support the following protocol interactions between an LCP server and LCP client: a) clients MUST be able to assert the service URNs of the services they need. b) clients MUST be able to refresh their LoST mapping data. c) clients MUST be able to obtain a list of LoST service URNs that are available. 3) I agree with section 6. In fact, I'm fairly confident you will never need to do this. Just use the LoST schema. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 09:42:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZJ8-0006yH-7l; Tue, 05 Jun 2007 09:42:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZJ6-0006yB-SF for ecrit@ietf.org; Tue, 05 Jun 2007 09:42:44 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvZJ4-0006mN-L4 for ecrit@ietf.org; Tue, 05 Jun 2007 09:42:44 -0400 Received: (qmail invoked by alias); 05 Jun 2007 13:42:41 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp034) with SMTP; 05 Jun 2007 15:42:41 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/f2MVpJGXfVFujTBoGEgXSpTmfGlL9xetej6mPk6 Dz7RKfq7/1cout Message-ID: <4665684F.3020906@gmx.net> Date: Tue, 05 Jun 2007 15:42:39 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Richard Barnes Subject: Re: [Ecrit] Location Hiding - another look References: <4663DE0A.1050409@gmx.net> <7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p> <46647238.80808@gmx.net> <8EF09A27-92D2-4590-A20F-31D377B576B3@cs.columbia.edu> <7582BC68E4994F4ABF0BD4723975C3FA043E8473@crexc41p> <46655136.8090304@gmx.net> <46655EE9.4010805@bbn.com> In-Reply-To: <46655EE9.4010805@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Richard, Richard Barnes wrote: >> These functions still have to exist since otherwise the end host >> would directly contact the PSAP and there wouldn't be an >> authenticated identity attached to the emergency call. This would be >> a serious security concern. > > From a security perspective, there's no difference between calling a > PSAP through a proxy or directly: There's no more a relationship > between the proxy/VSP and the PSAP than between the endpoint and the > PSAP. E.g., a PSAP in Fairfax, VA has (probably) no way to > authenticate a VSP Sierra Leone, or the "VSP" that I have running on a > box in my basement, and likewise, no way to authenticate identities of > callers from those VSPs. > You are always so security concerned. Don't you think that the calls should typically go through the VSP to have a chance of getting SIP identity added? Ciao Hannes > --Richard > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 09:47:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZNQ-0001qK-Vs; Tue, 05 Jun 2007 09:47:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZNP-0001qA-Vs for ecrit@ietf.org; Tue, 05 Jun 2007 09:47:11 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvZNP-0007E5-6V for ecrit@ietf.org; Tue, 05 Jun 2007 09:47:11 -0400 Received: (qmail invoked by alias); 05 Jun 2007 13:47:10 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp027) with SMTP; 05 Jun 2007 15:47:10 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/+SMk/Va/+WNF3m8+D9ItbE+Vb2sa5OcQ58PMkAt rez4JQsHRjEseA Message-ID: <4665695C.8030200@gmx.net> Date: Tue, 05 Jun 2007 15:47:08 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Richard Barnes Subject: Re: [Ecrit] Location Hiding - another look References: <4663DE0A.1050409@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p><46647238.80808@gmx.net> <179e01c7a712$c557bd20$6601a8c0@cis.neustar.com> <4665088B.4010104@gmx.net> <466564F1.4070205@bbn.com> In-Reply-To: <466564F1.4070205@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Richard, Richard Barnes wrote: > Hannes, > > I would frame the debate a little differently: > > * Some people want to provision rough LbyV to the endpoint so that it > can do LoST queries > --> Requires modification of LoST to handle rough locations (polygons) > Correct. > * Some people want the access network to do LoST on behalf of the > endpoint > --> Requires modification to LCP(s) or trusted LoST servers > Correct. > That said, I don't see why we can't offer both: As part of endpoint > configuration (e.g., the LCP), the access network can specify which > option it's using. > For instance, suppose the LCP could return either > > 1. LbyR + Rough LbyV, or > 2. LbyR + LoST elements > > (And phonebcp says it MUST do one of those two, not just LbyR). Then > the endpoint could look at the LCP response and decide whether it > needs to do LoST (in case 1) or just cache the returned mappings. Is this your suggestion for compromise or your ideal solution? > > This solution would require the most protocol changes (rough location > in LoST and in LCPs), but I don't think it adds a whole lot > of additional complexity. Don't you think we have too many options for emergency call signaling? Ciao Hannes > --Richard > > > > > > Hannes Tschofenig wrote: >> Brian, >> >> the main discussion here is: >> >> * Some people want to enhance HELD by adding LoST functionality >> * Some others want to use LoST as is. >> >> Now we are at the stage where we try to find arguments when one >> solution is better than the other one. >> >> Ciao >> Hannes >> >> Winterbottom, James wrote: >>> I am at a loss to understand why either needs a coarse location if the >>> PSAP URI is provided directly to the end-point. >>> >>> >>>> -----Original Message----- >>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>> Sent: Tuesday, 5 June 2007 11:42 AM >>>> To: 'Hannes Tschofenig'; 'Stark, Barbara' >>>> Cc: 'ECRIT' >>>> Subject: RE: [Ecrit] Location Hiding - another look >>>> >>>> I don't understand where this is going. >>>> If the access network supplies coarse location to a non-authenticated >>>> querier which is sufficient for routing or for validation, then it >>>> >>> doesn't >>> >>>> matter if it's the endpoint or the VSP that is doing the routing or >>>> >>> the >>> >>>> validating. >>>> >>>> Neither the VSP nor the endpoint is an authorized querier to the >>>> >>> access >>> >>>> network. They are of equal status, they get the same result. >>>> >>>> Brian >>>> >>>> >>>>> -----Original Message----- >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> Sent: Monday, June 04, 2007 4:13 PM >>>>> To: Stark, Barbara >>>>> Cc: ECRIT >>>>> Subject: Re: [Ecrit] Location Hiding - another look >>>>> >>>>> Hi Barbara, >>>>> >>>>> Stark, Barbara wrote: >>>>> >>>>>> I think it's important for the end point to be able to get the >>>>>> >>> PSAP >>> >>>> URI, >>>> >>>>>> because there may not be a VSP, at all. >>>>>> >>>>> For the case where there is no VSP, also referred as the >>>>> >>> unauthenticated >>> >>>>> emergency service architecture, the access network provider has to >>>>> provide emergency service support directly or indirectly (via a >>>>> partnership with another emergency service infrastructure provider). >>>>> >>>>> You additionally have to consider the case where link layer >>>>> authentication can also be bypassed since you might loose more than >>>>> >>> just >>> >>>>> the credentials of the VSP. >>>>> >>>>> >>>>>> I don't think the architecture >>>>>> should require that there be a VSP in order to make a SIP call >>>>>> >>> over >>> >>>> the >>>> >>>>>> Internet. Certainly, VSPs are needed to get to PSAPs on the legacy >>>>>> >>>> phone >>>> >>>>>> network. But once PSAPs are reachable directly by VoIP, the >>>>>> >>>> architecture >>>> >>>>>> should allow end devices with open Internet access, but no VSP, to >>>>>> >>>> make >>>> >>>>>> emergency calls. >>>>>> >>>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> >>>>>> Barbara >>>>>> >>>>>> -----Original Message----- >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>> Sent: Monday, June 04, 2007 5:40 AM >>>>>> To: ECRIT >>>>>> Subject: [Ecrit] Location Hiding - another look >>>>>> >>>>>> Hi all, >>>>>> >>>>>> with location hiding we assumed that the network operator does not >>>>>> >>>> want >>>> >>>>>> to provide information about the precise location information to >>>>>> >>> the >>> >>>> end >>>> >>>>>> point. >>>>>> A lot of discussions focused on the question how it can still >>>>>> >>> obtain a >>> >>>>>> PSAP URI in that case. >>>>>> >>>>>> There is, however, the question why the end point needs to obtain >>>>>> >>> this >>> >>>>>> PSAP URI in the location hiding case at all. >>>>>> Why cannot we just assume that the VSP has to obtain some location >>>>>> information from the ASP/ISP via LbyR and then it runs a LoST >>>>>> >>> query as >>> >>>>>> we specified it. >>>>>> >>>>>> DONE >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> ***** >>>>>> >>>>>> The information transmitted is intended only for the person or >>>>>> >>> entity >>> >>>> to >>>> >>>>> which it is addressed and may contain confidential, proprietary, >>>>> >>> and/or >>> >>>>> privileged material. Any review, retransmission, dissemination or >>>>> >>> other >>> >>>>> use of, or taking of any action in reliance upon this information by >>>>> persons or entities other than the intended recipient is prohibited. >>>>> >>> If >>> >>>>> you received this in error, please contact the sender and delete the >>>>> material from all computers. GA621 >>>>> >>>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>> >>> >>> ------------------------------------------------------------------------------------------------ >>> >>> This message is for the designated recipient only and may >>> contain privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender >>> immediately and delete the original. Any unauthorized use of >>> this email is prohibited. >>> ------------------------------------------------------------------------------------------------ >>> >>> [mf2] >>> >>> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 09:51:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZRR-0002ya-3f; Tue, 05 Jun 2007 09:51:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZRQ-0002yV-DL for ecrit@ietf.org; Tue, 05 Jun 2007 09:51:20 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvZRP-0007yd-5R for ecrit@ietf.org; Tue, 05 Jun 2007 09:51:20 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 05 Jun 2007 09:51:18 -0400 id 01588132.46656A56.00002CE0 In-Reply-To: References: <4663DE0A.1050409@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p><46647238.80808@gmx.net> <179e01c7a712$c557bd20$6601a8c0@cis.neustar.com> <4665088B.4010104@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3AD88C5F-AEAE-4FEB-BCDD-27738BC947A3@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Location Hiding - another look Date: Tue, 5 Jun 2007 09:51:15 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 5, 2007, at 9:10 AM, Henning Schulzrinne wrote: > Unless we agree whether VSP PSAP URI verification is a requirement > or not, we are unlikely to make much progress. Good point. Just backing up a bit, the requirement is really that VSPs need to verify that a routed emergency call is really a routed emergency call. Verifying the PSAP URI is just one method, but one which seems to hold most promise. The most common objection to the current method proposed seems to be that ASPs/ISPs must then provision both coarse grain and fine grain location information -- the coarse grain location info being used by the VSP as an input to LoST to verify the PSAP URI. Just thinking out loud here, but if we could use the PSAP URI as the input to LoST then this problem goes away. This is similar to reverse DNS lookups. The input is a PSAP URI and the output is a . A change to LoST would be required to support this. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 10:02:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZcQ-0004pC-EC; Tue, 05 Jun 2007 10:02:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZcO-0004oy-G3 for ecrit@ietf.org; Tue, 05 Jun 2007 10:02:40 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvZcM-0002o0-Qb for ecrit@ietf.org; Tue, 05 Jun 2007 10:02:40 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 05 Jun 2007 10:02:38 -0400 id 01588132.46656CFE.00003000 In-Reply-To: References: <46613214.5030202@gmx.net> <46615F20.1050103@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Location Hiding: Let's Make some Progress Date: Tue, 5 Jun 2007 10:02:36 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 3, 2007, at 10:15 PM, Winterbottom, James wrote: > [AJW] My point is that we only have to do this if the VSP billing > is an > issue. Looking at two prominent Internet VSPs this to me seems like a > ridiculous requirement. Many of these are providing international call > rates of like 1 cent per minute for between $17 and $25 a month, with > free national calls, and some international calls also free. I think > that this billing issue is almost not an issue, and so I see little > need > for the proposed changes to LoST, making the problem totally in the > location acquisition space. James, I'm willing to brush aside this requirement if you are willing to pay for all the fraudulent calls the occur while this system is deployed. You'll find out real fast how much 1 cent per minute costs. :) Fraud does occur in VoIP and there are truly people attempting to game VSPs. I see it every day. And much like a traditional telco, we allow disconnected/cancelled customers to make outbound 9-1-1 calls. There does need to be some means of detecting fraud. It does not have to be realtime and it does not have to be perfect, but it does have to be effective. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 10:04:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZeA-0006eV-BZ; Tue, 05 Jun 2007 10:04:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZe8-0006eQ-QM for ecrit@ietf.org; Tue, 05 Jun 2007 10:04:29 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvZe7-00034V-EU for ecrit@ietf.org; Tue, 05 Jun 2007 10:04:28 -0400 Received: from ([139.76.131.79]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.23419698; Tue, 05 Jun 2007 10:04:03 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 5 Jun 2007 10:03:36 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 5 Jun 2007 10:03:36 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Location Hiding - another look Date: Tue, 5 Jun 2007 10:03:34 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA043E8519@crexc41p> In-Reply-To: <46655EE9.4010805@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Hiding - another look thread-index: AcenchyzmdlDPs+tTtKlbrr2kLptVwAAkFPw References: <46655136.8090304@gmx.net> <46655EE9.4010805@bbn.com> From: "Stark, Barbara" To: "Richard Barnes" , "Hannes Tschofenig" X-OriginalArrivalTime: 05 Jun 2007 14:03:36.0778 (UTC) FILETIME=[4FAAA2A0:01C7A77A] X-Spam-Score: 0.6 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Thanks, Richard. My sentiments, exactly. I don't trust the Sierra Leone VSP, the box in your basement, or the plethora of Asterisk servers in so many people's basements and small and home offices, any more or less than I trust communications directly from end devices. Having a VSP in the flow does Unless we want to create an emergency architecture that forces end users to have relationships with "trustworthy" (certified?) VSPs [although I salivate at such an idea ... ;-) ], I think the end device needs to accept personal responsibility for as much as it can, where the need for emergency services is concerned. The abilities of a VSP (if present) are simply a redundant back-up to the capabilities of the end device, where emergency services are concerned. Barbara -----Original Message----- From: Richard Barnes [mailto:rbarnes@bbn.com]=20 Sent: Tuesday, June 05, 2007 9:03 AM To: Hannes Tschofenig Cc: Stark, Barbara; ECRIT Subject: Re: [Ecrit] Location Hiding - another look > These functions still have to exist since otherwise the end host would > directly contact the PSAP and there wouldn't be an authenticated=20 > identity attached to the emergency call. This would be a serious=20 > security concern. From a security perspective, there's no difference between calling a PSAP through a proxy or directly: There's no more a relationship between the proxy/VSP and the PSAP than between the endpoint and the PSAP.=20 E.g., a PSAP in Fairfax, VA has (probably) no way to authenticate a VSP Sierra Leone, or the "VSP" that I have running on a box in my basement, and likewise, no way to authenticate identities of callers from those VSPs. --Richard ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA621 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 10:06:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZfc-0007EI-Eb; Tue, 05 Jun 2007 10:06:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZfa-0007ED-Oi for ecrit@ietf.org; Tue, 05 Jun 2007 10:05:58 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvZfZ-0003Iq-WC for ecrit@ietf.org; Tue, 05 Jun 2007 10:05:58 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HvZfV-0001Fj-6H; Tue, 05 Jun 2007 10:05:54 -0400 Received: from [127.0.0.1] (col-dhcp33-244-154.bbn.com [128.33.244.154]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l55E5qw15526; Tue, 5 Jun 2007 10:05:52 -0400 (EDT) Message-ID: <46656DBA.1060507@bbn.com> Date: Tue, 05 Jun 2007 10:05:46 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Location Hiding - another look References: <4663DE0A.1050409@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p><46647238.80808@gmx.net> <179e01c7a712$c557bd20$6601a8c0@cis.neustar.com> <4665088B.4010104@gmx.net> <466564F1.4070205@bbn.com> <4665695C.8030200@gmx.net> In-Reply-To: <4665695C.8030200@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org >> That said, I don't see why we can't offer both: As part of endpoint >> configuration (e.g., the LCP), the access network can specify which >> option it's using. > >> For instance, suppose the LCP could return either >> >> 1. LbyR + Rough LbyV, or >> 2. LbyR + LoST elements >> >> (And phonebcp says it MUST do one of those two, not just LbyR). Then >> the endpoint could look at the LCP response and decide whether it >> needs to do LoST (in case 1) or just cache the returned mappings. > Is this your suggestion for compromise or your ideal solution? I think this is a good compromise solution for the problem of provisioning PSAP URIs when location is given by reference. At this point, I don't regard either of the competing solutions as ideal in all use cases. In terms of PSAP URI validation, this would effectively require reverse LoST, since the endpoint doesn't necessarily have its own location. If you really didn't want to do reverse LoST, you could have the endpoint include a service boundary (by value or reference) as its location, but that seems like a bad idea. >> >> This solution would require the most protocol changes (rough location >> in LoST and in LCPs), but I don't think it adds a whole lot >> of additional complexity. > > Don't you think we have too many options for emergency call signaling? I'm not sure understand the question. In either case, the call signaling is the same. What changes is how the endpoint gets the data to construct the INVITE. In case (2), you could say that complexity is reduced (vs. the non-LbyR case), since th endpoint doesn't have to do LoST, and in case (1), it's identical from the endpoint's perspective -- it just takes the LbyV and does LoST. And to determine which case to use, the endpoint only needs to look at the structure of the message, whether there's an LbyV or a present. --Richard > > Ciao > Hannes > >> --Richard >> >> >> >> >> >> Hannes Tschofenig wrote: >>> Brian, >>> >>> the main discussion here is: >>> >>> * Some people want to enhance HELD by adding LoST functionality >>> * Some others want to use LoST as is. >>> >>> Now we are at the stage where we try to find arguments when one >>> solution is better than the other one. >>> >>> Ciao >>> Hannes >>> >>> Winterbottom, James wrote: >>>> I am at a loss to understand why either needs a coarse location if the >>>> PSAP URI is provided directly to the end-point. >>>> >>>> >>>>> -----Original Message----- >>>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>>> Sent: Tuesday, 5 June 2007 11:42 AM >>>>> To: 'Hannes Tschofenig'; 'Stark, Barbara' >>>>> Cc: 'ECRIT' >>>>> Subject: RE: [Ecrit] Location Hiding - another look >>>>> >>>>> I don't understand where this is going. >>>>> If the access network supplies coarse location to a non-authenticated >>>>> querier which is sufficient for routing or for validation, then it >>>>> >>>> doesn't >>>> >>>>> matter if it's the endpoint or the VSP that is doing the routing or >>>>> >>>> the >>>> >>>>> validating. >>>>> >>>>> Neither the VSP nor the endpoint is an authorized querier to the >>>>> >>>> access >>>> >>>>> network. They are of equal status, they get the same result. >>>>> >>>>> Brian >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>> Sent: Monday, June 04, 2007 4:13 PM >>>>>> To: Stark, Barbara >>>>>> Cc: ECRIT >>>>>> Subject: Re: [Ecrit] Location Hiding - another look >>>>>> >>>>>> Hi Barbara, >>>>>> >>>>>> Stark, Barbara wrote: >>>>>> >>>>>>> I think it's important for the end point to be able to get the >>>>>>> >>>> PSAP >>>> >>>>> URI, >>>>> >>>>>>> because there may not be a VSP, at all. >>>>>>> >>>>>> For the case where there is no VSP, also referred as the >>>>>> >>>> unauthenticated >>>> >>>>>> emergency service architecture, the access network provider has to >>>>>> provide emergency service support directly or indirectly (via a >>>>>> partnership with another emergency service infrastructure provider). >>>>>> >>>>>> You additionally have to consider the case where link layer >>>>>> authentication can also be bypassed since you might loose more than >>>>>> >>>> just >>>> >>>>>> the credentials of the VSP. >>>>>> >>>>>> >>>>>>> I don't think the architecture >>>>>>> should require that there be a VSP in order to make a SIP call >>>>>>> >>>> over >>>> >>>>> the >>>>> >>>>>>> Internet. Certainly, VSPs are needed to get to PSAPs on the legacy >>>>>>> >>>>> phone >>>>> >>>>>>> network. But once PSAPs are reachable directly by VoIP, the >>>>>>> >>>>> architecture >>>>> >>>>>>> should allow end devices with open Internet access, but no VSP, to >>>>>>> >>>>> make >>>>> >>>>>>> emergency calls. >>>>>>> >>>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> >>>>>>> Barbara >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>> Sent: Monday, June 04, 2007 5:40 AM >>>>>>> To: ECRIT >>>>>>> Subject: [Ecrit] Location Hiding - another look >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> with location hiding we assumed that the network operator does not >>>>>>> >>>>> want >>>>> >>>>>>> to provide information about the precise location information to >>>>>>> >>>> the >>>> >>>>> end >>>>> >>>>>>> point. >>>>>>> A lot of discussions focused on the question how it can still >>>>>>> >>>> obtain a >>>> >>>>>>> PSAP URI in that case. >>>>>>> >>>>>>> There is, however, the question why the end point needs to obtain >>>>>>> >>>> this >>>> >>>>>>> PSAP URI in the location hiding case at all. >>>>>>> Why cannot we just assume that the VSP has to obtain some location >>>>>>> information from the ASP/ISP via LbyR and then it runs a LoST >>>>>>> >>>> query as >>>> >>>>>>> we specified it. >>>>>>> >>>>>>> DONE >>>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> ***** >>>>>>> >>>>>>> The information transmitted is intended only for the person or >>>>>>> >>>> entity >>>> >>>>> to >>>>> >>>>>> which it is addressed and may contain confidential, proprietary, >>>>>> >>>> and/or >>>> >>>>>> privileged material. Any review, retransmission, dissemination or >>>>>> >>>> other >>>> >>>>>> use of, or taking of any action in reliance upon this information by >>>>>> persons or entities other than the intended recipient is prohibited. >>>>>> >>>> If >>>> >>>>>> you received this in error, please contact the sender and delete the >>>>>> material from all computers. GA621 >>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>>> >>>> ------------------------------------------------------------------------------------------------ >>>> >>>> This message is for the designated recipient only and may >>>> contain privileged, proprietary, or otherwise private information. >>>> If you have received it in error, please notify the sender >>>> immediately and delete the original. Any unauthorized use of >>>> this email is prohibited. >>>> ------------------------------------------------------------------------------------------------ >>>> >>>> [mf2] >>>> >>>> >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 10:10:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZjb-0001VT-V2; Tue, 05 Jun 2007 10:10:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZjb-0001VO-0x for ecrit@ietf.org; Tue, 05 Jun 2007 10:10:07 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvZjZ-00049x-Nw for ecrit@ietf.org; Tue, 05 Jun 2007 10:10:07 -0400 Received: from [204.8.159.23] (temp-openyrless-dhcp23.bu.edu [204.8.159.23]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l55E9ifX025137 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 Jun 2007 10:09:49 -0400 (EDT) In-Reply-To: <3AD88C5F-AEAE-4FEB-BCDD-27738BC947A3@hxr.us> References: <4663DE0A.1050409@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p><46647238.80808@gmx.net> <179e01c7a712$c557bd20$6601a8c0@cis.neustar.com> <4665088B.4010104@gmx.net> <3AD88C5F-AEAE-4FEB-BCDD-27738BC947A3@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A2B593B-61F8-4A00-AA0C-E72289B76242@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Location Hiding - another look Date: Tue, 5 Jun 2007 10:09:53 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 5, 2007, at 9:51 AM, Andrew Newton wrote: > > On Jun 5, 2007, at 9:10 AM, Henning Schulzrinne wrote: > >> Unless we agree whether VSP PSAP URI verification is a requirement >> or not, we are unlikely to make much progress. > > Good point. Just backing up a bit, the requirement is really that > VSPs need to verify that a routed emergency call is really a routed > emergency call. Verifying the PSAP URI is just one method, but one > which seems to hold most promise. I can't think of any other, unless you want to administer lie detector tests to the caller. > > The most common objection to the current method proposed seems to > be that ASPs/ISPs must then provision both coarse grain and fine > grain location information -- the coarse grain location info being > used by the VSP as an input to LoST to verify the PSAP URI. Some of us believe that this burden is trivial. It also affects only those that benefit from location hiding. > > Just thinking out loud here, but if we could use the PSAP URI as > the input to LoST then this problem goes away. This is similar to > reverse DNS lookups. The input is a PSAP URI and the output is a > . A change to LoST would be required to support this. We've discussed this extensively in the past, so I'm loath to repeat this discussion. The changes are fairly significant, as this requires more than just adding a message or two, but rather requires global and reliable propagation of URLs. A basic criterion for any network architecture should be that those imposing a burden on others should also bear the cost. In other words, if somebody wants location hiding, they shouldn't make life more difficult for the rest of the world that obtains no benefit from that behavior. Forcing LoST maintainers and VSPs to add complexity violates this basic principle. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 10:12:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZlM-0003wk-HW; Tue, 05 Jun 2007 10:11:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZlL-0003wf-Bf for ecrit@ietf.org; Tue, 05 Jun 2007 10:11:55 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvZlK-0004MO-P2 for ecrit@ietf.org; Tue, 05 Jun 2007 10:11:55 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HvZlJ-0001Kg-55; Tue, 05 Jun 2007 10:11:53 -0400 Received: from [127.0.0.1] (col-dhcp33-244-154.bbn.com [128.33.244.154]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l55EBpw16719; Tue, 5 Jun 2007 10:11:52 -0400 (EDT) Message-ID: <46656F25.7040508@bbn.com> Date: Tue, 05 Jun 2007 10:11:49 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Location Hiding - another look References: <4663DE0A.1050409@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p><46647238.80808@gmx.net> <179e01c7a712$c557bd20$6601a8c0@cis.neustar.com> <4665088B.4010104@gmx.net> <3AD88C5F-AEAE-4FEB-BCDD-27738BC947A3@hxr.us> In-Reply-To: <3AD88C5F-AEAE-4FEB-BCDD-27738BC947A3@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Andy, We'd discussed this briefly before. I was thinking even simpler, inputting a URI and returning a boolean (is this a PSAP?) or a service boundary [reference]. In our previous discussions where we got stuck was changes to the mapping architecture (necessary changes to the LoST XML are minimal). You end up needing to flood URIs back up the LoST tree, then to a cluster of field guides that answer such queries. ISTM that such an architecture would be reasonable to deploy: The volume of data that would need to get passed around is fairly low, and changes are not that frequent. Others disagree with this. --Richard Andrew Newton wrote: > > On Jun 5, 2007, at 9:10 AM, Henning Schulzrinne wrote: > >> Unless we agree whether VSP PSAP URI verification is a requirement or >> not, we are unlikely to make much progress. > > Good point. Just backing up a bit, the requirement is really that VSPs > need to verify that a routed emergency call is really a routed emergency > call. Verifying the PSAP URI is just one method, but one which seems to > hold most promise. > > The most common objection to the current method proposed seems to be > that ASPs/ISPs must then provision both coarse grain and fine grain > location information -- the coarse grain location info being used by the > VSP as an input to LoST to verify the PSAP URI. > > Just thinking out loud here, but if we could use the PSAP URI as the > input to LoST then this problem goes away. This is similar to reverse > DNS lookups. The input is a PSAP URI and the output is a . A > change to LoST would be required to support this. > > -andy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 10:22:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZvi-0006wJ-VF; Tue, 05 Jun 2007 10:22:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZve-0006vh-Jy for ecrit@ietf.org; Tue, 05 Jun 2007 10:22:37 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvZvd-0006Wv-AX for ecrit@ietf.org; Tue, 05 Jun 2007 10:22:34 -0400 Received: from [204.8.159.23] (temp-openyrless-dhcp23.bu.edu [204.8.159.23]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l55ELsFJ008201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 Jun 2007 10:21:59 -0400 (EDT) In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA043E8519@crexc41p> References: <46655136.8090304@gmx.net> <46655EE9.4010805@bbn.com> <7582BC68E4994F4ABF0BD4723975C3FA043E8519@crexc41p> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Location Hiding - another look Date: Tue, 5 Jun 2007 10:22:03 -0400 To: "Stark, Barbara" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 5, 2007, at 10:03 AM, Stark, Barbara wrote: > Thanks, Richard. My sentiments, exactly. I don't trust the Sierra > Leone > VSP, the box in your basement, or the plethora of Asterisk servers > in so > many people's basements and small and home offices, any more or less > than I trust communications directly from end devices. Having a VSP in > the flow does Nobody has said that they should be. See my comments on this. > > Unless we want to create an emergency architecture that forces end > users > to have relationships with "trustworthy" (certified?) VSPs [although I > salivate at such an idea ... ;-) ], I think the end device needs to > accept personal responsibility for as much as it can, where the > need for > emergency services is concerned. The abilities of a VSP (if > present) are > simply a redundant back-up to the capabilities of the end device, > where > emergency services are concerned. This is a false dichotomy. I think there is general agreement that - not all calls will be originating from VSPs (and that VSPs should not be required) - not all VSPs will be known to PSAPs In previous discussions in other contexts, it has been claimed that even having most or some calls be traceable or location-verifiable is useful. Either there is value to "some call" validation in any of these scenarios or there isn't, but this then applies across all three types of validation. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 10:25:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZyb-0001jw-J5; Tue, 05 Jun 2007 10:25:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvZya-0001ji-0L for ecrit@ietf.org; Tue, 05 Jun 2007 10:25:36 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvZyY-0006oE-GF for ecrit@ietf.org; Tue, 05 Jun 2007 10:25:35 -0400 Received: (qmail invoked by alias); 05 Jun 2007 14:25:33 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp032) with SMTP; 05 Jun 2007 16:25:33 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18jdIwvoE8jRALIllfNkCZX1THg+L8oJ++3cNdTRK ARRr487uR6PlZD Message-ID: <4665725B.70002@gmx.net> Date: Tue, 05 Jun 2007 16:25:31 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Location Hiding: Let's Make some Progress References: <46613214.5030202@gmx.net> <97EF79AE-FF58-42BE-AC9A-680DC0EED3ED@hxr.us> In-Reply-To: <97EF79AE-FF58-42BE-AC9A-680DC0EED3ED@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Andy, Andrew Newton wrote: > > On Jun 2, 2007, at 5:02 AM, Hannes Tschofenig wrote: >> To restart the discussion Henning and myself have written a short >> draft about solution#3: >> http://www.tschofenig.priv.at/twiki/pub/EmergencyServices/LocationHiding/draft-schulzrinne-ecrit-lost-in-held-00.txt >> > > Interesting... you have taken bits of ideas from various parts of > these discussions and come up with a good proposal. I appreciate the > collaborative spirit you and Henning have shown here. > Good to hear something nice > I like this approach. You like the approach of summarizing the discussion or the idea of carrying LoST responses in HELD? > Here are my comments: > > 1) One point of the ECRIT architecture is not covered, and that is > getting LoST information at call time. The could be done via an > update from/to the LCS. True. The protocol has to support a way to re-query and to support mobility. Without a service boundary (or a notification mechanism) the client has to guess when he moves outside the boundary. That's certainly a weakness of the mechanism. On the other hand that's already a weakness of the LbyR without the concept of a subscription. > > 2) Perhaps this draft could be made general to all LCPs instead of > just HELD, or at-least to all XML carrying LCPs. Even DHCP might be > able to carry this information in a binary form of XML (perhaps). To > do this, maybe a _short_ list of LCP protocol requirements should be > stated. Something like this (just a strawman, I'm not wed to it): > > For an LCP to LoST compliant/capable, it must support the following > protocol interactions between an LCP server and LCP client: > a) clients MUST be able to assert the service URNs of the > services they need. > b) clients MUST be able to refresh their LoST mapping data. > c) clients MUST be able to obtain a list of LoST service URNs > that are available. > Sounds quite reasonable to me. > 3) I agree with section 6. In fact, I'm fairly confident you will > never need to do this. Just use the LoST schema. But I think you need to profile it. For example: While you need the content of the mapping you the usage of the service boundary is not required if you only use it with LbyR. Do you envision that HELD is piggy-backing the entire LoST exhanges? Probably that would not be a bad idea. Furthermore, there is also the question whether you send a single request at once or multiple requests at the same time. Here are some more thoughts: Service Boundary: The LCP may decide not to return a service boundary. That's possible with the current LoST version. Recursive Attribute: The default points to false. The client can change it to whatever it likes best. Hence, a minimal version of the findService request attached to a LCP message would be something like: (obviously you would have to omit the location info). urn:service:sos.police Requesting information about more than one service is not possible in LoST but it is certainly possible to enhance LoST, if necessary. For example: Something like the example below could return multiple LoST mappings for services provided by the local network. urn:service:sos* These are, however, optimizations and potentially subject for a separate discussion. In a response the following details are useful: New York City Police Department urn:service:sos.police sip:nypd@example.com xmpp:nypd@example.com 911 The serviceBoundary is omitted and that is legal with the current LoST schema. What do you think about that? Ciao Hannes > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 10:27:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hva0N-0003sj-TW; Tue, 05 Jun 2007 10:27:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hva0M-0003sT-Us for ecrit@ietf.org; Tue, 05 Jun 2007 10:27:26 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hva0L-0006yl-GE for ecrit@ietf.org; Tue, 05 Jun 2007 10:27:26 -0400 Received: (qmail invoked by alias); 05 Jun 2007 14:27:24 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp048) with SMTP; 05 Jun 2007 16:27:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+oek5/GyKo+lyIgAFM+S6WMqh7TNSTmbHu062pR2 x/VGhbh+NOjZy9 Message-ID: <466572CB.9050601@gmx.net> Date: Tue, 05 Jun 2007 16:27:23 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Location Hiding - another look References: <4663DE0A.1050409@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p><46647238.80808@gmx.net> <179e01c7a712$c557bd20$6601a8c0@cis.neustar.com> <4665088B.4010104@gmx.net> <3AD88C5F-AEAE-4FEB-BCDD-27738BC947A3@hxr.us> In-Reply-To: <3AD88C5F-AEAE-4FEB-BCDD-27738BC947A3@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Andy, Andrew Newton wrote: > > On Jun 5, 2007, at 9:10 AM, Henning Schulzrinne wrote: > >> Unless we agree whether VSP PSAP URI verification is a requirement or >> not, we are unlikely to make much progress. > > Good point. Just backing up a bit, the requirement is really that > VSPs need to verify that a routed emergency call is really a routed > emergency call. Verifying the PSAP URI is just one method, but one > which seems to hold most promise. > Yep. > The most common objection to the current method proposed seems to be > that ASPs/ISPs must then provision both coarse grain and fine grain > location information -- the coarse grain location info being used by > the VSP as an input to LoST to verify the PSAP URI. Yep > > Just thinking out loud here, but if we could use the PSAP URI as the > input to LoST then this problem goes away. This is similar to reverse > DNS lookups. The input is a PSAP URI and the output is a . > A change to LoST would be required to support this. That's true. But that would require an entirely separate infrastructure.... Ciao Hannes > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 10:35:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hva81-00033F-Uk; Tue, 05 Jun 2007 10:35:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hva80-0002zZ-FP for ecrit@ietf.org; Tue, 05 Jun 2007 10:35:20 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hva80-0007bt-0Q for ecrit@ietf.org; Tue, 05 Jun 2007 10:35:20 -0400 Received: (qmail invoked by alias); 05 Jun 2007 14:35:18 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp056) with SMTP; 05 Jun 2007 16:35:18 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX193wxISPYl34yp4HEP4POvwA/PiqFGqzU3DWdJYCM jdeWrGQmVMIaAS Message-ID: <466574A4.3070504@gmx.net> Date: Tue, 05 Jun 2007 16:35:16 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Richard Barnes Subject: Re: [Ecrit] Location Hiding - another look References: <4663DE0A.1050409@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p><46647238.80808@gmx.net> <179e01c7a712$c557bd20$6601a8c0@cis.neustar.com> <4665088B.4010104@gmx.net> <3AD88C5F-AEAE-4FEB-BCDD-27738BC947A3@hxr.us> <46656F25.7040508@bbn.com> In-Reply-To: <46656F25.7040508@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Richard, where do you put the PSAP URI as input to? When doing this with LoST then you essentially create something like a reverse lookup mechanism. Flooding as an extreme form was also mentioned and is certainly also possible. Ciao Hannes Richard Barnes wrote: > Andy, > > We'd discussed this briefly before. I was thinking even simpler, > inputting a URI and returning a boolean (is this a PSAP?) or a service > boundary [reference]. > > In our previous discussions where we got stuck was changes to the > mapping architecture (necessary changes to the LoST XML are minimal). > You end up needing to flood URIs back up the LoST tree, then to a > cluster of field guides that answer such queries. > > ISTM that such an architecture would be reasonable to deploy: The > volume of data that would need to get passed around is fairly low, and > changes are not that frequent. Others disagree with this. > > --Richard > > > > Andrew Newton wrote: >> >> On Jun 5, 2007, at 9:10 AM, Henning Schulzrinne wrote: >> >>> Unless we agree whether VSP PSAP URI verification is a requirement >>> or not, we are unlikely to make much progress. >> >> Good point. Just backing up a bit, the requirement is really that >> VSPs need to verify that a routed emergency call is really a routed >> emergency call. Verifying the PSAP URI is just one method, but one >> which seems to hold most promise. >> >> The most common objection to the current method proposed seems to be >> that ASPs/ISPs must then provision both coarse grain and fine grain >> location information -- the coarse grain location info being used by >> the VSP as an input to LoST to verify the PSAP URI. >> >> Just thinking out loud here, but if we could use the PSAP URI as the >> input to LoST then this problem goes away. This is similar to reverse >> DNS lookups. The input is a PSAP URI and the output is a . >> A change to LoST would be required to support this. >> >> -andy >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 11:14:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvak7-0001yJ-Mm; Tue, 05 Jun 2007 11:14:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvak6-0001xt-Cf for ecrit@ietf.org; Tue, 05 Jun 2007 11:14:42 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvak5-0007Ne-1X for ecrit@ietf.org; Tue, 05 Jun 2007 11:14:42 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 05 Jun 2007 11:14:35 -0400 id 0158836A.46657DE0.00004017 In-Reply-To: <4665725B.70002@gmx.net> References: <46613214.5030202@gmx.net> <97EF79AE-FF58-42BE-AC9A-680DC0EED3ED@hxr.us> <4665725B.70002@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Location Hiding: Let's Make some Progress Date: Tue, 5 Jun 2007 11:14:30 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 5, 2007, at 10:25 AM, Hannes Tschofenig wrote: > You like the approach of summarizing the discussion or the idea of > carrying LoST responses in HELD? Both, though I was focusing on the latter. >> 3) I agree with section 6. In fact, I'm fairly confident you will >> never need to do this. Just use the LoST schema. > But I think you need to profile it. For example: While you need the > content of the mapping you the usage of the service boundary is not > required if you only use it with LbyR. Redacting information from a LoST message is already possible without defining an entirely new schema. The problem with going down the new schema road is that it makes protocol and system maintenance a pain. When we come out with LoST v2, we'll have to go rev this other schema as well, etc.... > Do you envision that HELD is piggy-backing the entire LoST > exhanges? Probably that would not be a bad idea. > Furthermore, there is also the question whether you send a single > request at once or multiple requests at the same time. > > Here are some more thoughts: > > Service Boundary: The LCP may decide not to return a service > boundary. That's possible with the current LoST version. > > Recursive Attribute: The default points to false. The client can > change it to whatever it likes best. > > Hence, a minimal version of the findService request attached to a > LCP message would be something like: > (obviously you would have to omit the location info). > > > urn:service:sos.police > > > Requesting information about more than one service is not possible > in LoST but it is certainly possible to enhance LoST, if necessary. > > For example: Something like the example below could return multiple > LoST mappings for services provided by the local network. > > urn:service:sos* > > These are, however, optimizations and potentially subject for a > separate discussion. > > In a response the following details are useful: > > > xmlns:p2="http://www.opengis.net/gml"> > expires="2007-01-01T01:44:33Z" > lastUpdated="2006-11-01T01:00:00Z" > source="authoritative.example" > sourceId="7e3f40b098c711dbb6060800200c9a66"> > > New York City Police Department > > urn:service:sos.police > sip:nypd@example.com > xmpp:nypd@example.com > 911 > > > > > > > > The serviceBoundary is omitted and that is legal with the current > LoST schema. > > What do you think about that? It's all possible. Of course, taking this to its logical conclusion, an easier approach would be to just tunnel LoST through the LCP. But once you have done that, you gotta ask why they are not just running a LoST server and using the LCP to point to it. One possible answer is that there is a state issue between the LCP and LoST sessions. But we may be able to fix that with some fancy foot work in LoST. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 11:20:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvapR-0002xB-Fy; Tue, 05 Jun 2007 11:20:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvapP-0002x1-QN for ecrit@ietf.org; Tue, 05 Jun 2007 11:20:11 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvapO-000071-Jp for ecrit@ietf.org; Tue, 05 Jun 2007 11:20:11 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 05 Jun 2007 11:20:10 -0400 id 0158817B.46657F2A.000040D3 In-Reply-To: <7A2B593B-61F8-4A00-AA0C-E72289B76242@cs.columbia.edu> References: <4663DE0A.1050409@gmx.net><7582BC68E4994F4ABF0BD4723975C3FA043E8335@crexc41p><46647238.80808@gmx.net> <179e01c7a712$c557bd20$6601a8c0@cis.neustar.com> <4665088B.4010104@gmx.net> <3AD88C5F-AEAE-4FEB-BCDD-27738BC947A3@hxr.us> <7A2B593B-61F8-4A00-AA0C-E72289B76242@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Location Hiding - another look Date: Tue, 5 Jun 2007 11:20:08 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 5, 2007, at 10:09 AM, Henning Schulzrinne wrote: > A basic criterion for any network architecture should be that those > imposing a burden on others should also bear the cost. In other > words, if somebody wants location hiding, they shouldn't make life > more difficult for the rest of the world that obtains no benefit > from that behavior. Forcing LoST maintainers and VSPs to add > complexity violates this basic principle. Alright, I'll give you this point (though I'm not understanding the complexity being foisted upon VSPs). But this does add additional mappings for the system. However, such a mapping is not a bad idea. Many communications networks maintain these types of mappings to help in administrative and troubleshooting issues. The Internet has reverse DNS and Whois, to name just one example. So there are other benefits to it. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 11:53:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvbLa-0000uB-D2; Tue, 05 Jun 2007 11:53:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvbLY-0000sw-TI for ecrit@ietf.org; Tue, 05 Jun 2007 11:53:24 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HvbLX-00054Y-JE for ecrit@ietf.org; Tue, 05 Jun 2007 11:53:24 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 05 Jun 2007 11:53:20 -0400 id 0158817B.466586F0.000048B9 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <64D5A4F3-27C2-478A-BA0B-F45339A7674C@hxr.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Andrew Newton Date: Tue, 5 Jun 2007 11:53:19 -0400 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Ecrit] A compromise to move us forward X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org All, While we might find an answer to the location hiding scenario in the long term, I think it is rather apparent that a near-term solution the satisfies all/most constituencies is unlikely to materialize. Caught in the middle of this is all the other work we've done. I propose we do the following: 1) Move forward with the modest modifications to LoST to enable Henning's Location Fuzzing proposal (#1 on the wiki). 2) Note in some document somewhere (phonebcp, LoST, ecrit- framework... I don't care) how the location fuzzing proposal works and state that it is not ideal and a better solution is in the works. 3) Seek new charter items for a more thorough location-hiding solution. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 13:58:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvdJ3-00053A-IJ; Tue, 05 Jun 2007 13:58:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvdJ2-000535-Jb for ecrit@ietf.org; Tue, 05 Jun 2007 13:58:56 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvdJ1-0007AC-BU for ecrit@ietf.org; Tue, 05 Jun 2007 13:58:56 -0400 Received: from [204.8.159.23] (temp-openyrless-dhcp23.bu.edu [204.8.159.23]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l55Hwnfv020788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 Jun 2007 13:58:53 -0400 (EDT) In-Reply-To: <4665725B.70002@gmx.net> References: <46613214.5030202@gmx.net> <97EF79AE-FF58-42BE-AC9A-680DC0EED3ED@hxr.us> <4665725B.70002@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <737FABC5-544C-472A-A9B6-CA3CE1CFE1B3@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Location Hiding: Let's Make some Progress Date: Tue, 5 Jun 2007 13:58:57 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > True. The protocol has to support a way to re-query and to support > mobility. > Without a service boundary (or a notification mechanism) the client > has to guess when he moves outside the boundary. > That's certainly a weakness of the mechanism. On the other hand > that's already a weakness of the LbyR without the concept of a > subscription. >> Most of the discussion has been on fixed (DSL) infrastructure. Once you get into notification of changes in PSAP URL list, you have then successfully duplicated the SIP configuration work that is being completed in SIPPING. That working group might be interested in this competing effort. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 14:08:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvdS3-00080P-Oq; Tue, 05 Jun 2007 14:08:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvdS2-00080F-Mf for ecrit@ietf.org; Tue, 05 Jun 2007 14:08:14 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvdRz-0000FM-UO for ecrit@ietf.org; Tue, 05 Jun 2007 14:08:14 -0400 Received: (qmail invoked by alias); 05 Jun 2007 18:08:09 -0000 Received: from p5498739d.dip.t-dialin.net (EHLO [192.168.178.24]) [84.152.115.157] by mail.gmx.net (mp003) with SMTP; 05 Jun 2007 20:08:09 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18UtLkPvIIU5DNqp+cP0WcUdELn1/lDZbpVGzB1to +X5AazrqiV7je/ Message-ID: <4665A688.4000303@gmx.net> Date: Tue, 05 Jun 2007 20:08:08 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] A compromise to move us forward References: <64D5A4F3-27C2-478A-BA0B-F45339A7674C@hxr.us> In-Reply-To: <64D5A4F3-27C2-478A-BA0B-F45339A7674C@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Andy thank you for the proposal. Sounds good to me. Ciao Hannes Andrew Newton wrote: > All, > > While we might find an answer to the location hiding scenario in the > long term, I think it is rather apparent that a near-term solution the > satisfies all/most constituencies is unlikely to materialize. Caught > in the middle of this is all the other work we've done. > > I propose we do the following: > > 1) Move forward with the modest modifications to LoST to enable > Henning's Location Fuzzing proposal (#1 on the wiki). > 2) Note in some document somewhere (phonebcp, LoST, ecrit-framework... > I don't care) how the location fuzzing proposal works and state that > it is not ideal and a better solution is in the works. > 3) Seek new charter items for a more thorough location-hiding solution. > > -andy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 15:03:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HveJL-0003UM-9l; Tue, 05 Jun 2007 15:03:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HveJK-0003UH-Ve for ecrit@ietf.org; Tue, 05 Jun 2007 15:03:18 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HveJI-0006Gh-9Q for ecrit@ietf.org; Tue, 05 Jun 2007 15:03:18 -0400 Received: from ([139.76.131.31]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.178377120; Tue, 05 Jun 2007 15:02:50 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 5 Jun 2007 15:02:23 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 5 Jun 2007 15:02:23 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] A compromise to move us forward Date: Tue, 5 Jun 2007 15:02:21 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA043E8624@crexc41p> In-Reply-To: <64D5A4F3-27C2-478A-BA0B-F45339A7674C@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] A compromise to move us forward thread-index: Acenib/vXpGQE8Y3Q6a3KiqqviFECQAF+XyQ References: <64D5A4F3-27C2-478A-BA0B-F45339A7674C@hxr.us> From: "Stark, Barbara" To: "Andrew Newton" ,"ECRIT" X-OriginalArrivalTime: 05 Jun 2007 19:02:23.0335 (UTC) FILETIME=[0CBA2770:01C7A7A4] X-Spam-Score: 0.6 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I would prefer that, in addition to moving forward with #1, we also allow the LoST info to be returned via the L7 LCP. And use Richard's proposal on how end points should work. Don't deal with the LoST reverse look-up at this time. If national/state regulations permit use of LbyR + PSAP URI (no LbyV at all), then those same regulations can publish PSAP URIs for VSPs to use as look-up, and they can admit that VSPs based in other countries are beyond their regulation and can charge for calls to emergency services. I really don't think the EU can insist that US VSPs, who provide US phone numbers, and market in the US, should be required to provide free routing for emergency calls destined for the EU. If this is done by treaty, then we ca agree to swap PSAP URI lists. It's possible to deal with the VSP billing issue "out-of-band". Let the regulators and effected parties decide if it's a problem. Just give us the capability. Barbara -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Tuesday, June 05, 2007 11:53 AM To: ECRIT Subject: [Ecrit] A compromise to move us forward All, While we might find an answer to the location hiding scenario in the long term, I think it is rather apparent that a near-term solution =20 the satisfies all/most constituencies is unlikely to materialize. =20 Caught in the middle of this is all the other work we've done. I propose we do the following: 1) Move forward with the modest modifications to LoST to enable Henning's Location Fuzzing proposal (#1 on the wiki). 2) Note in some document somewhere (phonebcp, LoST, ecrit- framework... I don't care) how the location fuzzing proposal works and state that it is not ideal and a better solution is in the works. 3) Seek new charter items for a more thorough location-hiding solution. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA625 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 15:43:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvewQ-0003FW-3s; Tue, 05 Jun 2007 15:43:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvewO-0003FR-QM for ecrit@ietf.org; Tue, 05 Jun 2007 15:43:40 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvewN-0001Cw-Fm for ecrit@ietf.org; Tue, 05 Jun 2007 15:43:40 -0400 X-SEF-Processed: 5_0_0_910__2007_06_05_14_51_08 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 05 Jun 2007 14:51:08 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jun 2007 14:43:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Location Hiding - another look Date: Tue, 5 Jun 2007 14:43:55 -0500 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA043E8519@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location Hiding - another look Thread-Index: AcenchyzmdlDPs+tTtKlbrr2kLptVwAAkFPwAAz1g9A= References: <46655136.8090304@gmx.net> <46655EE9.4010805@bbn.com> <7582BC68E4994F4ABF0BD4723975C3FA043E8519@crexc41p> From: "Winterbottom, James" To: "Stark, Barbara" , "Richard Barnes" , "Hannes Tschofenig" X-OriginalArrivalTime: 05 Jun 2007 19:43:37.0463 (UTC) FILETIME=[CF6C2070:01C7A7A9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Is there a misunderstanding as to what the meaning of PSAP URI is=3F=0D=0AI= don't see the PSAP URI in almost all cases taking me directly to Bob=0D=0A= at the Denton PSAP. When I think of a PSAP URI, I think of this as being=0D= =0Athe (forgive the NENA i3 terminology) ESRP URI.=20=0D=0AThe ESRP being a= gateway shielding access to the actual emergency=0D=0Anetwork.=0D=0A=0D=0A= If I got this URI sending things to it directly seems reasonable to me.=0D=0A=0D= =0ACheers=0D=0AJames=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: S= tark, Barbara [mailto:bs7652@att.com]=0D=0A> Sent: Wednesday, 6 June 2007 1= 2:04 AM=0D=0A> To: Richard Barnes; Hannes Tschofenig=0D=0A> Cc: ECRIT=0D=0A= > Subject: RE: [Ecrit] Location Hiding - another look=0D=0A>=20=0D=0A> Than= ks, Richard. My sentiments, exactly. I don't trust the Sierra=0D=0ALeone=0D= =0A> VSP, the box in your basement, or the plethora of Asterisk servers in=0D= =0Aso=0D=0A> many people's basements and small and home offices, any more o= r less=0D=0A> than I trust communications directly from end devices. Having= a VSP in=0D=0A> the flow does=0D=0A>=20=0D=0A> Unless we want to create an= emergency architecture that forces end=0D=0Ausers=0D=0A> to have relations= hips with "trustworthy" (certified=3F) VSPs [although I=0D=0A> salivate at = such an idea ... ;-) ], I think the end device needs to=0D=0A> accept perso= nal responsibility for as much as it can, where the need=0D=0Afor=0D=0A> em= ergency services is concerned. The abilities of a VSP (if present)=0D=0Aare=0D= =0A> simply a redundant back-up to the capabilities of the end device,=0D=0A= where=0D=0A> emergency services are concerned.=0D=0A> Barbara=0D=0A>=20=0D=0A= > -----Original Message-----=0D=0A> From: Richard Barnes [mailto:rbarnes@bb= n.com]=0D=0A> Sent: Tuesday, June 05, 2007 9:03 AM=0D=0A> To: Hannes Tschof= enig=0D=0A> Cc: Stark, Barbara; ECRIT=0D=0A> Subject: Re: [Ecrit] Location = Hiding - another look=0D=0A>=20=0D=0A> > These functions still have to exis= t since otherwise the end host=0D=0Awould=0D=0A>=20=0D=0A> > directly conta= ct the PSAP and there wouldn't be an authenticated=0D=0A> > identity attach= ed to the emergency call. This would be a serious=0D=0A> > security concern= =2E=0D=0A>=20=0D=0A> From a security perspective, there's no difference be= tween calling a=0D=0A> PSAP through a proxy or directly: There's no more a = relationship=0D=0Abetween=0D=0A> the proxy/VSP and the PSAP than between th= e endpoint and the PSAP.=0D=0A> E.g., a PSAP in Fairfax, VA has (probably) = no way to authenticate a=0D=0AVSP=0D=0A> Sierra Leone, or the "VSP" that I = have running on a box in my=0D=0Abasement,=0D=0A> and likewise, no way to a= uthenticate identities of callers from those=0D=0A> VSPs.=0D=0A>=20=0D=0A> = --Richard=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> *****=0D=0A>=20=0D= =0A> The information transmitted is intended only for the person or entity=0D= =0Ato=0D=0A> which it is addressed and may contain confidential, proprietar= y,=0D=0Aand/or=0D=0A> privileged material. Any review, retransmission, diss= emination or=0D=0Aother=0D=0A> use of, or taking of any action in reliance = upon this information by=0D=0A> persons or entities other than the intended= recipient is prohibited.=0D=0AIf=0D=0A> you received this in error, please= contact the sender and delete the=0D=0A> material from all computers. GA62= 1=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> ____________________________________= ___________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://= www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A---------------------------= ---------------------------------------------------------------------=0D=0A= This message is for the designated recipient only and may=0D=0Acontain priv= ileged, proprietary, or otherwise private information. =20=0D=0AIf you have= received it in error, please notify the sender=0D=0Aimmediately and delete= the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 15:57:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvf9d-0003dD-0l; Tue, 05 Jun 2007 15:57:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvf9a-0003co-95 for ecrit@ietf.org; Tue, 05 Jun 2007 15:57:18 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvf9Y-0005HS-R7 for ecrit@ietf.org; Tue, 05 Jun 2007 15:57:18 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 5 Jun 2007 21:57:16 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 21:57:14 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [Ecrit] A compromise to move us forward Date: Tue, 5 Jun 2007 21:57:14 +0200 Message-Id: <182C63BFBAF131428EA0C16F7FD2191B01358539@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: <64D5A4F3-27C2-478A-BA0B-F45339A7674C@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] A compromise to move us forward Thread-Index: Aceniay6SEcwPJTyQ5aieT8JQ8oYhwAIFKfQ From: "Liess, Laura" To: , X-OriginalArrivalTime: 05 Jun 2007 19:57:14.0495 (UTC) FILETIME=[B66950F0:01C7A7AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Andy, I think it is a good idea. =20 Thanks Laura > -----Urspr=FCngliche Nachricht----- > Von: Andrew Newton [mailto:andy@hxr.us] > Gesendet: Dienstag, 5. Juni 2007 17:53 > An: ECRIT > Betreff: [Ecrit] A compromise to move us forward >=20 >=20 > All, >=20 > While we might find an answer to the location hiding scenario in the > long term, I think it is rather apparent that a near-term solution =20 > the satisfies all/most constituencies is unlikely to materialize. =20 > Caught in the middle of this is all the other work we've done. >=20 > I propose we do the following: >=20 > 1) Move forward with the modest modifications to LoST to enable > Henning's Location Fuzzing proposal (#1 on the wiki). > 2) Note in some document somewhere (phonebcp, LoST, ecrit-=20 > framework... I don't care) how the location fuzzing proposal works =20 > and state that it is not ideal and a better solution is in the works. > 3) Seek new charter items for a more thorough location-hiding=20 > solution. >=20 > -andy >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 16:00:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvfD6-0008CL-SN; Tue, 05 Jun 2007 16:00:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvfD5-0008CG-AV for ecrit@ietf.org; Tue, 05 Jun 2007 16:00:55 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvfD3-0006UV-0x for ecrit@ietf.org; Tue, 05 Jun 2007 16:00:55 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 05 Jun 2007 16:00:52 -0400 id 0158837D.4665C0F4.0000074A In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA043E8624@crexc41p> References: <64D5A4F3-27C2-478A-BA0B-F45339A7674C@hxr.us> <7582BC68E4994F4ABF0BD4723975C3FA043E8624@crexc41p> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <27A064A0-D4CE-48EC-9122-B8AE128F2A27@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] A compromise to move us forward Date: Tue, 5 Jun 2007 16:00:50 -0400 To: "Stark, Barbara" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Barbara, Let's leave the details to item 3 for later. Unless you are suggesting that we complete your proposal immediately... which is not what I'm proposing. -andy On Jun 5, 2007, at 3:02 PM, Stark, Barbara wrote: > I would prefer that, in addition to moving forward with #1, we also > allow the LoST info to be returned via the L7 LCP. And use Richard's > proposal on how end points should work. Don't deal with the LoST > reverse > look-up at this time. If national/state regulations permit use of > LbyR + > PSAP URI (no LbyV at all), then those same regulations can publish > PSAP > URIs for VSPs to use as look-up, and they can admit that VSPs based in > other countries are beyond their regulation and can charge for > calls to > emergency services. I really don't think the EU can insist that US > VSPs, > who provide US phone numbers, and market in the US, should be required > to provide free routing for emergency calls destined for the EU. If > this > is done by treaty, then we ca agree to swap PSAP URI lists. > > It's possible to deal with the VSP billing issue "out-of-band". Let > the > regulators and effected parties decide if it's a problem. Just give us > the capability. > Barbara > > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Tuesday, June 05, 2007 11:53 AM > To: ECRIT > Subject: [Ecrit] A compromise to move us forward > > All, > > While we might find an answer to the location hiding scenario in the > long term, I think it is rather apparent that a near-term solution > the satisfies all/most constituencies is unlikely to materialize. > Caught in the middle of this is all the other work we've done. > > I propose we do the following: > > 1) Move forward with the modest modifications to LoST to enable > Henning's Location Fuzzing proposal (#1 on the wiki). > 2) Note in some document somewhere (phonebcp, LoST, ecrit- > framework... > I don't care) how the location fuzzing proposal works and state > that it > is not ideal and a better solution is in the works. > 3) Seek new charter items for a more thorough location-hiding > solution. > > -andy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > ***** > > The information transmitted is intended only for the person or > entity to which it is addressed and may contain confidential, > proprietary, and/or privileged material. Any review, > retransmission, dissemination or other use of, or taking of any > action in reliance upon this information by persons or entities > other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material > from all computers. GA625 > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 17:33:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvger-0003o1-5S; Tue, 05 Jun 2007 17:33:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvgee-0003cA-6S for ecrit@ietf.org; Tue, 05 Jun 2007 17:33:28 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvged-0000cI-0O for ecrit@ietf.org; Tue, 05 Jun 2007 17:33:28 -0400 Received: from [204.8.159.23] (temp-openyrless-dhcp23.bu.edu [204.8.159.23]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l55LXLJb020087 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 5 Jun 2007 17:33:22 -0400 (EDT) In-Reply-To: References: <46655136.8090304@gmx.net> <46655EE9.4010805@bbn.com> <7582BC68E4994F4ABF0BD4723975C3FA043E8519@crexc41p> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Location Hiding - another look Date: Tue, 5 Jun 2007 17:33:31 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org In some cases, devices are configured to always use an outbound proxy. In addition, in other cases, SBCs won't let voice in or out without the proxy lifting the gates. Thus, this is not an issue of technical necessity, but deployment realities. I don't see, however, why this matters at all. On Jun 5, 2007, at 3:43 PM, Winterbottom, James wrote: > Is there a misunderstanding as to what the meaning of PSAP URI is? > I don't see the PSAP URI in almost all cases taking me directly to Bob > at the Denton PSAP. When I think of a PSAP URI, I think of this as > being > the (forgive the NENA i3 terminology) ESRP URI. > The ESRP being a gateway shielding access to the actual emergency > network. > > If I got this URI sending things to it directly seems reasonable to > me. > > Cheers > James _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 19:24:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HviOO-0007qC-1u; Tue, 05 Jun 2007 19:24:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HviOM-0007nA-48 for ecrit@ietf.org; Tue, 05 Jun 2007 19:24:46 -0400 Received: from smtp4.andrew.com ([198.135.207.236] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HviOL-0001hR-Pg for ecrit@ietf.org; Tue, 05 Jun 2007 19:24:46 -0400 X-SEF-Processed: 5_0_0_910__2007_06_05_18_26_50 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp1 - SurfControl E-mail Filter (5.2.1); Tue, 05 Jun 2007 18:26:50 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jun 2007 18:24:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] A compromise to move us forward Date: Tue, 5 Jun 2007 18:24:43 -0500 Message-ID: In-Reply-To: <27A064A0-D4CE-48EC-9122-B8AE128F2A27@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] A compromise to move us forward Thread-Index: AcenrDvs1CTjvJ17TlmaZT5roP9azwAHBzxg References: <64D5A4F3-27C2-478A-BA0B-F45339A7674C@hxr.us><7582BC68E4994F4ABF0BD4723975C3FA043E8624@crexc41p> <27A064A0-D4CE-48EC-9122-B8AE128F2A27@hxr.us> From: "Winterbottom, James" To: "Andrew Newton" , "Stark, Barbara" X-OriginalArrivalTime: 05 Jun 2007 23:24:45.0052 (UTC) FILETIME=[B3858BC0:01C7A7C8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Andy,=0D=0A=0D=0AI would like your point 2 to go a bit further.=0D=0AI want= it state that if the End-Point is provide the PSAP URI and a=0D=0Alocation= URI that it has to use those for the emergency call. This=0D=0Ashould be i= n phone BCP. However the end-point gets this information I=0D=0Aagree is th= e subject of further work.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A> = -----Original Message-----=0D=0A> From: Andrew Newton [mailto:andy@hxr.us]=0D= =0A> Sent: Wednesday, 6 June 2007 6:01 AM=0D=0A> To: Stark, Barbara=0D=0A> = Cc: ECRIT=0D=0A> Subject: Re: [Ecrit] A compromise to move us forward=0D=0A= >=20=0D=0A> Barbara,=0D=0A>=20=0D=0A> Let's leave the details to item 3 for= later. Unless you are=0D=0A> suggesting that we complete your proposal im= mediately... which is not=0D=0A> what I'm proposing.=0D=0A>=20=0D=0A> -andy=0D= =0A>=20=0D=0A> On Jun 5, 2007, at 3:02 PM, Stark, Barbara wrote:=0D=0A>=20=0D= =0A> > I would prefer that, in addition to moving forward with #1, we also=0D= =0A> > allow the LoST info to be returned via the L7 LCP. And use Richard's=0D= =0A> > proposal on how end points should work. Don't deal with the LoST=0D=0A= > > reverse=0D=0A> > look-up at this time. If national/state regulations pe= rmit use of=0D=0A> > LbyR +=0D=0A> > PSAP URI (no LbyV at all), then those = same regulations can publish=0D=0A> > PSAP=0D=0A> > URIs for VSPs to use as= look-up, and they can admit that VSPs based=0D=0Ain=0D=0A> > other countri= es are beyond their regulation and can charge for=0D=0A> > calls to=0D=0A> = > emergency services. I really don't think the EU can insist that US=0D=0A>= > VSPs,=0D=0A> > who provide US phone numbers, and market in the US, shoul= d be=0D=0Arequired=0D=0A> > to provide free routing for emergency calls des= tined for the EU. If=0D=0A> > this=0D=0A> > is done by treaty, then we ca a= gree to swap PSAP URI lists.=0D=0A> >=0D=0A> > It's possible to deal with t= he VSP billing issue "out-of-band". Let=0D=0A> > the=0D=0A> > regulators an= d effected parties decide if it's a problem. Just give=0D=0Aus=0D=0A> > the= capability.=0D=0A> > Barbara=0D=0A> >=0D=0A> > -----Original Message-----=0D= =0A> > From: Andrew Newton [mailto:andy@hxr.us]=0D=0A> > Sent: Tuesday, Jun= e 05, 2007 11:53 AM=0D=0A> > To: ECRIT=0D=0A> > Subject: [Ecrit] A compromi= se to move us forward=0D=0A> >=0D=0A> > All,=0D=0A> >=0D=0A> > While we mig= ht find an answer to the location hiding scenario in the=0D=0A> > long term= , I think it is rather apparent that a near-term solution=0D=0A> > the sati= sfies all/most constituencies is unlikely to materialize.=0D=0A> > Caught i= n the middle of this is all the other work we've done.=0D=0A> >=0D=0A> > I = propose we do the following:=0D=0A> >=0D=0A> > 1) Move forward with the mod= est modifications to LoST to enable=0D=0A> > Henning's Location Fuzzing pro= posal (#1 on the wiki).=0D=0A> > 2) Note in some document somewhere (phoneb= cp, LoST, ecrit-=0D=0A> > framework...=0D=0A> > I don't care) how the locat= ion fuzzing proposal works and state=0D=0A> > that it=0D=0A> > is not ideal= and a better solution is in the works.=0D=0A> > 3) Seek new charter items = for a more thorough location-hiding=0D=0A> > solution.=0D=0A> >=0D=0A> > -a= ndy=0D=0A> >=0D=0A> > _______________________________________________=0D=0A= > > Ecrit mailing list=0D=0A> > Ecrit@ietf.org=0D=0A> > https://www1.ietf.o= rg/mailman/listinfo/ecrit=0D=0A> >=0D=0A> > *****=0D=0A> >=0D=0A> > The inf= ormation transmitted is intended only for the person or=0D=0A> > entity to = which it is addressed and may contain confidential,=0D=0A> > proprietary, a= nd/or privileged material. Any review,=0D=0A> > retransmission, disseminati= on or other use of, or taking of any=0D=0A> > action in reliance upon this = information by persons or entities=0D=0A> > other than the intended recipie= nt is prohibited. If you received=0D=0A> > this in error, please contact th= e sender and delete the material=0D=0A> > from all computers. GA625=0D=0A> = >=0D=0A> >=0D=0A>=20=0D=0A>=20=0D=0A> _____________________________________= __________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://w= ww1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A----------------------------= --------------------------------------------------------------------=0D=0AT= his message is for the designated recipient only and may=0D=0Acontain privi= leged, proprietary, or otherwise private information. =20=0D=0AIf you have = received it in error, please notify the sender=0D=0Aimmediately and delete = the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 20:48:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvjhm-0003BO-Il; Tue, 05 Jun 2007 20:48:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvjhl-0003BJ-Lj for ecrit@ietf.org; Tue, 05 Jun 2007 20:48:53 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvjhk-00033l-AX for ecrit@ietf.org; Tue, 05 Jun 2007 20:48:53 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 05 Jun 2007 20:48:51 -0400 id 01588103.46660473.0000407A In-Reply-To: References: <64D5A4F3-27C2-478A-BA0B-F45339A7674C@hxr.us><7582BC68E4994F4ABF0BD4723975C3FA043E8624@crexc41p> <27A064A0-D4CE-48EC-9122-B8AE128F2A27@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] A compromise to move us forward Date: Tue, 5 Jun 2007 20:48:48 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org James, Your suggestion presupposes a solution for item 3, which is not in the spirit of what I proposed. Besides, what does it mean that a client has to use a PSAP URI? Does that mean it has to resolve the URI and attempt a connection or can it send that URI in an INVITE to an outbound proxy? -andy On Jun 5, 2007, at 7:24 PM, Winterbottom, James wrote: > Andy, > > I would like your point 2 to go a bit further. > I want it state that if the End-Point is provide the PSAP URI and a > location URI that it has to use those for the emergency call. This > should be in phone BCP. However the end-point gets this information I > agree is the subject of further work. > > Cheers > James > > >> -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Wednesday, 6 June 2007 6:01 AM >> To: Stark, Barbara >> Cc: ECRIT >> Subject: Re: [Ecrit] A compromise to move us forward >> >> Barbara, >> >> Let's leave the details to item 3 for later. Unless you are >> suggesting that we complete your proposal immediately... which is not >> what I'm proposing. >> >> -andy >> >> On Jun 5, 2007, at 3:02 PM, Stark, Barbara wrote: >> >>> I would prefer that, in addition to moving forward with #1, we also >>> allow the LoST info to be returned via the L7 LCP. And use Richard's >>> proposal on how end points should work. Don't deal with the LoST >>> reverse >>> look-up at this time. If national/state regulations permit use of >>> LbyR + >>> PSAP URI (no LbyV at all), then those same regulations can publish >>> PSAP >>> URIs for VSPs to use as look-up, and they can admit that VSPs based > in >>> other countries are beyond their regulation and can charge for >>> calls to >>> emergency services. I really don't think the EU can insist that US >>> VSPs, >>> who provide US phone numbers, and market in the US, should be > required >>> to provide free routing for emergency calls destined for the EU. If >>> this >>> is done by treaty, then we ca agree to swap PSAP URI lists. >>> >>> It's possible to deal with the VSP billing issue "out-of-band". Let >>> the >>> regulators and effected parties decide if it's a problem. Just give > us >>> the capability. >>> Barbara >>> >>> -----Original Message----- >>> From: Andrew Newton [mailto:andy@hxr.us] >>> Sent: Tuesday, June 05, 2007 11:53 AM >>> To: ECRIT >>> Subject: [Ecrit] A compromise to move us forward >>> >>> All, >>> >>> While we might find an answer to the location hiding scenario in the >>> long term, I think it is rather apparent that a near-term solution >>> the satisfies all/most constituencies is unlikely to materialize. >>> Caught in the middle of this is all the other work we've done. >>> >>> I propose we do the following: >>> >>> 1) Move forward with the modest modifications to LoST to enable >>> Henning's Location Fuzzing proposal (#1 on the wiki). >>> 2) Note in some document somewhere (phonebcp, LoST, ecrit- >>> framework... >>> I don't care) how the location fuzzing proposal works and state >>> that it >>> is not ideal and a better solution is in the works. >>> 3) Seek new charter items for a more thorough location-hiding >>> solution. >>> >>> -andy >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> ***** >>> >>> The information transmitted is intended only for the person or >>> entity to which it is addressed and may contain confidential, >>> proprietary, and/or privileged material. Any review, >>> retransmission, dissemination or other use of, or taking of any >>> action in reliance upon this information by persons or entities >>> other than the intended recipient is prohibited. If you received >>> this in error, please contact the sender and delete the material >>> from all computers. GA625 >>> >>> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2] > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 21:12:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvk4H-0000rW-W7; Tue, 05 Jun 2007 21:12:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvk4F-0000rR-UU for ecrit@ietf.org; Tue, 05 Jun 2007 21:12:07 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvk4F-0000SW-BJ for ecrit@ietf.org; Tue, 05 Jun 2007 21:12:07 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 05 Jun 2007 18:12:06 -0700 X-IronPort-AV: i="4.16,387,1175497200"; d="scan'208"; a="159479118:sNHT53195103" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l561C6qF003076; Tue, 5 Jun 2007 18:12:06 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l561Bw0K021721; Wed, 6 Jun 2007 01:12:02 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 18:11:39 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.69.207]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 18:11:38 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 05 Jun 2007 20:11:34 -0500 To: "Winterbottom, James" , "Andrew Newton" , "Stark, Barbara" From: "James M. Polk" Subject: RE: [Ecrit] A compromise to move us forward In-Reply-To: References: <64D5A4F3-27C2-478A-BA0B-F45339A7674C@hxr.us> <7582BC68E4994F4ABF0BD4723975C3FA043E8624@crexc41p> <27A064A0-D4CE-48EC-9122-B8AE128F2A27@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jun 2007 01:11:39.0027 (UTC) FILETIME=[A28C7630:01C7A7D7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4713; t=1181092326; x=1181956326; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Ecrit]=20A=20compromise=20to=20move=20us=20forward |Sender:=20; bh=ZZBylmOrVmHkT7SyMfLRzjlUJ2VkZpuOJOIr7nbOqoo=; b=QCIeVw5TwV7qo4QVEGO8Q4fNAqecMH72/qj+orIoHlmCSwFtCNLrBp/NMGFGKcDm6YtsO5TP OJTouk04mseIbjMr3yA4HcaDflAPLYIcyq9uh0R1Sap3RXkJhPc695lm; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org James what if the endpoint in question is provided more than one PSAP URI? What then? I think this falls into Andy's #3 to flesh out in another, future effort. At 06:24 PM 6/5/2007, Winterbottom, James wrote: >Andy, > >I would like your point 2 to go a bit further. >I want it state that if the End-Point is provide the PSAP URI and a >location URI that it has to use those for the emergency call. This >should be in phone BCP. However the end-point gets this information I >agree is the subject of further work. > >Cheers >James > > > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Wednesday, 6 June 2007 6:01 AM > > To: Stark, Barbara > > Cc: ECRIT > > Subject: Re: [Ecrit] A compromise to move us forward > > > > Barbara, > > > > Let's leave the details to item 3 for later. Unless you are > > suggesting that we complete your proposal immediately... which is not > > what I'm proposing. > > > > -andy > > > > On Jun 5, 2007, at 3:02 PM, Stark, Barbara wrote: > > > > > I would prefer that, in addition to moving forward with #1, we also > > > allow the LoST info to be returned via the L7 LCP. And use Richard's > > > proposal on how end points should work. Don't deal with the LoST > > > reverse > > > look-up at this time. If national/state regulations permit use of > > > LbyR + > > > PSAP URI (no LbyV at all), then those same regulations can publish > > > PSAP > > > URIs for VSPs to use as look-up, and they can admit that VSPs based >in > > > other countries are beyond their regulation and can charge for > > > calls to > > > emergency services. I really don't think the EU can insist that US > > > VSPs, > > > who provide US phone numbers, and market in the US, should be >required > > > to provide free routing for emergency calls destined for the EU. If > > > this > > > is done by treaty, then we ca agree to swap PSAP URI lists. > > > > > > It's possible to deal with the VSP billing issue "out-of-band". Let > > > the > > > regulators and effected parties decide if it's a problem. Just give >us > > > the capability. > > > Barbara > > > > > > -----Original Message----- > > > From: Andrew Newton [mailto:andy@hxr.us] > > > Sent: Tuesday, June 05, 2007 11:53 AM > > > To: ECRIT > > > Subject: [Ecrit] A compromise to move us forward > > > > > > All, > > > > > > While we might find an answer to the location hiding scenario in the > > > long term, I think it is rather apparent that a near-term solution > > > the satisfies all/most constituencies is unlikely to materialize. > > > Caught in the middle of this is all the other work we've done. > > > > > > I propose we do the following: > > > > > > 1) Move forward with the modest modifications to LoST to enable > > > Henning's Location Fuzzing proposal (#1 on the wiki). > > > 2) Note in some document somewhere (phonebcp, LoST, ecrit- > > > framework... > > > I don't care) how the location fuzzing proposal works and state > > > that it > > > is not ideal and a better solution is in the works. > > > 3) Seek new charter items for a more thorough location-hiding > > > solution. > > > > > > -andy > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > ***** > > > > > > The information transmitted is intended only for the person or > > > entity to which it is addressed and may contain confidential, > > > proprietary, and/or privileged material. Any review, > > > retransmission, dissemination or other use of, or taking of any > > > action in reliance upon this information by persons or entities > > > other than the intended recipient is prohibited. If you received > > > this in error, please contact the sender and delete the material > > > from all computers. GA625 > > > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 21:13:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvk5v-0002Tp-H2; Tue, 05 Jun 2007 21:13:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvk5u-0002Tk-PW for ecrit@ietf.org; Tue, 05 Jun 2007 21:13:50 -0400 Received: from smtp4.andrew.com ([198.135.207.236] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvk5u-0000j1-D1 for ecrit@ietf.org; Tue, 05 Jun 2007 21:13:50 -0400 X-SEF-Processed: 5_0_0_910__2007_06_05_20_15_54 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp1 - SurfControl E-mail Filter (5.2.1); Tue, 05 Jun 2007 20:15:54 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jun 2007 20:13:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] A compromise to move us forward Date: Tue, 5 Jun 2007 20:13:47 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] A compromise to move us forward Thread-Index: Acen1HVetIsgsWS6Qy2o6y+KquO0vQAAe62g References: <64D5A4F3-27C2-478A-BA0B-F45339A7674C@hxr.us><7582BC68E4994F4ABF0BD4723975C3FA043E8624@crexc41p> <27A064A0-D4CE-48EC-9122-B8AE128F2A27@hxr.us> From: "Winterbottom, James" To: "Andrew Newton" X-OriginalArrivalTime: 06 Jun 2007 01:13:49.0326 (UTC) FILETIME=[F03682E0:01C7A7D7] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Andy,=0D=0A=0D=0AIf you cover item 3 in phone BCP now, then you don't need = to revisit it=0D=0Alater, even if we don't have a standard way to provide t= his now. Note=0D=0Athat I am only interested in how the end-point behaves a= t this point,=0D=0Anot necessarily how any in-path call-server or a call-se= rvice provider=0D=0Abehaves.=0D=0A=0D=0ATo my mind solution 3 is providing = a subset of the output of LoST=0D=0Adirectly to the end-point. The end-poin= t gets this information using the=0D=0Asame mechanism that it would use to = obtain location if location provider=0D=0Awas prepared to give location.=0D= =0A=0D=0ASo, what would the end-point do with the output of LoST, because i= t is=0D=0Athe same thing=3F=0D=0A=0D=0AAs I have said before, what an end-p= oint does with "location-associated"=0D=0Ainformation in regards to emergen= cy calling is in scope for ECRIT, how=0D=0Ait gets this information is not.= So I question the need to recharter=0D=0AECRIT to address this issue at al= l as long as we accept how the=0D=0Aend-point should behave if it is only g= iven "location-associated"=0D=0Ainformation.=0D=0A=0D=0ACheers=0D=0AJames=0D= =0A=0D=0A> -----Original Message-----=0D=0A> From: Andrew Newton [mailto:an= dy@hxr.us]=0D=0A> Sent: Wednesday, 6 June 2007 10:49 AM=0D=0A> To: Winterbo= ttom, James=0D=0A> Cc: Stark, Barbara; ECRIT=0D=0A> Subject: Re: [Ecrit] A = compromise to move us forward=0D=0A>=20=0D=0A> James,=0D=0A>=20=0D=0A> Your= suggestion presupposes a solution for item 3, which is not in=0D=0A> the s= pirit of what I proposed.=0D=0A>=20=0D=0A> Besides, what does it mean that = a client has to use a PSAP URI=3F Does=0D=0A> that mean it has to resolve = the URI and attempt a connection or can=0D=0A> it send that URI in an INVIT= E to an outbound proxy=3F=0D=0A>=20=0D=0A> -andy=0D=0A>=20=0D=0A> On Jun 5,= 2007, at 7:24 PM, Winterbottom, James wrote:=0D=0A>=20=0D=0A> > Andy,=0D=0A= > >=0D=0A> > I would like your point 2 to go a bit further.=0D=0A> > I want= it state that if the End-Point is provide the PSAP URI and a=0D=0A> > loca= tion URI that it has to use those for the emergency call. This=0D=0A> > sho= uld be in phone BCP. However the end-point gets this information=0D=0AI=0D=0A= > > agree is the subject of further work.=0D=0A> >=0D=0A> > Cheers=0D=0A> >= James=0D=0A> >=0D=0A> >=0D=0A> >> -----Original Message-----=0D=0A> >> Fro= m: Andrew Newton [mailto:andy@hxr.us]=0D=0A> >> Sent: Wednesday, 6 June 200= 7 6:01 AM=0D=0A> >> To: Stark, Barbara=0D=0A> >> Cc: ECRIT=0D=0A> >> Subjec= t: Re: [Ecrit] A compromise to move us forward=0D=0A> >>=0D=0A> >> Barbara,=0D= =0A> >>=0D=0A> >> Let's leave the details to item 3 for later. Unless you = are=0D=0A> >> suggesting that we complete your proposal immediately... whic= h is=0D=0Anot=0D=0A> >> what I'm proposing.=0D=0A> >>=0D=0A> >> -andy=0D=0A= > >>=0D=0A> >> On Jun 5, 2007, at 3:02 PM, Stark, Barbara wrote:=0D=0A> >>=0D= =0A> >>> I would prefer that, in addition to moving forward with #1, we=0D=0A= also=0D=0A> >>> allow the LoST info to be returned via the L7 LCP. And use=0D= =0ARichard's=0D=0A> >>> proposal on how end points should work. Don't deal = with the LoST=0D=0A> >>> reverse=0D=0A> >>> look-up at this time. If nation= al/state regulations permit use of=0D=0A> >>> LbyR +=0D=0A> >>> PSAP URI (n= o LbyV at all), then those same regulations can publish=0D=0A> >>> PSAP=0D=0A= > >>> URIs for VSPs to use as look-up, and they can admit that VSPs=0D=0Aba= sed=0D=0A> > in=0D=0A> >>> other countries are beyond their regulation and = can charge for=0D=0A> >>> calls to=0D=0A> >>> emergency services. I really = don't think the EU can insist that US=0D=0A> >>> VSPs,=0D=0A> >>> who provi= de US phone numbers, and market in the US, should be=0D=0A> > required=0D=0A= > >>> to provide free routing for emergency calls destined for the EU.=0D=0A= If=0D=0A> >>> this=0D=0A> >>> is done by treaty, then we ca agree to swap P= SAP URI lists.=0D=0A> >>>=0D=0A> >>> It's possible to deal with the VSP bil= ling issue "out-of-band".=0D=0ALet=0D=0A> >>> the=0D=0A> >>> regulators and= effected parties decide if it's a problem. Just=0D=0Agive=0D=0A> > us=0D=0A= > >>> the capability.=0D=0A> >>> Barbara=0D=0A> >>>=0D=0A> >>> -----Origina= l Message-----=0D=0A> >>> From: Andrew Newton [mailto:andy@hxr.us]=0D=0A> >= >> Sent: Tuesday, June 05, 2007 11:53 AM=0D=0A> >>> To: ECRIT=0D=0A> >>> Su= bject: [Ecrit] A compromise to move us forward=0D=0A> >>>=0D=0A> >>> All,=0D= =0A> >>>=0D=0A> >>> While we might find an answer to the location hiding sc= enario in=0D=0Athe=0D=0A> >>> long term, I think it is rather apparent that= a near-term solution=0D=0A> >>> the satisfies all/most constituencies is u= nlikely to materialize.=0D=0A> >>> Caught in the middle of this is all the = other work we've done.=0D=0A> >>>=0D=0A> >>> I propose we do the following:=0D= =0A> >>>=0D=0A> >>> 1) Move forward with the modest modifications to LoST t= o enable=0D=0A> >>> Henning's Location Fuzzing proposal (#1 on the wiki).=0D= =0A> >>> 2) Note in some document somewhere (phonebcp, LoST, ecrit-=0D=0A> = >>> framework...=0D=0A> >>> I don't care) how the location fuzzing proposal= works and state=0D=0A> >>> that it=0D=0A> >>> is not ideal and a better so= lution is in the works.=0D=0A> >>> 3) Seek new charter items for a more tho= rough location-hiding=0D=0A> >>> solution.=0D=0A> >>>=0D=0A> >>> -andy=0D=0A= > >>>=0D=0A> >>> _______________________________________________=0D=0A> >>>= Ecrit mailing list=0D=0A> >>> Ecrit@ietf.org=0D=0A> >>> https://www1.ietf.= org/mailman/listinfo/ecrit=0D=0A> >>>=0D=0A> >>> *****=0D=0A> >>>=0D=0A> >>= > The information transmitted is intended only for the person or=0D=0A> >>>= entity to which it is addressed and may contain confidential,=0D=0A> >>> p= roprietary, and/or privileged material. Any review,=0D=0A> >>> retransmissi= on, dissemination or other use of, or taking of any=0D=0A> >>> action in re= liance upon this information by persons or entities=0D=0A> >>> other than t= he intended recipient is prohibited. If you received=0D=0A> >>> this in err= or, please contact the sender and delete the material=0D=0A> >>> from all c= omputers. GA625=0D=0A> >>>=0D=0A> >>>=0D=0A> >>=0D=0A> >>=0D=0A> >> _______= ________________________________________=0D=0A> >> Ecrit mailing list=0D=0A= > >> Ecrit@ietf.org=0D=0A> >> https://www1.ietf.org/mailman/listinfo/ecrit=0D= =0A> >=0D=0A> >=0D=0A------------------------------------------------------= ----------------=0D=0A> > --------------------------=0D=0A> > This message = is for the designated recipient only and may=0D=0A> > contain privileged, p= roprietary, or otherwise private information.=0D=0A> > If you have received= it in error, please notify the sender=0D=0A> > immediately and delete the = original. Any unauthorized use of=0D=0A> > this email is prohibited.=0D=0A= > >=0D=0A------------------------------------------------------------------= ----=0D=0A> > --------------------------=0D=0A> > [mf2]=0D=0A> >=0D=0A>=20=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 05 21:16:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvk8A-0003Uy-9N; Tue, 05 Jun 2007 21:16:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvk89-0003Ut-A9 for ecrit@ietf.org; Tue, 05 Jun 2007 21:16:09 -0400 Received: from smtp4.andrew.com ([198.135.207.236] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvk88-0001D0-Ug for ecrit@ietf.org; Tue, 05 Jun 2007 21:16:09 -0400 X-SEF-Processed: 5_0_0_910__2007_06_05_20_18_05 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp1 - SurfControl E-mail Filter (5.2.1); Tue, 05 Jun 2007 20:18:05 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 5 Jun 2007 20:16:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] A compromise to move us forward Date: Tue, 5 Jun 2007 20:15:58 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] A compromise to move us forward Thread-Index: Acen17PwYep+fAirSOe2Z5NXnWC15gAAFcpg References: <64D5A4F3-27C2-478A-BA0B-F45339A7674C@hxr.us> <7582BC68E4994F4ABF0BD4723975C3FA043E8624@crexc41p> <27A064A0-D4CE-48EC-9122-B8AE128F2A27@hxr.us> From: "Winterbottom, James" To: "James M. Polk" , "Andrew Newton" , "Stark, Barbara" X-OriginalArrivalTime: 06 Jun 2007 01:16:00.0418 (UTC) FILETIME=[3E599020:01C7A7D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi James,=0D=0A=0D=0AWhat does the end-point do now if it gets this from Lo= ST=3F=0D=0AThe issue is the same, and the end-point is in no better positio= n to=0D=0Adetermine which URI to use. So I don't see why this problem is ei= ther=0D=0Acomplicated or obscured more by solution 3.=0D=0A=0D=0ACheers=0D=0A= James=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: James M. Polk [m= ailto:jmpolk@cisco.com]=0D=0A> Sent: Wednesday, 6 June 2007 11:12 AM=0D=0A>= To: Winterbottom, James; Andrew Newton; Stark, Barbara=0D=0A> Cc: ECRIT=0D= =0A> Subject: RE: [Ecrit] A compromise to move us forward=0D=0A>=20=0D=0A> = James=0D=0A>=20=0D=0A> what if the endpoint in question is provided more th= an one PSAP=0D=0A> URI=3F What then=3F=0D=0A>=20=0D=0A> I think this falls= into Andy's #3 to flesh out in another, future=0D=0Aeffort.=0D=0A>=20=0D=0A= > At 06:24 PM 6/5/2007, Winterbottom, James wrote:=0D=0A> >Andy,=0D=0A> >=0D= =0A> >I would like your point 2 to go a bit further.=0D=0A> >I want it stat= e that if the End-Point is provide the PSAP URI and a=0D=0A> >location URI = that it has to use those for the emergency call. This=0D=0A> >should be in = phone BCP. However the end-point gets this information I=0D=0A> >agree is t= he subject of further work.=0D=0A> >=0D=0A> >Cheers=0D=0A> >James=0D=0A> >=0D= =0A> >=0D=0A> > > -----Original Message-----=0D=0A> > > From: Andrew Newton= [mailto:andy@hxr.us]=0D=0A> > > Sent: Wednesday, 6 June 2007 6:01 AM=0D=0A= > > > To: Stark, Barbara=0D=0A> > > Cc: ECRIT=0D=0A> > > Subject: Re: [Ecri= t] A compromise to move us forward=0D=0A> > >=0D=0A> > > Barbara,=0D=0A> > = >=0D=0A> > > Let's leave the details to item 3 for later. Unless you are=0D= =0A> > > suggesting that we complete your proposal immediately... which is=0D= =0Anot=0D=0A> > > what I'm proposing.=0D=0A> > >=0D=0A> > > -andy=0D=0A> > = >=0D=0A> > > On Jun 5, 2007, at 3:02 PM, Stark, Barbara wrote:=0D=0A> > >=0D= =0A> > > > I would prefer that, in addition to moving forward with #1, we=0D= =0Aalso=0D=0A> > > > allow the LoST info to be returned via the L7 LCP. And= use=0D=0ARichard's=0D=0A> > > > proposal on how end points should work. Do= n't deal with the LoST=0D=0A> > > > reverse=0D=0A> > > > look-up at this ti= me. If national/state regulations permit use=0D=0Aof=0D=0A> > > > LbyR +=0D= =0A> > > > PSAP URI (no LbyV at all), then those same regulations can=0D=0A= publish=0D=0A> > > > PSAP=0D=0A> > > > URIs for VSPs to use as look-up, and= they can admit that VSPs=0D=0Abased=0D=0A> >in=0D=0A> > > > other countrie= s are beyond their regulation and can charge for=0D=0A> > > > calls to=0D=0A= > > > > emergency services. I really don't think the EU can insist that=0D=0A= US=0D=0A> > > > VSPs,=0D=0A> > > > who provide US phone numbers, and market= in the US, should be=0D=0A> >required=0D=0A> > > > to provide free routing= for emergency calls destined for the EU.=0D=0AIf=0D=0A> > > > this=0D=0A> = > > > is done by treaty, then we ca agree to swap PSAP URI lists.=0D=0A> > = > >=0D=0A> > > > It's possible to deal with the VSP billing issue "out-of-b= and".=0D=0ALet=0D=0A> > > > the=0D=0A> > > > regulators and effected partie= s decide if it's a problem. Just=0D=0Agive=0D=0A> >us=0D=0A> > > > the capa= bility.=0D=0A> > > > Barbara=0D=0A> > > >=0D=0A> > > > -----Original Messag= e-----=0D=0A> > > > From: Andrew Newton [mailto:andy@hxr.us]=0D=0A> > > > S= ent: Tuesday, June 05, 2007 11:53 AM=0D=0A> > > > To: ECRIT=0D=0A> > > > Su= bject: [Ecrit] A compromise to move us forward=0D=0A> > > >=0D=0A> > > > Al= l,=0D=0A> > > >=0D=0A> > > > While we might find an answer to the location = hiding scenario in=0D=0Athe=0D=0A> > > > long term, I think it is rather ap= parent that a near-term=0D=0Asolution=0D=0A> > > > the satisfies all/most c= onstituencies is unlikely to=0D=0Amaterialize.=0D=0A> > > > Caught in the m= iddle of this is all the other work we've done.=0D=0A> > > >=0D=0A> > > > I= propose we do the following:=0D=0A> > > >=0D=0A> > > > 1) Move forward wit= h the modest modifications to LoST to enable=0D=0A> > > > Henning's Locatio= n Fuzzing proposal (#1 on the wiki).=0D=0A> > > > 2) Note in some document = somewhere (phonebcp, LoST, ecrit-=0D=0A> > > > framework...=0D=0A> > > > I = don't care) how the location fuzzing proposal works and state=0D=0A> > > > = that it=0D=0A> > > > is not ideal and a better solution is in the works.=0D= =0A> > > > 3) Seek new charter items for a more thorough location-hiding=0D= =0A> > > > solution.=0D=0A> > > >=0D=0A> > > > -andy=0D=0A> > > >=0D=0A> > = > > _______________________________________________=0D=0A> > > > Ecrit mail= ing list=0D=0A> > > > Ecrit@ietf.org=0D=0A> > > > https://www1.ietf.org/mai= lman/listinfo/ecrit=0D=0A> > > >=0D=0A> > > > *****=0D=0A> > > >=0D=0A> > >= > The information transmitted is intended only for the person or=0D=0A> > = > > entity to which it is addressed and may contain confidential,=0D=0A> > = > > proprietary, and/or privileged material. Any review,=0D=0A> > > > retra= nsmission, dissemination or other use of, or taking of any=0D=0A> > > > act= ion in reliance upon this information by persons or entities=0D=0A> > > > o= ther than the intended recipient is prohibited. If you received=0D=0A> > > = > this in error, please contact the sender and delete the material=0D=0A> >= > > from all computers. GA625=0D=0A> > > >=0D=0A> > > >=0D=0A> > >=0D=0A> = > >=0D=0A> > > _______________________________________________=0D=0A> > > E= crit mailing list=0D=0A> > > Ecrit@ietf.org=0D=0A> > > https://www1.ietf.or= g/mailman/listinfo/ecrit=0D=0A> >=0D=0A>=0D=0A>----------------------------= -------------------------------------------=0D=0A--=0D=0A> ----------------= -------=0D=0A> >This message is for the designated recipient only and may=0D= =0A> >contain privileged, proprietary, or otherwise private information.=0D= =0A> >If you have received it in error, please notify the sender=0D=0A> >im= mediately and delete the original. Any unauthorized use of=0D=0A> >this em= ail is prohibited.=0D=0A>=0D=0A>-------------------------------------------= ----------------------------=0D=0A--=0D=0A> -----------------------=0D=0A> = >[mf2]=0D=0A> >=0D=0A> >=0D=0A> >__________________________________________= _____=0D=0A> >Ecrit mailing list=0D=0A> >Ecrit@ietf.org=0D=0A> >https://www= 1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A------------------------------= ------------------------------------------------------------------=0D=0AThi= s message is for the designated recipient only and may=0D=0Acontain privile= ged, proprietary, or otherwise private information. =20=0D=0AIf you have re= ceived it in error, please notify the sender=0D=0Aimmediately and delete th= e original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A--= ---------------------------------------------------------------------------= -------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 06 06:21:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvsdl-0007HO-M9; Wed, 06 Jun 2007 06:21:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvsdj-0007Fe-MG for ecrit@ietf.org; Wed, 06 Jun 2007 06:21:19 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvsdj-000339-3N for ecrit@ietf.org; Wed, 06 Jun 2007 06:21:19 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 6 Jun 2007 12:21:18 +0200 Received: from S4DE8PSAAGM.mitte.t-com.de ([10.151.180.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 12:21:10 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [Ecrit] A compromise to move us forward Date: Wed, 6 Jun 2007 12:21:17 +0200 Message-Id: <182C63BFBAF131428EA0C16F7FD2191B0135853A@S4DE8PSAAGM.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] A compromise to move us forward Thread-Index: Acen1HVetIsgsWS6Qy2o6y+KquO0vQAAe62gAA/gftA= From: "Liess, Laura" To: X-OriginalArrivalTime: 06 Jun 2007 10:21:10.0930 (UTC) FILETIME=[67559720:01C7A824] X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org James, I woudn't like clients sending emergency calls with URIs to our proxy = without a reverse LOST mechanism in place, which enable us to verify the = URI. It is not just the billing issue. I expect the regulation will = require carriers to route unauthenticated emergency calls. I see here a = risk for us to become a nice intermediary for all kind of SPIT, DoS, = whatever. Clients sending URIs together with reverse LOST are OK for = me, but as I understand the reverse LOST needs more work. I think = Andy's proposal is for the moment a good compromise...=20 Or do you see some error in my reasoning? Laura > -----Urspr=FCngliche Nachricht----- > Von: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 > Gesendet: Mittwoch, 6. Juni 2007 03:14 > An: Andrew Newton > Cc: ECRIT > Betreff: RE: [Ecrit] A compromise to move us forward >=20 >=20 > Andy, >=20 > If you cover item 3 in phone BCP now, then you don't need to=20 > revisit it later, even if we don't have a standard way to=20 > provide this now. Note that I am only interested in how the=20 > end-point behaves at this point, not necessarily how any=20 > in-path call-server or a call-service provider behaves. >=20 > To my mind solution 3 is providing a subset of the output of=20 > LoST directly to the end-point. The end-point gets this=20 > information using the same mechanism that it would use to=20 > obtain location if location provider was prepared to give location. >=20 > So, what would the end-point do with the output of LoST,=20 > because it is the same thing? >=20 > As I have said before, what an end-point does with=20 > "location-associated" information in regards to emergency=20 > calling is in scope for ECRIT, how it gets this information=20 > is not. So I question the need to recharter ECRIT to address=20 > this issue at all as long as we accept how the end-point=20 > should behave if it is only given "location-associated" information. >=20 > Cheers > James >=20 > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Wednesday, 6 June 2007 10:49 AM > > To: Winterbottom, James > > Cc: Stark, Barbara; ECRIT > > Subject: Re: [Ecrit] A compromise to move us forward > >=20 > > James, > >=20 > > Your suggestion presupposes a solution for item 3, which is=20 > not in the=20 > > spirit of what I proposed. > >=20 > > Besides, what does it mean that a client has to use a PSAP=20 > URI? Does=20 > > that mean it has to resolve the URI and attempt a=20 > connection or can it=20 > > send that URI in an INVITE to an outbound proxy? > >=20 > > -andy > >=20 > > On Jun 5, 2007, at 7:24 PM, Winterbottom, James wrote: > >=20 > > > Andy, > > > > > > I would like your point 2 to go a bit further. > > > I want it state that if the End-Point is provide the PSAP=20 > URI and a=20 > > > location URI that it has to use those for the emergency=20 > call. This=20 > > > should be in phone BCP. However the end-point gets this=20 > information > I > > > agree is the subject of further work. > > > > > > Cheers > > > James > > > > > > > > >> -----Original Message----- > > >> From: Andrew Newton [mailto:andy@hxr.us] > > >> Sent: Wednesday, 6 June 2007 6:01 AM > > >> To: Stark, Barbara > > >> Cc: ECRIT > > >> Subject: Re: [Ecrit] A compromise to move us forward > > >> > > >> Barbara, > > >> > > >> Let's leave the details to item 3 for later. Unless you are=20 > > >> suggesting that we complete your proposal immediately... which is > not > > >> what I'm proposing. > > >> > > >> -andy > > >> > > >> On Jun 5, 2007, at 3:02 PM, Stark, Barbara wrote: > > >> > > >>> I would prefer that, in addition to moving forward with #1, we > also > > >>> allow the LoST info to be returned via the L7 LCP. And use > Richard's > > >>> proposal on how end points should work. Don't deal with=20 > the LoST=20 > > >>> reverse look-up at this time. If national/state=20 > regulations permit=20 > > >>> use of LbyR + > > >>> PSAP URI (no LbyV at all), then those same regulations=20 > can publish > > >>> PSAP > > >>> URIs for VSPs to use as look-up, and they can admit that VSPs > based > > > in > > >>> other countries are beyond their regulation and can charge for=20 > > >>> calls to emergency services. I really don't think the EU can=20 > > >>> insist that US VSPs, > > >>> who provide US phone numbers, and market in the US, should be > > > required > > >>> to provide free routing for emergency calls destined for the EU. > If > > >>> this > > >>> is done by treaty, then we ca agree to swap PSAP URI lists. > > >>> > > >>> It's possible to deal with the VSP billing issue "out-of-band". > Let > > >>> the > > >>> regulators and effected parties decide if it's a problem. Just > give > > > us > > >>> the capability. > > >>> Barbara > > >>> > > >>> -----Original Message----- > > >>> From: Andrew Newton [mailto:andy@hxr.us] > > >>> Sent: Tuesday, June 05, 2007 11:53 AM > > >>> To: ECRIT > > >>> Subject: [Ecrit] A compromise to move us forward > > >>> > > >>> All, > > >>> > > >>> While we might find an answer to the location hiding scenario in > the > > >>> long term, I think it is rather apparent that a=20 > near-term solution=20 > > >>> the satisfies all/most constituencies is unlikely to=20 > materialize.=20 > > >>> Caught in the middle of this is all the other work we've done. > > >>> > > >>> I propose we do the following: > > >>> > > >>> 1) Move forward with the modest modifications to LoST to enable=20 > > >>> Henning's Location Fuzzing proposal (#1 on the wiki). > > >>> 2) Note in some document somewhere (phonebcp, LoST, ecrit-=20 > > >>> framework... I don't care) how the location fuzzing=20 > proposal works=20 > > >>> and state that it > > >>> is not ideal and a better solution is in the works. > > >>> 3) Seek new charter items for a more thorough location-hiding > > >>> solution. > > >>> > > >>> -andy > > >>> > > >>> _______________________________________________ > > >>> Ecrit mailing list > > >>> Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit > > >>> > > >>> ***** > > >>> > > >>> The information transmitted is intended only for the person or=20 > > >>> entity to which it is addressed and may contain confidential,=20 > > >>> proprietary, and/or privileged material. Any review,=20 > > >>> retransmission, dissemination or other use of, or taking of any=20 > > >>> action in reliance upon this information by persons or entities=20 > > >>> other than the intended recipient is prohibited. If you=20 > received=20 > > >>> this in error, please contact the sender and delete the=20 > material=20 > > >>> from all computers. GA625 > > >>> > > >>> > > >> > > >> > > >> _______________________________________________ > > >> Ecrit mailing list > > >> Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > ---------------------------------------------------------------------- > > > -------------------------- > > > This message is for the designated recipient only and may contain=20 > > > privileged, proprietary, or otherwise private information. If you=20 > > > have received it in error, please notify the sender=20 > immediately and=20 > > > delete the original. Any unauthorized use of this email is=20 > > > prohibited. > > > > ---------------------------------------------------------------------- > > > -------------------------- > > > [mf2] > > > > >=20 >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may=20 > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender=20 > immediately and delete the original. Any unauthorized use of=20 > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 06 08:46:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvutw-0000w0-RP; Wed, 06 Jun 2007 08:46:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvutv-0000vs-6L for ecrit@ietf.org; Wed, 06 Jun 2007 08:46:11 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvutt-00015b-VU for ecrit@ietf.org; Wed, 06 Jun 2007 08:46:11 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l56Ck2DJ012525 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 6 Jun 2007 08:46:05 -0400 (EDT) In-Reply-To: <182C63BFBAF131428EA0C16F7FD2191B0135853A@S4DE8PSAAGM.mitte.t-com.de> References: <182C63BFBAF131428EA0C16F7FD2191B0135853A@S4DE8PSAAGM.mitte.t-com.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <03DE1A50-43A9-424A-BBA3-5FC683CA9460@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: AW: [Ecrit] A compromise to move us forward Date: Wed, 6 Jun 2007 08:46:00 -0400 To: "Liess, Laura" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I have to admit to being confused by this discussion about URLs. Any URL produced by whatever means is subject to the normal RFC 3261 and 3263 process ("Locating SIP Servers"). Doesn't matter if the URL was copied off the side of a bus or was delivered by LoST or any other protocol. RFC 3261 and RFC 3361, along with any configuration mechanism (such as the ones being discussed in SIPPING), dictates whether an outbound proxy is used and which one. None of this changes just because this is an emergency call. Henning On Jun 6, 2007, at 6:21 AM, Liess, Laura wrote: > James, > > I woudn't like clients sending emergency calls with URIs to our > proxy without a reverse LOST mechanism in place, which enable us to > verify the URI. It is not just the billing issue. I expect the > regulation will require carriers to route unauthenticated emergency > calls. I see here a risk for us to become a nice intermediary for > all kind of SPIT, DoS, whatever. Clients sending URIs together > with reverse LOST are OK for me, but as I understand the reverse > LOST needs more work. I think Andy's proposal is for the moment a > good compromise... > > Or do you see some error in my reasoning? > > Laura _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 06 08:50:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvuxk-0003UD-6D; Wed, 06 Jun 2007 08:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvuxj-0003U8-BJ for ecrit@ietf.org; Wed, 06 Jun 2007 08:50:07 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvuxi-0002J8-MR for ecrit@ietf.org; Wed, 06 Jun 2007 08:50:07 -0400 Received: from ([139.76.131.83]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.23496101; Wed, 06 Jun 2007 08:49:33 -0400 Received: from 01NC27689010625.AD.BLS.COM ([90.144.44.200]) by 01GAF5142010622.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 6 Jun 2007 08:49:08 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 6 Jun 2007 08:49:07 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] A compromise to move us forward Date: Wed, 6 Jun 2007 08:49:06 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA043E876B@crexc41p> In-Reply-To: <182C63BFBAF131428EA0C16F7FD2191B0135853A@S4DE8PSAAGM.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] A compromise to move us forward thread-index: Acen1HVetIsgsWS6Qy2o6y+KquO0vQAAe62gAA/gftAABvawwA== References: <182C63BFBAF131428EA0C16F7FD2191B0135853A@S4DE8PSAAGM.mitte.t-com.de> From: "Stark, Barbara" To: "Liess, Laura" , X-OriginalArrivalTime: 06 Jun 2007 12:49:07.0376 (UTC) FILETIME=[121BC300:01C7A839] X-Spam-Score: 0.6 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I would consider it more efficient, as a VSP, to have a cached list of = known, valid PSAP URIs, than to do a reverse LoST query for every = emergency call. If a nation wants to allow LbyR-only responses to = endpoints, then it needs to make its PSAP URIs known. I think reverse LoST would be a nice feature, but I don't see it as = necessary. Initially, the utopian view of a worldwide LoST network won't = exist, anyway. It will be possible for a VSP to get a call to a = completely valid foreign PSAP URI, but not be able to validate that URI = either through reverse LoST or through regular LoST look-up of a coarse = location. If the Forest Guide pointers (or whatever they are) don't = exist for a VSP to get to the correct foreign LoST server, then the VSP = will be unable to validate the URI. I'm pretty sure I've read somewhere = on this list that Forests will most likely initially grow in = disconnected clumps -- but please correct me if I'm wrong here. Independent of whether we do scenario 1 or 3, the case will exist where = the VSP cannot validate the PSAP URI. Therefore, it is imperative that = regulators specifically address this case (unvalidated PSAP URI) and its = desired behavior, independent of which scenario is implemented. It will = exist. The VSP must also determine its billing policy for this case, no matter = what. Barbara -----Original Message----- From: Liess, Laura [mailto:Laura.Liess@t-systems.com]=20 Sent: Wednesday, June 06, 2007 6:21 AM To: James.Winterbottom@andrew.com Cc: ecrit@ietf.org Subject: AW: [Ecrit] A compromise to move us forward James, I woudn't like clients sending emergency calls with URIs to our proxy = without a reverse LOST mechanism in place, which enable us to verify the = URI. It is not just the billing issue. I expect the regulation will = require carriers to route unauthenticated emergency calls. I see here a = risk for us to become a nice intermediary for all kind of SPIT, DoS, = whatever. Clients sending URIs together with reverse LOST are OK for = me, but as I understand the reverse LOST needs more work. I think = Andy's proposal is for the moment a good compromise...=20 Or do you see some error in my reasoning? Laura > -----Urspr=FCngliche Nachricht----- > Von: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Gesendet: Mittwoch, 6. Juni 2007 03:14 > An: Andrew Newton > Cc: ECRIT > Betreff: RE: [Ecrit] A compromise to move us forward >=20 >=20 > Andy, >=20 > If you cover item 3 in phone BCP now, then you don't need to revisit=20 > it later, even if we don't have a standard way to provide this now.=20 > Note that I am only interested in how the end-point behaves at this=20 > point, not necessarily how any in-path call-server or a call-service=20 > provider behaves. >=20 > To my mind solution 3 is providing a subset of the output of LoST=20 > directly to the end-point. The end-point gets this information using=20 > the same mechanism that it would use to obtain location if location=20 > provider was prepared to give location. >=20 > So, what would the end-point do with the output of LoST, because it is = > the same thing? >=20 > As I have said before, what an end-point does with=20 > "location-associated" information in regards to emergency calling is=20 > in scope for ECRIT, how it gets this information is not. So I question = > the need to recharter ECRIT to address this issue at all as long as we = > accept how the end-point should behave if it is only given=20 > "location-associated" information. >=20 > Cheers > James >=20 > > -----Original Message----- > > From: Andrew Newton [mailto:andy@hxr.us] > > Sent: Wednesday, 6 June 2007 10:49 AM > > To: Winterbottom, James > > Cc: Stark, Barbara; ECRIT > > Subject: Re: [Ecrit] A compromise to move us forward > >=20 > > James, > >=20 > > Your suggestion presupposes a solution for item 3, which is > not in the > > spirit of what I proposed. > >=20 > > Besides, what does it mean that a client has to use a PSAP > URI? Does > > that mean it has to resolve the URI and attempt a > connection or can it > > send that URI in an INVITE to an outbound proxy? > >=20 > > -andy > >=20 > > On Jun 5, 2007, at 7:24 PM, Winterbottom, James wrote: > >=20 > > > Andy, > > > > > > I would like your point 2 to go a bit further. > > > I want it state that if the End-Point is provide the PSAP > URI and a > > > location URI that it has to use those for the emergency > call. This > > > should be in phone BCP. However the end-point gets this > information > I > > > agree is the subject of further work. > > > > > > Cheers > > > James > > > > > > > > >> -----Original Message----- > > >> From: Andrew Newton [mailto:andy@hxr.us] > > >> Sent: Wednesday, 6 June 2007 6:01 AM > > >> To: Stark, Barbara > > >> Cc: ECRIT > > >> Subject: Re: [Ecrit] A compromise to move us forward > > >> > > >> Barbara, > > >> > > >> Let's leave the details to item 3 for later. Unless you are=20 > > >> suggesting that we complete your proposal immediately... which is > not > > >> what I'm proposing. > > >> > > >> -andy > > >> > > >> On Jun 5, 2007, at 3:02 PM, Stark, Barbara wrote: > > >> > > >>> I would prefer that, in addition to moving forward with #1, we > also > > >>> allow the LoST info to be returned via the L7 LCP. And use > Richard's > > >>> proposal on how end points should work. Don't deal with > the LoST > > >>> reverse look-up at this time. If national/state > regulations permit > > >>> use of LbyR + > > >>> PSAP URI (no LbyV at all), then those same regulations > can publish > > >>> PSAP > > >>> URIs for VSPs to use as look-up, and they can admit that VSPs > based > > > in > > >>> other countries are beyond their regulation and can charge for=20 > > >>> calls to emergency services. I really don't think the EU can=20 > > >>> insist that US VSPs, who provide US phone numbers, and market in = > > >>> the US, should be > > > required > > >>> to provide free routing for emergency calls destined for the EU. > If > > >>> this > > >>> is done by treaty, then we ca agree to swap PSAP URI lists. > > >>> > > >>> It's possible to deal with the VSP billing issue "out-of-band". > Let > > >>> the > > >>> regulators and effected parties decide if it's a problem. Just > give > > > us > > >>> the capability. > > >>> Barbara > > >>> > > >>> -----Original Message----- > > >>> From: Andrew Newton [mailto:andy@hxr.us] > > >>> Sent: Tuesday, June 05, 2007 11:53 AM > > >>> To: ECRIT > > >>> Subject: [Ecrit] A compromise to move us forward > > >>> > > >>> All, > > >>> > > >>> While we might find an answer to the location hiding scenario in > the > > >>> long term, I think it is rather apparent that a > near-term solution > > >>> the satisfies all/most constituencies is unlikely to > materialize.=20 > > >>> Caught in the middle of this is all the other work we've done. > > >>> > > >>> I propose we do the following: > > >>> > > >>> 1) Move forward with the modest modifications to LoST to enable=20 > > >>> Henning's Location Fuzzing proposal (#1 on the wiki). > > >>> 2) Note in some document somewhere (phonebcp, LoST, ecrit-=20 > > >>> framework... I don't care) how the location fuzzing > proposal works > > >>> and state that it > > >>> is not ideal and a better solution is in the works. > > >>> 3) Seek new charter items for a more thorough location-hiding=20 > > >>> solution. > > >>> > > >>> -andy > > >>> > > >>> _______________________________________________ > > >>> Ecrit mailing list > > >>> Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit > > >>> > > >>> ***** > > >>> > > >>> The information transmitted is intended only for the person or=20 > > >>> entity to which it is addressed and may contain confidential,=20 > > >>> proprietary, and/or privileged material. Any review,=20 > > >>> retransmission, dissemination or other use of, or taking of any=20 > > >>> action in reliance upon this information by persons or entities=20 > > >>> other than the intended recipient is prohibited. If you > received > > >>> this in error, please contact the sender and delete the > material > > >>> from all computers. GA625 > > >>> > > >>> > > >> > > >> > > >> _______________________________________________ > > >> Ecrit mailing list > > >> Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > ---------------------------------------------------------------------- > > > -------------------------- > > > This message is for the designated recipient only and may contain=20 > > > privileged, proprietary, or otherwise private information. If you=20 > > > have received it in error, please notify the sender > immediately and > > > delete the original. Any unauthorized use of this email is=20 > > > prohibited. > > > > ---------------------------------------------------------------------- > > > -------------------------- > > > [mf2] > > > > >=20 >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may contain=20 > privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender immediately = > and delete the original. Any unauthorized use of this email is=20 > prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA622 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 06 09:09:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvvG4-0007U9-5f; Wed, 06 Jun 2007 09:09:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvvG3-0007U4-K9 for ecrit@ietf.org; Wed, 06 Jun 2007 09:09:03 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvvG2-0006pq-CU for ecrit@ietf.org; Wed, 06 Jun 2007 09:09:03 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l56D91rb001552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 6 Jun 2007 09:09:01 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Henning Schulzrinne Date: Wed, 6 Jun 2007 09:08:58 -0400 X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Ecrit] Location hiding: another alternative X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Motivated by a side remark by Andy, here's another alternative that (I believe) avoids some of the architectural contortions of using the L7 LCP or DHCP as a LoST transport mechanism. The basic idea is that we define a new location type, namely an opaque token. This token is specific to LoST, i.e., possession of the token can only be used to get a LoST result. This is logically somewhat similar to the "additional code" (CAtype 32) in DHCP-civic. This new location format can be returned by HELD, DHCP or any other location configuration protocol. Indeed, it could probably be added as another CAtype in DHCP-civic. The LIS provider decides on the token format, which could be a hashed IP address, some customer identity (for DSL) or even an encrypted civic/geo address, with the key known only to the ISP. The client does what we have discussed for any other location format: It blindly copies the new location information into a LoST query. The LoST resolver/server/proxy, operated by the ISP, runs some internal protocol to get the location information from the LIS. This is a private matter left to the ISP. With that information, the "proxy" constructs a normal LoST query, of whatever kind, and gets the result, which it returns to the original querier. Since this token is local to a specific LoST server, the actual token returned would be a LoST URL, such as lost:lost.isp.com/fav8z98fa The VSP can perform URL verification using this token, if desired. This mechanism has the advantage that it maintains the same architecture as without location hiding and avoids conflating the functionality of two protocols. It doesn't need any special LbyR mechanisms with the attendant access issues, as the LoST URL serves only one purpose. It's not perfect, in that the VSP verification relies on the VSP trusting the ISP lookup results, but it is likely "good enough" for fraud prevention. This requires no fundamental changes to LoST and thus can (and should be) done later. Thus, I believe this is in the spirit of Andy's compromise proposal, but illustrates that there's more than one way to do this beyond Solution 1. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 06 12:22:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvyH7-0008I2-6m; Wed, 06 Jun 2007 12:22:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvyH5-0008Hx-Op for ecrit@ietf.org; Wed, 06 Jun 2007 12:22:19 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvyH4-0005z0-CD for ecrit@ietf.org; Wed, 06 Jun 2007 12:22:19 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Jun 2007 09:22:18 -0700 X-IronPort-AV: i="4.16,390,1175497200"; d="scan'208"; a="159895229:sNHT47537109" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l56GMHfC016143; Wed, 6 Jun 2007 09:22:17 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l56GMHtV020036; Wed, 6 Jun 2007 16:22:17 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 09:22:17 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.70.65]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 09:22:17 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Jun 2007 11:22:14 -0500 To: Henning Schulzrinne , ECRIT From: "James M. Polk" Subject: Re: [Ecrit] Location hiding: another alternative In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jun 2007 16:22:17.0462 (UTC) FILETIME=[D9980160:01C7A856] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3209; t=1181146937; x=1182010937; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Location=20hiding=3A=20another=20alternativ e |Sender:=20; bh=EKx7abco66O+1zY5DFlGQBJs9M2AKv+mVX5Ie68i2Vs=; b=hXuh1s4GyIi5DdunwaklfnHwnEqEHSJGgZbgQmAB9Az3/ZNq1QK4luB5+KSSiGv+S6eY9iVF 8FbgeUl9g15NK/vODvp4J8Il4+D4vxFhdZH+s5OmgdBEfKF427H3O4pq; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning Perhaps I'm not reading this correctly, but as you have offered this new token as part of a CAType, to be used for emergency calling, wouldn't that mean RFC 3825 (currently without the ability to simply add a token to it) would no longer function as this alternative expects emergency calling to? I know a great number of folks are biased towards Civic formats in DHCP, but nothing to date has actively prevented the Geo format from working. Does this alternative do that? Again, I may be missing something - or combining something I shouldn't be to get to this conclusion. Also, what happens to this alternative when location is measured by the endpoint itself (like a GPS chip), or even manual config? Just curious how these factor in... At 08:08 AM 6/6/2007, Henning Schulzrinne wrote: >Motivated by a side remark by Andy, here's another alternative that >(I believe) avoids some of the architectural contortions of using the >L7 LCP or DHCP as a LoST transport mechanism. > >The basic idea is that we define a new location type, namely an >opaque token. This token is specific to LoST, i.e., possession of the >token can only be used to get a LoST result. This is logically >somewhat similar to the "additional code" (CAtype 32) in DHCP-civic. >This new location format can be returned by HELD, DHCP or any other >location configuration protocol. Indeed, it could probably be added >as another CAtype in DHCP-civic. The LIS provider decides on the >token format, which could be a hashed IP address, some customer >identity (for DSL) or even an encrypted civic/geo address, with the >key known only to the ISP. > >The client does what we have discussed for any other location format: >It blindly copies the new location information into a LoST query. > >The LoST resolver/server/proxy, operated by the ISP, runs some >internal protocol to get the location information from the LIS. This >is a private matter left to the ISP. With that information, the >"proxy" constructs a normal LoST query, of whatever kind, and gets >the result, which it returns to the original querier. > >Since this token is local to a specific LoST server, the actual token >returned would be a LoST URL, such as > >lost:lost.isp.com/fav8z98fa > >The VSP can perform URL verification using this token, if desired. > >This mechanism has the advantage that it maintains the same >architecture as without location hiding and avoids conflating the >functionality of two protocols. It doesn't need any special LbyR >mechanisms with the attendant access issues, as the LoST URL serves >only one purpose. > >It's not perfect, in that the VSP verification relies on the VSP >trusting the ISP lookup results, but it is likely "good enough" for >fraud prevention. > >This requires no fundamental changes to LoST and thus can (and should >be) done later. Thus, I believe this is in the spirit of Andy's >compromise proposal, but illustrates that there's more than one way >to do this beyond Solution 1. > >Henning > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 06 13:22:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvzDN-0000FR-Ia; Wed, 06 Jun 2007 13:22:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvzDN-0000FM-17 for ecrit@ietf.org; Wed, 06 Jun 2007 13:22:33 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvzDL-0002Km-Pt for ecrit@ietf.org; Wed, 06 Jun 2007 13:22:33 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l56HMQXm006267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 6 Jun 2007 13:22:30 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Location hiding: another alternative Date: Wed, 6 Jun 2007 13:22:56 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 6, 2007, at 12:22 PM, James M. Polk wrote: > Henning > > Perhaps I'm not reading this correctly, but as you have offered > this new token as part of a CAType, to be used for emergency > calling, wouldn't that mean RFC 3825 (currently without the ability > to simply add a token to it) would no longer function as this > alternative expects emergency calling to? > James, the whole discussion only applies to location hiding cases. Thus, 3825 and any other mechanism can and should be used to convey location information. I'm hoping that location hiding remains the exception, used, if at all, mainly for residential DSL (and cable), but that's a separate discussion. I have not spent a whole lot of time thinking of whether such a token/ LoST URL should be conveyed in DHCP-civic or in a new DHCP option (in addition to L7 LCP). I can make a case for either, but it seems secondary at this point. > I know a great number of folks are biased towards Civic formats in > DHCP, but nothing to date has actively prevented the Geo format > from working. Does this alternative do that? I don't understand. The whole point of location hiding is that you want to convey neither (accurate) geo nor civic. You could obviously combine "fuzzed" location (Solution 1) with this approach, if you desire. They are not mutually exclusive. > > Again, I may be missing something - or combining something I > shouldn't be to get to this conclusion. > > Also, what happens to this alternative when location is measured by > the endpoint itself (like a GPS chip), or even manual config? Nothing special happens. Again, this is only about the location hiding case, as indicated by the subject line of my message. If a device has GPS data, the ISP can't hide that location from their customer. (This is why I believe, by the way, that location hiding will be largely pointless for wireless since most above-$50 cell phones will have GPS, if only to allow navigation to work, as well as other consumer features, such as annotating cell phone pictures with location information.) The whole point is that the approach looks, to the end device, pretty much the same either way, whether location is revealed or hidden. > > Just curious how these factor in... > I have to admit that I'm confused by your question. You seem to have a somewhat different mental picture of the whole system. Let me know if the attempt at explanation above missed your question. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 06 13:58:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvzmG-0006pW-Qc; Wed, 06 Jun 2007 13:58:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvzmF-0006pP-VV for ecrit@ietf.org; Wed, 06 Jun 2007 13:58:35 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvzmE-0005WK-Ky for ecrit@ietf.org; Wed, 06 Jun 2007 13:58:35 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1HvzmE-0001qO-3x; Wed, 06 Jun 2007 13:58:34 -0400 Received: from [127.0.0.1] (col-dhcp33-244-154.bbn.com [128.33.244.154]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l56HwXw07729; Wed, 6 Jun 2007 13:58:33 -0400 (EDT) Message-ID: <4666F5C8.7080404@bbn.com> Date: Wed, 06 Jun 2007 13:58:32 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Location hiding: another alternative References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning, Just to keep things organized, isn't this essentially Solution 2 from our earlier discussion? The "token" is a reference that indicates a LoST server that's authorized to dereference it. You could just as well have a regular reference, and some ancillary information alongside it in the LCP & signaling that specifies which LoST server to use it with. I agree that this is an architecturally cleaner proposal than many, and worth investigating, especially in the context of Andy's compromise proposal. --Richard Henning Schulzrinne wrote: > Motivated by a side remark by Andy, here's another alternative that (I > believe) avoids some of the architectural contortions of using the L7 > LCP or DHCP as a LoST transport mechanism. > > The basic idea is that we define a new location type, namely an opaque > token. This token is specific to LoST, i.e., possession of the token can > only be used to get a LoST result. This is logically somewhat similar to > the "additional code" (CAtype 32) in DHCP-civic. This new location > format can be returned by HELD, DHCP or any other location configuration > protocol. Indeed, it could probably be added as another CAtype in > DHCP-civic. The LIS provider decides on the token format, which could be > a hashed IP address, some customer identity (for DSL) or even an > encrypted civic/geo address, with the key known only to the ISP. > > The client does what we have discussed for any other location format: It > blindly copies the new location information into a LoST query. > > The LoST resolver/server/proxy, operated by the ISP, runs some internal > protocol to get the location information from the LIS. This is a private > matter left to the ISP. With that information, the "proxy" constructs a > normal LoST query, of whatever kind, and gets the result, which it > returns to the original querier. > > Since this token is local to a specific LoST server, the actual token > returned would be a LoST URL, such as > > lost:lost.isp.com/fav8z98fa > > The VSP can perform URL verification using this token, if desired. > > This mechanism has the advantage that it maintains the same architecture > as without location hiding and avoids conflating the functionality of > two protocols. It doesn't need any special LbyR mechanisms with the > attendant access issues, as the LoST URL serves only one purpose. > > It's not perfect, in that the VSP verification relies on the VSP > trusting the ISP lookup results, but it is likely "good enough" for > fraud prevention. > > This requires no fundamental changes to LoST and thus can (and should > be) done later. Thus, I believe this is in the spirit of Andy's > compromise proposal, but illustrates that there's more than one way to > do this beyond Solution 1. > > Henning > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 06 15:07:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw0ql-00025E-0C; Wed, 06 Jun 2007 15:07:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw0qj-000252-0h for ecrit@ietf.org; Wed, 06 Jun 2007 15:07:17 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw0qi-0000Q3-N4 for ecrit@ietf.org; Wed, 06 Jun 2007 15:07:16 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 06 Jun 2007 12:07:16 -0700 X-IronPort-AV: i="4.16,390,1175497200"; d="scan'208"; a="491195598:sNHT702802510" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l56J7FZQ010629; Wed, 6 Jun 2007 12:07:15 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l56J7FV1017867; Wed, 6 Jun 2007 19:07:15 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 12:07:15 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.70.65]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 12:07:15 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Jun 2007 14:07:13 -0500 To: Henning Schulzrinne From: "James M. Polk" Subject: Re: [Ecrit] Location hiding: another alternative In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jun 2007 19:07:15.0253 (UTC) FILETIME=[E5230E50:01C7A86D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=877; t=1181156835; x=1182020835; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Location=20hiding=3A=20another=20alternativ e |Sender:=20; bh=YlBCGK/hyDUdvhsUTEyY0nXQMX8KCuEdqd9nVZlVXLY=; b=VZqtpyEm10ubpL43EByoB2P6ztTLG1OK7Aae096i2lfms9V9VqNLNW7L3CxYpk3bBGS5zc0z Zq0b7jHkJ3PGA4+5329o00Sr6uc1pEp9SLYuRXJptldcLKviPGY9K9WB; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 12:22 PM 6/6/2007, Henning Schulzrinne wrote: >>Just curious how these factor in... > >I have to admit that I'm confused by your question. You seem to have >a somewhat different mental picture of the whole system. I think it's more of a case of me attempting to determine if there are any new (mental) pictures happening. I have, in the past, missed a 5 or 10 degree course change within this (emergency services focused) group that over time, becomes not-so-subtle. I was asking early in this discussion (of the new alternative) if this is one such case. Thank you for your explanation! >Let me know if the attempt at explanation above missed your question. I think you've confirmed that to me this is not new, and is in many ways rather pointless to work towards - since there are so many ways right in front of us around it. >Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 06 18:11:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3jJ-000280-K5; Wed, 06 Jun 2007 18:11:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw3jI-00027u-LU for ecrit@ietf.org; Wed, 06 Jun 2007 18:11:48 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw3jH-0007aN-Am for ecrit@ietf.org; Wed, 06 Jun 2007 18:11:48 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l56MBia4009558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Jun 2007 15:11:44 -0700 Received: from [76.102.225.135] (carbuncle.qualcomm.com [129.46.226.38]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l56MBfca004994; Wed, 6 Jun 2007 15:11:43 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <64D5A4F3-27C2-478A-BA0B-F45339A7674C@hxr.us> References: <64D5A4F3-27C2-478A-BA0B-F45339A7674C@hxr.us> Date: Wed, 6 Jun 2007 15:11:41 -0700 To: Andrew Newton , ECRIT From: Ted Hardie Subject: Re: [Ecrit] A compromise to move us forward Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 11:53 AM -0400 6/5/07, Andrew Newton wrote: >All, > >While we might find an answer to the location hiding scenario in the long term, I think it is rather apparent that a near-term solution the satisfies all/most constituencies is unlikely to materialize. >Caught in the middle of this is all the other work we've done. > >I propose we do the following: > >1) Move forward with the modest modifications to LoST to enable Henning's Location Fuzzing proposal (#1 on the wiki). >2) Note in some document somewhere (phonebcp, LoST, ecrit-framework... I don't care) how the location fuzzing proposal works and state that it is not ideal and a better solution is in the works. >3) Seek new charter items for a more thorough location-hiding solution. > >-andy > >___ I agree with this. After reading through the rest of the thread, I'm pretty convinced that a solution in the space covered by #3 is going to take some time to bake. We need to finish off LoST and get it out the door; this allows us to do that and still develop a more elegant solution in the future. Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 06 21:05:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw6Ro-0001nz-1j; Wed, 06 Jun 2007 21:05:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hw6Rn-0001nu-1l for ecrit@ietf.org; Wed, 06 Jun 2007 21:05:55 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hw6Rk-0006x8-Q6 for ecrit@ietf.org; Wed, 06 Jun 2007 21:05:55 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5715bdZ021796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 6 Jun 2007 21:05:38 -0400 (EDT) In-Reply-To: <4666F5C8.7080404@bbn.com> References: <4666F5C8.7080404@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8DA47774-33E6-483E-BC35-D32612F8216C@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Location hiding: another alternative Date: Wed, 6 Jun 2007 21:05:33 -0400 To: Richard Barnes X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 6, 2007, at 1:58 PM, Richard Barnes wrote: > Henning, > > Just to keep things organized, isn't this essentially Solution 2 > from our earlier discussion? > LocationHiding> They are related, but not the same. Among other differences, the solution proposed ("4") avoids the need for *every* LoST server to resolve references (only the ISP-LIS would deal with these) and avoids having to return a rough location or having special trust relationships between ISP/LIS and VSP/LoST server. Since it is unrealistic to assume that every LoST server has a trust relationship with every LIS, the LbyR solution imposes some uncertainty since the user can never know which LoST server will actually work. The objection to other solutions is the need to maintain rough location information; standard location references don't avoid this problem unless there's this unscalable trust relationship. > > The "token" is a reference that indicates a LoST server that's > authorized to dereference it. You could just as well have a > regular reference, and some ancillary information alongside it in > the LCP & signaling that specifies which LoST server to use it > with. I agree that this is an architecturally cleaner proposal > than many, and worth investigating, especially in the context of > Andy's compromise proposal. On the negative side, my proposal requires the end system to use a specific LoST server (which is the same as in Proposal 2, effectively) and has somewhat weaker verification properties for PSAP URLs (where Proposal 2 has none). For that reason, I continue to believe that solution 1 is a better trade-off and thus support Andy's compromise. This new proposal just provides a different set of trade-offs, closer to those in Proposal 3, without some of the architectural warts of tunneling LoST. > > --Richard > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jun 09 04:05:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwvwr-0000N6-EK; Sat, 09 Jun 2007 04:05:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwvwq-0000Mv-IJ for ecrit@ietf.org; Sat, 09 Jun 2007 04:05:24 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hwvwq-0000jA-05 for ecrit@ietf.org; Sat, 09 Jun 2007 04:05:24 -0400 Received: (qmail invoked by alias); 09 Jun 2007 08:05:22 -0000 Received: from ip-90-187-14-246.web.vodafone.de (EHLO [90.187.14.246]) [90.187.14.246] by mail.gmx.net (mp042) with SMTP; 09 Jun 2007 10:05:22 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19nOco1iflnEY41Z+Rh6rsxDH2vBbL2Yw60s0JQ94 BPvgJg0BkqH72b Message-ID: <466A5F3F.9070606@gmx.net> Date: Sat, 09 Jun 2007 10:05:19 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Location hiding: another alternative References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Henning, thank you for the proposal. If the emergency call to the VSP contains a PSAP URI and this token then the verification at the VSP would be performed as follows: * VSP puts the token into a FindService query * The VSP authenticates the VSP's LoST server - If the VSP knows the ASP/ISP then lost.isp.com can be assumed to belong to isp.com. - If the VSP does not know the ASP/ISP then there is a problem because an adversary can just obtain a certificate for a lost.isp.com and claim it is running a LoST server. I think that there is a missing piece here.** * When LoST returns the FindServiceResponse with the PSAP URI to the VSP then it can be compared with the one provided by the end host. If they match then the call is forwarded. If they do not match the PSAP URI that was recently fetched is used for routing the emergency call and a log entry regarding the mismatch is created (since this might potentially an attempt to cheat by the user.) **: Even if we make use of the registry for access networks, as established with RADIUS GEOPRIV, then the problem is not solved since the rights to use a given realm name from the operator namespace "REALM" are obtained coincident with acquiring the rights to use a particular Fully Qualified Domain Name (FQDN). Also, RADIUS GEOPRIV does not say (intentionally) anything about the fact that this access network identity might be associated with a particular type of certificate. Ciao Hannes Henning Schulzrinne wrote: > Motivated by a side remark by Andy, here's another alternative that (I > believe) avoids some of the architectural contortions of using the L7 > LCP or DHCP as a LoST transport mechanism. > > The basic idea is that we define a new location type, namely an opaque > token. This token is specific to LoST, i.e., possession of the token > can only be used to get a LoST result. This is logically somewhat > similar to the "additional code" (CAtype 32) in DHCP-civic. This new > location format can be returned by HELD, DHCP or any other location > configuration protocol. Indeed, it could probably be added as another > CAtype in DHCP-civic. The LIS provider decides on the token format, > which could be a hashed IP address, some customer identity (for DSL) > or even an encrypted civic/geo address, with the key known only to the > ISP. > > The client does what we have discussed for any other location format: > It blindly copies the new location information into a LoST query. > > The LoST resolver/server/proxy, operated by the ISP, runs some > internal protocol to get the location information from the LIS. This > is a private matter left to the ISP. With that information, the > "proxy" constructs a normal LoST query, of whatever kind, and gets the > result, which it returns to the original querier. > > Since this token is local to a specific LoST server, the actual token > returned would be a LoST URL, such as > > lost:lost.isp.com/fav8z98fa > > The VSP can perform URL verification using this token, if desired. > > This mechanism has the advantage that it maintains the same > architecture as without location hiding and avoids conflating the > functionality of two protocols. It doesn't need any special LbyR > mechanisms with the attendant access issues, as the LoST URL serves > only one purpose. > > It's not perfect, in that the VSP verification relies on the VSP > trusting the ISP lookup results, but it is likely "good enough" for > fraud prevention. > > This requires no fundamental changes to LoST and thus can (and should > be) done later. Thus, I believe this is in the spirit of Andy's > compromise proposal, but illustrates that there's more than one way to > do this beyond Solution 1. > > Henning > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jun 09 09:37:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx18A-0005za-9i; Sat, 09 Jun 2007 09:37:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx189-0005u0-Dq for ecrit@ietf.org; Sat, 09 Jun 2007 09:37:25 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hx186-0004dZ-5r for ecrit@ietf.org; Sat, 09 Jun 2007 09:37:25 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l59DbGIP018417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 9 Jun 2007 09:37:20 -0400 (EDT) In-Reply-To: <466A5F3F.9070606@gmx.net> References: <466A5F3F.9070606@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3F29511E-4B96-4729-8E8F-BDD1180E1A5B@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Location hiding: another alternative Date: Sat, 9 Jun 2007 09:37:14 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 9, 2007, at 4:05 AM, Hannes Tschofenig wrote: > - If the VSP does not know the ASP/ISP then there is a problem > because an adversary can just obtain a certificate for a > lost.isp.com and claim it is running a LoST server. I think that > there is a missing piece here.** > > **: Even if we make use of the registry for access networks, as > established with RADIUS GEOPRIV, then the problem is not solved > since the rights to use a given realm name from the operator > namespace "REALM" are obtained coincident with acquiring the rights > to use a particular Fully Qualified Domain Name (FQDN). Also, > RADIUS GEOPRIV does not say (intentionally) anything about the fact > that this access network identity might be associated with a > particular type of certificate. Indeed, this is the problem I alluded to. This is one of the reasons I still consider the rough-location approach to be preferable. That said, getting a certificate exposes a fraudster to significant risk of discovery, reducing the incentive. Also, I think, in general, we need to think about security (for location signing, caller verification and URI verification) as being more probabilistic than absolute. In this case, a combination of - unknown ISP - E.164 address (since the VSP doesn't much care about routing calls to sip:alice@somewhere.com, since those calls don't generally incur costs) - E.164 number that hasn't been seen before in a legitimate LoST resolution - purported ISP is in a different country than the number dialed will trigger a fraud alert. If a single VSP subscriber does more than one of these, maybe it's time for the fraud control department to call that number and find out if this really is a PSAP. There is another solution that we have discussed before for different reasons, namely that the LoST is digitally signed by a PSAP authority. This would avoid the problem altogether. > > Ciao > Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jun 09 10:13:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx1h4-0008Mn-1P; Sat, 09 Jun 2007 10:13:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx1h3-0008Ii-04 for ecrit@ietf.org; Sat, 09 Jun 2007 10:13:29 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hx1h1-00050d-Ot for ecrit@ietf.org; Sat, 09 Jun 2007 10:13:28 -0400 Received: from [10.0.1.110] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Sat, 09 Jun 2007 10:13:25 -0400 id 01588438.466AB585.00007C24 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <64D5A4F3-27C2-478A-BA0B-F45339A7674C@hxr.us> References: <64D5A4F3-27C2-478A-BA0B-F45339A7674C@hxr.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] A compromise to move us forward Date: Sat, 9 Jun 2007 10:13:20 -0400 To: ECRIT X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 5, 2007, at 11:53 AM, Andrew Newton wrote: > I propose we do the following: > > 1) Move forward with the modest modifications to LoST to enable > Henning's Location Fuzzing proposal (#1 on the wiki). > 2) Note in some document somewhere (phonebcp, LoST, ecrit- > framework... I don't care) how the location fuzzing proposal works > and state that it is not ideal and a better solution is in the works. > 3) Seek new charter items for a more thorough location-hiding > solution. Since I proposed this compromise, there have been many suggestions about how to accomplish goal #3 above. I think it is fair to say that with so many ideas and proposals, we are unlikely to discuss them all and come to resolution and conclusion within a short timeframe. Is there anyone who disagrees with this assessment? Is there anyone who does not agree with the proposal stated above on how to move this working group forward? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 12 10:08:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy72Y-00008y-5T; Tue, 12 Jun 2007 10:08:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy72X-00008t-Kd for ecrit@ietf.org; Tue, 12 Jun 2007 10:08:09 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hy72W-0001ih-GO for ecrit@ietf.org; Tue, 12 Jun 2007 10:08:09 -0400 X-SEF-Processed: 5_0_0_910__2007_06_12_09_15_43 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 12 Jun 2007 09:15:43 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Jun 2007 09:08:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Jun 2007 09:08:01 -0500 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Proposals 1 and 3 - summary of perspectives Thread-Index: AceqV4ZeonTtWSgmTEKwTanATYJDUQ== From: "Dawson, Martin" To: X-OriginalArrivalTime: 12 Jun 2007 14:08:04.0749 (UTC) FILETIME=[184803D0:01C7ACFB] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0aa23132abbc731e36938583486affe0 Subject: [Ecrit] Proposals 1 and 3 - summary of perspectives X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2022652387==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============2022652387== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C7ACFB.17BCAACB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7ACFB.17BCAACB Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7ACFB.17BCAACB" ------_=_NextPart_002_01C7ACFB.17BCAACB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For some reason this hasn't made it through moderation. Now I'm a list=0D=0A= subscriber, I'll try again...=0D=0A=0D=0A=20=0D=0A=0D=0AIt's a long weekend= in Australia and winter has finally hit - with cold=0D=0Awind and rain. Wh= at better time, then, to spend some time catching up=0D=0Awith the action o= n the ECRIT list. I only went back a couple of weeks;=0D=0Aobviously the ma= in topic has been to do with the question of how to=0D=0Adefine the "locati= on hiding" capability. Mostly it's a debate about the=0D=0Autility of optio= n 1 and 3.=0D=0A=0D=0A=20=0D=0A=0D=0AHaving just read through all the posti= ngs and while they are fresh in my=0D=0Amind, here is how I characterize th= e perspectives. First my summary of=0D=0Athe options...=0D=0A=0D=0A=20=0D=0A=0D= =0A*=09Option 1 achieves location hiding, somewhat oxymoronically, by=0D=0A= providing location. Whether it's by reference to the local LoST facility=0D= =0Aor by some internal knowledge, the LIS generates a coarse location which=0D= =0Ait knows will result in a correct PSAP URI resolution if/when another=0D= =0Aparty makes a request to the LoST facility. This is provided in addition=0D= =0Ato a location reference for subsequent accurate location requests from=0D= =0Athe PSAP for dispatch etc.=0D=0A*=09Option 3 achieves location hiding by= making the request to the=0D=0Alocal LoST facility using the end points lo= cation and providing the PSAP=0D=0AURI that the LoST service returns (in ad= dition to a location reference)=0D=0Aso the call can be routed to that PSAP= - whether directly from the=0D=0Adevice or via a proxy/VSP.=0D=0A=0D=0A =0D= =0A=0D=0ABoth suggestions are based on an assumption that a LIS, being asso= ciated=0D=0Awith the local jurisdiction, has enough local knowledge to iden= tify the=0D=0Acorrect LoST service for that jurisdiction or, at least in th= e case of=0D=0Aoption 1, to determine what "coarse location" isn't too coar= se.=0D=0A=0D=0A=20=0D=0A=0D=0APerspective 1 - articulated by a lot of peopl= e, Ted, Brian, Andy,...=0D=0Aetc. is that LoST needs to progress and get to= a first release and=0D=0Achanges associated with this particular use case = should be avoided for=0D=0Anow. I haven't seen anything in either proposal = that does require a=0D=0Achange to LoST. In the one case either or both of = the LIS and VSP/proxy=0D=0Amake LoST queries but neither options appears to= *dictate* a specific=0D=0Achange to LoST.=0D=0A=0D=0A=20=0D=0A=0D=0APerspe= ctive 2 - articulated by, for example, James W and Barbara is that=0D=0Athe= LIS operator should have the option of providing location or not - a=0D=0A= "coarse location" is still a location and location information to the=0D=0A= granularity of PSAP boundaries, for example, could still support a lot=0D=0A= of value-added services and be used for other than emergency services.=0D=0A=0D= =0A=20=0D=0A=0D=0APerspective 3 - articulated by, for example, Andy and Lau= ra is that,=0D=0Awhen the end-point initiates a call through the VSP/proxy = with a=0D=0Apre-determined PSAP URI, the proxy may not know that this reall= y is a=0D=0Agenuine emergency call destination. In fact it could be used to= call=0D=0Aanyone by just pretending it's an emergency call. This means the= VSP may=0D=0Alose call revenue through the fraudulent nomination of emerge= ncy calls.=0D=0A=0D=0A=20=0D=0A=0D=0APerspective 4 - articulated by, in par= ticular, Hannes (sorry Hannes, I=0D=0Acan't see anyone else emphasising thi= s point) is that all emergency=0D=0Acalls should go through a VSP so that t= here's an authenticated=0D=0Asubscriber identity to be associated with the = call. This seems like an=0D=0Aorthogonal point to me. If we accept that som= e calls will go through=0D=0AVSPs and therefore Perspective 3 is valid then= the question of whether=0D=0Aall emergency calls have to go through a VSP = is moot. I have to admit to=0D=0Abeing really surprised by the perspective = - it wasn't one that I thought=0D=0Ahad any currency in this forum.=0D=0A=0D= =0A=20=0D=0A=0D=0A=20=0D=0A=0D=0AThere were miscellaneous other perspective= s including some good=0D=0Asuggestions for alternatives/compromises from Ri= chard and Henning.=0D=0A=0D=0A=20=0D=0A=0D=0AMartin D's perspective -=0D=0A=0D= =0A=20=0D=0A=0D=0A*=09On perspective 1, I don't see any impediment to pushi= ng LoST=0D=0Aout. Even if there are changes to come, they can be done in a = revision=0D=0Aor whatever. But I haven't seen any definitive statement abou= t how=0D=0Aeither option *requires* a change to LoST.=0D=0A*=09On perspecti= ve 4, I don't think it's decisive in the discussion.=0D=0A*=09So, really, i= t boils down to an evaluation of which of=0D=0Aperspectives 2 and 3 are the= most valid - i.e. are the interests of the=0D=0ALIS operator or a VSP to h= ave priority.=0D=0A=0D=0A=20=0D=0A=0D=0AI don't understand why the interest= s of LIS operators and VSPs can't=0D=0Aboth be served. I'm surprised that w= ith all the experience and knowledge=0D=0Ain the forum that nobody can prov= ide a practical way for a proxy/VSP to=0D=0Adetermine whether a PSAP URI is= a valid emergency destination or not. I=0D=0Aknow that adding the reverse-= lookup to LoST has been discussed. That=0D=0Awould be effective, but it's n= ot in keeping with perspective 1. Surely,=0D=0Athough, there are alternativ= es.=0D=0A=0D=0A=20=0D=0A=0D=0AI think option 3 supports a faster and smooth= er deployment of global=0D=0Aemergency calling for VoIP. Here's my rational= e.=0D=0A=0D=0A=20=0D=0A=0D=0A1.=09Both options require a LoST and LIS capab= ility to exist at a=0D=0Alocal and jurisdictional level - so their availabi= lity is a premise in=0D=0Aeither proposal=0D=0A2.=09Option 1 assumes that e= ach VSP can make an effective LoST query=0D=0Aeven if it is a "non-local" V= SP to the point from where the call is=0D=0Abeing originated. This is eithe= r by the VSP automatically knowing which=0D=0ALoST server is applicable to = the coarse location or by the use of the so=0D=0Acalled forest guide and pe= rhaps some international hierarchy of=0D=0Ainterconnected LoST servers.=0D=0A= 3.=09Option 3 only assumes that this local knowledge is in the local=0D=0AL= IS function and doesn't rely on the existence of the infrastructure=0D=0Ade= scribed in point 2.=0D=0A4.=09The ability to verify a destination PSAP URI = as a valid=0D=0Aemergency URI could be supported by reference to a relative= ly static=0D=0Atable maintained by global cooperation. In fact, I would hav= e thought=0D=0Athat filtering based on domain name would be extremely relia= ble and=0D=0Afast. It would certainly obviate the ability to make arbitrary= calls by=0D=0Apretending they are emergency calls.=0D=0A5.=09Perhaps a lat= er revision of LoST can include the reverse-lookup=0D=0Amechanism and, perh= aps by then, the international infrastructure of LoST=0D=0Aservers, forest = guides, etc. may be in place.=0D=0A=0D=0A=20=0D=0A=0D=0AI mention point 4 a= s one possible way to protect the interest of the=0D=0AVSPs without requiri= ng a change to the current LoST definition. Are=0D=0Athere any other propos= als on how to achieve this or, alternatively, a=0D=0Aview that it simply is= n't possible=3F=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D= =0A=20=0D=0A=0D=0A Martin Dawson=0D=0A=0D=0AAndrew Network Solutions Asia-P= acific=0D=0A=0D=0AEmail: martin.dawson@andrew.com=0D=0A=0D=0APhone: +61 2 4= 2212992=0D=0A=0D=0AFax: +61 2 42212901=0D=0A=0D=0AMobile: +61 412 120300=0D= =0A=0D=0A=0D=0AThis message is for the designated recipient only and may co= ntain=0D=0Aprivileged, proprietary, or otherwise private information. If yo= u have=0D=0Areceived it in error, please notify the sender immediately and = delete=0D=0Athe original. Any unauthorized use of this email is prohibited.=0D= =0A=0D=0A=20=0D=0A=0D=0A---------------------------------------------------= ---------------------------------------------=0D=0AThis message is for the = designated recipient only and may=0D=0Acontain privileged, proprietary, or = otherwise private information. =20=0D=0AIf you have received it in error, p= lease notify the sender=0D=0Aimmediately and delete the original. Any unau= thorized use of=0D=0Athis email is prohibited.=0D=0A-----------------------= -------------------------------------------------------------------------=0D= =0A[mf2]=0D=0A ------_=_NextPart_002_01C7ACFB.17BCAACB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= =0D=0A=0D=0A
=0D=0A=0D=0A

For some reason this hasn&#= 8217;t made it through=0D=0Amoderation. Now I’m a list subscriber, I&= #8217;ll try again…

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

 

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

It’s a long weekend in Australia and winter has finally=0D=0Ahit – with cold wind and rain. What bet= ter time, then, to spend some time=0D=0Acatching up with the action on the = ECRIT list. I only went back a couple of=0D=0Aweeks; obviously the main top= ic has been to do with the question of how to=0D=0Adefine the “locati= on hiding” capability. Mostly it’s a debate=0D=0Aabout the util= ity of option 1 and 3.

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

 

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

Having just read through all the postings and while they= are=0D=0Afresh in my mind, here is how I characterize the perspectives. Fi= rst my summary=0D=0Aof the options…

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

 

=0D=0A=0D= =0A
    =0D=0A
  • Option 1 achieves location=0D= =0A hiding, somewhat oxymoronically, by providing location. Whether it&= #8217;s=0D=0A by reference to the local LoST facility or by some intern= al knowledge, the=0D=0A LIS generates a coarse location which it knows = will result in a correct=0D=0A PSAP URI resolution if/when another part= y makes a request to the LoST=0D=0A facility. This is provided in addit= ion to a location reference for=0D=0A subsequent accurate location requ= ests from the PSAP for dispatch etc.
    • =0D=0A Option 3= achieves location=0D=0A hiding by making the request to the local LoST= facility using the end=0D=0A points location and providing the PSAP UR= I that the LoST service returns=0D=0A (in addition to a location refere= nce) so the call can be routed to that=0D=0A PSAP – whether direc= tly from the device or via a proxy/VSP.=0D=0A=
=0D=0A=0D=0A

 

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

Both suggestions are bas= ed on an assumption that a LIS,=0D=0Abeing associated with the local jurisd= iction, has enough local knowledge to=0D=0Aidentify the correct LoST servic= e for that jurisdiction or, at least in the=0D=0Acase of option 1, to deter= mine what “coarse location” isn’t=0D=0Atoo coarse.

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

 <= /o:p>

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

Perspecti= ve 1 – articulated by a lot of people, Ted,=0D=0ABrian, Andy,… = etc. is that LoST needs to progress and get to a first=0D=0Arelease and cha= nges associated with this particular use case should be avoided=0D=0Afor no= w. I haven’t seen anything in either proposal that does require a=0D=0A= change to LoST. In the one case either or both of the LIS and VSP/proxy mak= e=0D=0ALoST queries but neither options appears to *dictate*=0D=0Aa specific change to LoST.=

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

 

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

Perspective = 2 – articulated by, for example, James W=0D=0Aand Barbara is that the= LIS operator should have the option of providing=0D=0Alocation or not R= 11; a “coarse location” is still a location and=0D=0Alocation i= nformation to the granularity of PSAP boundaries, for example, could=0D=0As= till support a lot of value-added services and be used for other than=0D=0A= emergency services.

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

 

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

Perspective 3 – articulated by, for example, Andy = and=0D=0ALaura is that, when the end-point initiates a call through the VSP= /proxy with a=0D=0Apre-determined PSAP URI, the proxy may not know that thi= s really is a genuine=0D=0Aemergency call destination. In fact it could be = used to call anyone by just=0D=0Apretending it’s an emergency call. T= his means the VSP may lose call=0D=0Arevenue through the fraudulent nominat= ion of emergency calls.

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

 

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

Perspective 4 – articulated by, in particular, Han= nes=0D=0A(sorry Hannes, I can’t see anyone else emphasising this poin= t) is that=0D=0Aall emergency calls should go through a VSP so that there&#= 8217;s an=0D=0Aauthenticated subscriber identity to be associated with the = call. This seems=0D=0Alike an orthogonal point to me. If we accept that som= e calls will go through=0D=0AVSPs and therefore Perspective 3 is valid then= the question of whether all=0D=0Aemergency calls have to go through a VSP = is moot. I have to admit to being=0D=0Areally surprised by the perspective = – it wasn’t one that I thought=0D=0Ahad any currency in this fo= rum.

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

 

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

 

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

There were miscellaneous other perspectives including some=0D=0Agood= suggestions for alternatives/compromises from Richard and Henning.

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

 <= /o:p>

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

Martin D&= #8217;s perspective –

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

 

=0D=0A=0D=0A
    =0D=0A
  • On perspective 1, I don’t=0D=0A = see any impediment to pushing LoST out. Even if there are changes to co= me,=0D=0A they can be done in a revision or whatever. But I haven’= ;t seen any=0D=0A definitive statement about how either option *requires* a change to Lo= ST.
    • =0D=0A
  • On perspective 4, I don’t=0D=0A = think it’s decisive in the discussion.=0D=0A
  • So, really, it boils down to an=0D=0A evaluation of which of perspecti= ves 2 and 3 are the most valid –=0D=0A i.e. are the interests of = the LIS operator or a VSP to have priority.
    • =0D= =0A
=0D=0A=0D=0A

 =

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

I don’t underst= and why the interests of LIS operators=0D=0Aand VSPs can’t both be se= rved. I’m surprised that with all the=0D=0Aexperience and knowledge i= n the forum that nobody can provide a practical way=0D=0Afor a proxy/VSP to= determine whether a PSAP URI is a valid emergency=0D=0Adestination or not.= I know that adding the reverse-lookup to LoST has been=0D=0Adiscussed. Tha= t would be effective, but it’s not in keeping with=0D=0Aperspective 1= =2E Surely, though, there are alternatives.

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

 

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

I think option 3 supports a faster = and smoother deployment=0D=0Aof global emergency calling for VoIP. HereR= 17;s my rationale.

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

 

=0D=0A=0D=0A
    =0D=0A
  1. Both options require a LoST and=0D=0A = LIS capability to exist at a local and jurisdictional level – so=0D= =0A their availability is a premise in either proposal
    2. =0D=0A
  2. Option 1 assumes that each VSP=0D=0A can make an effecti= ve LoST query even if it is a “non-local”=0D=0A VSP to the = point from where the call is being originated. This is either=0D=0A by = the VSP automatically knowing which LoST server is applicable to the=0D=0A = coarse location or by the use of the so called forest guide and perhaps=0D= =0A some international hierarchy of interconnected LoST servers.
    3. =0D=0A
  3. Option 3 only assumes that this=0D=0A local kn= owledge is in the local LIS function and doesn’t rely on the=0D=0A = existence of the infrastructure described in point 2.
    4. =0D=0A
  4. The ability to verify a=0D=0A destination PSAP URI as a val= id emergency URI could be supported by=0D=0A reference to a relatively = static table maintained by global cooperation.=0D=0A In fact, I would h= ave thought that filtering based on domain name would be=0D=0A extremel= y reliable and fast. It would certainly obviate the ability to=0D=0A ma= ke arbitrary calls by pretending they are emergency calls.
    5. =0D=0A
  5. Perhaps a later revision of=0D=0A LoST can include the r= everse-lookup mechanism and, perhaps by then, the=0D=0A international i= nfrastructure of LoST servers, forest guides, etc. may be=0D=0A in plac= e.
    6. =0D=0A
=0D=0A=0D=0A

 

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

I mention point 4 as one possible way to protect the=0D=0Aint= erest of the VSPs without requiring a change to the current LoST definition= =2E=0D=0AAre there any other proposals on how to achieve this or, alternati= vely, a view=0D=0Athat it simply isn’t possible=3F<= /font>

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

 

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

<= span style=3D'font-size:10.0pt;=0D=0Afont-family:Arial'>Cheers,<= /span>

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

Martin

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

 

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

Martin=0D=0ADawson

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

Andrew Netw= ork Solutions Asia-Pacific

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

Email: martin.dawson@an= drew.com

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

<= font size=3D2 face=3DArial>Phone: +61 2 42212992

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

Fax: +61 2 42212901

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

Mobile:=0D=0A+61 412 120300

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


=0D=0ATh= is message is for the designated recipient only and may=0D=0Acontain privil= eged, proprietary, or otherwise private information. If you have=0D=0Arecei= ved it in error, please notify the sender immediately and delete the=0D=0Ao= riginal. Any unauthorized use of this email is prohibited.

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

 <= /span>

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


--------------------------------------= ----------------------------------------------------------
=0D=0AThis&nb= sp;message is for the designated recipient on= ly and may
=0D=0Acontain privileged, proprietary,&nb= sp;or otherwise private information.  
=0D=0AIf=  you have received it in error, please&n= bsp;notify the sender
=0D=0Aimmediately and delete&n= bsp;the original.  Any unauthorized use of=0D=0Athis email is prohibited.
=0D=0A------------------= ---------------------------------------------------------------------------= ---
=0D=0A[mf2]
=0D=0A=0D=0A=0D=0A ------_=_NextPart_002_01C7ACFB.17BCAACB-- ------_=_NextPart_001_01C7ACFB.17BCAACB Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.jpg Content-Location: image002.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABfAPYDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1v7DZ /wDPpB/37X/Cj7FZ/wDPpB/36X/Cmahc3FrZvLa2jXcwwFiVgMk+57VxHiiLxQ+m+fe3SQrJIscd lZ5JYn1PU0m7HVhsP7eSTklfudlM2j28PnTfYo4/7zBAKxf+Es8KG5aEGAqqljKYAE47Djk1xEOg wW+oWFn4i1JbCS8IFvbEF5GycduF59a3LGPwN4fuL5r7UUuLnT3AnEqMREScABQOeeM81Cc3sjsq UMBRupVHJ+R1OlX1hrEjm30krbqPluJYFVZD6AHmtT7DZ/8APpB/36X/AArGXxx4ZGsDRzqkcd7u EYiZGUbjjAzjGeRTbfx94audXbSk1Efa1kaLa0bAF16gMRjPFaJM8ucot+6rI2/sVn/z6Qf9+1/w o+xWf/PpB/37X/Cudh+I/he4t5biO+kaGJlV3+zuACx2gZx61YHjvw41ylul/wCZK90bRUSJiWlG MgcdOevSnZkXRtfYrP8A59IP+/a/4UfYrP8A59IP+/a/4VNS0hkH2Kz/AOfSD/v2v+FH2Kz/AOfS D/v2v+FT0UAQfYrP/n0g/wC/a/4UfYrP/n0g/wC/a/4VPRQBB9is/wDn0g/79r/hR9is/wDn0g/7 9r/hU9FAEH2Kz/59IP8Av2v+FH2Kz/59IP8Av2v+FT0UAV2tLFFLNbW6qOpMagD9Kgtzo92zLbfY ZivURhGI/Ks+/t11nxGNOuvmsrS3Wd4c8TOxIG71AA6etRauPDFpcRrcslhc25V0lgjKMg9NyjGD 0IrRQ+8ydRrXobv2Kz/59IP+/S/4UfYbP/n0g/79L/hWZe+IfJvfsdjafbJVjWSQmZYlVW6DLdSf SlHiW3msLW4tIJbia7dkit1wG3L94E9ABjk0uSRXtI9zS+xWf/PpB/37X/Cj7FZ/8+kH/ftf8Ko2 utNJJcW95ZPaXcEXnGIuGDp6qw688e1Z8Hi24nSzcaHcD+0FzafvV+c4yd390Yyc+goUJMTqxRvf YrP/AJ9IP+/a/wCFH2Gz/wCfSD/v0v8AhWYPEsSaTLez20kc0M/2Z7YMC3m5ACg9Ocjn0qOLxDJO bi0lsjb3q27TRRrOriQD0YdCDjrQoSD2sDX+w2f/AD6Qf9+l/wAKPsVn/wA+kH/ftf8ACue07xBe QaBpTT2EtxdXh8uMeauXO3O4nsDitESRv4gsjPbSR3r2bsMS5RBkZUgcE5PWhwa3BVItaGh9hs/+ fSD/AL9L/hSfY7IEA2tvk9B5a8/pWWnieN50svscv9omfymtNwyi9fMJ6bMc5/Csu6iZ9Q33MwTa 3+kAt8+dxxsHUjbtxj1701B9ROqump1P2Kz/AOfSD/v0v+FFFl532GD7RnzfLG/Priis27GqZJ5k f/PRP++hRviyMunHT5hxXjl1fzx6jOgcgBzgVuaPdF4fnwx98Vs6TSuZe01DW/AOta14pk12TVrB WS6ia3iOTsiQ5A3dj7AYOaoXfwmvb7VpNSn1S082fUWnnUO21oSwIXp97r7Ve1SXywjA4GD0+tYE l5LNcYEjAZ7GlGLZHtE3axtf8K21W61y4nvtV09bGbUPtxSMEykjOxdx6D1qDS/hhqljfte3Gp2F y7JOyq0jbYp3BCyLxzjvmtDQmJlO87vl7jNdN+5AzsT/AL5FDTWlzSPKzi7P4Zanb+DtR0R9Q04T 3DxPDKsjkAqxJ3Z6dewqbw98MJ9B8QDVI9Ss5fIhH2dXJbExUBnI9PvY/CuneeIMAI4z/wABFIZY /tZGyPHptFK0g0udKkq7F3yx7sDOGGM0vmx/89E/76FYUqxbf9Wn/fIrA1S3LD5OMv2wO1EYczKb sd75kf8Az0T/AL6FJ5kf/PRP++hXAG0f7B3z61NpCG3glmlXzAilsNjsKp0rK9xc53Pmx/8APRP+ +hR5sf8Az0T/AL6Fchaa7p04G6EJ7hAwqxqGr2Fnpz3MKQysOFTaBk1Eo8quwU7uyOn82L/nqn/f Qo82L/nqn/fQrkvC2qTauZo72zgRk5R1jADCukW3g/54Rf8AfAqVZq6KbsWfNi/56p/30KPNi/56 p/30KUWtvj/URf8AfAo+y2//ADwj/wC+BSGZWp2Lz3cWo6deQ297CpTMhykqE52sOvXkEdKqXFpq 2sxi11KewtLMkecttIXeYA525IG0H866D7Lb/wDPCP8A74FH2W3/AOeEf/fAqlNoh00zm9T0Vm1a S/tINMu1njVHivDjYV4DKQDxjqPapP7IuLe1sZbS5shfWZclQoSGQP8AeXA6dufaug+y2/8Azwj/ AO+BR9lt/wDnhH/3wKftGT7KJiQWV3c3U9/qM1ok72zW8MUMhKxg8klj1JOO3amW+lSwx+H1a4ty dLQrNh/vfutny/j61vfZbf8A54R/98Cj7Lb/APPCP/vgUudj9nE5y40A3NjfxNc23mTagbyDd8yd FwHH4EH607TdMliuJbieDSrPMLRpHaAEkn+IsQCB7Cuh+y2//PCP/vgUfZbf/nhH/wB8Cn7SVrC9 lG9zCttKkhtdDia4gzpxzLh+G+Ujj8TVye2L67BqCSwlIraSLaXwSxII/DitH7Lb/wDPCP8A74FH 2W3/AOeEf/fApczK5FaxzS6JeJcLrAv4G1gyfvMufJaL/nl64A5BxnNdFugLBmaIsOhJBI/Gn/Zb f/nhH/3wKPstv/zwj/74FDk3uEYKOwnmxf8APVP++hRS/Zbf/nhH/wB8CiosWeLX0WdWn/3zWpp8 UygbYnx6hDVp5FMZu/8AUGQ4CQINzE9gepP40+b/AEWB7h5ppAmCAHyTnpXdzp6HM49SDWI2FnGW BBweox3rmbZ8XB+td3p1ymr2YEjvGASu1mDfzqLV/Cuk2tqb3zGhf+9kBCT0yPr6VN7CjEp6RJtL t6JWq9/8nXtWNaq1nKIpo8hk5eM5VvUr7VvjR7WW1WWN5iWxxxxRJX1Ki+hnrclmzmpZrjZeZz3q oIZEnZfs7hQepPXn19alnALb8kE84pS91alJOWxtCfzEXnrUjWfnRrx3rlW8SS2pKiCJsdNxNTwe O7tYyDY2/HfLf40lGT+EptLc6s2A+zbMVUktfs2nXJx/yzb+Vc6vxCv2k2fYLYZ92/xqzN4pu7u0 nhe0gAaJskE/3TT5Kii20F4t6FGw8J6b9oV8yxfvAxMUpGc/w+5qHXRZ2+py6ZZah9oaIjzonbcY ie2R+VUW8af8I7pPm7g92yYgiABBPck8dKxvhmLi+8SXl5OpcSgvJM3RWJznNZVpqUUkTSpNT1PU /DivDbx2uwKduV4wVI7GrttqjSXL275jnUnMUq4bHqPUe9ePa18Q9UmN3bWEiwRFmjWdf9YyA4zn tnrxWv4I8UXd/d6ZDevNdTws6CZjuJRgOCe+MVpCHQK1VN+6e0joKWkHQUtcxsFZ2p6xFpbRLNBd SecwVTDCXG49Bx0NaNVb2xS+EG92XyJ1mGO5XtQBBZ65p95DPItykZtnZJlkcBo9rFfmGeOnerE9 /bQ2YuzKGibGwx/NvJ6BcdSe2KzLvwva3cTRyTPgmQjKgjLzLLyO4DKBj0qwuhwppMOno5QQEPHI qgbXB3BgOnXtQBPFq1o0Uckzm1MknlrHcjy2LegB6/hSjV9MaYwDULUyiTyygmXdv/u4z146VRuv D8l9EgutRlkk2vHI4jUb42KkqBj5furz16+tEnhq3dWBnkG5ZAcAfxzeae3rx9KALUmt2AZFhuY5 y04gYQuG2Mc/e546GkbXdMS4toDfQF7pmSLbICGZcZGfXkVm2XhTaga8vGkkWQlRGoVVTe7Bff75 5pLfwbZ2tottHMygFgxRFXcjJsKn324560AbMmp2aadPqCzrNbwIzu0J38KMnGOp46VUt/EulXLS 7LtVWGKOWR5PlRQ+do3HjPHI6jio7Tw5b2WiXWmRyYW6Vld0jVSMrtyAO+AOtE3hu2MxmtJTaygq 6lFBCuGdi2D1z5jcfT0oAnXXLFrq7tRcJ51qgcoZFBZdobcMnpg9TxUtvq1nOdpmWJzM8KpIwDOy HBwM89Ky/wDhEIAjQC8m+zGPYse1cq3kmHduxk/KTx0zT5PCdm+oQ3jSFnjkaTDIrdZDIAM9MMet AG/RSDpRQB5mYPLVp3bMdsAqIgyyuRyx7cf1pIY7WSAAQyM7MA7NJyQOAOBjFRxRy3UZWCDELZEY DYI5yc+uf6CqxubmCfy9qRgHADOqn8ic10wptq63OOrVjDcyPFNzBp+tRxQ3ctlIIVYBl3RHOepX kfkapr4mvVYWOtkz206/IdwKEeqEcVe8R6WdRvkurgFGMQUA9wPSqll4We5srhFPmWoG503fMh/v p7j9RwafLUjqVGcJLQ0NFW5s9Rh0+e7MmmP+8t2CZbP1HIIB+hr0O3nit7aKJnViwGM8ZHrXCaJ9 r0XSt+pKoisZNn2huhVuhHfB4/OrM3inSZypk1CJDEcqSSAVPUfh1/Omo3Wg767HcCO1kI2lCa52 +mgMpiUksOOBxWXD4u0SzugW1eAMOMEnj8xWU/ibSzqZnOs24j3FlK559jxXNzSbdzoStsP1Oxn8 wkYGfXiobexeKHdPNGilupbqfb1qxP4p0S6kAbUoAT/EoO0/pxVU+b4gMj6Oz3KW7bXAIIQnpj2N dFOo7GVRPsW4NPSe4DLcwHnpuxW1YWTWt2kbiGWU5xCzcOcHAPsaoWGiauY0ZrOTjqcVNptpNb+I o5pVIERBIzk9DW0qnu2uZxiyp490ee8h0ltTmt4ovtaxGK2jCpCrjH3jyeQKxfFmvadoek/8Iv4f ZMv/AMfs0bZ4/uZ7k9/yrf8AE2oy3Tzo8QZUXlMZCj/GuCuNBtLqQGzdomc524yprCdL3rrcVOva LTLHg3TIr65nvbgL5NmoYoRnzCeMVt/Dqe207xNPZ3KglJDsH48EVf8AC2kWGm2k1tJc+ZNu2zKw wOVyMVc0/wAMWA1l55lLTXCFYpQxAVsfKR75FbyShBP7zGN5z5F8j1lTkA+1OqtFcxLJHZtJ/pHk +ZtxyVGAT+ZqwTivPPRMG68Q/YrvVYZJIpJbfY1vblgrMpQEnHUgHJJ9Aahi8TzO9urx2yq+7dJv YrNhtv7rAO49/p+db8lzBHIEZh5m3eEAyxXIGcDnqRUnHp09qAOLbxdf3Q8yOO3ihieRJcvzIPL3 oARna/UYPOe1XH8U3aGeOO1iZo1GxWcllOUAL8fdbfkeu011GRnGP0pGdUVnbgKMk47UAZD6ldS6 BcXAeG1uIZHiZ2PyAq+0kEjgHBwSCBnJyBWdH4nnit7XH+lCRmy8u1WkwwXahT5Xb5s5HBAPvXTw zxXNvHPE2+OVA6NjqCMg07gduntQByUXiS7gtFtfkkvJTthaVuZMtJyFA5C7F6etMh8VXkdiJpI7 eWbau+TzCIyfL3FV44Yn5QPXNdjx1xUUdzBLPLAjBpICPMXH3SRkfpQBk6frd1d6o1tNbJHC7SiJ lJ3Dyyud2Rjnd29KzU1zUbDzZLlYpmlupwgLsAVjk2CNBj75HIHfBNdbkUcHGRQBmWOpXM9ndXlz CkcMTyiNYtzuyozKSRjqduQBXPp4kv8AUVhkXEBSQxuIXDo/7225BGf4ZGHX1rsUkWRdyhgOeqkd D70oIA4GPwoAWiiigDza3kl0vwpLfXSBbhAwAXquTx+PNcXaade3iPPHaSzAklmVc810niLURdeE 7OcMQbnarr6Fc5zVTRtUSys0WVGZYmLIFA5zzyeo5HWvXoqUabkkfPYlxlUUW9COGQLDDazE+Q4w QeqH+8PTH8q0dDheFZ0ByVBVxnv0rK1K3urowJEMPPiQkfwqT1PpxzV3wvZyTa+90kuY2nLbWBGV z3/Cs5zu9jvow5YoXXZs/D+6BXB3qgY9eGBH868ru4migaWSRnYdB717D4ytoW8IXaRYAZ0IQ9SQ wBNeZT2CvayRswGV6DrkNiphBygz0KeqN6T4R6hLpw1GXWrYmSIOFIO7JAOK4hraXTL+Wxu0BdOm On1FexyXmpLYO0NxGLWCBQgYhucAZAI4/WuIbwve+IfELTmZHESj7QzP0/uqOOWIrwsPiZ+0fO9D 0qmGSheO5ybN1xxXpXwjJOn6yoHLSRDPpw2K85mAjZlIwynBFemfBpW+y6xIo5WSLOT04NepX+Fs 5IL3j1OHTYBaCKUFgRzg4zXPP4Y/smW8vbOdVRgXRCpJQ4/XmtR/ElpBMIZg4bIGVBIzUmp3Ulto uoXJUN5ETsoPfArkg1JryCcJQTueZX0oZvsURJkwXkJPJPXmqOkWYaX7QVyFGfbNYsN9LEJbwkmW UlixPr1rZsNchaxX7PGyoUG4t13d/wAK9BVU53fQ8nk0HW87LdyyHC/6SM88noK6N75oYQNp3QNu BFctYW5u9JuryP5tkjkn3ABrtIbCO5jV2OPMUEH1yKdOfNCzFKNppo6zVdHm1SVLmOSIDyFQxyA7 Xw6vhsfwkDBqsnhu8iaMi6gd1txGs0iMzQkBuEGcbTuHX0HBro4hiJB6KKfXCekcbD4LnjjjJmt/ OXzEVjuYxIzKwCt16qfT7xq0PCskk8huZoZIXnV3QqT5wDlvnz1PIX6CuooxQBz8vh+eXQvsJ1CZ pfKSM/ORGwVgcY6jIG0nng9Khh8LPG8MgnTzoY4UVzuZlVWcuoJ5wQ4H0H4V01UdW1OPSrI3DRPM xO1Yo+XfucDvgAn6A0Ac9N4PuE0Y6daXMMSMkQ2AFV3qhUsMdCWw3HXFWG8LTZnkS8RZrgOJZADm QFUADHuBtP8A31VgeK7TMjtbzi3VNyTfL85ESy425yPlYde9TWGsSvp9/eX8It/ss7p5ZYZAAGAS OCTn9aAM+LwrcDU4bw3EcAjj2iO3Z1WH73CDPIO4eg4HFWtE0CbTLW+ikaANc7QPs5ZM4TbuJ6hj 1JFJD4rhnMOLG5RWO2UuAphJk8oAgnJ+b0HvUMviovBHKltJb7j5h8zaxaIxysGXBxnMR4P9aAIo vCVyjaYz3aYs2J2Rkoo+cMCMY3HAwScZzzVmHwssVpaxLNtkV2+1Ouf9IQnJU557L9AMCpj4jRIZ pPsszpGdiNlQZpBgFAuc559OaqQeLBPOXa1lhs/3bJNwWYNGzkMucjG0/lQA5/DV00hP2qMl1kUT EN5luWeRsx4PUhwD/ujr0qO18LXFvBYIs0Y+zXBmbczSKB8vCqwxk7Tzxt3Ejvmw3iuONNzWFxuU M8qbk/doqK5brz8rA4HNaFpq8V1fXNr5bRfZ8cykKXBOAQvXaTwD0PagDRHSigdKKAPG1YLbKjxJ JA+d0TD5Sev4H3qe3Gnx7QVkEfVomUHPtkEcVpLoUt1p2+2QtkbtrMAy/wBKoDSr1Yy0kK7hwfmF X7dxTVyVhYzcXYpazrLfMIYivnJtklbG4j0AHAHHSptDvpbaKWWNPMO35UHG4ngfz/Kq7+HdS1KQ RxwoqEDMjOPl5/OmiCQamfDNozh05vpyQCVAztXnpz+NdMZJU0zKpC1ZpbJl/XNQGqeH79gwaOEI uVHBO4cj8f0rmtK0a41XmFIkjQ/PJIeOV6YHXnmul1uwGmeDLmJVIQyJkkgljn/61Yvhu9ZBLAD8 uQw/lWsJShQbW5vTStoSapp17p+htFbyTXcUDCFnSAOS+AenXisfwJLqt7rLIb2Wzt1nE8o2YaY9 NuT2x2rpLnUCLWwCPJGRevI5jbaSobH58YrOkuAt+18GKysSAw6rk9vSvKnSjq1uzrjWk7X6HPax od5f65qMsMJ8wytKYiApCk8EV2PwfJcaujsqYaJSrcdAa5y7Fx9rYRSku6l0J6HHVW9a6D4VtGV1 aclm3yx4IGOxzXRF3hy2MJaO56K3yNtV4AMjg1dkAngeGRo5EcsrKwyCD1zWdJPaeapMByWAFaKN B5xAi5JqY6MiTbRjz+GdOazKxWWno/8ACTCv+FYOp6Vb2mmF4V01GUc4iXn9K7yQQiLHl9KxdTit J7dg1pG/GGDDt7e9bQepk4qx5/LqEtlbPBBJaRQmLeyRoAGJHPGK59/GWopuWPVJY1QYRcAgD0HF b2sR2AkkiiiG7ygu4DA6cVxFxoc26QxhSvbmuirGSiuVGcY3Wp9QWpLWkLE5JRT+lTVlW2t6clrC pueRGoPyN6fSpf7d03/n5/8AHG/wrzzoNCis/wDt3Tf+fn/xxv8ACj+3dN/5+f8Axxv8KANCq91Z W19AYLuCOeInOyRdwqv/AG7pv/Pz/wCON/hR/bum/wDPz/443+FAEw02yVQotYQo6Dyxj7u3/wBB AH04pINMsba0a0gtIY7ds7olQBTnrkVF/bum/wDPz/443+FH9u6b/wA/P/jjf4UAMi8PaVDdxXMV lEjwIViAUbUyxYkDsST1p1noOmWNqLaCzi8sHJ3KCWOCCSe5wSPxNL/bum/8/P8A443+FH9u6b/z 8/8Ajjf4UAPfR9NkaVnsbdmlUK5MY+YDoDSppOnRNE0dlAphUJHiMfKo6AfnUf8Abum/8/P/AI43 +FH9u6b/AM/P/jjf4UASR6Tp8UXlR2UCJhhtEYxhvvfn3pw02zUyEWsQMrB5DsHzEHIJ+hAqH+3d N/5+f/HG/wAKP7d03/n5/wDHG/woAv0VQ/t3Tf8An5/8cb/CigD/2Q== ------_=_NextPart_001_01C7ACFB.17BCAACB-- --===============2022652387== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============2022652387==-- From ecrit-bounces@ietf.org Tue Jun 12 10:17:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy7Br-0001sG-Sw; Tue, 12 Jun 2007 10:17:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy7Bq-0001sA-FR for ecrit@ietf.org; Tue, 12 Jun 2007 10:17:46 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy7Bp-00069Q-8o for ecrit@ietf.org; Tue, 12 Jun 2007 10:17:46 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1Hy774-0004NA-PJ; Tue, 12 Jun 2007 09:12:54 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , References: Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Tue, 12 Jun 2007 10:17:37 -0400 Message-ID: <001c01c7acfc$7012e110$2400000a@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceqV4ZeonTtWSgmTEKwTanATYJDUQCpIGKw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: d0fac514cb168268a385dddd1f66d312 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0305830937==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0305830937== Content-Type: multipart/related; boundary="----=_NextPart_000_001D_01C7ACDA.E9014110" This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C7ACDA.E9014110 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001E_01C7ACDA.E9014110" ------=_NextPart_001_001E_01C7ACDA.E9014110 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I think those of us pushing for Option 1 for now is that we think VSP validation is a fact of life we have to deal with, waving hands over "reference to a relatively static table maintained by global cooperation" is not adequate, and something like a reverse lookup is required. This would be a change to LoST and we are reluctant to take this change on at this time. Brian _____ From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] Sent: Tuesday, June 12, 2007 10:08 AM To: ecrit@ietf.org Subject: [Ecrit] Proposals 1 and 3 - summary of perspectives For some reason this hasn't made it through moderation. Now I'm a list subscriber, I'll try again. It's a long weekend in Australia and winter has finally hit - with cold wind and rain. What better time, then, to spend some time catching up with the action on the ECRIT list. I only went back a couple of weeks; obviously the main topic has been to do with the question of how to define the "location hiding" capability. Mostly it's a debate about the utility of option 1 and 3. Having just read through all the postings and while they are fresh in my mind, here is how I characterize the perspectives. First my summary of the options. * Option 1 achieves location hiding, somewhat oxymoronically, by providing location. Whether it's by reference to the local LoST facility or by some internal knowledge, the LIS generates a coarse location which it knows will result in a correct PSAP URI resolution if/when another party makes a request to the LoST facility. This is provided in addition to a location reference for subsequent accurate location requests from the PSAP for dispatch etc. * Option 3 achieves location hiding by making the request to the local LoST facility using the end points location and providing the PSAP URI that the LoST service returns (in addition to a location reference) so the call can be routed to that PSAP - whether directly from the device or via a proxy/VSP. Both suggestions are based on an assumption that a LIS, being associated with the local jurisdiction, has enough local knowledge to identify the correct LoST service for that jurisdiction or, at least in the case of option 1, to determine what "coarse location" isn't too coarse. Perspective 1 - articulated by a lot of people, Ted, Brian, Andy,. etc. is that LoST needs to progress and get to a first release and changes associated with this particular use case should be avoided for now. I haven't seen anything in either proposal that does require a change to LoST. In the one case either or both of the LIS and VSP/proxy make LoST queries but neither options appears to *dictate* a specific change to LoST. Perspective 2 - articulated by, for example, James W and Barbara is that the LIS operator should have the option of providing location or not - a "coarse location" is still a location and location information to the granularity of PSAP boundaries, for example, could still support a lot of value-added services and be used for other than emergency services. Perspective 3 - articulated by, for example, Andy and Laura is that, when the end-point initiates a call through the VSP/proxy with a pre-determined PSAP URI, the proxy may not know that this really is a genuine emergency call destination. In fact it could be used to call anyone by just pretending it's an emergency call. This means the VSP may lose call revenue through the fraudulent nomination of emergency calls. Perspective 4 - articulated by, in particular, Hannes (sorry Hannes, I can't see anyone else emphasising this point) is that all emergency calls should go through a VSP so that there's an authenticated subscriber identity to be associated with the call. This seems like an orthogonal point to me. If we accept that some calls will go through VSPs and therefore Perspective 3 is valid then the question of whether all emergency calls have to go through a VSP is moot. I have to admit to being really surprised by the perspective - it wasn't one that I thought had any currency in this forum. There were miscellaneous other perspectives including some good suggestions for alternatives/compromises from Richard and Henning. Martin D's perspective - * On perspective 1, I don't see any impediment to pushing LoST out. Even if there are changes to come, they can be done in a revision or whatever. But I haven't seen any definitive statement about how either option *requires* a change to LoST. * On perspective 4, I don't think it's decisive in the discussion. * So, really, it boils down to an evaluation of which of perspectives 2 and 3 are the most valid - i.e. are the interests of the LIS operator or a VSP to have priority. I don't understand why the interests of LIS operators and VSPs can't both be served. I'm surprised that with all the experience and knowledge in the forum that nobody can provide a practical way for a proxy/VSP to determine whether a PSAP URI is a valid emergency destination or not. I know that adding the reverse-lookup to LoST has been discussed. That would be effective, but it's not in keeping with perspective 1. Surely, though, there are alternatives. I think option 3 supports a faster and smoother deployment of global emergency calling for VoIP. Here's my rationale. 1. Both options require a LoST and LIS capability to exist at a local and jurisdictional level - so their availability is a premise in either proposal 2. Option 1 assumes that each VSP can make an effective LoST query even if it is a "non-local" VSP to the point from where the call is being originated. This is either by the VSP automatically knowing which LoST server is applicable to the coarse location or by the use of the so called forest guide and perhaps some international hierarchy of interconnected LoST servers. 3. Option 3 only assumes that this local knowledge is in the local LIS function and doesn't rely on the existence of the infrastructure described in point 2. 4. The ability to verify a destination PSAP URI as a valid emergency URI could be supported by reference to a relatively static table maintained by global cooperation. In fact, I would have thought that filtering based on domain name would be extremely reliable and fast. It would certainly obviate the ability to make arbitrary calls by pretending they are emergency calls. 5. Perhaps a later revision of LoST can include the reverse-lookup mechanism and, perhaps by then, the international infrastructure of LoST servers, forest guides, etc. may be in place. I mention point 4 as one possible way to protect the interest of the VSPs without requiring a change to the current LoST definition. Are there any other proposals on how to achieve this or, alternatively, a view that it simply isn't possible? Cheers, Martin Martin Dawson Andrew Network Solutions Asia-Pacific Email: martin.dawson@andrew.com Phone: +61 2 42212992 Fax: +61 2 42212901 Mobile: +61 412 120300 This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] ------=_NextPart_001_001E_01C7ACDA.E9014110 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I think those of us pushing for = Option 1 for now is that we think VSP validation is a fact of life we have to = deal with, waving hands over “reference to a = relatively static table maintained by global cooperation” is not adequate, and something like a reverse lookup = is required.  This would be a change to LoST and we are reluctant to = take this change on at this time.

 

Brian

 

From: = Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Sent: Tuesday, June 12, = 2007 10:08 AM
To: ecrit@ietf.org
Subject: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

For some reason this hasn’t made it = through moderation. Now I’m a list subscriber, I’ll try = again…

 

It’s a long weekend in Australia and winter has = finally hit – with cold wind and rain. What better time, then, to spend = some time catching up with the action on the ECRIT list. I only went back a couple = of weeks; obviously the main topic has been to do with the question of how = to define the “location hiding” capability. Mostly it’s a debate = about the utility of option 1 and 3.

 

Having just read through all the postings and = while they are fresh in my mind, here is how I characterize the perspectives. = First my summary of the options…

 

  • Option 1 = achieves location hiding, somewhat oxymoronically, by providing location. = Whether it’s by reference to the local LoST facility or by some = internal knowledge, the LIS generates a coarse location which it knows will = result in a correct PSAP URI resolution if/when another party makes a = request to the LoST facility. This is provided in addition to a location = reference for subsequent accurate location requests from the PSAP for = dispatch etc.
  • Option 3 = achieves location hiding by making the request to the local LoST facility = using the end points location and providing the PSAP URI that the LoST = service returns (in addition to a location reference) so the call can be = routed to that PSAP – whether directly from the device or via a = proxy/VSP.

 

Both suggestions are based on an assumption = that a LIS, being associated with the local jurisdiction, has enough local = knowledge to identify the correct LoST service for that jurisdiction or, at least = in the case of option 1, to determine what “coarse location” = isn’t too coarse.

 

Perspective 1 – articulated by a lot of = people, Ted, Brian, Andy,… etc. is that LoST needs to progress and get to = a first release and changes associated with this particular use case should be = avoided for now. I haven’t seen anything in either proposal that does = require a change to LoST. In the one case either or both of the LIS and VSP/proxy = make LoST queries but neither options appears to *dictate* a specific change to LoST.

 

Perspective 2 – articulated by, for = example, James W and Barbara is that the LIS operator should have the option of providing location or not – a “coarse location” is = still a location and location information to the granularity of PSAP boundaries, = for example, could still support a lot of value-added services and be used = for other than emergency services.

 

Perspective 3 – articulated by, for = example, Andy and Laura is that, when the end-point initiates a call through the VSP/proxy with a pre-determined PSAP URI, the proxy may not know that = this really is a genuine emergency call destination. In fact it could be used = to call anyone by just pretending it’s an emergency call. This means = the VSP may lose call revenue through the fraudulent nomination of emergency = calls.

 

Perspective 4 – articulated by, in = particular, Hannes (sorry Hannes, I can’t see anyone else emphasising this = point) is that all emergency calls should go through a VSP so that there’s = an authenticated subscriber identity to be associated with the call. This = seems like an orthogonal point to me. If we accept that some calls will go = through VSPs and therefore Perspective 3 is valid then the question of whether = all emergency calls have to go through a VSP is moot. I have to admit to = being really surprised by the perspective – it wasn’t one that I = thought had any currency in this forum.

 

 

There were miscellaneous other perspectives = including some good suggestions for alternatives/compromises from Richard and = Henning.

 

Martin D’s perspective = –

 

  • On = perspective 1, I don’t see any impediment to pushing LoST out. Even if there = are changes to come, they can be done in a revision or whatever. But I haven’t seen any definitive statement about how either option = *requires* a change to = LoST.
  • On = perspective 4, I don’t think it’s decisive in the = discussion.
  • So, = really, it boils down to an evaluation of which of perspectives 2 and 3 are the most = valid – i.e. are the interests of the LIS operator or a VSP to have priority.

 

I don’t understand why the interests of = LIS operators and VSPs can’t both be served. I’m surprised that = with all the experience and knowledge in the forum that nobody can provide a practical way for a proxy/VSP to determine whether a PSAP URI is a valid emergency destination or not. I know that adding the reverse-lookup to = LoST has been discussed. That would be effective, but it’s not in keeping = with perspective 1. Surely, though, there are = alternatives.

 

I think option 3 supports a faster and = smoother deployment of global emergency calling for VoIP. Here’s my = rationale.

 

  1. Both = options require a LoST and LIS capability to exist at a local and jurisdictional = level – so their availability is a premise in either = proposal
  2. Option 1 = assumes that each VSP can make an effective LoST query even if it is a “non-local” VSP to the point from where the call is = being originated. This is either by the VSP automatically knowing which = LoST server is applicable to the coarse location or by the use of the so = called forest guide and perhaps some international hierarchy of = interconnected LoST servers.
  3. Option 3 = only assumes that this local knowledge is in the local LIS function and doesn’t rely on the existence of the infrastructure described = in point 2.
  4. The = ability to verify a destination PSAP URI as a valid emergency URI could be = supported by reference to a relatively static table maintained by global cooperation. In fact, I would have thought that filtering based on = domain name would be extremely reliable and fast. It would certainly = obviate the ability to make arbitrary calls by pretending they are emergency = calls.
  5. Perhaps a = later revision of LoST can include the reverse-lookup mechanism and, perhaps by = then, the international infrastructure of LoST servers, forest guides, etc. = may be in place.

 

I mention point 4 as one possible way to = protect the interest of the VSPs without requiring a change to the current LoST = definition. Are there any other proposals on how to achieve this or, alternatively, = a view that it simply isn’t possible?

 

Cheers,

Martin

 

Martin Dawson

Andrew Network Solutions = Asia-Pacific

Email: martin.dawson@andrew.com

Phone: +61 2 42212992

Fax: +61 2 42212901

Mobile: +61 412 120300


This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have = received it in error, please notify the sender immediately and delete the = original. Any unauthorized use of this email is prohibited.

 

 


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

 

------=_NextPart_001_001E_01C7ACDA.E9014110-- ------=_NextPart_000_001D_01C7ACDA.E9014110 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABfAPYDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1v7DZ /wDPpB/37X/Cj7FZ/wDPpB/36X/Cmahc3FrZvLa2jXcwwFiVgMk+57VxHiiLxQ+m+fe3SQrJIscd lZ5JYn1PU0m7HVhsP7eSTklfudlM2j28PnTfYo4/7zBAKxf+Es8KG5aEGAqqljKYAE47Djk1xEOg wW+oWFn4i1JbCS8IFvbEF5GycduF59a3LGPwN4fuL5r7UUuLnT3AnEqMREScABQOeeM81Cc3sjsq UMBRupVHJ+R1OlX1hrEjm30krbqPluJYFVZD6AHmtT7DZ/8APpB/36X/AArGXxx4ZGsDRzqkcd7u EYiZGUbjjAzjGeRTbfx94audXbSk1Efa1kaLa0bAF16gMRjPFaJM8ucot+6rI2/sVn/z6Qf9+1/w o+xWf/PpB/37X/Cudh+I/he4t5biO+kaGJlV3+zuACx2gZx61YHjvw41ylul/wCZK90bRUSJiWlG MgcdOevSnZkXRtfYrP8A59IP+/a/4UfYrP8A59IP+/a/4VNS0hkH2Kz/AOfSD/v2v+FH2Kz/AOfS D/v2v+FT0UAQfYrP/n0g/wC/a/4UfYrP/n0g/wC/a/4VPRQBB9is/wDn0g/79r/hR9is/wDn0g/7 9r/hU9FAEH2Kz/59IP8Av2v+FH2Kz/59IP8Av2v+FT0UAV2tLFFLNbW6qOpMagD9Kgtzo92zLbfY ZivURhGI/Ks+/t11nxGNOuvmsrS3Wd4c8TOxIG71AA6etRauPDFpcRrcslhc25V0lgjKMg9NyjGD 0IrRQ+8ydRrXobv2Kz/59IP+/S/4UfYbP/n0g/79L/hWZe+IfJvfsdjafbJVjWSQmZYlVW6DLdSf SlHiW3msLW4tIJbia7dkit1wG3L94E9ABjk0uSRXtI9zS+xWf/PpB/37X/Cj7FZ/8+kH/ftf8Ko2 utNJJcW95ZPaXcEXnGIuGDp6qw688e1Z8Hi24nSzcaHcD+0FzafvV+c4yd390Yyc+goUJMTqxRvf YrP/AJ9IP+/a/wCFH2Gz/wCfSD/v0v8AhWYPEsSaTLez20kc0M/2Z7YMC3m5ACg9Ocjn0qOLxDJO bi0lsjb3q27TRRrOriQD0YdCDjrQoSD2sDX+w2f/AD6Qf9+l/wAKPsVn/wA+kH/ftf8ACue07xBe QaBpTT2EtxdXh8uMeauXO3O4nsDitESRv4gsjPbSR3r2bsMS5RBkZUgcE5PWhwa3BVItaGh9hs/+ fSD/AL9L/hSfY7IEA2tvk9B5a8/pWWnieN50svscv9omfymtNwyi9fMJ6bMc5/Csu6iZ9Q33MwTa 3+kAt8+dxxsHUjbtxj1701B9ROqump1P2Kz/AOfSD/v0v+FFFl532GD7RnzfLG/Priis27GqZJ5k f/PRP++hRviyMunHT5hxXjl1fzx6jOgcgBzgVuaPdF4fnwx98Vs6TSuZe01DW/AOta14pk12TVrB WS6ia3iOTsiQ5A3dj7AYOaoXfwmvb7VpNSn1S082fUWnnUO21oSwIXp97r7Ve1SXywjA4GD0+tYE l5LNcYEjAZ7GlGLZHtE3axtf8K21W61y4nvtV09bGbUPtxSMEykjOxdx6D1qDS/hhqljfte3Gp2F y7JOyq0jbYp3BCyLxzjvmtDQmJlO87vl7jNdN+5AzsT/AL5FDTWlzSPKzi7P4Zanb+DtR0R9Q04T 3DxPDKsjkAqxJ3Z6dewqbw98MJ9B8QDVI9Ss5fIhH2dXJbExUBnI9PvY/CuneeIMAI4z/wABFIZY /tZGyPHptFK0g0udKkq7F3yx7sDOGGM0vmx/89E/76FYUqxbf9Wn/fIrA1S3LD5OMv2wO1EYczKb sd75kf8Az0T/AL6FJ5kf/PRP++hXAG0f7B3z61NpCG3glmlXzAilsNjsKp0rK9xc53Pmx/8APRP+ +hR5sf8Az0T/AL6Fchaa7p04G6EJ7hAwqxqGr2Fnpz3MKQysOFTaBk1Eo8quwU7uyOn82L/nqn/f Qo82L/nqn/fQrkvC2qTauZo72zgRk5R1jADCukW3g/54Rf8AfAqVZq6KbsWfNi/56p/30KPNi/56 p/30KUWtvj/URf8AfAo+y2//ADwj/wC+BSGZWp2Lz3cWo6deQ297CpTMhykqE52sOvXkEdKqXFpq 2sxi11KewtLMkecttIXeYA525IG0H866D7Lb/wDPCP8A74FH2W3/AOeEf/fAqlNoh00zm9T0Vm1a S/tINMu1njVHivDjYV4DKQDxjqPapP7IuLe1sZbS5shfWZclQoSGQP8AeXA6dufaug+y2/8Azwj/ AO+BR9lt/wDnhH/3wKftGT7KJiQWV3c3U9/qM1ok72zW8MUMhKxg8klj1JOO3amW+lSwx+H1a4ty dLQrNh/vfutny/j61vfZbf8A54R/98Cj7Lb/APPCP/vgUudj9nE5y40A3NjfxNc23mTagbyDd8yd FwHH4EH607TdMliuJbieDSrPMLRpHaAEkn+IsQCB7Cuh+y2//PCP/vgUfZbf/nhH/wB8Cn7SVrC9 lG9zCttKkhtdDia4gzpxzLh+G+Ujj8TVye2L67BqCSwlIraSLaXwSxII/DitH7Lb/wDPCP8A74FH 2W3/AOeEf/fApczK5FaxzS6JeJcLrAv4G1gyfvMufJaL/nl64A5BxnNdFugLBmaIsOhJBI/Gn/Zb f/nhH/3wKPstv/zwj/74FDk3uEYKOwnmxf8APVP++hRS/Zbf/nhH/wB8CiosWeLX0WdWn/3zWpp8 UygbYnx6hDVp5FMZu/8AUGQ4CQINzE9gepP40+b/AEWB7h5ppAmCAHyTnpXdzp6HM49SDWI2FnGW BBweox3rmbZ8XB+td3p1ymr2YEjvGASu1mDfzqLV/Cuk2tqb3zGhf+9kBCT0yPr6VN7CjEp6RJtL t6JWq9/8nXtWNaq1nKIpo8hk5eM5VvUr7VvjR7WW1WWN5iWxxxxRJX1Ki+hnrclmzmpZrjZeZz3q oIZEnZfs7hQepPXn19alnALb8kE84pS91alJOWxtCfzEXnrUjWfnRrx3rlW8SS2pKiCJsdNxNTwe O7tYyDY2/HfLf40lGT+EptLc6s2A+zbMVUktfs2nXJx/yzb+Vc6vxCv2k2fYLYZ92/xqzN4pu7u0 nhe0gAaJskE/3TT5Kii20F4t6FGw8J6b9oV8yxfvAxMUpGc/w+5qHXRZ2+py6ZZah9oaIjzonbcY ie2R+VUW8af8I7pPm7g92yYgiABBPck8dKxvhmLi+8SXl5OpcSgvJM3RWJznNZVpqUUkTSpNT1PU /DivDbx2uwKduV4wVI7GrttqjSXL275jnUnMUq4bHqPUe9ePa18Q9UmN3bWEiwRFmjWdf9YyA4zn tnrxWv4I8UXd/d6ZDevNdTws6CZjuJRgOCe+MVpCHQK1VN+6e0joKWkHQUtcxsFZ2p6xFpbRLNBd SecwVTDCXG49Bx0NaNVb2xS+EG92XyJ1mGO5XtQBBZ65p95DPItykZtnZJlkcBo9rFfmGeOnerE9 /bQ2YuzKGibGwx/NvJ6BcdSe2KzLvwva3cTRyTPgmQjKgjLzLLyO4DKBj0qwuhwppMOno5QQEPHI qgbXB3BgOnXtQBPFq1o0Uckzm1MknlrHcjy2LegB6/hSjV9MaYwDULUyiTyygmXdv/u4z146VRuv D8l9EgutRlkk2vHI4jUb42KkqBj5furz16+tEnhq3dWBnkG5ZAcAfxzeae3rx9KALUmt2AZFhuY5 y04gYQuG2Mc/e546GkbXdMS4toDfQF7pmSLbICGZcZGfXkVm2XhTaga8vGkkWQlRGoVVTe7Bff75 5pLfwbZ2tottHMygFgxRFXcjJsKn324560AbMmp2aadPqCzrNbwIzu0J38KMnGOp46VUt/EulXLS 7LtVWGKOWR5PlRQ+do3HjPHI6jio7Tw5b2WiXWmRyYW6Vld0jVSMrtyAO+AOtE3hu2MxmtJTaygq 6lFBCuGdi2D1z5jcfT0oAnXXLFrq7tRcJ51qgcoZFBZdobcMnpg9TxUtvq1nOdpmWJzM8KpIwDOy HBwM89Ky/wDhEIAjQC8m+zGPYse1cq3kmHduxk/KTx0zT5PCdm+oQ3jSFnjkaTDIrdZDIAM9MMet AG/RSDpRQB5mYPLVp3bMdsAqIgyyuRyx7cf1pIY7WSAAQyM7MA7NJyQOAOBjFRxRy3UZWCDELZEY DYI5yc+uf6CqxubmCfy9qRgHADOqn8ic10wptq63OOrVjDcyPFNzBp+tRxQ3ctlIIVYBl3RHOepX kfkapr4mvVYWOtkz206/IdwKEeqEcVe8R6WdRvkurgFGMQUA9wPSqll4We5srhFPmWoG503fMh/v p7j9RwafLUjqVGcJLQ0NFW5s9Rh0+e7MmmP+8t2CZbP1HIIB+hr0O3nit7aKJnViwGM8ZHrXCaJ9 r0XSt+pKoisZNn2huhVuhHfB4/OrM3inSZypk1CJDEcqSSAVPUfh1/Omo3Wg767HcCO1kI2lCa52 +mgMpiUksOOBxWXD4u0SzugW1eAMOMEnj8xWU/ibSzqZnOs24j3FlK559jxXNzSbdzoStsP1Oxn8 wkYGfXiobexeKHdPNGilupbqfb1qxP4p0S6kAbUoAT/EoO0/pxVU+b4gMj6Oz3KW7bXAIIQnpj2N dFOo7GVRPsW4NPSe4DLcwHnpuxW1YWTWt2kbiGWU5xCzcOcHAPsaoWGiauY0ZrOTjqcVNptpNb+I o5pVIERBIzk9DW0qnu2uZxiyp490ee8h0ltTmt4ovtaxGK2jCpCrjH3jyeQKxfFmvadoek/8Iv4f ZMv/AMfs0bZ4/uZ7k9/yrf8AE2oy3Tzo8QZUXlMZCj/GuCuNBtLqQGzdomc524yprCdL3rrcVOva LTLHg3TIr65nvbgL5NmoYoRnzCeMVt/Dqe207xNPZ3KglJDsH48EVf8AC2kWGm2k1tJc+ZNu2zKw wOVyMVc0/wAMWA1l55lLTXCFYpQxAVsfKR75FbyShBP7zGN5z5F8j1lTkA+1OqtFcxLJHZtJ/pHk +ZtxyVGAT+ZqwTivPPRMG68Q/YrvVYZJIpJbfY1vblgrMpQEnHUgHJJ9Aahi8TzO9urx2yq+7dJv YrNhtv7rAO49/p+db8lzBHIEZh5m3eEAyxXIGcDnqRUnHp09qAOLbxdf3Q8yOO3ihieRJcvzIPL3 oARna/UYPOe1XH8U3aGeOO1iZo1GxWcllOUAL8fdbfkeu011GRnGP0pGdUVnbgKMk47UAZD6ldS6 BcXAeG1uIZHiZ2PyAq+0kEjgHBwSCBnJyBWdH4nnit7XH+lCRmy8u1WkwwXahT5Xb5s5HBAPvXTw zxXNvHPE2+OVA6NjqCMg07gduntQByUXiS7gtFtfkkvJTthaVuZMtJyFA5C7F6etMh8VXkdiJpI7 eWbau+TzCIyfL3FV44Yn5QPXNdjx1xUUdzBLPLAjBpICPMXH3SRkfpQBk6frd1d6o1tNbJHC7SiJ lJ3Dyyud2Rjnd29KzU1zUbDzZLlYpmlupwgLsAVjk2CNBj75HIHfBNdbkUcHGRQBmWOpXM9ndXlz CkcMTyiNYtzuyozKSRjqduQBXPp4kv8AUVhkXEBSQxuIXDo/7225BGf4ZGHX1rsUkWRdyhgOeqkd D70oIA4GPwoAWiiigDza3kl0vwpLfXSBbhAwAXquTx+PNcXaade3iPPHaSzAklmVc810niLURdeE 7OcMQbnarr6Fc5zVTRtUSys0WVGZYmLIFA5zzyeo5HWvXoqUabkkfPYlxlUUW9COGQLDDazE+Q4w QeqH+8PTH8q0dDheFZ0ByVBVxnv0rK1K3urowJEMPPiQkfwqT1PpxzV3wvZyTa+90kuY2nLbWBGV z3/Cs5zu9jvow5YoXXZs/D+6BXB3qgY9eGBH868ru4migaWSRnYdB717D4ytoW8IXaRYAZ0IQ9SQ wBNeZT2CvayRswGV6DrkNiphBygz0KeqN6T4R6hLpw1GXWrYmSIOFIO7JAOK4hraXTL+Wxu0BdOm On1FexyXmpLYO0NxGLWCBQgYhucAZAI4/WuIbwve+IfELTmZHESj7QzP0/uqOOWIrwsPiZ+0fO9D 0qmGSheO5ybN1xxXpXwjJOn6yoHLSRDPpw2K85mAjZlIwynBFemfBpW+y6xIo5WSLOT04NepX+Fs 5IL3j1OHTYBaCKUFgRzg4zXPP4Y/smW8vbOdVRgXRCpJQ4/XmtR/ElpBMIZg4bIGVBIzUmp3Ulto uoXJUN5ETsoPfArkg1JryCcJQTueZX0oZvsURJkwXkJPJPXmqOkWYaX7QVyFGfbNYsN9LEJbwkmW UlixPr1rZsNchaxX7PGyoUG4t13d/wAK9BVU53fQ8nk0HW87LdyyHC/6SM88noK6N75oYQNp3QNu BFctYW5u9JuryP5tkjkn3ABrtIbCO5jV2OPMUEH1yKdOfNCzFKNppo6zVdHm1SVLmOSIDyFQxyA7 Xw6vhsfwkDBqsnhu8iaMi6gd1txGs0iMzQkBuEGcbTuHX0HBro4hiJB6KKfXCekcbD4LnjjjJmt/ OXzEVjuYxIzKwCt16qfT7xq0PCskk8huZoZIXnV3QqT5wDlvnz1PIX6CuooxQBz8vh+eXQvsJ1CZ pfKSM/ORGwVgcY6jIG0nng9Khh8LPG8MgnTzoY4UVzuZlVWcuoJ5wQ4H0H4V01UdW1OPSrI3DRPM xO1Yo+XfucDvgAn6A0Ac9N4PuE0Y6daXMMSMkQ2AFV3qhUsMdCWw3HXFWG8LTZnkS8RZrgOJZADm QFUADHuBtP8A31VgeK7TMjtbzi3VNyTfL85ESy425yPlYde9TWGsSvp9/eX8It/ss7p5ZYZAAGAS OCTn9aAM+LwrcDU4bw3EcAjj2iO3Z1WH73CDPIO4eg4HFWtE0CbTLW+ikaANc7QPs5ZM4TbuJ6hj 1JFJD4rhnMOLG5RWO2UuAphJk8oAgnJ+b0HvUMviovBHKltJb7j5h8zaxaIxysGXBxnMR4P9aAIo vCVyjaYz3aYs2J2Rkoo+cMCMY3HAwScZzzVmHwssVpaxLNtkV2+1Ouf9IQnJU557L9AMCpj4jRIZ pPsszpGdiNlQZpBgFAuc559OaqQeLBPOXa1lhs/3bJNwWYNGzkMucjG0/lQA5/DV00hP2qMl1kUT EN5luWeRsx4PUhwD/ujr0qO18LXFvBYIs0Y+zXBmbczSKB8vCqwxk7Tzxt3Ejvmw3iuONNzWFxuU M8qbk/doqK5brz8rA4HNaFpq8V1fXNr5bRfZ8cykKXBOAQvXaTwD0PagDRHSigdKKAPG1YLbKjxJ JA+d0TD5Sev4H3qe3Gnx7QVkEfVomUHPtkEcVpLoUt1p2+2QtkbtrMAy/wBKoDSr1Yy0kK7hwfmF X7dxTVyVhYzcXYpazrLfMIYivnJtklbG4j0AHAHHSptDvpbaKWWNPMO35UHG4ngfz/Kq7+HdS1KQ RxwoqEDMjOPl5/OmiCQamfDNozh05vpyQCVAztXnpz+NdMZJU0zKpC1ZpbJl/XNQGqeH79gwaOEI uVHBO4cj8f0rmtK0a41XmFIkjQ/PJIeOV6YHXnmul1uwGmeDLmJVIQyJkkgljn/61Yvhu9ZBLAD8 uQw/lWsJShQbW5vTStoSapp17p+htFbyTXcUDCFnSAOS+AenXisfwJLqt7rLIb2Wzt1nE8o2YaY9 NuT2x2rpLnUCLWwCPJGRevI5jbaSobH58YrOkuAt+18GKysSAw6rk9vSvKnSjq1uzrjWk7X6HPax od5f65qMsMJ8wytKYiApCk8EV2PwfJcaujsqYaJSrcdAa5y7Fx9rYRSku6l0J6HHVW9a6D4VtGV1 aclm3yx4IGOxzXRF3hy2MJaO56K3yNtV4AMjg1dkAngeGRo5EcsrKwyCD1zWdJPaeapMByWAFaKN B5xAi5JqY6MiTbRjz+GdOazKxWWno/8ACTCv+FYOp6Vb2mmF4V01GUc4iXn9K7yQQiLHl9KxdTit J7dg1pG/GGDDt7e9bQepk4qx5/LqEtlbPBBJaRQmLeyRoAGJHPGK59/GWopuWPVJY1QYRcAgD0HF b2sR2AkkiiiG7ygu4DA6cVxFxoc26QxhSvbmuirGSiuVGcY3Wp9QWpLWkLE5JRT+lTVlW2t6clrC pueRGoPyN6fSpf7d03/n5/8AHG/wrzzoNCis/wDt3Tf+fn/xxv8ACj+3dN/5+f8Axxv8KANCq91Z W19AYLuCOeInOyRdwqv/AG7pv/Pz/wCON/hR/bum/wDPz/443+FAEw02yVQotYQo6Dyxj7u3/wBB AH04pINMsba0a0gtIY7ds7olQBTnrkVF/bum/wDPz/443+FH9u6b/wA/P/jjf4UAMi8PaVDdxXMV lEjwIViAUbUyxYkDsST1p1noOmWNqLaCzi8sHJ3KCWOCCSe5wSPxNL/bum/8/P8A443+FH9u6b/z 8/8Ajjf4UAPfR9NkaVnsbdmlUK5MY+YDoDSppOnRNE0dlAphUJHiMfKo6AfnUf8Abum/8/P/AI43 +FH9u6b/AM/P/jjf4UASR6Tp8UXlR2UCJhhtEYxhvvfn3pw02zUyEWsQMrB5DsHzEHIJ+hAqH+3d N/5+f/HG/wAKP7d03/n5/wDHG/woAv0VQ/t3Tf8An5/8cb/CigD/2Q== ------=_NextPart_000_001D_01C7ACDA.E9014110-- --===============0305830937== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0305830937==-- From ecrit-bounces@ietf.org Tue Jun 12 17:19:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDlX-0007i4-AG; Tue, 12 Jun 2007 17:19:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDlW-0007eD-FE for ecrit@ietf.org; Tue, 12 Jun 2007 17:19:02 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyDlT-0000eE-ON for ecrit@ietf.org; Tue, 12 Jun 2007 17:19:02 -0400 X-SEF-Processed: 5_0_0_910__2007_06_12_16_26_32 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 12 Jun 2007 16:26:32 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Jun 2007 16:18:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Tue, 12 Jun 2007 16:18:45 -0500 Message-ID: In-Reply-To: <001c01c7acfc$7012e110$2400000a@cis.neustar.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives Thread-Index: AceqV4ZeonTtWSgmTEKwTanATYJDUQCpIGKwAA63d4A= References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , X-OriginalArrivalTime: 12 Jun 2007 21:18:53.0108 (UTC) FILETIME=[471A9740:01C7AD37] X-Spam-Score: 0.2 (/) X-Scan-Signature: e02509f7a15c0aaea12155beed3396f0 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1952825601==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1952825601== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C7AD37.45DF5BCD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7AD37.45DF5BCD Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7AD37.45DF5BCD" ------_=_NextPart_002_01C7AD37.45DF5BCD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well hand waving was about all I could invest in an email, but are you=0D=0A= saying you'd just have to give up at that stage=3F What is a reference to=0D= =0Aa "forest guide", if it's not a particularly low-detail suggestion of=0D= =0Athe sort of thing we need to resolve the right LoST server=3F Yet, witho= ut=0D=0Athat, option 1 doesn't work. Why wouldn't this "validation" be a=0D= =0Afunction of that system and why is reverse lookup the only option=3F=0D=0A=0D= =0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A_____= ___________________________=0D=0A=0D=0AFrom: Brian Rosen [mailto:br@brianro= sen.net]=20=0D=0ASent: Wednesday, 13 June 2007 12:18 AM=0D=0ATo: Dawson, Ma= rtin; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3 - summary = of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0AI think those of us pushing for O= ption 1 for now is that we think VSP=0D=0Avalidation is a fact of life we h= ave to deal with, waving hands over=0D=0A"reference to a relatively static = table maintained by global=0D=0Acooperation" is not adequate, and something= like a reverse lookup is=0D=0Arequired. This would be a change to LoST an= d we are reluctant to take=0D=0Athis change on at this time.=0D=0A=0D=0A =0D= =0A=0D=0ABrian=0D=0A=0D=0A=20=0D=0A=0D=0A________________________________=0D= =0A=0D=0AFrom: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20=0D=0ASen= t: Tuesday, June 12, 2007 10:08 AM=0D=0ATo: ecrit@ietf.org=0D=0ASubject: [E= crit] Proposals 1 and 3 - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0A= For some reason this hasn't made it through moderation. Now I'm a list=0D=0A= subscriber, I'll try again...=0D=0A=0D=0A=20=0D=0A=0D=0AIt's a long weekend= in Australia and winter has finally hit - with cold=0D=0Awind and rain. Wh= at better time, then, to spend some time catching up=0D=0Awith the action o= n the ECRIT list. I only went back a couple of weeks;=0D=0Aobviously the ma= in topic has been to do with the question of how to=0D=0Adefine the "locati= on hiding" capability. Mostly it's a debate about the=0D=0Autility of optio= n 1 and 3.=0D=0A=0D=0A=20=0D=0A=0D=0AHaving just read through all the posti= ngs and while they are fresh in my=0D=0Amind, here is how I characterize th= e perspectives. First my summary of=0D=0Athe options...=0D=0A=0D=0A=20=0D=0A=0D= =0A*=09Option 1 achieves location hiding, somewhat oxymoronically, by=0D=0A= providing location. Whether it's by reference to the local LoST facility=0D= =0Aor by some internal knowledge, the LIS generates a coarse location which=0D= =0Ait knows will result in a correct PSAP URI resolution if/when another=0D= =0Aparty makes a request to the LoST facility. This is provided in addition=0D= =0Ato a location reference for subsequent accurate location requests from=0D= =0Athe PSAP for dispatch etc.=0D=0A*=09Option 3 achieves location hiding by= making the request to the=0D=0Alocal LoST facility using the end points lo= cation and providing the PSAP=0D=0AURI that the LoST service returns (in ad= dition to a location reference)=0D=0Aso the call can be routed to that PSAP= - whether directly from the=0D=0Adevice or via a proxy/VSP.=0D=0A=0D=0A =0D= =0A=0D=0ABoth suggestions are based on an assumption that a LIS, being asso= ciated=0D=0Awith the local jurisdiction, has enough local knowledge to iden= tify the=0D=0Acorrect LoST service for that jurisdiction or, at least in th= e case of=0D=0Aoption 1, to determine what "coarse location" isn't too coar= se.=0D=0A=0D=0A=20=0D=0A=0D=0APerspective 1 - articulated by a lot of peopl= e, Ted, Brian, Andy,...=0D=0Aetc. is that LoST needs to progress and get to= a first release and=0D=0Achanges associated with this particular use case = should be avoided for=0D=0Anow. I haven't seen anything in either proposal = that does require a=0D=0Achange to LoST. In the one case either or both of = the LIS and VSP/proxy=0D=0Amake LoST queries but neither options appears to= *dictate* a specific=0D=0Achange to LoST.=0D=0A=0D=0A=20=0D=0A=0D=0APerspe= ctive 2 - articulated by, for example, James W and Barbara is that=0D=0Athe= LIS operator should have the option of providing location or not - a=0D=0A= "coarse location" is still a location and location information to the=0D=0A= granularity of PSAP boundaries, for example, could still support a lot=0D=0A= of value-added services and be used for other than emergency services.=0D=0A=0D= =0A=20=0D=0A=0D=0APerspective 3 - articulated by, for example, Andy and Lau= ra is that,=0D=0Awhen the end-point initiates a call through the VSP/proxy = with a=0D=0Apre-determined PSAP URI, the proxy may not know that this reall= y is a=0D=0Agenuine emergency call destination. In fact it could be used to= call=0D=0Aanyone by just pretending it's an emergency call. This means the= VSP may=0D=0Alose call revenue through the fraudulent nomination of emerge= ncy calls.=0D=0A=0D=0A=20=0D=0A=0D=0APerspective 4 - articulated by, in par= ticular, Hannes (sorry Hannes, I=0D=0Acan't see anyone else emphasising thi= s point) is that all emergency=0D=0Acalls should go through a VSP so that t= here's an authenticated=0D=0Asubscriber identity to be associated with the = call. This seems like an=0D=0Aorthogonal point to me. If we accept that som= e calls will go through=0D=0AVSPs and therefore Perspective 3 is valid then= the question of whether=0D=0Aall emergency calls have to go through a VSP = is moot. I have to admit to=0D=0Abeing really surprised by the perspective = - it wasn't one that I thought=0D=0Ahad any currency in this forum.=0D=0A=0D= =0A=20=0D=0A=0D=0A=20=0D=0A=0D=0AThere were miscellaneous other perspective= s including some good=0D=0Asuggestions for alternatives/compromises from Ri= chard and Henning.=0D=0A=0D=0A=20=0D=0A=0D=0AMartin D's perspective -=0D=0A=0D= =0A=20=0D=0A=0D=0A*=09On perspective 1, I don't see any impediment to pushi= ng LoST=0D=0Aout. Even if there are changes to come, they can be done in a = revision=0D=0Aor whatever. But I haven't seen any definitive statement abou= t how=0D=0Aeither option *requires* a change to LoST.=0D=0A*=09On perspecti= ve 4, I don't think it's decisive in the discussion.=0D=0A*=09So, really, i= t boils down to an evaluation of which of=0D=0Aperspectives 2 and 3 are the= most valid - i.e. are the interests of the=0D=0ALIS operator or a VSP to h= ave priority.=0D=0A=0D=0A=20=0D=0A=0D=0AI don't understand why the interest= s of LIS operators and VSPs can't=0D=0Aboth be served. I'm surprised that w= ith all the experience and knowledge=0D=0Ain the forum that nobody can prov= ide a practical way for a proxy/VSP to=0D=0Adetermine whether a PSAP URI is= a valid emergency destination or not. I=0D=0Aknow that adding the reverse-= lookup to LoST has been discussed. That=0D=0Awould be effective, but it's n= ot in keeping with perspective 1. Surely,=0D=0Athough, there are alternativ= es.=0D=0A=0D=0A=20=0D=0A=0D=0AI think option 3 supports a faster and smooth= er deployment of global=0D=0Aemergency calling for VoIP. Here's my rational= e.=0D=0A=0D=0A=20=0D=0A=0D=0A1.=09Both options require a LoST and LIS capab= ility to exist at a=0D=0Alocal and jurisdictional level - so their availabi= lity is a premise in=0D=0Aeither proposal=0D=0A2.=09Option 1 assumes that e= ach VSP can make an effective LoST query=0D=0Aeven if it is a "non-local" V= SP to the point from where the call is=0D=0Abeing originated. This is eithe= r by the VSP automatically knowing which=0D=0ALoST server is applicable to = the coarse location or by the use of the so=0D=0Acalled forest guide and pe= rhaps some international hierarchy of=0D=0Ainterconnected LoST servers.=0D=0A= 3.=09Option 3 only assumes that this local knowledge is in the local=0D=0AL= IS function and doesn't rely on the existence of the infrastructure=0D=0Ade= scribed in point 2.=0D=0A4.=09The ability to verify a destination PSAP URI = as a valid=0D=0Aemergency URI could be supported by reference to a relative= ly static=0D=0Atable maintained by global cooperation. In fact, I would hav= e thought=0D=0Athat filtering based on domain name would be extremely relia= ble and=0D=0Afast. It would certainly obviate the ability to make arbitrary= calls by=0D=0Apretending they are emergency calls.=0D=0A5.=09Perhaps a lat= er revision of LoST can include the reverse-lookup=0D=0Amechanism and, perh= aps by then, the international infrastructure of LoST=0D=0Aservers, forest = guides, etc. may be in place.=0D=0A=0D=0A=20=0D=0A=0D=0AI mention point 4 a= s one possible way to protect the interest of the=0D=0AVSPs without requiri= ng a change to the current LoST definition. Are=0D=0Athere any other propos= als on how to achieve this or, alternatively, a=0D=0Aview that it simply is= n't possible=3F=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D= =0A=20=0D=0A=0D=0A Martin Dawson=0D=0A=0D=0AAndrew Network Solutions Asia-P= acific=0D=0A=0D=0AEmail: martin.dawson@andrew.com=0D=0A=0D=0APhone: +61 2 4= 2212992=0D=0A=0D=0AFax: +61 2 42212901=0D=0A=0D=0AMobile: +61 412 120300=0D= =0A=0D=0A=0D=0AThis message is for the designated recipient only and may co= ntain=0D=0Aprivileged, proprietary, or otherwise private information. If yo= u have=0D=0Areceived it in error, please notify the sender immediately and = delete=0D=0Athe original. Any unauthorized use of this email is prohibited.=0D= =0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A=0D=0A------------------------------= ------------------------------------------=0D=0A------------------------=0D= =0AThis message is for the designated recipient only and may=0D=0Acontain p= rivileged, proprietary, or otherwise private information. =20=0D=0AIf you h= ave received it in error, please notify the sender=0D=0Aimmediately and del= ete the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D= =0A------------------------------------------------------------------------=0D= =0A------------------------=0D=0A[mf2]=0D=0A=0D=0A=20=0D=0A=0D=0A----------= ---------------------------------------------------------------------------= -----------=0D=0AThis message is for the designated recipient only and may=0D= =0Acontain privileged, proprietary, or otherwise private information. =20=0D= =0AIf you have received it in error, please notify the sender=0D=0Aimmediat= ely and delete the original. Any unauthorized use of=0D=0Athis email is pr= ohibited.=0D=0A------------------------------------------------------------= ------------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_002_01C7AD37.45DF5BCD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A
=0D= =0A=0D=0A

Well hand w= aving was about all I could=0D=0Ainvest in an email, but are you saying you= ’d just have to give up at that=0D=0Astage=3F What is a reference to = a “forest guide”, if it’s not a=0D=0Aparticularly low-det= ail suggestion of the sort of thing we need to resolve the=0D=0Aright LoST = server=3F Yet, without that, option 1 doesn’t work. Why wouldn’= t=0D=0Athis “validation” be a function of that system and why i= s reverse=0D=0Alookup the only option=3F

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

 =

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

Cheers,

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

Martin

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

 =

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

From:=0D=0ABrian Ros= en [mailto:br@brianrosen.net]
=0D=0ASent: Wednesday, 13 June 2007=0D=0A12:18 AM
=0D=0ATo: Dawson, Martin; ecrit@ietf.org
=0D=0ASubject: RE: [Ecrit] Proposals 1=0D=0Aand 3 - s= ummary of perspectives=0D=0A=0D=0A

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

 <= /span>

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

I think those of us=0D=0Apushing for Option 1 for now = is that we think VSP validation is a fact of life=0D=0Awe have to deal with= , waving hands over “<= span style=3D'font-size:10.0pt;font-family:Arial'>reference to a=0D=0Arelat= ively static table maintained by global cooperation” is not adequate, and som= ething like a=0D=0Areverse lookup is required.  This would be a change= to LoST and we are=0D=0Areluctant to take this change on at this time.

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

 

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

Brian

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

 

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

From:=0D=0ADawson, Martin [mailto:Martin.D= awson@andrew.com]
=0D=0ASent: Tuesday, June 12, 2007 10:08=0D=0AAM
=0D=0ATo: ecrit@ietf.org
=0D=0ASubject: [Ecrit] Proposals 1 and 3=0D=0A- summary of perspectives

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

 

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

For some reason this hasn’t made it th= rough=0D=0Amoderation. Now I’m a list subscriber, I’ll try agai= n…

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

 

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

It’s a long weekend in Australia and winte= r has finally=0D=0Ahit – with cold wind and rain. What better time, t= hen, to spend some time=0D=0Acatching up with the action on the ECRIT list.= I only went back a couple of=0D=0Aweeks; obviously the main topic has been= to do with the question of how to=0D=0Adefine the “location hiding&#= 8221; capability. Mostly it’s a debate=0D=0Aabout the utility of opti= on 1 and 3.

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

 

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

Having just read through all the postings and while they are=0D=0A= fresh in my mind, here is how I characterize the perspectives. First my sum= mary=0D=0Aof the options…

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

 

=0D=0A=0D=0A=
    =0D=0A
  • Option 1 achieves location=0D=0A= hiding, somewhat oxymoronically, by providing location. Whether itR= 17;s=0D=0A by reference to the local LoST facility or by some internal = knowledge, the=0D=0A LIS generates a coarse location which it knows wil= l result in a correct=0D=0A PSAP URI resolution if/when another party m= akes a request to the LoST=0D=0A facility. This is provided in addition= to a location reference for=0D=0A subsequent accurate location request= s from the PSAP for dispatch etc.
    • =0D=0A
  • Option 3 a= chieves location=0D=0A hiding by making the request to the local LoST f= acility using the end=0D=0A points location and providing the PSAP URI = that the LoST service returns=0D=0A (in addition to a location referenc= e) so the call can be routed to that=0D=0A PSAP – whether directl= y from the device or via a proxy/VSP.
    • =0D=0A=0D=0A=0D=0A

     

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

    Both suggestions are based= on an assumption that a LIS,=0D=0Abeing associated with the local jurisdic= tion, has enough local knowledge to=0D=0Aidentify the correct LoST service = for that jurisdiction or, at least in the=0D=0Acase of option 1, to determi= ne what “coarse location” isn’t=0D=0Atoo coarse.

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

     <= /o:p>

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

    Perspecti= ve 1 – articulated by a lot of people, Ted,=0D=0ABrian, Andy,… = etc. is that LoST needs to progress and get to a first=0D=0Arelease and cha= nges associated with this particular use case should be avoided=0D=0Afor no= w. I haven’t seen anything in either proposal that does require a=0D=0A= change to LoST. In the one case either or both of the LIS and VSP/proxy mak= e=0D=0ALoST queries but neither options appears to *dictate*=0D=0Aa specific change to LoST.=

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

     

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

    Perspective = 2 – articulated by, for example, James W=0D=0Aand Barbara is that the= LIS operator should have the option of providing=0D=0Alocation or not R= 11; a “coarse location” is still a location and=0D=0Alocation i= nformation to the granularity of PSAP boundaries, for example, could=0D=0As= till support a lot of value-added services and be used for other than=0D=0A= emergency services.

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

     

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

    Perspective 3 – articulated by, for example, Andy = and=0D=0ALaura is that, when the end-point initiates a call through the VSP= /proxy with a=0D=0Apre-determined PSAP URI, the proxy may not know that thi= s really is a genuine=0D=0Aemergency call destination. In fact it could be = used to call anyone by just=0D=0Apretending it’s an emergency call. T= his means the VSP may lose call=0D=0Arevenue through the fraudulent nominat= ion of emergency calls.

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

     

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

    Perspective 4 – articulated by, in particular, Han= nes=0D=0A(sorry Hannes, I can’t see anyone else emphasising this poin= t) is that=0D=0Aall emergency calls should go through a VSP so that there&#= 8217;s an=0D=0Aauthenticated subscriber identity to be associated with the = call. This seems=0D=0Alike an orthogonal point to me. If we accept that som= e calls will go through=0D=0AVSPs and therefore Perspective 3 is valid then= the question of whether all=0D=0Aemergency calls have to go through a VSP = is moot. I have to admit to being=0D=0Areally surprised by the perspective = – it wasn’t one that I thought=0D=0Ahad any currency in this fo= rum.

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

     

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

     

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

    There were miscellaneous other perspectives including some=0D=0Agood= suggestions for alternatives/compromises from Richard and Henning.

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

     <= /o:p>

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

    Martin D&= #8217;s perspective –

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

     

    =0D=0A=0D=0A
      =0D=0A
    • On perspective 1, I don’t=0D=0A = see any impediment to pushing LoST out. Even if there are changes to co= me,=0D=0A they can be done in a revision or whatever. But I haven’= ;t seen any=0D=0A definitive statement about how either option *requires* a change to Lo= ST.
      • =0D=0A
    • On perspective 4, I don’t=0D=0A = think it’s decisive in the discussion.=0D=0A
    • So, really, it boils down to an=0D=0A evaluation of which of perspecti= ves 2 and 3 are the most valid –=0D=0A i.e. are the interests of = the LIS operator or a VSP to have priority.
      • =0D= =0A
    =0D=0A=0D=0A

     =

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

    I don’t underst= and why the interests of LIS operators=0D=0Aand VSPs can’t both be se= rved. I’m surprised that with all the=0D=0Aexperience and knowledge i= n the forum that nobody can provide a practical way=0D=0Afor a proxy/VSP to= determine whether a PSAP URI is a valid emergency=0D=0Adestination or not.= I know that adding the reverse-lookup to LoST has been=0D=0Adiscussed. Tha= t would be effective, but it’s not in keeping with=0D=0Aperspective 1= =2E Surely, though, there are alternatives.

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

     

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

    I think option 3 supports a faster = and smoother deployment=0D=0Aof global emergency calling for VoIP. HereR= 17;s my rationale.

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

     

    =0D=0A=0D=0A
      =0D=0A
    1. Both options require a LoST and=0D=0A = LIS capability to exist at a local and jurisdictional level – so=0D= =0A their availability is a premise in either proposal
      2. =0D=0A
    2. Option 1 assumes that each VSP=0D=0A can make an effecti= ve LoST query even if it is a “non-local”=0D=0A VSP to the = point from where the call is being originated. This is either=0D=0A by = the VSP automatically knowing which LoST server is applicable to the=0D=0A = coarse location or by the use of the so called forest guide and perhaps=0D= =0A some international hierarchy of interconnected LoST servers.
      3. =0D=0A
    3. Option 3 only assumes that this=0D=0A local kn= owledge is in the local LIS function and doesn’t rely on the=0D=0A = existence of the infrastructure described in point 2.
      4. =0D=0A
    4. The ability to verify a=0D=0A destination PSAP URI as a val= id emergency URI could be supported by=0D=0A reference to a relatively = static table maintained by global cooperation.=0D=0A In fact, I would h= ave thought that filtering based on domain name would be=0D=0A extremel= y reliable and fast. It would certainly obviate the ability to=0D=0A ma= ke arbitrary calls by pretending they are emergency calls.
      5. =0D=0A
    5. Perhaps a later revision of=0D=0A LoST can include the r= everse-lookup mechanism and, perhaps by then, the=0D=0A international i= nfrastructure of LoST servers, forest guides, etc. may be=0D=0A in plac= e.
      6. =0D=0A
    =0D=0A=0D=0A

     

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

    I mention point 4 as one possible way to protect the=0D=0Aint= erest of the VSPs without requiring a change to the current LoST definition= =2E=0D=0AAre there any other proposals on how to achieve this or, alternati= vely, a view=0D=0Athat it simply isn’t possible=3F<= /font>

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

     

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

    <= span style=3D'font-size:10.0pt;=0D=0Afont-family:Arial'>Cheers,<= /span>

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

    Martin

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

     

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

    Martin=0D=0ADawson

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

    Andrew Netw= ork Solutions Asia-Pacific

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

    Email: martin.dawson@an= drew.com

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

    <= font size=3D2 face=3DArial>Phone: +61 2 42212992

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

    Fax: +61 2 42212901

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

    Mobile:=0D=0A+61 412 120300

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


    =0D=0A    Th= is message is for the designated recipient only and may=0D=0Acontain privil= eged, proprietary, or otherwise private information. If you have=0D=0Arecei= ved it in error, please notify the sender immediately and delete the=0D=0Ao= riginal. Any unauthorized use of this email is prohibited.

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

     <= /span>

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

     

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


    =0D=0A = --------------------------------------------------------------------------= ----------------------
    =0D=0A This message is for t= he designated recipient only and may
    =0D=0A co= ntain privileged, proprietary, or otherwise privat= e information.  
    =0D=0A If you have recei= ved it in error, please notify the sende= r
    =0D=0A immediately and delete the original. =  Any unauthorized use of
    =0D=0A this email&nbs= p;is prohibited.
    =0D=0A ------------------------------------------= ------------------------------------------------------
    =0D=0A [mf2]

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

     

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


----------------------------------------= --------------------------------------------------------
=0D=0AThis = ;message is for the designated recipient only=  and may
=0D=0Acontain privileged, proprietary, = ;or otherwise private information.  
=0D=0AIf&n= bsp;you have received it in error, please&nbs= p;notify the sender
=0D=0Aimmediately and delete&nbs= p;the original.  Any unauthorized use of
=0D= =0Athis email is prohibited.
=0D=0A----------------------= --------------------------------------------------------------------------<= br>=0D=0A[mf2]
=0D=0A=0D=0A=0D=0A ------_=_NextPart_002_01C7AD37.45DF5BCD-- ------_=_NextPart_001_01C7AD37.45DF5BCD Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.jpg Content-Location: image002.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABfAPYDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1v7DZ /wDPpB/37X/Cj7FZ/wDPpB/36X/Cmahc3FrZvLa2jXcwwFiVgMk+57VxHiiLxQ+m+fe3SQrJIscd lZ5JYn1PU0m7HVhsP7eSTklfudlM2j28PnTfYo4/7zBAKxf+Es8KG5aEGAqqljKYAE47Djk1xEOg wW+oWFn4i1JbCS8IFvbEF5GycduF59a3LGPwN4fuL5r7UUuLnT3AnEqMREScABQOeeM81Cc3sjsq UMBRupVHJ+R1OlX1hrEjm30krbqPluJYFVZD6AHmtT7DZ/8APpB/36X/AArGXxx4ZGsDRzqkcd7u EYiZGUbjjAzjGeRTbfx94audXbSk1Efa1kaLa0bAF16gMRjPFaJM8ucot+6rI2/sVn/z6Qf9+1/w o+xWf/PpB/37X/Cudh+I/he4t5biO+kaGJlV3+zuACx2gZx61YHjvw41ylul/wCZK90bRUSJiWlG MgcdOevSnZkXRtfYrP8A59IP+/a/4UfYrP8A59IP+/a/4VNS0hkH2Kz/AOfSD/v2v+FH2Kz/AOfS D/v2v+FT0UAQfYrP/n0g/wC/a/4UfYrP/n0g/wC/a/4VPRQBB9is/wDn0g/79r/hR9is/wDn0g/7 9r/hU9FAEH2Kz/59IP8Av2v+FH2Kz/59IP8Av2v+FT0UAV2tLFFLNbW6qOpMagD9Kgtzo92zLbfY ZivURhGI/Ks+/t11nxGNOuvmsrS3Wd4c8TOxIG71AA6etRauPDFpcRrcslhc25V0lgjKMg9NyjGD 0IrRQ+8ydRrXobv2Kz/59IP+/S/4UfYbP/n0g/79L/hWZe+IfJvfsdjafbJVjWSQmZYlVW6DLdSf SlHiW3msLW4tIJbia7dkit1wG3L94E9ABjk0uSRXtI9zS+xWf/PpB/37X/Cj7FZ/8+kH/ftf8Ko2 utNJJcW95ZPaXcEXnGIuGDp6qw688e1Z8Hi24nSzcaHcD+0FzafvV+c4yd390Yyc+goUJMTqxRvf YrP/AJ9IP+/a/wCFH2Gz/wCfSD/v0v8AhWYPEsSaTLez20kc0M/2Z7YMC3m5ACg9Ocjn0qOLxDJO bi0lsjb3q27TRRrOriQD0YdCDjrQoSD2sDX+w2f/AD6Qf9+l/wAKPsVn/wA+kH/ftf8ACue07xBe QaBpTT2EtxdXh8uMeauXO3O4nsDitESRv4gsjPbSR3r2bsMS5RBkZUgcE5PWhwa3BVItaGh9hs/+ fSD/AL9L/hSfY7IEA2tvk9B5a8/pWWnieN50svscv9omfymtNwyi9fMJ6bMc5/Csu6iZ9Q33MwTa 3+kAt8+dxxsHUjbtxj1701B9ROqump1P2Kz/AOfSD/v0v+FFFl532GD7RnzfLG/Priis27GqZJ5k f/PRP++hRviyMunHT5hxXjl1fzx6jOgcgBzgVuaPdF4fnwx98Vs6TSuZe01DW/AOta14pk12TVrB WS6ia3iOTsiQ5A3dj7AYOaoXfwmvb7VpNSn1S082fUWnnUO21oSwIXp97r7Ve1SXywjA4GD0+tYE l5LNcYEjAZ7GlGLZHtE3axtf8K21W61y4nvtV09bGbUPtxSMEykjOxdx6D1qDS/hhqljfte3Gp2F y7JOyq0jbYp3BCyLxzjvmtDQmJlO87vl7jNdN+5AzsT/AL5FDTWlzSPKzi7P4Zanb+DtR0R9Q04T 3DxPDKsjkAqxJ3Z6dewqbw98MJ9B8QDVI9Ss5fIhH2dXJbExUBnI9PvY/CuneeIMAI4z/wABFIZY /tZGyPHptFK0g0udKkq7F3yx7sDOGGM0vmx/89E/76FYUqxbf9Wn/fIrA1S3LD5OMv2wO1EYczKb sd75kf8Az0T/AL6FJ5kf/PRP++hXAG0f7B3z61NpCG3glmlXzAilsNjsKp0rK9xc53Pmx/8APRP+ +hR5sf8Az0T/AL6Fchaa7p04G6EJ7hAwqxqGr2Fnpz3MKQysOFTaBk1Eo8quwU7uyOn82L/nqn/f Qo82L/nqn/fQrkvC2qTauZo72zgRk5R1jADCukW3g/54Rf8AfAqVZq6KbsWfNi/56p/30KPNi/56 p/30KUWtvj/URf8AfAo+y2//ADwj/wC+BSGZWp2Lz3cWo6deQ297CpTMhykqE52sOvXkEdKqXFpq 2sxi11KewtLMkecttIXeYA525IG0H866D7Lb/wDPCP8A74FH2W3/AOeEf/fAqlNoh00zm9T0Vm1a S/tINMu1njVHivDjYV4DKQDxjqPapP7IuLe1sZbS5shfWZclQoSGQP8AeXA6dufaug+y2/8Azwj/ AO+BR9lt/wDnhH/3wKftGT7KJiQWV3c3U9/qM1ok72zW8MUMhKxg8klj1JOO3amW+lSwx+H1a4ty dLQrNh/vfutny/j61vfZbf8A54R/98Cj7Lb/APPCP/vgUudj9nE5y40A3NjfxNc23mTagbyDd8yd FwHH4EH607TdMliuJbieDSrPMLRpHaAEkn+IsQCB7Cuh+y2//PCP/vgUfZbf/nhH/wB8Cn7SVrC9 lG9zCttKkhtdDia4gzpxzLh+G+Ujj8TVye2L67BqCSwlIraSLaXwSxII/DitH7Lb/wDPCP8A74FH 2W3/AOeEf/fApczK5FaxzS6JeJcLrAv4G1gyfvMufJaL/nl64A5BxnNdFugLBmaIsOhJBI/Gn/Zb f/nhH/3wKPstv/zwj/74FDk3uEYKOwnmxf8APVP++hRS/Zbf/nhH/wB8CiosWeLX0WdWn/3zWpp8 UygbYnx6hDVp5FMZu/8AUGQ4CQINzE9gepP40+b/AEWB7h5ppAmCAHyTnpXdzp6HM49SDWI2FnGW BBweox3rmbZ8XB+td3p1ymr2YEjvGASu1mDfzqLV/Cuk2tqb3zGhf+9kBCT0yPr6VN7CjEp6RJtL t6JWq9/8nXtWNaq1nKIpo8hk5eM5VvUr7VvjR7WW1WWN5iWxxxxRJX1Ki+hnrclmzmpZrjZeZz3q oIZEnZfs7hQepPXn19alnALb8kE84pS91alJOWxtCfzEXnrUjWfnRrx3rlW8SS2pKiCJsdNxNTwe O7tYyDY2/HfLf40lGT+EptLc6s2A+zbMVUktfs2nXJx/yzb+Vc6vxCv2k2fYLYZ92/xqzN4pu7u0 nhe0gAaJskE/3TT5Kii20F4t6FGw8J6b9oV8yxfvAxMUpGc/w+5qHXRZ2+py6ZZah9oaIjzonbcY ie2R+VUW8af8I7pPm7g92yYgiABBPck8dKxvhmLi+8SXl5OpcSgvJM3RWJznNZVpqUUkTSpNT1PU /DivDbx2uwKduV4wVI7GrttqjSXL275jnUnMUq4bHqPUe9ePa18Q9UmN3bWEiwRFmjWdf9YyA4zn tnrxWv4I8UXd/d6ZDevNdTws6CZjuJRgOCe+MVpCHQK1VN+6e0joKWkHQUtcxsFZ2p6xFpbRLNBd SecwVTDCXG49Bx0NaNVb2xS+EG92XyJ1mGO5XtQBBZ65p95DPItykZtnZJlkcBo9rFfmGeOnerE9 /bQ2YuzKGibGwx/NvJ6BcdSe2KzLvwva3cTRyTPgmQjKgjLzLLyO4DKBj0qwuhwppMOno5QQEPHI qgbXB3BgOnXtQBPFq1o0Uckzm1MknlrHcjy2LegB6/hSjV9MaYwDULUyiTyygmXdv/u4z146VRuv D8l9EgutRlkk2vHI4jUb42KkqBj5furz16+tEnhq3dWBnkG5ZAcAfxzeae3rx9KALUmt2AZFhuY5 y04gYQuG2Mc/e546GkbXdMS4toDfQF7pmSLbICGZcZGfXkVm2XhTaga8vGkkWQlRGoVVTe7Bff75 5pLfwbZ2tottHMygFgxRFXcjJsKn324560AbMmp2aadPqCzrNbwIzu0J38KMnGOp46VUt/EulXLS 7LtVWGKOWR5PlRQ+do3HjPHI6jio7Tw5b2WiXWmRyYW6Vld0jVSMrtyAO+AOtE3hu2MxmtJTaygq 6lFBCuGdi2D1z5jcfT0oAnXXLFrq7tRcJ51qgcoZFBZdobcMnpg9TxUtvq1nOdpmWJzM8KpIwDOy HBwM89Ky/wDhEIAjQC8m+zGPYse1cq3kmHduxk/KTx0zT5PCdm+oQ3jSFnjkaTDIrdZDIAM9MMet AG/RSDpRQB5mYPLVp3bMdsAqIgyyuRyx7cf1pIY7WSAAQyM7MA7NJyQOAOBjFRxRy3UZWCDELZEY DYI5yc+uf6CqxubmCfy9qRgHADOqn8ic10wptq63OOrVjDcyPFNzBp+tRxQ3ctlIIVYBl3RHOepX kfkapr4mvVYWOtkz206/IdwKEeqEcVe8R6WdRvkurgFGMQUA9wPSqll4We5srhFPmWoG503fMh/v p7j9RwafLUjqVGcJLQ0NFW5s9Rh0+e7MmmP+8t2CZbP1HIIB+hr0O3nit7aKJnViwGM8ZHrXCaJ9 r0XSt+pKoisZNn2huhVuhHfB4/OrM3inSZypk1CJDEcqSSAVPUfh1/Omo3Wg767HcCO1kI2lCa52 +mgMpiUksOOBxWXD4u0SzugW1eAMOMEnj8xWU/ibSzqZnOs24j3FlK559jxXNzSbdzoStsP1Oxn8 wkYGfXiobexeKHdPNGilupbqfb1qxP4p0S6kAbUoAT/EoO0/pxVU+b4gMj6Oz3KW7bXAIIQnpj2N dFOo7GVRPsW4NPSe4DLcwHnpuxW1YWTWt2kbiGWU5xCzcOcHAPsaoWGiauY0ZrOTjqcVNptpNb+I o5pVIERBIzk9DW0qnu2uZxiyp490ee8h0ltTmt4ovtaxGK2jCpCrjH3jyeQKxfFmvadoek/8Iv4f ZMv/AMfs0bZ4/uZ7k9/yrf8AE2oy3Tzo8QZUXlMZCj/GuCuNBtLqQGzdomc524yprCdL3rrcVOva LTLHg3TIr65nvbgL5NmoYoRnzCeMVt/Dqe207xNPZ3KglJDsH48EVf8AC2kWGm2k1tJc+ZNu2zKw wOVyMVc0/wAMWA1l55lLTXCFYpQxAVsfKR75FbyShBP7zGN5z5F8j1lTkA+1OqtFcxLJHZtJ/pHk +ZtxyVGAT+ZqwTivPPRMG68Q/YrvVYZJIpJbfY1vblgrMpQEnHUgHJJ9Aahi8TzO9urx2yq+7dJv YrNhtv7rAO49/p+db8lzBHIEZh5m3eEAyxXIGcDnqRUnHp09qAOLbxdf3Q8yOO3ihieRJcvzIPL3 oARna/UYPOe1XH8U3aGeOO1iZo1GxWcllOUAL8fdbfkeu011GRnGP0pGdUVnbgKMk47UAZD6ldS6 BcXAeG1uIZHiZ2PyAq+0kEjgHBwSCBnJyBWdH4nnit7XH+lCRmy8u1WkwwXahT5Xb5s5HBAPvXTw zxXNvHPE2+OVA6NjqCMg07gduntQByUXiS7gtFtfkkvJTthaVuZMtJyFA5C7F6etMh8VXkdiJpI7 eWbau+TzCIyfL3FV44Yn5QPXNdjx1xUUdzBLPLAjBpICPMXH3SRkfpQBk6frd1d6o1tNbJHC7SiJ lJ3Dyyud2Rjnd29KzU1zUbDzZLlYpmlupwgLsAVjk2CNBj75HIHfBNdbkUcHGRQBmWOpXM9ndXlz CkcMTyiNYtzuyozKSRjqduQBXPp4kv8AUVhkXEBSQxuIXDo/7225BGf4ZGHX1rsUkWRdyhgOeqkd D70oIA4GPwoAWiiigDza3kl0vwpLfXSBbhAwAXquTx+PNcXaade3iPPHaSzAklmVc810niLURdeE 7OcMQbnarr6Fc5zVTRtUSys0WVGZYmLIFA5zzyeo5HWvXoqUabkkfPYlxlUUW9COGQLDDazE+Q4w QeqH+8PTH8q0dDheFZ0ByVBVxnv0rK1K3urowJEMPPiQkfwqT1PpxzV3wvZyTa+90kuY2nLbWBGV z3/Cs5zu9jvow5YoXXZs/D+6BXB3qgY9eGBH868ru4migaWSRnYdB717D4ytoW8IXaRYAZ0IQ9SQ wBNeZT2CvayRswGV6DrkNiphBygz0KeqN6T4R6hLpw1GXWrYmSIOFIO7JAOK4hraXTL+Wxu0BdOm On1FexyXmpLYO0NxGLWCBQgYhucAZAI4/WuIbwve+IfELTmZHESj7QzP0/uqOOWIrwsPiZ+0fO9D 0qmGSheO5ybN1xxXpXwjJOn6yoHLSRDPpw2K85mAjZlIwynBFemfBpW+y6xIo5WSLOT04NepX+Fs 5IL3j1OHTYBaCKUFgRzg4zXPP4Y/smW8vbOdVRgXRCpJQ4/XmtR/ElpBMIZg4bIGVBIzUmp3Ulto uoXJUN5ETsoPfArkg1JryCcJQTueZX0oZvsURJkwXkJPJPXmqOkWYaX7QVyFGfbNYsN9LEJbwkmW UlixPr1rZsNchaxX7PGyoUG4t13d/wAK9BVU53fQ8nk0HW87LdyyHC/6SM88noK6N75oYQNp3QNu BFctYW5u9JuryP5tkjkn3ABrtIbCO5jV2OPMUEH1yKdOfNCzFKNppo6zVdHm1SVLmOSIDyFQxyA7 Xw6vhsfwkDBqsnhu8iaMi6gd1txGs0iMzQkBuEGcbTuHX0HBro4hiJB6KKfXCekcbD4LnjjjJmt/ OXzEVjuYxIzKwCt16qfT7xq0PCskk8huZoZIXnV3QqT5wDlvnz1PIX6CuooxQBz8vh+eXQvsJ1CZ pfKSM/ORGwVgcY6jIG0nng9Khh8LPG8MgnTzoY4UVzuZlVWcuoJ5wQ4H0H4V01UdW1OPSrI3DRPM xO1Yo+XfucDvgAn6A0Ac9N4PuE0Y6daXMMSMkQ2AFV3qhUsMdCWw3HXFWG8LTZnkS8RZrgOJZADm QFUADHuBtP8A31VgeK7TMjtbzi3VNyTfL85ESy425yPlYde9TWGsSvp9/eX8It/ss7p5ZYZAAGAS OCTn9aAM+LwrcDU4bw3EcAjj2iO3Z1WH73CDPIO4eg4HFWtE0CbTLW+ikaANc7QPs5ZM4TbuJ6hj 1JFJD4rhnMOLG5RWO2UuAphJk8oAgnJ+b0HvUMviovBHKltJb7j5h8zaxaIxysGXBxnMR4P9aAIo vCVyjaYz3aYs2J2Rkoo+cMCMY3HAwScZzzVmHwssVpaxLNtkV2+1Ouf9IQnJU557L9AMCpj4jRIZ pPsszpGdiNlQZpBgFAuc559OaqQeLBPOXa1lhs/3bJNwWYNGzkMucjG0/lQA5/DV00hP2qMl1kUT EN5luWeRsx4PUhwD/ujr0qO18LXFvBYIs0Y+zXBmbczSKB8vCqwxk7Tzxt3Ejvmw3iuONNzWFxuU M8qbk/doqK5brz8rA4HNaFpq8V1fXNr5bRfZ8cykKXBOAQvXaTwD0PagDRHSigdKKAPG1YLbKjxJ JA+d0TD5Sev4H3qe3Gnx7QVkEfVomUHPtkEcVpLoUt1p2+2QtkbtrMAy/wBKoDSr1Yy0kK7hwfmF X7dxTVyVhYzcXYpazrLfMIYivnJtklbG4j0AHAHHSptDvpbaKWWNPMO35UHG4ngfz/Kq7+HdS1KQ RxwoqEDMjOPl5/OmiCQamfDNozh05vpyQCVAztXnpz+NdMZJU0zKpC1ZpbJl/XNQGqeH79gwaOEI uVHBO4cj8f0rmtK0a41XmFIkjQ/PJIeOV6YHXnmul1uwGmeDLmJVIQyJkkgljn/61Yvhu9ZBLAD8 uQw/lWsJShQbW5vTStoSapp17p+htFbyTXcUDCFnSAOS+AenXisfwJLqt7rLIb2Wzt1nE8o2YaY9 NuT2x2rpLnUCLWwCPJGRevI5jbaSobH58YrOkuAt+18GKysSAw6rk9vSvKnSjq1uzrjWk7X6HPax od5f65qMsMJ8wytKYiApCk8EV2PwfJcaujsqYaJSrcdAa5y7Fx9rYRSku6l0J6HHVW9a6D4VtGV1 aclm3yx4IGOxzXRF3hy2MJaO56K3yNtV4AMjg1dkAngeGRo5EcsrKwyCD1zWdJPaeapMByWAFaKN B5xAi5JqY6MiTbRjz+GdOazKxWWno/8ACTCv+FYOp6Vb2mmF4V01GUc4iXn9K7yQQiLHl9KxdTit J7dg1pG/GGDDt7e9bQepk4qx5/LqEtlbPBBJaRQmLeyRoAGJHPGK59/GWopuWPVJY1QYRcAgD0HF b2sR2AkkiiiG7ygu4DA6cVxFxoc26QxhSvbmuirGSiuVGcY3Wp9QWpLWkLE5JRT+lTVlW2t6clrC pueRGoPyN6fSpf7d03/n5/8AHG/wrzzoNCis/wDt3Tf+fn/xxv8ACj+3dN/5+f8Axxv8KANCq91Z W19AYLuCOeInOyRdwqv/AG7pv/Pz/wCON/hR/bum/wDPz/443+FAEw02yVQotYQo6Dyxj7u3/wBB AH04pINMsba0a0gtIY7ds7olQBTnrkVF/bum/wDPz/443+FH9u6b/wA/P/jjf4UAMi8PaVDdxXMV lEjwIViAUbUyxYkDsST1p1noOmWNqLaCzi8sHJ3KCWOCCSe5wSPxNL/bum/8/P8A443+FH9u6b/z 8/8Ajjf4UAPfR9NkaVnsbdmlUK5MY+YDoDSppOnRNE0dlAphUJHiMfKo6AfnUf8Abum/8/P/AI43 +FH9u6b/AM/P/jjf4UASR6Tp8UXlR2UCJhhtEYxhvvfn3pw02zUyEWsQMrB5DsHzEHIJ+hAqH+3d N/5+f/HG/wAKP7d03/n5/wDHG/woAv0VQ/t3Tf8An5/8cb/CigD/2Q== ------_=_NextPart_001_01C7AD37.45DF5BCD-- --===============1952825601== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1952825601==-- From ecrit-bounces@ietf.org Tue Jun 12 20:27:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyGiC-0007ws-A2; Tue, 12 Jun 2007 20:27:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyGiA-0007vl-Ie for ecrit@ietf.org; Tue, 12 Jun 2007 20:27:46 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyGi9-0003fZ-5d for ecrit@ietf.org; Tue, 12 Jun 2007 20:27:46 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1HyGfy-0005nE-8Z; Tue, 12 Jun 2007 19:25:31 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com> Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Tue, 12 Jun 2007 20:27:39 -0400 Message-ID: <012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AceqV4ZeonTtWSgmTEKwTanATYJDUQCpIGKwAA63d4AABo3GsA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 53a1754727d2be1e1d13b7140e24f91c Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1048161888==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1048161888== Content-Type: multipart/related; boundary="----=_NextPart_000_012B_01C7AD30.20C734B0" This is a multi-part message in MIME format. ------=_NextPart_000_012B_01C7AD30.20C734B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_012C_01C7AD30.20C734B0" ------=_NextPart_001_012C_01C7AD30.20C734B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm sorry but the forest guide idea is a whole lot more developed that any notion of an authoritative list of PSAP URIs. I'm not saying it can't be done, I'm saying we need a whole lot more work on it to make it real, and it's not at all clear to me that the reverse lookup idea has more or less merit. However, both of them are beyond what I think is appropriate for LoST at this point. Brian _____ From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] Sent: Tuesday, June 12, 2007 5:19 PM To: Brian Rosen; ecrit@ietf.org Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Well hand waving was about all I could invest in an email, but are you saying you'd just have to give up at that stage? What is a reference to a "forest guide", if it's not a particularly low-detail suggestion of the sort of thing we need to resolve the right LoST server? Yet, without that, option 1 doesn't work. Why wouldn't this "validation" be a function of that system and why is reverse lookup the only option? Cheers, Martin _____ From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, 13 June 2007 12:18 AM To: Dawson, Martin; ecrit@ietf.org Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives I think those of us pushing for Option 1 for now is that we think VSP validation is a fact of life we have to deal with, waving hands over "reference to a relatively static table maintained by global cooperation" is not adequate, and something like a reverse lookup is required. This would be a change to LoST and we are reluctant to take this change on at this time. Brian _____ From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] Sent: Tuesday, June 12, 2007 10:08 AM To: ecrit@ietf.org Subject: [Ecrit] Proposals 1 and 3 - summary of perspectives For some reason this hasn't made it through moderation. Now I'm a list subscriber, I'll try again. It's a long weekend in Australia and winter has finally hit - with cold wind and rain. What better time, then, to spend some time catching up with the action on the ECRIT list. I only went back a couple of weeks; obviously the main topic has been to do with the question of how to define the "location hiding" capability. Mostly it's a debate about the utility of option 1 and 3. Having just read through all the postings and while they are fresh in my mind, here is how I characterize the perspectives. First my summary of the options. * Option 1 achieves location hiding, somewhat oxymoronically, by providing location. Whether it's by reference to the local LoST facility or by some internal knowledge, the LIS generates a coarse location which it knows will result in a correct PSAP URI resolution if/when another party makes a request to the LoST facility. This is provided in addition to a location reference for subsequent accurate location requests from the PSAP for dispatch etc. * Option 3 achieves location hiding by making the request to the local LoST facility using the end points location and providing the PSAP URI that the LoST service returns (in addition to a location reference) so the call can be routed to that PSAP - whether directly from the device or via a proxy/VSP. Both suggestions are based on an assumption that a LIS, being associated with the local jurisdiction, has enough local knowledge to identify the correct LoST service for that jurisdiction or, at least in the case of option 1, to determine what "coarse location" isn't too coarse. Perspective 1 - articulated by a lot of people, Ted, Brian, Andy,. etc. is that LoST needs to progress and get to a first release and changes associated with this particular use case should be avoided for now. I haven't seen anything in either proposal that does require a change to LoST. In the one case either or both of the LIS and VSP/proxy make LoST queries but neither options appears to *dictate* a specific change to LoST. Perspective 2 - articulated by, for example, James W and Barbara is that the LIS operator should have the option of providing location or not - a "coarse location" is still a location and location information to the granularity of PSAP boundaries, for example, could still support a lot of value-added services and be used for other than emergency services. Perspective 3 - articulated by, for example, Andy and Laura is that, when the end-point initiates a call through the VSP/proxy with a pre-determined PSAP URI, the proxy may not know that this really is a genuine emergency call destination. In fact it could be used to call anyone by just pretending it's an emergency call. This means the VSP may lose call revenue through the fraudulent nomination of emergency calls. Perspective 4 - articulated by, in particular, Hannes (sorry Hannes, I can't see anyone else emphasising this point) is that all emergency calls should go through a VSP so that there's an authenticated subscriber identity to be associated with the call. This seems like an orthogonal point to me. If we accept that some calls will go through VSPs and therefore Perspective 3 is valid then the question of whether all emergency calls have to go through a VSP is moot. I have to admit to being really surprised by the perspective - it wasn't one that I thought had any currency in this forum. There were miscellaneous other perspectives including some good suggestions for alternatives/compromises from Richard and Henning. Martin D's perspective - * On perspective 1, I don't see any impediment to pushing LoST out. Even if there are changes to come, they can be done in a revision or whatever. But I haven't seen any definitive statement about how either option *requires* a change to LoST. * On perspective 4, I don't think it's decisive in the discussion. * So, really, it boils down to an evaluation of which of perspectives 2 and 3 are the most valid - i.e. are the interests of the LIS operator or a VSP to have priority. I don't understand why the interests of LIS operators and VSPs can't both be served. I'm surprised that with all the experience and knowledge in the forum that nobody can provide a practical way for a proxy/VSP to determine whether a PSAP URI is a valid emergency destination or not. I know that adding the reverse-lookup to LoST has been discussed. That would be effective, but it's not in keeping with perspective 1. Surely, though, there are alternatives. I think option 3 supports a faster and smoother deployment of global emergency calling for VoIP. Here's my rationale. 1. Both options require a LoST and LIS capability to exist at a local and jurisdictional level - so their availability is a premise in either proposal 2. Option 1 assumes that each VSP can make an effective LoST query even if it is a "non-local" VSP to the point from where the call is being originated. This is either by the VSP automatically knowing which LoST server is applicable to the coarse location or by the use of the so called forest guide and perhaps some international hierarchy of interconnected LoST servers. 3. Option 3 only assumes that this local knowledge is in the local LIS function and doesn't rely on the existence of the infrastructure described in point 2. 4. The ability to verify a destination PSAP URI as a valid emergency URI could be supported by reference to a relatively static table maintained by global cooperation. In fact, I would have thought that filtering based on domain name would be extremely reliable and fast. It would certainly obviate the ability to make arbitrary calls by pretending they are emergency calls. 5. Perhaps a later revision of LoST can include the reverse-lookup mechanism and, perhaps by then, the international infrastructure of LoST servers, forest guides, etc. may be in place. I mention point 4 as one possible way to protect the interest of the VSPs without requiring a change to the current LoST definition. Are there any other proposals on how to achieve this or, alternatively, a view that it simply isn't possible? Cheers, Martin Martin Dawson Andrew Network Solutions Asia-Pacific Email: martin.dawson@andrew.com Phone: +61 2 42212992 Fax: +61 2 42212901 Mobile: +61 412 120300 This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] ------=_NextPart_001_012C_01C7AD30.20C734B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m sorry but the forest = guide idea is a whole lot more developed that any notion of an authoritative list = of PSAP URIs.  I’m not saying it can’t be done, I’m = saying we need a whole lot more work on it to make it real, and it’s not at = all clear to me that the reverse lookup idea has more or less merit.  = However, both of them are beyond what I think is appropriate for LoST at this = point.

 

Brian

 

From: = Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Sent: Tuesday, June 12, = 2007 5:19 PM
To: Brian Rosen; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

Well hand waving = was about all I could invest in an email, but are you saying you’d = just have to give up at that stage? What is a reference to a “forest = guide”, if it’s not a particularly low-detail suggestion of the sort of = thing we need to resolve the right LoST server? Yet, without that, option 1 doesn’t work. Why wouldn’t this “validation” be = a function of that system and why is reverse lookup the only = option?

 =

Cheers,

Martin=

 =

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, 13 June = 2007 12:18 AM
To: Dawson, Martin; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

I think those of us pushing for = Option 1 for now is that we think VSP validation is a fact of life we have to = deal with, waving hands over “reference to a = relatively static table maintained by global cooperation” is not adequate, and something like a reverse lookup = is required.  This would be a change to LoST and we are reluctant to = take this change on at this time.

 

Brian

 

From: = Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Sent: Tuesday, June 12, = 2007 10:08 AM
To: ecrit@ietf.org
Subject: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

For some reason this hasn’t made it = through moderation. Now I’m a list subscriber, I’ll try = again…

 

It’s a long weekend in Australia and winter has = finally hit – with cold wind and rain. What better time, then, to spend = some time catching up with the action on the ECRIT list. I only went back a couple = of weeks; obviously the main topic has been to do with the question of how = to define the “location hiding” capability. Mostly it’s a = debate about the utility of option 1 and 3.

 

Having just read through all the postings and = while they are fresh in my mind, here is how I characterize the perspectives. = First my summary of the options…

 

  • Option 1 = achieves location hiding, somewhat oxymoronically, by providing location. = Whether it’s by reference to the local LoST facility or by some = internal knowledge, the LIS generates a coarse location which it knows will = result in a correct PSAP URI resolution if/when another party makes a = request to the LoST facility. This is provided in addition to a location = reference for subsequent accurate location requests from the PSAP for = dispatch etc.
  • Option 3 = achieves location hiding by making the request to the local LoST facility = using the end points location and providing the PSAP URI that the LoST = service returns (in addition to a location reference) so the call can be = routed to that PSAP – whether directly from the device or via a = proxy/VSP.

 

Both suggestions are based on an assumption = that a LIS, being associated with the local jurisdiction, has enough local = knowledge to identify the correct LoST service for that jurisdiction or, at least = in the case of option 1, to determine what “coarse location” = isn’t too coarse.

 

Perspective 1 – articulated by a lot of = people, Ted, Brian, Andy,… etc. is that LoST needs to progress and get to = a first release and changes associated with this particular use case should be = avoided for now. I haven’t seen anything in either proposal that does = require a change to LoST. In the one case either or both of the LIS and VSP/proxy = make LoST queries but neither options appears to *dictate* a specific change to LoST.

 

Perspective 2 – articulated by, for = example, James W and Barbara is that the LIS operator should have the option of providing location or not – a “coarse location” is = still a location and location information to the granularity of PSAP boundaries, = for example, could still support a lot of value-added services and be used = for other than emergency services.

 

Perspective 3 – articulated by, for = example, Andy and Laura is that, when the end-point initiates a call through the VSP/proxy with a pre-determined PSAP URI, the proxy may not know that = this really is a genuine emergency call destination. In fact it could be used = to call anyone by just pretending it’s an emergency call. This means = the VSP may lose call revenue through the fraudulent nomination of emergency = calls.

 

Perspective 4 – articulated by, in = particular, Hannes (sorry Hannes, I can’t see anyone else emphasising this = point) is that all emergency calls should go through a VSP so that there’s = an authenticated subscriber identity to be associated with the call. This = seems like an orthogonal point to me. If we accept that some calls will go = through VSPs and therefore Perspective 3 is valid then the question of whether = all emergency calls have to go through a VSP is moot. I have to admit to = being really surprised by the perspective – it wasn’t one that I = thought had any currency in this forum.

 

 

There were miscellaneous other perspectives = including some good suggestions for alternatives/compromises from Richard and = Henning.

 

Martin D’s perspective = –

 

  • On = perspective 1, I don’t see any impediment to pushing LoST out. Even if there = are changes to come, they can be done in a revision or whatever. But I haven’t seen any definitive statement about how either option = *requires* a change to = LoST.
  • On = perspective 4, I don’t think it’s decisive in the = discussion.
  • So, = really, it boils down to an evaluation of which of perspectives 2 and 3 are the most = valid – i.e. are the interests of the LIS operator or a VSP to have priority.

 

I don’t understand why the interests of = LIS operators and VSPs can’t both be served. I’m surprised that = with all the experience and knowledge in the forum that nobody can provide a practical way for a proxy/VSP to determine whether a PSAP URI is a valid emergency destination or not. I know that adding the reverse-lookup to = LoST has been discussed. That would be effective, but it’s not in keeping = with perspective 1. Surely, though, there are = alternatives.

 

I think option 3 supports a faster and = smoother deployment of global emergency calling for VoIP. Here’s my = rationale.

 

  1. Both = options require a LoST and LIS capability to exist at a local and jurisdictional = level – so their availability is a premise in either = proposal
  2. Option 1 = assumes that each VSP can make an effective LoST query even if it is a “non-local” VSP to the point from where the call is = being originated. This is either by the VSP automatically knowing which = LoST server is applicable to the coarse location or by the use of the so = called forest guide and perhaps some international hierarchy of = interconnected LoST servers.
  3. Option 3 = only assumes that this local knowledge is in the local LIS function and doesn’t rely on the existence of the infrastructure described = in point 2.
  4. The = ability to verify a destination PSAP URI as a valid emergency URI could be = supported by reference to a relatively static table maintained by global cooperation. In fact, I would have thought that filtering based on = domain name would be extremely reliable and fast. It would certainly = obviate the ability to make arbitrary calls by pretending they are emergency = calls.
  5. Perhaps a = later revision of LoST can include the reverse-lookup mechanism and, = perhaps by then, the international infrastructure of LoST servers, forest = guides, etc. may be in place.

 

I mention point 4 as one possible way to = protect the interest of the VSPs without requiring a change to the current LoST = definition. Are there any other proposals on how to achieve this or, alternatively, = a view that it simply isn’t possible?

 

Cheers,

Martin

 

Martin Dawson

Andrew Network Solutions = Asia-Pacific

Email: martin.dawson@andrew.com

Phone: +61 2 42212992

Fax: +61 2 42212901

Mobile: +61 412 120300


This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have = received it in error, please notify the sender immediately and delete the = original. Any unauthorized use of this email is prohibited.

 

 


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

 

 


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

 

------=_NextPart_001_012C_01C7AD30.20C734B0-- ------=_NextPart_000_012B_01C7AD30.20C734B0 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABfAPYDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1v7DZ /wDPpB/37X/Cj7FZ/wDPpB/36X/Cmahc3FrZvLa2jXcwwFiVgMk+57VxHiiLxQ+m+fe3SQrJIscd lZ5JYn1PU0m7HVhsP7eSTklfudlM2j28PnTfYo4/7zBAKxf+Es8KG5aEGAqqljKYAE47Djk1xEOg wW+oWFn4i1JbCS8IFvbEF5GycduF59a3LGPwN4fuL5r7UUuLnT3AnEqMREScABQOeeM81Cc3sjsq UMBRupVHJ+R1OlX1hrEjm30krbqPluJYFVZD6AHmtT7DZ/8APpB/36X/AArGXxx4ZGsDRzqkcd7u EYiZGUbjjAzjGeRTbfx94audXbSk1Efa1kaLa0bAF16gMRjPFaJM8ucot+6rI2/sVn/z6Qf9+1/w o+xWf/PpB/37X/Cudh+I/he4t5biO+kaGJlV3+zuACx2gZx61YHjvw41ylul/wCZK90bRUSJiWlG MgcdOevSnZkXRtfYrP8A59IP+/a/4UfYrP8A59IP+/a/4VNS0hkH2Kz/AOfSD/v2v+FH2Kz/AOfS D/v2v+FT0UAQfYrP/n0g/wC/a/4UfYrP/n0g/wC/a/4VPRQBB9is/wDn0g/79r/hR9is/wDn0g/7 9r/hU9FAEH2Kz/59IP8Av2v+FH2Kz/59IP8Av2v+FT0UAV2tLFFLNbW6qOpMagD9Kgtzo92zLbfY ZivURhGI/Ks+/t11nxGNOuvmsrS3Wd4c8TOxIG71AA6etRauPDFpcRrcslhc25V0lgjKMg9NyjGD 0IrRQ+8ydRrXobv2Kz/59IP+/S/4UfYbP/n0g/79L/hWZe+IfJvfsdjafbJVjWSQmZYlVW6DLdSf SlHiW3msLW4tIJbia7dkit1wG3L94E9ABjk0uSRXtI9zS+xWf/PpB/37X/Cj7FZ/8+kH/ftf8Ko2 utNJJcW95ZPaXcEXnGIuGDp6qw688e1Z8Hi24nSzcaHcD+0FzafvV+c4yd390Yyc+goUJMTqxRvf YrP/AJ9IP+/a/wCFH2Gz/wCfSD/v0v8AhWYPEsSaTLez20kc0M/2Z7YMC3m5ACg9Ocjn0qOLxDJO bi0lsjb3q27TRRrOriQD0YdCDjrQoSD2sDX+w2f/AD6Qf9+l/wAKPsVn/wA+kH/ftf8ACue07xBe QaBpTT2EtxdXh8uMeauXO3O4nsDitESRv4gsjPbSR3r2bsMS5RBkZUgcE5PWhwa3BVItaGh9hs/+ fSD/AL9L/hSfY7IEA2tvk9B5a8/pWWnieN50svscv9omfymtNwyi9fMJ6bMc5/Csu6iZ9Q33MwTa 3+kAt8+dxxsHUjbtxj1701B9ROqump1P2Kz/AOfSD/v0v+FFFl532GD7RnzfLG/Priis27GqZJ5k f/PRP++hRviyMunHT5hxXjl1fzx6jOgcgBzgVuaPdF4fnwx98Vs6TSuZe01DW/AOta14pk12TVrB WS6ia3iOTsiQ5A3dj7AYOaoXfwmvb7VpNSn1S082fUWnnUO21oSwIXp97r7Ve1SXywjA4GD0+tYE l5LNcYEjAZ7GlGLZHtE3axtf8K21W61y4nvtV09bGbUPtxSMEykjOxdx6D1qDS/hhqljfte3Gp2F y7JOyq0jbYp3BCyLxzjvmtDQmJlO87vl7jNdN+5AzsT/AL5FDTWlzSPKzi7P4Zanb+DtR0R9Q04T 3DxPDKsjkAqxJ3Z6dewqbw98MJ9B8QDVI9Ss5fIhH2dXJbExUBnI9PvY/CuneeIMAI4z/wABFIZY /tZGyPHptFK0g0udKkq7F3yx7sDOGGM0vmx/89E/76FYUqxbf9Wn/fIrA1S3LD5OMv2wO1EYczKb sd75kf8Az0T/AL6FJ5kf/PRP++hXAG0f7B3z61NpCG3glmlXzAilsNjsKp0rK9xc53Pmx/8APRP+ +hR5sf8Az0T/AL6Fchaa7p04G6EJ7hAwqxqGr2Fnpz3MKQysOFTaBk1Eo8quwU7uyOn82L/nqn/f Qo82L/nqn/fQrkvC2qTauZo72zgRk5R1jADCukW3g/54Rf8AfAqVZq6KbsWfNi/56p/30KPNi/56 p/30KUWtvj/URf8AfAo+y2//ADwj/wC+BSGZWp2Lz3cWo6deQ297CpTMhykqE52sOvXkEdKqXFpq 2sxi11KewtLMkecttIXeYA525IG0H866D7Lb/wDPCP8A74FH2W3/AOeEf/fAqlNoh00zm9T0Vm1a S/tINMu1njVHivDjYV4DKQDxjqPapP7IuLe1sZbS5shfWZclQoSGQP8AeXA6dufaug+y2/8Azwj/ AO+BR9lt/wDnhH/3wKftGT7KJiQWV3c3U9/qM1ok72zW8MUMhKxg8klj1JOO3amW+lSwx+H1a4ty dLQrNh/vfutny/j61vfZbf8A54R/98Cj7Lb/APPCP/vgUudj9nE5y40A3NjfxNc23mTagbyDd8yd FwHH4EH607TdMliuJbieDSrPMLRpHaAEkn+IsQCB7Cuh+y2//PCP/vgUfZbf/nhH/wB8Cn7SVrC9 lG9zCttKkhtdDia4gzpxzLh+G+Ujj8TVye2L67BqCSwlIraSLaXwSxII/DitH7Lb/wDPCP8A74FH 2W3/AOeEf/fApczK5FaxzS6JeJcLrAv4G1gyfvMufJaL/nl64A5BxnNdFugLBmaIsOhJBI/Gn/Zb f/nhH/3wKPstv/zwj/74FDk3uEYKOwnmxf8APVP++hRS/Zbf/nhH/wB8CiosWeLX0WdWn/3zWpp8 UygbYnx6hDVp5FMZu/8AUGQ4CQINzE9gepP40+b/AEWB7h5ppAmCAHyTnpXdzp6HM49SDWI2FnGW BBweox3rmbZ8XB+td3p1ymr2YEjvGASu1mDfzqLV/Cuk2tqb3zGhf+9kBCT0yPr6VN7CjEp6RJtL t6JWq9/8nXtWNaq1nKIpo8hk5eM5VvUr7VvjR7WW1WWN5iWxxxxRJX1Ki+hnrclmzmpZrjZeZz3q oIZEnZfs7hQepPXn19alnALb8kE84pS91alJOWxtCfzEXnrUjWfnRrx3rlW8SS2pKiCJsdNxNTwe O7tYyDY2/HfLf40lGT+EptLc6s2A+zbMVUktfs2nXJx/yzb+Vc6vxCv2k2fYLYZ92/xqzN4pu7u0 nhe0gAaJskE/3TT5Kii20F4t6FGw8J6b9oV8yxfvAxMUpGc/w+5qHXRZ2+py6ZZah9oaIjzonbcY ie2R+VUW8af8I7pPm7g92yYgiABBPck8dKxvhmLi+8SXl5OpcSgvJM3RWJznNZVpqUUkTSpNT1PU /DivDbx2uwKduV4wVI7GrttqjSXL275jnUnMUq4bHqPUe9ePa18Q9UmN3bWEiwRFmjWdf9YyA4zn tnrxWv4I8UXd/d6ZDevNdTws6CZjuJRgOCe+MVpCHQK1VN+6e0joKWkHQUtcxsFZ2p6xFpbRLNBd SecwVTDCXG49Bx0NaNVb2xS+EG92XyJ1mGO5XtQBBZ65p95DPItykZtnZJlkcBo9rFfmGeOnerE9 /bQ2YuzKGibGwx/NvJ6BcdSe2KzLvwva3cTRyTPgmQjKgjLzLLyO4DKBj0qwuhwppMOno5QQEPHI qgbXB3BgOnXtQBPFq1o0Uckzm1MknlrHcjy2LegB6/hSjV9MaYwDULUyiTyygmXdv/u4z146VRuv D8l9EgutRlkk2vHI4jUb42KkqBj5furz16+tEnhq3dWBnkG5ZAcAfxzeae3rx9KALUmt2AZFhuY5 y04gYQuG2Mc/e546GkbXdMS4toDfQF7pmSLbICGZcZGfXkVm2XhTaga8vGkkWQlRGoVVTe7Bff75 5pLfwbZ2tottHMygFgxRFXcjJsKn324560AbMmp2aadPqCzrNbwIzu0J38KMnGOp46VUt/EulXLS 7LtVWGKOWR5PlRQ+do3HjPHI6jio7Tw5b2WiXWmRyYW6Vld0jVSMrtyAO+AOtE3hu2MxmtJTaygq 6lFBCuGdi2D1z5jcfT0oAnXXLFrq7tRcJ51qgcoZFBZdobcMnpg9TxUtvq1nOdpmWJzM8KpIwDOy HBwM89Ky/wDhEIAjQC8m+zGPYse1cq3kmHduxk/KTx0zT5PCdm+oQ3jSFnjkaTDIrdZDIAM9MMet AG/RSDpRQB5mYPLVp3bMdsAqIgyyuRyx7cf1pIY7WSAAQyM7MA7NJyQOAOBjFRxRy3UZWCDELZEY DYI5yc+uf6CqxubmCfy9qRgHADOqn8ic10wptq63OOrVjDcyPFNzBp+tRxQ3ctlIIVYBl3RHOepX kfkapr4mvVYWOtkz206/IdwKEeqEcVe8R6WdRvkurgFGMQUA9wPSqll4We5srhFPmWoG503fMh/v p7j9RwafLUjqVGcJLQ0NFW5s9Rh0+e7MmmP+8t2CZbP1HIIB+hr0O3nit7aKJnViwGM8ZHrXCaJ9 r0XSt+pKoisZNn2huhVuhHfB4/OrM3inSZypk1CJDEcqSSAVPUfh1/Omo3Wg767HcCO1kI2lCa52 +mgMpiUksOOBxWXD4u0SzugW1eAMOMEnj8xWU/ibSzqZnOs24j3FlK559jxXNzSbdzoStsP1Oxn8 wkYGfXiobexeKHdPNGilupbqfb1qxP4p0S6kAbUoAT/EoO0/pxVU+b4gMj6Oz3KW7bXAIIQnpj2N dFOo7GVRPsW4NPSe4DLcwHnpuxW1YWTWt2kbiGWU5xCzcOcHAPsaoWGiauY0ZrOTjqcVNptpNb+I o5pVIERBIzk9DW0qnu2uZxiyp490ee8h0ltTmt4ovtaxGK2jCpCrjH3jyeQKxfFmvadoek/8Iv4f ZMv/AMfs0bZ4/uZ7k9/yrf8AE2oy3Tzo8QZUXlMZCj/GuCuNBtLqQGzdomc524yprCdL3rrcVOva LTLHg3TIr65nvbgL5NmoYoRnzCeMVt/Dqe207xNPZ3KglJDsH48EVf8AC2kWGm2k1tJc+ZNu2zKw wOVyMVc0/wAMWA1l55lLTXCFYpQxAVsfKR75FbyShBP7zGN5z5F8j1lTkA+1OqtFcxLJHZtJ/pHk +ZtxyVGAT+ZqwTivPPRMG68Q/YrvVYZJIpJbfY1vblgrMpQEnHUgHJJ9Aahi8TzO9urx2yq+7dJv YrNhtv7rAO49/p+db8lzBHIEZh5m3eEAyxXIGcDnqRUnHp09qAOLbxdf3Q8yOO3ihieRJcvzIPL3 oARna/UYPOe1XH8U3aGeOO1iZo1GxWcllOUAL8fdbfkeu011GRnGP0pGdUVnbgKMk47UAZD6ldS6 BcXAeG1uIZHiZ2PyAq+0kEjgHBwSCBnJyBWdH4nnit7XH+lCRmy8u1WkwwXahT5Xb5s5HBAPvXTw zxXNvHPE2+OVA6NjqCMg07gduntQByUXiS7gtFtfkkvJTthaVuZMtJyFA5C7F6etMh8VXkdiJpI7 eWbau+TzCIyfL3FV44Yn5QPXNdjx1xUUdzBLPLAjBpICPMXH3SRkfpQBk6frd1d6o1tNbJHC7SiJ lJ3Dyyud2Rjnd29KzU1zUbDzZLlYpmlupwgLsAVjk2CNBj75HIHfBNdbkUcHGRQBmWOpXM9ndXlz CkcMTyiNYtzuyozKSRjqduQBXPp4kv8AUVhkXEBSQxuIXDo/7225BGf4ZGHX1rsUkWRdyhgOeqkd D70oIA4GPwoAWiiigDza3kl0vwpLfXSBbhAwAXquTx+PNcXaade3iPPHaSzAklmVc810niLURdeE 7OcMQbnarr6Fc5zVTRtUSys0WVGZYmLIFA5zzyeo5HWvXoqUabkkfPYlxlUUW9COGQLDDazE+Q4w QeqH+8PTH8q0dDheFZ0ByVBVxnv0rK1K3urowJEMPPiQkfwqT1PpxzV3wvZyTa+90kuY2nLbWBGV z3/Cs5zu9jvow5YoXXZs/D+6BXB3qgY9eGBH868ru4migaWSRnYdB717D4ytoW8IXaRYAZ0IQ9SQ wBNeZT2CvayRswGV6DrkNiphBygz0KeqN6T4R6hLpw1GXWrYmSIOFIO7JAOK4hraXTL+Wxu0BdOm On1FexyXmpLYO0NxGLWCBQgYhucAZAI4/WuIbwve+IfELTmZHESj7QzP0/uqOOWIrwsPiZ+0fO9D 0qmGSheO5ybN1xxXpXwjJOn6yoHLSRDPpw2K85mAjZlIwynBFemfBpW+y6xIo5WSLOT04NepX+Fs 5IL3j1OHTYBaCKUFgRzg4zXPP4Y/smW8vbOdVRgXRCpJQ4/XmtR/ElpBMIZg4bIGVBIzUmp3Ulto uoXJUN5ETsoPfArkg1JryCcJQTueZX0oZvsURJkwXkJPJPXmqOkWYaX7QVyFGfbNYsN9LEJbwkmW UlixPr1rZsNchaxX7PGyoUG4t13d/wAK9BVU53fQ8nk0HW87LdyyHC/6SM88noK6N75oYQNp3QNu BFctYW5u9JuryP5tkjkn3ABrtIbCO5jV2OPMUEH1yKdOfNCzFKNppo6zVdHm1SVLmOSIDyFQxyA7 Xw6vhsfwkDBqsnhu8iaMi6gd1txGs0iMzQkBuEGcbTuHX0HBro4hiJB6KKfXCekcbD4LnjjjJmt/ OXzEVjuYxIzKwCt16qfT7xq0PCskk8huZoZIXnV3QqT5wDlvnz1PIX6CuooxQBz8vh+eXQvsJ1CZ pfKSM/ORGwVgcY6jIG0nng9Khh8LPG8MgnTzoY4UVzuZlVWcuoJ5wQ4H0H4V01UdW1OPSrI3DRPM xO1Yo+XfucDvgAn6A0Ac9N4PuE0Y6daXMMSMkQ2AFV3qhUsMdCWw3HXFWG8LTZnkS8RZrgOJZADm QFUADHuBtP8A31VgeK7TMjtbzi3VNyTfL85ESy425yPlYde9TWGsSvp9/eX8It/ss7p5ZYZAAGAS OCTn9aAM+LwrcDU4bw3EcAjj2iO3Z1WH73CDPIO4eg4HFWtE0CbTLW+ikaANc7QPs5ZM4TbuJ6hj 1JFJD4rhnMOLG5RWO2UuAphJk8oAgnJ+b0HvUMviovBHKltJb7j5h8zaxaIxysGXBxnMR4P9aAIo vCVyjaYz3aYs2J2Rkoo+cMCMY3HAwScZzzVmHwssVpaxLNtkV2+1Ouf9IQnJU557L9AMCpj4jRIZ pPsszpGdiNlQZpBgFAuc559OaqQeLBPOXa1lhs/3bJNwWYNGzkMucjG0/lQA5/DV00hP2qMl1kUT EN5luWeRsx4PUhwD/ujr0qO18LXFvBYIs0Y+zXBmbczSKB8vCqwxk7Tzxt3Ejvmw3iuONNzWFxuU M8qbk/doqK5brz8rA4HNaFpq8V1fXNr5bRfZ8cykKXBOAQvXaTwD0PagDRHSigdKKAPG1YLbKjxJ JA+d0TD5Sev4H3qe3Gnx7QVkEfVomUHPtkEcVpLoUt1p2+2QtkbtrMAy/wBKoDSr1Yy0kK7hwfmF X7dxTVyVhYzcXYpazrLfMIYivnJtklbG4j0AHAHHSptDvpbaKWWNPMO35UHG4ngfz/Kq7+HdS1KQ RxwoqEDMjOPl5/OmiCQamfDNozh05vpyQCVAztXnpz+NdMZJU0zKpC1ZpbJl/XNQGqeH79gwaOEI uVHBO4cj8f0rmtK0a41XmFIkjQ/PJIeOV6YHXnmul1uwGmeDLmJVIQyJkkgljn/61Yvhu9ZBLAD8 uQw/lWsJShQbW5vTStoSapp17p+htFbyTXcUDCFnSAOS+AenXisfwJLqt7rLIb2Wzt1nE8o2YaY9 NuT2x2rpLnUCLWwCPJGRevI5jbaSobH58YrOkuAt+18GKysSAw6rk9vSvKnSjq1uzrjWk7X6HPax od5f65qMsMJ8wytKYiApCk8EV2PwfJcaujsqYaJSrcdAa5y7Fx9rYRSku6l0J6HHVW9a6D4VtGV1 aclm3yx4IGOxzXRF3hy2MJaO56K3yNtV4AMjg1dkAngeGRo5EcsrKwyCD1zWdJPaeapMByWAFaKN B5xAi5JqY6MiTbRjz+GdOazKxWWno/8ACTCv+FYOp6Vb2mmF4V01GUc4iXn9K7yQQiLHl9KxdTit J7dg1pG/GGDDt7e9bQepk4qx5/LqEtlbPBBJaRQmLeyRoAGJHPGK59/GWopuWPVJY1QYRcAgD0HF b2sR2AkkiiiG7ygu4DA6cVxFxoc26QxhSvbmuirGSiuVGcY3Wp9QWpLWkLE5JRT+lTVlW2t6clrC pueRGoPyN6fSpf7d03/n5/8AHG/wrzzoNCis/wDt3Tf+fn/xxv8ACj+3dN/5+f8Axxv8KANCq91Z W19AYLuCOeInOyRdwqv/AG7pv/Pz/wCON/hR/bum/wDPz/443+FAEw02yVQotYQo6Dyxj7u3/wBB AH04pINMsba0a0gtIY7ds7olQBTnrkVF/bum/wDPz/443+FH9u6b/wA/P/jjf4UAMi8PaVDdxXMV lEjwIViAUbUyxYkDsST1p1noOmWNqLaCzi8sHJ3KCWOCCSe5wSPxNL/bum/8/P8A443+FH9u6b/z 8/8Ajjf4UAPfR9NkaVnsbdmlUK5MY+YDoDSppOnRNE0dlAphUJHiMfKo6AfnUf8Abum/8/P/AI43 +FH9u6b/AM/P/jjf4UASR6Tp8UXlR2UCJhhtEYxhvvfn3pw02zUyEWsQMrB5DsHzEHIJ+hAqH+3d N/5+f/HG/wAKP7d03/n5/wDHG/woAv0VQ/t3Tf8An5/8cb/CigD/2Q== ------=_NextPart_000_012B_01C7AD30.20C734B0-- --===============1048161888== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1048161888==-- From ecrit-bounces@ietf.org Wed Jun 13 03:38:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyNQc-0000Pe-J0; Wed, 13 Jun 2007 03:38:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyNQb-0000PP-AV for ecrit@ietf.org; Wed, 13 Jun 2007 03:38:05 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyNQZ-00014V-RX for ecrit@ietf.org; Wed, 13 Jun 2007 03:38:05 -0400 X-SEF-Processed: 5_0_0_910__2007_06_13_02_45_42 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 13 Jun 2007 02:45:42 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jun 2007 02:38:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Wed, 13 Jun 2007 02:37:59 -0500 Message-ID: In-Reply-To: <012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives Thread-Index: AceqV4ZeonTtWSgmTEKwTanATYJDUQCpIGKwAA63d4AABo3GsAAO+O4A References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com> <012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , X-OriginalArrivalTime: 13 Jun 2007 07:38:02.0816 (UTC) FILETIME=[C60E2C00:01C7AD8D] X-Spam-Score: 0.2 (/) X-Scan-Signature: 19fc2b47780353ba1ee25032fbc339e7 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0921290566==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0921290566== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C7AD8D.C5A8C8A5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7AD8D.C5A8C8A5 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7AD8D.C5A8C8A5" ------_=_NextPart_002_01C7AD8D.C5A8C8A5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I wasn't suggesting they were an identical level of definition. I was=0D=0A= saying that it's still not definitive solution; of course it's a matter=0D=0A= of degree. Without a definitive forest guide solution, how does a VSP=0D=0A= know how to find the right LoST server to find the PSAP URI=3F At least=0D=0A= with option 3, the PSAP URI is provided at the point of local knowledge=0D=0A= where the applicable LoST server is known.=0D=0A=0D=0A=20=0D=0A=0D=0APull y= our last comment apart for me... are you saying that the "forest=0D=0Aguide= " implementation requires changes to LoST=3F Without those changes,=0D=0Ath= e Forest Guide won't work either=3F=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D= =0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A________________________________=0D=0A=0D= =0AFrom: Brian Rosen [mailto:br@brianrosen.net]=20=0D=0ASent: Wednesday, 13= June 2007 10:28 AM=0D=0ATo: Dawson, Martin; ecrit@ietf.org=0D=0ASubject: R= E: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D= =0AI'm sorry but the forest guide idea is a whole lot more developed that=0D= =0Aany notion of an authoritative list of PSAP URIs. I'm not saying it=0D=0A= can't be done, I'm saying we need a whole lot more work on it to make it=0D= =0Areal, and it's not at all clear to me that the reverse lookup idea has=0D= =0Amore or less merit. However, both of them are beyond what I think is=0D= =0Aappropriate for LoST at this point.=0D=0A=0D=0A=20=0D=0A=0D=0ABrian=0D=0A=0D= =0A=20=0D=0A=0D=0A________________________________=0D=0A=0D=0AFrom: Dawson,= Martin [mailto:Martin.Dawson@andrew.com]=20=0D=0ASent: Tuesday, June 12, 2= 007 5:19 PM=0D=0ATo: Brian Rosen; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0AWell = hand waving was about all I could invest in an email, but are you=0D=0Asayi= ng you'd just have to give up at that stage=3F What is a reference to=0D=0A= a "forest guide", if it's not a particularly low-detail suggestion of=0D=0A= the sort of thing we need to resolve the right LoST server=3F Yet, without=0D= =0Athat, option 1 doesn't work. Why wouldn't this "validation" be a=0D=0Afu= nction of that system and why is reverse lookup the only option=3F=0D=0A=0D= =0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A_____= ___________________________=0D=0A=0D=0AFrom: Brian Rosen [mailto:br@brianro= sen.net]=20=0D=0ASent: Wednesday, 13 June 2007 12:18 AM=0D=0ATo: Dawson, Ma= rtin; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3 - summary = of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0AI think those of us pushing for O= ption 1 for now is that we think VSP=0D=0Avalidation is a fact of life we h= ave to deal with, waving hands over=0D=0A"reference to a relatively static = table maintained by global=0D=0Acooperation" is not adequate, and something= like a reverse lookup is=0D=0Arequired. This would be a change to LoST an= d we are reluctant to take=0D=0Athis change on at this time.=0D=0A=0D=0A =0D= =0A=0D=0ABrian=0D=0A=0D=0A=20=0D=0A=0D=0A________________________________=0D= =0A=0D=0AFrom: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20=0D=0ASen= t: Tuesday, June 12, 2007 10:08 AM=0D=0ATo: ecrit@ietf.org=0D=0ASubject: [E= crit] Proposals 1 and 3 - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0A= For some reason this hasn't made it through moderation. Now I'm a list=0D=0A= subscriber, I'll try again...=0D=0A=0D=0A=20=0D=0A=0D=0AIt's a long weekend= in Australia and winter has finally hit - with cold=0D=0Awind and rain. Wh= at better time, then, to spend some time catching up=0D=0Awith the action o= n the ECRIT list. I only went back a couple of weeks;=0D=0Aobviously the ma= in topic has been to do with the question of how to=0D=0Adefine the "locati= on hiding" capability. Mostly it's a debate about the=0D=0Autility of optio= n 1 and 3.=0D=0A=0D=0A=20=0D=0A=0D=0AHaving just read through all the posti= ngs and while they are fresh in my=0D=0Amind, here is how I characterize th= e perspectives. First my summary of=0D=0Athe options...=0D=0A=0D=0A=20=0D=0A=0D= =0A*=09Option 1 achieves location hiding, somewhat oxymoronically, by=0D=0A= providing location. Whether it's by reference to the local LoST facility=0D= =0Aor by some internal knowledge, the LIS generates a coarse location which=0D= =0Ait knows will result in a correct PSAP URI resolution if/when another=0D= =0Aparty makes a request to the LoST facility. This is provided in addition=0D= =0Ato a location reference for subsequent accurate location requests from=0D= =0Athe PSAP for dispatch etc.=0D=0A*=09Option 3 achieves location hiding by= making the request to the=0D=0Alocal LoST facility using the end points lo= cation and providing the PSAP=0D=0AURI that the LoST service returns (in ad= dition to a location reference)=0D=0Aso the call can be routed to that PSAP= - whether directly from the=0D=0Adevice or via a proxy/VSP.=0D=0A=0D=0A =0D= =0A=0D=0ABoth suggestions are based on an assumption that a LIS, being asso= ciated=0D=0Awith the local jurisdiction, has enough local knowledge to iden= tify the=0D=0Acorrect LoST service for that jurisdiction or, at least in th= e case of=0D=0Aoption 1, to determine what "coarse location" isn't too coar= se.=0D=0A=0D=0A=20=0D=0A=0D=0APerspective 1 - articulated by a lot of peopl= e, Ted, Brian, Andy,...=0D=0Aetc. is that LoST needs to progress and get to= a first release and=0D=0Achanges associated with this particular use case = should be avoided for=0D=0Anow. I haven't seen anything in either proposal = that does require a=0D=0Achange to LoST. In the one case either or both of = the LIS and VSP/proxy=0D=0Amake LoST queries but neither options appears to= *dictate* a specific=0D=0Achange to LoST.=0D=0A=0D=0A=20=0D=0A=0D=0APerspe= ctive 2 - articulated by, for example, James W and Barbara is that=0D=0Athe= LIS operator should have the option of providing location or not - a=0D=0A= "coarse location" is still a location and location information to the=0D=0A= granularity of PSAP boundaries, for example, could still support a lot=0D=0A= of value-added services and be used for other than emergency services.=0D=0A=0D= =0A=20=0D=0A=0D=0APerspective 3 - articulated by, for example, Andy and Lau= ra is that,=0D=0Awhen the end-point initiates a call through the VSP/proxy = with a=0D=0Apre-determined PSAP URI, the proxy may not know that this reall= y is a=0D=0Agenuine emergency call destination. In fact it could be used to= call=0D=0Aanyone by just pretending it's an emergency call. This means the= VSP may=0D=0Alose call revenue through the fraudulent nomination of emerge= ncy calls.=0D=0A=0D=0A=20=0D=0A=0D=0APerspective 4 - articulated by, in par= ticular, Hannes (sorry Hannes, I=0D=0Acan't see anyone else emphasising thi= s point) is that all emergency=0D=0Acalls should go through a VSP so that t= here's an authenticated=0D=0Asubscriber identity to be associated with the = call. This seems like an=0D=0Aorthogonal point to me. If we accept that som= e calls will go through=0D=0AVSPs and therefore Perspective 3 is valid then= the question of whether=0D=0Aall emergency calls have to go through a VSP = is moot. I have to admit to=0D=0Abeing really surprised by the perspective = - it wasn't one that I thought=0D=0Ahad any currency in this forum.=0D=0A=0D= =0A=20=0D=0A=0D=0A=20=0D=0A=0D=0AThere were miscellaneous other perspective= s including some good=0D=0Asuggestions for alternatives/compromises from Ri= chard and Henning.=0D=0A=0D=0A=20=0D=0A=0D=0AMartin D's perspective -=0D=0A=0D= =0A=20=0D=0A=0D=0A*=09On perspective 1, I don't see any impediment to pushi= ng LoST=0D=0Aout. Even if there are changes to come, they can be done in a = revision=0D=0Aor whatever. But I haven't seen any definitive statement abou= t how=0D=0Aeither option *requires* a change to LoST.=0D=0A*=09On perspecti= ve 4, I don't think it's decisive in the discussion.=0D=0A*=09So, really, i= t boils down to an evaluation of which of=0D=0Aperspectives 2 and 3 are the= most valid - i.e. are the interests of the=0D=0ALIS operator or a VSP to h= ave priority.=0D=0A=0D=0A=20=0D=0A=0D=0AI don't understand why the interest= s of LIS operators and VSPs can't=0D=0Aboth be served. I'm surprised that w= ith all the experience and knowledge=0D=0Ain the forum that nobody can prov= ide a practical way for a proxy/VSP to=0D=0Adetermine whether a PSAP URI is= a valid emergency destination or not. I=0D=0Aknow that adding the reverse-= lookup to LoST has been discussed. That=0D=0Awould be effective, but it's n= ot in keeping with perspective 1. Surely,=0D=0Athough, there are alternativ= es.=0D=0A=0D=0A=20=0D=0A=0D=0AI think option 3 supports a faster and smooth= er deployment of global=0D=0Aemergency calling for VoIP. Here's my rational= e.=0D=0A=0D=0A=20=0D=0A=0D=0A1.=09Both options require a LoST and LIS capab= ility to exist at a=0D=0Alocal and jurisdictional level - so their availabi= lity is a premise in=0D=0Aeither proposal=0D=0A2.=09Option 1 assumes that e= ach VSP can make an effective LoST query=0D=0Aeven if it is a "non-local" V= SP to the point from where the call is=0D=0Abeing originated. This is eithe= r by the VSP automatically knowing which=0D=0ALoST server is applicable to = the coarse location or by the use of the so=0D=0Acalled forest guide and pe= rhaps some international hierarchy of=0D=0Ainterconnected LoST servers.=0D=0A= 3.=09Option 3 only assumes that this local knowledge is in the local=0D=0AL= IS function and doesn't rely on the existence of the infrastructure=0D=0Ade= scribed in point 2.=0D=0A4.=09The ability to verify a destination PSAP URI = as a valid=0D=0Aemergency URI could be supported by reference to a relative= ly static=0D=0Atable maintained by global cooperation. In fact, I would hav= e thought=0D=0Athat filtering based on domain name would be extremely relia= ble and=0D=0Afast. It would certainly obviate the ability to make arbitrary= calls by=0D=0Apretending they are emergency calls.=0D=0A5.=09Perhaps a lat= er revision of LoST can include the reverse-lookup=0D=0Amechanism and, perh= aps by then, the international infrastructure of LoST=0D=0Aservers, forest = guides, etc. may be in place.=0D=0A=0D=0A=20=0D=0A=0D=0AI mention point 4 a= s one possible way to protect the interest of the=0D=0AVSPs without requiri= ng a change to the current LoST definition. Are=0D=0Athere any other propos= als on how to achieve this or, alternatively, a=0D=0Aview that it simply is= n't possible=3F=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D= =0A=20=0D=0A=0D=0A Martin Dawson=0D=0A=0D=0AAndrew Network Solutions Asia-P= acific=0D=0A=0D=0AEmail: martin.dawson@andrew.com=0D=0A=0D=0APhone: +61 2 4= 2212992=0D=0A=0D=0AFax: +61 2 42212901=0D=0A=0D=0AMobile: +61 412 120300=0D= =0A=0D=0A=0D=0AThis message is for the designated recipient only and may co= ntain=0D=0Aprivileged, proprietary, or otherwise private information. If yo= u have=0D=0Areceived it in error, please notify the sender immediately and = delete=0D=0Athe original. Any unauthorized use of this email is prohibited.=0D= =0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A=0D=0A------------------------------= ------------------------------------------=0D=0A------------------------=0D= =0AThis message is for the designated recipient only and may=0D=0Acontain p= rivileged, proprietary, or otherwise private information. =20=0D=0AIf you h= ave received it in error, please notify the sender=0D=0Aimmediately and del= ete the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D= =0A------------------------------------------------------------------------=0D= =0A------------------------=0D=0A[mf2]=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D= =0A=0D=0A------------------------------------------------------------------= ------=0D=0A------------------------=0D=0AThis message is for the designate= d recipient only and may=0D=0Acontain privileged, proprietary, or otherwise= private information. =20=0D=0AIf you have received it in error, please not= ify the sender=0D=0Aimmediately and delete the original. Any unauthorized = use of=0D=0Athis email is prohibited.=0D=0A--------------------------------= ----------------------------------------=0D=0A------------------------=0D=0A= [mf2]=0D=0A=0D=0A=20=0D=0A=0D=0A-------------------------------------------= -----------------------------------------------------=0D=0AThis message is = for the designated recipient only and may=0D=0Acontain privileged, propriet= ary, or otherwise private information. =20=0D=0AIf you have received it in = error, please notify the sender=0D=0Aimmediately and delete the original. = Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A---------------= ---------------------------------------------------------------------------= ------=0D=0A[mf2]=0D=0A ------_=_NextPart_002_01C7AD8D.C5A8C8A5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A
=0D= =0A=0D=0A

I wasn̵= 7;t suggesting they were an=0D=0Aidentical level of definition. I was sayin= g that it’s still not definitive=0D=0Asolution; of course it’s = a matter of degree. Without a definitive forest=0D=0Aguide solution, how do= es a VSP know how to find the right LoST server to find=0D=0Athe PSAP URI=3F= At least with option 3, the PSAP URI is provided at the point of=0D=0Aloca= l knowledge where the applicable LoST server is known.

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

<= o:p> 

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

Pull your last comment apart for me…=0D=0Aa= re you saying that the “forest guide” implementation requires=0D= =0Achanges to LoST=3F Without those changes, the Forest Guide won’t w= ork=0D=0Aeither=3F

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

 

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

Cheers,

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

Martin

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

 =

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

From:=0D=0ABrian Rosen [mailto:br@brianros= en.net]
=0D=0ASent: Wedn= esday, 13 June 2007=0D=0A10:28 AM
=0D=0ATo: Dawson, Martin; ecrit@ietf.org
=0D=0ASubject: RE: [Ecrit] Proposals 1=0D=0Aand 3 -= summary of perspectives=

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

 <= /span>

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

I’m sorry but the=0D=0Aforest guide idea is a wh= ole lot more developed that any notion of an=0D=0Aauthoritative list of PSA= P URIs.  I’m not saying it can’t be=0D=0Adone, I’m s= aying we need a whole lot more work on it to make it real, and=0D=0Ait̵= 7;s not at all clear to me that the reverse lookup idea has more or less=0D= =0Amerit.  However, both of them are beyond what I think is appropriat= e for=0D=0ALoST at this point.

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

 <= /o:p>

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

Brian

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

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

From:=0D=0ADawson, Martin [mailto:Martin.Dawson@andrew.com]
=0D=0ASent: Tuesday, June 12, 2007 5:19=0D= =0APM
=0D=0ATo: Brian Ros= en; ecrit@ietf.org
=0D=0ASubject: RE: [Ecrit] Proposals 1=0D=0Aand 3 - summary of perspectives

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

 

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

Well hand w= aving was about all I could=0D=0Ainvest in an email, but are you saying you= ’d just have to give up at that=0D=0Astage=3F What is a reference to = a “forest guide”, if it’s not a=0D=0Aparticularly low-det= ail suggestion of the sort of thing we need to resolve the=0D=0Aright LoST = server=3F Yet, without that, option 1 doesn’t work. Why=0D=0Awouldn&#= 8217;t this “validation” be a function of that system and=0D=0A= why is reverse lookup the only option=3F

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

 =

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

Cheers,

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

Martin

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

 =

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

From:=0D=0ABrian Ros= en [mailto:br@brianrosen.net]
=0D=0ASent: Wednesday, 13 June 2007=0D=0A12:18 AM
=0D=0ATo: Dawson, Martin; ecrit@ietf.org
=0D=0ASubject: RE: [Ecrit] Proposals 1=0D=0Aand 3 - s= ummary of perspectives=0D=0A=0D=0A

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

 <= /span>

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

I think those of us=0D=0Apushing for Option 1 for now = is that we think VSP validation is a fact of life=0D=0Awe have to deal with= , waving hands over “<= span style=3D'font-size:10.0pt;font-family:Arial'>reference to a=0D=0Arelat= ively static table maintained by global cooperation” is not adequate, and som= ething like a=0D=0Areverse lookup is required.  This would be a change= to LoST and we are=0D=0Areluctant to take this change on at this time.

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

 

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

Brian

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

 

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

From:=0D=0ADawson, Martin [mailto:Martin.D= awson@andrew.com]
=0D=0ASent: Tuesday, June 12, 2007 10:08=0D=0AAM
=0D=0ATo: ecrit@ietf.org
=0D=0ASubject: [Ecrit] Proposals 1 and 3=0D=0A- summary of perspectives

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

 

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

For some reason this hasn’t made it th= rough=0D=0Amoderation. Now I’m a list subscriber, I’ll try agai= n…

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

 

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

It’s a long weekend in Australia and winte= r has finally=0D=0Ahit – with cold wind and rain. What better time, t= hen, to spend some time=0D=0Acatching up with the action on the ECRIT list.= I only went back a couple of=0D=0Aweeks; obviously the main topic has been= to do with the question of how to=0D=0Adefine the “location hiding&#= 8221; capability. Mostly it’s a debate=0D=0Aabout the utility of opti= on 1 and 3.

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

 

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

Having just read through all the postings and while they are=0D=0A= fresh in my mind, here is how I characterize the perspectives. First my sum= mary=0D=0Aof the options…

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

 

=0D=0A=0D=0A=
    =0D=0A
  • Option 1 achieves location=0D=0A= hiding, somewhat oxymoronically, by providing location. Whether itR= 17;s=0D=0A by reference to the local LoST facility or by some internal = knowledge, the=0D=0A LIS generates a coarse location which it knows wil= l result in a correct=0D=0A PSAP URI resolution if/when another party m= akes a request to the LoST=0D=0A facility. This is provided in addition= to a location reference for=0D=0A subsequent accurate location request= s from the PSAP for dispatch etc.
    • =0D=0A
  • Option 3 a= chieves location=0D=0A hiding by making the request to the local LoST f= acility using the end=0D=0A points location and providing the PSAP URI = that the LoST service returns=0D=0A (in addition to a location referenc= e) so the call can be routed to that=0D=0A PSAP – whether directl= y from the device or via a proxy/VSP.
    • =0D=0A=0D=0A=0D=0A

     

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

    Both suggestions are based= on an assumption that a LIS,=0D=0Abeing associated with the local jurisdic= tion, has enough local knowledge to=0D=0Aidentify the correct LoST service = for that jurisdiction or, at least in the=0D=0Acase of option 1, to determi= ne what “coarse location” isn’t=0D=0Atoo coarse.

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

     <= /o:p>

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

    Perspecti= ve 1 – articulated by a lot of people, Ted,=0D=0ABrian, Andy,… = etc. is that LoST needs to progress and get to a first=0D=0Arelease and cha= nges associated with this particular use case should be avoided=0D=0Afor no= w. I haven’t seen anything in either proposal that does require a=0D=0A= change to LoST. In the one case either or both of the LIS and VSP/proxy mak= e=0D=0ALoST queries but neither options appears to *dictate*=0D=0Aa specific change to LoST.=

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

     

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

    Perspective = 2 – articulated by, for example, James W=0D=0Aand Barbara is that the= LIS operator should have the option of providing=0D=0Alocation or not R= 11; a “coarse location” is still a location and=0D=0Alocation i= nformation to the granularity of PSAP boundaries, for example, could=0D=0As= till support a lot of value-added services and be used for other than=0D=0A= emergency services.

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

     

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

    Perspective 3 – articulated by, for example, Andy = and=0D=0ALaura is that, when the end-point initiates a call through the VSP= /proxy with a=0D=0Apre-determined PSAP URI, the proxy may not know that thi= s really is a genuine=0D=0Aemergency call destination. In fact it could be = used to call anyone by just=0D=0Apretending it’s an emergency call. T= his means the VSP may lose call=0D=0Arevenue through the fraudulent nominat= ion of emergency calls.

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

     

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

    Perspective 4 – articulated by, in particular, Han= nes=0D=0A(sorry Hannes, I can’t see anyone else emphasising this poin= t) is that=0D=0Aall emergency calls should go through a VSP so that there&#= 8217;s an=0D=0Aauthenticated subscriber identity to be associated with the = call. This seems=0D=0Alike an orthogonal point to me. If we accept that som= e calls will go through=0D=0AVSPs and therefore Perspective 3 is valid then= the question of whether all=0D=0Aemergency calls have to go through a VSP = is moot. I have to admit to being=0D=0Areally surprised by the perspective = – it wasn’t one that I thought=0D=0Ahad any currency in this fo= rum.

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

     

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

     

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

    There were miscellaneous other perspectives including some=0D=0Agood= suggestions for alternatives/compromises from Richard and Henning.

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

     <= /o:p>

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

    Martin D&= #8217;s perspective –

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

     

    =0D=0A=0D=0A
      =0D=0A
    • On perspective 1, I don’t=0D=0A = see any impediment to pushing LoST out. Even if there are changes to co= me,=0D=0A they can be done in a revision or whatever. But I haven’= ;t seen any=0D=0A definitive statement about how either option *requires* a change to Lo= ST.
      • =0D=0A
    • On perspective 4, I don’t=0D=0A = think it’s decisive in the discussion.=0D=0A
    • So, really, it boils down to an=0D=0A evaluation of which of perspecti= ves 2 and 3 are the most valid –=0D=0A i.e. are the interests of = the LIS operator or a VSP to have priority.
      • =0D= =0A
    =0D=0A=0D=0A

     =

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

    I don’t underst= and why the interests of LIS operators=0D=0Aand VSPs can’t both be se= rved. I’m surprised that with all the=0D=0Aexperience and knowledge i= n the forum that nobody can provide a practical way=0D=0Afor a proxy/VSP to= determine whether a PSAP URI is a valid emergency=0D=0Adestination or not.= I know that adding the reverse-lookup to LoST has been=0D=0Adiscussed. Tha= t would be effective, but it’s not in keeping with=0D=0Aperspective 1= =2E Surely, though, there are alternatives.

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

     

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

    I think option 3 supports a faster = and smoother deployment=0D=0Aof global emergency calling for VoIP. HereR= 17;s my rationale.

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

     

    =0D=0A=0D=0A
      =0D=0A
    1. Both options require a LoST and=0D=0A = LIS capability to exist at a local and jurisdictional level – so=0D= =0A their availability is a premise in either proposal
      2. =0D=0A
    2. Option 1 assumes that each VSP=0D=0A can make an effecti= ve LoST query even if it is a “non-local”=0D=0A VSP to the = point from where the call is being originated. This is either=0D=0A by = the VSP automatically knowing which LoST server is applicable to the=0D=0A = coarse location or by the use of the so called forest guide and perhaps=0D= =0A some international hierarchy of interconnected LoST servers.
      3. =0D=0A
    3. Option 3 only assumes that this=0D=0A local kn= owledge is in the local LIS function and doesn’t rely on the=0D=0A = existence of the infrastructure described in point 2.
      4. =0D=0A
    4. The ability to verify a=0D=0A destination PSAP URI as a val= id emergency URI could be supported by=0D=0A reference to a relatively = static table maintained by global cooperation.=0D=0A In fact, I would h= ave thought that filtering based on domain name would be=0D=0A extremel= y reliable and fast. It would certainly obviate the ability to=0D=0A ma= ke arbitrary calls by pretending they are emergency calls.
      5. =0D=0A
    5. Perhaps a later revision of=0D=0A LoST can include the r= everse-lookup mechanism and, perhaps by then, the=0D=0A international i= nfrastructure of LoST servers, forest guides, etc. may be=0D=0A in plac= e.
      6. =0D=0A
    =0D=0A=0D=0A

     

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

    I mention point 4 as one possible way to protect the=0D=0Aint= erest of the VSPs without requiring a change to the current LoST definition= =2E=0D=0AAre there any other proposals on how to achieve this or, alternati= vely, a view=0D=0Athat it simply isn’t possible=3F<= /font>

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

     

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

    <= span style=3D'font-size:10.0pt;=0D=0Afont-family:Arial'>Cheers,<= /span>

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

    Martin

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

     

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

    Martin=0D=0ADawson

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

    Andrew Netw= ork Solutions Asia-Pacific

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

    Email: martin.dawson@an= drew.com

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

    <= font size=3D2 face=3DArial>Phone: +61 2 42212992

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

    Fax: +61 2 42212901

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

    Mobile:=0D=0A+61 412 120300

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


    =0D=0A    Th= is message is for the designated recipient only and may=0D=0Acontain privil= eged, proprietary, or otherwise private information. If you have=0D=0Arecei= ved it in error, please notify the sender immediately and delete the=0D=0Ao= riginal. Any unauthorized use of this email is prohibited.

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

     <= /span>

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

     

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


    =0D=0A = --------------------------------------------------------------------------= ----------------------
    =0D=0A This message is for t= he designated recipient only and may
    =0D=0A co= ntain privileged, proprietary, or otherwise privat= e information.  
    =0D=0A If you have recei= ved it in error, please notify the sende= r
    =0D=0A immediately and delete the original. =  Any unauthorized use of
    =0D=0A this email&nbs= p;is prohibited.
    =0D=0A ------------------------------------------= ------------------------------------------------------
    =0D=0A [mf2]

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

     

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

 

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


=0D=0A ------= ---------------------------------------------------------------------------= ---------------
=0D=0A This message is for the = ;designated recipient only and may
=0D=0A contain&n= bsp;privileged, proprietary, or otherwise private = information.  
=0D=0A If you have received&nbs= p;it in error, please notify the sender
=0D= =0A immediately and delete the original.  An= y unauthorized use of
=0D=0A this email is&nbs= p;prohibited.
=0D=0A --------------------------------------------------= ----------------------------------------------
=0D=0A [mf2]<= /span>

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

 

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


-------------------------------------------------= -----------------------------------------------
=0D=0AThis message&= nbsp;is for the designated recipient only and=  may
=0D=0Acontain privileged, proprietary, or = otherwise private information.  
=0D=0AIf you&n= bsp;have received it in error, please notify&= nbsp;the sender
=0D=0Aimmediately and delete the&nbs= p;original.  Any unauthorized use of
=0D=0Athis=  email is prohibited.
=0D=0A-----------------------------= -------------------------------------------------------------------
=0D=0A= [mf2]
=0D=0A=0D=0A=0D=0A ------_=_NextPart_002_01C7AD8D.C5A8C8A5-- ------_=_NextPart_001_01C7AD8D.C5A8C8A5 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABfAPYDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1v7DZ /wDPpB/37X/Cj7FZ/wDPpB/36X/Cmahc3FrZvLa2jXcwwFiVgMk+57VxHiiLxQ+m+fe3SQrJIscd lZ5JYn1PU0m7HVhsP7eSTklfudlM2j28PnTfYo4/7zBAKxf+Es8KG5aEGAqqljKYAE47Djk1xEOg wW+oWFn4i1JbCS8IFvbEF5GycduF59a3LGPwN4fuL5r7UUuLnT3AnEqMREScABQOeeM81Cc3sjsq UMBRupVHJ+R1OlX1hrEjm30krbqPluJYFVZD6AHmtT7DZ/8APpB/36X/AArGXxx4ZGsDRzqkcd7u EYiZGUbjjAzjGeRTbfx94audXbSk1Efa1kaLa0bAF16gMRjPFaJM8ucot+6rI2/sVn/z6Qf9+1/w o+xWf/PpB/37X/Cudh+I/he4t5biO+kaGJlV3+zuACx2gZx61YHjvw41ylul/wCZK90bRUSJiWlG MgcdOevSnZkXRtfYrP8A59IP+/a/4UfYrP8A59IP+/a/4VNS0hkH2Kz/AOfSD/v2v+FH2Kz/AOfS D/v2v+FT0UAQfYrP/n0g/wC/a/4UfYrP/n0g/wC/a/4VPRQBB9is/wDn0g/79r/hR9is/wDn0g/7 9r/hU9FAEH2Kz/59IP8Av2v+FH2Kz/59IP8Av2v+FT0UAV2tLFFLNbW6qOpMagD9Kgtzo92zLbfY ZivURhGI/Ks+/t11nxGNOuvmsrS3Wd4c8TOxIG71AA6etRauPDFpcRrcslhc25V0lgjKMg9NyjGD 0IrRQ+8ydRrXobv2Kz/59IP+/S/4UfYbP/n0g/79L/hWZe+IfJvfsdjafbJVjWSQmZYlVW6DLdSf SlHiW3msLW4tIJbia7dkit1wG3L94E9ABjk0uSRXtI9zS+xWf/PpB/37X/Cj7FZ/8+kH/ftf8Ko2 utNJJcW95ZPaXcEXnGIuGDp6qw688e1Z8Hi24nSzcaHcD+0FzafvV+c4yd390Yyc+goUJMTqxRvf YrP/AJ9IP+/a/wCFH2Gz/wCfSD/v0v8AhWYPEsSaTLez20kc0M/2Z7YMC3m5ACg9Ocjn0qOLxDJO bi0lsjb3q27TRRrOriQD0YdCDjrQoSD2sDX+w2f/AD6Qf9+l/wAKPsVn/wA+kH/ftf8ACue07xBe QaBpTT2EtxdXh8uMeauXO3O4nsDitESRv4gsjPbSR3r2bsMS5RBkZUgcE5PWhwa3BVItaGh9hs/+ fSD/AL9L/hSfY7IEA2tvk9B5a8/pWWnieN50svscv9omfymtNwyi9fMJ6bMc5/Csu6iZ9Q33MwTa 3+kAt8+dxxsHUjbtxj1701B9ROqump1P2Kz/AOfSD/v0v+FFFl532GD7RnzfLG/Priis27GqZJ5k f/PRP++hRviyMunHT5hxXjl1fzx6jOgcgBzgVuaPdF4fnwx98Vs6TSuZe01DW/AOta14pk12TVrB WS6ia3iOTsiQ5A3dj7AYOaoXfwmvb7VpNSn1S082fUWnnUO21oSwIXp97r7Ve1SXywjA4GD0+tYE l5LNcYEjAZ7GlGLZHtE3axtf8K21W61y4nvtV09bGbUPtxSMEykjOxdx6D1qDS/hhqljfte3Gp2F y7JOyq0jbYp3BCyLxzjvmtDQmJlO87vl7jNdN+5AzsT/AL5FDTWlzSPKzi7P4Zanb+DtR0R9Q04T 3DxPDKsjkAqxJ3Z6dewqbw98MJ9B8QDVI9Ss5fIhH2dXJbExUBnI9PvY/CuneeIMAI4z/wABFIZY /tZGyPHptFK0g0udKkq7F3yx7sDOGGM0vmx/89E/76FYUqxbf9Wn/fIrA1S3LD5OMv2wO1EYczKb sd75kf8Az0T/AL6FJ5kf/PRP++hXAG0f7B3z61NpCG3glmlXzAilsNjsKp0rK9xc53Pmx/8APRP+ +hR5sf8Az0T/AL6Fchaa7p04G6EJ7hAwqxqGr2Fnpz3MKQysOFTaBk1Eo8quwU7uyOn82L/nqn/f Qo82L/nqn/fQrkvC2qTauZo72zgRk5R1jADCukW3g/54Rf8AfAqVZq6KbsWfNi/56p/30KPNi/56 p/30KUWtvj/URf8AfAo+y2//ADwj/wC+BSGZWp2Lz3cWo6deQ297CpTMhykqE52sOvXkEdKqXFpq 2sxi11KewtLMkecttIXeYA525IG0H866D7Lb/wDPCP8A74FH2W3/AOeEf/fAqlNoh00zm9T0Vm1a S/tINMu1njVHivDjYV4DKQDxjqPapP7IuLe1sZbS5shfWZclQoSGQP8AeXA6dufaug+y2/8Azwj/ AO+BR9lt/wDnhH/3wKftGT7KJiQWV3c3U9/qM1ok72zW8MUMhKxg8klj1JOO3amW+lSwx+H1a4ty dLQrNh/vfutny/j61vfZbf8A54R/98Cj7Lb/APPCP/vgUudj9nE5y40A3NjfxNc23mTagbyDd8yd FwHH4EH607TdMliuJbieDSrPMLRpHaAEkn+IsQCB7Cuh+y2//PCP/vgUfZbf/nhH/wB8Cn7SVrC9 lG9zCttKkhtdDia4gzpxzLh+G+Ujj8TVye2L67BqCSwlIraSLaXwSxII/DitH7Lb/wDPCP8A74FH 2W3/AOeEf/fApczK5FaxzS6JeJcLrAv4G1gyfvMufJaL/nl64A5BxnNdFugLBmaIsOhJBI/Gn/Zb f/nhH/3wKPstv/zwj/74FDk3uEYKOwnmxf8APVP++hRS/Zbf/nhH/wB8CiosWeLX0WdWn/3zWpp8 UygbYnx6hDVp5FMZu/8AUGQ4CQINzE9gepP40+b/AEWB7h5ppAmCAHyTnpXdzp6HM49SDWI2FnGW BBweox3rmbZ8XB+td3p1ymr2YEjvGASu1mDfzqLV/Cuk2tqb3zGhf+9kBCT0yPr6VN7CjEp6RJtL t6JWq9/8nXtWNaq1nKIpo8hk5eM5VvUr7VvjR7WW1WWN5iWxxxxRJX1Ki+hnrclmzmpZrjZeZz3q oIZEnZfs7hQepPXn19alnALb8kE84pS91alJOWxtCfzEXnrUjWfnRrx3rlW8SS2pKiCJsdNxNTwe O7tYyDY2/HfLf40lGT+EptLc6s2A+zbMVUktfs2nXJx/yzb+Vc6vxCv2k2fYLYZ92/xqzN4pu7u0 nhe0gAaJskE/3TT5Kii20F4t6FGw8J6b9oV8yxfvAxMUpGc/w+5qHXRZ2+py6ZZah9oaIjzonbcY ie2R+VUW8af8I7pPm7g92yYgiABBPck8dKxvhmLi+8SXl5OpcSgvJM3RWJznNZVpqUUkTSpNT1PU /DivDbx2uwKduV4wVI7GrttqjSXL275jnUnMUq4bHqPUe9ePa18Q9UmN3bWEiwRFmjWdf9YyA4zn tnrxWv4I8UXd/d6ZDevNdTws6CZjuJRgOCe+MVpCHQK1VN+6e0joKWkHQUtcxsFZ2p6xFpbRLNBd SecwVTDCXG49Bx0NaNVb2xS+EG92XyJ1mGO5XtQBBZ65p95DPItykZtnZJlkcBo9rFfmGeOnerE9 /bQ2YuzKGibGwx/NvJ6BcdSe2KzLvwva3cTRyTPgmQjKgjLzLLyO4DKBj0qwuhwppMOno5QQEPHI qgbXB3BgOnXtQBPFq1o0Uckzm1MknlrHcjy2LegB6/hSjV9MaYwDULUyiTyygmXdv/u4z146VRuv D8l9EgutRlkk2vHI4jUb42KkqBj5furz16+tEnhq3dWBnkG5ZAcAfxzeae3rx9KALUmt2AZFhuY5 y04gYQuG2Mc/e546GkbXdMS4toDfQF7pmSLbICGZcZGfXkVm2XhTaga8vGkkWQlRGoVVTe7Bff75 5pLfwbZ2tottHMygFgxRFXcjJsKn324560AbMmp2aadPqCzrNbwIzu0J38KMnGOp46VUt/EulXLS 7LtVWGKOWR5PlRQ+do3HjPHI6jio7Tw5b2WiXWmRyYW6Vld0jVSMrtyAO+AOtE3hu2MxmtJTaygq 6lFBCuGdi2D1z5jcfT0oAnXXLFrq7tRcJ51qgcoZFBZdobcMnpg9TxUtvq1nOdpmWJzM8KpIwDOy HBwM89Ky/wDhEIAjQC8m+zGPYse1cq3kmHduxk/KTx0zT5PCdm+oQ3jSFnjkaTDIrdZDIAM9MMet AG/RSDpRQB5mYPLVp3bMdsAqIgyyuRyx7cf1pIY7WSAAQyM7MA7NJyQOAOBjFRxRy3UZWCDELZEY DYI5yc+uf6CqxubmCfy9qRgHADOqn8ic10wptq63OOrVjDcyPFNzBp+tRxQ3ctlIIVYBl3RHOepX kfkapr4mvVYWOtkz206/IdwKEeqEcVe8R6WdRvkurgFGMQUA9wPSqll4We5srhFPmWoG503fMh/v p7j9RwafLUjqVGcJLQ0NFW5s9Rh0+e7MmmP+8t2CZbP1HIIB+hr0O3nit7aKJnViwGM8ZHrXCaJ9 r0XSt+pKoisZNn2huhVuhHfB4/OrM3inSZypk1CJDEcqSSAVPUfh1/Omo3Wg767HcCO1kI2lCa52 +mgMpiUksOOBxWXD4u0SzugW1eAMOMEnj8xWU/ibSzqZnOs24j3FlK559jxXNzSbdzoStsP1Oxn8 wkYGfXiobexeKHdPNGilupbqfb1qxP4p0S6kAbUoAT/EoO0/pxVU+b4gMj6Oz3KW7bXAIIQnpj2N dFOo7GVRPsW4NPSe4DLcwHnpuxW1YWTWt2kbiGWU5xCzcOcHAPsaoWGiauY0ZrOTjqcVNptpNb+I o5pVIERBIzk9DW0qnu2uZxiyp490ee8h0ltTmt4ovtaxGK2jCpCrjH3jyeQKxfFmvadoek/8Iv4f ZMv/AMfs0bZ4/uZ7k9/yrf8AE2oy3Tzo8QZUXlMZCj/GuCuNBtLqQGzdomc524yprCdL3rrcVOva LTLHg3TIr65nvbgL5NmoYoRnzCeMVt/Dqe207xNPZ3KglJDsH48EVf8AC2kWGm2k1tJc+ZNu2zKw wOVyMVc0/wAMWA1l55lLTXCFYpQxAVsfKR75FbyShBP7zGN5z5F8j1lTkA+1OqtFcxLJHZtJ/pHk +ZtxyVGAT+ZqwTivPPRMG68Q/YrvVYZJIpJbfY1vblgrMpQEnHUgHJJ9Aahi8TzO9urx2yq+7dJv YrNhtv7rAO49/p+db8lzBHIEZh5m3eEAyxXIGcDnqRUnHp09qAOLbxdf3Q8yOO3ihieRJcvzIPL3 oARna/UYPOe1XH8U3aGeOO1iZo1GxWcllOUAL8fdbfkeu011GRnGP0pGdUVnbgKMk47UAZD6ldS6 BcXAeG1uIZHiZ2PyAq+0kEjgHBwSCBnJyBWdH4nnit7XH+lCRmy8u1WkwwXahT5Xb5s5HBAPvXTw zxXNvHPE2+OVA6NjqCMg07gduntQByUXiS7gtFtfkkvJTthaVuZMtJyFA5C7F6etMh8VXkdiJpI7 eWbau+TzCIyfL3FV44Yn5QPXNdjx1xUUdzBLPLAjBpICPMXH3SRkfpQBk6frd1d6o1tNbJHC7SiJ lJ3Dyyud2Rjnd29KzU1zUbDzZLlYpmlupwgLsAVjk2CNBj75HIHfBNdbkUcHGRQBmWOpXM9ndXlz CkcMTyiNYtzuyozKSRjqduQBXPp4kv8AUVhkXEBSQxuIXDo/7225BGf4ZGHX1rsUkWRdyhgOeqkd D70oIA4GPwoAWiiigDza3kl0vwpLfXSBbhAwAXquTx+PNcXaade3iPPHaSzAklmVc810niLURdeE 7OcMQbnarr6Fc5zVTRtUSys0WVGZYmLIFA5zzyeo5HWvXoqUabkkfPYlxlUUW9COGQLDDazE+Q4w QeqH+8PTH8q0dDheFZ0ByVBVxnv0rK1K3urowJEMPPiQkfwqT1PpxzV3wvZyTa+90kuY2nLbWBGV z3/Cs5zu9jvow5YoXXZs/D+6BXB3qgY9eGBH868ru4migaWSRnYdB717D4ytoW8IXaRYAZ0IQ9SQ wBNeZT2CvayRswGV6DrkNiphBygz0KeqN6T4R6hLpw1GXWrYmSIOFIO7JAOK4hraXTL+Wxu0BdOm On1FexyXmpLYO0NxGLWCBQgYhucAZAI4/WuIbwve+IfELTmZHESj7QzP0/uqOOWIrwsPiZ+0fO9D 0qmGSheO5ybN1xxXpXwjJOn6yoHLSRDPpw2K85mAjZlIwynBFemfBpW+y6xIo5WSLOT04NepX+Fs 5IL3j1OHTYBaCKUFgRzg4zXPP4Y/smW8vbOdVRgXRCpJQ4/XmtR/ElpBMIZg4bIGVBIzUmp3Ulto uoXJUN5ETsoPfArkg1JryCcJQTueZX0oZvsURJkwXkJPJPXmqOkWYaX7QVyFGfbNYsN9LEJbwkmW UlixPr1rZsNchaxX7PGyoUG4t13d/wAK9BVU53fQ8nk0HW87LdyyHC/6SM88noK6N75oYQNp3QNu BFctYW5u9JuryP5tkjkn3ABrtIbCO5jV2OPMUEH1yKdOfNCzFKNppo6zVdHm1SVLmOSIDyFQxyA7 Xw6vhsfwkDBqsnhu8iaMi6gd1txGs0iMzQkBuEGcbTuHX0HBro4hiJB6KKfXCekcbD4LnjjjJmt/ OXzEVjuYxIzKwCt16qfT7xq0PCskk8huZoZIXnV3QqT5wDlvnz1PIX6CuooxQBz8vh+eXQvsJ1CZ pfKSM/ORGwVgcY6jIG0nng9Khh8LPG8MgnTzoY4UVzuZlVWcuoJ5wQ4H0H4V01UdW1OPSrI3DRPM xO1Yo+XfucDvgAn6A0Ac9N4PuE0Y6daXMMSMkQ2AFV3qhUsMdCWw3HXFWG8LTZnkS8RZrgOJZADm QFUADHuBtP8A31VgeK7TMjtbzi3VNyTfL85ESy425yPlYde9TWGsSvp9/eX8It/ss7p5ZYZAAGAS OCTn9aAM+LwrcDU4bw3EcAjj2iO3Z1WH73CDPIO4eg4HFWtE0CbTLW+ikaANc7QPs5ZM4TbuJ6hj 1JFJD4rhnMOLG5RWO2UuAphJk8oAgnJ+b0HvUMviovBHKltJb7j5h8zaxaIxysGXBxnMR4P9aAIo vCVyjaYz3aYs2J2Rkoo+cMCMY3HAwScZzzVmHwssVpaxLNtkV2+1Ouf9IQnJU557L9AMCpj4jRIZ pPsszpGdiNlQZpBgFAuc559OaqQeLBPOXa1lhs/3bJNwWYNGzkMucjG0/lQA5/DV00hP2qMl1kUT EN5luWeRsx4PUhwD/ujr0qO18LXFvBYIs0Y+zXBmbczSKB8vCqwxk7Tzxt3Ejvmw3iuONNzWFxuU M8qbk/doqK5brz8rA4HNaFpq8V1fXNr5bRfZ8cykKXBOAQvXaTwD0PagDRHSigdKKAPG1YLbKjxJ JA+d0TD5Sev4H3qe3Gnx7QVkEfVomUHPtkEcVpLoUt1p2+2QtkbtrMAy/wBKoDSr1Yy0kK7hwfmF X7dxTVyVhYzcXYpazrLfMIYivnJtklbG4j0AHAHHSptDvpbaKWWNPMO35UHG4ngfz/Kq7+HdS1KQ RxwoqEDMjOPl5/OmiCQamfDNozh05vpyQCVAztXnpz+NdMZJU0zKpC1ZpbJl/XNQGqeH79gwaOEI uVHBO4cj8f0rmtK0a41XmFIkjQ/PJIeOV6YHXnmul1uwGmeDLmJVIQyJkkgljn/61Yvhu9ZBLAD8 uQw/lWsJShQbW5vTStoSapp17p+htFbyTXcUDCFnSAOS+AenXisfwJLqt7rLIb2Wzt1nE8o2YaY9 NuT2x2rpLnUCLWwCPJGRevI5jbaSobH58YrOkuAt+18GKysSAw6rk9vSvKnSjq1uzrjWk7X6HPax od5f65qMsMJ8wytKYiApCk8EV2PwfJcaujsqYaJSrcdAa5y7Fx9rYRSku6l0J6HHVW9a6D4VtGV1 aclm3yx4IGOxzXRF3hy2MJaO56K3yNtV4AMjg1dkAngeGRo5EcsrKwyCD1zWdJPaeapMByWAFaKN B5xAi5JqY6MiTbRjz+GdOazKxWWno/8ACTCv+FYOp6Vb2mmF4V01GUc4iXn9K7yQQiLHl9KxdTit J7dg1pG/GGDDt7e9bQepk4qx5/LqEtlbPBBJaRQmLeyRoAGJHPGK59/GWopuWPVJY1QYRcAgD0HF b2sR2AkkiiiG7ygu4DA6cVxFxoc26QxhSvbmuirGSiuVGcY3Wp9QWpLWkLE5JRT+lTVlW2t6clrC pueRGoPyN6fSpf7d03/n5/8AHG/wrzzoNCis/wDt3Tf+fn/xxv8ACj+3dN/5+f8Axxv8KANCq91Z W19AYLuCOeInOyRdwqv/AG7pv/Pz/wCON/hR/bum/wDPz/443+FAEw02yVQotYQo6Dyxj7u3/wBB AH04pINMsba0a0gtIY7ds7olQBTnrkVF/bum/wDPz/443+FH9u6b/wA/P/jjf4UAMi8PaVDdxXMV lEjwIViAUbUyxYkDsST1p1noOmWNqLaCzi8sHJ3KCWOCCSe5wSPxNL/bum/8/P8A443+FH9u6b/z 8/8Ajjf4UAPfR9NkaVnsbdmlUK5MY+YDoDSppOnRNE0dlAphUJHiMfKo6AfnUf8Abum/8/P/AI43 +FH9u6b/AM/P/jjf4UASR6Tp8UXlR2UCJhhtEYxhvvfn3pw02zUyEWsQMrB5DsHzEHIJ+hAqH+3d N/5+f/HG/wAKP7d03/n5/wDHG/woAv0VQ/t3Tf8An5/8cb/CigD/2Q== ------_=_NextPart_001_01C7AD8D.C5A8C8A5-- --===============0921290566== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0921290566==-- From ecrit-bounces@ietf.org Wed Jun 13 08:31:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyS02-0004Po-I7; Wed, 13 Jun 2007 08:30:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyS01-0004Pj-ND for ecrit@ietf.org; Wed, 13 Jun 2007 08:30:57 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyRzz-0007zT-Px for ecrit@ietf.org; Wed, 13 Jun 2007 08:30:57 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1HyRxd-00049c-4D; Wed, 13 Jun 2007 07:28:32 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com> <012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com> Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Wed, 13 Jun 2007 08:30:46 -0400 Message-ID: <023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AceqV4ZeonTtWSgmTEKwTanATYJDUQCpIGKwAA63d4AABo3GsAAO+O4AAAphx5A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 35332ddd50c13c907e3de24c6b975ab4 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1186980182==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1186980182== Content-Type: multipart/related; boundary="----=_NextPart_000_0238_01C7AD95.25F516E0" This is a multi-part message in MIME format. ------=_NextPart_000_0238_01C7AD95.25F516E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0239_01C7AD95.25F69D80" ------=_NextPart_001_0239_01C7AD95.25F69D80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't see any changes needed in LoST for forest guides. Brian _____ From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] Sent: Wednesday, June 13, 2007 3:38 AM To: Brian Rosen; ecrit@ietf.org Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives I wasn't suggesting they were an identical level of definition. I was saying that it's still not definitive solution; of course it's a matter of degree. Without a definitive forest guide solution, how does a VSP know how to find the right LoST server to find the PSAP URI? At least with option 3, the PSAP URI is provided at the point of local knowledge where the applicable LoST server is known. Pull your last comment apart for me. are you saying that the "forest guide" implementation requires changes to LoST? Without those changes, the Forest Guide won't work either? Cheers, Martin _____ From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, 13 June 2007 10:28 AM To: Dawson, Martin; ecrit@ietf.org Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives I'm sorry but the forest guide idea is a whole lot more developed that any notion of an authoritative list of PSAP URIs. I'm not saying it can't be done, I'm saying we need a whole lot more work on it to make it real, and it's not at all clear to me that the reverse lookup idea has more or less merit. However, both of them are beyond what I think is appropriate for LoST at this point. Brian _____ From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] Sent: Tuesday, June 12, 2007 5:19 PM To: Brian Rosen; ecrit@ietf.org Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Well hand waving was about all I could invest in an email, but are you saying you'd just have to give up at that stage? What is a reference to a "forest guide", if it's not a particularly low-detail suggestion of the sort of thing we need to resolve the right LoST server? Yet, without that, option 1 doesn't work. Why wouldn't this "validation" be a function of that system and why is reverse lookup the only option? Cheers, Martin _____ From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, 13 June 2007 12:18 AM To: Dawson, Martin; ecrit@ietf.org Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives I think those of us pushing for Option 1 for now is that we think VSP validation is a fact of life we have to deal with, waving hands over "reference to a relatively static table maintained by global cooperation" is not adequate, and something like a reverse lookup is required. This would be a change to LoST and we are reluctant to take this change on at this time. Brian _____ From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] Sent: Tuesday, June 12, 2007 10:08 AM To: ecrit@ietf.org Subject: [Ecrit] Proposals 1 and 3 - summary of perspectives For some reason this hasn't made it through moderation. Now I'm a list subscriber, I'll try again. It's a long weekend in Australia and winter has finally hit - with cold wind and rain. What better time, then, to spend some time catching up with the action on the ECRIT list. I only went back a couple of weeks; obviously the main topic has been to do with the question of how to define the "location hiding" capability. Mostly it's a debate about the utility of option 1 and 3. Having just read through all the postings and while they are fresh in my mind, here is how I characterize the perspectives. First my summary of the options. * Option 1 achieves location hiding, somewhat oxymoronically, by providing location. Whether it's by reference to the local LoST facility or by some internal knowledge, the LIS generates a coarse location which it knows will result in a correct PSAP URI resolution if/when another party makes a request to the LoST facility. This is provided in addition to a location reference for subsequent accurate location requests from the PSAP for dispatch etc. * Option 3 achieves location hiding by making the request to the local LoST facility using the end points location and providing the PSAP URI that the LoST service returns (in addition to a location reference) so the call can be routed to that PSAP - whether directly from the device or via a proxy/VSP. Both suggestions are based on an assumption that a LIS, being associated with the local jurisdiction, has enough local knowledge to identify the correct LoST service for that jurisdiction or, at least in the case of option 1, to determine what "coarse location" isn't too coarse. Perspective 1 - articulated by a lot of people, Ted, Brian, Andy,. etc. is that LoST needs to progress and get to a first release and changes associated with this particular use case should be avoided for now. I haven't seen anything in either proposal that does require a change to LoST. In the one case either or both of the LIS and VSP/proxy make LoST queries but neither options appears to *dictate* a specific change to LoST. Perspective 2 - articulated by, for example, James W and Barbara is that the LIS operator should have the option of providing location or not - a "coarse location" is still a location and location information to the granularity of PSAP boundaries, for example, could still support a lot of value-added services and be used for other than emergency services. Perspective 3 - articulated by, for example, Andy and Laura is that, when the end-point initiates a call through the VSP/proxy with a pre-determined PSAP URI, the proxy may not know that this really is a genuine emergency call destination. In fact it could be used to call anyone by just pretending it's an emergency call. This means the VSP may lose call revenue through the fraudulent nomination of emergency calls. Perspective 4 - articulated by, in particular, Hannes (sorry Hannes, I can't see anyone else emphasising this point) is that all emergency calls should go through a VSP so that there's an authenticated subscriber identity to be associated with the call. This seems like an orthogonal point to me. If we accept that some calls will go through VSPs and therefore Perspective 3 is valid then the question of whether all emergency calls have to go through a VSP is moot. I have to admit to being really surprised by the perspective - it wasn't one that I thought had any currency in this forum. There were miscellaneous other perspectives including some good suggestions for alternatives/compromises from Richard and Henning. Martin D's perspective - * On perspective 1, I don't see any impediment to pushing LoST out. Even if there are changes to come, they can be done in a revision or whatever. But I haven't seen any definitive statement about how either option *requires* a change to LoST. * On perspective 4, I don't think it's decisive in the discussion. * So, really, it boils down to an evaluation of which of perspectives 2 and 3 are the most valid - i.e. are the interests of the LIS operator or a VSP to have priority. I don't understand why the interests of LIS operators and VSPs can't both be served. I'm surprised that with all the experience and knowledge in the forum that nobody can provide a practical way for a proxy/VSP to determine whether a PSAP URI is a valid emergency destination or not. I know that adding the reverse-lookup to LoST has been discussed. That would be effective, but it's not in keeping with perspective 1. Surely, though, there are alternatives. I think option 3 supports a faster and smoother deployment of global emergency calling for VoIP. Here's my rationale. 1. Both options require a LoST and LIS capability to exist at a local and jurisdictional level - so their availability is a premise in either proposal 2. Option 1 assumes that each VSP can make an effective LoST query even if it is a "non-local" VSP to the point from where the call is being originated. This is either by the VSP automatically knowing which LoST server is applicable to the coarse location or by the use of the so called forest guide and perhaps some international hierarchy of interconnected LoST servers. 3. Option 3 only assumes that this local knowledge is in the local LIS function and doesn't rely on the existence of the infrastructure described in point 2. 4. The ability to verify a destination PSAP URI as a valid emergency URI could be supported by reference to a relatively static table maintained by global cooperation. In fact, I would have thought that filtering based on domain name would be extremely reliable and fast. It would certainly obviate the ability to make arbitrary calls by pretending they are emergency calls. 5. Perhaps a later revision of LoST can include the reverse-lookup mechanism and, perhaps by then, the international infrastructure of LoST servers, forest guides, etc. may be in place. I mention point 4 as one possible way to protect the interest of the VSPs without requiring a change to the current LoST definition. Are there any other proposals on how to achieve this or, alternatively, a view that it simply isn't possible? Cheers, Martin Martin Dawson Andrew Network Solutions Asia-Pacific Email: martin.dawson@andrew.com Phone: +61 2 42212992 Fax: +61 2 42212901 Mobile: +61 412 120300 This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] ------=_NextPart_001_0239_01C7AD95.25F69D80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t see any changes = needed in LoST for forest guides. 

 

Brian

 

From: = Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Sent: Wednesday, June 13, = 2007 3:38 AM
To: Brian Rosen; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

I wasn’t = suggesting they were an identical level of definition. I was saying that it’s = still not definitive solution; of course it’s a matter of degree. = Without a definitive forest guide solution, how does a VSP know how to find the = right LoST server to find the PSAP URI? At least with option 3, the PSAP URI = is provided at the point of local knowledge where the applicable LoST = server is known.

 =

Pull your last = comment apart for me… are you saying that the “forest guide” implementation requires changes to LoST? Without those changes, the = Forest Guide won’t work either?

 =

Cheers,

Martin=

 =

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, 13 June = 2007 10:28 AM
To: Dawson, Martin; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

I’m sorry but the forest = guide idea is a whole lot more developed that any notion of an authoritative list = of PSAP URIs.  I’m not saying it can’t be done, I’m = saying we need a whole lot more work on it to make it real, and it’s not at = all clear to me that the reverse lookup idea has more or less merit.  = However, both of them are beyond what I think is appropriate for LoST at this = point.

 

Brian

 

From: = Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Sent: Tuesday, June 12, = 2007 5:19 PM
To: Brian Rosen; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

Well hand waving = was about all I could invest in an email, but are you saying you’d = just have to give up at that stage? What is a reference to a “forest = guide”, if it’s not a particularly low-detail suggestion of the sort of = thing we need to resolve the right LoST server? Yet, without that, option 1 doesn’t work. Why wouldn’t this “validation” be = a function of that system and why is reverse lookup the only = option?

 =

Cheers,

Martin=

 =

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, 13 June = 2007 12:18 AM
To: Dawson, Martin; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

I think those of us pushing for = Option 1 for now is that we think VSP validation is a fact of life we have to = deal with, waving hands over “reference to a = relatively static table maintained by global cooperation” is not adequate, and something like a reverse lookup = is required.  This would be a change to LoST and we are reluctant to = take this change on at this time.

 

Brian

 

From: = Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Sent: Tuesday, June 12, = 2007 10:08 AM
To: ecrit@ietf.org
Subject: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

For some reason this hasn’t made it = through moderation. Now I’m a list subscriber, I’ll try = again…

 

It’s a long weekend in Australia and winter has = finally hit – with cold wind and rain. What better time, then, to spend = some time catching up with the action on the ECRIT list. I only went back a couple = of weeks; obviously the main topic has been to do with the question of how = to define the “location hiding” capability. Mostly it’s a = debate about the utility of option 1 and 3.

 

Having just read through all the postings and = while they are fresh in my mind, here is how I characterize the perspectives. = First my summary of the options…

 

  • Option 1 = achieves location hiding, somewhat oxymoronically, by providing location. = Whether it’s by reference to the local LoST facility or by some = internal knowledge, the LIS generates a coarse location which it knows will = result in a correct PSAP URI resolution if/when another party makes a = request to the LoST facility. This is provided in addition to a location = reference for subsequent accurate location requests from the PSAP for = dispatch etc.
  • Option 3 = achieves location hiding by making the request to the local LoST facility = using the end points location and providing the PSAP URI that the LoST = service returns (in addition to a location reference) so the call can be = routed to that PSAP – whether directly from the device or via a = proxy/VSP.

 

Both suggestions are based on an assumption = that a LIS, being associated with the local jurisdiction, has enough local = knowledge to identify the correct LoST service for that jurisdiction or, at least = in the case of option 1, to determine what “coarse location” = isn’t too coarse.

 

Perspective 1 – articulated by a lot of = people, Ted, Brian, Andy,… etc. is that LoST needs to progress and get to = a first release and changes associated with this particular use case should be = avoided for now. I haven’t seen anything in either proposal that does = require a change to LoST. In the one case either or both of the LIS and VSP/proxy = make LoST queries but neither options appears to *dictate* a specific change to LoST.

 

Perspective 2 – articulated by, for = example, James W and Barbara is that the LIS operator should have the option of providing location or not – a “coarse location” is = still a location and location information to the granularity of PSAP boundaries, = for example, could still support a lot of value-added services and be used = for other than emergency services.

 

Perspective 3 – articulated by, for = example, Andy and Laura is that, when the end-point initiates a call through the VSP/proxy with a pre-determined PSAP URI, the proxy may not know that = this really is a genuine emergency call destination. In fact it could be used = to call anyone by just pretending it’s an emergency call. This means = the VSP may lose call revenue through the fraudulent nomination of emergency = calls.

 

Perspective 4 – articulated by, in = particular, Hannes (sorry Hannes, I can’t see anyone else emphasising this = point) is that all emergency calls should go through a VSP so that there’s = an authenticated subscriber identity to be associated with the call. This = seems like an orthogonal point to me. If we accept that some calls will go through = VSPs and therefore Perspective 3 is valid then the question of whether all = emergency calls have to go through a VSP is moot. I have to admit to being really surprised by the perspective – it wasn’t one that I thought = had any currency in this forum.

 

 

There were miscellaneous other perspectives = including some good suggestions for alternatives/compromises from Richard and = Henning.

 

Martin D’s perspective = –

 

  • On = perspective 1, I don’t see any impediment to pushing LoST out. Even if there = are changes to come, they can be done in a revision or whatever. But I haven’t seen any definitive statement about how either option = *requires* a change to = LoST.
  • On = perspective 4, I don’t think it’s decisive in the = discussion.
  • So, = really, it boils down to an evaluation of which of perspectives 2 and 3 are the most = valid – i.e. are the interests of the LIS operator or a VSP to have priority.

 

I don’t understand why the interests of = LIS operators and VSPs can’t both be served. I’m surprised that = with all the experience and knowledge in the forum that nobody can provide a practical way for a proxy/VSP to determine whether a PSAP URI is a valid emergency destination or not. I know that adding the reverse-lookup to = LoST has been discussed. That would be effective, but it’s not in keeping = with perspective 1. Surely, though, there are = alternatives.

 

I think option 3 supports a faster and = smoother deployment of global emergency calling for VoIP. Here’s my = rationale.

 

  1. Both = options require a LoST and LIS capability to exist at a local and jurisdictional = level – so their availability is a premise in either = proposal
  2. Option 1 = assumes that each VSP can make an effective LoST query even if it is a “non-local” VSP to the point from where the call is = being originated. This is either by the VSP automatically knowing which = LoST server is applicable to the coarse location or by the use of the so = called forest guide and perhaps some international hierarchy of = interconnected LoST servers.
  3. Option 3 = only assumes that this local knowledge is in the local LIS function and doesn’t rely on the existence of the infrastructure described = in point 2.
  4. The = ability to verify a destination PSAP URI as a valid emergency URI could be = supported by reference to a relatively static table maintained by global cooperation. In fact, I would have thought that filtering based on = domain name would be extremely reliable and fast. It would certainly = obviate the ability to make arbitrary calls by pretending they are emergency = calls.
  5. Perhaps a = later revision of LoST can include the reverse-lookup mechanism and, = perhaps by then, the international infrastructure of LoST servers, forest = guides, etc. may be in place.

 

I mention point 4 as one possible way to = protect the interest of the VSPs without requiring a change to the current LoST = definition. Are there any other proposals on how to achieve this or, alternatively, = a view that it simply isn’t possible?

 

Cheers,

Martin

 

Martin Dawson

Andrew Network Solutions = Asia-Pacific

Email: martin.dawson@andrew.com

Phone: +61 2 42212992

Fax: +61 2 42212901

Mobile: +61 412 120300


This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have = received it in error, please notify the sender immediately and delete the = original. Any unauthorized use of this email is prohibited.

 

 


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

 

 


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

 

 


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

 

------=_NextPart_001_0239_01C7AD95.25F69D80-- ------=_NextPart_000_0238_01C7AD95.25F516E0 Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABfAPYDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1v7DZ /wDPpB/37X/Cj7FZ/wDPpB/36X/Cmahc3FrZvLa2jXcwwFiVgMk+57VxHiiLxQ+m+fe3SQrJIscd lZ5JYn1PU0m7HVhsP7eSTklfudlM2j28PnTfYo4/7zBAKxf+Es8KG5aEGAqqljKYAE47Djk1xEOg wW+oWFn4i1JbCS8IFvbEF5GycduF59a3LGPwN4fuL5r7UUuLnT3AnEqMREScABQOeeM81Cc3sjsq UMBRupVHJ+R1OlX1hrEjm30krbqPluJYFVZD6AHmtT7DZ/8APpB/36X/AArGXxx4ZGsDRzqkcd7u EYiZGUbjjAzjGeRTbfx94audXbSk1Efa1kaLa0bAF16gMRjPFaJM8ucot+6rI2/sVn/z6Qf9+1/w o+xWf/PpB/37X/Cudh+I/he4t5biO+kaGJlV3+zuACx2gZx61YHjvw41ylul/wCZK90bRUSJiWlG MgcdOevSnZkXRtfYrP8A59IP+/a/4UfYrP8A59IP+/a/4VNS0hkH2Kz/AOfSD/v2v+FH2Kz/AOfS D/v2v+FT0UAQfYrP/n0g/wC/a/4UfYrP/n0g/wC/a/4VPRQBB9is/wDn0g/79r/hR9is/wDn0g/7 9r/hU9FAEH2Kz/59IP8Av2v+FH2Kz/59IP8Av2v+FT0UAV2tLFFLNbW6qOpMagD9Kgtzo92zLbfY ZivURhGI/Ks+/t11nxGNOuvmsrS3Wd4c8TOxIG71AA6etRauPDFpcRrcslhc25V0lgjKMg9NyjGD 0IrRQ+8ydRrXobv2Kz/59IP+/S/4UfYbP/n0g/79L/hWZe+IfJvfsdjafbJVjWSQmZYlVW6DLdSf SlHiW3msLW4tIJbia7dkit1wG3L94E9ABjk0uSRXtI9zS+xWf/PpB/37X/Cj7FZ/8+kH/ftf8Ko2 utNJJcW95ZPaXcEXnGIuGDp6qw688e1Z8Hi24nSzcaHcD+0FzafvV+c4yd390Yyc+goUJMTqxRvf YrP/AJ9IP+/a/wCFH2Gz/wCfSD/v0v8AhWYPEsSaTLez20kc0M/2Z7YMC3m5ACg9Ocjn0qOLxDJO bi0lsjb3q27TRRrOriQD0YdCDjrQoSD2sDX+w2f/AD6Qf9+l/wAKPsVn/wA+kH/ftf8ACue07xBe QaBpTT2EtxdXh8uMeauXO3O4nsDitESRv4gsjPbSR3r2bsMS5RBkZUgcE5PWhwa3BVItaGh9hs/+ fSD/AL9L/hSfY7IEA2tvk9B5a8/pWWnieN50svscv9omfymtNwyi9fMJ6bMc5/Csu6iZ9Q33MwTa 3+kAt8+dxxsHUjbtxj1701B9ROqump1P2Kz/AOfSD/v0v+FFFl532GD7RnzfLG/Priis27GqZJ5k f/PRP++hRviyMunHT5hxXjl1fzx6jOgcgBzgVuaPdF4fnwx98Vs6TSuZe01DW/AOta14pk12TVrB WS6ia3iOTsiQ5A3dj7AYOaoXfwmvb7VpNSn1S082fUWnnUO21oSwIXp97r7Ve1SXywjA4GD0+tYE l5LNcYEjAZ7GlGLZHtE3axtf8K21W61y4nvtV09bGbUPtxSMEykjOxdx6D1qDS/hhqljfte3Gp2F y7JOyq0jbYp3BCyLxzjvmtDQmJlO87vl7jNdN+5AzsT/AL5FDTWlzSPKzi7P4Zanb+DtR0R9Q04T 3DxPDKsjkAqxJ3Z6dewqbw98MJ9B8QDVI9Ss5fIhH2dXJbExUBnI9PvY/CuneeIMAI4z/wABFIZY /tZGyPHptFK0g0udKkq7F3yx7sDOGGM0vmx/89E/76FYUqxbf9Wn/fIrA1S3LD5OMv2wO1EYczKb sd75kf8Az0T/AL6FJ5kf/PRP++hXAG0f7B3z61NpCG3glmlXzAilsNjsKp0rK9xc53Pmx/8APRP+ +hR5sf8Az0T/AL6Fchaa7p04G6EJ7hAwqxqGr2Fnpz3MKQysOFTaBk1Eo8quwU7uyOn82L/nqn/f Qo82L/nqn/fQrkvC2qTauZo72zgRk5R1jADCukW3g/54Rf8AfAqVZq6KbsWfNi/56p/30KPNi/56 p/30KUWtvj/URf8AfAo+y2//ADwj/wC+BSGZWp2Lz3cWo6deQ297CpTMhykqE52sOvXkEdKqXFpq 2sxi11KewtLMkecttIXeYA525IG0H866D7Lb/wDPCP8A74FH2W3/AOeEf/fAqlNoh00zm9T0Vm1a S/tINMu1njVHivDjYV4DKQDxjqPapP7IuLe1sZbS5shfWZclQoSGQP8AeXA6dufaug+y2/8Azwj/ AO+BR9lt/wDnhH/3wKftGT7KJiQWV3c3U9/qM1ok72zW8MUMhKxg8klj1JOO3amW+lSwx+H1a4ty dLQrNh/vfutny/j61vfZbf8A54R/98Cj7Lb/APPCP/vgUudj9nE5y40A3NjfxNc23mTagbyDd8yd FwHH4EH607TdMliuJbieDSrPMLRpHaAEkn+IsQCB7Cuh+y2//PCP/vgUfZbf/nhH/wB8Cn7SVrC9 lG9zCttKkhtdDia4gzpxzLh+G+Ujj8TVye2L67BqCSwlIraSLaXwSxII/DitH7Lb/wDPCP8A74FH 2W3/AOeEf/fApczK5FaxzS6JeJcLrAv4G1gyfvMufJaL/nl64A5BxnNdFugLBmaIsOhJBI/Gn/Zb f/nhH/3wKPstv/zwj/74FDk3uEYKOwnmxf8APVP++hRS/Zbf/nhH/wB8CiosWeLX0WdWn/3zWpp8 UygbYnx6hDVp5FMZu/8AUGQ4CQINzE9gepP40+b/AEWB7h5ppAmCAHyTnpXdzp6HM49SDWI2FnGW BBweox3rmbZ8XB+td3p1ymr2YEjvGASu1mDfzqLV/Cuk2tqb3zGhf+9kBCT0yPr6VN7CjEp6RJtL t6JWq9/8nXtWNaq1nKIpo8hk5eM5VvUr7VvjR7WW1WWN5iWxxxxRJX1Ki+hnrclmzmpZrjZeZz3q oIZEnZfs7hQepPXn19alnALb8kE84pS91alJOWxtCfzEXnrUjWfnRrx3rlW8SS2pKiCJsdNxNTwe O7tYyDY2/HfLf40lGT+EptLc6s2A+zbMVUktfs2nXJx/yzb+Vc6vxCv2k2fYLYZ92/xqzN4pu7u0 nhe0gAaJskE/3TT5Kii20F4t6FGw8J6b9oV8yxfvAxMUpGc/w+5qHXRZ2+py6ZZah9oaIjzonbcY ie2R+VUW8af8I7pPm7g92yYgiABBPck8dKxvhmLi+8SXl5OpcSgvJM3RWJznNZVpqUUkTSpNT1PU /DivDbx2uwKduV4wVI7GrttqjSXL275jnUnMUq4bHqPUe9ePa18Q9UmN3bWEiwRFmjWdf9YyA4zn tnrxWv4I8UXd/d6ZDevNdTws6CZjuJRgOCe+MVpCHQK1VN+6e0joKWkHQUtcxsFZ2p6xFpbRLNBd SecwVTDCXG49Bx0NaNVb2xS+EG92XyJ1mGO5XtQBBZ65p95DPItykZtnZJlkcBo9rFfmGeOnerE9 /bQ2YuzKGibGwx/NvJ6BcdSe2KzLvwva3cTRyTPgmQjKgjLzLLyO4DKBj0qwuhwppMOno5QQEPHI qgbXB3BgOnXtQBPFq1o0Uckzm1MknlrHcjy2LegB6/hSjV9MaYwDULUyiTyygmXdv/u4z146VRuv D8l9EgutRlkk2vHI4jUb42KkqBj5furz16+tEnhq3dWBnkG5ZAcAfxzeae3rx9KALUmt2AZFhuY5 y04gYQuG2Mc/e546GkbXdMS4toDfQF7pmSLbICGZcZGfXkVm2XhTaga8vGkkWQlRGoVVTe7Bff75 5pLfwbZ2tottHMygFgxRFXcjJsKn324560AbMmp2aadPqCzrNbwIzu0J38KMnGOp46VUt/EulXLS 7LtVWGKOWR5PlRQ+do3HjPHI6jio7Tw5b2WiXWmRyYW6Vld0jVSMrtyAO+AOtE3hu2MxmtJTaygq 6lFBCuGdi2D1z5jcfT0oAnXXLFrq7tRcJ51qgcoZFBZdobcMnpg9TxUtvq1nOdpmWJzM8KpIwDOy HBwM89Ky/wDhEIAjQC8m+zGPYse1cq3kmHduxk/KTx0zT5PCdm+oQ3jSFnjkaTDIrdZDIAM9MMet AG/RSDpRQB5mYPLVp3bMdsAqIgyyuRyx7cf1pIY7WSAAQyM7MA7NJyQOAOBjFRxRy3UZWCDELZEY DYI5yc+uf6CqxubmCfy9qRgHADOqn8ic10wptq63OOrVjDcyPFNzBp+tRxQ3ctlIIVYBl3RHOepX kfkapr4mvVYWOtkz206/IdwKEeqEcVe8R6WdRvkurgFGMQUA9wPSqll4We5srhFPmWoG503fMh/v p7j9RwafLUjqVGcJLQ0NFW5s9Rh0+e7MmmP+8t2CZbP1HIIB+hr0O3nit7aKJnViwGM8ZHrXCaJ9 r0XSt+pKoisZNn2huhVuhHfB4/OrM3inSZypk1CJDEcqSSAVPUfh1/Omo3Wg767HcCO1kI2lCa52 +mgMpiUksOOBxWXD4u0SzugW1eAMOMEnj8xWU/ibSzqZnOs24j3FlK559jxXNzSbdzoStsP1Oxn8 wkYGfXiobexeKHdPNGilupbqfb1qxP4p0S6kAbUoAT/EoO0/pxVU+b4gMj6Oz3KW7bXAIIQnpj2N dFOo7GVRPsW4NPSe4DLcwHnpuxW1YWTWt2kbiGWU5xCzcOcHAPsaoWGiauY0ZrOTjqcVNptpNb+I o5pVIERBIzk9DW0qnu2uZxiyp490ee8h0ltTmt4ovtaxGK2jCpCrjH3jyeQKxfFmvadoek/8Iv4f ZMv/AMfs0bZ4/uZ7k9/yrf8AE2oy3Tzo8QZUXlMZCj/GuCuNBtLqQGzdomc524yprCdL3rrcVOva LTLHg3TIr65nvbgL5NmoYoRnzCeMVt/Dqe207xNPZ3KglJDsH48EVf8AC2kWGm2k1tJc+ZNu2zKw wOVyMVc0/wAMWA1l55lLTXCFYpQxAVsfKR75FbyShBP7zGN5z5F8j1lTkA+1OqtFcxLJHZtJ/pHk +ZtxyVGAT+ZqwTivPPRMG68Q/YrvVYZJIpJbfY1vblgrMpQEnHUgHJJ9Aahi8TzO9urx2yq+7dJv YrNhtv7rAO49/p+db8lzBHIEZh5m3eEAyxXIGcDnqRUnHp09qAOLbxdf3Q8yOO3ihieRJcvzIPL3 oARna/UYPOe1XH8U3aGeOO1iZo1GxWcllOUAL8fdbfkeu011GRnGP0pGdUVnbgKMk47UAZD6ldS6 BcXAeG1uIZHiZ2PyAq+0kEjgHBwSCBnJyBWdH4nnit7XH+lCRmy8u1WkwwXahT5Xb5s5HBAPvXTw zxXNvHPE2+OVA6NjqCMg07gduntQByUXiS7gtFtfkkvJTthaVuZMtJyFA5C7F6etMh8VXkdiJpI7 eWbau+TzCIyfL3FV44Yn5QPXNdjx1xUUdzBLPLAjBpICPMXH3SRkfpQBk6frd1d6o1tNbJHC7SiJ lJ3Dyyud2Rjnd29KzU1zUbDzZLlYpmlupwgLsAVjk2CNBj75HIHfBNdbkUcHGRQBmWOpXM9ndXlz CkcMTyiNYtzuyozKSRjqduQBXPp4kv8AUVhkXEBSQxuIXDo/7225BGf4ZGHX1rsUkWRdyhgOeqkd D70oIA4GPwoAWiiigDza3kl0vwpLfXSBbhAwAXquTx+PNcXaade3iPPHaSzAklmVc810niLURdeE 7OcMQbnarr6Fc5zVTRtUSys0WVGZYmLIFA5zzyeo5HWvXoqUabkkfPYlxlUUW9COGQLDDazE+Q4w QeqH+8PTH8q0dDheFZ0ByVBVxnv0rK1K3urowJEMPPiQkfwqT1PpxzV3wvZyTa+90kuY2nLbWBGV z3/Cs5zu9jvow5YoXXZs/D+6BXB3qgY9eGBH868ru4migaWSRnYdB717D4ytoW8IXaRYAZ0IQ9SQ wBNeZT2CvayRswGV6DrkNiphBygz0KeqN6T4R6hLpw1GXWrYmSIOFIO7JAOK4hraXTL+Wxu0BdOm On1FexyXmpLYO0NxGLWCBQgYhucAZAI4/WuIbwve+IfELTmZHESj7QzP0/uqOOWIrwsPiZ+0fO9D 0qmGSheO5ybN1xxXpXwjJOn6yoHLSRDPpw2K85mAjZlIwynBFemfBpW+y6xIo5WSLOT04NepX+Fs 5IL3j1OHTYBaCKUFgRzg4zXPP4Y/smW8vbOdVRgXRCpJQ4/XmtR/ElpBMIZg4bIGVBIzUmp3Ulto uoXJUN5ETsoPfArkg1JryCcJQTueZX0oZvsURJkwXkJPJPXmqOkWYaX7QVyFGfbNYsN9LEJbwkmW UlixPr1rZsNchaxX7PGyoUG4t13d/wAK9BVU53fQ8nk0HW87LdyyHC/6SM88noK6N75oYQNp3QNu BFctYW5u9JuryP5tkjkn3ABrtIbCO5jV2OPMUEH1yKdOfNCzFKNppo6zVdHm1SVLmOSIDyFQxyA7 Xw6vhsfwkDBqsnhu8iaMi6gd1txGs0iMzQkBuEGcbTuHX0HBro4hiJB6KKfXCekcbD4LnjjjJmt/ OXzEVjuYxIzKwCt16qfT7xq0PCskk8huZoZIXnV3QqT5wDlvnz1PIX6CuooxQBz8vh+eXQvsJ1CZ pfKSM/ORGwVgcY6jIG0nng9Khh8LPG8MgnTzoY4UVzuZlVWcuoJ5wQ4H0H4V01UdW1OPSrI3DRPM xO1Yo+XfucDvgAn6A0Ac9N4PuE0Y6daXMMSMkQ2AFV3qhUsMdCWw3HXFWG8LTZnkS8RZrgOJZADm QFUADHuBtP8A31VgeK7TMjtbzi3VNyTfL85ESy425yPlYde9TWGsSvp9/eX8It/ss7p5ZYZAAGAS OCTn9aAM+LwrcDU4bw3EcAjj2iO3Z1WH73CDPIO4eg4HFWtE0CbTLW+ikaANc7QPs5ZM4TbuJ6hj 1JFJD4rhnMOLG5RWO2UuAphJk8oAgnJ+b0HvUMviovBHKltJb7j5h8zaxaIxysGXBxnMR4P9aAIo vCVyjaYz3aYs2J2Rkoo+cMCMY3HAwScZzzVmHwssVpaxLNtkV2+1Ouf9IQnJU557L9AMCpj4jRIZ pPsszpGdiNlQZpBgFAuc559OaqQeLBPOXa1lhs/3bJNwWYNGzkMucjG0/lQA5/DV00hP2qMl1kUT EN5luWeRsx4PUhwD/ujr0qO18LXFvBYIs0Y+zXBmbczSKB8vCqwxk7Tzxt3Ejvmw3iuONNzWFxuU M8qbk/doqK5brz8rA4HNaFpq8V1fXNr5bRfZ8cykKXBOAQvXaTwD0PagDRHSigdKKAPG1YLbKjxJ JA+d0TD5Sev4H3qe3Gnx7QVkEfVomUHPtkEcVpLoUt1p2+2QtkbtrMAy/wBKoDSr1Yy0kK7hwfmF X7dxTVyVhYzcXYpazrLfMIYivnJtklbG4j0AHAHHSptDvpbaKWWNPMO35UHG4ngfz/Kq7+HdS1KQ RxwoqEDMjOPl5/OmiCQamfDNozh05vpyQCVAztXnpz+NdMZJU0zKpC1ZpbJl/XNQGqeH79gwaOEI uVHBO4cj8f0rmtK0a41XmFIkjQ/PJIeOV6YHXnmul1uwGmeDLmJVIQyJkkgljn/61Yvhu9ZBLAD8 uQw/lWsJShQbW5vTStoSapp17p+htFbyTXcUDCFnSAOS+AenXisfwJLqt7rLIb2Wzt1nE8o2YaY9 NuT2x2rpLnUCLWwCPJGRevI5jbaSobH58YrOkuAt+18GKysSAw6rk9vSvKnSjq1uzrjWk7X6HPax od5f65qMsMJ8wytKYiApCk8EV2PwfJcaujsqYaJSrcdAa5y7Fx9rYRSku6l0J6HHVW9a6D4VtGV1 aclm3yx4IGOxzXRF3hy2MJaO56K3yNtV4AMjg1dkAngeGRo5EcsrKwyCD1zWdJPaeapMByWAFaKN B5xAi5JqY6MiTbRjz+GdOazKxWWno/8ACTCv+FYOp6Vb2mmF4V01GUc4iXn9K7yQQiLHl9KxdTit J7dg1pG/GGDDt7e9bQepk4qx5/LqEtlbPBBJaRQmLeyRoAGJHPGK59/GWopuWPVJY1QYRcAgD0HF b2sR2AkkiiiG7ygu4DA6cVxFxoc26QxhSvbmuirGSiuVGcY3Wp9QWpLWkLE5JRT+lTVlW2t6clrC pueRGoPyN6fSpf7d03/n5/8AHG/wrzzoNCis/wDt3Tf+fn/xxv8ACj+3dN/5+f8Axxv8KANCq91Z W19AYLuCOeInOyRdwqv/AG7pv/Pz/wCON/hR/bum/wDPz/443+FAEw02yVQotYQo6Dyxj7u3/wBB AH04pINMsba0a0gtIY7ds7olQBTnrkVF/bum/wDPz/443+FH9u6b/wA/P/jjf4UAMi8PaVDdxXMV lEjwIViAUbUyxYkDsST1p1noOmWNqLaCzi8sHJ3KCWOCCSe5wSPxNL/bum/8/P8A443+FH9u6b/z 8/8Ajjf4UAPfR9NkaVnsbdmlUK5MY+YDoDSppOnRNE0dlAphUJHiMfKo6AfnUf8Abum/8/P/AI43 +FH9u6b/AM/P/jjf4UASR6Tp8UXlR2UCJhhtEYxhvvfn3pw02zUyEWsQMrB5DsHzEHIJ+hAqH+3d N/5+f/HG/wAKP7d03/n5/wDHG/woAv0VQ/t3Tf8An5/8cb/CigD/2Q== ------=_NextPart_000_0238_01C7AD95.25F516E0-- --===============1186980182== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1186980182==-- From ecrit-bounces@ietf.org Wed Jun 13 08:37:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyS63-0006fT-6f; Wed, 13 Jun 2007 08:37:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyS62-0006cW-4z for ecrit@ietf.org; Wed, 13 Jun 2007 08:37:10 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyS60-00028U-Ex for ecrit@ietf.org; Wed, 13 Jun 2007 08:37:10 -0400 X-SEF-Processed: 5_0_0_910__2007_06_13_07_44_47 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 13 Jun 2007 07:44:46 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jun 2007 07:37:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Wed, 13 Jun 2007 07:37:01 -0500 Message-ID: In-Reply-To: <023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives Thread-Index: AceqV4ZeonTtWSgmTEKwTanATYJDUQCpIGKwAA63d4AABo3GsAAO+O4AAAphx5AAABwDcA== References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com> <012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com> <023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , X-OriginalArrivalTime: 13 Jun 2007 12:37:06.0708 (UTC) FILETIME=[8D72CD40:01C7ADB7] X-Spam-Score: 0.2 (/) X-Scan-Signature: 03798b51c5f8a7e89d7f7972440c2a03 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0165662729==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0165662729== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C7ADB7.8D3CC210" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7ADB7.8D3CC210 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7ADB7.8D3CC210" ------_=_NextPart_002_01C7ADB7.8D3CC210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OK, well neither did I. I didn't understand where the proposition of=0D=0A"= both" came in with respect to LoST. I only know of reverse-lookup as=0D=0Ab= eing discussed as a potential LoST function.=0D=0A=0D=0A=20=0D=0A=0D=0AI am= suggesting that, as yet another possibility and in the spirit of=0D=0Anot = just giving up (and saying, we've looked after VSP operator=0D=0Ainterests = but we won't worry about the LIS operators so much) is that=0D=0Avalidating= a PSAP URI could also be a forest guide function.=0D=0A=0D=0A=20=0D=0A=0D=0A= Cheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A_______________________= _________=0D=0A=0D=0AFrom: Brian Rosen [mailto:br@brianrosen.net]=20=0D=0AS= ent: Wednesday, 13 June 2007 10:31 PM=0D=0ATo: Dawson, Martin; ecrit@ietf.o= rg=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D= =0A=0D=0A=20=0D=0A=0D=0AI don't see any changes needed in LoST for forest g= uides. =20=0D=0A=0D=0A=20=0D=0A=0D=0ABrian=0D=0A=0D=0A=20=0D=0A=0D=0A______= __________________________=0D=0A=0D=0AFrom: Dawson, Martin [mailto:Martin.D= awson@andrew.com]=20=0D=0ASent: Wednesday, June 13, 2007 3:38 AM=0D=0ATo: B= rian Rosen; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3 - su= mmary of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0AI wasn't suggesting they we= re an identical level of definition. I was=0D=0Asaying that it's still not = definitive solution; of course it's a matter=0D=0Aof degree. Without a defi= nitive forest guide solution, how does a VSP=0D=0Aknow how to find the righ= t LoST server to find the PSAP URI=3F At least=0D=0Awith option 3, the PSAP= URI is provided at the point of local knowledge=0D=0Awhere the applicable = LoST server is known.=0D=0A=0D=0A=20=0D=0A=0D=0APull your last comment apar= t for me... are you saying that the "forest=0D=0Aguide" implementation requ= ires changes to LoST=3F Without those changes,=0D=0Athe Forest Guide won't = work either=3F=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D= =0A=20=0D=0A=0D=0A________________________________=0D=0A=0D=0AFrom: Brian R= osen [mailto:br@brianrosen.net]=20=0D=0ASent: Wednesday, 13 June 2007 10:28= AM=0D=0ATo: Dawson, Martin; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Propo= sals 1 and 3 - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0AI'm sorry = but the forest guide idea is a whole lot more developed that=0D=0Aany notio= n of an authoritative list of PSAP URIs. I'm not saying it=0D=0Acan't be d= one, I'm saying we need a whole lot more work on it to make it=0D=0Areal, a= nd it's not at all clear to me that the reverse lookup idea has=0D=0Amore o= r less merit. However, both of them are beyond what I think is=0D=0Aapprop= riate for LoST at this point.=0D=0A=0D=0A=20=0D=0A=0D=0ABrian=0D=0A=0D=0A =0D= =0A=0D=0A________________________________=0D=0A=0D=0AFrom: Dawson, Martin [= mailto:Martin.Dawson@andrew.com]=20=0D=0ASent: Tuesday, June 12, 2007 5:19 = PM=0D=0ATo: Brian Rosen; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Proposals= 1 and 3 - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0AWell hand wavi= ng was about all I could invest in an email, but are you=0D=0Asaying you'd = just have to give up at that stage=3F What is a reference to=0D=0Aa "forest= guide", if it's not a particularly low-detail suggestion of=0D=0Athe sort = of thing we need to resolve the right LoST server=3F Yet, without=0D=0Athat= , option 1 doesn't work. Why wouldn't this "validation" be a=0D=0Afunction = of that system and why is reverse lookup the only option=3F=0D=0A=0D=0A=20=0D= =0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A______________= __________________=0D=0A=0D=0AFrom: Brian Rosen [mailto:br@brianrosen.net] =0D= =0ASent: Wednesday, 13 June 2007 12:18 AM=0D=0ATo: Dawson, Martin; ecrit@ie= tf.org=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3 - summary of perspective= s=0D=0A=0D=0A=20=0D=0A=0D=0AI think those of us pushing for Option 1 for no= w is that we think VSP=0D=0Avalidation is a fact of life we have to deal wi= th, waving hands over=0D=0A"reference to a relatively static table maintain= ed by global=0D=0Acooperation" is not adequate, and something like a revers= e lookup is=0D=0Arequired. This would be a change to LoST and we are reluc= tant to take=0D=0Athis change on at this time.=0D=0A=0D=0A=20=0D=0A=0D=0ABr= ian=0D=0A=0D=0A=20=0D=0A=0D=0A________________________________=0D=0A=0D=0AF= rom: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20=0D=0ASent: Tuesday= , June 12, 2007 10:08 AM=0D=0ATo: ecrit@ietf.org=0D=0ASubject: [Ecrit] Prop= osals 1 and 3 - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0AFor some = reason this hasn't made it through moderation. Now I'm a list=0D=0Asubscrib= er, I'll try again...=0D=0A=0D=0A=20=0D=0A=0D=0AIt's a long weekend in Aust= ralia and winter has finally hit - with cold=0D=0Awind and rain. What bette= r time, then, to spend some time catching up=0D=0Awith the action on the EC= RIT list. I only went back a couple of weeks;=0D=0Aobviously the main topic= has been to do with the question of how to=0D=0Adefine the "location hidin= g" capability. Mostly it's a debate about the=0D=0Autility of option 1 and = 3.=0D=0A=0D=0A=20=0D=0A=0D=0AHaving just read through all the postings and = while they are fresh in my=0D=0Amind, here is how I characterize the perspe= ctives. First my summary of=0D=0Athe options...=0D=0A=0D=0A=20=0D=0A=0D=0A*= =09Option 1 achieves location hiding, somewhat oxymoronically, by=0D=0Aprov= iding location. Whether it's by reference to the local LoST facility=0D=0Ao= r by some internal knowledge, the LIS generates a coarse location which=0D=0A= it knows will result in a correct PSAP URI resolution if/when another=0D=0A= party makes a request to the LoST facility. This is provided in addition=0D= =0Ato a location reference for subsequent accurate location requests from=0D= =0Athe PSAP for dispatch etc.=0D=0A*=09Option 3 achieves location hiding by= making the request to the=0D=0Alocal LoST facility using the end points lo= cation and providing the PSAP=0D=0AURI that the LoST service returns (in ad= dition to a location reference)=0D=0Aso the call can be routed to that PSAP= - whether directly from the=0D=0Adevice or via a proxy/VSP.=0D=0A=0D=0A =0D= =0A=0D=0ABoth suggestions are based on an assumption that a LIS, being asso= ciated=0D=0Awith the local jurisdiction, has enough local knowledge to iden= tify the=0D=0Acorrect LoST service for that jurisdiction or, at least in th= e case of=0D=0Aoption 1, to determine what "coarse location" isn't too coar= se.=0D=0A=0D=0A=20=0D=0A=0D=0APerspective 1 - articulated by a lot of peopl= e, Ted, Brian, Andy,...=0D=0Aetc. is that LoST needs to progress and get to= a first release and=0D=0Achanges associated with this particular use case = should be avoided for=0D=0Anow. I haven't seen anything in either proposal = that does require a=0D=0Achange to LoST. In the one case either or both of = the LIS and VSP/proxy=0D=0Amake LoST queries but neither options appears to= *dictate* a specific=0D=0Achange to LoST.=0D=0A=0D=0A=20=0D=0A=0D=0APerspe= ctive 2 - articulated by, for example, James W and Barbara is that=0D=0Athe= LIS operator should have the option of providing location or not - a=0D=0A= "coarse location" is still a location and location information to the=0D=0A= granularity of PSAP boundaries, for example, could still support a lot=0D=0A= of value-added services and be used for other than emergency services.=0D=0A=0D= =0A=20=0D=0A=0D=0APerspective 3 - articulated by, for example, Andy and Lau= ra is that,=0D=0Awhen the end-point initiates a call through the VSP/proxy = with a=0D=0Apre-determined PSAP URI, the proxy may not know that this reall= y is a=0D=0Agenuine emergency call destination. In fact it could be used to= call=0D=0Aanyone by just pretending it's an emergency call. This means the= VSP may=0D=0Alose call revenue through the fraudulent nomination of emerge= ncy calls.=0D=0A=0D=0A=20=0D=0A=0D=0APerspective 4 - articulated by, in par= ticular, Hannes (sorry Hannes, I=0D=0Acan't see anyone else emphasising thi= s point) is that all emergency=0D=0Acalls should go through a VSP so that t= here's an authenticated=0D=0Asubscriber identity to be associated with the = call. This seems like an=0D=0Aorthogonal point to me. If we accept that som= e calls will go through=0D=0AVSPs and therefore Perspective 3 is valid then= the question of whether=0D=0Aall emergency calls have to go through a VSP = is moot. I have to admit to=0D=0Abeing really surprised by the perspective = - it wasn't one that I thought=0D=0Ahad any currency in this forum.=0D=0A=0D= =0A=20=0D=0A=0D=0A=20=0D=0A=0D=0AThere were miscellaneous other perspective= s including some good=0D=0Asuggestions for alternatives/compromises from Ri= chard and Henning.=0D=0A=0D=0A=20=0D=0A=0D=0AMartin D's perspective -=0D=0A=0D= =0A=20=0D=0A=0D=0A*=09On perspective 1, I don't see any impediment to pushi= ng LoST=0D=0Aout. Even if there are changes to come, they can be done in a = revision=0D=0Aor whatever. But I haven't seen any definitive statement abou= t how=0D=0Aeither option *requires* a change to LoST.=0D=0A*=09On perspecti= ve 4, I don't think it's decisive in the discussion.=0D=0A*=09So, really, i= t boils down to an evaluation of which of=0D=0Aperspectives 2 and 3 are the= most valid - i.e. are the interests of the=0D=0ALIS operator or a VSP to h= ave priority.=0D=0A=0D=0A=20=0D=0A=0D=0AI don't understand why the interest= s of LIS operators and VSPs can't=0D=0Aboth be served. I'm surprised that w= ith all the experience and knowledge=0D=0Ain the forum that nobody can prov= ide a practical way for a proxy/VSP to=0D=0Adetermine whether a PSAP URI is= a valid emergency destination or not. I=0D=0Aknow that adding the reverse-= lookup to LoST has been discussed. That=0D=0Awould be effective, but it's n= ot in keeping with perspective 1. Surely,=0D=0Athough, there are alternativ= es.=0D=0A=0D=0A=20=0D=0A=0D=0AI think option 3 supports a faster and smooth= er deployment of global=0D=0Aemergency calling for VoIP. Here's my rational= e.=0D=0A=0D=0A=20=0D=0A=0D=0A1.=09Both options require a LoST and LIS capab= ility to exist at a=0D=0Alocal and jurisdictional level - so their availabi= lity is a premise in=0D=0Aeither proposal=0D=0A2.=09Option 1 assumes that e= ach VSP can make an effective LoST query=0D=0Aeven if it is a "non-local" V= SP to the point from where the call is=0D=0Abeing originated. This is eithe= r by the VSP automatically knowing which=0D=0ALoST server is applicable to = the coarse location or by the use of the so=0D=0Acalled forest guide and pe= rhaps some international hierarchy of=0D=0Ainterconnected LoST servers.=0D=0A= 3.=09Option 3 only assumes that this local knowledge is in the local=0D=0AL= IS function and doesn't rely on the existence of the infrastructure=0D=0Ade= scribed in point 2.=0D=0A4.=09The ability to verify a destination PSAP URI = as a valid=0D=0Aemergency URI could be supported by reference to a relative= ly static=0D=0Atable maintained by global cooperation. In fact, I would hav= e thought=0D=0Athat filtering based on domain name would be extremely relia= ble and=0D=0Afast. It would certainly obviate the ability to make arbitrary= calls by=0D=0Apretending they are emergency calls.=0D=0A5.=09Perhaps a lat= er revision of LoST can include the reverse-lookup=0D=0Amechanism and, perh= aps by then, the international infrastructure of LoST=0D=0Aservers, forest = guides, etc. may be in place.=0D=0A=0D=0A=20=0D=0A=0D=0AI mention point 4 a= s one possible way to protect the interest of the=0D=0AVSPs without requiri= ng a change to the current LoST definition. Are=0D=0Athere any other propos= als on how to achieve this or, alternatively, a=0D=0Aview that it simply is= n't possible=3F=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D= =0A=20=0D=0A=0D=0A Martin Dawson=0D=0A=0D=0AAndrew Network Solutions Asia-P= acific=0D=0A=0D=0AEmail: martin.dawson@andrew.com=0D=0A=0D=0APhone: +61 2 4= 2212992=0D=0A=0D=0AFax: +61 2 42212901=0D=0A=0D=0AMobile: +61 412 120300=0D= =0A=0D=0A=0D=0AThis message is for the designated recipient only and may co= ntain=0D=0Aprivileged, proprietary, or otherwise private information. If yo= u have=0D=0Areceived it in error, please notify the sender immediately and = delete=0D=0Athe original. Any unauthorized use of this email is prohibited.=0D= =0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A=0D=0A------------------------------= ------------------------------------------=0D=0A------------------------=0D= =0AThis message is for the designated recipient only and may=0D=0Acontain p= rivileged, proprietary, or otherwise private information. =20=0D=0AIf you h= ave received it in error, please notify the sender=0D=0Aimmediately and del= ete the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D= =0A------------------------------------------------------------------------=0D= =0A------------------------=0D=0A[mf2]=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D= =0A=0D=0A------------------------------------------------------------------= ------=0D=0A------------------------=0D=0AThis message is for the designate= d recipient only and may=0D=0Acontain privileged, proprietary, or otherwise= private information. =20=0D=0AIf you have received it in error, please not= ify the sender=0D=0Aimmediately and delete the original. Any unauthorized = use of=0D=0Athis email is prohibited.=0D=0A--------------------------------= ----------------------------------------=0D=0A------------------------=0D=0A= [mf2]=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A=0D=0A----------------------= --------------------------------------------------=0D=0A-------------------= -----=0D=0AThis message is for the designated recipient only and may=0D=0Ac= ontain privileged, proprietary, or otherwise private information. =20=0D=0A= If you have received it in error, please notify the sender=0D=0Aimmediately= and delete the original. Any unauthorized use of=0D=0Athis email is prohi= bited.=0D=0A---------------------------------------------------------------= ---------=0D=0A------------------------=0D=0A[mf2]=0D=0A=0D=0A=20=0D=0A=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0AThis message is for the designated recipient onl= y and may=0D=0Acontain privileged, proprietary, or otherwise private inform= ation. =20=0D=0AIf you have received it in error, please notify the sender=0D= =0Aimmediately and delete the original. Any unauthorized use of=0D=0Athis = email is prohibited.=0D=0A-------------------------------------------------= -----------------------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_002_01C7ADB7.8D3CC210 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A

I don’t understand how this = would work.  The forest guide thing doesn’t need any more protocol function than we have already.  There is no function I know of in = LoST that would accept a URI as a query and return anything resembling or = computable to a Boolean (valid) in response.  That’s some kind of = protocol mechanism.  Whether the implementation of that is reverse lookup or flooding or some other mechanism would have to be invented, and using = some of the forest guide ideas may work, but it’s quite a stretch from = where we are now, and needs a new protocol mechanism of some = sort.

 

We can do that, but later, = please.

 

Brian

 

From: = Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Sent: Wednesday, June 13, = 2007 8:37 AM
To: Brian Rosen; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

OK, well neither = did I. I didn’t understand where the proposition of “both” came = in with respect to LoST. I only know of reverse-lookup as being discussed = as a potential LoST function.

 =

I am suggesting = that, as yet another possibility and in the spirit of not just giving up (and = saying, we’ve looked after VSP operator interests but we won’t worry = about the LIS operators so much) is that validating a PSAP URI could also be a = forest guide function.

 =

Cheers,

Martin=

 =

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, 13 June = 2007 10:31 PM
To: Dawson, Martin; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

I don’t see any changes = needed in LoST for forest guides. 

 

Brian

 

From: = Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Sent: Wednesday, June 13, = 2007 3:38 AM
To: Brian Rosen; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

I wasn’t = suggesting they were an identical level of definition. I was saying that it’s = still not definitive solution; of course it’s a matter of degree. = Without a definitive forest guide solution, how does a VSP know how to find the = right LoST server to find the PSAP URI? At least with option 3, the PSAP URI = is provided at the point of local knowledge where the applicable LoST = server is known.

 =

Pull your last = comment apart for me… are you saying that the “forest guide” = implementation requires changes to LoST? Without those changes, the Forest Guide = won’t work either?

 =

Cheers,

Martin=

 =

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, 13 June = 2007 10:28 AM
To: Dawson, Martin; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

I’m sorry but the forest = guide idea is a whole lot more developed that any notion of an authoritative list = of PSAP URIs.  I’m not saying it can’t be done, I’m = saying we need a whole lot more work on it to make it real, and it’s not at = all clear to me that the reverse lookup idea has more or less merit.  = However, both of them are beyond what I think is appropriate for LoST at this = point.

 

Brian

 

From: = Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Sent: Tuesday, June 12, = 2007 5:19 PM
To: Brian Rosen; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

Well hand waving = was about all I could invest in an email, but are you saying you’d = just have to give up at that stage? What is a reference to a “forest = guide”, if it’s not a particularly low-detail suggestion of the sort of = thing we need to resolve the right LoST server? Yet, without that, option 1 doesn’t work. Why wouldn’t this “validation” be = a function of that system and why is reverse lookup the only = option?

 =

Cheers,

Martin=

 =

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, 13 June = 2007 12:18 AM
To: Dawson, Martin; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

I think those of us pushing for = Option 1 for now is that we think VSP validation is a fact of life we have to = deal with, waving hands over “reference to a = relatively static table maintained by global cooperation” is not adequate, and something like a reverse lookup = is required.  This would be a change to LoST and we are reluctant to = take this change on at this time.

 

Brian

 

From: = Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Sent: Tuesday, June 12, = 2007 10:08 AM
To: ecrit@ietf.org
Subject: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

For some reason this hasn’t made it = through moderation. Now I’m a list subscriber, I’ll try = again…

 

It’s a long weekend in Australia and winter has = finally hit – with cold wind and rain. What better time, then, to spend = some time catching up with the action on the ECRIT list. I only went back a couple = of weeks; obviously the main topic has been to do with the question of how = to define the “location hiding” capability. Mostly it’s a = debate about the utility of option 1 and 3.

 

Having just read through all the postings and = while they are fresh in my mind, here is how I characterize the perspectives. = First my summary of the options…

 

  • Option 1 = achieves location hiding, somewhat oxymoronically, by providing location. = Whether it’s by reference to the local LoST facility or by some = internal knowledge, the LIS generates a coarse location which it knows will = result in a correct PSAP URI resolution if/when another party makes a = request to the LoST facility. This is provided in addition to a location = reference for subsequent accurate location requests from the PSAP for = dispatch etc.
  • Option 3 = achieves location hiding by making the request to the local LoST facility = using the end points location and providing the PSAP URI that the LoST = service returns (in addition to a location reference) so the call can be = routed to that PSAP – whether directly from the device or via a = proxy/VSP.

 

Both suggestions are based on an assumption = that a LIS, being associated with the local jurisdiction, has enough local = knowledge to identify the correct LoST service for that jurisdiction or, at least = in the case of option 1, to determine what “coarse location” = isn’t too coarse.

 

Perspective 1 – articulated by a lot of = people, Ted, Brian, Andy,… etc. is that LoST needs to progress and get to = a first release and changes associated with this particular use case should be = avoided for now. I haven’t seen anything in either proposal that does = require a change to LoST. In the one case either or both of the LIS and VSP/proxy = make LoST queries but neither options appears to *dictate* a specific change to LoST.

 

Perspective 2 – articulated by, for = example, James W and Barbara is that the LIS operator should have the option of providing location or not – a “coarse location” is = still a location and location information to the granularity of PSAP boundaries, = for example, could still support a lot of value-added services and be used = for other than emergency services.

 

Perspective 3 – articulated by, for = example, Andy and Laura is that, when the end-point initiates a call through the VSP/proxy with a pre-determined PSAP URI, the proxy may not know that = this really is a genuine emergency call destination. In fact it could be used = to call anyone by just pretending it’s an emergency call. This means = the VSP may lose call revenue through the fraudulent nomination of emergency = calls.

 

Perspective 4 – articulated by, in = particular, Hannes (sorry Hannes, I can’t see anyone else emphasising this = point) is that all emergency calls should go through a VSP so that there’s = an authenticated subscriber identity to be associated with the call. This = seems like an orthogonal point to me. If we accept that some calls will go = through VSPs and therefore Perspective 3 is valid then the question of whether = all emergency calls have to go through a VSP is moot. I have to admit to = being really surprised by the perspective – it wasn’t one that I = thought had any currency in this forum.

 

 

There were miscellaneous other perspectives = including some good suggestions for alternatives/compromises from Richard and = Henning.

 

Martin D’s perspective = –

 

  • On = perspective 1, I don’t see any impediment to pushing LoST out. Even if there = are changes to come, they can be done in a revision or whatever. But I haven’t seen any definitive statement about how either option = *requires* a change to = LoST.
  • On = perspective 4, I don’t think it’s decisive in the = discussion.
  • So, = really, it boils down to an evaluation of which of perspectives 2 and 3 are the most = valid – i.e. are the interests of the LIS operator or a VSP to have priority.

 

I don’t understand why the interests of = LIS operators and VSPs can’t both be served. I’m surprised that = with all the experience and knowledge in the forum that nobody can provide a practical way for a proxy/VSP to determine whether a PSAP URI is a valid emergency destination or not. I know that adding the reverse-lookup to = LoST has been discussed. That would be effective, but it’s not in keeping = with perspective 1. Surely, though, there are = alternatives.

 

I think option 3 supports a faster and = smoother deployment of global emergency calling for VoIP. Here’s my = rationale.

 

  1. Both = options require a LoST and LIS capability to exist at a local and jurisdictional = level – so their availability is a premise in either = proposal
  2. Option 1 = assumes that each VSP can make an effective LoST query even if it is a “non-local” VSP to the point from where the call is = being originated. This is either by the VSP automatically knowing which = LoST server is applicable to the coarse location or by the use of the so = called forest guide and perhaps some international hierarchy of = interconnected LoST servers.
  3. Option 3 = only assumes that this local knowledge is in the local LIS function and doesn’t rely on the existence of the infrastructure described = in point 2.
  4. The = ability to verify a destination PSAP URI as a valid emergency URI could be = supported by reference to a relatively static table maintained by global cooperation. In fact, I would have thought that filtering based on = domain name would be extremely reliable and fast. It would certainly = obviate the ability to make arbitrary calls by pretending they are emergency = calls.
  5. Perhaps a = later revision of LoST can include the reverse-lookup mechanism and, = perhaps by then, the international infrastructure of LoST servers, forest = guides, etc. may be in place.

 

I mention point 4 as one possible way to = protect the interest of the VSPs without requiring a change to the current LoST = definition. Are there any other proposals on how to achieve this or, alternatively, = a view that it simply isn’t possible?

 

Cheers,

Martin

 

Martin Dawson

Andrew Network Solutions = Asia-Pacific

Email: martin.dawson@andrew.com

Phone: +61 2 42212992

Fax: +61 2 42212901

Mobile: +61 412 120300


This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have = received it in error, please notify the sender immediately and delete the = original. Any unauthorized use of this email is prohibited.

 

 


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

 

 


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

 

 


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

 

 


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

 

------=_NextPart_001_02E5_01C7ADA0.FA25C3A0-- ------=_NextPart_000_02E4_01C7ADA0.FA25C3A0 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABfAPYDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1v7DZ /wDPpB/37X/Cj7FZ/wDPpB/36X/Cmahc3FrZvLa2jXcwwFiVgMk+57VxHiiLxQ+m+fe3SQrJIscd lZ5JYn1PU0m7HVhsP7eSTklfudlM2j28PnTfYo4/7zBAKxf+Es8KG5aEGAqqljKYAE47Djk1xEOg wW+oWFn4i1JbCS8IFvbEF5GycduF59a3LGPwN4fuL5r7UUuLnT3AnEqMREScABQOeeM81Cc3sjsq UMBRupVHJ+R1OlX1hrEjm30krbqPluJYFVZD6AHmtT7DZ/8APpB/36X/AArGXxx4ZGsDRzqkcd7u EYiZGUbjjAzjGeRTbfx94audXbSk1Efa1kaLa0bAF16gMRjPFaJM8ucot+6rI2/sVn/z6Qf9+1/w o+xWf/PpB/37X/Cudh+I/he4t5biO+kaGJlV3+zuACx2gZx61YHjvw41ylul/wCZK90bRUSJiWlG MgcdOevSnZkXRtfYrP8A59IP+/a/4UfYrP8A59IP+/a/4VNS0hkH2Kz/AOfSD/v2v+FH2Kz/AOfS D/v2v+FT0UAQfYrP/n0g/wC/a/4UfYrP/n0g/wC/a/4VPRQBB9is/wDn0g/79r/hR9is/wDn0g/7 9r/hU9FAEH2Kz/59IP8Av2v+FH2Kz/59IP8Av2v+FT0UAV2tLFFLNbW6qOpMagD9Kgtzo92zLbfY ZivURhGI/Ks+/t11nxGNOuvmsrS3Wd4c8TOxIG71AA6etRauPDFpcRrcslhc25V0lgjKMg9NyjGD 0IrRQ+8ydRrXobv2Kz/59IP+/S/4UfYbP/n0g/79L/hWZe+IfJvfsdjafbJVjWSQmZYlVW6DLdSf SlHiW3msLW4tIJbia7dkit1wG3L94E9ABjk0uSRXtI9zS+xWf/PpB/37X/Cj7FZ/8+kH/ftf8Ko2 utNJJcW95ZPaXcEXnGIuGDp6qw688e1Z8Hi24nSzcaHcD+0FzafvV+c4yd390Yyc+goUJMTqxRvf YrP/AJ9IP+/a/wCFH2Gz/wCfSD/v0v8AhWYPEsSaTLez20kc0M/2Z7YMC3m5ACg9Ocjn0qOLxDJO bi0lsjb3q27TRRrOriQD0YdCDjrQoSD2sDX+w2f/AD6Qf9+l/wAKPsVn/wA+kH/ftf8ACue07xBe QaBpTT2EtxdXh8uMeauXO3O4nsDitESRv4gsjPbSR3r2bsMS5RBkZUgcE5PWhwa3BVItaGh9hs/+ fSD/AL9L/hSfY7IEA2tvk9B5a8/pWWnieN50svscv9omfymtNwyi9fMJ6bMc5/Csu6iZ9Q33MwTa 3+kAt8+dxxsHUjbtxj1701B9ROqump1P2Kz/AOfSD/v0v+FFFl532GD7RnzfLG/Priis27GqZJ5k f/PRP++hRviyMunHT5hxXjl1fzx6jOgcgBzgVuaPdF4fnwx98Vs6TSuZe01DW/AOta14pk12TVrB WS6ia3iOTsiQ5A3dj7AYOaoXfwmvb7VpNSn1S082fUWnnUO21oSwIXp97r7Ve1SXywjA4GD0+tYE l5LNcYEjAZ7GlGLZHtE3axtf8K21W61y4nvtV09bGbUPtxSMEykjOxdx6D1qDS/hhqljfte3Gp2F y7JOyq0jbYp3BCyLxzjvmtDQmJlO87vl7jNdN+5AzsT/AL5FDTWlzSPKzi7P4Zanb+DtR0R9Q04T 3DxPDKsjkAqxJ3Z6dewqbw98MJ9B8QDVI9Ss5fIhH2dXJbExUBnI9PvY/CuneeIMAI4z/wABFIZY /tZGyPHptFK0g0udKkq7F3yx7sDOGGM0vmx/89E/76FYUqxbf9Wn/fIrA1S3LD5OMv2wO1EYczKb sd75kf8Az0T/AL6FJ5kf/PRP++hXAG0f7B3z61NpCG3glmlXzAilsNjsKp0rK9xc53Pmx/8APRP+ +hR5sf8Az0T/AL6Fchaa7p04G6EJ7hAwqxqGr2Fnpz3MKQysOFTaBk1Eo8quwU7uyOn82L/nqn/f Qo82L/nqn/fQrkvC2qTauZo72zgRk5R1jADCukW3g/54Rf8AfAqVZq6KbsWfNi/56p/30KPNi/56 p/30KUWtvj/URf8AfAo+y2//ADwj/wC+BSGZWp2Lz3cWo6deQ297CpTMhykqE52sOvXkEdKqXFpq 2sxi11KewtLMkecttIXeYA525IG0H866D7Lb/wDPCP8A74FH2W3/AOeEf/fAqlNoh00zm9T0Vm1a S/tINMu1njVHivDjYV4DKQDxjqPapP7IuLe1sZbS5shfWZclQoSGQP8AeXA6dufaug+y2/8Azwj/ AO+BR9lt/wDnhH/3wKftGT7KJiQWV3c3U9/qM1ok72zW8MUMhKxg8klj1JOO3amW+lSwx+H1a4ty dLQrNh/vfutny/j61vfZbf8A54R/98Cj7Lb/APPCP/vgUudj9nE5y40A3NjfxNc23mTagbyDd8yd FwHH4EH607TdMliuJbieDSrPMLRpHaAEkn+IsQCB7Cuh+y2//PCP/vgUfZbf/nhH/wB8Cn7SVrC9 lG9zCttKkhtdDia4gzpxzLh+G+Ujj8TVye2L67BqCSwlIraSLaXwSxII/DitH7Lb/wDPCP8A74FH 2W3/AOeEf/fApczK5FaxzS6JeJcLrAv4G1gyfvMufJaL/nl64A5BxnNdFugLBmaIsOhJBI/Gn/Zb f/nhH/3wKPstv/zwj/74FDk3uEYKOwnmxf8APVP++hRS/Zbf/nhH/wB8CiosWeLX0WdWn/3zWpp8 UygbYnx6hDVp5FMZu/8AUGQ4CQINzE9gepP40+b/AEWB7h5ppAmCAHyTnpXdzp6HM49SDWI2FnGW BBweox3rmbZ8XB+td3p1ymr2YEjvGASu1mDfzqLV/Cuk2tqb3zGhf+9kBCT0yPr6VN7CjEp6RJtL t6JWq9/8nXtWNaq1nKIpo8hk5eM5VvUr7VvjR7WW1WWN5iWxxxxRJX1Ki+hnrclmzmpZrjZeZz3q oIZEnZfs7hQepPXn19alnALb8kE84pS91alJOWxtCfzEXnrUjWfnRrx3rlW8SS2pKiCJsdNxNTwe O7tYyDY2/HfLf40lGT+EptLc6s2A+zbMVUktfs2nXJx/yzb+Vc6vxCv2k2fYLYZ92/xqzN4pu7u0 nhe0gAaJskE/3TT5Kii20F4t6FGw8J6b9oV8yxfvAxMUpGc/w+5qHXRZ2+py6ZZah9oaIjzonbcY ie2R+VUW8af8I7pPm7g92yYgiABBPck8dKxvhmLi+8SXl5OpcSgvJM3RWJznNZVpqUUkTSpNT1PU /DivDbx2uwKduV4wVI7GrttqjSXL275jnUnMUq4bHqPUe9ePa18Q9UmN3bWEiwRFmjWdf9YyA4zn tnrxWv4I8UXd/d6ZDevNdTws6CZjuJRgOCe+MVpCHQK1VN+6e0joKWkHQUtcxsFZ2p6xFpbRLNBd SecwVTDCXG49Bx0NaNVb2xS+EG92XyJ1mGO5XtQBBZ65p95DPItykZtnZJlkcBo9rFfmGeOnerE9 /bQ2YuzKGibGwx/NvJ6BcdSe2KzLvwva3cTRyTPgmQjKgjLzLLyO4DKBj0qwuhwppMOno5QQEPHI qgbXB3BgOnXtQBPFq1o0Uckzm1MknlrHcjy2LegB6/hSjV9MaYwDULUyiTyygmXdv/u4z146VRuv D8l9EgutRlkk2vHI4jUb42KkqBj5furz16+tEnhq3dWBnkG5ZAcAfxzeae3rx9KALUmt2AZFhuY5 y04gYQuG2Mc/e546GkbXdMS4toDfQF7pmSLbICGZcZGfXkVm2XhTaga8vGkkWQlRGoVVTe7Bff75 5pLfwbZ2tottHMygFgxRFXcjJsKn324560AbMmp2aadPqCzrNbwIzu0J38KMnGOp46VUt/EulXLS 7LtVWGKOWR5PlRQ+do3HjPHI6jio7Tw5b2WiXWmRyYW6Vld0jVSMrtyAO+AOtE3hu2MxmtJTaygq 6lFBCuGdi2D1z5jcfT0oAnXXLFrq7tRcJ51qgcoZFBZdobcMnpg9TxUtvq1nOdpmWJzM8KpIwDOy HBwM89Ky/wDhEIAjQC8m+zGPYse1cq3kmHduxk/KTx0zT5PCdm+oQ3jSFnjkaTDIrdZDIAM9MMet AG/RSDpRQB5mYPLVp3bMdsAqIgyyuRyx7cf1pIY7WSAAQyM7MA7NJyQOAOBjFRxRy3UZWCDELZEY DYI5yc+uf6CqxubmCfy9qRgHADOqn8ic10wptq63OOrVjDcyPFNzBp+tRxQ3ctlIIVYBl3RHOepX kfkapr4mvVYWOtkz206/IdwKEeqEcVe8R6WdRvkurgFGMQUA9wPSqll4We5srhFPmWoG503fMh/v p7j9RwafLUjqVGcJLQ0NFW5s9Rh0+e7MmmP+8t2CZbP1HIIB+hr0O3nit7aKJnViwGM8ZHrXCaJ9 r0XSt+pKoisZNn2huhVuhHfB4/OrM3inSZypk1CJDEcqSSAVPUfh1/Omo3Wg767HcCO1kI2lCa52 +mgMpiUksOOBxWXD4u0SzugW1eAMOMEnj8xWU/ibSzqZnOs24j3FlK559jxXNzSbdzoStsP1Oxn8 wkYGfXiobexeKHdPNGilupbqfb1qxP4p0S6kAbUoAT/EoO0/pxVU+b4gMj6Oz3KW7bXAIIQnpj2N dFOo7GVRPsW4NPSe4DLcwHnpuxW1YWTWt2kbiGWU5xCzcOcHAPsaoWGiauY0ZrOTjqcVNptpNb+I o5pVIERBIzk9DW0qnu2uZxiyp490ee8h0ltTmt4ovtaxGK2jCpCrjH3jyeQKxfFmvadoek/8Iv4f ZMv/AMfs0bZ4/uZ7k9/yrf8AE2oy3Tzo8QZUXlMZCj/GuCuNBtLqQGzdomc524yprCdL3rrcVOva LTLHg3TIr65nvbgL5NmoYoRnzCeMVt/Dqe207xNPZ3KglJDsH48EVf8AC2kWGm2k1tJc+ZNu2zKw wOVyMVc0/wAMWA1l55lLTXCFYpQxAVsfKR75FbyShBP7zGN5z5F8j1lTkA+1OqtFcxLJHZtJ/pHk +ZtxyVGAT+ZqwTivPPRMG68Q/YrvVYZJIpJbfY1vblgrMpQEnHUgHJJ9Aahi8TzO9urx2yq+7dJv YrNhtv7rAO49/p+db8lzBHIEZh5m3eEAyxXIGcDnqRUnHp09qAOLbxdf3Q8yOO3ihieRJcvzIPL3 oARna/UYPOe1XH8U3aGeOO1iZo1GxWcllOUAL8fdbfkeu011GRnGP0pGdUVnbgKMk47UAZD6ldS6 BcXAeG1uIZHiZ2PyAq+0kEjgHBwSCBnJyBWdH4nnit7XH+lCRmy8u1WkwwXahT5Xb5s5HBAPvXTw zxXNvHPE2+OVA6NjqCMg07gduntQByUXiS7gtFtfkkvJTthaVuZMtJyFA5C7F6etMh8VXkdiJpI7 eWbau+TzCIyfL3FV44Yn5QPXNdjx1xUUdzBLPLAjBpICPMXH3SRkfpQBk6frd1d6o1tNbJHC7SiJ lJ3Dyyud2Rjnd29KzU1zUbDzZLlYpmlupwgLsAVjk2CNBj75HIHfBNdbkUcHGRQBmWOpXM9ndXlz CkcMTyiNYtzuyozKSRjqduQBXPp4kv8AUVhkXEBSQxuIXDo/7225BGf4ZGHX1rsUkWRdyhgOeqkd D70oIA4GPwoAWiiigDza3kl0vwpLfXSBbhAwAXquTx+PNcXaade3iPPHaSzAklmVc810niLURdeE 7OcMQbnarr6Fc5zVTRtUSys0WVGZYmLIFA5zzyeo5HWvXoqUabkkfPYlxlUUW9COGQLDDazE+Q4w QeqH+8PTH8q0dDheFZ0ByVBVxnv0rK1K3urowJEMPPiQkfwqT1PpxzV3wvZyTa+90kuY2nLbWBGV z3/Cs5zu9jvow5YoXXZs/D+6BXB3qgY9eGBH868ru4migaWSRnYdB717D4ytoW8IXaRYAZ0IQ9SQ wBNeZT2CvayRswGV6DrkNiphBygz0KeqN6T4R6hLpw1GXWrYmSIOFIO7JAOK4hraXTL+Wxu0BdOm On1FexyXmpLYO0NxGLWCBQgYhucAZAI4/WuIbwve+IfELTmZHESj7QzP0/uqOOWIrwsPiZ+0fO9D 0qmGSheO5ybN1xxXpXwjJOn6yoHLSRDPpw2K85mAjZlIwynBFemfBpW+y6xIo5WSLOT04NepX+Fs 5IL3j1OHTYBaCKUFgRzg4zXPP4Y/smW8vbOdVRgXRCpJQ4/XmtR/ElpBMIZg4bIGVBIzUmp3Ulto uoXJUN5ETsoPfArkg1JryCcJQTueZX0oZvsURJkwXkJPJPXmqOkWYaX7QVyFGfbNYsN9LEJbwkmW UlixPr1rZsNchaxX7PGyoUG4t13d/wAK9BVU53fQ8nk0HW87LdyyHC/6SM88noK6N75oYQNp3QNu BFctYW5u9JuryP5tkjkn3ABrtIbCO5jV2OPMUEH1yKdOfNCzFKNppo6zVdHm1SVLmOSIDyFQxyA7 Xw6vhsfwkDBqsnhu8iaMi6gd1txGs0iMzQkBuEGcbTuHX0HBro4hiJB6KKfXCekcbD4LnjjjJmt/ OXzEVjuYxIzKwCt16qfT7xq0PCskk8huZoZIXnV3QqT5wDlvnz1PIX6CuooxQBz8vh+eXQvsJ1CZ pfKSM/ORGwVgcY6jIG0nng9Khh8LPG8MgnTzoY4UVzuZlVWcuoJ5wQ4H0H4V01UdW1OPSrI3DRPM xO1Yo+XfucDvgAn6A0Ac9N4PuE0Y6daXMMSMkQ2AFV3qhUsMdCWw3HXFWG8LTZnkS8RZrgOJZADm QFUADHuBtP8A31VgeK7TMjtbzi3VNyTfL85ESy425yPlYde9TWGsSvp9/eX8It/ss7p5ZYZAAGAS OCTn9aAM+LwrcDU4bw3EcAjj2iO3Z1WH73CDPIO4eg4HFWtE0CbTLW+ikaANc7QPs5ZM4TbuJ6hj 1JFJD4rhnMOLG5RWO2UuAphJk8oAgnJ+b0HvUMviovBHKltJb7j5h8zaxaIxysGXBxnMR4P9aAIo vCVyjaYz3aYs2J2Rkoo+cMCMY3HAwScZzzVmHwssVpaxLNtkV2+1Ouf9IQnJU557L9AMCpj4jRIZ pPsszpGdiNlQZpBgFAuc559OaqQeLBPOXa1lhs/3bJNwWYNGzkMucjG0/lQA5/DV00hP2qMl1kUT EN5luWeRsx4PUhwD/ujr0qO18LXFvBYIs0Y+zXBmbczSKB8vCqwxk7Tzxt3Ejvmw3iuONNzWFxuU M8qbk/doqK5brz8rA4HNaFpq8V1fXNr5bRfZ8cykKXBOAQvXaTwD0PagDRHSigdKKAPG1YLbKjxJ JA+d0TD5Sev4H3qe3Gnx7QVkEfVomUHPtkEcVpLoUt1p2+2QtkbtrMAy/wBKoDSr1Yy0kK7hwfmF X7dxTVyVhYzcXYpazrLfMIYivnJtklbG4j0AHAHHSptDvpbaKWWNPMO35UHG4ngfz/Kq7+HdS1KQ RxwoqEDMjOPl5/OmiCQamfDNozh05vpyQCVAztXnpz+NdMZJU0zKpC1ZpbJl/XNQGqeH79gwaOEI uVHBO4cj8f0rmtK0a41XmFIkjQ/PJIeOV6YHXnmul1uwGmeDLmJVIQyJkkgljn/61Yvhu9ZBLAD8 uQw/lWsJShQbW5vTStoSapp17p+htFbyTXcUDCFnSAOS+AenXisfwJLqt7rLIb2Wzt1nE8o2YaY9 NuT2x2rpLnUCLWwCPJGRevI5jbaSobH58YrOkuAt+18GKysSAw6rk9vSvKnSjq1uzrjWk7X6HPax od5f65qMsMJ8wytKYiApCk8EV2PwfJcaujsqYaJSrcdAa5y7Fx9rYRSku6l0J6HHVW9a6D4VtGV1 aclm3yx4IGOxzXRF3hy2MJaO56K3yNtV4AMjg1dkAngeGRo5EcsrKwyCD1zWdJPaeapMByWAFaKN B5xAi5JqY6MiTbRjz+GdOazKxWWno/8ACTCv+FYOp6Vb2mmF4V01GUc4iXn9K7yQQiLHl9KxdTit J7dg1pG/GGDDt7e9bQepk4qx5/LqEtlbPBBJaRQmLeyRoAGJHPGK59/GWopuWPVJY1QYRcAgD0HF b2sR2AkkiiiG7ygu4DA6cVxFxoc26QxhSvbmuirGSiuVGcY3Wp9QWpLWkLE5JRT+lTVlW2t6clrC pueRGoPyN6fSpf7d03/n5/8AHG/wrzzoNCis/wDt3Tf+fn/xxv8ACj+3dN/5+f8Axxv8KANCq91Z W19AYLuCOeInOyRdwqv/AG7pv/Pz/wCON/hR/bum/wDPz/443+FAEw02yVQotYQo6Dyxj7u3/wBB AH04pINMsba0a0gtIY7ds7olQBTnrkVF/bum/wDPz/443+FH9u6b/wA/P/jjf4UAMi8PaVDdxXMV lEjwIViAUbUyxYkDsST1p1noOmWNqLaCzi8sHJ3KCWOCCSe5wSPxNL/bum/8/P8A443+FH9u6b/z 8/8Ajjf4UAPfR9NkaVnsbdmlUK5MY+YDoDSppOnRNE0dlAphUJHiMfKo6AfnUf8Abum/8/P/AI43 +FH9u6b/AM/P/jjf4UASR6Tp8UXlR2UCJhhtEYxhvvfn3pw02zUyEWsQMrB5DsHzEHIJ+hAqH+3d N/5+f/HG/wAKP7d03/n5/wDHG/woAv0VQ/t3Tf8An5/8cb/CigD/2Q== ------=_NextPart_000_02E4_01C7ADA0.FA25C3A0-- --===============0107646357== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0107646357==-- From ecrit-bounces@ietf.org Wed Jun 13 10:06:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyTUg-0003Wq-FV; Wed, 13 Jun 2007 10:06:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyTUe-0003Wf-Su for ecrit@ietf.org; Wed, 13 Jun 2007 10:06:40 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyTUc-0001aQ-Uq for ecrit@ietf.org; Wed, 13 Jun 2007 10:06:40 -0400 X-SEF-Processed: 5_0_0_910__2007_06_13_09_14_18 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 13 Jun 2007 09:14:17 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jun 2007 09:06:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Wed, 13 Jun 2007 09:06:33 -0500 Message-ID: In-Reply-To: <02e301c7adc2$813763a0$9501a8c0@cis.neustar.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives Thread-Index: AceqV4ZeonTtWSgmTEKwTanATYJDUQCpIGKwAA63d4AABo3GsAAO+O4AAAphx5AAABwDcAACwHSQAAA8QlA= References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com> <012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com> <023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com> <02e301c7adc2$813763a0$9501a8c0@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , X-OriginalArrivalTime: 13 Jun 2007 14:06:37.0480 (UTC) FILETIME=[0EAD9280:01C7ADC4] X-Spam-Score: 0.2 (/) X-Scan-Signature: d0fac514cb168268a385dddd1f66d312 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1477529782==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1477529782== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C7ADC4.0E6DF93C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7ADC4.0E6DF93C Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7ADC4.0E6DF93C" ------_=_NextPart_002_01C7ADC4.0E6DF93C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I understood that "later please" was a request with respect to LoST...=0D=0A= which is why I'm avoiding it.=0D=0A=0D=0A=20=0D=0A=0D=0AOption 1, as I unde= rstand it, can't work at all until the forest guide=0D=0Adefinitions are co= mpleted and, in fact, until the actual forest guide=0D=0Asystem/network is = *implemented*. So I'm suggesting that the URI=0D=0Avalidation be added to t= he, still in development, forest guide=0D=0Aspecification.=0D=0A=0D=0A=20=0D= =0A=0D=0AIn the mean time, option 3 works regardless and, as the URI valida= tion=0D=0Abecomes available through the forest guide network, then the issu= e of=0D=0A"pretend" emergency calls is obviated as well.=0D=0A=0D=0A=20=0D=0A=0D= =0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A____________________= ____________=0D=0A=0D=0AFrom: Brian Rosen [mailto:br@brianrosen.net]=20=0D=0A= Sent: Wednesday, 13 June 2007 11:55 PM=0D=0ATo: Dawson, Martin; ecrit@ietf.= org=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D= =0A=0D=0A=20=0D=0A=0D=0AI don't understand how this would work. The forest= guide thing doesn't=0D=0Aneed any more protocol function than we have alre= ady. There is no=0D=0Afunction I know of in LoST that would accept a URI a= s a query and return=0D=0Aanything resembling or computable to a Boolean (v= alid) in response.=0D=0AThat's some kind of protocol mechanism. Whether th= e implementation of=0D=0Athat is reverse lookup or flooding or some other m= echanism would have to=0D=0Abe invented, and using some of the forest guide= ideas may work, but it's=0D=0Aquite a stretch from where we are now, and n= eeds a new protocol=0D=0Amechanism of some sort.=0D=0A=0D=0A=20=0D=0A=0D=0A= We can do that, but later, please.=0D=0A=0D=0A=20=0D=0A=0D=0ABrian=0D=0A=0D= =0A=20=0D=0A=0D=0A________________________________=0D=0A=0D=0AFrom: Dawson,= Martin [mailto:Martin.Dawson@andrew.com]=20=0D=0ASent: Wednesday, June 13,= 2007 8:37 AM=0D=0ATo: Brian Rosen; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit= ] Proposals 1 and 3 - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0AOK,= well neither did I. I didn't understand where the proposition of=0D=0A"bot= h" came in with respect to LoST. I only know of reverse-lookup as=0D=0Abein= g discussed as a potential LoST function.=0D=0A=0D=0A=20=0D=0A=0D=0AI am su= ggesting that, as yet another possibility and in the spirit of=0D=0Anot jus= t giving up (and saying, we've looked after VSP operator=0D=0Ainterests but= we won't worry about the LIS operators so much) is that=0D=0Avalidating a = PSAP URI could also be a forest guide function.=0D=0A=0D=0A=20=0D=0A=0D=0AC= heers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A________________________= ________=0D=0A=0D=0AFrom: Brian Rosen [mailto:br@brianrosen.net]=20=0D=0ASe= nt: Wednesday, 13 June 2007 10:31 PM=0D=0ATo: Dawson, Martin; ecrit@ietf.or= g=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A=0D= =0A=20=0D=0A=0D=0AI don't see any changes needed in LoST for forest guides.= =20=0D=0A=0D=0A=20=0D=0A=0D=0ABrian=0D=0A=0D=0A=20=0D=0A=0D=0A____________= ____________________=0D=0A=0D=0AFrom: Dawson, Martin [mailto:Martin.Dawson@= andrew.com]=20=0D=0ASent: Wednesday, June 13, 2007 3:38 AM=0D=0ATo: Brian R= osen; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3 - summary = of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0AI wasn't suggesting they were an = identical level of definition. I was=0D=0Asaying that it's still not defini= tive solution; of course it's a matter=0D=0Aof degree. Without a definitive= forest guide solution, how does a VSP=0D=0Aknow how to find the right LoST= server to find the PSAP URI=3F At least=0D=0Awith option 3, the PSAP URI i= s provided at the point of local knowledge=0D=0Awhere the applicable LoST s= erver is known.=0D=0A=0D=0A=20=0D=0A=0D=0APull your last comment apart for = me... are you saying that the "forest=0D=0Aguide" implementation requires c= hanges to LoST=3F Without those changes,=0D=0Athe Forest Guide won't work e= ither=3F=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A =0D= =0A=0D=0A________________________________=0D=0A=0D=0AFrom: Brian Rosen [mai= lto:br@brianrosen.net]=20=0D=0ASent: Wednesday, 13 June 2007 10:28 AM=0D=0A= To: Dawson, Martin; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Proposals 1 an= d 3 - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0AI'm sorry but the f= orest guide idea is a whole lot more developed that=0D=0Aany notion of an a= uthoritative list of PSAP URIs. I'm not saying it=0D=0Acan't be done, I'm = saying we need a whole lot more work on it to make it=0D=0Areal, and it's n= ot at all clear to me that the reverse lookup idea has=0D=0Amore or less me= rit. However, both of them are beyond what I think is=0D=0Aappropriate for= LoST at this point.=0D=0A=0D=0A=20=0D=0A=0D=0ABrian=0D=0A=0D=0A=20=0D=0A=0D= =0A________________________________=0D=0A=0D=0AFrom: Dawson, Martin [mailto= :Martin.Dawson@andrew.com]=20=0D=0ASent: Tuesday, June 12, 2007 5:19 PM=0D=0A= To: Brian Rosen; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3= - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0AWell hand waving was a= bout all I could invest in an email, but are you=0D=0Asaying you'd just hav= e to give up at that stage=3F What is a reference to=0D=0Aa "forest guide",= if it's not a particularly low-detail suggestion of=0D=0Athe sort of thing= we need to resolve the right LoST server=3F Yet, without=0D=0Athat, option= 1 doesn't work. Why wouldn't this "validation" be a=0D=0Afunction of that = system and why is reverse lookup the only option=3F=0D=0A=0D=0A=20=0D=0A=0D= =0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A____________________= ____________=0D=0A=0D=0AFrom: Brian Rosen [mailto:br@brianrosen.net]=20=0D=0A= Sent: Wednesday, 13 June 2007 12:18 AM=0D=0ATo: Dawson, Martin; ecrit@ietf.= org=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D= =0A=0D=0A=20=0D=0A=0D=0AI think those of us pushing for Option 1 for now is= that we think VSP=0D=0Avalidation is a fact of life we have to deal with, = waving hands over=0D=0A"reference to a relatively static table maintained b= y global=0D=0Acooperation" is not adequate, and something like a reverse lo= okup is=0D=0Arequired. This would be a change to LoST and we are reluctant= to take=0D=0Athis change on at this time.=0D=0A=0D=0A=20=0D=0A=0D=0ABrian=0D= =0A=0D=0A=20=0D=0A=0D=0A________________________________=0D=0A=0D=0AFrom: D= awson, Martin [mailto:Martin.Dawson@andrew.com]=20=0D=0ASent: Tuesday, June= 12, 2007 10:08 AM=0D=0ATo: ecrit@ietf.org=0D=0ASubject: [Ecrit] Proposals = 1 and 3 - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0AFor some reason= this hasn't made it through moderation. Now I'm a list=0D=0Asubscriber, I'= ll try again...=0D=0A=0D=0A=20=0D=0A=0D=0AIt's a long weekend in Australia = and winter has finally hit - with cold=0D=0Awind and rain. What better time= , then, to spend some time catching up=0D=0Awith the action on the ECRIT li= st. I only went back a couple of weeks;=0D=0Aobviously the main topic has b= een to do with the question of how to=0D=0Adefine the "location hiding" cap= ability. Mostly it's a debate about the=0D=0Autility of option 1 and 3.=0D=0A=0D= =0A=20=0D=0A=0D=0AHaving just read through all the postings and while they = are fresh in my=0D=0Amind, here is how I characterize the perspectives. Fir= st my summary of=0D=0Athe options...=0D=0A=0D=0A=20=0D=0A=0D=0A*=09Option 1= achieves location hiding, somewhat oxymoronically, by=0D=0Aproviding locat= ion. Whether it's by reference to the local LoST facility=0D=0Aor by some i= nternal knowledge, the LIS generates a coarse location which=0D=0Ait knows = will result in a correct PSAP URI resolution if/when another=0D=0Aparty mak= es a request to the LoST facility. This is provided in addition=0D=0Ato a l= ocation reference for subsequent accurate location requests from=0D=0Athe P= SAP for dispatch etc.=0D=0A*=09Option 3 achieves location hiding by making = the request to the=0D=0Alocal LoST facility using the end points location a= nd providing the PSAP=0D=0AURI that the LoST service returns (in addition t= o a location reference)=0D=0Aso the call can be routed to that PSAP - wheth= er directly from the=0D=0Adevice or via a proxy/VSP.=0D=0A=0D=0A=20=0D=0A=0D= =0ABoth suggestions are based on an assumption that a LIS, being associated=0D= =0Awith the local jurisdiction, has enough local knowledge to identify the=0D= =0Acorrect LoST service for that jurisdiction or, at least in the case of=0D= =0Aoption 1, to determine what "coarse location" isn't too coarse.=0D=0A=0D= =0A=20=0D=0A=0D=0APerspective 1 - articulated by a lot of people, Ted, Bria= n, Andy,...=0D=0Aetc. is that LoST needs to progress and get to a first rel= ease and=0D=0Achanges associated with this particular use case should be av= oided for=0D=0Anow. I haven't seen anything in either proposal that does re= quire a=0D=0Achange to LoST. In the one case either or both of the LIS and = VSP/proxy=0D=0Amake LoST queries but neither options appears to *dictate* a= specific=0D=0Achange to LoST.=0D=0A=0D=0A=20=0D=0A=0D=0APerspective 2 - ar= ticulated by, for example, James W and Barbara is that=0D=0Athe LIS operato= r should have the option of providing location or not - a=0D=0A"coarse loca= tion" is still a location and location information to the=0D=0Agranularity = of PSAP boundaries, for example, could still support a lot=0D=0Aof value-ad= ded services and be used for other than emergency services.=0D=0A=0D=0A=20=0D= =0A=0D=0APerspective 3 - articulated by, for example, Andy and Laura is tha= t,=0D=0Awhen the end-point initiates a call through the VSP/proxy with a=0D= =0Apre-determined PSAP URI, the proxy may not know that this really is a=0D= =0Agenuine emergency call destination. In fact it could be used to call=0D=0A= anyone by just pretending it's an emergency call. This means the VSP may=0D= =0Alose call revenue through the fraudulent nomination of emergency calls.=0D= =0A=0D=0A=20=0D=0A=0D=0APerspective 4 - articulated by, in particular, Hann= es (sorry Hannes, I=0D=0Acan't see anyone else emphasising this point) is t= hat all emergency=0D=0Acalls should go through a VSP so that there's an aut= henticated=0D=0Asubscriber identity to be associated with the call. This se= ems like an=0D=0Aorthogonal point to me. If we accept that some calls will = go through=0D=0AVSPs and therefore Perspective 3 is valid then the question= of whether=0D=0Aall emergency calls have to go through a VSP is moot. I ha= ve to admit to=0D=0Abeing really surprised by the perspective - it wasn't o= ne that I thought=0D=0Ahad any currency in this forum.=0D=0A=0D=0A=20=0D=0A=0D= =0A=20=0D=0A=0D=0AThere were miscellaneous other perspectives including som= e good=0D=0Asuggestions for alternatives/compromises from Richard and Henni= ng.=0D=0A=0D=0A=20=0D=0A=0D=0AMartin D's perspective -=0D=0A=0D=0A=20=0D=0A=0D= =0A*=09On perspective 1, I don't see any impediment to pushing LoST=0D=0Aou= t. Even if there are changes to come, they can be done in a revision=0D=0Ao= r whatever. But I haven't seen any definitive statement about how=0D=0Aeith= er option *requires* a change to LoST.=0D=0A*=09On perspective 4, I don't t= hink it's decisive in the discussion.=0D=0A*=09So, really, it boils down to= an evaluation of which of=0D=0Aperspectives 2 and 3 are the most valid - i= =2Ee. are the interests of the=0D=0ALIS operator or a VSP to have priority.=0D= =0A=0D=0A=20=0D=0A=0D=0AI don't understand why the interests of LIS operato= rs and VSPs can't=0D=0Aboth be served. I'm surprised that with all the expe= rience and knowledge=0D=0Ain the forum that nobody can provide a practical = way for a proxy/VSP to=0D=0Adetermine whether a PSAP URI is a valid emergen= cy destination or not. I=0D=0Aknow that adding the reverse-lookup to LoST h= as been discussed. That=0D=0Awould be effective, but it's not in keeping wi= th perspective 1. Surely,=0D=0Athough, there are alternatives.=0D=0A=0D=0A =0D= =0A=0D=0AI think option 3 supports a faster and smoother deployment of glob= al=0D=0Aemergency calling for VoIP. Here's my rationale.=0D=0A=0D=0A=20=0D=0A=0D= =0A1.=09Both options require a LoST and LIS capability to exist at a=0D=0Al= ocal and jurisdictional level - so their availability is a premise in=0D=0A= either proposal=0D=0A2.=09Option 1 assumes that each VSP can make an effect= ive LoST query=0D=0Aeven if it is a "non-local" VSP to the point from where= the call is=0D=0Abeing originated. This is either by the VSP automatically= knowing which=0D=0ALoST server is applicable to the coarse location or by = the use of the so=0D=0Acalled forest guide and perhaps some international h= ierarchy of=0D=0Ainterconnected LoST servers.=0D=0A3.=09Option 3 only assum= es that this local knowledge is in the local=0D=0ALIS function and doesn't = rely on the existence of the infrastructure=0D=0Adescribed in point 2.=0D=0A= 4.=09The ability to verify a destination PSAP URI as a valid=0D=0Aemergency= URI could be supported by reference to a relatively static=0D=0Atable main= tained by global cooperation. In fact, I would have thought=0D=0Athat filte= ring based on domain name would be extremely reliable and=0D=0Afast. It wou= ld certainly obviate the ability to make arbitrary calls by=0D=0Apretending= they are emergency calls.=0D=0A5.=09Perhaps a later revision of LoST can i= nclude the reverse-lookup=0D=0Amechanism and, perhaps by then, the internat= ional infrastructure of LoST=0D=0Aservers, forest guides, etc. may be in pl= ace.=0D=0A=0D=0A=20=0D=0A=0D=0AI mention point 4 as one possible way to pro= tect the interest of the=0D=0AVSPs without requiring a change to the curren= t LoST definition. Are=0D=0Athere any other proposals on how to achieve thi= s or, alternatively, a=0D=0Aview that it simply isn't possible=3F=0D=0A=0D=0A= =20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A Martin = Dawson=0D=0A=0D=0AAndrew Network Solutions Asia-Pacific=0D=0A=0D=0AEmail: m= artin.dawson@andrew.com=0D=0A=0D=0APhone: +61 2 42212992=0D=0A=0D=0AFax: +6= 1 2 42212901=0D=0A=0D=0AMobile: +61 412 120300=0D=0A=0D=0A=0D=0AThis messag= e is for the designated recipient only and may contain=0D=0Aprivileged, pro= prietary, or otherwise private information. If you have=0D=0Areceived it in= error, please notify the sender immediately and delete=0D=0Athe original. = Any unauthorized use of this email is prohibited.=0D=0A=0D=0A=20=0D=0A=0D=0A= =20=0D=0A=0D=0A=0D=0A------------------------------------------------------= ------------------=0D=0A------------------------=0D=0AThis message is for t= he designated recipient only and may=0D=0Acontain privileged, proprietary, = or otherwise private information. =20=0D=0AIf you have received it in error= , please notify the sender=0D=0Aimmediately and delete the original. Any u= nauthorized use of=0D=0Athis email is prohibited.=0D=0A--------------------= ----------------------------------------------------=0D=0A-----------------= -------=0D=0A[mf2]=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A=0D=0A---------= ---------------------------------------------------------------=0D=0A------= ------------------=0D=0AThis message is for the designated recipient only a= nd may=0D=0Acontain privileged, proprietary, or otherwise private informati= on. =20=0D=0AIf you have received it in error, please notify the sender=0D=0A= immediately and delete the original. Any unauthorized use of=0D=0Athis ema= il is prohibited.=0D=0A----------------------------------------------------= --------------------=0D=0A------------------------=0D=0A[mf2]=0D=0A=0D=0A =0D= =0A=0D=0A=20=0D=0A=0D=0A=0D=0A---------------------------------------------= ---------------------------=0D=0A------------------------=0D=0AThis message= is for the designated recipient only and may=0D=0Acontain privileged, prop= rietary, or otherwise private information. =20=0D=0AIf you have received it= in error, please notify the sender=0D=0Aimmediately and delete the origina= l. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A-----------= -------------------------------------------------------------=0D=0A--------= ----------------=0D=0A[mf2]=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A=0D=0A= ------------------------------------------------------------------------=0D= =0A------------------------=0D=0AThis message is for the designated recipie= nt only and may=0D=0Acontain privileged, proprietary, or otherwise private = information. =20=0D=0AIf you have received it in error, please notify the s= ender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------=0D=0A------------------------=0D=0A[mf2]=0D= =0A=0D=0A=20=0D=0A=0D=0A---------------------------------------------------= ---------------------------------------------=0D=0AThis message is for the = designated recipient only and may=0D=0Acontain privileged, proprietary, or = otherwise private information. =20=0D=0AIf you have received it in error, p= lease notify the sender=0D=0Aimmediately and delete the original. Any unau= thorized use of=0D=0Athis email is prohibited.=0D=0A-----------------------= -------------------------------------------------------------------------=0D= =0A[mf2]=0D=0A ------_=_NextPart_002_01C7ADC4.0E6DF93C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A

Hello?

 

Even if we were to include URI = validation as one of the forest guide’s tasks, which I’m not sure is = the right way, that isn’t enough; we need a protocol mechanism to implement it.  THAT is what I want to defer, at least for = now.

 

I also don’t want that = problem delaying development of forest guides.  =

 

Brian

 

From: = Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Sent: Wednesday, June 13, = 2007 10:07 AM
To: Brian Rosen; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

I understood = that “later please” was a request with respect to LoST… = which is why I’m avoiding it.

 =

Option 1, as I = understand it, can’t work at all until the forest guide definitions are = completed and, in fact, until the actual forest guide system/network is *implemented*. So I’m = suggesting that the URI validation be added to the, still in development, forest guide specification.

 =

In the mean = time, option 3 works regardless and, as the URI validation becomes available through = the forest guide network, then the issue of “pretend” emergency = calls is obviated as well.

 =

Cheers,

Martin=

 =

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, 13 June = 2007 11:55 PM
To: Dawson, Martin; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

I don’t understand how this = would work.  The forest guide thing doesn’t need any more protocol function than we have already.  There is no function I know of in = LoST that would accept a URI as a query and return anything resembling or = computable to a Boolean (valid) in response.  That’s some kind of = protocol mechanism.  Whether the implementation of that is reverse lookup or flooding or some other mechanism would have to be invented, and using = some of the forest guide ideas may work, but it’s quite a stretch from = where we are now, and needs a new protocol mechanism of some = sort.

 

We can do that, but later, = please.

 

Brian

 

From: = Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Sent: Wednesday, June 13, = 2007 8:37 AM
To: Brian Rosen; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

OK, well neither = did I. I didn’t understand where the proposition of “both” came = in with respect to LoST. I only know of reverse-lookup as being discussed = as a potential LoST function.

 =

I am suggesting = that, as yet another possibility and in the spirit of not just giving up (and = saying, we’ve looked after VSP operator interests but we won’t worry = about the LIS operators so much) is that validating a PSAP URI could also be a = forest guide function.

 =

Cheers,

Martin=

 =

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, 13 June = 2007 10:31 PM
To: Dawson, Martin; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

I don’t see any changes = needed in LoST for forest guides. 

 

Brian

 

From: = Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Sent: Wednesday, June 13, = 2007 3:38 AM
To: Brian Rosen; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

I wasn’t = suggesting they were an identical level of definition. I was saying that it’s = still not definitive solution; of course it’s a matter of degree. = Without a definitive forest guide solution, how does a VSP know how to find the = right LoST server to find the PSAP URI? At least with option 3, the PSAP URI = is provided at the point of local knowledge where the applicable LoST = server is known.

 =

Pull your last = comment apart for me… are you saying that the “forest guide” implementation requires changes to LoST? Without those changes, the = Forest Guide won’t work either?

 =

Cheers,

Martin=

 =

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, 13 June = 2007 10:28 AM
To: Dawson, Martin; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

I’m sorry but the forest = guide idea is a whole lot more developed that any notion of an authoritative list = of PSAP URIs.  I’m not saying it can’t be done, I’m saying we need a = whole lot more work on it to make it real, and it’s not at all clear to = me that the reverse lookup idea has more or less merit.  However, both of = them are beyond what I think is appropriate for LoST at this = point.

 

Brian

 

From: = Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Sent: Tuesday, June 12, = 2007 5:19 PM
To: Brian Rosen; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

Well hand waving = was about all I could invest in an email, but are you saying you’d = just have to give up at that stage? What is a reference to a “forest = guide”, if it’s not a particularly low-detail suggestion of the sort of = thing we need to resolve the right LoST server? Yet, without that, option 1 doesn’t work. Why wouldn’t this “validation” be = a function of that system and why is reverse lookup the only = option?

 =

Cheers,

Martin=

 =

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, 13 June = 2007 12:18 AM
To: Dawson, Martin; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

I think those of us pushing for = Option 1 for now is that we think VSP validation is a fact of life we have to = deal with, waving hands over “reference to a = relatively static table maintained by global cooperation” is not adequate, and something like a reverse lookup = is required.  This would be a change to LoST and we are reluctant to = take this change on at this time.

 

Brian

 

From: = Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Sent: Tuesday, June 12, = 2007 10:08 AM
To: ecrit@ietf.org
Subject: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

For some reason this hasn’t made it = through moderation. Now I’m a list subscriber, I’ll try = again…

 

It’s a long weekend in Australia and winter has = finally hit – with cold wind and rain. What better time, then, to spend = some time catching up with the action on the ECRIT list. I only went back a couple = of weeks; obviously the main topic has been to do with the question of how = to define the “location hiding” capability. Mostly it’s a = debate about the utility of option 1 and 3.

 

Having just read through all the postings and = while they are fresh in my mind, here is how I characterize the perspectives. = First my summary of the options…

 

  • Option 1 = achieves location hiding, somewhat oxymoronically, by providing location. = Whether it’s by reference to the local LoST facility or by some = internal knowledge, the LIS generates a coarse location which it knows will = result in a correct PSAP URI resolution if/when another party makes a = request to the LoST facility. This is provided in addition to a location = reference for subsequent accurate location requests from the PSAP for = dispatch etc.
  • Option 3 = achieves location hiding by making the request to the local LoST facility = using the end points location and providing the PSAP URI that the LoST = service returns (in addition to a location reference) so the call can be = routed to that PSAP – whether directly from the device or via a = proxy/VSP.

 

Both suggestions are based on an assumption = that a LIS, being associated with the local jurisdiction, has enough local = knowledge to identify the correct LoST service for that jurisdiction or, at least = in the case of option 1, to determine what “coarse location” = isn’t too coarse.

 

Perspective 1 – articulated by a lot of = people, Ted, Brian, Andy,… etc. is that LoST needs to progress and get to = a first release and changes associated with this particular use case should be = avoided for now. I haven’t seen anything in either proposal that does = require a change to LoST. In the one case either or both of the LIS and VSP/proxy = make LoST queries but neither options appears to *dictate* a specific change to LoST.

 

Perspective 2 – articulated by, for = example, James W and Barbara is that the LIS operator should have the option of providing location or not – a “coarse location” is = still a location and location information to the granularity of PSAP boundaries, = for example, could still support a lot of value-added services and be used = for other than emergency services.

 

Perspective 3 – articulated by, for = example, Andy and Laura is that, when the end-point initiates a call through the VSP/proxy with a pre-determined PSAP URI, the proxy may not know that = this really is a genuine emergency call destination. In fact it could be used = to call anyone by just pretending it’s an emergency call. This means = the VSP may lose call revenue through the fraudulent nomination of emergency = calls.

 

Perspective 4 – articulated by, in = particular, Hannes (sorry Hannes, I can’t see anyone else emphasising this = point) is that all emergency calls should go through a VSP so that there’s = an authenticated subscriber identity to be associated with the call. This = seems like an orthogonal point to me. If we accept that some calls will go = through VSPs and therefore Perspective 3 is valid then the question of whether = all emergency calls have to go through a VSP is moot. I have to admit to = being really surprised by the perspective – it wasn’t one that I = thought had any currency in this forum.

 

 

There were miscellaneous other perspectives = including some good suggestions for alternatives/compromises from Richard and = Henning.

 

Martin D’s perspective = –

 

  • On = perspective 1, I don’t see any impediment to pushing LoST out. Even if there = are changes to come, they can be done in a revision or whatever. But I haven’t seen any definitive statement about how either option = *requires* a change to = LoST.
  • On = perspective 4, I don’t think it’s decisive in the = discussion.
  • So, = really, it boils down to an evaluation of which of perspectives 2 and 3 are the most = valid – i.e. are the interests of the LIS operator or a VSP to have priority.

 

I don’t understand why the interests of = LIS operators and VSPs can’t both be served. I’m surprised that = with all the experience and knowledge in the forum that nobody can provide a practical way for a proxy/VSP to determine whether a PSAP URI is a valid emergency destination or not. I know that adding the reverse-lookup to = LoST has been discussed. That would be effective, but it’s not in keeping = with perspective 1. Surely, though, there are = alternatives.

 

I think option 3 supports a faster and = smoother deployment of global emergency calling for VoIP. Here’s my = rationale.

 

  1. Both = options require a LoST and LIS capability to exist at a local and jurisdictional = level – so their availability is a premise in either = proposal
  2. Option 1 = assumes that each VSP can make an effective LoST query even if it is a “non-local” VSP to the point from where the call is = being originated. This is either by the VSP automatically knowing which = LoST server is applicable to the coarse location or by the use of the so = called forest guide and perhaps some international hierarchy of = interconnected LoST servers.
  3. Option 3 = only assumes that this local knowledge is in the local LIS function and doesn’t rely on the existence of the infrastructure described = in point 2.
  4. The = ability to verify a destination PSAP URI as a valid emergency URI could be = supported by reference to a relatively static table maintained by global cooperation. In fact, I would have thought that filtering based on = domain name would be extremely reliable and fast. It would certainly = obviate the ability to make arbitrary calls by pretending they are emergency = calls.
  5. Perhaps a = later revision of LoST can include the reverse-lookup mechanism and, = perhaps by then, the international infrastructure of LoST servers, forest = guides, etc. may be in place.

 

I mention point 4 as one possible way to = protect the interest of the VSPs without requiring a change to the current LoST = definition. Are there any other proposals on how to achieve this or, alternatively, = a view that it simply isn’t possible?

 

Cheers,

Martin

 

Martin Dawson

Andrew Network Solutions = Asia-Pacific

Email: martin.dawson@andrew.com

Phone: +61 2 42212992

Fax: +61 2 42212901

Mobile: +61 412 120300


This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have = received it in error, please notify the sender immediately and delete the = original. Any unauthorized use of this email is prohibited.

 

 


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

 

 


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

 

 


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

 

 


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

 

 


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

 

------=_NextPart_001_0310_01C7ADA4.421B84D0-- ------=_NextPart_000_030F_01C7ADA4.421B84D0 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABfAPYDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1v7DZ /wDPpB/37X/Cj7FZ/wDPpB/36X/Cmahc3FrZvLa2jXcwwFiVgMk+57VxHiiLxQ+m+fe3SQrJIscd lZ5JYn1PU0m7HVhsP7eSTklfudlM2j28PnTfYo4/7zBAKxf+Es8KG5aEGAqqljKYAE47Djk1xEOg wW+oWFn4i1JbCS8IFvbEF5GycduF59a3LGPwN4fuL5r7UUuLnT3AnEqMREScABQOeeM81Cc3sjsq UMBRupVHJ+R1OlX1hrEjm30krbqPluJYFVZD6AHmtT7DZ/8APpB/36X/AArGXxx4ZGsDRzqkcd7u EYiZGUbjjAzjGeRTbfx94audXbSk1Efa1kaLa0bAF16gMRjPFaJM8ucot+6rI2/sVn/z6Qf9+1/w o+xWf/PpB/37X/Cudh+I/he4t5biO+kaGJlV3+zuACx2gZx61YHjvw41ylul/wCZK90bRUSJiWlG MgcdOevSnZkXRtfYrP8A59IP+/a/4UfYrP8A59IP+/a/4VNS0hkH2Kz/AOfSD/v2v+FH2Kz/AOfS D/v2v+FT0UAQfYrP/n0g/wC/a/4UfYrP/n0g/wC/a/4VPRQBB9is/wDn0g/79r/hR9is/wDn0g/7 9r/hU9FAEH2Kz/59IP8Av2v+FH2Kz/59IP8Av2v+FT0UAV2tLFFLNbW6qOpMagD9Kgtzo92zLbfY ZivURhGI/Ks+/t11nxGNOuvmsrS3Wd4c8TOxIG71AA6etRauPDFpcRrcslhc25V0lgjKMg9NyjGD 0IrRQ+8ydRrXobv2Kz/59IP+/S/4UfYbP/n0g/79L/hWZe+IfJvfsdjafbJVjWSQmZYlVW6DLdSf SlHiW3msLW4tIJbia7dkit1wG3L94E9ABjk0uSRXtI9zS+xWf/PpB/37X/Cj7FZ/8+kH/ftf8Ko2 utNJJcW95ZPaXcEXnGIuGDp6qw688e1Z8Hi24nSzcaHcD+0FzafvV+c4yd390Yyc+goUJMTqxRvf YrP/AJ9IP+/a/wCFH2Gz/wCfSD/v0v8AhWYPEsSaTLez20kc0M/2Z7YMC3m5ACg9Ocjn0qOLxDJO bi0lsjb3q27TRRrOriQD0YdCDjrQoSD2sDX+w2f/AD6Qf9+l/wAKPsVn/wA+kH/ftf8ACue07xBe QaBpTT2EtxdXh8uMeauXO3O4nsDitESRv4gsjPbSR3r2bsMS5RBkZUgcE5PWhwa3BVItaGh9hs/+ fSD/AL9L/hSfY7IEA2tvk9B5a8/pWWnieN50svscv9omfymtNwyi9fMJ6bMc5/Csu6iZ9Q33MwTa 3+kAt8+dxxsHUjbtxj1701B9ROqump1P2Kz/AOfSD/v0v+FFFl532GD7RnzfLG/Priis27GqZJ5k f/PRP++hRviyMunHT5hxXjl1fzx6jOgcgBzgVuaPdF4fnwx98Vs6TSuZe01DW/AOta14pk12TVrB WS6ia3iOTsiQ5A3dj7AYOaoXfwmvb7VpNSn1S082fUWnnUO21oSwIXp97r7Ve1SXywjA4GD0+tYE l5LNcYEjAZ7GlGLZHtE3axtf8K21W61y4nvtV09bGbUPtxSMEykjOxdx6D1qDS/hhqljfte3Gp2F y7JOyq0jbYp3BCyLxzjvmtDQmJlO87vl7jNdN+5AzsT/AL5FDTWlzSPKzi7P4Zanb+DtR0R9Q04T 3DxPDKsjkAqxJ3Z6dewqbw98MJ9B8QDVI9Ss5fIhH2dXJbExUBnI9PvY/CuneeIMAI4z/wABFIZY /tZGyPHptFK0g0udKkq7F3yx7sDOGGM0vmx/89E/76FYUqxbf9Wn/fIrA1S3LD5OMv2wO1EYczKb sd75kf8Az0T/AL6FJ5kf/PRP++hXAG0f7B3z61NpCG3glmlXzAilsNjsKp0rK9xc53Pmx/8APRP+ +hR5sf8Az0T/AL6Fchaa7p04G6EJ7hAwqxqGr2Fnpz3MKQysOFTaBk1Eo8quwU7uyOn82L/nqn/f Qo82L/nqn/fQrkvC2qTauZo72zgRk5R1jADCukW3g/54Rf8AfAqVZq6KbsWfNi/56p/30KPNi/56 p/30KUWtvj/URf8AfAo+y2//ADwj/wC+BSGZWp2Lz3cWo6deQ297CpTMhykqE52sOvXkEdKqXFpq 2sxi11KewtLMkecttIXeYA525IG0H866D7Lb/wDPCP8A74FH2W3/AOeEf/fAqlNoh00zm9T0Vm1a S/tINMu1njVHivDjYV4DKQDxjqPapP7IuLe1sZbS5shfWZclQoSGQP8AeXA6dufaug+y2/8Azwj/ AO+BR9lt/wDnhH/3wKftGT7KJiQWV3c3U9/qM1ok72zW8MUMhKxg8klj1JOO3amW+lSwx+H1a4ty dLQrNh/vfutny/j61vfZbf8A54R/98Cj7Lb/APPCP/vgUudj9nE5y40A3NjfxNc23mTagbyDd8yd FwHH4EH607TdMliuJbieDSrPMLRpHaAEkn+IsQCB7Cuh+y2//PCP/vgUfZbf/nhH/wB8Cn7SVrC9 lG9zCttKkhtdDia4gzpxzLh+G+Ujj8TVye2L67BqCSwlIraSLaXwSxII/DitH7Lb/wDPCP8A74FH 2W3/AOeEf/fApczK5FaxzS6JeJcLrAv4G1gyfvMufJaL/nl64A5BxnNdFugLBmaIsOhJBI/Gn/Zb f/nhH/3wKPstv/zwj/74FDk3uEYKOwnmxf8APVP++hRS/Zbf/nhH/wB8CiosWeLX0WdWn/3zWpp8 UygbYnx6hDVp5FMZu/8AUGQ4CQINzE9gepP40+b/AEWB7h5ppAmCAHyTnpXdzp6HM49SDWI2FnGW BBweox3rmbZ8XB+td3p1ymr2YEjvGASu1mDfzqLV/Cuk2tqb3zGhf+9kBCT0yPr6VN7CjEp6RJtL t6JWq9/8nXtWNaq1nKIpo8hk5eM5VvUr7VvjR7WW1WWN5iWxxxxRJX1Ki+hnrclmzmpZrjZeZz3q oIZEnZfs7hQepPXn19alnALb8kE84pS91alJOWxtCfzEXnrUjWfnRrx3rlW8SS2pKiCJsdNxNTwe O7tYyDY2/HfLf40lGT+EptLc6s2A+zbMVUktfs2nXJx/yzb+Vc6vxCv2k2fYLYZ92/xqzN4pu7u0 nhe0gAaJskE/3TT5Kii20F4t6FGw8J6b9oV8yxfvAxMUpGc/w+5qHXRZ2+py6ZZah9oaIjzonbcY ie2R+VUW8af8I7pPm7g92yYgiABBPck8dKxvhmLi+8SXl5OpcSgvJM3RWJznNZVpqUUkTSpNT1PU /DivDbx2uwKduV4wVI7GrttqjSXL275jnUnMUq4bHqPUe9ePa18Q9UmN3bWEiwRFmjWdf9YyA4zn tnrxWv4I8UXd/d6ZDevNdTws6CZjuJRgOCe+MVpCHQK1VN+6e0joKWkHQUtcxsFZ2p6xFpbRLNBd SecwVTDCXG49Bx0NaNVb2xS+EG92XyJ1mGO5XtQBBZ65p95DPItykZtnZJlkcBo9rFfmGeOnerE9 /bQ2YuzKGibGwx/NvJ6BcdSe2KzLvwva3cTRyTPgmQjKgjLzLLyO4DKBj0qwuhwppMOno5QQEPHI qgbXB3BgOnXtQBPFq1o0Uckzm1MknlrHcjy2LegB6/hSjV9MaYwDULUyiTyygmXdv/u4z146VRuv D8l9EgutRlkk2vHI4jUb42KkqBj5furz16+tEnhq3dWBnkG5ZAcAfxzeae3rx9KALUmt2AZFhuY5 y04gYQuG2Mc/e546GkbXdMS4toDfQF7pmSLbICGZcZGfXkVm2XhTaga8vGkkWQlRGoVVTe7Bff75 5pLfwbZ2tottHMygFgxRFXcjJsKn324560AbMmp2aadPqCzrNbwIzu0J38KMnGOp46VUt/EulXLS 7LtVWGKOWR5PlRQ+do3HjPHI6jio7Tw5b2WiXWmRyYW6Vld0jVSMrtyAO+AOtE3hu2MxmtJTaygq 6lFBCuGdi2D1z5jcfT0oAnXXLFrq7tRcJ51qgcoZFBZdobcMnpg9TxUtvq1nOdpmWJzM8KpIwDOy HBwM89Ky/wDhEIAjQC8m+zGPYse1cq3kmHduxk/KTx0zT5PCdm+oQ3jSFnjkaTDIrdZDIAM9MMet AG/RSDpRQB5mYPLVp3bMdsAqIgyyuRyx7cf1pIY7WSAAQyM7MA7NJyQOAOBjFRxRy3UZWCDELZEY DYI5yc+uf6CqxubmCfy9qRgHADOqn8ic10wptq63OOrVjDcyPFNzBp+tRxQ3ctlIIVYBl3RHOepX kfkapr4mvVYWOtkz206/IdwKEeqEcVe8R6WdRvkurgFGMQUA9wPSqll4We5srhFPmWoG503fMh/v p7j9RwafLUjqVGcJLQ0NFW5s9Rh0+e7MmmP+8t2CZbP1HIIB+hr0O3nit7aKJnViwGM8ZHrXCaJ9 r0XSt+pKoisZNn2huhVuhHfB4/OrM3inSZypk1CJDEcqSSAVPUfh1/Omo3Wg767HcCO1kI2lCa52 +mgMpiUksOOBxWXD4u0SzugW1eAMOMEnj8xWU/ibSzqZnOs24j3FlK559jxXNzSbdzoStsP1Oxn8 wkYGfXiobexeKHdPNGilupbqfb1qxP4p0S6kAbUoAT/EoO0/pxVU+b4gMj6Oz3KW7bXAIIQnpj2N dFOo7GVRPsW4NPSe4DLcwHnpuxW1YWTWt2kbiGWU5xCzcOcHAPsaoWGiauY0ZrOTjqcVNptpNb+I o5pVIERBIzk9DW0qnu2uZxiyp490ee8h0ltTmt4ovtaxGK2jCpCrjH3jyeQKxfFmvadoek/8Iv4f ZMv/AMfs0bZ4/uZ7k9/yrf8AE2oy3Tzo8QZUXlMZCj/GuCuNBtLqQGzdomc524yprCdL3rrcVOva LTLHg3TIr65nvbgL5NmoYoRnzCeMVt/Dqe207xNPZ3KglJDsH48EVf8AC2kWGm2k1tJc+ZNu2zKw wOVyMVc0/wAMWA1l55lLTXCFYpQxAVsfKR75FbyShBP7zGN5z5F8j1lTkA+1OqtFcxLJHZtJ/pHk +ZtxyVGAT+ZqwTivPPRMG68Q/YrvVYZJIpJbfY1vblgrMpQEnHUgHJJ9Aahi8TzO9urx2yq+7dJv YrNhtv7rAO49/p+db8lzBHIEZh5m3eEAyxXIGcDnqRUnHp09qAOLbxdf3Q8yOO3ihieRJcvzIPL3 oARna/UYPOe1XH8U3aGeOO1iZo1GxWcllOUAL8fdbfkeu011GRnGP0pGdUVnbgKMk47UAZD6ldS6 BcXAeG1uIZHiZ2PyAq+0kEjgHBwSCBnJyBWdH4nnit7XH+lCRmy8u1WkwwXahT5Xb5s5HBAPvXTw zxXNvHPE2+OVA6NjqCMg07gduntQByUXiS7gtFtfkkvJTthaVuZMtJyFA5C7F6etMh8VXkdiJpI7 eWbau+TzCIyfL3FV44Yn5QPXNdjx1xUUdzBLPLAjBpICPMXH3SRkfpQBk6frd1d6o1tNbJHC7SiJ lJ3Dyyud2Rjnd29KzU1zUbDzZLlYpmlupwgLsAVjk2CNBj75HIHfBNdbkUcHGRQBmWOpXM9ndXlz CkcMTyiNYtzuyozKSRjqduQBXPp4kv8AUVhkXEBSQxuIXDo/7225BGf4ZGHX1rsUkWRdyhgOeqkd D70oIA4GPwoAWiiigDza3kl0vwpLfXSBbhAwAXquTx+PNcXaade3iPPHaSzAklmVc810niLURdeE 7OcMQbnarr6Fc5zVTRtUSys0WVGZYmLIFA5zzyeo5HWvXoqUabkkfPYlxlUUW9COGQLDDazE+Q4w QeqH+8PTH8q0dDheFZ0ByVBVxnv0rK1K3urowJEMPPiQkfwqT1PpxzV3wvZyTa+90kuY2nLbWBGV z3/Cs5zu9jvow5YoXXZs/D+6BXB3qgY9eGBH868ru4migaWSRnYdB717D4ytoW8IXaRYAZ0IQ9SQ wBNeZT2CvayRswGV6DrkNiphBygz0KeqN6T4R6hLpw1GXWrYmSIOFIO7JAOK4hraXTL+Wxu0BdOm On1FexyXmpLYO0NxGLWCBQgYhucAZAI4/WuIbwve+IfELTmZHESj7QzP0/uqOOWIrwsPiZ+0fO9D 0qmGSheO5ybN1xxXpXwjJOn6yoHLSRDPpw2K85mAjZlIwynBFemfBpW+y6xIo5WSLOT04NepX+Fs 5IL3j1OHTYBaCKUFgRzg4zXPP4Y/smW8vbOdVRgXRCpJQ4/XmtR/ElpBMIZg4bIGVBIzUmp3Ulto uoXJUN5ETsoPfArkg1JryCcJQTueZX0oZvsURJkwXkJPJPXmqOkWYaX7QVyFGfbNYsN9LEJbwkmW UlixPr1rZsNchaxX7PGyoUG4t13d/wAK9BVU53fQ8nk0HW87LdyyHC/6SM88noK6N75oYQNp3QNu BFctYW5u9JuryP5tkjkn3ABrtIbCO5jV2OPMUEH1yKdOfNCzFKNppo6zVdHm1SVLmOSIDyFQxyA7 Xw6vhsfwkDBqsnhu8iaMi6gd1txGs0iMzQkBuEGcbTuHX0HBro4hiJB6KKfXCekcbD4LnjjjJmt/ OXzEVjuYxIzKwCt16qfT7xq0PCskk8huZoZIXnV3QqT5wDlvnz1PIX6CuooxQBz8vh+eXQvsJ1CZ pfKSM/ORGwVgcY6jIG0nng9Khh8LPG8MgnTzoY4UVzuZlVWcuoJ5wQ4H0H4V01UdW1OPSrI3DRPM xO1Yo+XfucDvgAn6A0Ac9N4PuE0Y6daXMMSMkQ2AFV3qhUsMdCWw3HXFWG8LTZnkS8RZrgOJZADm QFUADHuBtP8A31VgeK7TMjtbzi3VNyTfL85ESy425yPlYde9TWGsSvp9/eX8It/ss7p5ZYZAAGAS OCTn9aAM+LwrcDU4bw3EcAjj2iO3Z1WH73CDPIO4eg4HFWtE0CbTLW+ikaANc7QPs5ZM4TbuJ6hj 1JFJD4rhnMOLG5RWO2UuAphJk8oAgnJ+b0HvUMviovBHKltJb7j5h8zaxaIxysGXBxnMR4P9aAIo vCVyjaYz3aYs2J2Rkoo+cMCMY3HAwScZzzVmHwssVpaxLNtkV2+1Ouf9IQnJU557L9AMCpj4jRIZ pPsszpGdiNlQZpBgFAuc559OaqQeLBPOXa1lhs/3bJNwWYNGzkMucjG0/lQA5/DV00hP2qMl1kUT EN5luWeRsx4PUhwD/ujr0qO18LXFvBYIs0Y+zXBmbczSKB8vCqwxk7Tzxt3Ejvmw3iuONNzWFxuU M8qbk/doqK5brz8rA4HNaFpq8V1fXNr5bRfZ8cykKXBOAQvXaTwD0PagDRHSigdKKAPG1YLbKjxJ JA+d0TD5Sev4H3qe3Gnx7QVkEfVomUHPtkEcVpLoUt1p2+2QtkbtrMAy/wBKoDSr1Yy0kK7hwfmF X7dxTVyVhYzcXYpazrLfMIYivnJtklbG4j0AHAHHSptDvpbaKWWNPMO35UHG4ngfz/Kq7+HdS1KQ RxwoqEDMjOPl5/OmiCQamfDNozh05vpyQCVAztXnpz+NdMZJU0zKpC1ZpbJl/XNQGqeH79gwaOEI uVHBO4cj8f0rmtK0a41XmFIkjQ/PJIeOV6YHXnmul1uwGmeDLmJVIQyJkkgljn/61Yvhu9ZBLAD8 uQw/lWsJShQbW5vTStoSapp17p+htFbyTXcUDCFnSAOS+AenXisfwJLqt7rLIb2Wzt1nE8o2YaY9 NuT2x2rpLnUCLWwCPJGRevI5jbaSobH58YrOkuAt+18GKysSAw6rk9vSvKnSjq1uzrjWk7X6HPax od5f65qMsMJ8wytKYiApCk8EV2PwfJcaujsqYaJSrcdAa5y7Fx9rYRSku6l0J6HHVW9a6D4VtGV1 aclm3yx4IGOxzXRF3hy2MJaO56K3yNtV4AMjg1dkAngeGRo5EcsrKwyCD1zWdJPaeapMByWAFaKN B5xAi5JqY6MiTbRjz+GdOazKxWWno/8ACTCv+FYOp6Vb2mmF4V01GUc4iXn9K7yQQiLHl9KxdTit J7dg1pG/GGDDt7e9bQepk4qx5/LqEtlbPBBJaRQmLeyRoAGJHPGK59/GWopuWPVJY1QYRcAgD0HF b2sR2AkkiiiG7ygu4DA6cVxFxoc26QxhSvbmuirGSiuVGcY3Wp9QWpLWkLE5JRT+lTVlW2t6clrC pueRGoPyN6fSpf7d03/n5/8AHG/wrzzoNCis/wDt3Tf+fn/xxv8ACj+3dN/5+f8Axxv8KANCq91Z W19AYLuCOeInOyRdwqv/AG7pv/Pz/wCON/hR/bum/wDPz/443+FAEw02yVQotYQo6Dyxj7u3/wBB AH04pINMsba0a0gtIY7ds7olQBTnrkVF/bum/wDPz/443+FH9u6b/wA/P/jjf4UAMi8PaVDdxXMV lEjwIViAUbUyxYkDsST1p1noOmWNqLaCzi8sHJ3KCWOCCSe5wSPxNL/bum/8/P8A443+FH9u6b/z 8/8Ajjf4UAPfR9NkaVnsbdmlUK5MY+YDoDSppOnRNE0dlAphUJHiMfKo6AfnUf8Abum/8/P/AI43 +FH9u6b/AM/P/jjf4UASR6Tp8UXlR2UCJhhtEYxhvvfn3pw02zUyEWsQMrB5DsHzEHIJ+hAqH+3d N/5+f/HG/wAKP7d03/n5/wDHG/woAv0VQ/t3Tf8An5/8cb/CigD/2Q== ------=_NextPart_000_030F_01C7ADA4.421B84D0-- --===============0949397818== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0949397818==-- From ecrit-bounces@ietf.org Wed Jun 13 10:24:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyTls-0006lE-MZ; Wed, 13 Jun 2007 10:24:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyTlr-0006l8-Kt for ecrit@ietf.org; Wed, 13 Jun 2007 10:24:27 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyTlp-0006Nz-FV for ecrit@ietf.org; Wed, 13 Jun 2007 10:24:27 -0400 X-SEF-Processed: 5_0_0_910__2007_06_13_09_32_04 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 13 Jun 2007 09:32:03 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jun 2007 09:24:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Wed, 13 Jun 2007 09:24:19 -0500 Message-ID: In-Reply-To: <030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives Thread-Index: AceqV4ZeonTtWSgmTEKwTanATYJDUQCpIGKwAA63d4AABo3GsAAO+O4AAAphx5AAABwDcAACwHSQAAA8QlAAAHs3oAAAT9dQ References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com> <012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com> <023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com> <02e301c7adc2$813763a0$9501a8c0@cis.neustar.com> <030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , X-OriginalArrivalTime: 13 Jun 2007 14:24:24.0251 (UTC) FILETIME=[8A85E8B0:01C7ADC6] X-Spam-Score: 0.2 (/) X-Scan-Signature: ab6387292ea58ba7ed0706d86883d715 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0031424560==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0031424560== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C7ADC6.8A177345" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7ADC6.8A177345 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7ADC6.8A177345" ------_=_NextPart_002_01C7ADC6.8A177345 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So that would be to say that=0D=0A=0D=0A=20=0D=0A=0D=0Ai) = We can't change LoST=0D=0A=0D=0Aii) We can't change th= e forest guide (even though it's=0D=0Anot done yet)=0D=0A=0D=0Aiii) = We can't change anything that means that a VSP=0D=0Awould have a = way to verify a URI=3F=0D=0A=0D=0A=20=0D=0A=0D=0AI'm pretty sure we could d= efine a "here's a URI, provide a Boolean=0D=0Aresponse" protocol element wi= thout a significant delay. So this seems=0D=0Alike a contrived obstruction.= =2E.=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D= =0A________________________________=0D=0A=0D=0AFrom: Brian Rosen [mailto:br= @brianrosen.net]=20=0D=0ASent: Thursday, 14 June 2007 12:19 AM=0D=0ATo: Daw= son, Martin; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3 - s= ummary of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0AHello=3F=0D=0A=0D=0A=20=0D= =0A=0D=0AEven if we were to include URI validation as one of the forest gui= de's=0D=0Atasks, which I'm not sure is the right way, that isn't enough; we= need a=0D=0Aprotocol mechanism to implement it. THAT is what I want to de= fer, at=0D=0Aleast for now.=0D=0A=0D=0A=20=0D=0A=0D=0AI also don't want tha= t problem delaying development of forest guides. =20=0D=0A=0D=0A=20=0D=0A=0D= =0ABrian=0D=0A=0D=0A=20=0D=0A=0D=0A________________________________=0D=0A=0D= =0AFrom: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20=0D=0ASent: Wed= nesday, June 13, 2007 10:07 AM=0D=0ATo: Brian Rosen; ecrit@ietf.org=0D=0ASu= bject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A=0D=0A =0D= =0A=0D=0AI understood that "later please" was a request with respect to LoS= T...=0D=0Awhich is why I'm avoiding it.=0D=0A=0D=0A=20=0D=0A=0D=0AOption 1,= as I understand it, can't work at all until the forest guide=0D=0Adefiniti= ons are completed and, in fact, until the actual forest guide=0D=0Asystem/n= etwork is *implemented*. So I'm suggesting that the URI=0D=0Avalidation be = added to the, still in development, forest guide=0D=0Aspecification.=0D=0A=0D= =0A=20=0D=0A=0D=0AIn the mean time, option 3 works regardless and, as the U= RI validation=0D=0Abecomes available through the forest guide network, then= the issue of=0D=0A"pretend" emergency calls is obviated as well.=0D=0A=0D=0A= =20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A________= ________________________=0D=0A=0D=0AFrom: Brian Rosen [mailto:br@brianrosen= =2Enet]=20=0D=0ASent: Wednesday, 13 June 2007 11:55 PM=0D=0ATo: Dawson, Mar= tin; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3 - summary o= f perspectives=0D=0A=0D=0A=20=0D=0A=0D=0AI don't understand how this would = work. The forest guide thing doesn't=0D=0Aneed any more protocol function = than we have already. There is no=0D=0Afunction I know of in LoST that wou= ld accept a URI as a query and return=0D=0Aanything resembling or computabl= e to a Boolean (valid) in response.=0D=0AThat's some kind of protocol mecha= nism. Whether the implementation of=0D=0Athat is reverse lookup or floodin= g or some other mechanism would have to=0D=0Abe invented, and using some of= the forest guide ideas may work, but it's=0D=0Aquite a stretch from where = we are now, and needs a new protocol=0D=0Amechanism of some sort.=0D=0A=0D=0A= =20=0D=0A=0D=0AWe can do that, but later, please.=0D=0A=0D=0A=20=0D=0A=0D=0A= Brian=0D=0A=0D=0A=20=0D=0A=0D=0A________________________________=0D=0A=0D=0A= From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20=0D=0ASent: Wednes= day, June 13, 2007 8:37 AM=0D=0ATo: Brian Rosen; ecrit@ietf.org=0D=0ASubjec= t: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A=0D=0A=20=0D= =0A=0D=0AOK, well neither did I. I didn't understand where the proposition = of=0D=0A"both" came in with respect to LoST. I only know of reverse-lookup = as=0D=0Abeing discussed as a potential LoST function.=0D=0A=0D=0A=20=0D=0A=0D= =0AI am suggesting that, as yet another possibility and in the spirit of=0D= =0Anot just giving up (and saying, we've looked after VSP operator=0D=0Aint= erests but we won't worry about the LIS operators so much) is that=0D=0Aval= idating a PSAP URI could also be a forest guide function.=0D=0A=0D=0A=20=0D= =0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A______________= __________________=0D=0A=0D=0AFrom: Brian Rosen [mailto:br@brianrosen.net] =0D= =0ASent: Wednesday, 13 June 2007 10:31 PM=0D=0ATo: Dawson, Martin; ecrit@ie= tf.org=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3 - summary of perspective= s=0D=0A=0D=0A=20=0D=0A=0D=0AI don't see any changes needed in LoST for fore= st guides. =20=0D=0A=0D=0A=20=0D=0A=0D=0ABrian=0D=0A=0D=0A=20=0D=0A=0D=0A__= ______________________________=0D=0A=0D=0AFrom: Dawson, Martin [mailto:Mart= in.Dawson@andrew.com]=20=0D=0ASent: Wednesday, June 13, 2007 3:38 AM=0D=0AT= o: Brian Rosen; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3 = - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0AI wasn't suggesting the= y were an identical level of definition. I was=0D=0Asaying that it's still = not definitive solution; of course it's a matter=0D=0Aof degree. Without a = definitive forest guide solution, how does a VSP=0D=0Aknow how to find the = right LoST server to find the PSAP URI=3F At least=0D=0Awith option 3, the = PSAP URI is provided at the point of local knowledge=0D=0Awhere the applica= ble LoST server is known.=0D=0A=0D=0A=20=0D=0A=0D=0APull your last comment = apart for me... are you saying that the "forest=0D=0Aguide" implementation = requires changes to LoST=3F Without those changes,=0D=0Athe Forest Guide wo= n't work either=3F=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D= =0A=20=0D=0A=0D=0A________________________________=0D=0A=0D=0AFrom: Brian R= osen [mailto:br@brianrosen.net]=20=0D=0ASent: Wednesday, 13 June 2007 10:28= AM=0D=0ATo: Dawson, Martin; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Propo= sals 1 and 3 - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0AI'm sorry = but the forest guide idea is a whole lot more developed that=0D=0Aany notio= n of an authoritative list of PSAP URIs. I'm not saying it=0D=0Acan't be d= one, I'm saying we need a whole lot more work on it to make it=0D=0Areal, a= nd it's not at all clear to me that the reverse lookup idea has=0D=0Amore o= r less merit. However, both of them are beyond what I think is=0D=0Aapprop= riate for LoST at this point.=0D=0A=0D=0A=20=0D=0A=0D=0ABrian=0D=0A=0D=0A =0D= =0A=0D=0A________________________________=0D=0A=0D=0AFrom: Dawson, Martin [= mailto:Martin.Dawson@andrew.com]=20=0D=0ASent: Tuesday, June 12, 2007 5:19 = PM=0D=0ATo: Brian Rosen; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Proposals= 1 and 3 - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0AWell hand wavi= ng was about all I could invest in an email, but are you=0D=0Asaying you'd = just have to give up at that stage=3F What is a reference to=0D=0Aa "forest= guide", if it's not a particularly low-detail suggestion of=0D=0Athe sort = of thing we need to resolve the right LoST server=3F Yet, without=0D=0Athat= , option 1 doesn't work. Why wouldn't this "validation" be a=0D=0Afunction = of that system and why is reverse lookup the only option=3F=0D=0A=0D=0A=20=0D= =0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A______________= __________________=0D=0A=0D=0AFrom: Brian Rosen [mailto:br@brianrosen.net] =0D= =0ASent: Wednesday, 13 June 2007 12:18 AM=0D=0ATo: Dawson, Martin; ecrit@ie= tf.org=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3 - summary of perspective= s=0D=0A=0D=0A=20=0D=0A=0D=0AI think those of us pushing for Option 1 for no= w is that we think VSP=0D=0Avalidation is a fact of life we have to deal wi= th, waving hands over=0D=0A"reference to a relatively static table maintain= ed by global=0D=0Acooperation" is not adequate, and something like a revers= e lookup is=0D=0Arequired. This would be a change to LoST and we are reluc= tant to take=0D=0Athis change on at this time.=0D=0A=0D=0A=20=0D=0A=0D=0ABr= ian=0D=0A=0D=0A=20=0D=0A=0D=0A________________________________=0D=0A=0D=0AF= rom: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20=0D=0ASent: Tuesday= , June 12, 2007 10:08 AM=0D=0ATo: ecrit@ietf.org=0D=0ASubject: [Ecrit] Prop= osals 1 and 3 - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0AFor some = reason this hasn't made it through moderation. Now I'm a list=0D=0Asubscrib= er, I'll try again...=0D=0A=0D=0A=20=0D=0A=0D=0AIt's a long weekend in Aust= ralia and winter has finally hit - with cold=0D=0Awind and rain. What bette= r time, then, to spend some time catching up=0D=0Awith the action on the EC= RIT list. I only went back a couple of weeks;=0D=0Aobviously the main topic= has been to do with the question of how to=0D=0Adefine the "location hidin= g" capability. Mostly it's a debate about the=0D=0Autility of option 1 and = 3.=0D=0A=0D=0A=20=0D=0A=0D=0AHaving just read through all the postings and = while they are fresh in my=0D=0Amind, here is how I characterize the perspe= ctives. First my summary of=0D=0Athe options...=0D=0A=0D=0A=20=0D=0A=0D=0A*= =09Option 1 achieves location hiding, somewhat oxymoronically, by=0D=0Aprov= iding location. Whether it's by reference to the local LoST facility=0D=0Ao= r by some internal knowledge, the LIS generates a coarse location which=0D=0A= it knows will result in a correct PSAP URI resolution if/when another=0D=0A= party makes a request to the LoST facility. This is provided in addition=0D= =0Ato a location reference for subsequent accurate location requests from=0D= =0Athe PSAP for dispatch etc.=0D=0A*=09Option 3 achieves location hiding by= making the request to the=0D=0Alocal LoST facility using the end points lo= cation and providing the PSAP=0D=0AURI that the LoST service returns (in ad= dition to a location reference)=0D=0Aso the call can be routed to that PSAP= - whether directly from the=0D=0Adevice or via a proxy/VSP.=0D=0A=0D=0A =0D= =0A=0D=0ABoth suggestions are based on an assumption that a LIS, being asso= ciated=0D=0Awith the local jurisdiction, has enough local knowledge to iden= tify the=0D=0Acorrect LoST service for that jurisdiction or, at least in th= e case of=0D=0Aoption 1, to determine what "coarse location" isn't too coar= se.=0D=0A=0D=0A=20=0D=0A=0D=0APerspective 1 - articulated by a lot of peopl= e, Ted, Brian, Andy,...=0D=0Aetc. is that LoST needs to progress and get to= a first release and=0D=0Achanges associated with this particular use case = should be avoided for=0D=0Anow. I haven't seen anything in either proposal = that does require a=0D=0Achange to LoST. In the one case either or both of = the LIS and VSP/proxy=0D=0Amake LoST queries but neither options appears to= *dictate* a specific=0D=0Achange to LoST.=0D=0A=0D=0A=20=0D=0A=0D=0APerspe= ctive 2 - articulated by, for example, James W and Barbara is that=0D=0Athe= LIS operator should have the option of providing location or not - a=0D=0A= "coarse location" is still a location and location information to the=0D=0A= granularity of PSAP boundaries, for example, could still support a lot=0D=0A= of value-added services and be used for other than emergency services.=0D=0A=0D= =0A=20=0D=0A=0D=0APerspective 3 - articulated by, for example, Andy and Lau= ra is that,=0D=0Awhen the end-point initiates a call through the VSP/proxy = with a=0D=0Apre-determined PSAP URI, the proxy may not know that this reall= y is a=0D=0Agenuine emergency call destination. In fact it could be used to= call=0D=0Aanyone by just pretending it's an emergency call. This means the= VSP may=0D=0Alose call revenue through the fraudulent nomination of emerge= ncy calls.=0D=0A=0D=0A=20=0D=0A=0D=0APerspective 4 - articulated by, in par= ticular, Hannes (sorry Hannes, I=0D=0Acan't see anyone else emphasising thi= s point) is that all emergency=0D=0Acalls should go through a VSP so that t= here's an authenticated=0D=0Asubscriber identity to be associated with the = call. This seems like an=0D=0Aorthogonal point to me. If we accept that som= e calls will go through=0D=0AVSPs and therefore Perspective 3 is valid then= the question of whether=0D=0Aall emergency calls have to go through a VSP = is moot. I have to admit to=0D=0Abeing really surprised by the perspective = - it wasn't one that I thought=0D=0Ahad any currency in this forum.=0D=0A=0D= =0A=20=0D=0A=0D=0A=20=0D=0A=0D=0AThere were miscellaneous other perspective= s including some good=0D=0Asuggestions for alternatives/compromises from Ri= chard and Henning.=0D=0A=0D=0A=20=0D=0A=0D=0AMartin D's perspective -=0D=0A=0D= =0A=20=0D=0A=0D=0A*=09On perspective 1, I don't see any impediment to pushi= ng LoST=0D=0Aout. Even if there are changes to come, they can be done in a = revision=0D=0Aor whatever. But I haven't seen any definitive statement abou= t how=0D=0Aeither option *requires* a change to LoST.=0D=0A*=09On perspecti= ve 4, I don't think it's decisive in the discussion.=0D=0A*=09So, really, i= t boils down to an evaluation of which of=0D=0Aperspectives 2 and 3 are the= most valid - i.e. are the interests of the=0D=0ALIS operator or a VSP to h= ave priority.=0D=0A=0D=0A=20=0D=0A=0D=0AI don't understand why the interest= s of LIS operators and VSPs can't=0D=0Aboth be served. I'm surprised that w= ith all the experience and knowledge=0D=0Ain the forum that nobody can prov= ide a practical way for a proxy/VSP to=0D=0Adetermine whether a PSAP URI is= a valid emergency destination or not. I=0D=0Aknow that adding the reverse-= lookup to LoST has been discussed. That=0D=0Awould be effective, but it's n= ot in keeping with perspective 1. Surely,=0D=0Athough, there are alternativ= es.=0D=0A=0D=0A=20=0D=0A=0D=0AI think option 3 supports a faster and smooth= er deployment of global=0D=0Aemergency calling for VoIP. Here's my rational= e.=0D=0A=0D=0A=20=0D=0A=0D=0A1.=09Both options require a LoST and LIS capab= ility to exist at a=0D=0Alocal and jurisdictional level - so their availabi= lity is a premise in=0D=0Aeither proposal=0D=0A2.=09Option 1 assumes that e= ach VSP can make an effective LoST query=0D=0Aeven if it is a "non-local" V= SP to the point from where the call is=0D=0Abeing originated. This is eithe= r by the VSP automatically knowing which=0D=0ALoST server is applicable to = the coarse location or by the use of the so=0D=0Acalled forest guide and pe= rhaps some international hierarchy of=0D=0Ainterconnected LoST servers.=0D=0A= 3.=09Option 3 only assumes that this local knowledge is in the local=0D=0AL= IS function and doesn't rely on the existence of the infrastructure=0D=0Ade= scribed in point 2.=0D=0A4.=09The ability to verify a destination PSAP URI = as a valid=0D=0Aemergency URI could be supported by reference to a relative= ly static=0D=0Atable maintained by global cooperation. In fact, I would hav= e thought=0D=0Athat filtering based on domain name would be extremely relia= ble and=0D=0Afast. It would certainly obviate the ability to make arbitrary= calls by=0D=0Apretending they are emergency calls.=0D=0A5.=09Perhaps a lat= er revision of LoST can include the reverse-lookup=0D=0Amechanism and, perh= aps by then, the international infrastructure of LoST=0D=0Aservers, forest = guides, etc. may be in place.=0D=0A=0D=0A=20=0D=0A=0D=0AI mention point 4 a= s one possible way to protect the interest of the=0D=0AVSPs without requiri= ng a change to the current LoST definition. Are=0D=0Athere any other propos= als on how to achieve this or, alternatively, a=0D=0Aview that it simply is= n't possible=3F=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D= =0A=20=0D=0A=0D=0A Martin Dawson=0D=0A=0D=0AAndrew Network Solutions Asia-P= acific=0D=0A=0D=0AEmail: martin.dawson@andrew.com=0D=0A=0D=0APhone: +61 2 4= 2212992=0D=0A=0D=0AFax: +61 2 42212901=0D=0A=0D=0AMobile: +61 412 120300=0D= =0A=0D=0A=0D=0AThis message is for the designated recipient only and may co= ntain=0D=0Aprivileged, proprietary, or otherwise private information. If yo= u have=0D=0Areceived it in error, please notify the sender immediately and = delete=0D=0Athe original. Any unauthorized use of this email is prohibited.=0D= =0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A=0D=0A------------------------------= ------------------------------------------=0D=0A------------------------=0D= =0AThis message is for the designated recipient only and may=0D=0Acontain p= rivileged, proprietary, or otherwise private information. =20=0D=0AIf you h= ave received it in error, please notify the sender=0D=0Aimmediately and del= ete the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D= =0A------------------------------------------------------------------------=0D= =0A------------------------=0D=0A[mf2]=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D= =0A=0D=0A------------------------------------------------------------------= ------=0D=0A------------------------=0D=0AThis message is for the designate= d recipient only and may=0D=0Acontain privileged, proprietary, or otherwise= private information. =20=0D=0AIf you have received it in error, please not= ify the sender=0D=0Aimmediately and delete the original. Any unauthorized = use of=0D=0Athis email is prohibited.=0D=0A--------------------------------= ----------------------------------------=0D=0A------------------------=0D=0A= [mf2]=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A=0D=0A----------------------= --------------------------------------------------=0D=0A-------------------= -----=0D=0AThis message is for the designated recipient only and may=0D=0Ac= ontain privileged, proprietary, or otherwise private information. =20=0D=0A= If you have received it in error, please notify the sender=0D=0Aimmediately= and delete the original. Any unauthorized use of=0D=0Athis email is prohi= bited.=0D=0A---------------------------------------------------------------= ---------=0D=0A------------------------=0D=0A[mf2]=0D=0A=0D=0A=20=0D=0A=0D=0A= =20=0D=0A=0D=0A=0D=0A------------------------------------------------------= ------------------=0D=0A------------------------=0D=0AThis message is for t= he designated recipient only and may=0D=0Acontain privileged, proprietary, = or otherwise private information. =20=0D=0AIf you have received it in error= , please notify the sender=0D=0Aimmediately and delete the original. Any u= nauthorized use of=0D=0Athis email is prohibited.=0D=0A--------------------= ----------------------------------------------------=0D=0A-----------------= -------=0D=0A[mf2]=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A=0D=0A---------= ---------------------------------------------------------------=0D=0A------= ------------------=0D=0AThis message is for the designated recipient only a= nd may=0D=0Acontain privileged, proprietary, or otherwise private informati= on. =20=0D=0AIf you have received it in error, please notify the sender=0D=0A= immediately and delete the original. Any unauthorized use of=0D=0Athis ema= il is prohibited.=0D=0A----------------------------------------------------= --------------------=0D=0A------------------------=0D=0A[mf2]=0D=0A=0D=0A =0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_002_01C7ADC6.8A177345 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A

This will be my last message on = this particular thread, I don’t think we’re getting = anywhere.

 

I don’t want to extend the development of LoST to add this feature.  I agree with Andy: Option = #1 is good enough FOR NOW, and we can work on other options = later.

 

Brian

 

From: = Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Sent: Wednesday, June 13, = 2007 10:24 AM
To: Brian Rosen; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

So that would be = to say that

 =

i)           = ;      We can’t change LoST

ii)           = ;     We can’t change the forest guide (even though = it’s not done yet)

iii)           = ;   We can’t change anything that means that a VSP would = have a way to verify a URI?

 =

I’m pretty = sure we could define a “here’s a URI, provide a Boolean = response” protocol element without a significant delay. So this seems like a = contrived obstruction…

 =

Cheers,

Martin=

 =

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: Thursday, 14 June = 2007 12:19 AM
To: Dawson, Martin; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

Hello?

 

Even if we were to include URI = validation as one of the forest guide’s tasks, which I’m not sure is = the right way, that isn’t enough; we need a protocol mechanism to implement it.  THAT is what I want to defer, at least for = now.

 

I also don’t want that = problem delaying development of forest guides.  =

 

Brian

 

From: = Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Sent: Wednesday, June 13, = 2007 10:07 AM
To: Brian Rosen; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

I understood = that “later please” was a request with respect to LoST… = which is why I’m avoiding it.

 =

Option 1, as I = understand it, can’t work at all until the forest guide definitions are = completed and, in fact, until the actual forest guide system/network is *implemented*. So I’m = suggesting that the URI validation be added to the, still in development, forest guide specification.

 =

In the mean = time, option 3 works regardless and, as the URI validation becomes available through = the forest guide network, then the issue of “pretend” emergency = calls is obviated as well.

 =

Cheers,

Martin=

 =

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, 13 June = 2007 11:55 PM
To: Dawson, Martin; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

I don’t understand how this = would work.  The forest guide thing doesn’t need any more protocol function than we have already.  There is no function I know of in = LoST that would accept a URI as a query and return anything resembling or = computable to a Boolean (valid) in response.  That’s some kind of = protocol mechanism.  Whether the implementation of that is reverse lookup or flooding or some other mechanism would have to be invented, and using = some of the forest guide ideas may work, but it’s quite a stretch from = where we are now, and needs a new protocol mechanism of some = sort.

 

We can do that, but later, = please.

 

Brian

 

From: = Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Sent: Wednesday, June 13, = 2007 8:37 AM
To: Brian Rosen; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

OK, well neither = did I. I didn’t understand where the proposition of “both” came = in with respect to LoST. I only know of reverse-lookup as being discussed = as a potential LoST function.

 =

I am suggesting = that, as yet another possibility and in the spirit of not just giving up (and = saying, we’ve looked after VSP operator interests but we won’t worry = about the LIS operators so much) is that validating a PSAP URI could also be a = forest guide function.

 =

Cheers,

Martin=

 =

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, 13 June = 2007 10:31 PM
To: Dawson, Martin; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

I don’t see any changes = needed in LoST for forest guides. 

 

Brian

 

From: = Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Sent: Wednesday, June 13, = 2007 3:38 AM
To: Brian Rosen; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

I wasn’t = suggesting they were an identical level of definition. I was saying that it’s = still not definitive solution; of course it’s a matter of degree. = Without a definitive forest guide solution, how does a VSP know how to find the = right LoST server to find the PSAP URI? At least with option 3, the PSAP URI = is provided at the point of local knowledge where the applicable LoST = server is known.

 =

Pull your last = comment apart for me… are you saying that the “forest guide” implementation requires changes to LoST? Without those changes, the = Forest Guide won’t work either?

 =

Cheers,

Martin=

 =

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, 13 June = 2007 10:28 AM
To: Dawson, Martin; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

I’m sorry but the forest = guide idea is a whole lot more developed that any notion of an authoritative list = of PSAP URIs.  I’m not saying it can’t be done, I’m = saying we need a whole lot more work on it to make it real, and it’s not at = all clear to me that the reverse lookup idea has more or less merit.  = However, both of them are beyond what I think is appropriate for LoST at this = point.

 

Brian

 

From: = Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Sent: Tuesday, June 12, = 2007 5:19 PM
To: Brian Rosen; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

Well hand waving = was about all I could invest in an email, but are you saying you’d = just have to give up at that stage? What is a reference to a “forest = guide”, if it’s not a particularly low-detail suggestion of the sort of = thing we need to resolve the right LoST server? Yet, without that, option 1 doesn’t work. Why wouldn’t this “validation” be = a function of that system and why is reverse lookup the only = option?

 =

Cheers,

Martin=

 =

From: Brian = Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, 13 June = 2007 12:18 AM
To: Dawson, Martin; = ecrit@ietf.org
Subject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

I think those of us pushing for = Option 1 for now is that we think VSP validation is a fact of life we have to = deal with, waving hands over “reference to a = relatively static table maintained by global cooperation” is not adequate, and something like a reverse lookup = is required.  This would be a change to LoST and we are reluctant to = take this change on at this time.

 

Brian

 

From: = Dawson, Martin [mailto:Martin.Dawson@andrew.com]
Sent: Tuesday, June 12, = 2007 10:08 AM
To: ecrit@ietf.org
Subject: [Ecrit] = Proposals 1 and 3 - summary of perspectives

 

For some reason this hasn’t made it = through moderation. Now I’m a list subscriber, I’ll try = again…

 

It’s a long weekend in Australia and winter has = finally hit – with cold wind and rain. What better time, then, to spend = some time catching up with the action on the ECRIT list. I only went back a couple = of weeks; obviously the main topic has been to do with the question of how = to define the “location hiding” capability. Mostly it’s a = debate about the utility of option 1 and 3.

 

Having just read through all the postings and = while they are fresh in my mind, here is how I characterize the perspectives. = First my summary of the options…

 

  • Option 1 = achieves location hiding, somewhat oxymoronically, by providing location. = Whether it’s by reference to the local LoST facility or by some = internal knowledge, the LIS generates a coarse location which it knows will = result in a correct PSAP URI resolution if/when another party makes a = request to the LoST facility. This is provided in addition to a location = reference for subsequent accurate location requests from the PSAP for = dispatch etc.
  • Option 3 = achieves location hiding by making the request to the local LoST facility = using the end points location and providing the PSAP URI that the LoST = service returns (in addition to a location reference) so the call can be routed to = that PSAP – whether directly from the device or via a = proxy/VSP.

 

Both suggestions are based on an assumption = that a LIS, being associated with the local jurisdiction, has enough local = knowledge to identify the correct LoST service for that jurisdiction or, at least = in the case of option 1, to determine what “coarse location” = isn’t too coarse.

 

Perspective 1 – articulated by a lot of = people, Ted, Brian, Andy,… etc. is that LoST needs to progress and get to = a first release and changes associated with this particular use case should be = avoided for now. I haven’t seen anything in either proposal that does = require a change to LoST. In the one case either or both of the LIS and VSP/proxy = make LoST queries but neither options appears to *dictate* a specific change to LoST.

 

Perspective 2 – articulated by, for = example, James W and Barbara is that the LIS operator should have the option of providing location or not – a “coarse location” is = still a location and location information to the granularity of PSAP boundaries, = for example, could still support a lot of value-added services and be used = for other than emergency services.

 

Perspective 3 – articulated by, for = example, Andy and Laura is that, when the end-point initiates a call through the VSP/proxy with a pre-determined PSAP URI, the proxy may not know that = this really is a genuine emergency call destination. In fact it could be used = to call anyone by just pretending it’s an emergency call. This means = the VSP may lose call revenue through the fraudulent nomination of emergency = calls.

 

Perspective 4 – articulated by, in = particular, Hannes (sorry Hannes, I can’t see anyone else emphasising this = point) is that all emergency calls should go through a VSP so that there’s = an authenticated subscriber identity to be associated with the call. This = seems like an orthogonal point to me. If we accept that some calls will go = through VSPs and therefore Perspective 3 is valid then the question of whether = all emergency calls have to go through a VSP is moot. I have to admit to being really surprised by the perspective – it wasn’t one that I thought = had any currency in this forum.

 

 

There were miscellaneous other perspectives = including some good suggestions for alternatives/compromises from Richard and = Henning.

 

Martin D’s perspective = –

 

  • On = perspective 1, I don’t see any impediment to pushing LoST out. Even if there = are changes to come, they can be done in a revision or whatever. But I haven’t seen any definitive statement about how either option = *requires* a change to = LoST.
  • On = perspective 4, I don’t think it’s decisive in the = discussion.
  • So, = really, it boils down to an evaluation of which of perspectives 2 and 3 are the most = valid – i.e. are the interests of the LIS operator or a VSP to have priority.

 

I don’t understand why the interests of = LIS operators and VSPs can’t both be served. I’m surprised that = with all the experience and knowledge in the forum that nobody can provide a practical way for a proxy/VSP to determine whether a PSAP URI is a valid emergency destination or not. I know that adding the reverse-lookup to = LoST has been discussed. That would be effective, but it’s not in keeping = with perspective 1. Surely, though, there are = alternatives.

 

I think option 3 supports a faster and = smoother deployment of global emergency calling for VoIP. Here’s my = rationale.

 

  1. Both = options require a LoST and LIS capability to exist at a local and jurisdictional = level – so their availability is a premise in either = proposal
  2. Option 1 = assumes that each VSP can make an effective LoST query even if it is a “non-local” VSP to the point from where the call is = being originated. This is either by the VSP automatically knowing which = LoST server is applicable to the coarse location or by the use of the so = called forest guide and perhaps some international hierarchy of = interconnected LoST servers.
  3. Option 3 = only assumes that this local knowledge is in the local LIS function and doesn’t rely on the existence of the infrastructure described = in point 2.
  4. The = ability to verify a destination PSAP URI as a valid emergency URI could be = supported by reference to a relatively static table maintained by global cooperation. In fact, I would have thought that filtering based on = domain name would be extremely reliable and fast. It would certainly = obviate the ability to make arbitrary calls by pretending they are emergency = calls.
  5. Perhaps a = later revision of LoST can include the reverse-lookup mechanism and, = perhaps by then, the international infrastructure of LoST servers, forest = guides, etc. may be in place.

 

I mention point 4 as one possible way to = protect the interest of the VSPs without requiring a change to the current LoST = definition. Are there any other proposals on how to achieve this or, alternatively, = a view that it simply isn’t possible?

 

Cheers,

Martin

 

Martin Dawson

Andrew Network Solutions = Asia-Pacific

Email: martin.dawson@andrew.com

Phone: +61 2 42212992

Fax: +61 2 42212901

Mobile: +61 412 120300


This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have = received it in error, please notify the sender immediately and delete the = original. Any unauthorized use of this email is prohibited.

 

 


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

 

 


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

 

 


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

 

 


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

 

 


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

 

 


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

 

------=_NextPart_001_034E_01C7ADA5.C23C0170-- ------=_NextPart_000_034D_01C7ADA5.C23C0170 Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABfAPYDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1v7DZ /wDPpB/37X/Cj7FZ/wDPpB/36X/Cmahc3FrZvLa2jXcwwFiVgMk+57VxHiiLxQ+m+fe3SQrJIscd lZ5JYn1PU0m7HVhsP7eSTklfudlM2j28PnTfYo4/7zBAKxf+Es8KG5aEGAqqljKYAE47Djk1xEOg wW+oWFn4i1JbCS8IFvbEF5GycduF59a3LGPwN4fuL5r7UUuLnT3AnEqMREScABQOeeM81Cc3sjsq UMBRupVHJ+R1OlX1hrEjm30krbqPluJYFVZD6AHmtT7DZ/8APpB/36X/AArGXxx4ZGsDRzqkcd7u EYiZGUbjjAzjGeRTbfx94audXbSk1Efa1kaLa0bAF16gMRjPFaJM8ucot+6rI2/sVn/z6Qf9+1/w o+xWf/PpB/37X/Cudh+I/he4t5biO+kaGJlV3+zuACx2gZx61YHjvw41ylul/wCZK90bRUSJiWlG MgcdOevSnZkXRtfYrP8A59IP+/a/4UfYrP8A59IP+/a/4VNS0hkH2Kz/AOfSD/v2v+FH2Kz/AOfS D/v2v+FT0UAQfYrP/n0g/wC/a/4UfYrP/n0g/wC/a/4VPRQBB9is/wDn0g/79r/hR9is/wDn0g/7 9r/hU9FAEH2Kz/59IP8Av2v+FH2Kz/59IP8Av2v+FT0UAV2tLFFLNbW6qOpMagD9Kgtzo92zLbfY ZivURhGI/Ks+/t11nxGNOuvmsrS3Wd4c8TOxIG71AA6etRauPDFpcRrcslhc25V0lgjKMg9NyjGD 0IrRQ+8ydRrXobv2Kz/59IP+/S/4UfYbP/n0g/79L/hWZe+IfJvfsdjafbJVjWSQmZYlVW6DLdSf SlHiW3msLW4tIJbia7dkit1wG3L94E9ABjk0uSRXtI9zS+xWf/PpB/37X/Cj7FZ/8+kH/ftf8Ko2 utNJJcW95ZPaXcEXnGIuGDp6qw688e1Z8Hi24nSzcaHcD+0FzafvV+c4yd390Yyc+goUJMTqxRvf YrP/AJ9IP+/a/wCFH2Gz/wCfSD/v0v8AhWYPEsSaTLez20kc0M/2Z7YMC3m5ACg9Ocjn0qOLxDJO bi0lsjb3q27TRRrOriQD0YdCDjrQoSD2sDX+w2f/AD6Qf9+l/wAKPsVn/wA+kH/ftf8ACue07xBe QaBpTT2EtxdXh8uMeauXO3O4nsDitESRv4gsjPbSR3r2bsMS5RBkZUgcE5PWhwa3BVItaGh9hs/+ fSD/AL9L/hSfY7IEA2tvk9B5a8/pWWnieN50svscv9omfymtNwyi9fMJ6bMc5/Csu6iZ9Q33MwTa 3+kAt8+dxxsHUjbtxj1701B9ROqump1P2Kz/AOfSD/v0v+FFFl532GD7RnzfLG/Priis27GqZJ5k f/PRP++hRviyMunHT5hxXjl1fzx6jOgcgBzgVuaPdF4fnwx98Vs6TSuZe01DW/AOta14pk12TVrB WS6ia3iOTsiQ5A3dj7AYOaoXfwmvb7VpNSn1S082fUWnnUO21oSwIXp97r7Ve1SXywjA4GD0+tYE l5LNcYEjAZ7GlGLZHtE3axtf8K21W61y4nvtV09bGbUPtxSMEykjOxdx6D1qDS/hhqljfte3Gp2F y7JOyq0jbYp3BCyLxzjvmtDQmJlO87vl7jNdN+5AzsT/AL5FDTWlzSPKzi7P4Zanb+DtR0R9Q04T 3DxPDKsjkAqxJ3Z6dewqbw98MJ9B8QDVI9Ss5fIhH2dXJbExUBnI9PvY/CuneeIMAI4z/wABFIZY /tZGyPHptFK0g0udKkq7F3yx7sDOGGM0vmx/89E/76FYUqxbf9Wn/fIrA1S3LD5OMv2wO1EYczKb sd75kf8Az0T/AL6FJ5kf/PRP++hXAG0f7B3z61NpCG3glmlXzAilsNjsKp0rK9xc53Pmx/8APRP+ +hR5sf8Az0T/AL6Fchaa7p04G6EJ7hAwqxqGr2Fnpz3MKQysOFTaBk1Eo8quwU7uyOn82L/nqn/f Qo82L/nqn/fQrkvC2qTauZo72zgRk5R1jADCukW3g/54Rf8AfAqVZq6KbsWfNi/56p/30KPNi/56 p/30KUWtvj/URf8AfAo+y2//ADwj/wC+BSGZWp2Lz3cWo6deQ297CpTMhykqE52sOvXkEdKqXFpq 2sxi11KewtLMkecttIXeYA525IG0H866D7Lb/wDPCP8A74FH2W3/AOeEf/fAqlNoh00zm9T0Vm1a S/tINMu1njVHivDjYV4DKQDxjqPapP7IuLe1sZbS5shfWZclQoSGQP8AeXA6dufaug+y2/8Azwj/ AO+BR9lt/wDnhH/3wKftGT7KJiQWV3c3U9/qM1ok72zW8MUMhKxg8klj1JOO3amW+lSwx+H1a4ty dLQrNh/vfutny/j61vfZbf8A54R/98Cj7Lb/APPCP/vgUudj9nE5y40A3NjfxNc23mTagbyDd8yd FwHH4EH607TdMliuJbieDSrPMLRpHaAEkn+IsQCB7Cuh+y2//PCP/vgUfZbf/nhH/wB8Cn7SVrC9 lG9zCttKkhtdDia4gzpxzLh+G+Ujj8TVye2L67BqCSwlIraSLaXwSxII/DitH7Lb/wDPCP8A74FH 2W3/AOeEf/fApczK5FaxzS6JeJcLrAv4G1gyfvMufJaL/nl64A5BxnNdFugLBmaIsOhJBI/Gn/Zb f/nhH/3wKPstv/zwj/74FDk3uEYKOwnmxf8APVP++hRS/Zbf/nhH/wB8CiosWeLX0WdWn/3zWpp8 UygbYnx6hDVp5FMZu/8AUGQ4CQINzE9gepP40+b/AEWB7h5ppAmCAHyTnpXdzp6HM49SDWI2FnGW BBweox3rmbZ8XB+td3p1ymr2YEjvGASu1mDfzqLV/Cuk2tqb3zGhf+9kBCT0yPr6VN7CjEp6RJtL t6JWq9/8nXtWNaq1nKIpo8hk5eM5VvUr7VvjR7WW1WWN5iWxxxxRJX1Ki+hnrclmzmpZrjZeZz3q oIZEnZfs7hQepPXn19alnALb8kE84pS91alJOWxtCfzEXnrUjWfnRrx3rlW8SS2pKiCJsdNxNTwe O7tYyDY2/HfLf40lGT+EptLc6s2A+zbMVUktfs2nXJx/yzb+Vc6vxCv2k2fYLYZ92/xqzN4pu7u0 nhe0gAaJskE/3TT5Kii20F4t6FGw8J6b9oV8yxfvAxMUpGc/w+5qHXRZ2+py6ZZah9oaIjzonbcY ie2R+VUW8af8I7pPm7g92yYgiABBPck8dKxvhmLi+8SXl5OpcSgvJM3RWJznNZVpqUUkTSpNT1PU /DivDbx2uwKduV4wVI7GrttqjSXL275jnUnMUq4bHqPUe9ePa18Q9UmN3bWEiwRFmjWdf9YyA4zn tnrxWv4I8UXd/d6ZDevNdTws6CZjuJRgOCe+MVpCHQK1VN+6e0joKWkHQUtcxsFZ2p6xFpbRLNBd SecwVTDCXG49Bx0NaNVb2xS+EG92XyJ1mGO5XtQBBZ65p95DPItykZtnZJlkcBo9rFfmGeOnerE9 /bQ2YuzKGibGwx/NvJ6BcdSe2KzLvwva3cTRyTPgmQjKgjLzLLyO4DKBj0qwuhwppMOno5QQEPHI qgbXB3BgOnXtQBPFq1o0Uckzm1MknlrHcjy2LegB6/hSjV9MaYwDULUyiTyygmXdv/u4z146VRuv D8l9EgutRlkk2vHI4jUb42KkqBj5furz16+tEnhq3dWBnkG5ZAcAfxzeae3rx9KALUmt2AZFhuY5 y04gYQuG2Mc/e546GkbXdMS4toDfQF7pmSLbICGZcZGfXkVm2XhTaga8vGkkWQlRGoVVTe7Bff75 5pLfwbZ2tottHMygFgxRFXcjJsKn324560AbMmp2aadPqCzrNbwIzu0J38KMnGOp46VUt/EulXLS 7LtVWGKOWR5PlRQ+do3HjPHI6jio7Tw5b2WiXWmRyYW6Vld0jVSMrtyAO+AOtE3hu2MxmtJTaygq 6lFBCuGdi2D1z5jcfT0oAnXXLFrq7tRcJ51qgcoZFBZdobcMnpg9TxUtvq1nOdpmWJzM8KpIwDOy HBwM89Ky/wDhEIAjQC8m+zGPYse1cq3kmHduxk/KTx0zT5PCdm+oQ3jSFnjkaTDIrdZDIAM9MMet AG/RSDpRQB5mYPLVp3bMdsAqIgyyuRyx7cf1pIY7WSAAQyM7MA7NJyQOAOBjFRxRy3UZWCDELZEY DYI5yc+uf6CqxubmCfy9qRgHADOqn8ic10wptq63OOrVjDcyPFNzBp+tRxQ3ctlIIVYBl3RHOepX kfkapr4mvVYWOtkz206/IdwKEeqEcVe8R6WdRvkurgFGMQUA9wPSqll4We5srhFPmWoG503fMh/v p7j9RwafLUjqVGcJLQ0NFW5s9Rh0+e7MmmP+8t2CZbP1HIIB+hr0O3nit7aKJnViwGM8ZHrXCaJ9 r0XSt+pKoisZNn2huhVuhHfB4/OrM3inSZypk1CJDEcqSSAVPUfh1/Omo3Wg767HcCO1kI2lCa52 +mgMpiUksOOBxWXD4u0SzugW1eAMOMEnj8xWU/ibSzqZnOs24j3FlK559jxXNzSbdzoStsP1Oxn8 wkYGfXiobexeKHdPNGilupbqfb1qxP4p0S6kAbUoAT/EoO0/pxVU+b4gMj6Oz3KW7bXAIIQnpj2N dFOo7GVRPsW4NPSe4DLcwHnpuxW1YWTWt2kbiGWU5xCzcOcHAPsaoWGiauY0ZrOTjqcVNptpNb+I o5pVIERBIzk9DW0qnu2uZxiyp490ee8h0ltTmt4ovtaxGK2jCpCrjH3jyeQKxfFmvadoek/8Iv4f ZMv/AMfs0bZ4/uZ7k9/yrf8AE2oy3Tzo8QZUXlMZCj/GuCuNBtLqQGzdomc524yprCdL3rrcVOva LTLHg3TIr65nvbgL5NmoYoRnzCeMVt/Dqe207xNPZ3KglJDsH48EVf8AC2kWGm2k1tJc+ZNu2zKw wOVyMVc0/wAMWA1l55lLTXCFYpQxAVsfKR75FbyShBP7zGN5z5F8j1lTkA+1OqtFcxLJHZtJ/pHk +ZtxyVGAT+ZqwTivPPRMG68Q/YrvVYZJIpJbfY1vblgrMpQEnHUgHJJ9Aahi8TzO9urx2yq+7dJv YrNhtv7rAO49/p+db8lzBHIEZh5m3eEAyxXIGcDnqRUnHp09qAOLbxdf3Q8yOO3ihieRJcvzIPL3 oARna/UYPOe1XH8U3aGeOO1iZo1GxWcllOUAL8fdbfkeu011GRnGP0pGdUVnbgKMk47UAZD6ldS6 BcXAeG1uIZHiZ2PyAq+0kEjgHBwSCBnJyBWdH4nnit7XH+lCRmy8u1WkwwXahT5Xb5s5HBAPvXTw zxXNvHPE2+OVA6NjqCMg07gduntQByUXiS7gtFtfkkvJTthaVuZMtJyFA5C7F6etMh8VXkdiJpI7 eWbau+TzCIyfL3FV44Yn5QPXNdjx1xUUdzBLPLAjBpICPMXH3SRkfpQBk6frd1d6o1tNbJHC7SiJ lJ3Dyyud2Rjnd29KzU1zUbDzZLlYpmlupwgLsAVjk2CNBj75HIHfBNdbkUcHGRQBmWOpXM9ndXlz CkcMTyiNYtzuyozKSRjqduQBXPp4kv8AUVhkXEBSQxuIXDo/7225BGf4ZGHX1rsUkWRdyhgOeqkd D70oIA4GPwoAWiiigDza3kl0vwpLfXSBbhAwAXquTx+PNcXaade3iPPHaSzAklmVc810niLURdeE 7OcMQbnarr6Fc5zVTRtUSys0WVGZYmLIFA5zzyeo5HWvXoqUabkkfPYlxlUUW9COGQLDDazE+Q4w QeqH+8PTH8q0dDheFZ0ByVBVxnv0rK1K3urowJEMPPiQkfwqT1PpxzV3wvZyTa+90kuY2nLbWBGV z3/Cs5zu9jvow5YoXXZs/D+6BXB3qgY9eGBH868ru4migaWSRnYdB717D4ytoW8IXaRYAZ0IQ9SQ wBNeZT2CvayRswGV6DrkNiphBygz0KeqN6T4R6hLpw1GXWrYmSIOFIO7JAOK4hraXTL+Wxu0BdOm On1FexyXmpLYO0NxGLWCBQgYhucAZAI4/WuIbwve+IfELTmZHESj7QzP0/uqOOWIrwsPiZ+0fO9D 0qmGSheO5ybN1xxXpXwjJOn6yoHLSRDPpw2K85mAjZlIwynBFemfBpW+y6xIo5WSLOT04NepX+Fs 5IL3j1OHTYBaCKUFgRzg4zXPP4Y/smW8vbOdVRgXRCpJQ4/XmtR/ElpBMIZg4bIGVBIzUmp3Ulto uoXJUN5ETsoPfArkg1JryCcJQTueZX0oZvsURJkwXkJPJPXmqOkWYaX7QVyFGfbNYsN9LEJbwkmW UlixPr1rZsNchaxX7PGyoUG4t13d/wAK9BVU53fQ8nk0HW87LdyyHC/6SM88noK6N75oYQNp3QNu BFctYW5u9JuryP5tkjkn3ABrtIbCO5jV2OPMUEH1yKdOfNCzFKNppo6zVdHm1SVLmOSIDyFQxyA7 Xw6vhsfwkDBqsnhu8iaMi6gd1txGs0iMzQkBuEGcbTuHX0HBro4hiJB6KKfXCekcbD4LnjjjJmt/ OXzEVjuYxIzKwCt16qfT7xq0PCskk8huZoZIXnV3QqT5wDlvnz1PIX6CuooxQBz8vh+eXQvsJ1CZ pfKSM/ORGwVgcY6jIG0nng9Khh8LPG8MgnTzoY4UVzuZlVWcuoJ5wQ4H0H4V01UdW1OPSrI3DRPM xO1Yo+XfucDvgAn6A0Ac9N4PuE0Y6daXMMSMkQ2AFV3qhUsMdCWw3HXFWG8LTZnkS8RZrgOJZADm QFUADHuBtP8A31VgeK7TMjtbzi3VNyTfL85ESy425yPlYde9TWGsSvp9/eX8It/ss7p5ZYZAAGAS OCTn9aAM+LwrcDU4bw3EcAjj2iO3Z1WH73CDPIO4eg4HFWtE0CbTLW+ikaANc7QPs5ZM4TbuJ6hj 1JFJD4rhnMOLG5RWO2UuAphJk8oAgnJ+b0HvUMviovBHKltJb7j5h8zaxaIxysGXBxnMR4P9aAIo vCVyjaYz3aYs2J2Rkoo+cMCMY3HAwScZzzVmHwssVpaxLNtkV2+1Ouf9IQnJU557L9AMCpj4jRIZ pPsszpGdiNlQZpBgFAuc559OaqQeLBPOXa1lhs/3bJNwWYNGzkMucjG0/lQA5/DV00hP2qMl1kUT EN5luWeRsx4PUhwD/ujr0qO18LXFvBYIs0Y+zXBmbczSKB8vCqwxk7Tzxt3Ejvmw3iuONNzWFxuU M8qbk/doqK5brz8rA4HNaFpq8V1fXNr5bRfZ8cykKXBOAQvXaTwD0PagDRHSigdKKAPG1YLbKjxJ JA+d0TD5Sev4H3qe3Gnx7QVkEfVomUHPtkEcVpLoUt1p2+2QtkbtrMAy/wBKoDSr1Yy0kK7hwfmF X7dxTVyVhYzcXYpazrLfMIYivnJtklbG4j0AHAHHSptDvpbaKWWNPMO35UHG4ngfz/Kq7+HdS1KQ RxwoqEDMjOPl5/OmiCQamfDNozh05vpyQCVAztXnpz+NdMZJU0zKpC1ZpbJl/XNQGqeH79gwaOEI uVHBO4cj8f0rmtK0a41XmFIkjQ/PJIeOV6YHXnmul1uwGmeDLmJVIQyJkkgljn/61Yvhu9ZBLAD8 uQw/lWsJShQbW5vTStoSapp17p+htFbyTXcUDCFnSAOS+AenXisfwJLqt7rLIb2Wzt1nE8o2YaY9 NuT2x2rpLnUCLWwCPJGRevI5jbaSobH58YrOkuAt+18GKysSAw6rk9vSvKnSjq1uzrjWk7X6HPax od5f65qMsMJ8wytKYiApCk8EV2PwfJcaujsqYaJSrcdAa5y7Fx9rYRSku6l0J6HHVW9a6D4VtGV1 aclm3yx4IGOxzXRF3hy2MJaO56K3yNtV4AMjg1dkAngeGRo5EcsrKwyCD1zWdJPaeapMByWAFaKN B5xAi5JqY6MiTbRjz+GdOazKxWWno/8ACTCv+FYOp6Vb2mmF4V01GUc4iXn9K7yQQiLHl9KxdTit J7dg1pG/GGDDt7e9bQepk4qx5/LqEtlbPBBJaRQmLeyRoAGJHPGK59/GWopuWPVJY1QYRcAgD0HF b2sR2AkkiiiG7ygu4DA6cVxFxoc26QxhSvbmuirGSiuVGcY3Wp9QWpLWkLE5JRT+lTVlW2t6clrC pueRGoPyN6fSpf7d03/n5/8AHG/wrzzoNCis/wDt3Tf+fn/xxv8ACj+3dN/5+f8Axxv8KANCq91Z W19AYLuCOeInOyRdwqv/AG7pv/Pz/wCON/hR/bum/wDPz/443+FAEw02yVQotYQo6Dyxj7u3/wBB AH04pINMsba0a0gtIY7ds7olQBTnrkVF/bum/wDPz/443+FH9u6b/wA/P/jjf4UAMi8PaVDdxXMV lEjwIViAUbUyxYkDsST1p1noOmWNqLaCzi8sHJ3KCWOCCSe5wSPxNL/bum/8/P8A443+FH9u6b/z 8/8Ajjf4UAPfR9NkaVnsbdmlUK5MY+YDoDSppOnRNE0dlAphUJHiMfKo6AfnUf8Abum/8/P/AI43 +FH9u6b/AM/P/jjf4UASR6Tp8UXlR2UCJhhtEYxhvvfn3pw02zUyEWsQMrB5DsHzEHIJ+hAqH+3d N/5+f/HG/wAKP7d03/n5/wDHG/woAv0VQ/t3Tf8An5/8cb/CigD/2Q== ------=_NextPart_000_034D_01C7ADA5.C23C0170-- --===============1456499084== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1456499084==-- From ecrit-bounces@ietf.org Wed Jun 13 10:54:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUEi-0004bj-Fs; Wed, 13 Jun 2007 10:54:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUEh-0004be-Cp for ecrit@ietf.org; Wed, 13 Jun 2007 10:54:15 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyUEf-0003Pw-I0 for ecrit@ietf.org; Wed, 13 Jun 2007 10:54:15 -0400 X-SEF-Processed: 5_0_0_910__2007_06_13_10_01_53 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 13 Jun 2007 10:01:52 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jun 2007 09:54:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Wed, 13 Jun 2007 09:54:10 -0500 Message-ID: In-Reply-To: <034c01c7adc7$494da170$9501a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives Thread-Index: AceqV4ZeonTtWSgmTEKwTanATYJDUQCpIGKwAA63d4AABo3GsAAO+O4AAAphx5AAABwDcAACwHSQAAA8QlAAAHs3oAAAT9dQAAA9rSAAAEcxAA== References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com> <012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com> <023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com> <02e301c7adc2$813763a0$9501a8c0@cis.neustar.com> <030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com> <034c01c7adc7$494da170$9501a8c0@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , X-OriginalArrivalTime: 13 Jun 2007 14:54:12.0211 (UTC) FILETIME=[B43AF430:01C7ADCA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6fd0f59403cb35add9752da1f6c9ce67 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1404968778==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1404968778== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7ADCA.B401CFBF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7ADCA.B401CFBF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nobody has suggested changing LoST so this point is just a distraction.=0D=0A=0D= =0A=20=0D=0A=0D=0AOption 1 means that emergency calls will not be able to b= e routed until=0D=0Athe forest guide network is implemented. Option 3 means= that emergency=0D=0Acalls will be able to be routed regardless of the stat= e of deployment of=0D=0Athe forest guide.=0D=0A=0D=0A=20=0D=0A=0D=0AI'm of = the opinion that option 3 is good enough for now and option 1 is=0D=0Anot g= ood enough for now and, in fact, that's true regardless of a desire=0D=0Ato= provide location hiding or not.=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D= =0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A________________________________=0D=0A=0D= =0AFrom: Brian Rosen [mailto:br@brianrosen.net]=20=0D=0ASent: Thursday, 14 = June 2007 12:30 AM=0D=0ATo: Dawson, Martin; ecrit@ietf.org=0D=0ASubject: RE= : [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D= =0AThis will be my last message on this particular thread, I don't think=0D= =0Awe're getting anywhere.=0D=0A=0D=0A=20=0D=0A=0D=0AI don't want to extend= the development of LoST to add this feature. I=0D=0Aagree with Andy: Opti= on #1 is good enough FOR NOW, and we can work on=0D=0Aother options later.=0D= =0A=0D=0A=20=0D=0A=0D=0ABrian=0D=0A=0D=0A=20=0D=0A=0D=0A___________________= _____________=0D=0A=0D=0AFrom: Dawson, Martin [mailto:Martin.Dawson@andrew.= com]=20=0D=0ASent: Wednesday, June 13, 2007 10:24 AM=0D=0ATo: Brian Rosen; = ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3 - summary of per= spectives=0D=0A=0D=0A=20=0D=0A=0D=0ASo that would be to say that=0D=0A=0D=0A= =20=0D=0A=0D=0Ai) We can't change LoST=0D=0A=0D=0Aii) = We can't change the forest guide (even though it's=0D=0Anot done = yet)=0D=0A=0D=0Aiii) We can't change anything that means that = a VSP would=0D=0Ahave a way to verify a URI=3F=0D=0A=0D=0A=20=0D=0A=0D=0AI'= m pretty sure we could define a "here's a URI, provide a Boolean=0D=0Arespo= nse" protocol element without a significant delay. So this seems=0D=0Alike = a contrived obstruction...=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMar= tin=0D=0A=0D=0A=20=0D=0A=0D=0A________________________________=0D=0A=0D=0AF= rom: Brian Rosen [mailto:br@brianrosen.net]=20=0D=0ASent: Thursday, 14 June= 2007 12:19 AM=0D=0ATo: Dawson, Martin; ecrit@ietf.org=0D=0ASubject: RE: [E= crit] Proposals 1 and 3 - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0A= Hello=3F=0D=0A=0D=0A=20=0D=0A=0D=0AEven if we were to include URI validatio= n as one of the forest guide's=0D=0Atasks, which I'm not sure is the right = way, that isn't enough; we need a=0D=0Aprotocol mechanism to implement it. = THAT is what I want to defer, at=0D=0Aleast for now.=0D=0A=0D=0A=20=0D=0A=0D= =0AI also don't want that problem delaying development of forest guides. =0D= =0A=0D=0A=20=0D=0A=0D=0ABrian=0D=0A=0D=0A=20=0D=0A=0D=0A___________________= _____________=0D=0A=0D=0AFrom: Dawson, Martin [mailto:Martin.Dawson@andrew.= com]=20=0D=0ASent: Wednesday, June 13, 2007 10:07 AM=0D=0ATo: Brian Rosen; = ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3 - summary of per= spectives=0D=0A=0D=0A=20=0D=0A=0D=0AI understood that "later please" was a = request with respect to LoST...=0D=0Awhich is why I'm avoiding it.=0D=0A=0D= =0A=20=0D=0A=0D=0AOption 1, as I understand it, can't work at all until the= forest guide=0D=0Adefinitions are completed and, in fact, until the actual= forest guide=0D=0Asystem/network is *implemented*. So I'm suggesting that = the URI=0D=0Avalidation be added to the, still in development, forest guide=0D= =0Aspecification.=0D=0A=0D=0A=20=0D=0A=0D=0AIn the mean time, option 3 work= s regardless and, as the URI validation=0D=0Abecomes available through the = forest guide network, then the issue of=0D=0A"pretend" emergency calls is o= bviated as well.=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D= =0A=20=0D=0A=0D=0A________________________________=0D=0A=0D=0AFrom: Brian R= osen [mailto:br@brianrosen.net]=20=0D=0ASent: Wednesday, 13 June 2007 11:55= PM=0D=0ATo: Dawson, Martin; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Propo= sals 1 and 3 - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0AI don't un= derstand how this would work. The forest guide thing doesn't=0D=0Aneed any= more protocol function than we have already. There is no=0D=0Afunction I = know of in LoST that would accept a URI as a query and return=0D=0Aanything= resembling or computable to a Boolean (valid) in response.=0D=0AThat's som= e kind of protocol mechanism. Whether the implementation of=0D=0Athat is r= everse lookup or flooding or some other mechanism would have to=0D=0Abe inv= ented, and using some of the forest guide ideas may work, but it's=0D=0Aqui= te a stretch from where we are now, and needs a new protocol=0D=0Amechanism= of some sort.=0D=0A=0D=0A=20=0D=0A=0D=0AWe can do that, but later, please.=0D= =0A=0D=0A=20=0D=0A=0D=0ABrian=0D=0A=0D=0A=20=0D=0A=0D=0A___________________= _____________=0D=0A=0D=0AFrom: Dawson, Martin [mailto:Martin.Dawson@andrew.= com]=20=0D=0ASent: Wednesday, June 13, 2007 8:37 AM=0D=0ATo: Brian Rosen; e= crit@ietf.org=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3 - summary of pers= pectives=0D=0A=0D=0A=20=0D=0A=0D=0AOK, well neither did I. I didn't underst= and where the proposition of=0D=0A"both" came in with respect to LoST. I on= ly know of reverse-lookup as=0D=0Abeing discussed as a potential LoST funct= ion.=0D=0A=0D=0A=20=0D=0A=0D=0AI am suggesting that, as yet another possibi= lity and in the spirit of=0D=0Anot just giving up (and saying, we've looked= after VSP operator=0D=0Ainterests but we won't worry about the LIS operato= rs so much) is that=0D=0Avalidating a PSAP URI could also be a forest guide= function.=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A =0D= =0A=0D=0A________________________________=0D=0A=0D=0AFrom: Brian Rosen [mai= lto:br@brianrosen.net]=20=0D=0ASent: Wednesday, 13 June 2007 10:31 PM=0D=0A= To: Dawson, Martin; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Proposals 1 an= d 3 - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0AI don't see any cha= nges needed in LoST for forest guides. =20=0D=0A=0D=0A=20=0D=0A=0D=0ABrian=0D= =0A=0D=0A=20=0D=0A=0D=0A________________________________=0D=0A=0D=0AFrom: D= awson, Martin [mailto:Martin.Dawson@andrew.com]=20=0D=0ASent: Wednesday, Ju= ne 13, 2007 3:38 AM=0D=0ATo: Brian Rosen; ecrit@ietf.org=0D=0ASubject: RE: = [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D= =0AI wasn't suggesting they were an identical level of definition. I was=0D= =0Asaying that it's still not definitive solution; of course it's a matter=0D= =0Aof degree. Without a definitive forest guide solution, how does a VSP=0D= =0Aknow how to find the right LoST server to find the PSAP URI=3F At least=0D= =0Awith option 3, the PSAP URI is provided at the point of local knowledge=0D= =0Awhere the applicable LoST server is known.=0D=0A=0D=0A=20=0D=0A=0D=0APul= l your last comment apart for me... are you saying that the "forest=0D=0Agu= ide" implementation requires changes to LoST=3F Without those changes,=0D=0A= the Forest Guide won't work either=3F=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D= =0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A________________________________=0D=0A=0D= =0AFrom: Brian Rosen [mailto:br@brianrosen.net]=20=0D=0ASent: Wednesday, 13= June 2007 10:28 AM=0D=0ATo: Dawson, Martin; ecrit@ietf.org=0D=0ASubject: R= E: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D= =0AI'm sorry but the forest guide idea is a whole lot more developed that=0D= =0Aany notion of an authoritative list of PSAP URIs. I'm not saying it=0D=0A= can't be done, I'm saying we need a whole lot more work on it to make it=0D= =0Areal, and it's not at all clear to me that the reverse lookup idea has=0D= =0Amore or less merit. However, both of them are beyond what I think is=0D= =0Aappropriate for LoST at this point.=0D=0A=0D=0A=20=0D=0A=0D=0ABrian=0D=0A=0D= =0A=20=0D=0A=0D=0A________________________________=0D=0A=0D=0AFrom: Dawson,= Martin [mailto:Martin.Dawson@andrew.com]=20=0D=0ASent: Tuesday, June 12, 2= 007 5:19 PM=0D=0ATo: Brian Rosen; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] = Proposals 1 and 3 - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0AWell = hand waving was about all I could invest in an email, but are you=0D=0Asayi= ng you'd just have to give up at that stage=3F What is a reference to=0D=0A= a "forest guide", if it's not a particularly low-detail suggestion of=0D=0A= the sort of thing we need to resolve the right LoST server=3F Yet, without=0D= =0Athat, option 1 doesn't work. Why wouldn't this "validation" be a=0D=0Afu= nction of that system and why is reverse lookup the only option=3F=0D=0A=0D= =0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A_____= ___________________________=0D=0A=0D=0AFrom: Brian Rosen [mailto:br@brianro= sen.net]=20=0D=0ASent: Wednesday, 13 June 2007 12:18 AM=0D=0ATo: Dawson, Ma= rtin; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3 - summary = of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0AI think those of us pushing for O= ption 1 for now is that we think VSP=0D=0Avalidation is a fact of life we h= ave to deal with, waving hands over=0D=0A"reference to a relatively static = table maintained by global=0D=0Acooperation" is not adequate, and something= like a reverse lookup is=0D=0Arequired. This would be a change to LoST an= d we are reluctant to take=0D=0Athis change on at this time.=0D=0A=0D=0A =0D= =0A=0D=0ABrian=0D=0A=0D=0A=20=0D=0A=0D=0A________________________________=0D= =0A=0D=0AFrom: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20=0D=0ASen= t: Tuesday, June 12, 2007 10:08 AM=0D=0ATo: ecrit@ietf.org=0D=0ASubject: [E= crit] Proposals 1 and 3 - summary of perspectives=0D=0A=0D=0A=20=0D=0A=0D=0A= For some reason this hasn't made it through moderation. Now I'm a list=0D=0A= subscriber, I'll try again...=0D=0A=0D=0A=20=0D=0A=0D=0AIt's a long weekend= in Australia and winter has finally hit - with cold=0D=0Awind and rain. Wh= at better time, then, to spend some time catching up=0D=0Awith the action o= n the ECRIT list. I only went back a couple of weeks;=0D=0Aobviously the ma= in topic has been to do with the question of how to=0D=0Adefine the "locati= on hiding" capability. Mostly it's a debate about the=0D=0Autility of optio= n 1 and 3.=0D=0A=0D=0A=20=0D=0A=0D=0AHaving just read through all the posti= ngs and while they are fresh in my=0D=0Amind, here is how I characterize th= e perspectives. First my summary of=0D=0Athe options...=0D=0A=0D=0A=20=0D=0A=0D= =0A*=09Option 1 achieves location hiding, somewhat oxymoronically, by=0D=0A= providing location. Whether it's by reference to the local LoST facility=0D= =0Aor by some internal knowledge, the LIS generates a coarse location which=0D= =0Ait knows will result in a correct PSAP URI resolution if/when another=0D= =0Aparty makes a request to the LoST facility. This is provided in addition=0D= =0Ato a location reference for subsequent accurate location requests from=0D= =0Athe PSAP for dispatch etc.=0D=0A*=09Option 3 achieves location hiding by= making the request to the=0D=0Alocal LoST facility using the end points lo= cation and providing the PSAP=0D=0AURI that the LoST service returns (in ad= dition to a location reference)=0D=0Aso the call can be routed to that PSAP= - whether directly from the=0D=0Adevice or via a proxy/VSP.=0D=0A=0D=0A =0D= =0A=0D=0ABoth suggestions are based on an assumption that a LIS, being asso= ciated=0D=0Awith the local jurisdiction, has enough local knowledge to iden= tify the=0D=0Acorrect LoST service for that jurisdiction or, at least in th= e case of=0D=0Aoption 1, to determine what "coarse location" isn't too coar= se.=0D=0A=0D=0A=20=0D=0A=0D=0APerspective 1 - articulated by a lot of peopl= e, Ted, Brian, Andy,...=0D=0Aetc. is that LoST needs to progress and get to= a first release and=0D=0Achanges associated with this particular use case = should be avoided for=0D=0Anow. I haven't seen anything in either proposal = that does require a=0D=0Achange to LoST. In the one case either or both of = the LIS and VSP/proxy=0D=0Amake LoST queries but neither options appears to= *dictate* a specific=0D=0Achange to LoST.=0D=0A=0D=0A=20=0D=0A=0D=0APerspe= ctive 2 - articulated by, for example, James W and Barbara is that=0D=0Athe= LIS operator should have the option of providing location or not - a=0D=0A= "coarse location" is still a location and location information to the=0D=0A= granularity of PSAP boundaries, for example, could still support a lot=0D=0A= of value-added services and be used for other than emergency services.=0D=0A=0D= =0A=20=0D=0A=0D=0APerspective 3 - articulated by, for example, Andy and Lau= ra is that,=0D=0Awhen the end-point initiates a call through the VSP/proxy = with a=0D=0Apre-determined PSAP URI, the proxy may not know that this reall= y is a=0D=0Agenuine emergency call destination. In fact it could be used to= call=0D=0Aanyone by just pretending it's an emergency call. This means the= VSP may=0D=0Alose call revenue through the fraudulent nomination of emerge= ncy calls.=0D=0A=0D=0A=20=0D=0A=0D=0APerspective 4 - articulated by, in par= ticular, Hannes (sorry Hannes, I=0D=0Acan't see anyone else emphasising thi= s point) is that all emergency=0D=0Acalls should go through a VSP so that t= here's an authenticated=0D=0Asubscriber identity to be associated with the = call. This seems like an=0D=0Aorthogonal point to me. If we accept that som= e calls will go through=0D=0AVSPs and therefore Perspective 3 is valid then= the question of whether=0D=0Aall emergency calls have to go through a VSP = is moot. I have to admit to=0D=0Abeing really surprised by the perspective = - it wasn't one that I thought=0D=0Ahad any currency in this forum.=0D=0A=0D= =0A=20=0D=0A=0D=0A=20=0D=0A=0D=0AThere were miscellaneous other perspective= s including some good=0D=0Asuggestions for alternatives/compromises from Ri= chard and Henning.=0D=0A=0D=0A=20=0D=0A=0D=0AMartin D's perspective -=0D=0A=0D= =0A=20=0D=0A=0D=0A*=09On perspective 1, I don't see any impediment to pushi= ng LoST=0D=0Aout. Even if there are changes to come, they can be done in a = revision=0D=0Aor whatever. But I haven't seen any definitive statement abou= t how=0D=0Aeither option *requires* a change to LoST.=0D=0A*=09On perspecti= ve 4, I don't think it's decisive in the discussion.=0D=0A*=09So, really, i= t boils down to an evaluation of which of=0D=0Aperspectives 2 and 3 are the= most valid - i.e. are the interests of the=0D=0ALIS operator or a VSP to h= ave priority.=0D=0A=0D=0A=20=0D=0A=0D=0AI don't understand why the interest= s of LIS operators and VSPs can't=0D=0Aboth be served. I'm surprised that w= ith all the experience and knowledge=0D=0Ain the forum that nobody can prov= ide a practical way for a proxy/VSP to=0D=0Adetermine whether a PSAP URI is= a valid emergency destination or not. I=0D=0Aknow that adding the reverse-= lookup to LoST has been discussed. That=0D=0Awould be effective, but it's n= ot in keeping with perspective 1. Surely,=0D=0Athough, there are alternativ= es.=0D=0A=0D=0A=20=0D=0A=0D=0AI think option 3 supports a faster and smooth= er deployment of global=0D=0Aemergency calling for VoIP. Here's my rational= e.=0D=0A=0D=0A=20=0D=0A=0D=0A1.=09Both options require a LoST and LIS capab= ility to exist at a=0D=0Alocal and jurisdictional level - so their availabi= lity is a premise in=0D=0Aeither proposal=0D=0A2.=09Option 1 assumes that e= ach VSP can make an effective LoST query=0D=0Aeven if it is a "non-local" V= SP to the point from where the call is=0D=0Abeing originated. This is eithe= r by the VSP automatically knowing which=0D=0ALoST server is applicable to = the coarse location or by the use of the so=0D=0Acalled forest guide and pe= rhaps some international hierarchy of=0D=0Ainterconnected LoST servers.=0D=0A= 3.=09Option 3 only assumes that this local knowledge is in the local=0D=0AL= IS function and doesn't rely on the existence of the infrastructure=0D=0Ade= scribed in point 2.=0D=0A4.=09The ability to verify a destination PSAP URI = as a valid=0D=0Aemergency URI could be supported by reference to a relative= ly static=0D=0Atable maintained by global cooperation. In fact, I would hav= e thought=0D=0Athat filtering based on domain name would be extremely relia= ble and=0D=0Afast. It would certainly obviate the ability to make arbitrary= calls by=0D=0Apretending they are emergency calls.=0D=0A5.=09Perhaps a lat= er revision of LoST can include the reverse-lookup=0D=0Amechanism and, perh= aps by then, the international infrastructure of LoST=0D=0Aservers, forest = guides, etc. may be in place.=0D=0A=0D=0A=20=0D=0A=0D=0AI mention point 4 a= s one possible way to protect the interest of the=0D=0AVSPs without requiri= ng a change to the current LoST definition. Are=0D=0Athere any other propos= als on how to achieve this or, alternatively, a=0D=0Aview that it simply is= n't possible=3F=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0AMartin=0D=0A=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0AThis message is for the designated recipient = only and may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C7ADCA.B401CFBF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A= =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= =0D=0A=0D=0A
=0D=0A=0D=0A

Nob= ody has suggested changing LoST so this=0D=0Apoint is just a distraction.

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

 

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

Option 1 means that emergency c= alls will=0D=0Anot be able to be routed until the forest guide network is i= mplemented. Option=0D=0A3 means that emergency calls will be able to be rou= ted regardless of the state=0D=0Aof deployment of the forest guide.

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

 

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

I’m of the opinion that option 3= is=0D=0Agood enough for now and option 1 is not good enough for now and, i= n fact,=0D=0Athat’s true regardless of a desire to provide location h= iding or not.

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

=  

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

Cheers,

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

Martin

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

 

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

From:=0D=0ABrian Rosen [mailto:br@brianrosen.ne= t]
=0D=0ASent: Thursday,= 14 June 2007 12:30=0D=0AAM
=0D=0ATo= : Dawson, Martin; ecrit@ietf.org
=0D=0ASubject: RE: [Ecrit] Proposals 1=0D=0Aand 3 - summ= ary of perspectives

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

 

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

This will be my last=0D=0Amessage on this particular thread= , I don’t think we’re getting=0D=0Aanywhere.<= /font>

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

 

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

I don’t want to=0D= =0Aextend the development of LoST to add this feature.  I agree with A= ndy:=0D=0AOption #1 is good enough FOR NOW, and we can work on other option= s later.

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

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

= Brian

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

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

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

<= span lang=3DEN-US=0D=0Astyle=3D'font-size:10.0pt;font-family:Tahoma;font-we= ight:bold'>From:=0D=0ADawson, Mar= tin [mailto:Martin.Dawson@andrew.com]
=0D=0ASent: Wednesday, June 13, 2007=0D=0A10:24 AM
=0D=0A<= b>To: Brian Rosen; ecrit@ietf.o= rg
=0D=0ASubject: RE: [Ec= rit] Proposals 1=0D=0Aand 3 - summary of perspectives

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

 

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

So that would be to say= that

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

 

=0D=0A=0D=0Ai)    =             =0D= =0AWe=0D=0Acan’t change LoST

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

ii)   &nb= sp;           =0D=0A= We=0D=0Acan’t change the forest guide (even though it’s not = done yet)

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

iii)       &nb= sp;     =0D=0A<= ![endif]>We=0D=0Acan’t change anythi= ng that means that a VSP would have a way to verify a=0D=0AURI=3F

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

 

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

I’m pretty sure we could define = a=0D=0A“here’s a URI, provide a Boolean response” protoco= l element=0D=0Awithout a significant delay. So this seems like a contrived = obstruction…

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

 

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

Cheers,

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

Martin

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

 =

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

From:=0D=0ABrian Rosen [mailto:br@brianros= en.net]
=0D=0ASent: Thur= sday, 14 June 2007 12:19=0D=0AAM
=0D=0ATo: Dawson, Martin; ecrit@ietf.org
=0D=0ASubject: RE: [Ecrit] Proposals 1=0D=0Aand 3 -= summary of perspectives=

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

 <= /span>

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

Hello=3F

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

 

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

Even if we were to=0D=0Ainclude URI validation as on= e of the forest guide’s tasks, which=0D=0AI’m not sure is the r= ight way, that isn’t enough; we need a=0D=0Aprotocol mechanism to imp= lement it.  THAT is what I want to defer, at=0D=0Aleast for now.<= /o:p>

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

 

=0D=0A=0D=0A<= p class=3DMsoNormal>I also do= n’t want=0D=0Athat problem delaying development of forest guides.&nbs= p;

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

 

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

Brian=

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

 

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

F= rom:=0D=0ADawson, Martin [mailto:= Martin.Dawson@andrew.com]
=0D=0ASen= t: Wednesday, June 13, 2007=0D=0A10:07 AM
=0D=0ATo: Brian Rosen; ecrit@ietf.org
=0D=0A= Subject: RE: [Ecrit] Proposa= ls 1=0D=0Aand 3 - summary of perspectives<= o:p>

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

 

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

I understood that “later=0D=0A= please” was a request with respect to LoST… which is why I̵= 7;m=0D=0Aavoiding it.

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

 

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

Option 1, a= s I understand it, can’t=0D=0Awork at all until the forest guide defi= nitions are completed and, in fact,=0D=0Auntil the actual forest guide syst= em/network is *implemented= *. So I’m suggesting that the URI validation be=0D=0Aadded to the= , still in development, forest guide specification.

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

 

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

In the mean time, option 3 works=0D=0Aregardless an= d, as the URI validation becomes available through the forest=0D=0Aguide ne= twork, then the issue of “pretend” emergency calls is=0D=0Aobvi= ated as well.

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

=  

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

Cheers,

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

Martin

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

 

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

From:=0D=0ABrian Rosen [mailto:br@brianrosen.ne= t]
=0D=0ASent: Wednesday= , 13 June 2007=0D=0A11:55 PM
=0D=0AT= o: Dawson, Martin; ecrit@ietf.org
=0D=0ASubject: RE: [Ecrit] Proposals 1=0D=0Aand 3 - sum= mary of perspectives

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

 

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

I don’t understand=0D=0Ahow this would work.  Th= e forest guide thing doesn’t need any more=0D=0Aprotocol function tha= n we have already.  There is no function I know of in=0D=0ALoST that w= ould accept a URI as a query and return anything resembling or=0D=0Acomputa= ble to a Boolean (valid) in response.  That’s some kind of=0D=0A= protocol mechanism.  Whether the implementation of that is reverse loo= kup=0D=0Aor flooding or some other mechanism would have to be invented, and= using some=0D=0Aof the forest guide ideas may work, but it’s quite a= stretch from where=0D=0Awe are now, and needs a new protocol mechanism of = some sort.

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

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

We can do that, but=0D=0Alater, please.

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

 

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

Brian

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

 

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

= From:=0D=0ADawson, Martin [mailto:Martin.Dawson@andrew.com]
=0D= =0ASent: Wednesday, June 13,= 2007=0D=0A8:37 AM
=0D=0ATo:<= /b> Brian Rosen; ecrit@ietf.org
=0D=0ASubject: RE: [Ecrit] Proposals 1=0D=0Aand 3 - summary of persp= ectives

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

 

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

OK, well neither did I. I didn’t=0D=0Aunderstand where the prop= osition of “both” came in with respect to=0D=0ALoST. I only kno= w of reverse-lookup as being discussed as a potential LoST=0D=0Afunction.

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

 

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

I am suggesting that, as yet an= other=0D=0Apossibility and in the spirit of not just giving up (and saying,= we’ve=0D=0Alooked after VSP operator interests but we won’t wo= rry about the LIS=0D=0Aoperators so much) is that validating a PSAP URI cou= ld also be a forest guide=0D=0Afunction.

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

 =

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

Cheers,

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

Martin

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

 =

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

From:=0D=0ABrian Ros= en [mailto:br@brianrosen.net]
=0D=0ASent: Wednesday, 13 June 2007=0D=0A10:31 PM
=0D=0ATo: Dawson, Martin; ecrit@ietf.org
=0D= =0ASubject: RE: [Ecrit] Prop= osals 1=0D=0Aand 3 - summary of perspectives

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

=  

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

I don’t see any=0D=0Achang= es needed in LoST for forest guides. 

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

 

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

Brian

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

 

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

= From:=0D=0ADawson, Martin [mailto:Martin.Dawson@andrew.com]
=0D= =0ASent: Wednesday, June 13,= 2007=0D=0A3:38 AM
=0D=0ATo:<= /b> Brian Rosen; ecrit@ietf.org
=0D=0ASubject: RE: [Ecrit] Proposals 1=0D=0Aand 3 - summary of persp= ectives

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

 

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

I wasn’t suggesting they were an=0D=0Aidentical level of defini= tion. I was saying that it’s still not=0D=0Adefinitive solution; of c= ourse it’s a matter of degree. Without a=0D=0Adefinitive forest guide= solution, how does a VSP know how to find the right=0D=0ALoST server to fi= nd the PSAP URI=3F At least with option 3, the PSAP URI is=0D=0Aprovided at= the point of local knowledge where the applicable LoST server is=0D=0Aknow= n.

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

 

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

Pull your last comment apar= t for me…=0D=0Aare you saying that the “forest guide” imp= lementation requires=0D=0Achanges to LoST=3F Without those changes, the For= est Guide won’t work=0D=0Aeither=3F

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

 =

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

Cheers,

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

Martin

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

 =

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

From:=0D=0ABrian Ros= en [mailto:br@brianrosen.net]
=0D=0ASent: Wednesday, 13 June 2007=0D=0A10:28 AM
=0D=0ATo: Dawson, Martin; ecrit@ietf.org
=0D= =0ASubject: RE: [Ecrit] Prop= osals 1=0D=0Aand 3 - summary of perspectives

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

=  

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

I’m sorry but the=0D=0Afor= est guide idea is a whole lot more developed that any notion of an=0D=0Aaut= horitative list of PSAP URIs.  I’m not saying it can’t be=0D= =0Adone, I’m saying we need a whole lot more work on it to make it re= al, and=0D=0Ait’s not at all clear to me that the reverse lookup idea= has more or less=0D=0Amerit.  However, both of them are beyond what I= think is appropriate for=0D=0ALoST at this point.=

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

 

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

Brian

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

 

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

From:= =0D=0ADawson, Martin [mailto:Martin.Dawson@andrew.c= om]
=0D=0ASent: Tuesday,= June 12, 2007 5:19=0D=0APM
=0D=0ATo= : Brian Rosen; ecrit@ietf.org
=0D=0ASubject: RE: [Ecrit] Proposals 1=0D=0Aand 3 - summary= of perspectives

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

 =

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

Well hand waving was about all I could=0D=0Ainvest in an email, b= ut are you saying you’d just have to give up at that=0D=0Astage=3F Wh= at is a reference to a “forest guide”, if it’s not a=0D=0A= particularly low-detail suggestion of the sort of thing we need to resolve = the=0D=0Aright LoST server=3F Yet, without that, option 1 doesn’t wor= k. Why=0D=0Awouldn’t this “validation” be a function of t= hat system and=0D=0Awhy is reverse lookup the only option=3F

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

 

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

<= font size=3D2 color=3Dnavy face=3DArial>Cheers,

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

Martin=

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

 

=0D=0A=0D=0A
=0D=0A=0D=0A<= div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A

From:=0D=0ABrian Rosen [mailto:br@brianrosen.net]
=0D=0ASent: Wednesday, 13 June 2007=0D=0A12:18 A= M
=0D=0ATo: Dawson, Marti= n; ecrit@ietf.org
=0D=0A= Subject: RE: [Ecrit] Proposa= ls 1=0D=0Aand 3 - summary of perspectives<= o:p>

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

 

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

I think those of us=0D=0Apushing fo= r Option 1 for now is that we think VSP validation is a fact of life=0D=0Aw= e have to deal with, waving hands over “referenc= e to a=0D=0Arelatively static table maintained by global cooperation= ” is not a= dequate, and something like a=0D=0Areverse lookup is required.  This w= ould be a change to LoST and we are=0D=0Areluctant to take this change on a= t this time.

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

<= font size=3D2 color=3Dblue face=3DArial> 

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

Brian

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

 

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A<= hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>=0D=0A=0D=0A=
=0D=0A=0D=0A

From:=0D=0ADawson,= Martin [mailto:Martin.Dawson@andrew.com]
=0D=0ASent: Tuesday, June 12, 2007 10:08=0D=0AAM
=0D=0A= To: ecrit@ietf.org
=0D=0ASubject: [Ecrit] Proposals 1 and 3=0D=0A- summary of persp= ectives

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

 

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

= For some reason th= is hasn’t made it through=0D=0Amoderation. Now I’m a list subsc= riber, I’ll try again…

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

 

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

It’s a long weekend in Australia and winter has finally=0D=0Ahit – with cold wind and= rain. What better time, then, to spend some time=0D=0Acatching up with the= action on the ECRIT list. I only went back a couple of=0D=0Aweeks; obvious= ly the main topic has been to do with the question of how to=0D=0Adefine th= e “location hiding” capability. Mostly it’s a debate=0D=0A= about the utility of option 1 and 3.

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

 

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

Having just read through all the postings= and while they are=0D=0Afresh in my mind, here is how I characterize the p= erspectives. First my summary=0D=0Aof the options…<= /font>

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

 

=0D=0A=0D=0A
    =0D=0A Option 1= achieves location=0D=0A hiding, somewhat oxymoronically, by providing = location. Whether it’s=0D=0A by reference to the local LoST facil= ity or by some internal knowledge, the=0D=0A LIS generates a coarse loc= ation which it knows will result in a correct=0D=0A PSAP URI resolution= if/when another party makes a request to the LoST=0D=0A facility. This= is provided in addition to a location reference for=0D=0A subsequent a= ccurate location requests from the PSAP for dispatch etc.= =0D=0A
  • = Option 3 achieves location=0D=0A hiding by making the req= uest to the local LoST facility using the end=0D=0A points location and= providing the PSAP URI that the LoST service returns=0D=0A (in additio= n to a location reference) so the call can be routed to that=0D=0A PSAP= – whether directly from the device or via a proxy/VSP.
    • =0D=0A
=0D=0A=0D=0A

=  

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

Bot= h suggestions are based on an assumption that a LIS,=0D=0Abeing associated = with the local jurisdiction, has enough local knowledge to=0D=0Aidentify th= e correct LoST service for that jurisdiction or, at least in the=0D=0Acase = of option 1, to determine what “coarse location” isn’t=0D= =0Atoo coarse.

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

 

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

Perspective 1 – articulated by a lot of people, Ted,=0D= =0ABrian, Andy,… etc. is that LoST needs to progress and get to a fir= st=0D=0Arelease and changes associated with this particular use case should= be avoided=0D=0Afor now. I haven’t seen anything in either proposal = that does require a=0D=0Achange to LoST. In the one case either or both of = the LIS and VSP/proxy make=0D=0ALoST queries but neither options appears to= *dictate*=0D=0Aa specific c= hange to LoST.

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

 

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

Perspective 2 – articulated by, for example, James W=0D= =0Aand Barbara is that the LIS operator should have the option of providing=0D= =0Alocation or not – a “coarse location” is still a locat= ion and=0D=0Alocation information to the granularity of PSAP boundaries, fo= r example, could=0D=0Astill support a lot of value-added services and be us= ed for other than=0D=0Aemergency services.

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

 

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

Perspective 3 – articulated by, for= example, Andy and=0D=0ALaura is that, when the end-point initiates a call = through the VSP/proxy with a=0D=0Apre-determined PSAP URI, the proxy may no= t know that this really is a genuine=0D=0Aemergency call destination. In fa= ct it could be used to call anyone by just=0D=0Apretending it’s an em= ergency call. This means the VSP may lose call=0D=0Arevenue through the fra= udulent nomination of emergency calls.

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

 

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

Perspective 4 – articulated by, in = particular, Hannes=0D=0A(sorry Hannes, I can’t see anyone else emphas= ising this point) is that=0D=0Aall emergency calls should go through a VSP = so that there’s an=0D=0Aauthenticated subscriber identity to be assoc= iated with the call. This seems=0D=0Alike an orthogonal point to me. If we = accept that some calls will go through=0D=0AVSPs and therefore Perspective = 3 is valid then the question of whether all=0D=0Aemergency calls have to go= through a VSP is moot. I have to admit to being=0D=0Areally surprised by t= he perspective – it wasn’t one that I thought=0D=0Ahad any curr= ency in this forum.

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

 

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

 

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

There were miscellaneous other perspectives including so= me=0D=0Agood suggestions for alternatives/compromises from Richard and Henn= ing.

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

 

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

Martin D’s perspective –

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

 

=0D=0A=0D= =0A
    =0D=0A
  • On perspective 1, I don’= ;t=0D=0A see any impediment to pushing LoST out. Even if there are chan= ges to come,=0D=0A they can be done in a revision or whatever. But I ha= ven’t seen any=0D=0A definitive statement about how either option= *requires* a cha= nge to LoST.
    • =0D=0A
  • On perspective 4, I don’t=0D= =0A think it’s decisive in the discussion.
    • =0D=0A
  • So, really, it boils down to an=0D=0A evaluation of which of p= erspectives 2 and 3 are the most valid –=0D=0A i.e. are the inter= ests of the LIS operator or a VSP to have priority.
    • =0D=0A
=0D=0A=0D=0A

 

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

I don’= t understand why the interests of LIS operators=0D=0Aand VSPs can’t b= oth be served. I’m surprised that with all the=0D=0Aexperience and kn= owledge in the forum that nobody can provide a practical way=0D=0Afor a pro= xy/VSP to determine whether a PSAP URI is a valid emergency destination=0D=0A= or not. I know that adding the reverse-lookup to LoST has been discussed. T= hat=0D=0Awould be effective, but it’s not in keeping with perspective= 1. Surely,=0D=0Athough, there are alternatives.=0D=0A=0D=0A

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

I think option 3 supports a f= aster and smoother deployment=0D=0Aof global emergency calling for VoIP. He= re’s my rationale.

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

 

=0D=0A=0D=0A
    =0D=0A
  1. Both options require a LoST and=0D=0A= LIS capability to exist at a local and jurisdictional level – so=0D= =0A their availability is a premise in either proposal
    2. =0D=0A
  2. Option 1 assumes that each VSP=0D=0A can make an effecti= ve LoST query even if it is a “non-local”=0D=0A VSP to the = point from where the call is being originated. This is either=0D=0A by = the VSP automatically knowing which LoST server is applicable to the=0D=0A = coarse location or by the use of the so called forest guide and perhaps=0D= =0A some international hierarchy of interconnected LoST servers.
    3. =0D=0A
  3. Option 3 only assumes that this=0D=0A local kn= owledge is in the local LIS function and doesn’t rely on the=0D=0A = existence of the infrastructure described in point 2.
    4. =0D=0A
  4. The ability to verify a=0D=0A destination PSAP URI as a val= id emergency URI could be supported by=0D=0A reference to a relatively = static table maintained by global cooperation.=0D=0A In fact, I would h= ave thought that filtering based on domain name would be=0D=0A extremel= y reliable and fast. It would certainly obviate the ability to=0D=0A ma= ke arbitrary calls by pretending they are emergency calls.
    5. =0D=0A
  5. Perhaps a later revision of=0D=0A LoST can include the r= everse-lookup mechanism and, perhaps by then, the=0D=0A international i= nfrastructure of LoST servers, forest guides, etc. may be=0D=0A in plac= e.
    6. =0D=0A
=0D=0A=0D=0A

 

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

I mention point 4 as one possible way to protect the=0D=0Aint= erest of the VSPs without requiring a change to the current LoST definition= =2E=0D=0AAre there any other proposals on how to achieve this or, alternati= vely, a view=0D=0Athat it simply isn’t possible=3F<= /font>

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

 

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

<= span style=3D'font-size:10.0pt;=0D=0Afont-family:Arial'>Cheers,<= /span>

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

Martin

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


-------= ---------------------------------------------------------------------------= --------------
=0D=0AThis message is for the de= signated recipient only and may
=0D=0Acontain p= rivileged, proprietary, or otherwise private infor= mation.  
=0D=0AIf you have received it&nb= sp;in error, please notify the sender
=0D=0Aimm= ediately and delete the original.  Any u= nauthorized use of
=0D=0Athis email is prohibit= ed.
=0D=0A--------------------------------------------------------------= ----------------------------------
=0D=0A[mf2]
=0D= =0A=0D=0A=0D=0A ------_=_NextPart_001_01C7ADCA.B401CFBF-- --===============1404968778== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1404968778==-- From ecrit-bounces@ietf.org Wed Jun 13 10:57:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUI3-0005JI-Uf; Wed, 13 Jun 2007 10:57:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUI2-0005It-W7 for ecrit@ietf.org; Wed, 13 Jun 2007 10:57:42 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyUHo-0004Zc-3i for ecrit@ietf.org; Wed, 13 Jun 2007 10:57:42 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5DEvC6e028794 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 13 Jun 2007 10:57:13 -0400 (EDT) In-Reply-To: References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com> <012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com> <023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com> <02e301c7adc2$813763a0$9501a8c0@cis.neustar.com> <030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com> <034c01c7adc7$494da170$9501a8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Wed, 13 Jun 2007 10:57:59 -0400 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 13, 2007, at 10:54 AM, Dawson, Martin wrote: > Nobody has suggested changing LoST so this point is just a > distraction. > > > > Option 1 means that emergency calls will not be able to be routed > until the forest guide network is implemented. Option 3 means that > emergency calls will be able to be routed regardless of the state > of deployment of the forest guide. > > This is not true, at least for comparable installations. The ISP can offer a LoST server that has the locally-relevant information. Same for the VSP. This does not require a forest guide as such. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 13 11:28:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUld-0003mV-1D; Wed, 13 Jun 2007 11:28:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyUlc-0003mQ-7C for ecrit@ietf.org; Wed, 13 Jun 2007 11:28:16 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyUla-00041V-VN for ecrit@ietf.org; Wed, 13 Jun 2007 11:28:16 -0400 X-SEF-Processed: 5_0_0_910__2007_06_13_10_35_53 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 13 Jun 2007 10:35:53 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jun 2007 10:28:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Wed, 13 Jun 2007 10:28:10 -0500 Message-ID: In-Reply-To: <1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives Thread-Index: AcetyyQsrWmQoBOJQoSm1kJgV7dmUgAAwvmA References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com> <012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com> <023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com> <02e301c7adc2$813763a0$9501a8c0@cis.neustar.com> <030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com> <034c01c7adc7$494da170$9501a8c0@cis.neustar.com> <1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> From: "Dawson, Martin" To: "Henning Schulzrinne" X-OriginalArrivalTime: 13 Jun 2007 15:28:12.0907 (UTC) FILETIME=[749473B0:01C7ADCF] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The ISP could... but that's the essence of Option 3; the LIS knows what=0D=0A= the local LoST server is because it is always local. It can get the PSAP=0D= =0AURI directly from that LoST server to provide to the device.=0D=0A=0D=0A= However a VSP in a completely different country from where the call is=0D=0A= originated can't inherently know which is the correct LoST server to go=0D=0A= to and query for the PSAP URI - which is the essence of option 1. Hence=0D=0A= the call can't be routed.=0D=0A=0D=0A"Comparable" installations, viz degree= of "localness", aren't the=0D=0Ainteresting case. With global VoIP operato= rs - which are quite common -=0D=0Athis is not a scenario that can be ignor= ed.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D= =0AFrom: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20=0D=0ASent: Thu= rsday, 14 June 2007 12:58 AM=0D=0ATo: Dawson, Martin=0D=0ACc: Brian Rosen; = ecrit@ietf.org=0D=0ASubject: Re: [Ecrit] Proposals 1 and 3 - summary of per= spectives=0D=0A=0D=0A=0D=0AOn Jun 13, 2007, at 10:54 AM, Dawson, Martin wro= te:=0D=0A=0D=0A> Nobody has suggested changing LoST so this point is just a= =20=0D=0A> distraction.=0D=0A>=0D=0A>=0D=0A>=0D=0A> Option 1 means that em= ergency calls will not be able to be routed =20=0D=0A> until the forest gui= de network is implemented. Option 3 means that =20=0D=0A> emergency calls w= ill be able to be routed regardless of the state =20=0D=0A> of deployment o= f the forest guide.=0D=0A>=0D=0A>=0D=0AThis is not true, at least for compa= rable installations. The ISP can =20=0D=0Aoffer a LoST server that has the = locally-relevant information. Same =20=0D=0Afor the VSP. This does not requ= ire a forest guide as such.=0D=0A=0D=0A------------------------------------= ------------------------------------------------------------=0D=0AThis mess= age is for the designated recipient only and may=0D=0Acontain privileged, p= roprietary, or otherwise private information. =20=0D=0AIf you have received= it in error, please notify the sender=0D=0Aimmediately and delete the orig= inal. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A--------= ---------------------------------------------------------------------------= -------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 13 13:09:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyWLH-0003qL-Jx; Wed, 13 Jun 2007 13:09:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyWLF-0003q5-Tv for ecrit@ietf.org; Wed, 13 Jun 2007 13:09:09 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyWLE-0000Mj-4b for ecrit@ietf.org; Wed, 13 Jun 2007 13:09:09 -0400 Received: from ([139.76.131.87]) by aismt06p.bellsouth.com with SMTP id KP-AXPRN.23936229; Wed, 13 Jun 2007 13:08:53 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 13 Jun 2007 13:08:22 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Wed, 13 Jun 2007 13:08:22 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Wed, 13 Jun 2007 13:07:59 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA04666D9D@crexc41p> In-Reply-To: <012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives thread-index: AceqV4ZeonTtWSgmTEKwTanATYJDUQCpIGKwAA63d4AABo3GsAAifjlQ References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com> <012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com> From: "Stark, Barbara" To: "Brian Rosen" , "Dawson, Martin" , X-OriginalArrivalTime: 13 Jun 2007 17:08:22.0278 (UTC) FILETIME=[7271B260:01C7ADDD] X-Spam-Score: 1.2 (+) X-Scan-Signature: feabeb183291298816c7cddac131c81f Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2121932582==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============2121932582== Content-Class: urn:content-classes:message Content-Type: multipart/related; boundary="----_=_NextPart_001_01C7ADDD.725C12C0"; type="multipart/alternative" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7ADDD.725C12C0 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7ADDD.725C12C0" ------_=_NextPart_002_01C7ADDD.725C12C0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Just to be clear, I was never suggesting that the list of PSAP URIs be global. I really don't care if a VSP in Sierra Leone bills for 9-1-1 calls it has to process that go to US PSAPs. There is absolutely nothing that says the Sierra Leone VSP can't bill for that, unless Sierra Leone signs a treaty with the US and requires its VSPs to not bill. There's also nothing that requires the Sierra Leone VSP to route unauthenticated calls that claim to be "sos" and that want to be routed to a US PSAP (but the VSP doesn't know it's a PSAP). The only PSAP URIs that the Sierra Leone VSP is probably required to know about, are the ones in Sierra Leone. =20 The only rules (billing, handling of unauthenticated calls) that exist are for VSPs within the same regulatory region as the PSAP.=20 Barbara ________________________________ From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Tuesday, June 12, 2007 8:28 PM To: 'Dawson, Martin'; ecrit@ietf.org Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives I'm sorry but the forest guide idea is a whole lot more developed that any notion of an authoritative list of PSAP URIs. I'm not saying it can't be done, I'm saying we need a whole lot more work on it to make it real, and it's not at all clear to me that the reverse lookup idea has more or less merit. However, both of them are beyond what I think is appropriate for LoST at this point. =20 Brian =20 ________________________________ From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20 Sent: Tuesday, June 12, 2007 5:19 PM To: Brian Rosen; ecrit@ietf.org Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives =20 Well hand waving was about all I could invest in an email, but are you saying you'd just have to give up at that stage? What is a reference to a "forest guide", if it's not a particularly low-detail suggestion of the sort of thing we need to resolve the right LoST server? Yet, without that, option 1 doesn't work. Why wouldn't this "validation" be a function of that system and why is reverse lookup the only option? =20 Cheers, Martin =20 ________________________________ From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, 13 June 2007 12:18 AM To: Dawson, Martin; ecrit@ietf.org Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives =20 I think those of us pushing for Option 1 for now is that we think VSP validation is a fact of life we have to deal with, waving hands over "reference to a relatively static table maintained by global cooperation" is not adequate, and something like a reverse lookup is required. This would be a change to LoST and we are reluctant to take this change on at this time. =20 Brian =20 ________________________________ From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20 Sent: Tuesday, June 12, 2007 10:08 AM To: ecrit@ietf.org Subject: [Ecrit] Proposals 1 and 3 - summary of perspectives =20 For some reason this hasn't made it through moderation. Now I'm a list subscriber, I'll try again... =20 It's a long weekend in Australia and winter has finally hit - with cold wind and rain. What better time, then, to spend some time catching up with the action on the ECRIT list. I only went back a couple of weeks; obviously the main topic has been to do with the question of how to define the "location hiding" capability. Mostly it's a debate about the utility of option 1 and 3. =20 Having just read through all the postings and while they are fresh in my mind, here is how I characterize the perspectives. First my summary of the options... =20 * Option 1 achieves location hiding, somewhat oxymoronically, by providing location. Whether it's by reference to the local LoST facility or by some internal knowledge, the LIS generates a coarse location which it knows will result in a correct PSAP URI resolution if/when another party makes a request to the LoST facility. This is provided in addition to a location reference for subsequent accurate location requests from the PSAP for dispatch etc.=20 * Option 3 achieves location hiding by making the request to the local LoST facility using the end points location and providing the PSAP URI that the LoST service returns (in addition to a location reference) so the call can be routed to that PSAP - whether directly from the device or via a proxy/VSP.=20 =20 Both suggestions are based on an assumption that a LIS, being associated with the local jurisdiction, has enough local knowledge to identify the correct LoST service for that jurisdiction or, at least in the case of option 1, to determine what "coarse location" isn't too coarse. =20 Perspective 1 - articulated by a lot of people, Ted, Brian, Andy,... etc. is that LoST needs to progress and get to a first release and changes associated with this particular use case should be avoided for now. I haven't seen anything in either proposal that does require a change to LoST. In the one case either or both of the LIS and VSP/proxy make LoST queries but neither options appears to *dictate* a specific change to LoST. =20 Perspective 2 - articulated by, for example, James W and Barbara is that the LIS operator should have the option of providing location or not - a "coarse location" is still a location and location information to the granularity of PSAP boundaries, for example, could still support a lot of value-added services and be used for other than emergency services. =20 Perspective 3 - articulated by, for example, Andy and Laura is that, when the end-point initiates a call through the VSP/proxy with a pre-determined PSAP URI, the proxy may not know that this really is a genuine emergency call destination. In fact it could be used to call anyone by just pretending it's an emergency call. This means the VSP may lose call revenue through the fraudulent nomination of emergency calls. =20 Perspective 4 - articulated by, in particular, Hannes (sorry Hannes, I can't see anyone else emphasising this point) is that all emergency calls should go through a VSP so that there's an authenticated subscriber identity to be associated with the call. This seems like an orthogonal point to me. If we accept that some calls will go through VSPs and therefore Perspective 3 is valid then the question of whether all emergency calls have to go through a VSP is moot. I have to admit to being really surprised by the perspective - it wasn't one that I thought had any currency in this forum. =20 =20 There were miscellaneous other perspectives including some good suggestions for alternatives/compromises from Richard and Henning. =20 Martin D's perspective - =20 * On perspective 1, I don't see any impediment to pushing LoST out. Even if there are changes to come, they can be done in a revision or whatever. But I haven't seen any definitive statement about how either option *requires* a change to LoST.=20 * On perspective 4, I don't think it's decisive in the discussion. * So, really, it boils down to an evaluation of which of perspectives 2 and 3 are the most valid - i.e. are the interests of the LIS operator or a VSP to have priority.=20 =20 I don't understand why the interests of LIS operators and VSPs can't both be served. I'm surprised that with all the experience and knowledge in the forum that nobody can provide a practical way for a proxy/VSP to determine whether a PSAP URI is a valid emergency destination or not. I know that adding the reverse-lookup to LoST has been discussed. That would be effective, but it's not in keeping with perspective 1. Surely, though, there are alternatives. =20 I think option 3 supports a faster and smoother deployment of global emergency calling for VoIP. Here's my rationale. =20 1. Both options require a LoST and LIS capability to exist at a local and jurisdictional level - so their availability is a premise in either proposal=20 2. Option 1 assumes that each VSP can make an effective LoST query even if it is a "non-local" VSP to the point from where the call is being originated. This is either by the VSP automatically knowing which LoST server is applicable to the coarse location or by the use of the so called forest guide and perhaps some international hierarchy of interconnected LoST servers.=20 3. Option 3 only assumes that this local knowledge is in the local LIS function and doesn't rely on the existence of the infrastructure described in point 2.=20 4. The ability to verify a destination PSAP URI as a valid emergency URI could be supported by reference to a relatively static table maintained by global cooperation. In fact, I would have thought that filtering based on domain name would be extremely reliable and fast. It would certainly obviate the ability to make arbitrary calls by pretending they are emergency calls.=20 5. Perhaps a later revision of LoST can include the reverse-lookup mechanism and, perhaps by then, the international infrastructure of LoST servers, forest guides, etc. may be in place.=20 =20 I mention point 4 as one possible way to protect the interest of the VSPs without requiring a change to the current LoST definition. Are there any other proposals on how to achieve this or, alternatively, a view that it simply isn't possible? =20 Cheers, Martin =20 Martin Dawson Andrew Network Solutions Asia-Pacific Email: martin.dawson@andrew.com Phone: +61 2 42212992 Fax: +61 2 42212901 Mobile: +61 412 120300 This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. =20 =20 ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ------------------------ [mf2] =20 =20 ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------ ------------------------ [mf2] =20 ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA623 ------_=_NextPart_002_01C7ADDD.725C12C0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Just to be clear, I was never suggesting = that the list=20 of PSAP URIs be global. I really don't care if a VSP in Sierra Leone = bills for=20 9-1-1 calls it has to process that go to US PSAPs. There is absolutely = nothing=20 that says the Sierra Leone VSP can't bill for that, unless Sierra Leone = signs a=20 treaty with the US and requires its VSPs to not bill. There's also = nothing that=20 requires the Sierra Leone VSP to route unauthenticated calls that claim = to be=20 "sos" and that want to be routed to a US PSAP (but the VSP doesn't know = it's a=20 PSAP). The only PSAP URIs that the Sierra Leone VSP is probably required = to know=20 about, are the ones in Sierra Leone.
 
The only rules (billing, handling of = unauthenticated calls)=20 that exist are for VSPs within the same regulatory region as the PSAP.=20
Barbara

From: Brian Rosen = [mailto:br@brianrosen.net]=20
Sent: Tuesday, June 12, 2007 8:28 PM
To: 'Dawson, = Martin';=20 ecrit@ietf.org
Subject: RE: [Ecrit] Proposals 1 and 3 - = summary of=20 perspectives

I’m = sorry but the=20 forest guide idea is a whole lot more developed that any notion of an=20 authoritative list of PSAP URIs.  I’m not saying it = can’t be done, I’m=20 saying we need a whole lot more work on it to make it real, and = it’s not at all=20 clear to me that the reverse lookup idea has more or less merit.  = However,=20 both of them are beyond what I think is appropriate for LoST at this=20 point.

 

Brian

 

From: Dawson,=20 Martin [mailto:Martin.Dawson@andrew.com]
Sent: Tuesday, June 12, 2007 5:19 = PM
To: Brian Rosen;=20 ecrit@ietf.org
Subject: RE:=20 [Ecrit] Proposals 1 and 3 - summary of=20 perspectives

 

Well hand = waving was=20 about all I could invest in an email, but are you saying you’d = just have to give=20 up at that stage? What is a reference to a “forest guide”, = if it’s not a=20 particularly low-detail suggestion of the sort of thing we need to = resolve the=20 right LoST server? Yet, without that, option 1 doesn’t work. Why = wouldn’t this=20 “validation” be a function of that system and why is reverse = lookup the only=20 option?

 

Cheers,

Martin

 

From: Brian=20 Rosen [mailto:br@brianrosen.net]
Sent: Wednesday, 13 June 2007 = 12:18=20 AM
To: Dawson, = Martin;=20 ecrit@ietf.org
Subject: RE: [Ecrit] Proposals 1 = and 3 -=20 summary of perspectives

 

I think those = of us=20 pushing for Option 1 for now is that we think VSP validation is a fact = of life=20 we have to deal with, waving hands over “reference to=20 a relatively static table maintained by global = cooperation” is = not adequate, and=20 something like a reverse lookup is required.  This would be a = change to=20 LoST and we are reluctant to take this change on at this=20 time.

 

Brian

 

From: Dawson,=20 Martin [mailto:Martin.Dawson@andrew.com]
Sent: Tuesday, June 12, 2007 = 10:08=20 AM
To: = ecrit@ietf.org
Subject: [Ecrit] Proposals 1 and = 3 -=20 summary of perspectives

 

For some reason this = hasn’t made it=20 through moderation. Now I’m a list subscriber, I’ll try=20 again…

 

It’s a long weekend = in Australia and winter has = finally hit=20 – with cold wind and rain. What better time, then, to spend some = time catching=20 up with the action on the ECRIT list. I only went back a couple of = weeks;=20 obviously the main topic has been to do with the question of how to = define the=20 “location hiding” capability. Mostly it’s a debate = about the utility of option 1=20 and 3.

 

Having just read through = all the=20 postings and while they are fresh in my mind, here is how I characterize = the=20 perspectives. First my summary of the = options…

 

  • Option 1=20 achieves location hiding, somewhat oxymoronically, by providing = location.=20 Whether it’s by reference to the local LoST facility or by some = internal=20 knowledge, the LIS generates a coarse location which it knows will = result in a=20 correct PSAP URI resolution if/when another party makes a request to = the LoST=20 facility. This is provided in addition to a location reference for = subsequent=20 accurate location requests from the PSAP for dispatch=20 etc.=20
  • Option 3=20 achieves location hiding by making the request to the local LoST = facility=20 using the end points location and providing the PSAP URI that the LoST = service=20 returns (in addition to a location reference) so the call can be = routed to=20 that PSAP – whether directly from the device or via a=20 proxy/VSP.

 

Both suggestions are based = on an=20 assumption that a LIS, being associated with the local jurisdiction, has = enough=20 local knowledge to identify the correct LoST service for that = jurisdiction or,=20 at least in the case of option 1, to determine what “coarse = location” isn’t too=20 coarse.

 

Perspective 1 – = articulated by a lot=20 of people, Ted, Brian, Andy,… etc. is that LoST needs to progress = and get to a=20 first release and changes associated with this particular use case = should be=20 avoided for now. I haven’t seen anything in either proposal that = does require a=20 change to LoST. In the one case either or both of the LIS and VSP/proxy = make=20 LoST queries but neither options appears to *dictate* a specific change to=20 LoST.

 

Perspective 2 – = articulated by, for=20 example, James W and Barbara is that the LIS operator should have the = option of=20 providing location or not – a “coarse location” is = still a location and location=20 information to the granularity of PSAP boundaries, for example, could = still=20 support a lot of value-added services and be used for other than = emergency=20 services.

 

Perspective 3 – = articulated by, for=20 example, Andy and Laura is that, when the end-point initiates a call = through the=20 VSP/proxy with a pre-determined PSAP URI, the proxy may not know that = this=20 really is a genuine emergency call destination. In fact it could be used = to call=20 anyone by just pretending it’s an emergency call. This means the = VSP may lose=20 call revenue through the fraudulent nomination of emergency=20 calls.

 

Perspective 4 – = articulated by, in=20 particular, Hannes (sorry Hannes, I can’t see anyone else = emphasising this=20 point) is that all emergency calls should go through a VSP so that = there’s an=20 authenticated subscriber identity to be associated with the call. This = seems=20 like an orthogonal point to me. If we accept that some calls will go = through=20 VSPs and therefore Perspective 3 is valid then the question of whether = all=20 emergency calls have to go through a VSP is moot. I have to admit to = being=20 really surprised by the perspective – it wasn’t one that I = thought had any=20 currency in this forum.

 

 

There were miscellaneous = other=20 perspectives including some good suggestions for = alternatives/compromises from=20 Richard and Henning.

 

Martin D’s = perspective=20 –

 

  • On=20 perspective 1, I don’t see any impediment to pushing LoST out. = Even if there=20 are changes to come, they can be done in a revision or whatever. But I = haven’t=20 seen any definitive statement about how either option *requires* a change to=20 LoST.=20
  • On=20 perspective 4, I don’t think it’s decisive in the=20 discussion.=20
  • So,=20 really, it boils down to an evaluation of which of perspectives 2 and = 3 are=20 the most valid – i.e. are the interests of the LIS operator or a = VSP to have=20 priority.

 

I don’t understand = why the interests=20 of LIS operators and VSPs can’t both be served. I’m = surprised that with all the=20 experience and knowledge in the forum that nobody can provide a = practical way=20 for a proxy/VSP to determine whether a PSAP URI is a valid emergency = destination=20 or not. I know that adding the reverse-lookup to LoST has been = discussed. That=20 would be effective, but it’s not in keeping with perspective 1. = Surely, though,=20 there are alternatives.

 

I think option 3 supports = a faster=20 and smoother deployment of global emergency calling for VoIP. = Here’s my=20 rationale.

 

  1. Both=20 options require a LoST and LIS capability to exist at a local and=20 jurisdictional level – so their availability is a premise in = either=20 proposal=20
  2. Option 1=20 assumes that each VSP can make an effective LoST query even if it is a = “non-local” VSP to the point from where the call is being = originated. This is=20 either by the VSP automatically knowing which LoST server is = applicable to the=20 coarse location or by the use of the so called forest guide and = perhaps some=20 international hierarchy of interconnected LoST=20 servers.=20
  3. Option 3=20 only assumes that this local knowledge is in the local LIS function = and=20 doesn’t rely on the existence of the infrastructure described in = point=20 2.=20
  4. The=20 ability to verify a destination PSAP URI as a valid emergency URI = could be=20 supported by reference to a relatively static table maintained by = global=20 cooperation. In fact, I would have thought that filtering based on = domain name=20 would be extremely reliable and fast. It would certainly obviate the = ability=20 to make arbitrary calls by pretending they are emergency=20 calls.=20
  5. Perhaps a=20 later revision of LoST can include the reverse-lookup mechanism and, = perhaps=20 by then, the international infrastructure of LoST servers, forest = guides, etc.=20 may be in place.

 

I mention point 4 as one = possible=20 way to protect the interest of the VSPs without requiring a change to = the=20 current LoST definition. Are there any other proposals on how to achieve = this=20 or, alternatively, a view that it simply isn’t=20 possible?

 

Cheers,

Martin

 

Martin=20 Dawson

Andrew Network Solutions=20 Asia-Pacific

Email: martin.dawson@andrew.com

Phone: +61 2=20 42212992

Fax: +61 2=20 42212901

Mobile: +61 412=20 120300


This message = is for the=20 designated recipient only and may contain privileged, proprietary, or = otherwise=20 private information. If you have received it in error, please notify the = sender=20 immediately and delete the original. Any unauthorized use of this email = is=20 prohibited.

 

 


--------------------------------------------------------------= ----------------------------------
This message is for&= nbsp;the designated recipient only and may
co= ntain privileged, proprietary, or otherwise priv= ate information.  
If you have received&= nbsp;it in error, please notify the sender<= BR>immediately and delete the original.  An= y unauthorized use of
this email is proh= ibited.
--------------------------------------------------------------= ----------------------------------
[mf2]

<= /TD>

 

 


--------------------------------------------------------------= ----------------------------------
This message is for&= nbsp;the designated recipient only and may
co= ntain privileged, proprietary, or otherwise priv= ate information.  
If you have received&= nbsp;it in error, please notify the sender<= BR>immediately and delete the original.  An= y unauthorized use of
this email is proh= ibited.
--------------------------------------------------------------= ----------------------------------
[mf2]

<= /TD>

 

*****

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

 ------_=_NextPart_002_01C7ADDD.725C12C0-- ------_=_NextPart_001_01C7ADDD.725C12C0 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: <788275116@13062007-0753> Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABfAPYDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD1v7DZ /wDPpB/37X/Cj7FZ/wDPpB/36X/Cmahc3FrZvLa2jXcwwFiVgMk+57VxHiiLxQ+m+fe3SQrJIscd lZ5JYn1PU0m7HVhsP7eSTklfudlM2j28PnTfYo4/7zBAKxf+Es8KG5aEGAqqljKYAE47Djk1xEOg wW+oWFn4i1JbCS8IFvbEF5GycduF59a3LGPwN4fuL5r7UUuLnT3AnEqMREScABQOeeM81Cc3sjsq UMBRupVHJ+R1OlX1hrEjm30krbqPluJYFVZD6AHmtT7DZ/8APpB/36X/AArGXxx4ZGsDRzqkcd7u EYiZGUbjjAzjGeRTbfx94audXbSk1Efa1kaLa0bAF16gMRjPFaJM8ucot+6rI2/sVn/z6Qf9+1/w o+xWf/PpB/37X/Cudh+I/he4t5biO+kaGJlV3+zuACx2gZx61YHjvw41ylul/wCZK90bRUSJiWlG MgcdOevSnZkXRtfYrP8A59IP+/a/4UfYrP8A59IP+/a/4VNS0hkH2Kz/AOfSD/v2v+FH2Kz/AOfS D/v2v+FT0UAQfYrP/n0g/wC/a/4UfYrP/n0g/wC/a/4VPRQBB9is/wDn0g/79r/hR9is/wDn0g/7 9r/hU9FAEH2Kz/59IP8Av2v+FH2Kz/59IP8Av2v+FT0UAV2tLFFLNbW6qOpMagD9Kgtzo92zLbfY ZivURhGI/Ks+/t11nxGNOuvmsrS3Wd4c8TOxIG71AA6etRauPDFpcRrcslhc25V0lgjKMg9NyjGD 0IrRQ+8ydRrXobv2Kz/59IP+/S/4UfYbP/n0g/79L/hWZe+IfJvfsdjafbJVjWSQmZYlVW6DLdSf SlHiW3msLW4tIJbia7dkit1wG3L94E9ABjk0uSRXtI9zS+xWf/PpB/37X/Cj7FZ/8+kH/ftf8Ko2 utNJJcW95ZPaXcEXnGIuGDp6qw688e1Z8Hi24nSzcaHcD+0FzafvV+c4yd390Yyc+goUJMTqxRvf YrP/AJ9IP+/a/wCFH2Gz/wCfSD/v0v8AhWYPEsSaTLez20kc0M/2Z7YMC3m5ACg9Ocjn0qOLxDJO bi0lsjb3q27TRRrOriQD0YdCDjrQoSD2sDX+w2f/AD6Qf9+l/wAKPsVn/wA+kH/ftf8ACue07xBe QaBpTT2EtxdXh8uMeauXO3O4nsDitESRv4gsjPbSR3r2bsMS5RBkZUgcE5PWhwa3BVItaGh9hs/+ fSD/AL9L/hSfY7IEA2tvk9B5a8/pWWnieN50svscv9omfymtNwyi9fMJ6bMc5/Csu6iZ9Q33MwTa 3+kAt8+dxxsHUjbtxj1701B9ROqump1P2Kz/AOfSD/v0v+FFFl532GD7RnzfLG/Priis27GqZJ5k f/PRP++hRviyMunHT5hxXjl1fzx6jOgcgBzgVuaPdF4fnwx98Vs6TSuZe01DW/AOta14pk12TVrB WS6ia3iOTsiQ5A3dj7AYOaoXfwmvb7VpNSn1S082fUWnnUO21oSwIXp97r7Ve1SXywjA4GD0+tYE l5LNcYEjAZ7GlGLZHtE3axtf8K21W61y4nvtV09bGbUPtxSMEykjOxdx6D1qDS/hhqljfte3Gp2F y7JOyq0jbYp3BCyLxzjvmtDQmJlO87vl7jNdN+5AzsT/AL5FDTWlzSPKzi7P4Zanb+DtR0R9Q04T 3DxPDKsjkAqxJ3Z6dewqbw98MJ9B8QDVI9Ss5fIhH2dXJbExUBnI9PvY/CuneeIMAI4z/wABFIZY /tZGyPHptFK0g0udKkq7F3yx7sDOGGM0vmx/89E/76FYUqxbf9Wn/fIrA1S3LD5OMv2wO1EYczKb sd75kf8Az0T/AL6FJ5kf/PRP++hXAG0f7B3z61NpCG3glmlXzAilsNjsKp0rK9xc53Pmx/8APRP+ +hR5sf8Az0T/AL6Fchaa7p04G6EJ7hAwqxqGr2Fnpz3MKQysOFTaBk1Eo8quwU7uyOn82L/nqn/f Qo82L/nqn/fQrkvC2qTauZo72zgRk5R1jADCukW3g/54Rf8AfAqVZq6KbsWfNi/56p/30KPNi/56 p/30KUWtvj/URf8AfAo+y2//ADwj/wC+BSGZWp2Lz3cWo6deQ297CpTMhykqE52sOvXkEdKqXFpq 2sxi11KewtLMkecttIXeYA525IG0H866D7Lb/wDPCP8A74FH2W3/AOeEf/fAqlNoh00zm9T0Vm1a S/tINMu1njVHivDjYV4DKQDxjqPapP7IuLe1sZbS5shfWZclQoSGQP8AeXA6dufaug+y2/8Azwj/ AO+BR9lt/wDnhH/3wKftGT7KJiQWV3c3U9/qM1ok72zW8MUMhKxg8klj1JOO3amW+lSwx+H1a4ty dLQrNh/vfutny/j61vfZbf8A54R/98Cj7Lb/APPCP/vgUudj9nE5y40A3NjfxNc23mTagbyDd8yd FwHH4EH607TdMliuJbieDSrPMLRpHaAEkn+IsQCB7Cuh+y2//PCP/vgUfZbf/nhH/wB8Cn7SVrC9 lG9zCttKkhtdDia4gzpxzLh+G+Ujj8TVye2L67BqCSwlIraSLaXwSxII/DitH7Lb/wDPCP8A74FH 2W3/AOeEf/fApczK5FaxzS6JeJcLrAv4G1gyfvMufJaL/nl64A5BxnNdFugLBmaIsOhJBI/Gn/Zb f/nhH/3wKPstv/zwj/74FDk3uEYKOwnmxf8APVP++hRS/Zbf/nhH/wB8CiosWeLX0WdWn/3zWpp8 UygbYnx6hDVp5FMZu/8AUGQ4CQINzE9gepP40+b/AEWB7h5ppAmCAHyTnpXdzp6HM49SDWI2FnGW BBweox3rmbZ8XB+td3p1ymr2YEjvGASu1mDfzqLV/Cuk2tqb3zGhf+9kBCT0yPr6VN7CjEp6RJtL t6JWq9/8nXtWNaq1nKIpo8hk5eM5VvUr7VvjR7WW1WWN5iWxxxxRJX1Ki+hnrclmzmpZrjZeZz3q oIZEnZfs7hQepPXn19alnALb8kE84pS91alJOWxtCfzEXnrUjWfnRrx3rlW8SS2pKiCJsdNxNTwe O7tYyDY2/HfLf40lGT+EptLc6s2A+zbMVUktfs2nXJx/yzb+Vc6vxCv2k2fYLYZ92/xqzN4pu7u0 nhe0gAaJskE/3TT5Kii20F4t6FGw8J6b9oV8yxfvAxMUpGc/w+5qHXRZ2+py6ZZah9oaIjzonbcY ie2R+VUW8af8I7pPm7g92yYgiABBPck8dKxvhmLi+8SXl5OpcSgvJM3RWJznNZVpqUUkTSpNT1PU /DivDbx2uwKduV4wVI7GrttqjSXL275jnUnMUq4bHqPUe9ePa18Q9UmN3bWEiwRFmjWdf9YyA4zn tnrxWv4I8UXd/d6ZDevNdTws6CZjuJRgOCe+MVpCHQK1VN+6e0joKWkHQUtcxsFZ2p6xFpbRLNBd SecwVTDCXG49Bx0NaNVb2xS+EG92XyJ1mGO5XtQBBZ65p95DPItykZtnZJlkcBo9rFfmGeOnerE9 /bQ2YuzKGibGwx/NvJ6BcdSe2KzLvwva3cTRyTPgmQjKgjLzLLyO4DKBj0qwuhwppMOno5QQEPHI qgbXB3BgOnXtQBPFq1o0Uckzm1MknlrHcjy2LegB6/hSjV9MaYwDULUyiTyygmXdv/u4z146VRuv D8l9EgutRlkk2vHI4jUb42KkqBj5furz16+tEnhq3dWBnkG5ZAcAfxzeae3rx9KALUmt2AZFhuY5 y04gYQuG2Mc/e546GkbXdMS4toDfQF7pmSLbICGZcZGfXkVm2XhTaga8vGkkWQlRGoVVTe7Bff75 5pLfwbZ2tottHMygFgxRFXcjJsKn324560AbMmp2aadPqCzrNbwIzu0J38KMnGOp46VUt/EulXLS 7LtVWGKOWR5PlRQ+do3HjPHI6jio7Tw5b2WiXWmRyYW6Vld0jVSMrtyAO+AOtE3hu2MxmtJTaygq 6lFBCuGdi2D1z5jcfT0oAnXXLFrq7tRcJ51qgcoZFBZdobcMnpg9TxUtvq1nOdpmWJzM8KpIwDOy HBwM89Ky/wDhEIAjQC8m+zGPYse1cq3kmHduxk/KTx0zT5PCdm+oQ3jSFnjkaTDIrdZDIAM9MMet AG/RSDpRQB5mYPLVp3bMdsAqIgyyuRyx7cf1pIY7WSAAQyM7MA7NJyQOAOBjFRxRy3UZWCDELZEY DYI5yc+uf6CqxubmCfy9qRgHADOqn8ic10wptq63OOrVjDcyPFNzBp+tRxQ3ctlIIVYBl3RHOepX kfkapr4mvVYWOtkz206/IdwKEeqEcVe8R6WdRvkurgFGMQUA9wPSqll4We5srhFPmWoG503fMh/v p7j9RwafLUjqVGcJLQ0NFW5s9Rh0+e7MmmP+8t2CZbP1HIIB+hr0O3nit7aKJnViwGM8ZHrXCaJ9 r0XSt+pKoisZNn2huhVuhHfB4/OrM3inSZypk1CJDEcqSSAVPUfh1/Omo3Wg767HcCO1kI2lCa52 +mgMpiUksOOBxWXD4u0SzugW1eAMOMEnj8xWU/ibSzqZnOs24j3FlK559jxXNzSbdzoStsP1Oxn8 wkYGfXiobexeKHdPNGilupbqfb1qxP4p0S6kAbUoAT/EoO0/pxVU+b4gMj6Oz3KW7bXAIIQnpj2N dFOo7GVRPsW4NPSe4DLcwHnpuxW1YWTWt2kbiGWU5xCzcOcHAPsaoWGiauY0ZrOTjqcVNptpNb+I o5pVIERBIzk9DW0qnu2uZxiyp490ee8h0ltTmt4ovtaxGK2jCpCrjH3jyeQKxfFmvadoek/8Iv4f ZMv/AMfs0bZ4/uZ7k9/yrf8AE2oy3Tzo8QZUXlMZCj/GuCuNBtLqQGzdomc524yprCdL3rrcVOva LTLHg3TIr65nvbgL5NmoYoRnzCeMVt/Dqe207xNPZ3KglJDsH48EVf8AC2kWGm2k1tJc+ZNu2zKw wOVyMVc0/wAMWA1l55lLTXCFYpQxAVsfKR75FbyShBP7zGN5z5F8j1lTkA+1OqtFcxLJHZtJ/pHk +ZtxyVGAT+ZqwTivPPRMG68Q/YrvVYZJIpJbfY1vblgrMpQEnHUgHJJ9Aahi8TzO9urx2yq+7dJv YrNhtv7rAO49/p+db8lzBHIEZh5m3eEAyxXIGcDnqRUnHp09qAOLbxdf3Q8yOO3ihieRJcvzIPL3 oARna/UYPOe1XH8U3aGeOO1iZo1GxWcllOUAL8fdbfkeu011GRnGP0pGdUVnbgKMk47UAZD6ldS6 BcXAeG1uIZHiZ2PyAq+0kEjgHBwSCBnJyBWdH4nnit7XH+lCRmy8u1WkwwXahT5Xb5s5HBAPvXTw zxXNvHPE2+OVA6NjqCMg07gduntQByUXiS7gtFtfkkvJTthaVuZMtJyFA5C7F6etMh8VXkdiJpI7 eWbau+TzCIyfL3FV44Yn5QPXNdjx1xUUdzBLPLAjBpICPMXH3SRkfpQBk6frd1d6o1tNbJHC7SiJ lJ3Dyyud2Rjnd29KzU1zUbDzZLlYpmlupwgLsAVjk2CNBj75HIHfBNdbkUcHGRQBmWOpXM9ndXlz CkcMTyiNYtzuyozKSRjqduQBXPp4kv8AUVhkXEBSQxuIXDo/7225BGf4ZGHX1rsUkWRdyhgOeqkd D70oIA4GPwoAWiiigDza3kl0vwpLfXSBbhAwAXquTx+PNcXaade3iPPHaSzAklmVc810niLURdeE 7OcMQbnarr6Fc5zVTRtUSys0WVGZYmLIFA5zzyeo5HWvXoqUabkkfPYlxlUUW9COGQLDDazE+Q4w QeqH+8PTH8q0dDheFZ0ByVBVxnv0rK1K3urowJEMPPiQkfwqT1PpxzV3wvZyTa+90kuY2nLbWBGV z3/Cs5zu9jvow5YoXXZs/D+6BXB3qgY9eGBH868ru4migaWSRnYdB717D4ytoW8IXaRYAZ0IQ9SQ wBNeZT2CvayRswGV6DrkNiphBygz0KeqN6T4R6hLpw1GXWrYmSIOFIO7JAOK4hraXTL+Wxu0BdOm On1FexyXmpLYO0NxGLWCBQgYhucAZAI4/WuIbwve+IfELTmZHESj7QzP0/uqOOWIrwsPiZ+0fO9D 0qmGSheO5ybN1xxXpXwjJOn6yoHLSRDPpw2K85mAjZlIwynBFemfBpW+y6xIo5WSLOT04NepX+Fs 5IL3j1OHTYBaCKUFgRzg4zXPP4Y/smW8vbOdVRgXRCpJQ4/XmtR/ElpBMIZg4bIGVBIzUmp3Ulto uoXJUN5ETsoPfArkg1JryCcJQTueZX0oZvsURJkwXkJPJPXmqOkWYaX7QVyFGfbNYsN9LEJbwkmW UlixPr1rZsNchaxX7PGyoUG4t13d/wAK9BVU53fQ8nk0HW87LdyyHC/6SM88noK6N75oYQNp3QNu BFctYW5u9JuryP5tkjkn3ABrtIbCO5jV2OPMUEH1yKdOfNCzFKNppo6zVdHm1SVLmOSIDyFQxyA7 Xw6vhsfwkDBqsnhu8iaMi6gd1txGs0iMzQkBuEGcbTuHX0HBro4hiJB6KKfXCekcbD4LnjjjJmt/ OXzEVjuYxIzKwCt16qfT7xq0PCskk8huZoZIXnV3QqT5wDlvnz1PIX6CuooxQBz8vh+eXQvsJ1CZ pfKSM/ORGwVgcY6jIG0nng9Khh8LPG8MgnTzoY4UVzuZlVWcuoJ5wQ4H0H4V01UdW1OPSrI3DRPM xO1Yo+XfucDvgAn6A0Ac9N4PuE0Y6daXMMSMkQ2AFV3qhUsMdCWw3HXFWG8LTZnkS8RZrgOJZADm QFUADHuBtP8A31VgeK7TMjtbzi3VNyTfL85ESy425yPlYde9TWGsSvp9/eX8It/ss7p5ZYZAAGAS OCTn9aAM+LwrcDU4bw3EcAjj2iO3Z1WH73CDPIO4eg4HFWtE0CbTLW+ikaANc7QPs5ZM4TbuJ6hj 1JFJD4rhnMOLG5RWO2UuAphJk8oAgnJ+b0HvUMviovBHKltJb7j5h8zaxaIxysGXBxnMR4P9aAIo vCVyjaYz3aYs2J2Rkoo+cMCMY3HAwScZzzVmHwssVpaxLNtkV2+1Ouf9IQnJU557L9AMCpj4jRIZ pPsszpGdiNlQZpBgFAuc559OaqQeLBPOXa1lhs/3bJNwWYNGzkMucjG0/lQA5/DV00hP2qMl1kUT EN5luWeRsx4PUhwD/ujr0qO18LXFvBYIs0Y+zXBmbczSKB8vCqwxk7Tzxt3Ejvmw3iuONNzWFxuU M8qbk/doqK5brz8rA4HNaFpq8V1fXNr5bRfZ8cykKXBOAQvXaTwD0PagDRHSigdKKAPG1YLbKjxJ JA+d0TD5Sev4H3qe3Gnx7QVkEfVomUHPtkEcVpLoUt1p2+2QtkbtrMAy/wBKoDSr1Yy0kK7hwfmF X7dxTVyVhYzcXYpazrLfMIYivnJtklbG4j0AHAHHSptDvpbaKWWNPMO35UHG4ngfz/Kq7+HdS1KQ RxwoqEDMjOPl5/OmiCQamfDNozh05vpyQCVAztXnpz+NdMZJU0zKpC1ZpbJl/XNQGqeH79gwaOEI uVHBO4cj8f0rmtK0a41XmFIkjQ/PJIeOV6YHXnmul1uwGmeDLmJVIQyJkkgljn/61Yvhu9ZBLAD8 uQw/lWsJShQbW5vTStoSapp17p+htFbyTXcUDCFnSAOS+AenXisfwJLqt7rLIb2Wzt1nE8o2YaY9 NuT2x2rpLnUCLWwCPJGRevI5jbaSobH58YrOkuAt+18GKysSAw6rk9vSvKnSjq1uzrjWk7X6HPax od5f65qMsMJ8wytKYiApCk8EV2PwfJcaujsqYaJSrcdAa5y7Fx9rYRSku6l0J6HHVW9a6D4VtGV1 aclm3yx4IGOxzXRF3hy2MJaO56K3yNtV4AMjg1dkAngeGRo5EcsrKwyCD1zWdJPaeapMByWAFaKN B5xAi5JqY6MiTbRjz+GdOazKxWWno/8ACTCv+FYOp6Vb2mmF4V01GUc4iXn9K7yQQiLHl9KxdTit J7dg1pG/GGDDt7e9bQepk4qx5/LqEtlbPBBJaRQmLeyRoAGJHPGK59/GWopuWPVJY1QYRcAgD0HF b2sR2AkkiiiG7ygu4DA6cVxFxoc26QxhSvbmuirGSiuVGcY3Wp9QWpLWkLE5JRT+lTVlW2t6clrC pueRGoPyN6fSpf7d03/n5/8AHG/wrzzoNCis/wDt3Tf+fn/xxv8ACj+3dN/5+f8Axxv8KANCq91Z W19AYLuCOeInOyRdwqv/AG7pv/Pz/wCON/hR/bum/wDPz/443+FAEw02yVQotYQo6Dyxj7u3/wBB AH04pINMsba0a0gtIY7ds7olQBTnrkVF/bum/wDPz/443+FH9u6b/wA/P/jjf4UAMi8PaVDdxXMV lEjwIViAUbUyxYkDsST1p1noOmWNqLaCzi8sHJ3KCWOCCSe5wSPxNL/bum/8/P8A443+FH9u6b/z 8/8Ajjf4UAPfR9NkaVnsbdmlUK5MY+YDoDSppOnRNE0dlAphUJHiMfKo6AfnUf8Abum/8/P/AI43 +FH9u6b/AM/P/jjf4UASR6Tp8UXlR2UCJhhtEYxhvvfn3pw02zUyEWsQMrB5DsHzEHIJ+hAqH+3d N/5+f/HG/wAKP7d03/n5/wDHG/woAv0VQ/t3Tf8An5/8cb/CigD/2Q== ------_=_NextPart_001_01C7ADDD.725C12C0-- --===============2121932582== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============2121932582==-- From ecrit-bounces@ietf.org Wed Jun 13 13:48:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyWxc-000133-MQ; Wed, 13 Jun 2007 13:48:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyWxa-00012l-Mt for ecrit@ietf.org; Wed, 13 Jun 2007 13:48:46 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyWxZ-0001lz-BU for ecrit@ietf.org; Wed, 13 Jun 2007 13:48:46 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l5DHmhqt004844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 13 Jun 2007 10:48:44 -0700 Received: from [76.102.225.135] (carbuncle.qualcomm.com [129.46.226.38]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l5DHmgsw010773 for ; Wed, 13 Jun 2007 10:48:43 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Wed, 13 Jun 2007 10:48:41 -0700 To: ecrit@ietf.org From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Ecrit] What is left for LoST before IETF Last Call? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Since several people have now said that neither of the things on the table for location hiding require changes to LoST, what are the issues that prevent us from issuing the current rev and asking for IETF last call? If nothing, can we do so? If it needs revision later, so be it. But I'd like to get it done. Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 13 17:23:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyaJ4-0005AE-Do; Wed, 13 Jun 2007 17:23:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyaJ3-0005A2-7C for ecrit@ietf.org; Wed, 13 Jun 2007 17:23:09 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyaIm-00034C-KX for ecrit@ietf.org; Wed, 13 Jun 2007 17:23:09 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l5DLMpE6005760; Wed, 13 Jun 2007 15:22:51 -0600 Message-ID: <4670601B.2020508@ntt-at.com> Date: Wed, 13 Jun 2007 14:22:35 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Ecrit] What is left for LoST before IETF Last Call? References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Ted; needs to be modified to return location profile type. As discussed a month ago, currently client can't match the location used in the request to the location used to resolve the mapping. SIP location conveyance needs this correlation to flag the location used for routing. Regards Shida Ted Hardie wrote: > Since several people have now said that neither of the things on > the table for location hiding require changes to LoST, what are > the issues that prevent us from issuing the current rev and asking > for IETF last call? If nothing, can we do so? > > If it needs revision later, so be it. But I'd like to get it done. > > Ted > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 13 20:00:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyclR-0004KQ-Iz; Wed, 13 Jun 2007 20:00:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyclO-0004KB-B5 for ecrit@ietf.org; Wed, 13 Jun 2007 20:00:34 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyclN-0004Nr-13 for ecrit@ietf.org; Wed, 13 Jun 2007 20:00:34 -0400 X-SEF-Processed: 5_0_0_910__2007_06_13_19_08_12 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 13 Jun 2007 19:08:12 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jun 2007 19:00:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Wed, 13 Jun 2007 19:00:30 -0500 Message-ID: In-Reply-To: <1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives Thread-Index: AcetyzTKW9rsGN1gSwyoIGrKHA7vHgASVRyQ References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com> <1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> From: "Winterbottom, James" To: "Henning Schulzrinne" , "Dawson, Martin" X-OriginalArrivalTime: 14 Jun 2007 00:00:32.0505 (UTC) FILETIME=[06CEDE90:01C7AE17] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning,=0D=0A=0D=0AI think that your proposal only works if the VSP is abl= e to provide a=0D=0ALoST server for all jurisdictions that it plans to prov= ide service for,=0D=0Aor it has to do it for everything (sounds awfully lik= e a global VPC to=0D=0Ame). Option 3 would be deployable from a local area = to a local PSAP=0D=0AREGARDLESS of the VSP having a LoST server that has bo= undary information=0D=0Afor the local area I am in. It provides a global so= lution from the=0D=0Aget-go.=0D=0A=0D=0ALet's take the good old Sierra-Leon= e example again.=0D=0A=0D=0AMy VSP is in Sierra-Leone and I am visiting Sam= oa. In option 3, I get a=0D=0APSA P URI for the local Samoan PSAP from the = local access LIS serving=0D=0Athe area I am in, I send my call to VSP, it s= ends it on the PSAP. I get=0D=0Abilled, call completes, we are done. I can = quibble with my VSP later=0D=0Aover the 10 cent call charge if I can be bot= hered.=0D=0A=0D=0AWith option 1, I send my call with location to my VSP, an= d one of three=0D=0Athings happens. Either it has a complete forest guide n= etwork set-up to=0D=0Abe able to talk to the Samoan LoST server nearest me,= my call fails, or=0D=0Athe VSP routes the call anyway because the end-poin= t has done the LoST=0D=0Alookup. I point out, that from the VSP perspective= the third alternative=0D=0Ahere is simply option 3 re-badged. I am sure th= at VSPs wouldn't drop the=0D=0Acall on the floor, so choice 2 isn't an opti= on, and choice 1 can ONLY=0D=0Aoccur if the whole network is up and running= , and it doesn't consist of=0D=0Aisolated copse of Forest Guides and LoST S= ervers.=0D=0A=0D=0ASo to my mind, option 3 is the ONLY deployable solution = in the short=0D=0Aterm that will actually work universally.=0D=0A=0D=0AChee= rs=0D=0AJames=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: He= nning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A> Sent: Thursday, 14 Ju= ne 2007 12:58 AM=0D=0A> To: Dawson, Martin=0D=0A> Cc: ecrit@ietf.org=0D=0A>= Subject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A> =0D= =0A>=20=0D=0A> On Jun 13, 2007, at 10:54 AM, Dawson, Martin wrote:=0D=0A> =0D= =0A> > Nobody has suggested changing LoST so this point is just a=0D=0A> > = distraction.=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> > Option 1 means that emerge= ncy calls will not be able to be routed=0D=0A> > until the forest guide net= work is implemented. Option 3 means that=0D=0A> > emergency calls will be a= ble to be routed regardless of the state=0D=0A> > of deployment of the fore= st guide.=0D=0A> >=0D=0A> >=0D=0A> This is not true, at least for comparabl= e installations. The ISP can=0D=0A> offer a LoST server that has the locall= y-relevant information. Same=0D=0A> for the VSP. This does not require a fo= rest guide as such.=0D=0A>=20=0D=0A> ______________________________________= _________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://ww= w1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A-----------------------------= -------------------------------------------------------------------=0D=0ATh= is message is for the designated recipient only and may=0D=0Acontain privil= eged, proprietary, or otherwise private information. =20=0D=0AIf you have r= eceived it in error, please notify the sender=0D=0Aimmediately and delete t= he original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A-= ---------------------------------------------------------------------------= --------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 13 20:21:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyd5x-0007Y2-Co; Wed, 13 Jun 2007 20:21:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyd5v-0007Xx-PE for ecrit@ietf.org; Wed, 13 Jun 2007 20:21:47 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyd5v-00006U-F8 for ecrit@ietf.org; Wed, 13 Jun 2007 20:21:47 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5E0LdrX029415 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 13 Jun 2007 20:21:44 -0400 (EDT) In-Reply-To: References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com> <1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Wed, 13 Jun 2007 20:21:34 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I assume that your discussion has nothing to do with location hiding at this point, but wanted to call this out just in case I'm missing your train of thought. I'm afraid I don't follow your logic. Unless you assume that every ISP deploys a LoST+HELD server, VSPs will have to have LoST servers with PSAP knowledge for the places their customers are likely to visit. This doesn't change whether HELD also gets converted into a LoST access protocol or not. So far, at least, VSPs seem a whole lot more interested in providing emergency call services than ISPs, presumably because their customers look to them for that service, not to the random hot spot operator. It's always been the model that both ISPs and VSPs (as well as third parties that are neither) can and should operate LoST servers, as that seems most likely to ensure that you get broad coverage. Henning On Jun 13, 2007, at 8:00 PM, Winterbottom, James wrote: > Henning, > > I think that your proposal only works if the VSP is able to provide a > LoST server for all jurisdictions that it plans to provide service > for, > or it has to do it for everything (sounds awfully like a global VPC to > me). Option 3 would be deployable from a local area to a local PSAP > REGARDLESS of the VSP having a LoST server that has boundary > information > for the local area I am in. It provides a global solution from the > get-go. > > Let's take the good old Sierra-Leone example again. > > My VSP is in Sierra-Leone and I am visiting Samoa. In option 3, I > get a > PSA P URI for the local Samoan PSAP from the local access LIS serving > the area I am in, I send my call to VSP, it sends it on the PSAP. I > get > billed, call completes, we are done. I can quibble with my VSP later > over the 10 cent call charge if I can be bothered. > > With option 1, I send my call with location to my VSP, and one of > three > things happens. Either it has a complete forest guide network set- > up to > be able to talk to the Samoan LoST server nearest me, my call > fails, or > the VSP routes the call anyway because the end-point has done the LoST > lookup. I point out, that from the VSP perspective the third > alternative > here is simply option 3 re-badged. I am sure that VSPs wouldn't > drop the > call on the floor, so choice 2 isn't an option, and choice 1 can ONLY > occur if the whole network is up and running, and it doesn't > consist of > isolated copse of Forest Guides and LoST Servers. > > So to my mind, option 3 is the ONLY deployable solution in the short > term that will actually work universally. > > Cheers > James > > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Thursday, 14 June 2007 12:58 AM >> To: Dawson, Martin >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives >> >> >> On Jun 13, 2007, at 10:54 AM, Dawson, Martin wrote: >> >>> Nobody has suggested changing LoST so this point is just a >>> distraction. >>> >>> >>> >>> Option 1 means that emergency calls will not be able to be routed >>> until the forest guide network is implemented. Option 3 means that >>> emergency calls will be able to be routed regardless of the state >>> of deployment of the forest guide. >>> >>> >> This is not true, at least for comparable installations. The ISP can >> offer a LoST server that has the locally-relevant information. Same >> for the VSP. This does not require a forest guide as such. >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2] > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 13 20:44:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HydRq-00045R-5d; Wed, 13 Jun 2007 20:44:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HydRo-000458-8q for ecrit@ietf.org; Wed, 13 Jun 2007 20:44:25 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HydRn-0004Tt-Sg for ecrit@ietf.org; Wed, 13 Jun 2007 20:44:24 -0400 X-SEF-Processed: 5_0_0_910__2007_06_13_19_52_03 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 13 Jun 2007 19:52:03 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jun 2007 19:44:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Wed, 13 Jun 2007 19:44:21 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives Thread-Index: AceuGf8bUq0im9j6SjqniOGajZDHTgAADXZQ References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com> <1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> From: "Winterbottom, James" To: "Henning Schulzrinne" X-OriginalArrivalTime: 14 Jun 2007 00:44:23.0567 (UTC) FILETIME=[270B11F0:01C7AE1D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org You are not too far off the mark, option 3 not only provides location=0D=0A= hiding but provides a mechanism for enabling this service regardless of=0D=0A= core infrastructure does.=0D=0A=0D=0AMuch of the debate over option 1 versu= s option 3 is purely one of=0D=0Abilling. Option 1 puts most, if not all th= e cost back on the location=0D=0Aprovider, option 3 puts the risk on the VS= P that they can't charge=0D=0Aper-call.=0D=0A=0D=0AThe first thing is that = I don't think that the LoST and HELD servers=0D=0Aneed to be run by the sam= e operator as you suggest below. The thing that=0D=0Adoes need to be in pla= ce is for the HELD server to have access to a LoST=0D=0Aserver, these two t= hings are not the same. That aside, I believe that if=0D=0Awe provided an e= xtension to HELD that supported option 3, that most=0D=0Alocation providers= would deploy it initially. This is because the onus=0D=0Ais on the access = providers to provide location and this is where the=0D=0Ainitial cost is al= l going to be incurred. The VSP has, to some extent a=0D=0Achoice as to whe= ther it incurs costs in any of this, the access provider=0D=0Adoes not.=0D=0A=0D= =0ACheers=0D=0AJames=20=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D= =0A> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A> Sent: Th= ursday, 14 June 2007 10:22 AM=0D=0A> To: Winterbottom, James=0D=0A> Cc: ECR= IT=0D=0A> Subject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D= =0A>=20=0D=0A> I assume that your discussion has nothing to do with locatio= n hiding=0D=0A> at this point, but wanted to call this out just in case I'm= missing=0D=0A> your train of thought.=0D=0A>=20=0D=0A> I'm afraid I don't = follow your logic. Unless you assume that every=0D=0A> ISP deploys a LoST+H= ELD server, VSPs will have to have LoST servers=0D=0A> with PSAP knowledge = for the places their customers are likely to=0D=0A> visit. This doesn't cha= nge whether HELD also gets converted into a=0D=0A> LoST access protocol or = not. So far, at least, VSPs seem a whole lot=0D=0A> more interested in prov= iding emergency call services than ISPs,=0D=0A> presumably because their cu= stomers look to them for that service, not=0D=0A> to the random hot spot op= erator.=0D=0A>=20=0D=0A> It's always been the model that both ISPs and VSPs= (as well as third=0D=0A> parties that are neither) can and should operate = LoST servers, as=0D=0A> that seems most likely to ensure that you get broad= coverage.=0D=0A>=20=0D=0A> Henning=0D=0A>=20=0D=0A> On Jun 13, 2007, at 8:= 00 PM, Winterbottom, James wrote:=0D=0A>=20=0D=0A> > Henning,=0D=0A> >=0D=0A= > > I think that your proposal only works if the VSP is able to provide=0D=0A= a=0D=0A> > LoST server for all jurisdictions that it plans to provide servi= ce=0D=0A> > for,=0D=0A> > or it has to do it for everything (sounds awfully= like a global VPC=0D=0Ato=0D=0A> > me). Option 3 would be deployable from = a local area to a local PSAP=0D=0A> > REGARDLESS of the VSP having a LoST s= erver that has boundary=0D=0A> > information=0D=0A> > for the local area I = am in. It provides a global solution from the=0D=0A> > get-go.=0D=0A> >=0D=0A= > > Let's take the good old Sierra-Leone example again.=0D=0A> >=0D=0A> > M= y VSP is in Sierra-Leone and I am visiting Samoa. In option 3, I=0D=0A> > g= et a=0D=0A> > PSA P URI for the local Samoan PSAP from the local access LIS=0D= =0Aserving=0D=0A> > the area I am in, I send my call to VSP, it sends it on= the PSAP. I=0D=0A> > get=0D=0A> > billed, call completes, we are done. I c= an quibble with my VSP later=0D=0A> > over the 10 cent call charge if I can= be bothered.=0D=0A> >=0D=0A> > With option 1, I send my call with location= to my VSP, and one of=0D=0A> > three=0D=0A> > things happens. Either it ha= s a complete forest guide network set-=0D=0A> > up to=0D=0A> > be able to t= alk to the Samoan LoST server nearest me, my call=0D=0A> > fails, or=0D=0A>= > the VSP routes the call anyway because the end-point has done the=0D=0AL= oST=0D=0A> > lookup. I point out, that from the VSP perspective the third=0D= =0A> > alternative=0D=0A> > here is simply option 3 re-badged. I am sure th= at VSPs wouldn't=0D=0A> > drop the=0D=0A> > call on the floor, so choice 2 = isn't an option, and choice 1 can=0D=0AONLY=0D=0A> > occur if the whole net= work is up and running, and it doesn't=0D=0A> > consist of=0D=0A> > isolate= d copse of Forest Guides and LoST Servers.=0D=0A> >=0D=0A> > So to my mind,= option 3 is the ONLY deployable solution in the short=0D=0A> > term that w= ill actually work universally.=0D=0A> >=0D=0A> > Cheers=0D=0A> > James=0D=0A= > >=0D=0A> >=0D=0A> >> -----Original Message-----=0D=0A> >> From: Henning S= chulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A> >> Sent: Thursday, 14 June 2= 007 12:58 AM=0D=0A> >> To: Dawson, Martin=0D=0A> >> Cc: ecrit@ietf.org=0D=0A= > >> Subject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A= > >>=0D=0A> >>=0D=0A> >> On Jun 13, 2007, at 10:54 AM, Dawson, Martin wrote= :=0D=0A> >>=0D=0A> >>> Nobody has suggested changing LoST so this point is = just a=0D=0A> >>> distraction.=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>=0D=0A> >>> = Option 1 means that emergency calls will not be able to be routed=0D=0A> >>= > until the forest guide network is implemented. Option 3 means that=0D=0A>= >>> emergency calls will be able to be routed regardless of the state=0D=0A= > >>> of deployment of the forest guide.=0D=0A> >>>=0D=0A> >>>=0D=0A> >> Th= is is not true, at least for comparable installations. The ISP=0D=0Acan=0D=0A= > >> offer a LoST server that has the locally-relevant information. Same=0D= =0A> >> for the VSP. This does not require a forest guide as such.=0D=0A> >= >=0D=0A> >> _______________________________________________=0D=0A> >> Ecrit= mailing list=0D=0A> >> Ecrit@ietf.org=0D=0A> >> https://www1.ietf.org/mail= man/listinfo/ecrit=0D=0A> >=0D=0A> >=0D=0A---------------------------------= -------------------------------------=0D=0A> > --------------------------=0D= =0A> > This message is for the designated recipient only and may=0D=0A> > c= ontain privileged, proprietary, or otherwise private information.=0D=0A> > = If you have received it in error, please notify the sender=0D=0A> > immedia= tely and delete the original. Any unauthorized use of=0D=0A> > this email = is prohibited.=0D=0A> >=0D=0A----------------------------------------------= ------------------------=0D=0A> > --------------------------=0D=0A> > [mf2]=0D= =0A> >=0D=0A>=20=0D=0A=0D=0A-----------------------------------------------= -------------------------------------------------=0D=0AThis message is for = the designated recipient only and may=0D=0Acontain privileged, proprietary,= or otherwise private information. =20=0D=0AIf you have received it in erro= r, please notify the sender=0D=0Aimmediately and delete the original. Any = unauthorized use of=0D=0Athis email is prohibited.=0D=0A-------------------= ---------------------------------------------------------------------------= --=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 13 21:14:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyduq-0005Qc-W4; Wed, 13 Jun 2007 21:14:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hydun-0005Kv-S4 for ecrit@ietf.org; Wed, 13 Jun 2007 21:14:23 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hydum-0002zI-F3 for ecrit@ietf.org; Wed, 13 Jun 2007 21:14:21 -0400 X-SEF-Processed: 5_0_0_910__2007_06_13_20_22_00 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 13 Jun 2007 20:22:00 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jun 2007 20:14:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Wed, 13 Jun 2007 20:14:18 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives Thread-Index: AceuGgIUdnorn1MfT9KY7XAHcoK3nAABWk3g References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com><1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> From: "Dawson, Martin" To: "Henning Schulzrinne" , "Winterbottom, James" X-OriginalArrivalTime: 14 Jun 2007 01:14:20.0105 (UTC) FILETIME=[55DD0390:01C7AE21] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org BTW - as I understand option 1, it requires the LIS to query the local=0D=0A= LoST server as well. At least that's how I recall Brian's original=0D=0Apro= posal being stated. It returns a "PSAP URI boundary" location instead=0D=0A= of the PSAP URI.=0D=0A=0D=0AI think folk are being inconsistent characteris= ing option 3 as adding=0D=0ALoST functionality to HELD. Both proposals requ= ire the LIS to interact=0D=0Awith LoST with the subsequent proxying of resu= lts to the device.=0D=0A=0D=0AIf the proposition of option 1 is that it's a= ctually the LIS that holds=0D=0Athe PSAP-relevant boundary information, the= n option 1 is actually much=0D=0Amore like adding LoST functionality to the= LIS (and adds inappropriate=0D=0Aresponsibility to the LIS provider).=0D=0A=0D= =0AFurther, given my understanding, both proposals rely on the LIS knowing=0D= =0Ainherently what the appropriate local LoST server is. Option 1 just=0D=0A= means that this is required *as well as* the VSP being able to reach=0D=0At= hat same local LoST service.=0D=0A=0D=0ANeither option requires the ISP to = implement LoST, they just require the=0D=0AISP to know which LoST server is= applicable to the local area of=0D=0Acoverage. That's much more practical = than expecting any arbitrary global=0D=0AVSP being able to work that out bu= t that is what option 3 requires *in=0D=0Aaddition*.=0D=0A=0D=0ACheers,=0D=0A= Martin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Henning Schulzrinne= [mailto:hgs@cs.columbia.edu]=20=0D=0ASent: Thursday, 14 June 2007 10:22 AM=0D= =0ATo: Winterbottom, James=0D=0ACc: ECRIT=0D=0ASubject: Re: [Ecrit] Proposa= ls 1 and 3 - summary of perspectives=0D=0A=0D=0AI assume that your discussi= on has nothing to do with location hiding =20=0D=0Aat this point, but wante= d to call this out just in case I'm missing =20=0D=0Ayour train of thought.=0D= =0A=0D=0AI'm afraid I don't follow your logic. Unless you assume that every= =20=0D=0AISP deploys a LoST+HELD server, VSPs will have to have LoST serve= rs =20=0D=0Awith PSAP knowledge for the places their customers are likely t= o =20=0D=0Avisit. This doesn't change whether HELD also gets converted into= a =20=0D=0ALoST access protocol or not. So far, at least, VSPs seem a whol= e lot =20=0D=0Amore interested in providing emergency call services than IS= Ps, =20=0D=0Apresumably because their customers look to them for that servi= ce, not =20=0D=0Ato the random hot spot operator.=0D=0A=0D=0AIt's always be= en the model that both ISPs and VSPs (as well as third =20=0D=0Aparties tha= t are neither) can and should operate LoST servers, as =20=0D=0Athat seems = most likely to ensure that you get broad coverage.=0D=0A=0D=0AHenning=0D=0A=0D= =0AOn Jun 13, 2007, at 8:00 PM, Winterbottom, James wrote:=0D=0A=0D=0A> Hen= ning,=0D=0A>=0D=0A> I think that your proposal only works if the VSP is abl= e to provide a=0D=0A> LoST server for all jurisdictions that it plans to pr= ovide service =20=0D=0A> for,=0D=0A> or it has to do it for everything (sou= nds awfully like a global VPC to=0D=0A> me). Option 3 would be deployable f= rom a local area to a local PSAP=0D=0A> REGARDLESS of the VSP having a LoST= server that has boundary =20=0D=0A> information=0D=0A> for the local area = I am in. It provides a global solution from the=0D=0A> get-go.=0D=0A>=0D=0A= > Let's take the good old Sierra-Leone example again.=0D=0A>=0D=0A> My VSP = is in Sierra-Leone and I am visiting Samoa. In option 3, I =20=0D=0A> get a=0D= =0A> PSA P URI for the local Samoan PSAP from the local access LIS serving=0D= =0A> the area I am in, I send my call to VSP, it sends it on the PSAP. I =0D= =0A> get=0D=0A> billed, call completes, we are done. I can quibble with my = VSP later=0D=0A> over the 10 cent call charge if I can be bothered.=0D=0A>=0D= =0A> With option 1, I send my call with location to my VSP, and one of =20=0D= =0A> three=0D=0A> things happens. Either it has a complete forest guide net= work set-=20=0D=0A> up to=0D=0A> be able to talk to the Samoan LoST server = nearest me, my call =20=0D=0A> fails, or=0D=0A> the VSP routes the call any= way because the end-point has done the LoST=0D=0A> lookup. I point out, tha= t from the VSP perspective the third =20=0D=0A> alternative=0D=0A> here is = simply option 3 re-badged. I am sure that VSPs wouldn't =20=0D=0A> drop the=0D= =0A> call on the floor, so choice 2 isn't an option, and choice 1 can ONLY=0D= =0A> occur if the whole network is up and running, and it doesn't =20=0D=0A= > consist of=0D=0A> isolated copse of Forest Guides and LoST Servers.=0D=0A= >=0D=0A> So to my mind, option 3 is the ONLY deployable solution in the sho= rt=0D=0A> term that will actually work universally.=0D=0A>=0D=0A> Cheers=0D= =0A> James=0D=0A>=0D=0A>=0D=0A>> -----Original Message-----=0D=0A>> From: H= enning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A>> Sent: Thursday, 14 = June 2007 12:58 AM=0D=0A>> To: Dawson, Martin=0D=0A>> Cc: ecrit@ietf.org=0D= =0A>> Subject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A= >>=0D=0A>>=0D=0A>> On Jun 13, 2007, at 10:54 AM, Dawson, Martin wrote:=0D=0A= >>=0D=0A>>> Nobody has suggested changing LoST so this point is just a=0D=0A= >>> distraction.=0D=0A>>>=0D=0A>>>=0D=0A>>>=0D=0A>>> Option 1 means that em= ergency calls will not be able to be routed=0D=0A>>> until the forest guide= network is implemented. Option 3 means that=0D=0A>>> emergency calls will = be able to be routed regardless of the state=0D=0A>>> of deployment of the = forest guide.=0D=0A>>>=0D=0A>>>=0D=0A>> This is not true, at least for comp= arable installations. The ISP can=0D=0A>> offer a LoST server that has the = locally-relevant information. Same=0D=0A>> for the VSP. This does not requi= re a forest guide as such.=0D=0A>>=0D=0A>> ________________________________= _______________=0D=0A>> Ecrit mailing list=0D=0A>> Ecrit@ietf.org=0D=0A>> h= ttps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A>=0D=0A> -----------------= -----------------------------------------------------=0D=0A=0D=0A> --------= ------------------=0D=0A> This message is for the designated recipient only= and may=0D=0A> contain privileged, proprietary, or otherwise private infor= mation.=0D=0A> If you have received it in error, please notify the sender=0D= =0A> immediately and delete the original. Any unauthorized use of=0D=0A> t= his email is prohibited.=0D=0A> -------------------------------------------= ---------------------------=0D=0A=0D=0A> --------------------------=0D=0A> = [mf2]=0D=0A>=0D=0A=0D=0A=0D=0A_____________________________________________= __=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www1.ietf.org/m= ailman/listinfo/ecrit=0D=0A=0D=0A------------------------------------------= ------------------------------------------------------=0D=0AThis message is= for the designated recipient only and may=0D=0Acontain privileged, proprie= tary, or otherwise private information. =20=0D=0AIf you have received it in= error, please notify the sender=0D=0Aimmediately and delete the original. = Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A--------------= ---------------------------------------------------------------------------= -------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 13 22:55:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyfV3-00034q-QH; Wed, 13 Jun 2007 22:55:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyfV3-00034l-F3 for ecrit@ietf.org; Wed, 13 Jun 2007 22:55:53 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyfV3-0003tg-1s for ecrit@ietf.org; Wed, 13 Jun 2007 22:55:53 -0400 X-SEF-Processed: 5_0_0_910__2007_06_13_22_03_32 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 13 Jun 2007 22:03:32 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 Jun 2007 21:55:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Wed, 13 Jun 2007 21:55:51 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives Thread-Index: AceuGgIUdnorn1MfT9KY7XAHcoK3nAABWk3gAAP8qIA= References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com><1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> From: "Dawson, Martin" To: "ECRIT" X-OriginalArrivalTime: 14 Jun 2007 02:55:52.0403 (UTC) FILETIME=[8527EA30:01C7AE2F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Typo alert - obviously it should have said that option *1* requires the=0D=0A= VSP to work out the local LoST server in addition to the LIS needing to=0D=0A= know it.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message---= --=0D=0AFrom: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20=0D=0ASent= : Thursday, 14 June 2007 11:14 AM=0D=0ATo: Henning Schulzrinne; Winterbotto= m, James=0D=0ACc: ECRIT=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3 - summa= ry of perspectives=0D=0A=0D=0ABTW - as I understand option 1, it requires t= he LIS to query the local=0D=0ALoST server as well. At least that's how I r= ecall Brian's original=0D=0Aproposal being stated. It returns a "PSAP URI b= oundary" location instead=0D=0Aof the PSAP URI.=0D=0A=0D=0AI think folk are= being inconsistent characterising option 3 as adding=0D=0ALoST functionali= ty to HELD. Both proposals require the LIS to interact=0D=0Awith LoST with = the subsequent proxying of results to the device.=0D=0A=0D=0AIf the proposi= tion of option 1 is that it's actually the LIS that holds=0D=0Athe PSAP-rel= evant boundary information, then option 1 is actually much=0D=0Amore like a= dding LoST functionality to the LIS (and adds inappropriate=0D=0Aresponsibi= lity to the LIS provider).=0D=0A=0D=0AFurther, given my understanding, both= proposals rely on the LIS knowing=0D=0Ainherently what the appropriate loc= al LoST server is. Option 1 just=0D=0Ameans that this is required *as well = as* the VSP being able to reach=0D=0Athat same local LoST service.=0D=0A=0D= =0ANeither option requires the ISP to implement LoST, they just require the=0D= =0AISP to know which LoST server is applicable to the local area of=0D=0Aco= verage. That's much more practical than expecting any arbitrary global=0D=0A= VSP being able to work that out but that is what option 3 requires *in=0D=0A= addition*.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-= ----=0D=0AFrom: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20=0D=0ASe= nt: Thursday, 14 June 2007 10:22 AM=0D=0ATo: Winterbottom, James=0D=0ACc: E= CRIT=0D=0ASubject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D= =0A=0D=0AI assume that your discussion has nothing to do with location hidi= ng =20=0D=0Aat this point, but wanted to call this out just in case I'm mis= sing =20=0D=0Ayour train of thought.=0D=0A=0D=0AI'm afraid I don't follow y= our logic. Unless you assume that every =20=0D=0AISP deploys a LoST+HELD se= rver, VSPs will have to have LoST servers =20=0D=0Awith PSAP knowledge for = the places their customers are likely to =20=0D=0Avisit. This doesn't chang= e whether HELD also gets converted into a =20=0D=0ALoST access protocol or = not. So far, at least, VSPs seem a whole lot =20=0D=0Amore interested in pr= oviding emergency call services than ISPs, =20=0D=0Apresumably because thei= r customers look to them for that service, not =20=0D=0Ato the random hot s= pot operator.=0D=0A=0D=0AIt's always been the model that both ISPs and VSPs= (as well as third =20=0D=0Aparties that are neither) can and should operat= e LoST servers, as =20=0D=0Athat seems most likely to ensure that you get b= road coverage.=0D=0A=0D=0AHenning=0D=0A=0D=0AOn Jun 13, 2007, at 8:00 PM, W= interbottom, James wrote:=0D=0A=0D=0A> Henning,=0D=0A>=0D=0A> I think that = your proposal only works if the VSP is able to provide a=0D=0A> LoST server= for all jurisdictions that it plans to provide service =20=0D=0A> for,=0D=0A= > or it has to do it for everything (sounds awfully like a global VPC to=0D= =0A> me). Option 3 would be deployable from a local area to a local PSAP=0D= =0A> REGARDLESS of the VSP having a LoST server that has boundary =20=0D=0A= > information=0D=0A> for the local area I am in. It provides a global solut= ion from the=0D=0A> get-go.=0D=0A>=0D=0A> Let's take the good old Sierra-Le= one example again.=0D=0A>=0D=0A> My VSP is in Sierra-Leone and I am visitin= g Samoa. In option 3, I =20=0D=0A> get a=0D=0A> PSA P URI for the local Sam= oan PSAP from the local access LIS serving=0D=0A> the area I am in, I send = my call to VSP, it sends it on the PSAP. I =20=0D=0A> get=0D=0A> billed, ca= ll completes, we are done. I can quibble with my VSP later=0D=0A> over the = 10 cent call charge if I can be bothered.=0D=0A>=0D=0A> With option 1, I se= nd my call with location to my VSP, and one of =20=0D=0A> three=0D=0A> thin= gs happens. Either it has a complete forest guide network set-=20=0D=0A> up= to=0D=0A> be able to talk to the Samoan LoST server nearest me, my call =0D= =0A> fails, or=0D=0A> the VSP routes the call anyway because the end-point = has done the LoST=0D=0A> lookup. I point out, that from the VSP perspective= the third =20=0D=0A> alternative=0D=0A> here is simply option 3 re-badged.= I am sure that VSPs wouldn't =20=0D=0A> drop the=0D=0A> call on the floor,= so choice 2 isn't an option, and choice 1 can ONLY=0D=0A> occur if the who= le network is up and running, and it doesn't =20=0D=0A> consist of=0D=0A> i= solated copse of Forest Guides and LoST Servers.=0D=0A>=0D=0A> So to my min= d, option 3 is the ONLY deployable solution in the short=0D=0A> term that w= ill actually work universally.=0D=0A>=0D=0A> Cheers=0D=0A> James=0D=0A>=0D=0A= >=0D=0A>> -----Original Message-----=0D=0A>> From: Henning Schulzrinne [mai= lto:hgs@cs.columbia.edu]=0D=0A>> Sent: Thursday, 14 June 2007 12:58 AM=0D=0A= >> To: Dawson, Martin=0D=0A>> Cc: ecrit@ietf.org=0D=0A>> Subject: Re: [Ecri= t] Proposals 1 and 3 - summary of perspectives=0D=0A>>=0D=0A>>=0D=0A>> On J= un 13, 2007, at 10:54 AM, Dawson, Martin wrote:=0D=0A>>=0D=0A>>> Nobody has= suggested changing LoST so this point is just a=0D=0A>>> distraction.=0D=0A= >>>=0D=0A>>>=0D=0A>>>=0D=0A>>> Option 1 means that emergency calls will not= be able to be routed=0D=0A>>> until the forest guide network is implemente= d. Option 3 means that=0D=0A>>> emergency calls will be able to be routed r= egardless of the state=0D=0A>>> of deployment of the forest guide.=0D=0A>>>=0D= =0A>>>=0D=0A>> This is not true, at least for comparable installations. The= ISP can=0D=0A>> offer a LoST server that has the locally-relevant informat= ion. Same=0D=0A>> for the VSP. This does not require a forest guide as such= =2E=0D=0A>>=0D=0A>> _______________________________________________=0D=0A>>= Ecrit mailing list=0D=0A>> Ecrit@ietf.org=0D=0A>> https://www1.ietf.org/ma= ilman/listinfo/ecrit=0D=0A>=0D=0A> ----------------------------------------= ------------------------------=0D=0A=0D=0A> --------------------------=0D=0A= > This message is for the designated recipient only and may=0D=0A> contain = privileged, proprietary, or otherwise private information.=0D=0A> If you ha= ve received it in error, please notify the sender=0D=0A> immediately and de= lete the original. Any unauthorized use of=0D=0A> this email is prohibited= =2E=0D=0A> ----------------------------------------------------------------= ------=0D=0A=0D=0A> --------------------------=0D=0A> [mf2]=0D=0A>=0D=0A=0D= =0A=0D=0A_______________________________________________=0D=0AEcrit mailing= list=0D=0AEcrit@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/listinfo/ecrit=0D= =0A=0D=0A------------------------------------------------------------------= ------=0D=0A------------------------=0D=0AThis message is for the designate= d recipient only and may=0D=0Acontain privileged, proprietary, or otherwise= private information. =20=0D=0AIf you have received it in error, please not= ify the sender=0D=0Aimmediately and delete the original. Any unauthorized = use of=0D=0Athis email is prohibited.=0D=0A--------------------------------= ----------------------------------------=0D=0A------------------------=0D=0A= [mf2]=0D=0A=0D=0A=0D=0A_______________________________________________=0D=0A= Ecrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/l= istinfo/ecrit=0D=0A=0D=0A--------------------------------------------------= ----------------------------------------------=0D=0AThis message is for the= designated recipient only and may=0D=0Acontain privileged, proprietary, or= otherwise private information. =20=0D=0AIf you have received it in error, = please notify the sender=0D=0Aimmediately and delete the original. Any una= uthorized use of=0D=0Athis email is prohibited.=0D=0A----------------------= --------------------------------------------------------------------------=0D= =0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 13 23:00:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyfZp-0007y0-PS; Wed, 13 Jun 2007 23:00:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyfZo-0007xv-Pi for ecrit@ietf.org; Wed, 13 Jun 2007 23:00:48 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyfZo-00058K-FG for ecrit@ietf.org; Wed, 13 Jun 2007 23:00:48 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 13 Jun 2007 20:00:48 -0700 X-IronPort-AV: i="4.16,418,1175497200"; d="scan'208"; a="164772068:sNHT44528490" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l5E30l0K016479; Wed, 13 Jun 2007 20:00:47 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5E30laI006058; Thu, 14 Jun 2007 03:00:47 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 20:00:47 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.67.65]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 20:00:47 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Jun 2007 22:00:45 -0500 To: shida@ntt-at.com, Ted Hardie From: "James M. Polk" Subject: Re: [Ecrit] What is left for LoST before IETF Last Call? In-Reply-To: <4670601B.2020508@ntt-at.com> References: <4670601B.2020508@ntt-at.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 14 Jun 2007 03:00:47.0128 (UTC) FILETIME=[34D36180:01C7AE30] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1309; t=1181790047; x=1182654047; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20What=20is=20left=20for=20LoST=20before=20IE TF=20Last=20Call? |Sender:=20; bh=/57mCFd+c7v578ToPiu8xFKN5t1A22grJMXYxIhdN/8=; b=jC2h4vGYiwGssYt5SZ0McUKME7146APZdnxZYn/jZPDf9ydLkkghbZEoCE1K2p+jJ66oozTy 4cQMg/Or5CvuMh2fmqlVPZ1LPdsW+5egEa10cH7zxZkJiLKw8DLiAsnF; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 04:22 PM 6/13/2007, Shida Schubert wrote: >Ted; > > needs to be modified to return location profile >type. As discussed a month ago, currently client can't match the location used >in the request to the location used to resolve the mapping. > >SIP location conveyance needs this correlation to flag the location used for >routing. Shida "needs" or "has"? SIP Conveyance -07 has this flag as a header parameter within the Geolocation header. I'm trying to see if you want something different or more there in that doc. Thanks James >Regards > Shida > > >Ted Hardie wrote: >>Since several people have now said that neither of the things on >>the table for location hiding require changes to LoST, what are >>the issues that prevent us from issuing the current rev and asking >>for IETF last call? If nothing, can we do so? >> >>If it needs revision later, so be it. But I'd like to get it done. >> >> Ted >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> >> >> > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 13 23:23:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyfvI-00036d-K8; Wed, 13 Jun 2007 23:23:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyfvH-00036Y-AV for ecrit@ietf.org; Wed, 13 Jun 2007 23:22:59 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyfvH-0002wl-01 for ecrit@ietf.org; Wed, 13 Jun 2007 23:22:59 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l5E3MgY5012358; Wed, 13 Jun 2007 21:22:45 -0600 Message-ID: <4670B471.40609@ntt-at.com> Date: Wed, 13 Jun 2007 20:22:25 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] What is left for LoST before IETF Last Call? References: <4670601B.2020508@ntt-at.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org James; It is a "need" in LoST not in location conveyance. What I am trying to say is that LoST is missing an element to carry indication as to which location was used for resolution when boundary is provided by reference (not by value). It's not a problem if only one location information was used in the request, but LoST currently allows multiple location information in request as long as they are of different profiles. And because has no way to indicate which location information(profile) was used, UA can't flag the proper location on SIP signaling to tell the downstream entities which location was used for location based routing (LoST). Regards Shida James M. Polk wrote: > At 04:22 PM 6/13/2007, Shida Schubert wrote: > >> Ted; >> >> needs to be modified to return location >> profile >> type. As discussed a month ago, currently client can't match the >> location used >> in the request to the location used to resolve the mapping. >> >> SIP location conveyance needs this correlation to flag the location >> used for >> routing. > > Shida > > "needs" or "has"? > > SIP Conveyance -07 has this flag as a header parameter within the > Geolocation header. I'm trying to see if you want something different > or more there in that doc. > > Thanks > James > > >> Regards >> Shida >> >> >> Ted Hardie wrote: >>> Since several people have now said that neither of the things on >>> the table for location hiding require changes to LoST, what are >>> the issues that prevent us from issuing the current rev and asking >>> for IETF last call? If nothing, can we do so? >>> >>> If it needs revision later, so be it. But I'd like to get it done. >>> >>> Ted >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >>> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 13 23:58:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HygTU-0003Yl-Et; Wed, 13 Jun 2007 23:58:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HygTT-0003Yg-Vj for ecrit@ietf.org; Wed, 13 Jun 2007 23:58:19 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HygTT-0006iB-KK for ecrit@ietf.org; Wed, 13 Jun 2007 23:58:19 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 13 Jun 2007 20:58:19 -0700 X-IronPort-AV: i="4.16,418,1175497200"; d="scan'208"; a="493913434:sNHT57689550" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5E3wIca005124; Wed, 13 Jun 2007 20:58:18 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5E3wE20008209; Thu, 14 Jun 2007 03:58:18 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 20:58:13 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.67.65]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jun 2007 20:58:13 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 13 Jun 2007 22:58:11 -0500 To: shida@ntt-at.com From: "James M. Polk" Subject: Re: [Ecrit] What is left for LoST before IETF Last Call? In-Reply-To: <4670B471.40609@ntt-at.com> References: <4670601B.2020508@ntt-at.com> <4670B471.40609@ntt-at.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 14 Jun 2007 03:58:13.0300 (UTC) FILETIME=[3AE77F40:01C7AE38] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2349; t=1181793498; x=1182657498; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20What=20is=20left=20for=20LoST=20before=20IE TF=20Last=20Call? |Sender:=20; bh=Fb2dUHB0H5+rhVRl8cXUIV6wIKrZCxXrPxPOJyRDJQs=; b=BrOX5mSpL/Zt1blqEa6QYWNuQLEbA0BO6TXZLGgZUuPAXbsU5yIMYa0veFaj08CIIyU2Ra2M 7hZYtjiZCOQDDtTDef/FSEtblX9Seu3VzoICfsvRgEjzH46haYPnSK3r; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 10:22 PM 6/13/2007, Shida Schubert wrote: >James; > >It is a "need" in LoST not in location conveyance. Thanks I'd hoped so, but was just checking to see if I'd missed something in what I'm finishing putting into Conveyance-08 >What I am trying to say is that LoST is missing an element to >carry indication as to which location was used for resolution >when boundary is provided by reference (not by value). >It's not a problem if only one location information was used in >the request, but LoST currently allows multiple location >information in request as long as they are of different profiles. > >And because has no way to indicate >which location information(profile) was used, UA can't flag the proper >location on SIP signaling to tell the downstream entities which >location was used for location based routing (LoST). > >Regards > Shida > >James M. Polk wrote: >>At 04:22 PM 6/13/2007, Shida Schubert wrote: >> >>>Ted; >>> >>> needs to be modified to return location profile >>>type. As discussed a month ago, currently client can't match the >>>location used >>>in the request to the location used to resolve the mapping. >>> >>>SIP location conveyance needs this correlation to flag the location used for >>>routing. >> >>Shida >> >>"needs" or "has"? >> >>SIP Conveyance -07 has this flag as a header parameter within the >>Geolocation header. I'm trying to see if you want something >>different or more there in that doc. >> >>Thanks >>James >> >> >>>Regards >>> Shida >>> >>> >>>Ted Hardie wrote: >>>>Since several people have now said that neither of the things on >>>>the table for location hiding require changes to LoST, what are >>>>the issues that prevent us from issuing the current rev and asking >>>>for IETF last call? If nothing, can we do so? >>>> >>>>If it needs revision later, so be it. But I'd like to get it done. >>>> >>>> Ted >>>> >>>>_______________________________________________ >>>>Ecrit mailing list >>>>Ecrit@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>> >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 14 00:42:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyhA3-0004Tj-V2; Thu, 14 Jun 2007 00:42:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyhA2-0004TZ-Rn for ecrit@ietf.org; Thu, 14 Jun 2007 00:42:18 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyhA2-00040v-Eu for ecrit@ietf.org; Thu, 14 Jun 2007 00:42:18 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l5E4gGk8023703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Jun 2007 21:42:16 -0700 Received: from [76.102.225.135] (vpn-10-50-0-231.qualcomm.com [10.50.0.231]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l5E4gDZT009748; Wed, 13 Jun 2007 21:42:15 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4670601B.2020508@ntt-at.com> <4670B471.40609@ntt-at.com> Date: Wed, 13 Jun 2007 21:42:13 -0700 To: "James M. Polk" , shida@ntt-at.com From: Ted Hardie Subject: Re: [Ecrit] What is left for LoST before IETF Last Call? Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Okay, I'll talk to Henning, Andy, and Hannes via email and we'll try to get something into a revision real soon now. Any suggested text for this will be greeted warmly. Any *other* issues we need to fix before moving forward? Ted At 10:58 PM -0500 6/13/07, James M. Polk wrote: >At 10:22 PM 6/13/2007, Shida Schubert wrote: > >>James; >> >>It is a "need" in LoST not in location conveyance. > >Thanks > >I'd hoped so, but was just checking to see if I'd missed something in what I'm finishing putting into Conveyance-08 > >>What I am trying to say is that LoST is missing an element to >>carry indication as to which location was used for resolution >>when boundary is provided by reference (not by value). >>It's not a problem if only one location information was used in >>the request, but LoST currently allows multiple location >>information in request as long as they are of different profiles. >> >>And because has no way to indicate >>which location information(profile) was used, UA can't flag the proper >>location on SIP signaling to tell the downstream entities which >>location was used for location based routing (LoST). >> >>Regards >> Shida >> >>James M. Polk wrote: >>>At 04:22 PM 6/13/2007, Shida Schubert wrote: >>> >>>>Ted; >>>> >>>> needs to be modified to return location profile >>>>type. As discussed a month ago, currently client can't match the location used >>>>in the request to the location used to resolve the mapping. >>>> >>>>SIP location conveyance needs this correlation to flag the location used for >>>>routing. >>> >>>Shida >>> >>>"needs" or "has"? >>> >>>SIP Conveyance -07 has this flag as a header parameter within the Geolocation header. I'm trying to see if you want something different or more there in that doc. >>> >>>Thanks >>>James >>> >>>>Regards >>>> Shida >>>> >>>> >>>>Ted Hardie wrote: >>>>>Since several people have now said that neither of the things on >>>>>the table for location hiding require changes to LoST, what are >>>>>the issues that prevent us from issuing the current rev and asking >>>>>for IETF last call? If nothing, can we do so? >>>>> >>>>>If it needs revision later, so be it. But I'd like to get it done. >>>>> >>>>> Ted >>>>> >>>>>_______________________________________________ >>>>>Ecrit mailing list >>>>>Ecrit@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>>> >>>> >>>>_______________________________________________ >>>>Ecrit mailing list >>>>Ecrit@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 14 09:07:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyp2T-0006wv-V4; Thu, 14 Jun 2007 09:07:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyp2Q-0006uo-4f for ecrit@ietf.org; Thu, 14 Jun 2007 09:06:58 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyp2P-0004Dh-Iw for ecrit@ietf.org; Thu, 14 Jun 2007 09:06:58 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1Hyp2K-0002Uz-AU; Thu, 14 Jun 2007 08:06:52 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , "'ECRIT'" References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com><1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Thu, 14 Jun 2007 09:06:51 -0400 Message-ID: <087a01c7ae84$e1b48a10$9501a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AceuGgIUdnorn1MfT9KY7XAHcoK3nAABWk3gAAP8qIAAFRhfQA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Wait a minute, we're getting confused. Option 1 requires that the access network dereference to anyone with at least coarse location suitable for emergency call routing. If the endpoint does routing, it will use a local LoST server which has high probability of having the route. If a VSP wants to verify, it needs access to a LoST server covering the area where his customers roam. The cost is on the carrier that is trying to hide location (which, AFAIK, is an economic issue all the way, the hiding is so the access network can charge for non emergency uses of location). Option 3 requires that the access network dereference to anyone with at least coarse location suitable for emergency call routing. This is because if the endpoint doesn't route (or more specifically, if it doesn't recognize emergency dialstrings, query LoST, and add the PSAP URI), but does supply location, then the VSP has to route, and it will have to dereference. If the endpoint does routing, option 3 is easy, because it will have the correct PSAP URIs (it has to be all of them, BTW, a problem in itself). If a VSP wants to verify, it needs access to a LoST server covering the area where his customers roam. It can't use the LCP, it has to dereference the location, and then query LoST. If we supply a different mechanism for a VSP to validate, that could change, and it would affect 1 and 3 the same way. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Wednesday, June 13, 2007 10:56 PM > To: ECRIT > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > Typo alert - obviously it should have said that option *1* requires the > VSP to work out the local LoST server in addition to the LIS needing to > know it. > > Cheers, > Martin > > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Thursday, 14 June 2007 11:14 AM > To: Henning Schulzrinne; Winterbottom, James > Cc: ECRIT > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > BTW - as I understand option 1, it requires the LIS to query the local > LoST server as well. At least that's how I recall Brian's original > proposal being stated. It returns a "PSAP URI boundary" location instead > of the PSAP URI. > > I think folk are being inconsistent characterising option 3 as adding > LoST functionality to HELD. Both proposals require the LIS to interact > with LoST with the subsequent proxying of results to the device. > > If the proposition of option 1 is that it's actually the LIS that holds > the PSAP-relevant boundary information, then option 1 is actually much > more like adding LoST functionality to the LIS (and adds inappropriate > responsibility to the LIS provider). > > Further, given my understanding, both proposals rely on the LIS knowing > inherently what the appropriate local LoST server is. Option 1 just > means that this is required *as well as* the VSP being able to reach > that same local LoST service. > > Neither option requires the ISP to implement LoST, they just require the > ISP to know which LoST server is applicable to the local area of > coverage. That's much more practical than expecting any arbitrary global > VSP being able to work that out but that is what option 3 requires *in > addition*. > > Cheers, > Martin > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, 14 June 2007 10:22 AM > To: Winterbottom, James > Cc: ECRIT > Subject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives > > I assume that your discussion has nothing to do with location hiding > at this point, but wanted to call this out just in case I'm missing > your train of thought. > > I'm afraid I don't follow your logic. Unless you assume that every > ISP deploys a LoST+HELD server, VSPs will have to have LoST servers > with PSAP knowledge for the places their customers are likely to > visit. This doesn't change whether HELD also gets converted into a > LoST access protocol or not. So far, at least, VSPs seem a whole lot > more interested in providing emergency call services than ISPs, > presumably because their customers look to them for that service, not > to the random hot spot operator. > > It's always been the model that both ISPs and VSPs (as well as third > parties that are neither) can and should operate LoST servers, as > that seems most likely to ensure that you get broad coverage. > > Henning > > On Jun 13, 2007, at 8:00 PM, Winterbottom, James wrote: > > > Henning, > > > > I think that your proposal only works if the VSP is able to provide a > > LoST server for all jurisdictions that it plans to provide service > > for, > > or it has to do it for everything (sounds awfully like a global VPC to > > me). Option 3 would be deployable from a local area to a local PSAP > > REGARDLESS of the VSP having a LoST server that has boundary > > information > > for the local area I am in. It provides a global solution from the > > get-go. > > > > Let's take the good old Sierra-Leone example again. > > > > My VSP is in Sierra-Leone and I am visiting Samoa. In option 3, I > > get a > > PSA P URI for the local Samoan PSAP from the local access LIS serving > > the area I am in, I send my call to VSP, it sends it on the PSAP. I > > get > > billed, call completes, we are done. I can quibble with my VSP later > > over the 10 cent call charge if I can be bothered. > > > > With option 1, I send my call with location to my VSP, and one of > > three > > things happens. Either it has a complete forest guide network set- > > up to > > be able to talk to the Samoan LoST server nearest me, my call > > fails, or > > the VSP routes the call anyway because the end-point has done the LoST > > lookup. I point out, that from the VSP perspective the third > > alternative > > here is simply option 3 re-badged. I am sure that VSPs wouldn't > > drop the > > call on the floor, so choice 2 isn't an option, and choice 1 can ONLY > > occur if the whole network is up and running, and it doesn't > > consist of > > isolated copse of Forest Guides and LoST Servers. > > > > So to my mind, option 3 is the ONLY deployable solution in the short > > term that will actually work universally. > > > > Cheers > > James > > > > > >> -----Original Message----- > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >> Sent: Thursday, 14 June 2007 12:58 AM > >> To: Dawson, Martin > >> Cc: ecrit@ietf.org > >> Subject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives > >> > >> > >> On Jun 13, 2007, at 10:54 AM, Dawson, Martin wrote: > >> > >>> Nobody has suggested changing LoST so this point is just a > >>> distraction. > >>> > >>> > >>> > >>> Option 1 means that emergency calls will not be able to be routed > >>> until the forest guide network is implemented. Option 3 means that > >>> emergency calls will be able to be routed regardless of the state > >>> of deployment of the forest guide. > >>> > >>> > >> This is not true, at least for comparable installations. The ISP can > >> offer a LoST server that has the locally-relevant information. Same > >> for the VSP. This does not require a forest guide as such. > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > ---------------------------------------------------------------------- > > > -------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > ---------------------------------------------------------------------- > > > -------------------------- > > [mf2] > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------ > ------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ > ------------------------ > [mf2] > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 14 09:10:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyp60-0000W9-Oj; Thu, 14 Jun 2007 09:10:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyp60-0000W1-Ee for ecrit@ietf.org; Thu, 14 Jun 2007 09:10:40 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyp5z-0005pV-Uu for ecrit@ietf.org; Thu, 14 Jun 2007 09:10:40 -0400 Received: from ([139.76.131.91]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.178911316; Thu, 14 Jun 2007 09:10:21 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 14 Jun 2007 09:09:50 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 14 Jun 2007 09:09:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Thu, 14 Jun 2007 09:09:49 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA04666EB0@crexc41p> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives Thread-Index: AceuGf4tkdGQiPteTn+8Rwa4RbhKqAAZsLsg References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com><1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> From: "Stark, Barbara" To: "Henning Schulzrinne" , "Winterbottom, James" X-OriginalArrivalTime: 14 Jun 2007 13:09:50.0148 (UTC) FILETIME=[4A29B840:01C7AE85] X-Spam-Score: 0.6 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org No, VSPs only "have to have" knowledge of LoST servers for PSAPs within the regional boundaries of their stated area of operations. A VSP that claims to serve only the US, only sells to people with US addresses, and only provides US phone numbers (if interaction with the PSTN is provided), does not have to have knowledge of European or Australian PSAPs. The fact that many people in Europe and Australia use such services does not present a requirement on such services.=20 And VSPs weren't particularly interested in providing emergency call service until some got bad press and then the government stepped in and required it. Since ISPs don't get bad press today (for not being involved in support of emergency services), the government hasn't required such involvement, and it's going to cost a whole lot, you're right in that ISPs aren't interested.=20 Interest and willingness to deploy result from one of two things: (1) positive business case, or (2) regulation. In the absence of positive business cases, who sets up LoST servers will largely be a question of whether the government provides LoST servers (usually by contracting certain companies to do it), or the government requires certain companies (e.g., all VSPs, VSPs with over x number of customers, all ISPs, ISPs with over x number of customers) to provide LoST servers.=20 By the way, I agree that we need no further work in LoST for Location Hiding. The question of whether a LCP may also include the LoST information in the info it sends a device is a geopriv question. Unless I really misunderstand how IETF works, just because ecrit doesn't include mention of or support for this option in its emergency services architecture, doesn't mean that the option can't exist within a LCP for other purposes. But that's a topic for geopriv (I hope). Barbara -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Wednesday, June 13, 2007 8:22 PM To: Winterbottom, James Cc: ECRIT Subject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives I assume that your discussion has nothing to do with location hiding at this point, but wanted to call this out just in case I'm missing your train of thought. I'm afraid I don't follow your logic. Unless you assume that every ISP deploys a LoST+HELD server, VSPs will have to have LoST servers with PSAP knowledge for the places their customers are likely to visit. This doesn't change whether HELD also gets converted into a LoST access protocol or not. So far, at least, VSPs seem a whole lot more interested in providing emergency call services than ISPs, presumably because their customers look to them for that service, not to the random hot spot operator. It's always been the model that both ISPs and VSPs (as well as third parties that are neither) can and should operate LoST servers, as that seems most likely to ensure that you get broad coverage. Henning On Jun 13, 2007, at 8:00 PM, Winterbottom, James wrote: > Henning, > > I think that your proposal only works if the VSP is able to provide a=20 > LoST server for all jurisdictions that it plans to provide service=20 > for, or it has to do it for everything (sounds awfully like a global=20 > VPC to me). Option 3 would be deployable from a local area to a local=20 > PSAP REGARDLESS of the VSP having a LoST server that has boundary=20 > information for the local area I am in. It provides a global solution=20 > from the get-go. > > Let's take the good old Sierra-Leone example again. > > My VSP is in Sierra-Leone and I am visiting Samoa. In option 3, I get=20 > a PSA P URI for the local Samoan PSAP from the local access LIS=20 > serving the area I am in, I send my call to VSP, it sends it on the=20 > PSAP. I get billed, call completes, we are done. I can quibble with my > VSP later over the 10 cent call charge if I can be bothered. > > With option 1, I send my call with location to my VSP, and one of=20 > three things happens. Either it has a complete forest guide network=20 > set- up to be able to talk to the Samoan LoST server nearest me, my=20 > call fails, or the VSP routes the call anyway because the end-point=20 > has done the LoST lookup. I point out, that from the VSP perspective=20 > the third alternative here is simply option 3 re-badged. I am sure=20 > that VSPs wouldn't drop the call on the floor, so choice 2 isn't an=20 > option, and choice 1 can ONLY occur if the whole network is up and=20 > running, and it doesn't consist of isolated copse of Forest Guides and > LoST Servers. > > So to my mind, option 3 is the ONLY deployable solution in the short=20 > term that will actually work universally. > > Cheers > James > > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Thursday, 14 June 2007 12:58 AM >> To: Dawson, Martin >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives >> >> >> On Jun 13, 2007, at 10:54 AM, Dawson, Martin wrote: >> >>> Nobody has suggested changing LoST so this point is just a=20 >>> distraction. >>> >>> >>> >>> Option 1 means that emergency calls will not be able to be routed=20 >>> until the forest guide network is implemented. Option 3 means that=20 >>> emergency calls will be able to be routed regardless of the state of >>> deployment of the forest guide. >>> >>> >> This is not true, at least for comparable installations. The ISP can=20 >> offer a LoST server that has the locally-relevant information. Same=20 >> for the VSP. This does not require a forest guide as such. >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > ---------------------------------------------------------------------- > -------------------------- > This message is for the designated recipient only and may contain=20 > privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender immediately > and delete the original. Any unauthorized use of this email is=20 > prohibited. > ---------------------------------------------------------------------- > -------------------------- > [mf2] > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 14 13:00:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hysge-0006x5-Vw; Thu, 14 Jun 2007 13:00:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hysgd-0006wf-IL for ecrit@ietf.org; Thu, 14 Jun 2007 13:00:43 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hysgc-0007la-Bt for ecrit@ietf.org; Thu, 14 Jun 2007 13:00:43 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 14 Jun 2007 13:00:40 -0400 id 01588442.46717438.000014C8 In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA04666EB0@crexc41p> References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com><1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> <7582BC68E4994F4ABF0BD4723975C3FA04666EB0@crexc41p> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Thu, 14 Jun 2007 13:00:36 -0400 To: "Stark, Barbara" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 14, 2007, at 9:09 AM, Stark, Barbara wrote: > No, VSPs only "have to have" knowledge of LoST servers for PSAPs > within > the regional boundaries of their stated area of operations. A VSP that > claims to serve only the US, only sells to people with US > addresses, and > only provides US phone numbers (if interaction with the PSTN is > provided), does not have to have knowledge of European or Australian > PSAPs. The fact that many people in Europe and Australia use such > services does not present a requirement on such services. You've over generalized here. There are VSPs that cover more than one country. > And VSPs weren't particularly interested in providing emergency call > service until some got bad press and then the government stepped in > and > required it. And again, you've over generalized. Some VSPs have offered emergency call service since day 1 of operation. Some continue to offer it to customers in bad standing. And the notion that VSPs are entities that solely retail services is incorrect. Some very, very large VSPs are the IT departments of large, multi-national corporations and non-profits. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 14 17:15:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hywex-0004V2-E9; Thu, 14 Jun 2007 17:15:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hywev-0004O3-MW for ecrit@ietf.org; Thu, 14 Jun 2007 17:15:13 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HywdI-00030J-Rn for ecrit@ietf.org; Thu, 14 Jun 2007 17:13:33 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5ELDOrA008949 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Jun 2007 17:13:24 -0400 (EDT) In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA04666EB0@crexc41p> References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com><1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> <7582BC68E4994F4ABF0BD4723975C3FA04666EB0@crexc41p> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <74426F0E-C137-4D3E-8974-288E82D7A36F@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Thu, 14 Jun 2007 17:14:12 -0400 To: "Stark, Barbara" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Just to add a small note to Andy's comments: Rather than guessing what regulators may or may not require or what VSP (or ISPs) will try to get away with, I think it is more productive to make it possible for all parties to do the right thing, which presumably includes the ability for VSPs to serve their traveling customers. After all, even if looked at from a purely monetary perspective, a traveling customer that can dial 911 is better than a dead customer. I realize we may not get there immediately and universally. Henning On Jun 14, 2007, at 9:09 AM, Stark, Barbara wrote: > No, VSPs only "have to have" knowledge of LoST servers for PSAPs > within > the regional boundaries of their stated area of operations. A VSP that > claims to serve only the US, only sells to people with US > addresses, and > only provides US phone numbers (if interaction with the PSTN is > provided), does not have to have knowledge of European or Australian > PSAPs. The fact that many people in Europe and Australia use such > services does not present a requirement on such services. > > And VSPs weren't particularly interested in providing emergency call > service until some got bad press and then the government stepped in > and > required it. Since ISPs don't get bad press today (for not being > involved in support of emergency services), the government hasn't > required such involvement, and it's going to cost a whole lot, you're > right in that ISPs aren't interested. > > Interest and willingness to deploy result from one of two things: (1) > positive business case, or (2) regulation. In the absence of positive > business cases, who sets up LoST servers will largely be a question of > whether the government provides LoST servers (usually by contracting > certain companies to do it), or the government requires certain > companies (e.g., all VSPs, VSPs with over x number of customers, all > ISPs, ISPs with over x number of customers) to provide LoST servers. > > By the way, I agree that we need no further work in LoST for Location > Hiding. The question of whether a LCP may also include the LoST > information in the info it sends a device is a geopriv question. > Unless > I really misunderstand how IETF works, just because ecrit doesn't > include mention of or support for this option in its emergency > services > architecture, doesn't mean that the option can't exist within a LCP > for > other purposes. But that's a topic for geopriv (I hope). > Barbara > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 15 03:34:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz6Jl-0000Mk-Mm; Fri, 15 Jun 2007 03:34:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz6Ji-00007W-Dj for ecrit@ietf.org; Fri, 15 Jun 2007 03:33:58 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz6Hx-0001s2-8a for ecrit@ietf.org; Fri, 15 Jun 2007 03:32:09 -0400 X-SEF-Processed: 5_0_0_910__2007_06_15_02_39_50 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 15 Jun 2007 02:39:50 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jun 2007 02:32:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Fri, 15 Jun 2007 02:32:06 -0500 Message-ID: In-Reply-To: <087a01c7ae84$e1b48a10$9501a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives Thread-Index: AceuGgIUdnorn1MfT9KY7XAHcoK3nAABWk3gAAP8qIAAFRhfQAAEcxKw References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com><1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> <087a01c7ae84$e1b48a10$9501a8c0@cis.neustar.com> From: "Dawson, Martin" To: X-OriginalArrivalTime: 15 Jun 2007 07:32:08.0629 (UTC) FILETIME=[47C50650:01C7AF1F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org =0D=0ASpeak for yourself :) Your description of option 3 does not correlate=0D= =0Awith my description or understanding of it. So, if there's confusion,=0D= =0Aperhaps this is the root of it.=0D=0A=0D=0AIn option 3 - the access netw= ork doesn't determine coarse location at=0D=0Aall. It doesn't concern itsel= f with coarse location. It uses the precise=0D=0Alocation that it determine= s for the device, queries the local LoST=0D=0Aserver and provides the resul= tant PSAP URI directly to the device. At=0D=0Athis point the routing has be= en achieved and the device can route=0D=0Adirectly or via the VSP. When the= PSAP dereferences, it gets the precise=0D=0Alocation from the LIS. It is e= xactly because the routing is achieved by=0D=0Ajust the local elements that= this option doesn't have the Achilles heel=0D=0Aof option 1 which requires= the VSP, absolutely, to be able to find the=0D=0Aauthoritative local LoST = server. As I say, for a very remote VSP and no=0D=0Afunctioning forest guid= e, it may very well not be able to.=0D=0A=0D=0AThere's a basic principle he= re - emergency services are local to the=0D=0Acaller, the access network op= erator (and LIS) are local to the caller,=0D=0Aand the authoritative LoST s= erver is going to most local to the caller.=0D=0AThe ability to reliably ro= ute the call is going to be optimal if it's=0D=0Adone between all these loc= al entities who are best placed to be aware of=0D=0Aeach other. Waiting unt= il the call scenario has geographically diverged=0D=0Ato the VSP before att= empting to determine routing is unnecessarily=0D=0Asub-optimal.=0D=0A=0D=0A= In option 1 - how do you propose the access network determine the=0D=0A"coa= rse location"=3F I believe your proposal is that it uses the local=0D=0ALoS= T server applicable to its area of coverage and utilize the semantics=0D=0A= of LoST which provide a PSAP boundary in the response. Can you confirm=0D=0A= that this is your proposal=3F Otherwise, how would you anticipate that the=0D= =0Aaccess provider, who doesn't manage the PSAP boundaries after all, would=0D= =0Aknow what is the appropriate coarse location that will result in a=0D=0A= reliable response when LoST is queried=3F=0D=0A=0D=0AWith respect to Hennin= g's comment about LoST services being provided by=0D=0AISPs and/or VSPs, I = didn't resonate with that. I would expect that LoST=0D=0Ais emergency servi= ces specific and it is likely to be part of some=0D=0Ajurisdictional functi= on or some provider of services to that=0D=0Ajurisdictional function. I don= 't see that either ISPs or VSPs are=0D=0Aqualified to manage the PSAP routi= ng information contained in a LoST=0D=0Aserver.=0D=0A=0D=0ACheers,=0D=0AMar= tin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Brian Rosen [mailto:br= @brianrosen.net]=20=0D=0ASent: Thursday, 14 June 2007 11:07 PM=0D=0ATo: Daw= son, Martin; 'ECRIT'=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3 - summary = of perspectives=0D=0A=0D=0AWait a minute, we're getting confused.=0D=0A=0D=0A= Option 1 requires that the access network dereference to anyone with at=0D=0A= least coarse location suitable for emergency call routing. If the=0D=0Aend= point=0D=0Adoes routing, it will use a local LoST server which has high pro= bability=0D=0Aof=0D=0Ahaving the route. If a VSP wants to verify, it needs= access to a LoST=0D=0Aserver covering the area where his customers roam. = The cost is on the=0D=0Acarrier that is trying to hide location (which, AFA= IK, is an economic=0D=0Aissue=0D=0Aall the way, the hiding is so the access= network can charge for non=0D=0Aemergency uses of location).=0D=0A=0D=0AOp= tion 3 requires that the access network dereference to anyone with at=0D=0A= least coarse location suitable for emergency call routing. This is=0D=0Abe= cause=0D=0Aif the endpoint doesn't route (or more specifically, if it doesn= 't=0D=0Arecognize=0D=0Aemergency dialstrings, query LoST, and add the PSAP = URI), but does=0D=0Asupply=0D=0Alocation, then the VSP has to route, and it= will have to dereference.=0D=0AIf=0D=0Athe endpoint does routing, option 3= is easy, because it will have the=0D=0Acorrect PSAP URIs (it has to be all= of them, BTW, a problem in itself).=0D=0AIf=0D=0Aa VSP wants to verify, it= needs access to a LoST server covering the=0D=0Aarea=0D=0Awhere his custom= ers roam. It can't use the LCP, it has to dereference=0D=0Athe=0D=0Alocati= on, and then query LoST. =20=0D=0A=0D=0AIf we supply a different mechanism = for a VSP to validate, that could=0D=0Achange,=0D=0Aand it would affect 1 a= nd 3 the same way.=0D=0A=0D=0ABrian=0D=0A=0D=0A> -----Original Message-----=0D= =0A> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> Sent: We= dnesday, June 13, 2007 10:56 PM=0D=0A> To: ECRIT=0D=0A> Subject: RE: [Ecrit= ] Proposals 1 and 3 - summary of perspectives=0D=0A>=20=0D=0A> Typo alert -= obviously it should have said that option *1* requires=0D=0Athe=0D=0A> VSP= to work out the local LoST server in addition to the LIS needing=0D=0Ato=0D= =0A> know it.=0D=0A>=20=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=20=0D=0A> -----= Original Message-----=0D=0A> From: Dawson, Martin [mailto:Martin.Dawson@and= rew.com]=0D=0A> Sent: Thursday, 14 June 2007 11:14 AM=0D=0A> To: Henning Sc= hulzrinne; Winterbottom, James=0D=0A> Cc: ECRIT=0D=0A> Subject: RE: [Ecrit]= Proposals 1 and 3 - summary of perspectives=0D=0A>=20=0D=0A> BTW - as I un= derstand option 1, it requires the LIS to query the local=0D=0A> LoST serve= r as well. At least that's how I recall Brian's original=0D=0A> proposal be= ing stated. It returns a "PSAP URI boundary" location=0D=0Ainstead=0D=0A> o= f the PSAP URI.=0D=0A>=20=0D=0A> I think folk are being inconsistent charac= terising option 3 as adding=0D=0A> LoST functionality to HELD. Both proposa= ls require the LIS to interact=0D=0A> with LoST with the subsequent proxyin= g of results to the device.=0D=0A>=20=0D=0A> If the proposition of option 1= is that it's actually the LIS that=0D=0Aholds=0D=0A> the PSAP-relevant bou= ndary information, then option 1 is actually much=0D=0A> more like adding L= oST functionality to the LIS (and adds inappropriate=0D=0A> responsibility = to the LIS provider).=0D=0A>=20=0D=0A> Further, given my understanding, bot= h proposals rely on the LIS=0D=0Aknowing=0D=0A> inherently what the appropr= iate local LoST server is. Option 1 just=0D=0A> means that this is required= *as well as* the VSP being able to reach=0D=0A> that same local LoST servi= ce.=0D=0A>=20=0D=0A> Neither option requires the ISP to implement LoST, the= y just require=0D=0Athe=0D=0A> ISP to know which LoST server is applicable = to the local area of=0D=0A> coverage. That's much more practical than expec= ting any arbitrary=0D=0Aglobal=0D=0A> VSP being able to work that out but t= hat is what option 3 requires *in=0D=0A> addition*.=0D=0A>=20=0D=0A> Cheers= ,=0D=0A> Martin=0D=0A>=20=0D=0A> -----Original Message-----=0D=0A> From: He= nning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A> Sent: Thursday, 14 Ju= ne 2007 10:22 AM=0D=0A> To: Winterbottom, James=0D=0A> Cc: ECRIT=0D=0A> Sub= ject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A>=20=0D=0A= > I assume that your discussion has nothing to do with location hiding=0D=0A= > at this point, but wanted to call this out just in case I'm missing=0D=0A= > your train of thought.=0D=0A>=20=0D=0A> I'm afraid I don't follow your lo= gic. Unless you assume that every=0D=0A> ISP deploys a LoST+HELD server, VS= Ps will have to have LoST servers=0D=0A> with PSAP knowledge for the places= their customers are likely to=0D=0A> visit. This doesn't change whether HE= LD also gets converted into a=0D=0A> LoST access protocol or not. So far, a= t least, VSPs seem a whole lot=0D=0A> more interested in providing emergenc= y call services than ISPs,=0D=0A> presumably because their customers look t= o them for that service, not=0D=0A> to the random hot spot operator.=0D=0A>= =20=0D=0A> It's always been the model that both ISPs and VSPs (as well as t= hird=0D=0A> parties that are neither) can and should operate LoST servers, = as=0D=0A> that seems most likely to ensure that you get broad coverage.=0D=0A= >=20=0D=0A> Henning=0D=0A>=20=0D=0A> On Jun 13, 2007, at 8:00 PM, Winterbot= tom, James wrote:=0D=0A>=20=0D=0A> > Henning,=0D=0A> >=0D=0A> > I think tha= t your proposal only works if the VSP is able to provide=0D=0Aa=0D=0A> > Lo= ST server for all jurisdictions that it plans to provide service=0D=0A> > f= or,=0D=0A> > or it has to do it for everything (sounds awfully like a globa= l VPC=0D=0Ato=0D=0A> > me). Option 3 would be deployable from a local area = to a local PSAP=0D=0A> > REGARDLESS of the VSP having a LoST server that ha= s boundary=0D=0A> > information=0D=0A> > for the local area I am in. It pro= vides a global solution from the=0D=0A> > get-go.=0D=0A> >=0D=0A> > Let's t= ake the good old Sierra-Leone example again.=0D=0A> >=0D=0A> > My VSP is in= Sierra-Leone and I am visiting Samoa. In option 3, I=0D=0A> > get a=0D=0A>= > PSA P URI for the local Samoan PSAP from the local access LIS=0D=0Aservi= ng=0D=0A> > the area I am in, I send my call to VSP, it sends it on the PSA= P. I=0D=0A> > get=0D=0A> > billed, call completes, we are done. I can quibb= le with my VSP later=0D=0A> > over the 10 cent call charge if I can be both= ered.=0D=0A> >=0D=0A> > With option 1, I send my call with location to my V= SP, and one of=0D=0A> > three=0D=0A> > things happens. Either it has a comp= lete forest guide network set-=0D=0A> > up to=0D=0A> > be able to talk to t= he Samoan LoST server nearest me, my call=0D=0A> > fails, or=0D=0A> > the V= SP routes the call anyway because the end-point has done the=0D=0ALoST=0D=0A= > > lookup. I point out, that from the VSP perspective the third=0D=0A> > a= lternative=0D=0A> > here is simply option 3 re-badged. I am sure that VSPs = wouldn't=0D=0A> > drop the=0D=0A> > call on the floor, so choice 2 isn't an= option, and choice 1 can=0D=0AONLY=0D=0A> > occur if the whole network is = up and running, and it doesn't=0D=0A> > consist of=0D=0A> > isolated copse = of Forest Guides and LoST Servers.=0D=0A> >=0D=0A> > So to my mind, option = 3 is the ONLY deployable solution in the short=0D=0A> > term that will actu= ally work universally.=0D=0A> >=0D=0A> > Cheers=0D=0A> > James=0D=0A> >=0D=0A= > >=0D=0A> >> -----Original Message-----=0D=0A> >> From: Henning Schulzrinn= e [mailto:hgs@cs.columbia.edu]=0D=0A> >> Sent: Thursday, 14 June 2007 12:58= AM=0D=0A> >> To: Dawson, Martin=0D=0A> >> Cc: ecrit@ietf.org=0D=0A> >> Sub= ject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A> >>=0D=0A= > >>=0D=0A> >> On Jun 13, 2007, at 10:54 AM, Dawson, Martin wrote:=0D=0A> >= >=0D=0A> >>> Nobody has suggested changing LoST so this point is just a=0D=0A= > >>> distraction.=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>=0D=0A> >>> Option 1 mea= ns that emergency calls will not be able to be routed=0D=0A> >>> until the = forest guide network is implemented. Option 3 means that=0D=0A> >>> emergen= cy calls will be able to be routed regardless of the state=0D=0A> >>> of de= ployment of the forest guide.=0D=0A> >>>=0D=0A> >>>=0D=0A> >> This is not t= rue, at least for comparable installations. The ISP=0D=0Acan=0D=0A> >> offe= r a LoST server that has the locally-relevant information. Same=0D=0A> >> f= or the VSP. This does not require a forest guide as such.=0D=0A> >>=0D=0A> = >> _______________________________________________=0D=0A> >> Ecrit mailing = list=0D=0A> >> Ecrit@ietf.org=0D=0A> >> https://www1.ietf.org/mailman/listi= nfo/ecrit=0D=0A> >=0D=0A> >=0D=0A------------------------------------------= ----------------------------=0D=0A>=20=0D=0A> > --------------------------=0D= =0A> > This message is for the designated recipient only and may=0D=0A> > c= ontain privileged, proprietary, or otherwise private information.=0D=0A> > = If you have received it in error, please notify the sender=0D=0A> > immedia= tely and delete the original. Any unauthorized use of=0D=0A> > this email = is prohibited.=0D=0A> >=0D=0A----------------------------------------------= ------------------------=0D=0A>=20=0D=0A> > --------------------------=0D=0A= > > [mf2]=0D=0A> >=0D=0A>=20=0D=0A>=20=0D=0A> _____________________________= __________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> h= ttps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A>=0D=0A---------= ---------------------------------------------------------------=0D=0A> ----= --------------------=0D=0A> This message is for the designated recipient on= ly and may=0D=0A> contain privileged, proprietary, or otherwise private inf= ormation.=0D=0A> If you have received it in error, please notify the sender=0D= =0A> immediately and delete the original. Any unauthorized use of=0D=0A> t= his email is prohibited.=0D=0A>=0D=0A--------------------------------------= ----------------------------------=0D=0A> ------------------------=0D=0A> [= mf2]=0D=0A>=20=0D=0A>=20=0D=0A> ___________________________________________= ____=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ie= tf.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A>=0D=0A-----------------------= -------------------------------------------------=0D=0A--=0D=0A> ----------= ------------=0D=0A> This message is for the designated recipient only and m= ay=0D=0A> contain privileged, proprietary, or otherwise private information= =2E=0D=0A> If you have received it in error, please notify the sender=0D=0A= > immediately and delete the original. Any unauthorized use of=0D=0A> this= email is prohibited.=0D=0A>=0D=0A-----------------------------------------= -------------------------------=0D=0A--=0D=0A> ----------------------=0D=0A= > [mf2]=0D=0A>=20=0D=0A>=20=0D=0A> ________________________________________= _______=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www1= =2Eietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A=0D=0A-----------------------= -------------------------------------------------------------------------=0D= =0AThis message is for the designated recipient only and may=0D=0Acontain p= rivileged, proprietary, or otherwise private information. =20=0D=0AIf you h= ave received it in error, please notify the sender=0D=0Aimmediately and del= ete the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 15 09:03:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBSY-00039s-IR; Fri, 15 Jun 2007 09:03:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBSX-00039n-Kc for ecrit@ietf.org; Fri, 15 Jun 2007 09:03:25 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzBSW-0006H8-Tj for ecrit@ietf.org; Fri, 15 Jun 2007 09:03:25 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1HzBSO-0001Mp-78; Fri, 15 Jun 2007 08:03:17 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com><1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> < 087a01c7ae84$e1b48a10$9501a8c0@cis.neustar.com> Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Fri, 15 Jun 2007 09:03:18 -0400 Message-ID: <0b8c01c7af4d$8e22b3d0$9501a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AceuGgIUdnorn1MfT9KY7XAHcoK3nAABWk3gAAP8qIAAFRhfQAAEcxKwAC1PJ0A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: f4e722e9456ead69ba4cdd21dd3d3600 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Yeah, you agree with me. You just want to ignore the VSP validation problem. I'd like to ignore the location hiding problem, but we're stuck with both. If you come up with some way other than allowing the VSP to get coarse location and using that to validate the PSAP URI, then we can use that for option 1 or 3. So far there is no other mechanism that we can use. We can extend LoST in some way to do it, but several of us are suggesting that we postpone that work and get LoST out now. I certainly agree that the basic assumption that the access provider, LoST server and PSAP are local to one another is a good one. It's what makes option 1 or 3 possible, and gives the greatest likelihood that the system will work. I think having the VSP route is fairly easy, but "fairly" means that we need forest guides so that callers that are remote can be routed. I'd strongly prefer endpoints to route. That will be much more likely to work in all circumstances. It seems very unlikely to me that we would have a situation where the endpoint could supply location, but could not do dialstring recognition and routing. Having the VSP supply location AND route is really going to be difficult with VPNs and NATs, etc. With respect to who runs the servers, I believe you are conflating two parts of the problem: who is responsible for the data, and who runs the actual server. The PSAP is responsible for the data. It will probably run a server which anyone can use. However, I believe most access network providers will want a copy of the data in a server they run. That is the purpose of the LoST mechanisms to maintain replicas of the data. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Friday, June 15, 2007 3:32 AM > To: ecrit@ietf.org > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > Speak for yourself :) Your description of option 3 does not correlate > with my description or understanding of it. So, if there's confusion, > perhaps this is the root of it. > > In option 3 - the access network doesn't determine coarse location at > all. It doesn't concern itself with coarse location. It uses the precise > location that it determines for the device, queries the local LoST > server and provides the resultant PSAP URI directly to the device. At > this point the routing has been achieved and the device can route > directly or via the VSP. When the PSAP dereferences, it gets the precise > location from the LIS. It is exactly because the routing is achieved by > just the local elements that this option doesn't have the Achilles heel > of option 1 which requires the VSP, absolutely, to be able to find the > authoritative local LoST server. As I say, for a very remote VSP and no > functioning forest guide, it may very well not be able to. > > There's a basic principle here - emergency services are local to the > caller, the access network operator (and LIS) are local to the caller, > and the authoritative LoST server is going to most local to the caller. > The ability to reliably route the call is going to be optimal if it's > done between all these local entities who are best placed to be aware of > each other. Waiting until the call scenario has geographically diverged > to the VSP before attempting to determine routing is unnecessarily > sub-optimal. > > In option 1 - how do you propose the access network determine the > "coarse location"? I believe your proposal is that it uses the local > LoST server applicable to its area of coverage and utilize the semantics > of LoST which provide a PSAP boundary in the response. Can you confirm > that this is your proposal? Otherwise, how would you anticipate that the > access provider, who doesn't manage the PSAP boundaries after all, would > know what is the appropriate coarse location that will result in a > reliable response when LoST is queried? > > With respect to Henning's comment about LoST services being provided by > ISPs and/or VSPs, I didn't resonate with that. I would expect that LoST > is emergency services specific and it is likely to be part of some > jurisdictional function or some provider of services to that > jurisdictional function. I don't see that either ISPs or VSPs are > qualified to manage the PSAP routing information contained in a LoST > server. > > Cheers, > Martin > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, 14 June 2007 11:07 PM > To: Dawson, Martin; 'ECRIT' > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > Wait a minute, we're getting confused. > > Option 1 requires that the access network dereference to anyone with at > least coarse location suitable for emergency call routing. If the > endpoint > does routing, it will use a local LoST server which has high probability > of > having the route. If a VSP wants to verify, it needs access to a LoST > server covering the area where his customers roam. The cost is on the > carrier that is trying to hide location (which, AFAIK, is an economic > issue > all the way, the hiding is so the access network can charge for non > emergency uses of location). > > Option 3 requires that the access network dereference to anyone with at > least coarse location suitable for emergency call routing. This is > because > if the endpoint doesn't route (or more specifically, if it doesn't > recognize > emergency dialstrings, query LoST, and add the PSAP URI), but does > supply > location, then the VSP has to route, and it will have to dereference. > If > the endpoint does routing, option 3 is easy, because it will have the > correct PSAP URIs (it has to be all of them, BTW, a problem in itself). > If > a VSP wants to verify, it needs access to a LoST server covering the > area > where his customers roam. It can't use the LCP, it has to dereference > the > location, and then query LoST. > > If we supply a different mechanism for a VSP to validate, that could > change, > and it would affect 1 and 3 the same way. > > Brian > > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: Wednesday, June 13, 2007 10:56 PM > > To: ECRIT > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > Typo alert - obviously it should have said that option *1* requires > the > > VSP to work out the local LoST server in addition to the LIS needing > to > > know it. > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: Thursday, 14 June 2007 11:14 AM > > To: Henning Schulzrinne; Winterbottom, James > > Cc: ECRIT > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > BTW - as I understand option 1, it requires the LIS to query the local > > LoST server as well. At least that's how I recall Brian's original > > proposal being stated. It returns a "PSAP URI boundary" location > instead > > of the PSAP URI. > > > > I think folk are being inconsistent characterising option 3 as adding > > LoST functionality to HELD. Both proposals require the LIS to interact > > with LoST with the subsequent proxying of results to the device. > > > > If the proposition of option 1 is that it's actually the LIS that > holds > > the PSAP-relevant boundary information, then option 1 is actually much > > more like adding LoST functionality to the LIS (and adds inappropriate > > responsibility to the LIS provider). > > > > Further, given my understanding, both proposals rely on the LIS > knowing > > inherently what the appropriate local LoST server is. Option 1 just > > means that this is required *as well as* the VSP being able to reach > > that same local LoST service. > > > > Neither option requires the ISP to implement LoST, they just require > the > > ISP to know which LoST server is applicable to the local area of > > coverage. That's much more practical than expecting any arbitrary > global > > VSP being able to work that out but that is what option 3 requires *in > > addition*. > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Thursday, 14 June 2007 10:22 AM > > To: Winterbottom, James > > Cc: ECRIT > > Subject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > I assume that your discussion has nothing to do with location hiding > > at this point, but wanted to call this out just in case I'm missing > > your train of thought. > > > > I'm afraid I don't follow your logic. Unless you assume that every > > ISP deploys a LoST+HELD server, VSPs will have to have LoST servers > > with PSAP knowledge for the places their customers are likely to > > visit. This doesn't change whether HELD also gets converted into a > > LoST access protocol or not. So far, at least, VSPs seem a whole lot > > more interested in providing emergency call services than ISPs, > > presumably because their customers look to them for that service, not > > to the random hot spot operator. > > > > It's always been the model that both ISPs and VSPs (as well as third > > parties that are neither) can and should operate LoST servers, as > > that seems most likely to ensure that you get broad coverage. > > > > Henning > > > > On Jun 13, 2007, at 8:00 PM, Winterbottom, James wrote: > > > > > Henning, > > > > > > I think that your proposal only works if the VSP is able to provide > a > > > LoST server for all jurisdictions that it plans to provide service > > > for, > > > or it has to do it for everything (sounds awfully like a global VPC > to > > > me). Option 3 would be deployable from a local area to a local PSAP > > > REGARDLESS of the VSP having a LoST server that has boundary > > > information > > > for the local area I am in. It provides a global solution from the > > > get-go. > > > > > > Let's take the good old Sierra-Leone example again. > > > > > > My VSP is in Sierra-Leone and I am visiting Samoa. In option 3, I > > > get a > > > PSA P URI for the local Samoan PSAP from the local access LIS > serving > > > the area I am in, I send my call to VSP, it sends it on the PSAP. I > > > get > > > billed, call completes, we are done. I can quibble with my VSP later > > > over the 10 cent call charge if I can be bothered. > > > > > > With option 1, I send my call with location to my VSP, and one of > > > three > > > things happens. Either it has a complete forest guide network set- > > > up to > > > be able to talk to the Samoan LoST server nearest me, my call > > > fails, or > > > the VSP routes the call anyway because the end-point has done the > LoST > > > lookup. I point out, that from the VSP perspective the third > > > alternative > > > here is simply option 3 re-badged. I am sure that VSPs wouldn't > > > drop the > > > call on the floor, so choice 2 isn't an option, and choice 1 can > ONLY > > > occur if the whole network is up and running, and it doesn't > > > consist of > > > isolated copse of Forest Guides and LoST Servers. > > > > > > So to my mind, option 3 is the ONLY deployable solution in the short > > > term that will actually work universally. > > > > > > Cheers > > > James > > > > > > > > >> -----Original Message----- > > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > >> Sent: Thursday, 14 June 2007 12:58 AM > > >> To: Dawson, Martin > > >> Cc: ecrit@ietf.org > > >> Subject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives > > >> > > >> > > >> On Jun 13, 2007, at 10:54 AM, Dawson, Martin wrote: > > >> > > >>> Nobody has suggested changing LoST so this point is just a > > >>> distraction. > > >>> > > >>> > > >>> > > >>> Option 1 means that emergency calls will not be able to be routed > > >>> until the forest guide network is implemented. Option 3 means that > > >>> emergency calls will be able to be routed regardless of the state > > >>> of deployment of the forest guide. > > >>> > > >>> > > >> This is not true, at least for comparable installations. The ISP > can > > >> offer a LoST server that has the locally-relevant information. Same > > >> for the VSP. This does not require a forest guide as such. > > >> > > >> _______________________________________________ > > >> Ecrit mailing list > > >> Ecrit@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > ---------------------------------------------------------------------- > > > > > -------------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > ---------------------------------------------------------------------- > > > > > -------------------------- > > > [mf2] > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > ------------------------------------------------------------------------ > > ------------------------ > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > > ------------------------ > > [mf2] > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 15 09:19:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBht-0002lw-F0; Fri, 15 Jun 2007 09:19:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBhs-0002lq-6t for ecrit@ietf.org; Fri, 15 Jun 2007 09:19:16 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzBhr-0001AO-Fl for ecrit@ietf.org; Fri, 15 Jun 2007 09:19:16 -0400 X-SEF-Processed: 5_0_0_910__2007_06_15_08_26_55 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 15 Jun 2007 08:26:54 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jun 2007 08:19:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Fri, 15 Jun 2007 08:19:11 -0500 Message-ID: In-Reply-To: <0b8c01c7af4d$8e22b3d0$9501a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives Thread-Index: AceuGgIUdnorn1MfT9KY7XAHcoK3nAABWk3gAAP8qIAAFRhfQAAEcxKwAC1PJ0AAAMljcA== References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com><1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> < 087a01c7ae84$e1b48a10$9501a8c0@cis.neustar.com> <0b8c01c7af4d$8e22b3d0$9501a8c0@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , X-OriginalArrivalTime: 15 Jun 2007 13:19:12.0879 (UTC) FILETIME=[C3FD67F0:01C7AF4F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org OK - but there's a very significant qualitative difference that you=0D=0Aha= ven't acknowledged yet.=0D=0A=0D=0AOption 3 works without dependency on for= est guides - it can work=0D=0Astraight away. Option 1 means that emergency = calls will simply fail to=0D=0Aroute until a global and reliable forest gui= de infrastructure is in=0D=0Aplace. As I said, that's completely independen= t of the question of=0D=0Alocation hiding. Even if the LIS wasn't hiding lo= cation I'd still=0D=0Arecommend that the device acquires the PSAP URI from = the local services=0D=0Aand not just hope that the VSP can do it for it.=0D= =0A=0D=0AIf the VSP is really going to run its own copy of the LoST data fo= r the=0D=0Aarea of coverage that it cares about, then it can use any intern= al=0D=0Amechanism it likes to spot the matching PSAP URI in the database. I= t=0D=0Adoesn't have to talk LoST to its own infrastructure. Barbara pointed= out=0D=0Athat, as a VSP operator, she isn't going to be so concerned about= those=0D=0A"foreign" emergency calls anyway. I actually agree with the sen= timents=0D=0Aexpressed that a VSP should still have a mission to support em= ergency=0D=0Acalling regardless of point of origin. In the spirit of Barbar= a's=0D=0Aposition, however, perhaps it's still reasonable if they charge fo= r=0D=0Athose "foreign" emergency calls.=0D=0A=0D=0AMain point - I think the= ability to provide global emergency service as=0D=0Asoon as possible is a = better goal than saying I'll wait until I can be=0D=0Asure that global emer= gency service can be provided for free before the=0D=0Aservice can be used = at all.=0D=0A=0D=0ACheers,=0D=0AMartin=20=0D=0A=0D=0A-----Original Message-= ----=0D=0AFrom: Brian Rosen [mailto:br@brianrosen.net]=20=0D=0ASent: Friday= , 15 June 2007 11:03 PM=0D=0ATo: Dawson, Martin; ecrit@ietf.org=0D=0ASubjec= t: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A=0D=0AYeah,= you agree with me. You just want to ignore the VSP validation=0D=0Aproble= m. I'd like to ignore the location hiding problem, but we're=0D=0Astuck=0D= =0Awith both.=0D=0A=0D=0AIf you come up with some way other than allowing t= he VSP to get coarse=0D=0Alocation and using that to validate the PSAP URI,= then we can use that=0D=0Afor=0D=0Aoption 1 or 3. So far there is no othe= r mechanism that we can use. We=0D=0Acan=0D=0Aextend LoST in some way to d= o it, but several of us are suggesting that=0D=0Awe=0D=0Apostpone that work= and get LoST out now.=0D=0A=0D=0AI certainly agree that the basic assumpti= on that the access provider,=0D=0ALoST=0D=0Aserver and PSAP are local to on= e another is a good one. It's what makes=0D=0Aoption 1 or 3 possible, and = gives the greatest likelihood that the=0D=0Asystem=0D=0Awill work. I think= having the VSP route is fairly easy, but "fairly"=0D=0Ameans=0D=0Athat we = need forest guides so that callers that are remote can be=0D=0Arouted.=0D=0A= I'd strongly prefer endpoints to route. That will be much more likely=0D=0A= to=0D=0Awork in all circumstances. It seems very unlikely to me that we wo= uld=0D=0Ahave=0D=0Aa situation where the endpoint could supply location, bu= t could not do=0D=0Adialstring recognition and routing. Having the VSP sup= ply location AND=0D=0Aroute is really going to be difficult with VPNs and N= ATs, etc.=0D=0A=0D=0AWith respect to who runs the servers, I believe you ar= e conflating two=0D=0Aparts=0D=0Aof the problem: who is responsible for the= data, and who runs the actual=0D=0Aserver. The PSAP is responsible for th= e data. It will probably run a=0D=0Aserver which anyone can use. However,= I believe most access network=0D=0Aproviders will want a copy of the data = in a server they run. That is=0D=0Athe=0D=0Apurpose of the LoST mechanisms= to maintain replicas of the data.=0D=0A=0D=0ABrian=0D=0A=0D=0A=0D=0A=0D=0A= > -----Original Message-----=0D=0A> From: Dawson, Martin [mailto:Martin.Daw= son@andrew.com]=0D=0A> Sent: Friday, June 15, 2007 3:32 AM=0D=0A> To: ecrit= @ietf.org=0D=0A> Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspe= ctives=0D=0A>=20=0D=0A>=20=0D=0A> Speak for yourself :) Your description of= option 3 does not correlate=0D=0A> with my description or understanding of= it. So, if there's confusion,=0D=0A> perhaps this is the root of it.=0D=0A= >=20=0D=0A> In option 3 - the access network doesn't determine coarse locat= ion at=0D=0A> all. It doesn't concern itself with coarse location. It uses = the=0D=0Aprecise=0D=0A> location that it determines for the device, queries= the local LoST=0D=0A> server and provides the resultant PSAP URI directly = to the device. At=0D=0A> this point the routing has been achieved and the d= evice can route=0D=0A> directly or via the VSP. When the PSAP dereferences,= it gets the=0D=0Aprecise=0D=0A> location from the LIS. It is exactly becau= se the routing is achieved=0D=0Aby=0D=0A> just the local elements that this= option doesn't have the Achilles=0D=0Aheel=0D=0A> of option 1 which requir= es the VSP, absolutely, to be able to find the=0D=0A> authoritative local L= oST server. As I say, for a very remote VSP and=0D=0Ano=0D=0A> functioning = forest guide, it may very well not be able to.=0D=0A>=20=0D=0A> There's a b= asic principle here - emergency services are local to the=0D=0A> caller, th= e access network operator (and LIS) are local to the caller,=0D=0A> and the= authoritative LoST server is going to most local to the=0D=0Acaller.=0D=0A= > The ability to reliably route the call is going to be optimal if it's=0D=0A= > done between all these local entities who are best placed to be aware=0D=0A= of=0D=0A> each other. Waiting until the call scenario has geographically=0D= =0Adiverged=0D=0A> to the VSP before attempting to determine routing is unn= ecessarily=0D=0A> sub-optimal.=0D=0A>=20=0D=0A> In option 1 - how do you pr= opose the access network determine the=0D=0A> "coarse location"=3F I believ= e your proposal is that it uses the local=0D=0A> LoST server applicable to = its area of coverage and utilize the=0D=0Asemantics=0D=0A> of LoST which pr= ovide a PSAP boundary in the response. Can you confirm=0D=0A> that this is = your proposal=3F Otherwise, how would you anticipate that=0D=0Athe=0D=0A> a= ccess provider, who doesn't manage the PSAP boundaries after all,=0D=0Awoul= d=0D=0A> know what is the appropriate coarse location that will result in a=0D= =0A> reliable response when LoST is queried=3F=0D=0A>=20=0D=0A> With respec= t to Henning's comment about LoST services being provided=0D=0Aby=0D=0A> IS= Ps and/or VSPs, I didn't resonate with that. I would expect that=0D=0ALoST=0D= =0A> is emergency services specific and it is likely to be part of some=0D=0A= > jurisdictional function or some provider of services to that=0D=0A> juris= dictional function. I don't see that either ISPs or VSPs are=0D=0A> qualifi= ed to manage the PSAP routing information contained in a LoST=0D=0A> server= =2E=0D=0A>=20=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=20=0D=0A> -----Original M= essage-----=0D=0A> From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> Sent= : Thursday, 14 June 2007 11:07 PM=0D=0A> To: Dawson, Martin; 'ECRIT'=0D=0A>= Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A> =0D= =0A> Wait a minute, we're getting confused.=0D=0A>=20=0D=0A> Option 1 requi= res that the access network dereference to anyone with=0D=0Aat=0D=0A> least= coarse location suitable for emergency call routing. If the=0D=0A> endpoi= nt=0D=0A> does routing, it will use a local LoST server which has high=0D=0A= probability=0D=0A> of=0D=0A> having the route. If a VSP wants to verify, i= t needs access to a LoST=0D=0A> server covering the area where his customer= s roam. The cost is on the=0D=0A> carrier that is trying to hide location = (which, AFAIK, is an economic=0D=0A> issue=0D=0A> all the way, the hiding i= s so the access network can charge for non=0D=0A> emergency uses of locatio= n).=0D=0A>=20=0D=0A> Option 3 requires that the access network dereference = to anyone with=0D=0Aat=0D=0A> least coarse location suitable for emergency = call routing. This is=0D=0A> because=0D=0A> if the endpoint doesn't route = (or more specifically, if it doesn't=0D=0A> recognize=0D=0A> emergency dial= strings, query LoST, and add the PSAP URI), but does=0D=0A> supply=0D=0A> l= ocation, then the VSP has to route, and it will have to dereference.=0D=0A>= If=0D=0A> the endpoint does routing, option 3 is easy, because it will hav= e the=0D=0A> correct PSAP URIs (it has to be all of them, BTW, a problem in=0D= =0Aitself).=0D=0A> If=0D=0A> a VSP wants to verify, it needs access to a Lo= ST server covering the=0D=0A> area=0D=0A> where his customers roam. It can= 't use the LCP, it has to dereference=0D=0A> the=0D=0A> location, and then = query LoST.=0D=0A>=20=0D=0A> If we supply a different mechanism for a VSP t= o validate, that could=0D=0A> change,=0D=0A> and it would affect 1 and 3 th= e same way.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A> > -----Original Message= -----=0D=0A> > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A= > > Sent: Wednesday, June 13, 2007 10:56 PM=0D=0A> > To: ECRIT=0D=0A> > Sub= ject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A> >=0D=0A= > > Typo alert - obviously it should have said that option *1* requires=0D=0A= > the=0D=0A> > VSP to work out the local LoST server in addition to the LIS= needing=0D=0A> to=0D=0A> > know it.=0D=0A> >=0D=0A> > Cheers,=0D=0A> > Mar= tin=0D=0A> >=0D=0A> > -----Original Message-----=0D=0A> > From: Dawson, Mar= tin [mailto:Martin.Dawson@andrew.com]=0D=0A> > Sent: Thursday, 14 June 2007= 11:14 AM=0D=0A> > To: Henning Schulzrinne; Winterbottom, James=0D=0A> > Cc= : ECRIT=0D=0A> > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspe= ctives=0D=0A> >=0D=0A> > BTW - as I understand option 1, it requires the LI= S to query the=0D=0Alocal=0D=0A> > LoST server as well. At least that's how= I recall Brian's original=0D=0A> > proposal being stated. It returns a "PS= AP URI boundary" location=0D=0A> instead=0D=0A> > of the PSAP URI.=0D=0A> >=0D= =0A> > I think folk are being inconsistent characterising option 3 as=0D=0A= adding=0D=0A> > LoST functionality to HELD. Both proposals require the LIS = to=0D=0Ainteract=0D=0A> > with LoST with the subsequent proxying of results= to the device.=0D=0A> >=0D=0A> > If the proposition of option 1 is that it= 's actually the LIS that=0D=0A> holds=0D=0A> > the PSAP-relevant boundary i= nformation, then option 1 is actually=0D=0Amuch=0D=0A> > more like adding L= oST functionality to the LIS (and adds=0D=0Ainappropriate=0D=0A> > responsi= bility to the LIS provider).=0D=0A> >=0D=0A> > Further, given my understand= ing, both proposals rely on the LIS=0D=0A> knowing=0D=0A> > inherently what= the appropriate local LoST server is. Option 1 just=0D=0A> > means that th= is is required *as well as* the VSP being able to reach=0D=0A> > that same = local LoST service.=0D=0A> >=0D=0A> > Neither option requires the ISP to im= plement LoST, they just require=0D=0A> the=0D=0A> > ISP to know which LoST = server is applicable to the local area of=0D=0A> > coverage. That's much mo= re practical than expecting any arbitrary=0D=0A> global=0D=0A> > VSP being = able to work that out but that is what option 3 requires=0D=0A*in=0D=0A> > = addition*.=0D=0A> >=0D=0A> > Cheers,=0D=0A> > Martin=0D=0A> >=0D=0A> > ----= -Original Message-----=0D=0A> > From: Henning Schulzrinne [mailto:hgs@cs.co= lumbia.edu]=0D=0A> > Sent: Thursday, 14 June 2007 10:22 AM=0D=0A> > To: Win= terbottom, James=0D=0A> > Cc: ECRIT=0D=0A> > Subject: Re: [Ecrit] Proposals= 1 and 3 - summary of perspectives=0D=0A> >=0D=0A> > I assume that your dis= cussion has nothing to do with location hiding=0D=0A> > at this point, but = wanted to call this out just in case I'm missing=0D=0A> > your train of tho= ught.=0D=0A> >=0D=0A> > I'm afraid I don't follow your logic. Unless you as= sume that every=0D=0A> > ISP deploys a LoST+HELD server, VSPs will have to = have LoST servers=0D=0A> > with PSAP knowledge for the places their custome= rs are likely to=0D=0A> > visit. This doesn't change whether HELD also gets= converted into a=0D=0A> > LoST access protocol or not. So far, at least, V= SPs seem a whole lot=0D=0A> > more interested in providing emergency call s= ervices than ISPs,=0D=0A> > presumably because their customers look to them= for that service,=0D=0Anot=0D=0A> > to the random hot spot operator.=0D=0A= > >=0D=0A> > It's always been the model that both ISPs and VSPs (as well as= third=0D=0A> > parties that are neither) can and should operate LoST serve= rs, as=0D=0A> > that seems most likely to ensure that you get broad coverag= e.=0D=0A> >=0D=0A> > Henning=0D=0A> >=0D=0A> > On Jun 13, 2007, at 8:00 PM,= Winterbottom, James wrote:=0D=0A> >=0D=0A> > > Henning,=0D=0A> > >=0D=0A> = > > I think that your proposal only works if the VSP is able to=0D=0Aprovid= e=0D=0A> a=0D=0A> > > LoST server for all jurisdictions that it plans to pr= ovide service=0D=0A> > > for,=0D=0A> > > or it has to do it for everything = (sounds awfully like a global=0D=0AVPC=0D=0A> to=0D=0A> > > me). Option 3 w= ould be deployable from a local area to a local=0D=0APSAP=0D=0A> > > REGARD= LESS of the VSP having a LoST server that has boundary=0D=0A> > > informati= on=0D=0A> > > for the local area I am in. It provides a global solution fro= m the=0D=0A> > > get-go.=0D=0A> > >=0D=0A> > > Let's take the good old Sier= ra-Leone example again.=0D=0A> > >=0D=0A> > > My VSP is in Sierra-Leone and= I am visiting Samoa. In option 3, I=0D=0A> > > get a=0D=0A> > > PSA P URI = for the local Samoan PSAP from the local access LIS=0D=0A> serving=0D=0A> >= > the area I am in, I send my call to VSP, it sends it on the PSAP.=0D=0AI=0D= =0A> > > get=0D=0A> > > billed, call completes, we are done. I can quibble = with my VSP=0D=0Alater=0D=0A> > > over the 10 cent call charge if I can be = bothered.=0D=0A> > >=0D=0A> > > With option 1, I send my call with location= to my VSP, and one of=0D=0A> > > three=0D=0A> > > things happens. Either i= t has a complete forest guide network set-=0D=0A> > > up to=0D=0A> > > be a= ble to talk to the Samoan LoST server nearest me, my call=0D=0A> > > fails,= or=0D=0A> > > the VSP routes the call anyway because the end-point has don= e the=0D=0A> LoST=0D=0A> > > lookup. I point out, that from the VSP perspec= tive the third=0D=0A> > > alternative=0D=0A> > > here is simply option 3 re= -badged. I am sure that VSPs wouldn't=0D=0A> > > drop the=0D=0A> > > call o= n the floor, so choice 2 isn't an option, and choice 1 can=0D=0A> ONLY=0D=0A= > > > occur if the whole network is up and running, and it doesn't=0D=0A> >= > consist of=0D=0A> > > isolated copse of Forest Guides and LoST Servers.=0D= =0A> > >=0D=0A> > > So to my mind, option 3 is the ONLY deployable solution= in the=0D=0Ashort=0D=0A> > > term that will actually work universally.=0D=0A= > > >=0D=0A> > > Cheers=0D=0A> > > James=0D=0A> > >=0D=0A> > >=0D=0A> > >> = -----Original Message-----=0D=0A> > >> From: Henning Schulzrinne [mailto:hg= s@cs.columbia.edu]=0D=0A> > >> Sent: Thursday, 14 June 2007 12:58 AM=0D=0A>= > >> To: Dawson, Martin=0D=0A> > >> Cc: ecrit@ietf.org=0D=0A> > >> Subject= : Re: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A> > >>=0D=0A= > > >>=0D=0A> > >> On Jun 13, 2007, at 10:54 AM, Dawson, Martin wrote:=0D=0A= > > >>=0D=0A> > >>> Nobody has suggested changing LoST so this point is jus= t a=0D=0A> > >>> distraction.=0D=0A> > >>>=0D=0A> > >>>=0D=0A> > >>>=0D=0A>= > >>> Option 1 means that emergency calls will not be able to be=0D=0Arout= ed=0D=0A> > >>> until the forest guide network is implemented. Option 3 mea= ns=0D=0Athat=0D=0A> > >>> emergency calls will be able to be routed regardl= ess of the=0D=0Astate=0D=0A> > >>> of deployment of the forest guide.=0D=0A= > > >>>=0D=0A> > >>>=0D=0A> > >> This is not true, at least for comparable = installations. The ISP=0D=0A> can=0D=0A> > >> offer a LoST server that has = the locally-relevant information.=0D=0ASame=0D=0A> > >> for the VSP. This d= oes not require a forest guide as such.=0D=0A> > >>=0D=0A> > >> ___________= ____________________________________=0D=0A> > >> Ecrit mailing list=0D=0A> = > >> Ecrit@ietf.org=0D=0A> > >> https://www1.ietf.org/mailman/listinfo/ecri= t=0D=0A> > >=0D=0A> > >=0D=0A> --------------------------------------------= --------------------------=0D=0A> >=0D=0A> > > --------------------------=0D= =0A> > > This message is for the designated recipient only and may=0D=0A> >= > contain privileged, proprietary, or otherwise private information.=0D=0A= > > > If you have received it in error, please notify the sender=0D=0A> > >= immediately and delete the original. Any unauthorized use of=0D=0A> > > t= his email is prohibited.=0D=0A> > >=0D=0A> --------------------------------= --------------------------------------=0D=0A> >=0D=0A> > > ----------------= ----------=0D=0A> > > [mf2]=0D=0A> > >=0D=0A> >=0D=0A> >=0D=0A> > _________= ______________________________________=0D=0A> > Ecrit mailing list=0D=0A> >= Ecrit@ietf.org=0D=0A> > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A= > >=0D=0A> >=0D=0A>=0D=0A--------------------------------------------------= ----------------------=0D=0A> > ------------------------=0D=0A> > This mess= age is for the designated recipient only and may=0D=0A> > contain privilege= d, proprietary, or otherwise private information.=0D=0A> > If you have rece= ived it in error, please notify the sender=0D=0A> > immediately and delete = the original. Any unauthorized use of=0D=0A> > this email is prohibited.=0D= =0A> >=0D=0A>=0D=0A--------------------------------------------------------= ----------------=0D=0A> > ------------------------=0D=0A> > [mf2]=0D=0A> >=0D= =0A> >=0D=0A> > _______________________________________________=0D=0A> > Ec= rit mailing list=0D=0A> > Ecrit@ietf.org=0D=0A> > https://www1.ietf.org/mai= lman/listinfo/ecrit=0D=0A> >=0D=0A> >=0D=0A>=0D=0A-------------------------= -----------------------------------------------=0D=0A> --=0D=0A> > --------= --------------=0D=0A> > This message is for the designated recipient only a= nd may=0D=0A> > contain privileged, proprietary, or otherwise private infor= mation.=0D=0A> > If you have received it in error, please notify the sender=0D= =0A> > immediately and delete the original. Any unauthorized use of=0D=0A>= > this email is prohibited.=0D=0A> >=0D=0A>=0D=0A-------------------------= -----------------------------------------------=0D=0A> --=0D=0A> > --------= --------------=0D=0A> > [mf2]=0D=0A> >=0D=0A> >=0D=0A> > __________________= _____________________________=0D=0A> > Ecrit mailing list=0D=0A> > Ecrit@ie= tf.org=0D=0A> > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A= >=20=0D=0A>=0D=0A----------------------------------------------------------= --------------=0D=0A--=0D=0A> ----------------------=0D=0A> This message is= for the designated recipient only and may=0D=0A> contain privileged, propr= ietary, or otherwise private information.=0D=0A> If you have received it in= error, please notify the sender=0D=0A> immediately and delete the original= =2E Any unauthorized use of=0D=0A> this email is prohibited.=0D=0A>=0D=0A-= -----------------------------------------------------------------------=0D=0A= --=0D=0A> ----------------------=0D=0A> [mf2]=0D=0A>=20=0D=0A>=20=0D=0A> __= _____________________________________________=0D=0A> Ecrit mailing list=0D=0A= > Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 15 09:35:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBxp-0006al-1O; Fri, 15 Jun 2007 09:35:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBxn-0006Wk-9J for ecrit@ietf.org; Fri, 15 Jun 2007 09:35:43 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzBxg-0004vP-F9 for ecrit@ietf.org; Fri, 15 Jun 2007 09:35:43 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 15 Jun 2007 09:35:36 -0400 X-IronPort-AV: i="4.16,425,1175486400"; d="scan'208"; a="123713264:sNHT46088998" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5FDZaDc021807 for ; Fri, 15 Jun 2007 09:35:36 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5FDZaBe003293 for ; Fri, 15 Jun 2007 13:35:36 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 09:35:35 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 09:35:35 -0400 From: "Marc Linsner" To: "'ECRIT'" Date: Fri, 15 Jun 2007 09:35:34 -0400 Message-ID: <005c01c7af52$0da82190$220d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcevUgsd8Tbzo57DQO2YHzh0Ak/QJw== X-OriginalArrivalTime: 15 Jun 2007 13:35:35.0557 (UTC) FILETIME=[0DB62B50:01C7AF52] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1055; t=1181914536; x=1182778536; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20LoST=20Progress |Sender:=20 |To:=20=22'ECRIT'=22=20; bh=lSQ0sHVkLFuL8+v6MJ25pNOyDhKZZ1ZbLJgmZTSPzDg=; b=UYua9cnMjqB1YIn+XnW/J2xH2SICIVDgZojTm70RsDdsI8PksOs1wE87TN5sjzP1Ct69XsvI i4Ia+MXUXkJl2V8fUZZNgo2nMlhK4IQloeBuaAY/9GNX7TeXIiQlipuW; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ecrit] LoST Progress X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The ECRIT WG chairs have struggled with the progress we made on the discussions in context of the different proposals for providing 'location hiding'. First, we started our discussion on the requirements quite late in the process, LoST has already been through one working group last call. Second, there is still confusion about the requirements and the architecture surrounding 'location hiding'. We believe the requirements/solutions surrounding 'location hiding' need further discussion. Hence, in the interest of moving forward and meeting our stated (already late) milestone, we are going to ask the authors to submit LoST-06 with changes that came from the last call process. It would be great to complete the document as initially planned since it is already delayed. We do expect to see more discussions in the context of 'location hiding'. We will work on a proposal for a charter update to reflect this work and potentially other related activities. We hope everyone will support this path forward. Marc & Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 15 10:53:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzDAd-0005fr-6u; Fri, 15 Jun 2007 10:53:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzDAb-0005fk-J7 for ecrit@ietf.org; Fri, 15 Jun 2007 10:53:01 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzDAa-0005hc-MQ for ecrit@ietf.org; Fri, 15 Jun 2007 10:53:01 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1HzDAR-0005oK-8v; Fri, 15 Jun 2007 09:52:51 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com><1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> < 087a01c7ae84$e1b48a10$9501a8c0@cis.neustar.com> <0b8c01c7af4d$8e22b3d0$9501a8c0@cis.neustar.com> Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Fri, 15 Jun 2007 10:52:56 -0400 Message-ID: <0bc401c7af5c$ddd16c50$9501a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AceuGgIUdnorn1MfT9KY7XAHcoK3nAABWk3gAAP8qIAAFRhfQAAEcxKwAC1PJ0AAAMljcAADai4w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 54f716cba2c98b25bc07e094cc18394c Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Huh? I said the normal case is endpoint route. If the endpoint routes, option 1 is endpoint gets coarse location, endpoint queries LoST. No forest guide. If the VSP routes, either option needs forest guides. Option 1 and Option 3 need forest guides for the VSP to validate. I don't see why a VSP would have a replica of the LoST database, but if it did, it wouldn't cover the world. So unless it restricts nomading, it has to rely on forest guides to validate (or route). If it did have a replica, it could have some non standard way to validate for the parts of the database it had. That's not a solution, that's an optimization. I don't think you can handwave with "charge for foreign emergency calls". They aren't "foreign" to the guy making them. I think it would be illegal in the U.S. for example, although the VSP may not be subject to U.S. law in all cases. I think a reasonable strategy for a VSP attempting to validate is to arrange forest guides, and to permit emergency calls from areas where it cannot get coverage for without validation. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Friday, June 15, 2007 9:19 AM > To: Brian Rosen; ecrit@ietf.org > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > OK - but there's a very significant qualitative difference that you > haven't acknowledged yet. > > Option 3 works without dependency on forest guides - it can work > straight away. Option 1 means that emergency calls will simply fail to > route until a global and reliable forest guide infrastructure is in > place. As I said, that's completely independent of the question of > location hiding. Even if the LIS wasn't hiding location I'd still > recommend that the device acquires the PSAP URI from the local services > and not just hope that the VSP can do it for it. > > If the VSP is really going to run its own copy of the LoST data for the > area of coverage that it cares about, then it can use any internal > mechanism it likes to spot the matching PSAP URI in the database. It > doesn't have to talk LoST to its own infrastructure. Barbara pointed out > that, as a VSP operator, she isn't going to be so concerned about those > "foreign" emergency calls anyway. I actually agree with the sentiments > expressed that a VSP should still have a mission to support emergency > calling regardless of point of origin. In the spirit of Barbara's > position, however, perhaps it's still reasonable if they charge for > those "foreign" emergency calls. > > Main point - I think the ability to provide global emergency service as > soon as possible is a better goal than saying I'll wait until I can be > sure that global emergency service can be provided for free before the > service can be used at all. > > Cheers, > Martin > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, 15 June 2007 11:03 PM > To: Dawson, Martin; ecrit@ietf.org > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > Yeah, you agree with me. You just want to ignore the VSP validation > problem. I'd like to ignore the location hiding problem, but we're > stuck > with both. > > If you come up with some way other than allowing the VSP to get coarse > location and using that to validate the PSAP URI, then we can use that > for > option 1 or 3. So far there is no other mechanism that we can use. We > can > extend LoST in some way to do it, but several of us are suggesting that > we > postpone that work and get LoST out now. > > I certainly agree that the basic assumption that the access provider, > LoST > server and PSAP are local to one another is a good one. It's what makes > option 1 or 3 possible, and gives the greatest likelihood that the > system > will work. I think having the VSP route is fairly easy, but "fairly" > means > that we need forest guides so that callers that are remote can be > routed. > I'd strongly prefer endpoints to route. That will be much more likely > to > work in all circumstances. It seems very unlikely to me that we would > have > a situation where the endpoint could supply location, but could not do > dialstring recognition and routing. Having the VSP supply location AND > route is really going to be difficult with VPNs and NATs, etc. > > With respect to who runs the servers, I believe you are conflating two > parts > of the problem: who is responsible for the data, and who runs the actual > server. The PSAP is responsible for the data. It will probably run a > server which anyone can use. However, I believe most access network > providers will want a copy of the data in a server they run. That is > the > purpose of the LoST mechanisms to maintain replicas of the data. > > Brian > > > > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: Friday, June 15, 2007 3:32 AM > > To: ecrit@ietf.org > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > Speak for yourself :) Your description of option 3 does not correlate > > with my description or understanding of it. So, if there's confusion, > > perhaps this is the root of it. > > > > In option 3 - the access network doesn't determine coarse location at > > all. It doesn't concern itself with coarse location. It uses the > precise > > location that it determines for the device, queries the local LoST > > server and provides the resultant PSAP URI directly to the device. At > > this point the routing has been achieved and the device can route > > directly or via the VSP. When the PSAP dereferences, it gets the > precise > > location from the LIS. It is exactly because the routing is achieved > by > > just the local elements that this option doesn't have the Achilles > heel > > of option 1 which requires the VSP, absolutely, to be able to find the > > authoritative local LoST server. As I say, for a very remote VSP and > no > > functioning forest guide, it may very well not be able to. > > > > There's a basic principle here - emergency services are local to the > > caller, the access network operator (and LIS) are local to the caller, > > and the authoritative LoST server is going to most local to the > caller. > > The ability to reliably route the call is going to be optimal if it's > > done between all these local entities who are best placed to be aware > of > > each other. Waiting until the call scenario has geographically > diverged > > to the VSP before attempting to determine routing is unnecessarily > > sub-optimal. > > > > In option 1 - how do you propose the access network determine the > > "coarse location"? I believe your proposal is that it uses the local > > LoST server applicable to its area of coverage and utilize the > semantics > > of LoST which provide a PSAP boundary in the response. Can you confirm > > that this is your proposal? Otherwise, how would you anticipate that > the > > access provider, who doesn't manage the PSAP boundaries after all, > would > > know what is the appropriate coarse location that will result in a > > reliable response when LoST is queried? > > > > With respect to Henning's comment about LoST services being provided > by > > ISPs and/or VSPs, I didn't resonate with that. I would expect that > LoST > > is emergency services specific and it is likely to be part of some > > jurisdictional function or some provider of services to that > > jurisdictional function. I don't see that either ISPs or VSPs are > > qualified to manage the PSAP routing information contained in a LoST > > server. > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, 14 June 2007 11:07 PM > > To: Dawson, Martin; 'ECRIT' > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > Wait a minute, we're getting confused. > > > > Option 1 requires that the access network dereference to anyone with > at > > least coarse location suitable for emergency call routing. If the > > endpoint > > does routing, it will use a local LoST server which has high > probability > > of > > having the route. If a VSP wants to verify, it needs access to a LoST > > server covering the area where his customers roam. The cost is on the > > carrier that is trying to hide location (which, AFAIK, is an economic > > issue > > all the way, the hiding is so the access network can charge for non > > emergency uses of location). > > > > Option 3 requires that the access network dereference to anyone with > at > > least coarse location suitable for emergency call routing. This is > > because > > if the endpoint doesn't route (or more specifically, if it doesn't > > recognize > > emergency dialstrings, query LoST, and add the PSAP URI), but does > > supply > > location, then the VSP has to route, and it will have to dereference. > > If > > the endpoint does routing, option 3 is easy, because it will have the > > correct PSAP URIs (it has to be all of them, BTW, a problem in > itself). > > If > > a VSP wants to verify, it needs access to a LoST server covering the > > area > > where his customers roam. It can't use the LCP, it has to dereference > > the > > location, and then query LoST. > > > > If we supply a different mechanism for a VSP to validate, that could > > change, > > and it would affect 1 and 3 the same way. > > > > Brian > > > > > -----Original Message----- > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > Sent: Wednesday, June 13, 2007 10:56 PM > > > To: ECRIT > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > Typo alert - obviously it should have said that option *1* requires > > the > > > VSP to work out the local LoST server in addition to the LIS needing > > to > > > know it. > > > > > > Cheers, > > > Martin > > > > > > -----Original Message----- > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > Sent: Thursday, 14 June 2007 11:14 AM > > > To: Henning Schulzrinne; Winterbottom, James > > > Cc: ECRIT > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > BTW - as I understand option 1, it requires the LIS to query the > local > > > LoST server as well. At least that's how I recall Brian's original > > > proposal being stated. It returns a "PSAP URI boundary" location > > instead > > > of the PSAP URI. > > > > > > I think folk are being inconsistent characterising option 3 as > adding > > > LoST functionality to HELD. Both proposals require the LIS to > interact > > > with LoST with the subsequent proxying of results to the device. > > > > > > If the proposition of option 1 is that it's actually the LIS that > > holds > > > the PSAP-relevant boundary information, then option 1 is actually > much > > > more like adding LoST functionality to the LIS (and adds > inappropriate > > > responsibility to the LIS provider). > > > > > > Further, given my understanding, both proposals rely on the LIS > > knowing > > > inherently what the appropriate local LoST server is. Option 1 just > > > means that this is required *as well as* the VSP being able to reach > > > that same local LoST service. > > > > > > Neither option requires the ISP to implement LoST, they just require > > the > > > ISP to know which LoST server is applicable to the local area of > > > coverage. That's much more practical than expecting any arbitrary > > global > > > VSP being able to work that out but that is what option 3 requires > *in > > > addition*. > > > > > > Cheers, > > > Martin > > > > > > -----Original Message----- > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > Sent: Thursday, 14 June 2007 10:22 AM > > > To: Winterbottom, James > > > Cc: ECRIT > > > Subject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > I assume that your discussion has nothing to do with location hiding > > > at this point, but wanted to call this out just in case I'm missing > > > your train of thought. > > > > > > I'm afraid I don't follow your logic. Unless you assume that every > > > ISP deploys a LoST+HELD server, VSPs will have to have LoST servers > > > with PSAP knowledge for the places their customers are likely to > > > visit. This doesn't change whether HELD also gets converted into a > > > LoST access protocol or not. So far, at least, VSPs seem a whole lot > > > more interested in providing emergency call services than ISPs, > > > presumably because their customers look to them for that service, > not > > > to the random hot spot operator. > > > > > > It's always been the model that both ISPs and VSPs (as well as third > > > parties that are neither) can and should operate LoST servers, as > > > that seems most likely to ensure that you get broad coverage. > > > > > > Henning > > > > > > On Jun 13, 2007, at 8:00 PM, Winterbottom, James wrote: > > > > > > > Henning, > > > > > > > > I think that your proposal only works if the VSP is able to > provide > > a > > > > LoST server for all jurisdictions that it plans to provide service > > > > for, > > > > or it has to do it for everything (sounds awfully like a global > VPC > > to > > > > me). Option 3 would be deployable from a local area to a local > PSAP > > > > REGARDLESS of the VSP having a LoST server that has boundary > > > > information > > > > for the local area I am in. It provides a global solution from the > > > > get-go. > > > > > > > > Let's take the good old Sierra-Leone example again. > > > > > > > > My VSP is in Sierra-Leone and I am visiting Samoa. In option 3, I > > > > get a > > > > PSA P URI for the local Samoan PSAP from the local access LIS > > serving > > > > the area I am in, I send my call to VSP, it sends it on the PSAP. > I > > > > get > > > > billed, call completes, we are done. I can quibble with my VSP > later > > > > over the 10 cent call charge if I can be bothered. > > > > > > > > With option 1, I send my call with location to my VSP, and one of > > > > three > > > > things happens. Either it has a complete forest guide network set- > > > > up to > > > > be able to talk to the Samoan LoST server nearest me, my call > > > > fails, or > > > > the VSP routes the call anyway because the end-point has done the > > LoST > > > > lookup. I point out, that from the VSP perspective the third > > > > alternative > > > > here is simply option 3 re-badged. I am sure that VSPs wouldn't > > > > drop the > > > > call on the floor, so choice 2 isn't an option, and choice 1 can > > ONLY > > > > occur if the whole network is up and running, and it doesn't > > > > consist of > > > > isolated copse of Forest Guides and LoST Servers. > > > > > > > > So to my mind, option 3 is the ONLY deployable solution in the > short > > > > term that will actually work universally. > > > > > > > > Cheers > > > > James > > > > > > > > > > > >> -----Original Message----- > > > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > >> Sent: Thursday, 14 June 2007 12:58 AM > > > >> To: Dawson, Martin > > > >> Cc: ecrit@ietf.org > > > >> Subject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > >> > > > >> > > > >> On Jun 13, 2007, at 10:54 AM, Dawson, Martin wrote: > > > >> > > > >>> Nobody has suggested changing LoST so this point is just a > > > >>> distraction. > > > >>> > > > >>> > > > >>> > > > >>> Option 1 means that emergency calls will not be able to be > routed > > > >>> until the forest guide network is implemented. Option 3 means > that > > > >>> emergency calls will be able to be routed regardless of the > state > > > >>> of deployment of the forest guide. > > > >>> > > > >>> > > > >> This is not true, at least for comparable installations. The ISP > > can > > > >> offer a LoST server that has the locally-relevant information. > Same > > > >> for the VSP. This does not require a forest guide as such. > > > >> > > > >> _______________________________________________ > > > >> Ecrit mailing list > > > >> Ecrit@ietf.org > > > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > -------------------------- > > > > This message is for the designated recipient only and may > > > > contain privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > > immediately and delete the original. Any unauthorized use of > > > > this email is prohibited. > > > > > > ---------------------------------------------------------------------- > > > > > > > -------------------------- > > > > [mf2] > > > > > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > ------------------------------------------------------------------------ > > > ------------------------ > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > > > ------------------------------------------------------------------------ > > > ------------------------ > > > [mf2] > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > [mf2] > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 15 22:03:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzNdp-0000gO-Om; Fri, 15 Jun 2007 22:03:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzNdo-0000gB-BA for ecrit@ietf.org; Fri, 15 Jun 2007 22:03:52 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzNdn-0004C7-22 for ecrit@ietf.org; Fri, 15 Jun 2007 22:03:52 -0400 X-SEF-Processed: 5_0_0_910__2007_06_15_21_11_33 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 15 Jun 2007 21:11:33 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jun 2007 21:03:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] LoST Progress Date: Fri, 15 Jun 2007 21:03:48 -0500 Message-ID: In-Reply-To: <005c01c7af52$0da82190$220d0d0a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Progress Thread-Index: AcevUgsd8Tbzo57DQO2YHzh0Ak/QJwAaEv8w References: <005c01c7af52$0da82190$220d0d0a@amer.cisco.com> From: "Dawson, Martin" To: "Marc Linsner" , "ECRIT" X-OriginalArrivalTime: 16 Jun 2007 02:03:50.0755 (UTC) FILETIME=[9555BB30:01C7AFBA] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Yes - for me. That's why we're discussing options that don't need=0D=0Achan= ges to LoST as an assumed constraint.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D= =0A-----Original Message-----=0D=0AFrom: Marc Linsner [mailto:mlinsner@cisc= o.com]=20=0D=0ASent: Friday, 15 June 2007 11:36 PM=0D=0ATo: 'ECRIT'=0D=0ASu= bject: [Ecrit] LoST Progress=0D=0A=0D=0AThe ECRIT WG chairs have struggled = with the progress we made on the=0D=0Adiscussions in context of the differe= nt proposals for providing=0D=0A'location=0D=0Ahiding'.=20=0D=0A=0D=0AFirst= , we started our discussion on the requirements quite late in the=0D=0Aproc= ess, LoST has already been through one working group last call.=20=0D=0A=0D= =0ASecond, there is still confusion about the requirements and the=0D=0Aarc= hitecture=0D=0Asurrounding 'location hiding'.=0D=0A=0D=0AWe believe the req= uirements/solutions surrounding 'location hiding' need=0D=0Afurther discuss= ion. Hence, in the interest of moving forward and meeting=0D=0Aour=0D=0Asta= ted (already late) milestone, we are going to ask the authors to=0D=0Asubmi= t=0D=0ALoST-06 with changes that came from the last call process.=20=0D=0A=0D= =0AIt would be great to complete the document as initially planned since it=0D= =0Ais=0D=0Aalready delayed. We do expect to see more discussions in the con= text of=0D=0A'location hiding'. We will work on a proposal for a charter up= date to=0D=0Areflect this work and potentially other related activities.=0D= =0A=0D=0AWe hope everyone will support this path forward.=0D=0A=0D=0AMarc &= Hannes=0D=0A=0D=0A_______________________________________________=0D=0AEcr= it mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/list= info/ecrit=0D=0A=0D=0A-----------------------------------------------------= -------------------------------------------=0D=0AThis message is for the de= signated recipient only and may=0D=0Acontain privileged, proprietary, or ot= herwise private information. =20=0D=0AIf you have received it in error, ple= ase notify the sender=0D=0Aimmediately and delete the original. Any unauth= orized use of=0D=0Athis email is prohibited.=0D=0A-------------------------= -----------------------------------------------------------------------=0D=0A= [mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 15 22:25:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzNyD-0005jr-N0; Fri, 15 Jun 2007 22:24:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzNyB-0005jj-LN for ecrit@ietf.org; Fri, 15 Jun 2007 22:24:55 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzNyA-0001K8-8t for ecrit@ietf.org; Fri, 15 Jun 2007 22:24:55 -0400 X-SEF-Processed: 5_0_0_910__2007_06_15_21_32_36 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 15 Jun 2007 21:32:36 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jun 2007 21:24:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Fri, 15 Jun 2007 21:24:50 -0500 Message-ID: In-Reply-To: <0bc401c7af5c$ddd16c50$9501a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives Thread-Index: AceuGgIUdnorn1MfT9KY7XAHcoK3nAABWk3gAAP8qIAAFRhfQAAEcxKwAC1PJ0AAAMljcAADai4wABfBL7A= References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com><1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> < 087a01c7ae84$e1b48a10$9501a8c0@cis.neustar.com> <0b8c01c7af4d$8e22b3d0$9501a8c0@cis.neustar.com> <0bc401c7af5c$ddd16c50$9501a8c0@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , X-OriginalArrivalTime: 16 Jun 2007 02:24:53.0740 (UTC) FILETIME=[8621F2C0:01C7AFBD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 872695ea777a517bf5717e5acc69f8be Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org If the "normal case" is endpoint route, then there's no need to=0D=0Avalida= te, right=3F So option 3 supports this without any need to provide=0D=0Aloc= ation information. Option 1 requires it to provide location=0D=0Ainformatio= n *for all requests* since it doesn't really know this is an=0D=0Aemergency= scenario.=0D=0A=0D=0ASo - let's leave end-point route out of the discussio= n with the note=0D=0Athat option 3 satisfies the location hiding requiremen= t most=0D=0Asatisfactorily and without impact on VSP validation.=0D=0A=0D=0A= Now - for VSP route where the issue of URI validation comes up (which is=0D= =0Aalso purely a commercial issue AFAIK).=0D=0A=0D=0AA. If there's no fores= t guide in place, option 1 doesn't allow the=0D=0Aemergency call to be rout= ed at all but at least nobody will have to=0D=0Aworry about whether the non= -call should be charged for or not.=0D=0A=0D=0AB. If there's no functional = way to validate the proffered PSAP URI then=0D=0Aoption 3 requires the VSP = to decide whether to charge for the call or=0D=0Anot based on its policy in= this regard. However, the emergency call can=0D=0Aalways be made regardles= s of the availability of a functional forest=0D=0Aguide network.=0D=0A=0D=0A= Your proposition is that scenario A is preferable to scenario B. I think=0D= =0Athat is profoundly incorrect. I think it's self-evidently so.=0D=0A=0D=0A= You continually dismiss any attempt on my part to start a discussion=0D=0Aa= bout ways for a VSP to validate the PSAP URI as "hand waving". Every=0D=0Ar= easonable discussion based on a genuine desire to solve a problem=0D=0Astar= ts with those sorts of suggestions. Your approach is a=0D=0Aself-fulfilling= argument that says there's no solution therefore there=0D=0Acan't be a sol= ution, because I'm simply not going to talk about one. How=0D=0Aabout a BCP= that says that PSAP URIs should follow a specific convention=0D=0Ain terms= of domain name structure=3F The VSP would only provide emergency=0D=0Acall= tariffs to destinations that satisfy that BCP. Then somebody=0D=0Awanting = to "scam a free call" would have to make sure that the called=0D=0Aparty UR= I met that form. Not particularly useful.=0D=0A=0D=0AThere's no precedent f= or a US-based operator charging for emergency=0D=0Acalls made by subscriber= s roaming in foreign jurisdictions. PSTN calls=0D=0A(whether cellular or wi= reline) are always handled by an operator in that=0D=0Ajurisdiction. In the= case of cellular, it is handled by the roaming=0D=0Apartner in that jurisd= iction. VoIP is the first instance of the call=0D=0Aprocessing occurring at= the home provider end while the call occurs in=0D=0Athe foreign jurisdicti= on. I think it's extremely unlikely that charging=0D=0Afor emergency calls = made in foreign jurisdictions would be illegal.=0D=0AThere's only the bares= t shreds of legislation covering VoIP in any=0D=0Arespect at all at the mom= ent.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D= =0AFrom: Brian Rosen [mailto:br@brianrosen.net]=20=0D=0ASent: Saturday, 16 = June 2007 12:53 AM=0D=0ATo: Dawson, Martin; ecrit@ietf.org=0D=0ASubject: RE= : [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A=0D=0AHuh=3F I = said the normal case is endpoint route. If the endpoint routes,=0D=0Aoptio= n 1 is endpoint gets coarse location, endpoint queries LoST. No=0D=0Afores= t=0D=0Aguide.=0D=0A=0D=0AIf the VSP routes, either option needs forest guid= es.=0D=0A=0D=0AOption 1 and Option 3 need forest guides for the VSP to vali= date.=0D=0A=0D=0AI don't see why a VSP would have a replica of the LoST dat= abase, but if=0D=0Ait=0D=0Adid, it wouldn't cover the world. So unless it = restricts nomading, it=0D=0Ahas=0D=0Ato rely on forest guides to validate (= or route). If it did have a=0D=0Areplica,=0D=0Ait could have some non stan= dard way to validate for the parts of the=0D=0Adatabase it had. That's not= a solution, that's an optimization. I=0D=0Adon't=0D=0Athink you can handw= ave with "charge for foreign emergency calls". They=0D=0Aaren't "foreign" = to the guy making them. I think it would be illegal in=0D=0Athe=0D=0AU.S. = for example, although the VSP may not be subject to U.S. law in all=0D=0Aca= ses.=0D=0A=0D=0AI think a reasonable strategy for a VSP attempting to valid= ate is to=0D=0Aarrange=0D=0Aforest guides, and to permit emergency calls fr= om areas where it cannot=0D=0Aget=0D=0Acoverage for without validation. =0D= =0A=0D=0ABrian=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> F= rom: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> Sent: Friday, = June 15, 2007 9:19 AM=0D=0A> To: Brian Rosen; ecrit@ietf.org=0D=0A> Subject= : RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A>=20=0D=0A> = OK - but there's a very significant qualitative difference that you=0D=0A> = haven't acknowledged yet.=0D=0A>=20=0D=0A> Option 3 works without dependenc= y on forest guides - it can work=0D=0A> straight away. Option 1 means that = emergency calls will simply fail to=0D=0A> route until a global and reliabl= e forest guide infrastructure is in=0D=0A> place. As I said, that's complet= ely independent of the question of=0D=0A> location hiding. Even if the LIS = wasn't hiding location I'd still=0D=0A> recommend that the device acquires = the PSAP URI from the local=0D=0Aservices=0D=0A> and not just hope that the= VSP can do it for it.=0D=0A>=20=0D=0A> If the VSP is really going to run i= ts own copy of the LoST data for=0D=0Athe=0D=0A> area of coverage that it c= ares about, then it can use any internal=0D=0A> mechanism it likes to spot = the matching PSAP URI in the database. It=0D=0A> doesn't have to talk LoST = to its own infrastructure. Barbara pointed=0D=0Aout=0D=0A> that, as a VSP o= perator, she isn't going to be so concerned about=0D=0Athose=0D=0A> "foreig= n" emergency calls anyway. I actually agree with the sentiments=0D=0A> expr= essed that a VSP should still have a mission to support emergency=0D=0A> ca= lling regardless of point of origin. In the spirit of Barbara's=0D=0A> posi= tion, however, perhaps it's still reasonable if they charge for=0D=0A> thos= e "foreign" emergency calls.=0D=0A>=20=0D=0A> Main point - I think the abil= ity to provide global emergency service=0D=0Aas=0D=0A> soon as possible is = a better goal than saying I'll wait until I can be=0D=0A> sure that global = emergency service can be provided for free before the=0D=0A> service can be= used at all.=0D=0A>=20=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=20=0D=0A> -----= Original Message-----=0D=0A> From: Brian Rosen [mailto:br@brianrosen.net]=0D= =0A> Sent: Friday, 15 June 2007 11:03 PM=0D=0A> To: Dawson, Martin; ecrit@i= etf.org=0D=0A> Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspect= ives=0D=0A>=20=0D=0A> Yeah, you agree with me. You just want to ignore the= VSP validation=0D=0A> problem. I'd like to ignore the location hiding pro= blem, but we're=0D=0A> stuck=0D=0A> with both.=0D=0A>=20=0D=0A> If you come= up with some way other than allowing the VSP to get coarse=0D=0A> location= and using that to validate the PSAP URI, then we can use that=0D=0A> for=0D= =0A> option 1 or 3. So far there is no other mechanism that we can use.=0D= =0AWe=0D=0A> can=0D=0A> extend LoST in some way to do it, but several of us= are suggesting=0D=0Athat=0D=0A> we=0D=0A> postpone that work and get LoST = out now.=0D=0A>=20=0D=0A> I certainly agree that the basic assumption that = the access provider,=0D=0A> LoST=0D=0A> server and PSAP are local to one an= other is a good one. It's what=0D=0Amakes=0D=0A> option 1 or 3 possible, a= nd gives the greatest likelihood that the=0D=0A> system=0D=0A> will work. = I think having the VSP route is fairly easy, but "fairly"=0D=0A> means=0D=0A= > that we need forest guides so that callers that are remote can be=0D=0A> = routed.=0D=0A> I'd strongly prefer endpoints to route. That will be much m= ore likely=0D=0A> to=0D=0A> work in all circumstances. It seems very unlik= ely to me that we would=0D=0A> have=0D=0A> a situation where the endpoint c= ould supply location, but could not do=0D=0A> dialstring recognition and ro= uting. Having the VSP supply location=0D=0AAND=0D=0A> route is really goin= g to be difficult with VPNs and NATs, etc.=0D=0A>=20=0D=0A> With respect to= who runs the servers, I believe you are conflating two=0D=0A> parts=0D=0A>= of the problem: who is responsible for the data, and who runs the=0D=0Aact= ual=0D=0A> server. The PSAP is responsible for the data. It will probably= run a=0D=0A> server which anyone can use. However, I believe most access = network=0D=0A> providers will want a copy of the data in a server they run.= That is=0D=0A> the=0D=0A> purpose of the LoST mechanisms to maintain repl= icas of the data.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A= > > -----Original Message-----=0D=0A> > From: Dawson, Martin [mailto:Martin= =2EDawson@andrew.com]=0D=0A> > Sent: Friday, June 15, 2007 3:32 AM=0D=0A> >= To: ecrit@ietf.org=0D=0A> > Subject: RE: [Ecrit] Proposals 1 and 3 - summa= ry of perspectives=0D=0A> >=0D=0A> >=0D=0A> > Speak for yourself :) Your de= scription of option 3 does not=0D=0Acorrelate=0D=0A> > with my description = or understanding of it. So, if there's=0D=0Aconfusion,=0D=0A> > perhaps thi= s is the root of it.=0D=0A> >=0D=0A> > In option 3 - the access network doe= sn't determine coarse location=0D=0Aat=0D=0A> > all. It doesn't concern its= elf with coarse location. It uses the=0D=0A> precise=0D=0A> > location that= it determines for the device, queries the local LoST=0D=0A> > server and p= rovides the resultant PSAP URI directly to the device.=0D=0AAt=0D=0A> > thi= s point the routing has been achieved and the device can route=0D=0A> > dir= ectly or via the VSP. When the PSAP dereferences, it gets the=0D=0A> precis= e=0D=0A> > location from the LIS. It is exactly because the routing is achi= eved=0D=0A> by=0D=0A> > just the local elements that this option doesn't ha= ve the Achilles=0D=0A> heel=0D=0A> > of option 1 which requires the VSP, ab= solutely, to be able to find=0D=0Athe=0D=0A> > authoritative local LoST ser= ver. As I say, for a very remote VSP and=0D=0A> no=0D=0A> > functioning for= est guide, it may very well not be able to.=0D=0A> >=0D=0A> > There's a bas= ic principle here - emergency services are local to the=0D=0A> > caller, th= e access network operator (and LIS) are local to the=0D=0Acaller,=0D=0A> > = and the authoritative LoST server is going to most local to the=0D=0A> call= er.=0D=0A> > The ability to reliably route the call is going to be optimal = if=0D=0Ait's=0D=0A> > done between all these local entities who are best pl= aced to be=0D=0Aaware=0D=0A> of=0D=0A> > each other. Waiting until the call= scenario has geographically=0D=0A> diverged=0D=0A> > to the VSP before att= empting to determine routing is unnecessarily=0D=0A> > sub-optimal.=0D=0A> = >=0D=0A> > In option 1 - how do you propose the access network determine th= e=0D=0A> > "coarse location"=3F I believe your proposal is that it uses the= local=0D=0A> > LoST server applicable to its area of coverage and utilize = the=0D=0A> semantics=0D=0A> > of LoST which provide a PSAP boundary in the = response. Can you=0D=0Aconfirm=0D=0A> > that this is your proposal=3F Other= wise, how would you anticipate that=0D=0A> the=0D=0A> > access provider, wh= o doesn't manage the PSAP boundaries after all,=0D=0A> would=0D=0A> > know = what is the appropriate coarse location that will result in a=0D=0A> > reli= able response when LoST is queried=3F=0D=0A> >=0D=0A> > With respect to Hen= ning's comment about LoST services being provided=0D=0A> by=0D=0A> > ISPs a= nd/or VSPs, I didn't resonate with that. I would expect that=0D=0A> LoST=0D= =0A> > is emergency services specific and it is likely to be part of some=0D= =0A> > jurisdictional function or some provider of services to that=0D=0A> = > jurisdictional function. I don't see that either ISPs or VSPs are=0D=0A> = > qualified to manage the PSAP routing information contained in a LoST=0D=0A= > > server.=0D=0A> >=0D=0A> > Cheers,=0D=0A> > Martin=0D=0A> >=0D=0A> > ---= --Original Message-----=0D=0A> > From: Brian Rosen [mailto:br@brianrosen.ne= t]=0D=0A> > Sent: Thursday, 14 June 2007 11:07 PM=0D=0A> > To: Dawson, Mart= in; 'ECRIT'=0D=0A> > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of pe= rspectives=0D=0A> >=0D=0A> > Wait a minute, we're getting confused.=0D=0A> = >=0D=0A> > Option 1 requires that the access network dereference to anyone = with=0D=0A> at=0D=0A> > least coarse location suitable for emergency call r= outing. If the=0D=0A> > endpoint=0D=0A> > does routing, it will use a loca= l LoST server which has high=0D=0A> probability=0D=0A> > of=0D=0A> > having= the route. If a VSP wants to verify, it needs access to a=0D=0ALoST=0D=0A= > > server covering the area where his customers roam. The cost is on=0D=0A= the=0D=0A> > carrier that is trying to hide location (which, AFAIK, is an=0D= =0Aeconomic=0D=0A> > issue=0D=0A> > all the way, the hiding is so the acces= s network can charge for non=0D=0A> > emergency uses of location).=0D=0A> >=0D= =0A> > Option 3 requires that the access network dereference to anyone with=0D= =0A> at=0D=0A> > least coarse location suitable for emergency call routing.= This is=0D=0A> > because=0D=0A> > if the endpoint doesn't route (or more = specifically, if it doesn't=0D=0A> > recognize=0D=0A> > emergency dialstrin= gs, query LoST, and add the PSAP URI), but does=0D=0A> > supply=0D=0A> > lo= cation, then the VSP has to route, and it will have to=0D=0Adereference.=0D= =0A> > If=0D=0A> > the endpoint does routing, option 3 is easy, because it = will have=0D=0Athe=0D=0A> > correct PSAP URIs (it has to be all of them, BT= W, a problem in=0D=0A> itself).=0D=0A> > If=0D=0A> > a VSP wants to verify,= it needs access to a LoST server covering the=0D=0A> > area=0D=0A> > where= his customers roam. It can't use the LCP, it has to=0D=0Adereference=0D=0A= > > the=0D=0A> > location, and then query LoST.=0D=0A> >=0D=0A> > If we sup= ply a different mechanism for a VSP to validate, that could=0D=0A> > change= ,=0D=0A> > and it would affect 1 and 3 the same way.=0D=0A> >=0D=0A> > Bria= n=0D=0A> >=0D=0A> > > -----Original Message-----=0D=0A> > > From: Dawson, M= artin [mailto:Martin.Dawson@andrew.com]=0D=0A> > > Sent: Wednesday, June 13= , 2007 10:56 PM=0D=0A> > > To: ECRIT=0D=0A> > > Subject: RE: [Ecrit] Propos= als 1 and 3 - summary of perspectives=0D=0A> > >=0D=0A> > > Typo alert - ob= viously it should have said that option *1*=0D=0Arequires=0D=0A> > the=0D=0A= > > > VSP to work out the local LoST server in addition to the LIS=0D=0Anee= ding=0D=0A> > to=0D=0A> > > know it.=0D=0A> > >=0D=0A> > > Cheers,=0D=0A> >= > Martin=0D=0A> > >=0D=0A> > > -----Original Message-----=0D=0A> > > From:= Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> > > Sent: Thursday= , 14 June 2007 11:14 AM=0D=0A> > > To: Henning Schulzrinne; Winterbottom, J= ames=0D=0A> > > Cc: ECRIT=0D=0A> > > Subject: RE: [Ecrit] Proposals 1 and 3= - summary of perspectives=0D=0A> > >=0D=0A> > > BTW - as I understand opti= on 1, it requires the LIS to query the=0D=0A> local=0D=0A> > > LoST server = as well. At least that's how I recall Brian's original=0D=0A> > > proposal = being stated. It returns a "PSAP URI boundary" location=0D=0A> > instead=0D= =0A> > > of the PSAP URI.=0D=0A> > >=0D=0A> > > I think folk are being inco= nsistent characterising option 3 as=0D=0A> adding=0D=0A> > > LoST functiona= lity to HELD. Both proposals require the LIS to=0D=0A> interact=0D=0A> > > = with LoST with the subsequent proxying of results to the device.=0D=0A> > >=0D= =0A> > > If the proposition of option 1 is that it's actually the LIS that=0D= =0A> > holds=0D=0A> > > the PSAP-relevant boundary information, then option= 1 is actually=0D=0A> much=0D=0A> > > more like adding LoST functionality t= o the LIS (and adds=0D=0A> inappropriate=0D=0A> > > responsibility to the L= IS provider).=0D=0A> > >=0D=0A> > > Further, given my understanding, both p= roposals rely on the LIS=0D=0A> > knowing=0D=0A> > > inherently what the ap= propriate local LoST server is. Option 1=0D=0Ajust=0D=0A> > > means that th= is is required *as well as* the VSP being able to=0D=0Areach=0D=0A> > > tha= t same local LoST service.=0D=0A> > >=0D=0A> > > Neither option requires th= e ISP to implement LoST, they just=0D=0Arequire=0D=0A> > the=0D=0A> > > ISP= to know which LoST server is applicable to the local area of=0D=0A> > > co= verage. That's much more practical than expecting any arbitrary=0D=0A> > gl= obal=0D=0A> > > VSP being able to work that out but that is what option 3 r= equires=0D=0A> *in=0D=0A> > > addition*.=0D=0A> > >=0D=0A> > > Cheers,=0D=0A= > > > Martin=0D=0A> > >=0D=0A> > > -----Original Message-----=0D=0A> > > Fr= om: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A> > > Sent: Thurs= day, 14 June 2007 10:22 AM=0D=0A> > > To: Winterbottom, James=0D=0A> > > Cc= : ECRIT=0D=0A> > > Subject: Re: [Ecrit] Proposals 1 and 3 - summary of pers= pectives=0D=0A> > >=0D=0A> > > I assume that your discussion has nothing to= do with location=0D=0Ahiding=0D=0A> > > at this point, but wanted to call = this out just in case I'm=0D=0Amissing=0D=0A> > > your train of thought.=0D= =0A> > >=0D=0A> > > I'm afraid I don't follow your logic. Unless you assume= that every=0D=0A> > > ISP deploys a LoST+HELD server, VSPs will have to ha= ve LoST=0D=0Aservers=0D=0A> > > with PSAP knowledge for the places their cu= stomers are likely to=0D=0A> > > visit. This doesn't change whether HELD al= so gets converted into a=0D=0A> > > LoST access protocol or not. So far, at= least, VSPs seem a whole=0D=0Alot=0D=0A> > > more interested in providing = emergency call services than ISPs,=0D=0A> > > presumably because their cust= omers look to them for that service,=0D=0A> not=0D=0A> > > to the random ho= t spot operator.=0D=0A> > >=0D=0A> > > It's always been the model that both= ISPs and VSPs (as well as=0D=0Athird=0D=0A> > > parties that are neither) = can and should operate LoST servers, as=0D=0A> > > that seems most likely t= o ensure that you get broad coverage.=0D=0A> > >=0D=0A> > > Henning=0D=0A> = > >=0D=0A> > > On Jun 13, 2007, at 8:00 PM, Winterbottom, James wrote:=0D=0A= > > >=0D=0A> > > > Henning,=0D=0A> > > >=0D=0A> > > > I think that your pro= posal only works if the VSP is able to=0D=0A> provide=0D=0A> > a=0D=0A> > >= > LoST server for all jurisdictions that it plans to provide=0D=0Aservice=0D= =0A> > > > for,=0D=0A> > > > or it has to do it for everything (sounds awfu= lly like a global=0D=0A> VPC=0D=0A> > to=0D=0A> > > > me). Option 3 would b= e deployable from a local area to a local=0D=0A> PSAP=0D=0A> > > > REGARDLE= SS of the VSP having a LoST server that has boundary=0D=0A> > > > informati= on=0D=0A> > > > for the local area I am in. It provides a global solution f= rom=0D=0Athe=0D=0A> > > > get-go.=0D=0A> > > >=0D=0A> > > > Let's take the = good old Sierra-Leone example again.=0D=0A> > > >=0D=0A> > > > My VSP is in= Sierra-Leone and I am visiting Samoa. In option 3,=0D=0AI=0D=0A> > > > get= a=0D=0A> > > > PSA P URI for the local Samoan PSAP from the local access L= IS=0D=0A> > serving=0D=0A> > > > the area I am in, I send my call to VSP, i= t sends it on the=0D=0APSAP.=0D=0A> I=0D=0A> > > > get=0D=0A> > > > billed,= call completes, we are done. I can quibble with my VSP=0D=0A> later=0D=0A>= > > > over the 10 cent call charge if I can be bothered.=0D=0A> > > >=0D=0A= > > > > With option 1, I send my call with location to my VSP, and one=0D=0A= of=0D=0A> > > > three=0D=0A> > > > things happens. Either it has a complete= forest guide network=0D=0Aset-=0D=0A> > > > up to=0D=0A> > > > be able to = talk to the Samoan LoST server nearest me, my call=0D=0A> > > > fails, or=0D= =0A> > > > the VSP routes the call anyway because the end-point has done=0D= =0Athe=0D=0A> > LoST=0D=0A> > > > lookup. I point out, that from the VSP pe= rspective the third=0D=0A> > > > alternative=0D=0A> > > > here is simply op= tion 3 re-badged. I am sure that VSPs wouldn't=0D=0A> > > > drop the=0D=0A>= > > > call on the floor, so choice 2 isn't an option, and choice 1 can=0D=0A= > > ONLY=0D=0A> > > > occur if the whole network is up and running, and it = doesn't=0D=0A> > > > consist of=0D=0A> > > > isolated copse of Forest Guide= s and LoST Servers.=0D=0A> > > >=0D=0A> > > > So to my mind, option 3 is th= e ONLY deployable solution in the=0D=0A> short=0D=0A> > > > term that will = actually work universally.=0D=0A> > > >=0D=0A> > > > Cheers=0D=0A> > > > Ja= mes=0D=0A> > > >=0D=0A> > > >=0D=0A> > > >> -----Original Message-----=0D=0A= > > > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A> > > = >> Sent: Thursday, 14 June 2007 12:58 AM=0D=0A> > > >> To: Dawson, Martin=0D= =0A> > > >> Cc: ecrit@ietf.org=0D=0A> > > >> Subject: Re: [Ecrit] Proposals= 1 and 3 - summary of=0D=0Aperspectives=0D=0A> > > >>=0D=0A> > > >>=0D=0A> = > > >> On Jun 13, 2007, at 10:54 AM, Dawson, Martin wrote:=0D=0A> > > >>=0D= =0A> > > >>> Nobody has suggested changing LoST so this point is just a=0D=0A= > > > >>> distraction.=0D=0A> > > >>>=0D=0A> > > >>>=0D=0A> > > >>>=0D=0A> = > > >>> Option 1 means that emergency calls will not be able to be=0D=0A> r= outed=0D=0A> > > >>> until the forest guide network is implemented. Option = 3 means=0D=0A> that=0D=0A> > > >>> emergency calls will be able to be route= d regardless of the=0D=0A> state=0D=0A> > > >>> of deployment of the forest= guide.=0D=0A> > > >>>=0D=0A> > > >>>=0D=0A> > > >> This is not true, at le= ast for comparable installations. The=0D=0AISP=0D=0A> > can=0D=0A> > > >> o= ffer a LoST server that has the locally-relevant information.=0D=0A> Same=0D= =0A> > > >> for the VSP. This does not require a forest guide as such.=0D=0A= > > > >>=0D=0A> > > >> _______________________________________________=0D=0A= > > > >> Ecrit mailing list=0D=0A> > > >> Ecrit@ietf.org=0D=0A> > > >> http= s://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > > >=0D=0A> > > >=0D=0A> >=0D= =0A----------------------------------------------------------------------=0D= =0A> > >=0D=0A> > > > --------------------------=0D=0A> > > > This message = is for the designated recipient only and may=0D=0A> > > > contain privilege= d, proprietary, or otherwise private=0D=0Ainformation.=0D=0A> > > > If you = have received it in error, please notify the sender=0D=0A> > > > immediatel= y and delete the original. Any unauthorized use of=0D=0A> > > > this email= is prohibited.=0D=0A> > > >=0D=0A> >=0D=0A--------------------------------= --------------------------------------=0D=0A> > >=0D=0A> > > > ------------= --------------=0D=0A> > > > [mf2]=0D=0A> > > >=0D=0A> > >=0D=0A> > >=0D=0A>= > > _______________________________________________=0D=0A> > > Ecrit maili= ng list=0D=0A> > > Ecrit@ietf.org=0D=0A> > > https://www1.ietf.org/mailman/= listinfo/ecrit=0D=0A> > >=0D=0A> > >=0D=0A> >=0D=0A>=0D=0A-----------------= -------------------------------------------------------=0D=0A> > > --------= ----------------=0D=0A> > > This message is for the designated recipient on= ly and may=0D=0A> > > contain privileged, proprietary, or otherwise private= information.=0D=0A> > > If you have received it in error, please notify th= e sender=0D=0A> > > immediately and delete the original. Any unauthorized = use of=0D=0A> > > this email is prohibited.=0D=0A> > >=0D=0A> >=0D=0A>=0D=0A= ------------------------------------------------------------------------=0D= =0A> > > ------------------------=0D=0A> > > [mf2]=0D=0A> > >=0D=0A> > >=0D= =0A> > > _______________________________________________=0D=0A> > > Ecrit m= ailing list=0D=0A> > > Ecrit@ietf.org=0D=0A> > > https://www1.ietf.org/mail= man/listinfo/ecrit=0D=0A> > >=0D=0A> > >=0D=0A> >=0D=0A>=0D=0A-------------= -----------------------------------------------------------=0D=0A> > --=0D=0A= > > > ----------------------=0D=0A> > > This message is for the designated = recipient only and may=0D=0A> > > contain privileged, proprietary, or other= wise private information.=0D=0A> > > If you have received it in error, plea= se notify the sender=0D=0A> > > immediately and delete the original. Any u= nauthorized use of=0D=0A> > > this email is prohibited.=0D=0A> > >=0D=0A> >=0D= =0A>=0D=0A-----------------------------------------------------------------= -------=0D=0A> > --=0D=0A> > > ----------------------=0D=0A> > > [mf2]=0D=0A= > > >=0D=0A> > >=0D=0A> > > _______________________________________________=0D= =0A> > > Ecrit mailing list=0D=0A> > > Ecrit@ietf.org=0D=0A> > > https://ww= w1.ietf.org/mailman/listinfo/ecrit=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A>=0D=0A-= -----------------------------------------------------------------------=0D=0A= > --=0D=0A> > ----------------------=0D=0A> > This message is for the desig= nated recipient only and may=0D=0A> > contain privileged, proprietary, or o= therwise private information.=0D=0A> > If you have received it in error, pl= ease notify the sender=0D=0A> > immediately and delete the original. Any u= nauthorized use of=0D=0A> > this email is prohibited.=0D=0A> >=0D=0A>=0D=0A= ------------------------------------------------------------------------=0D= =0A> --=0D=0A> > ----------------------=0D=0A> > [mf2]=0D=0A> >=0D=0A> >=0D= =0A> > _______________________________________________=0D=0A> > Ecrit maili= ng list=0D=0A> > Ecrit@ietf.org=0D=0A> > https://www1.ietf.org/mailman/list= info/ecrit=0D=0A>=20=0D=0A>=20=0D=0A>=0D=0A--------------------------------= ----------------------------------------=0D=0A--=0D=0A> -------------------= ---=0D=0A> This message is for the designated recipient only and may=0D=0A>= contain privileged, proprietary, or otherwise private information.=0D=0A> = If you have received it in error, please notify the sender=0D=0A> immediate= ly and delete the original. Any unauthorized use of=0D=0A> this email is p= rohibited.=0D=0A>=0D=0A----------------------------------------------------= --------------------=0D=0A--=0D=0A> ----------------------=0D=0A> [mf2]=0D=0A=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 15 22:56:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzOSU-00073T-1f; Fri, 15 Jun 2007 22:56:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzOSS-00072v-AW; Fri, 15 Jun 2007 22:56:12 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzOSS-0008N4-1b; Fri, 15 Jun 2007 22:56:12 -0400 X-SEF-Processed: 5_0_0_910__2007_06_15_22_03_54 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 15 Jun 2007 22:03:54 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 15 Jun 2007 21:56:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] LoST Progress Date: Fri, 15 Jun 2007 21:56:09 -0500 Message-ID: In-Reply-To: <005c01c7af52$0da82190$220d0d0a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Progress Thread-Index: AcevUgsd8Tbzo57DQO2YHzh0Ak/QJwAb3oKw References: <005c01c7af52$0da82190$220d0d0a@amer.cisco.com> From: "Winterbottom, James" To: "Marc Linsner" , "ECRIT" X-OriginalArrivalTime: 16 Jun 2007 02:56:11.0594 (UTC) FILETIME=[E56BBAA0:01C7AFC1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: GEOPRIV X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Please can somebody explain to me how location hiding is an ECRIT=0D=0Achar= ter item=3F=0D=0A=0D=0AI understand that IF, it changes LoST that it may ha= ve SOME necessary=0D=0AECRIT work, but the core of everything to do with lo= cation hiding is on=0D=0Athe access side, with how an end-point gets this s= tuff. This is, without=0D=0Aany doubt in my mind a geopriv concern, as it i= s location information of=0D=0Asorts.=0D=0A=0D=0AI am totally opposed to an= y charter change with in ECRIT to pick up work=0D=0Athat has clear scope in= a different WG.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A=0D=0A> ----= -Original Message-----=0D=0A> From: Marc Linsner [mailto:mlinsner@cisco.com= ]=0D=0A> Sent: Friday, 15 June 2007 11:36 PM=0D=0A> To: 'ECRIT'=0D=0A> Subj= ect: [Ecrit] LoST Progress=0D=0A>=20=0D=0A> The ECRIT WG chairs have strugg= led with the progress we made on the=0D=0A> discussions in context of the d= ifferent proposals for providing=0D=0A'location=0D=0A> hiding'.=0D=0A>=20=0D= =0A> First, we started our discussion on the requirements quite late in the=0D= =0A> process, LoST has already been through one working group last call.=0D= =0A>=20=0D=0A> Second, there is still confusion about the requirements and = the=0D=0A> architecture=0D=0A> surrounding 'location hiding'.=0D=0A>=20=0D=0A= > We believe the requirements/solutions surrounding 'location hiding'=0D=0A= need=0D=0A> further discussion. Hence, in the interest of moving forward an= d=0D=0Ameeting=0D=0A> our=0D=0A> stated (already late) milestone, we are go= ing to ask the authors to=0D=0Asubmit=0D=0A> LoST-06 with changes that came= from the last call process.=0D=0A>=20=0D=0A> It would be great to complete= the document as initially planned since=0D=0Ait=0D=0A> is=0D=0A> already d= elayed. We do expect to see more discussions in the context=0D=0Aof=0D=0A> = 'location hiding'. We will work on a proposal for a charter update to=0D=0A= > reflect this work and potentially other related activities.=0D=0A>=20=0D=0A= > We hope everyone will support this path forward.=0D=0A>=20=0D=0A> Marc & = Hannes=0D=0A>=20=0D=0A> _______________________________________________=0D=0A= > Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mai= lman/listinfo/ecrit=0D=0A=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0AThis message is f= or the designated recipient only and may=0D=0Acontain privileged, proprieta= ry, or otherwise private information. =20=0D=0AIf you have received it in e= rror, please notify the sender=0D=0Aimmediately and delete the original. A= ny unauthorized use of=0D=0Athis email is prohibited.=0D=0A----------------= ---------------------------------------------------------------------------= -----=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jun 16 04:30:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzTg8-0007AF-EH; Sat, 16 Jun 2007 04:30:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzTg7-00079r-5m for ecrit@ietf.org; Sat, 16 Jun 2007 04:30:39 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HzTg5-0000mF-Mz for ecrit@ietf.org; Sat, 16 Jun 2007 04:30:39 -0400 Received: (qmail invoked by alias); 16 Jun 2007 08:30:34 -0000 Received: from ip-90-187-120-226.web.vodafone.de (EHLO [90.187.120.226]) [90.187.120.226] by mail.gmx.net (mp015) with SMTP; 16 Jun 2007 10:30:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18GosMVEeMGVs3eiX7fjwaX77wY8gdSbD4YsKKtuq HC4laeT25AYTie Message-ID: <46739FA3.80808@gmx.net> Date: Sat, 16 Jun 2007 10:30:27 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Geopriv] RE: [Ecrit] LoST Progress References: <005c01c7af52$0da82190$220d0d0a@amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi James, I think we shouldn't get too focused on where the work takes place. After all, we have a very good relationship with GEOPRIV and if we finally conclude that it would be better todo parts of the work in GEOPRIV than that will be fine as well. Still, the problem surfaced in ECRIT as part of the location hiding for emergency calls. That's what we care about. There may be other use cases for non-emergency services but so far we wanted to solve an emergency services problem. Right? Ciao Hannes Winterbottom, James wrote: > Please can somebody explain to me how location hiding is an ECRIT > charter item? > > I understand that IF, it changes LoST that it may have SOME necessary > ECRIT work, but the core of everything to do with location hiding is on > the access side, with how an end-point gets this stuff. This is, without > any doubt in my mind a geopriv concern, as it is location information of > sorts. > > I am totally opposed to any charter change with in ECRIT to pick up work > that has clear scope in a different WG. > > Cheers > James > > > > >> -----Original Message----- >> From: Marc Linsner [mailto:mlinsner@cisco.com] >> Sent: Friday, 15 June 2007 11:36 PM >> To: 'ECRIT' >> Subject: [Ecrit] LoST Progress >> >> The ECRIT WG chairs have struggled with the progress we made on the >> discussions in context of the different proposals for providing >> > 'location > >> hiding'. >> >> First, we started our discussion on the requirements quite late in the >> process, LoST has already been through one working group last call. >> >> Second, there is still confusion about the requirements and the >> architecture >> surrounding 'location hiding'. >> >> We believe the requirements/solutions surrounding 'location hiding' >> > need > >> further discussion. Hence, in the interest of moving forward and >> > meeting > >> our >> stated (already late) milestone, we are going to ask the authors to >> > submit > >> LoST-06 with changes that came from the last call process. >> >> It would be great to complete the document as initially planned since >> > it > >> is >> already delayed. We do expect to see more discussions in the context >> > of > >> 'location hiding'. We will work on a proposal for a charter update to >> reflect this work and potentially other related activities. >> >> We hope everyone will support this path forward. >> >> Marc & Hannes >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jun 16 11:29:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzaDU-0005Of-FL; Sat, 16 Jun 2007 11:29:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzaDT-0005NY-Mg for ecrit@ietf.org; Sat, 16 Jun 2007 11:29:31 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzaDS-0003UX-QU for ecrit@ietf.org; Sat, 16 Jun 2007 11:29:31 -0400 X-SEF-Processed: 5_0_0_910__2007_06_16_10_37_13 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sat, 16 Jun 2007 10:37:13 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 16 Jun 2007 10:29:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Sat, 16 Jun 2007 10:29:15 -0500 Message-ID: In-Reply-To: <0bc401c7af5c$ddd16c50$9501a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives Thread-Index: AceuGgIUdnorn1MfT9KY7XAHcoK3nAABWk3gAAP8qIAAFRhfQAAEcxKwAC1PJ0AAAMljcAADai4wABfBL7A= References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com><1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> < 087a01c7ae84$e1b48a10$9501a8c0@cis.neustar.com> <0b8c01c7af4d$8e22b3d0$9501a8c0@cis.neustar.com> <0bc401c7af5c$ddd16c50$9501a8c0@cis.neustar.com> From: "Dawson, Martin" To: X-OriginalArrivalTime: 16 Jun 2007 15:29:30.0446 (UTC) FILETIME=[220936E0:01C7B02B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 872695ea777a517bf5717e5acc69f8be X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org If the "normal case" is endpoint route, then there's no need to=0D=0Avalida= te, right=3F So option 3 supports this without any need to provide=0D=0Aloc= ation information. Option 1 requires it to provide location=0D=0Ainformatio= n *for all requests* since it doesn't really know this is an=0D=0Aemergency= scenario.=0D=0A=0D=0ASo - let's leave end-point route out of the discussio= n with the note=0D=0Athat option 3 satisfies the location hiding requiremen= t most=0D=0Asatisfactorily and without impact on VSP validation.=0D=0A=0D=0A= Now - for VSP route where the issue of URI validation comes up (which is=0D= =0Aalso purely a commercial issue AFAIK).=0D=0A=0D=0AA. If there's no fores= t guide in place, option 1 doesn't allow the=0D=0Aemergency call to be rout= ed at all but at least nobody will have to=0D=0Aworry about whether the non= -call should be charged for or not.=0D=0A=0D=0AB. If there's no functional = way to validate the proffered PSAP URI then=0D=0Aoption 3 requires the VSP = to decide whether to charge for the call or=0D=0Anot based on its policy in= this regard. However, the emergency call can=0D=0Aalways be made regardles= s of the availability of a functional forest=0D=0Aguide network.=0D=0A=0D=0A= Your proposition is that scenario A is preferable to scenario B. I think=0D= =0Athat is profoundly incorrect. I think it's self-evidently so.=0D=0A=0D=0A= You continually dismiss any attempt on my part to start a discussion=0D=0Aa= bout ways for a VSP to validate the PSAP URI as "hand waving". Every=0D=0Ar= easonable discussion based on a genuine desire to solve a problem=0D=0Astar= ts with those sorts of suggestions. Your approach is a=0D=0Aself-fulfilling= argument that says there's no solution therefore there=0D=0Acan't be a sol= ution, because I'm simply not going to talk about one. How=0D=0Aabout a BCP= that says that PSAP URIs should follow a specific convention=0D=0Ain terms= of domain name structure=3F The VSP would only provide emergency=0D=0Acall= tariffs to destinations that satisfy that BCP. Then somebody=0D=0Awanting = to "scam a free call" would have to make sure that the called=0D=0Aparty UR= I met that form. Not particularly useful.=0D=0A=0D=0AThere's no precedent f= or a US-based operator charging for emergency=0D=0Acalls made by subscriber= s roaming in foreign jurisdictions. PSTN calls=0D=0A(whether cellular or wi= reline) are always handled by an operator in that=0D=0Ajurisdiction. In the= case of cellular, it is handled by the roaming=0D=0Apartner in that jurisd= iction. VoIP is the first instance of the call=0D=0Aprocessing occurring at= the home provider end while the call occurs in=0D=0Athe foreign jurisdicti= on. I think it's extremely unlikely that charging=0D=0Afor emergency calls = made in foreign jurisdictions would be illegal.=0D=0AThere's only the bares= t shreds of legislation covering VoIP in any=0D=0Arespect at all at the mom= ent.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D= =0AFrom: Brian Rosen [mailto:br@brianrosen.net]=20=0D=0ASent: Saturday, 16 = June 2007 12:53 AM=0D=0ATo: Dawson, Martin; ecrit@ietf.org=0D=0ASubject: RE= : [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A=0D=0AHuh=3F I = said the normal case is endpoint route. If the endpoint routes,=0D=0Aoptio= n 1 is endpoint gets coarse location, endpoint queries LoST. No=0D=0Afores= t=0D=0Aguide.=0D=0A=0D=0AIf the VSP routes, either option needs forest guid= es.=0D=0A=0D=0AOption 1 and Option 3 need forest guides for the VSP to vali= date.=0D=0A=0D=0AI don't see why a VSP would have a replica of the LoST dat= abase, but if=0D=0Ait=0D=0Adid, it wouldn't cover the world. So unless it = restricts nomading, it=0D=0Ahas=0D=0Ato rely on forest guides to validate (= or route). If it did have a=0D=0Areplica,=0D=0Ait could have some non stan= dard way to validate for the parts of the=0D=0Adatabase it had. That's not= a solution, that's an optimization. I=0D=0Adon't=0D=0Athink you can handw= ave with "charge for foreign emergency calls". They=0D=0Aaren't "foreign" = to the guy making them. I think it would be illegal in=0D=0Athe=0D=0AU.S. = for example, although the VSP may not be subject to U.S. law in all=0D=0Aca= ses.=0D=0A=0D=0AI think a reasonable strategy for a VSP attempting to valid= ate is to=0D=0Aarrange=0D=0Aforest guides, and to permit emergency calls fr= om areas where it cannot=0D=0Aget=0D=0Acoverage for without validation. =0D= =0A=0D=0ABrian=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> F= rom: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> Sent: Friday, = June 15, 2007 9:19 AM=0D=0A> To: Brian Rosen; ecrit@ietf.org=0D=0A> Subject= : RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A>=20=0D=0A> = OK - but there's a very significant qualitative difference that you=0D=0A> = haven't acknowledged yet.=0D=0A>=20=0D=0A> Option 3 works without dependenc= y on forest guides - it can work=0D=0A> straight away. Option 1 means that = emergency calls will simply fail to=0D=0A> route until a global and reliabl= e forest guide infrastructure is in=0D=0A> place. As I said, that's complet= ely independent of the question of=0D=0A> location hiding. Even if the LIS = wasn't hiding location I'd still=0D=0A> recommend that the device acquires = the PSAP URI from the local=0D=0Aservices=0D=0A> and not just hope that the= VSP can do it for it.=0D=0A>=20=0D=0A> If the VSP is really going to run i= ts own copy of the LoST data for=0D=0Athe=0D=0A> area of coverage that it c= ares about, then it can use any internal=0D=0A> mechanism it likes to spot = the matching PSAP URI in the database. It=0D=0A> doesn't have to talk LoST = to its own infrastructure. Barbara pointed=0D=0Aout=0D=0A> that, as a VSP o= perator, she isn't going to be so concerned about=0D=0Athose=0D=0A> "foreig= n" emergency calls anyway. I actually agree with the sentiments=0D=0A> expr= essed that a VSP should still have a mission to support emergency=0D=0A> ca= lling regardless of point of origin. In the spirit of Barbara's=0D=0A> posi= tion, however, perhaps it's still reasonable if they charge for=0D=0A> thos= e "foreign" emergency calls.=0D=0A>=20=0D=0A> Main point - I think the abil= ity to provide global emergency service=0D=0Aas=0D=0A> soon as possible is = a better goal than saying I'll wait until I can be=0D=0A> sure that global = emergency service can be provided for free before the=0D=0A> service can be= used at all.=0D=0A>=20=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=20=0D=0A> -----= Original Message-----=0D=0A> From: Brian Rosen [mailto:br@brianrosen.net]=0D= =0A> Sent: Friday, 15 June 2007 11:03 PM=0D=0A> To: Dawson, Martin; ecrit@i= etf.org=0D=0A> Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspect= ives=0D=0A>=20=0D=0A> Yeah, you agree with me. You just want to ignore the= VSP validation=0D=0A> problem. I'd like to ignore the location hiding pro= blem, but we're=0D=0A> stuck=0D=0A> with both.=0D=0A>=20=0D=0A> If you come= up with some way other than allowing the VSP to get coarse=0D=0A> location= and using that to validate the PSAP URI, then we can use that=0D=0A> for=0D= =0A> option 1 or 3. So far there is no other mechanism that we can use.=0D= =0AWe=0D=0A> can=0D=0A> extend LoST in some way to do it, but several of us= are suggesting=0D=0Athat=0D=0A> we=0D=0A> postpone that work and get LoST = out now.=0D=0A>=20=0D=0A> I certainly agree that the basic assumption that = the access provider,=0D=0A> LoST=0D=0A> server and PSAP are local to one an= other is a good one. It's what=0D=0Amakes=0D=0A> option 1 or 3 possible, a= nd gives the greatest likelihood that the=0D=0A> system=0D=0A> will work. = I think having the VSP route is fairly easy, but "fairly"=0D=0A> means=0D=0A= > that we need forest guides so that callers that are remote can be=0D=0A> = routed.=0D=0A> I'd strongly prefer endpoints to route. That will be much m= ore likely=0D=0A> to=0D=0A> work in all circumstances. It seems very unlik= ely to me that we would=0D=0A> have=0D=0A> a situation where the endpoint c= ould supply location, but could not do=0D=0A> dialstring recognition and ro= uting. Having the VSP supply location=0D=0AAND=0D=0A> route is really goin= g to be difficult with VPNs and NATs, etc.=0D=0A>=20=0D=0A> With respect to= who runs the servers, I believe you are conflating two=0D=0A> parts=0D=0A>= of the problem: who is responsible for the data, and who runs the=0D=0Aact= ual=0D=0A> server. The PSAP is responsible for the data. It will probably= run a=0D=0A> server which anyone can use. However, I believe most access = network=0D=0A> providers will want a copy of the data in a server they run.= That is=0D=0A> the=0D=0A> purpose of the LoST mechanisms to maintain repl= icas of the data.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A= > > -----Original Message-----=0D=0A> > From: Dawson, Martin [mailto:Martin= =2EDawson@andrew.com]=0D=0A> > Sent: Friday, June 15, 2007 3:32 AM=0D=0A> >= To: ecrit@ietf.org=0D=0A> > Subject: RE: [Ecrit] Proposals 1 and 3 - summa= ry of perspectives=0D=0A> >=0D=0A> >=0D=0A> > Speak for yourself :) Your de= scription of option 3 does not=0D=0Acorrelate=0D=0A> > with my description = or understanding of it. So, if there's=0D=0Aconfusion,=0D=0A> > perhaps thi= s is the root of it.=0D=0A> >=0D=0A> > In option 3 - the access network doe= sn't determine coarse location=0D=0Aat=0D=0A> > all. It doesn't concern its= elf with coarse location. It uses the=0D=0A> precise=0D=0A> > location that= it determines for the device, queries the local LoST=0D=0A> > server and p= rovides the resultant PSAP URI directly to the device.=0D=0AAt=0D=0A> > thi= s point the routing has been achieved and the device can route=0D=0A> > dir= ectly or via the VSP. When the PSAP dereferences, it gets the=0D=0A> precis= e=0D=0A> > location from the LIS. It is exactly because the routing is achi= eved=0D=0A> by=0D=0A> > just the local elements that this option doesn't ha= ve the Achilles=0D=0A> heel=0D=0A> > of option 1 which requires the VSP, ab= solutely, to be able to find=0D=0Athe=0D=0A> > authoritative local LoST ser= ver. As I say, for a very remote VSP and=0D=0A> no=0D=0A> > functioning for= est guide, it may very well not be able to.=0D=0A> >=0D=0A> > There's a bas= ic principle here - emergency services are local to the=0D=0A> > caller, th= e access network operator (and LIS) are local to the=0D=0Acaller,=0D=0A> > = and the authoritative LoST server is going to most local to the=0D=0A> call= er.=0D=0A> > The ability to reliably route the call is going to be optimal = if=0D=0Ait's=0D=0A> > done between all these local entities who are best pl= aced to be=0D=0Aaware=0D=0A> of=0D=0A> > each other. Waiting until the call= scenario has geographically=0D=0A> diverged=0D=0A> > to the VSP before att= empting to determine routing is unnecessarily=0D=0A> > sub-optimal.=0D=0A> = >=0D=0A> > In option 1 - how do you propose the access network determine th= e=0D=0A> > "coarse location"=3F I believe your proposal is that it uses the= local=0D=0A> > LoST server applicable to its area of coverage and utilize = the=0D=0A> semantics=0D=0A> > of LoST which provide a PSAP boundary in the = response. Can you=0D=0Aconfirm=0D=0A> > that this is your proposal=3F Other= wise, how would you anticipate that=0D=0A> the=0D=0A> > access provider, wh= o doesn't manage the PSAP boundaries after all,=0D=0A> would=0D=0A> > know = what is the appropriate coarse location that will result in a=0D=0A> > reli= able response when LoST is queried=3F=0D=0A> >=0D=0A> > With respect to Hen= ning's comment about LoST services being provided=0D=0A> by=0D=0A> > ISPs a= nd/or VSPs, I didn't resonate with that. I would expect that=0D=0A> LoST=0D= =0A> > is emergency services specific and it is likely to be part of some=0D= =0A> > jurisdictional function or some provider of services to that=0D=0A> = > jurisdictional function. I don't see that either ISPs or VSPs are=0D=0A> = > qualified to manage the PSAP routing information contained in a LoST=0D=0A= > > server.=0D=0A> >=0D=0A> > Cheers,=0D=0A> > Martin=0D=0A> >=0D=0A> > ---= --Original Message-----=0D=0A> > From: Brian Rosen [mailto:br@brianrosen.ne= t]=0D=0A> > Sent: Thursday, 14 June 2007 11:07 PM=0D=0A> > To: Dawson, Mart= in; 'ECRIT'=0D=0A> > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of pe= rspectives=0D=0A> >=0D=0A> > Wait a minute, we're getting confused.=0D=0A> = >=0D=0A> > Option 1 requires that the access network dereference to anyone = with=0D=0A> at=0D=0A> > least coarse location suitable for emergency call r= outing. If the=0D=0A> > endpoint=0D=0A> > does routing, it will use a loca= l LoST server which has high=0D=0A> probability=0D=0A> > of=0D=0A> > having= the route. If a VSP wants to verify, it needs access to a=0D=0ALoST=0D=0A= > > server covering the area where his customers roam. The cost is on=0D=0A= the=0D=0A> > carrier that is trying to hide location (which, AFAIK, is an=0D= =0Aeconomic=0D=0A> > issue=0D=0A> > all the way, the hiding is so the acces= s network can charge for non=0D=0A> > emergency uses of location).=0D=0A> >=0D= =0A> > Option 3 requires that the access network dereference to anyone with=0D= =0A> at=0D=0A> > least coarse location suitable for emergency call routing.= This is=0D=0A> > because=0D=0A> > if the endpoint doesn't route (or more = specifically, if it doesn't=0D=0A> > recognize=0D=0A> > emergency dialstrin= gs, query LoST, and add the PSAP URI), but does=0D=0A> > supply=0D=0A> > lo= cation, then the VSP has to route, and it will have to=0D=0Adereference.=0D= =0A> > If=0D=0A> > the endpoint does routing, option 3 is easy, because it = will have=0D=0Athe=0D=0A> > correct PSAP URIs (it has to be all of them, BT= W, a problem in=0D=0A> itself).=0D=0A> > If=0D=0A> > a VSP wants to verify,= it needs access to a LoST server covering the=0D=0A> > area=0D=0A> > where= his customers roam. It can't use the LCP, it has to=0D=0Adereference=0D=0A= > > the=0D=0A> > location, and then query LoST.=0D=0A> >=0D=0A> > If we sup= ply a different mechanism for a VSP to validate, that could=0D=0A> > change= ,=0D=0A> > and it would affect 1 and 3 the same way.=0D=0A> >=0D=0A> > Bria= n=0D=0A> >=0D=0A> > > -----Original Message-----=0D=0A> > > From: Dawson, M= artin [mailto:Martin.Dawson@andrew.com]=0D=0A> > > Sent: Wednesday, June 13= , 2007 10:56 PM=0D=0A> > > To: ECRIT=0D=0A> > > Subject: RE: [Ecrit] Propos= als 1 and 3 - summary of perspectives=0D=0A> > >=0D=0A> > > Typo alert - ob= viously it should have said that option *1*=0D=0Arequires=0D=0A> > the=0D=0A= > > > VSP to work out the local LoST server in addition to the LIS=0D=0Anee= ding=0D=0A> > to=0D=0A> > > know it.=0D=0A> > >=0D=0A> > > Cheers,=0D=0A> >= > Martin=0D=0A> > >=0D=0A> > > -----Original Message-----=0D=0A> > > From:= Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> > > Sent: Thursday= , 14 June 2007 11:14 AM=0D=0A> > > To: Henning Schulzrinne; Winterbottom, J= ames=0D=0A> > > Cc: ECRIT=0D=0A> > > Subject: RE: [Ecrit] Proposals 1 and 3= - summary of perspectives=0D=0A> > >=0D=0A> > > BTW - as I understand opti= on 1, it requires the LIS to query the=0D=0A> local=0D=0A> > > LoST server = as well. At least that's how I recall Brian's original=0D=0A> > > proposal = being stated. It returns a "PSAP URI boundary" location=0D=0A> > instead=0D= =0A> > > of the PSAP URI.=0D=0A> > >=0D=0A> > > I think folk are being inco= nsistent characterising option 3 as=0D=0A> adding=0D=0A> > > LoST functiona= lity to HELD. Both proposals require the LIS to=0D=0A> interact=0D=0A> > > = with LoST with the subsequent proxying of results to the device.=0D=0A> > >=0D= =0A> > > If the proposition of option 1 is that it's actually the LIS that=0D= =0A> > holds=0D=0A> > > the PSAP-relevant boundary information, then option= 1 is actually=0D=0A> much=0D=0A> > > more like adding LoST functionality t= o the LIS (and adds=0D=0A> inappropriate=0D=0A> > > responsibility to the L= IS provider).=0D=0A> > >=0D=0A> > > Further, given my understanding, both p= roposals rely on the LIS=0D=0A> > knowing=0D=0A> > > inherently what the ap= propriate local LoST server is. Option 1=0D=0Ajust=0D=0A> > > means that th= is is required *as well as* the VSP being able to=0D=0Areach=0D=0A> > > tha= t same local LoST service.=0D=0A> > >=0D=0A> > > Neither option requires th= e ISP to implement LoST, they just=0D=0Arequire=0D=0A> > the=0D=0A> > > ISP= to know which LoST server is applicable to the local area of=0D=0A> > > co= verage. That's much more practical than expecting any arbitrary=0D=0A> > gl= obal=0D=0A> > > VSP being able to work that out but that is what option 3 r= equires=0D=0A> *in=0D=0A> > > addition*.=0D=0A> > >=0D=0A> > > Cheers,=0D=0A= > > > Martin=0D=0A> > >=0D=0A> > > -----Original Message-----=0D=0A> > > Fr= om: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A> > > Sent: Thurs= day, 14 June 2007 10:22 AM=0D=0A> > > To: Winterbottom, James=0D=0A> > > Cc= : ECRIT=0D=0A> > > Subject: Re: [Ecrit] Proposals 1 and 3 - summary of pers= pectives=0D=0A> > >=0D=0A> > > I assume that your discussion has nothing to= do with location=0D=0Ahiding=0D=0A> > > at this point, but wanted to call = this out just in case I'm=0D=0Amissing=0D=0A> > > your train of thought.=0D= =0A> > >=0D=0A> > > I'm afraid I don't follow your logic. Unless you assume= that every=0D=0A> > > ISP deploys a LoST+HELD server, VSPs will have to ha= ve LoST=0D=0Aservers=0D=0A> > > with PSAP knowledge for the places their cu= stomers are likely to=0D=0A> > > visit. This doesn't change whether HELD al= so gets converted into a=0D=0A> > > LoST access protocol or not. So far, at= least, VSPs seem a whole=0D=0Alot=0D=0A> > > more interested in providing = emergency call services than ISPs,=0D=0A> > > presumably because their cust= omers look to them for that service,=0D=0A> not=0D=0A> > > to the random ho= t spot operator.=0D=0A> > >=0D=0A> > > It's always been the model that both= ISPs and VSPs (as well as=0D=0Athird=0D=0A> > > parties that are neither) = can and should operate LoST servers, as=0D=0A> > > that seems most likely t= o ensure that you get broad coverage.=0D=0A> > >=0D=0A> > > Henning=0D=0A> = > >=0D=0A> > > On Jun 13, 2007, at 8:00 PM, Winterbottom, James wrote:=0D=0A= > > >=0D=0A> > > > Henning,=0D=0A> > > >=0D=0A> > > > I think that your pro= posal only works if the VSP is able to=0D=0A> provide=0D=0A> > a=0D=0A> > >= > LoST server for all jurisdictions that it plans to provide=0D=0Aservice=0D= =0A> > > > for,=0D=0A> > > > or it has to do it for everything (sounds awfu= lly like a global=0D=0A> VPC=0D=0A> > to=0D=0A> > > > me). Option 3 would b= e deployable from a local area to a local=0D=0A> PSAP=0D=0A> > > > REGARDLE= SS of the VSP having a LoST server that has boundary=0D=0A> > > > informati= on=0D=0A> > > > for the local area I am in. It provides a global solution f= rom=0D=0Athe=0D=0A> > > > get-go.=0D=0A> > > >=0D=0A> > > > Let's take the = good old Sierra-Leone example again.=0D=0A> > > >=0D=0A> > > > My VSP is in= Sierra-Leone and I am visiting Samoa. In option 3,=0D=0AI=0D=0A> > > > get= a=0D=0A> > > > PSA P URI for the local Samoan PSAP from the local access L= IS=0D=0A> > serving=0D=0A> > > > the area I am in, I send my call to VSP, i= t sends it on the=0D=0APSAP.=0D=0A> I=0D=0A> > > > get=0D=0A> > > > billed,= call completes, we are done. I can quibble with my VSP=0D=0A> later=0D=0A>= > > > over the 10 cent call charge if I can be bothered.=0D=0A> > > >=0D=0A= > > > > With option 1, I send my call with location to my VSP, and one=0D=0A= of=0D=0A> > > > three=0D=0A> > > > things happens. Either it has a complete= forest guide network=0D=0Aset-=0D=0A> > > > up to=0D=0A> > > > be able to = talk to the Samoan LoST server nearest me, my call=0D=0A> > > > fails, or=0D= =0A> > > > the VSP routes the call anyway because the end-point has done=0D= =0Athe=0D=0A> > LoST=0D=0A> > > > lookup. I point out, that from the VSP pe= rspective the third=0D=0A> > > > alternative=0D=0A> > > > here is simply op= tion 3 re-badged. I am sure that VSPs wouldn't=0D=0A> > > > drop the=0D=0A>= > > > call on the floor, so choice 2 isn't an option, and choice 1 can=0D=0A= > > ONLY=0D=0A> > > > occur if the whole network is up and running, and it = doesn't=0D=0A> > > > consist of=0D=0A> > > > isolated copse of Forest Guide= s and LoST Servers.=0D=0A> > > >=0D=0A> > > > So to my mind, option 3 is th= e ONLY deployable solution in the=0D=0A> short=0D=0A> > > > term that will = actually work universally.=0D=0A> > > >=0D=0A> > > > Cheers=0D=0A> > > > Ja= mes=0D=0A> > > >=0D=0A> > > >=0D=0A> > > >> -----Original Message-----=0D=0A= > > > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A> > > = >> Sent: Thursday, 14 June 2007 12:58 AM=0D=0A> > > >> To: Dawson, Martin=0D= =0A> > > >> Cc: ecrit@ietf.org=0D=0A> > > >> Subject: Re: [Ecrit] Proposals= 1 and 3 - summary of=0D=0Aperspectives=0D=0A> > > >>=0D=0A> > > >>=0D=0A> = > > >> On Jun 13, 2007, at 10:54 AM, Dawson, Martin wrote:=0D=0A> > > >>=0D= =0A> > > >>> Nobody has suggested changing LoST so this point is just a=0D=0A= > > > >>> distraction.=0D=0A> > > >>>=0D=0A> > > >>>=0D=0A> > > >>>=0D=0A> = > > >>> Option 1 means that emergency calls will not be able to be=0D=0A> r= outed=0D=0A> > > >>> until the forest guide network is implemented. Option = 3 means=0D=0A> that=0D=0A> > > >>> emergency calls will be able to be route= d regardless of the=0D=0A> state=0D=0A> > > >>> of deployment of the forest= guide.=0D=0A> > > >>>=0D=0A> > > >>>=0D=0A> > > >> This is not true, at le= ast for comparable installations. The=0D=0AISP=0D=0A> > can=0D=0A> > > >> o= ffer a LoST server that has the locally-relevant information.=0D=0A> Same=0D= =0A> > > >> for the VSP. This does not require a forest guide as such.=0D=0A= > > > >>=0D=0A> > > >> _______________________________________________=0D=0A= > > > >> Ecrit mailing list=0D=0A> > > >> Ecrit@ietf.org=0D=0A> > > >> http= s://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > > >=0D=0A> > > >=0D=0A> >=0D= =0A----------------------------------------------------------------------=0D= =0A> > >=0D=0A> > > > --------------------------=0D=0A> > > > This message = is for the designated recipient only and may=0D=0A> > > > contain privilege= d, proprietary, or otherwise private=0D=0Ainformation.=0D=0A> > > > If you = have received it in error, please notify the sender=0D=0A> > > > immediatel= y and delete the original. Any unauthorized use of=0D=0A> > > > this email= is prohibited.=0D=0A> > > >=0D=0A> >=0D=0A--------------------------------= --------------------------------------=0D=0A> > >=0D=0A> > > > ------------= --------------=0D=0A> > > > [mf2]=0D=0A> > > >=0D=0A> > >=0D=0A> > >=0D=0A>= > > _______________________________________________=0D=0A> > > Ecrit maili= ng list=0D=0A> > > Ecrit@ietf.org=0D=0A> > > https://www1.ietf.org/mailman/= listinfo/ecrit=0D=0A> > >=0D=0A> > >=0D=0A> >=0D=0A>=0D=0A-----------------= -------------------------------------------------------=0D=0A> > > --------= ----------------=0D=0A> > > This message is for the designated recipient on= ly and may=0D=0A> > > contain privileged, proprietary, or otherwise private= information.=0D=0A> > > If you have received it in error, please notify th= e sender=0D=0A> > > immediately and delete the original. Any unauthorized = use of=0D=0A> > > this email is prohibited.=0D=0A> > >=0D=0A> >=0D=0A>=0D=0A= ------------------------------------------------------------------------=0D= =0A> > > ------------------------=0D=0A> > > [mf2]=0D=0A> > >=0D=0A> > >=0D= =0A> > > _______________________________________________=0D=0A> > > Ecrit m= ailing list=0D=0A> > > Ecrit@ietf.org=0D=0A> > > https://www1.ietf.org/mail= man/listinfo/ecrit=0D=0A> > >=0D=0A> > >=0D=0A> >=0D=0A>=0D=0A-------------= -----------------------------------------------------------=0D=0A> > --=0D=0A= > > > ----------------------=0D=0A> > > This message is for the designated = recipient only and may=0D=0A> > > contain privileged, proprietary, or other= wise private information.=0D=0A> > > If you have received it in error, plea= se notify the sender=0D=0A> > > immediately and delete the original. Any u= nauthorized use of=0D=0A> > > this email is prohibited.=0D=0A> > >=0D=0A> >=0D= =0A>=0D=0A-----------------------------------------------------------------= -------=0D=0A> > --=0D=0A> > > ----------------------=0D=0A> > > [mf2]=0D=0A= > > >=0D=0A> > >=0D=0A> > > _______________________________________________=0D= =0A> > > Ecrit mailing list=0D=0A> > > Ecrit@ietf.org=0D=0A> > > https://ww= w1.ietf.org/mailman/listinfo/ecrit=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A>=0D=0A-= -----------------------------------------------------------------------=0D=0A= > --=0D=0A> > ----------------------=0D=0A> > This message is for the desig= nated recipient only and may=0D=0A> > contain privileged, proprietary, or o= therwise private information.=0D=0A> > If you have received it in error, pl= ease notify the sender=0D=0A> > immediately and delete the original. Any u= nauthorized use of=0D=0A> > this email is prohibited.=0D=0A> >=0D=0A>=0D=0A= ------------------------------------------------------------------------=0D= =0A> --=0D=0A> > ----------------------=0D=0A> > [mf2]=0D=0A> >=0D=0A> >=0D= =0A> > _______________________________________________=0D=0A> > Ecrit maili= ng list=0D=0A> > Ecrit@ietf.org=0D=0A> > https://www1.ietf.org/mailman/list= info/ecrit=0D=0A>=20=0D=0A>=20=0D=0A>=0D=0A--------------------------------= ----------------------------------------=0D=0A--=0D=0A> -------------------= ---=0D=0A> This message is for the designated recipient only and may=0D=0A>= contain privileged, proprietary, or otherwise private information.=0D=0A> = If you have received it in error, please notify the sender=0D=0A> immediate= ly and delete the original. Any unauthorized use of=0D=0A> this email is p= rohibited.=0D=0A>=0D=0A----------------------------------------------------= --------------------=0D=0A--=0D=0A> ----------------------=0D=0A> [mf2]=0D=0A=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jun 16 14:33:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzd5u-0001TG-U8; Sat, 16 Jun 2007 14:33:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzd5t-0001PU-2p; Sat, 16 Jun 2007 14:33:53 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzd5s-0008BH-Ni; Sat, 16 Jun 2007 14:33:53 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 16 Jun 2007 14:33:53 -0400 X-IronPort-AV: i="4.16,430,1175486400"; d="scan'208"; a="123808319:sNHT52838604" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5GIXqoG002941; Sat, 16 Jun 2007 14:33:52 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5GIXq5f017866; Sat, 16 Jun 2007 18:33:52 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Jun 2007 14:33:52 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Jun 2007 14:33:51 -0400 From: "Marc Linsner" To: "'Winterbottom, James'" , "'ECRIT'" Subject: RE: [Ecrit] LoST Progress Date: Sat, 16 Jun 2007 14:33:50 -0400 Message-ID: <003901c7b044$e2fec2c0$220d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: AcevUgsd8Tbzo57DQO2YHzh0Ak/QJwAb3oKwAB/ndaA= In-Reply-To: X-OriginalArrivalTime: 16 Jun 2007 18:33:51.0730 (UTC) FILETIME=[E3133520:01C7B044] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3684; t=1182018832; x=1182882832; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20LoST=20Progress |Sender:=20 |To:=20=22'Winterbottom, =20James'=22=20, =0 A=20=20=20=20=20=20=20=20=22'ECRIT'=22=20; bh=1QMYviFf27pvZMJT+ig+uZ6F9CZjHZdf1DyZzM0nROI=; b=X3ul3mbnS9qoYSqQIRfOkLEILbmMBglE1kyIzhJVVDzlKukd8kbPChudH0ptw+EhTmhL4WvJ U/qjk52NBb6bx2wF4+MeasyIg6HC4Kx6S144hLhy2W74e3WUO08we7sw; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: 'GEOPRIV' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org James, >From the ECRIT charter: "The group will show how the availability of location data and call routing information at different steps in session setup would enable communication between a user and a relevant emergency response center." ECRIT's current charter/milestones include creating architecture documents describing VoIP emergency calling. To that end, 'availability of location data' includes 'location hiding' and will either be dealt with by ECRIT and/or GeoPriv and possibly others. The very issue of location hiding arose from ECRIT's architecture documents when Deutsche Telekom (DT) stated they would not support the IETF emergency calling architecture due to our requirement to advise the end-host and/or non-DT-VSP of DT provided location data. So, yes, ECRIT will deal with 'location hiding'. -Marc- > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Friday, June 15, 2007 10:56 PM > To: Marc Linsner; ECRIT > Cc: GEOPRIV > Subject: RE: [Ecrit] LoST Progress > > Please can somebody explain to me how location hiding is an > ECRIT charter item? > > I understand that IF, it changes LoST that it may have SOME > necessary ECRIT work, but the core of everything to do with > location hiding is on the access side, with how an end-point > gets this stuff. This is, without any doubt in my mind a > geopriv concern, as it is location information of sorts. > > I am totally opposed to any charter change with in ECRIT to > pick up work that has clear scope in a different WG. > > Cheers > James > > > > > -----Original Message----- > > From: Marc Linsner [mailto:mlinsner@cisco.com] > > Sent: Friday, 15 June 2007 11:36 PM > > To: 'ECRIT' > > Subject: [Ecrit] LoST Progress > > > > The ECRIT WG chairs have struggled with the progress we made on the > > discussions in context of the different proposals for providing > 'location > > hiding'. > > > > First, we started our discussion on the requirements quite > late in the > > process, LoST has already been through one working group last call. > > > > Second, there is still confusion about the requirements and the > > architecture surrounding 'location hiding'. > > > > We believe the requirements/solutions surrounding 'location hiding' > need > > further discussion. Hence, in the interest of moving forward and > meeting > > our > > stated (already late) milestone, we are going to ask the authors to > submit > > LoST-06 with changes that came from the last call process. > > > > It would be great to complete the document as initially > planned since > it > > is > > already delayed. We do expect to see more discussions in the context > of > > 'location hiding'. We will work on a proposal for a charter > update to > > reflect this work and potentially other related activities. > > > > We hope everyone will support this path forward. > > > > Marc & Hannes > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jun 16 16:40:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzf4i-0000vy-1h; Sat, 16 Jun 2007 16:40:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzf4g-0000vt-JG for ecrit@ietf.org; Sat, 16 Jun 2007 16:40:46 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hzf4e-0001wi-HE for ecrit@ietf.org; Sat, 16 Jun 2007 16:40:46 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1Hzf4R-0006as-5s; Sat, 16 Jun 2007 15:40:31 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com><1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> < 087a01c7ae84$e1b48a10$9501a8c0@cis.neustar.com> <0b8c01c7af4d$8e22b3d0$9501a8c0@cis.neustar.com> <0bc401c7af5c$ddd16c50$9501a8c0@cis.neustar.com> Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Sat, 16 Jun 2007 16:40:40 -0400 Message-ID: <0e4801c7b056$9c15d120$9501a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AceuGgIUdnorn1MfT9KY7XAHcoK3nAABWk3gAAP8qIAAFRhfQAAEcxKwAC1PJ0AAAMljcAADai4wABfBL7AAJiIUMA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 93a9b7eb0f4b3b8a49c341eb77478ab2 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Maybe we're getting ourselves confused with the word "validation". An endpoint would like to know that the location it got was a valid location. It can do that by querying LoST. If it's given a reference and a PSAP URI, it can't check it unless it does a dereference, gets some kind of location and queries LoST. So option 3 leaves the endpoint not being able to validate. If an endpoint routes, some VSPs want to validate that the route the endpoint handed it is valid. That's another form of validation. Option 3 doesn't provide any way for the VSP to validate that the PSAP URI in the Request URI is a bona fide PSAP URI. Yes, option 1 requires the LIS to provide a coarse location value for anyone that asks. It provides a way for the endpoint to validate that the location results in a route to a PSAP, and it provides a way for a VSP to validate that the URI is a valid PSAP URI. If there is no forest guide, the local LoST server is still highly likely to have the route for the location the endpoint is given. Everything except VSP validation works without forest guides. PSAP validation requires that the VSP have access to the same LoST data that the endpoint does. In the general case, that means forest guides. There are lots of cases where the VSP could reasonably get access to the LoST data where MOST of his subscribers are, but most is not all, and forest guides would be required. With option 3, the LIS is highly likely to have access to LoST data covering it's service area, so no forest guides are needed. The endpoint can't validate, so whether there are forest guides is moot. Same for VSP validation. There is a document that describes how forest guides work. There has been discussion on this document, which has had more than one revision. The only words describing how option 3 might provide validation are email discussions of reverse lookups, and one email from you that said "The ability to verify a destination PSAP URI as a valid emergency URI could be supported by reference to a relatively static table maintained by global cooperation." That is the extent of the discussion. There is no text. I more or less understand how reverse lookup would work. I think we would have a significant piece of work to add that to the current LoST document. I think everyone agrees that now is not the time to do that work. If you accept VSP validation as a requirement, which I do (reluctantly, but then I accept location hiding as a requirement just as reluctantly) then we need something that doesn't need a change to LoST with the impact of reverse lookups. You have suggested something. I think it won't work, but it's hard to criticize because there is no text. In your latest email, you have another idea, which I find equally unlikely to work, but again, there is no text to criticize. I don't really like option 3, but I could live with it if there was a way for the VSP to validate. I'd really like a way for the endpoint to validate, but that is not quite so important. I don't want to hold up LoST. So, I'd say, in the absence of a reasonable alternative, with text that has had some level of review, and has at least a reasonable amount of consensus, that we document option 1 (in phonebcp) and keep working. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Friday, June 15, 2007 10:25 PM > To: Brian Rosen; ecrit@ietf.org > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > If the "normal case" is endpoint route, then there's no need to > validate, right? So option 3 supports this without any need to provide > location information. Option 1 requires it to provide location > information *for all requests* since it doesn't really know this is an > emergency scenario. > > So - let's leave end-point route out of the discussion with the note > that option 3 satisfies the location hiding requirement most > satisfactorily and without impact on VSP validation. > > Now - for VSP route where the issue of URI validation comes up (which is > also purely a commercial issue AFAIK). > > A. If there's no forest guide in place, option 1 doesn't allow the > emergency call to be routed at all but at least nobody will have to > worry about whether the non-call should be charged for or not. > > B. If there's no functional way to validate the proffered PSAP URI then > option 3 requires the VSP to decide whether to charge for the call or > not based on its policy in this regard. However, the emergency call can > always be made regardless of the availability of a functional forest > guide network. > > Your proposition is that scenario A is preferable to scenario B. I think > that is profoundly incorrect. I think it's self-evidently so. > > You continually dismiss any attempt on my part to start a discussion > about ways for a VSP to validate the PSAP URI as "hand waving". Every > reasonable discussion based on a genuine desire to solve a problem > starts with those sorts of suggestions. Your approach is a > self-fulfilling argument that says there's no solution therefore there > can't be a solution, because I'm simply not going to talk about one. How > about a BCP that says that PSAP URIs should follow a specific convention > in terms of domain name structure? The VSP would only provide emergency > call tariffs to destinations that satisfy that BCP. Then somebody > wanting to "scam a free call" would have to make sure that the called > party URI met that form. Not particularly useful. > > There's no precedent for a US-based operator charging for emergency > calls made by subscribers roaming in foreign jurisdictions. PSTN calls > (whether cellular or wireline) are always handled by an operator in that > jurisdiction. In the case of cellular, it is handled by the roaming > partner in that jurisdiction. VoIP is the first instance of the call > processing occurring at the home provider end while the call occurs in > the foreign jurisdiction. I think it's extremely unlikely that charging > for emergency calls made in foreign jurisdictions would be illegal. > There's only the barest shreds of legislation covering VoIP in any > respect at all at the moment. > > Cheers, > Martin > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Saturday, 16 June 2007 12:53 AM > To: Dawson, Martin; ecrit@ietf.org > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > Huh? I said the normal case is endpoint route. If the endpoint routes, > option 1 is endpoint gets coarse location, endpoint queries LoST. No > forest > guide. > > If the VSP routes, either option needs forest guides. > > Option 1 and Option 3 need forest guides for the VSP to validate. > > I don't see why a VSP would have a replica of the LoST database, but if > it > did, it wouldn't cover the world. So unless it restricts nomading, it > has > to rely on forest guides to validate (or route). If it did have a > replica, > it could have some non standard way to validate for the parts of the > database it had. That's not a solution, that's an optimization. I > don't > think you can handwave with "charge for foreign emergency calls". They > aren't "foreign" to the guy making them. I think it would be illegal in > the > U.S. for example, although the VSP may not be subject to U.S. law in all > cases. > > I think a reasonable strategy for a VSP attempting to validate is to > arrange > forest guides, and to permit emergency calls from areas where it cannot > get > coverage for without validation. > > Brian > > > > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: Friday, June 15, 2007 9:19 AM > > To: Brian Rosen; ecrit@ietf.org > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > OK - but there's a very significant qualitative difference that you > > haven't acknowledged yet. > > > > Option 3 works without dependency on forest guides - it can work > > straight away. Option 1 means that emergency calls will simply fail to > > route until a global and reliable forest guide infrastructure is in > > place. As I said, that's completely independent of the question of > > location hiding. Even if the LIS wasn't hiding location I'd still > > recommend that the device acquires the PSAP URI from the local > services > > and not just hope that the VSP can do it for it. > > > > If the VSP is really going to run its own copy of the LoST data for > the > > area of coverage that it cares about, then it can use any internal > > mechanism it likes to spot the matching PSAP URI in the database. It > > doesn't have to talk LoST to its own infrastructure. Barbara pointed > out > > that, as a VSP operator, she isn't going to be so concerned about > those > > "foreign" emergency calls anyway. I actually agree with the sentiments > > expressed that a VSP should still have a mission to support emergency > > calling regardless of point of origin. In the spirit of Barbara's > > position, however, perhaps it's still reasonable if they charge for > > those "foreign" emergency calls. > > > > Main point - I think the ability to provide global emergency service > as > > soon as possible is a better goal than saying I'll wait until I can be > > sure that global emergency service can be provided for free before the > > service can be used at all. > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, 15 June 2007 11:03 PM > > To: Dawson, Martin; ecrit@ietf.org > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > Yeah, you agree with me. You just want to ignore the VSP validation > > problem. I'd like to ignore the location hiding problem, but we're > > stuck > > with both. > > > > If you come up with some way other than allowing the VSP to get coarse > > location and using that to validate the PSAP URI, then we can use that > > for > > option 1 or 3. So far there is no other mechanism that we can use. > We > > can > > extend LoST in some way to do it, but several of us are suggesting > that > > we > > postpone that work and get LoST out now. > > > > I certainly agree that the basic assumption that the access provider, > > LoST > > server and PSAP are local to one another is a good one. It's what > makes > > option 1 or 3 possible, and gives the greatest likelihood that the > > system > > will work. I think having the VSP route is fairly easy, but "fairly" > > means > > that we need forest guides so that callers that are remote can be > > routed. > > I'd strongly prefer endpoints to route. That will be much more likely > > to > > work in all circumstances. It seems very unlikely to me that we would > > have > > a situation where the endpoint could supply location, but could not do > > dialstring recognition and routing. Having the VSP supply location > AND > > route is really going to be difficult with VPNs and NATs, etc. > > > > With respect to who runs the servers, I believe you are conflating two > > parts > > of the problem: who is responsible for the data, and who runs the > actual > > server. The PSAP is responsible for the data. It will probably run a > > server which anyone can use. However, I believe most access network > > providers will want a copy of the data in a server they run. That is > > the > > purpose of the LoST mechanisms to maintain replicas of the data. > > > > Brian > > > > > > > > > -----Original Message----- > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > Sent: Friday, June 15, 2007 3:32 AM > > > To: ecrit@ietf.org > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > > > > Speak for yourself :) Your description of option 3 does not > correlate > > > with my description or understanding of it. So, if there's > confusion, > > > perhaps this is the root of it. > > > > > > In option 3 - the access network doesn't determine coarse location > at > > > all. It doesn't concern itself with coarse location. It uses the > > precise > > > location that it determines for the device, queries the local LoST > > > server and provides the resultant PSAP URI directly to the device. > At > > > this point the routing has been achieved and the device can route > > > directly or via the VSP. When the PSAP dereferences, it gets the > > precise > > > location from the LIS. It is exactly because the routing is achieved > > by > > > just the local elements that this option doesn't have the Achilles > > heel > > > of option 1 which requires the VSP, absolutely, to be able to find > the > > > authoritative local LoST server. As I say, for a very remote VSP and > > no > > > functioning forest guide, it may very well not be able to. > > > > > > There's a basic principle here - emergency services are local to the > > > caller, the access network operator (and LIS) are local to the > caller, > > > and the authoritative LoST server is going to most local to the > > caller. > > > The ability to reliably route the call is going to be optimal if > it's > > > done between all these local entities who are best placed to be > aware > > of > > > each other. Waiting until the call scenario has geographically > > diverged > > > to the VSP before attempting to determine routing is unnecessarily > > > sub-optimal. > > > > > > In option 1 - how do you propose the access network determine the > > > "coarse location"? I believe your proposal is that it uses the local > > > LoST server applicable to its area of coverage and utilize the > > semantics > > > of LoST which provide a PSAP boundary in the response. Can you > confirm > > > that this is your proposal? Otherwise, how would you anticipate that > > the > > > access provider, who doesn't manage the PSAP boundaries after all, > > would > > > know what is the appropriate coarse location that will result in a > > > reliable response when LoST is queried? > > > > > > With respect to Henning's comment about LoST services being provided > > by > > > ISPs and/or VSPs, I didn't resonate with that. I would expect that > > LoST > > > is emergency services specific and it is likely to be part of some > > > jurisdictional function or some provider of services to that > > > jurisdictional function. I don't see that either ISPs or VSPs are > > > qualified to manage the PSAP routing information contained in a LoST > > > server. > > > > > > Cheers, > > > Martin > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, 14 June 2007 11:07 PM > > > To: Dawson, Martin; 'ECRIT' > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > Wait a minute, we're getting confused. > > > > > > Option 1 requires that the access network dereference to anyone with > > at > > > least coarse location suitable for emergency call routing. If the > > > endpoint > > > does routing, it will use a local LoST server which has high > > probability > > > of > > > having the route. If a VSP wants to verify, it needs access to a > LoST > > > server covering the area where his customers roam. The cost is on > the > > > carrier that is trying to hide location (which, AFAIK, is an > economic > > > issue > > > all the way, the hiding is so the access network can charge for non > > > emergency uses of location). > > > > > > Option 3 requires that the access network dereference to anyone with > > at > > > least coarse location suitable for emergency call routing. This is > > > because > > > if the endpoint doesn't route (or more specifically, if it doesn't > > > recognize > > > emergency dialstrings, query LoST, and add the PSAP URI), but does > > > supply > > > location, then the VSP has to route, and it will have to > dereference. > > > If > > > the endpoint does routing, option 3 is easy, because it will have > the > > > correct PSAP URIs (it has to be all of them, BTW, a problem in > > itself). > > > If > > > a VSP wants to verify, it needs access to a LoST server covering the > > > area > > > where his customers roam. It can't use the LCP, it has to > dereference > > > the > > > location, and then query LoST. > > > > > > If we supply a different mechanism for a VSP to validate, that could > > > change, > > > and it would affect 1 and 3 the same way. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > Sent: Wednesday, June 13, 2007 10:56 PM > > > > To: ECRIT > > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > > > Typo alert - obviously it should have said that option *1* > requires > > > the > > > > VSP to work out the local LoST server in addition to the LIS > needing > > > to > > > > know it. > > > > > > > > Cheers, > > > > Martin > > > > > > > > -----Original Message----- > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > Sent: Thursday, 14 June 2007 11:14 AM > > > > To: Henning Schulzrinne; Winterbottom, James > > > > Cc: ECRIT > > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > > > BTW - as I understand option 1, it requires the LIS to query the > > local > > > > LoST server as well. At least that's how I recall Brian's original > > > > proposal being stated. It returns a "PSAP URI boundary" location > > > instead > > > > of the PSAP URI. > > > > > > > > I think folk are being inconsistent characterising option 3 as > > adding > > > > LoST functionality to HELD. Both proposals require the LIS to > > interact > > > > with LoST with the subsequent proxying of results to the device. > > > > > > > > If the proposition of option 1 is that it's actually the LIS that > > > holds > > > > the PSAP-relevant boundary information, then option 1 is actually > > much > > > > more like adding LoST functionality to the LIS (and adds > > inappropriate > > > > responsibility to the LIS provider). > > > > > > > > Further, given my understanding, both proposals rely on the LIS > > > knowing > > > > inherently what the appropriate local LoST server is. Option 1 > just > > > > means that this is required *as well as* the VSP being able to > reach > > > > that same local LoST service. > > > > > > > > Neither option requires the ISP to implement LoST, they just > require > > > the > > > > ISP to know which LoST server is applicable to the local area of > > > > coverage. That's much more practical than expecting any arbitrary > > > global > > > > VSP being able to work that out but that is what option 3 requires > > *in > > > > addition*. > > > > > > > > Cheers, > > > > Martin > > > > > > > > -----Original Message----- > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > Sent: Thursday, 14 June 2007 10:22 AM > > > > To: Winterbottom, James > > > > Cc: ECRIT > > > > Subject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > > > I assume that your discussion has nothing to do with location > hiding > > > > at this point, but wanted to call this out just in case I'm > missing > > > > your train of thought. > > > > > > > > I'm afraid I don't follow your logic. Unless you assume that every > > > > ISP deploys a LoST+HELD server, VSPs will have to have LoST > servers > > > > with PSAP knowledge for the places their customers are likely to > > > > visit. This doesn't change whether HELD also gets converted into a > > > > LoST access protocol or not. So far, at least, VSPs seem a whole > lot > > > > more interested in providing emergency call services than ISPs, > > > > presumably because their customers look to them for that service, > > not > > > > to the random hot spot operator. > > > > > > > > It's always been the model that both ISPs and VSPs (as well as > third > > > > parties that are neither) can and should operate LoST servers, as > > > > that seems most likely to ensure that you get broad coverage. > > > > > > > > Henning > > > > > > > > On Jun 13, 2007, at 8:00 PM, Winterbottom, James wrote: > > > > > > > > > Henning, > > > > > > > > > > I think that your proposal only works if the VSP is able to > > provide > > > a > > > > > LoST server for all jurisdictions that it plans to provide > service > > > > > for, > > > > > or it has to do it for everything (sounds awfully like a global > > VPC > > > to > > > > > me). Option 3 would be deployable from a local area to a local > > PSAP > > > > > REGARDLESS of the VSP having a LoST server that has boundary > > > > > information > > > > > for the local area I am in. It provides a global solution from > the > > > > > get-go. > > > > > > > > > > Let's take the good old Sierra-Leone example again. > > > > > > > > > > My VSP is in Sierra-Leone and I am visiting Samoa. In option 3, > I > > > > > get a > > > > > PSA P URI for the local Samoan PSAP from the local access LIS > > > serving > > > > > the area I am in, I send my call to VSP, it sends it on the > PSAP. > > I > > > > > get > > > > > billed, call completes, we are done. I can quibble with my VSP > > later > > > > > over the 10 cent call charge if I can be bothered. > > > > > > > > > > With option 1, I send my call with location to my VSP, and one > of > > > > > three > > > > > things happens. Either it has a complete forest guide network > set- > > > > > up to > > > > > be able to talk to the Samoan LoST server nearest me, my call > > > > > fails, or > > > > > the VSP routes the call anyway because the end-point has done > the > > > LoST > > > > > lookup. I point out, that from the VSP perspective the third > > > > > alternative > > > > > here is simply option 3 re-badged. I am sure that VSPs wouldn't > > > > > drop the > > > > > call on the floor, so choice 2 isn't an option, and choice 1 can > > > ONLY > > > > > occur if the whole network is up and running, and it doesn't > > > > > consist of > > > > > isolated copse of Forest Guides and LoST Servers. > > > > > > > > > > So to my mind, option 3 is the ONLY deployable solution in the > > short > > > > > term that will actually work universally. > > > > > > > > > > Cheers > > > > > James > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > >> Sent: Thursday, 14 June 2007 12:58 AM > > > > >> To: Dawson, Martin > > > > >> Cc: ecrit@ietf.org > > > > >> Subject: Re: [Ecrit] Proposals 1 and 3 - summary of > perspectives > > > > >> > > > > >> > > > > >> On Jun 13, 2007, at 10:54 AM, Dawson, Martin wrote: > > > > >> > > > > >>> Nobody has suggested changing LoST so this point is just a > > > > >>> distraction. > > > > >>> > > > > >>> > > > > >>> > > > > >>> Option 1 means that emergency calls will not be able to be > > routed > > > > >>> until the forest guide network is implemented. Option 3 means > > that > > > > >>> emergency calls will be able to be routed regardless of the > > state > > > > >>> of deployment of the forest guide. > > > > >>> > > > > >>> > > > > >> This is not true, at least for comparable installations. The > ISP > > > can > > > > >> offer a LoST server that has the locally-relevant information. > > Same > > > > >> for the VSP. This does not require a forest guide as such. > > > > >> > > > > >> _______________________________________________ > > > > >> Ecrit mailing list > > > > >> Ecrit@ietf.org > > > > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > -------------------------- > > > > > This message is for the designated recipient only and may > > > > > contain privileged, proprietary, or otherwise private > information. > > > > > If you have received it in error, please notify the sender > > > > > immediately and delete the original. Any unauthorized use of > > > > > this email is prohibited. > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > -------------------------- > > > > > [mf2] > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > ------------------------ > > > > This message is for the designated recipient only and may > > > > contain privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > > immediately and delete the original. Any unauthorized use of > > > > this email is prohibited. > > > > > > > > > > ------------------------------------------------------------------------ > > > > ------------------------ > > > > [mf2] > > > > > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > ---------------------- > > > > This message is for the designated recipient only and may > > > > contain privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > > immediately and delete the original. Any unauthorized use of > > > > this email is prohibited. > > > > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > ---------------------- > > > > [mf2] > > > > > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > [mf2] > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jun 16 23:24:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzlNi-0001R8-8j; Sat, 16 Jun 2007 23:24:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzlNh-0001Pl-F5 for ecrit@ietf.org; Sat, 16 Jun 2007 23:24:49 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzlNg-0002Xn-97 for ecrit@ietf.org; Sat, 16 Jun 2007 23:24:49 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5H3ObaB010994 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 16 Jun 2007 23:24:43 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <4670601B.2020508@ntt-at.com> References: <4670601B.2020508@ntt-at.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <923B8285-28FC-40E4-999A-F029AD142F0A@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] What is left for LoST before IETF Last Call? Date: Sat, 16 Jun 2007 23:24:09 -0400 To: Shida Schubert , ECRIT X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Since this is needed for any request with a location object, I added a token to the location object, as in element for responses. Henning On Jun 13, 2007, at 5:22 PM, Shida Schubert wrote: > > Ted; > > needs to be modified to return location > profile > type. As discussed a month ago, currently client can't match the > location used > in the request to the location used to resolve the mapping. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jun 17 19:34:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I04G2-00039J-93; Sun, 17 Jun 2007 19:34:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I04G1-00039E-12 for ecrit@ietf.org; Sun, 17 Jun 2007 19:34:09 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I04Fx-00065b-TK for ecrit@ietf.org; Sun, 17 Jun 2007 19:34:09 -0400 X-SEF-Processed: 5_0_0_910__2007_06_17_18_41_43 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 17 Jun 2007 18:41:43 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 17 Jun 2007 18:33:58 -0500 Content-class: urn:content-classes:message Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 17 Jun 2007 18:33:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <0e4801c7b056$9c15d120$9501a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives Thread-Index: AceuGgIUdnorn1MfT9KY7XAHcoK3nAABWk3gAAP8qIAAFRhfQAAEcxKwAC1PJ0AAAMljcAADai4wABfBL7AAJiIUMAA467og References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com><1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu>< 087a01c7ae84$e1b48a10$9501a8c0@cis.neustar.com><0b8c01c7af4d$8e22b3d0$9501a8c0@cis.neustar.com><0bc401c7af5c$ddd16c50$9501a8c0@cis.neustar.com> <0e4801c7b056$9c15d120$9501a8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Dawson, Martin" , X-OriginalArrivalTime: 17 Jun 2007 23:33:58.0576 (UTC) FILETIME=[FA679B00:01C7B137] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8e9fbe727bc2159b431d624c595c1eab Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I would like to bring your attention to something that Barbara Stark has=0D= =0Asaid a couple of times now.=0D=0A=0D=0AIf the calls are national, then t= he potential list (even if there is one=0D=0Aper PSAP in the USA) is not un= manageable. So that can easily be kept=0D=0Alocal. There is no mandate, or = precedent for allowing free international=0D=0Aemergency calls, so why set = one=3F=0D=0A=0D=0AIn short, this problem quite simply doesn't warrant a com= plex reverse=0D=0ALoST lookup at this point. We are talking a sub 1% of eme= rgency calls,=0D=0Aand these calls won't fail, they will just be billed unt= il the=0D=0Adestination URI can be confirmed. What happened to the old 90% = rule,=0D=0Athis problem isn't even in the 1% category!=0D=0A=0D=0ACheers=0D= =0AJames=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> F= rom: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> Sent: Sunday, 17 June 20= 07 6:41 AM=0D=0A> To: Dawson, Martin; ecrit@ietf.org=0D=0A> Subject: RE: [E= crit] Proposals 1 and 3 - summary of perspectives=0D=0A>=20=0D=0A> Maybe we= 're getting ourselves confused with the word "validation". An=0D=0A> endpo= int would like to know that the location it got was a valid=0D=0Alocation.=0D= =0A> It can do that by querying LoST. If it's given a reference and a PSAP=0D= =0A> URI,=0D=0A> it can't check it unless it does a dereference, gets some = kind of=0D=0Alocation=0D=0A> and queries LoST. So option 3 leaves the endp= oint not being able to=0D=0A> validate.=0D=0A>=20=0D=0A> If an endpoint rou= tes, some VSPs want to validate that the route the=0D=0A> endpoint handed i= t is valid. That's another form of validation.=0D=0AOption 3=0D=0A> doesn'= t provide any way for the VSP to validate that the PSAP URI in=0D=0Athe=0D=0A= > Request URI is a bona fide PSAP URI.=0D=0A>=20=0D=0A> Yes, option 1 requi= res the LIS to provide a coarse location value for=0D=0A> anyone=0D=0A> tha= t asks. It provides a way for the endpoint to validate that the=0D=0A> loc= ation=0D=0A> results in a route to a PSAP, and it provides a way for a VSP = to=0D=0Avalidate=0D=0A> that the URI is a valid PSAP URI.=0D=0A>=20=0D=0A> = If there is no forest guide, the local LoST server is still highly=0D=0Alik= ely=0D=0A> to=0D=0A> have the route for the location the endpoint is given.= Everything=0D=0Aexcept=0D=0A> VSP validation works without forest guides.= PSAP validation requires=0D=0Athat=0D=0A> the VSP have access to the same= LoST data that the endpoint does. In=0D=0Athe=0D=0A> general case, that m= eans forest guides. There are lots of cases where=0D=0Athe=0D=0A> VSP coul= d reasonably get access to the LoST data where MOST of his=0D=0A> subscribe= rs are, but most is not all, and forest guides would be=0D=0Arequired.=0D=0A= >=20=0D=0A> With option 3, the LIS is highly likely to have access to LoST = data=0D=0A> covering=0D=0A> it's service area, so no forest guides are need= ed. The endpoint can't=0D=0A> validate, so whether there are forest guides= is moot. Same for VSP=0D=0A> validation.=0D=0A>=20=0D=0A> There is a docu= ment that describes how forest guides work. There has=0D=0Abeen=0D=0A> dis= cussion on this document, which has had more than one revision.=0D=0AThe=0D= =0A> only=0D=0A> words describing how option 3 might provide validation are= email=0D=0A> discussions=0D=0A> of reverse lookups, and one email from you= that said "The ability to=0D=0A> verify=0D=0A> a destination PSAP URI as a= valid emergency URI could be supported by=0D=0A> reference to a relatively= static table maintained by global=0D=0Acooperation."=0D=0A> That is the ex= tent of the discussion. There is no text.=0D=0A>=20=0D=0A> I more or less = understand how reverse lookup would work. I think we=0D=0Awould=0D=0A> hav= e a significant piece of work to add that to the current LoST=0D=0Adocument= =2E=0D=0A> I think everyone agrees that now is not the time to do that work= =2E If=0D=0Ayou=0D=0A> accept VSP validation as a requirement, which I do = (reluctantly, but=0D=0Athen=0D=0A> I=0D=0A> accept location hiding as a req= uirement just as reluctantly) then we=0D=0Aneed=0D=0A> something that doesn= 't need a change to LoST with the impact of=0D=0Areverse=0D=0A> lookups. Y= ou have suggested something. I think it won't work, but=0D=0Ait's=0D=0A> h= ard to criticize because there is no text. In your latest email, you=0D=0A= > have=0D=0A> another idea, which I find equally unlikely to work, but agai= n, there=0D=0Ais=0D=0A> no=0D=0A> text to criticize.=0D=0A>=20=0D=0A> I don= 't really like option 3, but I could live with it if there was a=0D=0Away=0D= =0A> for the VSP to validate. I'd really like a way for the endpoint to=0D= =0A> validate, but that is not quite so important. I don't want to hold up=0D= =0A> LoST.=0D=0A>=20=0D=0A> So, I'd say, in the absence of a reasonable alt= ernative, with text=0D=0Athat=0D=0A> has=0D=0A> had some level of review, a= nd has at least a reasonable amount of=0D=0A> consensus,=0D=0A> that we doc= ument option 1 (in phonebcp) and keep working.=0D=0A>=20=0D=0A> Brian=0D=0A= > > -----Original Message-----=0D=0A> > From: Dawson, Martin [mailto:Martin= =2EDawson@andrew.com]=0D=0A> > Sent: Friday, June 15, 2007 10:25 PM=0D=0A> = > To: Brian Rosen; ecrit@ietf.org=0D=0A> > Subject: RE: [Ecrit] Proposals 1= and 3 - summary of perspectives=0D=0A> >=0D=0A> > If the "normal case" is = endpoint route, then there's no need to=0D=0A> > validate, right=3F So opti= on 3 supports this without any need to=0D=0Aprovide=0D=0A> > location infor= mation. Option 1 requires it to provide location=0D=0A> > information *for = all requests* since it doesn't really know this is=0D=0Aan=0D=0A> > emergen= cy scenario.=0D=0A> >=0D=0A> > So - let's leave end-point route out of the = discussion with the note=0D=0A> > that option 3 satisfies the location hidi= ng requirement most=0D=0A> > satisfactorily and without impact on VSP valid= ation.=0D=0A> >=0D=0A> > Now - for VSP route where the issue of URI validat= ion comes up=0D=0A(which is=0D=0A> > also purely a commercial issue AFAIK).=0D= =0A> >=0D=0A> > A. If there's no forest guide in place, option 1 doesn't al= low the=0D=0A> > emergency call to be routed at all but at least nobody wil= l have to=0D=0A> > worry about whether the non-call should be charged for o= r not.=0D=0A> >=0D=0A> > B. If there's no functional way to validate the pr= offered PSAP URI=0D=0Athen=0D=0A> > option 3 requires the VSP to decide whe= ther to charge for the call=0D=0Aor=0D=0A> > not based on its policy in thi= s regard. However, the emergency call=0D=0Acan=0D=0A> > always be made rega= rdless of the availability of a functional forest=0D=0A> > guide network.=0D= =0A> >=0D=0A> > Your proposition is that scenario A is preferable to scenar= io B. I=0D=0Athink=0D=0A> > that is profoundly incorrect. I think it's self= -evidently so.=0D=0A> >=0D=0A> > You continually dismiss any attempt on my = part to start a discussion=0D=0A> > about ways for a VSP to validate the PS= AP URI as "hand waving".=0D=0AEvery=0D=0A> > reasonable discussion based on= a genuine desire to solve a problem=0D=0A> > starts with those sorts of su= ggestions. Your approach is a=0D=0A> > self-fulfilling argument that says t= here's no solution therefore=0D=0Athere=0D=0A> > can't be a solution, becau= se I'm simply not going to talk about one.=0D=0AHow=0D=0A> > about a BCP th= at says that PSAP URIs should follow a specific=0D=0Aconvention=0D=0A> > in= terms of domain name structure=3F The VSP would only provide=0D=0Aemergenc= y=0D=0A> > call tariffs to destinations that satisfy that BCP. Then somebod= y=0D=0A> > wanting to "scam a free call" would have to make sure that the=0D= =0Acalled=0D=0A> > party URI met that form. Not particularly useful.=0D=0A>= >=0D=0A> > There's no precedent for a US-based operator charging for emerg= ency=0D=0A> > calls made by subscribers roaming in foreign jurisdictions. P= STN=0D=0Acalls=0D=0A> > (whether cellular or wireline) are always handled b= y an operator in=0D=0Athat=0D=0A> > jurisdiction. In the case of cellular, = it is handled by the roaming=0D=0A> > partner in that jurisdiction. VoIP is= the first instance of the call=0D=0A> > processing occurring at the home p= rovider end while the call occurs=0D=0Ain=0D=0A> > the foreign jurisdiction= =2E I think it's extremely unlikely that=0D=0Acharging=0D=0A> > for emergen= cy calls made in foreign jurisdictions would be illegal.=0D=0A> > There's o= nly the barest shreds of legislation covering VoIP in any=0D=0A> > respect = at all at the moment.=0D=0A> >=0D=0A> > Cheers,=0D=0A> > Martin=0D=0A> >=0D= =0A> > -----Original Message-----=0D=0A> > From: Brian Rosen [mailto:br@bri= anrosen.net]=0D=0A> > Sent: Saturday, 16 June 2007 12:53 AM=0D=0A> > To: Da= wson, Martin; ecrit@ietf.org=0D=0A> > Subject: RE: [Ecrit] Proposals 1 and = 3 - summary of perspectives=0D=0A> >=0D=0A> > Huh=3F I said the normal cas= e is endpoint route. If the endpoint=0D=0Aroutes,=0D=0A> > option 1 is end= point gets coarse location, endpoint queries LoST.=0D=0ANo=0D=0A> > forest=0D= =0A> > guide.=0D=0A> >=0D=0A> > If the VSP routes, either option needs fore= st guides.=0D=0A> >=0D=0A> > Option 1 and Option 3 need forest guides for t= he VSP to validate.=0D=0A> >=0D=0A> > I don't see why a VSP would have a re= plica of the LoST database, but=0D=0Aif=0D=0A> > it=0D=0A> > did, it wouldn= 't cover the world. So unless it restricts nomading,=0D=0Ait=0D=0A> > has=0D= =0A> > to rely on forest guides to validate (or route). If it did have a=0D= =0A> > replica,=0D=0A> > it could have some non standard way to validate fo= r the parts of the=0D=0A> > database it had. That's not a solution, that's= an optimization. I=0D=0A> > don't=0D=0A> > think you can handwave with "c= harge for foreign emergency calls".=0D=0AThey=0D=0A> > aren't "foreign" to = the guy making them. I think it would be=0D=0Aillegal in=0D=0A> > the=0D=0A= > > U.S. for example, although the VSP may not be subject to U.S. law in=0D= =0Aall=0D=0A> > cases.=0D=0A> >=0D=0A> > I think a reasonable strategy for = a VSP attempting to validate is to=0D=0A> > arrange=0D=0A> > forest guides,= and to permit emergency calls from areas where it=0D=0Acannot=0D=0A> > get=0D= =0A> > coverage for without validation.=0D=0A> >=0D=0A> > Brian=0D=0A> >=0D= =0A> >=0D=0A> >=0D=0A> > > -----Original Message-----=0D=0A> > > From: Daws= on, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> > > Sent: Friday, June = 15, 2007 9:19 AM=0D=0A> > > To: Brian Rosen; ecrit@ietf.org=0D=0A> > > Subj= ect: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A> > >=0D=0A= > > > OK - but there's a very significant qualitative difference that=0D=0A= you=0D=0A> > > haven't acknowledged yet.=0D=0A> > >=0D=0A> > > Option 3 wor= ks without dependency on forest guides - it can work=0D=0A> > > straight aw= ay. Option 1 means that emergency calls will simply=0D=0Afail to=0D=0A> > >= route until a global and reliable forest guide infrastructure is=0D=0Ain=0D= =0A> > > place. As I said, that's completely independent of the question of=0D= =0A> > > location hiding. Even if the LIS wasn't hiding location I'd still=0D= =0A> > > recommend that the device acquires the PSAP URI from the local=0D=0A= > > services=0D=0A> > > and not just hope that the VSP can do it for it.=0D= =0A> > >=0D=0A> > > If the VSP is really going to run its own copy of the L= oST data=0D=0Afor=0D=0A> > the=0D=0A> > > area of coverage that it cares ab= out, then it can use any internal=0D=0A> > > mechanism it likes to spot the= matching PSAP URI in the database.=0D=0AIt=0D=0A> > > doesn't have to talk= LoST to its own infrastructure. Barbara=0D=0Apointed=0D=0A> > out=0D=0A> >= > that, as a VSP operator, she isn't going to be so concerned about=0D=0A>= > those=0D=0A> > > "foreign" emergency calls anyway. I actually agree with= the=0D=0Asentiments=0D=0A> > > expressed that a VSP should still have a mi= ssion to support=0D=0Aemergency=0D=0A> > > calling regardless of point of o= rigin. In the spirit of Barbara's=0D=0A> > > position, however, perhaps it'= s still reasonable if they charge=0D=0Afor=0D=0A> > > those "foreign" emerg= ency calls.=0D=0A> > >=0D=0A> > > Main point - I think the ability to provi= de global emergency=0D=0Aservice=0D=0A> > as=0D=0A> > > soon as possible is= a better goal than saying I'll wait until I=0D=0Acan be=0D=0A> > > sure th= at global emergency service can be provided for free before=0D=0Athe=0D=0A>= > > service can be used at all.=0D=0A> > >=0D=0A> > > Cheers,=0D=0A> > > M= artin=0D=0A> > >=0D=0A> > > -----Original Message-----=0D=0A> > > From: Bri= an Rosen [mailto:br@brianrosen.net]=0D=0A> > > Sent: Friday, 15 June 2007 1= 1:03 PM=0D=0A> > > To: Dawson, Martin; ecrit@ietf.org=0D=0A> > > Subject: R= E: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A> > >=0D=0A> > = > Yeah, you agree with me. You just want to ignore the VSP=0D=0Avalidation=0D= =0A> > > problem. I'd like to ignore the location hiding problem, but=0D=0A= we're=0D=0A> > > stuck=0D=0A> > > with both.=0D=0A> > >=0D=0A> > > If you c= ome up with some way other than allowing the VSP to get=0D=0Acoarse=0D=0A> = > > location and using that to validate the PSAP URI, then we can use=0D=0A= that=0D=0A> > > for=0D=0A> > > option 1 or 3. So far there is no other mec= hanism that we can=0D=0Ause.=0D=0A> > We=0D=0A> > > can=0D=0A> > > extend L= oST in some way to do it, but several of us are suggesting=0D=0A> > that=0D= =0A> > > we=0D=0A> > > postpone that work and get LoST out now.=0D=0A> > >=0D= =0A> > > I certainly agree that the basic assumption that the access=0D=0Ap= rovider,=0D=0A> > > LoST=0D=0A> > > server and PSAP are local to one anothe= r is a good one. It's what=0D=0A> > makes=0D=0A> > > option 1 or 3 possibl= e, and gives the greatest likelihood that the=0D=0A> > > system=0D=0A> > > = will work. I think having the VSP route is fairly easy, but=0D=0A"fairly"=0D= =0A> > > means=0D=0A> > > that we need forest guides so that callers that a= re remote can be=0D=0A> > > routed.=0D=0A> > > I'd strongly prefer endpoint= s to route. That will be much more=0D=0Alikely=0D=0A> > > to=0D=0A> > > wo= rk in all circumstances. It seems very unlikely to me that we=0D=0Awould=0D= =0A> > > have=0D=0A> > > a situation where the endpoint could supply locati= on, but could=0D=0Anot do=0D=0A> > > dialstring recognition and routing. H= aving the VSP supply=0D=0Alocation=0D=0A> > AND=0D=0A> > > route is really = going to be difficult with VPNs and NATs, etc.=0D=0A> > >=0D=0A> > > With r= espect to who runs the servers, I believe you are conflating=0D=0Atwo=0D=0A= > > > parts=0D=0A> > > of the problem: who is responsible for the data, and= who runs the=0D=0A> > actual=0D=0A> > > server. The PSAP is responsible f= or the data. It will probably=0D=0Arun a=0D=0A> > > server which anyone ca= n use. However, I believe most access=0D=0Anetwork=0D=0A> > > providers wi= ll want a copy of the data in a server they run. That=0D=0Ais=0D=0A> > > t= he=0D=0A> > > purpose of the LoST mechanisms to maintain replicas of the da= ta.=0D=0A> > >=0D=0A> > > Brian=0D=0A> > >=0D=0A> > >=0D=0A> > >=0D=0A> > >= > -----Original Message-----=0D=0A> > > > From: Dawson, Martin [mailto:Mar= tin.Dawson@andrew.com]=0D=0A> > > > Sent: Friday, June 15, 2007 3:32 AM=0D=0A= > > > > To: ecrit@ietf.org=0D=0A> > > > Subject: RE: [Ecrit] Proposals 1 an= d 3 - summary of perspectives=0D=0A> > > >=0D=0A> > > >=0D=0A> > > > Speak = for yourself :) Your description of option 3 does not=0D=0A> > correlate=0D= =0A> > > > with my description or understanding of it. So, if there's=0D=0A= > > confusion,=0D=0A> > > > perhaps this is the root of it.=0D=0A> > > >=0D= =0A> > > > In option 3 - the access network doesn't determine coarse=0D=0Al= ocation=0D=0A> > at=0D=0A> > > > all. It doesn't concern itself with coarse= location. It uses the=0D=0A> > > precise=0D=0A> > > > location that it det= ermines for the device, queries the local=0D=0ALoST=0D=0A> > > > server and= provides the resultant PSAP URI directly to the=0D=0Adevice.=0D=0A> > At=0D= =0A> > > > this point the routing has been achieved and the device can=0D=0A= route=0D=0A> > > > directly or via the VSP. When the PSAP dereferences, it = gets the=0D=0A> > > precise=0D=0A> > > > location from the LIS. It is exact= ly because the routing is=0D=0Aachieved=0D=0A> > > by=0D=0A> > > > just the= local elements that this option doesn't have the=0D=0AAchilles=0D=0A> > > = heel=0D=0A> > > > of option 1 which requires the VSP, absolutely, to be abl= e to=0D=0Afind=0D=0A> > the=0D=0A> > > > authoritative local LoST server. A= s I say, for a very remote VSP=0D=0Aand=0D=0A> > > no=0D=0A> > > > function= ing forest guide, it may very well not be able to.=0D=0A> > > >=0D=0A> > > = > There's a basic principle here - emergency services are local to=0D=0Athe=0D= =0A> > > > caller, the access network operator (and LIS) are local to the=0D= =0A> > caller,=0D=0A> > > > and the authoritative LoST server is going to m= ost local to the=0D=0A> > > caller.=0D=0A> > > > The ability to reliably ro= ute the call is going to be optimal if=0D=0A> > it's=0D=0A> > > > done betw= een all these local entities who are best placed to be=0D=0A> > aware=0D=0A= > > > of=0D=0A> > > > each other. Waiting until the call scenario has geogr= aphically=0D=0A> > > diverged=0D=0A> > > > to the VSP before attempting to = determine routing is=0D=0Aunnecessarily=0D=0A> > > > sub-optimal.=0D=0A> > = > >=0D=0A> > > > In option 1 - how do you propose the access network determ= ine=0D=0Athe=0D=0A> > > > "coarse location"=3F I believe your proposal is t= hat it uses the=0D=0Alocal=0D=0A> > > > LoST server applicable to its area = of coverage and utilize the=0D=0A> > > semantics=0D=0A> > > > of LoST which= provide a PSAP boundary in the response. Can you=0D=0A> > confirm=0D=0A> >= > > that this is your proposal=3F Otherwise, how would you anticipate=0D=0A= that=0D=0A> > > the=0D=0A> > > > access provider, who doesn't manage the PS= AP boundaries after=0D=0Aall,=0D=0A> > > would=0D=0A> > > > know what is th= e appropriate coarse location that will result in=0D=0Aa=0D=0A> > > > relia= ble response when LoST is queried=3F=0D=0A> > > >=0D=0A> > > > With respect= to Henning's comment about LoST services being=0D=0Aprovided=0D=0A> > > by=0D= =0A> > > > ISPs and/or VSPs, I didn't resonate with that. I would expect=0D= =0Athat=0D=0A> > > LoST=0D=0A> > > > is emergency services specific and it = is likely to be part of=0D=0Asome=0D=0A> > > > jurisdictional function or s= ome provider of services to that=0D=0A> > > > jurisdictional function. I do= n't see that either ISPs or VSPs=0D=0Aare=0D=0A> > > > qualified to manage = the PSAP routing information contained in a=0D=0ALoST=0D=0A> > > > server.=0D= =0A> > > >=0D=0A> > > > Cheers,=0D=0A> > > > Martin=0D=0A> > > >=0D=0A> > >= > -----Original Message-----=0D=0A> > > > From: Brian Rosen [mailto:br@bri= anrosen.net]=0D=0A> > > > Sent: Thursday, 14 June 2007 11:07 PM=0D=0A> > > = > To: Dawson, Martin; 'ECRIT'=0D=0A> > > > Subject: RE: [Ecrit] Proposals 1= and 3 - summary of perspectives=0D=0A> > > >=0D=0A> > > > Wait a minute, w= e're getting confused.=0D=0A> > > >=0D=0A> > > > Option 1 requires that the= access network dereference to anyone=0D=0Awith=0D=0A> > > at=0D=0A> > > > = least coarse location suitable for emergency call routing. If=0D=0Athe=0D=0A= > > > > endpoint=0D=0A> > > > does routing, it will use a local LoST server= which has high=0D=0A> > > probability=0D=0A> > > > of=0D=0A> > > > having = the route. If a VSP wants to verify, it needs access to=0D=0Aa=0D=0A> > Lo= ST=0D=0A> > > > server covering the area where his customers roam. The cos= t is=0D=0Aon=0D=0A> > the=0D=0A> > > > carrier that is trying to hide locat= ion (which, AFAIK, is an=0D=0A> > economic=0D=0A> > > > issue=0D=0A> > > > = all the way, the hiding is so the access network can charge for=0D=0Anon=0D= =0A> > > > emergency uses of location).=0D=0A> > > >=0D=0A> > > > Option 3 = requires that the access network dereference to anyone=0D=0Awith=0D=0A> > >= at=0D=0A> > > > least coarse location suitable for emergency call routing.= This=0D=0Ais=0D=0A> > > > because=0D=0A> > > > if the endpoint doesn't ro= ute (or more specifically, if it=0D=0Adoesn't=0D=0A> > > > recognize=0D=0A>= > > > emergency dialstrings, query LoST, and add the PSAP URI), but=0D=0Ad= oes=0D=0A> > > > supply=0D=0A> > > > location, then the VSP has to route, a= nd it will have to=0D=0A> > dereference.=0D=0A> > > > If=0D=0A> > > > the e= ndpoint does routing, option 3 is easy, because it will=0D=0Ahave=0D=0A> > = the=0D=0A> > > > correct PSAP URIs (it has to be all of them, BTW, a proble= m in=0D=0A> > > itself).=0D=0A> > > > If=0D=0A> > > > a VSP wants to verify= , it needs access to a LoST server covering=0D=0Athe=0D=0A> > > > area=0D=0A= > > > > where his customers roam. It can't use the LCP, it has to=0D=0A> >= dereference=0D=0A> > > > the=0D=0A> > > > location, and then query LoST.=0D= =0A> > > >=0D=0A> > > > If we supply a different mechanism for a VSP to val= idate, that=0D=0Acould=0D=0A> > > > change,=0D=0A> > > > and it would affec= t 1 and 3 the same way.=0D=0A> > > >=0D=0A> > > > Brian=0D=0A> > > >=0D=0A>= > > > > -----Original Message-----=0D=0A> > > > > From: Dawson, Martin [ma= ilto:Martin.Dawson@andrew.com]=0D=0A> > > > > Sent: Wednesday, June 13, 200= 7 10:56 PM=0D=0A> > > > > To: ECRIT=0D=0A> > > > > Subject: RE: [Ecrit] Pro= posals 1 and 3 - summary of=0D=0Aperspectives=0D=0A> > > > >=0D=0A> > > > >= Typo alert - obviously it should have said that option *1*=0D=0A> > requir= es=0D=0A> > > > the=0D=0A> > > > > VSP to work out the local LoST server in= addition to the LIS=0D=0A> > needing=0D=0A> > > > to=0D=0A> > > > > know i= t.=0D=0A> > > > >=0D=0A> > > > > Cheers,=0D=0A> > > > > Martin=0D=0A> > > >= >=0D=0A> > > > > -----Original Message-----=0D=0A> > > > > From: Dawson, M= artin [mailto:Martin.Dawson@andrew.com]=0D=0A> > > > > Sent: Thursday, 14 J= une 2007 11:14 AM=0D=0A> > > > > To: Henning Schulzrinne; Winterbottom, Jam= es=0D=0A> > > > > Cc: ECRIT=0D=0A> > > > > Subject: RE: [Ecrit] Proposals 1= and 3 - summary of=0D=0Aperspectives=0D=0A> > > > >=0D=0A> > > > > BTW - a= s I understand option 1, it requires the LIS to query=0D=0Athe=0D=0A> > > l= ocal=0D=0A> > > > > LoST server as well. At least that's how I recall Brian= 's=0D=0Aoriginal=0D=0A> > > > > proposal being stated. It returns a "PSAP U= RI boundary"=0D=0Alocation=0D=0A> > > > instead=0D=0A> > > > > of the PSAP = URI.=0D=0A> > > > >=0D=0A> > > > > I think folk are being inconsistent char= acterising option 3 as=0D=0A> > > adding=0D=0A> > > > > LoST functionality = to HELD. Both proposals require the LIS to=0D=0A> > > interact=0D=0A> > > >= > with LoST with the subsequent proxying of results to the=0D=0Adevice.=0D= =0A> > > > >=0D=0A> > > > > If the proposition of option 1 is that it's act= ually the LIS=0D=0Athat=0D=0A> > > > holds=0D=0A> > > > > the PSAP-relevant= boundary information, then option 1 is=0D=0Aactually=0D=0A> > > much=0D=0A= > > > > > more like adding LoST functionality to the LIS (and adds=0D=0A> >= > inappropriate=0D=0A> > > > > responsibility to the LIS provider).=0D=0A>= > > > >=0D=0A> > > > > Further, given my understanding, both proposals rel= y on the=0D=0ALIS=0D=0A> > > > knowing=0D=0A> > > > > inherently what the a= ppropriate local LoST server is. Option 1=0D=0A> > just=0D=0A> > > > > mean= s that this is required *as well as* the VSP being able to=0D=0A> > reach=0D= =0A> > > > > that same local LoST service.=0D=0A> > > > >=0D=0A> > > > > Ne= ither option requires the ISP to implement LoST, they just=0D=0A> > require=0D= =0A> > > > the=0D=0A> > > > > ISP to know which LoST server is applicable t= o the local area=0D=0Aof=0D=0A> > > > > coverage. That's much more practica= l than expecting any=0D=0Aarbitrary=0D=0A> > > > global=0D=0A> > > > > VSP = being able to work that out but that is what option 3=0D=0Arequires=0D=0A> = > > *in=0D=0A> > > > > addition*.=0D=0A> > > > >=0D=0A> > > > > Cheers,=0D=0A= > > > > > Martin=0D=0A> > > > >=0D=0A> > > > > -----Original Message-----=0D= =0A> > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A> = > > > > Sent: Thursday, 14 June 2007 10:22 AM=0D=0A> > > > > To: Winterbott= om, James=0D=0A> > > > > Cc: ECRIT=0D=0A> > > > > Subject: Re: [Ecrit] Prop= osals 1 and 3 - summary of=0D=0Aperspectives=0D=0A> > > > >=0D=0A> > > > > = I assume that your discussion has nothing to do with location=0D=0A> > hidi= ng=0D=0A> > > > > at this point, but wanted to call this out just in case I= 'm=0D=0A> > missing=0D=0A> > > > > your train of thought.=0D=0A> > > > >=0D= =0A> > > > > I'm afraid I don't follow your logic. Unless you assume that=0D= =0Aevery=0D=0A> > > > > ISP deploys a LoST+HELD server, VSPs will have to h= ave LoST=0D=0A> > servers=0D=0A> > > > > with PSAP knowledge for the places= their customers are likely=0D=0Ato=0D=0A> > > > > visit. This doesn't chan= ge whether HELD also gets converted=0D=0Ainto a=0D=0A> > > > > LoST access = protocol or not. So far, at least, VSPs seem a=0D=0Awhole=0D=0A> > lot=0D=0A= > > > > > more interested in providing emergency call services than=0D=0AIS= Ps,=0D=0A> > > > > presumably because their customers look to them for that=0D= =0Aservice,=0D=0A> > > not=0D=0A> > > > > to the random hot spot operator.=0D= =0A> > > > >=0D=0A> > > > > It's always been the model that both ISPs and V= SPs (as well as=0D=0A> > third=0D=0A> > > > > parties that are neither) can= and should operate LoST servers,=0D=0Aas=0D=0A> > > > > that seems most li= kely to ensure that you get broad coverage.=0D=0A> > > > >=0D=0A> > > > > H= enning=0D=0A> > > > >=0D=0A> > > > > On Jun 13, 2007, at 8:00 PM, Winterbot= tom, James wrote:=0D=0A> > > > >=0D=0A> > > > > > Henning,=0D=0A> > > > > >=0D= =0A> > > > > > I think that your proposal only works if the VSP is able to=0D= =0A> > > provide=0D=0A> > > > a=0D=0A> > > > > > LoST server for all jurisd= ictions that it plans to provide=0D=0A> > service=0D=0A> > > > > > for,=0D=0A= > > > > > > or it has to do it for everything (sounds awfully like a=0D=0Ag= lobal=0D=0A> > > VPC=0D=0A> > > > to=0D=0A> > > > > > me). Option 3 would b= e deployable from a local area to a=0D=0Alocal=0D=0A> > > PSAP=0D=0A> > > >= > > REGARDLESS of the VSP having a LoST server that has boundary=0D=0A> > = > > > > information=0D=0A> > > > > > for the local area I am in. It provide= s a global solution=0D=0Afrom=0D=0A> > the=0D=0A> > > > > > get-go.=0D=0A> = > > > > >=0D=0A> > > > > > Let's take the good old Sierra-Leone example aga= in.=0D=0A> > > > > >=0D=0A> > > > > > My VSP is in Sierra-Leone and I am vi= siting Samoa. In option=0D=0A3,=0D=0A> > I=0D=0A> > > > > > get a=0D=0A> > = > > > > PSA P URI for the local Samoan PSAP from the local access=0D=0ALIS=0D= =0A> > > > serving=0D=0A> > > > > > the area I am in, I send my call to VSP= , it sends it on the=0D=0A> > PSAP.=0D=0A> > > I=0D=0A> > > > > > get=0D=0A= > > > > > > billed, call completes, we are done. I can quibble with my=0D=0A= VSP=0D=0A> > > later=0D=0A> > > > > > over the 10 cent call charge if I can= be bothered.=0D=0A> > > > > >=0D=0A> > > > > > With option 1, I send my ca= ll with location to my VSP, and=0D=0Aone=0D=0A> > of=0D=0A> > > > > > three=0D= =0A> > > > > > things happens. Either it has a complete forest guide=0D=0An= etwork=0D=0A> > set-=0D=0A> > > > > > up to=0D=0A> > > > > > be able to tal= k to the Samoan LoST server nearest me, my=0D=0Acall=0D=0A> > > > > > fails= , or=0D=0A> > > > > > the VSP routes the call anyway because the end-point = has=0D=0Adone=0D=0A> > the=0D=0A> > > > LoST=0D=0A> > > > > > lookup. I poi= nt out, that from the VSP perspective the third=0D=0A> > > > > > alternativ= e=0D=0A> > > > > > here is simply option 3 re-badged. I am sure that VSPs=0D= =0Awouldn't=0D=0A> > > > > > drop the=0D=0A> > > > > > call on the floor, s= o choice 2 isn't an option, and choice 1=0D=0Acan=0D=0A> > > > ONLY=0D=0A> = > > > > > occur if the whole network is up and running, and it doesn't=0D=0A= > > > > > > consist of=0D=0A> > > > > > isolated copse of Forest Guides and= LoST Servers.=0D=0A> > > > > >=0D=0A> > > > > > So to my mind, option 3 is= the ONLY deployable solution in=0D=0Athe=0D=0A> > > short=0D=0A> > > > > >= term that will actually work universally.=0D=0A> > > > > >=0D=0A> > > > > = > Cheers=0D=0A> > > > > > James=0D=0A> > > > > >=0D=0A> > > > > >=0D=0A> > = > > > >> -----Original Message-----=0D=0A> > > > > >> From: Henning Schulzr= inne [mailto:hgs@cs.columbia.edu]=0D=0A> > > > > >> Sent: Thursday, 14 June= 2007 12:58 AM=0D=0A> > > > > >> To: Dawson, Martin=0D=0A> > > > > >> Cc: e= crit@ietf.org=0D=0A> > > > > >> Subject: Re: [Ecrit] Proposals 1 and 3 - su= mmary of=0D=0A> > perspectives=0D=0A> > > > > >>=0D=0A> > > > > >>=0D=0A> >= > > > >> On Jun 13, 2007, at 10:54 AM, Dawson, Martin wrote:=0D=0A> > > > = > >>=0D=0A> > > > > >>> Nobody has suggested changing LoST so this point is= just a=0D=0A> > > > > >>> distraction.=0D=0A> > > > > >>>=0D=0A> > > > > >= >>=0D=0A> > > > > >>>=0D=0A> > > > > >>> Option 1 means that emergency call= s will not be able to be=0D=0A> > > routed=0D=0A> > > > > >>> until the for= est guide network is implemented. Option 3=0D=0Ameans=0D=0A> > > that=0D=0A= > > > > > >>> emergency calls will be able to be routed regardless of=0D=0A= the=0D=0A> > > state=0D=0A> > > > > >>> of deployment of the forest guide.=0D= =0A> > > > > >>>=0D=0A> > > > > >>>=0D=0A> > > > > >> This is not true, at = least for comparable installations.=0D=0AThe=0D=0A> > ISP=0D=0A> > > > can=0D= =0A> > > > > >> offer a LoST server that has the locally-relevant=0D=0Ainfo= rmation.=0D=0A> > > Same=0D=0A> > > > > >> for the VSP. This does not requi= re a forest guide as such.=0D=0A> > > > > >>=0D=0A> > > > > >> ____________= ___________________________________=0D=0A> > > > > >> Ecrit mailing list=0D= =0A> > > > > >> Ecrit@ietf.org=0D=0A> > > > > >> https://www1.ietf.org/mail= man/listinfo/ecrit=0D=0A> > > > > >=0D=0A> > > > > >=0D=0A> > > >=0D=0A> >=0D= =0A----------------------------------------------------------------------=0D= =0A> > > > >=0D=0A> > > > > > --------------------------=0D=0A> > > > > > T= his message is for the designated recipient only and may=0D=0A> > > > > > c= ontain privileged, proprietary, or otherwise private=0D=0A> > information.=0D= =0A> > > > > > If you have received it in error, please notify the sender=0D= =0A> > > > > > immediately and delete the original. Any unauthorized use=0D= =0Aof=0D=0A> > > > > > this email is prohibited.=0D=0A> > > > > >=0D=0A> > = > >=0D=0A> >=0D=0A---------------------------------------------------------= -------------=0D=0A> > > > >=0D=0A> > > > > > --------------------------=0D= =0A> > > > > > [mf2]=0D=0A> > > > > >=0D=0A> > > > >=0D=0A> > > > >=0D=0A> = > > > > _______________________________________________=0D=0A> > > > > Ecri= t mailing list=0D=0A> > > > > Ecrit@ietf.org=0D=0A> > > > > https://www1.ie= tf.org/mailman/listinfo/ecrit=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > > >=0D= =0A> > >=0D=0A> >=0D=0A----------------------------------------------------= --------------------=0D=0A> > > > > ------------------------=0D=0A> > > > >= This message is for the designated recipient only and may=0D=0A> > > > > c= ontain privileged, proprietary, or otherwise private=0D=0Ainformation.=0D=0A= > > > > > If you have received it in error, please notify the sender=0D=0A>= > > > > immediately and delete the original. Any unauthorized use of=0D=0A= > > > > > this email is prohibited.=0D=0A> > > > >=0D=0A> > > >=0D=0A> > >=0D= =0A> >=0D=0A---------------------------------------------------------------= ---------=0D=0A> > > > > ------------------------=0D=0A> > > > > [mf2]=0D=0A= > > > > >=0D=0A> > > > >=0D=0A> > > > > ___________________________________= ____________=0D=0A> > > > > Ecrit mailing list=0D=0A> > > > > Ecrit@ietf.or= g=0D=0A> > > > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > > > = >=0D=0A> > > > >=0D=0A> > > >=0D=0A> > >=0D=0A> >=0D=0A--------------------= ----------------------------------------------------=0D=0A> > > > --=0D=0A>= > > > > ----------------------=0D=0A> > > > > This message is for the desi= gnated recipient only and may=0D=0A> > > > > contain privileged, proprietar= y, or otherwise private=0D=0Ainformation.=0D=0A> > > > > If you have receiv= ed it in error, please notify the sender=0D=0A> > > > > immediately and del= ete the original. Any unauthorized use of=0D=0A> > > > > this email is pro= hibited.=0D=0A> > > > >=0D=0A> > > >=0D=0A> > >=0D=0A> >=0D=0A-------------= -----------------------------------------------------------=0D=0A> > > > --=0D= =0A> > > > > ----------------------=0D=0A> > > > > [mf2]=0D=0A> > > > >=0D=0A= > > > > >=0D=0A> > > > > _______________________________________________=0D= =0A> > > > > Ecrit mailing list=0D=0A> > > > > Ecrit@ietf.org=0D=0A> > > > = > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > > >=0D=0A> > > >=0D= =0A> > > >=0D=0A> > >=0D=0A> >=0D=0A---------------------------------------= ---------------------------------=0D=0A> > > --=0D=0A> > > > --------------= --------=0D=0A> > > > This message is for the designated recipient only and= may=0D=0A> > > > contain privileged, proprietary, or otherwise private=0D=0A= information.=0D=0A> > > > If you have received it in error, please notify t= he sender=0D=0A> > > > immediately and delete the original. Any unauthoriz= ed use of=0D=0A> > > > this email is prohibited.=0D=0A> > > >=0D=0A> > >=0D= =0A> >=0D=0A---------------------------------------------------------------= ---------=0D=0A> > > --=0D=0A> > > > ----------------------=0D=0A> > > > [m= f2]=0D=0A> > > >=0D=0A> > > >=0D=0A> > > > ________________________________= _______________=0D=0A> > > > Ecrit mailing list=0D=0A> > > > Ecrit@ietf.org=0D= =0A> > > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > >=0D=0A> >= >=0D=0A> > >=0D=0A> >=0D=0A-----------------------------------------------= -------------------------=0D=0A> > --=0D=0A> > > ----------------------=0D=0A= > > > This message is for the designated recipient only and may=0D=0A> > > = contain privileged, proprietary, or otherwise private information.=0D=0A> >= > If you have received it in error, please notify the sender=0D=0A> > > im= mediately and delete the original. Any unauthorized use of=0D=0A> > > this= email is prohibited.=0D=0A> > >=0D=0A> >=0D=0A----------------------------= --------------------------------------------=0D=0A> > --=0D=0A> > > -------= ---------------=0D=0A> > > [mf2]=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A----------= --------------------------------------------------------------=0D=0A> --=0D= =0A> > ----------------------=0D=0A> > This message is for the designated r= ecipient only and may=0D=0A> > contain privileged, proprietary, or otherwis= e private information.=0D=0A> > If you have received it in error, please no= tify the sender=0D=0A> > immediately and delete the original. Any unauthor= ized use of=0D=0A> > this email is prohibited.=0D=0A> >=0D=0A--------------= ----------------------------------------------------------=0D=0A> --=0D=0A>= > ----------------------=0D=0A> > [mf2]=0D=0A>=20=0D=0A>=20=0D=0A> _______= ________________________________________=0D=0A> Ecrit mailing list=0D=0A> E= crit@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0AThis message is for the designated recipient onl= y and may=0D=0Acontain privileged, proprietary, or otherwise private inform= ation. =20=0D=0AIf you have received it in error, please notify the sender=0D= =0Aimmediately and delete the original. Any unauthorized use of=0D=0Athis = email is prohibited.=0D=0A-------------------------------------------------= -----------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jun 17 23:06:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I07Zd-0005pI-Sl; Sun, 17 Jun 2007 23:06:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I07Zc-0005p7-Ny for ecrit@ietf.org; Sun, 17 Jun 2007 23:06:36 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I07Zb-00085I-KK for ecrit@ietf.org; Sun, 17 Jun 2007 23:06:36 -0400 X-SEF-Processed: 5_0_0_910__2007_06_17_22_14_18 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 17 Jun 2007 22:14:18 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 17 Jun 2007 22:06:33 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 17 Jun 2007 22:06:30 -0500 Message-ID: In-Reply-To: <0e4801c7b056$9c15d120$9501a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives Thread-Index: AceuGgIUdnorn1MfT9KY7XAHcoK3nAABWk3gAAP8qIAAFRhfQAAEcxKwAC1PJ0AAAMljcAADai4wABfBL7AAJiIUMABAPJGw References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com><1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> < 087a01c7ae84$e1b48a10$9501a8c0@cis.neustar.com> <0b8c01c7af4d$8e22b3d0$9501a8c0@cis.neustar.com> <0bc401c7af5c$ddd16c50$9501a8c0@cis.neustar.com> <0e4801c7b056$9c15d120$9501a8c0@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , X-OriginalArrivalTime: 18 Jun 2007 03:06:33.0093 (UTC) FILETIME=[ACB07350:01C7B155] X-Spam-Score: 0.0 (/) X-Scan-Signature: 231d7929942febf3be8fd5be2903302f Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'd like to challenge the following:=0D=0A=0D=0A" If there is no forest gui= de, the local LoST server is still highly=0D=0Alikely to have the route for= the location the endpoint is given.=0D=0AEverything except=0D=0AVSP valida= tion works without forest guides."=0D=0A=0D=0AYou make it sound as if routi= ng will work without forest guides given=0D=0Aoption 1. It does not unless= by (insert miracle happens here) the VSP=0D=0Ahappens to have the foreign = jurisdiction LoST identity or a copy of the=0D=0Aforeign jurisdiction LoST = information.=0D=0A=0D=0AI have only referred to "validation" in the context= of this thread as=0D=0Ameaning "confirming that a nominal PSAP URI is a ge= nuine PSAP URI". So=0D=0Athat hasn't been a root of any confusion for me. I= think option 3 does=0D=0Aprovide validation of the PSAP URI because it is = based on the=0D=0Aunderstanding that the LIS acquires the URI from the loca= l LoST server.=0D=0A=0D=0AI guess what I object to is the precipitous settl= ing on option 1 (with=0D=0Aits inherent failure) before anybody has an opti= on to submit alternative=0D=0Atext in any form.=0D=0A=0D=0AIn the mean time= , and as you acknowledge below, both options 1 and 3=0D=0Ahave "commercial"= compromises for one or other party and there's no=0D=0Aobjective way to gi= ve one priority over the other on that basis.=0D=0A=0D=0AI would be interes= ted in hearing from others (than Brian) whether they=0D=0Athink scenario A = or scenario B below are the best starting point for=0D=0Anow.=0D=0A=0D=0ACh= eers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Brian Ro= sen [mailto:br@brianrosen.net]=20=0D=0ASent: Sunday, 17 June 2007 6:41 AM=0D= =0ATo: Dawson, Martin; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Proposals 1= and 3 - summary of perspectives=0D=0A=0D=0AMaybe we're getting ourselves c= onfused with the word "validation". An=0D=0Aendpoint would like to know th= at the location it got was a valid=0D=0Alocation.=0D=0AIt can do that by qu= erying LoST. If it's given a reference and a PSAP=0D=0AURI,=0D=0Ait can't = check it unless it does a dereference, gets some kind of=0D=0Alocation=0D=0A= and queries LoST. So option 3 leaves the endpoint not being able to=0D=0Av= alidate.=0D=0A=0D=0AIf an endpoint routes, some VSPs want to validate that = the route the=0D=0Aendpoint handed it is valid. That's another form of val= idation. Option=0D=0A3=0D=0Adoesn't provide any way for the VSP to validat= e that the PSAP URI in the=0D=0ARequest URI is a bona fide PSAP URI.=0D=0A=0D= =0AYes, option 1 requires the LIS to provide a coarse location value for=0D= =0Aanyone=0D=0Athat asks. It provides a way for the endpoint to validate t= hat the=0D=0Alocation=0D=0Aresults in a route to a PSAP, and it provides a = way for a VSP to=0D=0Avalidate=0D=0Athat the URI is a valid PSAP URI.=0D=0A=0D= =0AIf there is no forest guide, the local LoST server is still highly=0D=0A= likely to=0D=0Ahave the route for the location the endpoint is given. Ever= ything=0D=0Aexcept=0D=0AVSP validation works without forest guides. PSAP v= alidation requires=0D=0Athat=0D=0Athe VSP have access to the same LoST data= that the endpoint does. In=0D=0Athe=0D=0Ageneral case, that means forest = guides. There are lots of cases where=0D=0Athe=0D=0AVSP could reasonably g= et access to the LoST data where MOST of his=0D=0Asubscribers are, but most= is not all, and forest guides would be=0D=0Arequired.=0D=0A=0D=0AWith opti= on 3, the LIS is highly likely to have access to LoST data=0D=0Acovering=0D= =0Ait's service area, so no forest guides are needed. The endpoint can't=0D= =0Avalidate, so whether there are forest guides is moot. Same for VSP=0D=0A= validation. =20=0D=0A=0D=0AThere is a document that describes how forest gu= ides work. There has=0D=0Abeen=0D=0Adiscussion on this document, which has= had more than one revision. The=0D=0Aonly=0D=0Awords describing how optio= n 3 might provide validation are email=0D=0Adiscussions=0D=0Aof reverse loo= kups, and one email from you that said "The ability to=0D=0Averify=0D=0Aa d= estination PSAP URI as a valid emergency URI could be supported by=0D=0Aref= erence to a relatively static table maintained by global=0D=0Acooperation."=0D= =0AThat is the extent of the discussion. There is no text.=0D=0A=0D=0AI mo= re or less understand how reverse lookup would work. I think we=0D=0Awould=0D= =0Ahave a significant piece of work to add that to the current LoST=0D=0Ado= cument.=0D=0AI think everyone agrees that now is not the time to do that wo= rk. If=0D=0Ayou=0D=0Aaccept VSP validation as a requirement, which I do (r= eluctantly, but=0D=0Athen I=0D=0Aaccept location hiding as a requirement ju= st as reluctantly) then we=0D=0Aneed=0D=0Asomething that doesn't need a cha= nge to LoST with the impact of reverse=0D=0Alookups. You have suggested so= mething. I think it won't work, but it's=0D=0Ahard to criticize because th= ere is no text. In your latest email, you=0D=0Ahave=0D=0Aanother idea, whi= ch I find equally unlikely to work, but again, there is=0D=0Ano=0D=0Atext t= o criticize.=0D=0A=0D=0AI don't really like option 3, but I could live with= it if there was a=0D=0Away=0D=0Afor the VSP to validate. I'd really like = a way for the endpoint to=0D=0Avalidate, but that is not quite so important= =2E I don't want to hold up=0D=0ALoST.=0D=0A=0D=0ASo, I'd say, in the abse= nce of a reasonable alternative, with text that=0D=0Ahas=0D=0Ahad some leve= l of review, and has at least a reasonable amount of=0D=0Aconsensus,=0D=0At= hat we document option 1 (in phonebcp) and keep working.=0D=0A=0D=0ABrian=0D= =0A> -----Original Message-----=0D=0A> From: Dawson, Martin [mailto:Martin.= Dawson@andrew.com]=0D=0A> Sent: Friday, June 15, 2007 10:25 PM=0D=0A> To: B= rian Rosen; ecrit@ietf.org=0D=0A> Subject: RE: [Ecrit] Proposals 1 and 3 - = summary of perspectives=0D=0A>=20=0D=0A> If the "normal case" is endpoint r= oute, then there's no need to=0D=0A> validate, right=3F So option 3 support= s this without any need to provide=0D=0A> location information. Option 1 re= quires it to provide location=0D=0A> information *for all requests* since i= t doesn't really know this is an=0D=0A> emergency scenario.=0D=0A>=20=0D=0A= > So - let's leave end-point route out of the discussion with the note=0D=0A= > that option 3 satisfies the location hiding requirement most=0D=0A> satis= factorily and without impact on VSP validation.=0D=0A>=20=0D=0A> Now - for = VSP route where the issue of URI validation comes up (which=0D=0Ais=0D=0A> = also purely a commercial issue AFAIK).=0D=0A>=20=0D=0A> A. If there's no fo= rest guide in place, option 1 doesn't allow the=0D=0A> emergency call to be= routed at all but at least nobody will have to=0D=0A> worry about whether = the non-call should be charged for or not.=0D=0A>=20=0D=0A> B. If there's n= o functional way to validate the proffered PSAP URI=0D=0Athen=0D=0A> option= 3 requires the VSP to decide whether to charge for the call or=0D=0A> not = based on its policy in this regard. However, the emergency call=0D=0Acan=0D= =0A> always be made regardless of the availability of a functional forest=0D= =0A> guide network.=0D=0A>=20=0D=0A> Your proposition is that scenario A is= preferable to scenario B. I=0D=0Athink=0D=0A> that is profoundly incorrect= =2E I think it's self-evidently so.=0D=0A>=20=0D=0A> You continually dismis= s any attempt on my part to start a discussion=0D=0A> about ways for a VSP = to validate the PSAP URI as "hand waving". Every=0D=0A> reasonable discussi= on based on a genuine desire to solve a problem=0D=0A> starts with those so= rts of suggestions. Your approach is a=0D=0A> self-fulfilling argument that= says there's no solution therefore there=0D=0A> can't be a solution, becau= se I'm simply not going to talk about one.=0D=0AHow=0D=0A> about a BCP that= says that PSAP URIs should follow a specific=0D=0Aconvention=0D=0A> in ter= ms of domain name structure=3F The VSP would only provide=0D=0Aemergency=0D= =0A> call tariffs to destinations that satisfy that BCP. Then somebody=0D=0A= > wanting to "scam a free call" would have to make sure that the called=0D=0A= > party URI met that form. Not particularly useful.=0D=0A>=20=0D=0A> There'= s no precedent for a US-based operator charging for emergency=0D=0A> calls = made by subscribers roaming in foreign jurisdictions. PSTN calls=0D=0A> (wh= ether cellular or wireline) are always handled by an operator in=0D=0Athat=0D= =0A> jurisdiction. In the case of cellular, it is handled by the roaming=0D= =0A> partner in that jurisdiction. VoIP is the first instance of the call=0D= =0A> processing occurring at the home provider end while the call occurs in=0D= =0A> the foreign jurisdiction. I think it's extremely unlikely that=0D=0Ach= arging=0D=0A> for emergency calls made in foreign jurisdictions would be il= legal.=0D=0A> There's only the barest shreds of legislation covering VoIP i= n any=0D=0A> respect at all at the moment.=0D=0A>=20=0D=0A> Cheers,=0D=0A> = Martin=0D=0A>=20=0D=0A> -----Original Message-----=0D=0A> From: Brian Rosen= [mailto:br@brianrosen.net]=0D=0A> Sent: Saturday, 16 June 2007 12:53 AM=0D= =0A> To: Dawson, Martin; ecrit@ietf.org=0D=0A> Subject: RE: [Ecrit] Proposa= ls 1 and 3 - summary of perspectives=0D=0A>=20=0D=0A> Huh=3F I said the no= rmal case is endpoint route. If the endpoint=0D=0Aroutes,=0D=0A> option 1 = is endpoint gets coarse location, endpoint queries LoST. No=0D=0A> forest=0D= =0A> guide.=0D=0A>=20=0D=0A> If the VSP routes, either option needs forest = guides.=0D=0A>=20=0D=0A> Option 1 and Option 3 need forest guides for the V= SP to validate.=0D=0A>=20=0D=0A> I don't see why a VSP would have a replica= of the LoST database, but=0D=0Aif=0D=0A> it=0D=0A> did, it wouldn't cover = the world. So unless it restricts nomading, it=0D=0A> has=0D=0A> to rely o= n forest guides to validate (or route). If it did have a=0D=0A> replica,=0D= =0A> it could have some non standard way to validate for the parts of the=0D= =0A> database it had. That's not a solution, that's an optimization. I=0D= =0A> don't=0D=0A> think you can handwave with "charge for foreign emergency= calls".=0D=0AThey=0D=0A> aren't "foreign" to the guy making them. I think= it would be illegal=0D=0Ain=0D=0A> the=0D=0A> U.S. for example, although t= he VSP may not be subject to U.S. law in=0D=0Aall=0D=0A> cases.=0D=0A>=20=0D= =0A> I think a reasonable strategy for a VSP attempting to validate is to=0D= =0A> arrange=0D=0A> forest guides, and to permit emergency calls from areas= where it=0D=0Acannot=0D=0A> get=0D=0A> coverage for without validation.=0D= =0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> > -----Original M= essage-----=0D=0A> > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D= =0A> > Sent: Friday, June 15, 2007 9:19 AM=0D=0A> > To: Brian Rosen; ecrit@= ietf.org=0D=0A> > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of persp= ectives=0D=0A> >=0D=0A> > OK - but there's a very significant qualitative d= ifference that you=0D=0A> > haven't acknowledged yet.=0D=0A> >=0D=0A> > Opt= ion 3 works without dependency on forest guides - it can work=0D=0A> > stra= ight away. Option 1 means that emergency calls will simply fail=0D=0Ato=0D=0A= > > route until a global and reliable forest guide infrastructure is in=0D=0A= > > place. As I said, that's completely independent of the question of=0D=0A= > > location hiding. Even if the LIS wasn't hiding location I'd still=0D=0A= > > recommend that the device acquires the PSAP URI from the local=0D=0A> s= ervices=0D=0A> > and not just hope that the VSP can do it for it.=0D=0A> >=0D= =0A> > If the VSP is really going to run its own copy of the LoST data for=0D= =0A> the=0D=0A> > area of coverage that it cares about, then it can use any= internal=0D=0A> > mechanism it likes to spot the matching PSAP URI in the = database. It=0D=0A> > doesn't have to talk LoST to its own infrastructure. = Barbara pointed=0D=0A> out=0D=0A> > that, as a VSP operator, she isn't goin= g to be so concerned about=0D=0A> those=0D=0A> > "foreign" emergency calls = anyway. I actually agree with the=0D=0Asentiments=0D=0A> > expressed that a= VSP should still have a mission to support=0D=0Aemergency=0D=0A> > calling= regardless of point of origin. In the spirit of Barbara's=0D=0A> > positio= n, however, perhaps it's still reasonable if they charge for=0D=0A> > those= "foreign" emergency calls.=0D=0A> >=0D=0A> > Main point - I think the abil= ity to provide global emergency service=0D=0A> as=0D=0A> > soon as possible= is a better goal than saying I'll wait until I can=0D=0Abe=0D=0A> > sure t= hat global emergency service can be provided for free before=0D=0Athe=0D=0A= > > service can be used at all.=0D=0A> >=0D=0A> > Cheers,=0D=0A> > Martin=0D= =0A> >=0D=0A> > -----Original Message-----=0D=0A> > From: Brian Rosen [mail= to:br@brianrosen.net]=0D=0A> > Sent: Friday, 15 June 2007 11:03 PM=0D=0A> >= To: Dawson, Martin; ecrit@ietf.org=0D=0A> > Subject: RE: [Ecrit] Proposals= 1 and 3 - summary of perspectives=0D=0A> >=0D=0A> > Yeah, you agree with m= e. You just want to ignore the VSP validation=0D=0A> > problem. I'd like = to ignore the location hiding problem, but we're=0D=0A> > stuck=0D=0A> > wi= th both.=0D=0A> >=0D=0A> > If you come up with some way other than allowing= the VSP to get=0D=0Acoarse=0D=0A> > location and using that to validate th= e PSAP URI, then we can use=0D=0Athat=0D=0A> > for=0D=0A> > option 1 or 3. = So far there is no other mechanism that we can use.=0D=0A> We=0D=0A> > can=0D= =0A> > extend LoST in some way to do it, but several of us are suggesting=0D= =0A> that=0D=0A> > we=0D=0A> > postpone that work and get LoST out now.=0D=0A= > >=0D=0A> > I certainly agree that the basic assumption that the access=0D= =0Aprovider,=0D=0A> > LoST=0D=0A> > server and PSAP are local to one anothe= r is a good one. It's what=0D=0A> makes=0D=0A> > option 1 or 3 possible, a= nd gives the greatest likelihood that the=0D=0A> > system=0D=0A> > will wor= k. I think having the VSP route is fairly easy, but=0D=0A"fairly"=0D=0A> >= means=0D=0A> > that we need forest guides so that callers that are remote = can be=0D=0A> > routed.=0D=0A> > I'd strongly prefer endpoints to route. T= hat will be much more=0D=0Alikely=0D=0A> > to=0D=0A> > work in all circumst= ances. It seems very unlikely to me that we=0D=0Awould=0D=0A> > have=0D=0A= > > a situation where the endpoint could supply location, but could not=0D=0A= do=0D=0A> > dialstring recognition and routing. Having the VSP supply loca= tion=0D=0A> AND=0D=0A> > route is really going to be difficult with VPNs an= d NATs, etc.=0D=0A> >=0D=0A> > With respect to who runs the servers, I beli= eve you are conflating=0D=0Atwo=0D=0A> > parts=0D=0A> > of the problem: who= is responsible for the data, and who runs the=0D=0A> actual=0D=0A> > serve= r. The PSAP is responsible for the data. It will probably run=0D=0Aa=0D=0A= > > server which anyone can use. However, I believe most access network=0D= =0A> > providers will want a copy of the data in a server they run. That=0D= =0Ais=0D=0A> > the=0D=0A> > purpose of the LoST mechanisms to maintain repl= icas of the data.=0D=0A> >=0D=0A> > Brian=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A>= > > -----Original Message-----=0D=0A> > > From: Dawson, Martin [mailto:Mar= tin.Dawson@andrew.com]=0D=0A> > > Sent: Friday, June 15, 2007 3:32 AM=0D=0A= > > > To: ecrit@ietf.org=0D=0A> > > Subject: RE: [Ecrit] Proposals 1 and 3 = - summary of perspectives=0D=0A> > >=0D=0A> > >=0D=0A> > > Speak for yourse= lf :) Your description of option 3 does not=0D=0A> correlate=0D=0A> > > wit= h my description or understanding of it. So, if there's=0D=0A> confusion,=0D= =0A> > > perhaps this is the root of it.=0D=0A> > >=0D=0A> > > In option 3 = - the access network doesn't determine coarse location=0D=0A> at=0D=0A> > >= all. It doesn't concern itself with coarse location. It uses the=0D=0A> > = precise=0D=0A> > > location that it determines for the device, queries the = local LoST=0D=0A> > > server and provides the resultant PSAP URI directly t= o the device.=0D=0A> At=0D=0A> > > this point the routing has been achieved= and the device can route=0D=0A> > > directly or via the VSP. When the PSAP= dereferences, it gets the=0D=0A> > precise=0D=0A> > > location from the LI= S. It is exactly because the routing is=0D=0Aachieved=0D=0A> > by=0D=0A> > = > just the local elements that this option doesn't have the Achilles=0D=0A>= > heel=0D=0A> > > of option 1 which requires the VSP, absolutely, to be ab= le to find=0D=0A> the=0D=0A> > > authoritative local LoST server. As I say,= for a very remote VSP=0D=0Aand=0D=0A> > no=0D=0A> > > functioning forest g= uide, it may very well not be able to.=0D=0A> > >=0D=0A> > > There's a basi= c principle here - emergency services are local to=0D=0Athe=0D=0A> > > call= er, the access network operator (and LIS) are local to the=0D=0A> caller,=0D= =0A> > > and the authoritative LoST server is going to most local to the=0D= =0A> > caller.=0D=0A> > > The ability to reliably route the call is going t= o be optimal if=0D=0A> it's=0D=0A> > > done between all these local entitie= s who are best placed to be=0D=0A> aware=0D=0A> > of=0D=0A> > > each other.= Waiting until the call scenario has geographically=0D=0A> > diverged=0D=0A= > > > to the VSP before attempting to determine routing is unnecessarily=0D= =0A> > > sub-optimal.=0D=0A> > >=0D=0A> > > In option 1 - how do you propos= e the access network determine the=0D=0A> > > "coarse location"=3F I believ= e your proposal is that it uses the=0D=0Alocal=0D=0A> > > LoST server appli= cable to its area of coverage and utilize the=0D=0A> > semantics=0D=0A> > >= of LoST which provide a PSAP boundary in the response. Can you=0D=0A> conf= irm=0D=0A> > > that this is your proposal=3F Otherwise, how would you antic= ipate=0D=0Athat=0D=0A> > the=0D=0A> > > access provider, who doesn't manage= the PSAP boundaries after all,=0D=0A> > would=0D=0A> > > know what is the = appropriate coarse location that will result in a=0D=0A> > > reliable respo= nse when LoST is queried=3F=0D=0A> > >=0D=0A> > > With respect to Henning's= comment about LoST services being=0D=0Aprovided=0D=0A> > by=0D=0A> > > ISP= s and/or VSPs, I didn't resonate with that. I would expect that=0D=0A> > Lo= ST=0D=0A> > > is emergency services specific and it is likely to be part of= some=0D=0A> > > jurisdictional function or some provider of services to th= at=0D=0A> > > jurisdictional function. I don't see that either ISPs or VSPs= are=0D=0A> > > qualified to manage the PSAP routing information contained = in a=0D=0ALoST=0D=0A> > > server.=0D=0A> > >=0D=0A> > > Cheers,=0D=0A> > > = Martin=0D=0A> > >=0D=0A> > > -----Original Message-----=0D=0A> > > From: Br= ian Rosen [mailto:br@brianrosen.net]=0D=0A> > > Sent: Thursday, 14 June 200= 7 11:07 PM=0D=0A> > > To: Dawson, Martin; 'ECRIT'=0D=0A> > > Subject: RE: [= Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A> > >=0D=0A> > > Wa= it a minute, we're getting confused.=0D=0A> > >=0D=0A> > > Option 1 require= s that the access network dereference to anyone=0D=0Awith=0D=0A> > at=0D=0A= > > > least coarse location suitable for emergency call routing. If the=0D= =0A> > > endpoint=0D=0A> > > does routing, it will use a local LoST server = which has high=0D=0A> > probability=0D=0A> > > of=0D=0A> > > having the rou= te. If a VSP wants to verify, it needs access to a=0D=0A> LoST=0D=0A> > > = server covering the area where his customers roam. The cost is on=0D=0A> t= he=0D=0A> > > carrier that is trying to hide location (which, AFAIK, is an=0D= =0A> economic=0D=0A> > > issue=0D=0A> > > all the way, the hiding is so the= access network can charge for=0D=0Anon=0D=0A> > > emergency uses of locati= on).=0D=0A> > >=0D=0A> > > Option 3 requires that the access network derefe= rence to anyone=0D=0Awith=0D=0A> > at=0D=0A> > > least coarse location suit= able for emergency call routing. This=0D=0Ais=0D=0A> > > because=0D=0A> > = > if the endpoint doesn't route (or more specifically, if it doesn't=0D=0A>= > > recognize=0D=0A> > > emergency dialstrings, query LoST, and add the PS= AP URI), but does=0D=0A> > > supply=0D=0A> > > location, then the VSP has t= o route, and it will have to=0D=0A> dereference.=0D=0A> > > If=0D=0A> > > t= he endpoint does routing, option 3 is easy, because it will have=0D=0A> the=0D= =0A> > > correct PSAP URIs (it has to be all of them, BTW, a problem in=0D=0A= > > itself).=0D=0A> > > If=0D=0A> > > a VSP wants to verify, it needs acces= s to a LoST server covering=0D=0Athe=0D=0A> > > area=0D=0A> > > where his c= ustomers roam. It can't use the LCP, it has to=0D=0A> dereference=0D=0A> >= > the=0D=0A> > > location, and then query LoST.=0D=0A> > >=0D=0A> > > If w= e supply a different mechanism for a VSP to validate, that=0D=0Acould=0D=0A= > > > change,=0D=0A> > > and it would affect 1 and 3 the same way.=0D=0A> >= >=0D=0A> > > Brian=0D=0A> > >=0D=0A> > > > -----Original Message-----=0D=0A= > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> > > >= Sent: Wednesday, June 13, 2007 10:56 PM=0D=0A> > > > To: ECRIT=0D=0A> > > = > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A> >= > >=0D=0A> > > > Typo alert - obviously it should have said that option *1= *=0D=0A> requires=0D=0A> > > the=0D=0A> > > > VSP to work out the local LoS= T server in addition to the LIS=0D=0A> needing=0D=0A> > > to=0D=0A> > > > k= now it.=0D=0A> > > >=0D=0A> > > > Cheers,=0D=0A> > > > Martin=0D=0A> > > >=0D= =0A> > > > -----Original Message-----=0D=0A> > > > From: Dawson, Martin [ma= ilto:Martin.Dawson@andrew.com]=0D=0A> > > > Sent: Thursday, 14 June 2007 11= :14 AM=0D=0A> > > > To: Henning Schulzrinne; Winterbottom, James=0D=0A> > >= > Cc: ECRIT=0D=0A> > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary = of perspectives=0D=0A> > > >=0D=0A> > > > BTW - as I understand option 1, i= t requires the LIS to query the=0D=0A> > local=0D=0A> > > > LoST server as = well. At least that's how I recall Brian's=0D=0Aoriginal=0D=0A> > > > propo= sal being stated. It returns a "PSAP URI boundary" location=0D=0A> > > inst= ead=0D=0A> > > > of the PSAP URI.=0D=0A> > > >=0D=0A> > > > I think folk ar= e being inconsistent characterising option 3 as=0D=0A> > adding=0D=0A> > > = > LoST functionality to HELD. Both proposals require the LIS to=0D=0A> > in= teract=0D=0A> > > > with LoST with the subsequent proxying of results to th= e device.=0D=0A> > > >=0D=0A> > > > If the proposition of option 1 is that = it's actually the LIS=0D=0Athat=0D=0A> > > holds=0D=0A> > > > the PSAP-rele= vant boundary information, then option 1 is=0D=0Aactually=0D=0A> > much=0D=0A= > > > > more like adding LoST functionality to the LIS (and adds=0D=0A> > i= nappropriate=0D=0A> > > > responsibility to the LIS provider).=0D=0A> > > >=0D= =0A> > > > Further, given my understanding, both proposals rely on the LIS=0D= =0A> > > knowing=0D=0A> > > > inherently what the appropriate local LoST se= rver is. Option 1=0D=0A> just=0D=0A> > > > means that this is required *as = well as* the VSP being able to=0D=0A> reach=0D=0A> > > > that same local Lo= ST service.=0D=0A> > > >=0D=0A> > > > Neither option requires the ISP to im= plement LoST, they just=0D=0A> require=0D=0A> > > the=0D=0A> > > > ISP to k= now which LoST server is applicable to the local area of=0D=0A> > > > cover= age. That's much more practical than expecting any=0D=0Aarbitrary=0D=0A> > = > global=0D=0A> > > > VSP being able to work that out but that is what opti= on 3=0D=0Arequires=0D=0A> > *in=0D=0A> > > > addition*.=0D=0A> > > >=0D=0A>= > > > Cheers,=0D=0A> > > > Martin=0D=0A> > > >=0D=0A> > > > -----Original = Message-----=0D=0A> > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia= =2Eedu]=0D=0A> > > > Sent: Thursday, 14 June 2007 10:22 AM=0D=0A> > > > To:= Winterbottom, James=0D=0A> > > > Cc: ECRIT=0D=0A> > > > Subject: Re: [Ecri= t] Proposals 1 and 3 - summary of perspectives=0D=0A> > > >=0D=0A> > > > I = assume that your discussion has nothing to do with location=0D=0A> hiding=0D= =0A> > > > at this point, but wanted to call this out just in case I'm=0D=0A= > missing=0D=0A> > > > your train of thought.=0D=0A> > > >=0D=0A> > > > I'm= afraid I don't follow your logic. Unless you assume that=0D=0Aevery=0D=0A>= > > > ISP deploys a LoST+HELD server, VSPs will have to have LoST=0D=0A> s= ervers=0D=0A> > > > with PSAP knowledge for the places their customers are = likely to=0D=0A> > > > visit. This doesn't change whether HELD also gets co= nverted into=0D=0Aa=0D=0A> > > > LoST access protocol or not. So far, at le= ast, VSPs seem a whole=0D=0A> lot=0D=0A> > > > more interested in providing= emergency call services than ISPs,=0D=0A> > > > presumably because their c= ustomers look to them for that=0D=0Aservice,=0D=0A> > not=0D=0A> > > > to t= he random hot spot operator.=0D=0A> > > >=0D=0A> > > > It's always been the= model that both ISPs and VSPs (as well as=0D=0A> third=0D=0A> > > > partie= s that are neither) can and should operate LoST servers,=0D=0Aas=0D=0A> > >= > that seems most likely to ensure that you get broad coverage.=0D=0A> > >= >=0D=0A> > > > Henning=0D=0A> > > >=0D=0A> > > > On Jun 13, 2007, at 8:00 = PM, Winterbottom, James wrote:=0D=0A> > > >=0D=0A> > > > > Henning,=0D=0A> = > > > >=0D=0A> > > > > I think that your proposal only works if the VSP is = able to=0D=0A> > provide=0D=0A> > > a=0D=0A> > > > > LoST server for all ju= risdictions that it plans to provide=0D=0A> service=0D=0A> > > > > for,=0D=0A= > > > > > or it has to do it for everything (sounds awfully like a=0D=0Aglo= bal=0D=0A> > VPC=0D=0A> > > to=0D=0A> > > > > me). Option 3 would be deploy= able from a local area to a local=0D=0A> > PSAP=0D=0A> > > > > REGARDLESS o= f the VSP having a LoST server that has boundary=0D=0A> > > > > information=0D= =0A> > > > > for the local area I am in. It provides a global solution from=0D= =0A> the=0D=0A> > > > > get-go.=0D=0A> > > > >=0D=0A> > > > > Let's take th= e good old Sierra-Leone example again.=0D=0A> > > > >=0D=0A> > > > > My VSP= is in Sierra-Leone and I am visiting Samoa. In option=0D=0A3,=0D=0A> I=0D=0A= > > > > > get a=0D=0A> > > > > PSA P URI for the local Samoan PSAP from the= local access LIS=0D=0A> > > serving=0D=0A> > > > > the area I am in, I sen= d my call to VSP, it sends it on the=0D=0A> PSAP.=0D=0A> > I=0D=0A> > > > >= get=0D=0A> > > > > billed, call completes, we are done. I can quibble with= my VSP=0D=0A> > later=0D=0A> > > > > over the 10 cent call charge if I can= be bothered.=0D=0A> > > > >=0D=0A> > > > > With option 1, I send my call w= ith location to my VSP, and one=0D=0A> of=0D=0A> > > > > three=0D=0A> > > >= > things happens. Either it has a complete forest guide network=0D=0A> set= -=0D=0A> > > > > up to=0D=0A> > > > > be able to talk to the Samoan LoST se= rver nearest me, my call=0D=0A> > > > > fails, or=0D=0A> > > > > the VSP ro= utes the call anyway because the end-point has done=0D=0A> the=0D=0A> > > L= oST=0D=0A> > > > > lookup. I point out, that from the VSP perspective the t= hird=0D=0A> > > > > alternative=0D=0A> > > > > here is simply option 3 re-b= adged. I am sure that VSPs=0D=0Awouldn't=0D=0A> > > > > drop the=0D=0A> > >= > > call on the floor, so choice 2 isn't an option, and choice 1=0D=0Acan=0D= =0A> > > ONLY=0D=0A> > > > > occur if the whole network is up and running, = and it doesn't=0D=0A> > > > > consist of=0D=0A> > > > > isolated copse of F= orest Guides and LoST Servers.=0D=0A> > > > >=0D=0A> > > > > So to my mind,= option 3 is the ONLY deployable solution in the=0D=0A> > short=0D=0A> > > = > > term that will actually work universally.=0D=0A> > > > >=0D=0A> > > > >= Cheers=0D=0A> > > > > James=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > > > >> = -----Original Message-----=0D=0A> > > > >> From: Henning Schulzrinne [mailt= o:hgs@cs.columbia.edu]=0D=0A> > > > >> Sent: Thursday, 14 June 2007 12:58 A= M=0D=0A> > > > >> To: Dawson, Martin=0D=0A> > > > >> Cc: ecrit@ietf.org=0D=0A= > > > > >> Subject: Re: [Ecrit] Proposals 1 and 3 - summary of=0D=0A> persp= ectives=0D=0A> > > > >>=0D=0A> > > > >>=0D=0A> > > > >> On Jun 13, 2007, at= 10:54 AM, Dawson, Martin wrote:=0D=0A> > > > >>=0D=0A> > > > >>> Nobody ha= s suggested changing LoST so this point is just a=0D=0A> > > > >>> distract= ion.=0D=0A> > > > >>>=0D=0A> > > > >>>=0D=0A> > > > >>>=0D=0A> > > > >>> Op= tion 1 means that emergency calls will not be able to be=0D=0A> > routed=0D= =0A> > > > >>> until the forest guide network is implemented. Option 3=0D=0A= means=0D=0A> > that=0D=0A> > > > >>> emergency calls will be able to be rou= ted regardless of the=0D=0A> > state=0D=0A> > > > >>> of deployment of the = forest guide.=0D=0A> > > > >>>=0D=0A> > > > >>>=0D=0A> > > > >> This is not= true, at least for comparable installations. The=0D=0A> ISP=0D=0A> > > can=0D= =0A> > > > >> offer a LoST server that has the locally-relevant=0D=0Ainform= ation.=0D=0A> > Same=0D=0A> > > > >> for the VSP. This does not require a f= orest guide as such.=0D=0A> > > > >>=0D=0A> > > > >> ______________________= _________________________=0D=0A> > > > >> Ecrit mailing list=0D=0A> > > > >= > Ecrit@ietf.org=0D=0A> > > > >> https://www1.ietf.org/mailman/listinfo/ecr= it=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > >=0D=0A> ------------------------= ----------------------------------------------=0D=0A> > > >=0D=0A> > > > > = --------------------------=0D=0A> > > > > This message is for the designate= d recipient only and may=0D=0A> > > > > contain privileged, proprietary, or= otherwise private=0D=0A> information.=0D=0A> > > > > If you have received = it in error, please notify the sender=0D=0A> > > > > immediately and delete= the original. Any unauthorized use of=0D=0A> > > > > this email is prohib= ited.=0D=0A> > > > >=0D=0A> > >=0D=0A> ------------------------------------= ----------------------------------=0D=0A> > > >=0D=0A> > > > > ------------= --------------=0D=0A> > > > > [mf2]=0D=0A> > > > >=0D=0A> > > >=0D=0A> > > = >=0D=0A> > > > _______________________________________________=0D=0A> > > >= Ecrit mailing list=0D=0A> > > > Ecrit@ietf.org=0D=0A> > > > https://www1.i= etf.org/mailman/listinfo/ecrit=0D=0A> > > >=0D=0A> > > >=0D=0A> > >=0D=0A> = >=0D=0A>=0D=0A-------------------------------------------------------------= -----------=0D=0A> > > > ------------------------=0D=0A> > > > This message= is for the designated recipient only and may=0D=0A> > > > contain privileg= ed, proprietary, or otherwise private=0D=0Ainformation.=0D=0A> > > > If you= have received it in error, please notify the sender=0D=0A> > > > immediate= ly and delete the original. Any unauthorized use of=0D=0A> > > > this emai= l is prohibited.=0D=0A> > > >=0D=0A> > >=0D=0A> >=0D=0A>=0D=0A-------------= -----------------------------------------------------------=0D=0A> > > > --= ----------------------=0D=0A> > > > [mf2]=0D=0A> > > >=0D=0A> > > >=0D=0A> = > > > _______________________________________________=0D=0A> > > > Ecrit ma= iling list=0D=0A> > > > Ecrit@ietf.org=0D=0A> > > > https://www1.ietf.org/m= ailman/listinfo/ecrit=0D=0A> > > >=0D=0A> > > >=0D=0A> > >=0D=0A> >=0D=0A>=0D= =0A------------------------------------------------------------------------=0D= =0A> > > --=0D=0A> > > > ----------------------=0D=0A> > > > This message i= s for the designated recipient only and may=0D=0A> > > > contain privileged= , proprietary, or otherwise private=0D=0Ainformation.=0D=0A> > > > If you h= ave received it in error, please notify the sender=0D=0A> > > > immediately= and delete the original. Any unauthorized use of=0D=0A> > > > this email = is prohibited.=0D=0A> > > >=0D=0A> > >=0D=0A> >=0D=0A>=0D=0A---------------= ---------------------------------------------------------=0D=0A> > > --=0D=0A= > > > > ----------------------=0D=0A> > > > [mf2]=0D=0A> > > >=0D=0A> > > >=0D= =0A> > > > _______________________________________________=0D=0A> > > > Ecr= it mailing list=0D=0A> > > > Ecrit@ietf.org=0D=0A> > > > https://www1.ietf.= org/mailman/listinfo/ecrit=0D=0A> > >=0D=0A> > >=0D=0A> > >=0D=0A> >=0D=0A>=0D= =0A------------------------------------------------------------------------=0D= =0A> > --=0D=0A> > > ----------------------=0D=0A> > > This message is for = the designated recipient only and may=0D=0A> > > contain privileged, propri= etary, or otherwise private information.=0D=0A> > > If you have received it= in error, please notify the sender=0D=0A> > > immediately and delete the o= riginal. Any unauthorized use of=0D=0A> > > this email is prohibited.=0D=0A= > > >=0D=0A> >=0D=0A>=0D=0A------------------------------------------------= ------------------------=0D=0A> > --=0D=0A> > > ----------------------=0D=0A= > > > [mf2]=0D=0A> > >=0D=0A> > >=0D=0A> > > ______________________________= _________________=0D=0A> > > Ecrit mailing list=0D=0A> > > Ecrit@ietf.org=0D= =0A> > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> >=0D=0A> >=0D=0A= > >=0D=0A>=0D=0A-----------------------------------------------------------= -------------=0D=0A> --=0D=0A> > ----------------------=0D=0A> > This messa= ge is for the designated recipient only and may=0D=0A> > contain privileged= , proprietary, or otherwise private information.=0D=0A> > If you have recei= ved it in error, please notify the sender=0D=0A> > immediately and delete t= he original. Any unauthorized use of=0D=0A> > this email is prohibited.=0D= =0A> >=0D=0A>=0D=0A--------------------------------------------------------= ----------------=0D=0A> --=0D=0A> > ----------------------=0D=0A> > [mf2]=0D= =0A>=20=0D=0A>=20=0D=0A>=0D=0A---------------------------------------------= ---------------------------=0D=0A--=0D=0A> ----------------------=0D=0A> Th= is message is for the designated recipient only and may=0D=0A> contain priv= ileged, proprietary, or otherwise private information.=0D=0A> If you have r= eceived it in error, please notify the sender=0D=0A> immediately and delete= the original. Any unauthorized use of=0D=0A> this email is prohibited.=0D= =0A>=0D=0A-----------------------------------------------------------------= -------=0D=0A--=0D=0A> ----------------------=0D=0A> [mf2]=0D=0A=0D=0A=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0AThis message is for the designated recipient onl= y and may=0D=0Acontain privileged, proprietary, or otherwise private inform= ation. =20=0D=0AIf you have received it in error, please notify the sender=0D= =0Aimmediately and delete the original. Any unauthorized use of=0D=0Athis = email is prohibited.=0D=0A-------------------------------------------------= -----------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jun 17 23:15:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I07hv-0003iB-0b; Sun, 17 Jun 2007 23:15:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I07ht-0003hn-9Z; Sun, 17 Jun 2007 23:15:09 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I07hs-00012U-Uz; Sun, 17 Jun 2007 23:15:09 -0400 X-SEF-Processed: 5_0_0_910__2007_06_17_22_22_53 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 17 Jun 2007 22:22:53 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 17 Jun 2007 22:15:08 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] RE: [Ecrit] LoST Progress X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 17 Jun 2007 22:15:06 -0500 Message-ID: In-Reply-To: <46739FA3.80808@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: [Ecrit] LoST Progress Thread-Index: AcexUgujaglpY/LYRGur0WSOt+F0VgAA0D6A References: <005c01c7af52$0da82190$220d0d0a@amer.cisco.com> <46739FA3.80808@gmx.net> From: "Winterbottom, James" To: "Hannes Tschofenig" X-OriginalArrivalTime: 18 Jun 2007 03:15:08.0396 (UTC) FILETIME=[DFD572C0:01C7B156] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: GEOPRIV , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Hannes,=0D=0A=0D=0AThanks for the conciliatory response it is appreciate= d.=0D=0A=0D=0AI agree that the problem surfaced here, and as far the routin= g of a call=0D=0Agoes I am happy with that bit to stay in ECRIT. I just wan= ted it=0D=0Aacknowledged that providing location and location representatio= n is in=0D=0AGEORPIV space, and that that is where it would stay. I think y= ou have=0D=0Adone that, thanks.=0D=0A=0D=0AI agree that we want emergency c= alling to work, I guess that it just=0D=0Aisn't clear to me how if the end-= point is given a PSAP URI that it won't=0D=0Awork. Without a forest guide t= he VSP will have to trust the PSAP URI=0D=0Aanyway no matter what solution = is put in place.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A> -----Origi= nal Message-----=0D=0A> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@g= mx.net]=0D=0A> Sent: Saturday, 16 June 2007 6:30 PM=0D=0A> To: Winterbottom= , James=0D=0A> Cc: Marc Linsner; ECRIT; GEOPRIV=0D=0A> Subject: Re: [Geopri= v] RE: [Ecrit] LoST Progress=0D=0A>=20=0D=0A> Hi James,=0D=0A>=20=0D=0A> I = think we shouldn't get too focused on where the work takes place.=0D=0A> Af= ter all, we have a very good relationship with GEOPRIV and if we=0D=0A> fin= ally conclude that it would be better todo parts of the work in=0D=0A> GEOP= RIV than that will be fine as well.=0D=0A>=20=0D=0A> Still, the problem sur= faced in ECRIT as part of the location hiding=0D=0Afor=0D=0A> emergency cal= ls. That's what we care about. There may be other use=0D=0Acases=0D=0A> for= non-emergency services but so far we wanted to solve an emergency=0D=0A> s= ervices problem. Right=3F=0D=0A>=20=0D=0A> Ciao=0D=0A> Hannes=0D=0A>=20=0D=0A= > Winterbottom, James wrote:=0D=0A> > Please can somebody explain to me how= location hiding is an ECRIT=0D=0A> > charter item=3F=0D=0A> >=0D=0A> > I u= nderstand that IF, it changes LoST that it may have SOME=0D=0Anecessary=0D=0A= > > ECRIT work, but the core of everything to do with location hiding is=0D= =0Aon=0D=0A> > the access side, with how an end-point gets this stuff. This= is,=0D=0Awithout=0D=0A> > any doubt in my mind a geopriv concern, as it is= location=0D=0Ainformation of=0D=0A> > sorts.=0D=0A> >=0D=0A> > I am totall= y opposed to any charter change with in ECRIT to pick up=0D=0Awork=0D=0A> >= that has clear scope in a different WG.=0D=0A> >=0D=0A> > Cheers=0D=0A> > = James=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> >> -----Original Message--= ---=0D=0A> >> From: Marc Linsner [mailto:mlinsner@cisco.com]=0D=0A> >> Sent= : Friday, 15 June 2007 11:36 PM=0D=0A> >> To: 'ECRIT'=0D=0A> >> Subject: [E= crit] LoST Progress=0D=0A> >>=0D=0A> >> The ECRIT WG chairs have struggled = with the progress we made on the=0D=0A> >> discussions in context of the di= fferent proposals for providing=0D=0A> >>=0D=0A> > 'location=0D=0A> >=0D=0A= > >> hiding'.=0D=0A> >>=0D=0A> >> First, we started our discussion on the r= equirements quite late in=0D=0Athe=0D=0A> >> process, LoST has already been= through one working group last call.=0D=0A> >>=0D=0A> >> Second, there is = still confusion about the requirements and the=0D=0A> >> architecture=0D=0A= > >> surrounding 'location hiding'.=0D=0A> >>=0D=0A> >> We believe the requ= irements/solutions surrounding 'location hiding'=0D=0A> >>=0D=0A> > need=0D= =0A> >=0D=0A> >> further discussion. Hence, in the interest of moving forwa= rd and=0D=0A> >>=0D=0A> > meeting=0D=0A> >=0D=0A> >> our=0D=0A> >> stated (= already late) milestone, we are going to ask the authors to=0D=0A> >>=0D=0A= > > submit=0D=0A> >=0D=0A> >> LoST-06 with changes that came from the last = call process.=0D=0A> >>=0D=0A> >> It would be great to complete the documen= t as initially planned=0D=0Asince=0D=0A> >>=0D=0A> > it=0D=0A> >=0D=0A> >> = is=0D=0A> >> already delayed. We do expect to see more discussions in the=0D= =0Acontext=0D=0A> >>=0D=0A> > of=0D=0A> >=0D=0A> >> 'location hiding'. We w= ill work on a proposal for a charter update=0D=0Ato=0D=0A> >> reflect this = work and potentially other related activities.=0D=0A> >>=0D=0A> >> We hope = everyone will support this path forward.=0D=0A> >>=0D=0A> >> Marc & Hannes=0D= =0A> >>=0D=0A> >> _______________________________________________=0D=0A> >>= Ecrit mailing list=0D=0A> >> Ecrit@ietf.org=0D=0A> >> https://www1.ietf.or= g/mailman/listinfo/ecrit=0D=0A> >>=0D=0A> >=0D=0A> >=0D=0A-----------------= -------------------------------------------------------=0D=0A> ------------= ------------=0D=0A> > This message is for the designated recipient only and= may=0D=0A> > contain privileged, proprietary, or otherwise private informa= tion.=0D=0A> > If you have received it in error, please notify the sender=0D= =0A> > immediately and delete the original. Any unauthorized use of=0D=0A>= > this email is prohibited.=0D=0A> >=0D=0A--------------------------------= ----------------------------------------=0D=0A> ------------------------=0D= =0A> > [mf2]=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> > __________________________= _____________________=0D=0A> > Geopriv mailing list=0D=0A> > Geopriv@ietf.o= rg=0D=0A> > https://www1.ietf.org/mailman/listinfo/geopriv=0D=0A> >=0D=0A> =0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jun 17 23:47:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I08Ck-0006lb-PU; Sun, 17 Jun 2007 23:47:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I08Ci-0006lR-Me for ecrit@ietf.org; Sun, 17 Jun 2007 23:47:00 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I08Cg-0000dL-BD for ecrit@ietf.org; Sun, 17 Jun 2007 23:47:00 -0400 X-SEF-Processed: 5_0_0_910__2007_06_17_22_54_43 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 17 Jun 2007 22:54:42 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 17 Jun 2007 22:46:57 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 17 Jun 2007 22:46:56 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives Thread-Index: AceuGgIUdnorn1MfT9KY7XAHcoK3nAABWk3gAAP8qIAAFRhfQAAEcxKwAC1PJ0AAAMljcAADai4wABfBL7AAJiIUMABAPJGwAAFAENA= References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com><1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> < 087a01c7ae84$e1b48a10$9501a8c0@cis.neustar.com><0b8c01c7af4d$8e22b3d0$9501a8c0@cis.neustar.com><0bc401c7af5c$ddd16c50$9501a8c0@cis.neustar.com><0e4801c7b056$9c15d120$9501a8c0@cis.neustar.com> From: "Dawson, Martin" To: X-OriginalArrivalTime: 18 Jun 2007 03:46:57.0967 (UTC) FILETIME=[5206DBF0:01C7B15B] X-Spam-Score: 0.0 (/) X-Scan-Signature: d4a1871e876bd836d4c351e861e8720d X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian,=0D=0A=0D=0AI owe you an apology. I understood option 1 incorrectl= y (this has been=0D=0Athe disconnect). I've just had it pointed out to me t= hat option 1 also=0D=0Arelies on the LIS (or the end point) to obtain the P= SAP URI for the=0D=0Aendpoint to send it to the VSP along with the coarse l= ocation. I=0D=0Aunderstood that it was only the VSP that was going to do th= at (if the=0D=0AVSP was going to be involved in the call processing).=0D=0A=0D= =0ASo to correct my summary of the two methods:=0D=0A=0D=0AOption 1 (VSP ca= ll processing)=0D=0A1. The end-point queries the LIS which determines the l= ocation of the=0D=0Adevice=0D=0A2. The LIS queries LoST to obtain the PSAP = coverage (coarse location)=0D=0Aand PSAP URI=0D=0A3. The LIS provides the c= oarse location and (optionally=3F) the PSAP URI=0D=0A4. The end point (opti= onally=3F) queries LoST again for the PSAP URI=0D=0A5. The end point invoke= s the emergency call to the VSP with the coarse=0D=0Alocation and the PSAP = URI=0D=0A6. The VSP invokes the forest guide (if necessary) and queries LoS= T=0D=0Aagain to see if the PSAP URI that is returned is the same as the one=0D= =0Aprovided by the end point=0D=0A7. If the PSAP URI has "validated" then t= he call is processed.=0D=0A=0D=0AOption 3 (VSP call processing)=0D=0A1. The= end-point queries the LIS which determines the location of the=0D=0Adevice=0D= =0A2. The LIS queries LoST to obtain the PSAP URI for the location=0D=0A3. = The LIS provides the PSAP URI to the device=0D=0A4. The end point invokes t= he emergency call to the VSP with the PSAP URI=0D=0A5. The VSP routes the e= mergency call (and charges for it or not=0D=0Adepending on policy)=0D=0A=0D= =0AOption 1 requires the LIS operator to always provide location=0D=0Ainfor= mation - which is useful depending on the granularity required by=0D=0Athe = jurisdiction. The VSP might be able to validate the PSAP URI if the=0D=0Afo= rest guide exists or it happens to have the access to the LoST=0D=0Ainforma= tion one way or the other.=0D=0A=0D=0AOption 3 does not require the LIS ope= rator to provide any location. The=0D=0AVSP has to apply a policy on emerge= ncy calls in the absence of the=0D=0Aability validate the PSAP URI - at lea= st until such time as the forest=0D=0Aguide or other mechanism supports thi= s validation (text pending).=0D=0A=0D=0ADoes that summarize things more fai= rly=3F=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D= =0AFrom: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20=0D=0ASent: Mon= day, 18 June 2007 1:07 PM=0D=0ATo: Brian Rosen; ecrit@ietf.org=0D=0ASubject= : RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A=0D=0AI'd li= ke to challenge the following:=0D=0A=0D=0A" If there is no forest guide, th= e local LoST server is still highly=0D=0Alikely to have the route for the l= ocation the endpoint is given.=0D=0AEverything except=0D=0AVSP validation w= orks without forest guides."=0D=0A=0D=0AYou make it sound as if routing wil= l work without forest guides given=0D=0Aoption 1. It does not unless by (i= nsert miracle happens here) the VSP=0D=0Ahappens to have the foreign jurisd= iction LoST identity or a copy of the=0D=0Aforeign jurisdiction LoST inform= ation.=0D=0A=0D=0AI have only referred to "validation" in the context of th= is thread as=0D=0Ameaning "confirming that a nominal PSAP URI is a genuine = PSAP URI". So=0D=0Athat hasn't been a root of any confusion for me. I think= option 3 does=0D=0Aprovide validation of the PSAP URI because it is based = on the=0D=0Aunderstanding that the LIS acquires the URI from the local LoST= server.=0D=0A=0D=0AI guess what I object to is the precipitous settling on= option 1 (with=0D=0Aits inherent failure) before anybody has an option to = submit alternative=0D=0Atext in any form.=0D=0A=0D=0AIn the mean time, and = as you acknowledge below, both options 1 and 3=0D=0Ahave "commercial" compr= omises for one or other party and there's no=0D=0Aobjective way to give one= priority over the other on that basis.=0D=0A=0D=0AI would be interested in= hearing from others (than Brian) whether they=0D=0Athink scenario A or sce= nario B below are the best starting point for=0D=0Anow.=0D=0A=0D=0ACheers,=0D= =0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Brian Rosen [mai= lto:br@brianrosen.net]=20=0D=0ASent: Sunday, 17 June 2007 6:41 AM=0D=0ATo: = Dawson, Martin; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3 = - summary of perspectives=0D=0A=0D=0AMaybe we're getting ourselves confused= with the word "validation". An=0D=0Aendpoint would like to know that the = location it got was a valid=0D=0Alocation.=0D=0AIt can do that by querying = LoST. If it's given a reference and a PSAP=0D=0AURI,=0D=0Ait can't check i= t unless it does a dereference, gets some kind of=0D=0Alocation=0D=0Aand qu= eries LoST. So option 3 leaves the endpoint not being able to=0D=0Avalidat= e.=0D=0A=0D=0AIf an endpoint routes, some VSPs want to validate that the ro= ute the=0D=0Aendpoint handed it is valid. That's another form of validatio= n. Option=0D=0A3=0D=0Adoesn't provide any way for the VSP to validate that= the PSAP URI in the=0D=0ARequest URI is a bona fide PSAP URI.=0D=0A=0D=0AY= es, option 1 requires the LIS to provide a coarse location value for=0D=0Aa= nyone=0D=0Athat asks. It provides a way for the endpoint to validate that = the=0D=0Alocation=0D=0Aresults in a route to a PSAP, and it provides a way = for a VSP to=0D=0Avalidate=0D=0Athat the URI is a valid PSAP URI.=0D=0A=0D=0A= If there is no forest guide, the local LoST server is still highly=0D=0Alik= ely to=0D=0Ahave the route for the location the endpoint is given. Everyth= ing=0D=0Aexcept=0D=0AVSP validation works without forest guides. PSAP vali= dation requires=0D=0Athat=0D=0Athe VSP have access to the same LoST data th= at the endpoint does. In=0D=0Athe=0D=0Ageneral case, that means forest gui= des. There are lots of cases where=0D=0Athe=0D=0AVSP could reasonably get = access to the LoST data where MOST of his=0D=0Asubscribers are, but most is= not all, and forest guides would be=0D=0Arequired.=0D=0A=0D=0AWith option = 3, the LIS is highly likely to have access to LoST data=0D=0Acovering=0D=0A= it's service area, so no forest guides are needed. The endpoint can't=0D=0A= validate, so whether there are forest guides is moot. Same for VSP=0D=0Ava= lidation. =20=0D=0A=0D=0AThere is a document that describes how forest guid= es work. There has=0D=0Abeen=0D=0Adiscussion on this document, which has h= ad more than one revision. The=0D=0Aonly=0D=0Awords describing how option = 3 might provide validation are email=0D=0Adiscussions=0D=0Aof reverse looku= ps, and one email from you that said "The ability to=0D=0Averify=0D=0Aa des= tination PSAP URI as a valid emergency URI could be supported by=0D=0Arefer= ence to a relatively static table maintained by global=0D=0Acooperation."=0D= =0AThat is the extent of the discussion. There is no text.=0D=0A=0D=0AI mo= re or less understand how reverse lookup would work. I think we=0D=0Awould=0D= =0Ahave a significant piece of work to add that to the current LoST=0D=0Ado= cument.=0D=0AI think everyone agrees that now is not the time to do that wo= rk. If=0D=0Ayou=0D=0Aaccept VSP validation as a requirement, which I do (r= eluctantly, but=0D=0Athen I=0D=0Aaccept location hiding as a requirement ju= st as reluctantly) then we=0D=0Aneed=0D=0Asomething that doesn't need a cha= nge to LoST with the impact of reverse=0D=0Alookups. You have suggested so= mething. I think it won't work, but it's=0D=0Ahard to criticize because th= ere is no text. In your latest email, you=0D=0Ahave=0D=0Aanother idea, whi= ch I find equally unlikely to work, but again, there is=0D=0Ano=0D=0Atext t= o criticize.=0D=0A=0D=0AI don't really like option 3, but I could live with= it if there was a=0D=0Away=0D=0Afor the VSP to validate. I'd really like = a way for the endpoint to=0D=0Avalidate, but that is not quite so important= =2E I don't want to hold up=0D=0ALoST.=0D=0A=0D=0ASo, I'd say, in the abse= nce of a reasonable alternative, with text that=0D=0Ahas=0D=0Ahad some leve= l of review, and has at least a reasonable amount of=0D=0Aconsensus,=0D=0At= hat we document option 1 (in phonebcp) and keep working.=0D=0A=0D=0ABrian=0D= =0A> -----Original Message-----=0D=0A> From: Dawson, Martin [mailto:Martin.= Dawson@andrew.com]=0D=0A> Sent: Friday, June 15, 2007 10:25 PM=0D=0A> To: B= rian Rosen; ecrit@ietf.org=0D=0A> Subject: RE: [Ecrit] Proposals 1 and 3 - = summary of perspectives=0D=0A>=20=0D=0A> If the "normal case" is endpoint r= oute, then there's no need to=0D=0A> validate, right=3F So option 3 support= s this without any need to provide=0D=0A> location information. Option 1 re= quires it to provide location=0D=0A> information *for all requests* since i= t doesn't really know this is an=0D=0A> emergency scenario.=0D=0A>=20=0D=0A= > So - let's leave end-point route out of the discussion with the note=0D=0A= > that option 3 satisfies the location hiding requirement most=0D=0A> satis= factorily and without impact on VSP validation.=0D=0A>=20=0D=0A> Now - for = VSP route where the issue of URI validation comes up (which=0D=0Ais=0D=0A> = also purely a commercial issue AFAIK).=0D=0A>=20=0D=0A> A. If there's no fo= rest guide in place, option 1 doesn't allow the=0D=0A> emergency call to be= routed at all but at least nobody will have to=0D=0A> worry about whether = the non-call should be charged for or not.=0D=0A>=20=0D=0A> B. If there's n= o functional way to validate the proffered PSAP URI=0D=0Athen=0D=0A> option= 3 requires the VSP to decide whether to charge for the call or=0D=0A> not = based on its policy in this regard. However, the emergency call=0D=0Acan=0D= =0A> always be made regardless of the availability of a functional forest=0D= =0A> guide network.=0D=0A>=20=0D=0A> Your proposition is that scenario A is= preferable to scenario B. I=0D=0Athink=0D=0A> that is profoundly incorrect= =2E I think it's self-evidently so.=0D=0A>=20=0D=0A> You continually dismis= s any attempt on my part to start a discussion=0D=0A> about ways for a VSP = to validate the PSAP URI as "hand waving". Every=0D=0A> reasonable discussi= on based on a genuine desire to solve a problem=0D=0A> starts with those so= rts of suggestions. Your approach is a=0D=0A> self-fulfilling argument that= says there's no solution therefore there=0D=0A> can't be a solution, becau= se I'm simply not going to talk about one.=0D=0AHow=0D=0A> about a BCP that= says that PSAP URIs should follow a specific=0D=0Aconvention=0D=0A> in ter= ms of domain name structure=3F The VSP would only provide=0D=0Aemergency=0D= =0A> call tariffs to destinations that satisfy that BCP. Then somebody=0D=0A= > wanting to "scam a free call" would have to make sure that the called=0D=0A= > party URI met that form. Not particularly useful.=0D=0A>=20=0D=0A> There'= s no precedent for a US-based operator charging for emergency=0D=0A> calls = made by subscribers roaming in foreign jurisdictions. PSTN calls=0D=0A> (wh= ether cellular or wireline) are always handled by an operator in=0D=0Athat=0D= =0A> jurisdiction. In the case of cellular, it is handled by the roaming=0D= =0A> partner in that jurisdiction. VoIP is the first instance of the call=0D= =0A> processing occurring at the home provider end while the call occurs in=0D= =0A> the foreign jurisdiction. I think it's extremely unlikely that=0D=0Ach= arging=0D=0A> for emergency calls made in foreign jurisdictions would be il= legal.=0D=0A> There's only the barest shreds of legislation covering VoIP i= n any=0D=0A> respect at all at the moment.=0D=0A>=20=0D=0A> Cheers,=0D=0A> = Martin=0D=0A>=20=0D=0A> -----Original Message-----=0D=0A> From: Brian Rosen= [mailto:br@brianrosen.net]=0D=0A> Sent: Saturday, 16 June 2007 12:53 AM=0D= =0A> To: Dawson, Martin; ecrit@ietf.org=0D=0A> Subject: RE: [Ecrit] Proposa= ls 1 and 3 - summary of perspectives=0D=0A>=20=0D=0A> Huh=3F I said the no= rmal case is endpoint route. If the endpoint=0D=0Aroutes,=0D=0A> option 1 = is endpoint gets coarse location, endpoint queries LoST. No=0D=0A> forest=0D= =0A> guide.=0D=0A>=20=0D=0A> If the VSP routes, either option needs forest = guides.=0D=0A>=20=0D=0A> Option 1 and Option 3 need forest guides for the V= SP to validate.=0D=0A>=20=0D=0A> I don't see why a VSP would have a replica= of the LoST database, but=0D=0Aif=0D=0A> it=0D=0A> did, it wouldn't cover = the world. So unless it restricts nomading, it=0D=0A> has=0D=0A> to rely o= n forest guides to validate (or route). If it did have a=0D=0A> replica,=0D= =0A> it could have some non standard way to validate for the parts of the=0D= =0A> database it had. That's not a solution, that's an optimization. I=0D= =0A> don't=0D=0A> think you can handwave with "charge for foreign emergency= calls".=0D=0AThey=0D=0A> aren't "foreign" to the guy making them. I think= it would be illegal=0D=0Ain=0D=0A> the=0D=0A> U.S. for example, although t= he VSP may not be subject to U.S. law in=0D=0Aall=0D=0A> cases.=0D=0A>=20=0D= =0A> I think a reasonable strategy for a VSP attempting to validate is to=0D= =0A> arrange=0D=0A> forest guides, and to permit emergency calls from areas= where it=0D=0Acannot=0D=0A> get=0D=0A> coverage for without validation.=0D= =0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> > -----Original M= essage-----=0D=0A> > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D= =0A> > Sent: Friday, June 15, 2007 9:19 AM=0D=0A> > To: Brian Rosen; ecrit@= ietf.org=0D=0A> > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of persp= ectives=0D=0A> >=0D=0A> > OK - but there's a very significant qualitative d= ifference that you=0D=0A> > haven't acknowledged yet.=0D=0A> >=0D=0A> > Opt= ion 3 works without dependency on forest guides - it can work=0D=0A> > stra= ight away. Option 1 means that emergency calls will simply fail=0D=0Ato=0D=0A= > > route until a global and reliable forest guide infrastructure is in=0D=0A= > > place. As I said, that's completely independent of the question of=0D=0A= > > location hiding. Even if the LIS wasn't hiding location I'd still=0D=0A= > > recommend that the device acquires the PSAP URI from the local=0D=0A> s= ervices=0D=0A> > and not just hope that the VSP can do it for it.=0D=0A> >=0D= =0A> > If the VSP is really going to run its own copy of the LoST data for=0D= =0A> the=0D=0A> > area of coverage that it cares about, then it can use any= internal=0D=0A> > mechanism it likes to spot the matching PSAP URI in the = database. It=0D=0A> > doesn't have to talk LoST to its own infrastructure. = Barbara pointed=0D=0A> out=0D=0A> > that, as a VSP operator, she isn't goin= g to be so concerned about=0D=0A> those=0D=0A> > "foreign" emergency calls = anyway. I actually agree with the=0D=0Asentiments=0D=0A> > expressed that a= VSP should still have a mission to support=0D=0Aemergency=0D=0A> > calling= regardless of point of origin. In the spirit of Barbara's=0D=0A> > positio= n, however, perhaps it's still reasonable if they charge for=0D=0A> > those= "foreign" emergency calls.=0D=0A> >=0D=0A> > Main point - I think the abil= ity to provide global emergency service=0D=0A> as=0D=0A> > soon as possible= is a better goal than saying I'll wait until I can=0D=0Abe=0D=0A> > sure t= hat global emergency service can be provided for free before=0D=0Athe=0D=0A= > > service can be used at all.=0D=0A> >=0D=0A> > Cheers,=0D=0A> > Martin=0D= =0A> >=0D=0A> > -----Original Message-----=0D=0A> > From: Brian Rosen [mail= to:br@brianrosen.net]=0D=0A> > Sent: Friday, 15 June 2007 11:03 PM=0D=0A> >= To: Dawson, Martin; ecrit@ietf.org=0D=0A> > Subject: RE: [Ecrit] Proposals= 1 and 3 - summary of perspectives=0D=0A> >=0D=0A> > Yeah, you agree with m= e. You just want to ignore the VSP validation=0D=0A> > problem. I'd like = to ignore the location hiding problem, but we're=0D=0A> > stuck=0D=0A> > wi= th both.=0D=0A> >=0D=0A> > If you come up with some way other than allowing= the VSP to get=0D=0Acoarse=0D=0A> > location and using that to validate th= e PSAP URI, then we can use=0D=0Athat=0D=0A> > for=0D=0A> > option 1 or 3. = So far there is no other mechanism that we can use.=0D=0A> We=0D=0A> > can=0D= =0A> > extend LoST in some way to do it, but several of us are suggesting=0D= =0A> that=0D=0A> > we=0D=0A> > postpone that work and get LoST out now.=0D=0A= > >=0D=0A> > I certainly agree that the basic assumption that the access=0D= =0Aprovider,=0D=0A> > LoST=0D=0A> > server and PSAP are local to one anothe= r is a good one. It's what=0D=0A> makes=0D=0A> > option 1 or 3 possible, a= nd gives the greatest likelihood that the=0D=0A> > system=0D=0A> > will wor= k. I think having the VSP route is fairly easy, but=0D=0A"fairly"=0D=0A> >= means=0D=0A> > that we need forest guides so that callers that are remote = can be=0D=0A> > routed.=0D=0A> > I'd strongly prefer endpoints to route. T= hat will be much more=0D=0Alikely=0D=0A> > to=0D=0A> > work in all circumst= ances. It seems very unlikely to me that we=0D=0Awould=0D=0A> > have=0D=0A= > > a situation where the endpoint could supply location, but could not=0D=0A= do=0D=0A> > dialstring recognition and routing. Having the VSP supply loca= tion=0D=0A> AND=0D=0A> > route is really going to be difficult with VPNs an= d NATs, etc.=0D=0A> >=0D=0A> > With respect to who runs the servers, I beli= eve you are conflating=0D=0Atwo=0D=0A> > parts=0D=0A> > of the problem: who= is responsible for the data, and who runs the=0D=0A> actual=0D=0A> > serve= r. The PSAP is responsible for the data. It will probably run=0D=0Aa=0D=0A= > > server which anyone can use. However, I believe most access network=0D= =0A> > providers will want a copy of the data in a server they run. That=0D= =0Ais=0D=0A> > the=0D=0A> > purpose of the LoST mechanisms to maintain repl= icas of the data.=0D=0A> >=0D=0A> > Brian=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A>= > > -----Original Message-----=0D=0A> > > From: Dawson, Martin [mailto:Mar= tin.Dawson@andrew.com]=0D=0A> > > Sent: Friday, June 15, 2007 3:32 AM=0D=0A= > > > To: ecrit@ietf.org=0D=0A> > > Subject: RE: [Ecrit] Proposals 1 and 3 = - summary of perspectives=0D=0A> > >=0D=0A> > >=0D=0A> > > Speak for yourse= lf :) Your description of option 3 does not=0D=0A> correlate=0D=0A> > > wit= h my description or understanding of it. So, if there's=0D=0A> confusion,=0D= =0A> > > perhaps this is the root of it.=0D=0A> > >=0D=0A> > > In option 3 = - the access network doesn't determine coarse location=0D=0A> at=0D=0A> > >= all. It doesn't concern itself with coarse location. It uses the=0D=0A> > = precise=0D=0A> > > location that it determines for the device, queries the = local LoST=0D=0A> > > server and provides the resultant PSAP URI directly t= o the device.=0D=0A> At=0D=0A> > > this point the routing has been achieved= and the device can route=0D=0A> > > directly or via the VSP. When the PSAP= dereferences, it gets the=0D=0A> > precise=0D=0A> > > location from the LI= S. It is exactly because the routing is=0D=0Aachieved=0D=0A> > by=0D=0A> > = > just the local elements that this option doesn't have the Achilles=0D=0A>= > heel=0D=0A> > > of option 1 which requires the VSP, absolutely, to be ab= le to find=0D=0A> the=0D=0A> > > authoritative local LoST server. As I say,= for a very remote VSP=0D=0Aand=0D=0A> > no=0D=0A> > > functioning forest g= uide, it may very well not be able to.=0D=0A> > >=0D=0A> > > There's a basi= c principle here - emergency services are local to=0D=0Athe=0D=0A> > > call= er, the access network operator (and LIS) are local to the=0D=0A> caller,=0D= =0A> > > and the authoritative LoST server is going to most local to the=0D= =0A> > caller.=0D=0A> > > The ability to reliably route the call is going t= o be optimal if=0D=0A> it's=0D=0A> > > done between all these local entitie= s who are best placed to be=0D=0A> aware=0D=0A> > of=0D=0A> > > each other.= Waiting until the call scenario has geographically=0D=0A> > diverged=0D=0A= > > > to the VSP before attempting to determine routing is unnecessarily=0D= =0A> > > sub-optimal.=0D=0A> > >=0D=0A> > > In option 1 - how do you propos= e the access network determine the=0D=0A> > > "coarse location"=3F I believ= e your proposal is that it uses the=0D=0Alocal=0D=0A> > > LoST server appli= cable to its area of coverage and utilize the=0D=0A> > semantics=0D=0A> > >= of LoST which provide a PSAP boundary in the response. Can you=0D=0A> conf= irm=0D=0A> > > that this is your proposal=3F Otherwise, how would you antic= ipate=0D=0Athat=0D=0A> > the=0D=0A> > > access provider, who doesn't manage= the PSAP boundaries after all,=0D=0A> > would=0D=0A> > > know what is the = appropriate coarse location that will result in a=0D=0A> > > reliable respo= nse when LoST is queried=3F=0D=0A> > >=0D=0A> > > With respect to Henning's= comment about LoST services being=0D=0Aprovided=0D=0A> > by=0D=0A> > > ISP= s and/or VSPs, I didn't resonate with that. I would expect that=0D=0A> > Lo= ST=0D=0A> > > is emergency services specific and it is likely to be part of= some=0D=0A> > > jurisdictional function or some provider of services to th= at=0D=0A> > > jurisdictional function. I don't see that either ISPs or VSPs= are=0D=0A> > > qualified to manage the PSAP routing information contained = in a=0D=0ALoST=0D=0A> > > server.=0D=0A> > >=0D=0A> > > Cheers,=0D=0A> > > = Martin=0D=0A> > >=0D=0A> > > -----Original Message-----=0D=0A> > > From: Br= ian Rosen [mailto:br@brianrosen.net]=0D=0A> > > Sent: Thursday, 14 June 200= 7 11:07 PM=0D=0A> > > To: Dawson, Martin; 'ECRIT'=0D=0A> > > Subject: RE: [= Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A> > >=0D=0A> > > Wa= it a minute, we're getting confused.=0D=0A> > >=0D=0A> > > Option 1 require= s that the access network dereference to anyone=0D=0Awith=0D=0A> > at=0D=0A= > > > least coarse location suitable for emergency call routing. If the=0D= =0A> > > endpoint=0D=0A> > > does routing, it will use a local LoST server = which has high=0D=0A> > probability=0D=0A> > > of=0D=0A> > > having the rou= te. If a VSP wants to verify, it needs access to a=0D=0A> LoST=0D=0A> > > = server covering the area where his customers roam. The cost is on=0D=0A> t= he=0D=0A> > > carrier that is trying to hide location (which, AFAIK, is an=0D= =0A> economic=0D=0A> > > issue=0D=0A> > > all the way, the hiding is so the= access network can charge for=0D=0Anon=0D=0A> > > emergency uses of locati= on).=0D=0A> > >=0D=0A> > > Option 3 requires that the access network derefe= rence to anyone=0D=0Awith=0D=0A> > at=0D=0A> > > least coarse location suit= able for emergency call routing. This=0D=0Ais=0D=0A> > > because=0D=0A> > = > if the endpoint doesn't route (or more specifically, if it doesn't=0D=0A>= > > recognize=0D=0A> > > emergency dialstrings, query LoST, and add the PS= AP URI), but does=0D=0A> > > supply=0D=0A> > > location, then the VSP has t= o route, and it will have to=0D=0A> dereference.=0D=0A> > > If=0D=0A> > > t= he endpoint does routing, option 3 is easy, because it will have=0D=0A> the=0D= =0A> > > correct PSAP URIs (it has to be all of them, BTW, a problem in=0D=0A= > > itself).=0D=0A> > > If=0D=0A> > > a VSP wants to verify, it needs acces= s to a LoST server covering=0D=0Athe=0D=0A> > > area=0D=0A> > > where his c= ustomers roam. It can't use the LCP, it has to=0D=0A> dereference=0D=0A> >= > the=0D=0A> > > location, and then query LoST.=0D=0A> > >=0D=0A> > > If w= e supply a different mechanism for a VSP to validate, that=0D=0Acould=0D=0A= > > > change,=0D=0A> > > and it would affect 1 and 3 the same way.=0D=0A> >= >=0D=0A> > > Brian=0D=0A> > >=0D=0A> > > > -----Original Message-----=0D=0A= > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> > > >= Sent: Wednesday, June 13, 2007 10:56 PM=0D=0A> > > > To: ECRIT=0D=0A> > > = > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A> >= > >=0D=0A> > > > Typo alert - obviously it should have said that option *1= *=0D=0A> requires=0D=0A> > > the=0D=0A> > > > VSP to work out the local LoS= T server in addition to the LIS=0D=0A> needing=0D=0A> > > to=0D=0A> > > > k= now it.=0D=0A> > > >=0D=0A> > > > Cheers,=0D=0A> > > > Martin=0D=0A> > > >=0D= =0A> > > > -----Original Message-----=0D=0A> > > > From: Dawson, Martin [ma= ilto:Martin.Dawson@andrew.com]=0D=0A> > > > Sent: Thursday, 14 June 2007 11= :14 AM=0D=0A> > > > To: Henning Schulzrinne; Winterbottom, James=0D=0A> > >= > Cc: ECRIT=0D=0A> > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary = of perspectives=0D=0A> > > >=0D=0A> > > > BTW - as I understand option 1, i= t requires the LIS to query the=0D=0A> > local=0D=0A> > > > LoST server as = well. At least that's how I recall Brian's=0D=0Aoriginal=0D=0A> > > > propo= sal being stated. It returns a "PSAP URI boundary" location=0D=0A> > > inst= ead=0D=0A> > > > of the PSAP URI.=0D=0A> > > >=0D=0A> > > > I think folk ar= e being inconsistent characterising option 3 as=0D=0A> > adding=0D=0A> > > = > LoST functionality to HELD. Both proposals require the LIS to=0D=0A> > in= teract=0D=0A> > > > with LoST with the subsequent proxying of results to th= e device.=0D=0A> > > >=0D=0A> > > > If the proposition of option 1 is that = it's actually the LIS=0D=0Athat=0D=0A> > > holds=0D=0A> > > > the PSAP-rele= vant boundary information, then option 1 is=0D=0Aactually=0D=0A> > much=0D=0A= > > > > more like adding LoST functionality to the LIS (and adds=0D=0A> > i= nappropriate=0D=0A> > > > responsibility to the LIS provider).=0D=0A> > > >=0D= =0A> > > > Further, given my understanding, both proposals rely on the LIS=0D= =0A> > > knowing=0D=0A> > > > inherently what the appropriate local LoST se= rver is. Option 1=0D=0A> just=0D=0A> > > > means that this is required *as = well as* the VSP being able to=0D=0A> reach=0D=0A> > > > that same local Lo= ST service.=0D=0A> > > >=0D=0A> > > > Neither option requires the ISP to im= plement LoST, they just=0D=0A> require=0D=0A> > > the=0D=0A> > > > ISP to k= now which LoST server is applicable to the local area of=0D=0A> > > > cover= age. That's much more practical than expecting any=0D=0Aarbitrary=0D=0A> > = > global=0D=0A> > > > VSP being able to work that out but that is what opti= on 3=0D=0Arequires=0D=0A> > *in=0D=0A> > > > addition*.=0D=0A> > > >=0D=0A>= > > > Cheers,=0D=0A> > > > Martin=0D=0A> > > >=0D=0A> > > > -----Original = Message-----=0D=0A> > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia= =2Eedu]=0D=0A> > > > Sent: Thursday, 14 June 2007 10:22 AM=0D=0A> > > > To:= Winterbottom, James=0D=0A> > > > Cc: ECRIT=0D=0A> > > > Subject: Re: [Ecri= t] Proposals 1 and 3 - summary of perspectives=0D=0A> > > >=0D=0A> > > > I = assume that your discussion has nothing to do with location=0D=0A> hiding=0D= =0A> > > > at this point, but wanted to call this out just in case I'm=0D=0A= > missing=0D=0A> > > > your train of thought.=0D=0A> > > >=0D=0A> > > > I'm= afraid I don't follow your logic. Unless you assume that=0D=0Aevery=0D=0A>= > > > ISP deploys a LoST+HELD server, VSPs will have to have LoST=0D=0A> s= ervers=0D=0A> > > > with PSAP knowledge for the places their customers are = likely to=0D=0A> > > > visit. This doesn't change whether HELD also gets co= nverted into=0D=0Aa=0D=0A> > > > LoST access protocol or not. So far, at le= ast, VSPs seem a whole=0D=0A> lot=0D=0A> > > > more interested in providing= emergency call services than ISPs,=0D=0A> > > > presumably because their c= ustomers look to them for that=0D=0Aservice,=0D=0A> > not=0D=0A> > > > to t= he random hot spot operator.=0D=0A> > > >=0D=0A> > > > It's always been the= model that both ISPs and VSPs (as well as=0D=0A> third=0D=0A> > > > partie= s that are neither) can and should operate LoST servers,=0D=0Aas=0D=0A> > >= > that seems most likely to ensure that you get broad coverage.=0D=0A> > >= >=0D=0A> > > > Henning=0D=0A> > > >=0D=0A> > > > On Jun 13, 2007, at 8:00 = PM, Winterbottom, James wrote:=0D=0A> > > >=0D=0A> > > > > Henning,=0D=0A> = > > > >=0D=0A> > > > > I think that your proposal only works if the VSP is = able to=0D=0A> > provide=0D=0A> > > a=0D=0A> > > > > LoST server for all ju= risdictions that it plans to provide=0D=0A> service=0D=0A> > > > > for,=0D=0A= > > > > > or it has to do it for everything (sounds awfully like a=0D=0Aglo= bal=0D=0A> > VPC=0D=0A> > > to=0D=0A> > > > > me). Option 3 would be deploy= able from a local area to a local=0D=0A> > PSAP=0D=0A> > > > > REGARDLESS o= f the VSP having a LoST server that has boundary=0D=0A> > > > > information=0D= =0A> > > > > for the local area I am in. It provides a global solution from=0D= =0A> the=0D=0A> > > > > get-go.=0D=0A> > > > >=0D=0A> > > > > Let's take th= e good old Sierra-Leone example again.=0D=0A> > > > >=0D=0A> > > > > My VSP= is in Sierra-Leone and I am visiting Samoa. In option=0D=0A3,=0D=0A> I=0D=0A= > > > > > get a=0D=0A> > > > > PSA P URI for the local Samoan PSAP from the= local access LIS=0D=0A> > > serving=0D=0A> > > > > the area I am in, I sen= d my call to VSP, it sends it on the=0D=0A> PSAP.=0D=0A> > I=0D=0A> > > > >= get=0D=0A> > > > > billed, call completes, we are done. I can quibble with= my VSP=0D=0A> > later=0D=0A> > > > > over the 10 cent call charge if I can= be bothered.=0D=0A> > > > >=0D=0A> > > > > With option 1, I send my call w= ith location to my VSP, and one=0D=0A> of=0D=0A> > > > > three=0D=0A> > > >= > things happens. Either it has a complete forest guide network=0D=0A> set= -=0D=0A> > > > > up to=0D=0A> > > > > be able to talk to the Samoan LoST se= rver nearest me, my call=0D=0A> > > > > fails, or=0D=0A> > > > > the VSP ro= utes the call anyway because the end-point has done=0D=0A> the=0D=0A> > > L= oST=0D=0A> > > > > lookup. I point out, that from the VSP perspective the t= hird=0D=0A> > > > > alternative=0D=0A> > > > > here is simply option 3 re-b= adged. I am sure that VSPs=0D=0Awouldn't=0D=0A> > > > > drop the=0D=0A> > >= > > call on the floor, so choice 2 isn't an option, and choice 1=0D=0Acan=0D= =0A> > > ONLY=0D=0A> > > > > occur if the whole network is up and running, = and it doesn't=0D=0A> > > > > consist of=0D=0A> > > > > isolated copse of F= orest Guides and LoST Servers.=0D=0A> > > > >=0D=0A> > > > > So to my mind,= option 3 is the ONLY deployable solution in the=0D=0A> > short=0D=0A> > > = > > term that will actually work universally.=0D=0A> > > > >=0D=0A> > > > >= Cheers=0D=0A> > > > > James=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > > > >> = -----Original Message-----=0D=0A> > > > >> From: Henning Schulzrinne [mailt= o:hgs@cs.columbia.edu]=0D=0A> > > > >> Sent: Thursday, 14 June 2007 12:58 A= M=0D=0A> > > > >> To: Dawson, Martin=0D=0A> > > > >> Cc: ecrit@ietf.org=0D=0A= > > > > >> Subject: Re: [Ecrit] Proposals 1 and 3 - summary of=0D=0A> persp= ectives=0D=0A> > > > >>=0D=0A> > > > >>=0D=0A> > > > >> On Jun 13, 2007, at= 10:54 AM, Dawson, Martin wrote:=0D=0A> > > > >>=0D=0A> > > > >>> Nobody ha= s suggested changing LoST so this point is just a=0D=0A> > > > >>> distract= ion.=0D=0A> > > > >>>=0D=0A> > > > >>>=0D=0A> > > > >>>=0D=0A> > > > >>> Op= tion 1 means that emergency calls will not be able to be=0D=0A> > routed=0D= =0A> > > > >>> until the forest guide network is implemented. Option 3=0D=0A= means=0D=0A> > that=0D=0A> > > > >>> emergency calls will be able to be rou= ted regardless of the=0D=0A> > state=0D=0A> > > > >>> of deployment of the = forest guide.=0D=0A> > > > >>>=0D=0A> > > > >>>=0D=0A> > > > >> This is not= true, at least for comparable installations. The=0D=0A> ISP=0D=0A> > > can=0D= =0A> > > > >> offer a LoST server that has the locally-relevant=0D=0Ainform= ation.=0D=0A> > Same=0D=0A> > > > >> for the VSP. This does not require a f= orest guide as such.=0D=0A> > > > >>=0D=0A> > > > >> ______________________= _________________________=0D=0A> > > > >> Ecrit mailing list=0D=0A> > > > >= > Ecrit@ietf.org=0D=0A> > > > >> https://www1.ietf.org/mailman/listinfo/ecr= it=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > >=0D=0A> ------------------------= ----------------------------------------------=0D=0A> > > >=0D=0A> > > > > = --------------------------=0D=0A> > > > > This message is for the designate= d recipient only and may=0D=0A> > > > > contain privileged, proprietary, or= otherwise private=0D=0A> information.=0D=0A> > > > > If you have received = it in error, please notify the sender=0D=0A> > > > > immediately and delete= the original. Any unauthorized use of=0D=0A> > > > > this email is prohib= ited.=0D=0A> > > > >=0D=0A> > >=0D=0A> ------------------------------------= ----------------------------------=0D=0A> > > >=0D=0A> > > > > ------------= --------------=0D=0A> > > > > [mf2]=0D=0A> > > > >=0D=0A> > > >=0D=0A> > > = >=0D=0A> > > > _______________________________________________=0D=0A> > > >= Ecrit mailing list=0D=0A> > > > Ecrit@ietf.org=0D=0A> > > > https://www1.i= etf.org/mailman/listinfo/ecrit=0D=0A> > > >=0D=0A> > > >=0D=0A> > >=0D=0A> = >=0D=0A>=0D=0A-------------------------------------------------------------= -----------=0D=0A> > > > ------------------------=0D=0A> > > > This message= is for the designated recipient only and may=0D=0A> > > > contain privileg= ed, proprietary, or otherwise private=0D=0Ainformation.=0D=0A> > > > If you= have received it in error, please notify the sender=0D=0A> > > > immediate= ly and delete the original. Any unauthorized use of=0D=0A> > > > this emai= l is prohibited.=0D=0A> > > >=0D=0A> > >=0D=0A> >=0D=0A>=0D=0A-------------= -----------------------------------------------------------=0D=0A> > > > --= ----------------------=0D=0A> > > > [mf2]=0D=0A> > > >=0D=0A> > > >=0D=0A> = > > > _______________________________________________=0D=0A> > > > Ecrit ma= iling list=0D=0A> > > > Ecrit@ietf.org=0D=0A> > > > https://www1.ietf.org/m= ailman/listinfo/ecrit=0D=0A> > > >=0D=0A> > > >=0D=0A> > >=0D=0A> >=0D=0A>=0D= =0A------------------------------------------------------------------------=0D= =0A> > > --=0D=0A> > > > ----------------------=0D=0A> > > > This message i= s for the designated recipient only and may=0D=0A> > > > contain privileged= , proprietary, or otherwise private=0D=0Ainformation.=0D=0A> > > > If you h= ave received it in error, please notify the sender=0D=0A> > > > immediately= and delete the original. Any unauthorized use of=0D=0A> > > > this email = is prohibited.=0D=0A> > > >=0D=0A> > >=0D=0A> >=0D=0A>=0D=0A---------------= ---------------------------------------------------------=0D=0A> > > --=0D=0A= > > > > ----------------------=0D=0A> > > > [mf2]=0D=0A> > > >=0D=0A> > > >=0D= =0A> > > > _______________________________________________=0D=0A> > > > Ecr= it mailing list=0D=0A> > > > Ecrit@ietf.org=0D=0A> > > > https://www1.ietf.= org/mailman/listinfo/ecrit=0D=0A> > >=0D=0A> > >=0D=0A> > >=0D=0A> >=0D=0A>=0D= =0A------------------------------------------------------------------------=0D= =0A> > --=0D=0A> > > ----------------------=0D=0A> > > This message is for = the designated recipient only and may=0D=0A> > > contain privileged, propri= etary, or otherwise private information.=0D=0A> > > If you have received it= in error, please notify the sender=0D=0A> > > immediately and delete the o= riginal. Any unauthorized use of=0D=0A> > > this email is prohibited.=0D=0A= > > >=0D=0A> >=0D=0A>=0D=0A------------------------------------------------= ------------------------=0D=0A> > --=0D=0A> > > ----------------------=0D=0A= > > > [mf2]=0D=0A> > >=0D=0A> > >=0D=0A> > > ______________________________= _________________=0D=0A> > > Ecrit mailing list=0D=0A> > > Ecrit@ietf.org=0D= =0A> > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> >=0D=0A> >=0D=0A= > >=0D=0A>=0D=0A-----------------------------------------------------------= -------------=0D=0A> --=0D=0A> > ----------------------=0D=0A> > This messa= ge is for the designated recipient only and may=0D=0A> > contain privileged= , proprietary, or otherwise private information.=0D=0A> > If you have recei= ved it in error, please notify the sender=0D=0A> > immediately and delete t= he original. Any unauthorized use of=0D=0A> > this email is prohibited.=0D= =0A> >=0D=0A>=0D=0A--------------------------------------------------------= ----------------=0D=0A> --=0D=0A> > ----------------------=0D=0A> > [mf2]=0D= =0A>=20=0D=0A>=20=0D=0A>=0D=0A---------------------------------------------= ---------------------------=0D=0A--=0D=0A> ----------------------=0D=0A> Th= is message is for the designated recipient only and may=0D=0A> contain priv= ileged, proprietary, or otherwise private information.=0D=0A> If you have r= eceived it in error, please notify the sender=0D=0A> immediately and delete= the original. Any unauthorized use of=0D=0A> this email is prohibited.=0D= =0A>=0D=0A-----------------------------------------------------------------= -------=0D=0A--=0D=0A> ----------------------=0D=0A> [mf2]=0D=0A=0D=0A=0D=0A= ------------------------------------------------------------------------=0D= =0A------------------------=0D=0AThis message is for the designated recipie= nt only and may=0D=0Acontain privileged, proprietary, or otherwise private = information. =20=0D=0AIf you have received it in error, please notify the s= ender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------=0D=0A------------------------=0D=0A[mf2]=0D= =0A=0D=0A=0D=0A_______________________________________________=0D=0AEcrit m= ailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/listinfo= /ecrit=0D=0A=0D=0A---------------------------------------------------------= ---------------------------------------=0D=0AThis message is for the design= ated recipient only and may=0D=0Acontain privileged, proprietary, or otherw= ise private information. =20=0D=0AIf you have received it in error, please = notify the sender=0D=0Aimmediately and delete the original. Any unauthoriz= ed use of=0D=0Athis email is prohibited.=0D=0A-----------------------------= -------------------------------------------------------------------=0D=0A[m= f2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jun 17 23:51:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I08HP-00035y-TF; Sun, 17 Jun 2007 23:51:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I08HP-00035r-Bo for ecrit@ietf.org; Sun, 17 Jun 2007 23:51:51 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I08HO-0001zs-7a for ecrit@ietf.org; Sun, 17 Jun 2007 23:51:51 -0400 X-SEF-Processed: 5_0_0_910__2007_06_17_22_59_34 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 17 Jun 2007 22:59:34 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 17 Jun 2007 22:51:49 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 17 Jun 2007 22:51:47 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives Thread-Index: AceuGgIUdnorn1MfT9KY7XAHcoK3nAABWk3gAAP8qIAAFRhfQAAEcxKwAC1PJ0AAAMljcAADai4wABfBL7AAJiIUMAA467ogAAgzyuA= References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com><1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu>< 087a01c7ae84$e1b48a10$9501a8c0@cis.neustar.com><0b8c01c7af4d$8e22b3d0$9501a8c0@cis.neustar.com><0bc401c7af5c$ddd16c50$9501a8c0@cis.neustar.com> <0e4801c7b056$9c15d120$9501a8c0@cis.neustar.com> From: "Dawson, Martin" To: X-OriginalArrivalTime: 18 Jun 2007 03:51:49.0760 (UTC) FILETIME=[FFF2F000:01C7B15B] X-Spam-Score: 0.0 (/) X-Scan-Signature: c40ff0c70161549dbde2f89c7946385a X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi James,=0D=0A=0D=0AA counter perspective.=0D=0A=0D=0AI'm currently logged= on with Skype. I use it multiple times every day -=0D=0Abecause it can wor= k anywhere I am (like in a Singapore hotel at the=0D=0Amoment) as I know yo= u do.=0D=0A=0D=0AAccording to the Skype client, there are currently 5,166,7= 96 users on=0D=0Aline. These users are spread over the globe and, I would s= uggest, that=0D=0Avery few of them are local to the VSP - wherever that may= be.=0D=0A=0D=0AIt doesn't really matter whether we think that Skype is typ= ical of what=0D=0AVoIP is or will become (I think it is, because I can't un= derstand why it=0D=0Awouldn't). Regardless, it represents the extreme scena= rio that we need=0D=0Ato address. We cannot assume any proportional represe= ntation of local=0D=0Aversus foreign subscribers.=0D=0A=0D=0AThat's why we = need to rely on the local infrastructure when it comes to=0D=0Aprocessing e= mergency calls. We could go to the 3GPP extreme and=0D=0A*require* the call= processing to be part of the local network as well.=0D=0AWhen an end-point= routes directly to the PSAP URI, this is effectively=0D=0Awhat happens. Un= like 3GPP, ECRIT/i3 doesn't actually require the access=0D=0Anetwork to hav= e a local call session control function that has a=0D=0Arelationship with t= he VSP.=0D=0A=0D=0AIf we are going to permit the scenario where the home VS= P participates=0D=0Ain the routing according to the ECRIT/i3 model, then we= need to reduce=0D=0Athe amount of "caller-local" knowledge that the VSP ha= s to have and=0D=0Amaximize the use of the "caller-local" network resources= =2E=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D= =0AFrom: Winterbottom, James=20=0D=0ASent: Monday, 18 June 2007 9:34 AM=0D=0A= To: Brian Rosen; Dawson, Martin; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] P= roposals 1 and 3 - summary of perspectives=0D=0A=0D=0AI would like to bring= your attention to something that Barbara Stark has=0D=0Asaid a couple of t= imes now.=0D=0A=0D=0AIf the calls are national, then the potential list (ev= en if there is one=0D=0Aper PSAP in the USA) is not unmanageable. So that c= an easily be kept=0D=0Alocal. There is no mandate, or precedent for allowin= g free international=0D=0Aemergency calls, so why set one=3F=0D=0A=0D=0AIn = short, this problem quite simply doesn't warrant a complex reverse=0D=0ALoS= T lookup at this point. We are talking a sub 1% of emergency calls,=0D=0Aan= d these calls won't fail, they will just be billed until the=0D=0Adestinati= on URI can be confirmed. What happened to the old 90% rule,=0D=0Athis probl= em isn't even in the 1% category!=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Brian Rosen [mailt= o:br@brianrosen.net]=0D=0A> Sent: Sunday, 17 June 2007 6:41 AM=0D=0A> To: D= awson, Martin; ecrit@ietf.org=0D=0A> Subject: RE: [Ecrit] Proposals 1 and 3= - summary of perspectives=0D=0A>=20=0D=0A> Maybe we're getting ourselves c= onfused with the word "validation". An=0D=0A> endpoint would like to know = that the location it got was a valid=0D=0Alocation.=0D=0A> It can do that b= y querying LoST. If it's given a reference and a PSAP=0D=0A> URI,=0D=0A> i= t can't check it unless it does a dereference, gets some kind of=0D=0Alocat= ion=0D=0A> and queries LoST. So option 3 leaves the endpoint not being abl= e to=0D=0A> validate.=0D=0A>=20=0D=0A> If an endpoint routes, some VSPs wan= t to validate that the route the=0D=0A> endpoint handed it is valid. That'= s another form of validation.=0D=0AOption 3=0D=0A> doesn't provide any way = for the VSP to validate that the PSAP URI in=0D=0Athe=0D=0A> Request URI is= a bona fide PSAP URI.=0D=0A>=20=0D=0A> Yes, option 1 requires the LIS to p= rovide a coarse location value for=0D=0A> anyone=0D=0A> that asks. It prov= ides a way for the endpoint to validate that the=0D=0A> location=0D=0A> res= ults in a route to a PSAP, and it provides a way for a VSP to=0D=0Avalidate=0D= =0A> that the URI is a valid PSAP URI.=0D=0A>=20=0D=0A> If there is no fore= st guide, the local LoST server is still highly=0D=0Alikely=0D=0A> to=0D=0A= > have the route for the location the endpoint is given. Everything=0D=0Ae= xcept=0D=0A> VSP validation works without forest guides. PSAP validation r= equires=0D=0Athat=0D=0A> the VSP have access to the same LoST data that the= endpoint does. In=0D=0Athe=0D=0A> general case, that means forest guides.= There are lots of cases where=0D=0Athe=0D=0A> VSP could reasonably get ac= cess to the LoST data where MOST of his=0D=0A> subscribers are, but most is= not all, and forest guides would be=0D=0Arequired.=0D=0A>=20=0D=0A> With o= ption 3, the LIS is highly likely to have access to LoST data=0D=0A> coveri= ng=0D=0A> it's service area, so no forest guides are needed. The endpoint = can't=0D=0A> validate, so whether there are forest guides is moot. Same fo= r VSP=0D=0A> validation.=0D=0A>=20=0D=0A> There is a document that describe= s how forest guides work. There has=0D=0Abeen=0D=0A> discussion on this do= cument, which has had more than one revision.=0D=0AThe=0D=0A> only=0D=0A> w= ords describing how option 3 might provide validation are email=0D=0A> disc= ussions=0D=0A> of reverse lookups, and one email from you that said "The ab= ility to=0D=0A> verify=0D=0A> a destination PSAP URI as a valid emergency U= RI could be supported by=0D=0A> reference to a relatively static table main= tained by global=0D=0Acooperation."=0D=0A> That is the extent of the discus= sion. There is no text.=0D=0A>=20=0D=0A> I more or less understand how rev= erse lookup would work. I think we=0D=0Awould=0D=0A> have a significant pi= ece of work to add that to the current LoST=0D=0Adocument.=0D=0A> I think e= veryone agrees that now is not the time to do that work. If=0D=0Ayou=0D=0A= > accept VSP validation as a requirement, which I do (reluctantly, but=0D=0A= then=0D=0A> I=0D=0A> accept location hiding as a requirement just as reluct= antly) then we=0D=0Aneed=0D=0A> something that doesn't need a change to LoS= T with the impact of=0D=0Areverse=0D=0A> lookups. You have suggested somet= hing. I think it won't work, but=0D=0Ait's=0D=0A> hard to criticize becaus= e there is no text. In your latest email, you=0D=0A> have=0D=0A> another i= dea, which I find equally unlikely to work, but again, there=0D=0Ais=0D=0A>= no=0D=0A> text to criticize.=0D=0A>=20=0D=0A> I don't really like option 3= , but I could live with it if there was a=0D=0Away=0D=0A> for the VSP to va= lidate. I'd really like a way for the endpoint to=0D=0A> validate, but tha= t is not quite so important. I don't want to hold up=0D=0A> LoST.=0D=0A> =0D= =0A> So, I'd say, in the absence of a reasonable alternative, with text=0D=0A= that=0D=0A> has=0D=0A> had some level of review, and has at least a reasona= ble amount of=0D=0A> consensus,=0D=0A> that we document option 1 (in phoneb= cp) and keep working.=0D=0A>=20=0D=0A> Brian=0D=0A> > -----Original Message= -----=0D=0A> > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A= > > Sent: Friday, June 15, 2007 10:25 PM=0D=0A> > To: Brian Rosen; ecrit@ie= tf.org=0D=0A> > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspec= tives=0D=0A> >=0D=0A> > If the "normal case" is endpoint route, then there'= s no need to=0D=0A> > validate, right=3F So option 3 supports this without = any need to=0D=0Aprovide=0D=0A> > location information. Option 1 requires i= t to provide location=0D=0A> > information *for all requests* since it does= n't really know this is=0D=0Aan=0D=0A> > emergency scenario.=0D=0A> >=0D=0A= > > So - let's leave end-point route out of the discussion with the note=0D= =0A> > that option 3 satisfies the location hiding requirement most=0D=0A> = > satisfactorily and without impact on VSP validation.=0D=0A> >=0D=0A> > No= w - for VSP route where the issue of URI validation comes up=0D=0A(which is=0D= =0A> > also purely a commercial issue AFAIK).=0D=0A> >=0D=0A> > A. If there= 's no forest guide in place, option 1 doesn't allow the=0D=0A> > emergency = call to be routed at all but at least nobody will have to=0D=0A> > worry ab= out whether the non-call should be charged for or not.=0D=0A> >=0D=0A> > B.= If there's no functional way to validate the proffered PSAP URI=0D=0Athen=0D= =0A> > option 3 requires the VSP to decide whether to charge for the call=0D= =0Aor=0D=0A> > not based on its policy in this regard. However, the emergen= cy call=0D=0Acan=0D=0A> > always be made regardless of the availability of = a functional forest=0D=0A> > guide network.=0D=0A> >=0D=0A> > Your proposit= ion is that scenario A is preferable to scenario B. I=0D=0Athink=0D=0A> > t= hat is profoundly incorrect. I think it's self-evidently so.=0D=0A> >=0D=0A= > > You continually dismiss any attempt on my part to start a discussion=0D= =0A> > about ways for a VSP to validate the PSAP URI as "hand waving".=0D=0A= Every=0D=0A> > reasonable discussion based on a genuine desire to solve a p= roblem=0D=0A> > starts with those sorts of suggestions. Your approach is a=0D= =0A> > self-fulfilling argument that says there's no solution therefore=0D=0A= there=0D=0A> > can't be a solution, because I'm simply not going to talk ab= out one.=0D=0AHow=0D=0A> > about a BCP that says that PSAP URIs should foll= ow a specific=0D=0Aconvention=0D=0A> > in terms of domain name structure=3F= The VSP would only provide=0D=0Aemergency=0D=0A> > call tariffs to destina= tions that satisfy that BCP. Then somebody=0D=0A> > wanting to "scam a free= call" would have to make sure that the=0D=0Acalled=0D=0A> > party URI met = that form. Not particularly useful.=0D=0A> >=0D=0A> > There's no precedent = for a US-based operator charging for emergency=0D=0A> > calls made by subsc= ribers roaming in foreign jurisdictions. PSTN=0D=0Acalls=0D=0A> > (whether = cellular or wireline) are always handled by an operator in=0D=0Athat=0D=0A>= > jurisdiction. In the case of cellular, it is handled by the roaming=0D=0A= > > partner in that jurisdiction. VoIP is the first instance of the call=0D= =0A> > processing occurring at the home provider end while the call occurs=0D= =0Ain=0D=0A> > the foreign jurisdiction. I think it's extremely unlikely th= at=0D=0Acharging=0D=0A> > for emergency calls made in foreign jurisdictions= would be illegal.=0D=0A> > There's only the barest shreds of legislation c= overing VoIP in any=0D=0A> > respect at all at the moment.=0D=0A> >=0D=0A> = > Cheers,=0D=0A> > Martin=0D=0A> >=0D=0A> > -----Original Message-----=0D=0A= > > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > Sent: Saturday, 1= 6 June 2007 12:53 AM=0D=0A> > To: Dawson, Martin; ecrit@ietf.org=0D=0A> > S= ubject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A> >=0D= =0A> > Huh=3F I said the normal case is endpoint route. If the endpoint=0D= =0Aroutes,=0D=0A> > option 1 is endpoint gets coarse location, endpoint que= ries LoST.=0D=0ANo=0D=0A> > forest=0D=0A> > guide.=0D=0A> >=0D=0A> > If the= VSP routes, either option needs forest guides.=0D=0A> >=0D=0A> > Option 1 = and Option 3 need forest guides for the VSP to validate.=0D=0A> >=0D=0A> > = I don't see why a VSP would have a replica of the LoST database, but=0D=0Ai= f=0D=0A> > it=0D=0A> > did, it wouldn't cover the world. So unless it rest= ricts nomading,=0D=0Ait=0D=0A> > has=0D=0A> > to rely on forest guides to v= alidate (or route). If it did have a=0D=0A> > replica,=0D=0A> > it could h= ave some non standard way to validate for the parts of the=0D=0A> > databas= e it had. That's not a solution, that's an optimization. I=0D=0A> > don't=0D= =0A> > think you can handwave with "charge for foreign emergency calls".=0D= =0AThey=0D=0A> > aren't "foreign" to the guy making them. I think it would= be=0D=0Aillegal in=0D=0A> > the=0D=0A> > U.S. for example, although the VS= P may not be subject to U.S. law in=0D=0Aall=0D=0A> > cases.=0D=0A> >=0D=0A= > > I think a reasonable strategy for a VSP attempting to validate is to=0D= =0A> > arrange=0D=0A> > forest guides, and to permit emergency calls from a= reas where it=0D=0Acannot=0D=0A> > get=0D=0A> > coverage for without valida= tion.=0D=0A> >=0D=0A> > Brian=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> > > -----Or= iginal Message-----=0D=0A> > > From: Dawson, Martin [mailto:Martin.Dawson@a= ndrew.com]=0D=0A> > > Sent: Friday, June 15, 2007 9:19 AM=0D=0A> > > To: Br= ian Rosen; ecrit@ietf.org=0D=0A> > > Subject: RE: [Ecrit] Proposals 1 and 3= - summary of perspectives=0D=0A> > >=0D=0A> > > OK - but there's a very si= gnificant qualitative difference that=0D=0Ayou=0D=0A> > > haven't acknowled= ged yet.=0D=0A> > >=0D=0A> > > Option 3 works without dependency on forest = guides - it can work=0D=0A> > > straight away. Option 1 means that emergenc= y calls will simply=0D=0Afail to=0D=0A> > > route until a global and reliab= le forest guide infrastructure is=0D=0Ain=0D=0A> > > place. As I said, that= 's completely independent of the question of=0D=0A> > > location hiding. Ev= en if the LIS wasn't hiding location I'd still=0D=0A> > > recommend that th= e device acquires the PSAP URI from the local=0D=0A> > services=0D=0A> > > = and not just hope that the VSP can do it for it.=0D=0A> > >=0D=0A> > > If t= he VSP is really going to run its own copy of the LoST data=0D=0Afor=0D=0A>= > the=0D=0A> > > area of coverage that it cares about, then it can use any= internal=0D=0A> > > mechanism it likes to spot the matching PSAP URI in th= e database.=0D=0AIt=0D=0A> > > doesn't have to talk LoST to its own infrast= ructure. Barbara=0D=0Apointed=0D=0A> > out=0D=0A> > > that, as a VSP operat= or, she isn't going to be so concerned about=0D=0A> > those=0D=0A> > > "for= eign" emergency calls anyway. I actually agree with the=0D=0Asentiments=0D=0A= > > > expressed that a VSP should still have a mission to support=0D=0Aemer= gency=0D=0A> > > calling regardless of point of origin. In the spirit of Ba= rbara's=0D=0A> > > position, however, perhaps it's still reasonable if they= charge=0D=0Afor=0D=0A> > > those "foreign" emergency calls.=0D=0A> > >=0D=0A= > > > Main point - I think the ability to provide global emergency=0D=0Aser= vice=0D=0A> > as=0D=0A> > > soon as possible is a better goal than saying I= 'll wait until I=0D=0Acan be=0D=0A> > > sure that global emergency service = can be provided for free before=0D=0Athe=0D=0A> > > service can be used at = all.=0D=0A> > >=0D=0A> > > Cheers,=0D=0A> > > Martin=0D=0A> > >=0D=0A> > > = -----Original Message-----=0D=0A> > > From: Brian Rosen [mailto:br@brianros= en.net]=0D=0A> > > Sent: Friday, 15 June 2007 11:03 PM=0D=0A> > > To: Dawso= n, Martin; ecrit@ietf.org=0D=0A> > > Subject: RE: [Ecrit] Proposals 1 and 3= - summary of perspectives=0D=0A> > >=0D=0A> > > Yeah, you agree with me. = You just want to ignore the VSP=0D=0Avalidation=0D=0A> > > problem. I'd li= ke to ignore the location hiding problem, but=0D=0Awe're=0D=0A> > > stuck=0D= =0A> > > with both.=0D=0A> > >=0D=0A> > > If you come up with some way othe= r than allowing the VSP to get=0D=0Acoarse=0D=0A> > > location and using th= at to validate the PSAP URI, then we can use=0D=0Athat=0D=0A> > > for=0D=0A= > > > option 1 or 3. So far there is no other mechanism that we can=0D=0Au= se.=0D=0A> > We=0D=0A> > > can=0D=0A> > > extend LoST in some way to do it,= but several of us are suggesting=0D=0A> > that=0D=0A> > > we=0D=0A> > > po= stpone that work and get LoST out now.=0D=0A> > >=0D=0A> > > I certainly ag= ree that the basic assumption that the access=0D=0Aprovider,=0D=0A> > > LoS= T=0D=0A> > > server and PSAP are local to one another is a good one. It's = what=0D=0A> > makes=0D=0A> > > option 1 or 3 possible, and gives the greate= st likelihood that the=0D=0A> > > system=0D=0A> > > will work. I think hav= ing the VSP route is fairly easy, but=0D=0A"fairly"=0D=0A> > > means=0D=0A>= > > that we need forest guides so that callers that are remote can be=0D=0A= > > > routed.=0D=0A> > > I'd strongly prefer endpoints to route. That will= be much more=0D=0Alikely=0D=0A> > > to=0D=0A> > > work in all circumstance= s. It seems very unlikely to me that we=0D=0Awould=0D=0A> > > have=0D=0A> = > > a situation where the endpoint could supply location, but could=0D=0Ano= t do=0D=0A> > > dialstring recognition and routing. Having the VSP supply=0D= =0Alocation=0D=0A> > AND=0D=0A> > > route is really going to be difficult w= ith VPNs and NATs, etc.=0D=0A> > >=0D=0A> > > With respect to who runs the = servers, I believe you are conflating=0D=0Atwo=0D=0A> > > parts=0D=0A> > > = of the problem: who is responsible for the data, and who runs the=0D=0A> > = actual=0D=0A> > > server. The PSAP is responsible for the data. It will p= robably=0D=0Arun a=0D=0A> > > server which anyone can use. However, I beli= eve most access=0D=0Anetwork=0D=0A> > > providers will want a copy of the d= ata in a server they run. That=0D=0Ais=0D=0A> > > the=0D=0A> > > purpose o= f the LoST mechanisms to maintain replicas of the data.=0D=0A> > >=0D=0A> >= > Brian=0D=0A> > >=0D=0A> > >=0D=0A> > >=0D=0A> > > > -----Original Messag= e-----=0D=0A> > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D= =0A> > > > Sent: Friday, June 15, 2007 3:32 AM=0D=0A> > > > To: ecrit@ietf.= org=0D=0A> > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspe= ctives=0D=0A> > > >=0D=0A> > > >=0D=0A> > > > Speak for yourself :) Your de= scription of option 3 does not=0D=0A> > correlate=0D=0A> > > > with my desc= ription or understanding of it. So, if there's=0D=0A> > confusion,=0D=0A> >= > > perhaps this is the root of it.=0D=0A> > > >=0D=0A> > > > In option 3 = - the access network doesn't determine coarse=0D=0Alocation=0D=0A> > at=0D=0A= > > > > all. It doesn't concern itself with coarse location. It uses the=0D= =0A> > > precise=0D=0A> > > > location that it determines for the device, q= ueries the local=0D=0ALoST=0D=0A> > > > server and provides the resultant P= SAP URI directly to the=0D=0Adevice.=0D=0A> > At=0D=0A> > > > this point th= e routing has been achieved and the device can=0D=0Aroute=0D=0A> > > > dire= ctly or via the VSP. When the PSAP dereferences, it gets the=0D=0A> > > pre= cise=0D=0A> > > > location from the LIS. It is exactly because the routing = is=0D=0Aachieved=0D=0A> > > by=0D=0A> > > > just the local elements that th= is option doesn't have the=0D=0AAchilles=0D=0A> > > heel=0D=0A> > > > of op= tion 1 which requires the VSP, absolutely, to be able to=0D=0Afind=0D=0A> >= the=0D=0A> > > > authoritative local LoST server. As I say, for a very rem= ote VSP=0D=0Aand=0D=0A> > > no=0D=0A> > > > functioning forest guide, it ma= y very well not be able to.=0D=0A> > > >=0D=0A> > > > There's a basic princ= iple here - emergency services are local to=0D=0Athe=0D=0A> > > > caller, t= he access network operator (and LIS) are local to the=0D=0A> > caller,=0D=0A= > > > > and the authoritative LoST server is going to most local to the=0D=0A= > > > caller.=0D=0A> > > > The ability to reliably route the call is going = to be optimal if=0D=0A> > it's=0D=0A> > > > done between all these local en= tities who are best placed to be=0D=0A> > aware=0D=0A> > > of=0D=0A> > > > = each other. Waiting until the call scenario has geographically=0D=0A> > > d= iverged=0D=0A> > > > to the VSP before attempting to determine routing is=0D= =0Aunnecessarily=0D=0A> > > > sub-optimal.=0D=0A> > > >=0D=0A> > > > In opt= ion 1 - how do you propose the access network determine=0D=0Athe=0D=0A> > >= > "coarse location"=3F I believe your proposal is that it uses the=0D=0Alo= cal=0D=0A> > > > LoST server applicable to its area of coverage and utilize= the=0D=0A> > > semantics=0D=0A> > > > of LoST which provide a PSAP boundar= y in the response. Can you=0D=0A> > confirm=0D=0A> > > > that this is your = proposal=3F Otherwise, how would you anticipate=0D=0Athat=0D=0A> > > the=0D= =0A> > > > access provider, who doesn't manage the PSAP boundaries after=0D= =0Aall,=0D=0A> > > would=0D=0A> > > > know what is the appropriate coarse l= ocation that will result in=0D=0Aa=0D=0A> > > > reliable response when LoST= is queried=3F=0D=0A> > > >=0D=0A> > > > With respect to Henning's comment = about LoST services being=0D=0Aprovided=0D=0A> > > by=0D=0A> > > > ISPs and= /or VSPs, I didn't resonate with that. I would expect=0D=0Athat=0D=0A> > > = LoST=0D=0A> > > > is emergency services specific and it is likely to be par= t of=0D=0Asome=0D=0A> > > > jurisdictional function or some provider of ser= vices to that=0D=0A> > > > jurisdictional function. I don't see that either= ISPs or VSPs=0D=0Aare=0D=0A> > > > qualified to manage the PSAP routing in= formation contained in a=0D=0ALoST=0D=0A> > > > server.=0D=0A> > > >=0D=0A>= > > > Cheers,=0D=0A> > > > Martin=0D=0A> > > >=0D=0A> > > > -----Original = Message-----=0D=0A> > > > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A= > > > > Sent: Thursday, 14 June 2007 11:07 PM=0D=0A> > > > To: Dawson, Mart= in; 'ECRIT'=0D=0A> > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary o= f perspectives=0D=0A> > > >=0D=0A> > > > Wait a minute, we're getting confu= sed.=0D=0A> > > >=0D=0A> > > > Option 1 requires that the access network de= reference to anyone=0D=0Awith=0D=0A> > > at=0D=0A> > > > least coarse locat= ion suitable for emergency call routing. If=0D=0Athe=0D=0A> > > > endpoint=0D= =0A> > > > does routing, it will use a local LoST server which has high=0D=0A= > > > probability=0D=0A> > > > of=0D=0A> > > > having the route. If a VSP = wants to verify, it needs access to=0D=0Aa=0D=0A> > LoST=0D=0A> > > > serve= r covering the area where his customers roam. The cost is=0D=0Aon=0D=0A> >= the=0D=0A> > > > carrier that is trying to hide location (which, AFAIK, is= an=0D=0A> > economic=0D=0A> > > > issue=0D=0A> > > > all the way, the hidi= ng is so the access network can charge for=0D=0Anon=0D=0A> > > > emergency = uses of location).=0D=0A> > > >=0D=0A> > > > Option 3 requires that the acc= ess network dereference to anyone=0D=0Awith=0D=0A> > > at=0D=0A> > > > leas= t coarse location suitable for emergency call routing. This=0D=0Ais=0D=0A>= > > > because=0D=0A> > > > if the endpoint doesn't route (or more specific= ally, if it=0D=0Adoesn't=0D=0A> > > > recognize=0D=0A> > > > emergency dial= strings, query LoST, and add the PSAP URI), but=0D=0Adoes=0D=0A> > > > supp= ly=0D=0A> > > > location, then the VSP has to route, and it will have to=0D= =0A> > dereference.=0D=0A> > > > If=0D=0A> > > > the endpoint does routing,= option 3 is easy, because it will=0D=0Ahave=0D=0A> > the=0D=0A> > > > corr= ect PSAP URIs (it has to be all of them, BTW, a problem in=0D=0A> > > itsel= f).=0D=0A> > > > If=0D=0A> > > > a VSP wants to verify, it needs access to = a LoST server covering=0D=0Athe=0D=0A> > > > area=0D=0A> > > > where his cu= stomers roam. It can't use the LCP, it has to=0D=0A> > dereference=0D=0A> = > > > the=0D=0A> > > > location, and then query LoST.=0D=0A> > > >=0D=0A> >= > > If we supply a different mechanism for a VSP to validate, that=0D=0Aco= uld=0D=0A> > > > change,=0D=0A> > > > and it would affect 1 and 3 the same = way.=0D=0A> > > >=0D=0A> > > > Brian=0D=0A> > > >=0D=0A> > > > > -----Origi= nal Message-----=0D=0A> > > > > From: Dawson, Martin [mailto:Martin.Dawson@= andrew.com]=0D=0A> > > > > Sent: Wednesday, June 13, 2007 10:56 PM=0D=0A> >= > > > To: ECRIT=0D=0A> > > > > Subject: RE: [Ecrit] Proposals 1 and 3 - su= mmary of=0D=0Aperspectives=0D=0A> > > > >=0D=0A> > > > > Typo alert - obvio= usly it should have said that option *1*=0D=0A> > requires=0D=0A> > > > the=0D= =0A> > > > > VSP to work out the local LoST server in addition to the LIS=0D= =0A> > needing=0D=0A> > > > to=0D=0A> > > > > know it.=0D=0A> > > > >=0D=0A= > > > > > Cheers,=0D=0A> > > > > Martin=0D=0A> > > > >=0D=0A> > > > > -----= Original Message-----=0D=0A> > > > > From: Dawson, Martin [mailto:Martin.Da= wson@andrew.com]=0D=0A> > > > > Sent: Thursday, 14 June 2007 11:14 AM=0D=0A= > > > > > To: Henning Schulzrinne; Winterbottom, James=0D=0A> > > > > Cc: E= CRIT=0D=0A> > > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of=0D=0A= perspectives=0D=0A> > > > >=0D=0A> > > > > BTW - as I understand option 1, = it requires the LIS to query=0D=0Athe=0D=0A> > > local=0D=0A> > > > > LoST = server as well. At least that's how I recall Brian's=0D=0Aoriginal=0D=0A> >= > > > proposal being stated. It returns a "PSAP URI boundary"=0D=0Alocatio= n=0D=0A> > > > instead=0D=0A> > > > > of the PSAP URI.=0D=0A> > > > >=0D=0A= > > > > > I think folk are being inconsistent characterising option 3 as=0D= =0A> > > adding=0D=0A> > > > > LoST functionality to HELD. Both proposals r= equire the LIS to=0D=0A> > > interact=0D=0A> > > > > with LoST with the sub= sequent proxying of results to the=0D=0Adevice.=0D=0A> > > > >=0D=0A> > > >= > If the proposition of option 1 is that it's actually the LIS=0D=0Athat=0D= =0A> > > > holds=0D=0A> > > > > the PSAP-relevant boundary information, the= n option 1 is=0D=0Aactually=0D=0A> > > much=0D=0A> > > > > more like adding= LoST functionality to the LIS (and adds=0D=0A> > > inappropriate=0D=0A> > = > > > responsibility to the LIS provider).=0D=0A> > > > >=0D=0A> > > > > Fu= rther, given my understanding, both proposals rely on the=0D=0ALIS=0D=0A> >= > > knowing=0D=0A> > > > > inherently what the appropriate local LoST serv= er is. Option 1=0D=0A> > just=0D=0A> > > > > means that this is required *a= s well as* the VSP being able to=0D=0A> > reach=0D=0A> > > > > that same lo= cal LoST service.=0D=0A> > > > >=0D=0A> > > > > Neither option requires the= ISP to implement LoST, they just=0D=0A> > require=0D=0A> > > > the=0D=0A> = > > > > ISP to know which LoST server is applicable to the local area=0D=0A= of=0D=0A> > > > > coverage. That's much more practical than expecting any=0D= =0Aarbitrary=0D=0A> > > > global=0D=0A> > > > > VSP being able to work that= out but that is what option 3=0D=0Arequires=0D=0A> > > *in=0D=0A> > > > > = addition*.=0D=0A> > > > >=0D=0A> > > > > Cheers,=0D=0A> > > > > Martin=0D=0A= > > > > >=0D=0A> > > > > -----Original Message-----=0D=0A> > > > > From: He= nning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A> > > > > Sent: Thursda= y, 14 June 2007 10:22 AM=0D=0A> > > > > To: Winterbottom, James=0D=0A> > > = > > Cc: ECRIT=0D=0A> > > > > Subject: Re: [Ecrit] Proposals 1 and 3 - summa= ry of=0D=0Aperspectives=0D=0A> > > > >=0D=0A> > > > > I assume that your di= scussion has nothing to do with location=0D=0A> > hiding=0D=0A> > > > > at = this point, but wanted to call this out just in case I'm=0D=0A> > missing=0D= =0A> > > > > your train of thought.=0D=0A> > > > >=0D=0A> > > > > I'm afrai= d I don't follow your logic. Unless you assume that=0D=0Aevery=0D=0A> > > >= > ISP deploys a LoST+HELD server, VSPs will have to have LoST=0D=0A> > ser= vers=0D=0A> > > > > with PSAP knowledge for the places their customers are = likely=0D=0Ato=0D=0A> > > > > visit. This doesn't change whether HELD also = gets converted=0D=0Ainto a=0D=0A> > > > > LoST access protocol or not. So f= ar, at least, VSPs seem a=0D=0Awhole=0D=0A> > lot=0D=0A> > > > > more inter= ested in providing emergency call services than=0D=0AISPs,=0D=0A> > > > > p= resumably because their customers look to them for that=0D=0Aservice,=0D=0A= > > > not=0D=0A> > > > > to the random hot spot operator.=0D=0A> > > > >=0D= =0A> > > > > It's always been the model that both ISPs and VSPs (as well as=0D= =0A> > third=0D=0A> > > > > parties that are neither) can and should operat= e LoST servers,=0D=0Aas=0D=0A> > > > > that seems most likely to ensure tha= t you get broad coverage.=0D=0A> > > > >=0D=0A> > > > > Henning=0D=0A> > > = > >=0D=0A> > > > > On Jun 13, 2007, at 8:00 PM, Winterbottom, James wrote:=0D= =0A> > > > >=0D=0A> > > > > > Henning,=0D=0A> > > > > >=0D=0A> > > > > > I = think that your proposal only works if the VSP is able to=0D=0A> > > provid= e=0D=0A> > > > a=0D=0A> > > > > > LoST server for all jurisdictions that it= plans to provide=0D=0A> > service=0D=0A> > > > > > for,=0D=0A> > > > > > o= r it has to do it for everything (sounds awfully like a=0D=0Aglobal=0D=0A> = > > VPC=0D=0A> > > > to=0D=0A> > > > > > me). Option 3 would be deployable = from a local area to a=0D=0Alocal=0D=0A> > > PSAP=0D=0A> > > > > > REGARDLE= SS of the VSP having a LoST server that has boundary=0D=0A> > > > > > infor= mation=0D=0A> > > > > > for the local area I am in. It provides a global so= lution=0D=0Afrom=0D=0A> > the=0D=0A> > > > > > get-go.=0D=0A> > > > > >=0D=0A= > > > > > > Let's take the good old Sierra-Leone example again.=0D=0A> > > = > > >=0D=0A> > > > > > My VSP is in Sierra-Leone and I am visiting Samoa. I= n option=0D=0A3,=0D=0A> > I=0D=0A> > > > > > get a=0D=0A> > > > > > PSA P U= RI for the local Samoan PSAP from the local access=0D=0ALIS=0D=0A> > > > se= rving=0D=0A> > > > > > the area I am in, I send my call to VSP, it sends it= on the=0D=0A> > PSAP.=0D=0A> > > I=0D=0A> > > > > > get=0D=0A> > > > > > b= illed, call completes, we are done. I can quibble with my=0D=0AVSP=0D=0A> >= > later=0D=0A> > > > > > over the 10 cent call charge if I can be bothered= =2E=0D=0A> > > > > >=0D=0A> > > > > > With option 1, I send my call with lo= cation to my VSP, and=0D=0Aone=0D=0A> > of=0D=0A> > > > > > three=0D=0A> > = > > > > things happens. Either it has a complete forest guide=0D=0Anetwork=0D= =0A> > set-=0D=0A> > > > > > up to=0D=0A> > > > > > be able to talk to the = Samoan LoST server nearest me, my=0D=0Acall=0D=0A> > > > > > fails, or=0D=0A= > > > > > > the VSP routes the call anyway because the end-point has=0D=0Ad= one=0D=0A> > the=0D=0A> > > > LoST=0D=0A> > > > > > lookup. I point out, th= at from the VSP perspective the third=0D=0A> > > > > > alternative=0D=0A> >= > > > > here is simply option 3 re-badged. I am sure that VSPs=0D=0Awouldn= 't=0D=0A> > > > > > drop the=0D=0A> > > > > > call on the floor, so choice = 2 isn't an option, and choice 1=0D=0Acan=0D=0A> > > > ONLY=0D=0A> > > > > >= occur if the whole network is up and running, and it doesn't=0D=0A> > > > = > > consist of=0D=0A> > > > > > isolated copse of Forest Guides and LoST Se= rvers.=0D=0A> > > > > >=0D=0A> > > > > > So to my mind, option 3 is the ONL= Y deployable solution in=0D=0Athe=0D=0A> > > short=0D=0A> > > > > > term th= at will actually work universally.=0D=0A> > > > > >=0D=0A> > > > > > Cheers=0D= =0A> > > > > > James=0D=0A> > > > > >=0D=0A> > > > > >=0D=0A> > > > > >> --= ---Original Message-----=0D=0A> > > > > >> From: Henning Schulzrinne [mailt= o:hgs@cs.columbia.edu]=0D=0A> > > > > >> Sent: Thursday, 14 June 2007 12:58= AM=0D=0A> > > > > >> To: Dawson, Martin=0D=0A> > > > > >> Cc: ecrit@ietf.o= rg=0D=0A> > > > > >> Subject: Re: [Ecrit] Proposals 1 and 3 - summary of=0D= =0A> > perspectives=0D=0A> > > > > >>=0D=0A> > > > > >>=0D=0A> > > > > >> O= n Jun 13, 2007, at 10:54 AM, Dawson, Martin wrote:=0D=0A> > > > > >>=0D=0A>= > > > > >>> Nobody has suggested changing LoST so this point is just a=0D=0A= > > > > > >>> distraction.=0D=0A> > > > > >>>=0D=0A> > > > > >>>=0D=0A> > >= > > >>>=0D=0A> > > > > >>> Option 1 means that emergency calls will not be= able to be=0D=0A> > > routed=0D=0A> > > > > >>> until the forest guide net= work is implemented. Option 3=0D=0Ameans=0D=0A> > > that=0D=0A> > > > > >>>= emergency calls will be able to be routed regardless of=0D=0Athe=0D=0A> > = > state=0D=0A> > > > > >>> of deployment of the forest guide.=0D=0A> > > > = > >>>=0D=0A> > > > > >>>=0D=0A> > > > > >> This is not true, at least for c= omparable installations.=0D=0AThe=0D=0A> > ISP=0D=0A> > > > can=0D=0A> > > = > > >> offer a LoST server that has the locally-relevant=0D=0Ainformation.=0D= =0A> > > Same=0D=0A> > > > > >> for the VSP. This does not require a forest= guide as such.=0D=0A> > > > > >>=0D=0A> > > > > >> _______________________= ________________________=0D=0A> > > > > >> Ecrit mailing list=0D=0A> > > > = > >> Ecrit@ietf.org=0D=0A> > > > > >> https://www1.ietf.org/mailman/listinf= o/ecrit=0D=0A> > > > > >=0D=0A> > > > > >=0D=0A> > > >=0D=0A> >=0D=0A------= ----------------------------------------------------------------=0D=0A> > >= > >=0D=0A> > > > > > --------------------------=0D=0A> > > > > > This mess= age is for the designated recipient only and may=0D=0A> > > > > > contain p= rivileged, proprietary, or otherwise private=0D=0A> > information.=0D=0A> >= > > > > If you have received it in error, please notify the sender=0D=0A> = > > > > > immediately and delete the original. Any unauthorized use=0D=0Ao= f=0D=0A> > > > > > this email is prohibited.=0D=0A> > > > > >=0D=0A> > > >=0D= =0A> >=0D=0A---------------------------------------------------------------= -------=0D=0A> > > > >=0D=0A> > > > > > --------------------------=0D=0A> >= > > > > [mf2]=0D=0A> > > > > >=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > > > = > _______________________________________________=0D=0A> > > > > Ecrit mail= ing list=0D=0A> > > > > Ecrit@ietf.org=0D=0A> > > > > https://www1.ietf.org= /mailman/listinfo/ecrit=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > > >=0D=0A> >= >=0D=0A> >=0D=0A----------------------------------------------------------= --------------=0D=0A> > > > > ------------------------=0D=0A> > > > > This = message is for the designated recipient only and may=0D=0A> > > > > contain= privileged, proprietary, or otherwise private=0D=0Ainformation.=0D=0A> > >= > > If you have received it in error, please notify the sender=0D=0A> > > = > > immediately and delete the original. Any unauthorized use of=0D=0A> > = > > > this email is prohibited.=0D=0A> > > > >=0D=0A> > > >=0D=0A> > >=0D=0A= > >=0D=0A------------------------------------------------------------------= ------=0D=0A> > > > > ------------------------=0D=0A> > > > > [mf2]=0D=0A> = > > > >=0D=0A> > > > >=0D=0A> > > > > _____________________________________= __________=0D=0A> > > > > Ecrit mailing list=0D=0A> > > > > Ecrit@ietf.org=0D= =0A> > > > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > > > >=0D= =0A> > > > >=0D=0A> > > >=0D=0A> > >=0D=0A> >=0D=0A------------------------= ------------------------------------------------=0D=0A> > > > --=0D=0A> > >= > > ----------------------=0D=0A> > > > > This message is for the designat= ed recipient only and may=0D=0A> > > > > contain privileged, proprietary, o= r otherwise private=0D=0Ainformation.=0D=0A> > > > > If you have received i= t in error, please notify the sender=0D=0A> > > > > immediately and delete = the original. Any unauthorized use of=0D=0A> > > > > this email is prohibi= ted.=0D=0A> > > > >=0D=0A> > > >=0D=0A> > >=0D=0A> >=0D=0A-----------------= -------------------------------------------------------=0D=0A> > > > --=0D=0A= > > > > > ----------------------=0D=0A> > > > > [mf2]=0D=0A> > > > >=0D=0A>= > > > >=0D=0A> > > > > _______________________________________________=0D=0A= > > > > > Ecrit mailing list=0D=0A> > > > > Ecrit@ietf.org=0D=0A> > > > > h= ttps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > > >=0D=0A> > > >=0D=0A= > > > >=0D=0A> > >=0D=0A> >=0D=0A------------------------------------------= ------------------------------=0D=0A> > > --=0D=0A> > > > -----------------= -----=0D=0A> > > > This message is for the designated recipient only and ma= y=0D=0A> > > > contain privileged, proprietary, or otherwise private=0D=0Ai= nformation.=0D=0A> > > > If you have received it in error, please notify th= e sender=0D=0A> > > > immediately and delete the original. Any unauthorize= d use of=0D=0A> > > > this email is prohibited.=0D=0A> > > >=0D=0A> > >=0D=0A= > >=0D=0A------------------------------------------------------------------= ------=0D=0A> > > --=0D=0A> > > > ----------------------=0D=0A> > > > [mf2]=0D= =0A> > > >=0D=0A> > > >=0D=0A> > > > ______________________________________= _________=0D=0A> > > > Ecrit mailing list=0D=0A> > > > Ecrit@ietf.org=0D=0A= > > > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > >=0D=0A> > >=0D= =0A> > >=0D=0A> >=0D=0A----------------------------------------------------= --------------------=0D=0A> > --=0D=0A> > > ----------------------=0D=0A> >= > This message is for the designated recipient only and may=0D=0A> > > con= tain privileged, proprietary, or otherwise private information.=0D=0A> > > = If you have received it in error, please notify the sender=0D=0A> > > immed= iately and delete the original. Any unauthorized use of=0D=0A> > > this em= ail is prohibited.=0D=0A> > >=0D=0A> >=0D=0A-------------------------------= -----------------------------------------=0D=0A> > --=0D=0A> > > ----------= ------------=0D=0A> > > [mf2]=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A-------------= -----------------------------------------------------------=0D=0A> --=0D=0A= > > ----------------------=0D=0A> > This message is for the designated reci= pient only and may=0D=0A> > contain privileged, proprietary, or otherwise p= rivate information.=0D=0A> > If you have received it in error, please notif= y the sender=0D=0A> > immediately and delete the original. Any unauthorize= d use of=0D=0A> > this email is prohibited.=0D=0A> >=0D=0A-----------------= -------------------------------------------------------=0D=0A> --=0D=0A> > = ----------------------=0D=0A> > [mf2]=0D=0A>=20=0D=0A>=20=0D=0A> __________= _____________________________________=0D=0A> Ecrit mailing list=0D=0A> Ecri= t@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A-= ---------------------------------------------------------------------------= --------------------=0D=0AThis message is for the designated recipient only= and may=0D=0Acontain privileged, proprietary, or otherwise private informa= tion. =20=0D=0AIf you have received it in error, please notify the sender=0D= =0Aimmediately and delete the original. Any unauthorized use of=0D=0Athis = email is prohibited.=0D=0A-------------------------------------------------= -----------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jun 17 23:58:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I08Ng-0007fu-4V; Sun, 17 Jun 2007 23:58:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I08Ne-0007fp-Ih for ecrit@ietf.org; Sun, 17 Jun 2007 23:58:18 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I08Nd-00044R-DV for ecrit@ietf.org; Sun, 17 Jun 2007 23:58:18 -0400 X-SEF-Processed: 5_0_0_910__2007_06_17_23_06_02 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 17 Jun 2007 23:06:01 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 17 Jun 2007 22:58:16 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 17 Jun 2007 22:58:14 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives Thread-Index: AceuGgIUdnorn1MfT9KY7XAHcoK3nAABWk3gAAP8qIAAFRhfQAAEcxKwAC1PJ0AAAMljcAADai4wABfBL7AAJiIUMABAPJGwAAFAENA= References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com><1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> < 087a01c7ae84$e1b48a10$9501a8c0@cis.neustar.com><0b8c01c7af4d$8e22b3d0$9501a8c0@cis.neustar.com><0bc401c7af5c$ddd16c50$9501a8c0@cis.neustar.com><0e4801c7b056$9c15d120$9501a8c0@cis.neustar.com> From: "Dawson, Martin" To: X-OriginalArrivalTime: 18 Jun 2007 03:58:16.0362 (UTC) FILETIME=[E661B8A0:01C7B15C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8da0cbf8c1eef8eab03772f2044efec0 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Freakin' Outlook - I don't know why it deleted the line-feeds in my=0D=0Aen= umerated list. It was plain text mode. Here's an attempt to make it=0D=0Amo= re readable.=0D=0A=0D=0AHi Brian,=0D=0A=0D=0AI owe you an apology. I unders= tood option 1 incorrectly (this has been=0D=0Athe disconnect). I've just ha= d it pointed out to me that option 1 also=0D=0Arelies on the LIS (or the en= d point) to obtain the PSAP URI for the=0D=0Aendpoint to send it to the VSP= along with the coarse location. I=0D=0Aunderstood that the VSP wasn't goin= g to know the PSAP URI until it=0D=0Aretrieved it from LoST.=0D=0A=0D=0ASo = to correct my summary of the two methods:=0D=0A=0D=0AOption 1 (VSP call pro= cessing)=0D=0A1. The end-point queries the LIS which determines the locatio= n of the=0D=0Adevice=0D=0A=0D=0A2. The LIS queries LoST to obtain the PSAP = coverage (coarse location)=0D=0Aand PSAP URI=0D=0A=0D=0A3. The LIS provides= the coarse location and (optionally=3F) the PSAP URI=0D=0A=0D=0A4. The end= point (optionally=3F) queries LoST again for the PSAP URI=0D=0A=0D=0A5. Th= e end point invokes the emergency call to the VSP with the coarse=0D=0Aloca= tion and the PSAP URI=0D=0A=0D=0A6. The VSP invokes the forest guide (if ne= cessary) and queries LoST=0D=0Aagain to see if the PSAP URI that is returne= d is the same as the one=0D=0Aprovided by the end point=0D=0A=0D=0A7. If th= e PSAP URI has "validated" then the call is processed.=0D=0A=0D=0AOption 3 = (VSP call processing)=0D=0A1. The end-point queries the LIS which determine= s the location of the=0D=0Adevice=0D=0A=0D=0A2. The LIS queries LoST to obt= ain the PSAP URI for the location=0D=0A=0D=0A3. The LIS provides the PSAP U= RI to the device=0D=0A=0D=0A4. The end point invokes the emergency call to = the VSP with the PSAP URI=0D=0A=0D=0A5. The VSP routes the emergency call (= and charges for it or not=0D=0Adepending on policy)=0D=0A=0D=0A=0D=0AOption= 1 requires the LIS operator to always provide location=0D=0Ainformation - = which is useful depending on the granularity required by=0D=0Athe jurisdict= ion. The VSP might be able to validate the PSAP URI if the=0D=0Aforest guid= e exists or it happens to have the access to the LoST=0D=0Ainformation one = way or the other.=0D=0A=0D=0AOption 3 does not require the LIS operator to = provide any location. The=0D=0AVSP has to apply a policy on emergency calls= in the absence of the=0D=0Aability validate the PSAP URI - at least until = such time as the forest=0D=0Aguide or other mechanism supports this validat= ion (text pending).=0D=0A=0D=0ADoes that summarize things more fairly=3F=0D= =0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFro= m: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20=0D=0ASent: Monday, 1= 8 June 2007 1:07 PM=0D=0ATo: Brian Rosen; ecrit@ietf.org=0D=0ASubject: RE: = [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A=0D=0AI'd like to = challenge the following:=0D=0A=0D=0A" If there is no forest guide, the loca= l LoST server is still highly=0D=0Alikely to have the route for the locatio= n the endpoint is given.=0D=0AEverything except=0D=0AVSP validation works w= ithout forest guides."=0D=0A=0D=0AYou make it sound as if routing will work= without forest guides given=0D=0Aoption 1. It does not unless by (insert = miracle happens here) the VSP=0D=0Ahappens to have the foreign jurisdiction= LoST identity or a copy of the=0D=0Aforeign jurisdiction LoST information.=0D= =0A=0D=0AI have only referred to "validation" in the context of this thread= as=0D=0Ameaning "confirming that a nominal PSAP URI is a genuine PSAP URI"= =2E So=0D=0Athat hasn't been a root of any confusion for me. I think option= 3 does=0D=0Aprovide validation of the PSAP URI because it is based on the=0D= =0Aunderstanding that the LIS acquires the URI from the local LoST server.=0D= =0A=0D=0AI guess what I object to is the precipitous settling on option 1 (= with=0D=0Aits inherent failure) before anybody has an option to submit alte= rnative=0D=0Atext in any form.=0D=0A=0D=0AIn the mean time, and as you ackn= owledge below, both options 1 and 3=0D=0Ahave "commercial" compromises for = one or other party and there's no=0D=0Aobjective way to give one priority o= ver the other on that basis.=0D=0A=0D=0AI would be interested in hearing fr= om others (than Brian) whether they=0D=0Athink scenario A or scenario B bel= ow are the best starting point for=0D=0Anow.=0D=0A=0D=0ACheers,=0D=0AMartin=0D= =0A=0D=0A-----Original Message-----=0D=0AFrom: Brian Rosen [mailto:br@brian= rosen.net]=20=0D=0ASent: Sunday, 17 June 2007 6:41 AM=0D=0ATo: Dawson, Mart= in; ecrit@ietf.org=0D=0ASubject: RE: [Ecrit] Proposals 1 and 3 - summary of= perspectives=0D=0A=0D=0AMaybe we're getting ourselves confused with the wo= rd "validation". An=0D=0Aendpoint would like to know that the location it = got was a valid=0D=0Alocation.=0D=0AIt can do that by querying LoST. If it= 's given a reference and a PSAP=0D=0AURI,=0D=0Ait can't check it unless it = does a dereference, gets some kind of=0D=0Alocation=0D=0Aand queries LoST. = So option 3 leaves the endpoint not being able to=0D=0Avalidate.=0D=0A=0D=0A= If an endpoint routes, some VSPs want to validate that the route the=0D=0Ae= ndpoint handed it is valid. That's another form of validation. Option=0D=0A= 3=0D=0Adoesn't provide any way for the VSP to validate that the PSAP URI in= the=0D=0ARequest URI is a bona fide PSAP URI.=0D=0A=0D=0AYes, option 1 req= uires the LIS to provide a coarse location value for=0D=0Aanyone=0D=0Athat = asks. It provides a way for the endpoint to validate that the=0D=0Alocatio= n=0D=0Aresults in a route to a PSAP, and it provides a way for a VSP to=0D=0A= validate=0D=0Athat the URI is a valid PSAP URI.=0D=0A=0D=0AIf there is no f= orest guide, the local LoST server is still highly=0D=0Alikely to=0D=0Ahave= the route for the location the endpoint is given. Everything=0D=0Aexcept=0D= =0AVSP validation works without forest guides. PSAP validation requires=0D= =0Athat=0D=0Athe VSP have access to the same LoST data that the endpoint do= es. In=0D=0Athe=0D=0Ageneral case, that means forest guides. There are lo= ts of cases where=0D=0Athe=0D=0AVSP could reasonably get access to the LoST= data where MOST of his=0D=0Asubscribers are, but most is not all, and fore= st guides would be=0D=0Arequired.=0D=0A=0D=0AWith option 3, the LIS is high= ly likely to have access to LoST data=0D=0Acovering=0D=0Ait's service area,= so no forest guides are needed. The endpoint can't=0D=0Avalidate, so whet= her there are forest guides is moot. Same for VSP=0D=0Avalidation. =20=0D=0A=0D= =0AThere is a document that describes how forest guides work. There has=0D= =0Abeen=0D=0Adiscussion on this document, which has had more than one revis= ion. The=0D=0Aonly=0D=0Awords describing how option 3 might provide valida= tion are email=0D=0Adiscussions=0D=0Aof reverse lookups, and one email from= you that said "The ability to=0D=0Averify=0D=0Aa destination PSAP URI as a= valid emergency URI could be supported by=0D=0Areference to a relatively s= tatic table maintained by global=0D=0Acooperation."=0D=0AThat is the extent= of the discussion. There is no text.=0D=0A=0D=0AI more or less understand= how reverse lookup would work. I think we=0D=0Awould=0D=0Ahave a signific= ant piece of work to add that to the current LoST=0D=0Adocument.=0D=0AI thi= nk everyone agrees that now is not the time to do that work. If=0D=0Ayou=0D= =0Aaccept VSP validation as a requirement, which I do (reluctantly, but=0D=0A= then I=0D=0Aaccept location hiding as a requirement just as reluctantly) th= en we=0D=0Aneed=0D=0Asomething that doesn't need a change to LoST with the = impact of reverse=0D=0Alookups. You have suggested something. I think it = won't work, but it's=0D=0Ahard to criticize because there is no text. In y= our latest email, you=0D=0Ahave=0D=0Aanother idea, which I find equally unl= ikely to work, but again, there is=0D=0Ano=0D=0Atext to criticize.=0D=0A=0D= =0AI don't really like option 3, but I could live with it if there was a=0D= =0Away=0D=0Afor the VSP to validate. I'd really like a way for the endpoin= t to=0D=0Avalidate, but that is not quite so important. I don't want to ho= ld up=0D=0ALoST.=0D=0A=0D=0ASo, I'd say, in the absence of a reasonable alt= ernative, with text that=0D=0Ahas=0D=0Ahad some level of review, and has at= least a reasonable amount of=0D=0Aconsensus,=0D=0Athat we document option = 1 (in phonebcp) and keep working.=0D=0A=0D=0ABrian=0D=0A> -----Original Mes= sage-----=0D=0A> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A= > Sent: Friday, June 15, 2007 10:25 PM=0D=0A> To: Brian Rosen; ecrit@ietf.o= rg=0D=0A> Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D= =0A>=20=0D=0A> If the "normal case" is endpoint route, then there's no need= to=0D=0A> validate, right=3F So option 3 supports this without any need to= provide=0D=0A> location information. Option 1 requires it to provide locat= ion=0D=0A> information *for all requests* since it doesn't really know this= is an=0D=0A> emergency scenario.=0D=0A>=20=0D=0A> So - let's leave end-poi= nt route out of the discussion with the note=0D=0A> that option 3 satisfies= the location hiding requirement most=0D=0A> satisfactorily and without imp= act on VSP validation.=0D=0A>=20=0D=0A> Now - for VSP route where the issue= of URI validation comes up (which=0D=0Ais=0D=0A> also purely a commercial = issue AFAIK).=0D=0A>=20=0D=0A> A. If there's no forest guide in place, opti= on 1 doesn't allow the=0D=0A> emergency call to be routed at all but at lea= st nobody will have to=0D=0A> worry about whether the non-call should be ch= arged for or not.=0D=0A>=20=0D=0A> B. If there's no functional way to valid= ate the proffered PSAP URI=0D=0Athen=0D=0A> option 3 requires the VSP to de= cide whether to charge for the call or=0D=0A> not based on its policy in th= is regard. However, the emergency call=0D=0Acan=0D=0A> always be made regar= dless of the availability of a functional forest=0D=0A> guide network.=0D=0A= >=20=0D=0A> Your proposition is that scenario A is preferable to scenario B= =2E I=0D=0Athink=0D=0A> that is profoundly incorrect. I think it's self-evi= dently so.=0D=0A>=20=0D=0A> You continually dismiss any attempt on my part = to start a discussion=0D=0A> about ways for a VSP to validate the PSAP URI = as "hand waving". Every=0D=0A> reasonable discussion based on a genuine des= ire to solve a problem=0D=0A> starts with those sorts of suggestions. Your = approach is a=0D=0A> self-fulfilling argument that says there's no solution= therefore there=0D=0A> can't be a solution, because I'm simply not going t= o talk about one.=0D=0AHow=0D=0A> about a BCP that says that PSAP URIs shou= ld follow a specific=0D=0Aconvention=0D=0A> in terms of domain name structu= re=3F The VSP would only provide=0D=0Aemergency=0D=0A> call tariffs to dest= inations that satisfy that BCP. Then somebody=0D=0A> wanting to "scam a fre= e call" would have to make sure that the called=0D=0A> party URI met that f= orm. Not particularly useful.=0D=0A>=20=0D=0A> There's no precedent for a U= S-based operator charging for emergency=0D=0A> calls made by subscribers ro= aming in foreign jurisdictions. PSTN calls=0D=0A> (whether cellular or wire= line) are always handled by an operator in=0D=0Athat=0D=0A> jurisdiction. I= n the case of cellular, it is handled by the roaming=0D=0A> partner in that= jurisdiction. VoIP is the first instance of the call=0D=0A> processing occ= urring at the home provider end while the call occurs in=0D=0A> the foreign= jurisdiction. I think it's extremely unlikely that=0D=0Acharging=0D=0A> fo= r emergency calls made in foreign jurisdictions would be illegal.=0D=0A> Th= ere's only the barest shreds of legislation covering VoIP in any=0D=0A> res= pect at all at the moment.=0D=0A>=20=0D=0A> Cheers,=0D=0A> Martin=0D=0A> =0D= =0A> -----Original Message-----=0D=0A> From: Brian Rosen [mailto:br@brianro= sen.net]=0D=0A> Sent: Saturday, 16 June 2007 12:53 AM=0D=0A> To: Dawson, Ma= rtin; ecrit@ietf.org=0D=0A> Subject: RE: [Ecrit] Proposals 1 and 3 - summar= y of perspectives=0D=0A>=20=0D=0A> Huh=3F I said the normal case is endpoi= nt route. If the endpoint=0D=0Aroutes,=0D=0A> option 1 is endpoint gets co= arse location, endpoint queries LoST. No=0D=0A> forest=0D=0A> guide.=0D=0A= >=20=0D=0A> If the VSP routes, either option needs forest guides.=0D=0A> =0D= =0A> Option 1 and Option 3 need forest guides for the VSP to validate.=0D=0A= >=20=0D=0A> I don't see why a VSP would have a replica of the LoST database= , but=0D=0Aif=0D=0A> it=0D=0A> did, it wouldn't cover the world. So unless= it restricts nomading, it=0D=0A> has=0D=0A> to rely on forest guides to va= lidate (or route). If it did have a=0D=0A> replica,=0D=0A> it could have s= ome non standard way to validate for the parts of the=0D=0A> database it ha= d. That's not a solution, that's an optimization. I=0D=0A> don't=0D=0A> t= hink you can handwave with "charge for foreign emergency calls".=0D=0AThey=0D= =0A> aren't "foreign" to the guy making them. I think it would be illegal=0D= =0Ain=0D=0A> the=0D=0A> U.S. for example, although the VSP may not be subje= ct to U.S. law in=0D=0Aall=0D=0A> cases.=0D=0A>=20=0D=0A> I think a reasona= ble strategy for a VSP attempting to validate is to=0D=0A> arrange=0D=0A> f= orest guides, and to permit emergency calls from areas where it=0D=0Acannot=0D= =0A> get=0D=0A> coverage for without validation.=0D=0A>=20=0D=0A> Brian=0D=0A= >=20=0D=0A>=20=0D=0A>=20=0D=0A> > -----Original Message-----=0D=0A> > From:= Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> > Sent: Friday, Ju= ne 15, 2007 9:19 AM=0D=0A> > To: Brian Rosen; ecrit@ietf.org=0D=0A> > Subje= ct: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A> >=0D=0A>= > OK - but there's a very significant qualitative difference that you=0D=0A= > > haven't acknowledged yet.=0D=0A> >=0D=0A> > Option 3 works without depe= ndency on forest guides - it can work=0D=0A> > straight away. Option 1 mean= s that emergency calls will simply fail=0D=0Ato=0D=0A> > route until a glob= al and reliable forest guide infrastructure is in=0D=0A> > place. As I said= , that's completely independent of the question of=0D=0A> > location hiding= =2E Even if the LIS wasn't hiding location I'd still=0D=0A> > recommend tha= t the device acquires the PSAP URI from the local=0D=0A> services=0D=0A> > = and not just hope that the VSP can do it for it.=0D=0A> >=0D=0A> > If the V= SP is really going to run its own copy of the LoST data for=0D=0A> the=0D=0A= > > area of coverage that it cares about, then it can use any internal=0D=0A= > > mechanism it likes to spot the matching PSAP URI in the database. It=0D= =0A> > doesn't have to talk LoST to its own infrastructure. Barbara pointed=0D= =0A> out=0D=0A> > that, as a VSP operator, she isn't going to be so concern= ed about=0D=0A> those=0D=0A> > "foreign" emergency calls anyway. I actually= agree with the=0D=0Asentiments=0D=0A> > expressed that a VSP should still = have a mission to support=0D=0Aemergency=0D=0A> > calling regardless of poi= nt of origin. In the spirit of Barbara's=0D=0A> > position, however, perhap= s it's still reasonable if they charge for=0D=0A> > those "foreign" emergen= cy calls.=0D=0A> >=0D=0A> > Main point - I think the ability to provide glo= bal emergency service=0D=0A> as=0D=0A> > soon as possible is a better goal = than saying I'll wait until I can=0D=0Abe=0D=0A> > sure that global emergen= cy service can be provided for free before=0D=0Athe=0D=0A> > service can be= used at all.=0D=0A> >=0D=0A> > Cheers,=0D=0A> > Martin=0D=0A> >=0D=0A> > -= ----Original Message-----=0D=0A> > From: Brian Rosen [mailto:br@brianrosen.= net]=0D=0A> > Sent: Friday, 15 June 2007 11:03 PM=0D=0A> > To: Dawson, Mart= in; ecrit@ietf.org=0D=0A> > Subject: RE: [Ecrit] Proposals 1 and 3 - summar= y of perspectives=0D=0A> >=0D=0A> > Yeah, you agree with me. You just want= to ignore the VSP validation=0D=0A> > problem. I'd like to ignore the loc= ation hiding problem, but we're=0D=0A> > stuck=0D=0A> > with both.=0D=0A> >=0D= =0A> > If you come up with some way other than allowing the VSP to get=0D=0A= coarse=0D=0A> > location and using that to validate the PSAP URI, then we c= an use=0D=0Athat=0D=0A> > for=0D=0A> > option 1 or 3. So far there is no o= ther mechanism that we can use.=0D=0A> We=0D=0A> > can=0D=0A> > extend LoST= in some way to do it, but several of us are suggesting=0D=0A> that=0D=0A> = > we=0D=0A> > postpone that work and get LoST out now.=0D=0A> >=0D=0A> > I = certainly agree that the basic assumption that the access=0D=0Aprovider,=0D= =0A> > LoST=0D=0A> > server and PSAP are local to one another is a good one= =2E It's what=0D=0A> makes=0D=0A> > option 1 or 3 possible, and gives the = greatest likelihood that the=0D=0A> > system=0D=0A> > will work. I think h= aving the VSP route is fairly easy, but=0D=0A"fairly"=0D=0A> > means=0D=0A>= > that we need forest guides so that callers that are remote can be=0D=0A>= > routed.=0D=0A> > I'd strongly prefer endpoints to route. That will be m= uch more=0D=0Alikely=0D=0A> > to=0D=0A> > work in all circumstances. It se= ems very unlikely to me that we=0D=0Awould=0D=0A> > have=0D=0A> > a situati= on where the endpoint could supply location, but could not=0D=0Ado=0D=0A> >= dialstring recognition and routing. Having the VSP supply location=0D=0A>= AND=0D=0A> > route is really going to be difficult with VPNs and NATs, etc= =2E=0D=0A> >=0D=0A> > With respect to who runs the servers, I believe you a= re conflating=0D=0Atwo=0D=0A> > parts=0D=0A> > of the problem: who is respo= nsible for the data, and who runs the=0D=0A> actual=0D=0A> > server. The P= SAP is responsible for the data. It will probably run=0D=0Aa=0D=0A> > serv= er which anyone can use. However, I believe most access network=0D=0A> > p= roviders will want a copy of the data in a server they run. That=0D=0Ais=0D= =0A> > the=0D=0A> > purpose of the LoST mechanisms to maintain replicas of = the data.=0D=0A> >=0D=0A> > Brian=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> > > ---= --Original Message-----=0D=0A> > > From: Dawson, Martin [mailto:Martin.Daws= on@andrew.com]=0D=0A> > > Sent: Friday, June 15, 2007 3:32 AM=0D=0A> > > To= : ecrit@ietf.org=0D=0A> > > Subject: RE: [Ecrit] Proposals 1 and 3 - summar= y of perspectives=0D=0A> > >=0D=0A> > >=0D=0A> > > Speak for yourself :) Yo= ur description of option 3 does not=0D=0A> correlate=0D=0A> > > with my des= cription or understanding of it. So, if there's=0D=0A> confusion,=0D=0A> > = > perhaps this is the root of it.=0D=0A> > >=0D=0A> > > In option 3 - the a= ccess network doesn't determine coarse location=0D=0A> at=0D=0A> > > all. I= t doesn't concern itself with coarse location. It uses the=0D=0A> > precise=0D= =0A> > > location that it determines for the device, queries the local LoST=0D= =0A> > > server and provides the resultant PSAP URI directly to the device.=0D= =0A> At=0D=0A> > > this point the routing has been achieved and the device = can route=0D=0A> > > directly or via the VSP. When the PSAP dereferences, i= t gets the=0D=0A> > precise=0D=0A> > > location from the LIS. It is exactly= because the routing is=0D=0Aachieved=0D=0A> > by=0D=0A> > > just the local= elements that this option doesn't have the Achilles=0D=0A> > heel=0D=0A> >= > of option 1 which requires the VSP, absolutely, to be able to find=0D=0A= > the=0D=0A> > > authoritative local LoST server. As I say, for a very remo= te VSP=0D=0Aand=0D=0A> > no=0D=0A> > > functioning forest guide, it may ver= y well not be able to.=0D=0A> > >=0D=0A> > > There's a basic principle here= - emergency services are local to=0D=0Athe=0D=0A> > > caller, the access n= etwork operator (and LIS) are local to the=0D=0A> caller,=0D=0A> > > and th= e authoritative LoST server is going to most local to the=0D=0A> > caller.=0D= =0A> > > The ability to reliably route the call is going to be optimal if=0D= =0A> it's=0D=0A> > > done between all these local entities who are best pla= ced to be=0D=0A> aware=0D=0A> > of=0D=0A> > > each other. Waiting until the= call scenario has geographically=0D=0A> > diverged=0D=0A> > > to the VSP b= efore attempting to determine routing is unnecessarily=0D=0A> > > sub-optim= al.=0D=0A> > >=0D=0A> > > In option 1 - how do you propose the access netwo= rk determine the=0D=0A> > > "coarse location"=3F I believe your proposal is= that it uses the=0D=0Alocal=0D=0A> > > LoST server applicable to its area = of coverage and utilize the=0D=0A> > semantics=0D=0A> > > of LoST which pro= vide a PSAP boundary in the response. Can you=0D=0A> confirm=0D=0A> > > tha= t this is your proposal=3F Otherwise, how would you anticipate=0D=0Athat=0D= =0A> > the=0D=0A> > > access provider, who doesn't manage the PSAP boundari= es after all,=0D=0A> > would=0D=0A> > > know what is the appropriate coarse= location that will result in a=0D=0A> > > reliable response when LoST is q= ueried=3F=0D=0A> > >=0D=0A> > > With respect to Henning's comment about LoS= T services being=0D=0Aprovided=0D=0A> > by=0D=0A> > > ISPs and/or VSPs, I d= idn't resonate with that. I would expect that=0D=0A> > LoST=0D=0A> > > is e= mergency services specific and it is likely to be part of some=0D=0A> > > j= urisdictional function or some provider of services to that=0D=0A> > > juri= sdictional function. I don't see that either ISPs or VSPs are=0D=0A> > > qu= alified to manage the PSAP routing information contained in a=0D=0ALoST=0D=0A= > > > server.=0D=0A> > >=0D=0A> > > Cheers,=0D=0A> > > Martin=0D=0A> > >=0D= =0A> > > -----Original Message-----=0D=0A> > > From: Brian Rosen [mailto:br= @brianrosen.net]=0D=0A> > > Sent: Thursday, 14 June 2007 11:07 PM=0D=0A> > = > To: Dawson, Martin; 'ECRIT'=0D=0A> > > Subject: RE: [Ecrit] Proposals 1 a= nd 3 - summary of perspectives=0D=0A> > >=0D=0A> > > Wait a minute, we're g= etting confused.=0D=0A> > >=0D=0A> > > Option 1 requires that the access ne= twork dereference to anyone=0D=0Awith=0D=0A> > at=0D=0A> > > least coarse l= ocation suitable for emergency call routing. If the=0D=0A> > > endpoint=0D= =0A> > > does routing, it will use a local LoST server which has high=0D=0A= > > probability=0D=0A> > > of=0D=0A> > > having the route. If a VSP wants = to verify, it needs access to a=0D=0A> LoST=0D=0A> > > server covering the = area where his customers roam. The cost is on=0D=0A> the=0D=0A> > > carrie= r that is trying to hide location (which, AFAIK, is an=0D=0A> economic=0D=0A= > > > issue=0D=0A> > > all the way, the hiding is so the access network can= charge for=0D=0Anon=0D=0A> > > emergency uses of location).=0D=0A> > >=0D=0A= > > > Option 3 requires that the access network dereference to anyone=0D=0A= with=0D=0A> > at=0D=0A> > > least coarse location suitable for emergency ca= ll routing. This=0D=0Ais=0D=0A> > > because=0D=0A> > > if the endpoint doe= sn't route (or more specifically, if it doesn't=0D=0A> > > recognize=0D=0A>= > > emergency dialstrings, query LoST, and add the PSAP URI), but does=0D=0A= > > > supply=0D=0A> > > location, then the VSP has to route, and it will ha= ve to=0D=0A> dereference.=0D=0A> > > If=0D=0A> > > the endpoint does routin= g, option 3 is easy, because it will have=0D=0A> the=0D=0A> > > correct PSA= P URIs (it has to be all of them, BTW, a problem in=0D=0A> > itself).=0D=0A= > > > If=0D=0A> > > a VSP wants to verify, it needs access to a LoST server= covering=0D=0Athe=0D=0A> > > area=0D=0A> > > where his customers roam. It= can't use the LCP, it has to=0D=0A> dereference=0D=0A> > > the=0D=0A> > > = location, and then query LoST.=0D=0A> > >=0D=0A> > > If we supply a differe= nt mechanism for a VSP to validate, that=0D=0Acould=0D=0A> > > change,=0D=0A= > > > and it would affect 1 and 3 the same way.=0D=0A> > >=0D=0A> > > Brian=0D= =0A> > >=0D=0A> > > > -----Original Message-----=0D=0A> > > > From: Dawson,= Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> > > > Sent: Wednesday, Jun= e 13, 2007 10:56 PM=0D=0A> > > > To: ECRIT=0D=0A> > > > Subject: RE: [Ecrit= ] Proposals 1 and 3 - summary of perspectives=0D=0A> > > >=0D=0A> > > > Typ= o alert - obviously it should have said that option *1*=0D=0A> requires=0D=0A= > > > the=0D=0A> > > > VSP to work out the local LoST server in addition to= the LIS=0D=0A> needing=0D=0A> > > to=0D=0A> > > > know it.=0D=0A> > > >=0D= =0A> > > > Cheers,=0D=0A> > > > Martin=0D=0A> > > >=0D=0A> > > > -----Origi= nal Message-----=0D=0A> > > > From: Dawson, Martin [mailto:Martin.Dawson@an= drew.com]=0D=0A> > > > Sent: Thursday, 14 June 2007 11:14 AM=0D=0A> > > > T= o: Henning Schulzrinne; Winterbottom, James=0D=0A> > > > Cc: ECRIT=0D=0A> >= > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A= > > > >=0D=0A> > > > BTW - as I understand option 1, it requires the LIS to= query the=0D=0A> > local=0D=0A> > > > LoST server as well. At least that's= how I recall Brian's=0D=0Aoriginal=0D=0A> > > > proposal being stated. It = returns a "PSAP URI boundary" location=0D=0A> > > instead=0D=0A> > > > of t= he PSAP URI.=0D=0A> > > >=0D=0A> > > > I think folk are being inconsistent = characterising option 3 as=0D=0A> > adding=0D=0A> > > > LoST functionality = to HELD. Both proposals require the LIS to=0D=0A> > interact=0D=0A> > > > w= ith LoST with the subsequent proxying of results to the device.=0D=0A> > > = >=0D=0A> > > > If the proposition of option 1 is that it's actually the LIS=0D= =0Athat=0D=0A> > > holds=0D=0A> > > > the PSAP-relevant boundary informatio= n, then option 1 is=0D=0Aactually=0D=0A> > much=0D=0A> > > > more like addi= ng LoST functionality to the LIS (and adds=0D=0A> > inappropriate=0D=0A> > = > > responsibility to the LIS provider).=0D=0A> > > >=0D=0A> > > > Further,= given my understanding, both proposals rely on the LIS=0D=0A> > > knowing=0D= =0A> > > > inherently what the appropriate local LoST server is. Option 1=0D= =0A> just=0D=0A> > > > means that this is required *as well as* the VSP bei= ng able to=0D=0A> reach=0D=0A> > > > that same local LoST service.=0D=0A> >= > >=0D=0A> > > > Neither option requires the ISP to implement LoST, they j= ust=0D=0A> require=0D=0A> > > the=0D=0A> > > > ISP to know which LoST serve= r is applicable to the local area of=0D=0A> > > > coverage. That's much mor= e practical than expecting any=0D=0Aarbitrary=0D=0A> > > global=0D=0A> > > = > VSP being able to work that out but that is what option 3=0D=0Arequires=0D= =0A> > *in=0D=0A> > > > addition*.=0D=0A> > > >=0D=0A> > > > Cheers,=0D=0A>= > > > Martin=0D=0A> > > >=0D=0A> > > > -----Original Message-----=0D=0A> >= > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A> > > > Se= nt: Thursday, 14 June 2007 10:22 AM=0D=0A> > > > To: Winterbottom, James=0D= =0A> > > > Cc: ECRIT=0D=0A> > > > Subject: Re: [Ecrit] Proposals 1 and 3 - = summary of perspectives=0D=0A> > > >=0D=0A> > > > I assume that your discus= sion has nothing to do with location=0D=0A> hiding=0D=0A> > > > at this poi= nt, but wanted to call this out just in case I'm=0D=0A> missing=0D=0A> > > = > your train of thought.=0D=0A> > > >=0D=0A> > > > I'm afraid I don't follo= w your logic. Unless you assume that=0D=0Aevery=0D=0A> > > > ISP deploys a = LoST+HELD server, VSPs will have to have LoST=0D=0A> servers=0D=0A> > > > w= ith PSAP knowledge for the places their customers are likely to=0D=0A> > > = > visit. This doesn't change whether HELD also gets converted into=0D=0Aa=0D= =0A> > > > LoST access protocol or not. So far, at least, VSPs seem a whole=0D= =0A> lot=0D=0A> > > > more interested in providing emergency call services = than ISPs,=0D=0A> > > > presumably because their customers look to them for= that=0D=0Aservice,=0D=0A> > not=0D=0A> > > > to the random hot spot operat= or.=0D=0A> > > >=0D=0A> > > > It's always been the model that both ISPs and= VSPs (as well as=0D=0A> third=0D=0A> > > > parties that are neither) can a= nd should operate LoST servers,=0D=0Aas=0D=0A> > > > that seems most likely= to ensure that you get broad coverage.=0D=0A> > > >=0D=0A> > > > Henning=0D= =0A> > > >=0D=0A> > > > On Jun 13, 2007, at 8:00 PM, Winterbottom, James wr= ote:=0D=0A> > > >=0D=0A> > > > > Henning,=0D=0A> > > > >=0D=0A> > > > > I t= hink that your proposal only works if the VSP is able to=0D=0A> > provide=0D= =0A> > > a=0D=0A> > > > > LoST server for all jurisdictions that it plans t= o provide=0D=0A> service=0D=0A> > > > > for,=0D=0A> > > > > or it has to do= it for everything (sounds awfully like a=0D=0Aglobal=0D=0A> > VPC=0D=0A> >= > to=0D=0A> > > > > me). Option 3 would be deployable from a local area to= a local=0D=0A> > PSAP=0D=0A> > > > > REGARDLESS of the VSP having a LoST s= erver that has boundary=0D=0A> > > > > information=0D=0A> > > > > for the l= ocal area I am in. It provides a global solution from=0D=0A> the=0D=0A> > >= > > get-go.=0D=0A> > > > >=0D=0A> > > > > Let's take the good old Sierra-L= eone example again.=0D=0A> > > > >=0D=0A> > > > > My VSP is in Sierra-Leone= and I am visiting Samoa. In option=0D=0A3,=0D=0A> I=0D=0A> > > > > get a=0D= =0A> > > > > PSA P URI for the local Samoan PSAP from the local access LIS=0D= =0A> > > serving=0D=0A> > > > > the area I am in, I send my call to VSP, it= sends it on the=0D=0A> PSAP.=0D=0A> > I=0D=0A> > > > > get=0D=0A> > > > > = billed, call completes, we are done. I can quibble with my VSP=0D=0A> > lat= er=0D=0A> > > > > over the 10 cent call charge if I can be bothered.=0D=0A>= > > > >=0D=0A> > > > > With option 1, I send my call with location to my V= SP, and one=0D=0A> of=0D=0A> > > > > three=0D=0A> > > > > things happens. E= ither it has a complete forest guide network=0D=0A> set-=0D=0A> > > > > up = to=0D=0A> > > > > be able to talk to the Samoan LoST server nearest me, my = call=0D=0A> > > > > fails, or=0D=0A> > > > > the VSP routes the call anyway= because the end-point has done=0D=0A> the=0D=0A> > > LoST=0D=0A> > > > > l= ookup. I point out, that from the VSP perspective the third=0D=0A> > > > > = alternative=0D=0A> > > > > here is simply option 3 re-badged. I am sure tha= t VSPs=0D=0Awouldn't=0D=0A> > > > > drop the=0D=0A> > > > > call on the flo= or, so choice 2 isn't an option, and choice 1=0D=0Acan=0D=0A> > > ONLY=0D=0A= > > > > > occur if the whole network is up and running, and it doesn't=0D=0A= > > > > > consist of=0D=0A> > > > > isolated copse of Forest Guides and LoS= T Servers.=0D=0A> > > > >=0D=0A> > > > > So to my mind, option 3 is the ONL= Y deployable solution in the=0D=0A> > short=0D=0A> > > > > term that will a= ctually work universally.=0D=0A> > > > >=0D=0A> > > > > Cheers=0D=0A> > > >= > James=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > > > >> -----Original Messag= e-----=0D=0A> > > > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.ed= u]=0D=0A> > > > >> Sent: Thursday, 14 June 2007 12:58 AM=0D=0A> > > > >> To= : Dawson, Martin=0D=0A> > > > >> Cc: ecrit@ietf.org=0D=0A> > > > >> Subject= : Re: [Ecrit] Proposals 1 and 3 - summary of=0D=0A> perspectives=0D=0A> > >= > >>=0D=0A> > > > >>=0D=0A> > > > >> On Jun 13, 2007, at 10:54 AM, Dawson,= Martin wrote:=0D=0A> > > > >>=0D=0A> > > > >>> Nobody has suggested changi= ng LoST so this point is just a=0D=0A> > > > >>> distraction.=0D=0A> > > > = >>>=0D=0A> > > > >>>=0D=0A> > > > >>>=0D=0A> > > > >>> Option 1 means that = emergency calls will not be able to be=0D=0A> > routed=0D=0A> > > > >>> unt= il the forest guide network is implemented. Option 3=0D=0Ameans=0D=0A> > th= at=0D=0A> > > > >>> emergency calls will be able to be routed regardless of= the=0D=0A> > state=0D=0A> > > > >>> of deployment of the forest guide.=0D=0A= > > > > >>>=0D=0A> > > > >>>=0D=0A> > > > >> This is not true, at least for= comparable installations. The=0D=0A> ISP=0D=0A> > > can=0D=0A> > > > >> of= fer a LoST server that has the locally-relevant=0D=0Ainformation.=0D=0A> > = Same=0D=0A> > > > >> for the VSP. This does not require a forest guide as s= uch.=0D=0A> > > > >>=0D=0A> > > > >> ______________________________________= _________=0D=0A> > > > >> Ecrit mailing list=0D=0A> > > > >> Ecrit@ietf.org=0D= =0A> > > > >> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > > > >=0D= =0A> > > > >=0D=0A> > >=0D=0A> --------------------------------------------= --------------------------=0D=0A> > > >=0D=0A> > > > > --------------------= ------=0D=0A> > > > > This message is for the designated recipient only and= may=0D=0A> > > > > contain privileged, proprietary, or otherwise private=0D= =0A> information.=0D=0A> > > > > If you have received it in error, please n= otify the sender=0D=0A> > > > > immediately and delete the original. Any u= nauthorized use of=0D=0A> > > > > this email is prohibited.=0D=0A> > > > >=0D= =0A> > >=0D=0A> -----------------------------------------------------------= -----------=0D=0A> > > >=0D=0A> > > > > --------------------------=0D=0A> >= > > > [mf2]=0D=0A> > > > >=0D=0A> > > >=0D=0A> > > >=0D=0A> > > > ________= _______________________________________=0D=0A> > > > Ecrit mailing list=0D=0A= > > > > Ecrit@ietf.org=0D=0A> > > > https://www1.ietf.org/mailman/listinfo/= ecrit=0D=0A> > > >=0D=0A> > > >=0D=0A> > >=0D=0A> >=0D=0A>=0D=0A-----------= -------------------------------------------------------------=0D=0A> > > > = ------------------------=0D=0A> > > > This message is for the designated re= cipient only and may=0D=0A> > > > contain privileged, proprietary, or other= wise private=0D=0Ainformation.=0D=0A> > > > If you have received it in erro= r, please notify the sender=0D=0A> > > > immediately and delete the origina= l. Any unauthorized use of=0D=0A> > > > this email is prohibited.=0D=0A> >= > >=0D=0A> > >=0D=0A> >=0D=0A>=0D=0A--------------------------------------= ----------------------------------=0D=0A> > > > ------------------------=0D= =0A> > > > [mf2]=0D=0A> > > >=0D=0A> > > >=0D=0A> > > > ___________________= ____________________________=0D=0A> > > > Ecrit mailing list=0D=0A> > > > E= crit@ietf.org=0D=0A> > > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A= > > > >=0D=0A> > > >=0D=0A> > >=0D=0A> >=0D=0A>=0D=0A----------------------= --------------------------------------------------=0D=0A> > > --=0D=0A> > >= > ----------------------=0D=0A> > > > This message is for the designated r= ecipient only and may=0D=0A> > > > contain privileged, proprietary, or othe= rwise private=0D=0Ainformation.=0D=0A> > > > If you have received it in err= or, please notify the sender=0D=0A> > > > immediately and delete the origin= al. Any unauthorized use of=0D=0A> > > > this email is prohibited.=0D=0A> = > > >=0D=0A> > >=0D=0A> >=0D=0A>=0D=0A-------------------------------------= -----------------------------------=0D=0A> > > --=0D=0A> > > > ------------= ----------=0D=0A> > > > [mf2]=0D=0A> > > >=0D=0A> > > >=0D=0A> > > > ______= _________________________________________=0D=0A> > > > Ecrit mailing list=0D= =0A> > > > Ecrit@ietf.org=0D=0A> > > > https://www1.ietf.org/mailman/listin= fo/ecrit=0D=0A> > >=0D=0A> > >=0D=0A> > >=0D=0A> >=0D=0A>=0D=0A------------= ------------------------------------------------------------=0D=0A> > --=0D= =0A> > > ----------------------=0D=0A> > > This message is for the designat= ed recipient only and may=0D=0A> > > contain privileged, proprietary, or ot= herwise private information.=0D=0A> > > If you have received it in error, p= lease notify the sender=0D=0A> > > immediately and delete the original. An= y unauthorized use of=0D=0A> > > this email is prohibited.=0D=0A> > >=0D=0A= > >=0D=0A>=0D=0A-----------------------------------------------------------= -------------=0D=0A> > --=0D=0A> > > ----------------------=0D=0A> > > [mf2= ]=0D=0A> > >=0D=0A> > >=0D=0A> > > ________________________________________= _______=0D=0A> > > Ecrit mailing list=0D=0A> > > Ecrit@ietf.org=0D=0A> > > = https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A= >=0D=0A--------------------------------------------------------------------= ----=0D=0A> --=0D=0A> > ----------------------=0D=0A> > This message is for= the designated recipient only and may=0D=0A> > contain privileged, proprie= tary, or otherwise private information.=0D=0A> > If you have received it in= error, please notify the sender=0D=0A> > immediately and delete the origin= al. Any unauthorized use of=0D=0A> > this email is prohibited.=0D=0A> >=0D= =0A>=0D=0A-----------------------------------------------------------------= -------=0D=0A> --=0D=0A> > ----------------------=0D=0A> > [mf2]=0D=0A>=20=0D= =0A>=20=0D=0A>=0D=0A-------------------------------------------------------= -----------------=0D=0A--=0D=0A> ----------------------=0D=0A> This message= is for the designated recipient only and may=0D=0A> contain privileged, pr= oprietary, or otherwise private information.=0D=0A> If you have received it= in error, please notify the sender=0D=0A> immediately and delete the origi= nal. Any unauthorized use of=0D=0A> this email is prohibited.=0D=0A>=0D=0A= ------------------------------------------------------------------------=0D= =0A--=0D=0A> ----------------------=0D=0A> [mf2]=0D=0A=0D=0A=0D=0A---------= ---------------------------------------------------------------=0D=0A------= ------------------=0D=0AThis message is for the designated recipient only a= nd may=0D=0Acontain privileged, proprietary, or otherwise private informati= on. =20=0D=0AIf you have received it in error, please notify the sender=0D=0A= immediately and delete the original. Any unauthorized use of=0D=0Athis ema= il is prohibited.=0D=0A----------------------------------------------------= --------------------=0D=0A------------------------=0D=0A[mf2]=0D=0A=0D=0A=0D= =0A_______________________________________________=0D=0AEcrit mailing list=0D= =0AEcrit@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0AThis message is for the designated recipient = only and may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 18 09:38:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0HQq-0006cp-JR; Mon, 18 Jun 2007 09:38:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0HQp-0006ch-Ga for ecrit@ietf.org; Mon, 18 Jun 2007 09:38:11 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0HQo-0006z2-8F for ecrit@ietf.org; Mon, 18 Jun 2007 09:38:11 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5IDc5Dq023605 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 18 Jun 2007 09:38:09 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <47369DFE-4B26-4E3C-972E-F3D44A979E65@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Henning Schulzrinne Date: Mon, 18 Jun 2007 09:38:05 -0400 X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Ecrit] Architecture comparisons X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think it would help things if we compare apples to apples. We seem to agree that both VSP and ISP will run a LoST resolver (and contact other LoST servers). There are two cases based on the proposals: (1) ISP makes the LoST information available via LoST (2) ISP makes some LoST information (partially) available via some yet-to-be-specified extension to HELD We then have a second dimension: whether LoST resolution is done by the UA or the VSP. *** UA resolution case For the UA resolution case, we presence of the FG makes no difference. If resolution by the foreign VSP fails, the UA will contact the ISPs LoST server. (Which LoST servers to contact first is something that the Phone BCP would presumably cover.) If there is no FG, for Solution 1, the foreign VSP gets rough location information and can thus at least restrict those callers to domestic calls within that country by matching E.164 prefixes, rather than offer worldwide free long distance calls. In countries where the VSP has LoST information (see below), validation is possible. For Solution 3, the VSP has no means of distinguishing the caller's girl friend in Haiti from a PSAP. *** VSP resolution case This isn't an option for Solution 3, since it relies on UA resolution. For Solution 1, the resolution will work for all countries where the VSP has established a LoST presence. (A VSP with an international customer base, such as Skype, could run its own 'private' FG until such time that there is a public one.) With Solution 4, it will work even for those cases where only the ISP has LoST information. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 18 11:56:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0JaC-0005oa-Tk; Mon, 18 Jun 2007 11:56:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0JaB-0005oQ-SM for ecrit@ietf.org; Mon, 18 Jun 2007 11:55:59 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Ja9-0001RC-AU for ecrit@ietf.org; Mon, 18 Jun 2007 11:55:59 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I0JZm-000431-Hl; Mon, 18 Jun 2007 10:55:47 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com><1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu> < 087a01c7ae84$e1b48a10$9501a8c0@cis.neustar.com><0b8c01c7af4d$8e22b3d0$9501a8c0@cis.neustar.com><0bc401c7af5c$ddd16c50$9501a8c0@cis.neustar.com><0e4801c7b056$9c15d120$9501a8c0@cis.neustar.com> Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Mon, 18 Jun 2007 11:55:40 -0400 Message-ID: <112b01c7b1c1$27909620$9501a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AceuGgIUdnorn1MfT9KY7XAHcoK3nAABWk3gAAP8qIAAFRhfQAAEcxKwAC1PJ0AAAMljcAADai4wABfBL7AAJiIUMABAPJGwAAFAENAAGbuS8A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 31c5f48314ee2074d17118e5d97ef478 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Yeah. I don't think we need the LIS to provide the PSAP URI for option 1. In the U.S., I think 9-1-1 calls have to be free. If your VSP is Sierra Leone VoIP Services Pty, I don't think they can charge for it if they have a nomad in Chicago. It may be the case that SLVS is not subject to U.S. law, but in theory, you can't charge for emergency calls within the jurisdiction of the caller. I do think, as a practical matter, that if the VSP doesn't have a forest guide that can get it to the LoST server who is authoritative for the location, it has to assume it's valid. I think that will work. I think they could subsequently look into it (why they didn't have a forest guide with the data, and if it was valid). That's a trust but subsequently verify modus operandi. I think it's a requirement to validate, just like it's a requirement to support location hiding. I think in the absence of a worked out way to validate, Option 3 is a future possibility and not a currently acceptable proposal. We may be able to get there, but not right now. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Sunday, June 17, 2007 11:58 PM > To: ecrit@ietf.org > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > Freakin' Outlook - I don't know why it deleted the line-feeds in my > enumerated list. It was plain text mode. Here's an attempt to make it > more readable. > > Hi Brian, > > I owe you an apology. I understood option 1 incorrectly (this has been > the disconnect). I've just had it pointed out to me that option 1 also > relies on the LIS (or the end point) to obtain the PSAP URI for the > endpoint to send it to the VSP along with the coarse location. I > understood that the VSP wasn't going to know the PSAP URI until it > retrieved it from LoST. > > So to correct my summary of the two methods: > > Option 1 (VSP call processing) > 1. The end-point queries the LIS which determines the location of the > device > > 2. The LIS queries LoST to obtain the PSAP coverage (coarse location) > and PSAP URI > > 3. The LIS provides the coarse location and (optionally?) the PSAP URI > > 4. The end point (optionally?) queries LoST again for the PSAP URI > > 5. The end point invokes the emergency call to the VSP with the coarse > location and the PSAP URI > > 6. The VSP invokes the forest guide (if necessary) and queries LoST > again to see if the PSAP URI that is returned is the same as the one > provided by the end point > > 7. If the PSAP URI has "validated" then the call is processed. > > Option 3 (VSP call processing) > 1. The end-point queries the LIS which determines the location of the > device > > 2. The LIS queries LoST to obtain the PSAP URI for the location > > 3. The LIS provides the PSAP URI to the device > > 4. The end point invokes the emergency call to the VSP with the PSAP URI > > 5. The VSP routes the emergency call (and charges for it or not > depending on policy) > > > Option 1 requires the LIS operator to always provide location > information - which is useful depending on the granularity required by > the jurisdiction. The VSP might be able to validate the PSAP URI if the > forest guide exists or it happens to have the access to the LoST > information one way or the other. > > Option 3 does not require the LIS operator to provide any location. The > VSP has to apply a policy on emergency calls in the absence of the > ability validate the PSAP URI - at least until such time as the forest > guide or other mechanism supports this validation (text pending). > > Does that summarize things more fairly? > > Cheers, > Martin > > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Monday, 18 June 2007 1:07 PM > To: Brian Rosen; ecrit@ietf.org > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > I'd like to challenge the following: > > " If there is no forest guide, the local LoST server is still highly > likely to have the route for the location the endpoint is given. > Everything except > VSP validation works without forest guides." > > You make it sound as if routing will work without forest guides given > option 1. It does not unless by (insert miracle happens here) the VSP > happens to have the foreign jurisdiction LoST identity or a copy of the > foreign jurisdiction LoST information. > > I have only referred to "validation" in the context of this thread as > meaning "confirming that a nominal PSAP URI is a genuine PSAP URI". So > that hasn't been a root of any confusion for me. I think option 3 does > provide validation of the PSAP URI because it is based on the > understanding that the LIS acquires the URI from the local LoST server. > > I guess what I object to is the precipitous settling on option 1 (with > its inherent failure) before anybody has an option to submit alternative > text in any form. > > In the mean time, and as you acknowledge below, both options 1 and 3 > have "commercial" compromises for one or other party and there's no > objective way to give one priority over the other on that basis. > > I would be interested in hearing from others (than Brian) whether they > think scenario A or scenario B below are the best starting point for > now. > > Cheers, > Martin > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Sunday, 17 June 2007 6:41 AM > To: Dawson, Martin; ecrit@ietf.org > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > Maybe we're getting ourselves confused with the word "validation". An > endpoint would like to know that the location it got was a valid > location. > It can do that by querying LoST. If it's given a reference and a PSAP > URI, > it can't check it unless it does a dereference, gets some kind of > location > and queries LoST. So option 3 leaves the endpoint not being able to > validate. > > If an endpoint routes, some VSPs want to validate that the route the > endpoint handed it is valid. That's another form of validation. Option > 3 > doesn't provide any way for the VSP to validate that the PSAP URI in the > Request URI is a bona fide PSAP URI. > > Yes, option 1 requires the LIS to provide a coarse location value for > anyone > that asks. It provides a way for the endpoint to validate that the > location > results in a route to a PSAP, and it provides a way for a VSP to > validate > that the URI is a valid PSAP URI. > > If there is no forest guide, the local LoST server is still highly > likely to > have the route for the location the endpoint is given. Everything > except > VSP validation works without forest guides. PSAP validation requires > that > the VSP have access to the same LoST data that the endpoint does. In > the > general case, that means forest guides. There are lots of cases where > the > VSP could reasonably get access to the LoST data where MOST of his > subscribers are, but most is not all, and forest guides would be > required. > > With option 3, the LIS is highly likely to have access to LoST data > covering > it's service area, so no forest guides are needed. The endpoint can't > validate, so whether there are forest guides is moot. Same for VSP > validation. > > There is a document that describes how forest guides work. There has > been > discussion on this document, which has had more than one revision. The > only > words describing how option 3 might provide validation are email > discussions > of reverse lookups, and one email from you that said "The ability to > verify > a destination PSAP URI as a valid emergency URI could be supported by > reference to a relatively static table maintained by global > cooperation." > That is the extent of the discussion. There is no text. > > I more or less understand how reverse lookup would work. I think we > would > have a significant piece of work to add that to the current LoST > document. > I think everyone agrees that now is not the time to do that work. If > you > accept VSP validation as a requirement, which I do (reluctantly, but > then I > accept location hiding as a requirement just as reluctantly) then we > need > something that doesn't need a change to LoST with the impact of reverse > lookups. You have suggested something. I think it won't work, but it's > hard to criticize because there is no text. In your latest email, you > have > another idea, which I find equally unlikely to work, but again, there is > no > text to criticize. > > I don't really like option 3, but I could live with it if there was a > way > for the VSP to validate. I'd really like a way for the endpoint to > validate, but that is not quite so important. I don't want to hold up > LoST. > > So, I'd say, in the absence of a reasonable alternative, with text that > has > had some level of review, and has at least a reasonable amount of > consensus, > that we document option 1 (in phonebcp) and keep working. > > Brian > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: Friday, June 15, 2007 10:25 PM > > To: Brian Rosen; ecrit@ietf.org > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > If the "normal case" is endpoint route, then there's no need to > > validate, right? So option 3 supports this without any need to provide > > location information. Option 1 requires it to provide location > > information *for all requests* since it doesn't really know this is an > > emergency scenario. > > > > So - let's leave end-point route out of the discussion with the note > > that option 3 satisfies the location hiding requirement most > > satisfactorily and without impact on VSP validation. > > > > Now - for VSP route where the issue of URI validation comes up (which > is > > also purely a commercial issue AFAIK). > > > > A. If there's no forest guide in place, option 1 doesn't allow the > > emergency call to be routed at all but at least nobody will have to > > worry about whether the non-call should be charged for or not. > > > > B. If there's no functional way to validate the proffered PSAP URI > then > > option 3 requires the VSP to decide whether to charge for the call or > > not based on its policy in this regard. However, the emergency call > can > > always be made regardless of the availability of a functional forest > > guide network. > > > > Your proposition is that scenario A is preferable to scenario B. I > think > > that is profoundly incorrect. I think it's self-evidently so. > > > > You continually dismiss any attempt on my part to start a discussion > > about ways for a VSP to validate the PSAP URI as "hand waving". Every > > reasonable discussion based on a genuine desire to solve a problem > > starts with those sorts of suggestions. Your approach is a > > self-fulfilling argument that says there's no solution therefore there > > can't be a solution, because I'm simply not going to talk about one. > How > > about a BCP that says that PSAP URIs should follow a specific > convention > > in terms of domain name structure? The VSP would only provide > emergency > > call tariffs to destinations that satisfy that BCP. Then somebody > > wanting to "scam a free call" would have to make sure that the called > > party URI met that form. Not particularly useful. > > > > There's no precedent for a US-based operator charging for emergency > > calls made by subscribers roaming in foreign jurisdictions. PSTN calls > > (whether cellular or wireline) are always handled by an operator in > that > > jurisdiction. In the case of cellular, it is handled by the roaming > > partner in that jurisdiction. VoIP is the first instance of the call > > processing occurring at the home provider end while the call occurs in > > the foreign jurisdiction. I think it's extremely unlikely that > charging > > for emergency calls made in foreign jurisdictions would be illegal. > > There's only the barest shreds of legislation covering VoIP in any > > respect at all at the moment. > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Saturday, 16 June 2007 12:53 AM > > To: Dawson, Martin; ecrit@ietf.org > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > Huh? I said the normal case is endpoint route. If the endpoint > routes, > > option 1 is endpoint gets coarse location, endpoint queries LoST. No > > forest > > guide. > > > > If the VSP routes, either option needs forest guides. > > > > Option 1 and Option 3 need forest guides for the VSP to validate. > > > > I don't see why a VSP would have a replica of the LoST database, but > if > > it > > did, it wouldn't cover the world. So unless it restricts nomading, it > > has > > to rely on forest guides to validate (or route). If it did have a > > replica, > > it could have some non standard way to validate for the parts of the > > database it had. That's not a solution, that's an optimization. I > > don't > > think you can handwave with "charge for foreign emergency calls". > They > > aren't "foreign" to the guy making them. I think it would be illegal > in > > the > > U.S. for example, although the VSP may not be subject to U.S. law in > all > > cases. > > > > I think a reasonable strategy for a VSP attempting to validate is to > > arrange > > forest guides, and to permit emergency calls from areas where it > cannot > > get > > coverage for without validation. > > > > Brian > > > > > > > > > -----Original Message----- > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > Sent: Friday, June 15, 2007 9:19 AM > > > To: Brian Rosen; ecrit@ietf.org > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > OK - but there's a very significant qualitative difference that you > > > haven't acknowledged yet. > > > > > > Option 3 works without dependency on forest guides - it can work > > > straight away. Option 1 means that emergency calls will simply fail > to > > > route until a global and reliable forest guide infrastructure is in > > > place. As I said, that's completely independent of the question of > > > location hiding. Even if the LIS wasn't hiding location I'd still > > > recommend that the device acquires the PSAP URI from the local > > services > > > and not just hope that the VSP can do it for it. > > > > > > If the VSP is really going to run its own copy of the LoST data for > > the > > > area of coverage that it cares about, then it can use any internal > > > mechanism it likes to spot the matching PSAP URI in the database. It > > > doesn't have to talk LoST to its own infrastructure. Barbara pointed > > out > > > that, as a VSP operator, she isn't going to be so concerned about > > those > > > "foreign" emergency calls anyway. I actually agree with the > sentiments > > > expressed that a VSP should still have a mission to support > emergency > > > calling regardless of point of origin. In the spirit of Barbara's > > > position, however, perhaps it's still reasonable if they charge for > > > those "foreign" emergency calls. > > > > > > Main point - I think the ability to provide global emergency service > > as > > > soon as possible is a better goal than saying I'll wait until I can > be > > > sure that global emergency service can be provided for free before > the > > > service can be used at all. > > > > > > Cheers, > > > Martin > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Friday, 15 June 2007 11:03 PM > > > To: Dawson, Martin; ecrit@ietf.org > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > Yeah, you agree with me. You just want to ignore the VSP validation > > > problem. I'd like to ignore the location hiding problem, but we're > > > stuck > > > with both. > > > > > > If you come up with some way other than allowing the VSP to get > coarse > > > location and using that to validate the PSAP URI, then we can use > that > > > for > > > option 1 or 3. So far there is no other mechanism that we can use. > > We > > > can > > > extend LoST in some way to do it, but several of us are suggesting > > that > > > we > > > postpone that work and get LoST out now. > > > > > > I certainly agree that the basic assumption that the access > provider, > > > LoST > > > server and PSAP are local to one another is a good one. It's what > > makes > > > option 1 or 3 possible, and gives the greatest likelihood that the > > > system > > > will work. I think having the VSP route is fairly easy, but > "fairly" > > > means > > > that we need forest guides so that callers that are remote can be > > > routed. > > > I'd strongly prefer endpoints to route. That will be much more > likely > > > to > > > work in all circumstances. It seems very unlikely to me that we > would > > > have > > > a situation where the endpoint could supply location, but could not > do > > > dialstring recognition and routing. Having the VSP supply location > > AND > > > route is really going to be difficult with VPNs and NATs, etc. > > > > > > With respect to who runs the servers, I believe you are conflating > two > > > parts > > > of the problem: who is responsible for the data, and who runs the > > actual > > > server. The PSAP is responsible for the data. It will probably run > a > > > server which anyone can use. However, I believe most access network > > > providers will want a copy of the data in a server they run. That > is > > > the > > > purpose of the LoST mechanisms to maintain replicas of the data. > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > Sent: Friday, June 15, 2007 3:32 AM > > > > To: ecrit@ietf.org > > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > > > > > > > Speak for yourself :) Your description of option 3 does not > > correlate > > > > with my description or understanding of it. So, if there's > > confusion, > > > > perhaps this is the root of it. > > > > > > > > In option 3 - the access network doesn't determine coarse location > > at > > > > all. It doesn't concern itself with coarse location. It uses the > > > precise > > > > location that it determines for the device, queries the local LoST > > > > server and provides the resultant PSAP URI directly to the device. > > At > > > > this point the routing has been achieved and the device can route > > > > directly or via the VSP. When the PSAP dereferences, it gets the > > > precise > > > > location from the LIS. It is exactly because the routing is > achieved > > > by > > > > just the local elements that this option doesn't have the Achilles > > > heel > > > > of option 1 which requires the VSP, absolutely, to be able to find > > the > > > > authoritative local LoST server. As I say, for a very remote VSP > and > > > no > > > > functioning forest guide, it may very well not be able to. > > > > > > > > There's a basic principle here - emergency services are local to > the > > > > caller, the access network operator (and LIS) are local to the > > caller, > > > > and the authoritative LoST server is going to most local to the > > > caller. > > > > The ability to reliably route the call is going to be optimal if > > it's > > > > done between all these local entities who are best placed to be > > aware > > > of > > > > each other. Waiting until the call scenario has geographically > > > diverged > > > > to the VSP before attempting to determine routing is unnecessarily > > > > sub-optimal. > > > > > > > > In option 1 - how do you propose the access network determine the > > > > "coarse location"? I believe your proposal is that it uses the > local > > > > LoST server applicable to its area of coverage and utilize the > > > semantics > > > > of LoST which provide a PSAP boundary in the response. Can you > > confirm > > > > that this is your proposal? Otherwise, how would you anticipate > that > > > the > > > > access provider, who doesn't manage the PSAP boundaries after all, > > > would > > > > know what is the appropriate coarse location that will result in a > > > > reliable response when LoST is queried? > > > > > > > > With respect to Henning's comment about LoST services being > provided > > > by > > > > ISPs and/or VSPs, I didn't resonate with that. I would expect that > > > LoST > > > > is emergency services specific and it is likely to be part of some > > > > jurisdictional function or some provider of services to that > > > > jurisdictional function. I don't see that either ISPs or VSPs are > > > > qualified to manage the PSAP routing information contained in a > LoST > > > > server. > > > > > > > > Cheers, > > > > Martin > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Thursday, 14 June 2007 11:07 PM > > > > To: Dawson, Martin; 'ECRIT' > > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > > > Wait a minute, we're getting confused. > > > > > > > > Option 1 requires that the access network dereference to anyone > with > > > at > > > > least coarse location suitable for emergency call routing. If the > > > > endpoint > > > > does routing, it will use a local LoST server which has high > > > probability > > > > of > > > > having the route. If a VSP wants to verify, it needs access to a > > LoST > > > > server covering the area where his customers roam. The cost is on > > the > > > > carrier that is trying to hide location (which, AFAIK, is an > > economic > > > > issue > > > > all the way, the hiding is so the access network can charge for > non > > > > emergency uses of location). > > > > > > > > Option 3 requires that the access network dereference to anyone > with > > > at > > > > least coarse location suitable for emergency call routing. This > is > > > > because > > > > if the endpoint doesn't route (or more specifically, if it doesn't > > > > recognize > > > > emergency dialstrings, query LoST, and add the PSAP URI), but does > > > > supply > > > > location, then the VSP has to route, and it will have to > > dereference. > > > > If > > > > the endpoint does routing, option 3 is easy, because it will have > > the > > > > correct PSAP URIs (it has to be all of them, BTW, a problem in > > > itself). > > > > If > > > > a VSP wants to verify, it needs access to a LoST server covering > the > > > > area > > > > where his customers roam. It can't use the LCP, it has to > > dereference > > > > the > > > > location, and then query LoST. > > > > > > > > If we supply a different mechanism for a VSP to validate, that > could > > > > change, > > > > and it would affect 1 and 3 the same way. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > > Sent: Wednesday, June 13, 2007 10:56 PM > > > > > To: ECRIT > > > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > > > > > Typo alert - obviously it should have said that option *1* > > requires > > > > the > > > > > VSP to work out the local LoST server in addition to the LIS > > needing > > > > to > > > > > know it. > > > > > > > > > > Cheers, > > > > > Martin > > > > > > > > > > -----Original Message----- > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > > Sent: Thursday, 14 June 2007 11:14 AM > > > > > To: Henning Schulzrinne; Winterbottom, James > > > > > Cc: ECRIT > > > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > > > > > BTW - as I understand option 1, it requires the LIS to query the > > > local > > > > > LoST server as well. At least that's how I recall Brian's > original > > > > > proposal being stated. It returns a "PSAP URI boundary" location > > > > instead > > > > > of the PSAP URI. > > > > > > > > > > I think folk are being inconsistent characterising option 3 as > > > adding > > > > > LoST functionality to HELD. Both proposals require the LIS to > > > interact > > > > > with LoST with the subsequent proxying of results to the device. > > > > > > > > > > If the proposition of option 1 is that it's actually the LIS > that > > > > holds > > > > > the PSAP-relevant boundary information, then option 1 is > actually > > > much > > > > > more like adding LoST functionality to the LIS (and adds > > > inappropriate > > > > > responsibility to the LIS provider). > > > > > > > > > > Further, given my understanding, both proposals rely on the LIS > > > > knowing > > > > > inherently what the appropriate local LoST server is. Option 1 > > just > > > > > means that this is required *as well as* the VSP being able to > > reach > > > > > that same local LoST service. > > > > > > > > > > Neither option requires the ISP to implement LoST, they just > > require > > > > the > > > > > ISP to know which LoST server is applicable to the local area of > > > > > coverage. That's much more practical than expecting any > arbitrary > > > > global > > > > > VSP being able to work that out but that is what option 3 > requires > > > *in > > > > > addition*. > > > > > > > > > > Cheers, > > > > > Martin > > > > > > > > > > -----Original Message----- > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > > Sent: Thursday, 14 June 2007 10:22 AM > > > > > To: Winterbottom, James > > > > > Cc: ECRIT > > > > > Subject: Re: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > > > > > I assume that your discussion has nothing to do with location > > hiding > > > > > at this point, but wanted to call this out just in case I'm > > missing > > > > > your train of thought. > > > > > > > > > > I'm afraid I don't follow your logic. Unless you assume that > every > > > > > ISP deploys a LoST+HELD server, VSPs will have to have LoST > > servers > > > > > with PSAP knowledge for the places their customers are likely to > > > > > visit. This doesn't change whether HELD also gets converted into > a > > > > > LoST access protocol or not. So far, at least, VSPs seem a whole > > lot > > > > > more interested in providing emergency call services than ISPs, > > > > > presumably because their customers look to them for that > service, > > > not > > > > > to the random hot spot operator. > > > > > > > > > > It's always been the model that both ISPs and VSPs (as well as > > third > > > > > parties that are neither) can and should operate LoST servers, > as > > > > > that seems most likely to ensure that you get broad coverage. > > > > > > > > > > Henning > > > > > > > > > > On Jun 13, 2007, at 8:00 PM, Winterbottom, James wrote: > > > > > > > > > > > Henning, > > > > > > > > > > > > I think that your proposal only works if the VSP is able to > > > provide > > > > a > > > > > > LoST server for all jurisdictions that it plans to provide > > service > > > > > > for, > > > > > > or it has to do it for everything (sounds awfully like a > global > > > VPC > > > > to > > > > > > me). Option 3 would be deployable from a local area to a local > > > PSAP > > > > > > REGARDLESS of the VSP having a LoST server that has boundary > > > > > > information > > > > > > for the local area I am in. It provides a global solution from > > the > > > > > > get-go. > > > > > > > > > > > > Let's take the good old Sierra-Leone example again. > > > > > > > > > > > > My VSP is in Sierra-Leone and I am visiting Samoa. In option > 3, > > I > > > > > > get a > > > > > > PSA P URI for the local Samoan PSAP from the local access LIS > > > > serving > > > > > > the area I am in, I send my call to VSP, it sends it on the > > PSAP. > > > I > > > > > > get > > > > > > billed, call completes, we are done. I can quibble with my VSP > > > later > > > > > > over the 10 cent call charge if I can be bothered. > > > > > > > > > > > > With option 1, I send my call with location to my VSP, and one > > of > > > > > > three > > > > > > things happens. Either it has a complete forest guide network > > set- > > > > > > up to > > > > > > be able to talk to the Samoan LoST server nearest me, my call > > > > > > fails, or > > > > > > the VSP routes the call anyway because the end-point has done > > the > > > > LoST > > > > > > lookup. I point out, that from the VSP perspective the third > > > > > > alternative > > > > > > here is simply option 3 re-badged. I am sure that VSPs > wouldn't > > > > > > drop the > > > > > > call on the floor, so choice 2 isn't an option, and choice 1 > can > > > > ONLY > > > > > > occur if the whole network is up and running, and it doesn't > > > > > > consist of > > > > > > isolated copse of Forest Guides and LoST Servers. > > > > > > > > > > > > So to my mind, option 3 is the ONLY deployable solution in the > > > short > > > > > > term that will actually work universally. > > > > > > > > > > > > Cheers > > > > > > James > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > > >> Sent: Thursday, 14 June 2007 12:58 AM > > > > > >> To: Dawson, Martin > > > > > >> Cc: ecrit@ietf.org > > > > > >> Subject: Re: [Ecrit] Proposals 1 and 3 - summary of > > perspectives > > > > > >> > > > > > >> > > > > > >> On Jun 13, 2007, at 10:54 AM, Dawson, Martin wrote: > > > > > >> > > > > > >>> Nobody has suggested changing LoST so this point is just a > > > > > >>> distraction. > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> Option 1 means that emergency calls will not be able to be > > > routed > > > > > >>> until the forest guide network is implemented. Option 3 > means > > > that > > > > > >>> emergency calls will be able to be routed regardless of the > > > state > > > > > >>> of deployment of the forest guide. > > > > > >>> > > > > > >>> > > > > > >> This is not true, at least for comparable installations. The > > ISP > > > > can > > > > > >> offer a LoST server that has the locally-relevant > information. > > > Same > > > > > >> for the VSP. This does not require a forest guide as such. > > > > > >> > > > > > >> _______________________________________________ > > > > > >> Ecrit mailing list > > > > > >> Ecrit@ietf.org > > > > > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > > -------------------------- > > > > > > This message is for the designated recipient only and may > > > > > > contain privileged, proprietary, or otherwise private > > information. > > > > > > If you have received it in error, please notify the sender > > > > > > immediately and delete the original. Any unauthorized use of > > > > > > this email is prohibited. > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > > -------------------------- > > > > > > [mf2] > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------ > > > > > This message is for the designated recipient only and may > > > > > contain privileged, proprietary, or otherwise private > information. > > > > > If you have received it in error, please notify the sender > > > > > immediately and delete the original. Any unauthorized use of > > > > > this email is prohibited. > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > ------------------------ > > > > > [mf2] > > > > > > > > > > > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > ---------------------- > > > > > This message is for the designated recipient only and may > > > > > contain privileged, proprietary, or otherwise private > information. > > > > > If you have received it in error, please notify the sender > > > > > immediately and delete the original. Any unauthorized use of > > > > > this email is prohibited. > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > ---------------------- > > > > > [mf2] > > > > > > > > > > > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > ---------------------- > > > > This message is for the designated recipient only and may > > > > contain privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > > immediately and delete the original. Any unauthorized use of > > > > this email is prohibited. > > > > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > ---------------------- > > > > [mf2] > > > > > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > [mf2] > > > > > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] > > > ------------------------------------------------------------------------ > ------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------ > ------------------------ > [mf2] > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 18 12:08:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Jmd-0001UE-9a; Mon, 18 Jun 2007 12:08:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Jmb-0001U6-TG for ecrit@ietf.org; Mon, 18 Jun 2007 12:08:50 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I0Jma-0005AT-Fp for ecrit@ietf.org; Mon, 18 Jun 2007 12:08:49 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I0JmQ-0005Yq-1V; Mon, 18 Jun 2007 11:08:38 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'ECRIT'" References: <47369DFE-4B26-4E3C-972E-F3D44A979E65@cs.columbia.edu> Subject: RE: [Ecrit] Architecture comparisons Date: Mon, 18 Jun 2007 12:08:44 -0400 Message-ID: <113601c7b1c2$f3f15640$9501a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47369DFE-4B26-4E3C-972E-F3D44A979E65@cs.columbia.edu> Thread-Index: AcexremaX0mkpkefQGGogs+v3EDV1QAFC/Dw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I don't understand the line: > ....If resolution by the foreign VSP fails, the UA will > contact the ISPs LoST server. This sentence is in "UA resolution". The UA would FIRST try using the LoST server suggested by its ISP (which should be local to it), and failing that would try a LoST server suggested by its VSP. I am glad you pointed out that Solution 3 doesn't permit the VSP to route. While it would be rare, I think, for the UA to have location, but not be able to route, I think we have to allow for that case. The VSP should be able to route if the UA fails to route. I am uncomfortable with the access network saying that the UA has to use the route it supplies, or the system fails. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, June 18, 2007 9:38 AM > To: ECRIT > Subject: [Ecrit] Architecture comparisons > > I think it would help things if we compare apples to apples. We seem > to agree that both VSP and ISP will run a LoST resolver (and contact > other LoST servers). There are two cases based on the proposals: > > (1) ISP makes the LoST information available via LoST > > (2) ISP makes some LoST information (partially) available via some > yet-to-be-specified extension to HELD > > We then have a second dimension: whether LoST resolution is done by > the UA or the VSP. > > *** UA resolution case > > For the UA resolution case, we presence of the FG makes no > difference. If resolution by the foreign VSP fails, the UA will > contact the ISPs LoST server. (Which LoST servers to contact first is > something that the Phone BCP would presumably cover.) > > If there is no FG, for Solution 1, the foreign VSP gets rough > location information and can thus at least restrict those callers to > domestic calls within that country by matching E.164 prefixes, rather > than offer worldwide free long distance calls. In countries where the > VSP has LoST information (see below), validation is possible. > > For Solution 3, the VSP has no means of distinguishing the caller's > girl friend in Haiti from a PSAP. > > *** VSP resolution case > > This isn't an option for Solution 3, since it relies on UA resolution. > > For Solution 1, the resolution will work for all countries where the > VSP has established a LoST presence. (A VSP with an international > customer base, such as Skype, could run its own 'private' FG until > such time that there is a public one.) > > With Solution 4, it will work even for those cases where only the ISP > has LoST information. > > Henning > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 18 12:32:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0K92-0003rF-FX; Mon, 18 Jun 2007 12:32:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0K90-0003qV-Tk for ecrit@ietf.org; Mon, 18 Jun 2007 12:31:58 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0K8z-0000w2-Lg for ecrit@ietf.org; Mon, 18 Jun 2007 12:31:58 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5IGVo7t022687 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 18 Jun 2007 12:31:50 -0400 (EDT) In-Reply-To: <113601c7b1c2$f3f15640$9501a8c0@cis.neustar.com> References: <47369DFE-4B26-4E3C-972E-F3D44A979E65@cs.columbia.edu> <113601c7b1c2$f3f15640$9501a8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Architecture comparisons Date: Mon, 18 Jun 2007 12:32:47 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 18, 2007, at 12:08 PM, Brian Rosen wrote: > I don't understand the line: >> ....If resolution by the foreign VSP fails, the UA will >> contact the ISPs LoST server. > This sentence is in "UA resolution". The UA would FIRST try using > the LoST > server suggested by its ISP (which should be local to it), and > failing that > would try a LoST server suggested by its VSP. I admit not checking the current text in the phone-bcp before writing my note and agree that checking locally first makes sense. I don't think this changes the basic thrust of the discussion. > > I am glad you pointed out that Solution 3 doesn't permit the VSP to > route. > While it would be rare, I think, for the UA to have location, but > not be > able to route, I think we have to allow for that case. The VSP > should be > able to route if the UA fails to route. I am uncomfortable with > the access > network saying that the UA has to use the route it supplies, or the > system > fails. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 18 19:18:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0QTt-0004Kp-R0; Mon, 18 Jun 2007 19:17:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0QTs-0004Kj-7C for ecrit@ietf.org; Mon, 18 Jun 2007 19:17:56 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0QTr-0004pC-Sf for ecrit@ietf.org; Mon, 18 Jun 2007 19:17:56 -0400 X-SEF-Processed: 5_0_0_910__2007_06_18_18_25_34 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 18 Jun 2007 18:25:34 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jun 2007 18:17:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Architecture comparisons Date: Mon, 18 Jun 2007 18:17:47 -0500 Message-ID: In-Reply-To: <113601c7b1c2$f3f15640$9501a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Architecture comparisons Thread-Index: AcexremaX0mkpkefQGGogs+v3EDV1QAFC/DwAA8aZoA= References: <47369DFE-4B26-4E3C-972E-F3D44A979E65@cs.columbia.edu> <113601c7b1c2$f3f15640$9501a8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Henning Schulzrinne" , "ECRIT" X-OriginalArrivalTime: 18 Jun 2007 23:17:49.0000 (UTC) FILETIME=[E2E7CC80:01C7B1FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Perhaps I am missing something here.=0D=0A=0D=0AWe have a local LoST server= that provides PSAP URI when given location.=0D=0AWe have a forset guide in= Sierra Leone that knows how to find this LoST=0D=0Aserver.=0D=0A=0D=0AWe h= ave a UA that asks the LIS for location.=0D=0AThe LIS gets location, perfor= ms LoST lookup, and returns the PSAP URI.=0D=0A=0D=0APlease tell me how th= e VSP is going to do any better even if we give it=0D=0Alocation, given tha= t the forest guide it uses will take it to the same=0D=0ALoST server.=0D=0A=0D= =0ACheers=0D=0AJames=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: B= rian Rosen [mailto:br@brianrosen.net]=0D=0A> Sent: Tuesday, 19 June 2007 2:= 09 AM=0D=0A> To: 'Henning Schulzrinne'; 'ECRIT'=0D=0A> Subject: RE: [Ecrit]= Architecture comparisons=0D=0A>=20=0D=0A> I don't understand the line:=0D=0A= > > ....If resolution by the foreign VSP fails, the UA will=0D=0A> > contac= t the ISPs LoST server.=0D=0A> This sentence is in "UA resolution". The UA= would FIRST try using the=0D=0A> LoST=0D=0A> server suggested by its ISP (= which should be local to it), and failing=0D=0A> that=0D=0A> would try a Lo= ST server suggested by its VSP.=0D=0A>=20=0D=0A> I am glad you pointed out = that Solution 3 doesn't permit the VSP to=0D=0Aroute.=0D=0A> While it would= be rare, I think, for the UA to have location, but not=0D=0Abe=0D=0A> able= to route, I think we have to allow for that case. The VSP should=0D=0Abe=0D= =0A> able to route if the UA fails to route. I am uncomfortable with the=0D= =0A> access=0D=0A> network saying that the UA has to use the route it suppl= ies, or the=0D=0Asystem=0D=0A> fails.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A= > > -----Original Message-----=0D=0A> > From: Henning Schulzrinne [mailto:h= gs@cs.columbia.edu]=0D=0A> > Sent: Monday, June 18, 2007 9:38 AM=0D=0A> > T= o: ECRIT=0D=0A> > Subject: [Ecrit] Architecture comparisons=0D=0A> >=0D=0A>= > I think it would help things if we compare apples to apples. We seem=0D=0A= > > to agree that both VSP and ISP will run a LoST resolver (and contact=0D= =0A> > other LoST servers). There are two cases based on the proposals:=0D=0A= > >=0D=0A> > (1) ISP makes the LoST information available via LoST=0D=0A> >=0D= =0A> > (2) ISP makes some LoST information (partially) available via some=0D= =0A> > yet-to-be-specified extension to HELD=0D=0A> >=0D=0A> > We then have= a second dimension: whether LoST resolution is done by=0D=0A> > the UA or = the VSP.=0D=0A> >=0D=0A> > *** UA resolution case=0D=0A> >=0D=0A> > For the= UA resolution case, we presence of the FG makes no=0D=0A> > difference. If= resolution by the foreign VSP fails, the UA will=0D=0A> > contact the ISPs= LoST server. (Which LoST servers to contact first=0D=0Ais=0D=0A> > somethi= ng that the Phone BCP would presumably cover.)=0D=0A> >=0D=0A> > If there i= s no FG, for Solution 1, the foreign VSP gets rough=0D=0A> > location infor= mation and can thus at least restrict those callers to=0D=0A> > domestic ca= lls within that country by matching E.164 prefixes,=0D=0Arather=0D=0A> > th= an offer worldwide free long distance calls. In countries where=0D=0Athe=0D= =0A> > VSP has LoST information (see below), validation is possible.=0D=0A>= >=0D=0A> > For Solution 3, the VSP has no means of distinguishing the call= er's=0D=0A> > girl friend in Haiti from a PSAP.=0D=0A> >=0D=0A> > *** VSP r= esolution case=0D=0A> >=0D=0A> > This isn't an option for Solution 3, since= it relies on UA=0D=0Aresolution.=0D=0A> >=0D=0A> > For Solution 1, the res= olution will work for all countries where the=0D=0A> > VSP has established = a LoST presence. (A VSP with an international=0D=0A> > customer base, such = as Skype, could run its own 'private' FG until=0D=0A> > such time that ther= e is a public one.)=0D=0A> >=0D=0A> > With Solution 4, it will work even fo= r those cases where only the=0D=0AISP=0D=0A> > has LoST information.=0D=0A>= >=0D=0A> > Henning=0D=0A> >=0D=0A> > _____________________________________= __________=0D=0A> > Ecrit mailing list=0D=0A> > Ecrit@ietf.org=0D=0A> > htt= ps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A>=20=0D=0A> ______= _________________________________________=0D=0A> Ecrit mailing list=0D=0A> = Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0AThis message is for the designated recipient = only and may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 18 19:30:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Qg8-00063n-OQ; Mon, 18 Jun 2007 19:30:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Qg7-0005wQ-Eb for ecrit@ietf.org; Mon, 18 Jun 2007 19:30:35 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Qg5-0008N7-MT for ecrit@ietf.org; Mon, 18 Jun 2007 19:30:35 -0400 X-SEF-Processed: 5_0_0_910__2007_06_18_18_38_19 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 18 Jun 2007 18:38:19 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jun 2007 18:30:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Mon, 18 Jun 2007 18:30:29 -0500 Message-ID: In-Reply-To: <112b01c7b1c1$27909620$9501a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Proposals 1 and 3 - summary of perspectives Thread-Index: AceuGgIUdnorn1MfT9KY7XAHcoK3nAABWk3gAAP8qIAAFRhfQAAEcxKwAC1PJ0AAAMljcAADai4wABfBL7AAJiIUMABAPJGwAAFAENAAGbuS8AAPykbQ References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com><1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu><0 87a01c7ae84$e1b48a10$9501a8c0@cis.neustar.com><0b8c01c7af4d$8e22b3d0$9501a8c0@cis.neustar.com><0bc401c7af5c$ddd16c50$9501a8c0@cis.neustar.com><0e4801c7b056$9c15d120$9501a8c0@cis.neustar.com> <112b01c7b1c1$27909620$9501a8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Dawson, Martin" , X-OriginalArrivalTime: 18 Jun 2007 23:30:33.0313 (UTC) FILETIME=[AA78B510:01C7B200] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8353da2fde044920180672209f5bf8a0 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian,=0D=0A=0D=0AWhile I agree with some of what you have said below, I ce= rtainly don't=0D=0Aagree with a lot of it.=0D=0A=0D=0AI think that there ar= e no grounds to suggest that SLVS can't charge=0D=0Atheir mobile sub for ma= king a call in the US emergency or not. Indeed=0D=0Amaking this assertion i= n the way in which you have would be tantamount=0D=0Ato saying that all cal= ls they made to US destinations while in the US=0D=0Awere national calls an= d their for likely free from tariff also. Which I=0D=0Athink we all agree i= s ridiculous.=0D=0A=0D=0AAs you point out, if there is no forest guide, the= n the VSP has to trust=0D=0Athe URI provided by the caller or bill them. Th= is is the same as=0D=0Asolution 3 from the VSP perspective. So what you are= saying is that=0D=0Asolution 3 has to be the case where a forest guide is = not available.=0D=0AThanks for the support.. ;)=0D=0A=0D=0AI think what thi= s boils down to is that in the future PSAP URI=0D=0Avalidation may be possi= ble, and that from a VSP perspective it is a=0D=0Abilling requirement. Init= ially this will not be possible, either because=0D=0Aforest guides will not= be available, or because no mechanism for PSAP=0D=0AURI to service lookup = will be available.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A> -----Ori= ginal Message-----=0D=0A> From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A= > Sent: Tuesday, 19 June 2007 1:56 AM=0D=0A> To: Dawson, Martin; ecrit@ietf= =2Eorg=0D=0A> Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspecti= ves=0D=0A>=20=0D=0A> Yeah.=0D=0A>=20=0D=0A> I don't think we need the LIS t= o provide the PSAP URI for option 1.=0D=0A>=20=0D=0A> In the U.S., I think = 9-1-1 calls have to be free. If your VSP is=0D=0ASierra=0D=0A> Leone VoIP = Services Pty, I don't think they can charge for it if they=0D=0Ahave=0D=0A>= a=0D=0A> nomad in Chicago. It may be the case that SLVS is not subject to= U.S.=0D=0A> law,=0D=0A> but in theory, you can't charge for emergency call= s within the=0D=0A> jurisdiction=0D=0A> of the caller. I do think, as a pr= actical matter, that if the VSP=0D=0Adoesn't=0D=0A> have a forest guide tha= t can get it to the LoST server who is=0D=0A> authoritative=0D=0A> for the = location, it has to assume it's valid. I think that will=0D=0Awork. I=0D=0A= > think they could subsequently look into it (why they didn't have a=0D=0Af= orest=0D=0A> guide with the data, and if it was valid). That's a trust but=0D= =0A> subsequently=0D=0A> verify modus operandi.=0D=0A>=20=0D=0A> I think it= 's a requirement to validate, just like it's a requirement=0D=0Ato=0D=0A> s= upport location hiding. I think in the absence of a worked out way=0D=0Ato=0D= =0A> validate, Option 3 is a future possibility and not a currently=0D=0Aac= ceptable=0D=0A> proposal. We may be able to get there, but not right now.=0D= =0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A> > -----Original Message-----=0D=0A> >= From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> > Sent: Sund= ay, June 17, 2007 11:58 PM=0D=0A> > To: ecrit@ietf.org=0D=0A> > Subject: RE= : [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A> >=0D=0A> > Fre= akin' Outlook - I don't know why it deleted the line-feeds in my=0D=0A> > e= numerated list. It was plain text mode. Here's an attempt to make=0D=0Ait=0D= =0A> > more readable.=0D=0A> >=0D=0A> > Hi Brian,=0D=0A> >=0D=0A> > I owe y= ou an apology. I understood option 1 incorrectly (this has=0D=0Abeen=0D=0A>= > the disconnect). I've just had it pointed out to me that option 1=0D=0Aa= lso=0D=0A> > relies on the LIS (or the end point) to obtain the PSAP URI fo= r the=0D=0A> > endpoint to send it to the VSP along with the coarse locatio= n. I=0D=0A> > understood that the VSP wasn't going to know the PSAP URI unt= il it=0D=0A> > retrieved it from LoST.=0D=0A> >=0D=0A> > So to correct my s= ummary of the two methods:=0D=0A> >=0D=0A> > Option 1 (VSP call processing)=0D= =0A> > 1. The end-point queries the LIS which determines the location of=0D= =0Athe=0D=0A> > device=0D=0A> >=0D=0A> > 2. The LIS queries LoST to obtain = the PSAP coverage (coarse=0D=0Alocation)=0D=0A> > and PSAP URI=0D=0A> >=0D=0A= > > 3. The LIS provides the coarse location and (optionally=3F) the PSAP=0D= =0AURI=0D=0A> >=0D=0A> > 4. The end point (optionally=3F) queries LoST agai= n for the PSAP URI=0D=0A> >=0D=0A> > 5. The end point invokes the emergency= call to the VSP with the=0D=0Acoarse=0D=0A> > location and the PSAP URI=0D= =0A> >=0D=0A> > 6. The VSP invokes the forest guide (if necessary) and quer= ies LoST=0D=0A> > again to see if the PSAP URI that is returned is the same= as the one=0D=0A> > provided by the end point=0D=0A> >=0D=0A> > 7. If the = PSAP URI has "validated" then the call is processed.=0D=0A> >=0D=0A> > Opti= on 3 (VSP call processing)=0D=0A> > 1. The end-point queries the LIS which = determines the location of=0D=0Athe=0D=0A> > device=0D=0A> >=0D=0A> > 2. Th= e LIS queries LoST to obtain the PSAP URI for the location=0D=0A> >=0D=0A> = > 3. The LIS provides the PSAP URI to the device=0D=0A> >=0D=0A> > 4. The e= nd point invokes the emergency call to the VSP with the PSAP=0D=0AURI=0D=0A= > >=0D=0A> > 5. The VSP routes the emergency call (and charges for it or no= t=0D=0A> > depending on policy)=0D=0A> >=0D=0A> >=0D=0A> > Option 1 require= s the LIS operator to always provide location=0D=0A> > information - which = is useful depending on the granularity required=0D=0Aby=0D=0A> > the jurisd= iction. The VSP might be able to validate the PSAP URI if=0D=0Athe=0D=0A> >= forest guide exists or it happens to have the access to the LoST=0D=0A> > = information one way or the other.=0D=0A> >=0D=0A> > Option 3 does not requi= re the LIS operator to provide any location.=0D=0AThe=0D=0A> > VSP has to a= pply a policy on emergency calls in the absence of the=0D=0A> > ability val= idate the PSAP URI - at least until such time as the=0D=0Aforest=0D=0A> > g= uide or other mechanism supports this validation (text pending).=0D=0A> >=0D= =0A> > Does that summarize things more fairly=3F=0D=0A> >=0D=0A> > Cheers,=0D= =0A> > Martin=0D=0A> >=0D=0A> > -----Original Message-----=0D=0A> > From: D= awson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> > Sent: Monday, 18 J= une 2007 1:07 PM=0D=0A> > To: Brian Rosen; ecrit@ietf.org=0D=0A> > Subject:= RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A> >=0D=0A> > = I'd like to challenge the following:=0D=0A> >=0D=0A> > " If there is no for= est guide, the local LoST server is still highly=0D=0A> > likely to have th= e route for the location the endpoint is given.=0D=0A> > Everything except=0D= =0A> > VSP validation works without forest guides."=0D=0A> >=0D=0A> > You m= ake it sound as if routing will work without forest guides=0D=0Agiven=0D=0A= > > option 1. It does not unless by (insert miracle happens here) the=0D=0A= VSP=0D=0A> > happens to have the foreign jurisdiction LoST identity or a co= py of=0D=0Athe=0D=0A> > foreign jurisdiction LoST information.=0D=0A> >=0D=0A= > > I have only referred to "validation" in the context of this thread=0D=0A= as=0D=0A> > meaning "confirming that a nominal PSAP URI is a genuine PSAP U= RI".=0D=0ASo=0D=0A> > that hasn't been a root of any confusion for me. I th= ink option 3=0D=0Adoes=0D=0A> > provide validation of the PSAP URI because = it is based on the=0D=0A> > understanding that the LIS acquires the URI fro= m the local LoST=0D=0Aserver.=0D=0A> >=0D=0A> > I guess what I object to is= the precipitous settling on option 1=0D=0A(with=0D=0A> > its inherent fail= ure) before anybody has an option to submit=0D=0Aalternative=0D=0A> > text = in any form.=0D=0A> >=0D=0A> > In the mean time, and as you acknowledge bel= ow, both options 1 and 3=0D=0A> > have "commercial" compromises for one or = other party and there's no=0D=0A> > objective way to give one priority over= the other on that basis.=0D=0A> >=0D=0A> > I would be interested in hearin= g from others (than Brian) whether=0D=0Athey=0D=0A> > think scenario A or s= cenario B below are the best starting point for=0D=0A> > now.=0D=0A> >=0D=0A= > > Cheers,=0D=0A> > Martin=0D=0A> >=0D=0A> > -----Original Message-----=0D= =0A> > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > Sent: Sunday, = 17 June 2007 6:41 AM=0D=0A> > To: Dawson, Martin; ecrit@ietf.org=0D=0A> > S= ubject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A> >=0D= =0A> > Maybe we're getting ourselves confused with the word "validation".=0D= =0AAn=0D=0A> > endpoint would like to know that the location it got was a v= alid=0D=0A> > location.=0D=0A> > It can do that by querying LoST. If it's = given a reference and a=0D=0APSAP=0D=0A> > URI,=0D=0A> > it can't check it = unless it does a dereference, gets some kind of=0D=0A> > location=0D=0A> > = and queries LoST. So option 3 leaves the endpoint not being able to=0D=0A>= > validate.=0D=0A> >=0D=0A> > If an endpoint routes, some VSPs want to val= idate that the route the=0D=0A> > endpoint handed it is valid. That's anot= her form of validation.=0D=0AOption=0D=0A> > 3=0D=0A> > doesn't provide any= way for the VSP to validate that the PSAP URI in=0D=0Athe=0D=0A> > Request= URI is a bona fide PSAP URI.=0D=0A> >=0D=0A> > Yes, option 1 requires the = LIS to provide a coarse location value=0D=0Afor=0D=0A> > anyone=0D=0A> > th= at asks. It provides a way for the endpoint to validate that the=0D=0A> > = location=0D=0A> > results in a route to a PSAP, and it provides a way for a= VSP to=0D=0A> > validate=0D=0A> > that the URI is a valid PSAP URI.=0D=0A>= >=0D=0A> > If there is no forest guide, the local LoST server is still hig= hly=0D=0A> > likely to=0D=0A> > have the route for the location the endpoin= t is given. Everything=0D=0A> > except=0D=0A> > VSP validation works witho= ut forest guides. PSAP validation=0D=0Arequires=0D=0A> > that=0D=0A> > the= VSP have access to the same LoST data that the endpoint does.=0D=0AIn=0D=0A= > > the=0D=0A> > general case, that means forest guides. There are lots of= cases=0D=0Awhere=0D=0A> > the=0D=0A> > VSP could reasonably get access to = the LoST data where MOST of his=0D=0A> > subscribers are, but most is not a= ll, and forest guides would be=0D=0A> > required.=0D=0A> >=0D=0A> > With op= tion 3, the LIS is highly likely to have access to LoST data=0D=0A> > cover= ing=0D=0A> > it's service area, so no forest guides are needed. The endpoi= nt=0D=0Acan't=0D=0A> > validate, so whether there are forest guides is moot= =2E Same for VSP=0D=0A> > validation.=0D=0A> >=0D=0A> > There is a documen= t that describes how forest guides work. There=0D=0Ahas=0D=0A> > been=0D=0A= > > discussion on this document, which has had more than one revision.=0D=0A= The=0D=0A> > only=0D=0A> > words describing how option 3 might provide vali= dation are email=0D=0A> > discussions=0D=0A> > of reverse lookups, and one = email from you that said "The ability to=0D=0A> > verify=0D=0A> > a destina= tion PSAP URI as a valid emergency URI could be supported=0D=0Aby=0D=0A> > = reference to a relatively static table maintained by global=0D=0A> > cooper= ation."=0D=0A> > That is the extent of the discussion. There is no text.=0D= =0A> >=0D=0A> > I more or less understand how reverse lookup would work. I= think we=0D=0A> > would=0D=0A> > have a significant piece of work to add t= hat to the current LoST=0D=0A> > document.=0D=0A> > I think everyone agrees= that now is not the time to do that work.=0D=0AIf=0D=0A> > you=0D=0A> > ac= cept VSP validation as a requirement, which I do (reluctantly, but=0D=0A> >= then I=0D=0A> > accept location hiding as a requirement just as reluctantl= y) then we=0D=0A> > need=0D=0A> > something that doesn't need a change to L= oST with the impact of=0D=0Areverse=0D=0A> > lookups. You have suggested s= omething. I think it won't work, but=0D=0Ait's=0D=0A> > hard to criticize = because there is no text. In your latest email,=0D=0Ayou=0D=0A> > have=0D=0A= > > another idea, which I find equally unlikely to work, but again,=0D=0Ath= ere is=0D=0A> > no=0D=0A> > text to criticize.=0D=0A> >=0D=0A> > I don't re= ally like option 3, but I could live with it if there was=0D=0Aa=0D=0A> > w= ay=0D=0A> > for the VSP to validate. I'd really like a way for the endpoin= t to=0D=0A> > validate, but that is not quite so important. I don't want t= o hold=0D=0Aup=0D=0A> > LoST.=0D=0A> >=0D=0A> > So, I'd say, in the absence= of a reasonable alternative, with text=0D=0Athat=0D=0A> > has=0D=0A> > had= some level of review, and has at least a reasonable amount of=0D=0A> > con= sensus,=0D=0A> > that we document option 1 (in phonebcp) and keep working.=0D= =0A> >=0D=0A> > Brian=0D=0A> > > -----Original Message-----=0D=0A> > > From= : Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> > > Sent: Friday,= June 15, 2007 10:25 PM=0D=0A> > > To: Brian Rosen; ecrit@ietf.org=0D=0A> >= > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A> = > >=0D=0A> > > If the "normal case" is endpoint route, then there's no need= to=0D=0A> > > validate, right=3F So option 3 supports this without any nee= d to=0D=0Aprovide=0D=0A> > > location information. Option 1 requires it to = provide location=0D=0A> > > information *for all requests* since it doesn't= really know this=0D=0Ais an=0D=0A> > > emergency scenario.=0D=0A> > >=0D=0A= > > > So - let's leave end-point route out of the discussion with the=0D=0A= note=0D=0A> > > that option 3 satisfies the location hiding requirement mos= t=0D=0A> > > satisfactorily and without impact on VSP validation.=0D=0A> > = >=0D=0A> > > Now - for VSP route where the issue of URI validation comes up=0D= =0A(which=0D=0A> > is=0D=0A> > > also purely a commercial issue AFAIK).=0D=0A= > > >=0D=0A> > > A. If there's no forest guide in place, option 1 doesn't a= llow the=0D=0A> > > emergency call to be routed at all but at least nobody = will have=0D=0Ato=0D=0A> > > worry about whether the non-call should be cha= rged for or not.=0D=0A> > >=0D=0A> > > B. If there's no functional way to v= alidate the proffered PSAP URI=0D=0A> > then=0D=0A> > > option 3 requires t= he VSP to decide whether to charge for the call=0D=0Aor=0D=0A> > > not base= d on its policy in this regard. However, the emergency=0D=0Acall=0D=0A> > c= an=0D=0A> > > always be made regardless of the availability of a functional=0D= =0Aforest=0D=0A> > > guide network.=0D=0A> > >=0D=0A> > > Your proposition = is that scenario A is preferable to scenario B. I=0D=0A> > think=0D=0A> > >= that is profoundly incorrect. I think it's self-evidently so.=0D=0A> > >=0D= =0A> > > You continually dismiss any attempt on my part to start a=0D=0Adis= cussion=0D=0A> > > about ways for a VSP to validate the PSAP URI as "hand w= aving".=0D=0AEvery=0D=0A> > > reasonable discussion based on a genuine desi= re to solve a problem=0D=0A> > > starts with those sorts of suggestions. Yo= ur approach is a=0D=0A> > > self-fulfilling argument that says there's no s= olution therefore=0D=0Athere=0D=0A> > > can't be a solution, because I'm si= mply not going to talk about=0D=0Aone.=0D=0A> > How=0D=0A> > > about a BCP = that says that PSAP URIs should follow a specific=0D=0A> > convention=0D=0A= > > > in terms of domain name structure=3F The VSP would only provide=0D=0A= > > emergency=0D=0A> > > call tariffs to destinations that satisfy that BCP= =2E Then somebody=0D=0A> > > wanting to "scam a free call" would have to ma= ke sure that the=0D=0Acalled=0D=0A> > > party URI met that form. Not partic= ularly useful.=0D=0A> > >=0D=0A> > > There's no precedent for a US-based op= erator charging for=0D=0Aemergency=0D=0A> > > calls made by subscribers roa= ming in foreign jurisdictions. PSTN=0D=0Acalls=0D=0A> > > (whether cellular= or wireline) are always handled by an operator=0D=0Ain=0D=0A> > that=0D=0A= > > > jurisdiction. In the case of cellular, it is handled by the=0D=0Aroam= ing=0D=0A> > > partner in that jurisdiction. VoIP is the first instance of = the=0D=0Acall=0D=0A> > > processing occurring at the home provider end whil= e the call=0D=0Aoccurs in=0D=0A> > > the foreign jurisdiction. I think it's= extremely unlikely that=0D=0A> > charging=0D=0A> > > for emergency calls m= ade in foreign jurisdictions would be=0D=0Aillegal.=0D=0A> > > There's only= the barest shreds of legislation covering VoIP in any=0D=0A> > > respect a= t all at the moment.=0D=0A> > >=0D=0A> > > Cheers,=0D=0A> > > Martin=0D=0A>= > >=0D=0A> > > -----Original Message-----=0D=0A> > > From: Brian Rosen [ma= ilto:br@brianrosen.net]=0D=0A> > > Sent: Saturday, 16 June 2007 12:53 AM=0D= =0A> > > To: Dawson, Martin; ecrit@ietf.org=0D=0A> > > Subject: RE: [Ecrit]= Proposals 1 and 3 - summary of perspectives=0D=0A> > >=0D=0A> > > Huh=3F = I said the normal case is endpoint route. If the endpoint=0D=0A> > routes,=0D= =0A> > > option 1 is endpoint gets coarse location, endpoint queries LoST.=0D= =0ANo=0D=0A> > > forest=0D=0A> > > guide.=0D=0A> > >=0D=0A> > > If the VSP = routes, either option needs forest guides.=0D=0A> > >=0D=0A> > > Option 1 a= nd Option 3 need forest guides for the VSP to validate.=0D=0A> > >=0D=0A> >= > I don't see why a VSP would have a replica of the LoST database,=0D=0Abu= t=0D=0A> > if=0D=0A> > > it=0D=0A> > > did, it wouldn't cover the world. S= o unless it restricts=0D=0Anomading, it=0D=0A> > > has=0D=0A> > > to rely o= n forest guides to validate (or route). If it did have a=0D=0A> > > replic= a,=0D=0A> > > it could have some non standard way to validate for the parts= of=0D=0Athe=0D=0A> > > database it had. That's not a solution, that's an = optimization.=0D=0AI=0D=0A> > > don't=0D=0A> > > think you can handwave wit= h "charge for foreign emergency calls".=0D=0A> > They=0D=0A> > > aren't "fo= reign" to the guy making them. I think it would be=0D=0Aillegal=0D=0A> > i= n=0D=0A> > > the=0D=0A> > > U.S. for example, although the VSP may not be s= ubject to U.S. law=0D=0Ain=0D=0A> > all=0D=0A> > > cases.=0D=0A> > >=0D=0A>= > > I think a reasonable strategy for a VSP attempting to validate is=0D=0A= to=0D=0A> > > arrange=0D=0A> > > forest guides, and to permit emergency cal= ls from areas where it=0D=0A> > cannot=0D=0A> > > get=0D=0A> > > coverage f= or without validation.=0D=0A> > >=0D=0A> > > Brian=0D=0A> > >=0D=0A> > >=0D= =0A> > >=0D=0A> > > > -----Original Message-----=0D=0A> > > > From: Dawson,= Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> > > > Sent: Friday, June 1= 5, 2007 9:19 AM=0D=0A> > > > To: Brian Rosen; ecrit@ietf.org=0D=0A> > > > S= ubject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A> > > = >=0D=0A> > > > OK - but there's a very significant qualitative difference t= hat=0D=0Ayou=0D=0A> > > > haven't acknowledged yet.=0D=0A> > > >=0D=0A> > >= > Option 3 works without dependency on forest guides - it can work=0D=0A> = > > > straight away. Option 1 means that emergency calls will simply=0D=0Af= ail=0D=0A> > to=0D=0A> > > > route until a global and reliable forest guide= infrastructure is=0D=0Ain=0D=0A> > > > place. As I said, that's completely= independent of the question=0D=0Aof=0D=0A> > > > location hiding. Even if = the LIS wasn't hiding location I'd=0D=0Astill=0D=0A> > > > recommend that t= he device acquires the PSAP URI from the local=0D=0A> > > services=0D=0A> >= > > and not just hope that the VSP can do it for it.=0D=0A> > > >=0D=0A> >= > > If the VSP is really going to run its own copy of the LoST data=0D=0Af= or=0D=0A> > > the=0D=0A> > > > area of coverage that it cares about, then i= t can use any=0D=0Ainternal=0D=0A> > > > mechanism it likes to spot the mat= ching PSAP URI in the=0D=0Adatabase. It=0D=0A> > > > doesn't have to talk L= oST to its own infrastructure. Barbara=0D=0Apointed=0D=0A> > > out=0D=0A> >= > > that, as a VSP operator, she isn't going to be so concerned=0D=0Aabout=0D= =0A> > > those=0D=0A> > > > "foreign" emergency calls anyway. I actually ag= ree with the=0D=0A> > sentiments=0D=0A> > > > expressed that a VSP should s= till have a mission to support=0D=0A> > emergency=0D=0A> > > > calling rega= rdless of point of origin. In the spirit of=0D=0ABarbara's=0D=0A> > > > pos= ition, however, perhaps it's still reasonable if they charge=0D=0Afor=0D=0A= > > > > those "foreign" emergency calls.=0D=0A> > > >=0D=0A> > > > Main poi= nt - I think the ability to provide global emergency=0D=0Aservice=0D=0A> > = > as=0D=0A> > > > soon as possible is a better goal than saying I'll wait u= ntil I=0D=0Acan=0D=0A> > be=0D=0A> > > > sure that global emergency service= can be provided for free=0D=0Abefore=0D=0A> > the=0D=0A> > > > service can= be used at all.=0D=0A> > > >=0D=0A> > > > Cheers,=0D=0A> > > > Martin=0D=0A= > > > >=0D=0A> > > > -----Original Message-----=0D=0A> > > > From: Brian Ro= sen [mailto:br@brianrosen.net]=0D=0A> > > > Sent: Friday, 15 June 2007 11:0= 3 PM=0D=0A> > > > To: Dawson, Martin; ecrit@ietf.org=0D=0A> > > > Subject: = RE: [Ecrit] Proposals 1 and 3 - summary of perspectives=0D=0A> > > >=0D=0A>= > > > Yeah, you agree with me. You just want to ignore the VSP=0D=0Avalid= ation=0D=0A> > > > problem. I'd like to ignore the location hiding problem= , but=0D=0Awe're=0D=0A> > > > stuck=0D=0A> > > > with both.=0D=0A> > > >=0D= =0A> > > > If you come up with some way other than allowing the VSP to get=0D= =0A> > coarse=0D=0A> > > > location and using that to validate the PSAP URI= , then we can=0D=0Ause=0D=0A> > that=0D=0A> > > > for=0D=0A> > > > option 1= or 3. So far there is no other mechanism that we can=0D=0Ause.=0D=0A> > >= We=0D=0A> > > > can=0D=0A> > > > extend LoST in some way to do it, but sev= eral of us are=0D=0Asuggesting=0D=0A> > > that=0D=0A> > > > we=0D=0A> > > >= postpone that work and get LoST out now.=0D=0A> > > >=0D=0A> > > > I certa= inly agree that the basic assumption that the access=0D=0A> > provider,=0D=0A= > > > > LoST=0D=0A> > > > server and PSAP are local to one another is a goo= d one. It's=0D=0Awhat=0D=0A> > > makes=0D=0A> > > > option 1 or 3 possible= , and gives the greatest likelihood that=0D=0Athe=0D=0A> > > > system=0D=0A= > > > > will work. I think having the VSP route is fairly easy, but=0D=0A>= > "fairly"=0D=0A> > > > means=0D=0A> > > > that we need forest guides so t= hat callers that are remote can=0D=0Abe=0D=0A> > > > routed.=0D=0A> > > > I= 'd strongly prefer endpoints to route. That will be much more=0D=0A> > lik= ely=0D=0A> > > > to=0D=0A> > > > work in all circumstances. It seems very = unlikely to me that we=0D=0A> > would=0D=0A> > > > have=0D=0A> > > > a situ= ation where the endpoint could supply location, but could=0D=0Anot=0D=0A> >= do=0D=0A> > > > dialstring recognition and routing. Having the VSP supply=0D= =0Alocation=0D=0A> > > AND=0D=0A> > > > route is really going to be difficu= lt with VPNs and NATs, etc.=0D=0A> > > >=0D=0A> > > > With respect to who r= uns the servers, I believe you are=0D=0Aconflating=0D=0A> > two=0D=0A> > > = > parts=0D=0A> > > > of the problem: who is responsible for the data, and w= ho runs=0D=0Athe=0D=0A> > > actual=0D=0A> > > > server. The PSAP is respon= sible for the data. It will probably=0D=0Arun=0D=0A> > a=0D=0A> > > > serv= er which anyone can use. However, I believe most access=0D=0Anetwork=0D=0A= > > > > providers will want a copy of the data in a server they run.=0D=0AT= hat=0D=0A> > is=0D=0A> > > > the=0D=0A> > > > purpose of the LoST mechanism= s to maintain replicas of the data.=0D=0A> > > >=0D=0A> > > > Brian=0D=0A> = > > >=0D=0A> > > >=0D=0A> > > >=0D=0A> > > > > -----Original Message-----=0D= =0A> > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> = > > > > Sent: Friday, June 15, 2007 3:32 AM=0D=0A> > > > > To: ecrit@ietf.o= rg=0D=0A> > > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of=0D=0A= perspectives=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > > > > Speak for yoursel= f :) Your description of option 3 does not=0D=0A> > > correlate=0D=0A> > > = > > with my description or understanding of it. So, if there's=0D=0A> > > c= onfusion,=0D=0A> > > > > perhaps this is the root of it.=0D=0A> > > > >=0D=0A= > > > > > In option 3 - the access network doesn't determine coarse=0D=0Alo= cation=0D=0A> > > at=0D=0A> > > > > all. It doesn't concern itself with coa= rse location. It uses=0D=0Athe=0D=0A> > > > precise=0D=0A> > > > > location= that it determines for the device, queries the local=0D=0ALoST=0D=0A> > > = > > server and provides the resultant PSAP URI directly to the=0D=0Adevice.=0D= =0A> > > At=0D=0A> > > > > this point the routing has been achieved and the= device can=0D=0Aroute=0D=0A> > > > > directly or via the VSP. When the PSA= P dereferences, it gets=0D=0Athe=0D=0A> > > > precise=0D=0A> > > > > locati= on from the LIS. It is exactly because the routing is=0D=0A> > achieved=0D=0A= > > > > by=0D=0A> > > > > just the local elements that this option doesn't = have the=0D=0AAchilles=0D=0A> > > > heel=0D=0A> > > > > of option 1 which r= equires the VSP, absolutely, to be able to=0D=0Afind=0D=0A> > > the=0D=0A> = > > > > authoritative local LoST server. As I say, for a very remote=0D=0AV= SP=0D=0A> > and=0D=0A> > > > no=0D=0A> > > > > functioning forest guide, it= may very well not be able to.=0D=0A> > > > >=0D=0A> > > > > There's a basi= c principle here - emergency services are local=0D=0Ato=0D=0A> > the=0D=0A>= > > > > caller, the access network operator (and LIS) are local to the=0D=0A= > > > caller,=0D=0A> > > > > and the authoritative LoST server is going to = most local to=0D=0Athe=0D=0A> > > > caller.=0D=0A> > > > > The ability to r= eliably route the call is going to be optimal=0D=0Aif=0D=0A> > > it's=0D=0A= > > > > > done between all these local entities who are best placed to=0D=0A= be=0D=0A> > > aware=0D=0A> > > > of=0D=0A> > > > > each other. Waiting unti= l the call scenario has geographically=0D=0A> > > > diverged=0D=0A> > > > >= to the VSP before attempting to determine routing is=0D=0Aunnecessarily=0D= =0A> > > > > sub-optimal.=0D=0A> > > > >=0D=0A> > > > > In option 1 - how d= o you propose the access network determine=0D=0Athe=0D=0A> > > > > "coarse = location"=3F I believe your proposal is that it uses the=0D=0A> > local=0D=0A= > > > > > LoST server applicable to its area of coverage and utilize the=0D= =0A> > > > semantics=0D=0A> > > > > of LoST which provide a PSAP boundary i= n the response. Can you=0D=0A> > > confirm=0D=0A> > > > > that this is your= proposal=3F Otherwise, how would you=0D=0Aanticipate=0D=0A> > that=0D=0A> = > > > the=0D=0A> > > > > access provider, who doesn't manage the PSAP bound= aries after=0D=0Aall,=0D=0A> > > > would=0D=0A> > > > > know what is the ap= propriate coarse location that will result=0D=0Ain a=0D=0A> > > > > reliabl= e response when LoST is queried=3F=0D=0A> > > > >=0D=0A> > > > > With respe= ct to Henning's comment about LoST services being=0D=0A> > provided=0D=0A> = > > > by=0D=0A> > > > > ISPs and/or VSPs, I didn't resonate with that. I wo= uld expect=0D=0Athat=0D=0A> > > > LoST=0D=0A> > > > > is emergency services= specific and it is likely to be part of=0D=0Asome=0D=0A> > > > > jurisdict= ional function or some provider of services to that=0D=0A> > > > > jurisdic= tional function. I don't see that either ISPs or VSPs=0D=0Aare=0D=0A> > > >= > qualified to manage the PSAP routing information contained in=0D=0Aa=0D=0A= > > LoST=0D=0A> > > > > server.=0D=0A> > > > >=0D=0A> > > > > Cheers,=0D=0A= > > > > > Martin=0D=0A> > > > >=0D=0A> > > > > -----Original Message-----=0D= =0A> > > > > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > > > > Se= nt: Thursday, 14 June 2007 11:07 PM=0D=0A> > > > > To: Dawson, Martin; 'ECR= IT'=0D=0A> > > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of=0D=0A= perspectives=0D=0A> > > > >=0D=0A> > > > > Wait a minute, we're getting con= fused.=0D=0A> > > > >=0D=0A> > > > > Option 1 requires that the access netw= ork dereference to=0D=0Aanyone=0D=0A> > with=0D=0A> > > > at=0D=0A> > > > >= least coarse location suitable for emergency call routing. If=0D=0Athe=0D= =0A> > > > > endpoint=0D=0A> > > > > does routing, it will use a local LoST= server which has high=0D=0A> > > > probability=0D=0A> > > > > of=0D=0A> > = > > > having the route. If a VSP wants to verify, it needs access=0D=0Ato = a=0D=0A> > > LoST=0D=0A> > > > > server covering the area where his custome= rs roam. The cost=0D=0Ais on=0D=0A> > > the=0D=0A> > > > > carrier that is= trying to hide location (which, AFAIK, is an=0D=0A> > > economic=0D=0A> > = > > > issue=0D=0A> > > > > all the way, the hiding is so the access network= can charge=0D=0Afor=0D=0A> > non=0D=0A> > > > > emergency uses of location= ).=0D=0A> > > > >=0D=0A> > > > > Option 3 requires that the access network = dereference to=0D=0Aanyone=0D=0A> > with=0D=0A> > > > at=0D=0A> > > > > lea= st coarse location suitable for emergency call routing.=0D=0AThis=0D=0A> > = is=0D=0A> > > > > because=0D=0A> > > > > if the endpoint doesn't route (or = more specifically, if it=0D=0Adoesn't=0D=0A> > > > > recognize=0D=0A> > > >= > emergency dialstrings, query LoST, and add the PSAP URI), but=0D=0Adoes=0D= =0A> > > > > supply=0D=0A> > > > > location, then the VSP has to route, and= it will have to=0D=0A> > > dereference.=0D=0A> > > > > If=0D=0A> > > > > t= he endpoint does routing, option 3 is easy, because it will=0D=0Ahave=0D=0A= > > > the=0D=0A> > > > > correct PSAP URIs (it has to be all of them, BTW, = a problem in=0D=0A> > > > itself).=0D=0A> > > > > If=0D=0A> > > > > a VSP w= ants to verify, it needs access to a LoST server=0D=0Acovering=0D=0A> > the=0D= =0A> > > > > area=0D=0A> > > > > where his customers roam. It can't use th= e LCP, it has to=0D=0A> > > dereference=0D=0A> > > > > the=0D=0A> > > > > l= ocation, and then query LoST.=0D=0A> > > > >=0D=0A> > > > > If we supply a = different mechanism for a VSP to validate, that=0D=0A> > could=0D=0A> > > >= > change,=0D=0A> > > > > and it would affect 1 and 3 the same way.=0D=0A> = > > > >=0D=0A> > > > > Brian=0D=0A> > > > >=0D=0A> > > > > > -----Original = Message-----=0D=0A> > > > > > From: Dawson, Martin [mailto:Martin.Dawson@an= drew.com]=0D=0A> > > > > > Sent: Wednesday, June 13, 2007 10:56 PM=0D=0A> >= > > > > To: ECRIT=0D=0A> > > > > > Subject: RE: [Ecrit] Proposals 1 and 3 = - summary of=0D=0Aperspectives=0D=0A> > > > > >=0D=0A> > > > > > Typo alert= - obviously it should have said that option *1*=0D=0A> > > requires=0D=0A>= > > > > the=0D=0A> > > > > > VSP to work out the local LoST server in addi= tion to the LIS=0D=0A> > > needing=0D=0A> > > > > to=0D=0A> > > > > > know = it.=0D=0A> > > > > >=0D=0A> > > > > > Cheers,=0D=0A> > > > > > Martin=0D=0A= > > > > > >=0D=0A> > > > > > -----Original Message-----=0D=0A> > > > > > Fr= om: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> > > > > > Sent:= Thursday, 14 June 2007 11:14 AM=0D=0A> > > > > > To: Henning Schulzrinne; = Winterbottom, James=0D=0A> > > > > > Cc: ECRIT=0D=0A> > > > > > Subject: RE= : [Ecrit] Proposals 1 and 3 - summary of=0D=0Aperspectives=0D=0A> > > > > >=0D= =0A> > > > > > BTW - as I understand option 1, it requires the LIS to query=0D= =0Athe=0D=0A> > > > local=0D=0A> > > > > > LoST server as well. At least th= at's how I recall Brian's=0D=0A> > original=0D=0A> > > > > > proposal being= stated. It returns a "PSAP URI boundary"=0D=0Alocation=0D=0A> > > > > inst= ead=0D=0A> > > > > > of the PSAP URI.=0D=0A> > > > > >=0D=0A> > > > > > I t= hink folk are being inconsistent characterising option 3=0D=0Aas=0D=0A> > >= > adding=0D=0A> > > > > > LoST functionality to HELD. Both proposals requi= re the LIS=0D=0Ato=0D=0A> > > > interact=0D=0A> > > > > > with LoST with th= e subsequent proxying of results to the=0D=0Adevice.=0D=0A> > > > > >=0D=0A= > > > > > > If the proposition of option 1 is that it's actually the LIS=0D= =0A> > that=0D=0A> > > > > holds=0D=0A> > > > > > the PSAP-relevant boundar= y information, then option 1 is=0D=0A> > actually=0D=0A> > > > much=0D=0A> = > > > > > more like adding LoST functionality to the LIS (and adds=0D=0A> >= > > inappropriate=0D=0A> > > > > > responsibility to the LIS provider).=0D= =0A> > > > > >=0D=0A> > > > > > Further, given my understanding, both propo= sals rely on the=0D=0ALIS=0D=0A> > > > > knowing=0D=0A> > > > > > inherentl= y what the appropriate local LoST server is. Option=0D=0A1=0D=0A> > > just=0D= =0A> > > > > > means that this is required *as well as* the VSP being able=0D= =0Ato=0D=0A> > > reach=0D=0A> > > > > > that same local LoST service.=0D=0A= > > > > > >=0D=0A> > > > > > Neither option requires the ISP to implement L= oST, they just=0D=0A> > > require=0D=0A> > > > > the=0D=0A> > > > > > ISP t= o know which LoST server is applicable to the local=0D=0Aarea of=0D=0A> > >= > > > coverage. That's much more practical than expecting any=0D=0A> > arb= itrary=0D=0A> > > > > global=0D=0A> > > > > > VSP being able to work that o= ut but that is what option 3=0D=0A> > requires=0D=0A> > > > *in=0D=0A> > > = > > > addition*.=0D=0A> > > > > >=0D=0A> > > > > > Cheers,=0D=0A> > > > > >= Martin=0D=0A> > > > > >=0D=0A> > > > > > -----Original Message-----=0D=0A>= > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A> > = > > > > Sent: Thursday, 14 June 2007 10:22 AM=0D=0A> > > > > > To: Winterbo= ttom, James=0D=0A> > > > > > Cc: ECRIT=0D=0A> > > > > > Subject: Re: [Ecrit= ] Proposals 1 and 3 - summary of=0D=0Aperspectives=0D=0A> > > > > >=0D=0A> = > > > > > I assume that your discussion has nothing to do with=0D=0Alocatio= n=0D=0A> > > hiding=0D=0A> > > > > > at this point, but wanted to call this= out just in case I'm=0D=0A> > > missing=0D=0A> > > > > > your train of tho= ught.=0D=0A> > > > > >=0D=0A> > > > > > I'm afraid I don't follow your logi= c. Unless you assume that=0D=0A> > every=0D=0A> > > > > > ISP deploys a LoS= T+HELD server, VSPs will have to have LoST=0D=0A> > > servers=0D=0A> > > > = > > with PSAP knowledge for the places their customers are=0D=0Alikely to=0D= =0A> > > > > > visit. This doesn't change whether HELD also gets converted=0D= =0Ainto=0D=0A> > a=0D=0A> > > > > > LoST access protocol or not. So far, at= least, VSPs seem a=0D=0Awhole=0D=0A> > > lot=0D=0A> > > > > > more interes= ted in providing emergency call services than=0D=0AISPs,=0D=0A> > > > > > p= resumably because their customers look to them for that=0D=0A> > service,=0D= =0A> > > > not=0D=0A> > > > > > to the random hot spot operator.=0D=0A> > >= > > >=0D=0A> > > > > > It's always been the model that both ISPs and VSPs = (as well=0D=0Aas=0D=0A> > > third=0D=0A> > > > > > parties that are neither= ) can and should operate LoST=0D=0Aservers,=0D=0A> > as=0D=0A> > > > > > th= at seems most likely to ensure that you get broad=0D=0Acoverage.=0D=0A> > >= > > >=0D=0A> > > > > > Henning=0D=0A> > > > > >=0D=0A> > > > > > On Jun 13= , 2007, at 8:00 PM, Winterbottom, James wrote:=0D=0A> > > > > >=0D=0A> > > = > > > > Henning,=0D=0A> > > > > > >=0D=0A> > > > > > > I think that your pr= oposal only works if the VSP is able=0D=0Ato=0D=0A> > > > provide=0D=0A> > = > > > a=0D=0A> > > > > > > LoST server for all jurisdictions that it plans = to provide=0D=0A> > > service=0D=0A> > > > > > > for,=0D=0A> > > > > > > or= it has to do it for everything (sounds awfully like a=0D=0A> > global=0D=0A= > > > > VPC=0D=0A> > > > > to=0D=0A> > > > > > > me). Option 3 would be dep= loyable from a local area to a=0D=0Alocal=0D=0A> > > > PSAP=0D=0A> > > > > = > > REGARDLESS of the VSP having a LoST server that has=0D=0Aboundary=0D=0A= > > > > > > > information=0D=0A> > > > > > > for the local area I am in. It= provides a global solution=0D=0Afrom=0D=0A> > > the=0D=0A> > > > > > > get= -go.=0D=0A> > > > > > >=0D=0A> > > > > > > Let's take the good old Sierra-L= eone example again.=0D=0A> > > > > > >=0D=0A> > > > > > > My VSP is in Sier= ra-Leone and I am visiting Samoa. In=0D=0Aoption=0D=0A> > 3,=0D=0A> > > I=0D= =0A> > > > > > > get a=0D=0A> > > > > > > PSA P URI for the local Samoan PS= AP from the local access=0D=0ALIS=0D=0A> > > > > serving=0D=0A> > > > > > >= the area I am in, I send my call to VSP, it sends it on=0D=0Athe=0D=0A> > = > PSAP.=0D=0A> > > > I=0D=0A> > > > > > > get=0D=0A> > > > > > > billed, ca= ll completes, we are done. I can quibble with my=0D=0AVSP=0D=0A> > > > late= r=0D=0A> > > > > > > over the 10 cent call charge if I can be bothered.=0D=0A= > > > > > > >=0D=0A> > > > > > > With option 1, I send my call with locatio= n to my VSP, and=0D=0Aone=0D=0A> > > of=0D=0A> > > > > > > three=0D=0A> > >= > > > > things happens. Either it has a complete forest guide=0D=0Anetwork=0D= =0A> > > set-=0D=0A> > > > > > > up to=0D=0A> > > > > > > be able to talk t= o the Samoan LoST server nearest me, my=0D=0Acall=0D=0A> > > > > > > fails,= or=0D=0A> > > > > > > the VSP routes the call anyway because the end-point= has=0D=0Adone=0D=0A> > > the=0D=0A> > > > > LoST=0D=0A> > > > > > > lookup= =2E I point out, that from the VSP perspective the=0D=0Athird=0D=0A> > > > = > > > alternative=0D=0A> > > > > > > here is simply option 3 re-badged. I a= m sure that VSPs=0D=0A> > wouldn't=0D=0A> > > > > > > drop the=0D=0A> > > >= > > > call on the floor, so choice 2 isn't an option, and choice=0D=0A1=0D= =0A> > can=0D=0A> > > > > ONLY=0D=0A> > > > > > > occur if the whole networ= k is up and running, and it=0D=0Adoesn't=0D=0A> > > > > > > consist of=0D=0A= > > > > > > > isolated copse of Forest Guides and LoST Servers.=0D=0A> > > = > > > >=0D=0A> > > > > > > So to my mind, option 3 is the ONLY deployable s= olution in=0D=0Athe=0D=0A> > > > short=0D=0A> > > > > > > term that will ac= tually work universally.=0D=0A> > > > > > >=0D=0A> > > > > > > Cheers=0D=0A= > > > > > > > James=0D=0A> > > > > > >=0D=0A> > > > > > >=0D=0A> > > > > > = >> -----Original Message-----=0D=0A> > > > > > >> From: Henning Schulzrinne= [mailto:hgs@cs.columbia.edu]=0D=0A> > > > > > >> Sent: Thursday, 14 June 2= 007 12:58 AM=0D=0A> > > > > > >> To: Dawson, Martin=0D=0A> > > > > > >> Cc:= ecrit@ietf.org=0D=0A> > > > > > >> Subject: Re: [Ecrit] Proposals 1 and 3 = - summary of=0D=0A> > > perspectives=0D=0A> > > > > > >>=0D=0A> > > > > > >= >=0D=0A> > > > > > >> On Jun 13, 2007, at 10:54 AM, Dawson, Martin wrote:=0D= =0A> > > > > > >>=0D=0A> > > > > > >>> Nobody has suggested changing LoST s= o this point is just=0D=0Aa=0D=0A> > > > > > >>> distraction.=0D=0A> > > > = > > >>>=0D=0A> > > > > > >>>=0D=0A> > > > > > >>>=0D=0A> > > > > > >>> Opti= on 1 means that emergency calls will not be able to=0D=0Abe=0D=0A> > > > ro= uted=0D=0A> > > > > > >>> until the forest guide network is implemented. Op= tion 3=0D=0A> > means=0D=0A> > > > that=0D=0A> > > > > > >>> emergency call= s will be able to be routed regardless of=0D=0Athe=0D=0A> > > > state=0D=0A= > > > > > > >>> of deployment of the forest guide.=0D=0A> > > > > > >>>=0D=0A= > > > > > > >>>=0D=0A> > > > > > >> This is not true, at least for comparab= le installations.=0D=0AThe=0D=0A> > > ISP=0D=0A> > > > > can=0D=0A> > > > >= > >> offer a LoST server that has the locally-relevant=0D=0A> > informatio= n.=0D=0A> > > > Same=0D=0A> > > > > > >> for the VSP. This does not require= a forest guide as=0D=0Asuch.=0D=0A> > > > > > >>=0D=0A> > > > > > >> _____= __________________________________________=0D=0A> > > > > > >> Ecrit mailin= g list=0D=0A> > > > > > >> Ecrit@ietf.org=0D=0A> > > > > > >> https://www1.= ietf.org/mailman/listinfo/ecrit=0D=0A> > > > > > >=0D=0A> > > > > > >=0D=0A= > > > > >=0D=0A> > >=0D=0A-------------------------------------------------= ---------------------=0D=0A> > > > > >=0D=0A> > > > > > > -----------------= ---------=0D=0A> > > > > > > This message is for the designated recipient o= nly and may=0D=0A> > > > > > > contain privileged, proprietary, or otherwis= e private=0D=0A> > > information.=0D=0A> > > > > > > If you have received i= t in error, please notify the sender=0D=0A> > > > > > > immediately and del= ete the original. Any unauthorized use=0D=0Aof=0D=0A> > > > > > > this ema= il is prohibited.=0D=0A> > > > > > >=0D=0A> > > > >=0D=0A> > >=0D=0A-------= ---------------------------------------------------------------=0D=0A> > > = > > >=0D=0A> > > > > > > --------------------------=0D=0A> > > > > > > [mf2= ]=0D=0A> > > > > > >=0D=0A> > > > > >=0D=0A> > > > > >=0D=0A> > > > > > ___= ____________________________________________=0D=0A> > > > > > Ecrit mailing= list=0D=0A> > > > > > Ecrit@ietf.org=0D=0A> > > > > > https://www1.ietf.or= g/mailman/listinfo/ecrit=0D=0A> > > > > >=0D=0A> > > > > >=0D=0A> > > > >=0D= =0A> > > >=0D=0A> > >=0D=0A> >=0D=0A---------------------------------------= ---------------------------------=0D=0A> > > > > > ------------------------=0D= =0A> > > > > > This message is for the designated recipient only and may=0D= =0A> > > > > > contain privileged, proprietary, or otherwise private=0D=0A>= > information.=0D=0A> > > > > > If you have received it in error, please n= otify the sender=0D=0A> > > > > > immediately and delete the original. Any= unauthorized use=0D=0Aof=0D=0A> > > > > > this email is prohibited.=0D=0A>= > > > > >=0D=0A> > > > >=0D=0A> > > >=0D=0A> > >=0D=0A> >=0D=0A-----------= -------------------------------------------------------------=0D=0A> > > > = > > ------------------------=0D=0A> > > > > > [mf2]=0D=0A> > > > > >=0D=0A>= > > > > >=0D=0A> > > > > > _______________________________________________=0D= =0A> > > > > > Ecrit mailing list=0D=0A> > > > > > Ecrit@ietf.org=0D=0A> > = > > > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > > > > >=0D=0A= > > > > > >=0D=0A> > > > >=0D=0A> > > >=0D=0A> > >=0D=0A> >=0D=0A----------= --------------------------------------------------------------=0D=0A> > > >= > --=0D=0A> > > > > > ----------------------=0D=0A> > > > > > This message= is for the designated recipient only and may=0D=0A> > > > > > contain priv= ileged, proprietary, or otherwise private=0D=0A> > information.=0D=0A> > > = > > > If you have received it in error, please notify the sender=0D=0A> > >= > > > immediately and delete the original. Any unauthorized use=0D=0Aof=0D= =0A> > > > > > this email is prohibited.=0D=0A> > > > > >=0D=0A> > > > >=0D= =0A> > > >=0D=0A> > >=0D=0A> >=0D=0A---------------------------------------= ---------------------------------=0D=0A> > > > > --=0D=0A> > > > > > ------= ----------------=0D=0A> > > > > > [mf2]=0D=0A> > > > > >=0D=0A> > > > > >=0D= =0A> > > > > > _______________________________________________=0D=0A> > > >= > > Ecrit mailing list=0D=0A> > > > > > Ecrit@ietf.org=0D=0A> > > > > > ht= tps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > > > >=0D=0A> > > > >=0D= =0A> > > > >=0D=0A> > > >=0D=0A> > >=0D=0A> >=0D=0A------------------------= ------------------------------------------------=0D=0A> > > > --=0D=0A> > >= > > ----------------------=0D=0A> > > > > This message is for the designat= ed recipient only and may=0D=0A> > > > > contain privileged, proprietary, o= r otherwise private=0D=0Ainformation.=0D=0A> > > > > If you have received i= t in error, please notify the sender=0D=0A> > > > > immediately and delete = the original. Any unauthorized use of=0D=0A> > > > > this email is prohibi= ted.=0D=0A> > > > >=0D=0A> > > >=0D=0A> > >=0D=0A> >=0D=0A-----------------= -------------------------------------------------------=0D=0A> > > > --=0D=0A= > > > > > ----------------------=0D=0A> > > > > [mf2]=0D=0A> > > > >=0D=0A>= > > > >=0D=0A> > > > > _______________________________________________=0D=0A= > > > > > Ecrit mailing list=0D=0A> > > > > Ecrit@ietf.org=0D=0A> > > > > h= ttps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> > > >=0D=0A> > > >=0D=0A= > > > >=0D=0A> > >=0D=0A> >=0D=0A------------------------------------------= ------------------------------=0D=0A> > > --=0D=0A> > > > -----------------= -----=0D=0A> > > > This message is for the designated recipient only and ma= y=0D=0A> > > > contain privileged, proprietary, or otherwise private=0D=0Ai= nformation.=0D=0A> > > > If you have received it in error, please notify th= e sender=0D=0A> > > > immediately and delete the original. Any unauthorize= d use of=0D=0A> > > > this email is prohibited.=0D=0A> > > >=0D=0A> > >=0D=0A= > >=0D=0A------------------------------------------------------------------= ------=0D=0A> > > --=0D=0A> > > > ----------------------=0D=0A> > > > [mf2]=0D= =0A> > >=0D=0A> > >=0D=0A> > >=0D=0A> >=0D=0A------------------------------= ------------------------------------------=0D=0A> > --=0D=0A> > > ---------= -------------=0D=0A> > > This message is for the designated recipient only = and may=0D=0A> > > contain privileged, proprietary, or otherwise private in= formation.=0D=0A> > > If you have received it in error, please notify the s= ender=0D=0A> > > immediately and delete the original. Any unauthorized use= of=0D=0A> > > this email is prohibited.=0D=0A> > >=0D=0A> >=0D=0A---------= ---------------------------------------------------------------=0D=0A> > --=0D= =0A> > > ----------------------=0D=0A> > > [mf2]=0D=0A> >=0D=0A> >=0D=0A> >=0D= =0A------------------------------------------------------------------------=0D= =0A> > ------------------------=0D=0A> > This message is for the designated= recipient only and may=0D=0A> > contain privileged, proprietary, or otherw= ise private information.=0D=0A> > If you have received it in error, please = notify the sender=0D=0A> > immediately and delete the original. Any unauth= orized use of=0D=0A> > this email is prohibited.=0D=0A> >=0D=0A------------= ------------------------------------------------------------=0D=0A> > -----= -------------------=0D=0A> > [mf2]=0D=0A> >=0D=0A> >=0D=0A> > _____________= __________________________________=0D=0A> > Ecrit mailing list=0D=0A> > Ecr= it@ietf.org=0D=0A> > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> >=0D= =0A> >=0D=0A---------------------------------------------------------------= ---------=0D=0A> --=0D=0A> > ----------------------=0D=0A> > This message i= s for the designated recipient only and may=0D=0A> > contain privileged, pr= oprietary, or otherwise private information.=0D=0A> > If you have received = it in error, please notify the sender=0D=0A> > immediately and delete the o= riginal. Any unauthorized use of=0D=0A> > this email is prohibited.=0D=0A>= >=0D=0A-------------------------------------------------------------------= -----=0D=0A> --=0D=0A> > ----------------------=0D=0A> > [mf2]=0D=0A> >=0D=0A= > >=0D=0A> > _______________________________________________=0D=0A> > Ecrit= mailing list=0D=0A> > Ecrit@ietf.org=0D=0A> > https://www1.ietf.org/mailma= n/listinfo/ecrit=0D=0A>=20=0D=0A>=20=0D=0A> _______________________________= ________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> htt= ps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A----------------------= --------------------------------------------------------------------------=0D= =0AThis message is for the designated recipient only and may=0D=0Acontain p= rivileged, proprietary, or otherwise private information. =20=0D=0AIf you h= ave received it in error, please notify the sender=0D=0Aimmediately and del= ete the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 18 21:15:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0SJu-0001UT-2M; Mon, 18 Jun 2007 21:15:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0SJs-0001T2-5d for ecrit@ietf.org; Mon, 18 Jun 2007 21:15:44 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0SJq-0002bJ-LC for ecrit@ietf.org; Mon, 18 Jun 2007 21:15:44 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I0SJY-0000sc-SB; Mon, 18 Jun 2007 20:15:27 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Dawson, Martin'" , References: <001c01c7acfc$7012e110$2400000a@cis.neustar.com><012a01c7ad51$a7d8d4b0$9501a8c0@cis.neustar.com><023701c7adb6$ad06b6e0$9501a8c0@cis.neustar.com><02e301c7adc2$813763a0$9501a8c0@cis.neustar.com><030e01c7adc5$c92d24d0$9501a8c0@cis.neustar.com><034c01c7adc7$494da170$9501a8c0@cis.neustar.com><1765EE17-3983-42EA-8259-29ED4AB474B2@cs.columbia.edu><0 87a01c7ae84$e1b48a10$9501a8c0@cis.neustar.com><0b8c01c7af4d$8e22b3d0$9501a8c0@cis.neustar.com><0bc401c7af5c$ddd16c50$9501a8c0@cis.neustar.com><0e4801c7b056$9c15d120$9501a8c0@cis.neustar.com> <112b01c7b1c1$27909620$9501a8c0@cis.neustar.com> Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives Date: Mon, 18 Jun 2007 21:15:35 -0400 Message-ID: <149101c7b20f$5a7fb180$9501a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AceuGgIUdnorn1MfT9KY7XAHcoK3nAABWk3gAAP8qIAAFRhfQAAEcxKwAC1PJ0AAAMljcAADai4wABfBL7AAJiIUMABAPJGwAAFAENAAGbuS8AAPykbQAAOx0VA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 1743cdf5f149865a6879de7e0f6ae63e Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org You can scream all you want, but I think (IANAL) that a 9-1-1 call within the US has to be free, no matter who the carrier is. The US could rule that calls within the U.S. had to be in U.S. tariffs. They have chosen not to. If they did, I suspect the systems would look different, but that is speculation and not relevant. I think getting a forest guide for 90% of the places a VoIP subscriber nomdads will be easy. Getting the last 10% will be hard. I don't see a problem in a VSP handling the last 10% by assume good and investigate. Most of the world will have only a couple of entries per customer, and regional forest guides will be readily available. It may be that there are commercial ventures who dig up the data and operate forest guides before the "official" ones, but even that may be so short life it isn't worth it. It's in everyone's best interest to have forest guides work, so that nomads get service. While I am very much in favor of having endpoints route, VSP route is going to be common as we start out. I think you have to treat VSP validation with as much respect as location hiding. They are both economic arguments. They are valid, somewhat. Long term, I suspect the hiding stuff fades away, but the validation is likely to be with us for a long time, at least until all the pricing is all you can eat. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Monday, June 18, 2007 7:30 PM > To: Brian Rosen; Dawson, Martin; ecrit@ietf.org > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > Brian, > > While I agree with some of what you have said below, I certainly don't > agree with a lot of it. > > I think that there are no grounds to suggest that SLVS can't charge > their mobile sub for making a call in the US emergency or not. Indeed > making this assertion in the way in which you have would be tantamount > to saying that all calls they made to US destinations while in the US > were national calls and their for likely free from tariff also. Which I > think we all agree is ridiculous. > > As you point out, if there is no forest guide, then the VSP has to trust > the URI provided by the caller or bill them. This is the same as > solution 3 from the VSP perspective. So what you are saying is that > solution 3 has to be the case where a forest guide is not available. > Thanks for the support.. ;) > > I think what this boils down to is that in the future PSAP URI > validation may be possible, and that from a VSP perspective it is a > billing requirement. Initially this will not be possible, either because > forest guides will not be available, or because no mechanism for PSAP > URI to service lookup will be available. > > Cheers > James > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, 19 June 2007 1:56 AM > > To: Dawson, Martin; ecrit@ietf.org > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > Yeah. > > > > I don't think we need the LIS to provide the PSAP URI for option 1. > > > > In the U.S., I think 9-1-1 calls have to be free. If your VSP is > Sierra > > Leone VoIP Services Pty, I don't think they can charge for it if they > have > > a > > nomad in Chicago. It may be the case that SLVS is not subject to U.S. > > law, > > but in theory, you can't charge for emergency calls within the > > jurisdiction > > of the caller. I do think, as a practical matter, that if the VSP > doesn't > > have a forest guide that can get it to the LoST server who is > > authoritative > > for the location, it has to assume it's valid. I think that will > work. I > > think they could subsequently look into it (why they didn't have a > forest > > guide with the data, and if it was valid). That's a trust but > > subsequently > > verify modus operandi. > > > > I think it's a requirement to validate, just like it's a requirement > to > > support location hiding. I think in the absence of a worked out way > to > > validate, Option 3 is a future possibility and not a currently > acceptable > > proposal. We may be able to get there, but not right now. > > > > Brian > > > > > -----Original Message----- > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > Sent: Sunday, June 17, 2007 11:58 PM > > > To: ecrit@ietf.org > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > Freakin' Outlook - I don't know why it deleted the line-feeds in my > > > enumerated list. It was plain text mode. Here's an attempt to make > it > > > more readable. > > > > > > Hi Brian, > > > > > > I owe you an apology. I understood option 1 incorrectly (this has > been > > > the disconnect). I've just had it pointed out to me that option 1 > also > > > relies on the LIS (or the end point) to obtain the PSAP URI for the > > > endpoint to send it to the VSP along with the coarse location. I > > > understood that the VSP wasn't going to know the PSAP URI until it > > > retrieved it from LoST. > > > > > > So to correct my summary of the two methods: > > > > > > Option 1 (VSP call processing) > > > 1. The end-point queries the LIS which determines the location of > the > > > device > > > > > > 2. The LIS queries LoST to obtain the PSAP coverage (coarse > location) > > > and PSAP URI > > > > > > 3. The LIS provides the coarse location and (optionally?) the PSAP > URI > > > > > > 4. The end point (optionally?) queries LoST again for the PSAP URI > > > > > > 5. The end point invokes the emergency call to the VSP with the > coarse > > > location and the PSAP URI > > > > > > 6. The VSP invokes the forest guide (if necessary) and queries LoST > > > again to see if the PSAP URI that is returned is the same as the one > > > provided by the end point > > > > > > 7. If the PSAP URI has "validated" then the call is processed. > > > > > > Option 3 (VSP call processing) > > > 1. The end-point queries the LIS which determines the location of > the > > > device > > > > > > 2. The LIS queries LoST to obtain the PSAP URI for the location > > > > > > 3. The LIS provides the PSAP URI to the device > > > > > > 4. The end point invokes the emergency call to the VSP with the PSAP > URI > > > > > > 5. The VSP routes the emergency call (and charges for it or not > > > depending on policy) > > > > > > > > > Option 1 requires the LIS operator to always provide location > > > information - which is useful depending on the granularity required > by > > > the jurisdiction. The VSP might be able to validate the PSAP URI if > the > > > forest guide exists or it happens to have the access to the LoST > > > information one way or the other. > > > > > > Option 3 does not require the LIS operator to provide any location. > The > > > VSP has to apply a policy on emergency calls in the absence of the > > > ability validate the PSAP URI - at least until such time as the > forest > > > guide or other mechanism supports this validation (text pending). > > > > > > Does that summarize things more fairly? > > > > > > Cheers, > > > Martin > > > > > > -----Original Message----- > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > Sent: Monday, 18 June 2007 1:07 PM > > > To: Brian Rosen; ecrit@ietf.org > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > I'd like to challenge the following: > > > > > > " If there is no forest guide, the local LoST server is still highly > > > likely to have the route for the location the endpoint is given. > > > Everything except > > > VSP validation works without forest guides." > > > > > > You make it sound as if routing will work without forest guides > given > > > option 1. It does not unless by (insert miracle happens here) the > VSP > > > happens to have the foreign jurisdiction LoST identity or a copy of > the > > > foreign jurisdiction LoST information. > > > > > > I have only referred to "validation" in the context of this thread > as > > > meaning "confirming that a nominal PSAP URI is a genuine PSAP URI". > So > > > that hasn't been a root of any confusion for me. I think option 3 > does > > > provide validation of the PSAP URI because it is based on the > > > understanding that the LIS acquires the URI from the local LoST > server. > > > > > > I guess what I object to is the precipitous settling on option 1 > (with > > > its inherent failure) before anybody has an option to submit > alternative > > > text in any form. > > > > > > In the mean time, and as you acknowledge below, both options 1 and 3 > > > have "commercial" compromises for one or other party and there's no > > > objective way to give one priority over the other on that basis. > > > > > > I would be interested in hearing from others (than Brian) whether > they > > > think scenario A or scenario B below are the best starting point for > > > now. > > > > > > Cheers, > > > Martin > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Sunday, 17 June 2007 6:41 AM > > > To: Dawson, Martin; ecrit@ietf.org > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > Maybe we're getting ourselves confused with the word "validation". > An > > > endpoint would like to know that the location it got was a valid > > > location. > > > It can do that by querying LoST. If it's given a reference and a > PSAP > > > URI, > > > it can't check it unless it does a dereference, gets some kind of > > > location > > > and queries LoST. So option 3 leaves the endpoint not being able to > > > validate. > > > > > > If an endpoint routes, some VSPs want to validate that the route the > > > endpoint handed it is valid. That's another form of validation. > Option > > > 3 > > > doesn't provide any way for the VSP to validate that the PSAP URI in > the > > > Request URI is a bona fide PSAP URI. > > > > > > Yes, option 1 requires the LIS to provide a coarse location value > for > > > anyone > > > that asks. It provides a way for the endpoint to validate that the > > > location > > > results in a route to a PSAP, and it provides a way for a VSP to > > > validate > > > that the URI is a valid PSAP URI. > > > > > > If there is no forest guide, the local LoST server is still highly > > > likely to > > > have the route for the location the endpoint is given. Everything > > > except > > > VSP validation works without forest guides. PSAP validation > requires > > > that > > > the VSP have access to the same LoST data that the endpoint does. > In > > > the > > > general case, that means forest guides. There are lots of cases > where > > > the > > > VSP could reasonably get access to the LoST data where MOST of his > > > subscribers are, but most is not all, and forest guides would be > > > required. > > > > > > With option 3, the LIS is highly likely to have access to LoST data > > > covering > > > it's service area, so no forest guides are needed. The endpoint > can't > > > validate, so whether there are forest guides is moot. Same for VSP > > > validation. > > > > > > There is a document that describes how forest guides work. There > has > > > been > > > discussion on this document, which has had more than one revision. > The > > > only > > > words describing how option 3 might provide validation are email > > > discussions > > > of reverse lookups, and one email from you that said "The ability to > > > verify > > > a destination PSAP URI as a valid emergency URI could be supported > by > > > reference to a relatively static table maintained by global > > > cooperation." > > > That is the extent of the discussion. There is no text. > > > > > > I more or less understand how reverse lookup would work. I think we > > > would > > > have a significant piece of work to add that to the current LoST > > > document. > > > I think everyone agrees that now is not the time to do that work. > If > > > you > > > accept VSP validation as a requirement, which I do (reluctantly, but > > > then I > > > accept location hiding as a requirement just as reluctantly) then we > > > need > > > something that doesn't need a change to LoST with the impact of > reverse > > > lookups. You have suggested something. I think it won't work, but > it's > > > hard to criticize because there is no text. In your latest email, > you > > > have > > > another idea, which I find equally unlikely to work, but again, > there is > > > no > > > text to criticize. > > > > > > I don't really like option 3, but I could live with it if there was > a > > > way > > > for the VSP to validate. I'd really like a way for the endpoint to > > > validate, but that is not quite so important. I don't want to hold > up > > > LoST. > > > > > > So, I'd say, in the absence of a reasonable alternative, with text > that > > > has > > > had some level of review, and has at least a reasonable amount of > > > consensus, > > > that we document option 1 (in phonebcp) and keep working. > > > > > > Brian > > > > -----Original Message----- > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > Sent: Friday, June 15, 2007 10:25 PM > > > > To: Brian Rosen; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > > > If the "normal case" is endpoint route, then there's no need to > > > > validate, right? So option 3 supports this without any need to > provide > > > > location information. Option 1 requires it to provide location > > > > information *for all requests* since it doesn't really know this > is an > > > > emergency scenario. > > > > > > > > So - let's leave end-point route out of the discussion with the > note > > > > that option 3 satisfies the location hiding requirement most > > > > satisfactorily and without impact on VSP validation. > > > > > > > > Now - for VSP route where the issue of URI validation comes up > (which > > > is > > > > also purely a commercial issue AFAIK). > > > > > > > > A. If there's no forest guide in place, option 1 doesn't allow the > > > > emergency call to be routed at all but at least nobody will have > to > > > > worry about whether the non-call should be charged for or not. > > > > > > > > B. If there's no functional way to validate the proffered PSAP URI > > > then > > > > option 3 requires the VSP to decide whether to charge for the call > or > > > > not based on its policy in this regard. However, the emergency > call > > > can > > > > always be made regardless of the availability of a functional > forest > > > > guide network. > > > > > > > > Your proposition is that scenario A is preferable to scenario B. I > > > think > > > > that is profoundly incorrect. I think it's self-evidently so. > > > > > > > > You continually dismiss any attempt on my part to start a > discussion > > > > about ways for a VSP to validate the PSAP URI as "hand waving". > Every > > > > reasonable discussion based on a genuine desire to solve a problem > > > > starts with those sorts of suggestions. Your approach is a > > > > self-fulfilling argument that says there's no solution therefore > there > > > > can't be a solution, because I'm simply not going to talk about > one. > > > How > > > > about a BCP that says that PSAP URIs should follow a specific > > > convention > > > > in terms of domain name structure? The VSP would only provide > > > emergency > > > > call tariffs to destinations that satisfy that BCP. Then somebody > > > > wanting to "scam a free call" would have to make sure that the > called > > > > party URI met that form. Not particularly useful. > > > > > > > > There's no precedent for a US-based operator charging for > emergency > > > > calls made by subscribers roaming in foreign jurisdictions. PSTN > calls > > > > (whether cellular or wireline) are always handled by an operator > in > > > that > > > > jurisdiction. In the case of cellular, it is handled by the > roaming > > > > partner in that jurisdiction. VoIP is the first instance of the > call > > > > processing occurring at the home provider end while the call > occurs in > > > > the foreign jurisdiction. I think it's extremely unlikely that > > > charging > > > > for emergency calls made in foreign jurisdictions would be > illegal. > > > > There's only the barest shreds of legislation covering VoIP in any > > > > respect at all at the moment. > > > > > > > > Cheers, > > > > Martin > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Saturday, 16 June 2007 12:53 AM > > > > To: Dawson, Martin; ecrit@ietf.org > > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > > > Huh? I said the normal case is endpoint route. If the endpoint > > > routes, > > > > option 1 is endpoint gets coarse location, endpoint queries LoST. > No > > > > forest > > > > guide. > > > > > > > > If the VSP routes, either option needs forest guides. > > > > > > > > Option 1 and Option 3 need forest guides for the VSP to validate. > > > > > > > > I don't see why a VSP would have a replica of the LoST database, > but > > > if > > > > it > > > > did, it wouldn't cover the world. So unless it restricts > nomading, it > > > > has > > > > to rely on forest guides to validate (or route). If it did have a > > > > replica, > > > > it could have some non standard way to validate for the parts of > the > > > > database it had. That's not a solution, that's an optimization. > I > > > > don't > > > > think you can handwave with "charge for foreign emergency calls". > > > They > > > > aren't "foreign" to the guy making them. I think it would be > illegal > > > in > > > > the > > > > U.S. for example, although the VSP may not be subject to U.S. law > in > > > all > > > > cases. > > > > > > > > I think a reasonable strategy for a VSP attempting to validate is > to > > > > arrange > > > > forest guides, and to permit emergency calls from areas where it > > > cannot > > > > get > > > > coverage for without validation. > > > > > > > > Brian > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > > Sent: Friday, June 15, 2007 9:19 AM > > > > > To: Brian Rosen; ecrit@ietf.org > > > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > > > > > OK - but there's a very significant qualitative difference that > you > > > > > haven't acknowledged yet. > > > > > > > > > > Option 3 works without dependency on forest guides - it can work > > > > > straight away. Option 1 means that emergency calls will simply > fail > > > to > > > > > route until a global and reliable forest guide infrastructure is > in > > > > > place. As I said, that's completely independent of the question > of > > > > > location hiding. Even if the LIS wasn't hiding location I'd > still > > > > > recommend that the device acquires the PSAP URI from the local > > > > services > > > > > and not just hope that the VSP can do it for it. > > > > > > > > > > If the VSP is really going to run its own copy of the LoST data > for > > > > the > > > > > area of coverage that it cares about, then it can use any > internal > > > > > mechanism it likes to spot the matching PSAP URI in the > database. It > > > > > doesn't have to talk LoST to its own infrastructure. Barbara > pointed > > > > out > > > > > that, as a VSP operator, she isn't going to be so concerned > about > > > > those > > > > > "foreign" emergency calls anyway. I actually agree with the > > > sentiments > > > > > expressed that a VSP should still have a mission to support > > > emergency > > > > > calling regardless of point of origin. In the spirit of > Barbara's > > > > > position, however, perhaps it's still reasonable if they charge > for > > > > > those "foreign" emergency calls. > > > > > > > > > > Main point - I think the ability to provide global emergency > service > > > > as > > > > > soon as possible is a better goal than saying I'll wait until I > can > > > be > > > > > sure that global emergency service can be provided for free > before > > > the > > > > > service can be used at all. > > > > > > > > > > Cheers, > > > > > Martin > > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Friday, 15 June 2007 11:03 PM > > > > > To: Dawson, Martin; ecrit@ietf.org > > > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of perspectives > > > > > > > > > > Yeah, you agree with me. You just want to ignore the VSP > validation > > > > > problem. I'd like to ignore the location hiding problem, but > we're > > > > > stuck > > > > > with both. > > > > > > > > > > If you come up with some way other than allowing the VSP to get > > > coarse > > > > > location and using that to validate the PSAP URI, then we can > use > > > that > > > > > for > > > > > option 1 or 3. So far there is no other mechanism that we can > use. > > > > We > > > > > can > > > > > extend LoST in some way to do it, but several of us are > suggesting > > > > that > > > > > we > > > > > postpone that work and get LoST out now. > > > > > > > > > > I certainly agree that the basic assumption that the access > > > provider, > > > > > LoST > > > > > server and PSAP are local to one another is a good one. It's > what > > > > makes > > > > > option 1 or 3 possible, and gives the greatest likelihood that > the > > > > > system > > > > > will work. I think having the VSP route is fairly easy, but > > > "fairly" > > > > > means > > > > > that we need forest guides so that callers that are remote can > be > > > > > routed. > > > > > I'd strongly prefer endpoints to route. That will be much more > > > likely > > > > > to > > > > > work in all circumstances. It seems very unlikely to me that we > > > would > > > > > have > > > > > a situation where the endpoint could supply location, but could > not > > > do > > > > > dialstring recognition and routing. Having the VSP supply > location > > > > AND > > > > > route is really going to be difficult with VPNs and NATs, etc. > > > > > > > > > > With respect to who runs the servers, I believe you are > conflating > > > two > > > > > parts > > > > > of the problem: who is responsible for the data, and who runs > the > > > > actual > > > > > server. The PSAP is responsible for the data. It will probably > run > > > a > > > > > server which anyone can use. However, I believe most access > network > > > > > providers will want a copy of the data in a server they run. > That > > > is > > > > > the > > > > > purpose of the LoST mechanisms to maintain replicas of the data. > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > > > Sent: Friday, June 15, 2007 3:32 AM > > > > > > To: ecrit@ietf.org > > > > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of > perspectives > > > > > > > > > > > > > > > > > > Speak for yourself :) Your description of option 3 does not > > > > correlate > > > > > > with my description or understanding of it. So, if there's > > > > confusion, > > > > > > perhaps this is the root of it. > > > > > > > > > > > > In option 3 - the access network doesn't determine coarse > location > > > > at > > > > > > all. It doesn't concern itself with coarse location. It uses > the > > > > > precise > > > > > > location that it determines for the device, queries the local > LoST > > > > > > server and provides the resultant PSAP URI directly to the > device. > > > > At > > > > > > this point the routing has been achieved and the device can > route > > > > > > directly or via the VSP. When the PSAP dereferences, it gets > the > > > > > precise > > > > > > location from the LIS. It is exactly because the routing is > > > achieved > > > > > by > > > > > > just the local elements that this option doesn't have the > Achilles > > > > > heel > > > > > > of option 1 which requires the VSP, absolutely, to be able to > find > > > > the > > > > > > authoritative local LoST server. As I say, for a very remote > VSP > > > and > > > > > no > > > > > > functioning forest guide, it may very well not be able to. > > > > > > > > > > > > There's a basic principle here - emergency services are local > to > > > the > > > > > > caller, the access network operator (and LIS) are local to the > > > > caller, > > > > > > and the authoritative LoST server is going to most local to > the > > > > > caller. > > > > > > The ability to reliably route the call is going to be optimal > if > > > > it's > > > > > > done between all these local entities who are best placed to > be > > > > aware > > > > > of > > > > > > each other. Waiting until the call scenario has geographically > > > > > diverged > > > > > > to the VSP before attempting to determine routing is > unnecessarily > > > > > > sub-optimal. > > > > > > > > > > > > In option 1 - how do you propose the access network determine > the > > > > > > "coarse location"? I believe your proposal is that it uses the > > > local > > > > > > LoST server applicable to its area of coverage and utilize the > > > > > semantics > > > > > > of LoST which provide a PSAP boundary in the response. Can you > > > > confirm > > > > > > that this is your proposal? Otherwise, how would you > anticipate > > > that > > > > > the > > > > > > access provider, who doesn't manage the PSAP boundaries after > all, > > > > > would > > > > > > know what is the appropriate coarse location that will result > in a > > > > > > reliable response when LoST is queried? > > > > > > > > > > > > With respect to Henning's comment about LoST services being > > > provided > > > > > by > > > > > > ISPs and/or VSPs, I didn't resonate with that. I would expect > that > > > > > LoST > > > > > > is emergency services specific and it is likely to be part of > some > > > > > > jurisdictional function or some provider of services to that > > > > > > jurisdictional function. I don't see that either ISPs or VSPs > are > > > > > > qualified to manage the PSAP routing information contained in > a > > > LoST > > > > > > server. > > > > > > > > > > > > Cheers, > > > > > > Martin > > > > > > > > > > > > -----Original Message----- > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > Sent: Thursday, 14 June 2007 11:07 PM > > > > > > To: Dawson, Martin; 'ECRIT' > > > > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of > perspectives > > > > > > > > > > > > Wait a minute, we're getting confused. > > > > > > > > > > > > Option 1 requires that the access network dereference to > anyone > > > with > > > > > at > > > > > > least coarse location suitable for emergency call routing. If > the > > > > > > endpoint > > > > > > does routing, it will use a local LoST server which has high > > > > > probability > > > > > > of > > > > > > having the route. If a VSP wants to verify, it needs access > to a > > > > LoST > > > > > > server covering the area where his customers roam. The cost > is on > > > > the > > > > > > carrier that is trying to hide location (which, AFAIK, is an > > > > economic > > > > > > issue > > > > > > all the way, the hiding is so the access network can charge > for > > > non > > > > > > emergency uses of location). > > > > > > > > > > > > Option 3 requires that the access network dereference to > anyone > > > with > > > > > at > > > > > > least coarse location suitable for emergency call routing. > This > > > is > > > > > > because > > > > > > if the endpoint doesn't route (or more specifically, if it > doesn't > > > > > > recognize > > > > > > emergency dialstrings, query LoST, and add the PSAP URI), but > does > > > > > > supply > > > > > > location, then the VSP has to route, and it will have to > > > > dereference. > > > > > > If > > > > > > the endpoint does routing, option 3 is easy, because it will > have > > > > the > > > > > > correct PSAP URIs (it has to be all of them, BTW, a problem in > > > > > itself). > > > > > > If > > > > > > a VSP wants to verify, it needs access to a LoST server > covering > > > the > > > > > > area > > > > > > where his customers roam. It can't use the LCP, it has to > > > > dereference > > > > > > the > > > > > > location, and then query LoST. > > > > > > > > > > > > If we supply a different mechanism for a VSP to validate, that > > > could > > > > > > change, > > > > > > and it would affect 1 and 3 the same way. > > > > > > > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > > > > Sent: Wednesday, June 13, 2007 10:56 PM > > > > > > > To: ECRIT > > > > > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of > perspectives > > > > > > > > > > > > > > Typo alert - obviously it should have said that option *1* > > > > requires > > > > > > the > > > > > > > VSP to work out the local LoST server in addition to the LIS > > > > needing > > > > > > to > > > > > > > know it. > > > > > > > > > > > > > > Cheers, > > > > > > > Martin > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > > > > Sent: Thursday, 14 June 2007 11:14 AM > > > > > > > To: Henning Schulzrinne; Winterbottom, James > > > > > > > Cc: ECRIT > > > > > > > Subject: RE: [Ecrit] Proposals 1 and 3 - summary of > perspectives > > > > > > > > > > > > > > BTW - as I understand option 1, it requires the LIS to query > the > > > > > local > > > > > > > LoST server as well. At least that's how I recall Brian's > > > original > > > > > > > proposal being stated. It returns a "PSAP URI boundary" > location > > > > > > instead > > > > > > > of the PSAP URI. > > > > > > > > > > > > > > I think folk are being inconsistent characterising option 3 > as > > > > > adding > > > > > > > LoST functionality to HELD. Both proposals require the LIS > to > > > > > interact > > > > > > > with LoST with the subsequent proxying of results to the > device. > > > > > > > > > > > > > > If the proposition of option 1 is that it's actually the LIS > > > that > > > > > > holds > > > > > > > the PSAP-relevant boundary information, then option 1 is > > > actually > > > > > much > > > > > > > more like adding LoST functionality to the LIS (and adds > > > > > inappropriate > > > > > > > responsibility to the LIS provider). > > > > > > > > > > > > > > Further, given my understanding, both proposals rely on the > LIS > > > > > > knowing > > > > > > > inherently what the appropriate local LoST server is. Option > 1 > > > > just > > > > > > > means that this is required *as well as* the VSP being able > to > > > > reach > > > > > > > that same local LoST service. > > > > > > > > > > > > > > Neither option requires the ISP to implement LoST, they just > > > > require > > > > > > the > > > > > > > ISP to know which LoST server is applicable to the local > area of > > > > > > > coverage. That's much more practical than expecting any > > > arbitrary > > > > > > global > > > > > > > VSP being able to work that out but that is what option 3 > > > requires > > > > > *in > > > > > > > addition*. > > > > > > > > > > > > > > Cheers, > > > > > > > Martin > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > > > > Sent: Thursday, 14 June 2007 10:22 AM > > > > > > > To: Winterbottom, James > > > > > > > Cc: ECRIT > > > > > > > Subject: Re: [Ecrit] Proposals 1 and 3 - summary of > perspectives > > > > > > > > > > > > > > I assume that your discussion has nothing to do with > location > > > > hiding > > > > > > > at this point, but wanted to call this out just in case I'm > > > > missing > > > > > > > your train of thought. > > > > > > > > > > > > > > I'm afraid I don't follow your logic. Unless you assume that > > > every > > > > > > > ISP deploys a LoST+HELD server, VSPs will have to have LoST > > > > servers > > > > > > > with PSAP knowledge for the places their customers are > likely to > > > > > > > visit. This doesn't change whether HELD also gets converted > into > > > a > > > > > > > LoST access protocol or not. So far, at least, VSPs seem a > whole > > > > lot > > > > > > > more interested in providing emergency call services than > ISPs, > > > > > > > presumably because their customers look to them for that > > > service, > > > > > not > > > > > > > to the random hot spot operator. > > > > > > > > > > > > > > It's always been the model that both ISPs and VSPs (as well > as > > > > third > > > > > > > parties that are neither) can and should operate LoST > servers, > > > as > > > > > > > that seems most likely to ensure that you get broad > coverage. > > > > > > > > > > > > > > Henning > > > > > > > > > > > > > > On Jun 13, 2007, at 8:00 PM, Winterbottom, James wrote: > > > > > > > > > > > > > > > Henning, > > > > > > > > > > > > > > > > I think that your proposal only works if the VSP is able > to > > > > > provide > > > > > > a > > > > > > > > LoST server for all jurisdictions that it plans to provide > > > > service > > > > > > > > for, > > > > > > > > or it has to do it for everything (sounds awfully like a > > > global > > > > > VPC > > > > > > to > > > > > > > > me). Option 3 would be deployable from a local area to a > local > > > > > PSAP > > > > > > > > REGARDLESS of the VSP having a LoST server that has > boundary > > > > > > > > information > > > > > > > > for the local area I am in. It provides a global solution > from > > > > the > > > > > > > > get-go. > > > > > > > > > > > > > > > > Let's take the good old Sierra-Leone example again. > > > > > > > > > > > > > > > > My VSP is in Sierra-Leone and I am visiting Samoa. In > option > > > 3, > > > > I > > > > > > > > get a > > > > > > > > PSA P URI for the local Samoan PSAP from the local access > LIS > > > > > > serving > > > > > > > > the area I am in, I send my call to VSP, it sends it on > the > > > > PSAP. > > > > > I > > > > > > > > get > > > > > > > > billed, call completes, we are done. I can quibble with my > VSP > > > > > later > > > > > > > > over the 10 cent call charge if I can be bothered. > > > > > > > > > > > > > > > > With option 1, I send my call with location to my VSP, and > one > > > > of > > > > > > > > three > > > > > > > > things happens. Either it has a complete forest guide > network > > > > set- > > > > > > > > up to > > > > > > > > be able to talk to the Samoan LoST server nearest me, my > call > > > > > > > > fails, or > > > > > > > > the VSP routes the call anyway because the end-point has > done > > > > the > > > > > > LoST > > > > > > > > lookup. I point out, that from the VSP perspective the > third > > > > > > > > alternative > > > > > > > > here is simply option 3 re-badged. I am sure that VSPs > > > wouldn't > > > > > > > > drop the > > > > > > > > call on the floor, so choice 2 isn't an option, and choice > 1 > > > can > > > > > > ONLY > > > > > > > > occur if the whole network is up and running, and it > doesn't > > > > > > > > consist of > > > > > > > > isolated copse of Forest Guides and LoST Servers. > > > > > > > > > > > > > > > > So to my mind, option 3 is the ONLY deployable solution in > the > > > > > short > > > > > > > > term that will actually work universally. > > > > > > > > > > > > > > > > Cheers > > > > > > > > James > > > > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > > > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > > > > >> Sent: Thursday, 14 June 2007 12:58 AM > > > > > > > >> To: Dawson, Martin > > > > > > > >> Cc: ecrit@ietf.org > > > > > > > >> Subject: Re: [Ecrit] Proposals 1 and 3 - summary of > > > > perspectives > > > > > > > >> > > > > > > > >> > > > > > > > >> On Jun 13, 2007, at 10:54 AM, Dawson, Martin wrote: > > > > > > > >> > > > > > > > >>> Nobody has suggested changing LoST so this point is just > a > > > > > > > >>> distraction. > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> Option 1 means that emergency calls will not be able to > be > > > > > routed > > > > > > > >>> until the forest guide network is implemented. Option 3 > > > means > > > > > that > > > > > > > >>> emergency calls will be able to be routed regardless of > the > > > > > state > > > > > > > >>> of deployment of the forest guide. > > > > > > > >>> > > > > > > > >>> > > > > > > > >> This is not true, at least for comparable installations. > The > > > > ISP > > > > > > can > > > > > > > >> offer a LoST server that has the locally-relevant > > > information. > > > > > Same > > > > > > > >> for the VSP. This does not require a forest guide as > such. > > > > > > > >> > > > > > > > >> _______________________________________________ > > > > > > > >> Ecrit mailing list > > > > > > > >> Ecrit@ietf.org > > > > > > > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > > > > > > -------------------------- > > > > > > > > This message is for the designated recipient only and may > > > > > > > > contain privileged, proprietary, or otherwise private > > > > information. > > > > > > > > If you have received it in error, please notify the sender > > > > > > > > immediately and delete the original. Any unauthorized use > of > > > > > > > > this email is prohibited. > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > > > > > > -------------------------- > > > > > > > > [mf2] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Ecrit mailing list > > > > > > > Ecrit@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > ------------------------ > > > > > > > This message is for the designated recipient only and may > > > > > > > contain privileged, proprietary, or otherwise private > > > information. > > > > > > > If you have received it in error, please notify the sender > > > > > > > immediately and delete the original. Any unauthorized use > of > > > > > > > this email is prohibited. > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > ------------------------ > > > > > > > [mf2] > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Ecrit mailing list > > > > > > > Ecrit@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > -- > > > > > > > ---------------------- > > > > > > > This message is for the designated recipient only and may > > > > > > > contain privileged, proprietary, or otherwise private > > > information. > > > > > > > If you have received it in error, please notify the sender > > > > > > > immediately and delete the original. Any unauthorized use > of > > > > > > > this email is prohibited. > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > -- > > > > > > > ---------------------- > > > > > > > [mf2] > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Ecrit mailing list > > > > > > > Ecrit@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > -- > > > > > > ---------------------- > > > > > > This message is for the designated recipient only and may > > > > > > contain privileged, proprietary, or otherwise private > information. > > > > > > If you have received it in error, please notify the sender > > > > > > immediately and delete the original. Any unauthorized use of > > > > > > this email is prohibited. > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > -- > > > > > > ---------------------- > > > > > > [mf2] > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Ecrit mailing list > > > > > > Ecrit@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > ---------------------- > > > > > This message is for the designated recipient only and may > > > > > contain privileged, proprietary, or otherwise private > information. > > > > > If you have received it in error, please notify the sender > > > > > immediately and delete the original. Any unauthorized use of > > > > > this email is prohibited. > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > -- > > > > > ---------------------- > > > > > [mf2] > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > ---------------------- > > > > This message is for the designated recipient only and may > > > > contain privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > > immediately and delete the original. Any unauthorized use of > > > > this email is prohibited. > > > > > > > > ------------------------------------------------------------------------ > > > -- > > > > ---------------------- > > > > [mf2] > > > > > > > > > > ------------------------------------------------------------------------ > > > ------------------------ > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > ------------------------------------------------------------------------ > > > ------------------------ > > > [mf2] > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > [mf2] > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 18 21:19:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0SNv-0003E8-3o; Mon, 18 Jun 2007 21:19:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0SNt-0003DF-Ht for ecrit@ietf.org; Mon, 18 Jun 2007 21:19:53 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0SNt-0004X6-5I for ecrit@ietf.org; Mon, 18 Jun 2007 21:19:53 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I0SNM-0000zj-Vm; Mon, 18 Jun 2007 20:19:37 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Henning Schulzrinne'" , "'ECRIT'" References: <47369DFE-4B26-4E3C-972E-F3D44A979E65@cs.columbia.edu> <113601c7b1c2$f3f15640$9501a8c0@cis.neustar.com> Subject: RE: [Ecrit] Architecture comparisons Date: Mon, 18 Jun 2007 21:19:33 -0400 Message-ID: <149b01c7b20f$f05c68b0$9501a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcexremaX0mkpkefQGGogs+v3EDV1QAFC/DwAA8aZoAABDgekA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Are you having the same problems Martin did? The assumption is that the endpoint cheats. What it supplies as a PSAP URI is not what it gets from LoST. We hope indeed that the forest guide takes it to the same server the endpoint used (or should have used). VSP will get the real one, not what the endpoint claims. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Monday, June 18, 2007 7:18 PM > To: Brian Rosen; Henning Schulzrinne; ECRIT > Subject: RE: [Ecrit] Architecture comparisons > > Perhaps I am missing something here. > > We have a local LoST server that provides PSAP URI when given location. > We have a forset guide in Sierra Leone that knows how to find this LoST > server. > > We have a UA that asks the LIS for location. > The LIS gets location, performs LoST lookup, and returns the PSAP URI. > > Please tell me how the VSP is going to do any better even if we give it > location, given that the forest guide it uses will take it to the same > LoST server. > > Cheers > James > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, 19 June 2007 2:09 AM > > To: 'Henning Schulzrinne'; 'ECRIT' > > Subject: RE: [Ecrit] Architecture comparisons > > > > I don't understand the line: > > > ....If resolution by the foreign VSP fails, the UA will > > > contact the ISPs LoST server. > > This sentence is in "UA resolution". The UA would FIRST try using the > > LoST > > server suggested by its ISP (which should be local to it), and failing > > that > > would try a LoST server suggested by its VSP. > > > > I am glad you pointed out that Solution 3 doesn't permit the VSP to > route. > > While it would be rare, I think, for the UA to have location, but not > be > > able to route, I think we have to allow for that case. The VSP should > be > > able to route if the UA fails to route. I am uncomfortable with the > > access > > network saying that the UA has to use the route it supplies, or the > system > > fails. > > > > Brian > > > > > -----Original Message----- > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > Sent: Monday, June 18, 2007 9:38 AM > > > To: ECRIT > > > Subject: [Ecrit] Architecture comparisons > > > > > > I think it would help things if we compare apples to apples. We seem > > > to agree that both VSP and ISP will run a LoST resolver (and contact > > > other LoST servers). There are two cases based on the proposals: > > > > > > (1) ISP makes the LoST information available via LoST > > > > > > (2) ISP makes some LoST information (partially) available via some > > > yet-to-be-specified extension to HELD > > > > > > We then have a second dimension: whether LoST resolution is done by > > > the UA or the VSP. > > > > > > *** UA resolution case > > > > > > For the UA resolution case, we presence of the FG makes no > > > difference. If resolution by the foreign VSP fails, the UA will > > > contact the ISPs LoST server. (Which LoST servers to contact first > is > > > something that the Phone BCP would presumably cover.) > > > > > > If there is no FG, for Solution 1, the foreign VSP gets rough > > > location information and can thus at least restrict those callers to > > > domestic calls within that country by matching E.164 prefixes, > rather > > > than offer worldwide free long distance calls. In countries where > the > > > VSP has LoST information (see below), validation is possible. > > > > > > For Solution 3, the VSP has no means of distinguishing the caller's > > > girl friend in Haiti from a PSAP. > > > > > > *** VSP resolution case > > > > > > This isn't an option for Solution 3, since it relies on UA > resolution. > > > > > > For Solution 1, the resolution will work for all countries where the > > > VSP has established a LoST presence. (A VSP with an international > > > customer base, such as Skype, could run its own 'private' FG until > > > such time that there is a public one.) > > > > > > With Solution 4, it will work even for those cases where only the > ISP > > > has LoST information. > > > > > > Henning > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jun 18 21:27:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0SVN-0002f3-Rl; Mon, 18 Jun 2007 21:27:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0SVM-0002cG-PX for ecrit@ietf.org; Mon, 18 Jun 2007 21:27:36 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0SVL-0001HE-Cv for ecrit@ietf.org; Mon, 18 Jun 2007 21:27:36 -0400 X-SEF-Processed: 5_0_0_910__2007_06_18_20_35_18 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 18 Jun 2007 20:35:18 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Jun 2007 20:27:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Architecture comparisons Date: Mon, 18 Jun 2007 20:27:30 -0500 Message-ID: In-Reply-To: <149b01c7b20f$f05c68b0$9501a8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Architecture comparisons Thread-Index: AcexremaX0mkpkefQGGogs+v3EDV1QAFC/DwAA8aZoAABDgekAAALZzw References: <47369DFE-4B26-4E3C-972E-F3D44A979E65@cs.columbia.edu> <113601c7b1c2$f3f15640$9501a8c0@cis.neustar.com> <149b01c7b20f$f05c68b0$9501a8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Henning Schulzrinne" , "ECRIT" X-OriginalArrivalTime: 19 Jun 2007 01:27:32.0387 (UTC) FILETIME=[022A6730:01C7B211] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org No Brian, I am not having the problem that Martin had as I set him=0D=0Astr= aight.=0D=0A=0D=0AIf there is no forest guide, then the VSP cannot check if= the end-point=0D=0Ais cheating, EVEN IF A LOCATION IS PROVIDED. As Barbara= has pointed out=0D=0Aseveral times now, and you choose to ignore, forest g= uides will not be=0D=0Auniversally deployed for quite some time (please rea= d years), so until=0D=0Athey are, solution 1 provides nothing better than s= olution 3 from a VSP=0D=0Astop-the-cheaters perspective, but does place a l= ot of burden on=0D=0Alocation providers.=20=0D=0A=0D=0AGiven this, the VSPs= can only do one of three things, drop the call,=0D=0Abill for it, let it g= o for free. Solution 1 does not solve this unless a=0D=0Asizeable percentag= e of the coverage area has forest guides, and this=0D=0Awill not be the cas= e for some time.=0D=0A=0D=0AItso facto solution 3 is better for location pr= oviders and provides no=0D=0Adisadvantage to VSPs over option 1 for the nea= r to medium term.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A> -----Original Message-----=0D=0A> From: Brian Rosen [mailto:br@brianro= sen.net]=0D=0A> Sent: Tuesday, 19 June 2007 11:20 AM=0D=0A> To: Winterbotto= m, James; 'Henning Schulzrinne'; 'ECRIT'=0D=0A> Subject: RE: [Ecrit] Archit= ecture comparisons=0D=0A>=20=0D=0A> Are you having the same problems Martin= did=3F=0D=0A>=20=0D=0A> The assumption is that the endpoint cheats. What = it supplies as a=0D=0APSAP=0D=0A> URI=0D=0A> is not what it gets from LoST.= We hope indeed that the forest guide=0D=0Atakes=0D=0A> it to the same ser= ver the endpoint used (or should have used).=0D=0A>=20=0D=0A> VSP will get = the real one, not what the endpoint claims.=0D=0A>=20=0D=0A> Brian=0D=0A> =0D= =0A> > -----Original Message-----=0D=0A> > From: Winterbottom, James [mailt= o:James.Winterbottom@andrew.com]=0D=0A> > Sent: Monday, June 18, 2007 7:18 = PM=0D=0A> > To: Brian Rosen; Henning Schulzrinne; ECRIT=0D=0A> > Subject: R= E: [Ecrit] Architecture comparisons=0D=0A> >=0D=0A> > Perhaps I am missing = something here.=0D=0A> >=0D=0A> > We have a local LoST server that provides= PSAP URI when given=0D=0Alocation.=0D=0A> > We have a forset guide in Sier= ra Leone that knows how to find this=0D=0ALoST=0D=0A> > server.=0D=0A> >=0D= =0A> > We have a UA that asks the LIS for location.=0D=0A> > The LIS gets l= ocation, performs LoST lookup, and returns the PSAP=0D=0AURI.=0D=0A> >=0D=0A= > > Please tell me how the VSP is going to do any better even if we give=0D= =0Ait=0D=0A> > location, given that the forest guide it uses will take it t= o the=0D=0Asame=0D=0A> > LoST server.=0D=0A> >=0D=0A> > Cheers=0D=0A> > Jam= es=0D=0A> >=0D=0A> > > -----Original Message-----=0D=0A> > > From: Brian Ro= sen [mailto:br@brianrosen.net]=0D=0A> > > Sent: Tuesday, 19 June 2007 2:09 = AM=0D=0A> > > To: 'Henning Schulzrinne'; 'ECRIT'=0D=0A> > > Subject: RE: [E= crit] Architecture comparisons=0D=0A> > >=0D=0A> > > I don't understand the= line:=0D=0A> > > > ....If resolution by the foreign VSP fails, the UA will=0D= =0A> > > > contact the ISPs LoST server.=0D=0A> > > This sentence is in "UA= resolution". The UA would FIRST try using=0D=0Athe=0D=0A> > > LoST=0D=0A>= > > server suggested by its ISP (which should be local to it), and=0D=0Afa= iling=0D=0A> > > that=0D=0A> > > would try a LoST server suggested by its V= SP.=0D=0A> > >=0D=0A> > > I am glad you pointed out that Solution 3 doesn't= permit the VSP=0D=0Ato=0D=0A> > route.=0D=0A> > > While it would be rare, = I think, for the UA to have location, but=0D=0Anot=0D=0A> > be=0D=0A> > > a= ble to route, I think we have to allow for that case. The VSP=0D=0Ashould=0D= =0A> > be=0D=0A> > > able to route if the UA fails to route. I am uncomfor= table with=0D=0Athe=0D=0A> > > access=0D=0A> > > network saying that the UA= has to use the route it supplies, or=0D=0Athe=0D=0A> > system=0D=0A> > > f= ails.=0D=0A> > >=0D=0A> > > Brian=0D=0A> > >=0D=0A> > > > -----Original Mes= sage-----=0D=0A> > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.ed= u]=0D=0A> > > > Sent: Monday, June 18, 2007 9:38 AM=0D=0A> > > > To: ECRIT=0D= =0A> > > > Subject: [Ecrit] Architecture comparisons=0D=0A> > > >=0D=0A> > = > > I think it would help things if we compare apples to apples. We=0D=0Ase= em=0D=0A> > > > to agree that both VSP and ISP will run a LoST resolver (an= d=0D=0Acontact=0D=0A> > > > other LoST servers). There are two cases based = on the proposals:=0D=0A> > > >=0D=0A> > > > (1) ISP makes the LoST informat= ion available via LoST=0D=0A> > > >=0D=0A> > > > (2) ISP makes some LoST in= formation (partially) available via=0D=0Asome=0D=0A> > > > yet-to-be-specif= ied extension to HELD=0D=0A> > > >=0D=0A> > > > We then have a second dimen= sion: whether LoST resolution is done=0D=0Aby=0D=0A> > > > the UA or the VS= P.=0D=0A> > > >=0D=0A> > > > *** UA resolution case=0D=0A> > > >=0D=0A> > >= > For the UA resolution case, we presence of the FG makes no=0D=0A> > > > = difference. If resolution by the foreign VSP fails, the UA will=0D=0A> > > = > contact the ISPs LoST server. (Which LoST servers to contact=0D=0Afirst=0D= =0A> > is=0D=0A> > > > something that the Phone BCP would presumably cover.= )=0D=0A> > > >=0D=0A> > > > If there is no FG, for Solution 1, the foreign = VSP gets rough=0D=0A> > > > location information and can thus at least rest= rict those=0D=0Acallers to=0D=0A> > > > domestic calls within that country = by matching E.164 prefixes,=0D=0A> > rather=0D=0A> > > > than offer worldwi= de free long distance calls. In countries=0D=0Awhere=0D=0A> > the=0D=0A> > = > > VSP has LoST information (see below), validation is possible.=0D=0A> > = > >=0D=0A> > > > For Solution 3, the VSP has no means of distinguishing the=0D= =0Acaller's=0D=0A> > > > girl friend in Haiti from a PSAP.=0D=0A> > > >=0D=0A= > > > > *** VSP resolution case=0D=0A> > > >=0D=0A> > > > This isn't an opt= ion for Solution 3, since it relies on UA=0D=0A> > resolution.=0D=0A> > > >=0D= =0A> > > > For Solution 1, the resolution will work for all countries where=0D= =0Athe=0D=0A> > > > VSP has established a LoST presence. (A VSP with an=0D=0A= international=0D=0A> > > > customer base, such as Skype, could run its own = 'private' FG=0D=0Auntil=0D=0A> > > > such time that there is a public one.)=0D= =0A> > > >=0D=0A> > > > With Solution 4, it will work even for those cases = where only=0D=0Athe=0D=0A> > ISP=0D=0A> > > > has LoST information.=0D=0A> = > > >=0D=0A> > > > Henning=0D=0A> > > >=0D=0A> > > > ______________________= _________________________=0D=0A> > > > Ecrit mailing list=0D=0A> > > > Ecri= t@ietf.org=0D=0A> > > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A>= > >=0D=0A> > >=0D=0A> > > _______________________________________________=0D= =0A> > > Ecrit mailing list=0D=0A> > > Ecrit@ietf.org=0D=0A> > > https://ww= w1.ietf.org/mailman/listinfo/ecrit=0D=0A> >=0D=0A> >=0D=0A-----------------= -------------------------------------------------------=0D=0A> --=0D=0A> > = ----------------------=0D=0A> > This message is for the designated recipien= t only and may=0D=0A> > contain privileged, proprietary, or otherwise priva= te information.=0D=0A> > If you have received it in error, please notify th= e sender=0D=0A> > immediately and delete the original. Any unauthorized us= e of=0D=0A> > this email is prohibited.=0D=0A> >=0D=0A---------------------= ---------------------------------------------------=0D=0A> --=0D=0A> > ----= ------------------=0D=0A> > [mf2]=0D=0A>=20=0D=0A=0D=0A--------------------= ---------------------------------------------------------------------------= -=0D=0AThis message is for the designated recipient only and may=0D=0Aconta= in privileged, proprietary, or otherwise private information. =20=0D=0AIf y= ou have received it in error, please notify the sender=0D=0Aimmediately and= delete the original. Any unauthorized use of=0D=0Athis email is prohibite= d.=0D=0A-------------------------------------------------------------------= -----------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 08:35:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0cvj-0001Aw-6F; Tue, 19 Jun 2007 08:35:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0cvi-0001Aq-4y for ecrit@ietf.org; Tue, 19 Jun 2007 08:35:30 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0cvg-0003uC-Lx for ecrit@ietf.org; Tue, 19 Jun 2007 08:35:30 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 19 Jun 2007 08:35:28 -0400 X-IronPort-AV: i="4.16,438,1175486400"; d="scan'208"; a="124009063:sNHT76042610" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5JCZSmb019646; Tue, 19 Jun 2007 08:35:28 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5JCZHBe021474; Tue, 19 Jun 2007 12:35:17 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 08:35:17 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 08:35:17 -0400 From: "Marc Linsner" To: "'Winterbottom, James'" , "'Brian Rosen'" , "'Henning Schulzrinne'" , "'ECRIT'" Subject: RE: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 08:35:15 -0400 Message-ID: <004101c7b26e$49e1a5e0$220d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcexremaX0mkpkefQGGogs+v3EDV1QAFC/DwAA8aZoAABDgekAAALZzwABc5+9A= X-OriginalArrivalTime: 19 Jun 2007 12:35:17.0150 (UTC) FILETIME=[4AA013E0:01C7B26E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8463; t=1182256528; x=1183120528; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20Architecture=20comparisons |Sender:=20 |To:=20=22'Winterbottom, =20James'=22=20, =0 A=20=20=20=20=20=20=20=20=22'Brian=20Rosen'=22=20, =0A=2 0=20=20=20=20=20=20=20=22'Henning=20Schulzrinne'=22=20,=0A=20=20=20=20=20=20=20=20=22'ECRIT'=22=20; bh=7nE4+g2a0Yb59skmmff1mN8n9p4Q7ExWVwzijXXDs3M=; b=N+TLskxPXjKgYlHjt/QKobRC6Vtyh8V1udbUQIye9c1s8pc/iCPLzFKl1eDcnQE2ona6S202 4BRP2we9AMm5siYp8HqufhPMuXE52kCpGDqo1JzH4PLUGpmUt+OJ1PBu; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org All, In my attempt to follow this thread, I've concluded that there is a belief the access provider will have information wrt LoST authoritative servers that VSPs won't have. Is my assumption correct? Is it not true that the architecture we've adopted depends on the forest guide to 'find' the authoritative LoST server? So, this raises the question, short of a working forest guide, how does the access provider find the authoritative LoST server and why can't the VSP use the same such mechanism? Just curious, -Marc- > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Monday, June 18, 2007 9:28 PM > To: Brian Rosen; Henning Schulzrinne; ECRIT > Subject: RE: [Ecrit] Architecture comparisons > > No Brian, I am not having the problem that Martin had as I > set him straight. > > If there is no forest guide, then the VSP cannot check if the > end-point is cheating, EVEN IF A LOCATION IS PROVIDED. As > Barbara has pointed out several times now, and you choose to > ignore, forest guides will not be universally deployed for > quite some time (please read years), so until they are, > solution 1 provides nothing better than solution 3 from a VSP > stop-the-cheaters perspective, but does place a lot of burden > on location providers. > > Given this, the VSPs can only do one of three things, drop > the call, bill for it, let it go for free. Solution 1 does > not solve this unless a sizeable percentage of the coverage > area has forest guides, and this will not be the case for some time. > > Itso facto solution 3 is better for location providers and > provides no disadvantage to VSPs over option 1 for the near > to medium term. > > Cheers > James > > > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, 19 June 2007 11:20 AM > > To: Winterbottom, James; 'Henning Schulzrinne'; 'ECRIT' > > Subject: RE: [Ecrit] Architecture comparisons > > > > Are you having the same problems Martin did? > > > > The assumption is that the endpoint cheats. What it supplies as a > PSAP > > URI > > is not what it gets from LoST. We hope indeed that the forest guide > takes > > it to the same server the endpoint used (or should have used). > > > > VSP will get the real one, not what the endpoint claims. > > > > Brian > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Monday, June 18, 2007 7:18 PM > > > To: Brian Rosen; Henning Schulzrinne; ECRIT > > > Subject: RE: [Ecrit] Architecture comparisons > > > > > > Perhaps I am missing something here. > > > > > > We have a local LoST server that provides PSAP URI when given > location. > > > We have a forset guide in Sierra Leone that knows how to find this > LoST > > > server. > > > > > > We have a UA that asks the LIS for location. > > > The LIS gets location, performs LoST lookup, and returns the PSAP > URI. > > > > > > Please tell me how the VSP is going to do any better even > if we give > it > > > location, given that the forest guide it uses will take it to the > same > > > LoST server. > > > > > > Cheers > > > James > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Tuesday, 19 June 2007 2:09 AM > > > > To: 'Henning Schulzrinne'; 'ECRIT' > > > > Subject: RE: [Ecrit] Architecture comparisons > > > > > > > > I don't understand the line: > > > > > ....If resolution by the foreign VSP fails, the UA > will contact > > > > > the ISPs LoST server. > > > > This sentence is in "UA resolution". The UA would > FIRST try using > the > > > > LoST > > > > server suggested by its ISP (which should be local to it), and > failing > > > > that > > > > would try a LoST server suggested by its VSP. > > > > > > > > I am glad you pointed out that Solution 3 doesn't permit the VSP > to > > > route. > > > > While it would be rare, I think, for the UA to have > location, but > not > > > be > > > > able to route, I think we have to allow for that case. The VSP > should > > > be > > > > able to route if the UA fails to route. I am uncomfortable with > the > > > > access > > > > network saying that the UA has to use the route it supplies, or > the > > > system > > > > fails. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > > Sent: Monday, June 18, 2007 9:38 AM > > > > > To: ECRIT > > > > > Subject: [Ecrit] Architecture comparisons > > > > > > > > > > I think it would help things if we compare apples to > apples. We > seem > > > > > to agree that both VSP and ISP will run a LoST resolver (and > contact > > > > > other LoST servers). There are two cases based on the > proposals: > > > > > > > > > > (1) ISP makes the LoST information available via LoST > > > > > > > > > > (2) ISP makes some LoST information (partially) available via > some > > > > > yet-to-be-specified extension to HELD > > > > > > > > > > We then have a second dimension: whether LoST > resolution is done > by > > > > > the UA or the VSP. > > > > > > > > > > *** UA resolution case > > > > > > > > > > For the UA resolution case, we presence of the FG makes no > > > > > difference. If resolution by the foreign VSP fails, > the UA will > > > > > contact the ISPs LoST server. (Which LoST servers to contact > first > > > is > > > > > something that the Phone BCP would presumably cover.) > > > > > > > > > > If there is no FG, for Solution 1, the foreign VSP gets rough > > > > > location information and can thus at least restrict those > callers to > > > > > domestic calls within that country by matching E.164 prefixes, > > > rather > > > > > than offer worldwide free long distance calls. In countries > where > > > the > > > > > VSP has LoST information (see below), validation is possible. > > > > > > > > > > For Solution 3, the VSP has no means of distinguishing the > caller's > > > > > girl friend in Haiti from a PSAP. > > > > > > > > > > *** VSP resolution case > > > > > > > > > > This isn't an option for Solution 3, since it relies on UA > > > resolution. > > > > > > > > > > For Solution 1, the resolution will work for all > countries where > the > > > > > VSP has established a LoST presence. (A VSP with an > international > > > > > customer base, such as Skype, could run its own 'private' FG > until > > > > > such time that there is a public one.) > > > > > > > > > > With Solution 4, it will work even for those cases where only > the > > > ISP > > > > > has LoST information. > > > > > > > > > > Henning > > > > > > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > -------------------------------------------------------------- > ---------- > > -- > > > ---------------------- > > > This message is for the designated recipient only and may contain > > > privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized > use of this > > > email is prohibited. > > > > -------------------------------------------------------------- > ---------- > > -- > > > ---------------------- > > > [mf2] > > > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 08:36:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0cx6-0002SX-5w; Tue, 19 Jun 2007 08:36:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0cx5-0002SR-Qf for ecrit@ietf.org; Tue, 19 Jun 2007 08:36:55 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0cx5-00047c-9O for ecrit@ietf.org; Tue, 19 Jun 2007 08:36:55 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I0cwc-0005oc-Js; Tue, 19 Jun 2007 07:36:51 -0500 From: "Brian Rosen" To: "'Winterbottom, James'" , "'Henning Schulzrinne'" , "'ECRIT'" References: <47369DFE-4B26-4E3C-972E-F3D44A979E65@cs.columbia.edu> <113601c7b1c2$f3f15640$9501a8c0@cis.neustar.com> <149b01c7b20f$f05c68b0$9501a8c0@cis.neustar.com> Subject: RE: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 08:36:26 -0400 Message-ID: <154d01c7b26e$84a1a040$9501a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcexremaX0mkpkefQGGogs+v3EDV1QAFC/DwAA8aZoAABDgekAAALZzwABdTJPA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I don't agree that forest guides will be years in the making, unless you mean a single, guaranteed to work always forest guide. It's a percentage game. I think VSPs will start out with 80-90% coverage, and expand from there. Barabara's statement on forest guides was: I think reverse LoST would be a nice feature, but I don't see it as necessary. Initially, the utopian view of a worldwide LoST network won't exist, anyway. It will be possible for a VSP to get a call to a completely valid foreign PSAP URI, but not be able to validate that URI either through reverse LoST or through regular LoST look-up of a coarse location. If the Forest Guide pointers (or whatever they are) don't exist for a VSP to get to the correct foreign LoST server, then the VSP will be unable to validate the URI. I'm pretty sure I've read somewhere on this list that Forests will most likely initially grow in disconnected clumps -- but please correct me if I'm wrong here. I agree with her. VSPs won't have access to worldwide LoST coverage any time soon, and forest guides will start out in disconnected clumps. That is still a percentage game. If 90% of their emergency calls happen from places they CAN validate, then their fraud problem is considerably smaller than if they had no way to validate. Brian > -----Original Message----- > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > Sent: Monday, June 18, 2007 9:28 PM > To: Brian Rosen; Henning Schulzrinne; ECRIT > Subject: RE: [Ecrit] Architecture comparisons > > No Brian, I am not having the problem that Martin had as I set him > straight. > > If there is no forest guide, then the VSP cannot check if the end-point > is cheating, EVEN IF A LOCATION IS PROVIDED. As Barbara has pointed out > several times now, and you choose to ignore, forest guides will not be > universally deployed for quite some time (please read years), so until > they are, solution 1 provides nothing better than solution 3 from a VSP > stop-the-cheaters perspective, but does place a lot of burden on > location providers. > > Given this, the VSPs can only do one of three things, drop the call, > bill for it, let it go for free. Solution 1 does not solve this unless a > sizeable percentage of the coverage area has forest guides, and this > will not be the case for some time. > > Itso facto solution 3 is better for location providers and provides no > disadvantage to VSPs over option 1 for the near to medium term. > > Cheers > James > > > > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Tuesday, 19 June 2007 11:20 AM > > To: Winterbottom, James; 'Henning Schulzrinne'; 'ECRIT' > > Subject: RE: [Ecrit] Architecture comparisons > > > > Are you having the same problems Martin did? > > > > The assumption is that the endpoint cheats. What it supplies as a > PSAP > > URI > > is not what it gets from LoST. We hope indeed that the forest guide > takes > > it to the same server the endpoint used (or should have used). > > > > VSP will get the real one, not what the endpoint claims. > > > > Brian > > > > > -----Original Message----- > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > Sent: Monday, June 18, 2007 7:18 PM > > > To: Brian Rosen; Henning Schulzrinne; ECRIT > > > Subject: RE: [Ecrit] Architecture comparisons > > > > > > Perhaps I am missing something here. > > > > > > We have a local LoST server that provides PSAP URI when given > location. > > > We have a forset guide in Sierra Leone that knows how to find this > LoST > > > server. > > > > > > We have a UA that asks the LIS for location. > > > The LIS gets location, performs LoST lookup, and returns the PSAP > URI. > > > > > > Please tell me how the VSP is going to do any better even if we give > it > > > location, given that the forest guide it uses will take it to the > same > > > LoST server. > > > > > > Cheers > > > James > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Tuesday, 19 June 2007 2:09 AM > > > > To: 'Henning Schulzrinne'; 'ECRIT' > > > > Subject: RE: [Ecrit] Architecture comparisons > > > > > > > > I don't understand the line: > > > > > ....If resolution by the foreign VSP fails, the UA will > > > > > contact the ISPs LoST server. > > > > This sentence is in "UA resolution". The UA would FIRST try using > the > > > > LoST > > > > server suggested by its ISP (which should be local to it), and > failing > > > > that > > > > would try a LoST server suggested by its VSP. > > > > > > > > I am glad you pointed out that Solution 3 doesn't permit the VSP > to > > > route. > > > > While it would be rare, I think, for the UA to have location, but > not > > > be > > > > able to route, I think we have to allow for that case. The VSP > should > > > be > > > > able to route if the UA fails to route. I am uncomfortable with > the > > > > access > > > > network saying that the UA has to use the route it supplies, or > the > > > system > > > > fails. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > > Sent: Monday, June 18, 2007 9:38 AM > > > > > To: ECRIT > > > > > Subject: [Ecrit] Architecture comparisons > > > > > > > > > > I think it would help things if we compare apples to apples. We > seem > > > > > to agree that both VSP and ISP will run a LoST resolver (and > contact > > > > > other LoST servers). There are two cases based on the proposals: > > > > > > > > > > (1) ISP makes the LoST information available via LoST > > > > > > > > > > (2) ISP makes some LoST information (partially) available via > some > > > > > yet-to-be-specified extension to HELD > > > > > > > > > > We then have a second dimension: whether LoST resolution is done > by > > > > > the UA or the VSP. > > > > > > > > > > *** UA resolution case > > > > > > > > > > For the UA resolution case, we presence of the FG makes no > > > > > difference. If resolution by the foreign VSP fails, the UA will > > > > > contact the ISPs LoST server. (Which LoST servers to contact > first > > > is > > > > > something that the Phone BCP would presumably cover.) > > > > > > > > > > If there is no FG, for Solution 1, the foreign VSP gets rough > > > > > location information and can thus at least restrict those > callers to > > > > > domestic calls within that country by matching E.164 prefixes, > > > rather > > > > > than offer worldwide free long distance calls. In countries > where > > > the > > > > > VSP has LoST information (see below), validation is possible. > > > > > > > > > > For Solution 3, the VSP has no means of distinguishing the > caller's > > > > > girl friend in Haiti from a PSAP. > > > > > > > > > > *** VSP resolution case > > > > > > > > > > This isn't an option for Solution 3, since it relies on UA > > > resolution. > > > > > > > > > > For Solution 1, the resolution will work for all countries where > the > > > > > VSP has established a LoST presence. (A VSP with an > international > > > > > customer base, such as Skype, could run its own 'private' FG > until > > > > > such time that there is a public one.) > > > > > > > > > > With Solution 4, it will work even for those cases where only > the > > > ISP > > > > > has LoST information. > > > > > > > > > > Henning > > > > > > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > [mf2] > > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 08:44:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0d4a-0007Kx-SD; Tue, 19 Jun 2007 08:44:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0d4Z-0007Ki-NJ for ecrit@ietf.org; Tue, 19 Jun 2007 08:44:39 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0d4Z-0005ke-5G for ecrit@ietf.org; Tue, 19 Jun 2007 08:44:39 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I0d4B-0007Yl-TY; Tue, 19 Jun 2007 07:44:35 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , "'Winterbottom, James'" , "'Henning Schulzrinne'" , "'ECRIT'" References: <004101c7b26e$49e1a5e0$220d0d0a@amer.cisco.com> Subject: RE: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 08:44:15 -0400 Message-ID: <155601c7b26f$9922b0d0$9501a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <004101c7b26e$49e1a5e0$220d0d0a@amer.cisco.com> Thread-Index: AcexremaX0mkpkefQGGogs+v3EDV1QAFC/DwAA8aZoAABDgekAAALZzwABc5+9AAAGoNAA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The data comes locally (from the local emergency services authorities). It is reasonable to assume that the access network is more likely to have access to the data than some far away VSP. If the VSP is also local, then they will have equal access, but I think you have to assume the access network is more likely to have the data. I think as a practical matter that most access networks will arrange to have a replica of the LoST database that they keep in their network, that the local emergency authorities supply with data. LoST includes mechanisms to make this possible, although I suspect that other ways will be more common (traditional database replication routines). VSPs may also make such arrangements, but they have more of them to worry about unless they prohibit nomading. The forest guides should work; I think they will work quite well actually; it's in everyone's best interest to see that they do, and even if there are a few clumps, it should be easy for a VSP to arrange access to each of the clumps. Brian > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Tuesday, June 19, 2007 8:35 AM > To: 'Winterbottom, James'; 'Brian Rosen'; 'Henning Schulzrinne'; 'ECRIT' > Subject: RE: [Ecrit] Architecture comparisons > > All, > > In my attempt to follow this thread, I've concluded that there is a belief > the access provider will have information wrt LoST authoritative servers > that VSPs won't have. > > Is my assumption correct? > > Is it not true that the architecture we've adopted depends on the forest > guide to 'find' the authoritative LoST server? So, this raises the > question, short of a working forest guide, how does the access provider > find > the authoritative LoST server and why can't the VSP use the same such > mechanism? > > Just curious, > > -Marc- > > > -----Original Message----- > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > Sent: Monday, June 18, 2007 9:28 PM > > To: Brian Rosen; Henning Schulzrinne; ECRIT > > Subject: RE: [Ecrit] Architecture comparisons > > > > No Brian, I am not having the problem that Martin had as I > > set him straight. > > > > If there is no forest guide, then the VSP cannot check if the > > end-point is cheating, EVEN IF A LOCATION IS PROVIDED. As > > Barbara has pointed out several times now, and you choose to > > ignore, forest guides will not be universally deployed for > > quite some time (please read years), so until they are, > > solution 1 provides nothing better than solution 3 from a VSP > > stop-the-cheaters perspective, but does place a lot of burden > > on location providers. > > > > Given this, the VSPs can only do one of three things, drop > > the call, bill for it, let it go for free. Solution 1 does > > not solve this unless a sizeable percentage of the coverage > > area has forest guides, and this will not be the case for some time. > > > > Itso facto solution 3 is better for location providers and > > provides no disadvantage to VSPs over option 1 for the near > > to medium term. > > > > Cheers > > James > > > > > > > > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Tuesday, 19 June 2007 11:20 AM > > > To: Winterbottom, James; 'Henning Schulzrinne'; 'ECRIT' > > > Subject: RE: [Ecrit] Architecture comparisons > > > > > > Are you having the same problems Martin did? > > > > > > The assumption is that the endpoint cheats. What it supplies as a > > PSAP > > > URI > > > is not what it gets from LoST. We hope indeed that the forest guide > > takes > > > it to the same server the endpoint used (or should have used). > > > > > > VSP will get the real one, not what the endpoint claims. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] > > > > Sent: Monday, June 18, 2007 7:18 PM > > > > To: Brian Rosen; Henning Schulzrinne; ECRIT > > > > Subject: RE: [Ecrit] Architecture comparisons > > > > > > > > Perhaps I am missing something here. > > > > > > > > We have a local LoST server that provides PSAP URI when given > > location. > > > > We have a forset guide in Sierra Leone that knows how to find this > > LoST > > > > server. > > > > > > > > We have a UA that asks the LIS for location. > > > > The LIS gets location, performs LoST lookup, and returns the PSAP > > URI. > > > > > > > > Please tell me how the VSP is going to do any better even > > if we give > > it > > > > location, given that the forest guide it uses will take it to the > > same > > > > LoST server. > > > > > > > > Cheers > > > > James > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Tuesday, 19 June 2007 2:09 AM > > > > > To: 'Henning Schulzrinne'; 'ECRIT' > > > > > Subject: RE: [Ecrit] Architecture comparisons > > > > > > > > > > I don't understand the line: > > > > > > ....If resolution by the foreign VSP fails, the UA > > will contact > > > > > > the ISPs LoST server. > > > > > This sentence is in "UA resolution". The UA would > > FIRST try using > > the > > > > > LoST > > > > > server suggested by its ISP (which should be local to it), and > > failing > > > > > that > > > > > would try a LoST server suggested by its VSP. > > > > > > > > > > I am glad you pointed out that Solution 3 doesn't permit the VSP > > to > > > > route. > > > > > While it would be rare, I think, for the UA to have > > location, but > > not > > > > be > > > > > able to route, I think we have to allow for that case. The VSP > > should > > > > be > > > > > able to route if the UA fails to route. I am uncomfortable with > > the > > > > > access > > > > > network saying that the UA has to use the route it supplies, or > > the > > > > system > > > > > fails. > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > > > > Sent: Monday, June 18, 2007 9:38 AM > > > > > > To: ECRIT > > > > > > Subject: [Ecrit] Architecture comparisons > > > > > > > > > > > > I think it would help things if we compare apples to > > apples. We > > seem > > > > > > to agree that both VSP and ISP will run a LoST resolver (and > > contact > > > > > > other LoST servers). There are two cases based on the > > proposals: > > > > > > > > > > > > (1) ISP makes the LoST information available via LoST > > > > > > > > > > > > (2) ISP makes some LoST information (partially) available via > > some > > > > > > yet-to-be-specified extension to HELD > > > > > > > > > > > > We then have a second dimension: whether LoST > > resolution is done > > by > > > > > > the UA or the VSP. > > > > > > > > > > > > *** UA resolution case > > > > > > > > > > > > For the UA resolution case, we presence of the FG makes no > > > > > > difference. If resolution by the foreign VSP fails, > > the UA will > > > > > > contact the ISPs LoST server. (Which LoST servers to contact > > first > > > > is > > > > > > something that the Phone BCP would presumably cover.) > > > > > > > > > > > > If there is no FG, for Solution 1, the foreign VSP gets rough > > > > > > location information and can thus at least restrict those > > callers to > > > > > > domestic calls within that country by matching E.164 prefixes, > > > > rather > > > > > > than offer worldwide free long distance calls. In countries > > where > > > > the > > > > > > VSP has LoST information (see below), validation is possible. > > > > > > > > > > > > For Solution 3, the VSP has no means of distinguishing the > > caller's > > > > > > girl friend in Haiti from a PSAP. > > > > > > > > > > > > *** VSP resolution case > > > > > > > > > > > > This isn't an option for Solution 3, since it relies on UA > > > > resolution. > > > > > > > > > > > > For Solution 1, the resolution will work for all > > countries where > > the > > > > > > VSP has established a LoST presence. (A VSP with an > > international > > > > > > customer base, such as Skype, could run its own 'private' FG > > until > > > > > > such time that there is a public one.) > > > > > > > > > > > > With Solution 4, it will work even for those cases where only > > the > > > > ISP > > > > > > has LoST information. > > > > > > > > > > > > Henning > > > > > > > > > > > > _______________________________________________ > > > > > > Ecrit mailing list > > > > > > Ecrit@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > > _______________________________________________ > > > > > Ecrit mailing list > > > > > Ecrit@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > -------------------------------------------------------------- > > ---------- > > > -- > > > > ---------------------- > > > > This message is for the designated recipient only and may contain > > > > privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > > immediately and delete the original. Any unauthorized > > use of this > > > > email is prohibited. > > > > > > -------------------------------------------------------------- > > ---------- > > > -- > > > > ---------------------- > > > > [mf2] > > > > > > > -------------------------------------------------------------- > > ---------------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -------------------------------------------------------------- > > ---------------------------------- > > [mf2] > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 10:25:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0eeC-0007SE-R5; Tue, 19 Jun 2007 10:25:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ee8-0007Qt-T6 for ecrit@ietf.org; Tue, 19 Jun 2007 10:25:29 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I0ee7-0001Yw-JH for ecrit@ietf.org; Tue, 19 Jun 2007 10:25:28 -0400 Received: from [10.2.3.8] (vbn.0050420.lodgenet.net [209.19.49.10]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5JEPKBV001486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 19 Jun 2007 10:25:25 -0400 (EDT) In-Reply-To: <004101c7b26e$49e1a5e0$220d0d0a@amer.cisco.com> References: <004101c7b26e$49e1a5e0$220d0d0a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 10:25:16 -0400 To: "Marc Linsner" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'll ad to the crystal ball gazing sessIon: I think the evolution will depend on who will be running LoST servers and how data is distributed. One model is that the PSAP or other government authorities will make data available, but LoST servers will be run by private enterprises. Another is that these authorities will run it themselves. The depth of the trees will presumably depend on the level of federalism in the respective country, with some countries, like France, presumably going national immediately, while others, such as the United States and Germany, maybe starting bottom up, with some progressive states going first. Regardless, as long as these trees make coverage information available or such information can be derived, it's not too hard for either a larger VSP or some third-party service company to aggregate this information and offer a "private" FG. After all, the boundaries of states and countries don't change all that often. In some countries, the incumbent ISP will presumably try to make life difficult for third-party VoIP customers until forced to by regulators, so I wouldn't count on having "open" access to PSAP URIs courtesy of the ISP, either, but we'll see. To echo what Brian said, the likelihood that we'll have Zimbabwe, Taiwan and North Korea all happily in one FG run by the UN is probably a ways off, just after the black helicopters have landed. However, for most people, almost all the time, things will work, as long as we have some good will. (For example, avoid decade-long legal fights about data ownership.) Henning On Jun 19, 2007, at 8:35 AM, Marc Linsner wrote: > All, > > In my attempt to follow this thread, I've concluded that there is a > belief > the access provider will have information wrt LoST authoritative > servers > that VSPs won't have. > > Is my assumption correct? > > Is it not true that the architecture we've adopted depends on the > forest > guide to 'find' the authoritative LoST server? So, this raises the > question, short of a working forest guide, how does the access > provider find > the authoritative LoST server and why can't the VSP use the same such > mechanism? > > Just curious, _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 11:12:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fND-0000H9-WA; Tue, 19 Jun 2007 11:12:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fNC-0000Fq-AN for ecrit@ietf.org; Tue, 19 Jun 2007 11:12:02 -0400 Received: from fl-65-40-30-218.sta.embarqhsd.net ([65.40.30.218] helo=mail.linsner.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fLk-0004K1-NK for ecrit@ietf.org; Tue, 19 Jun 2007 11:10:33 -0400 Received: from 10.13.13.34 by mail.linsner.us (SMTPD); id s20070619111047.6237; Tue, 19 Jun 2007 11:10:47 From: "Marc Linsner" To: "'ECRIT'" Subject: FW: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 11:10:30 -0400 Message-ID: <001001c7b283$f9fd1080$220d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceydUwKzy1FSY0XTXSPQ7fXT6X09AABl0+QAAIRhqA= X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Richard, More questions/comments in-line.... > > You're correct that a general LoST lookup (with no assumptions about > the locality of the seeker) does rely on the network of FGs and tree > nodes to guide the query to the LoST server that's authoritative for > the seeker's location. > > The assumption that's being made here is that since the access network > is a geographically local entity, it can just remember which LoST > servers are authoritative for its coverage area, so that its queries > don't have to start at the top of the mapping heirarchy. It can just > take queries from seekers connected to its network (since this > connectivity implies that they're in the coverage area) and send them > directly to the local LoST server. Without a FG, how is the authoritative LoST server found initially? I would think we (ecrit) would want to discourage 'remembering' the authoritative server for the same reasons one should not 'remember' DNS mappings. > > A VSP-operated resolver, on the other hand, would potentially have to > handle queries from subscribers all over the world. > In other words, it would have to handle general LoST lookups, with no > assumptions about the locality of the seeker. Thus, in general, VSPs > will have to rely on the mapping infrastructure to find the > appropriate LoST server to answer a given query from one of its > subscribers. This can be optimized by caching (e.g., if most > subscribers are in one area), but in general, a VSP needs to do the > full LoST song and dance. > > IOW: Geographic locality of an entity allows caching of authoritative > LoST servers. Access networks (and their > subscribers) are necessarily localized to a coverage area; VSPs > aren't, in general. I'm still missing the tie between the access provider and the authoritative LoST server. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 11:19:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fU9-00046Z-3c; Tue, 19 Jun 2007 11:19:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fU7-00042J-BT for ecrit@ietf.org; Tue, 19 Jun 2007 11:19:11 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fU6-00073T-VL for ecrit@ietf.org; Tue, 19 Jun 2007 11:19:11 -0400 X-SEF-Processed: 5_0_0_910__2007_06_19_10_26_53 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 19 Jun 2007 10:26:53 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jun 2007 10:19:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 10:19:06 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Architecture comparisons Thread-Index: AceyfbTM2g2gpFGSTOOcoIa34qe4sQABWYsg References: <004101c7b26e$49e1a5e0$220d0d0a@amer.cisco.com> From: "Dawson, Martin" To: "Henning Schulzrinne" , "Marc Linsner" X-OriginalArrivalTime: 19 Jun 2007 15:19:06.0473 (UTC) FILETIME=[2D5BBD90:01C7B285] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org There's probably a reality check in order in this discussion as well.=0D=0A= I'd be interested in what opinions are out there.=0D=0A=0D=0AHow many valid= "PSAP URIs" exist anywhere in the world today=3F I'll take=0D=0Aa wild sta= b and suggest... zero. That's certainly approximately correct.=0D=0A=0D=0AW= hen any significant jurisdiction does IP enable their emergency call=0D=0Ac= enters (and aren't they likely to be doing it before "insignificant"=0D=0Aj= urisdictions do=3F) I suspect it'll make the industry news.=0D=0A=0D=0AJust= how fast is this likely to happen=3F Is it the case that it will=0D=0Aactu= ally be reasonably straightforward to keep track of countries that=0D=0AIP = enable their emergency call centers as they emerge=3F And could this=0D=0An= ot be the case to the extent that any suitably diligent party could=0D=0Abu= ild a global database of PSAP URIs that was 95+ percent correct just=0D=0Ab= y monitoring the industry=3F Ideally, of course, each jurisdiction would=0D= =0Ahave an actual authority who would formally publish this information=0D=0A= (ideally publishing it into a forest guide infrastructure eventually,=0D=0A= though this wouldn't be necessary at the outset).=0D=0A=0D=0ADo people thin= k it's more or less likely that UA's will actually just=0D=0Auniversally ro= ute to the PSAP themselves rather than go via the VSP=0D=0Aanyway before an= y need for this global infrastructure emerges=3F Is there=0D=0Aany reason, = in the long term, for devices to route via the VSP if the=0D=0APSAP is dire= ctly reachable=3F=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original M= essage-----=0D=0AFrom: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20=0D= =0ASent: Wednesday, 20 June 2007 12:25 AM=0D=0ATo: Marc Linsner=0D=0ACc: EC= RIT=0D=0ASubject: Re: [Ecrit] Architecture comparisons=0D=0A=0D=0AI'll ad t= o the crystal ball gazing sessIon:=0D=0A=0D=0AI think the evolution will de= pend on who will be running LoST servers =20=0D=0Aand how data is distribut= ed. One model is that the PSAP or other =20=0D=0Agovernment authorities wil= l make data available, but LoST servers =20=0D=0Awill be run by private ent= erprises. Another is that these authorities =20=0D=0Awill run it themselves= =2E The depth of the trees will presumably depend =20=0D=0Aon the level of = federalism in the respective country, with some =20=0D=0Acountries, like Fr= ance, presumably going national immediately, while =20=0D=0Aothers, such as= the United States and Germany, maybe starting bottom =20=0D=0Aup, with som= e progressive states going first.=0D=0A=0D=0ARegardless, as long as these t= rees make coverage information =20=0D=0Aavailable or such information can b= e derived, it's not too hard for =20=0D=0Aeither a larger VSP or some third= -party service company to aggregate =20=0D=0Athis information and offer a "= private" FG. After all, the boundaries =20=0D=0Aof states and countries don= 't change all that often. In some =20=0D=0Acountries, the incumbent ISP wil= l presumably try to make life =20=0D=0Adifficult for third-party VoIP custo= mers until forced to by =20=0D=0Aregulators, so I wouldn't count on having = "open" access to PSAP URIs =20=0D=0Acourtesy of the ISP, either, but we'll = see.=0D=0A=0D=0ATo echo what Brian said, the likelihood that we'll have Zim= babwe, =20=0D=0ATaiwan and North Korea all happily in one FG run by the UN = is =20=0D=0Aprobably a ways off, just after the black helicopters have land= ed. =20=0D=0AHowever, for most people, almost all the time, things will wor= k, as =20=0D=0Along as we have some good will. (For example, avoid decade-l= ong legal =20=0D=0Afights about data ownership.)=0D=0A=0D=0AHenning=0D=0A=0D= =0AOn Jun 19, 2007, at 8:35 AM, Marc Linsner wrote:=0D=0A=0D=0A> All,=0D=0A= >=0D=0A> In my attempt to follow this thread, I've concluded that there is = a =20=0D=0A> belief=0D=0A> the access provider will have information wrt Lo= ST authoritative =20=0D=0A> servers=0D=0A> that VSPs won't have.=0D=0A>=0D=0A= > Is my assumption correct=3F=0D=0A>=0D=0A> Is it not true that the archite= cture we've adopted depends on the =20=0D=0A> forest=0D=0A> guide to 'find'= the authoritative LoST server=3F So, this raises the=0D=0A> question, sho= rt of a working forest guide, how does the access =20=0D=0A> provider find=0D= =0A> the authoritative LoST server and why can't the VSP use the same such=0D= =0A> mechanism=3F=0D=0A>=0D=0A> Just curious,=0D=0A=0D=0A=0D=0A____________= ___________________________________=0D=0AEcrit mailing list=0D=0AEcrit@ietf= =2Eorg=0D=0Ahttps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A-------= ---------------------------------------------------------------------------= --------------=0D=0AThis message is for the designated recipient only and m= ay=0D=0Acontain privileged, proprietary, or otherwise private information. = =20=0D=0AIf you have received it in error, please notify the sender=0D=0Aim= mediately and delete the original. Any unauthorized use of=0D=0Athis email= is prohibited.=0D=0A------------------------------------------------------= ------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 11:32:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fhL-0000JR-Ul; Tue, 19 Jun 2007 11:32:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fhK-0000JM-Pg for ecrit@ietf.org; Tue, 19 Jun 2007 11:32:50 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fhJ-0001I9-Hx for ecrit@ietf.org; Tue, 19 Jun 2007 11:32:49 -0400 X-SEF-Processed: 5_0_0_910__2007_06_19_10_40_36 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 19 Jun 2007 10:40:35 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jun 2007 10:32:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 10:32:50 -0500 Message-ID: In-Reply-To: <001001c7b283$f9fd1080$220d0d0a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Architecture comparisons Thread-Index: AceydUwKzy1FSY0XTXSPQ7fXT6X09AABl0+QAAIRhqAAAFbpsA== References: <001001c7b283$f9fd1080$220d0d0a@amer.cisco.com> From: "Dawson, Martin" To: "Marc Linsner" , "ECRIT" X-OriginalArrivalTime: 19 Jun 2007 15:32:49.0196 (UTC) FILETIME=[17BD4EC0:01C7B287] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Marc,=0D=0A=0D=0ARegarding you last comment:=0D=0A=0D=0A" I'm still miss= ing the tie between the access provider and the=0D=0Aauthoritative LoST ser= ver."=0D=0A=0D=0AIt's what Brian said - the ISP is "local" to the caller. J= ust as a=0D=0Acellular network provider currently "knows" which PSAPs are p= ertinent to=0D=0Atheir area of coverage (have to in order to provide the de= dicated trunks=0D=0Ato the 911 tandem switches) so too can any Internet acc= ess network=0D=0Aprovider offering service in a particular geographic regio= n.=0D=0A=0D=0AJust as they know the PSAP operators, they can know the ident= ity of the=0D=0Apertinent LoST server.=0D=0A=0D=0AThey are definitely in a = qualitatively different situation compared to=0D=0Athe VSPs by virtue of th= e physics of providing network coverage and the=0D=0Alocal knowledge that g= oes along with that.=0D=0A=0D=0Ae.g. I can certainly use a VoIP provider th= at has no business status in=0D=0AAustralia; I haven't found a way to do th= at with a DSL provider yet...=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A---= --Original Message-----=0D=0AFrom: Marc Linsner [mailto:mlinsner@cisco.com]= =20=0D=0ASent: Wednesday, 20 June 2007 1:11 AM=0D=0ATo: 'ECRIT'=0D=0ASubjec= t: FW: [Ecrit] Architecture comparisons=0D=0A=0D=0A=0D=0A=20=0D=0ARichard,=0D= =0A=0D=0AMore questions/comments in-line....=20=0D=0A=0D=0A>=20=0D=0A> You'= re correct that a general LoST lookup (with no assumptions about=20=0D=0A> = the locality of the seeker) does rely on the network of FGs and tree=20=0D=0A= > nodes to guide the query to the LoST server that's authoritative for=20=0D= =0A> the seeker's location.=0D=0A>=20=0D=0A> The assumption that's being ma= de here is that since the access network=0D=0A=0D=0A> is a geographically l= ocal entity, it can just remember which LoST=20=0D=0A> servers are authorit= ative for its coverage area, so that its queries=20=0D=0A> don't have to st= art at the top of the mapping heirarchy. It can just=20=0D=0A> take querie= s from seekers connected to its network (since this=20=0D=0A> connectivity = implies that they're in the coverage area) and send them=20=0D=0A> directly= to the local LoST server.=0D=0A=0D=0AWithout a FG, how is the authoritativ= e LoST server found initially=3F=0D=0A=0D=0AI would think we (ecrit) would = want to discourage 'remembering' the=0D=0Aauthoritative server for the same= reasons one should not 'remember' DNS=0D=0Amappings.=0D=0A=0D=0A>=20=0D=0A= > A VSP-operated resolver, on the other hand, would potentially have to=20=0D= =0A> handle queries from subscribers all over the world.=0D=0A> In other wo= rds, it would have to handle general LoST lookups, with no=20=0D=0A> assump= tions about the locality of the seeker. Thus, in general, VSPs=20=0D=0A> w= ill have to rely on the mapping infrastructure to find the=20=0D=0A> approp= riate LoST server to answer a given query from one of its=20=0D=0A> subscri= bers. This can be optimized by caching (e.g., if most=20=0D=0A> subscriber= s are in one area), but in general, a VSP needs to do the=20=0D=0A> full Lo= ST song and dance.=0D=0A>=20=0D=0A> IOW: Geographic locality of an entity a= llows caching of authoritative=20=0D=0A> LoST servers. Access networks (an= d their=0D=0A> subscribers) are necessarily localized to a coverage area; V= SPs=20=0D=0A> aren't, in general.=0D=0A=0D=0AI'm still missing the tie betw= een the access provider and the=0D=0Aauthoritative=0D=0ALoST server.=0D=0A=0D= =0A-Marc-=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A____________________________________= ___________=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www1.i= etf.org/mailman/listinfo/ecrit=0D=0A=0D=0A---------------------------------= ---------------------------------------------------------------=0D=0AThis m= essage is for the designated recipient only and may=0D=0Acontain privileged= , proprietary, or otherwise private information. =20=0D=0AIf you have recei= ved it in error, please notify the sender=0D=0Aimmediately and delete the o= riginal. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A-----= ---------------------------------------------------------------------------= ----------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 11:56:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0g4X-0001Qz-Jz; Tue, 19 Jun 2007 11:56:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0g4W-0001Qt-LJ for ecrit@ietf.org; Tue, 19 Jun 2007 11:56:48 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0g4W-0008Qq-36 for ecrit@ietf.org; Tue, 19 Jun 2007 11:56:48 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I0g4Q-0006Op-7h; Tue, 19 Jun 2007 10:56:42 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Henning Schulzrinne'" , "'Marc Linsner'" References: <004101c7b26e$49e1a5e0$220d0d0a@amer.cisco.com> Subject: RE: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 11:56:43 -0400 Message-ID: <008001c7b28a$71ed5a40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AceyfbTM2g2gpFGSTOOcoIa34qe4sQABWYsgAAGN1AA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Actually, most of the world already has them, depending on how you define most. Most PSAPs are only reachable via e.164s, for which we have tel or sip URIs readily mintable. The forest guide IS the jurisdiction publishing its data. That's the purpose. There is no point in publishing it a different way. Please also remember that for most countries (excepting the U.S. and Canada) the entire LoST database is a couple of records. We'll probably have the LoST data way before we have the PSAPs on an IP network. It would actually be quite useful to publish the geo boundaries. There are very few VSPs which can be bypassed. UAs don't ever route direct. They send all outbound calls to their outbound proxy. That's the VSP's proxy. Even the free services (FWD for example) are done that way. We could try to have emergency calls not do that of course, but I think that's a very big change. -phonebcp doesn't say that. I don't think it should. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Tuesday, June 19, 2007 11:19 AM > To: Henning Schulzrinne; Marc Linsner > Cc: ECRIT > Subject: RE: [Ecrit] Architecture comparisons > > There's probably a reality check in order in this discussion as well. > I'd be interested in what opinions are out there. > > How many valid "PSAP URIs" exist anywhere in the world today? I'll take > a wild stab and suggest... zero. That's certainly approximately correct. > > When any significant jurisdiction does IP enable their emergency call > centers (and aren't they likely to be doing it before "insignificant" > jurisdictions do?) I suspect it'll make the industry news. > > Just how fast is this likely to happen? Is it the case that it will > actually be reasonably straightforward to keep track of countries that > IP enable their emergency call centers as they emerge? And could this > not be the case to the extent that any suitably diligent party could > build a global database of PSAP URIs that was 95+ percent correct just > by monitoring the industry? Ideally, of course, each jurisdiction would > have an actual authority who would formally publish this information > (ideally publishing it into a forest guide infrastructure eventually, > though this wouldn't be necessary at the outset). > > Do people think it's more or less likely that UA's will actually just > universally route to the PSAP themselves rather than go via the VSP > anyway before any need for this global infrastructure emerges? Is there > any reason, in the long term, for devices to route via the VSP if the > PSAP is directly reachable? > > Cheers, > Martin > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, 20 June 2007 12:25 AM > To: Marc Linsner > Cc: ECRIT > Subject: Re: [Ecrit] Architecture comparisons > > I'll ad to the crystal ball gazing sessIon: > > I think the evolution will depend on who will be running LoST servers > and how data is distributed. One model is that the PSAP or other > government authorities will make data available, but LoST servers > will be run by private enterprises. Another is that these authorities > will run it themselves. The depth of the trees will presumably depend > on the level of federalism in the respective country, with some > countries, like France, presumably going national immediately, while > others, such as the United States and Germany, maybe starting bottom > up, with some progressive states going first. > > Regardless, as long as these trees make coverage information > available or such information can be derived, it's not too hard for > either a larger VSP or some third-party service company to aggregate > this information and offer a "private" FG. After all, the boundaries > of states and countries don't change all that often. In some > countries, the incumbent ISP will presumably try to make life > difficult for third-party VoIP customers until forced to by > regulators, so I wouldn't count on having "open" access to PSAP URIs > courtesy of the ISP, either, but we'll see. > > To echo what Brian said, the likelihood that we'll have Zimbabwe, > Taiwan and North Korea all happily in one FG run by the UN is > probably a ways off, just after the black helicopters have landed. > However, for most people, almost all the time, things will work, as > long as we have some good will. (For example, avoid decade-long legal > fights about data ownership.) > > Henning > > On Jun 19, 2007, at 8:35 AM, Marc Linsner wrote: > > > All, > > > > In my attempt to follow this thread, I've concluded that there is a > > belief > > the access provider will have information wrt LoST authoritative > > servers > > that VSPs won't have. > > > > Is my assumption correct? > > > > Is it not true that the architecture we've adopted depends on the > > forest > > guide to 'find' the authoritative LoST server? So, this raises the > > question, short of a working forest guide, how does the access > > provider find > > the authoritative LoST server and why can't the VSP use the same such > > mechanism? > > > > Just curious, > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 12:06:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gDZ-000592-J4; Tue, 19 Jun 2007 12:06:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gDY-00058s-UY for ecrit@ietf.org; Tue, 19 Jun 2007 12:06:08 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0gDY-0001um-GO for ecrit@ietf.org; Tue, 19 Jun 2007 12:06:08 -0400 X-SEF-Processed: 5_0_0_910__2007_06_19_11_13_54 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 19 Jun 2007 11:13:54 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jun 2007 11:06:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 11:06:11 -0500 Message-ID: In-Reply-To: <008001c7b28a$71ed5a40$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Architecture comparisons Thread-Index: AceyfbTM2g2gpFGSTOOcoIa34qe4sQABWYsgAAGN1AAAAFoqgA== References: <004101c7b26e$49e1a5e0$220d0d0a@amer.cisco.com> <008001c7b28a$71ed5a40$640fa8c0@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , "Henning Schulzrinne" , "Marc Linsner" X-OriginalArrivalTime: 19 Jun 2007 16:06:07.0927 (UTC) FILETIME=[BF137470:01C7B28B] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Oh for pity's... that wasn't the spirit of my question.=0D=0A=0D=0AOK, how = many PSAP URIs exist which will permit the location object or=0D=0Alocation= reference to be delivered with the call=3F=0D=0A=0D=0AAnd doing PSTN bridg= ing doesn't work in the US... that's i1 and it's not=0D=0Aacceptable. It do= esn't work in any other country where emergency calls=0D=0Aare not carried = on the PSTN.=0D=0A=0D=0AWhy don't you think the BCP should recommend that a= UA which knows it's=0D=0Adoing an emergency call just route directly=3F Wh= at actual value does the=0D=0AVSP add, out of curiosity=3F Is this in order= to enforce some sort of=0D=0Asubscriber identity audit trail=3F I don't th= ink that would work for=0D=0Aforeign VSPs anyway; is it something that ECRI= T has decided is a goal=3F=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----O= riginal Message-----=0D=0AFrom: Brian Rosen [mailto:br@brianrosen.net]=20=0D= =0ASent: Wednesday, 20 June 2007 1:57 AM=0D=0ATo: Dawson, Martin; 'Henning = Schulzrinne'; 'Marc Linsner'=0D=0ACc: 'ECRIT'=0D=0ASubject: RE: [Ecrit] Arc= hitecture comparisons=0D=0A=0D=0AActually, most of the world already has th= em, depending on how you=0D=0Adefine=0D=0Amost. Most PSAPs are only reacha= ble via e.164s, for which we have tel=0D=0Aor=0D=0Asip URIs readily mintabl= e.=0D=0A=0D=0AThe forest guide IS the jurisdiction publishing its data. Th= at's the=0D=0Apurpose. There is no point in publishing it a different way.=0D= =0A=0D=0APlease also remember that for most countries (excepting the U.S. a= nd=0D=0ACanada)=0D=0Athe entire LoST database is a couple of records. We'l= l probably have=0D=0Athe=0D=0ALoST data way before we have the PSAPs on an = IP network. It would=0D=0Aactually=0D=0Abe quite useful to publish the geo= boundaries.=0D=0A=0D=0AThere are very few VSPs which can be bypassed. UAs= don't ever route=0D=0Adirect.=0D=0AThey send all outbound calls to their o= utbound proxy. That's the VSP's=0D=0Aproxy. Even the free services (FWD f= or example) are done that way. We=0D=0Acould try to have emergency calls n= ot do that of course, but I think=0D=0Athat's=0D=0Aa very big change. -pho= nebcp doesn't say that. I don't think it=0D=0Ashould.=0D=0A=0D=0ABrian=0D=0A=0D= =0A> -----Original Message-----=0D=0A> From: Dawson, Martin [mailto:Martin.= Dawson@andrew.com]=0D=0A> Sent: Tuesday, June 19, 2007 11:19 AM=0D=0A> To: = Henning Schulzrinne; Marc Linsner=0D=0A> Cc: ECRIT=0D=0A> Subject: RE: [Ecr= it] Architecture comparisons=0D=0A>=20=0D=0A> There's probably a reality ch= eck in order in this discussion as well.=0D=0A> I'd be interested in what o= pinions are out there.=0D=0A>=20=0D=0A> How many valid "PSAP URIs" exist an= ywhere in the world today=3F I'll=0D=0Atake=0D=0A> a wild stab and suggest.= =2E. zero. That's certainly approximately=0D=0Acorrect.=0D=0A>=20=0D=0A> Wh= en any significant jurisdiction does IP enable their emergency call=0D=0A> = centers (and aren't they likely to be doing it before "insignificant"=0D=0A= > jurisdictions do=3F) I suspect it'll make the industry news.=0D=0A>=20=0D= =0A> Just how fast is this likely to happen=3F Is it the case that it will=0D= =0A> actually be reasonably straightforward to keep track of countries that=0D= =0A> IP enable their emergency call centers as they emerge=3F And could thi= s=0D=0A> not be the case to the extent that any suitably diligent party cou= ld=0D=0A> build a global database of PSAP URIs that was 95+ percent correct= just=0D=0A> by monitoring the industry=3F Ideally, of course, each jurisdi= ction=0D=0Awould=0D=0A> have an actual authority who would formally publish= this information=0D=0A> (ideally publishing it into a forest guide infrast= ructure eventually,=0D=0A> though this wouldn't be necessary at the outset)= =2E=0D=0A>=20=0D=0A> Do people think it's more or less likely that UA's wil= l actually just=0D=0A> universally route to the PSAP themselves rather than= go via the VSP=0D=0A> anyway before any need for this global infrastructur= e emerges=3F Is=0D=0Athere=0D=0A> any reason, in the long term, for devices= to route via the VSP if the=0D=0A> PSAP is directly reachable=3F=0D=0A> =0D= =0A> Cheers,=0D=0A> Martin=0D=0A>=20=0D=0A> -----Original Message-----=0D=0A= > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A> Sent: Wedne= sday, 20 June 2007 12:25 AM=0D=0A> To: Marc Linsner=0D=0A> Cc: ECRIT=0D=0A>= Subject: Re: [Ecrit] Architecture comparisons=0D=0A>=20=0D=0A> I'll ad to = the crystal ball gazing sessIon:=0D=0A>=20=0D=0A> I think the evolution wil= l depend on who will be running LoST servers=0D=0A> and how data is distrib= uted. One model is that the PSAP or other=0D=0A> government authorities wil= l make data available, but LoST servers=0D=0A> will be run by private enter= prises. Another is that these authorities=0D=0A> will run it themselves. Th= e depth of the trees will presumably depend=0D=0A> on the level of federali= sm in the respective country, with some=0D=0A> countries, like France, pres= umably going national immediately, while=0D=0A> others, such as the United = States and Germany, maybe starting bottom=0D=0A> up, with some progressive = states going first.=0D=0A>=20=0D=0A> Regardless, as long as these trees mak= e coverage information=0D=0A> available or such information can be derived,= it's not too hard for=0D=0A> either a larger VSP or some third-party servi= ce company to aggregate=0D=0A> this information and offer a "private" FG. A= fter all, the boundaries=0D=0A> of states and countries don't change all th= at often. In some=0D=0A> countries, the incumbent ISP will presumably try t= o make life=0D=0A> difficult for third-party VoIP customers until forced to= by=0D=0A> regulators, so I wouldn't count on having "open" access to PSAP = URIs=0D=0A> courtesy of the ISP, either, but we'll see.=0D=0A>=20=0D=0A> To= echo what Brian said, the likelihood that we'll have Zimbabwe,=0D=0A> Taiw= an and North Korea all happily in one FG run by the UN is=0D=0A> probably a= ways off, just after the black helicopters have landed.=0D=0A> However, fo= r most people, almost all the time, things will work, as=0D=0A> long as we = have some good will. (For example, avoid decade-long legal=0D=0A> fights ab= out data ownership.)=0D=0A>=20=0D=0A> Henning=0D=0A>=20=0D=0A> On Jun 19, 2= 007, at 8:35 AM, Marc Linsner wrote:=0D=0A>=20=0D=0A> > All,=0D=0A> >=0D=0A= > > In my attempt to follow this thread, I've concluded that there is a=0D=0A= > > belief=0D=0A> > the access provider will have information wrt LoST auth= oritative=0D=0A> > servers=0D=0A> > that VSPs won't have.=0D=0A> >=0D=0A> >= Is my assumption correct=3F=0D=0A> >=0D=0A> > Is it not true that the arch= itecture we've adopted depends on the=0D=0A> > forest=0D=0A> > guide to 'fi= nd' the authoritative LoST server=3F So, this raises the=0D=0A> > question= , short of a working forest guide, how does the access=0D=0A> > provider fi= nd=0D=0A> > the authoritative LoST server and why can't the VSP use the sam= e=0D=0Asuch=0D=0A> > mechanism=3F=0D=0A> >=0D=0A> > Just curious,=0D=0A> =0D= =0A>=20=0D=0A> _______________________________________________=0D=0A> Ecrit= mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mailman/li= stinfo/ecrit=0D=0A>=20=0D=0A>=0D=0A----------------------------------------= --------------------------------=0D=0A--=0D=0A> ----------------------=0D=0A= > This message is for the designated recipient only and may=0D=0A> contain = privileged, proprietary, or otherwise private information.=0D=0A> If you ha= ve received it in error, please notify the sender=0D=0A> immediately and de= lete the original. Any unauthorized use of=0D=0A> this email is prohibited= =2E=0D=0A>=0D=0A-----------------------------------------------------------= -------------=0D=0A--=0D=0A> ----------------------=0D=0A> [mf2]=0D=0A>=20=0D= =0A>=20=0D=0A> _______________________________________________=0D=0A> Ecrit= mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mailman/li= stinfo/ecrit=0D=0A=0D=0A=0D=0A---------------------------------------------= ---------------------------------------------------=0D=0AThis message is fo= r the designated recipient only and may=0D=0Acontain privileged, proprietar= y, or otherwise private information. =20=0D=0AIf you have received it in er= ror, please notify the sender=0D=0Aimmediately and delete the original. An= y unauthorized use of=0D=0Athis email is prohibited.=0D=0A-----------------= ---------------------------------------------------------------------------= ----=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 12:14:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gLV-0003ki-5X; Tue, 19 Jun 2007 12:14:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gLU-0003ka-Et for ecrit@ietf.org; Tue, 19 Jun 2007 12:14:20 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0gLT-0003c6-7N for ecrit@ietf.org; Tue, 19 Jun 2007 12:14:20 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I0gLS-0001Fu-69; Tue, 19 Jun 2007 12:14:18 -0400 Received: from [127.0.0.1] (col-dhcp33-244-162.bbn.com [128.33.244.162]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l5JGEII17641; Tue, 19 Jun 2007 12:14:18 -0400 (EDT) Message-ID: <467800C8.6030009@bbn.com> Date: Tue, 19 Jun 2007 12:14:00 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Marc Linsner Subject: Re: FW: [Ecrit] Architecture comparisons References: <001001c7b283$f9fd1080$220d0d0a@amer.cisco.com> In-Reply-To: <001001c7b283$f9fd1080$220d0d0a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > Without a FG, how is the authoritative LoST server found initially? > ~snip~ > I'm still missing the tie between the access provider and the authoritative > LoST server. As Martin notes, it can be done by local configuration, just as networks today know about their local PSAPs. This is, of course, not the optimal case, but it works as a stop-gap until FGs are deployed. The tie between the access provider and the authoritative LoST server is the same as the tie between the access provider and the selective router it uses to get to its PSAPs -- they're both concerned with the same geographical area. So, as an optimization, an access provider might hard-wire LoST queries straight to the appropriate authoritative server, rather than going all the way from FGs down the tree. I think you're right, though, that this kind of "caching" is a bad idea, since there's no standard way to know when the set of authoritative servers changes. > I would think we (ecrit) would want to discourage 'remembering' the > authoritative server for the same reasons one should not 'remember' DNS > mappings. You're correct that it's not good to remember authoritative servers because there's no standard refresh mechanism. However, it makes a lot of sense to cache mappings (as the DNS does). A likely scenario is that an access network will have a local resolver that caches LoST mappings to cover its coverage area. (It can either cache as subscriber requests come through or scan the area itself to gather them.) This is OK: The mappings have marked expirations so that the resolver knows when to throw them out. So, just like the DNS caches name-address mappings at various points, there will probably be caching in the mapping infrastructure -- it just makes sense, given the expected lifetime of mappings. The mapping architecture allows for this; the expiry fields in LoST tell the server when to refresh. --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 12:25:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gWh-0000m9-Vi; Tue, 19 Jun 2007 12:25:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gWg-0000kq-KG for ecrit@ietf.org; Tue, 19 Jun 2007 12:25:54 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0gWe-0006fB-1A for ecrit@ietf.org; Tue, 19 Jun 2007 12:25:54 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I0gWX-0002js-8Q; Tue, 19 Jun 2007 11:25:46 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Henning Schulzrinne'" , "'Marc Linsner'" References: <004101c7b26e$49e1a5e0$220d0d0a@amer.cisco.com> <008001c7b28a$71ed5a40$640fa8c0@cis.neustar.com> Subject: RE: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 12:25:48 -0400 Message-ID: <009301c7b28e$80c1e780$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AceyfbTM2g2gpFGSTOOcoIa34qe4sQABWYsgAAGN1AAAAFoqgAAAgH8g X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org But the point is that if the e.164 is in the database, the right thing happens if the PSAP is only reachable by the PSTN. They don't get addresses from the endpoint (if they get them at all, it's an internal phone book). A VoIP endpoint conformant to phonebcp would be able to successfully complete an emergency call to such a PSAP if the data is put in a LoST server it can get to. Realistically, it would be very possible to make most VSP systems correctly handle 3 digit emergency calls, albeit nomadic users wouldn't have correct location. The VSP would have to route a call to the right 3 digit gateway. A U.S. "i2" solution, but if you nomaded to the U.K., we could get the right thing to happen there (probably have to use their mobile location stuff). I'm not seriously suggesting it, just noting that if you had the correct boundary data, and internal route infrastructure, the whole mechanism can be made to work pretty well without putting PSAPs on IP networks. Outbound routing is usually pretty tough. One example is NAT traversal for media. Unless the UA does STUN/TURN, it's usually an SBC in the VSP that fixes the media. Signaling outbound is sometimes a problem (outbound SIP on port 5060 is often blocked). It has nothing nefarious; just the likelihood of working, where special procedures only used for emergency calls may not work. Also, we're expecting the VSPs to often have VPN connections to the ESRP, rather than taking the calls from the Internet. Where there is QoS, we can maintain it. We also get some DDoS protection. That won't work when you nomad afar, but it does work for the normal case. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Tuesday, June 19, 2007 12:06 PM > To: Brian Rosen; Henning Schulzrinne; Marc Linsner > Cc: ECRIT > Subject: RE: [Ecrit] Architecture comparisons > > Oh for pity's... that wasn't the spirit of my question. > > OK, how many PSAP URIs exist which will permit the location object or > location reference to be delivered with the call? > > And doing PSTN bridging doesn't work in the US... that's i1 and it's not > acceptable. It doesn't work in any other country where emergency calls > are not carried on the PSTN. > > Why don't you think the BCP should recommend that a UA which knows it's > doing an emergency call just route directly? What actual value does the > VSP add, out of curiosity? Is this in order to enforce some sort of > subscriber identity audit trail? I don't think that would work for > foreign VSPs anyway; is it something that ECRIT has decided is a goal? > > Cheers, > Martin > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, 20 June 2007 1:57 AM > To: Dawson, Martin; 'Henning Schulzrinne'; 'Marc Linsner' > Cc: 'ECRIT' > Subject: RE: [Ecrit] Architecture comparisons > > Actually, most of the world already has them, depending on how you > define > most. Most PSAPs are only reachable via e.164s, for which we have tel > or > sip URIs readily mintable. > > The forest guide IS the jurisdiction publishing its data. That's the > purpose. There is no point in publishing it a different way. > > Please also remember that for most countries (excepting the U.S. and > Canada) > the entire LoST database is a couple of records. We'll probably have > the > LoST data way before we have the PSAPs on an IP network. It would > actually > be quite useful to publish the geo boundaries. > > There are very few VSPs which can be bypassed. UAs don't ever route > direct. > They send all outbound calls to their outbound proxy. That's the VSP's > proxy. Even the free services (FWD for example) are done that way. We > could try to have emergency calls not do that of course, but I think > that's > a very big change. -phonebcp doesn't say that. I don't think it > should. > > Brian > > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: Tuesday, June 19, 2007 11:19 AM > > To: Henning Schulzrinne; Marc Linsner > > Cc: ECRIT > > Subject: RE: [Ecrit] Architecture comparisons > > > > There's probably a reality check in order in this discussion as well. > > I'd be interested in what opinions are out there. > > > > How many valid "PSAP URIs" exist anywhere in the world today? I'll > take > > a wild stab and suggest... zero. That's certainly approximately > correct. > > > > When any significant jurisdiction does IP enable their emergency call > > centers (and aren't they likely to be doing it before "insignificant" > > jurisdictions do?) I suspect it'll make the industry news. > > > > Just how fast is this likely to happen? Is it the case that it will > > actually be reasonably straightforward to keep track of countries that > > IP enable their emergency call centers as they emerge? And could this > > not be the case to the extent that any suitably diligent party could > > build a global database of PSAP URIs that was 95+ percent correct just > > by monitoring the industry? Ideally, of course, each jurisdiction > would > > have an actual authority who would formally publish this information > > (ideally publishing it into a forest guide infrastructure eventually, > > though this wouldn't be necessary at the outset). > > > > Do people think it's more or less likely that UA's will actually just > > universally route to the PSAP themselves rather than go via the VSP > > anyway before any need for this global infrastructure emerges? Is > there > > any reason, in the long term, for devices to route via the VSP if the > > PSAP is directly reachable? > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Wednesday, 20 June 2007 12:25 AM > > To: Marc Linsner > > Cc: ECRIT > > Subject: Re: [Ecrit] Architecture comparisons > > > > I'll ad to the crystal ball gazing sessIon: > > > > I think the evolution will depend on who will be running LoST servers > > and how data is distributed. One model is that the PSAP or other > > government authorities will make data available, but LoST servers > > will be run by private enterprises. Another is that these authorities > > will run it themselves. The depth of the trees will presumably depend > > on the level of federalism in the respective country, with some > > countries, like France, presumably going national immediately, while > > others, such as the United States and Germany, maybe starting bottom > > up, with some progressive states going first. > > > > Regardless, as long as these trees make coverage information > > available or such information can be derived, it's not too hard for > > either a larger VSP or some third-party service company to aggregate > > this information and offer a "private" FG. After all, the boundaries > > of states and countries don't change all that often. In some > > countries, the incumbent ISP will presumably try to make life > > difficult for third-party VoIP customers until forced to by > > regulators, so I wouldn't count on having "open" access to PSAP URIs > > courtesy of the ISP, either, but we'll see. > > > > To echo what Brian said, the likelihood that we'll have Zimbabwe, > > Taiwan and North Korea all happily in one FG run by the UN is > > probably a ways off, just after the black helicopters have landed. > > However, for most people, almost all the time, things will work, as > > long as we have some good will. (For example, avoid decade-long legal > > fights about data ownership.) > > > > Henning > > > > On Jun 19, 2007, at 8:35 AM, Marc Linsner wrote: > > > > > All, > > > > > > In my attempt to follow this thread, I've concluded that there is a > > > belief > > > the access provider will have information wrt LoST authoritative > > > servers > > > that VSPs won't have. > > > > > > Is my assumption correct? > > > > > > Is it not true that the architecture we've adopted depends on the > > > forest > > > guide to 'find' the authoritative LoST server? So, this raises the > > > question, short of a working forest guide, how does the access > > > provider find > > > the authoritative LoST server and why can't the VSP use the same > such > > > mechanism? > > > > > > Just curious, > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 12:25:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gWi-0000mf-7V; Tue, 19 Jun 2007 12:25:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gWh-0000lJ-6J for ecrit@ietf.org; Tue, 19 Jun 2007 12:25:55 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0gWg-0006fV-Qd for ecrit@ietf.org; Tue, 19 Jun 2007 12:25:55 -0400 X-SEF-Processed: 5_0_0_910__2007_06_19_11_33_41 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 19 Jun 2007 11:33:41 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jun 2007 11:25:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 11:25:59 -0500 Message-ID: In-Reply-To: <467800C8.6030009@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: [Ecrit] Architecture comparisons Thread-Index: AceyjObAZWDY3b26S3qKjrmTjczC2AAAFJ3Q References: <001001c7b283$f9fd1080$220d0d0a@amer.cisco.com> <467800C8.6030009@bbn.com> From: "Dawson, Martin" To: "Richard Barnes" , "Marc Linsner" X-OriginalArrivalTime: 19 Jun 2007 16:25:54.0310 (UTC) FILETIME=[82372260:01C7B28E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I don't even know that this simile is very compelling...=0D=0A=0D=0ALoST is= a service, the URI for the service can be looked up in DNS and=0D=0Athose = entries will be managed by whoever manages that LoST service. I=0D=0Adon't = think I'm really caching the important information in this=0D=0Ascenario. I= f a FG comes into play at the local level then I still have=0D=0Ato have an= FG URI; should I be concerned about the fact that I've=0D=0Ahardwired that= =3F=0D=0A=0D=0AThink about it; in the commonest type of national jurisdicti= on there'll=0D=0Aprobably be one PSAP URI (which will be in DNS including r= edundant=0D=0Adestinations) and that jurisdiction is likely to have one LoS= T server to=0D=0Aserve up that one PSAP URI. So we have a system of using a= known (=3F)=0D=0Alocal FG to lookup up a local LoST server to look up the = one local PSAP=0D=0AURI. Isn't there a good deal of overkill viz levels of = indirection going=0D=0Aon here=3F=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A= -----Original Message-----=0D=0AFrom: Richard Barnes [mailto:rbarnes@bbn.co= m]=20=0D=0ASent: Wednesday, 20 June 2007 2:14 AM=0D=0ATo: Marc Linsner=0D=0A= Cc: 'ECRIT'=0D=0ASubject: Re: FW: [Ecrit] Architecture comparisons=0D=0A=0D= =0A> Without a FG, how is the authoritative LoST server found initially=3F =0D= =0A> ~snip~=0D=0A> I'm still missing the tie between the access provider an= d the=0D=0Aauthoritative=0D=0A> LoST server.=0D=0A=0D=0AAs Martin notes, it= can be done by local configuration, just as networks=0D=0A=0D=0Atoday know= about their local PSAPs. This is, of course, not the optimal=0D=0A=0D=0A = case, but it works as a stop-gap until FGs are deployed.=0D=0A=0D=0AThe ti= e between the access provider and the authoritative LoST server is=0D=0A=0D= =0Athe same as the tie between the access provider and the selective router=0D= =0A=0D=0Ait uses to get to its PSAPs -- they're both concerned with the sam= e=20=0D=0Ageographical area. So, as an optimization, an access provider mi= ght=20=0D=0Ahard-wire LoST queries straight to the appropriate authoritativ= e server,=0D=0A=0D=0Arather than going all the way from FGs down the tree. = I think you're=20=0D=0Aright, though, that this kind of "caching" is a bad= idea, since there's=20=0D=0Ano standard way to know when the set of author= itative servers changes.=0D=0A=0D=0A> I would think we (ecrit) would want t= o discourage 'remembering' the=0D=0A> authoritative server for the same rea= sons one should not 'remember'=0D=0ADNS=0D=0A> mappings.=0D=0A=0D=0AYou're = correct that it's not good to remember authoritative servers=20=0D=0Abecaus= e there's no standard refresh mechanism. However, it makes a lot=20=0D=0Ao= f sense to cache mappings (as the DNS does). A likely scenario is that=0D=0A=0D= =0Aan access network will have a local resolver that caches LoST mappings =0D= =0Ato cover its coverage area. (It can either cache as subscriber requests=0D= =0A=0D=0Acome through or scan the area itself to gather them.) This is OK:= The=20=0D=0Amappings have marked expirations so that the resolver knows wh= en to=20=0D=0Athrow them out.=0D=0A=0D=0ASo, just like the DNS caches name-= address mappings at various points,=20=0D=0Athere will probably be caching = in the mapping infrastructure -- it just=20=0D=0Amakes sense, given the exp= ected lifetime of mappings. The mapping=20=0D=0Aarchitecture allows for th= is; the expiry fields in LoST tell the server=20=0D=0Awhen to refresh.=0D=0A=0D= =0A--Richard=0D=0A=0D=0A=0D=0A_____________________________________________= __=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www1.ietf.org/m= ailman/listinfo/ecrit=0D=0A=0D=0A------------------------------------------= ------------------------------------------------------=0D=0AThis message is= for the designated recipient only and may=0D=0Acontain privileged, proprie= tary, or otherwise private information. =20=0D=0AIf you have received it in= error, please notify the sender=0D=0Aimmediately and delete the original. = Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A--------------= ---------------------------------------------------------------------------= -------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 12:25:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gWh-0000m9-Vi; Tue, 19 Jun 2007 12:25:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gWg-0000kq-KG for ecrit@ietf.org; Tue, 19 Jun 2007 12:25:54 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0gWe-0006fB-1A for ecrit@ietf.org; Tue, 19 Jun 2007 12:25:54 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I0gWX-0002js-8Q; Tue, 19 Jun 2007 11:25:46 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Henning Schulzrinne'" , "'Marc Linsner'" References: <004101c7b26e$49e1a5e0$220d0d0a@amer.cisco.com> <008001c7b28a$71ed5a40$640fa8c0@cis.neustar.com> Subject: RE: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 12:25:48 -0400 Message-ID: <009301c7b28e$80c1e780$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AceyfbTM2g2gpFGSTOOcoIa34qe4sQABWYsgAAGN1AAAAFoqgAAAgH8g X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org But the point is that if the e.164 is in the database, the right thing happens if the PSAP is only reachable by the PSTN. They don't get addresses from the endpoint (if they get them at all, it's an internal phone book). A VoIP endpoint conformant to phonebcp would be able to successfully complete an emergency call to such a PSAP if the data is put in a LoST server it can get to. Realistically, it would be very possible to make most VSP systems correctly handle 3 digit emergency calls, albeit nomadic users wouldn't have correct location. The VSP would have to route a call to the right 3 digit gateway. A U.S. "i2" solution, but if you nomaded to the U.K., we could get the right thing to happen there (probably have to use their mobile location stuff). I'm not seriously suggesting it, just noting that if you had the correct boundary data, and internal route infrastructure, the whole mechanism can be made to work pretty well without putting PSAPs on IP networks. Outbound routing is usually pretty tough. One example is NAT traversal for media. Unless the UA does STUN/TURN, it's usually an SBC in the VSP that fixes the media. Signaling outbound is sometimes a problem (outbound SIP on port 5060 is often blocked). It has nothing nefarious; just the likelihood of working, where special procedures only used for emergency calls may not work. Also, we're expecting the VSPs to often have VPN connections to the ESRP, rather than taking the calls from the Internet. Where there is QoS, we can maintain it. We also get some DDoS protection. That won't work when you nomad afar, but it does work for the normal case. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Tuesday, June 19, 2007 12:06 PM > To: Brian Rosen; Henning Schulzrinne; Marc Linsner > Cc: ECRIT > Subject: RE: [Ecrit] Architecture comparisons > > Oh for pity's... that wasn't the spirit of my question. > > OK, how many PSAP URIs exist which will permit the location object or > location reference to be delivered with the call? > > And doing PSTN bridging doesn't work in the US... that's i1 and it's not > acceptable. It doesn't work in any other country where emergency calls > are not carried on the PSTN. > > Why don't you think the BCP should recommend that a UA which knows it's > doing an emergency call just route directly? What actual value does the > VSP add, out of curiosity? Is this in order to enforce some sort of > subscriber identity audit trail? I don't think that would work for > foreign VSPs anyway; is it something that ECRIT has decided is a goal? > > Cheers, > Martin > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, 20 June 2007 1:57 AM > To: Dawson, Martin; 'Henning Schulzrinne'; 'Marc Linsner' > Cc: 'ECRIT' > Subject: RE: [Ecrit] Architecture comparisons > > Actually, most of the world already has them, depending on how you > define > most. Most PSAPs are only reachable via e.164s, for which we have tel > or > sip URIs readily mintable. > > The forest guide IS the jurisdiction publishing its data. That's the > purpose. There is no point in publishing it a different way. > > Please also remember that for most countries (excepting the U.S. and > Canada) > the entire LoST database is a couple of records. We'll probably have > the > LoST data way before we have the PSAPs on an IP network. It would > actually > be quite useful to publish the geo boundaries. > > There are very few VSPs which can be bypassed. UAs don't ever route > direct. > They send all outbound calls to their outbound proxy. That's the VSP's > proxy. Even the free services (FWD for example) are done that way. We > could try to have emergency calls not do that of course, but I think > that's > a very big change. -phonebcp doesn't say that. I don't think it > should. > > Brian > > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: Tuesday, June 19, 2007 11:19 AM > > To: Henning Schulzrinne; Marc Linsner > > Cc: ECRIT > > Subject: RE: [Ecrit] Architecture comparisons > > > > There's probably a reality check in order in this discussion as well. > > I'd be interested in what opinions are out there. > > > > How many valid "PSAP URIs" exist anywhere in the world today? I'll > take > > a wild stab and suggest... zero. That's certainly approximately > correct. > > > > When any significant jurisdiction does IP enable their emergency call > > centers (and aren't they likely to be doing it before "insignificant" > > jurisdictions do?) I suspect it'll make the industry news. > > > > Just how fast is this likely to happen? Is it the case that it will > > actually be reasonably straightforward to keep track of countries that > > IP enable their emergency call centers as they emerge? And could this > > not be the case to the extent that any suitably diligent party could > > build a global database of PSAP URIs that was 95+ percent correct just > > by monitoring the industry? Ideally, of course, each jurisdiction > would > > have an actual authority who would formally publish this information > > (ideally publishing it into a forest guide infrastructure eventually, > > though this wouldn't be necessary at the outset). > > > > Do people think it's more or less likely that UA's will actually just > > universally route to the PSAP themselves rather than go via the VSP > > anyway before any need for this global infrastructure emerges? Is > there > > any reason, in the long term, for devices to route via the VSP if the > > PSAP is directly reachable? > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Wednesday, 20 June 2007 12:25 AM > > To: Marc Linsner > > Cc: ECRIT > > Subject: Re: [Ecrit] Architecture comparisons > > > > I'll ad to the crystal ball gazing sessIon: > > > > I think the evolution will depend on who will be running LoST servers > > and how data is distributed. One model is that the PSAP or other > > government authorities will make data available, but LoST servers > > will be run by private enterprises. Another is that these authorities > > will run it themselves. The depth of the trees will presumably depend > > on the level of federalism in the respective country, with some > > countries, like France, presumably going national immediately, while > > others, such as the United States and Germany, maybe starting bottom > > up, with some progressive states going first. > > > > Regardless, as long as these trees make coverage information > > available or such information can be derived, it's not too hard for > > either a larger VSP or some third-party service company to aggregate > > this information and offer a "private" FG. After all, the boundaries > > of states and countries don't change all that often. In some > > countries, the incumbent ISP will presumably try to make life > > difficult for third-party VoIP customers until forced to by > > regulators, so I wouldn't count on having "open" access to PSAP URIs > > courtesy of the ISP, either, but we'll see. > > > > To echo what Brian said, the likelihood that we'll have Zimbabwe, > > Taiwan and North Korea all happily in one FG run by the UN is > > probably a ways off, just after the black helicopters have landed. > > However, for most people, almost all the time, things will work, as > > long as we have some good will. (For example, avoid decade-long legal > > fights about data ownership.) > > > > Henning > > > > On Jun 19, 2007, at 8:35 AM, Marc Linsner wrote: > > > > > All, > > > > > > In my attempt to follow this thread, I've concluded that there is a > > > belief > > > the access provider will have information wrt LoST authoritative > > > servers > > > that VSPs won't have. > > > > > > Is my assumption correct? > > > > > > Is it not true that the architecture we've adopted depends on the > > > forest > > > guide to 'find' the authoritative LoST server? So, this raises the > > > question, short of a working forest guide, how does the access > > > provider find > > > the authoritative LoST server and why can't the VSP use the same > such > > > mechanism? > > > > > > Just curious, > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 12:25:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gWi-0000mf-7V; Tue, 19 Jun 2007 12:25:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gWh-0000lJ-6J for ecrit@ietf.org; Tue, 19 Jun 2007 12:25:55 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0gWg-0006fV-Qd for ecrit@ietf.org; Tue, 19 Jun 2007 12:25:55 -0400 X-SEF-Processed: 5_0_0_910__2007_06_19_11_33_41 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 19 Jun 2007 11:33:41 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jun 2007 11:25:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 11:25:59 -0500 Message-ID: In-Reply-To: <467800C8.6030009@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: [Ecrit] Architecture comparisons Thread-Index: AceyjObAZWDY3b26S3qKjrmTjczC2AAAFJ3Q References: <001001c7b283$f9fd1080$220d0d0a@amer.cisco.com> <467800C8.6030009@bbn.com> From: "Dawson, Martin" To: "Richard Barnes" , "Marc Linsner" X-OriginalArrivalTime: 19 Jun 2007 16:25:54.0310 (UTC) FILETIME=[82372260:01C7B28E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I don't even know that this simile is very compelling...=0D=0A=0D=0ALoST is= a service, the URI for the service can be looked up in DNS and=0D=0Athose = entries will be managed by whoever manages that LoST service. I=0D=0Adon't = think I'm really caching the important information in this=0D=0Ascenario. I= f a FG comes into play at the local level then I still have=0D=0Ato have an= FG URI; should I be concerned about the fact that I've=0D=0Ahardwired that= =3F=0D=0A=0D=0AThink about it; in the commonest type of national jurisdicti= on there'll=0D=0Aprobably be one PSAP URI (which will be in DNS including r= edundant=0D=0Adestinations) and that jurisdiction is likely to have one LoS= T server to=0D=0Aserve up that one PSAP URI. So we have a system of using a= known (=3F)=0D=0Alocal FG to lookup up a local LoST server to look up the = one local PSAP=0D=0AURI. Isn't there a good deal of overkill viz levels of = indirection going=0D=0Aon here=3F=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A= -----Original Message-----=0D=0AFrom: Richard Barnes [mailto:rbarnes@bbn.co= m]=20=0D=0ASent: Wednesday, 20 June 2007 2:14 AM=0D=0ATo: Marc Linsner=0D=0A= Cc: 'ECRIT'=0D=0ASubject: Re: FW: [Ecrit] Architecture comparisons=0D=0A=0D= =0A> Without a FG, how is the authoritative LoST server found initially=3F =0D= =0A> ~snip~=0D=0A> I'm still missing the tie between the access provider an= d the=0D=0Aauthoritative=0D=0A> LoST server.=0D=0A=0D=0AAs Martin notes, it= can be done by local configuration, just as networks=0D=0A=0D=0Atoday know= about their local PSAPs. This is, of course, not the optimal=0D=0A=0D=0A = case, but it works as a stop-gap until FGs are deployed.=0D=0A=0D=0AThe ti= e between the access provider and the authoritative LoST server is=0D=0A=0D= =0Athe same as the tie between the access provider and the selective router=0D= =0A=0D=0Ait uses to get to its PSAPs -- they're both concerned with the sam= e=20=0D=0Ageographical area. So, as an optimization, an access provider mi= ght=20=0D=0Ahard-wire LoST queries straight to the appropriate authoritativ= e server,=0D=0A=0D=0Arather than going all the way from FGs down the tree. = I think you're=20=0D=0Aright, though, that this kind of "caching" is a bad= idea, since there's=20=0D=0Ano standard way to know when the set of author= itative servers changes.=0D=0A=0D=0A> I would think we (ecrit) would want t= o discourage 'remembering' the=0D=0A> authoritative server for the same rea= sons one should not 'remember'=0D=0ADNS=0D=0A> mappings.=0D=0A=0D=0AYou're = correct that it's not good to remember authoritative servers=20=0D=0Abecaus= e there's no standard refresh mechanism. However, it makes a lot=20=0D=0Ao= f sense to cache mappings (as the DNS does). A likely scenario is that=0D=0A=0D= =0Aan access network will have a local resolver that caches LoST mappings =0D= =0Ato cover its coverage area. (It can either cache as subscriber requests=0D= =0A=0D=0Acome through or scan the area itself to gather them.) This is OK:= The=20=0D=0Amappings have marked expirations so that the resolver knows wh= en to=20=0D=0Athrow them out.=0D=0A=0D=0ASo, just like the DNS caches name-= address mappings at various points,=20=0D=0Athere will probably be caching = in the mapping infrastructure -- it just=20=0D=0Amakes sense, given the exp= ected lifetime of mappings. The mapping=20=0D=0Aarchitecture allows for th= is; the expiry fields in LoST tell the server=20=0D=0Awhen to refresh.=0D=0A=0D= =0A--Richard=0D=0A=0D=0A=0D=0A_____________________________________________= __=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www1.ietf.org/m= ailman/listinfo/ecrit=0D=0A=0D=0A------------------------------------------= ------------------------------------------------------=0D=0AThis message is= for the designated recipient only and may=0D=0Acontain privileged, proprie= tary, or otherwise private information. =20=0D=0AIf you have received it in= error, please notify the sender=0D=0Aimmediately and delete the original. = Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A--------------= ---------------------------------------------------------------------------= -------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 12:26:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gX0-00013y-2w; Tue, 19 Jun 2007 12:26:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gWz-00013t-Ck for ecrit@ietf.org; Tue, 19 Jun 2007 12:26:13 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0gWy-0006iL-3v for ecrit@ietf.org; Tue, 19 Jun 2007 12:26:13 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 19 Jun 2007 12:26:12 -0400 X-IronPort-AV: i="4.16,439,1175486400"; d="scan'208"; a="124036036:sNHT46972108" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5JGQB5o010836; Tue, 19 Jun 2007 12:26:11 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5JGPgCC000303; Tue, 19 Jun 2007 16:26:11 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 12:26:07 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 12:26:07 -0400 From: "Marc Linsner" To: "'Dawson, Martin'" , "'ECRIT'" Subject: RE: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 12:26:06 -0400 Message-ID: <001401c7b28e$89d86970$220d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AceydUwKzy1FSY0XTXSPQ7fXT6X09AABl0+QAAIRhqAAAFbpsAABBu3A X-OriginalArrivalTime: 19 Jun 2007 16:26:07.0343 (UTC) FILETIME=[89FBCFF0:01C7B28E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1258; t=1182270371; x=1183134371; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20Architecture=20comparisons |Sender:=20 |To:=20=22'Dawson, =20Martin'=22=20, =20=22'ECRIT '=22=20; bh=8vY4jgxFTZMJjNgYsfIeejYtEQk2QioIDf8fZyKCp0Q=; b=hIvKSGAVIRrP5qTeLE7993Pxow8jCqATLCJ5wl4gLoRdomtG3q48nDuw8QSgmLX5TlagfWO7 OTGDe40Hc2TtIqaXVjeAVrQC3EU7G3EEhDAjimGKaWhz45gXQPzt11TH; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Martin, > " I'm still missing the tie between the access provider and > the authoritative LoST server." > > It's what Brian said - the ISP is "local" to the caller. Just > as a cellular network provider currently "knows" which PSAPs > are pertinent to their area of coverage (have to in order to > provide the dedicated trunks to the 911 tandem switches) so > too can any Internet access network provider offering service > in a particular geographic region. > I disagree that we can/should assume that ISPs are "local" to the caller. Yes, some are, but some are not. Many hot-spot/hotel networks are aggregated/managed from afar with no local knowledge. Should we propose these ISPs change their business model in order to support LoST queries (due to lack of a FG)? The IETF LoST architecture includes support for "all" access network providers and VSPs and should continue to do so. The FG is a key component to that architecture. We have acknowledged that we will work on variations to the architecture to support access providers that want/need to 'hide location' from the end-host/VSP. But I don't think we should sacrifice supporting current/selective Internet provider architectures in doing so. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 12:35:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gfs-0001q0-KV; Tue, 19 Jun 2007 12:35:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gfq-0001ml-Kq for ecrit@ietf.org; Tue, 19 Jun 2007 12:35:23 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0gfq-0003U7-Cv for ecrit@ietf.org; Tue, 19 Jun 2007 12:35:22 -0400 X-SEF-Processed: 5_0_0_910__2007_06_19_11_43_08 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 19 Jun 2007 11:43:08 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jun 2007 11:35:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 11:35:27 -0500 Message-ID: In-Reply-To: <001401c7b28e$89d86970$220d0d0a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Architecture comparisons Thread-Index: AceydUwKzy1FSY0XTXSPQ7fXT6X09AABl0+QAAIRhqAAAFbpsAABBu3AAAFuAqA= References: <001401c7b28e$89d86970$220d0d0a@amer.cisco.com> From: "Dawson, Martin" To: "Marc Linsner" , "ECRIT" X-OriginalArrivalTime: 19 Jun 2007 16:35:22.0079 (UTC) FILETIME=[D4A1CEF0:01C7B28F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Tsk... we've discussed on numerous occasions that the access provider is=0D= =0Aan amalgamation of the ISP and any intervening infrastructure provider.=0D= =0AThe necessary assets for both location determination and corresponding=0D= =0Alocal knowledge exist within that mix.=0D=0A=0D=0AI haven't heard of any= one delivering mass market Internet access via=0D=0Asubspace Ethernet yet, = so there is always a physical presence associated=0D=0Awith the provision o= f the access.=0D=0A=0D=0AYou can go ahead and talk about satellite Internet= access providers if=0D=0Ayou like. I'll grant you the corner case - they'l= l probably need a FG...=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Orig= inal Message-----=0D=0AFrom: Marc Linsner [mailto:mlinsner@cisco.com]=20=0D= =0ASent: Wednesday, 20 June 2007 2:26 AM=0D=0ATo: Dawson, Martin; 'ECRIT'=0D= =0ASubject: RE: [Ecrit] Architecture comparisons=0D=0A=0D=0AMartin,=0D=0A =0D= =0A> " I'm still missing the tie between the access provider and=20=0D=0A> = the authoritative LoST server."=0D=0A>=20=0D=0A> It's what Brian said - the= ISP is "local" to the caller. Just=20=0D=0A> as a cellular network provide= r currently "knows" which PSAPs=20=0D=0A> are pertinent to their area of co= verage (have to in order to=20=0D=0A> provide the dedicated trunks to the 9= 11 tandem switches) so=20=0D=0A> too can any Internet access network provid= er offering service=20=0D=0A> in a particular geographic region.=0D=0A>=20=0D= =0A=0D=0AI disagree that we can/should assume that ISPs are "local" to the=0D= =0Acaller.=0D=0AYes, some are, but some are not. Many hot-spot/hotel netwo= rks are=0D=0Aaggregated/managed from afar with no local knowledge. Should = we propose=0D=0Athese ISPs change their business model in order to support = LoST queries=0D=0A(due=0D=0Ato lack of a FG)=3F The IETF LoST architecture= includes support for "all"=0D=0Aaccess network providers and VSPs and shou= ld continue to do so. The FG=0D=0Ais a=0D=0Akey component to that architec= ture.=0D=0A=0D=0AWe have acknowledged that we will work on variations to th= e architecture=0D=0Ato=0D=0Asupport access providers that want/need to 'hid= e location' from the=0D=0Aend-host/VSP. But I don't think we should sacrif= ice supporting=0D=0Acurrent/selective Internet provider architectures in do= ing so.=0D=0A=0D=0A=0D=0A-Marc-=0D=0A=0D=0A=0D=0A--------------------------= ----------------------------------------------------------------------=0D=0A= This message is for the designated recipient only and may=0D=0Acontain priv= ileged, proprietary, or otherwise private information. =20=0D=0AIf you have= received it in error, please notify the sender=0D=0Aimmediately and delete= the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 13:08:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0hC2-0000tM-9W; Tue, 19 Jun 2007 13:08:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0hC1-0000rm-7e for ecrit@ietf.org; Tue, 19 Jun 2007 13:08:37 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0hBy-0008Hp-W1 for ecrit@ietf.org; Tue, 19 Jun 2007 13:08:37 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Jun 2007 13:08:35 -0400 X-IronPort-AV: i="4.16,439,1175486400"; d="scan'208"; a="63166445:sNHT44890076" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5JH8Y5j015012; Tue, 19 Jun 2007 13:08:34 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5JH8D6H008753; Tue, 19 Jun 2007 17:08:34 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 13:08:25 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 13:08:24 -0400 From: "Marc Linsner" To: "'Richard Barnes'" Subject: RE: FW: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 13:08:23 -0400 Message-ID: <002601c7b294$7243fa30$220d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <467800C8.6030009@bbn.com> Thread-Index: AceyjPBLIbyWc8J/RWOtAoJKe1euLgABO5Lg X-OriginalArrivalTime: 19 Jun 2007 17:08:24.0858 (UTC) FILETIME=[7275DFA0:01C7B294] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=911; t=1182272914; x=1183136914; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20FW=3A=20[Ecrit]=20Architecture=20comparisons |Sender:=20 |To:=20=22'Richard=20Barnes'=22=20; bh=OefywhJ6Bk0C0mjv1cImpQxnukU9L5l4dUg8eVEZ+gw=; b=G1fdi7pMAfmDsrLuerIipg0gSOaSMIKosr4XfEEJyiz90bnnQ/WPbGTbV9rReEI1OP/bbF8C iL2Xo72P3UThk1eRSE9/9R1MkpM0QOAm0WE0ERK3+9Y0PJicymNrDlt5; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Richard, > > The tie between the access provider and the authoritative > LoST server is the same as the tie between the access > provider and the selective router it uses to get to its PSAPs > -- they're both concerned with the same geographical area. And for non-telephony-offering access providers what is the tie? My point is that for as many access providers that offer LoST services, there will be just as many if not more that won't. Furthermore, if the access provider doesn't provide a LoST service because they don't care about any telephony-like service (nor 'location-hiding' since that is what drove this discussion), this leaves the end-host/VSP required to perform LoST queries. IMO, we, the IETF, cannot advocate an architecture that 'requires' access providers to perform/provide LoST services, hence the need for a FG such to support end-hosts/VSPs. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 13:15:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0hJ6-0006XT-FI; Tue, 19 Jun 2007 13:15:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0hJ5-0006XN-TS for ecrit@ietf.org; Tue, 19 Jun 2007 13:15:55 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0hJ5-0001QT-DB for ecrit@ietf.org; Tue, 19 Jun 2007 13:15:55 -0400 Received: from dhcp89-089-119.bbn.com ([128.89.89.119] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I0hJ5-0002IF-3S; Tue, 19 Jun 2007 13:15:55 -0400 Message-ID: <46780F4B.4050004@bbn.com> Date: Tue, 19 Jun 2007 13:15:55 -0400 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Architecture comparisons References: <004101c7b26e$49e1a5e0$220d0d0a@amer.cisco.com> <008001c7b28a$71ed5a40$640fa8c0@cis.neustar.com> <009301c7b28e$80c1e780$640fa8c0@cis.neustar.com> In-Reply-To: <009301c7b28e$80c1e780$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb Cc: "'Dawson, Martin'" , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I agree with Brian that NAT traversal and the possibility of a VPN tunnel from VSP to ESRP are good reasons to suggest (in phonebcp) that a UAC routes emergency calls through its outbound proxy. (We don't want emergency calls to fail unnecessarily just because someone is blocking outbound SIP on port 5060.) Additionally, providing a meaningful identity to the PSAP whenever possible is a good thing. I know that a subscriber identity with a VSP in Sierra Leone might not be meaningful to a PSAP in Kansas. However, iin most cases the VSP's subscriber information is a useful tool for PSAPs who wish to audit fraudulent calls. - Matt L. :-> Brian Rosen wrote: > > >Outbound routing is usually pretty tough. One example is NAT traversal for >media. Unless the UA does STUN/TURN, it's usually an SBC in the VSP that >fixes the media. Signaling outbound is sometimes a problem (outbound SIP on >port 5060 is often blocked). It has nothing nefarious; just the likelihood >of working, where special procedures only used for emergency calls may not >work. > >Also, we're expecting the VSPs to often have VPN connections to the ESRP, >rather than taking the calls from the Internet. Where there is QoS, we can >maintain it. We also get some DDoS protection. That won't work when you >nomad afar, but it does work for the normal case. > >Brian > > > >>-----Original Message----- >>From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] >>Sent: Tuesday, June 19, 2007 12:06 PM >>To: Brian Rosen; Henning Schulzrinne; Marc Linsner >>Cc: ECRIT >>Subject: RE: [Ecrit] Architecture comparisons >> >>Oh for pity's... that wasn't the spirit of my question. >> >>OK, how many PSAP URIs exist which will permit the location object or >>location reference to be delivered with the call? >> >>And doing PSTN bridging doesn't work in the US... that's i1 and it's not >>acceptable. It doesn't work in any other country where emergency calls >>are not carried on the PSTN. >> >>Why don't you think the BCP should recommend that a UA which knows it's >>doing an emergency call just route directly? What actual value does the >>VSP add, out of curiosity? Is this in order to enforce some sort of >>subscriber identity audit trail? I don't think that would work for >>foreign VSPs anyway; is it something that ECRIT has decided is a goal? >> >>Cheers, >>Martin >> >>-----Original Message----- >>From: Brian Rosen [mailto:br@brianrosen.net] >>Sent: Wednesday, 20 June 2007 1:57 AM >>To: Dawson, Martin; 'Henning Schulzrinne'; 'Marc Linsner' >>Cc: 'ECRIT' >>Subject: RE: [Ecrit] Architecture comparisons >> >>Actually, most of the world already has them, depending on how you >>define >>most. Most PSAPs are only reachable via e.164s, for which we have tel >>or >>sip URIs readily mintable. >> >>The forest guide IS the jurisdiction publishing its data. That's the >>purpose. There is no point in publishing it a different way. >> >>Please also remember that for most countries (excepting the U.S. and >>Canada) >>the entire LoST database is a couple of records. We'll probably have >>the >>LoST data way before we have the PSAPs on an IP network. It would >>actually >>be quite useful to publish the geo boundaries. >> >>There are very few VSPs which can be bypassed. UAs don't ever route >>direct. >>They send all outbound calls to their outbound proxy. That's the VSP's >>proxy. Even the free services (FWD for example) are done that way. We >>could try to have emergency calls not do that of course, but I think >>that's >>a very big change. -phonebcp doesn't say that. I don't think it >>should. >> >>Brian >> >> >> >>>-----Original Message----- >>>From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] >>>Sent: Tuesday, June 19, 2007 11:19 AM >>>To: Henning Schulzrinne; Marc Linsner >>>Cc: ECRIT >>>Subject: RE: [Ecrit] Architecture comparisons >>> >>>There's probably a reality check in order in this discussion as well. >>>I'd be interested in what opinions are out there. >>> >>>How many valid "PSAP URIs" exist anywhere in the world today? I'll >>> >>> >>take >> >> >>>a wild stab and suggest... zero. That's certainly approximately >>> >>> >>correct. >> >> >>>When any significant jurisdiction does IP enable their emergency call >>>centers (and aren't they likely to be doing it before "insignificant" >>>jurisdictions do?) I suspect it'll make the industry news. >>> >>>Just how fast is this likely to happen? Is it the case that it will >>>actually be reasonably straightforward to keep track of countries that >>>IP enable their emergency call centers as they emerge? And could this >>>not be the case to the extent that any suitably diligent party could >>>build a global database of PSAP URIs that was 95+ percent correct just >>>by monitoring the industry? Ideally, of course, each jurisdiction >>> >>> >>would >> >> >>>have an actual authority who would formally publish this information >>>(ideally publishing it into a forest guide infrastructure eventually, >>>though this wouldn't be necessary at the outset). >>> >>>Do people think it's more or less likely that UA's will actually just >>>universally route to the PSAP themselves rather than go via the VSP >>>anyway before any need for this global infrastructure emerges? Is >>> >>> >>there >> >> >>>any reason, in the long term, for devices to route via the VSP if the >>>PSAP is directly reachable? >>> >>>Cheers, >>>Martin >>> >>>-----Original Message----- >>>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>Sent: Wednesday, 20 June 2007 12:25 AM >>>To: Marc Linsner >>>Cc: ECRIT >>>Subject: Re: [Ecrit] Architecture comparisons >>> >>>I'll ad to the crystal ball gazing sessIon: >>> >>>I think the evolution will depend on who will be running LoST servers >>>and how data is distributed. One model is that the PSAP or other >>>government authorities will make data available, but LoST servers >>>will be run by private enterprises. Another is that these authorities >>>will run it themselves. The depth of the trees will presumably depend >>>on the level of federalism in the respective country, with some >>>countries, like France, presumably going national immediately, while >>>others, such as the United States and Germany, maybe starting bottom >>>up, with some progressive states going first. >>> >>>Regardless, as long as these trees make coverage information >>>available or such information can be derived, it's not too hard for >>>either a larger VSP or some third-party service company to aggregate >>>this information and offer a "private" FG. After all, the boundaries >>>of states and countries don't change all that often. In some >>>countries, the incumbent ISP will presumably try to make life >>>difficult for third-party VoIP customers until forced to by >>>regulators, so I wouldn't count on having "open" access to PSAP URIs >>>courtesy of the ISP, either, but we'll see. >>> >>>To echo what Brian said, the likelihood that we'll have Zimbabwe, >>>Taiwan and North Korea all happily in one FG run by the UN is >>>probably a ways off, just after the black helicopters have landed. >>>However, for most people, almost all the time, things will work, as >>>long as we have some good will. (For example, avoid decade-long legal >>>fights about data ownership.) >>> >>>Henning >>> >>>On Jun 19, 2007, at 8:35 AM, Marc Linsner wrote: >>> >>> >>> >>>>All, >>>> >>>>In my attempt to follow this thread, I've concluded that there is a >>>>belief >>>>the access provider will have information wrt LoST authoritative >>>>servers >>>>that VSPs won't have. >>>> >>>>Is my assumption correct? >>>> >>>>Is it not true that the architecture we've adopted depends on the >>>>forest >>>>guide to 'find' the authoritative LoST server? So, this raises the >>>>question, short of a working forest guide, how does the access >>>>provider find >>>>the authoritative LoST server and why can't the VSP use the same >>>> >>>> >>such >> >> >>>>mechanism? >>>> >>>>Just curious, >>>> >>>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >>> >>> >>------------------------------------------------------------------------ >>-- >> >> >>>---------------------- >>>This message is for the designated recipient only and may >>>contain privileged, proprietary, or otherwise private information. >>>If you have received it in error, please notify the sender >>>immediately and delete the original. Any unauthorized use of >>>this email is prohibited. >>> >>> >>> >>------------------------------------------------------------------------ >>-- >> >> >>>---------------------- >>>[mf2] >>> >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >>-------------------------------------------------------------------------- >>---------------------- >>This message is for the designated recipient only and may >>contain privileged, proprietary, or otherwise private information. >>If you have received it in error, please notify the sender >>immediately and delete the original. Any unauthorized use of >>this email is prohibited. >>-------------------------------------------------------------------------- >>---------------------- >>[mf2] >> >> > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 13:17:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0hKK-0007uk-UO; Tue, 19 Jun 2007 13:17:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0hKJ-0007uc-97 for ecrit@ietf.org; Tue, 19 Jun 2007 13:17:11 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0hKH-0002jZ-VZ for ecrit@ietf.org; Tue, 19 Jun 2007 13:17:11 -0400 X-SEF-Processed: 5_0_0_910__2007_06_19_12_24_56 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 19 Jun 2007 12:24:56 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jun 2007 12:17:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 12:17:00 -0500 Message-ID: In-Reply-To: <002601c7b294$7243fa30$220d0d0a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: [Ecrit] Architecture comparisons Thread-Index: AceyjPBLIbyWc8J/RWOtAoJKe1euLgABO5LgAADC0ZA= References: <467800C8.6030009@bbn.com> <002601c7b294$7243fa30$220d0d0a@amer.cisco.com> From: "Dawson, Martin" To: "Marc Linsner" , "Richard Barnes" X-OriginalArrivalTime: 19 Jun 2007 17:17:09.0595 (UTC) FILETIME=[AB3A62B0:01C7B295] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org So who are we going to force to provide the FG=3F=0D=0A=0D=0AIn the mean ti= me, since LoST already includes local discovery mechanisms=0D=0Avia DNS, ho= w much has actually been forced on the ISP=3F All we've said is=0D=0Athat t= he LIS operator can discover and query the LoST server. Some=0D=0Apeople ha= ve suggested that one possible implementation model is that=0D=0AISPs actua= lly implement the LoST infrastructure - but I don't think=0D=0Athat's been = stated as an imperative.=0D=0A=0D=0AAnswer the first question and I might a= gree that taking care of as much=0D=0Aas possible at the local level isn't = necessarily the only safe starting=0D=0Apoint.=0D=0A=0D=0ACheers,=0D=0AMart= in=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Marc Linsner [mailto:ml= insner@cisco.com]=20=0D=0ASent: Wednesday, 20 June 2007 3:08 AM=0D=0ATo: 'R= ichard Barnes'=0D=0ACc: 'ECRIT'=0D=0ASubject: RE: FW: [Ecrit] Architecture = comparisons=0D=0A=0D=0ARichard,=20=0D=0A=0D=0A>=20=0D=0A> The tie between t= he access provider and the authoritative=20=0D=0A> LoST server is the same = as the tie between the access=20=0D=0A> provider and the selective router i= t uses to get to its PSAPs=20=0D=0A> -- they're both concerned with the sam= e geographical area.=0D=0A=0D=0AAnd for non-telephony-offering access provi= ders what is the tie=3F=0D=0A=0D=0AMy point is that for as many access prov= iders that offer LoST services,=0D=0Athere will be just as many if not more= that won't. Furthermore, if the=0D=0Aaccess provider doesn't provide a Lo= ST service because they don't care=0D=0Aabout=0D=0Aany telephony-like servi= ce (nor 'location-hiding' since that is what=0D=0Adrove=0D=0Athis discussio= n), this leaves the end-host/VSP required to perform LoST=0D=0Aqueries. IM= O, we, the IETF, cannot advocate an architecture that=0D=0A'requires'=0D=0A= access providers to perform/provide LoST services, hence the need for a=0D=0A= FG=0D=0Asuch to support end-hosts/VSPs.=0D=0A=0D=0A-Marc-=20=0D=0A=0D=0A =0D= =0A=0D=0A_______________________________________________=0D=0AEcrit mailing= list=0D=0AEcrit@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/listinfo/ecrit=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 13:28:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0hVh-0001Jz-F0; Tue, 19 Jun 2007 13:28:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0hVg-0001IB-It for ecrit@ietf.org; Tue, 19 Jun 2007 13:28:56 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0hVf-0005RU-N2 for ecrit@ietf.org; Tue, 19 Jun 2007 13:28:56 -0400 X-SEF-Processed: 5_0_0_910__2007_06_19_12_36_42 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 19 Jun 2007 12:36:42 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jun 2007 12:28:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 12:28:43 -0500 Message-ID: In-Reply-To: <009301c7b28e$80c1e780$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Architecture comparisons Thread-Index: AceyfbTM2g2gpFGSTOOcoIa34qe4sQABWYsgAAGN1AAAAFoqgAAAgH8gAADIP1A= References: <004101c7b26e$49e1a5e0$220d0d0a@amer.cisco.com> <008001c7b28a$71ed5a40$640fa8c0@cis.neustar.com> <009301c7b28e$80c1e780$640fa8c0@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , "Henning Schulzrinne" , "Marc Linsner" X-OriginalArrivalTime: 19 Jun 2007 17:28:55.0272 (UTC) FILETIME=[4FD82680:01C7B297] X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I find a number of assumptions in your response surprising and/or=0D=0Apuzz= ling... I think a lot must be to do with me not appreciating the=0D=0Ainher= ited of developing wisdom about how VoIP will be provided.=0D=0A=0D=0AThe i= 2 architecture was defined to support the out of band delivery of=0D=0Aloca= tion information when calls have to be terminated on legacy switch=0D=0Acir= cuits. However, there's no such thing as a "PSAP URI" in the sense of=0D=0A= something that a UA would ever see in that architecture. Yes, you could=0D=0A= provide the i2 proxy function as a PSAP service - which would=0D=0Aeffectiv= ely turn the PSAP into an IP one. However, that's the thing=0D=0Aisn't it=3F= How many PSAPs have actually done that - and how long will it=0D=0Atake=3F= Without that the UA never sees any such thing as a PSAP URI, which=0D=0Ais= why it does rely on the VSP to do the routing and for the VSP to=0D=0Aensu= re that location is properly delivered care of a VPC.=0D=0A=0D=0AYour expla= nation of why you'd have to call via the VSP versus direct=0D=0Asounds quit= e complicated. I use a SIP provider for my residential VoIP -=0D=0Athey are= an Australian VSP but they have no relationship with my ISP. I=0D=0Adon't = know how my ISP could possibly tell the difference between a call=0D=0Ainit= iated through my VSP or one to a SIP server operated by emergency=0D=0Aserv= ices... my ATA does STUN anyway.=0D=0A=0D=0AThe situation you describe soun= ds very much like a VSP which is closely=0D=0Atied to the access provider w= ith a proxy co-located with the access=0D=0A(otherwise the call does go ove= r the Internet before the VSP even sees=0D=0Ait right=3F And otherwise how = can SIP be blocked for everyone else=3F). This=0D=0Aends up being so close = to the 3GPP model as makes no odds. I find these=0D=0Apuzzling assumptions = on which to make value judgements about the best=0D=0Away forward. It seems= to assume a very conservative model about VoIP=0D=0Aservices. And I really= don't know what would qualify as "far" when it=0D=0Acomes to nomad'ing (wh= en did that become a verb=3F).=20=0D=0A=0D=0ASurely taking my PDA/VoIP-clie= nt across town or across the state is=0D=0Agoing to eliminate the cozy rela= tionship my VSP may have had with my=0D=0Anominal "home" location. In fact = I just have to switch from my preferred=0D=0Ahome DSL provider to my prefer= red WiMAX provider when I step out of the=0D=0Adoor to change who my ISP is= =2E If the answer is that the VSP has to have=0D=0Aa proxy in the WiMAX acc= ess as well, then I smile wryly to myself at the=0D=0Airony - given VoIP wa= s supposed to dismantle all the established power=0D=0Astructures associate= d with telephony services. I think I'll stick with=0D=0ASkype... (isn't it = VoIP too=3F)=0D=0A=0D=0AI'm mostly asking all this for my own illumination,= but perhaps others=0D=0Awill find the information useful as well.=0D=0A=0D= =0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Bri= an Rosen [mailto:br@brianrosen.net]=20=0D=0ASent: Wednesday, 20 June 2007 2= :26 AM=0D=0ATo: Dawson, Martin; 'Henning Schulzrinne'; 'Marc Linsner'=0D=0A= Cc: 'ECRIT'=0D=0ASubject: RE: [Ecrit] Architecture comparisons=0D=0A=0D=0AB= ut the point is that if the e.164 is in the database, the right thing=0D=0A= happens if the PSAP is only reachable by the PSTN. They don't get=0D=0Aadd= resses=0D=0Afrom the endpoint (if they get them at all, it's an internal ph= one=0D=0Abook). A=0D=0AVoIP endpoint conformant to phonebcp would be able = to successfully=0D=0Acomplete=0D=0Aan emergency call to such a PSAP if the = data is put in a LoST server it=0D=0Acan=0D=0Aget to. =20=0D=0A=0D=0ARealis= tically, it would be very possible to make most VSP systems=0D=0Acorrectly=0D= =0Ahandle 3 digit emergency calls, albeit nomadic users wouldn't have=0D=0A= correct=0D=0Alocation. The VSP would have to route a call to the right 3 d= igit=0D=0Agateway.=0D=0AA U.S. "i2" solution, but if you nomaded to the U.K= =2E, we could get the=0D=0Aright=0D=0Athing to happen there (probably have = to use their mobile location=0D=0Astuff).=0D=0AI'm not seriously suggesting= it, just noting that if you had the correct=0D=0Aboundary data, and intern= al route infrastructure, the whole mechanism=0D=0Acan be=0D=0Amade to work = pretty well without putting PSAPs on IP networks.=0D=0A=0D=0AOutbound routi= ng is usually pretty tough. One example is NAT traversal=0D=0Afor=0D=0Amed= ia. Unless the UA does STUN/TURN, it's usually an SBC in the VSP=0D=0Athat=0D= =0Afixes the media. Signaling outbound is sometimes a problem (outbound=0D= =0ASIP on=0D=0Aport 5060 is often blocked). It has nothing nefarious; just= the=0D=0Alikelihood=0D=0Aof working, where special procedures only used fo= r emergency calls may=0D=0Anot=0D=0Awork. =20=0D=0A=0D=0AAlso, we're expect= ing the VSPs to often have VPN connections to the=0D=0AESRP,=0D=0Arather th= an taking the calls from the Internet. Where there is QoS, we=0D=0Acan=0D=0A= maintain it. We also get some DDoS protection. That won't work when=0D=0A= you=0D=0Anomad afar, but it does work for the normal case.=0D=0A=0D=0ABrian=0D= =0A=0D=0A> -----Original Message-----=0D=0A> From: Dawson, Martin [mailto:M= artin.Dawson@andrew.com]=0D=0A> Sent: Tuesday, June 19, 2007 12:06 PM=0D=0A= > To: Brian Rosen; Henning Schulzrinne; Marc Linsner=0D=0A> Cc: ECRIT=0D=0A= > Subject: RE: [Ecrit] Architecture comparisons=0D=0A>=20=0D=0A> Oh for pit= y's... that wasn't the spirit of my question.=0D=0A>=20=0D=0A> OK, how many= PSAP URIs exist which will permit the location object or=0D=0A> location r= eference to be delivered with the call=3F=0D=0A>=20=0D=0A> And doing PSTN b= ridging doesn't work in the US... that's i1 and it's=0D=0Anot=0D=0A> accept= able. It doesn't work in any other country where emergency calls=0D=0A> are= not carried on the PSTN.=0D=0A>=20=0D=0A> Why don't you think the BCP shou= ld recommend that a UA which knows=0D=0Ait's=0D=0A> doing an emergency call= just route directly=3F What actual value does=0D=0Athe=0D=0A> VSP add, out= of curiosity=3F Is this in order to enforce some sort of=0D=0A> subscriber= identity audit trail=3F I don't think that would work for=0D=0A> foreign V= SPs anyway; is it something that ECRIT has decided is a goal=3F=0D=0A>=20=0D= =0A> Cheers,=0D=0A> Martin=0D=0A>=20=0D=0A> -----Original Message-----=0D=0A= > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> Sent: Wednesday, 20 J= une 2007 1:57 AM=0D=0A> To: Dawson, Martin; 'Henning Schulzrinne'; 'Marc Li= nsner'=0D=0A> Cc: 'ECRIT'=0D=0A> Subject: RE: [Ecrit] Architecture comparis= ons=0D=0A>=20=0D=0A> Actually, most of the world already has them, dependin= g on how you=0D=0A> define=0D=0A> most. Most PSAPs are only reachable via = e.164s, for which we have tel=0D=0A> or=0D=0A> sip URIs readily mintable.=0D= =0A>=20=0D=0A> The forest guide IS the jurisdiction publishing its data. T= hat's the=0D=0A> purpose. There is no point in publishing it a different w= ay.=0D=0A>=20=0D=0A> Please also remember that for most countries (exceptin= g the U.S. and=0D=0A> Canada)=0D=0A> the entire LoST database is a couple o= f records. We'll probably have=0D=0A> the=0D=0A> LoST data way before we h= ave the PSAPs on an IP network. It would=0D=0A> actually=0D=0A> be quite u= seful to publish the geo boundaries.=0D=0A>=20=0D=0A> There are very few VS= Ps which can be bypassed. UAs don't ever route=0D=0A> direct.=0D=0A> They = send all outbound calls to their outbound proxy. That's the=0D=0AVSP's=0D=0A= > proxy. Even the free services (FWD for example) are done that way.=0D=0A= We=0D=0A> could try to have emergency calls not do that of course, but I th= ink=0D=0A> that's=0D=0A> a very big change. -phonebcp doesn't say that. I= don't think it=0D=0A> should.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A> > --= ---Original Message-----=0D=0A> > From: Dawson, Martin [mailto:Martin.Dawso= n@andrew.com]=0D=0A> > Sent: Tuesday, June 19, 2007 11:19 AM=0D=0A> > To: H= enning Schulzrinne; Marc Linsner=0D=0A> > Cc: ECRIT=0D=0A> > Subject: RE: [= Ecrit] Architecture comparisons=0D=0A> >=0D=0A> > There's probably a realit= y check in order in this discussion as=0D=0Awell.=0D=0A> > I'd be intereste= d in what opinions are out there.=0D=0A> >=0D=0A> > How many valid "PSAP UR= Is" exist anywhere in the world today=3F I'll=0D=0A> take=0D=0A> > a wild s= tab and suggest... zero. That's certainly approximately=0D=0A> correct.=0D=0A= > >=0D=0A> > When any significant jurisdiction does IP enable their emergen= cy=0D=0Acall=0D=0A> > centers (and aren't they likely to be doing it before=0D= =0A"insignificant"=0D=0A> > jurisdictions do=3F) I suspect it'll make the i= ndustry news.=0D=0A> >=0D=0A> > Just how fast is this likely to happen=3F I= s it the case that it will=0D=0A> > actually be reasonably straightforward = to keep track of countries=0D=0Athat=0D=0A> > IP enable their emergency cal= l centers as they emerge=3F And could=0D=0Athis=0D=0A> > not be the case to= the extent that any suitably diligent party could=0D=0A> > build a global = database of PSAP URIs that was 95+ percent correct=0D=0Ajust=0D=0A> > by mo= nitoring the industry=3F Ideally, of course, each jurisdiction=0D=0A> would=0D= =0A> > have an actual authority who would formally publish this information=0D= =0A> > (ideally publishing it into a forest guide infrastructure=0D=0Aevent= ually,=0D=0A> > though this wouldn't be necessary at the outset).=0D=0A> >=0D= =0A> > Do people think it's more or less likely that UA's will actually=0D=0A= just=0D=0A> > universally route to the PSAP themselves rather than go via t= he VSP=0D=0A> > anyway before any need for this global infrastructure emerg= es=3F Is=0D=0A> there=0D=0A> > any reason, in the long term, for devices to= route via the VSP if=0D=0Athe=0D=0A> > PSAP is directly reachable=3F=0D=0A= > >=0D=0A> > Cheers,=0D=0A> > Martin=0D=0A> >=0D=0A> > -----Original Messag= e-----=0D=0A> > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A= > > Sent: Wednesday, 20 June 2007 12:25 AM=0D=0A> > To: Marc Linsner=0D=0A>= > Cc: ECRIT=0D=0A> > Subject: Re: [Ecrit] Architecture comparisons=0D=0A> = >=0D=0A> > I'll ad to the crystal ball gazing sessIon:=0D=0A> >=0D=0A> > I = think the evolution will depend on who will be running LoST=0D=0Aservers=0D= =0A> > and how data is distributed. One model is that the PSAP or other=0D=0A= > > government authorities will make data available, but LoST servers=0D=0A= > > will be run by private enterprises. Another is that these=0D=0Aauthorit= ies=0D=0A> > will run it themselves. The depth of the trees will presumably=0D= =0Adepend=0D=0A> > on the level of federalism in the respective country, wi= th some=0D=0A> > countries, like France, presumably going national immediat= ely, while=0D=0A> > others, such as the United States and Germany, maybe st= arting bottom=0D=0A> > up, with some progressive states going first.=0D=0A>= >=0D=0A> > Regardless, as long as these trees make coverage information=0D= =0A> > available or such information can be derived, it's not too hard for=0D= =0A> > either a larger VSP or some third-party service company to aggregate=0D= =0A> > this information and offer a "private" FG. After all, the boundaries=0D= =0A> > of states and countries don't change all that often. In some=0D=0A> = > countries, the incumbent ISP will presumably try to make life=0D=0A> > di= fficult for third-party VoIP customers until forced to by=0D=0A> > regulato= rs, so I wouldn't count on having "open" access to PSAP URIs=0D=0A> > court= esy of the ISP, either, but we'll see.=0D=0A> >=0D=0A> > To echo what Brian= said, the likelihood that we'll have Zimbabwe,=0D=0A> > Taiwan and North K= orea all happily in one FG run by the UN is=0D=0A> > probably a ways off, j= ust after the black helicopters have landed.=0D=0A> > However, for most peo= ple, almost all the time, things will work, as=0D=0A> > long as we have som= e good will. (For example, avoid decade-long=0D=0Alegal=0D=0A> > fights abo= ut data ownership.)=0D=0A> >=0D=0A> > Henning=0D=0A> >=0D=0A> > On Jun 19, = 2007, at 8:35 AM, Marc Linsner wrote:=0D=0A> >=0D=0A> > > All,=0D=0A> > >=0D= =0A> > > In my attempt to follow this thread, I've concluded that there is=0D= =0Aa=0D=0A> > > belief=0D=0A> > > the access provider will have information= wrt LoST authoritative=0D=0A> > > servers=0D=0A> > > that VSPs won't have.=0D= =0A> > >=0D=0A> > > Is my assumption correct=3F=0D=0A> > >=0D=0A> > > Is it= not true that the architecture we've adopted depends on the=0D=0A> > > for= est=0D=0A> > > guide to 'find' the authoritative LoST server=3F So, this r= aises=0D=0Athe=0D=0A> > > question, short of a working forest guide, how do= es the access=0D=0A> > > provider find=0D=0A> > > the authoritative LoST se= rver and why can't the VSP use the same=0D=0A> such=0D=0A> > > mechanism=3F=0D= =0A> > >=0D=0A> > > Just curious,=0D=0A> >=0D=0A> >=0D=0A> > ______________= _________________________________=0D=0A> > Ecrit mailing list=0D=0A> > Ecri= t@ietf.org=0D=0A> > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> >=0D= =0A> >=0D=0A>=0D=0A--------------------------------------------------------= ----------------=0D=0A> --=0D=0A> > ----------------------=0D=0A> > This me= ssage is for the designated recipient only and may=0D=0A> > contain privile= ged, proprietary, or otherwise private information.=0D=0A> > If you have re= ceived it in error, please notify the sender=0D=0A> > immediately and delet= e the original. Any unauthorized use of=0D=0A> > this email is prohibited.=0D= =0A> >=0D=0A>=0D=0A--------------------------------------------------------= ----------------=0D=0A> --=0D=0A> > ----------------------=0D=0A> > [mf2]=0D= =0A> >=0D=0A> >=0D=0A> > _______________________________________________=0D= =0A> > Ecrit mailing list=0D=0A> > Ecrit@ietf.org=0D=0A> > https://www1.iet= f.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A>=20=0D=0A>=0D=0A--------------= ----------------------------------------------------------=0D=0A--=0D=0A> -= ---------------------=0D=0A> This message is for the designated recipient o= nly and may=0D=0A> contain privileged, proprietary, or otherwise private in= formation.=0D=0A> If you have received it in error, please notify the sende= r=0D=0A> immediately and delete the original. Any unauthorized use of=0D=0A= > this email is prohibited.=0D=0A>=0D=0A-----------------------------------= -------------------------------------=0D=0A--=0D=0A> ----------------------=0D= =0A> [mf2]=0D=0A=0D=0A=0D=0A-----------------------------------------------= -------------------------------------------------=0D=0AThis message is for = the designated recipient only and may=0D=0Acontain privileged, proprietary,= or otherwise private information. =20=0D=0AIf you have received it in erro= r, please notify the sender=0D=0Aimmediately and delete the original. Any = unauthorized use of=0D=0Athis email is prohibited.=0D=0A-------------------= ---------------------------------------------------------------------------= --=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 13:57:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0hx3-0007YO-BV; Tue, 19 Jun 2007 13:57:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0hx1-0007Xw-RY for ecrit@ietf.org; Tue, 19 Jun 2007 13:57:11 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0hx1-0002qy-4U for ecrit@ietf.org; Tue, 19 Jun 2007 13:57:11 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I0hwt-0002fo-Fw; Tue, 19 Jun 2007 12:57:04 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Henning Schulzrinne'" , "'Marc Linsner'" References: <004101c7b26e$49e1a5e0$220d0d0a@amer.cisco.com> <008001c7b28a$71ed5a40$640fa8c0@cis.neustar.com> <009301c7b28e$80c1e780$640fa8c0@cis.neustar.com> Subject: RE: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 13:57:06 -0400 Message-ID: <00ac01c7b29b$42147360$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AceyfbTM2g2gpFGSTOOcoIa34qe4sQABWYsgAAGN1AAAAFoqgAAAgH8gAADIP1AAAi8IcA== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I2 makes this silly assumption that ALL calls go to a U.S. PSAP. Clearly not true. You could filter out 9-1-1 and route to a VPC (the i2 emergency call processor). You could also just use the whole ecrit mechanism and put the URI of your VPC in the LoST service (really, a generic US VPC URI, which you resolve to a specific one). The point being you could have something different that would make 999 in London work, and 116 in France, etc. Clearly we WILL do this. It will be part of the transition from i2 to i3. If you have a phonebcp compliant client on a system that only supports i2, we'll make it work. My ATA is configured to use an outbound proxy. Don't know about yours. My ATA doesn't do STUN. The "normal" way we expect the Next Generation 9-1-1 system to work (to use the U.S. and hopefully Canada as an example), is that the VSP will maintain VPN connections to ESRPs operated by the 9-1-1 authorities, probably at the state level. A normal call from a high volume VSP when the caller is "home" will go through that path. If there is a nomadic caller, operating outside the area the VSP normally serves a lot of customers, then the call will route over the Internet. The routing is simply by PSAP URI. The route will either take the tunnel or not based on the IP address with normal IP routing. If the tunnel fails, the Internet should work. It has nothing to do with the ISP. You can change the ISP and it still works. Of course QoS may depend on the ISP, but we're only being opportunistic about that. If QoS is available, we'd like it on the tunnel. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Tuesday, June 19, 2007 1:29 PM > To: Brian Rosen; Henning Schulzrinne; Marc Linsner > Cc: ECRIT > Subject: RE: [Ecrit] Architecture comparisons > > I find a number of assumptions in your response surprising and/or > puzzling... I think a lot must be to do with me not appreciating the > inherited of developing wisdom about how VoIP will be provided. > > The i2 architecture was defined to support the out of band delivery of > location information when calls have to be terminated on legacy switch > circuits. However, there's no such thing as a "PSAP URI" in the sense of > something that a UA would ever see in that architecture. Yes, you could > provide the i2 proxy function as a PSAP service - which would > effectively turn the PSAP into an IP one. However, that's the thing > isn't it? How many PSAPs have actually done that - and how long will it > take? Without that the UA never sees any such thing as a PSAP URI, which > is why it does rely on the VSP to do the routing and for the VSP to > ensure that location is properly delivered care of a VPC. > > Your explanation of why you'd have to call via the VSP versus direct > sounds quite complicated. I use a SIP provider for my residential VoIP - > they are an Australian VSP but they have no relationship with my ISP. I > don't know how my ISP could possibly tell the difference between a call > initiated through my VSP or one to a SIP server operated by emergency > services... my ATA does STUN anyway. > > The situation you describe sounds very much like a VSP which is closely > tied to the access provider with a proxy co-located with the access > (otherwise the call does go over the Internet before the VSP even sees > it right? And otherwise how can SIP be blocked for everyone else?). This > ends up being so close to the 3GPP model as makes no odds. I find these > puzzling assumptions on which to make value judgements about the best > way forward. It seems to assume a very conservative model about VoIP > services. And I really don't know what would qualify as "far" when it > comes to nomad'ing (when did that become a verb?). > > Surely taking my PDA/VoIP-client across town or across the state is > going to eliminate the cozy relationship my VSP may have had with my > nominal "home" location. In fact I just have to switch from my preferred > home DSL provider to my preferred WiMAX provider when I step out of the > door to change who my ISP is. If the answer is that the VSP has to have > a proxy in the WiMAX access as well, then I smile wryly to myself at the > irony - given VoIP was supposed to dismantle all the established power > structures associated with telephony services. I think I'll stick with > Skype... (isn't it VoIP too?) > > I'm mostly asking all this for my own illumination, but perhaps others > will find the information useful as well. > > Cheers, > Martin > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, 20 June 2007 2:26 AM > To: Dawson, Martin; 'Henning Schulzrinne'; 'Marc Linsner' > Cc: 'ECRIT' > Subject: RE: [Ecrit] Architecture comparisons > > But the point is that if the e.164 is in the database, the right thing > happens if the PSAP is only reachable by the PSTN. They don't get > addresses > from the endpoint (if they get them at all, it's an internal phone > book). A > VoIP endpoint conformant to phonebcp would be able to successfully > complete > an emergency call to such a PSAP if the data is put in a LoST server it > can > get to. > > Realistically, it would be very possible to make most VSP systems > correctly > handle 3 digit emergency calls, albeit nomadic users wouldn't have > correct > location. The VSP would have to route a call to the right 3 digit > gateway. > A U.S. "i2" solution, but if you nomaded to the U.K., we could get the > right > thing to happen there (probably have to use their mobile location > stuff). > I'm not seriously suggesting it, just noting that if you had the correct > boundary data, and internal route infrastructure, the whole mechanism > can be > made to work pretty well without putting PSAPs on IP networks. > > Outbound routing is usually pretty tough. One example is NAT traversal > for > media. Unless the UA does STUN/TURN, it's usually an SBC in the VSP > that > fixes the media. Signaling outbound is sometimes a problem (outbound > SIP on > port 5060 is often blocked). It has nothing nefarious; just the > likelihood > of working, where special procedures only used for emergency calls may > not > work. > > Also, we're expecting the VSPs to often have VPN connections to the > ESRP, > rather than taking the calls from the Internet. Where there is QoS, we > can > maintain it. We also get some DDoS protection. That won't work when > you > nomad afar, but it does work for the normal case. > > Brian > > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: Tuesday, June 19, 2007 12:06 PM > > To: Brian Rosen; Henning Schulzrinne; Marc Linsner > > Cc: ECRIT > > Subject: RE: [Ecrit] Architecture comparisons > > > > Oh for pity's... that wasn't the spirit of my question. > > > > OK, how many PSAP URIs exist which will permit the location object or > > location reference to be delivered with the call? > > > > And doing PSTN bridging doesn't work in the US... that's i1 and it's > not > > acceptable. It doesn't work in any other country where emergency calls > > are not carried on the PSTN. > > > > Why don't you think the BCP should recommend that a UA which knows > it's > > doing an emergency call just route directly? What actual value does > the > > VSP add, out of curiosity? Is this in order to enforce some sort of > > subscriber identity audit trail? I don't think that would work for > > foreign VSPs anyway; is it something that ECRIT has decided is a goal? > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, 20 June 2007 1:57 AM > > To: Dawson, Martin; 'Henning Schulzrinne'; 'Marc Linsner' > > Cc: 'ECRIT' > > Subject: RE: [Ecrit] Architecture comparisons > > > > Actually, most of the world already has them, depending on how you > > define > > most. Most PSAPs are only reachable via e.164s, for which we have tel > > or > > sip URIs readily mintable. > > > > The forest guide IS the jurisdiction publishing its data. That's the > > purpose. There is no point in publishing it a different way. > > > > Please also remember that for most countries (excepting the U.S. and > > Canada) > > the entire LoST database is a couple of records. We'll probably have > > the > > LoST data way before we have the PSAPs on an IP network. It would > > actually > > be quite useful to publish the geo boundaries. > > > > There are very few VSPs which can be bypassed. UAs don't ever route > > direct. > > They send all outbound calls to their outbound proxy. That's the > VSP's > > proxy. Even the free services (FWD for example) are done that way. > We > > could try to have emergency calls not do that of course, but I think > > that's > > a very big change. -phonebcp doesn't say that. I don't think it > > should. > > > > Brian > > > > > -----Original Message----- > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > Sent: Tuesday, June 19, 2007 11:19 AM > > > To: Henning Schulzrinne; Marc Linsner > > > Cc: ECRIT > > > Subject: RE: [Ecrit] Architecture comparisons > > > > > > There's probably a reality check in order in this discussion as > well. > > > I'd be interested in what opinions are out there. > > > > > > How many valid "PSAP URIs" exist anywhere in the world today? I'll > > take > > > a wild stab and suggest... zero. That's certainly approximately > > correct. > > > > > > When any significant jurisdiction does IP enable their emergency > call > > > centers (and aren't they likely to be doing it before > "insignificant" > > > jurisdictions do?) I suspect it'll make the industry news. > > > > > > Just how fast is this likely to happen? Is it the case that it will > > > actually be reasonably straightforward to keep track of countries > that > > > IP enable their emergency call centers as they emerge? And could > this > > > not be the case to the extent that any suitably diligent party could > > > build a global database of PSAP URIs that was 95+ percent correct > just > > > by monitoring the industry? Ideally, of course, each jurisdiction > > would > > > have an actual authority who would formally publish this information > > > (ideally publishing it into a forest guide infrastructure > eventually, > > > though this wouldn't be necessary at the outset). > > > > > > Do people think it's more or less likely that UA's will actually > just > > > universally route to the PSAP themselves rather than go via the VSP > > > anyway before any need for this global infrastructure emerges? Is > > there > > > any reason, in the long term, for devices to route via the VSP if > the > > > PSAP is directly reachable? > > > > > > Cheers, > > > Martin > > > > > > -----Original Message----- > > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > > Sent: Wednesday, 20 June 2007 12:25 AM > > > To: Marc Linsner > > > Cc: ECRIT > > > Subject: Re: [Ecrit] Architecture comparisons > > > > > > I'll ad to the crystal ball gazing sessIon: > > > > > > I think the evolution will depend on who will be running LoST > servers > > > and how data is distributed. One model is that the PSAP or other > > > government authorities will make data available, but LoST servers > > > will be run by private enterprises. Another is that these > authorities > > > will run it themselves. The depth of the trees will presumably > depend > > > on the level of federalism in the respective country, with some > > > countries, like France, presumably going national immediately, while > > > others, such as the United States and Germany, maybe starting bottom > > > up, with some progressive states going first. > > > > > > Regardless, as long as these trees make coverage information > > > available or such information can be derived, it's not too hard for > > > either a larger VSP or some third-party service company to aggregate > > > this information and offer a "private" FG. After all, the boundaries > > > of states and countries don't change all that often. In some > > > countries, the incumbent ISP will presumably try to make life > > > difficult for third-party VoIP customers until forced to by > > > regulators, so I wouldn't count on having "open" access to PSAP URIs > > > courtesy of the ISP, either, but we'll see. > > > > > > To echo what Brian said, the likelihood that we'll have Zimbabwe, > > > Taiwan and North Korea all happily in one FG run by the UN is > > > probably a ways off, just after the black helicopters have landed. > > > However, for most people, almost all the time, things will work, as > > > long as we have some good will. (For example, avoid decade-long > legal > > > fights about data ownership.) > > > > > > Henning > > > > > > On Jun 19, 2007, at 8:35 AM, Marc Linsner wrote: > > > > > > > All, > > > > > > > > In my attempt to follow this thread, I've concluded that there is > a > > > > belief > > > > the access provider will have information wrt LoST authoritative > > > > servers > > > > that VSPs won't have. > > > > > > > > Is my assumption correct? > > > > > > > > Is it not true that the architecture we've adopted depends on the > > > > forest > > > > guide to 'find' the authoritative LoST server? So, this raises > the > > > > question, short of a working forest guide, how does the access > > > > provider find > > > > the authoritative LoST server and why can't the VSP use the same > > such > > > > mechanism? > > > > > > > > Just curious, > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > > > > ------------------------------------------------------------------------ > > -- > > > ---------------------- > > > [mf2] > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > > ------------------------------------------------------------------------ > -- > > ---------------------- > > [mf2] > > > -------------------------------------------------------------------------- > ---------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------------------- > ---------------------- > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 14:04:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0i4R-000234-S7; Tue, 19 Jun 2007 14:04:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0i4Q-00022w-RB for ecrit@ietf.org; Tue, 19 Jun 2007 14:04:50 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0i4P-0005d1-92 for ecrit@ietf.org; Tue, 19 Jun 2007 14:04:50 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I0i4O-0002zu-64; Tue, 19 Jun 2007 14:04:49 -0400 Message-ID: <46781AC1.1070504@bbn.com> Date: Tue, 19 Jun 2007 14:04:49 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Marc Linsner Subject: Re: FW: [Ecrit] Architecture comparisons References: <002601c7b294$7243fa30$220d0d0a@amer.cisco.com> In-Reply-To: <002601c7b294$7243fa30$220d0d0a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Marc, We're in violent agreement. I was just suggesting that such caching/hard-wiring might reasonably be done as an optimization, or as a stop-gap until FGs are deployed. I certainly agree that the approach of mapping-arch is the correct one. (Incidentally, this doesn't have much to do with whether the access provider "offers telephony" -- any IP network offers it de facto as long as they allow SIP and RTP. Ultimately, I expect that there will be regulation as to who exactly has to care about emergency services, including who has to run LoST services.) --RB Marc Linsner wrote: > Richard, > >> The tie between the access provider and the authoritative >> LoST server is the same as the tie between the access >> provider and the selective router it uses to get to its PSAPs >> -- they're both concerned with the same geographical area. > > And for non-telephony-offering access providers what is the tie? > > My point is that for as many access providers that offer LoST services, > there will be just as many if not more that won't. Furthermore, if the > access provider doesn't provide a LoST service because they don't care about > any telephony-like service (nor 'location-hiding' since that is what drove > this discussion), this leaves the end-host/VSP required to perform LoST > queries. IMO, we, the IETF, cannot advocate an architecture that 'requires' > access providers to perform/provide LoST services, hence the need for a FG > such to support end-hosts/VSPs. > > -Marc- > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 14:38:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ib1-0004n1-FM; Tue, 19 Jun 2007 14:38:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0iaz-0004mn-Lp for ecrit@ietf.org; Tue, 19 Jun 2007 14:38:29 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0iaz-0002ZN-AR for ecrit@ietf.org; Tue, 19 Jun 2007 14:38:29 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 19 Jun 2007 14:38:29 -0400 X-IronPort-AV: i="4.16,439,1175486400"; d="scan'208"; a="63176115:sNHT57634004" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5JIcTbe026106; Tue, 19 Jun 2007 14:38:29 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5JIc5CE008261; Tue, 19 Jun 2007 18:38:27 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 14:38:21 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 14:38:21 -0400 From: "Marc Linsner" To: "'Dawson, Martin'" Subject: RE: FW: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 14:38:20 -0400 Message-ID: <004001c7b2a1$02a36550$220d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AceyjPBLIbyWc8J/RWOtAoJKe1euLgABO5LgAADC0ZAAAeD14A== X-OriginalArrivalTime: 19 Jun 2007 18:38:21.0198 (UTC) FILETIME=[02EE02E0:01C7B2A1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3702; t=1182278309; x=1183142309; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20FW=3A=20[Ecrit]=20Architecture=20comparisons |Sender:=20 |To:=20=22'Dawson,=20Martin'=22=20; bh=w2MI1iIkKfpEMSvjODCMh00LHfRs5sE6tCUJ/uahiD8=; b=WUJdcuuKdruxVry/7MVcbfOlzxy//l92IdgCE7IIYPNuRGpkqgbEX29hkOW6vqiUUdmVwXBH 3+STaXQZj3MtOpQhTcS7fTgHIW5zYE4+7luS4I1PYNlziglP/13IQelk; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Martin, > > So who are we going to force to provide the FG? The FG is a process of the LoST service which will be under the jurisdiction of the PSAP/gov't or it's assignee. > > In the mean time, since LoST already includes local discovery > mechanisms via DNS, FG and DNS LoST server discovery are orthogonal! how much has actually been forced on the > ISP? All we've said is that the LIS operator can discover and > query the LoST server. Some people have suggested that one > possible implementation model is that ISPs actually implement > the LoST infrastructure - but I don't think that's been > stated as an imperative. But you are attempting to discourage the FG, which is imperative if the ISP doesn't want to participate in anything 'LoST'! I don't have a problem if an ISP wants to: operate a LoST server and/or query LoST OBO their subscribers. What I have a problem with is advocating/building an architecture that forces such. I would expect most VSPs to either operate, or have a relationship with a LoST resolver. BTW, I sense a misunderstanding. UAs and/or VSP proxies don't/won't know about FGs, only LoST servers do. From a UA/Proxy view, the goal is for *any* LoST server to resolve location to uri for everywhere. There is nothing in the architecture that I'm aware of that suggests a UA/Proxy go 'LoST server shopping'. So, if my ISP (Joe's U-Haul and Pool Parlor) offers a LoST service and my UA queries that server for a mapping from afar, it will be expected the Joe's LoST server is fully engaged in the FG such that my UA will receive correct data. -Marc- > > Answer the first question and I might agree that taking care > of as much as possible at the local level isn't necessarily > the only safe starting point. > > Cheers, > Martin > > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Wednesday, 20 June 2007 3:08 AM > To: 'Richard Barnes' > Cc: 'ECRIT' > Subject: RE: FW: [Ecrit] Architecture comparisons > > Richard, > > > > > The tie between the access provider and the authoritative > LoST server > > is the same as the tie between the access provider and the > selective > > router it uses to get to its PSAPs > > -- they're both concerned with the same geographical area. > > And for non-telephony-offering access providers what is the tie? > > My point is that for as many access providers that offer LoST > services, there will be just as many if not more that won't. > Furthermore, if the access provider doesn't provide a LoST > service because they don't care about any telephony-like > service (nor 'location-hiding' since that is what drove this > discussion), this leaves the end-host/VSP required to perform > LoST queries. IMO, we, the IETF, cannot advocate an > architecture that 'requires' > access providers to perform/provide LoST services, hence the > need for a FG such to support end-hosts/VSPs. > > -Marc- > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 14:57:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0isx-0004Fn-GH; Tue, 19 Jun 2007 14:57:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0isw-0004Fh-Mt for ecrit@ietf.org; Tue, 19 Jun 2007 14:57:02 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0isu-0005Z1-69 for ecrit@ietf.org; Tue, 19 Jun 2007 14:57:02 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 19 Jun 2007 14:56:58 -0400 id 0158801B.467826FA.000037FF In-Reply-To: References: <467800C8.6030009@bbn.com> <002601c7b294$7243fa30$220d0d0a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9841613C-5EAB-47D4-BA71-35F732B27248@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 14:56:55 -0400 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 19, 2007, at 1:17 PM, Dawson, Martin wrote: > In the mean time, since LoST already includes local discovery > mechanisms > via DNS, how much has actually been forced on the ISP? It does? Where did you find that? I know there is a proposed DHCP discovery mechanism, but nothing along the lines as is found with the document that James/Martin wrote for LIS discovery. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 16:20:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kBN-0007Wg-Kh; Tue, 19 Jun 2007 16:20:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kBL-0007VI-It for ecrit@ietf.org; Tue, 19 Jun 2007 16:20:07 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0kBD-0006Gy-7y for ecrit@ietf.org; Tue, 19 Jun 2007 16:20:07 -0400 X-SEF-Processed: 5_0_0_910__2007_06_19_15_27_45 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 19 Jun 2007 15:27:45 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jun 2007 15:19:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 15:19:57 -0500 Message-ID: In-Reply-To: <00ac01c7b29b$42147360$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Architecture comparisons Thread-Index: AceyfbTM2g2gpFGSTOOcoIa34qe4sQABWYsgAAGN1AAAAFoqgAAAgH8gAADIP1AAAi8IcAAFOz3w References: <004101c7b26e$49e1a5e0$220d0d0a@amer.cisco.com> <008001c7b28a$71ed5a40$640fa8c0@cis.neustar.com> <009301c7b28e$80c1e780$640fa8c0@cis.neustar.com> <00ac01c7b29b$42147360$640fa8c0@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , "Henning Schulzrinne" , "Marc Linsner" X-OriginalArrivalTime: 19 Jun 2007 20:19:58.0650 (UTC) FILETIME=[354B59A0:01C7B2AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'm not aware of anything in i2 that has a built in assumption about the=0D= =0Adestination being a US PSAP. The VSP queries its selected VPC for a=0D=0A= route - the route could be to anywhere.=0D=0A=0D=0AYou may recall that I or= iginally responded sympathetically to the=0D=0Aquestion of how the ECRIT VS= P would know which LoST server to query=0D=0Abecause the i2 VSP would have = the same dilemma with respect to which VPC=0D=0Ato query. Location hiding c= auses the same problem for an i2 VSP in this=0D=0Arespect. I've been talkin= g to the UK interconnect forum; I think that=0D=0Athe UK will adopt i2 as w= ell.=0D=0A=0D=0AIn the end both ECRIT and i2 wrestle with exactly the same = issues - i2=0D=0Areally just includes the specifics about how to deliver th= e location=0D=0Ainformation out of band (via E2 in the US case). In fact, a= part from=0D=0Athis additional "location relay" function, and from a VSP pe= rspective, a=0D=0AVPC is semantically the equivalent of a LoST server.=0D=0A=0D= =0AI'm truly fascinated by the assumptions around VSP topology. Skype=0D=0A= doesn't bear any resemblance to these assumptions. I wonder what it is=0D=0A= that is making people assume that VSPs will end up being regional to any=0D= =0Asignificant extent - even if they start out that way. Does Vonage=0D=0Ac= onfiguration use proxies=3F=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----= Original Message-----=0D=0AFrom: Brian Rosen [mailto:br@brianrosen.net]=20=0D= =0ASent: Wednesday, 20 June 2007 3:57 AM=0D=0ATo: Dawson, Martin; 'Henning = Schulzrinne'; 'Marc Linsner'=0D=0ACc: 'ECRIT'=0D=0ASubject: RE: [Ecrit] Arc= hitecture comparisons=0D=0A=0D=0AI2 makes this silly assumption that ALL ca= lls go to a U.S. PSAP.=0D=0AClearly=0D=0Anot true. You could filter out 9-= 1-1 and route to a VPC (the i2=0D=0Aemergency=0D=0Acall processor). You co= uld also just use the whole ecrit mechanism and=0D=0Aput=0D=0Athe URI of yo= ur VPC in the LoST service (really, a generic US VPC URI,=0D=0Awhich=0D=0Ay= ou resolve to a specific one). The point being you could have=0D=0Asomethi= ng=0D=0Adifferent that would make 999 in London work, and 116 in France, et= c.=0D=0A=0D=0AClearly we WILL do this. It will be part of the transition f= rom i2 to=0D=0Ai3.=0D=0AIf you have a phonebcp compliant client on a system= that only supports=0D=0Ai2,=0D=0Awe'll make it work.=0D=0A=0D=0AMy ATA is = configured to use an outbound proxy. Don't know about yours.=0D=0AMy=0D=0A= ATA doesn't do STUN.=0D=0A=0D=0AThe "normal" way we expect the Next Generat= ion 9-1-1 system to work (to=0D=0Ause=0D=0Athe U.S. and hopefully Canada as= an example), is that the VSP will=0D=0Amaintain=0D=0AVPN connections to ES= RPs operated by the 9-1-1 authorities, probably at=0D=0Athe=0D=0Astate leve= l. A normal call from a high volume VSP when the caller is=0D=0A"home"=0D=0A= will go through that path. If there is a nomadic caller, operating=0D=0Aou= tside=0D=0Athe area the VSP normally serves a lot of customers, then the ca= ll will=0D=0Aroute over the Internet. The routing is simply by PSAP URI. = The route=0D=0Awill=0D=0Aeither take the tunnel or not based on the IP addr= ess with normal IP=0D=0Arouting. If the tunnel fails, the Internet should = work.=0D=0A=0D=0AIt has nothing to do with the ISP. You can change the ISP= and it still=0D=0Aworks. Of course QoS may depend on the ISP, but we're o= nly being=0D=0Aopportunistic about that. If QoS is available, we'd like it= on the=0D=0Atunnel.=0D=0A=0D=0ABrian=0D=0A=0D=0A=0D=0A> -----Original Mess= age-----=0D=0A> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A= > Sent: Tuesday, June 19, 2007 1:29 PM=0D=0A> To: Brian Rosen; Henning Schu= lzrinne; Marc Linsner=0D=0A> Cc: ECRIT=0D=0A> Subject: RE: [Ecrit] Architec= ture comparisons=0D=0A>=20=0D=0A> I find a number of assumptions in your re= sponse surprising and/or=0D=0A> puzzling... I think a lot must be to do wit= h me not appreciating the=0D=0A> inherited of developing wisdom about how V= oIP will be provided.=0D=0A>=20=0D=0A> The i2 architecture was defined to s= upport the out of band delivery of=0D=0A> location information when calls h= ave to be terminated on legacy switch=0D=0A> circuits. However, there's no = such thing as a "PSAP URI" in the sense=0D=0Aof=0D=0A> something that a UA = would ever see in that architecture. Yes, you=0D=0Acould=0D=0A> provide the= i2 proxy function as a PSAP service - which would=0D=0A> effectively turn = the PSAP into an IP one. However, that's the thing=0D=0A> isn't it=3F How m= any PSAPs have actually done that - and how long will=0D=0Ait=0D=0A> take=3F= Without that the UA never sees any such thing as a PSAP URI,=0D=0Awhich=0D= =0A> is why it does rely on the VSP to do the routing and for the VSP to=0D= =0A> ensure that location is properly delivered care of a VPC.=0D=0A>=20=0D= =0A> Your explanation of why you'd have to call via the VSP versus direct=0D= =0A> sounds quite complicated. I use a SIP provider for my residential VoIP=0D= =0A-=0D=0A> they are an Australian VSP but they have no relationship with m= y ISP.=0D=0AI=0D=0A> don't know how my ISP could possibly tell the differen= ce between a=0D=0Acall=0D=0A> initiated through my VSP or one to a SIP serv= er operated by emergency=0D=0A> services... my ATA does STUN anyway.=0D=0A>= =20=0D=0A> The situation you describe sounds very much like a VSP which is=0D= =0Aclosely=0D=0A> tied to the access provider with a proxy co-located with = the access=0D=0A> (otherwise the call does go over the Internet before the = VSP even sees=0D=0A> it right=3F And otherwise how can SIP be blocked for e= veryone else=3F).=0D=0AThis=0D=0A> ends up being so close to the 3GPP model= as makes no odds. I find=0D=0Athese=0D=0A> puzzling assumptions on which t= o make value judgements about the best=0D=0A> way forward. It seems to assu= me a very conservative model about VoIP=0D=0A> services. And I really don't= know what would qualify as "far" when it=0D=0A> comes to nomad'ing (when d= id that become a verb=3F).=0D=0A>=20=0D=0A> Surely taking my PDA/VoIP-clien= t across town or across the state is=0D=0A> going to eliminate the cozy rel= ationship my VSP may have had with my=0D=0A> nominal "home" location. In fa= ct I just have to switch from my=0D=0Apreferred=0D=0A> home DSL provider to= my preferred WiMAX provider when I step out of=0D=0Athe=0D=0A> door to cha= nge who my ISP is. If the answer is that the VSP has to=0D=0Ahave=0D=0A> a = proxy in the WiMAX access as well, then I smile wryly to myself at=0D=0Athe=0D= =0A> irony - given VoIP was supposed to dismantle all the established power=0D= =0A> structures associated with telephony services. I think I'll stick with=0D= =0A> Skype... (isn't it VoIP too=3F)=0D=0A>=20=0D=0A> I'm mostly asking all= this for my own illumination, but perhaps others=0D=0A> will find the info= rmation useful as well.=0D=0A>=20=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=20=0D= =0A> -----Original Message-----=0D=0A> From: Brian Rosen [mailto:br@brianro= sen.net]=0D=0A> Sent: Wednesday, 20 June 2007 2:26 AM=0D=0A> To: Dawson, Ma= rtin; 'Henning Schulzrinne'; 'Marc Linsner'=0D=0A> Cc: 'ECRIT'=0D=0A> Subje= ct: RE: [Ecrit] Architecture comparisons=0D=0A>=20=0D=0A> But the point is = that if the e.164 is in the database, the right thing=0D=0A> happens if the= PSAP is only reachable by the PSTN. They don't get=0D=0A> addresses=0D=0A= > from the endpoint (if they get them at all, it's an internal phone=0D=0A>= book). A=0D=0A> VoIP endpoint conformant to phonebcp would be able to suc= cessfully=0D=0A> complete=0D=0A> an emergency call to such a PSAP if the da= ta is put in a LoST server=0D=0Ait=0D=0A> can=0D=0A> get to.=0D=0A>=20=0D=0A= > Realistically, it would be very possible to make most VSP systems=0D=0A> = correctly=0D=0A> handle 3 digit emergency calls, albeit nomadic users would= n't have=0D=0A> correct=0D=0A> location. The VSP would have to route a cal= l to the right 3 digit=0D=0A> gateway.=0D=0A> A U.S. "i2" solution, but if = you nomaded to the U.K., we could get the=0D=0A> right=0D=0A> thing to happ= en there (probably have to use their mobile location=0D=0A> stuff).=0D=0A> = I'm not seriously suggesting it, just noting that if you had the=0D=0Acorre= ct=0D=0A> boundary data, and internal route infrastructure, the whole mecha= nism=0D=0A> can be=0D=0A> made to work pretty well without putting PSAPs on= IP networks.=0D=0A>=20=0D=0A> Outbound routing is usually pretty tough. O= ne example is NAT=0D=0Atraversal=0D=0A> for=0D=0A> media. Unless the UA do= es STUN/TURN, it's usually an SBC in the VSP=0D=0A> that=0D=0A> fixes the m= edia. Signaling outbound is sometimes a problem (outbound=0D=0A> SIP on=0D= =0A> port 5060 is often blocked). It has nothing nefarious; just the=0D=0A= > likelihood=0D=0A> of working, where special procedures only used for emer= gency calls may=0D=0A> not=0D=0A> work.=0D=0A>=20=0D=0A> Also, we're expect= ing the VSPs to often have VPN connections to the=0D=0A> ESRP,=0D=0A> rathe= r than taking the calls from the Internet. Where there is QoS,=0D=0Awe=0D=0A= > can=0D=0A> maintain it. We also get some DDoS protection. That won't wo= rk when=0D=0A> you=0D=0A> nomad afar, but it does work for the normal case.=0D= =0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A> > -----Original Message-----=0D=0A> >= From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A> > Sent: Tues= day, June 19, 2007 12:06 PM=0D=0A> > To: Brian Rosen; Henning Schulzrinne; = Marc Linsner=0D=0A> > Cc: ECRIT=0D=0A> > Subject: RE: [Ecrit] Architecture = comparisons=0D=0A> >=0D=0A> > Oh for pity's... that wasn't the spirit of my= question.=0D=0A> >=0D=0A> > OK, how many PSAP URIs exist which will permit= the location object=0D=0Aor=0D=0A> > location reference to be delivered wi= th the call=3F=0D=0A> >=0D=0A> > And doing PSTN bridging doesn't work in th= e US... that's i1 and it's=0D=0A> not=0D=0A> > acceptable. It doesn't work = in any other country where emergency=0D=0Acalls=0D=0A> > are not carried on= the PSTN.=0D=0A> >=0D=0A> > Why don't you think the BCP should recommend t= hat a UA which knows=0D=0A> it's=0D=0A> > doing an emergency call just rout= e directly=3F What actual value does=0D=0A> the=0D=0A> > VSP add, out of cu= riosity=3F Is this in order to enforce some sort of=0D=0A> > subscriber ide= ntity audit trail=3F I don't think that would work for=0D=0A> > foreign VSP= s anyway; is it something that ECRIT has decided is a=0D=0Agoal=3F=0D=0A> >=0D= =0A> > Cheers,=0D=0A> > Martin=0D=0A> >=0D=0A> > -----Original Message-----=0D= =0A> > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > Sent: Wednesda= y, 20 June 2007 1:57 AM=0D=0A> > To: Dawson, Martin; 'Henning Schulzrinne';= 'Marc Linsner'=0D=0A> > Cc: 'ECRIT'=0D=0A> > Subject: RE: [Ecrit] Architec= ture comparisons=0D=0A> >=0D=0A> > Actually, most of the world already has = them, depending on how you=0D=0A> > define=0D=0A> > most. Most PSAPs are o= nly reachable via e.164s, for which we have=0D=0Atel=0D=0A> > or=0D=0A> > s= ip URIs readily mintable.=0D=0A> >=0D=0A> > The forest guide IS the jurisdi= ction publishing its data. That's=0D=0Athe=0D=0A> > purpose. There is no = point in publishing it a different way.=0D=0A> >=0D=0A> > Please also remem= ber that for most countries (excepting the U.S. and=0D=0A> > Canada)=0D=0A>= > the entire LoST database is a couple of records. We'll probably=0D=0Aha= ve=0D=0A> > the=0D=0A> > LoST data way before we have the PSAPs on an IP ne= twork. It would=0D=0A> > actually=0D=0A> > be quite useful to publish the = geo boundaries.=0D=0A> >=0D=0A> > There are very few VSPs which can be bypa= ssed. UAs don't ever route=0D=0A> > direct.=0D=0A> > They send all outboun= d calls to their outbound proxy. That's the=0D=0A> VSP's=0D=0A> > proxy. = Even the free services (FWD for example) are done that way.=0D=0A> We=0D=0A= > > could try to have emergency calls not do that of course, but I think=0D= =0A> > that's=0D=0A> > a very big change. -phonebcp doesn't say that. I d= on't think it=0D=0A> > should.=0D=0A> >=0D=0A> > Brian=0D=0A> >=0D=0A> > > = -----Original Message-----=0D=0A> > > From: Dawson, Martin [mailto:Martin.D= awson@andrew.com]=0D=0A> > > Sent: Tuesday, June 19, 2007 11:19 AM=0D=0A> >= > To: Henning Schulzrinne; Marc Linsner=0D=0A> > > Cc: ECRIT=0D=0A> > > Su= bject: RE: [Ecrit] Architecture comparisons=0D=0A> > >=0D=0A> > > There's p= robably a reality check in order in this discussion as=0D=0A> well.=0D=0A> = > > I'd be interested in what opinions are out there.=0D=0A> > >=0D=0A> > >= How many valid "PSAP URIs" exist anywhere in the world today=3F I'll=0D=0A= > > take=0D=0A> > > a wild stab and suggest... zero. That's certainly appro= ximately=0D=0A> > correct.=0D=0A> > >=0D=0A> > > When any significant juris= diction does IP enable their emergency=0D=0A> call=0D=0A> > > centers (and = aren't they likely to be doing it before=0D=0A> "insignificant"=0D=0A> > > = jurisdictions do=3F) I suspect it'll make the industry news.=0D=0A> > >=0D=0A= > > > Just how fast is this likely to happen=3F Is it the case that it=0D=0A= will=0D=0A> > > actually be reasonably straightforward to keep track of cou= ntries=0D=0A> that=0D=0A> > > IP enable their emergency call centers as the= y emerge=3F And could=0D=0A> this=0D=0A> > > not be the case to the extent = that any suitably diligent party=0D=0Acould=0D=0A> > > build a global datab= ase of PSAP URIs that was 95+ percent correct=0D=0A> just=0D=0A> > > by mon= itoring the industry=3F Ideally, of course, each jurisdiction=0D=0A> > woul= d=0D=0A> > > have an actual authority who would formally publish this=0D=0A= information=0D=0A> > > (ideally publishing it into a forest guide infrastru= cture=0D=0A> eventually,=0D=0A> > > though this wouldn't be necessary at th= e outset).=0D=0A> > >=0D=0A> > > Do people think it's more or less likely t= hat UA's will actually=0D=0A> just=0D=0A> > > universally route to the PSAP= themselves rather than go via the=0D=0AVSP=0D=0A> > > anyway before any ne= ed for this global infrastructure emerges=3F Is=0D=0A> > there=0D=0A> > > a= ny reason, in the long term, for devices to route via the VSP if=0D=0A> the=0D= =0A> > > PSAP is directly reachable=3F=0D=0A> > >=0D=0A> > > Cheers,=0D=0A>= > > Martin=0D=0A> > >=0D=0A> > > -----Original Message-----=0D=0A> > > Fro= m: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A> > > Sent: Wednes= day, 20 June 2007 12:25 AM=0D=0A> > > To: Marc Linsner=0D=0A> > > Cc: ECRIT=0D= =0A> > > Subject: Re: [Ecrit] Architecture comparisons=0D=0A> > >=0D=0A> > = > I'll ad to the crystal ball gazing sessIon:=0D=0A> > >=0D=0A> > > I think= the evolution will depend on who will be running LoST=0D=0A> servers=0D=0A= > > > and how data is distributed. One model is that the PSAP or other=0D=0A= > > > government authorities will make data available, but LoST servers=0D=0A= > > > will be run by private enterprises. Another is that these=0D=0A> auth= orities=0D=0A> > > will run it themselves. The depth of the trees will pres= umably=0D=0A> depend=0D=0A> > > on the level of federalism in the respectiv= e country, with some=0D=0A> > > countries, like France, presumably going na= tional immediately,=0D=0Awhile=0D=0A> > > others, such as the United States= and Germany, maybe starting=0D=0Abottom=0D=0A> > > up, with some progressi= ve states going first.=0D=0A> > >=0D=0A> > > Regardless, as long as these t= rees make coverage information=0D=0A> > > available or such information can= be derived, it's not too hard=0D=0Afor=0D=0A> > > either a larger VSP or s= ome third-party service company to=0D=0Aaggregate=0D=0A> > > this informati= on and offer a "private" FG. After all, the=0D=0Aboundaries=0D=0A> > > of s= tates and countries don't change all that often. In some=0D=0A> > > countri= es, the incumbent ISP will presumably try to make life=0D=0A> > > difficult= for third-party VoIP customers until forced to by=0D=0A> > > regulators, s= o I wouldn't count on having "open" access to PSAP=0D=0AURIs=0D=0A> > > cou= rtesy of the ISP, either, but we'll see.=0D=0A> > >=0D=0A> > > To echo what= Brian said, the likelihood that we'll have Zimbabwe,=0D=0A> > > Taiwan and= North Korea all happily in one FG run by the UN is=0D=0A> > > probably a w= ays off, just after the black helicopters have landed.=0D=0A> > > However, = for most people, almost all the time, things will work,=0D=0Aas=0D=0A> > > = long as we have some good will. (For example, avoid decade-long=0D=0A> lega= l=0D=0A> > > fights about data ownership.)=0D=0A> > >=0D=0A> > > Henning=0D= =0A> > >=0D=0A> > > On Jun 19, 2007, at 8:35 AM, Marc Linsner wrote:=0D=0A>= > >=0D=0A> > > > All,=0D=0A> > > >=0D=0A> > > > In my attempt to follow th= is thread, I've concluded that there=0D=0Ais=0D=0A> a=0D=0A> > > > belief=0D= =0A> > > > the access provider will have information wrt LoST authoritative=0D= =0A> > > > servers=0D=0A> > > > that VSPs won't have.=0D=0A> > > >=0D=0A> >= > > Is my assumption correct=3F=0D=0A> > > >=0D=0A> > > > Is it not true t= hat the architecture we've adopted depends on=0D=0Athe=0D=0A> > > > forest=0D= =0A> > > > guide to 'find' the authoritative LoST server=3F So, this raise= s=0D=0A> the=0D=0A> > > > question, short of a working forest guide, how do= es the access=0D=0A> > > > provider find=0D=0A> > > > the authoritative LoS= T server and why can't the VSP use the same=0D=0A> > such=0D=0A> > > > mech= anism=3F=0D=0A> > > >=0D=0A> > > > Just curious,=0D=0A> > >=0D=0A> > >=0D=0A= > > > _______________________________________________=0D=0A> > > Ecrit mail= ing list=0D=0A> > > Ecrit@ietf.org=0D=0A> > > https://www1.ietf.org/mailman= /listinfo/ecrit=0D=0A> > >=0D=0A> > >=0D=0A> >=0D=0A>=0D=0A----------------= --------------------------------------------------------=0D=0A> > --=0D=0A>= > > ----------------------=0D=0A> > > This message is for the designated r= ecipient only and may=0D=0A> > > contain privileged, proprietary, or otherw= ise private information.=0D=0A> > > If you have received it in error, pleas= e notify the sender=0D=0A> > > immediately and delete the original. Any un= authorized use of=0D=0A> > > this email is prohibited.=0D=0A> > >=0D=0A> >=0D= =0A>=0D=0A-----------------------------------------------------------------= -------=0D=0A> > --=0D=0A> > > ----------------------=0D=0A> > > [mf2]=0D=0A= > > >=0D=0A> > >=0D=0A> > > _______________________________________________=0D= =0A> > > Ecrit mailing list=0D=0A> > > Ecrit@ietf.org=0D=0A> > > https://ww= w1.ietf.org/mailman/listinfo/ecrit=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A>=0D=0A-= -----------------------------------------------------------------------=0D=0A= > --=0D=0A> > ----------------------=0D=0A> > This message is for the desig= nated recipient only and may=0D=0A> > contain privileged, proprietary, or o= therwise private information.=0D=0A> > If you have received it in error, pl= ease notify the sender=0D=0A> > immediately and delete the original. Any u= nauthorized use of=0D=0A> > this email is prohibited.=0D=0A> >=0D=0A>=0D=0A= ------------------------------------------------------------------------=0D= =0A> --=0D=0A> > ----------------------=0D=0A> > [mf2]=0D=0A>=20=0D=0A>=20=0D= =0A>=0D=0A-----------------------------------------------------------------= -------=0D=0A--=0D=0A> ----------------------=0D=0A> This message is for th= e designated recipient only and may=0D=0A> contain privileged, proprietary,= or otherwise private information.=0D=0A> If you have received it in error,= please notify the sender=0D=0A> immediately and delete the original. Any = unauthorized use of=0D=0A> this email is prohibited.=0D=0A>=0D=0A----------= --------------------------------------------------------------=0D=0A--=0D=0A= > ----------------------=0D=0A> [mf2]=0D=0A=0D=0A=0D=0A--------------------= ---------------------------------------------------------------------------= -=0D=0AThis message is for the designated recipient only and may=0D=0Aconta= in privileged, proprietary, or otherwise private information. =20=0D=0AIf y= ou have received it in error, please notify the sender=0D=0Aimmediately and= delete the original. Any unauthorized use of=0D=0Athis email is prohibite= d.=0D=0A-------------------------------------------------------------------= -----------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 16:27:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kIn-00042P-IA; Tue, 19 Jun 2007 16:27:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kIl-00041Q-Re for ecrit@ietf.org; Tue, 19 Jun 2007 16:27:47 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0kIS-0000N7-E7 for ecrit@ietf.org; Tue, 19 Jun 2007 16:27:47 -0400 Received: from [10.2.3.113] (vbn.0050420.lodgenet.net [209.19.49.10]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5JKRNtg002447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 19 Jun 2007 16:27:27 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <004101c7b26e$49e1a5e0$220d0d0a@amer.cisco.com> <008001c7b28a$71ed5a40$640fa8c0@cis.neustar.com> <009301c7b28e$80c1e780$640fa8c0@cis.neustar.com> <00ac01c7b29b$42147360$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 16:26:55 -0400 To: ECRIT X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > significant extent - even if they start out that way. Does Vonage > configuration use proxies? Yes. They happen to be B2BUAs. (I'm not advocating any architecture here, just stating what I know.) Same is true for sipgate.de, the provider I use. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 17:23:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lAd-0002hf-HV; Tue, 19 Jun 2007 17:23:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lAb-0002hS-Iv for ecrit@ietf.org; Tue, 19 Jun 2007 17:23:26 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0lAa-0006jx-Cw for ecrit@ietf.org; Tue, 19 Jun 2007 17:23:25 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 19 Jun 2007 17:23:23 -0400 id 01588433.4678494B.00005F6E In-Reply-To: References: <004101c7b26e$49e1a5e0$220d0d0a@amer.cisco.com> <008001c7b28a$71ed5a40$640fa8c0@cis.neustar.com> <009301c7b28e$80c1e780$640fa8c0@cis.neustar.com> <00ac01c7b29b$42147360$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <66D3DE4C-4CB4-4008-9EB1-EC7D66C896DF@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 17:23:20 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 19, 2007, at 4:26 PM, Henning Schulzrinne wrote: > >> significant extent - even if they start out that way. Does Vonage >> configuration use proxies? > > Yes. They happen to be B2BUAs. (I'm not advocating any architecture > here, just stating what I know.) Same is true for sipgate.de, the > provider I use. True enough. Most VSPs, both direct and indirect (using the SPEERMINT terminology) use B2BUAs. Of course, that has nothing to do with the regions they serve. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 19:38:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0nHc-0000jC-QL; Tue, 19 Jun 2007 19:38:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0nHb-0000fn-Lk for ecrit@ietf.org; Tue, 19 Jun 2007 19:38:47 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0nHb-0005JP-CH for ecrit@ietf.org; Tue, 19 Jun 2007 19:38:47 -0400 X-SEF-Processed: 5_0_0_910__2007_06_19_18_46_30 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 19 Jun 2007 18:46:29 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jun 2007 18:38:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 18:38:41 -0500 Message-ID: In-Reply-To: <9841613C-5EAB-47D4-BA71-35F732B27248@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Architecture comparisons Thread-Index: Aceyo6DIgJC7CBz3TSyPZIoXJ8dW1gAJLKjQ References: <467800C8.6030009@bbn.com><002601c7b294$7243fa30$220d0d0a@amer.cisco.com> <9841613C-5EAB-47D4-BA71-35F732B27248@hxr.us> From: "Winterbottom, James" To: "Andrew Newton" , "Dawson, Martin" X-OriginalArrivalTime: 19 Jun 2007 23:38:43.0024 (UTC) FILETIME=[F8C66D00:01C7B2CA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Andy,=0D=0A=0D=0AThe current LoST draft specifically puts finding the ho= stname of the=0D=0ALoST server out of scope. Which means that the end-point= has to know=0D=0Athis, including the domain before performing the U-NAPTR = lookup to=0D=0Aobtain the full URI.=0D=0A=0D=0AYes, there are a number of w= ays that the End-Point can learn the=0D=0Ahostname of the LoST server. Real= istically in many broadband deployments=0D=0Athis number is significantly r= estricted as DHCP, the only currently=0D=0Adefined way to learn the identit= y of the lost server, is not available.=0D=0AThis really only leaves hard-c= oding or DNS.=0D=0A=0D=0AOne basic DNS mechanism is defined in the LIS disc= overy draft you=0D=0Amention below.=20=0D=0A=0D=0ATo work in general though= the End-Point needs to identify a domain of=0D=0Asome description or it wo= n't work. If the End-Point uses the domain=0D=0Aconfigured into their devic= e then they will discover the LoST server=0D=0Aassociated with their home d= omain. If they are roaming, then there needs=0D=0Ato be a set of forest gui= des that can link their home LoST server to the=0D=0ALoST server for the Us= er's current area or they really are LoST.=0D=0A=0D=0AAlternatively the End= -Point can learn the identity of the domain=0D=0Acurrently providing it acc= ess, and ask the DNS server for the local LoST=0D=0Aserver.=0D=0A=0D=0AI am= sure that there are other methods too. The point I think Martin was=0D=0At= rying to make was that if option 3 is used, then the ISP don't have to=0D=0A= have LoST records in its DNS, and connecting forest guides don't have to=0D= =0Abe in place for the service to work. I agree that ultimately we want=0D=0A= them there, but it is a fact of life that they won't be to start with,=0D=0A= and having an orderly alternative is better than a bunch of adhoc=0D=0Asolu= tions.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A> -----Original Messag= e-----=0D=0A> From: Andrew Newton [mailto:andy@hxr.us]=0D=0A> Sent: Wednesd= ay, 20 June 2007 4:57 AM=0D=0A> To: Dawson, Martin=0D=0A> Cc: ECRIT=0D=0A> = Subject: Re: [Ecrit] Architecture comparisons=0D=0A>=20=0D=0A>=20=0D=0A> On= Jun 19, 2007, at 1:17 PM, Dawson, Martin wrote:=0D=0A>=20=0D=0A> > In the = mean time, since LoST already includes local discovery=0D=0A> > mechanisms=0D= =0A> > via DNS, how much has actually been forced on the ISP=3F=0D=0A>=20=0D= =0A> It does=3F Where did you find that=3F I know there is a proposed DHC= P=0D=0A> discovery mechanism, but nothing along the lines as is found with = the=0D=0A> document that James/Martin wrote for LIS discovery.=0D=0A>=20=0D= =0A> -andy=0D=0A>=20=0D=0A> _______________________________________________=0D= =0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/= mailman/listinfo/ecrit=0D=0A=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0AThis message i= s for the designated recipient only and may=0D=0Acontain privileged, propri= etary, or otherwise private information. =20=0D=0AIf you have received it i= n error, please notify the sender=0D=0Aimmediately and delete the original.= Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A-------------= ---------------------------------------------------------------------------= --------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 20:22:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0nxd-0003xy-T3; Tue, 19 Jun 2007 20:22:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0nxc-0003x0-As for ecrit@ietf.org; Tue, 19 Jun 2007 20:22:12 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0nxb-0008SE-3l for ecrit@ietf.org; Tue, 19 Jun 2007 20:22:12 -0400 Received: from [10.0.1.110] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 19 Jun 2007 20:22:08 -0400 id 015880C3.46787330.00000499 In-Reply-To: References: <467800C8.6030009@bbn.com><002601c7b294$7243fa30$220d0d0a@amer.cisco.com> <9841613C-5EAB-47D4-BA71-35F732B27248@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8E1BCF9A-1E6A-420C-B46E-84F89E303535@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 20:22:05 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: "Dawson, Martin" , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 19, 2007, at 7:38 PM, Winterbottom, James wrote: > I am sure that there are other methods too. The point I think > Martin was > trying to make was that if option 3 is used, then the ISP don't > have to > have LoST records in its DNS, and connecting forest guides don't > have to > be in place for the service to work. I agree that ultimately we want > them there, but it is a fact of life that they won't be to start with, > and having an orderly alternative is better than a bunch of adhoc > solutions. If an ISP thinks it is an onerous task to put some DNS records in their name servers that point to a LoST regional resolver, then they need not be in the ISP business. I've been to enough NANOG and RIPE meetings to tell you that most ISPs in the modern world would find this to be a trivial task. And doing DNS discovery for networks that don't use DHCP is a far shorter path than trying to half-heartedly tunnel LoST through an LCP. LoST discovery is work that this group needs to conduct. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 21:21:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0osm-0005lJ-LL; Tue, 19 Jun 2007 21:21:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0osl-0005l8-Eu for ecrit@ietf.org; Tue, 19 Jun 2007 21:21:15 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0osk-0004kS-6l for ecrit@ietf.org; Tue, 19 Jun 2007 21:21:15 -0400 X-SEF-Processed: 5_0_0_910__2007_06_19_20_28_58 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 19 Jun 2007 20:28:58 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 19 Jun 2007 20:21:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 20:21:09 -0500 Message-ID: In-Reply-To: <8E1BCF9A-1E6A-420C-B46E-84F89E303535@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Architecture comparisons Thread-Index: Acey0Qo7apJDO3+8R+e1K7XjayXQQgABWHag References: <467800C8.6030009@bbn.com><002601c7b294$7243fa30$220d0d0a@amer.cisco.com> <9841613C-5EAB-47D4-BA71-35F732B27248@hxr.us> <8E1BCF9A-1E6A-420C-B46E-84F89E303535@hxr.us> From: "Winterbottom, James" To: "Andrew Newton" X-OriginalArrivalTime: 20 Jun 2007 01:21:11.0362 (UTC) FILETIME=[49785A20:01C7B2D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: "Dawson, Martin" , ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Andy,=0D=0A=0D=0AI would just like to point out that the description tha= t I provided is=0D=0Ain addition to the ISP having to boundary map intersec= tions for LoST=0D=0Aservice boundaries on a per subscriber basis. I think t= hat if you couple=0D=0Athose two efforts then providing enabled service URN= s and URIs through=0D=0Aan LCP is much less work and provides a far higher = degree of control=0D=0Awith regards to what location can and cannot be used= for.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A> -----Orig= inal Message-----=0D=0A> From: Andrew Newton [mailto:andy@hxr.us]=0D=0A> Se= nt: Wednesday, 20 June 2007 10:22 AM=0D=0A> To: Winterbottom, James=0D=0A> = Cc: Dawson, Martin; ECRIT=0D=0A> Subject: Re: [Ecrit] Architecture comparis= ons=0D=0A>=20=0D=0A>=20=0D=0A> On Jun 19, 2007, at 7:38 PM, Winterbottom, J= ames wrote:=0D=0A>=20=0D=0A> > I am sure that there are other methods too. = The point I think=0D=0A> > Martin was=0D=0A> > trying to make was that if o= ption 3 is used, then the ISP don't=0D=0A> > have to=0D=0A> > have LoST rec= ords in its DNS, and connecting forest guides don't=0D=0A> > have to=0D=0A>= > be in place for the service to work. I agree that ultimately we want=0D=0A= > > them there, but it is a fact of life that they won't be to start=0D=0Aw= ith,=0D=0A> > and having an orderly alternative is better than a bunch of a= dhoc=0D=0A> > solutions.=0D=0A>=20=0D=0A> If an ISP thinks it is an onerous= task to put some DNS records in=0D=0A> their name servers that point to a = LoST regional resolver, then they=0D=0A> need not be in the ISP business. = I've been to enough NANOG and RIPE=0D=0A> meetings to tell you that most IS= Ps in the modern world would find=0D=0A> this to be a trivial task. And do= ing DNS discovery for networks that=0D=0A> don't use DHCP is a far shorter = path than trying to half-heartedly=0D=0A> tunnel LoST through an LCP.=0D=0A= >=20=0D=0A> LoST discovery is work that this group needs to conduct.=0D=0A>= =20=0D=0A> -andy=0D=0A=0D=0A-----------------------------------------------= -------------------------------------------------=0D=0AThis message is for = the designated recipient only and may=0D=0Acontain privileged, proprietary,= or otherwise private information. =20=0D=0AIf you have received it in erro= r, please notify the sender=0D=0Aimmediately and delete the original. Any = unauthorized use of=0D=0Athis email is prohibited.=0D=0A-------------------= ---------------------------------------------------------------------------= --=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 19 21:21:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0otT-0006OG-Pw; Tue, 19 Jun 2007 21:21:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0otS-0006M9-Sn for ecrit@ietf.org; Tue, 19 Jun 2007 21:21:58 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0otR-0004nm-IG for ecrit@ietf.org; Tue, 19 Jun 2007 21:21:58 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I0otF-0005KC-KI; Tue, 19 Jun 2007 20:21:45 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Winterbottom, James'" References: <467800C8.6030009@bbn.com><002601c7b294$7243fa30$220d0d0a@amer.cisco.com><9841613C-5EAB-47D4-BA71-35F732B27248@hxr.us> <8E1BCF9A-1E6A-420C-B46E-84F89E303535@hxr.us> Subject: RE: [Ecrit] Architecture comparisons Date: Tue, 19 Jun 2007 21:21:51 -0400 Message-ID: <029f01c7b2d9$64e95890$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <8E1BCF9A-1E6A-420C-B46E-84F89E303535@hxr.us> Thread-Index: Acey0QhFSULVbeeQRtqGBGY+zilFIgACDLnA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "'Dawson, Martin'" , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Agree with everything in this post > LoST discovery is work that this group needs to conduct. Okay so: The ISP supplies a DHCP entry and/or a DNS entry for the domain The VSP could do it with config It would be very nice to have some more universal mechanism. I have an idea, but I'd better run it by some experts before I get seriously singed. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Tuesday, June 19, 2007 8:22 PM > To: Winterbottom, James > Cc: Dawson, Martin; ECRIT > Subject: Re: [Ecrit] Architecture comparisons > > > On Jun 19, 2007, at 7:38 PM, Winterbottom, James wrote: > > > I am sure that there are other methods too. The point I think > > Martin was > > trying to make was that if option 3 is used, then the ISP don't > > have to > > have LoST records in its DNS, and connecting forest guides don't > > have to > > be in place for the service to work. I agree that ultimately we want > > them there, but it is a fact of life that they won't be to start with, > > and having an orderly alternative is better than a bunch of adhoc > > solutions. > > If an ISP thinks it is an onerous task to put some DNS records in > their name servers that point to a LoST regional resolver, then they > need not be in the ISP business. I've been to enough NANOG and RIPE > meetings to tell you that most ISPs in the modern world would find > this to be a trivial task. And doing DNS discovery for networks that > don't use DHCP is a far shorter path than trying to half-heartedly > tunnel LoST through an LCP. > > LoST discovery is work that this group needs to conduct. > > -andy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 20 08:50:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0zdq-0000h0-Ky; Wed, 20 Jun 2007 08:50:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0zdo-0000gr-Vu for ecrit@ietf.org; Wed, 20 Jun 2007 08:50:32 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0zdn-0005jO-QI for ecrit@ietf.org; Wed, 20 Jun 2007 08:50:32 -0400 Received: from [10.0.1.110] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 20 Jun 2007 08:40:27 -0400 id 01588131.4679203B.00002AD3 In-Reply-To: <029f01c7b2d9$64e95890$640fa8c0@cis.neustar.com> References: <467800C8.6030009@bbn.com><002601c7b294$7243fa30$220d0d0a@amer.cisco.com><9841613C-5EAB-47D4-BA71-35F732B27248@hxr.us> <8E1BCF9A-1E6A-420C-B46E-84F89E303535@hxr.us> <029f01c7b2d9$64e95890$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Architecture comparisons Date: Wed, 20 Jun 2007 08:40:23 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: "'Dawson, Martin'" , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 19, 2007, at 9:21 PM, Brian Rosen wrote: > Okay so: > The ISP supplies a DHCP entry and/or a DNS entry for the domain There's also rev. DNS and mDNS. > The VSP could do it with config And I don't think this needs to be specified any further. The config mechanisms for ATAs and soft clients are various and many. > It would be very nice to have some more universal mechanism. > I have an idea, but I'd better run it by some experts before I get > seriously > singed. I agree, a more universal mechanism is better. It's annoying to re- invent this type of thing for every application. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 20 11:06:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I11l7-0001I2-ED; Wed, 20 Jun 2007 11:06:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I11l6-0001Hv-Aw for ecrit@ietf.org; Wed, 20 Jun 2007 11:06:12 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I11l3-0006yH-Um for ecrit@ietf.org; Wed, 20 Jun 2007 11:06:12 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I11ku-0003IE-Kw; Wed, 20 Jun 2007 10:06:01 -0500 From: "Brian Rosen" To: "'Andrew Newton'" References: <467800C8.6030009@bbn.com><002601c7b294$7243fa30$220d0d0a@amer.cisco.com><9841613C-5EAB-47D4-BA71-35F732B27248@hxr.us> <8E1BCF9A-1E6A-420C-B46E-84F89E303535@hxr.us> <029f01c7b2d9$64e95890$640fa8c0@cis.neustar.com> Subject: RE: [Ecrit] Architecture comparisons Date: Wed, 20 Jun 2007 11:06:02 -0400 Message-ID: <03df01c7b34c$889e7180$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcezOCvvpeo2UtV4QVavWvgl3Xx+PQAE3AYw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "'Dawson, Martin'" , 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Well, my suggestion may not solve the general case. Put an SRV for LoST in the root of the ccTLD (e.g. in .us) For most countries, that's pretty much exactly what you want. For places like the U.S., configuration of the domain may be complex to spread the load on multiple servers that may or may not be operated by the same entity, but we can do that. Of course we could also put one in .pa.us for example. It's pretty straightforward to get a country code, and even if you are off, the FG thing ought to work. I'd make a priority order of first ISP, then VSP then ccTLD. Reverse DNS may be needed to get the domain of the ISP. Was that what you were thinking? mDNS clearly should be an alternative. Brian > -----Original Message----- > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Wednesday, June 20, 2007 8:40 AM > To: Brian Rosen > Cc: 'Winterbottom, James'; 'Dawson, Martin'; 'ECRIT' > Subject: Re: [Ecrit] Architecture comparisons > > > On Jun 19, 2007, at 9:21 PM, Brian Rosen wrote: > > > Okay so: > > The ISP supplies a DHCP entry and/or a DNS entry for the domain > > There's also rev. DNS and mDNS. > > > The VSP could do it with config > > And I don't think this needs to be specified any further. The config > mechanisms for ATAs and soft clients are various and many. > > > It would be very nice to have some more universal mechanism. > > I have an idea, but I'd better run it by some experts before I get > > seriously > > singed. > > I agree, a more universal mechanism is better. It's annoying to re- > invent this type of thing for every application. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 20 13:04:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13bL-0000um-91; Wed, 20 Jun 2007 13:04:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13bJ-0000sA-8X for ecrit@ietf.org; Wed, 20 Jun 2007 13:04:13 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I13bI-0007Uq-U3 for ecrit@ietf.org; Wed, 20 Jun 2007 13:04:13 -0400 Received: from [10.2.4.97] (vbn.0050420.lodgenet.net [209.19.49.10]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5KH3vnf021380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Jun 2007 13:04:03 -0400 (EDT) In-Reply-To: <03df01c7b34c$889e7180$640fa8c0@cis.neustar.com> References: <467800C8.6030009@bbn.com><002601c7b294$7243fa30$220d0d0a@amer.cisco.com><9841613C-5EAB-47D4-BA71-35F732B27248@hxr.us> <8E1BCF9A-1E6A-420C-B46E-84F89E303535@hxr.us> <029f01c7b2d9$64e95890$640fa8c0@cis.neustar.com> <03df01c7b34c$889e7180$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Architecture comparisons Date: Wed, 20 Jun 2007 13:03:55 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian: Practically speaking, inserting things directly under .ccltd is probably difficult. I'm also not convinced that this is a problem we need to solve immediately, given that most systems will get configuration information from their VSP. For the VSP model, we have two choices: - leverage SIP configuration, now in SIPPING WG LC; it picks the SIP subscription address based on the AOR - creating a look-up from the host part of the AOR, via NAPTR; this is essentially already in the draft. We only need to add one sentence: "A SIP user agent uses the host part of its SIP AOR." Done. For the non-VSP model, there is the danger of re-creating the global ENUM problem, i.e., agreeing on a common root. I happen to think that the model used for finding DNS root servers, namely anycast, would be a better one. It provides a low-level redundancy that is highly robust and avoids having to start with a country code. I'm not opposed to something like us.lost.org (just to make up something), but it would be nice to have something that can be done by a grassroots effort, rather than getting ICANN and/or the ITU involved. Determining who can speak for the public safety community in each country is non-trivial; the equivalent (determining the local authority in charge of E.164) made global ENUM such a pain. (I was on the IAB during that discussion, so I can attest to the pain and suffering. And it's still not working.) Henning On Jun 20, 2007, at 11:06 AM, Brian Rosen wrote: > Well, my suggestion may not solve the general case. > > Put an SRV for LoST in the root of the ccTLD (e.g. in .us) > For most countries, that's pretty much exactly what you want. > > For places like the U.S., configuration of the domain may be > complex to > spread the load on multiple servers that may or may not be operated > by the > same entity, but we can do that. Of course we could also put one > in .pa.us > for example. It's pretty straightforward to get a country code, > and even if > you are off, the FG thing ought to work. > > I'd make a priority order of first ISP, then VSP then ccTLD. > > Reverse DNS may be needed to get the domain of the ISP. Was that > what you > were thinking? > > mDNS clearly should be an alternative. > > Brian > >> -----Original Message----- >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Wednesday, June 20, 2007 8:40 AM >> To: Brian Rosen >> Cc: 'Winterbottom, James'; 'Dawson, Martin'; 'ECRIT' >> Subject: Re: [Ecrit] Architecture comparisons >> >> >> On Jun 19, 2007, at 9:21 PM, Brian Rosen wrote: >> >>> Okay so: >>> The ISP supplies a DHCP entry and/or a DNS entry for the domain >> >> There's also rev. DNS and mDNS. >> >>> The VSP could do it with config >> >> And I don't think this needs to be specified any further. The config >> mechanisms for ATAs and soft clients are various and many. >> >>> It would be very nice to have some more universal mechanism. >>> I have an idea, but I'd better run it by some experts before I get >>> seriously >>> singed. >> >> I agree, a more universal mechanism is better. It's annoying to re- >> invent this type of thing for every application. >> >> -andy > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 20 14:09:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14cC-0006GP-UK; Wed, 20 Jun 2007 14:09:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14cB-0006Cn-DN for ecrit@ietf.org; Wed, 20 Jun 2007 14:09:11 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I14cA-0003uQ-W4 for ecrit@ietf.org; Wed, 20 Jun 2007 14:09:11 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I14c0-00049V-5U; Wed, 20 Jun 2007 13:09:00 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" References: <467800C8.6030009@bbn.com><002601c7b294$7243fa30$220d0d0a@amer.cisco.com><9841613C-5EAB-47D4-BA71-35F732B27248@hxr.us> <8E1BCF9A-1E6A-420C-B46E-84F89E303535@hxr.us> <029f01c7b2d9$64e95890$640fa8c0@cis.neustar.com> <03df01c7b34c$889e7180$640fa8c0@cis.neustar.com> Subject: RE: [Ecrit] Architecture comparisons Date: Wed, 20 Jun 2007 14:09:07 -0400 Message-ID: <046001c7b366$1a24e490$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcezXQAyFV5xA3/ZSfWPUq5gUyQvhwABuZdQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I checked; there are already some SRVs in the ccTLDs: dig _nicname._tcp.us srv My local DNS expert (Ed Lewis) didn't bat an eyelash when I asked. The point of this is that the ccTLDs already have the delegations, so we don't have to get into another ENUM mess. The problem devolves to having the ccTLD operator decide that the entity wanting to load the SRV was the right one. I think that could work pretty well; they are, after all, local. I would make this mechanism third: if your ISP AND your VSP don't get you to a LoST server that can route, use the ccTLD entry where you are. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, June 20, 2007 1:04 PM > To: Brian Rosen > Cc: ECRIT > Subject: Re: [Ecrit] Architecture comparisons > > Brian: > > Practically speaking, inserting things directly under .ccltd is > probably difficult. I'm also not convinced that this is a problem we > need to solve immediately, given that most systems will get > configuration information from their VSP. > > For the VSP model, we have two choices: > > - leverage SIP configuration, now in SIPPING WG LC; it picks the SIP > subscription address based on the AOR > > - creating a look-up from the host part of the AOR, via NAPTR; this > is essentially already in the draft. We only need to add one > sentence: "A SIP user agent uses the host part of its SIP AOR." Done. > > For the non-VSP model, there is the danger of re-creating the global > ENUM problem, i.e., agreeing on a common root. I happen to think that > the model used for finding DNS root servers, namely anycast, would be > a better one. It provides a low-level redundancy that is highly > robust and avoids having to start with a country code. > > I'm not opposed to something like us.lost.org (just to make up > something), but it would be nice to have something that can be done > by a grassroots effort, rather than getting ICANN and/or the ITU > involved. Determining who can speak for the public safety community > in each country is non-trivial; the equivalent (determining the local > authority in charge of E.164) made global ENUM such a pain. (I was on > the IAB during that discussion, so I can attest to the pain and > suffering. And it's still not working.) > > Henning > > On Jun 20, 2007, at 11:06 AM, Brian Rosen wrote: > > > Well, my suggestion may not solve the general case. > > > > Put an SRV for LoST in the root of the ccTLD (e.g. in .us) > > For most countries, that's pretty much exactly what you want. > > > > For places like the U.S., configuration of the domain may be > > complex to > > spread the load on multiple servers that may or may not be operated > > by the > > same entity, but we can do that. Of course we could also put one > > in .pa.us > > for example. It's pretty straightforward to get a country code, > > and even if > > you are off, the FG thing ought to work. > > > > I'd make a priority order of first ISP, then VSP then ccTLD. > > > > Reverse DNS may be needed to get the domain of the ISP. Was that > > what you > > were thinking? > > > > mDNS clearly should be an alternative. > > > > Brian > > > >> -----Original Message----- > >> From: Andrew Newton [mailto:andy@hxr.us] > >> Sent: Wednesday, June 20, 2007 8:40 AM > >> To: Brian Rosen > >> Cc: 'Winterbottom, James'; 'Dawson, Martin'; 'ECRIT' > >> Subject: Re: [Ecrit] Architecture comparisons > >> > >> > >> On Jun 19, 2007, at 9:21 PM, Brian Rosen wrote: > >> > >>> Okay so: > >>> The ISP supplies a DHCP entry and/or a DNS entry for the domain > >> > >> There's also rev. DNS and mDNS. > >> > >>> The VSP could do it with config > >> > >> And I don't think this needs to be specified any further. The config > >> mechanisms for ATAs and soft clients are various and many. > >> > >>> It would be very nice to have some more universal mechanism. > >>> I have an idea, but I'd better run it by some experts before I get > >>> seriously > >>> singed. > >> > >> I agree, a more universal mechanism is better. It's annoying to re- > >> invent this type of thing for every application. > >> > >> -andy > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 20 14:25:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14rq-0002D3-IX; Wed, 20 Jun 2007 14:25:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14rp-0002C0-Ay for ecrit@ietf.org; Wed, 20 Jun 2007 14:25:21 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I14rn-0008OT-LV for ecrit@ietf.org; Wed, 20 Jun 2007 14:25:20 -0400 Received: from [10.2.4.97] (vbn.0050420.lodgenet.net [209.19.49.10]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5KIPDmg021969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Jun 2007 14:25:18 -0400 (EDT) In-Reply-To: <046001c7b366$1a24e490$640fa8c0@cis.neustar.com> References: <467800C8.6030009@bbn.com><002601c7b294$7243fa30$220d0d0a@amer.cisco.com><9841613C-5EAB-47D4-BA71-35F732B27248@hxr.us> <8E1BCF9A-1E6A-420C-B46E-84F89E303535@hxr.us> <029f01c7b2d9$64e95890$640fa8c0@cis.neustar.com> <03df01c7b34c$889e7180$640fa8c0@cis.neustar.com> <046001c7b366$1a24e490$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Architecture comparisons Date: Wed, 20 Jun 2007 14:25:12 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 20, 2007, at 2:09 PM, Brian Rosen wrote: > I checked; there are already some SRVs in the ccTLDs: > dig _nicname._tcp.us srv > This is a service operated directly by the ccTLD operator, so there is no issue with the NIC figuring out who represents PSAPs in the US, particularly if, say, two large commercial database operators both stand up and say "it's me!". Or, in the US, NENA and APCO. > My local DNS expert (Ed Lewis) didn't bat an eyelash when I asked. > > The point of this is that the ccTLDs already have the delegations, > so we > don't have to get into another ENUM mess. The problem devolves to > having This was exactly the same problem for ENUM. It also relied (partially) on national ccTLDs, but they were not the same entities that managed the local E.164 space. The ccTLDs don't know anything about local PSAP politics. > the ccTLD operator decide that the entity wanting to load the SRV > was the > right one. I think that could work pretty well; they are, after > all, local. > > I would make this mechanism third: if your ISP AND your VSP don't > get you to > a LoST server that can route, use the ccTLD entry where you are. > > Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 20 14:38:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I154r-0002k6-O3; Wed, 20 Jun 2007 14:38:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I154q-0002jx-6S for ecrit@ietf.org; Wed, 20 Jun 2007 14:38:48 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I154o-0001lY-Si for ecrit@ietf.org; Wed, 20 Jun 2007 14:38:48 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I154d-0001GV-IU; Wed, 20 Jun 2007 13:38:35 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" References: <467800C8.6030009@bbn.com><002601c7b294$7243fa30$220d0d0a@amer.cisco.com><9841613C-5EAB-47D4-BA71-35F732B27248@hxr.us> <8E1BCF9A-1E6A-420C-B46E-84F89E303535@hxr.us> <029f01c7b2d9$64e95890$640fa8c0@cis.neustar.com> <03df01c7b34c$889e7180$640fa8c0@cis.neustar.com> <046001c7b366$1a24e490$640fa8c0@cis.neustar.com> Subject: RE: [Ecrit] Architecture comparisons Date: Wed, 20 Jun 2007 14:38:43 -0400 Message-ID: <047701c7b36a$3ca79770$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcezaFUn63Ov8wpLSsCFucH1NqyVOgAANu+Q X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I wouldn't dare speak to anything other than the part I know about. If APCO and NENA came to Neustar (the .us ccTLD operator) and both asked for the SRV to point to them, we would ask both the DoC (who contracts with us for .us domain operation) and the FCC what we should do. We would get an answer. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, June 20, 2007 2:25 PM > To: Brian Rosen > Cc: 'ECRIT' > Subject: Re: [Ecrit] Architecture comparisons > > > On Jun 20, 2007, at 2:09 PM, Brian Rosen wrote: > > > I checked; there are already some SRVs in the ccTLDs: > > dig _nicname._tcp.us srv > > > > This is a service operated directly by the ccTLD operator, so there > is no issue with the NIC figuring out who represents PSAPs in the US, > particularly if, say, two large commercial database operators both > stand up and say "it's me!". Or, in the US, NENA and APCO. > > > My local DNS expert (Ed Lewis) didn't bat an eyelash when I asked. > > > > > > > The point of this is that the ccTLDs already have the delegations, > > so we > > don't have to get into another ENUM mess. The problem devolves to > > having > > This was exactly the same problem for ENUM. It also relied > (partially) on national ccTLDs, but they were not the same entities > that managed the local E.164 space. The ccTLDs don't know anything > about local PSAP politics. > > > the ccTLD operator decide that the entity wanting to load the SRV > > was the > > right one. I think that could work pretty well; they are, after > > all, local. > > > > I would make this mechanism third: if your ISP AND your VSP don't > > get you to > > a LoST server that can route, use the ccTLD entry where you are. > > > > Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 20 15:09:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I15Y0-0007AE-Ir; Wed, 20 Jun 2007 15:08:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I15Xz-0007A7-QQ for ecrit@ietf.org; Wed, 20 Jun 2007 15:08:55 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I15Xy-000763-G6 for ecrit@ietf.org; Wed, 20 Jun 2007 15:08:55 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Wed, 20 Jun 2007 15:08:52 -0400 id 015880F0.46797B45.000008D7 In-Reply-To: References: <467800C8.6030009@bbn.com><002601c7b294$7243fa30$220d0d0a@amer.cisco.com><9841613C-5EAB-47D4-BA71-35F732B27248@hxr.us> <8E1BCF9A-1E6A-420C-B46E-84F89E303535@hxr.us> <029f01c7b2d9$64e95890$640fa8c0@cis.neustar.com> <03df01c7b34c$889e7180$640fa8c0@cis.neustar.com> <046001c7b366$1a24e490$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Architecture comparisons Date: Wed, 20 Jun 2007 15:08:50 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 20, 2007, at 2:25 PM, Henning Schulzrinne wrote: > > On Jun 20, 2007, at 2:09 PM, Brian Rosen wrote: > >> I checked; there are already some SRVs in the ccTLDs: >> dig _nicname._tcp.us srv >> It would be a NAPTR record, btw. I'm not sure what the hang-up is with SRV. > > This was exactly the same problem for ENUM. It also relied > (partially) on national ccTLDs, but they were not the same entities > that managed the local E.164 space. The ccTLDs don't know anything > about local PSAP politics. I agree with Henning. There might end up being only a smattering of countries that put in the correct NAPTR record. However, as a third tier mechanism, I don't think it is harmful. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jun 26 03:22:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I35No-0002YH-K9; Tue, 26 Jun 2007 03:22:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I35Nm-0002Y8-GL for ecrit@ietf.org; Tue, 26 Jun 2007 03:22:38 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I35Ng-0007iE-F3 for ecrit@ietf.org; Tue, 26 Jun 2007 03:22:38 -0400 Received: (qmail invoked by alias); 26 Jun 2007 07:15:51 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp029) with SMTP; 26 Jun 2007 09:15:51 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/9hsQZcoj95vplCpaTXaTzzln8ampa7Um9RycNXr 2gqwJalDR8opeU Message-ID: <4680BD27.1030800@gmx.net> Date: Tue, 26 Jun 2007 09:15:51 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Ecrit] [Fwd: [RFC State] has been added to RFC Editor database] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org We are making progress! -------- Original Message -------- Subject: [RFC State] has been added to RFC Editor database Date: Mon, 25 Jun 2007 15:42:51 -0700 (PDT) From: rfc-editor@rfc-editor.org To: hgs+ecrit@cs.columbia.edu, rmarshall@telecomsys.com CC: ecrit-ads@tools.ietf.org, ecrit-chairs@tools.ietf.org, rfc-editor@rfc-editor.org Author(s) We have received notice that your document draft-ietf-ecrit-requirements-13 has been approved for publication as an RFC. The document has been added to the RFC-Editor queue and you can check the status at If you created this document using -ms nroff, please send us the source file. If you have an xml source file that can be converted using the xml2rfc tool at , please send us the file now. This should help increase the pace with which documents move through the RFC-Editor queue. Please let us know if you have any questions. Thank you. The RFC-Editor Team _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 27 21:39:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3iys-00015m-IT; Wed, 27 Jun 2007 21:39:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3iyr-00014L-Vd for ecrit@ietf.org; Wed, 27 Jun 2007 21:39:33 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3iyn-0002i9-Ni for ecrit@ietf.org; Wed, 27 Jun 2007 21:39:33 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I3iyl-0001Zb-3v for ecrit@ietf.org; Wed, 27 Jun 2007 21:39:27 -0400 Message-ID: <4683114D.8070305@bbn.com> Date: Wed, 27 Jun 2007 21:39:25 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ecrit] Location hiding: VSP verification by UAS X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org So, the "location hiding" problem is really two problems: When the access network provisions location in a way that the endpoint can't get the location, (1) How does the endpoint or VSP route and emergency call? and (2) How can a VSP verify that a call is an emergency call? To date, solutions to the second problem have focused on performing this verification based on information in the INVITE. In a location hiding context, this approach runs into the problem that in order to use LoST to verify the To: URI, either the UAC, the VSP, or a LoST server has to dereference the location, and none of these is necessarily authorized to do so. On the other hand, I think the second problem is pretty easy to solve if the VSP is willing to transmit the INVITE and allow the UAS to provide evidence that the call is an emergency call. The PSAP, after all, is in a much better position to authenticate itself than the UAC is to authenticate it. This authentication could take several forms: 1. If VSPs are willing to trust the LoST infrastructure, the PSAP could include its service area in its 200 response; the VSP would verify by performing a LoST query with the location and service URN in the SIP traffic, and compare the element in the resulting mapping to the To: address in the INVITE transaction. 2. If PSAPs have credentials, then the PSAP could use connected-identity to assert its identity (or just use S/MIME to sign a 200 response with it's key). Both of these can be done with protocols that are already released or in process: Option 1 by including a GML or PIDF-LO document in the 200 response (possibly indicated by a Geolocation: header), and Option 2 with S/MIME or connected-identity. Humbly submitted, --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jun 27 23:57:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3l8G-0004HL-8k; Wed, 27 Jun 2007 23:57:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3l8F-0004H5-21 for ecrit@ietf.org; Wed, 27 Jun 2007 23:57:23 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3l85-0000ju-Et for ecrit@ietf.org; Wed, 27 Jun 2007 23:57:23 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 27 Jun 2007 23:57:08 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAC/OgkZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,468,1175486400"; d="scan'208"; a="63865414:sNHT31857632" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5S3v7GQ030053; Wed, 27 Jun 2007 23:57:07 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5S3v3Lf011324; Thu, 28 Jun 2007 03:57:03 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 23:57:03 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.20.194]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 23:57:02 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Jun 2007 22:57:01 -0500 To: Richard Barnes , ECRIT From: "James M. Polk" Subject: Re: [Ecrit] Location hiding: VSP verification by UAS In-Reply-To: <4683114D.8070305@bbn.com> References: <4683114D.8070305@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 28 Jun 2007 03:57:02.0894 (UTC) FILETIME=[62B8E4E0:01C7B938] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2345; t=1183003027; x=1183867027; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Location=20hiding=3A=20VSP=20verification=2 0by=20UAS |Sender:=20 |To:=20Richard=20Barnes=20,=20ECRIT=20; bh=qrzMtFFO5JM3l/3RI/GqWD+FsWOCzDyN3SKrJcN3AEQ=; b=Q+A3MII6e1j3W10JCq/Gam1hoyawcKBmspfjJkDxr4L4msCleRNRd4fTCut0eRTSe33J/tWH VMtpzog2dvO0DvwdbygIY1R5OXYbMRYaGPyUhvj68Owg14FBX5ev4Bgm; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I need to see each proposed message flow. SIP is an e2e protocol, and a 200Ok to an INVITE means the INVITE was accepted as is - and is intended to travel all the way back to the original UAC. SIP doesn't error responses, which is what I feel you are proposing if the authentication fails (within a VSP proxy). At 08:39 PM 6/27/2007, Richard Barnes wrote: >So, the "location hiding" problem is really two problems: When the >access network provisions location in a way that the endpoint can't >get the location, >(1) How does the endpoint or VSP route and emergency call? and >(2) How can a VSP verify that a call is an emergency call? > >To date, solutions to the second problem have focused on performing >this verification based on information in the INVITE. In a location >hiding context, this approach runs into the problem that in order to >use LoST to verify the To: URI, either the UAC, the VSP, or a LoST >server has to dereference the location, and none of these is >necessarily authorized to do so. > >On the other hand, I think the second problem is pretty easy to >solve if the VSP is willing to transmit the INVITE and allow the UAS >to provide evidence that the call is an emergency call. The PSAP, >after all, is in a much better position to authenticate itself than >the UAC is to authenticate it. This authentication could take several forms: > >1. If VSPs are willing to trust the LoST infrastructure, the PSAP >could include its service area in its 200 response; the VSP would >verify by performing a LoST query with the location and service URN >in the SIP traffic, and compare the element in the resulting >mapping to the To: address in the INVITE transaction. > >2. If PSAPs have credentials, then the PSAP could use >connected-identity to assert its identity (or just use S/MIME to >sign a 200 response with it's key). > >Both of these can be done with protocols that are already released >or in process: Option 1 by including a GML or PIDF-LO document in >the 200 response (possibly indicated by a Geolocation: header), and >Option 2 with S/MIME or connected-identity. > >Humbly submitted, >--Richard > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 28 00:29:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ldW-00081u-36; Thu, 28 Jun 2007 00:29:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ldU-00080o-Cx for ecrit@ietf.org; Thu, 28 Jun 2007 00:29:40 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3ldQ-00087W-1n for ecrit@ietf.org; Thu, 28 Jun 2007 00:29:40 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I3ldP-0002mo-4Y; Thu, 28 Jun 2007 00:29:35 -0400 Message-ID: <4683392D.8020106@bbn.com> Date: Thu, 28 Jun 2007 00:29:33 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] Location hiding: VSP verification by UAS References: <4683114D.8070305@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi James, > I need to see each proposed message flow. I was proposing more the conceptual flow of the UAS providing the authentication information than a specific message flow. There are many models that could be used: Authenticators could be conveyed in a 200, or in a separate UPDATE transaction (as in connected-identity). > SIP is an e2e protocol, and a > 200Ok to an INVITE means the INVITE was accepted as is - and is intended > to travel all the way back to the original UAC. SIP doesn't error > responses, which is what I feel you are proposing if the authentication > fails (within a VSP proxy). I don't think that it's necessarily within the purview of ECRIT to specify the behavior that results from a failed authentication. In fact, I expect that this behavior will vary widely from VSP to VSP: One VSP might allow the call to proceed normally, but start billing for it after the authentication fails. Another might use a B2BUA that it inserted in the path to kill the call. Et cetera. The essential thing is that allowing the UAS to provide authenticators allows the PSAP to vouch for the fact that a call is an emergency call, regardless of how location is provisioned. What the VSP chooses to do with that information is a local decision (though maybe we could make some non-normative recommendations). --Richard > > At 08:39 PM 6/27/2007, Richard Barnes wrote: >> So, the "location hiding" problem is really two problems: When the >> access network provisions location in a way that the endpoint can't >> get the location, >> (1) How does the endpoint or VSP route and emergency call? and >> (2) How can a VSP verify that a call is an emergency call? >> >> To date, solutions to the second problem have focused on performing >> this verification based on information in the INVITE. In a location >> hiding context, this approach runs into the problem that in order to >> use LoST to verify the To: URI, either the UAC, the VSP, or a LoST >> server has to dereference the location, and none of these is >> necessarily authorized to do so. >> >> On the other hand, I think the second problem is pretty easy to solve >> if the VSP is willing to transmit the INVITE and allow the UAS to >> provide evidence that the call is an emergency call. The PSAP, after >> all, is in a much better position to authenticate itself than the UAC >> is to authenticate it. This authentication could take several forms: >> >> 1. If VSPs are willing to trust the LoST infrastructure, the PSAP >> could include its service area in its 200 response; the VSP would >> verify by performing a LoST query with the location and service URN in >> the SIP traffic, and compare the element in the resulting >> mapping to the To: address in the INVITE transaction. >> >> 2. If PSAPs have credentials, then the PSAP could use >> connected-identity to assert its identity (or just use S/MIME to sign >> a 200 response with it's key). >> >> Both of these can be done with protocols that are already released or >> in process: Option 1 by including a GML or PIDF-LO document in the 200 >> response (possibly indicated by a Geolocation: header), and Option 2 >> with S/MIME or connected-identity. >> >> Humbly submitted, >> --Richard >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 28 01:59:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3n2P-0007K8-3m; Thu, 28 Jun 2007 01:59:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3n2N-0007K3-T1 for ecrit@ietf.org; Thu, 28 Jun 2007 01:59:27 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3n27-0001Rj-Rv for ecrit@ietf.org; Thu, 28 Jun 2007 01:59:27 -0400 X-SEF-Processed: 5_0_0_910__2007_06_28_01_06_54 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 28 Jun 2007 01:06:53 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jun 2007 00:58:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Location hiding: VSP verification by UAS Date: Thu, 28 Jun 2007 00:58:55 -0500 Message-ID: In-Reply-To: <4683392D.8020106@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Location hiding: VSP verification by UAS Thread-Index: Ace5PPPbBbvDAnwGQ3u5ye4vtJWCWQADFoCQ References: <4683114D.8070305@bbn.com> <4683392D.8020106@bbn.com> From: "Winterbottom, James" To: "Richard Barnes" , "James M. Polk" X-OriginalArrivalTime: 28 Jun 2007 05:58:57.0336 (UTC) FILETIME=[6A782B80:01C7B949] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hey Richard,=0D=0A=0D=0AA lot of large call-servers from what I understand = operate as B2BUA=0D=0Aanyway. So that may be something that you can leverag= e.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D=0A> -----Original Message-----=0D=0A= > From: Richard Barnes [mailto:rbarnes@bbn.com]=0D=0A> Sent: Thursday, 28 J= une 2007 2:30 PM=0D=0A> To: James M. Polk=0D=0A> Cc: ECRIT=0D=0A> Subject: = Re: [Ecrit] Location hiding: VSP verification by UAS=0D=0A>=20=0D=0A> Hi Ja= mes,=0D=0A>=20=0D=0A> > I need to see each proposed message flow.=0D=0A> =0D= =0A> I was proposing more the conceptual flow of the UAS providing the=0D=0A= > authentication information than a specific message flow. There are=0D=0A= many=0D=0A> models that could be used: Authenticators could be conveyed in = a 200,=0D=0Aor=0D=0A> in a separate UPDATE transaction (as in connected-ide= ntity).=0D=0A>=20=0D=0A> > SIP is an e2e protocol, and a=0D=0A> > 200Ok to = an INVITE means the INVITE was accepted as is - and is=0D=0Aintended=0D=0A>= > to travel all the way back to the original UAC. SIP doesn't error=0D=0A>= > responses, which is what I feel you are proposing if the=0D=0Aauthentica= tion=0D=0A> > fails (within a VSP proxy).=0D=0A>=20=0D=0A> I don't think th= at it's necessarily within the purview of ECRIT to=0D=0A> specify the behav= ior that results from a failed authentication. In=0D=0A> fact, I expect th= at this behavior will vary widely from VSP to VSP:=0D=0AOne=0D=0A> VSP migh= t allow the call to proceed normally, but start billing for it=0D=0A> after= the authentication fails. Another might use a B2BUA that it=0D=0A> insert= ed in the path to kill the call. Et cetera.=0D=0A>=20=0D=0A> The essential= thing is that allowing the UAS to provide authenticators=0D=0A> allows the= PSAP to vouch for the fact that a call is an emergency=0D=0Acall,=0D=0A> r= egardless of how location is provisioned. What the VSP chooses to do=0D=0A= > with that information is a local decision (though maybe we could make=0D=0A= > some non-normative recommendations).=0D=0A>=20=0D=0A> --Richard=0D=0A> =0D= =0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> >=0D=0A> > At 08:39 PM 6/27/20= 07, Richard Barnes wrote:=0D=0A> >> So, the "location hiding" problem is re= ally two problems: When the=0D=0A> >> access network provisions location in= a way that the endpoint can't=0D=0A> >> get the location,=0D=0A> >> (1) Ho= w does the endpoint or VSP route and emergency call=3F and=0D=0A> >> (2) Ho= w can a VSP verify that a call is an emergency call=3F=0D=0A> >>=0D=0A> >> = To date, solutions to the second problem have focused on performing=0D=0A> = >> this verification based on information in the INVITE. In a=0D=0Alocatio= n=0D=0A> >> hiding context, this approach runs into the problem that in ord= er=0D=0Ato=0D=0A> >> use LoST to verify the To: URI, either the UAC, the VS= P, or a LoST=0D=0A> >> server has to dereference the location, and none of = these is=0D=0A> >> necessarily authorized to do so.=0D=0A> >>=0D=0A> >> On = the other hand, I think the second problem is pretty easy to=0D=0Asolve=0D=0A= > >> if the VSP is willing to transmit the INVITE and allow the UAS to=0D=0A= > >> provide evidence that the call is an emergency call. The PSAP,=0D=0Aa= fter=0D=0A> >> all, is in a much better position to authenticate itself tha= n the=0D=0AUAC=0D=0A> >> is to authenticate it. This authentication could = take several=0D=0Aforms:=0D=0A> >>=0D=0A> >> 1. If VSPs are willing to trus= t the LoST infrastructure, the PSAP=0D=0A> >> could include its service are= a in its 200 response; the VSP would=0D=0A> >> verify by performing a LoST = query with the location and service URN=0D=0Ain=0D=0A> >> the SIP traffic, = and compare the element in the resulting=0D=0A> >> mapping to the To:= address in the INVITE transaction.=0D=0A> >>=0D=0A> >> 2. If PSAPs have cr= edentials, then the PSAP could use=0D=0A> >> connected-identity to assert i= ts identity (or just use S/MIME to=0D=0Asign=0D=0A> >> a 200 response with = it's key).=0D=0A> >>=0D=0A> >> Both of these can be done with protocols tha= t are already released=0D=0Aor=0D=0A> >> in process: Option 1 by including = a GML or PIDF-LO document in the=0D=0A200=0D=0A> >> response (possibly indi= cated by a Geolocation: header), and Option=0D=0A2=0D=0A> >> with S/MIME or= connected-identity.=0D=0A> >>=0D=0A> >> Humbly submitted,=0D=0A> >> --Rich= ard=0D=0A> >>=0D=0A> >>=0D=0A> >> _________________________________________= ______=0D=0A> >> Ecrit mailing list=0D=0A> >> Ecrit@ietf.org=0D=0A> >> http= s://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> >=0D=0A> >=0D=0A>=20=0D=0A>= =20=0D=0A>=20=0D=0A> _______________________________________________=0D=0A>= Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mail= man/listinfo/ecrit=0D=0A=0D=0A---------------------------------------------= ---------------------------------------------------=0D=0AThis message is fo= r the designated recipient only and may=0D=0Acontain privileged, proprietar= y, or otherwise private information. =20=0D=0AIf you have received it in er= ror, please notify the sender=0D=0Aimmediately and delete the original. An= y unauthorized use of=0D=0Athis email is prohibited.=0D=0A-----------------= ---------------------------------------------------------------------------= ----=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 28 07:55:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3sbI-0001Eq-0S; Thu, 28 Jun 2007 07:55:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3sbG-0001Eg-IJ for ecrit@ietf.org; Thu, 28 Jun 2007 07:55:50 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3sbG-000848-7W for ecrit@ietf.org; Thu, 28 Jun 2007 07:55:50 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I3sak-00050n-FQ; Thu, 28 Jun 2007 06:55:19 -0500 From: "Brian Rosen" To: "'Richard Barnes'" , "'James M. Polk'" References: <4683114D.8070305@bbn.com> <4683392D.8020106@bbn.com> Subject: RE: [Ecrit] Location hiding: VSP verification by UAS Date: Thu, 28 Jun 2007 07:55:18 -0400 Message-ID: <024401c7b97b$3639c4a0$a0acf444@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4683392D.8020106@bbn.com> Thread-Index: Ace5PPMJYK7G+xPQR5an75+RItRdXAAPhUbg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org We would have to do it with an Update. I am uncomfortable with this idea, as it complicates the message flow on every emergency call. The basic idea has merit, but the details don't work for me. Brian > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Thursday, June 28, 2007 12:30 AM > To: James M. Polk > Cc: ECRIT > Subject: Re: [Ecrit] Location hiding: VSP verification by UAS > > Hi James, > > > I need to see each proposed message flow. > > I was proposing more the conceptual flow of the UAS providing the > authentication information than a specific message flow. There are many > models that could be used: Authenticators could be conveyed in a 200, or > in a separate UPDATE transaction (as in connected-identity). > > > SIP is an e2e protocol, and a > > 200Ok to an INVITE means the INVITE was accepted as is - and is intended > > to travel all the way back to the original UAC. SIP doesn't error > > responses, which is what I feel you are proposing if the authentication > > fails (within a VSP proxy). > > I don't think that it's necessarily within the purview of ECRIT to > specify the behavior that results from a failed authentication. In > fact, I expect that this behavior will vary widely from VSP to VSP: One > VSP might allow the call to proceed normally, but start billing for it > after the authentication fails. Another might use a B2BUA that it > inserted in the path to kill the call. Et cetera. > > The essential thing is that allowing the UAS to provide authenticators > allows the PSAP to vouch for the fact that a call is an emergency call, > regardless of how location is provisioned. What the VSP chooses to do > with that information is a local decision (though maybe we could make > some non-normative recommendations). > > --Richard > > > > > > > > > At 08:39 PM 6/27/2007, Richard Barnes wrote: > >> So, the "location hiding" problem is really two problems: When the > >> access network provisions location in a way that the endpoint can't > >> get the location, > >> (1) How does the endpoint or VSP route and emergency call? and > >> (2) How can a VSP verify that a call is an emergency call? > >> > >> To date, solutions to the second problem have focused on performing > >> this verification based on information in the INVITE. In a location > >> hiding context, this approach runs into the problem that in order to > >> use LoST to verify the To: URI, either the UAC, the VSP, or a LoST > >> server has to dereference the location, and none of these is > >> necessarily authorized to do so. > >> > >> On the other hand, I think the second problem is pretty easy to solve > >> if the VSP is willing to transmit the INVITE and allow the UAS to > >> provide evidence that the call is an emergency call. The PSAP, after > >> all, is in a much better position to authenticate itself than the UAC > >> is to authenticate it. This authentication could take several forms: > >> > >> 1. If VSPs are willing to trust the LoST infrastructure, the PSAP > >> could include its service area in its 200 response; the VSP would > >> verify by performing a LoST query with the location and service URN in > >> the SIP traffic, and compare the element in the resulting > >> mapping to the To: address in the INVITE transaction. > >> > >> 2. If PSAPs have credentials, then the PSAP could use > >> connected-identity to assert its identity (or just use S/MIME to sign > >> a 200 response with it's key). > >> > >> Both of these can be done with protocols that are already released or > >> in process: Option 1 by including a GML or PIDF-LO document in the 200 > >> response (possibly indicated by a Geolocation: header), and Option 2 > >> with S/MIME or connected-identity. > >> > >> Humbly submitted, > >> --Richard > >> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 28 09:24:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3tzJ-0004fh-Ht; Thu, 28 Jun 2007 09:24:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3tzI-0004f5-K1 for ecrit@ietf.org; Thu, 28 Jun 2007 09:24:44 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3tz2-0001ds-W8 for ecrit@ietf.org; Thu, 28 Jun 2007 09:24:44 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 28 Jun 2007 09:19:13 -0400 id 01588454.4683B551.000017BD In-Reply-To: <024401c7b97b$3639c4a0$a0acf444@cis.neustar.com> References: <4683114D.8070305@bbn.com> <4683392D.8020106@bbn.com> <024401c7b97b$3639c4a0$a0acf444@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <08904E1F-0EB8-46B5-AC2A-D6CB74C239B5@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Location hiding: VSP verification by UAS Date: Thu, 28 Jun 2007 09:19:10 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I don't see how an UPDATE helps. And the endpoint can simply not issue the UPDATE to get around the verification. I think Richard's proposal has legs. -andy On Jun 28, 2007, at 7:55 AM, Brian Rosen wrote: > We would have to do it with an Update. > > I am uncomfortable with this idea, as it complicates the message > flow on > every emergency call. > > The basic idea has merit, but the details don't work for me. > > Brian > >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Thursday, June 28, 2007 12:30 AM >> To: James M. Polk >> Cc: ECRIT >> Subject: Re: [Ecrit] Location hiding: VSP verification by UAS >> >> Hi James, >> >>> I need to see each proposed message flow. >> >> I was proposing more the conceptual flow of the UAS providing the >> authentication information than a specific message flow. There >> are many >> models that could be used: Authenticators could be conveyed in a >> 200, or >> in a separate UPDATE transaction (as in connected-identity). >> >>> SIP is an e2e protocol, and a >>> 200Ok to an INVITE means the INVITE was accepted as is - and is >>> intended >>> to travel all the way back to the original UAC. SIP doesn't error >>> responses, which is what I feel you are proposing if the >>> authentication >>> fails (within a VSP proxy). >> >> I don't think that it's necessarily within the purview of ECRIT to >> specify the behavior that results from a failed authentication. In >> fact, I expect that this behavior will vary widely from VSP to >> VSP: One >> VSP might allow the call to proceed normally, but start billing >> for it >> after the authentication fails. Another might use a B2BUA that it >> inserted in the path to kill the call. Et cetera. >> >> The essential thing is that allowing the UAS to provide >> authenticators >> allows the PSAP to vouch for the fact that a call is an emergency >> call, >> regardless of how location is provisioned. What the VSP chooses >> to do >> with that information is a local decision (though maybe we could make >> some non-normative recommendations). >> >> --Richard >> >> >> >> >> >>> >>> At 08:39 PM 6/27/2007, Richard Barnes wrote: >>>> So, the "location hiding" problem is really two problems: When the >>>> access network provisions location in a way that the endpoint can't >>>> get the location, >>>> (1) How does the endpoint or VSP route and emergency call? and >>>> (2) How can a VSP verify that a call is an emergency call? >>>> >>>> To date, solutions to the second problem have focused on performing >>>> this verification based on information in the INVITE. In a >>>> location >>>> hiding context, this approach runs into the problem that in >>>> order to >>>> use LoST to verify the To: URI, either the UAC, the VSP, or a LoST >>>> server has to dereference the location, and none of these is >>>> necessarily authorized to do so. >>>> >>>> On the other hand, I think the second problem is pretty easy to >>>> solve >>>> if the VSP is willing to transmit the INVITE and allow the UAS to >>>> provide evidence that the call is an emergency call. The PSAP, >>>> after >>>> all, is in a much better position to authenticate itself than >>>> the UAC >>>> is to authenticate it. This authentication could take several >>>> forms: >>>> >>>> 1. If VSPs are willing to trust the LoST infrastructure, the PSAP >>>> could include its service area in its 200 response; the VSP would >>>> verify by performing a LoST query with the location and service >>>> URN in >>>> the SIP traffic, and compare the element in the resulting >>>> mapping to the To: address in the INVITE transaction. >>>> >>>> 2. If PSAPs have credentials, then the PSAP could use >>>> connected-identity to assert its identity (or just use S/MIME to >>>> sign >>>> a 200 response with it's key). >>>> >>>> Both of these can be done with protocols that are already >>>> released or >>>> in process: Option 1 by including a GML or PIDF-LO document in >>>> the 200 >>>> response (possibly indicated by a Geolocation: header), and >>>> Option 2 >>>> with S/MIME or connected-identity. >>>> >>>> Humbly submitted, >>>> --Richard >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 28 09:36:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3uB0-0001kC-Qd; Thu, 28 Jun 2007 09:36:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3uB0-0001hk-BG for ecrit@ietf.org; Thu, 28 Jun 2007 09:36:50 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3uB0-0006WG-0W for ecrit@ietf.org; Thu, 28 Jun 2007 09:36:50 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I3uAT-0007mZ-4X; Thu, 28 Jun 2007 09:36:17 -0400 Received: from [127.0.0.1] (col-dhcp33-244-168.bbn.com [128.33.244.168]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l5SDaGh08920; Thu, 28 Jun 2007 09:36:17 -0400 (EDT) Message-ID: <4683B950.5020404@bbn.com> Date: Thu, 28 Jun 2007 09:36:16 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Location hiding: VSP verification by UAS References: <4683114D.8070305@bbn.com> <4683392D.8020106@bbn.com> <024401c7b97b$3639c4a0$a0acf444@cis.neustar.com> <08904E1F-0EB8-46B5-AC2A-D6CB74C239B5@hxr.us> In-Reply-To: <08904E1F-0EB8-46B5-AC2A-D6CB74C239B5@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Right. In either cases, the VSP would be free to consider a call unverified if no authenticator were presented after a certain period (this period would be good to specify in a BCP). --Richard Andrew Newton wrote: > I don't see how an UPDATE helps. And the endpoint can simply not issue > the UPDATE to get around the verification. > > I think Richard's proposal has legs. > > -andy > > On Jun 28, 2007, at 7:55 AM, Brian Rosen wrote: > >> We would have to do it with an Update. >> >> I am uncomfortable with this idea, as it complicates the message flow on >> every emergency call. >> >> The basic idea has merit, but the details don't work for me. >> >> Brian >> >>> -----Original Message----- >>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>> Sent: Thursday, June 28, 2007 12:30 AM >>> To: James M. Polk >>> Cc: ECRIT >>> Subject: Re: [Ecrit] Location hiding: VSP verification by UAS >>> >>> Hi James, >>> >>>> I need to see each proposed message flow. >>> >>> I was proposing more the conceptual flow of the UAS providing the >>> authentication information than a specific message flow. There are many >>> models that could be used: Authenticators could be conveyed in a 200, or >>> in a separate UPDATE transaction (as in connected-identity). >>> >>>> SIP is an e2e protocol, and a >>>> 200Ok to an INVITE means the INVITE was accepted as is - and is >>>> intended >>>> to travel all the way back to the original UAC. SIP doesn't error >>>> responses, which is what I feel you are proposing if the authentication >>>> fails (within a VSP proxy). >>> >>> I don't think that it's necessarily within the purview of ECRIT to >>> specify the behavior that results from a failed authentication. In >>> fact, I expect that this behavior will vary widely from VSP to VSP: One >>> VSP might allow the call to proceed normally, but start billing for it >>> after the authentication fails. Another might use a B2BUA that it >>> inserted in the path to kill the call. Et cetera. >>> >>> The essential thing is that allowing the UAS to provide authenticators >>> allows the PSAP to vouch for the fact that a call is an emergency call, >>> regardless of how location is provisioned. What the VSP chooses to do >>> with that information is a local decision (though maybe we could make >>> some non-normative recommendations). >>> >>> --Richard >>> >>> >>> >>> >>> >>>> >>>> At 08:39 PM 6/27/2007, Richard Barnes wrote: >>>>> So, the "location hiding" problem is really two problems: When the >>>>> access network provisions location in a way that the endpoint can't >>>>> get the location, >>>>> (1) How does the endpoint or VSP route and emergency call? and >>>>> (2) How can a VSP verify that a call is an emergency call? >>>>> >>>>> To date, solutions to the second problem have focused on performing >>>>> this verification based on information in the INVITE. In a location >>>>> hiding context, this approach runs into the problem that in order to >>>>> use LoST to verify the To: URI, either the UAC, the VSP, or a LoST >>>>> server has to dereference the location, and none of these is >>>>> necessarily authorized to do so. >>>>> >>>>> On the other hand, I think the second problem is pretty easy to solve >>>>> if the VSP is willing to transmit the INVITE and allow the UAS to >>>>> provide evidence that the call is an emergency call. The PSAP, after >>>>> all, is in a much better position to authenticate itself than the UAC >>>>> is to authenticate it. This authentication could take several forms: >>>>> >>>>> 1. If VSPs are willing to trust the LoST infrastructure, the PSAP >>>>> could include its service area in its 200 response; the VSP would >>>>> verify by performing a LoST query with the location and service URN in >>>>> the SIP traffic, and compare the element in the resulting >>>>> mapping to the To: address in the INVITE transaction. >>>>> >>>>> 2. If PSAPs have credentials, then the PSAP could use >>>>> connected-identity to assert its identity (or just use S/MIME to sign >>>>> a 200 response with it's key). >>>>> >>>>> Both of these can be done with protocols that are already released or >>>>> in process: Option 1 by including a GML or PIDF-LO document in the 200 >>>>> response (possibly indicated by a Geolocation: header), and Option 2 >>>>> with S/MIME or connected-identity. >>>>> >>>>> Humbly submitted, >>>>> --Richard >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 28 12:15:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3weS-0004pk-Hy; Thu, 28 Jun 2007 12:15:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3weR-0004pa-Oz for ecrit@ietf.org; Thu, 28 Jun 2007 12:15:23 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3weR-0003m1-D3 for ecrit@ietf.org; Thu, 28 Jun 2007 12:15:23 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I3we0-0001vV-N0; Thu, 28 Jun 2007 11:14:57 -0500 From: "Brian Rosen" To: "'Richard Barnes'" , "'Andrew Newton'" References: <4683114D.8070305@bbn.com> <4683392D.8020106@bbn.com> <024401c7b97b$3639c4a0$a0acf444@cis.neustar.com> <08904E1F-0EB8-46B5-AC2A-D6CB74C239B5@hxr.us> <4683B950.5020404@bbn.com> Subject: RE: [Ecrit] Location hiding: VSP verification by UAS Date: Thu, 28 Jun 2007 12:14:57 -0400 Message-ID: <002901c7b99f$7da01410$1772f544@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4683B950.5020404@bbn.com> thread-index: Ace5iU5hlEEgxZgNQhWnORWLievh3wAFe3XQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org To get the location of the PSAP, you need an UPDATE, with the PSAP doing the update and becoming the UAC because it's reliable. Conveyance is defined from UAC to UAS only, for this, among other reasons. Brian > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Thursday, June 28, 2007 9:36 AM > To: Andrew Newton > Cc: Brian Rosen; 'James M. Polk'; 'ECRIT' > Subject: Re: [Ecrit] Location hiding: VSP verification by UAS > > Right. In either cases, the VSP would be free to consider a call > unverified if no authenticator were presented after a certain period > (this period would be good to specify in a BCP). > > --Richard > > > > > Andrew Newton wrote: > > I don't see how an UPDATE helps. And the endpoint can simply not issue > > the UPDATE to get around the verification. > > > > I think Richard's proposal has legs. > > > > -andy > > > > On Jun 28, 2007, at 7:55 AM, Brian Rosen wrote: > > > >> We would have to do it with an Update. > >> > >> I am uncomfortable with this idea, as it complicates the message flow > on > >> every emergency call. > >> > >> The basic idea has merit, but the details don't work for me. > >> > >> Brian > >> > >>> -----Original Message----- > >>> From: Richard Barnes [mailto:rbarnes@bbn.com] > >>> Sent: Thursday, June 28, 2007 12:30 AM > >>> To: James M. Polk > >>> Cc: ECRIT > >>> Subject: Re: [Ecrit] Location hiding: VSP verification by UAS > >>> > >>> Hi James, > >>> > >>>> I need to see each proposed message flow. > >>> > >>> I was proposing more the conceptual flow of the UAS providing the > >>> authentication information than a specific message flow. There are > many > >>> models that could be used: Authenticators could be conveyed in a 200, > or > >>> in a separate UPDATE transaction (as in connected-identity). > >>> > >>>> SIP is an e2e protocol, and a > >>>> 200Ok to an INVITE means the INVITE was accepted as is - and is > >>>> intended > >>>> to travel all the way back to the original UAC. SIP doesn't error > >>>> responses, which is what I feel you are proposing if the > authentication > >>>> fails (within a VSP proxy). > >>> > >>> I don't think that it's necessarily within the purview of ECRIT to > >>> specify the behavior that results from a failed authentication. In > >>> fact, I expect that this behavior will vary widely from VSP to VSP: > One > >>> VSP might allow the call to proceed normally, but start billing for it > >>> after the authentication fails. Another might use a B2BUA that it > >>> inserted in the path to kill the call. Et cetera. > >>> > >>> The essential thing is that allowing the UAS to provide authenticators > >>> allows the PSAP to vouch for the fact that a call is an emergency > call, > >>> regardless of how location is provisioned. What the VSP chooses to do > >>> with that information is a local decision (though maybe we could make > >>> some non-normative recommendations). > >>> > >>> --Richard > >>> > >>> > >>> > >>> > >>> > >>>> > >>>> At 08:39 PM 6/27/2007, Richard Barnes wrote: > >>>>> So, the "location hiding" problem is really two problems: When the > >>>>> access network provisions location in a way that the endpoint can't > >>>>> get the location, > >>>>> (1) How does the endpoint or VSP route and emergency call? and > >>>>> (2) How can a VSP verify that a call is an emergency call? > >>>>> > >>>>> To date, solutions to the second problem have focused on performing > >>>>> this verification based on information in the INVITE. In a location > >>>>> hiding context, this approach runs into the problem that in order to > >>>>> use LoST to verify the To: URI, either the UAC, the VSP, or a LoST > >>>>> server has to dereference the location, and none of these is > >>>>> necessarily authorized to do so. > >>>>> > >>>>> On the other hand, I think the second problem is pretty easy to > solve > >>>>> if the VSP is willing to transmit the INVITE and allow the UAS to > >>>>> provide evidence that the call is an emergency call. The PSAP, > after > >>>>> all, is in a much better position to authenticate itself than the > UAC > >>>>> is to authenticate it. This authentication could take several > forms: > >>>>> > >>>>> 1. If VSPs are willing to trust the LoST infrastructure, the PSAP > >>>>> could include its service area in its 200 response; the VSP would > >>>>> verify by performing a LoST query with the location and service URN > in > >>>>> the SIP traffic, and compare the element in the resulting > >>>>> mapping to the To: address in the INVITE transaction. > >>>>> > >>>>> 2. If PSAPs have credentials, then the PSAP could use > >>>>> connected-identity to assert its identity (or just use S/MIME to > sign > >>>>> a 200 response with it's key). > >>>>> > >>>>> Both of these can be done with protocols that are already released > or > >>>>> in process: Option 1 by including a GML or PIDF-LO document in the > 200 > >>>>> response (possibly indicated by a Geolocation: header), and Option 2 > >>>>> with S/MIME or connected-identity. > >>>>> > >>>>> Humbly submitted, > >>>>> --Richard > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Ecrit mailing list > >>>>> Ecrit@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/ecrit > >>>> > >>>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Ecrit mailing list > >>> Ecrit@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/ecrit > >> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 28 13:48:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3y6p-0000mI-2y; Thu, 28 Jun 2007 13:48:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3y6l-0000l7-KM for ecrit@ietf.org; Thu, 28 Jun 2007 13:48:43 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3y6l-00021A-1t for ecrit@ietf.org; Thu, 28 Jun 2007 13:48:43 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 28 Jun 2007 10:48:23 -0700 X-IronPort-AV: i="4.16,471,1175497200"; d="scan'208"; a="5453097:sNHT2539945092" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5SHmNcJ026591; Thu, 28 Jun 2007 10:48:23 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5SHmNXH000994; Thu, 28 Jun 2007 17:48:23 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 10:48:23 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.16.120]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 10:48:22 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Jun 2007 12:48:21 -0500 To: "Winterbottom, James" , "Richard Barnes" From: "James M. Polk" Subject: RE: [Ecrit] Location hiding: VSP verification by UAS (with B2BUAs?) In-Reply-To: References: <4683114D.8070305@bbn.com> <4683392D.8020106@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 28 Jun 2007 17:48:22.0811 (UTC) FILETIME=[857836B0:01C7B9AC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5486; t=1183052903; x=1183916903; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Ecrit]=20Location=20hiding=3A=20VSP=20verification=2 0by=20UAS=20(with=0A=20=20B2BUAs?) |Sender:=20; bh=Yzd7P4+rRvIJYxBws5fN4N2Ps5YjOlbkr9BK6Kp/Xsc=; b=Hvh5zFgN5g4Vo6unvKf6FY/uFrsgBKq4jcVjmvf6y9fh4+Y5kzrETu6iTgaC/FUbcaO+4BTI 0JEe5aB8IXWdnhCEwaOA76sDEb1HiGNFvb0S0iJXV0fbYTU+36iqZchZQkVFQ+dsmFBgfLYUDv OnnLM7KGDo0ppHbFifRKDfFU8=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 12:58 AM 6/28/2007, Winterbottom, James wrote: >Hey Richard, > >A lot of large call-servers from what I understand operate as B2BUA >anyway. So that may be something that you can leverage. James - the SIP WG has violently agreed B2BUAs cannot be relied upon in a message flow, so I'm not sure how this will work (where's that message flow to show that it will?). Thus, relying on a B2BUA in every message flow means 100% of the time, one will be in the message flow, otherwise this leverage is zero. That's not a good position (no pun intended) to be in. Someone working up a message flow will go a long ways towards showing if this can work, else we're talking in abstracts about something that seriously needs to work all the time. >Cheers >James > > > -----Original Message----- > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > Sent: Thursday, 28 June 2007 2:30 PM > > To: James M. Polk > > Cc: ECRIT > > Subject: Re: [Ecrit] Location hiding: VSP verification by UAS > > > > Hi James, > > > > > I need to see each proposed message flow. > > > > I was proposing more the conceptual flow of the UAS providing the > > authentication information than a specific message flow. There are >many > > models that could be used: Authenticators could be conveyed in a 200, >or > > in a separate UPDATE transaction (as in connected-identity). > > > > > SIP is an e2e protocol, and a > > > 200Ok to an INVITE means the INVITE was accepted as is - and is >intended > > > to travel all the way back to the original UAC. SIP doesn't error > > > responses, which is what I feel you are proposing if the >authentication > > > fails (within a VSP proxy). > > > > I don't think that it's necessarily within the purview of ECRIT to > > specify the behavior that results from a failed authentication. In > > fact, I expect that this behavior will vary widely from VSP to VSP: >One > > VSP might allow the call to proceed normally, but start billing for it > > after the authentication fails. Another might use a B2BUA that it > > inserted in the path to kill the call. Et cetera. > > > > The essential thing is that allowing the UAS to provide authenticators > > allows the PSAP to vouch for the fact that a call is an emergency >call, > > regardless of how location is provisioned. What the VSP chooses to do > > with that information is a local decision (though maybe we could make > > some non-normative recommendations). > > > > --Richard > > > > > > > > > > > > > > > > At 08:39 PM 6/27/2007, Richard Barnes wrote: > > >> So, the "location hiding" problem is really two problems: When the > > >> access network provisions location in a way that the endpoint can't > > >> get the location, > > >> (1) How does the endpoint or VSP route and emergency call? and > > >> (2) How can a VSP verify that a call is an emergency call? > > >> > > >> To date, solutions to the second problem have focused on performing > > >> this verification based on information in the INVITE. In a >location > > >> hiding context, this approach runs into the problem that in order >to > > >> use LoST to verify the To: URI, either the UAC, the VSP, or a LoST > > >> server has to dereference the location, and none of these is > > >> necessarily authorized to do so. > > >> > > >> On the other hand, I think the second problem is pretty easy to >solve > > >> if the VSP is willing to transmit the INVITE and allow the UAS to > > >> provide evidence that the call is an emergency call. The PSAP, >after > > >> all, is in a much better position to authenticate itself than the >UAC > > >> is to authenticate it. This authentication could take several >forms: > > >> > > >> 1. If VSPs are willing to trust the LoST infrastructure, the PSAP > > >> could include its service area in its 200 response; the VSP would > > >> verify by performing a LoST query with the location and service URN >in > > >> the SIP traffic, and compare the element in the resulting > > >> mapping to the To: address in the INVITE transaction. > > >> > > >> 2. If PSAPs have credentials, then the PSAP could use > > >> connected-identity to assert its identity (or just use S/MIME to >sign > > >> a 200 response with it's key). > > >> > > >> Both of these can be done with protocols that are already released >or > > >> in process: Option 1 by including a GML or PIDF-LO document in the >200 > > >> response (possibly indicated by a Geolocation: header), and Option >2 > > >> with S/MIME or connected-identity. > > >> > > >> Humbly submitted, > > >> --Richard > > >> > > >> > > >> _______________________________________________ > > >> Ecrit mailing list > > >> Ecrit@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 28 13:51:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3y9p-0005Tz-Hy; Thu, 28 Jun 2007 13:51:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3y9n-0005Tr-LV for ecrit@ietf.org; Thu, 28 Jun 2007 13:51:51 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3y9V-0006hL-Dq for ecrit@ietf.org; Thu, 28 Jun 2007 13:51:51 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 28 Jun 2007 13:43:52 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOeRg0ZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,471,1175486400"; d="scan'208"; a="124797930:sNHT19987608808" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5SHhp3p031003; Thu, 28 Jun 2007 13:43:51 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5SHhXZF013844; Thu, 28 Jun 2007 17:43:33 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 13:43:32 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.120]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 13:43:32 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Jun 2007 12:43:31 -0500 To: "Brian Rosen" , "'Richard Barnes'" , "'Andrew Newton'" From: "James M. Polk" Subject: RE: [Ecrit] Location hiding: VSP verification by UAS In-Reply-To: <002901c7b99f$7da01410$1772f544@cis.neustar.com> References: <4683114D.8070305@bbn.com> <4683392D.8020106@bbn.com> <024401c7b97b$3639c4a0$a0acf444@cis.neustar.com> <08904E1F-0EB8-46B5-AC2A-D6CB74C239B5@hxr.us> <4683B950.5020404@bbn.com> <002901c7b99f$7da01410$1772f544@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 28 Jun 2007 17:43:32.0520 (UTC) FILETIME=[D8715280:01C7B9AB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6202; t=1183052631; x=1183916631; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Ecrit]=20Location=20hiding=3A=20VSP=20verification=2 0by=20UAS |Sender:=20 |To:=20=22Brian=20Rosen=22=20, =20=22'Richard=20Barnes' =22=20, =0A=20=20=20=20=20=20=20=20=22'Andrew=20Newton'=22 =20; bh=1ElDF5UF7fVuLj1WFbjZ9dPN3+A4NGVfRCqAu3Xa3BQ=; b=tVp/2TReEYPiA6bSyGdWlh0VGM2iai/2ume6/8WU7essmNKCvRL2U85l129QsGUvzLvOXU9Q CgnegOtwf9ZcEC02U6mToAV208lGOCPtZvt+esr8ao+LBMZwTHsAGEaF; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org what he said! James (I need to see a planned message flow to be swayed from this pov) At 11:14 AM 6/28/2007, Brian Rosen wrote: >To get the location of the PSAP, you need an UPDATE, with the PSAP doing the >update and becoming the UAC because it's reliable. Conveyance is defined >from UAC to UAS only, for this, among other reasons. > >Brian > > -----Original Message----- > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > Sent: Thursday, June 28, 2007 9:36 AM > > To: Andrew Newton > > Cc: Brian Rosen; 'James M. Polk'; 'ECRIT' > > Subject: Re: [Ecrit] Location hiding: VSP verification by UAS > > > > Right. In either cases, the VSP would be free to consider a call > > unverified if no authenticator were presented after a certain period > > (this period would be good to specify in a BCP). > > > > --Richard > > > > > > > > > > Andrew Newton wrote: > > > I don't see how an UPDATE helps. And the endpoint can simply not issue > > > the UPDATE to get around the verification. > > > > > > I think Richard's proposal has legs. > > > > > > -andy > > > > > > On Jun 28, 2007, at 7:55 AM, Brian Rosen wrote: > > > > > >> We would have to do it with an Update. > > >> > > >> I am uncomfortable with this idea, as it complicates the message flow > > on > > >> every emergency call. > > >> > > >> The basic idea has merit, but the details don't work for me. > > >> > > >> Brian > > >> > > >>> -----Original Message----- > > >>> From: Richard Barnes [mailto:rbarnes@bbn.com] > > >>> Sent: Thursday, June 28, 2007 12:30 AM > > >>> To: James M. Polk > > >>> Cc: ECRIT > > >>> Subject: Re: [Ecrit] Location hiding: VSP verification by UAS > > >>> > > >>> Hi James, > > >>> > > >>>> I need to see each proposed message flow. > > >>> > > >>> I was proposing more the conceptual flow of the UAS providing the > > >>> authentication information than a specific message flow. There are > > many > > >>> models that could be used: Authenticators could be conveyed in a 200, > > or > > >>> in a separate UPDATE transaction (as in connected-identity). > > >>> > > >>>> SIP is an e2e protocol, and a > > >>>> 200Ok to an INVITE means the INVITE was accepted as is - and is > > >>>> intended > > >>>> to travel all the way back to the original UAC. SIP doesn't error > > >>>> responses, which is what I feel you are proposing if the > > authentication > > >>>> fails (within a VSP proxy). > > >>> > > >>> I don't think that it's necessarily within the purview of ECRIT to > > >>> specify the behavior that results from a failed authentication. In > > >>> fact, I expect that this behavior will vary widely from VSP to VSP: > > One > > >>> VSP might allow the call to proceed normally, but start billing for it > > >>> after the authentication fails. Another might use a B2BUA that it > > >>> inserted in the path to kill the call. Et cetera. > > >>> > > >>> The essential thing is that allowing the UAS to provide authenticators > > >>> allows the PSAP to vouch for the fact that a call is an emergency > > call, > > >>> regardless of how location is provisioned. What the VSP chooses to do > > >>> with that information is a local decision (though maybe we could make > > >>> some non-normative recommendations). > > >>> > > >>> --Richard > > >>> > > >>> > > >>> > > >>> > > >>> > > >>>> > > >>>> At 08:39 PM 6/27/2007, Richard Barnes wrote: > > >>>>> So, the "location hiding" problem is really two problems: When the > > >>>>> access network provisions location in a way that the endpoint can't > > >>>>> get the location, > > >>>>> (1) How does the endpoint or VSP route and emergency call? and > > >>>>> (2) How can a VSP verify that a call is an emergency call? > > >>>>> > > >>>>> To date, solutions to the second problem have focused on performing > > >>>>> this verification based on information in the INVITE. In a location > > >>>>> hiding context, this approach runs into the problem that in order to > > >>>>> use LoST to verify the To: URI, either the UAC, the VSP, or a LoST > > >>>>> server has to dereference the location, and none of these is > > >>>>> necessarily authorized to do so. > > >>>>> > > >>>>> On the other hand, I think the second problem is pretty easy to > > solve > > >>>>> if the VSP is willing to transmit the INVITE and allow the UAS to > > >>>>> provide evidence that the call is an emergency call. The PSAP, > > after > > >>>>> all, is in a much better position to authenticate itself than the > > UAC > > >>>>> is to authenticate it. This authentication could take several > > forms: > > >>>>> > > >>>>> 1. If VSPs are willing to trust the LoST infrastructure, the PSAP > > >>>>> could include its service area in its 200 response; the VSP would > > >>>>> verify by performing a LoST query with the location and service URN > > in > > >>>>> the SIP traffic, and compare the element in the resulting > > >>>>> mapping to the To: address in the INVITE transaction. > > >>>>> > > >>>>> 2. If PSAPs have credentials, then the PSAP could use > > >>>>> connected-identity to assert its identity (or just use S/MIME to > > sign > > >>>>> a 200 response with it's key). > > >>>>> > > >>>>> Both of these can be done with protocols that are already released > > or > > >>>>> in process: Option 1 by including a GML or PIDF-LO document in the > > 200 > > >>>>> response (possibly indicated by a Geolocation: header), and Option 2 > > >>>>> with S/MIME or connected-identity. > > >>>>> > > >>>>> Humbly submitted, > > >>>>> --Richard > > >>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> Ecrit mailing list > > >>>>> Ecrit@ietf.org > > >>>>> https://www1.ietf.org/mailman/listinfo/ecrit > > >>>> > > >>>> > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> Ecrit mailing list > > >>> Ecrit@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/ecrit > > >> > > >> > > >> _______________________________________________ > > >> Ecrit mailing list > > >> Ecrit@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 28 14:22:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ydf-00059f-3K; Thu, 28 Jun 2007 14:22:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ydb-0004pf-NR for ecrit@ietf.org; Thu, 28 Jun 2007 14:22:40 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3yct-0006sX-8d for ecrit@ietf.org; Thu, 28 Jun 2007 14:22:39 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I3ycq-00040B-64; Thu, 28 Jun 2007 14:21:52 -0400 Received: from [127.0.0.1] (col-dhcp33-244-168.bbn.com [128.33.244.168]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l5SILqh03629; Thu, 28 Jun 2007 14:21:52 -0400 (EDT) Message-ID: <4683FC2C.3090001@bbn.com> Date: Thu, 28 Jun 2007 14:21:32 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] Location hiding: VSP verification by UAS (with B2BUAs?) References: <4683114D.8070305@bbn.com> <4683392D.8020106@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I apologize for bringing B2BUAs into this. I didn't mean that they should be part of the recommendation, just that that would be one way for the VSP to terminate the call if it so desired. Obviously, the solution should not depend on them. --RB James M. Polk wrote: > At 12:58 AM 6/28/2007, Winterbottom, James wrote: >> Hey Richard, >> >> A lot of large call-servers from what I understand operate as B2BUA >> anyway. So that may be something that you can leverage. > > James - the SIP WG has violently agreed B2BUAs cannot be relied upon in > a message flow, so I'm not sure how this will work (where's that message > flow to show that it will?). > > Thus, relying on a B2BUA in every message flow means 100% of the time, > one will be in the message flow, otherwise this leverage is zero. > That's not a good position (no pun intended) to be in. > > Someone working up a message flow will go a long ways towards showing if > this can work, else we're talking in abstracts about something that > seriously needs to work all the time. > > >> Cheers >> James >> >> > -----Original Message----- >> > From: Richard Barnes [mailto:rbarnes@bbn.com] >> > Sent: Thursday, 28 June 2007 2:30 PM >> > To: James M. Polk >> > Cc: ECRIT >> > Subject: Re: [Ecrit] Location hiding: VSP verification by UAS >> > >> > Hi James, >> > >> > > I need to see each proposed message flow. >> > >> > I was proposing more the conceptual flow of the UAS providing the >> > authentication information than a specific message flow. There are >> many >> > models that could be used: Authenticators could be conveyed in a 200, >> or >> > in a separate UPDATE transaction (as in connected-identity). >> > >> > > SIP is an e2e protocol, and a >> > > 200Ok to an INVITE means the INVITE was accepted as is - and is >> intended >> > > to travel all the way back to the original UAC. SIP doesn't error >> > > responses, which is what I feel you are proposing if the >> authentication >> > > fails (within a VSP proxy). >> > >> > I don't think that it's necessarily within the purview of ECRIT to >> > specify the behavior that results from a failed authentication. In >> > fact, I expect that this behavior will vary widely from VSP to VSP: >> One >> > VSP might allow the call to proceed normally, but start billing for it >> > after the authentication fails. Another might use a B2BUA that it >> > inserted in the path to kill the call. Et cetera. >> > >> > The essential thing is that allowing the UAS to provide authenticators >> > allows the PSAP to vouch for the fact that a call is an emergency >> call, >> > regardless of how location is provisioned. What the VSP chooses to do >> > with that information is a local decision (though maybe we could make >> > some non-normative recommendations). >> > >> > --Richard >> > >> > >> > >> > >> > >> > > >> > > At 08:39 PM 6/27/2007, Richard Barnes wrote: >> > >> So, the "location hiding" problem is really two problems: When the >> > >> access network provisions location in a way that the endpoint can't >> > >> get the location, >> > >> (1) How does the endpoint or VSP route and emergency call? and >> > >> (2) How can a VSP verify that a call is an emergency call? >> > >> >> > >> To date, solutions to the second problem have focused on performing >> > >> this verification based on information in the INVITE. In a >> location >> > >> hiding context, this approach runs into the problem that in order >> to >> > >> use LoST to verify the To: URI, either the UAC, the VSP, or a LoST >> > >> server has to dereference the location, and none of these is >> > >> necessarily authorized to do so. >> > >> >> > >> On the other hand, I think the second problem is pretty easy to >> solve >> > >> if the VSP is willing to transmit the INVITE and allow the UAS to >> > >> provide evidence that the call is an emergency call. The PSAP, >> after >> > >> all, is in a much better position to authenticate itself than the >> UAC >> > >> is to authenticate it. This authentication could take several >> forms: >> > >> >> > >> 1. If VSPs are willing to trust the LoST infrastructure, the PSAP >> > >> could include its service area in its 200 response; the VSP would >> > >> verify by performing a LoST query with the location and service URN >> in >> > >> the SIP traffic, and compare the element in the resulting >> > >> mapping to the To: address in the INVITE transaction. >> > >> >> > >> 2. If PSAPs have credentials, then the PSAP could use >> > >> connected-identity to assert its identity (or just use S/MIME to >> sign >> > >> a 200 response with it's key). >> > >> >> > >> Both of these can be done with protocols that are already released >> or >> > >> in process: Option 1 by including a GML or PIDF-LO document in the >> 200 >> > >> response (possibly indicated by a Geolocation: header), and Option >> 2 >> > >> with S/MIME or connected-identity. >> > >> >> > >> Humbly submitted, >> > >> --Richard >> > >> >> > >> >> > >> _______________________________________________ >> > >> Ecrit mailing list >> > >> Ecrit@ietf.org >> > >> https://www1.ietf.org/mailman/listinfo/ecrit >> > > >> > > >> > >> > >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www1.ietf.org/mailman/listinfo/ecrit >> >> ------------------------------------------------------------------------------------------------ >> >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> ------------------------------------------------------------------------------------------------ >> >> [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 28 14:31:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ylv-0000Jo-WE; Thu, 28 Jun 2007 14:31:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ylv-0000Ji-JE for ecrit@ietf.org; Thu, 28 Jun 2007 14:31:15 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3ylI-0008Dd-Gb for ecrit@ietf.org; Thu, 28 Jun 2007 14:31:15 -0400 Received: from po2.bbn.com ([128.33.0.56]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I3ylI-0004AV-3k; Thu, 28 Jun 2007 14:30:36 -0400 Received: from [127.0.0.1] (col-dhcp33-244-168.bbn.com [128.33.244.168]) by po2.bbn.com (8.11.6+Sun/8.10.2) with ESMTP id l5SIUZh05531; Thu, 28 Jun 2007 14:30:35 -0400 (EDT) Message-ID: <4683FE38.5060407@bbn.com> Date: Thu, 28 Jun 2007 14:30:16 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Location hiding: VSP verification by UAS References: <4683114D.8070305@bbn.com> <4683392D.8020106@bbn.com> <024401c7b97b$3639c4a0$a0acf444@cis.neustar.com> <08904E1F-0EB8-46B5-AC2A-D6CB74C239B5@hxr.us> <4683B950.5020404@bbn.com> <002901c7b99f$7da01410$1772f544@cis.neustar.com> In-Reply-To: <002901c7b99f$7da01410$1772f544@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I don't think that reliability is necessarily a discriminator in this case: If you send the PSAP's location/service area in a 200 and the 200 doesn't get there, you've got other problems above and beyond VSP verification. --Richard Brian Rosen wrote: > To get the location of the PSAP, you need an UPDATE, with the PSAP doing the > update and becoming the UAC because it's reliable. Conveyance is defined > from UAC to UAS only, for this, among other reasons. > > Brian >> -----Original Message----- >> From: Richard Barnes [mailto:rbarnes@bbn.com] >> Sent: Thursday, June 28, 2007 9:36 AM >> To: Andrew Newton >> Cc: Brian Rosen; 'James M. Polk'; 'ECRIT' >> Subject: Re: [Ecrit] Location hiding: VSP verification by UAS >> >> Right. In either cases, the VSP would be free to consider a call >> unverified if no authenticator were presented after a certain period >> (this period would be good to specify in a BCP). >> >> --Richard >> >> >> >> >> Andrew Newton wrote: >>> I don't see how an UPDATE helps. And the endpoint can simply not issue >>> the UPDATE to get around the verification. >>> >>> I think Richard's proposal has legs. >>> >>> -andy >>> >>> On Jun 28, 2007, at 7:55 AM, Brian Rosen wrote: >>> >>>> We would have to do it with an Update. >>>> >>>> I am uncomfortable with this idea, as it complicates the message flow >> on >>>> every emergency call. >>>> >>>> The basic idea has merit, but the details don't work for me. >>>> >>>> Brian >>>> >>>>> -----Original Message----- >>>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>>> Sent: Thursday, June 28, 2007 12:30 AM >>>>> To: James M. Polk >>>>> Cc: ECRIT >>>>> Subject: Re: [Ecrit] Location hiding: VSP verification by UAS >>>>> >>>>> Hi James, >>>>> >>>>>> I need to see each proposed message flow. >>>>> I was proposing more the conceptual flow of the UAS providing the >>>>> authentication information than a specific message flow. There are >> many >>>>> models that could be used: Authenticators could be conveyed in a 200, >> or >>>>> in a separate UPDATE transaction (as in connected-identity). >>>>> >>>>>> SIP is an e2e protocol, and a >>>>>> 200Ok to an INVITE means the INVITE was accepted as is - and is >>>>>> intended >>>>>> to travel all the way back to the original UAC. SIP doesn't error >>>>>> responses, which is what I feel you are proposing if the >> authentication >>>>>> fails (within a VSP proxy). >>>>> I don't think that it's necessarily within the purview of ECRIT to >>>>> specify the behavior that results from a failed authentication. In >>>>> fact, I expect that this behavior will vary widely from VSP to VSP: >> One >>>>> VSP might allow the call to proceed normally, but start billing for it >>>>> after the authentication fails. Another might use a B2BUA that it >>>>> inserted in the path to kill the call. Et cetera. >>>>> >>>>> The essential thing is that allowing the UAS to provide authenticators >>>>> allows the PSAP to vouch for the fact that a call is an emergency >> call, >>>>> regardless of how location is provisioned. What the VSP chooses to do >>>>> with that information is a local decision (though maybe we could make >>>>> some non-normative recommendations). >>>>> >>>>> --Richard >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> At 08:39 PM 6/27/2007, Richard Barnes wrote: >>>>>>> So, the "location hiding" problem is really two problems: When the >>>>>>> access network provisions location in a way that the endpoint can't >>>>>>> get the location, >>>>>>> (1) How does the endpoint or VSP route and emergency call? and >>>>>>> (2) How can a VSP verify that a call is an emergency call? >>>>>>> >>>>>>> To date, solutions to the second problem have focused on performing >>>>>>> this verification based on information in the INVITE. In a location >>>>>>> hiding context, this approach runs into the problem that in order to >>>>>>> use LoST to verify the To: URI, either the UAC, the VSP, or a LoST >>>>>>> server has to dereference the location, and none of these is >>>>>>> necessarily authorized to do so. >>>>>>> >>>>>>> On the other hand, I think the second problem is pretty easy to >> solve >>>>>>> if the VSP is willing to transmit the INVITE and allow the UAS to >>>>>>> provide evidence that the call is an emergency call. The PSAP, >> after >>>>>>> all, is in a much better position to authenticate itself than the >> UAC >>>>>>> is to authenticate it. This authentication could take several >> forms: >>>>>>> 1. If VSPs are willing to trust the LoST infrastructure, the PSAP >>>>>>> could include its service area in its 200 response; the VSP would >>>>>>> verify by performing a LoST query with the location and service URN >> in >>>>>>> the SIP traffic, and compare the element in the resulting >>>>>>> mapping to the To: address in the INVITE transaction. >>>>>>> >>>>>>> 2. If PSAPs have credentials, then the PSAP could use >>>>>>> connected-identity to assert its identity (or just use S/MIME to >> sign >>>>>>> a 200 response with it's key). >>>>>>> >>>>>>> Both of these can be done with protocols that are already released >> or >>>>>>> in process: Option 1 by including a GML or PIDF-LO document in the >> 200 >>>>>>> response (possibly indicated by a Geolocation: header), and Option 2 >>>>>>> with S/MIME or connected-identity. >>>>>>> >>>>>>> Humbly submitted, >>>>>>> --Richard >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ecrit >>> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 28 14:54:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3z8l-0004QD-QU; Thu, 28 Jun 2007 14:54:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3z8k-0004Q8-KH for ecrit@ietf.org; Thu, 28 Jun 2007 14:54:50 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3z8Q-0006Yq-ND for ecrit@ietf.org; Thu, 28 Jun 2007 14:54:50 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 28 Jun 2007 14:54:28 -0400 id 01588386.468403E5.00007E9B In-Reply-To: <002901c7b99f$7da01410$1772f544@cis.neustar.com> References: <4683114D.8070305@bbn.com> <4683392D.8020106@bbn.com> <024401c7b97b$3639c4a0$a0acf444@cis.neustar.com> <08904E1F-0EB8-46B5-AC2A-D6CB74C239B5@hxr.us> <4683B950.5020404@bbn.com> <002901c7b99f$7da01410$1772f544@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <75450DF3-1BEA-4D50-837D-BF90D3E1EF5B@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Location hiding: VSP verification by UAS Date: Thu, 28 Jun 2007 14:54:25 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jun 28, 2007, at 12:14 PM, Brian Rosen wrote: > To get the location of the PSAP, you need an UPDATE, with the PSAP > doing the > update and becoming the UAC because it's reliable. Conveyance is > defined > from UAC to UAS only, for this, among other reasons. Well, this really wouldn't be location conveyance but service boundary conveyance. But I understand your point. Still, the idea that the PSAP should be able to prove that it is a PSAP is worthwhile. This could happen with an identity instead of a service boundary. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 28 15:05:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3zIp-0005rN-1K; Thu, 28 Jun 2007 15:05:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3zIn-0005jY-1d for ecrit@ietf.org; Thu, 28 Jun 2007 15:05:13 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3zEj-0000pa-LT for ecrit@ietf.org; Thu, 28 Jun 2007 15:01:54 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 28 Jun 2007 15:00:55 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAIaig0ZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,471,1175486400"; d="scan'208"; a="124808266:sNHT5143403086" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5SJ0sNh026415; Thu, 28 Jun 2007 15:00:54 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5SJ0YZH010578; Thu, 28 Jun 2007 19:00:42 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 15:00:34 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.120]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 15:00:33 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Jun 2007 14:00:22 -0500 To: Richard Barnes , Brian Rosen From: "James M. Polk" Subject: Re: [Ecrit] Location hiding: VSP verification by UAS In-Reply-To: <4683FE38.5060407@bbn.com> References: <4683114D.8070305@bbn.com> <4683392D.8020106@bbn.com> <024401c7b97b$3639c4a0$a0acf444@cis.neustar.com> <08904E1F-0EB8-46B5-AC2A-D6CB74C239B5@hxr.us> <4683B950.5020404@bbn.com> <002901c7b99f$7da01410$1772f544@cis.neustar.com> <4683FE38.5060407@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 28 Jun 2007 19:00:34.0099 (UTC) FILETIME=[9B1E5030:01C7B9B6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7546; t=1183057254; x=1183921254; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Location=20hiding=3A=20VSP=20verification=2 0by=20UAS |Sender:=20 |To:=20Richard=20Barnes=20, =20Brian=20Rosen=20; bh=ApSut46sAnOY9xJ5VKGjWLfnuMe5IqiDcvVlQU9F82s=; b=iPpEV7GFQ0Scq2Q9ljd0JafY9XYyaGeIS900rb6QT2KOdPGt/9OXU45i8RCNbcm8WSdh6sx3 hQJPwALItEx11sN83IdNdXkixn0MjFlaPxhThx0frXOu+x2vQwq4YBdH; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 01:30 PM 6/28/2007, Richard Barnes wrote: >I don't think that reliability is necessarily a discriminator in >this case: If you send the PSAP's location/service area in a 200 and >the 200 doesn't get there, Where's "there" in this context? A caller sends an INVITE to a PSAP (regardless of how many servers it goes through, it's destination is towards the PSAP - even if the R-URI is changed). In other words, it's e2e. A 200OK to the INVITE is destined for the caller's UAC, not anywhere else - though servers can view unencrypted message bodies if location is LbyV. I think also that if you build a PIDF-LO for the coverage area of a PSAP, you aren't going to use civic, as I don't think PSAP boundaries are absolutely limited to a defined city or county perimeter. I remember being railed on because PSAP boundaries often are the middle line of a street, where one side of the street is PSAP-A and the other side of the street is PSAP-B. This means that this street cannot be a boundary delineation between PSAP coverage areas. This gets you into coordinate or geo formats (basically, the linear ring concept within GML). This can be HUGE in xml with all the points you have to include, if you want to be precise, and since SIP cannot error response messages, this 200OK message will likely be substantially larger than the request (which will likely be in civic) - therefore the packet might get too large and require an error message to it. This is part of the reason (but not specifically about PSAP boundaries) that location is not to be in SIP responses. This is part of section 5.2 UAS Behavior of Conveyance. >you've got other problems above and beyond VSP verification. > >--Richard > > > >Brian Rosen wrote: >>To get the location of the PSAP, you need an UPDATE, with the PSAP doing the >>update and becoming the UAC because it's reliable. Conveyance is defined >>from UAC to UAS only, for this, among other reasons. >>Brian >>>-----Original Message----- >>>From: Richard Barnes [mailto:rbarnes@bbn.com] >>>Sent: Thursday, June 28, 2007 9:36 AM >>>To: Andrew Newton >>>Cc: Brian Rosen; 'James M. Polk'; 'ECRIT' >>>Subject: Re: [Ecrit] Location hiding: VSP verification by UAS >>> >>>Right. In either cases, the VSP would be free to consider a call >>>unverified if no authenticator were presented after a certain period >>>(this period would be good to specify in a BCP). >>> >>>--Richard >>> >>> >>> >>> >>>Andrew Newton wrote: >>>>I don't see how an UPDATE helps. And the endpoint can simply not issue >>>>the UPDATE to get around the verification. >>>> >>>>I think Richard's proposal has legs. >>>> >>>>-andy >>>> >>>>On Jun 28, 2007, at 7:55 AM, Brian Rosen wrote: >>>> >>>>>We would have to do it with an Update. >>>>> >>>>>I am uncomfortable with this idea, as it complicates the message flow >>>on >>>>>every emergency call. >>>>> >>>>>The basic idea has merit, but the details don't work for me. >>>>> >>>>>Brian >>>>> >>>>>>-----Original Message----- >>>>>>From: Richard Barnes [mailto:rbarnes@bbn.com] >>>>>>Sent: Thursday, June 28, 2007 12:30 AM >>>>>>To: James M. Polk >>>>>>Cc: ECRIT >>>>>>Subject: Re: [Ecrit] Location hiding: VSP verification by UAS >>>>>> >>>>>>Hi James, >>>>>> >>>>>>>I need to see each proposed message flow. >>>>>>I was proposing more the conceptual flow of the UAS providing the >>>>>>authentication information than a specific message flow. There are >>>many >>>>>>models that could be used: Authenticators could be conveyed in a 200, >>>or >>>>>>in a separate UPDATE transaction (as in connected-identity). >>>>>> >>>>>>>SIP is an e2e protocol, and a >>>>>>>200Ok to an INVITE means the INVITE was accepted as is - and is >>>>>>>intended >>>>>>>to travel all the way back to the original UAC. SIP doesn't error >>>>>>>responses, which is what I feel you are proposing if the >>>authentication >>>>>>>fails (within a VSP proxy). >>>>>>I don't think that it's necessarily within the purview of ECRIT to >>>>>>specify the behavior that results from a failed authentication. In >>>>>>fact, I expect that this behavior will vary widely from VSP to VSP: >>>One >>>>>>VSP might allow the call to proceed normally, but start billing for it >>>>>>after the authentication fails. Another might use a B2BUA that it >>>>>>inserted in the path to kill the call. Et cetera. >>>>>> >>>>>>The essential thing is that allowing the UAS to provide authenticators >>>>>>allows the PSAP to vouch for the fact that a call is an emergency >>>call, >>>>>>regardless of how location is provisioned. What the VSP chooses to do >>>>>>with that information is a local decision (though maybe we could make >>>>>>some non-normative recommendations). >>>>>> >>>>>>--Richard >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>At 08:39 PM 6/27/2007, Richard Barnes wrote: >>>>>>>>So, the "location hiding" problem is really two problems: When the >>>>>>>>access network provisions location in a way that the endpoint can't >>>>>>>>get the location, >>>>>>>>(1) How does the endpoint or VSP route and emergency call? and >>>>>>>>(2) How can a VSP verify that a call is an emergency call? >>>>>>>> >>>>>>>>To date, solutions to the second problem have focused on performing >>>>>>>>this verification based on information in the INVITE. In a location >>>>>>>>hiding context, this approach runs into the problem that in order to >>>>>>>>use LoST to verify the To: URI, either the UAC, the VSP, or a LoST >>>>>>>>server has to dereference the location, and none of these is >>>>>>>>necessarily authorized to do so. >>>>>>>> >>>>>>>>On the other hand, I think the second problem is pretty easy to >>>solve >>>>>>>>if the VSP is willing to transmit the INVITE and allow the UAS to >>>>>>>>provide evidence that the call is an emergency call. The PSAP, >>>after >>>>>>>>all, is in a much better position to authenticate itself than the >>>UAC >>>>>>>>is to authenticate it. This authentication could take several >>>forms: >>>>>>>>1. If VSPs are willing to trust the LoST infrastructure, the PSAP >>>>>>>>could include its service area in its 200 response; the VSP would >>>>>>>>verify by performing a LoST query with the location and service URN >>>in >>>>>>>>the SIP traffic, and compare the element in the resulting >>>>>>>>mapping to the To: address in the INVITE transaction. >>>>>>>> >>>>>>>>2. If PSAPs have credentials, then the PSAP could use >>>>>>>>connected-identity to assert its identity (or just use S/MIME to >>>sign >>>>>>>>a 200 response with it's key). >>>>>>>> >>>>>>>>Both of these can be done with protocols that are already released >>>or >>>>>>>>in process: Option 1 by including a GML or PIDF-LO document in the >>>200 >>>>>>>>response (possibly indicated by a Geolocation: header), and Option 2 >>>>>>>>with S/MIME or connected-identity. >>>>>>>> >>>>>>>>Humbly submitted, >>>>>>>>--Richard >>>>>>>> >>>>>>>> >>>>>>>>_______________________________________________ >>>>>>>>Ecrit mailing list >>>>>>>>Ecrit@ietf.org >>>>>>>>https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Ecrit mailing list >>>>>>Ecrit@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>>>>_______________________________________________ >>>>>Ecrit mailing list >>>>>Ecrit@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jun 28 16:36:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40j7-0001Zb-Kw; Thu, 28 Jun 2007 16:36:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40j6-0001ZW-2V for ecrit@ietf.org; Thu, 28 Jun 2007 16:36:28 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I40iY-0008IS-8v for ecrit@ietf.org; Thu, 28 Jun 2007 16:36:28 -0400 Received: from dhcp89-089-119.bbn.com ([128.89.89.119] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I40iX-00033A-6I; Thu, 28 Jun 2007 16:35:54 -0400 Message-ID: <46841BA9.909@bbn.com> Date: Thu, 28 Jun 2007 16:35:53 -0400 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] Location hiding: VSP verification by UAS References: <4683114D.8070305@bbn.com> <4683392D.8020106@bbn.com> <024401c7b97b$3639c4a0$a0acf444@cis.neustar.com> <08904E1F-0EB8-46B5-AC2A-D6CB74C239B5@hxr.us> <4683B950.5020404@bbn.com> <002901c7b99f$7da01410$1772f544@cis.neustar.com> <4683FE38.5060407@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org James, James M. Polk wrote: > I think also that if you build a PIDF-LO for the coverage area of a > PSAP, you aren't going to use civic, as I don't think PSAP boundaries > are absolutely limited to a defined city or county perimeter. I > remember being railed on because PSAP boundaries often are the middle > line of a street, where one side of the street is PSAP-A and the other > side of the street is PSAP-B. This means that this street cannot be a > boundary delineation between PSAP coverage areas. This gets you into > coordinate or geo formats (basically, the linear ring concept within > GML). This can be HUGE in xml with all the points you have to include, > if you want to be precise, and since SIP cannot error response > messages, this 200OK message will likely be substantially larger than > the request (which will likely be in civic) - therefore the packet > might get too large and require an error message to it. If the point is verifying that the end-point is a PSAP, then it's not necessary for the PSAP to convey the entire boundry of the service region to the VSP. All that's needed is for the PSAP to hand the VSP an arbitrary point in the service region. The VSP can then query LoST with this point and see that the result matches the URI to which the call was routed. That is, the VSP doesn't care what the service region is for the PSAP. All the VSP cares about is that there exists at least point for which the callee is a valid PSAP. - Matt Lepinski :-> > >> you've got other problems above and beyond VSP verification. >> >> --Richard >> >> >> >> Brian Rosen wrote: >> >>> To get the location of the PSAP, you need an UPDATE, with the PSAP >>> doing the >>> update and becoming the UAC because it's reliable. Conveyance is >>> defined >>> from UAC to UAS only, for this, among other reasons. >>> Brian >>> >>>> -----Original Message----- >>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>> Sent: Thursday, June 28, 2007 9:36 AM >>>> To: Andrew Newton >>>> Cc: Brian Rosen; 'James M. Polk'; 'ECRIT' >>>> Subject: Re: [Ecrit] Location hiding: VSP verification by UAS >>>> >>>> Right. In either cases, the VSP would be free to consider a call >>>> unverified if no authenticator were presented after a certain period >>>> (this period would be good to specify in a BCP). >>>> >>>> --Richard >>>> >>>> >>>> >>>> >>>> Andrew Newton wrote: >>>> >>>>> I don't see how an UPDATE helps. And the endpoint can simply not >>>>> issue >>>>> the UPDATE to get around the verification. >>>>> >>>>> I think Richard's proposal has legs. >>>>> >>>>> -andy >>>>> >>>>> On Jun 28, 2007, at 7:55 AM, Brian Rosen wrote: >>>>> >>>>>> We would have to do it with an Update. >>>>>> >>>>>> I am uncomfortable with this idea, as it complicates the message >>>>>> flow >>>>> >>>> on >>>> >>>>>> every emergency call. >>>>>> >>>>>> The basic idea has merit, but the details don't work for me. >>>>>> >>>>>> Brian >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>>>>> Sent: Thursday, June 28, 2007 12:30 AM >>>>>>> To: James M. Polk >>>>>>> Cc: ECRIT >>>>>>> Subject: Re: [Ecrit] Location hiding: VSP verification by UAS >>>>>>> >>>>>>> Hi James, >>>>>>> >>>>>>>> I need to see each proposed message flow. >>>>>>> >>>>>>> I was proposing more the conceptual flow of the UAS providing the >>>>>>> authentication information than a specific message flow. There are >>>>>> >>>> many >>>> >>>>>>> models that could be used: Authenticators could be conveyed in a >>>>>>> 200, >>>>>> >>>> or >>>> >>>>>>> in a separate UPDATE transaction (as in connected-identity). >>>>>>> >>>>>>>> SIP is an e2e protocol, and a >>>>>>>> 200Ok to an INVITE means the INVITE was accepted as is - and is >>>>>>>> intended >>>>>>>> to travel all the way back to the original UAC. SIP doesn't error >>>>>>>> responses, which is what I feel you are proposing if the >>>>>>> >>>> authentication >>>> >>>>>>>> fails (within a VSP proxy). >>>>>>> >>>>>>> I don't think that it's necessarily within the purview of ECRIT to >>>>>>> specify the behavior that results from a failed authentication. In >>>>>>> fact, I expect that this behavior will vary widely from VSP to VSP: >>>>>> >>>> One >>>> >>>>>>> VSP might allow the call to proceed normally, but start billing >>>>>>> for it >>>>>>> after the authentication fails. Another might use a B2BUA that it >>>>>>> inserted in the path to kill the call. Et cetera. >>>>>>> >>>>>>> The essential thing is that allowing the UAS to provide >>>>>>> authenticators >>>>>>> allows the PSAP to vouch for the fact that a call is an emergency >>>>>> >>>> call, >>>> >>>>>>> regardless of how location is provisioned. What the VSP chooses >>>>>>> to do >>>>>>> with that information is a local decision (though maybe we could >>>>>>> make >>>>>>> some non-normative recommendations). >>>>>>> >>>>>>> --Richard >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> At 08:39 PM 6/27/2007, Richard Barnes wrote: >>>>>>>> >>>>>>>>> So, the "location hiding" problem is really two problems: When >>>>>>>>> the >>>>>>>>> access network provisions location in a way that the endpoint >>>>>>>>> can't >>>>>>>>> get the location, >>>>>>>>> (1) How does the endpoint or VSP route and emergency call? and >>>>>>>>> (2) How can a VSP verify that a call is an emergency call? >>>>>>>>> >>>>>>>>> To date, solutions to the second problem have focused on >>>>>>>>> performing >>>>>>>>> this verification based on information in the INVITE. In a >>>>>>>>> location >>>>>>>>> hiding context, this approach runs into the problem that in >>>>>>>>> order to >>>>>>>>> use LoST to verify the To: URI, either the UAC, the VSP, or a >>>>>>>>> LoST >>>>>>>>> server has to dereference the location, and none of these is >>>>>>>>> necessarily authorized to do so. >>>>>>>>> >>>>>>>>> On the other hand, I think the second problem is pretty easy to >>>>>>>> >>>> solve >>>> >>>>>>>>> if the VSP is willing to transmit the INVITE and allow the UAS to >>>>>>>>> provide evidence that the call is an emergency call. The PSAP, >>>>>>>> >>>> after >>>> >>>>>>>>> all, is in a much better position to authenticate itself than the >>>>>>>> >>>> UAC >>>> >>>>>>>>> is to authenticate it. This authentication could take several >>>>>>>> >>>> forms: >>>> >>>>>>>>> 1. If VSPs are willing to trust the LoST infrastructure, the PSAP >>>>>>>>> could include its service area in its 200 response; the VSP would >>>>>>>>> verify by performing a LoST query with the location and >>>>>>>>> service URN >>>>>>>> >>>> in >>>> >>>>>>>>> the SIP traffic, and compare the element in the resulting >>>>>>>>> mapping to the To: address in the INVITE transaction. >>>>>>>>> >>>>>>>>> 2. If PSAPs have credentials, then the PSAP could use >>>>>>>>> connected-identity to assert its identity (or just use S/MIME to >>>>>>>> >>>> sign >>>> >>>>>>>>> a 200 response with it's key). >>>>>>>>> >>>>>>>>> Both of these can be done with protocols that are already >>>>>>>>> released >>>>>>>> >>>> or >>>> >>>>>>>>> in process: Option 1 by including a GML or PIDF-LO document in >>>>>>>>> the >>>>>>>> >>>> 200 >>>> >>>>>>>>> response (possibly indicated by a Geolocation: header), and >>>>>>>>> Option 2 >>>>>>>>> with S/MIME or connected-identity. >>>>>>>>> >>>>>>>>> Humbly submitted, >>>>>>>>> --Richard >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Ecrit mailing list >>>>>>>>> Ecrit@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 29 00:10:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I47og-0005LW-Rl; Fri, 29 Jun 2007 00:10:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I47og-0005Ky-01 for ecrit@ietf.org; Fri, 29 Jun 2007 00:10:42 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I47ob-0003Ic-F4 for ecrit@ietf.org; Fri, 29 Jun 2007 00:10:41 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I47oa-00024k-44; Fri, 29 Jun 2007 00:10:37 -0400 Message-ID: <46848639.7050403@bbn.com> Date: Fri, 29 Jun 2007 00:10:33 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] Location hiding: VSP verification by UAS References: <4683114D.8070305@bbn.com> <4683392D.8020106@bbn.com> <024401c7b97b$3639c4a0$a0acf444@cis.neustar.com> <08904E1F-0EB8-46B5-AC2A-D6CB74C239B5@hxr.us> <4683B950.5020404@bbn.com> <002901c7b99f$7da01410$1772f544@cis.neustar.com> <4683FE38.5060407@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org To be a little more concrete, if the authenticator (location/sb or Identity header) is going to be carried in the 200/OK, then there is no change required to the standard INVITE message flow. The proxy simply observes the 200 as it passes by, and any action it takes based on the authenticator is external to that transaction. > A caller sends an INVITE to a PSAP (regardless of how many servers it > goes through, it's destination is towards the PSAP - even if the R-URI > is changed). In other words, it's e2e. Sure. But the response will still go back through the proxies in the Record-Route chain, so if a proxy wants to verify, it just has to add itself into the Record-Route. The 200 will travel e2e, but the proxy will get to see it and get the authenticator from it. > A 200OK to the INVITE is destined for the caller's UAC, not anywhere > else - though servers can view unencrypted message bodies if location is > LbyV. This is just an argument to put the authenticator in a header so that proxies can see it. Makes sense to me. > I think also that if you build a PIDF-LO for the coverage area of a > PSAP, you aren't going to use civic, as I don't think PSAP boundaries > are absolutely limited to a defined city or county perimeter. ... This is a good point, but I think there are ways around it. Using connected-identity instead of LoST as an authenticator is one. Even if you do use LoST to authenticate the call, then all the PSAP really needs to provide is a single location in its service area; presumably the location of the PSAP will suffice in a lot of cases. Alternatively, the message could contain no location at all, and carry an service boundary reference that could be used to get the location to do the verification. > This is part of the reason (but not specifically about PSAP boundaries) > that location is not to be in SIP responses. This is part of section > 5.2 UAS Behavior of Conveyance. I don't really see the harm here. I guess the risk is that the PSAP puts in a location that the VSP can't understand, but it seems like you could write the phonebcp in such a way as to constrain this, e.g., "the value in the Geolocation header MUST be a cid URI" or "MUST be an HTTP URI". Even if there is an error with the Geolocation value, the risk is mostly that the call won't authenticate and the call gets handled as a non-emergency call. This seems like a small risk, and one that could be addressed in the phonebcp (e.g., "VSPs MUST NOT terminate unverifable emergency calls, but MAY choose to handle them as they would non-emergency calls"). (As a general point, I don't see anything in section 5.2 that forbids putting Geolocation into a response, and Table 1 explicitly indicates that Geolocation can be carried in responses. We should move any further debate on this to another forum, though.) --Richard >> you've got other problems above and beyond VSP verification. >> >> --Richard >> >> >> >> Brian Rosen wrote: >>> To get the location of the PSAP, you need an UPDATE, with the PSAP >>> doing the >>> update and becoming the UAC because it's reliable. Conveyance is >>> defined >>> from UAC to UAS only, for this, among other reasons. >>> Brian >>>> -----Original Message----- >>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>> Sent: Thursday, June 28, 2007 9:36 AM >>>> To: Andrew Newton >>>> Cc: Brian Rosen; 'James M. Polk'; 'ECRIT' >>>> Subject: Re: [Ecrit] Location hiding: VSP verification by UAS >>>> >>>> Right. In either cases, the VSP would be free to consider a call >>>> unverified if no authenticator were presented after a certain period >>>> (this period would be good to specify in a BCP). >>>> >>>> --Richard >>>> >>>> >>>> >>>> >>>> Andrew Newton wrote: >>>>> I don't see how an UPDATE helps. And the endpoint can simply not >>>>> issue >>>>> the UPDATE to get around the verification. >>>>> >>>>> I think Richard's proposal has legs. >>>>> >>>>> -andy >>>>> >>>>> On Jun 28, 2007, at 7:55 AM, Brian Rosen wrote: >>>>> >>>>>> We would have to do it with an Update. >>>>>> >>>>>> I am uncomfortable with this idea, as it complicates the message flow >>>> on >>>>>> every emergency call. >>>>>> >>>>>> The basic idea has merit, but the details don't work for me. >>>>>> >>>>>> Brian >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>>>>> Sent: Thursday, June 28, 2007 12:30 AM >>>>>>> To: James M. Polk >>>>>>> Cc: ECRIT >>>>>>> Subject: Re: [Ecrit] Location hiding: VSP verification by UAS >>>>>>> >>>>>>> Hi James, >>>>>>> >>>>>>>> I need to see each proposed message flow. >>>>>>> I was proposing more the conceptual flow of the UAS providing the >>>>>>> authentication information than a specific message flow. There are >>>> many >>>>>>> models that could be used: Authenticators could be conveyed in a >>>>>>> 200, >>>> or >>>>>>> in a separate UPDATE transaction (as in connected-identity). >>>>>>> >>>>>>>> SIP is an e2e protocol, and a >>>>>>>> 200Ok to an INVITE means the INVITE was accepted as is - and is >>>>>>>> intended >>>>>>>> to travel all the way back to the original UAC. SIP doesn't error >>>>>>>> responses, which is what I feel you are proposing if the >>>> authentication >>>>>>>> fails (within a VSP proxy). >>>>>>> I don't think that it's necessarily within the purview of ECRIT to >>>>>>> specify the behavior that results from a failed authentication. In >>>>>>> fact, I expect that this behavior will vary widely from VSP to VSP: >>>> One >>>>>>> VSP might allow the call to proceed normally, but start billing >>>>>>> for it >>>>>>> after the authentication fails. Another might use a B2BUA that it >>>>>>> inserted in the path to kill the call. Et cetera. >>>>>>> >>>>>>> The essential thing is that allowing the UAS to provide >>>>>>> authenticators >>>>>>> allows the PSAP to vouch for the fact that a call is an emergency >>>> call, >>>>>>> regardless of how location is provisioned. What the VSP chooses >>>>>>> to do >>>>>>> with that information is a local decision (though maybe we could >>>>>>> make >>>>>>> some non-normative recommendations). >>>>>>> >>>>>>> --Richard >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> At 08:39 PM 6/27/2007, Richard Barnes wrote: >>>>>>>>> So, the "location hiding" problem is really two problems: When the >>>>>>>>> access network provisions location in a way that the endpoint >>>>>>>>> can't >>>>>>>>> get the location, >>>>>>>>> (1) How does the endpoint or VSP route and emergency call? and >>>>>>>>> (2) How can a VSP verify that a call is an emergency call? >>>>>>>>> >>>>>>>>> To date, solutions to the second problem have focused on >>>>>>>>> performing >>>>>>>>> this verification based on information in the INVITE. In a >>>>>>>>> location >>>>>>>>> hiding context, this approach runs into the problem that in >>>>>>>>> order to >>>>>>>>> use LoST to verify the To: URI, either the UAC, the VSP, or a LoST >>>>>>>>> server has to dereference the location, and none of these is >>>>>>>>> necessarily authorized to do so. >>>>>>>>> >>>>>>>>> On the other hand, I think the second problem is pretty easy to >>>> solve >>>>>>>>> if the VSP is willing to transmit the INVITE and allow the UAS to >>>>>>>>> provide evidence that the call is an emergency call. The PSAP, >>>> after >>>>>>>>> all, is in a much better position to authenticate itself than the >>>> UAC >>>>>>>>> is to authenticate it. This authentication could take several >>>> forms: >>>>>>>>> 1. If VSPs are willing to trust the LoST infrastructure, the PSAP >>>>>>>>> could include its service area in its 200 response; the VSP would >>>>>>>>> verify by performing a LoST query with the location and service >>>>>>>>> URN >>>> in >>>>>>>>> the SIP traffic, and compare the element in the resulting >>>>>>>>> mapping to the To: address in the INVITE transaction. >>>>>>>>> >>>>>>>>> 2. If PSAPs have credentials, then the PSAP could use >>>>>>>>> connected-identity to assert its identity (or just use S/MIME to >>>> sign >>>>>>>>> a 200 response with it's key). >>>>>>>>> >>>>>>>>> Both of these can be done with protocols that are already released >>>> or >>>>>>>>> in process: Option 1 by including a GML or PIDF-LO document in the >>>> 200 >>>>>>>>> response (possibly indicated by a Geolocation: header), and >>>>>>>>> Option 2 >>>>>>>>> with S/MIME or connected-identity. >>>>>>>>> >>>>>>>>> Humbly submitted, >>>>>>>>> --Richard >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Ecrit mailing list >>>>>>>>> Ecrit@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 29 14:13:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ky2-00055D-HA; Fri, 29 Jun 2007 14:13:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ky1-00052U-Rg for ecrit@ietf.org; Fri, 29 Jun 2007 14:13:13 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4KxJ-0002cw-MN for ecrit@ietf.org; Fri, 29 Jun 2007 14:13:13 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 29 Jun 2007 11:12:29 -0700 X-IronPort-AV: i="4.16,476,1175497200"; d="scan'208"; a="5788424:sNHT21959334" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5TICTFY013913; Fri, 29 Jun 2007 11:12:29 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l5TICHwN015583; Fri, 29 Jun 2007 18:12:20 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 11:12:17 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.20.251]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 11:12:16 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 29 Jun 2007 13:12:14 -0500 To: Andrew Newton , Brian Rosen From: "James M. Polk" Subject: Re: [Ecrit] Location hiding: VSP verification by UAS In-Reply-To: <75450DF3-1BEA-4D50-837D-BF90D3E1EF5B@hxr.us> References: <4683114D.8070305@bbn.com> <4683392D.8020106@bbn.com> <024401c7b97b$3639c4a0$a0acf444@cis.neustar.com> <08904E1F-0EB8-46B5-AC2A-D6CB74C239B5@hxr.us> <4683B950.5020404@bbn.com> <002901c7b99f$7da01410$1772f544@cis.neustar.com> <75450DF3-1BEA-4D50-837D-BF90D3E1EF5B@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 29 Jun 2007 18:12:16.0714 (UTC) FILETIME=[068E32A0:01C7BA79] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=933; t=1183140749; x=1184004749; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Location=20hiding=3A=20VSP=20verification=2 0by=20UAS |Sender:=20; bh=OtAISd+zhLDzIaVOvE+3C7x4KtH8NbcVKgA6NoVBZ1k=; b=XniZcIxiW7iNQ+b/k4mBT75h7Ij7dxLg6kpPvL2HwRekYpQBg5zlvqh1JtQUTUCGNS8J/pqj QAfkyMR6KMjAlh0fch5/eawZA3kut1vAq5TPU652HbcFJjc49iZt/Ygi; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 01:54 PM 6/28/2007, Andrew Newton wrote: >On Jun 28, 2007, at 12:14 PM, Brian Rosen wrote: > >>To get the location of the PSAP, you need an UPDATE, with the PSAP >>doing the >>update and becoming the UAC because it's reliable. Conveyance is >>defined >>from UAC to UAS only, for this, among other reasons. > >Well, this really wouldn't be location conveyance but service >boundary conveyance. err, this is a location (which can be either small or large) being "pushed" (vs. pulled or retrieved) towards a destination device. How exactly isn't this location conveyance? ;-) >But I understand your point. > >Still, the idea that the PSAP should be able to prove that it is a >PSAP is worthwhile. there was a draft on replied identification about a year ago in SIP/PING written by Feng Cao and Cullen, but it died. >This could happen with an identity instead of a >service boundary. > >-andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 29 14:15:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Kzn-0006wD-HQ; Fri, 29 Jun 2007 14:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Kzn-0006vs-5K for ecrit@ietf.org; Fri, 29 Jun 2007 14:15:03 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Kyg-0002tT-00 for ecrit@ietf.org; Fri, 29 Jun 2007 14:15:02 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 29 Jun 2007 11:13:53 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPjohEarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,476,1175497200"; d="scan'208"; a="5937172:sNHT17075268" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5TIDrN1018093; Fri, 29 Jun 2007 11:13:53 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l5TIDhGe004267; Fri, 29 Jun 2007 18:13:53 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 11:13:45 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.20.251]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 11:13:44 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 29 Jun 2007 13:13:42 -0500 To: Matt Lepinski From: "James M. Polk" Subject: Re: [Ecrit] Location hiding: VSP verification by UAS In-Reply-To: <46841BA9.909@bbn.com> References: <4683114D.8070305@bbn.com> <4683392D.8020106@bbn.com> <024401c7b97b$3639c4a0$a0acf444@cis.neustar.com> <08904E1F-0EB8-46B5-AC2A-D6CB74C239B5@hxr.us> <4683B950.5020404@bbn.com> <002901c7b99f$7da01410$1772f544@cis.neustar.com> <4683FE38.5060407@bbn.com> <46841BA9.909@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 29 Jun 2007 18:13:44.0785 (UTC) FILETIME=[3B0CC410:01C7BA79] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8135; t=1183140833; x=1184004833; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Location=20hiding=3A=20VSP=20verification=2 0by=20UAS |Sender:=20; bh=CFhNucR0w6qEa7xGfYUoLe6m76PBjmxATrA407vmYA0=; b=XSe/9skYZxiwrAljYmgxbW6YvGk29cOwutHuOD/su8+T82HoFPXpZBX4c7QqXCO4NF55+mOj xrBRFvxGqFxQBFuPEnVUMFW2aDNXuoTrZ9GGNgQg2y1oEC++VxjOl3D6; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 03:35 PM 6/28/2007, Matt Lepinski wrote: >James, > >James M. Polk wrote: > >>I think also that if you build a PIDF-LO for the coverage area of a >>PSAP, you aren't going to use civic, as I don't think PSAP >>boundaries are absolutely limited to a defined city or county >>perimeter. I remember being railed on because PSAP boundaries often >>are the middle line of a street, where one side of the street is >>PSAP-A and the other side of the street is PSAP-B. This means that >>this street cannot be a boundary delineation between PSAP coverage >>areas. This gets you into coordinate or geo formats (basically, >>the linear ring concept within GML). This can be HUGE in xml with >>all the points you have to include, if you want to be precise, and >>since SIP cannot error response messages, this 200OK message will >>likely be substantially larger than the request (which will likely >>be in civic) - therefore the packet might get too large and require >>an error message to it. > >If the point is verifying that the end-point is a PSAP, then it's >not necessary for the PSAP to convey the entire boundry of the >service region to the VSP. All that's needed is for the PSAP to hand >the VSP an arbitrary point in the service region. The VSP can then >query LoST with this point and see that the result matches the URI >to which the call was routed. fair (i.e., point taken) I sit corrected >That is, the VSP doesn't care what the service region is for the >PSAP. All the VSP cares about is that there exists at least point >for which the callee is a valid PSAP. > >- Matt Lepinski :-> > >> >>>you've got other problems above and beyond VSP verification. >>> >>>--Richard >>> >>> >>> >>>Brian Rosen wrote: >>> >>>>To get the location of the PSAP, you need an UPDATE, with the >>>>PSAP doing the >>>>update and becoming the UAC because it's reliable. Conveyance is defined >>>>from UAC to UAS only, for this, among other reasons. >>>>Brian >>>> >>>>>-----Original Message----- >>>>>From: Richard Barnes [mailto:rbarnes@bbn.com] >>>>>Sent: Thursday, June 28, 2007 9:36 AM >>>>>To: Andrew Newton >>>>>Cc: Brian Rosen; 'James M. Polk'; 'ECRIT' >>>>>Subject: Re: [Ecrit] Location hiding: VSP verification by UAS >>>>> >>>>>Right. In either cases, the VSP would be free to consider a call >>>>>unverified if no authenticator were presented after a certain period >>>>>(this period would be good to specify in a BCP). >>>>> >>>>>--Richard >>>>> >>>>> >>>>> >>>>> >>>>>Andrew Newton wrote: >>>>> >>>>>>I don't see how an UPDATE helps. And the endpoint can simply not issue >>>>>>the UPDATE to get around the verification. >>>>>> >>>>>>I think Richard's proposal has legs. >>>>>> >>>>>>-andy >>>>>> >>>>>>On Jun 28, 2007, at 7:55 AM, Brian Rosen wrote: >>>>>> >>>>>>>We would have to do it with an Update. >>>>>>> >>>>>>>I am uncomfortable with this idea, as it complicates the message flow >>>>>on >>>>> >>>>>>>every emergency call. >>>>>>> >>>>>>>The basic idea has merit, but the details don't work for me. >>>>>>> >>>>>>>Brian >>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: Richard Barnes [mailto:rbarnes@bbn.com] >>>>>>>>Sent: Thursday, June 28, 2007 12:30 AM >>>>>>>>To: James M. Polk >>>>>>>>Cc: ECRIT >>>>>>>>Subject: Re: [Ecrit] Location hiding: VSP verification by UAS >>>>>>>> >>>>>>>>Hi James, >>>>>>>> >>>>>>>>>I need to see each proposed message flow. >>>>>>>> >>>>>>>>I was proposing more the conceptual flow of the UAS providing the >>>>>>>>authentication information than a specific message flow. There are >>>>>many >>>>> >>>>>>>>models that could be used: Authenticators could be conveyed in a 200, >>>>>or >>>>> >>>>>>>>in a separate UPDATE transaction (as in connected-identity). >>>>>>>> >>>>>>>>>SIP is an e2e protocol, and a >>>>>>>>>200Ok to an INVITE means the INVITE was accepted as is - and is >>>>>>>>>intended >>>>>>>>>to travel all the way back to the original UAC. SIP doesn't error >>>>>>>>>responses, which is what I feel you are proposing if the >>>>>authentication >>>>> >>>>>>>>>fails (within a VSP proxy). >>>>>>>> >>>>>>>>I don't think that it's necessarily within the purview of ECRIT to >>>>>>>>specify the behavior that results from a failed authentication. In >>>>>>>>fact, I expect that this behavior will vary widely from VSP to VSP: >>>>>One >>>>> >>>>>>>>VSP might allow the call to proceed normally, but start billing for it >>>>>>>>after the authentication fails. Another might use a B2BUA that it >>>>>>>>inserted in the path to kill the call. Et cetera. >>>>>>>> >>>>>>>>The essential thing is that allowing the UAS to provide authenticators >>>>>>>>allows the PSAP to vouch for the fact that a call is an emergency >>>>>call, >>>>> >>>>>>>>regardless of how location is provisioned. What the VSP chooses to do >>>>>>>>with that information is a local decision (though maybe we could make >>>>>>>>some non-normative recommendations). >>>>>>>> >>>>>>>>--Richard >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>At 08:39 PM 6/27/2007, Richard Barnes wrote: >>>>>>>>> >>>>>>>>>>So, the "location hiding" problem is really two problems: When the >>>>>>>>>>access network provisions location in a way that the endpoint can't >>>>>>>>>>get the location, >>>>>>>>>>(1) How does the endpoint or VSP route and emergency call? and >>>>>>>>>>(2) How can a VSP verify that a call is an emergency call? >>>>>>>>>> >>>>>>>>>>To date, solutions to the second problem have focused on performing >>>>>>>>>>this verification based on information in the INVITE. In a location >>>>>>>>>>hiding context, this approach runs into the problem that in order to >>>>>>>>>>use LoST to verify the To: URI, either the UAC, the VSP, or a LoST >>>>>>>>>>server has to dereference the location, and none of these is >>>>>>>>>>necessarily authorized to do so. >>>>>>>>>> >>>>>>>>>>On the other hand, I think the second problem is pretty easy to >>>>>solve >>>>> >>>>>>>>>>if the VSP is willing to transmit the INVITE and allow the UAS to >>>>>>>>>>provide evidence that the call is an emergency call. The PSAP, >>>>>after >>>>> >>>>>>>>>>all, is in a much better position to authenticate itself than the >>>>>UAC >>>>> >>>>>>>>>>is to authenticate it. This authentication could take several >>>>>forms: >>>>> >>>>>>>>>>1. If VSPs are willing to trust the LoST infrastructure, the PSAP >>>>>>>>>>could include its service area in its 200 response; the VSP would >>>>>>>>>>verify by performing a LoST query with the location and service URN >>>>>in >>>>> >>>>>>>>>>the SIP traffic, and compare the element in the resulting >>>>>>>>>>mapping to the To: address in the INVITE transaction. >>>>>>>>>> >>>>>>>>>>2. If PSAPs have credentials, then the PSAP could use >>>>>>>>>>connected-identity to assert its identity (or just use S/MIME to >>>>>sign >>>>> >>>>>>>>>>a 200 response with it's key). >>>>>>>>>> >>>>>>>>>>Both of these can be done with protocols that are already released >>>>>or >>>>> >>>>>>>>>>in process: Option 1 by including a GML or PIDF-LO document in the >>>>>200 >>>>> >>>>>>>>>>response (possibly indicated by a Geolocation: header), and Option 2 >>>>>>>>>>with S/MIME or connected-identity. >>>>>>>>>> >>>>>>>>>>Humbly submitted, >>>>>>>>>>--Richard >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>_______________________________________________ >>>>>>>>>>Ecrit mailing list >>>>>>>>>>Ecrit@ietf.org >>>>>>>>>>https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>> >>>>>>>> >>>>>>>>_______________________________________________ >>>>>>>>Ecrit mailing list >>>>>>>>Ecrit@ietf.org >>>>>>>>https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> >>>>>>>_______________________________________________ >>>>>>>Ecrit mailing list >>>>>>>Ecrit@ietf.org >>>>>>>https://www1.ietf.org/mailman/listinfo/ecrit >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 29 14:27:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4LBq-0001O6-2H; Fri, 29 Jun 2007 14:27:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4LBo-0001Lo-N4 for ecrit@ietf.org; Fri, 29 Jun 2007 14:27:28 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4LBg-0006ib-RG for ecrit@ietf.org; Fri, 29 Jun 2007 14:27:28 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 29 Jun 2007 14:27:20 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABnshEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,476,1175486400"; d="scan'208"; a="64032573:sNHT37205792" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5TIRKhR010172; Fri, 29 Jun 2007 14:27:20 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5TIR36c001297; Fri, 29 Jun 2007 18:27:03 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 14:27:03 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.20.251]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 14:27:03 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 29 Jun 2007 13:27:01 -0500 To: Richard Barnes From: "James M. Polk" Subject: Re: [Ecrit] Location hiding: VSP verification by UAS In-Reply-To: <46848639.7050403@bbn.com> References: <4683114D.8070305@bbn.com> <4683392D.8020106@bbn.com> <024401c7b97b$3639c4a0$a0acf444@cis.neustar.com> <08904E1F-0EB8-46B5-AC2A-D6CB74C239B5@hxr.us> <4683B950.5020404@bbn.com> <002901c7b99f$7da01410$1772f544@cis.neustar.com> <4683FE38.5060407@bbn.com> <46848639.7050403@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 29 Jun 2007 18:27:03.0383 (UTC) FILETIME=[170D2670:01C7BA7B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10121; t=1183141640; x=1184005640; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Location=20hiding=3A=20VSP=20verification=2 0by=20UAS |Sender:=20 |To:=20Richard=20Barnes=20; bh=bH014pNaJs3+/eC+SD1D+7ongt7Gigh4tPWofKJidiU=; b=jLYxPKK772d/lEVC/h5tl3V9R0TsE9MjvkE1AlvMAHojHht6VL5FqrHRyYRfckpLhpOGRT0R DQl5N1hMDFtX4Sbq6TeQIeF21xNe6mHk+cb+8KzeK6RSUqLQ6oyJ6Mp4; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 11:10 PM 6/28/2007, Richard Barnes wrote: >To be a little more concrete, if the authenticator (location/sb or >Identity header) is going to be carried in the 200/OK, then there is >no change required to the standard INVITE message flow. The proxy >simply observes the 200 as it passes by, and any action it takes >based on the authenticator is external to that transaction. > >>A caller sends an INVITE to a PSAP (regardless of how many servers >>it goes through, it's destination is towards the PSAP - even if the >>R-URI is changed). In other words, it's e2e. > >Sure. But the response will still go back through the proxies in >the Record-Route chain, so if a proxy wants to verify, it just has >to add itself into the Record-Route. The 200 will travel e2e, but >the proxy will get to see it and get the authenticator from it. > >>A 200OK to the INVITE is destined for the caller's UAC, not >>anywhere else - though servers can view unencrypted message bodies >>if location is LbyV. > >This is just an argument to put the authenticator in a header so >that proxies can see it. Makes sense to me. > >>I think also that if you build a PIDF-LO for the coverage area of a >>PSAP, you aren't going to use civic, as I don't think PSAP >>boundaries are absolutely limited to a defined city or county perimeter. ... > >This is a good point, but I think there are ways around it. Using >connected-identity instead of LoST as an authenticator is one. Even >if you do use LoST to authenticate the call, then all the PSAP >really needs to provide is a single location in its service area; >presumably the location of the PSAP will suffice in a lot of >cases. Alternatively, the message could contain no location at all, >and carry an service boundary reference that could be used to get >the location to do the verification. > >>This is part of the reason (but not specifically about PSAP >>boundaries) that location is not to be in SIP responses. This is >>part of section 5.2 UAS Behavior of Conveyance. > >I don't really see the harm here. Conveyance is written (now) as a general purpose mechanism for conveying location, as such, there are no exceptions made because the UAS is a PSAP, even for responses. As stated, location cannot be in responses from any UAS according to the text in Conveyance -08. >I guess the risk is that the PSAP puts in a location that the VSP >can't understand, the risk is that any other UAS can do what the PSAP UAS can do, if Conveyance says location can be in responses. >but it seems like you could write the phonebcp in such a way as to >constrain this, e.g., "the value in the Geolocation header MUST be a >cid URI" or "MUST be an HTTP URI". Even if there is an error with >the Geolocation value, the risk is mostly that the call won't >authenticate and the call gets handled as a non-emergency call. The larger concern is that there is an error with the SIP response, which cannot be reacted to, so the UAS sender will never know it is causing the problem by including location in the response. >This seems like a small risk, and one that could be addressed in the >phonebcp (e.g., "VSPs MUST NOT terminate unverifable emergency >calls, but MAY choose to handle them as they would non-emergency calls"). > >(As a general point, I don't see anything in section 5.2 that >forbids putting Geolocation into a response, and Table 1 explicitly >indicates that Geolocation can be carried in responses. Table 1 has an 'R' in the 'where' column, which means "not to be in responses", according to the rules of RFC 3261. Section 5.2 of Conveyance says "A UAS MUST NOT send location in a response message..." both are pretty clear >We should move any further debate on this to another forum, though.) indeed, as this is a SIP protocol issue, not an ECRIT issue >--Richard > >>>you've got other problems above and beyond VSP verification. >>> >>>--Richard >>> >>> >>> >>>Brian Rosen wrote: >>>>To get the location of the PSAP, you need an UPDATE, with the >>>>PSAP doing the >>>>update and becoming the UAC because it's reliable. Conveyance is defined >>>>from UAC to UAS only, for this, among other reasons. >>>>Brian >>>>>-----Original Message----- >>>>>From: Richard Barnes [mailto:rbarnes@bbn.com] >>>>>Sent: Thursday, June 28, 2007 9:36 AM >>>>>To: Andrew Newton >>>>>Cc: Brian Rosen; 'James M. Polk'; 'ECRIT' >>>>>Subject: Re: [Ecrit] Location hiding: VSP verification by UAS >>>>> >>>>>Right. In either cases, the VSP would be free to consider a call >>>>>unverified if no authenticator were presented after a certain period >>>>>(this period would be good to specify in a BCP). >>>>> >>>>>--Richard >>>>> >>>>> >>>>> >>>>> >>>>>Andrew Newton wrote: >>>>>>I don't see how an UPDATE helps. And the endpoint can simply not issue >>>>>>the UPDATE to get around the verification. >>>>>> >>>>>>I think Richard's proposal has legs. >>>>>> >>>>>>-andy >>>>>> >>>>>>On Jun 28, 2007, at 7:55 AM, Brian Rosen wrote: >>>>>> >>>>>>>We would have to do it with an Update. >>>>>>> >>>>>>>I am uncomfortable with this idea, as it complicates the message flow >>>>>on >>>>>>>every emergency call. >>>>>>> >>>>>>>The basic idea has merit, but the details don't work for me. >>>>>>> >>>>>>>Brian >>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: Richard Barnes [mailto:rbarnes@bbn.com] >>>>>>>>Sent: Thursday, June 28, 2007 12:30 AM >>>>>>>>To: James M. Polk >>>>>>>>Cc: ECRIT >>>>>>>>Subject: Re: [Ecrit] Location hiding: VSP verification by UAS >>>>>>>> >>>>>>>>Hi James, >>>>>>>> >>>>>>>>>I need to see each proposed message flow. >>>>>>>>I was proposing more the conceptual flow of the UAS providing the >>>>>>>>authentication information than a specific message flow. There are >>>>>many >>>>>>>>models that could be used: Authenticators could be conveyed in a 200, >>>>>or >>>>>>>>in a separate UPDATE transaction (as in connected-identity). >>>>>>>> >>>>>>>>>SIP is an e2e protocol, and a >>>>>>>>>200Ok to an INVITE means the INVITE was accepted as is - and is >>>>>>>>>intended >>>>>>>>>to travel all the way back to the original UAC. SIP doesn't error >>>>>>>>>responses, which is what I feel you are proposing if the >>>>>authentication >>>>>>>>>fails (within a VSP proxy). >>>>>>>>I don't think that it's necessarily within the purview of ECRIT to >>>>>>>>specify the behavior that results from a failed authentication. In >>>>>>>>fact, I expect that this behavior will vary widely from VSP to VSP: >>>>>One >>>>>>>>VSP might allow the call to proceed normally, but start billing for it >>>>>>>>after the authentication fails. Another might use a B2BUA that it >>>>>>>>inserted in the path to kill the call. Et cetera. >>>>>>>> >>>>>>>>The essential thing is that allowing the UAS to provide authenticators >>>>>>>>allows the PSAP to vouch for the fact that a call is an emergency >>>>>call, >>>>>>>>regardless of how location is provisioned. What the VSP chooses to do >>>>>>>>with that information is a local decision (though maybe we could make >>>>>>>>some non-normative recommendations). >>>>>>>> >>>>>>>>--Richard >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>At 08:39 PM 6/27/2007, Richard Barnes wrote: >>>>>>>>>>So, the "location hiding" problem is really two problems: When the >>>>>>>>>>access network provisions location in a way that the endpoint can't >>>>>>>>>>get the location, >>>>>>>>>>(1) How does the endpoint or VSP route and emergency call? and >>>>>>>>>>(2) How can a VSP verify that a call is an emergency call? >>>>>>>>>> >>>>>>>>>>To date, solutions to the second problem have focused on performing >>>>>>>>>>this verification based on information in the INVITE. In a location >>>>>>>>>>hiding context, this approach runs into the problem that in order to >>>>>>>>>>use LoST to verify the To: URI, either the UAC, the VSP, or a LoST >>>>>>>>>>server has to dereference the location, and none of these is >>>>>>>>>>necessarily authorized to do so. >>>>>>>>>> >>>>>>>>>>On the other hand, I think the second problem is pretty easy to >>>>>solve >>>>>>>>>>if the VSP is willing to transmit the INVITE and allow the UAS to >>>>>>>>>>provide evidence that the call is an emergency call. The PSAP, >>>>>after >>>>>>>>>>all, is in a much better position to authenticate itself than the >>>>>UAC >>>>>>>>>>is to authenticate it. This authentication could take several >>>>>forms: >>>>>>>>>>1. If VSPs are willing to trust the LoST infrastructure, the PSAP >>>>>>>>>>could include its service area in its 200 response; the VSP would >>>>>>>>>>verify by performing a LoST query with the location and service URN >>>>>in >>>>>>>>>>the SIP traffic, and compare the element in the resulting >>>>>>>>>>mapping to the To: address in the INVITE transaction. >>>>>>>>>> >>>>>>>>>>2. If PSAPs have credentials, then the PSAP could use >>>>>>>>>>connected-identity to assert its identity (or just use S/MIME to >>>>>sign >>>>>>>>>>a 200 response with it's key). >>>>>>>>>> >>>>>>>>>>Both of these can be done with protocols that are already released >>>>>or >>>>>>>>>>in process: Option 1 by including a GML or PIDF-LO document in the >>>>>200 >>>>>>>>>>response (possibly indicated by a Geolocation: header), and Option 2 >>>>>>>>>>with S/MIME or connected-identity. >>>>>>>>>> >>>>>>>>>>Humbly submitted, >>>>>>>>>>--Richard >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>_______________________________________________ >>>>>>>>>>Ecrit mailing list >>>>>>>>>>Ecrit@ietf.org >>>>>>>>>>https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>>> >>>>>>>> >>>>>>>>_______________________________________________ >>>>>>>>Ecrit mailing list >>>>>>>>Ecrit@ietf.org >>>>>>>>https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>>_______________________________________________ >>>>>>>Ecrit mailing list >>>>>>>Ecrit@ietf.org >>>>>>>https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jun 29 16:32:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4N8G-0003IR-Vb; Fri, 29 Jun 2007 16:31:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4N8F-0003G6-UD for ecrit@ietf.org; Fri, 29 Jun 2007 16:31:56 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4N8F-0004mb-Co for ecrit@ietf.org; Fri, 29 Jun 2007 16:31:55 -0400 Received: from [68.244.71.20] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I4N7d-0003Rg-OU; Fri, 29 Jun 2007 15:31:19 -0500 From: "Brian Rosen" To: "'James M. Polk'" , "'Richard Barnes'" References: <4683114D.8070305@bbn.com> <4683392D.8020106@bbn.com> <024401c7b97b$3639c4a0$a0acf444@cis.neustar.com> <08904E1F-0EB8-46B5-AC2A-D6CB74C239B5@hxr.us> <4683B950.5020404@bbn.com> <002901c7b99f$7da01410$1772f544@cis.neustar.com> <4683FE38.5060407@bbn.com> <46848639.7050403@bbn.com> Subject: RE: [Ecrit] Location hiding: VSP verification by UAS Date: Fri, 29 Jun 2007 16:31:24 -0400 Message-ID: <032801c7ba8c$792eda90$1447f444@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: Ace6ex35HuFcZWQfTFGHcsxWkq69lQAETQdw In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Generally, I continue to agree that this is a worthwhile thought, but we haven't gotten to a believable (to me) mechanism. Identity is great, but outside of a global emergency PKI, how do we do that? Brian > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Friday, June 29, 2007 2:27 PM > To: Richard Barnes > Cc: Brian Rosen; 'Andrew Newton'; 'ECRIT' > Subject: Re: [Ecrit] Location hiding: VSP verification by UAS > > At 11:10 PM 6/28/2007, Richard Barnes wrote: > >To be a little more concrete, if the authenticator (location/sb or > >Identity header) is going to be carried in the 200/OK, then there is > >no change required to the standard INVITE message flow. The proxy > >simply observes the 200 as it passes by, and any action it takes > >based on the authenticator is external to that transaction. > > > >>A caller sends an INVITE to a PSAP (regardless of how many servers > >>it goes through, it's destination is towards the PSAP - even if the > >>R-URI is changed). In other words, it's e2e. > > > >Sure. But the response will still go back through the proxies in > >the Record-Route chain, so if a proxy wants to verify, it just has > >to add itself into the Record-Route. The 200 will travel e2e, but > >the proxy will get to see it and get the authenticator from it. > > > >>A 200OK to the INVITE is destined for the caller's UAC, not > >>anywhere else - though servers can view unencrypted message bodies > >>if location is LbyV. > > > >This is just an argument to put the authenticator in a header so > >that proxies can see it. Makes sense to me. > > > >>I think also that if you build a PIDF-LO for the coverage area of a > >>PSAP, you aren't going to use civic, as I don't think PSAP > >>boundaries are absolutely limited to a defined city or county perimeter. > ... > > > >This is a good point, but I think there are ways around it. Using > >connected-identity instead of LoST as an authenticator is one. Even > >if you do use LoST to authenticate the call, then all the PSAP > >really needs to provide is a single location in its service area; > >presumably the location of the PSAP will suffice in a lot of > >cases. Alternatively, the message could contain no location at all, > >and carry an service boundary reference that could be used to get > >the location to do the verification. > > > >>This is part of the reason (but not specifically about PSAP > >>boundaries) that location is not to be in SIP responses. This is > >>part of section 5.2 UAS Behavior of Conveyance. > > > >I don't really see the harm here. > > Conveyance is written (now) as a general purpose mechanism for > conveying location, as such, there are no exceptions made because the > UAS is a PSAP, even for responses. As stated, location cannot be in > responses from any UAS according to the text in Conveyance -08. > > >I guess the risk is that the PSAP puts in a location that the VSP > >can't understand, > > the risk is that any other UAS can do what the PSAP UAS can do, if > Conveyance says location can be in responses. > > >but it seems like you could write the phonebcp in such a way as to > >constrain this, e.g., "the value in the Geolocation header MUST be a > >cid URI" or "MUST be an HTTP URI". Even if there is an error with > >the Geolocation value, the risk is mostly that the call won't > >authenticate and the call gets handled as a non-emergency call. > > The larger concern is that there is an error with the SIP response, > which cannot be reacted to, so the UAS sender will never know it is > causing the problem by including location in the response. > > >This seems like a small risk, and one that could be addressed in the > >phonebcp (e.g., "VSPs MUST NOT terminate unverifable emergency > >calls, but MAY choose to handle them as they would non-emergency calls"). > > > >(As a general point, I don't see anything in section 5.2 that > >forbids putting Geolocation into a response, and Table 1 explicitly > >indicates that Geolocation can be carried in responses. > > Table 1 has an 'R' in the 'where' column, which means "not to be in > responses", according to the rules of RFC 3261. Section 5.2 of > Conveyance says "A UAS MUST NOT send location in a response message..." > > both are pretty clear > > >We should move any further debate on this to another forum, though.) > > indeed, as this is a SIP protocol issue, not an ECRIT issue > > > >--Richard > > > >>>you've got other problems above and beyond VSP verification. > >>> > >>>--Richard > >>> > >>> > >>> > >>>Brian Rosen wrote: > >>>>To get the location of the PSAP, you need an UPDATE, with the > >>>>PSAP doing the > >>>>update and becoming the UAC because it's reliable. Conveyance is > defined > >>>>from UAC to UAS only, for this, among other reasons. > >>>>Brian > >>>>>-----Original Message----- > >>>>>From: Richard Barnes [mailto:rbarnes@bbn.com] > >>>>>Sent: Thursday, June 28, 2007 9:36 AM > >>>>>To: Andrew Newton > >>>>>Cc: Brian Rosen; 'James M. Polk'; 'ECRIT' > >>>>>Subject: Re: [Ecrit] Location hiding: VSP verification by UAS > >>>>> > >>>>>Right. In either cases, the VSP would be free to consider a call > >>>>>unverified if no authenticator were presented after a certain period > >>>>>(this period would be good to specify in a BCP). > >>>>> > >>>>>--Richard > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>Andrew Newton wrote: > >>>>>>I don't see how an UPDATE helps. And the endpoint can simply not > issue > >>>>>>the UPDATE to get around the verification. > >>>>>> > >>>>>>I think Richard's proposal has legs. > >>>>>> > >>>>>>-andy > >>>>>> > >>>>>>On Jun 28, 2007, at 7:55 AM, Brian Rosen wrote: > >>>>>> > >>>>>>>We would have to do it with an Update. > >>>>>>> > >>>>>>>I am uncomfortable with this idea, as it complicates the message > flow > >>>>>on > >>>>>>>every emergency call. > >>>>>>> > >>>>>>>The basic idea has merit, but the details don't work for me. > >>>>>>> > >>>>>>>Brian > >>>>>>> > >>>>>>>>-----Original Message----- > >>>>>>>>From: Richard Barnes [mailto:rbarnes@bbn.com] > >>>>>>>>Sent: Thursday, June 28, 2007 12:30 AM > >>>>>>>>To: James M. Polk > >>>>>>>>Cc: ECRIT > >>>>>>>>Subject: Re: [Ecrit] Location hiding: VSP verification by UAS > >>>>>>>> > >>>>>>>>Hi James, > >>>>>>>> > >>>>>>>>>I need to see each proposed message flow. > >>>>>>>>I was proposing more the conceptual flow of the UAS providing the > >>>>>>>>authentication information than a specific message flow. There > are > >>>>>many > >>>>>>>>models that could be used: Authenticators could be conveyed in a > 200, > >>>>>or > >>>>>>>>in a separate UPDATE transaction (as in connected-identity). > >>>>>>>> > >>>>>>>>>SIP is an e2e protocol, and a > >>>>>>>>>200Ok to an INVITE means the INVITE was accepted as is - and is > >>>>>>>>>intended > >>>>>>>>>to travel all the way back to the original UAC. SIP doesn't error > >>>>>>>>>responses, which is what I feel you are proposing if the > >>>>>authentication > >>>>>>>>>fails (within a VSP proxy). > >>>>>>>>I don't think that it's necessarily within the purview of ECRIT to > >>>>>>>>specify the behavior that results from a failed authentication. > In > >>>>>>>>fact, I expect that this behavior will vary widely from VSP to > VSP: > >>>>>One > >>>>>>>>VSP might allow the call to proceed normally, but start billing > for it > >>>>>>>>after the authentication fails. Another might use a B2BUA that it > >>>>>>>>inserted in the path to kill the call. Et cetera. > >>>>>>>> > >>>>>>>>The essential thing is that allowing the UAS to provide > authenticators > >>>>>>>>allows the PSAP to vouch for the fact that a call is an emergency > >>>>>call, > >>>>>>>>regardless of how location is provisioned. What the VSP chooses > to do > >>>>>>>>with that information is a local decision (though maybe we could > make > >>>>>>>>some non-normative recommendations). > >>>>>>>> > >>>>>>>>--Richard > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>>At 08:39 PM 6/27/2007, Richard Barnes wrote: > >>>>>>>>>>So, the "location hiding" problem is really two problems: When > the > >>>>>>>>>>access network provisions location in a way that the endpoint > can't > >>>>>>>>>>get the location, > >>>>>>>>>>(1) How does the endpoint or VSP route and emergency call? and > >>>>>>>>>>(2) How can a VSP verify that a call is an emergency call? > >>>>>>>>>> > >>>>>>>>>>To date, solutions to the second problem have focused on > performing > >>>>>>>>>>this verification based on information in the INVITE. In a > location > >>>>>>>>>>hiding context, this approach runs into the problem that in > order to > >>>>>>>>>>use LoST to verify the To: URI, either the UAC, the VSP, or a > LoST > >>>>>>>>>>server has to dereference the location, and none of these is > >>>>>>>>>>necessarily authorized to do so. > >>>>>>>>>> > >>>>>>>>>>On the other hand, I think the second problem is pretty easy to > >>>>>solve > >>>>>>>>>>if the VSP is willing to transmit the INVITE and allow the UAS > to > >>>>>>>>>>provide evidence that the call is an emergency call. The PSAP, > >>>>>after > >>>>>>>>>>all, is in a much better position to authenticate itself than > the > >>>>>UAC > >>>>>>>>>>is to authenticate it. This authentication could take several > >>>>>forms: > >>>>>>>>>>1. If VSPs are willing to trust the LoST infrastructure, the > PSAP > >>>>>>>>>>could include its service area in its 200 response; the VSP > would > >>>>>>>>>>verify by performing a LoST query with the location and service > URN > >>>>>in > >>>>>>>>>>the SIP traffic, and compare the element in the resulting > >>>>>>>>>>mapping to the To: address in the INVITE transaction. > >>>>>>>>>> > >>>>>>>>>>2. If PSAPs have credentials, then the PSAP could use > >>>>>>>>>>connected-identity to assert its identity (or just use S/MIME to > >>>>>sign > >>>>>>>>>>a 200 response with it's key). > >>>>>>>>>> > >>>>>>>>>>Both of these can be done with protocols that are already > released > >>>>>or > >>>>>>>>>>in process: Option 1 by including a GML or PIDF-LO document in > the > >>>>>200 > >>>>>>>>>>response (possibly indicated by a Geolocation: header), and > Option 2 > >>>>>>>>>>with S/MIME or connected-identity. > >>>>>>>>>> > >>>>>>>>>>Humbly submitted, > >>>>>>>>>>--Richard > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>_______________________________________________ > >>>>>>>>>>Ecrit mailing list > >>>>>>>>>>Ecrit@ietf.org > >>>>>>>>>>https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>>> > >>>>>>>> > >>>>>>>>_______________________________________________ > >>>>>>>>Ecrit mailing list > >>>>>>>>Ecrit@ietf.org > >>>>>>>>https://www1.ietf.org/mailman/listinfo/ecrit > >>>>>>> > >>>>>>>_______________________________________________ > >>>>>>>Ecrit mailing list > >>>>>>>Ecrit@ietf.org > >>>>>>>https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit