Re: [Geopriv] [Ecrit] Location Determination Platforms in DSL wholesaleinCanada

["Thomson, Martin" <[e-mail]>]

[Limiting this to geopriv since I'm only discussing location-related issues]

Francois,

I can see that you are concerned about the exchange between ISP and wholesale provider (infrastructure provider).

As you note the lis2lis drafts you refer to are long expired.  These documents are expired for two reasons: firstly, James and I have not had enough time to dedicate to this work; secondly, there have been changes in the way that ISP-infrastructure interaction is defined.

Historically, the view has been that the relationship between ISP and infrastructure is sensitive.  To that end, these documents were written to facilitate multiple modes of operation.  As written the measurements (and identity) draft assume that the holder of location information (in this case, the infrastructure provider) is only willing to provide that information in response to direct need.

No mechanism is provided to facilitate transfers of databases.  Because significant investment is made in creating and maintaining location databases, this was seen to provide the database owner the best protection for their investment - or at least to allow for that possibility.

Of course, the push model that you refer to is possible.  However, this doesn't need HELD extensions - the exchange doesn't map onto HELD - it's another protocol.

In the UK model, the exchange is how you seem to want it (infrastructure provider -> ISP).  However, this is performed when CPE registers and acquires an address.  Again, this isn't HELD.  I'm not up with the details, but I think that the necessary info is passed in either PPP or RADIUS, depending on the deployment details.

--Martin

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Francois Menard
> Sent: Sunday, 9 August 2009 11:49 PM
> To: Hannes Tschofenig
> Cc: [e-mail]; 'ecrit'
> Subject: Re: [Ecrit] Location Determination Platforms in DSL
> wholesaleinCanada
> Importance: High
> 
> 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: [e-mail] 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
> >>> [e-mail]
> >>>
> >>>
> >>> _______________________________________________
> >>> Ecrit mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/ecrit
> >>
> >> Francois Menard
> >> [e-mail]
> >>
> >>
> >>
> >> _______________________________________________
> >> Ecrit mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/ecrit
> >>
> >
> 
> Francois Menard
> [e-mail]
> 
> 
> 
> Francois Menard
> [e-mail]
> 
> 
> 
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit

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