Re: [Ecrit] Location Determination Platforms in DSL wholesale inCanada

[Francois Menard <[e-mail]>]

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]