Re: [Ecrit] Location Determination Platforms in DSL wholesale inCanada
Francois Menard <fmenard@xittel.net> Sun, 09 August 2009 13:48 UTC
Return-Path: <fmenard@xittel.net>
X-Original-To: ecrit@core3.amsl.com
Delivered-To: ecrit@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 808493A69D7; Sun, 9 Aug 2009 06:48:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level:
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vhmct2iMPUSo; Sun, 9 Aug 2009 06:48:11 -0700 (PDT)
Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id E3EFB3A69B4; Sun, 9 Aug 2009 06:48:10 -0700 (PDT)
Received: from relay2.infoteck.qc.ca ([205.151.16.16]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from <fmenard@xittel.net>) id 1Ma8kv-0001X8-5x; Sun, 09 Aug 2009 09:48:13 -0400
Received: from [207.96.236.65] (helo=[192.168.3.252]) by relay2.infoteck.qc.ca with esmtpa (Exim 4.69) (envelope-from <fmenard@xittel.net>) id 1Ma8kv-0001Af-94; Sun, 09 Aug 2009 09:48:13 -0400
From: Francois Menard <fmenard@xittel.net>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
In-Reply-To: <011801ca18bf$34a502d0$be5ca20a@nsnintra.net>
X-Priority: 1
References: <36E6ED93-ACE3-4AD2-A7FF-ACF11D5D5007@xittel.net><E51D5B15BFDEFD448F90BDD17D41CFF104A34473@AHQEX1.andrew.com> <826C0AAE-B404-4797-91BB-0C694C76B63B@xittel.net> <011801ca18bf$34a502d0$be5ca20a@nsnintra.net>
Message-Id: <D8CB8FA9-E270-4412-857D-2385A6CA833C@xittel.net>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Sun, 09 Aug 2009 09:48:12 -0400
X-Mailer: Apple Mail (2.935.3)
Cc: geopriv@ietf.org, 'ecrit' <ecrit@ietf.org>
Subject: Re: [Ecrit] Location Determination Platforms in DSL wholesale inCanada
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ecrit>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Aug 2009 13:48:12 -0000
Hannes, thanks for the pointers. My assertion into my submission to our Canadian regulator, in my final concluding paragraph (of August 7), was: *********** CISP is Coalition of Internet Service Providers inc. (www.cfai-cisp.ca) 1. Finally, CISP submits that considering that the SIP location conveyance[1] standard draft is finally set to be forwarded for approval by the IESG in August 2009 as an IETF proposed standard, the widescale worldwide implementation is now guaranteed and known manufacturers of ATAs and SIP Phones in Canada are already working on its implementation. CISP submits that it will likely take less time to see wide scale roll out of SIP location conveyance than it will take for the Canadian industry to agree on ILEC hosted-LIS to ISP Location Determination platform specifications (and for which there are no standardization initiatives to begin with at this time). ************* So let's look at them one by one. 1) http://tools.ietf.org/html/draft-winterbottom-geopriv-held-lis2lis-bcp-00 is dated November 9 2007 and which has expired on May 12, 2008. It does refer to draft-winterbottom-geopriv-lis2lis-req-00, which is not the latest version. 2) http://tools.ietf.org/html/draft-thomson-geopriv-held-measurements-04 This is standards track and expires on November 5 2009. This provides measurements data. The measurement data has to be provided by the ACCESS NETWORK PROVIDER to the Internet Service Provider in the context of WHOLESALE. My issue is the use of LIS to LIS in the CONVERSE DIRECTION, which is that of obtaining CIVIC However, this document also refers to: http://tools.ietf.org/html/draft-winterbottom-geopriv-lis2lis-req-01 dated November 19, 2007 and which has expired on May 22, 2008. Presumably, as this one goes forward, its reference to http://tools.ietf.org/html/draft-winterbottom-geopriv-lis2lis-req-01 will have to follow the same route than in raft-winterbottom- geopriv-held-identity-extensions-09 and get filtered out, for this not being an RFC. However http://tools.ietf.org/html/draft-winterbottom-geopriv-lis2lis-req-01 is is PRECISELY what I was trying to hunt down, insofar as whether the IETF had considered formalizing this LIS to LIS protocol. So we finally get to: 3) http://tools.ietf.org/id/draft-winterbottom-geopriv-held-identity-extensions-09 This document is standards-track and expires August 29, 2009. This document clearly shows as being the one that's closest to formalizing the use of HELD across INCUMBENT OPERATOR to COMPETITIVE ISP boundary I find this in section 1.1, which clearly points to the usage case we're considering here in Canada: *** A third party LR can be granted authorization to make requests for a given Target. In particular, network services can be permitted to retrieve location for a Device that is unable to acquire location information for itself (see Section 6.3 of [I-D.ietf-ecrit-phonebcp]). This allows use of location-dependent applications--particularly essential services like emergency calling--where Devices do not support a location configuration protocol (LCP) or they are unable to successfully retrieve location information. *** However the problem is this is a PULL MODEL, and rather what we want here is a PUSH MODEL, where the ISP who operates a LOCATION DETERMINATION PLATFORM, would PUSH into the ILEC LIS, a TUPLET of information in the form of LOCATION-URI and/or CIRCUIT-ID and/or CABLE MODEM MAC ADDRESS along with the CIVIC PIDF-LO OBJECT. So I do not find that http://tools.ietf.org/id/draft-winterbottom-geopriv-held-identity-extensions-09 clearly stipulates what the LIS-to-LIS protocol ought to be, for the aforementioned application. So basically, I feel that my assertion, as I have filed it to the regulator is correct. There is no current standards-track initiative in the IETF to specific a protocol for LIS to LIS communications, which is what our incumbent telephone operators in Canada are trying to push for. This is a significant problem, which will need to be formally adressed by GEOPRIV. So a question to the group: Would the specification of HELD as a PUSH protocol to send PIDF-LO updates to a LOCATION INFORMATION SERVER in the context of an ISP LIS pushing this into an EMERGENCY SERVICE PROVIDER LIS, be welcomed by the group? I will further assert that http://tools.ietf.org/html/draft-winterbottom-geopriv-lis2lis-req-01 DID not anticipate the notion of providing LOCATION UPDATES, which are much more akin to PRESENCE I also find the notion of location updates to be referred to in 4) http://tools.ietf.org/html/draft-winterbottom-geopriv-deref-protocol-04 This is also standards track. I find from the various versions of that document, that the notion of LOCATION UPDATES has washed out. So my conclusion, is that the Canadian ILEC proposed solution requires use of somekind of LIS UPDATE PUSH PROTOCOL which would probably be provisioned with a LOCATION URI computed by the ISP and a PIDF-LO provided by the ISP. And that one does not exist yet. Is developing one welcomed? I look for the feedback from the group, as in Canada, we have tremendous pressure from the regulator to make this work. However, the problem I see which is the biggest one, is not technical at all, and lies in the fact that being the Emergency Service Provider, the ILECs in Canada have the ability to monitor the entire competitive industry if they are getting Location Updates for all current broadband accesses of all competitors. This is why I favour the concept of SIPCORE PIDF-LO LOCATION CONVEYANCE, at the TIME of an emergency call, END-to-END, where the first end is the residential subscriber and the other end, is the ILEC which is OPERATING the Emergency Service Routing Proxy / Media Gateway (which in Canada, will not be on the Internet, but rather over an MPLS/ VPN private route to the ILEC and will more than likely require the Voice over IP service provider to implement a session border controller with media proxy). F. On 9-Aug-09, at 3:01 AM, Hannes Tschofenig wrote: > Hi Francois, > >> Q. is HELD meant to be used as a PIDF-LO carrying protocol >> between two LISes and is there any standards track work done >> at the IETF to make this happen? > > A: The LIS-to-LIS communication is provided by the usage of > http://tools.ietf.org/id/draft-winterbottom-geopriv-held-identity-extensions > -09.txt > http://tools.ietf.org/html/draft-thomson-geopriv-held-measurements-04 > > For a bit more background there is another document: > http://tools.ietf.org/html/draft-winterbottom-geopriv-held-lis2lis-bcp-00 > > Ciao > Hannes > >> >> F. >> >> On 8-Aug-09, at 7:20 PM, Winterbottom, James wrote: >> >>> Francois, >>> >>> Why do you think that this mailing list has any more insight >> into this >>> than you do? >>> Why don't you simply ask the ILECs what they mean? >>> >>> Regards >>> James >>> >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org on behalf of Francois Menard >>> Sent: Sat 8/8/2009 10:39 AM >>> To: ecrit >>> Subject: [Ecrit] Location Determination Platforms in DSL >> wholesale in >>> Canada >>> >>> >>> In yesterday's submission to the CRTC, the ILECs have submitted the >>> following: >>> >>> --- >>> For wholesale, the ILEC LDP will interact with the Wholesale ISP by >>> responding to HELD location requests at the IP address >> assignment time >>> by the Wholesale ISP. >>> >>> The Wholesale ISP will be responsible to update the ILEC LIS >>> accordingly and in a timely fashion. >>> ---- >>> >>> This language is very confusing to me. >>> >>> Does this mean that we are enabling LIS to LIS >> communications via HELD >>> ? >>> >>> Question to the group: >>> >>> 1) What forms the query of the ISP into the ILEC LDP? >>> >>> 2) What forms the response of the ILEC LDP to the Wholesale >> ISP inside >>> the HELD location request? >>> >>> 3) What forms the push update of the Wholesale ISP into the ILEC >>> LIS? >>> >>> I have my suspicion that the ILEC has just devised a PIDF-LO >> carrying >>> protocol in the form of HELD based on a L2TP AAA data >> atypical of DSL >>> wholesale. >>> >>> Your enlightments will be great as the ILEC submission is mute on >>> this. >>> >>> F. >>> >>> -- >>> Francois Menard >>> fmenard@xittel.net >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> Francois Menard >> fmenard@xittel.net >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > Francois Menard fmenard@xittel.net
- [Ecrit] Location Determination Platforms in DSL w… Francois Menard
- Re: [Ecrit] Location Determination Platforms in D… Winterbottom, James
- Re: [Ecrit] Location Determination Platforms in D… Francois Menard
- Re: [Ecrit] Location Determination Platforms in D… Hannes Tschofenig
- Re: [Ecrit] Location Determination Platforms in D… Francois Menard
- Re: [Ecrit] Location Determination Platforms in D… Francois Menard