Re: [Geopriv] Geo in ENUM

["Brian Rosen" <br at brianrosen.net>]

Because we have too many mechanisms.  This one is particularly backward
looking (TN as identifier for location, which only works when the access
network and the calling network have a relationship that lets the
TN-as-identifier work).  This one would have to be by exception.  If you
don't get a location in the call, try doing an ENUM dip to see if you can
find one.

And, of course, it runs smack into the issue of which ENUM?  There is no
current likelihood of a single ENUM tree for any one country.  That means
the PSAP has to arrange access to some indeterminate number of ENUM
databases, and it also needs some way to relate the origin of the call to
which of the databases it queries.  Ugh.

Simply requiring that ALL calls arrive with an LbyV or LbyR makes the whole
thing much simpler for everyone; one set of mechanisms that work for all
services.

A simple LbyR provides sufficient authorization, although for emergency
calls, possession is sufficient.

Brian


> -----Original Message-----
> From: Richard Barnes [mailto:rbarnes at bbn.com]
> Sent: Tuesday, August 26, 2008 2:55 PM
> To: Brian Rosen
> Cc: creed at opengeospatial.org; 'Alexander Mayrhofer'; 'GEOPRIV'
> Subject: Re: [Geopriv] Geo in ENUM
> 
> 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