Re: [Geopriv] Geo in ENUM

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

Wouldn't presume to speak for Australia.  Over here, we're faced with the
fact that no one wants to invest in the legacy systems and they are
expensive to maintain.  It works out best to replace the legacy system with
a new mechanism.  It requires some investment in the new system, but it's
overall less expensive than throwing money at the old system.

Thus, we're going to dismantle the centralized "ALI" database, and make a
per-carrier (or per switch if the carrier wants to) TN-to-address database,
with a HELD or SIP interface.  The content, and the provisioning mechanism
isn't really much different from the current ALI, but the database itself
will be different.

Your mileage may vary.

Brian

> -----Original Message-----
> From: Dawson, Martin [mailto:Martin.Dawson at andrew.com]
> Sent: Tuesday, August 26, 2008 10:16 PM
> To: Brian Rosen; Richard Barnes
> Cc: GEOPRIV
> Subject: RE: [Geopriv] Geo in ENUM
> 
> I gave a presentation on VoIP emergency calling to the regulator (ACMA)
> here in Australia a few weeks back.
> 
> During Q&A one of the attendees asked whether the IPND (integrated
> public number database) that the emergency call centre has for all POTS
> lines would still be necessary in an all-IP world.
> 
> I responded that *if* there are phone subscriptions that *really really*
> are fixed in location - no possibility of nomadicity, ever - then the
> IPND could still be useful for those services. However, bearing in mind
> that the Internet connection associated with those subscriptions, and
> the Internet provider in general, would still need to provide a location
> service for non-fixed calling, then why would you not just use the same
> infrastructure even for the fixed services?
> 
> Leaving interim/transitional/legacy issues aside - in the long term I
> don't think you would. So why invent new technologies to support the
> idea?
> 
> Cheers,
> Martin
> 
> -----Original Message-----
> From: geopriv-bounces at ietf.org [mailto:geopriv-bounces at ietf.org] On
> Behalf Of Brian Rosen
> Sent: Wednesday, 27 August 2008 5:06 AM
> To: 'Richard Barnes'
> Cc: 'GEOPRIV'
> Subject: Re: [Geopriv] Geo in ENUM
> 
> 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
> 
> --------------------------------------------------------------------------
> ----------------------
> 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]

_______________________________________________
Geopriv mailing list
Geopriv at ietf.org
https://www.ietf.org/mailman/listinfo/geopriv