Re: [Geopriv] Geo in ENUM

[Richard Barnes <rbarnes at bbn.com>]

Brian,

Can you clarify why you think this is a bad idea?

I agree that putting "possession model" location URIs in the ENUM tree 
poses privacy risks.  I don't think that LbyR in general poses as big a 
risk, since the deref server can authenticate and apply access control 
to dereference requests.  This would work well in the emergency case.

The model that James and Alex are discussing (above/sibling in this 
thread) adds even another layer of indirection/authentication/access 
control by intermediating a presence server / HSS.  The PSAP could use 
the TN to find a presence server and ask for location; the presence 
server could authenticate the PSAP and apply authorization policy before 
providing an answer.

--Richard




Brian Rosen wrote:
> Generally, NENA's NG9-1-1 architecture would not appreciate more complexity
> in location conveyance.  We expect each call to arrive with location in a
> SIP Geolocation header (by value or by reference).
> 
> We assume that, indeed, for a legacy wireline network connecting to an
> NG9-1-1 PSAP, that there will be a database indexed by telephone number
> containing location.  That issue is local to the carrier that owns that
> legacy system; it must deliver SIP calls with location.
> 
> One way to do that is to create a location reference that is of the form
> heldref://2025551212 at lis.example.com.  Actually, we're likely to suggest
> that at a minimum, the TN be hashed, just because of privacy issues.  That
> makes the PSAP do the dereference on the LIS that has the TN-to-location
> information. On the other hand, since this is legacy wireline, it may be
> that the gateway does the dereference and puts the location by value on the
> SIP call.  In that case, the gateway and the LIS have to agree on how the
> gateway queries the LIS when all it has is the TN of the caller.  It could
> use a reference like the above, or something else.
> 
> What we're not going to do is allow the call to arrive without location, and
> imply that the TN is used to query an ENUM database to get a location
> reference.
> 
> So, at least for North American emergency calls, this is a bad idea.
> 
> Brian
> 
>> -----Original Message-----
>> From: geopriv-bounces at ietf.org [mailto:geopriv-bounces at ietf.org] On Behalf
>> Of creed at opengeospatial.org
>> Sent: Tuesday, August 26, 2008 9:31 AM
>> To: Alexander Mayrhofer
>> Cc: GEOPRIV
>> Subject: Re: [Geopriv] Geo in ENUM
>>
>> May be appropriate to bring these use cases up with the Next Generation
>> 9-1-1 community. Location is a major design component at multiple levels
>> in the i3 architecture and is discussed in a number of NG 9-1-1 Working
>> Groups.
>>
>> Regards
>>
>> Carl
>>
>>
>>>> I just saw your document in ENUM proposing a location ENUM
>>>> service.  Why
>>>> is this necessary in addition to the U-NAPTR mechanism in the LIS
>>>> discovery document?  (draft-ietf-geopriv-lis-discovery)  It
>>>> seems like
>>>> you could just one of the U-NAPTR records as defined there with an
>>>> e164.arpa domain to do what you're doing.  Is there something special
>>>> about the e164.arpa domain that requires a separate NAPTR mechanism?
>>> Hello Richard,
>>>
>>> i've reviewed the LIS Discovery draft, and it has a very different use
>>> case from what i'm trying to achieve with the "Geo" ENUM service.
>>>
>>> The LIS discovery draft says in the introduction that the URI retrieved
>>> can jsut be used for location configuration of the requestor, not as a
>>> location by reference URI. That's exactly the contrary of what i'm
>>> trying to achieve with the ENUM-Service: The ENUM service is supposed to
>>> carry a location-by-reference URI for the device that uses the
>>> corresponding phone number, and that URI would not be used for location
>>> configuration.
>>>
>>>
>>> This might be useful in a scenario like this:
>>>
>>> - Carrier A delivers an emergency call to a PSAP using "normal" PSTN
>>> transport.
>>> - PSAP receives only the number, but can "look up" the
>>> location-by-reference URI by means of an ENUM tree (that tree may very
>>> likely be private to carriers and PSAPs)
>>> - PSAP dereferences location-by-reference URI gathered from ENUM.
>>>
>>> Another scenario might be a quite "open" scenario, like:
>>>
>>> - I configure the location-by-reference URI into my public ENUM entry.
>>> - everybody can look up that ENUM entry by my phone number
>>> - However, i limit location dereferencing to "people i know".
>>>
>>> Hope that made the difference in use cases (compared to the
>>> lis-discovery draft) clear.
>>>
>>> (BTW, small nit - i've not read the held: URI spec, but you say in
>>> section 2 that there "is no default port", while the port component is
>>> not included in the example URI in section 4)
>>>
>>>
>>> Alex
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv at ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>
>>
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv at ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv at ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
> 
_______________________________________________
Geopriv mailing list
Geopriv at ietf.org
https://www.ietf.org/mailman/listinfo/geopriv