Subject: Re: [Geopriv] Geo in ENUM

From: "Alexander Mayrhofer" <[email-masked]>
Date: Mon, 25 Aug 2008 17:43:51 +0200

> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: Richard Barnes <[email-masked]>
Date: Mon, 25 Aug 2008 12:48:02 -0400

Alex,

Thanks for your reply.  Given the distinction between location 
configuration and location by reference, I agree that it makes more 
sense to keep these DNS entries distinct.

--Richard

---

From: [email-masked]
Date: Tue, 26 Aug 2008 09:30:58 -0400 (EDT)

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 26 Aug 2008 11:10:41 -0400

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://[email-masked].  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: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Tuesday, August 26, 2008 9:31 AM
> To: Alexander Mayrhofer
> Cc: GEOPRIV
> Subject: Re: [Geopriv] Geo in ENUM
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 26 Aug 2008 14:55:20 -0400

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

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 26 Aug 2008 15:05:46 -0400

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

> From: Richard Barnes [mailto:[email-masked]]
> Sent: Tuesday, August 26, 2008 2:55 PM
> To: Brian Rosen
> Cc: [email-masked]; 'Alexander Mayrhofer'; 'GEOPRIV'

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 26 Aug 2008 21:16:01 -0500

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brian Rosen
Sent: Wednesday, 27 August 2008 5:06 AM
To: 'Richard Barnes'
Cc: 'GEOPRIV'
Subject: Re: [Geopriv] Geo in ENUM

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.

Brian

> > in location conveyance.  We expect each call to arrive with location
in
> a
> > 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
> > What we're not going to do is allow the call to arrive without
location,
> and
> >>> trying to achieve with the ENUM-Service: The ENUM service is
supposed
> to

------------------------------------------------------------------------------------------------
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]

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 27 Aug 2008 13:57:17 -0400

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

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Tuesday, August 26, 2008 10:16 PM
> To: Brian Rosen; Richard Barnes
> Cc: GEOPRIV
> Subject: RE: [Geopriv] Geo in ENUM
> 
> > Behalf